RFC 189
Interim NETRJS specifications
🎀 INTERIM NETRJS SPECIFICATIONS 🎀
okay bestie, this is RFC 189 and the title block has all the tea 🫖✨
- Series: Network Working Group
- Request for Comments: 189
- Author: R. T. Braden, UCLA/CCN
- Date: 15 July 1971
- Obsoletes: RFC 88 (NIC 5668)
- Also listed as: NIC 7133
- Category: D
💌 Opening Note
okay so this doc describes how the remote job entry service to CCN's 360 Model 91 works, plus the protocol behind it 🧚 The interim protocol is going to be a production service before the end of July, and two host sites, Rand and UCLA/NMC, already wrote user processes for the interim NETRJS based on this document. If you have questions, send them to CCN's Technical Liaison 💅
it's expected that the interim protocol will be superseded in a few months by a revised NETRJS, but the changes will be minor 🫶 the revision brings the data transfer protocol of NETRJS into complete conformity with the proposed Data Transfer Protocol DTP (see RFC #171). the current differences between the DTP and NETRJS protocols are:
- (a) The format (but not the contents) of the 72 bit transaction header of NETRJS must be changed to conform with DTP.
- (b) The End-of-Data marker must be changed from
X'FE'toX'B40F'. - (c) The initial "modes available" transaction of DTP must be added.
- (d) Some of the DTP error codes will be implemented.
no other protocol changes are presently planned, although some may be suggested by operating experience with the interim protocol 👀 when the revised protocol is fully specified, it will be implemented with different ICP sockets than the interim protocol. this lets a site that wants to start using CCN immediately convert its protocol at leisure 🌸
some possible future extensions to NETRJS that have been suggested are:
- (1) A 7-bit ASCII option of data transfer connections, for the convenience of PDP-10s.
- (2) A "transparency" mode for input from ASCII remote sites, to allow the transmission of "binary decks" (object decks) in the job stream from these sites.
- (3) More than one simultaneous virtual card read, printer, and punch stream to the same virtual terminal.
comments on the utility of these proposals, or others, for your site would be appreciated 🍓
Robert T. Braden
Technical Liaison
UCLA/CCN
(213) 825-7518REMOTE JOB ENTRY TO UCLA/CCN FROM THE ARPA NETWORK (Interim Protocol)
A. Introduction ✨
NETRJS is the protocol for the remote job entry service to the 360 Model 91 at the UCLA Campus Computing Network (CCN). it lets a user at a remote host reach CCN's RJS ("Remote Job Service") sub-system, which gives remote job entry service to real remote batch (card reader/line printer) terminals over direct communications lines, as well as to the ARPA Network 🛰️
to use NETRJS, a user at a remote host needs a NETRJS user process to communicate with one of the NETRJS server processes at CCN. each active NETRJS user process appears to RJS as a separate (virtual) remote batch terminal, which we will refer to as a VRBT 🦋
a VRBT may have virtual card readers, printers, and punches. through a virtual card reader, a Network user can transmit a stream of card images comprising one or more OS/360 jobs, complete with Job Control Language, to CCN. these jobs will be spooled into CCN's batch system (OS/360 MVT) and run according to their priority. RJS will automatically return the print and/or punch output images created by these jobs to the virtual printer and/or card punch at the VRBT the job came from (or to a different destination specified in the JCL). the remote user can wait for their output, or they can sign off and sign back on later to receive it 💖
the VRBT is assumed to be under the control of the user's teletype or other remote console, which serves as an RJS remote operator console 💻 to start a NETRJS session, the remote user must execute the standard ICP (see RFC #165) to a fixed socket at CCN. the result is a duplex Telnet connection to their console, which lets them sign into RJS. once they're signed in, they can use the console to issue commands to RJS and to receive status, confirmation, and error messages from RJS. the most important RJS commands are summarized in Appendix D 📋
different VRBT's are distinguished by 8-character terminal id's. there may be more than one VRBT using RJS simultaneously from the same remote host. terminal id's for new VRBT's will be assigned by CCN to individual users or user groups who want to run batch jobs at CCN (contact the CCN Technical Liaison for details) 🎀
B. Connections and Protocols 🦋
Figure 1 shows conceptually the processes and protocols required to use NETRJS. the operator console uses a duplex connection under the Telnet third-level protocol (see RFC #158). the actual data transfer streams for job input and output are handled over separate simplex connections using a data transfer protocol 🌈
we will use the term channel for one of these NETRJS connections, and we designate it input or output with reference to CCN. each data transfer channel is identified with a particular virtual remote device -- card reader, printer, or punch. the data transfer channels need be open only while they are in use, and different channels may be used sequentially or simultaneously. NETRJS will presently support simultaneous operation of a virtual card reader, a virtual printer, and a virtual punch (in addition to the operator console) on the same VRBT process. RJS itself will support more than one reader, printer, and punch at each remote terminal, so the NETRJS protocol could easily be expanded in the future to allow more simultaneous I/O streams to each Network user 🚀
the remote user needs a local escape convention so they can send commands directly to their VRBT process. these local VRBT commands would allow selection of the files at their host that contain job streams to be sent to the server, and files to receive job output from the server. they would also let the user open data transfer channels to the NETRJS server process, and close these connections to free buffer space or abort a transmission 🧁
when a VRBT starts a session, it has a choice of two ICP sockets, depending on whether it is an ASCII or an EBCDIC virtual terminal. an EBCDIC virtual terminal transmits and receives its data as transparent streams of 8 bit bytes (since CCN is an EBCDIC installation). it is expected that a user at an ASCII installation, however, will want their VRBT declared ASCII. RJS will then translate the input stream from ASCII to EBCDIC and translate the printer stream back to ASCII. this lets the user employ their local text editor for preparing input to CCN and for examining output 🔥 the punch stream will always be transparent, for outputting "binary decks" 👑
it should be noted that the choice of code for the operator console connections is independent of the declared terminal type. in particular, they always use ASCII under Telnet protocol, even from an EBCDIC VRBT 🙈
NETRJS protocol provides data compression, replacing repeated blanks or other characters by repeat counts. however, when the terminal id is assigned by CCN, a particular network terminal may be specified as using no data compression. in this case, NETRJS will simply truncate trailing blanks and send records in a simple "op code-length-data" form, called truncated format 🍓
C. Starting and Terminating a Session 💅
the remote user establishes a connection to RJS via the standard ICP from their socket U to socket 11 [sub] 10 (EBCDIC) or socket 13 [sub] 10 (ASCII) at host 1, IMP 1. if it succeeds, the ICP results in a pair of connections, which are in fact the NETRJS operator control connections 🧚
once the user is connected, they must enter a valid RJS signon command (SIGNON terminal-id) through their console. RJS will normally acknowledge signon with a console message. however, if RJS does not recognize the terminal-id, or has no available Line Handler for the Network, it will indicate refusal by closing both operator connections 😭 if the user attempts to open data transfer connections before their signon command is accepted, CCN will refuse the data transfer connections with an error message sent to their console 💀
suppose the operator input connection is socket S at CCN, where S is the even number sent in the ICP. then the other NETRJS channels have sockets at CCN with a fixed relation to S, as shown in the table below. until there is a suitable Network-wide solution to the problem of identity control on sockets, NETRJS will also require that the VRBT process use fixed socket offsets from its initial connection socket U. these are shown in the following table:
Channel CCN Socket Remote Socket
(Server) (User)
Telnet / Remote Operator Console Input S U + 3 \
\ Remote Operator Console Output S + 1 U + 2 / Telnet
Data / Card Reader #1 S + 2 U + 5
Transfer < Printer #1 S + 3 U + 4
\ Punch #1 S + 5 U + 6once the user is signed on, they can open data transfer channels and initiate input and output operations as explained in the following sections. to end the session, the remote user may close all connections. alternatively, the user may enter a SIGNOFF command through their console. in this case, RJS will wait until the current job output streams are complete, and then it will end the session itself by closing all connections 🌸
D. Input Operations ✨
Okay so bestie, a job stream sent to RJS at CCN is a series of logical records 🎀, and each record is a card image. A card image can be at most 80 characters long 💅, to match what OS/360 requires for job input (iykyk). You can send a "stack" of successive jobs through the card reader channel with NO end-of-job indication between them 🙈. RJS knows a new job has started when it sees a JOB card. Iconic, honestly.
To submit a job or stack of jobs for execution at CCN, the remote user must first open the card reader channel. He signals his VRBT process to issue Init (local = U + 5, foreign = S + 2, size = 8). NETRJS is listening on socket S + 2 and will normally return an RTS command, which opens the channel 🦋. But if all input buffer space within the CCN NCP is in use, the request gets refused, and the user should try again later. If the problem persists, call the Technical Liaison at CCN 📞.
Once the connection is open, the user can start sending his job stream using the protocol defined in Appendix A. For each job that's successfully spooled, he gets a confirming message on his console ✨. At the end of the stack, he must send an End-of-Data transaction to kick off processing of the last job. NETRJS then closes the channel to avoid holding buffer space unnecessarily 🧹. At any time during the session, the user can re-open the card reader channel and transmit another job stack. He can also end the session and sign on later to get his output 💖.
The user can abort the card reader channel at any time by closing the channel (his socket S + 2). NETRJS will then discard the last partially spooled job 🥲. If NETRJS finds an error (e.g., transaction sequence number error or a dropped bit), it aborts the channel by closing the connection prematurely, and also tells the user via his console that his job was discarded. That's how the race condition between End-of-Data and aborting gets solved 🧠. The user needs to retransmit only the last job. He could retransmit the entire stack (although it would be somewhat wasteful), since the CCN operating system enforces job name uniqueness by immediately "flushing" jobs with names already in the system 🗑️.
If the user's process, NCP, or host, or the Network itself fails during input, RJS will discard the job being transmitted. A message saying this job was discarded gets generated and sent to him the next time he signs on 📬. On the other hand, jobs whose receipt has been acknowledged on the operator's console won't be affected by the failure, and CCN will still execute them 🔥.
E. Output Operations 🌸
The user can wait to set up a virtual printer (or punch) and open its channel until a STATUS message on his console says output is ready. Or he can leave the output channel(s) open for the entire session, ready to receive output whenever it shows up 🫶. He can also pick which one of several available jobs gets returned, by entering the right operator commands.
To get ready for printer (or punch) output from his jobs, the user site issues Init (local = U + 4 (U + 6), foreign = S + 3 (S + 5), size = 8), respectively. NETRJS listens on these sockets and should immediately return an STR. However, because of software problems at CCN, RJS might refuse the connection and return a CLS. If that happens, try again or call the Technical Liaison 😭.
When RJS has output for a particular (virtual) terminal with a matching open output channel, it sends the output as a series of logical records using the protocol in Appendix A 🧚. The first record consists of the job name (8 characters), followed by a comma, and then the ID string from the JOB card (if there is one). In the printer stream, the first column of each record is an ASA carriage control character (see Appendix C). The punch output stream never contains carriage control characters 💅.
NETRJS sends an End-of-Data transaction and then closes an output channel at the end of the output for each complete batch job. After that, the remote site must send a new RFC (and ALL) to start output for another job. This gives the remote site a chance to allocate a new file for each job without breaking the output within a job 📁. If the user at the remote site wants to cancel (or backspace or defer) a particular job's output, he enters the appropriate RJS commands on the operator input channel (see Appendix D) 🙅♀️.
A virtual printer in NETRJS has 254 columns, not counting carriage control. RJS sends up to 255 characters of a logical record it finds in a SYSOUT data set 🌈. If the user wants to reject or fold records longer than some smaller record size, he can do that in his VRBT process.
If RJS hits a permanent I/O error while reading the disk data set, it notifies the user via his console, skips forward to the next set of system messages or SYSOUT data set in the same job, and continues 😬. In the future, RJS may be changed to send a Lost Data marker within the data stream, as well as a console message to the user. Either way, the user gets notified when output transfer terminates for each job, through messages on his console ✨.
If the user spots an error in the stream, he can issue a Backspace (BSP) command from his console to repeat the last "page" of output. He can also issue a Restart (RST) command to repeat from the last SYSOUT data set or from the beginning of the job. Or he can abort the channel by closing his socket 🛑. If he aborts the channel, RJS simulates a Backspace command, and when the user re-opens the channel, the job begins transmission again from an earlier point in the same data set. This is true even if the user ends the current session first and re-opens the channel in a later session, because RJS saves the state of its output streams 💾. Before re-opening the channel, though, he can defer this job for later output, restart it at the beginning, or cancel its output (see Appendix D). Note that aborting the channel is only effective if RJS has not yet sent the End-of-Data transaction ⚠️.
If the user's process, NCP, or host, or the Network itself fails during an output operation, RJS acts as if the channel had been aborted and the user signed off. In no case should a user lose output from NETRJS 🚨.
Appendix A. Data Transfer Protocol in NETRJS 🧚♀️
1. Introduction
The records in the data transfer channels (for virtual card reader, printer, and punch) are generally grouped into _transactions_ preceded by headers 🎀. The transaction header includes a sequence number and the length of the transaction. Network byte size must be 8 bits in these data streams.
A transaction is the unit of buffering within the Model 91 software. Internal buffers are 880 bytes, so CCN cannot transmit or receive a single transaction larger than 880 bytes 🧮. Transactions can be as short as one record. However, sites that care about efficiency should send transactions as close as possible to the 880 byte limit ⚡.
There is no necessary connection between physical message boundaries and transactions ("logical messages"). The NCP can break a "logical message" apart arbitrarily into physical messages. At CCN, we choose to have each logical message start a new physical message, so the NCP can send the last part of each message without waiting for an explicit request. A remote site is not required to follow this convention 🦋.
Each logical record within a transaction begins with an "op code" byte that contains the channel identification. Its value is unique to each channel but constant within a channel. This choice provides a convenient way to verify bit synchronization at the receiver, and it also allows an extension in the future to true "multi-leaving" (i.e., multiplexing all channels within one connection in each direction) 🌸.
The only provisions for transmission error detection in the current NETRJS protocol are (1) this "op code" byte, to verify bit synchronization, and (2) the transaction sequence number 🔍. At the urging of Crowther, we favor putting an optional 16 bit check sum in the unused bytes of the second-level header. It is currently assumed that if an error is detected, the channel is to be aborted and the entire transmission repeated. To provide automatic retransmission, we would have to put in reverse channels for ACK/NAK messages 🔁.
2. Character Sets
For an ASCII VRBT, NETRJS maps ASCII in the card reader stream into EBCDIC, and re-maps the printer stream to ASCII, by the following rules 🔤:
- One-to-one mapping between the three ASCII characters
|,~,\which are not in EBCDIC, and the three EBCDIC characters [vertical bar, not-sign and cent-sign] (respectively) which are not in ASCII. - The other six ASCII graphics not in EBCDIC will be translated on input to an EBCDIC question mark (
?). - The ASCII control DC3 (the only one not in EBCDIC) will be mapped into and from the EBCDIC control TM.
- The EBCDIC characters not in ASCII will be mapped in the printer stream into the ASCII question mark (
?).
3. Meta-Notation
The following description of the NETRJS data transfer protocol uses a formal notation derived from the one proposed in RFC #31 by Bobrow and Sutherland. (The NETRJS format is also shown diagramatically in Figure 2 🧁.)
The derived notation is both concise and easily readable, and we recommend its use for Network documentation 💜. The notation consists of a series of productions for bit string variables whose names are capitalized. Each variable name that represents a fixed length field is followed by the length in bits (e.g., SEQNUMB(16)). Numbers enclosed in quotes are decimal, unless qualified by a leading X meaning hex. Since each hex digit is 4 bits, the length is not shown explicitly in hex numbers. For example, '1'(8) and X'FF' both represent a string of 8 one bits. The meta-syntactic operators are:
| :alternative string
[ ] :optional string
( ) :grouping
+ :catenation of bit stringsThe numerical value of a bit string (interpreted as an integer) is symbolized by a lower case identifier preceding the string expression and separated by a colon. For example, in "i:FIELD(8)", i symbolizes the numeric value of the 8 bit string FIELD 🔢.
Finally, we use Bobrow and Sutherland's symbolism for iteration of a sub-string: (STRING-EXPRESSION = n) denotes n occurrences of STRING EXPRESSION, implicitly catenated together. Here any n >= 0 is assumed unless n is explicitly restricted 🌈.
4. Protocol Definition ✨
okay bestie, here's the big picture 🦋 the STREAM is the entire sequence of data on one open channel. It's n TRANSACTIONS lined up one after another, then an END-OF-DATA marker at the very end 💖
STREAM <-- (TRANSACTION = n) + [END-OF-DATA]the END-OF-DATA marker gets left off if the sender aborts the channel 🙈
each TRANSACTION is a 72 bit header, r records, and f filler bits 🎀
TRANSACTION <-- THEAD(72) + (RECORD = r) + ('0'(1) = f)the header is called THEAD and it's 72 bits, so it's giving very precise 💅
THEAD <-- X'FF' + f:FILLER(8) + SEQNUMB(16) + LENGTH(32) + X'00'transactions get numbered in the SEQNUMB field, starting at 0 for the first transaction after the channel is (re-)opened ✨ the 32 bit LENGTH field gives the total length in bits of the r RECORDs that follow. and for convenience, the using site can tack on f extra filler bits at the end to hit a nice word boundary on its machine 🧚 the value f also gets sent in the FILLER field of THEAD, so it's right there in the header 💜
RECORD <-- COMPRESSED | TRUNCATEDRECORDs are either COMPRESSED or TRUNCATED 🌸 RJS will accept a mix of COMPRESSED and TRUNCATED RECORDs in an input stream, no drama 😭 but for the printer and punch streams going to a given VRBT, RJS will send one or the other format. which one gets picked is decided when CCN establishes a terminal id 🌈
COMPRESSED <-- '2'(2) + DEVID(6) + (STRING = p) + '0'(8)the STRING part comes in three flavours 🍓
STRING <-- ('6'(3) + i:DUPCOUNT(5))
This form represents a string of i
consecutive blanks
('7'(3) + i:DUPCOUNT(5) + TEXTBYTE(8))
This form represents string of i consecutive
duplicated of TEXTBYTE.
('2'(2) + j:LENGTH(6) + (TEXTBYTE(8) = j))
This form represents a string of j
characters.the first two alternatives begin with count bytes that are chosen to be distinguishable from the (currently defined) Telnet control characters. in a Telnet stream, the third count byte wouldn't be needed. this is irrelevant to the current NETRJS, but it would allow the use of compression within a Telnet data stream 🦋
TRUNCATED <-- '3'(2) + DEVID(6) + n:COUNT(8) + (TEXTBYTE(8) = n)DEVID(6) <-- DEVNO(3) + t:DEVTYPE(3)DEVID identifies a particular virtual device, which means it identifies a channel 🌷 DEVTYPE specifies the type of device, like this:
t = 1: Output to remote operator console
2: Input from remote operator console
3: Input from card reader
4: Output to printer
5: Output to card punch
6,7: UnusedDEVNO(3) identifies the particular device of type t at this remote site, and at present only DEVNO = 0 is possible 👑
END-OF-DATA <-- X'FE'END-OF-DATA signals the end of a job (output) or a job stack (input) 🏁
APPENDIX B: Telnet for VRBT Operator Console 🎀
the remote operator console connections use the ASCII Telnet protocol as in RFC #158. here's the specifics 💅
- the following one-to-one character mappings are used for the three EBCDIC graphics that aren't in ASCII:
ASCII
in Telnet NETRJS
| [vertical bar]
~ [not-sign]
\ [cent-sign]- initially, all Telnet control characters will be ignored 🙈 in the future, the plan is to implement the Telnet Break facility, so a remote user can terminate extensive console output from a command ✨
- an operator console input line that exceeds 133 characters (not counting CR LF) will be truncated by NETRJS ✂️
- NETRJS will accept BS to delete a character, and CAN to delete the current line 🧹 the sequence CR LF terminates each input and output line. HT gets translated to a single space in RJS. all other ASCII control characters will be ignored. and NETRJS will translate the six ASCII graphics that have no EBCDIC equivalent into the character question mark ("?") on input 💜
APPENDIX C: Carriage Control 🧚
the carriage control characters that NETRJS sends in a printer channel follow IBM's extended USASI code. here's the table 💖
CODE ACTION BEFORE WRITING RECORD
blank Space one line before printing
0 Space two lines before printing
- Space three lines before printing
+ Suppress space before printing
1 Skip to channel 1
2 Skip to channel 2
3 Skip to channel 3
4 Skip to channel 4
5 Skip to channel 5
6 Skip to channel 6
7 Skip to channel 7
8 Skip to channel 8
9 Skip to channel 9
A Skip to channel 10
B Skip to channel 11
C Skip to channel 12APPENDIX D: Network/RJS Command Summary 🍓
Terminal Control and Information Command
SIGNONis the first command of a session 🌸 it identifies the VRBT by giving its terminal id.SIGNOFFis the last command of a session. RJS waits for any data transfer in progress to complete, and then closes all connections 👋STATUSoutputs on the remote operator console a complete list, or a summary, of all jobs in the system for this VRBT, with an indication of their processing status in the Model 91 📋ALERToutputs on the operator console the special "Alert" message, if there is one, from the CCN computer operator 🚨 the Alert message is also automatically sent when the user does a SIGNON, or whenever the message changes.MSGsends a message to the CCN computer operator or to any other RJS terminal (real or virtual) 💌 a message from the computer operator or another RJS terminal will automatically appear on the remote operator console.
Job Control and Routing Commands
under CCN's job management system, the default destination for output is the input source. so a job submitted under a given VRBT gets returned to that VRBT (the same terminal id), unless the user's JCL overrides the default destination 🦋
RJS places print and punch output for a particular remote terminal into either an Active Queue or a Deferred Queue 🫶 when the user opens their print or punch output channel, RJS immediately starts sending job output from the Active Queue, and keeps going until this queue is empty. job output in the Deferred Queue is different: it has to be called for by job name (via a RESET command from the remote operator) before RJS will send it 🔥 the Active/Deferred choice for a job's output is decided by the deferral status of the VRBT when the job is entered. that deferral status is set to the Active option when the user signs on, and it can be changed with the SET command ✨
SETlets the remote user change certain properties of their VRBT for the duration of the current session 💅- (a) may change the default output destination to be another (real or virtual) RJS terminal or the central facility.
- (b) may change the deferral status of the VRBT.
DEFERmoves the print and punch output for a specified job or set of jobs from the Active Queue to the Deferred Queue 📦 if the job's output is in the middle of being transmitted over a channel, RJS aborts the channel and saves the current output location before moving the job. a later RESET command will return it to the Active Queue with an implied Backspace (BSP) ⏪RESETmoves specified job(s) from the Deferred Queue to the Active Queue so they can be sent to the user 🌈 a specific list of job names, or all jobs, can be moved with one RESET command.ROUTEre-routes the output of specified jobs (or all jobs) waiting in the Active and Deferred Queues for this VRBT 🧭 the new destination can be any other RJS terminal or the central facility.ABORTcancels a job that was successfully submitted and is awaiting execution, or is currently executing in the Model 91 🙅♀️ if the cancelled job was executing, all output it produced will be returned.
Output Stream Control Commands 🎀
okay bestie, these are the output stream control commands 💅 they let you mess with what's coming out of the system 🖨️
BSP (BACKSPACE) 🔙
BSP backspaces the output stream inside the current sysout data set ✨ how far it goes depends on the sysout blocking, but it's typically about a page on the line printer 📄 lowkey iconic
CAN (CANCEL) 🚫
CAN has three different vibes depending on where you use it 👑
- (a) On an output channel, CAN makes the rest of the output in the sysout data set that's currently being transmitted get omitted 💀 Alternatively, it can skip the rest of the sysout data sets for the job currently being transmitted. The remaining system and accounting messages will still be sent tho 🫶
- (b) On an input channel, CAN tells RJS to ignore the job it's currently reading 🙈 The channel isn't aborted as a result though, so RJS keeps reading in jobs on that channel like nothing happened 💖
- (c) CAN can delete all sysout data sets for specified job(s) waiting in the Active or Deferred Queue 🗑️ bye bye
RST (RESTART) 🔁
RST is the comeback queen 👑
- (a) It restarts a specified output stream at the beginning of the current sysout data set or, optionally, at the beginning of the job 🦋
- (b) It marks specified job(s) as restarted if their transmission got interrupted earlier, whether by system failure or user action (like the DEFER command or aborting the channel) 🌈 When RJS transmits these jobs again, it starts at the beginning of the partially transmitted sysout data set or, optionally, at the beginning of the job. This can be applied to jobs in either the Active or the Deferred Queue. If the job was in the Deferred Queue, RST also moves it to the Active Queue 🧚 If the job was never transmitted, RST has no effect other than this queue movement
REPEAT 🍓
REPEAT sends additional copies of the output of specified jobs. literally that's it 💅
EAM 🎧
EAM echoes the card reader stream back into the printer or punch stream, or both 🖨️✨
Now for the pictures 🖼️ Figure 1 is the whole NETRJS setup and Figure 2 is how the data moves around 🫶
+---------------------------------+
| RJS |
+---------------------------------+
^ | ^ | |
| v | v v
+------------------------------+
CCN -- Server | |
| NETRJS |
+------------------------------+
^ | ^ | |
| v | v v
+----------+ +---------------+
| TELNET | | Data Xfer | (server)
| Server | | 3rd Level |
+----------+ +---------------+
^ | ^ | |
---------------------|-----|----------|-----|-----|-----------------
O | O | | | |
p | p | C| C| C|
e I | e O| I h| O h| P h|
ARPA r n | r u| n a| u a| u a|
a p | a t| p n| t n| n n|
Network t u | t p| u n| p n| c n|
o t | o u| t e| u e| h e|
r | r t| l| t l| l|
---------------------|-----|----------|-----|-----|-----------------
| | | | |
| V | V V
+----------+ +---------------+
| TELNET | | Data Xfer | (user)
| Server | | 3rd Level |
+----------+ +---------------+
Remote ^ ^ | |
/ "Virtual | | |
User / Remote Batch | V V
/ Terminal" +------------------+
/ | |
V | NETRJS |
+---------+ | User |
/ |<------------->| Process |
/ Console | | |
+____________| +------------------+
^ | |
| V V
(file) (file) (file)
FIGURE 1. SCHEMATIC OF NETRJS OPERATION +------+ +------+ +-----------+ +---------------------+
TRANSACTION <--> | X'FF'| |Filler| |Sequence | | Data Length |
| | | Count| | Number | | in bits |
+------+ +------+ +-----------+ +---------------------+
+------+
| X'00'| { RECORD } *
| |
+------+
<---- n text bytes ------>
+--+-----+ +--------+ +--------+ +--------+
TRUNCATED <--> |11|Devid| | n (8) | | Text | . . . | Text |
RECORD | | (6) | | | | (8) | | (8) |
+--+-----+ +--------+ +--------+ +--------+
/ \
| +---+----+ | *
| |110| n | (n blanks) |
| | |(5) | |
| +---+----+ |
| |
+--+-----+ / +---+----+ +--------+ |
COMPRESSED<--> |10|Devid|< |111| n | |Char- | (n replications |
RECORD | | (6) | \ | |(5) | | acter | of "Character") |
+--+-----+ | +---+----+ +--------+ |
| |
| +--+-----+ +--------+ +--------+ |
| |10| n | | Text | . . .| Text | |
| | | (6) | | (8) | | (8) | |
| +--+-----+ +--------+ +--------+ |
\ /
+------+
| X'00'|
| |
+------+
FIGURE 2. DATA TRANSFER PROTOCOL IN NETRJS [ This RFC was put into machine readable form for entry ]
[ into the online RFC archives by Tony Hansen 11/98 ]📦 where this page comes from
- ietf: rfc189 1971-07
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms