rfc189.txt

RFC 的详细文档！

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
                              [phone]



































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 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 1971


B. 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 1971


D. 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 1971


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