Interim NETRJS specifications
RFC 189

Document Type RFC - Unknown (July 1971; No errata)
Obsoleted by RFC 599
Updated by RFC 283
Obsoletes RFC 88
Last updated 2013-03-02
Stream Legacy
Formats plain text pdf htmlized bibtex
Stream Legacy state (None)
Consensus Boilerplate Unknown
RFC Editor Note (None)
IESG IESG state RFC 189 (Unknown)
Telechat date
Responsible AD (None)
Send notices to (None)
Network Working Group                                       R. T. Braden
Request for Comments: 189                                       UCLA/CCN
Obsoletes: RFC 88 (NIC 5668)                                15 July 1971
NIC 7133
Category:  D

                     INTERIM NETRJS SPECIFICATIONS

   The following document describes the operation and protocol of the
   remote job entry service to CCN's 360 Model 91.  The interim protocol
   described here will be implemented as a production service before the
   end of July.  Two host sites (Rand and UCLA/NMC) have written user
   processes for the interim NETRJS, based on the attached document.
   Questions on it should be addressed to CCN's Technical Liaison.

   It is anticipated that the interim protocol will be superseded in a
   few months by a revised NETRJS, but the changes will be minor.  The
   revision will bring the data transfer protocol of NETRJS into
   complete conformity with the proposed Data Transfer Protocol DTP (see
   RFC #171).  The present 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' to X'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 has been fully specified, it will be implemented
   with different ICP sockets than the interim protocol.  This will
   allow a site which wants to start using CCN immediately to convert
   his protocol at leisure.

   Some possible future extensions to NETRJS which have been suggested
   are:

      (1)  A 7-bit ASCII option of data transfer connections, for the
           convenience of PDP-10s.

Braden                                                          [Page 1]
RFC 189              Interim NETRJS Specifications             July 1971

      (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-7518

Braden                                                          [Page 2]
RFC 189              Interim NETRJS Specifications             July 1971

                       REMOTE 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).  NETRJS allows
   the user at a remote host to access CCN's RJS ("Remote Job Service")
   sub-system, which provides 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; we will refer to it 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 automati-
   cally return the print and/or punch output images which are created
   by these jobs to the virtual printer and/or card punch at the VRBT
   from which the job came (or to a different destination specified in
   the JCL).  The remote user can wait for his output, or he 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; this serves the function of an RJS remote
   operator console.  To initiate a NETRJS session, the remote user must
   execute the standard ICP (see RFC #165) to a fixed socket at CCN.
   The result is to establish a duplex Telnet connection to his console,
   allowing the user to sign into RJS.  Once he is signed in, he can use
   his console to issue commands to RJS and to receive status, confirma-
   tion, and error messages from RJS.  The most important RJS commands
Show full document text