RFC 88 (rfc88) - Page 2 of 9

NETRJS: A third level protocol for Remote Job Entry

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





Braden, et. al.