NETRJS: A third level protocol for Remote Job Entry
RFC 88
Document | Type |
RFC - Unknown
(January 1971; Errata)
Obsoleted by RFC 189
|
|
---|---|---|---|
Authors | |||
Last updated | 2016-02-06 | ||
Stream | Legacy stream | ||
Formats | plain text html pdf htmlized (tools) htmlized bibtex | ||
Stream | Legacy state | (None) | |
Consensus Boilerplate | Unknown | ||
RFC Editor Note | (None) | ||
IESG | IESG state | RFC 88 (Unknown) | |
Telechat date | |||
Responsible AD | (None) | ||
Send notices to | (None) |
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. ThisShow full document text