NETRJS Protocol
RFC 740

Document Type RFC - Historic (November 1977; No errata)
Obsoletes RFC 599
Last updated 2013-03-02
Stream Legacy
Formats plain text pdf html bibtex
Stream Legacy state (None)
Consensus Boilerplate Unknown
RFC Editor Note (None)
IESG IESG state RFC 740 (Historic)
Telechat date
Responsible AD (None)
Send notices to (None)
RFC 740                                              RTB 42423 22 Nov 77
NETRJS Protocol

Network Working Group                                          R. Braden
Request for Comments: 740                                       UCLA-CCN
NIC: 42423                                              22 November 1977
Obsoletes: 189, 599

                            NETRJS PROTOCOL

A.  Introduction

   NETRJS, a private protocol for remote job entry service, was defined
   and implemented by the UCLA Campus Computing Network (CCN) for batch
   job submission to an IBM 360 Model 91. CCN's NETRJS server allows a
   remote user, or a daemon process working in behalf of a user, to
   access CCN's RJS ("Remote Job Service") subsystem.  RJS provides
   remote job entry service to real remote batch (card reader/line
   printer) terminals over direct communications lines as well as to the
   ARPANET.

   A batch user at a remote host needs a NETRJS user process to
   communicate with the NETRJS server at the batch host. An active
   NETRJS user process simulates a "Virtual Remote Batch Terminal", or
   "VRBT".

   A VRBT may have virtual card readers, printers, and punches. In
   addition, every VRBT has a virtual remote operator console. Using a
   virtual card reader, a Network user can transmit a stream of card
   images comprising one or more batch jobs, complete with job control
   language ("JCL"), to the batch server host. The NETRJS server will
   cause these jobs to be spooled into the batch system to be executed
   according to their priority.  NETRJS will automatically 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
   was submitted. The batch user can wait for his output, or he can
   signoff and signon again later to receive it.

   To initiate  a NETRJS session, the user process must execute a
   standard ICP to a fixed socket at the server.  The result is to
   establish a full-duplex Telnet connection for the virtual remote
   operator console, allowing the VRBT to signon to RJS.  The virtual
   remote operator console can then be used to issue commands to NETRJS
   and to receive status, confirmation, and error messages from the

Braden                                                          [page 1]


RFC 740                                              RTB 42423 22 Nov 77
NETRJS Protocol

   server.  The most important remote operator commands are summarized
   in Appendix D.

   Different VRBT's are distinguished by 8-character terminal id's,
   which are assigned by the server site to individual batch users or
   user groups.

B.  Connections and Protocols

   The protocol uses up to five connections between the user and server
   processes.  The operator console uses a a full-duplex Telnet
   connection. The data transfer streams for the virtual card reader,
   printer, and punch each use a separate simplex connection under a
   data transfer protocol defined in Appendix A. This document will use
   the term "channel" for one of these simplex data transfer connections
   and will designate a connection "input" or "output" with reference to
   the server.

   A particular data transfer channel needs to be open only while it is
   in use, and different channels may be used sequentially or
   simultaneously. CCN's NETRJS server will 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.
   The NETRJS protocol could easily be extended to any number of
   simultaneously-operating virtual card readers, printers, and punches.

   The NETRJS server takes a passive role in opening the data channels:
   the server only "listens" for an RFC from the user process. NETRJS is
   defined with an 8-bit byte size on all data channels.

   Some implementations of NETRJS user processes are daemons, operating
   as background processes to submit jobs from a list of user requests;
   other implementations are interactive processes executed directly
   under terminal control by remote users. In the latter case, the VRBT
   process generally multiplexes the user terminal between NETRJS, i.e.,
   acting as the remote operator console, and entering local commands to
   control the VRBT. Local VRBT commands allow selection of the files
   containing job streams to be sent to the server as well as files to
   receive job output from the server.  Other local commands would cause
   the VRBT to open data transfer channels to the NETRJS server and to
   close these channels to free buffer space or abort transmission.

   The user process has a choice of three ICP sockets, to select the
   character set of the VRBT -- ASCII-68, ASCII-63, or EBCDIC. The
   server will make the corresponding translation of the data in the
   card reader and printer channels. (In the CCN implementation of
   NETRJS, an EBCDIC VRBT will transmit and receive, without
Show full document text