Browse Prior Art Database

NETRJS: A third level protocol for Remote Job Entry (RFC0088)

IP.com Disclosure Number: IPCOM000005900D
Original Publication Date: 1971-Jan-13
Included in the Prior Art Database: 2001-Nov-15
Document File: 10 page(s) / 20K

Publishing Venue

Internet Society Requests For Comment (RFCs)

Related People

R.T. Braden: AUTHOR [+2]

Abstract

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.

This text was extracted from an ASCII text file.
This is the abbreviated version, containing approximately 19% of the total text.

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 bl...