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 html 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 commandsShow full document text