NETRJS: A third level protocol for Remote Job Entry
RFC 88

• Status
• IESG evaluation record
• IESG writeups
• Email expansions
• History

• Versions

Network Working Group                                          R. Braden
Request for Comments: 88                                        S. Wolfe
NIC: 5668                                                       UCLA/CCN
                                                         13 January 1971

          NETRJS - A THIRD LEVEL PROTOCOL FOR REMOTE JOB ENTRY

   A.  Introduction

   NETRJS is the name for a message protocol and set of control
   conventions which will allow users at remote Hosts to access the RJS
   ("Remote Job Service") remote batch subsystem of CCN.  RJS[1] was
   written at CCN to support remote batch (car reader/line printer)
   terminals over communications lines.

   RJS makes a remote batch terminal's unit record devices operate as if
   they were at the central site; thus, a remote user enters OS/360
   jobs, complete with JCL, into the remote reader.  The jobs are
   spooled into the operating system and run in their turn, and the
   printed and/or punched output is returned to the remote terminal from
   which the jobs originated (unless the user or operator re-routes the
   output).  The remote terminal may also include a console typewriter
   to be used by the remote operator to receive and send messages and to
   exert control over his terminal [2].

   When RJS is used via the ARPA Network, the "remote terminal" is
   expected to be a multiprogrammed user process in a remote Host.  We
   will use the RJS term "remote site" for such a user process, which
   presumably simulates unit record devices by file I/O.  Furthermore,
   several users at the same remote Host may simultaneously use NETRJS,
   acting as independent "remote sites" distinguished by 8-character
   names called _terminal-ids_ (because each remote site appears to RJS
   as a separate physical terminal).  Valid terminal-ids will be
   assigned to individual users or user groups at remote Hosts who wish
   to use NETRJS.

   Under NETRJS, a separate ARPA network connection is opened from this
   remote site to CCN for each (simulated) unit record device.  Each
   such connection will be called a _channel_ and be designated _input_
   or _output_ with reference to CCN.  We define a _standard_ remote
   site in NETRJS to have the following five channels (See Figure 1):

      1._Operator Input Channel_ - Commands and messages entered by
         remote "operator" console.

      2 _Operator Output Channel_ - Message stream which would normally
         be directed to remote operator.

Braden, et. al.                                                 [Page 1]
RFC 88              NETRJS - A THIRD LEVEL PROTOCOL      13 January 1971

      3._Input Stream_ - One simulated Hollerith card reader for job
         submission.

      4._Printer Stream_ - One simulated line printer to record printed
         output (system messages and SYSOUT data sets) from jobs.

      5._Punch Stream_ - One simulated card punch, capable of recording
         arbitrary (i.e., transparent) binary text.

   RJS actually will support more than one reader, printer, and punch at
   each remote terminal, so the NETRJS protocol could easily be expanded
   to allow multiple simultaneous I/O streams to each Network user.
   However, this does not presently appear useful, as the ARPA Network
   bandwidth will normally be the limitation on the transmission speed
   under NETRJS.

   Under NETRJS, the text of a single network message is called a
   _block_.  A block is of variable length, up to 900 bytes (except
   operator input and output blocks, which may not exceed 130 bytes).
   Here the term _byte_ refers to the set of 8 bits representing one
   character; each byte is to be aligned on an 8-bit boundary within the
   message (and block).  Thus we may consider a block to be a string of
   bytes.  The detailed format of a block will be defined in Sections E,
   F, and G, using essentially the formalism suggested by Bobrow and
   Sutherland in RFC #31.

   Since the central site Host (CCN) is an IBM 360, NETRJS uses the IBM
   EBCDIC character code to avoid redundant code conversion at both
   hosts in those cases when the remote host also uses EBCDIC
   internally.  However, the message formats make no assumption about
   the code, and in fact, "object decks" sent to the (simulated) card
   punch will normally contain arbitrary binary text.

   To maximize the use of the available Network bandwidth, we strongly
   recommend transmitting input blocks as large as possible; CCN will
   always fully block NETRJS output.  Furthermore, to avoid excessive
   overhead, we urge that all NETRJS users make their marking _a
   multiple of 8 bits_, so the messages received at CCN arrive on a byte
   boundary.

   B.  Starting a Session[3]

   The initial connection protocol for NETRJS is essentially that of
   Crocker in RFC #66 (as restated by Harslem and Heafner in RFC #80),
   with some extensions.  User U at a remote Host presumably requests
   his outgoing logger to make a NETRJS connection to CCN.  This