RFC 283

NETRJT: Remote Job Service Protocol for TIPS

📅 published December 1971, from ietf

NETRJT — Remote Job Service Protocol for TIPS ✨

Okay bestie, let's get the vibes straight first 💖 This is RFC #283, written by R. T. Braden from UCLA/CCN (NIC #8165) on December 20, 1971. It's Category D, it obsoletes nothing, and it updates RFC #189 🎀

A. INTRODUCTION 🦋

Okay so TIPs (Terminal Interface Processors) have very limited processing power 🥺 Mostly they just connect printer-keyboard devices to the Network using the TELNET protocol. They can also have a tape drive, using a subset of the count form of DTP (see RFC #264). But TIPs cannot and will not support DTP or FTP (see RFC #265) in general 💀 So TIP users are shut out of every existing remote job entry protocol (e.g. CCN's NETRJS - see RFC #189). Not fair, honestly 😭

It might become possible to use TIPs for remote job entry in one of these three ways:

(a) Attach local card readers, line printers, and card punches directly to TIP ports. These devices would use a TELNET-like* format and frame their characters with Start/Stop bits. BBN can now supply a suitable 200 LPM printer, and is searching for suitable readers and punches.

(b) Connect a remote batch terminal to a full-duplex TIP port via a communication line. BBN is looking into this.

(c) Use the tape drive, and do card-to-tape and/or tape-to-print on another computer.

BBN is hoping to make case (b) look exactly like case (a) to the server host 🫶 So the remote batch terminal sends to and receives from the server in a TELNET-like format*. The printer, card reader, punch, and operator console connections all use different sockets, but they share one hardware port at the TIP, which maps multiple sockets into that one port. Main character energy, fr 👑

NOTE: By "TELNET-like format", we mean: (a) _CR_LF_ used to delimit logical records (lines or cards), and (b) the ASCII or EBCDIC format effector control characters used for carriage control in the printer stream. It does _not_ necessarily imply ASCII character codes. [ This RFC was put into machine readable form for entry ] [ into the online RFC archives by BBN Corp. under the ] [ direction of Alex McKenzie. 12/96 ]

Now the good stuff 🌸 This document describes NETRJT, which is basically a modification of CCN's NETRJS protocol, built specifically to give remote job entry service to TIPs using method (a), (b), or (c). NETRJT follows the general NETRJS model: it uses TELNET over a primary or "operator" connection pair, and opens simplex secondary connections for moving the job stream input and output. We also considered using the TIP's Divert Output mechanism to send remote job output over the operator connection (and a similar mechanism for input). But after talking with Alex McKenzie, everyone agreed that sharing the operator connections has little merit and causes lots of problems 🙈

NETRJT differs from NETRJS in two main ways, and these are the big ones 🔥

  1. The NETRJT server process starts the data transfer connections itself, under control of commands from the remote operator console. Under NETRJS, it was the remote user process that was responsible for opening the secondary data transfer connections, and the NETRJS server just listened on those sockets.
  2. NETRJT provides the TELNET-like format defined above for data transfer, as well as the TIP-tape DTP format. NETRJS, on the other hand, was limited to counts for delimiting logical records within DTP-like transactions, plus ASA carriage control.

There are some other minor differences too 🧚 (1) The NETRJT server takes care of folding output records when they exceed a size the user specifies in a command. Under NETRJS, that was the user process's job. (2) NETRJT has operator commands to set the record format, record size, and code for each data transfer connection. NETRJS made the first two fixed properties of a particular terminal id, and decided the last one by which ICP socket was chosen. All of this means NETRJT needs remote operator commands on top of the NETRJS ones. The operator needs to be able to (1) make NETRJT open a secondary connection to a TIP socket, and (2) specify the data transfer protocol, maximum logical record length, and/or transmission code. Those NETRJT commands are covered in the next section ✨

CCN plans to build a NETRJT server, with the goal of finishing an initial version by March 15, 1972 🎀 That first version may only support DTP=BS or TT, and RECFM=TELNET or RECORDS. Other options will get added as the need comes up. Comments and suggestions are very welcome 💌

Longer term, we think the NETRJT protocol described here should be considered the first draft of a Network standard for remote job entry via TIPs 🌈 In its current form, NETRJT owes a lot to the ideas and comments of Alex McKenzie (BBN), Jon Postel (NMC), Jim White (UCSB), and Steve Wolfe (CCN). Iconic team 🫶

B. NETRJT COMMANDS 💅

NETRJT adds the following commands over the remote operator connection, on top of the NETRJS operator commands (see Appendix D of RFC #189). The symbol "#" stands for one or more spaces. We use the IBM meta-language to describe the command syntax. The literal text shown here in upper case can be entered in either upper or lower case, so no stress 🍓

1. Opening a Stream

                /            \
                | PR [INTER] |  _         _
                |            | |           |
     O [PEN] # <  PU [NCH]    >| (jobname) | [ =socket-number[ /host-name ]]
                |            | |           |
                | R  [EADER] | |   (*)     |
                \            / |_         _|

If the specified device doesn't already have an open connection, the NETRJT server requests a connection to the specified socket ✨ The optional "(jobname)" parameter lets you pick out a particular job by name. For more on how that parameter works, check the discussion of input and output operations below. The "/host-name" parameter is going to be implemented later. It's meant to let the file live on a host that's different from both the user and server hosts. We only include it here to suggest a syntax 🔮

The socket number can have a one-letter suffix: D, H, or O, meaning decimal, hex, or octal. Octal is the default, so you can leave the O suffix off 🦋 If BBN sets up standardized TIP sockets for specific unit record devices, the socket number parameter can be left out whenever the standard socket number is the one you want.

2. Closing a Stream

          _            _
         | # PR [INTER] |
         |              |
CL [OSE] | # PU [NCH]   | [,A [CCEPT]]
         |              |
         | # R  [EADER] |
         |_            _|

This command closes the specified data transfer connection 🚪 The ACCEPT option tells the server that it may discard output it has already transmitted, or that it has received a complete stack of job input. There's more on that in the next section 👀 The device specification (PR, PU, or R) can be left out if only one device stream is open right now.

3. Setting Format and Device Characteristics

In each of the following variants of the RJT commands, the parameter "device" is one of "PR [INTER]", "PU [NCH]", or "R [EADER]" 💜

                         /        \
RJT # D [TP] (device) = <  B [S]   >
                         | T [T]  |
                         | D [TP] |
                         \        /
  • BS: an unstructured byte stream. Just raw vibes, no structure 🌊
  • TT: the TIP-tape transfer protocol, which is essentially the count form of Network DTP.
  • DTP: the Network standard DTP, complete with a modes-available handshake. This form isn't really useful for TIPs, but it's included here in anticipation of the general Network standard RJE protocol 🧠
                           /               \
RJT # R [ECFM] (device) = <  T [ELNET]      >
                           | A [SA]        |
                           | R [ECORDS]    |
                           | C [OMPRESSED] |
                           \               /

The choice of options below is tentative 🫧 It's not clear yet which record formats will be useful for TIP tapes or for remote batch terminals connected to TIPs, so we're keeping it flexible.

  • TELNET: the "TELNET-like format". _CR_LF_ delimits logical records in all streams, and format effector control characters (_CR_, _LF_, _FF_) handle printer carriage control.
  • ASA: CRLF delimits logical records, but an ASA carriage control character is sent as the first character of each printer record. This option may be useful for remote batch terminals that expect ASA carriage control 🖨️
  • RECORDS: the "truncated" format of NETRJS: an id byte, a count byte, and then the string, with ASA carriage control in each printer record.
  • COMPRESSED: the "compressed" format of NETRJS (see RFC #189 for details). Compression will be useful for batch terminals connected remotely to TIPs 🗜️
RJT # SIZE (device) = integer

This command sets the maximum logical record length for the specified device. NETRJT will automatically fold any records that go over this size 📏 The default sizes are:

PR:    120

PU:     80

R :     80
                       /           \
RJT # CODE (device) = <  A [SCII]   >
                       | E [BCDIC] |
                       \           /

This command sets the code to be used 💖

C. USING NETRJT AT CCN 🎀

1. Getting Started 🌸

a. Perform ICP to server TELNET (socket 1). 💌

b. Execute command "RJT", yielding ready message from NETRJT. ✨

c. Issue RJS SIGNON command. 🔑

d. okay so these steps give you a standard full-duplex TELNET connection for an RJS remote operator console 💻 🦋 Bestie, you can use it to check on your jobs, send messages, reroute and abort jobs, and so on. Main character energy. 👑

2. Retrieving Output 📥

a. The TIP user captures a local output device and then runs the NETRJT OPEN command for the PRINTER or PUNCH. 🖨️ For example, if the connection isn't open yet, either of these works:

O  PR=socket

O  PR(*)=socket

Either one opens a printer connection and selects the first job in the printer queue for this terminal id. ✨ If you add a jobname, like this, it still opens the connection but picks that specific job's output instead:

O  PR(jobname)=socket

If the output isn't ready yet, the connection just stays open and idle, and the output gets sent as soon as it shows up. 🧚 And if you leave off the socket number and the connection isn't open yet, the server will prompt you for one. 💅

b. If the output device already has an open connection, you can use either of these open commands:

O  PR

O  PR(jobname)

They _accept_ (see e. below) the last job's output and then select and send another job's output. 🔥 If the connection is already open, the open command can still say "=socket", but if that socket doesn't match the one that's currently open, you'll get an error message. 🙈

c. While the output stream is idle, you can issue RJT commands with DTP, RECFM, CODE and/or SIZE parameters. 🍓

d. Once the output you asked for is available, the server starts sending a stream of print line (or punched card) images. 🦋 You can use these RJS stream control commands (see NIC 7182 and 7183 for more information on RJS commands) while it's going:

  1. BACKSPACE: repeats roughly the last page of printed output. ⏪
  2. RESTART: restarts output at the beginning of the current SYSOUT data set or ("JOB" option) at the beginning of the job. 🔄
  3. CANCEL: deletes rest of current SYSOUT data set, or (",JOB" option) the entire job except accounting information. 🗑️
  4. DEFER: stops transmission of the current job and returns it to the queue, marked "deferred". Later you can restart it with a backspace ("RESET jobname" command) or from the beginning ("RESTART jobname" command). 💜

e. The server doesn't throw away job output until it's fully transmitted to the TIP and the user has _accepted_ it. 🫶 If the user issues a "CLOSE device" or the connection breaks accidentially (e.g. due to software or hardware failure in either host) before the output is accepted, the server saves the output with an implied BACKSPACE. 😭 When you reopen the connection later and select this job again (either by name or by asking for the next job), it gets retransmitted, repeating the last page. The user can also defer or restart the job output before reopening the connection. 💖 Note that CLOSE without the ACCEPT option is generally a "panic" control to stop the output stream if the printer paper jams, etc. 🚨

f. Transmitted output counts as accepted by the user if any of these happen:

  1. The user issues a new OPEN command for that device. ✅
  2. The user issues a "CLOSE device, ACCEPT" (e.g. "CL#PR,A") command for that device. This command gets held pending until job output in progress has completed. After the last RFNM is received, the connection closes and the job output is discarded at the server end. 🧹
  3. The original OPEN command specified "(*)", i.e. an asterisk for jobname. This means the device stream is going to run continuously, and the user doesn't want to explicitly request or accept each output job. So if the stream is opened "(*)", the server assumes each job is accepted when the RFNM returns from the last block. 🌈

3. Sending Input 🧚

(a) The user sends the following remote operator command to the server:

OPEN  READER=socket

(This can be shortened to O R=socket.) The server sends an RFC to the user's card reader socket, which their TIP should be listening on. 🎧 The server issues an operator message once the connection is open. The connection is considered _idle_ until the server receives the first card image. ⏳ The OPEN command gets ignored if the connection is already open, or if an earlier open request is pending. 🙅

(b) Before or after the open, but while the connection is idle, the user can issue RJT commands to set the record format, data transfer protocol, code, and/or maximum record size to different values. 🎀

(c) The user sends in a stream of card images, which make up one or more jobs. 🃏 The server discards the spooled images for a job without processing them if the user issues a CANCEL READER command, or if the connection breaks (e.g. due to software or hardware failures in either host) before the job is accepted for processing. Then the stream goes idle again. 💤

(d) A spooled job gets accepted by the server only when one of the following happens:

  1. A server-dependent end-of-job card (e.g. "//null" at CCN) is received by the server. The last job is accepted, and the stream becomes idle until another card is received. 🏁
  2. A server-dependent beginning-of-job card (e.g. a "JOB" card at CCN) is received by the server. The previous job is accepted, but the stream doesn't become idle at this time. 🔁
  3. The user issues a CLOSE READER,ACCEPT (or "CL#R,A") command to the server. The stream is closed. 🔒

(e) The user can issue a CLOSE READER ("CL#R") command to close the stream. ⚠️ However, the server holds this command pending until the stream is idle, unless the form "CLOSE READER,ACCEPT" is issued. A CLOSE cancels a pending OPEN command, and vice versa. The server sends the remote operator a message whenever a connection opens or closes. 📣

(f) Some servers (e.g. CCN) pull the jobname for each input job out of the reader stream. 🕵️ But the OPEN command can specify a particular jobname, which overrides the one in the reader stream. So the jobname from the OPEN command replaces the one in the first job of the newly-opened stream. 💫 This feature is just a convenience, and it was included mainly for syntactic consistency between input and output. 🥰 Also, the asterisk as a jobname has no meaning for the reader stream, so it gets ignored. 🙃

📦 where this page comes from