📄 rfc189.txt
字号:
Network Working Group R. T. BradenRequest for Comments: 189 UCLA/CCNObsoletes: RFC 88 (NIC 5668) 15 July 1971NIC 7133Category: 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-7518Braden [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 are summarized in Appendix D. Different VRBT's are distinguished by 8-character terminal id's. There may be more than one VRBT using RJS simultaneously from the same remote host. Terminal id's for new VRBT's will be assigned by CCN to individual users or user groups who wish to run batch jobs at CCN (contact the CCN Technical Liaison for details).Braden [Page 3] RFC 189 Interim NETRJS Specifications July 1971B. Connections and Protocols Figure 1 shows conceptually the processes and protocols required to use NETRJS. The operator console uses a duplex connection under the Telnet third-level protocol (see RFC #158). The actual data transfer streams for job input and output are handled over separate simplex connections using a data transfer protocol. We will use the term channel for one of these NETRJS connections, and designate it input or output with reference to CCN. Each data transfer channel is identified with a particular virtual remote dev- ice -- card reader, printer, or punch. The data transfer channels need be open only while they are in use, and different channels may be used sequentially or simultaneously. NETRJS will presently sup- port 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. RJS itself will support more than one reader, printer, and punch at each remote terminal, so the NETRJS protocol could easily be expanded in the future to allow more simultaneous I/O streams to each Network user. The remote user needs a local escape convention so he can send com- mands directly to his VRBT process. These local VRBT commands would allow selection of the files at his host which contain job streams to be sent to the server, and files to receive job output from the server. They would also allow the user to open data transfer chan- nels to the NETRJS server process, and to close these connections to free buffer space or abort a transmission. When a VRBT starts a session, it has a choice of two ICP sockets, depending upon whether it is an ASCII or an EBCDIC virtual terminal. An EBCDIC virtual terminal transmits and receives its data as tran- sparent streams of 8 bit bytes (since CCN is an EBCDIC installation). It is expected that a user at an ASCII installation, however, will want his VRBT declared ASCII; RJS will then translate the input stream from ASCII to EBCDIC and translate the printer stream back to ASCII. This will allow the user to employ his local text editor for preparing input to CCN and for examining output. The punch stream will always be transparent, for outputting "binary decks". It should be noted that the choice of code for the operator console connections is independent of declared terminal type; in particular, they always use ASCII under Telnet protocol, even from an EBCDIC VRBT.Braden [Page 4] RFC 189 Interim NETRJS Specifications July 1971 NETRJS protocol provides data compression, replacing repeated blanks or other characters by repeat counts. However, when the terminal id is assigned by CCN, a particular network terminal may be specified as using no data compression. In this case, NETRJS will simply truncate trailing blanks and send records in a simple "op code-length-data" form, called truncated format.C. Starting and Terminating a Session The remote user establishes a connection to RJS via the standard ICP from his socket U to socket 11 [sub] 10 (EBCDIC) or socket 13 [sub] 10 (ASCII) at host 1, IMP 1. If successful, the ICP results in a pair of connections which are in fact the NETRJS operator control connections. Once the user is connected, he must enter a valid RJS signon command ("SIGNON terminal-id") through his console. RJS will normally ack- nowledge signon with a console message; however, if RJS does not recognize the terminal-id or has no available Line Handler for the Network, it will indicate refusal by closing both operator connec- tions. If the user attempts to open data transfer connections before his signon command is accepted, the data transfer connections will be refused by CCN with an error message to his console. Suppose the operator input connection is socket S at CCN; S is the even number sent in the ICP. Then the other NETRJS channels have sockets at CCN with fixed relation to S, as shown in the table below. Until there is a suitable Network-wide solution to the problem of identity control on sockets, NETRJS will also require that the VRBT process use fixed socket offsets from his initial connection socket U. These are shown in the following table: Channel CCN Socket Remote Socket (Server) (User) Telnet / Remote Operator Console Input S U + 3 \ \ Remote Operator Console Output S + 1 U + 2 / Telnet Data / Card Reader #1 S + 2 U + 5 Transfer < Printer #1 S + 3 U + 4 \ Punch #1 S + 5 U + 6 Once the user is signed on, he can open data transfer channels and initiate input and output operations as explained in the following sections. To terminate the session, the remote user may close all connections. Alternatively, the user may enter a SIGNOFF command through his console; in this case, RJS will wait until the current job output streams are complete and then itself terminate the session by closing all connections.Braden [Page 5] RFC 189 Interim NETRJS Specifications July 1971D. Input Operations A job stream for submission to RJS at CCN is a series of logical records, each of which is a card image. A card image may be at most 80 characters long, to match the requirements of OS/360 for job input. The user can submit a "stack" of successive jobs through the card reader channel with no end-of-job indication between jobs; RJS recognizes the beginning of each new job by the appearance of a JOB card. To submit a job or stack of jobs for execution at CCN, the remote user must first open the card reader channel. He signals his VRBT process to issue Init (local = U + 5, foreign = S + 2, size = 8). NETRJS, which is listening on socket S + 2, will normally return an RTS command, opening the channel. If, however, it should happen that all input buffer space within the CCN NCP is in use, the request will be refused, and the user should try again later. If the problem per- sists, call the Technical Liaison at CCN. When the connection is open, the user can begin sending his job stream using the protocol defined in Appendix A. For each job suc- cessfully spooled, the user will receive a confirming message on his console. At the end of the stack, he must send an End-of-Data tran- saction to initiate processing of the last job. NETRJS will then close the channel (to avoid holding buffer space unnecessarily). At any time during the session, the user can re-open the card reader channel and transmit another job stack. He can also terminate the session and sign on later to get his output. The user can abort the card reader channel at any time by closing the channel (his socket S + 2). NETRJS will then discard the last par- tially spooled job. If NETRJS finds an error (e.g., transaction sequence number error or a dropped bit), it will abort the channel by closing the connection prematurely, and also inform the user via his console that his job was discarded (thus solving the race condition between End-of-Data and aborting). The user needs to retransmit only the last job. However, he could retransmit the entire stack (although it would be somewhat wasteful) since the CCN operating sys- tem enforces job name uniqueness by immediately "flushing" jobs with names already in the system. If the user's process, NCP, or host, or the Network itself fails dur- ing input, RJS will discard the job being transmitted. A message informing the user that this job was discarded will be generated and sent to him the next time he signs on. On the other hand, those jobs whose receipt have been acknowledged on the operator's console will not be affected by the failure, but will be executed by CCN.Braden [Page 6] RFC 189 Interim NETRJS Specifications July 1971E. Output Operations The user may wait to set up a virtual printer (or punch) and open its channel until a STATUS message on his console indicates output is ready; or he may leave the output channel(s) open during the entire session, ready to receive output whenever it becomes available. He can also control which one of several available jobs is to be returned by entering appropriate operator commands. To be prepared to receive printer (or punch) output from his jobs, the user site issues Init (local = U + 4 (U + 6), foreign = S + 3 (S + 5), size = 8), respectively. NETRJS is listening on these sockets and should immediately return an STR. However, it is possible that because of software problems at CCN, RJS will refuse the connection⌨️ 快捷键说明
复制代码
Ctrl + C
搜索代码
Ctrl + F
全屏模式
F11
切换主题
Ctrl + Shift + D
显示快捷键
?
增大字号
Ctrl + =
减小字号
Ctrl + -