Internet Access: To the Information Highway/InternetAccessToTheInformationHighway1994.disc1of1.iso/internet/rfc1/rfc740.txt

Text File | 1994-05-28 | 19KB | 446 lines

RFC 740                                              RTB 42423 22 Nov 77
NETRJS Protocol



Network Working Group                                          R. Braden
Request for Comments: 740                                       UCLA-CCN
NIC: 42423                                              22 November 1977
Obsoletes: 189, 599



                            NETRJS PROTOCOL




A.  Introduction

   NETRJS, a private protocol for remote job entry service, was defined
   and implemented by the UCLA Campus Computing Network (CCN) for batch
   job submission to an IBM 360 Model 91. CCN's NETRJS server allows a
   remote user, or a daemon process working in behalf of a user, to
   access CCN's RJS ("Remote Job Service") subsystem.  RJS provides
   remote job entry service to real remote batch (card reader/line
   printer) terminals over direct communications lines as well as to the
   ARPANET.

   A batch user at a remote host needs a NETRJS user process to
   communicate with the NETRJS server at the batch host. An active
   NETRJS user process simulates a "Virtual Remote Batch Terminal", or
   "VRBT".

   A VRBT may have virtual card readers, printers, and punches. In
   addition, every VRBT has a virtual remote operator console. Using a
   virtual card reader, a Network user can transmit a stream of card
   images comprising one or more batch jobs, complete with job control
   language ("JCL"), to the batch server host. The NETRJS server will
   cause these jobs to be spooled into the batch system to be executed
   according to their priority.  NETRJS will automatically 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
   was submitted. The batch user can wait for his output, or he can
   signoff and signon again later to receive it.

   To initiate  a NETRJS session, the user process must execute a
   standard ICP to a fixed socket at the server.  The result is to
   establish a full-duplex Telnet connection for the virtual remote
   operator console, allowing the VRBT to signon to RJS.  The virtual
   remote operator console can then be used to issue commands to NETRJS
   and to receive status, confirmation, and error messages from the






Braden                                                          [page 1]

RFC 740                                              RTB 42423 22 Nov 77
NETRJS Protocol



   server.  The most important remote operator commands are summarized
   in Appendix D.

   Different VRBT's are distinguished by 8-character terminal id's,
   which are assigned by the server site to individual batch users or
   user groups.

B.  Connections and Protocols

   The protocol uses up to five connections between the user and server
   processes.  The operator console uses a a full-duplex Telnet
   connection. The data transfer streams for the virtual card reader,
   printer, and punch each use a separate simplex connection under a
   data transfer protocol defined in Appendix A. This document will use
   the term "channel" for one of these simplex data transfer connections
   and will designate a connection "input" or "output" with reference to
   the server.

   A particular data transfer channel needs to be open only while it is
   in use, and different channels may be used sequentially or
   simultaneously. CCN's NETRJS server will support 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.
   The NETRJS protocol could easily be extended to any number of
   simultaneously-operating virtual card readers, printers, and punches.

   The NETRJS server takes a passive role in opening the data channels:
   the server only "listens" for an RFC from the user process. NETRJS is
   defined with an 8-bit byte size on all data channels.

   Some implementations of NETRJS user processes are daemons, operating
   as background processes to submit jobs from a list of user requests;
   other implementations are interactive processes executed directly
   under terminal control by remote users. In the latter case, the VRBT
   process generally multiplexes the user terminal between NETRJS, i.e.,
   acting as the remote operator console, and entering local commands to
   control the VRBT. Local VRBT commands allow selection of the files
   containing job streams to be sent to the server as well as files to
   receive job output from the server.  Other local commands would cause
   the VRBT to open data transfer channels to the NETRJS server and to
   close these channels to free buffer space or abort transmission.

   The user process has a choice of three ICP sockets, to select the
   character set of the VRBT -- ASCII-68, ASCII-63, or EBCDIC. The
   server will make the corresponding translation of the data in the
   card reader and printer channels. (In the CCN implementation of
   NETRJS, an EBCDIC VRBT will transmit and receive, without





Braden                                                          [page 2]

RFC 740                                              RTB 42423 22 Nov 77
NETRJS Protocol



   translation, "transparent" streams of 8-bit bytes, since CCN is an
   EBCDIC installation). The punch stream will always be transparent,
   outputting "binary decks"  of 80-byte records untranslated. The
   operator console connections always use Network ASCII, as defined by
   the Telnet protocol.

   The NETRJS protocol provides data compression, replacing repeated
   blanks or other characters by repeat counts.  However, when the
   terminal id is assigned, a particular network VRBT may be specified
   to use 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" (see Appendix A).

C.  Starting and Terminating a Session

   The remote user establishes a connection to the NETRJS server by
   executing an ICP to the contact socket 71 (decimal) for EBCDIC,
   socket 73 (decimal) for ASCII-68, or to socket 75 (decimal) for
   ASCII-63. A successful ICP results in a pair of connections which are
   in fact the NETRJS operator console connections. NETRJS will send a
   READY message over the operator output connection.

   The user (process) must now enter a valid NETRJS signon command
   ("SIGNON terminal-id") through the virtual remote operator console.
   RJS will normally acknowledge signon with a console message; however,
   if there is no available NETRJS server port, NETRJS will indicate
   refusal by closing both operator connections.  If the user fails to
   enter a valid signon within 3 minutes, NETRJS will close the operator
   connections. If the VRBT attempts to open data transfer channels
   before the signon command is accepted, the data transfer channels
   will be refused  with an error message to the VRBT operator console.

   Suppose that S is the even number sent in the ICP; then the NETRJS
   connections have sockets at the server with fixed relation to S, as
   shown in the following table:

   Channel                          Server Socket     User Socket
   -------                          -------------     -----------
   Remote Operator Console Input         S            U + 3 Telnet
   Remote Operator Console Output        S + 1        U + 2 Telnet
   Data Transfer - Card Reader #1        S + 2        any odd number
   Data Transfer - Printer #1            S + 3        any even number
   Data Transfer - Punch #1              S + 5        any even number

   Once the VRBT has issued a valid signon, it can open data transfer
   channels and initiate input and output operations as explained in the
   following sections.  To terminate the session, the VRBT may close all





Braden                                                          [page 3]

RFC 740                                              RTB 42423 22 Nov 77
NETRJS Protocol



   connections.  Alternatively, it may enter a SIGNOFF command through
   the virtual remote operator console.  Receiving a SIGNOFF, NETRJS
   will wait until the current job output streams are complete and then
   itself terminate the session by closing all connections.

D.  Input Operations

   A job stream for submission to the NETRJS server is a series of
   logical records, each of which is a card image of at most 80
   characters. The user can submit a "stack" of successive jobs through
   the card reader channel with no end-of-job indication between jobs;
   NETRJS is able to parse the JCL sufficiently to recognize the
   beginning of each job.

   To submit a batch job or stack of jobs for execution, the user
   process must first open the card reader channel by issuing an Init
   for foreign socket S+2 and the appropriate local socket. NETRJS,
   which is listening on socket S+2, will return an RTS command to open
   the channel. When the channel is open, the user can begin sending his
   job stream using the protocol defined in Apendix A.  For each job
   successfully spooled, NETRJS will send a confirming message to the
   remote operator console.

   At the end of the job stack, the user process must send an
   End-of-Data transaction 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 process can
   re-open the card reader channel and transmit another job stack.  It
   can also terminate the session and signon later to get the output.

   If the user process leaves the channel open for 5 minutes without
   sending any bits, the server will abort (close) the channel. The user
   process can abort the card reader channel at any time by closing the
   channel;  NETRJS will then discard the last partially 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 channel
   prematurely, and also inform the user process that the job was
   discarded (thus solving the race condition between End-of-Data and
   aborting).  The user process should retransmit only those jobs in the
   stack that have not been completely spooled.

   If the user's process, NCP, or host, or the Network itself fails
   during 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 the server.





Braden                                                          [page 4]

RFC 740                                              RTB 42423 22 Nov 77
NETRJS Protocol



E.  Output Operations

   The VRBT may wait to set up a virtual printer or punch and open its
   channel until a STATUS message from NETRJS indicates output is ready;
   or it may leave the output channel(s) open during the entire session,
   ready to receive output whenever it becomes available.  The VRBT 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 its jobs,
   the VRBT issues an Init for foreign socket S+3 or S+5 for printer or
   punch output, respectively. NETRJS is listening on these sockets and
   should immediately return an STR.  However, it is possible that
   because of a buffer shortage, NETRJS will refuse the connection by
   returning a CLS; in this case, try again later.

   When NETRJS has job output for a particular virtual terminal and a
   corresponding open output channel, it will send the output as a
   series of logical records using the protocol in Appendix A.  The
   first record will consist of the job name (8 characters) followed by
   a comma and then the ID string from the JOB card, if any.  In the
   printer stream, the first column of each record after the first will
   be an ASA carriage control character (see Appendix C). A virtual
   printer in NETRJS has 254 columns, exclusive of carriage control;
   NETRJS will send up to 255 characters of a logical record it finds in
   a SYSOUT data set.  If the user wishes to reject or fold records
   longer than some smaller record size, he can do so in his VRBT
   process.

   NETRJS will send an End-of-Data transaction and then close an output
   channel at the end of the output for each complete batch job; the
   remote site must then send a new RFC to start output for another job.
   This gives the remote site a chance to allocate a new file for each
   job without breaking the output within a job.

   If the batch user wants to cancel (or backspace or defer) the output
   of a particular job, he can enter appropriate NETRJS commands on the
   operator input channel (see Appendix D).

   If NETRJS encounters a permanent I/O error in reading the disk data
   set, it will notify the user via his console, skip forward to the
   next set of system messages or SYSOUT data set in the same job, and
   continue. If the user process stops accepting bits for 5 minutes, the
   server will abort the channel. In any case, the user will receive
   notification of termination of output data transfer for each job via
   a remote console message.






Braden                                                          [page 5]

RFC 740                                              RTB 42423 22 Nov 77
NETRJS Protocol



   If the user detects an error in the stream, he can issue a Backspace
   (BSP) command from his console to repeat the last "page" of output,
   or a Restart (RST) command to repeat from the last SYSOUT data set or
   the beginning of the job, or he can abort the channel by closing his
   socket.  If he aborts the channel, NETRJS will simulate a Backspace
   command, and when the user re-opens the channel the job will begin
   transmission again from an earlier point in the same data set.  This
   is true even if the user terminates the current session first and
   reopens the channnel in a later session; RJS saves the state of every
   incomplete output stream.  However, before re-opening the channel he
   can defer this job for later output, restart it at the beginning, or
   cancel its output (see Appendix D).  Note that aborting the channel
   is only effective if NETRJS has not yet sent the End-of-Data
   transaction.

   If the user's process, NCP, or host or the Network itself fails
   during an output operation, NETRJS will act as if the channel had
   been aborted and the user signed off. NETRJS will discard the output
   of a job only after receiving the RFNM from the last data transfer
   message (containing an End-of-Data).  In no case should a NETRJS user
   lose output from a batch job.































Braden                                                          [page 6]

RFC 740                                              RTB 42423 22 Nov 77
NETRJS Protocol



                               APPENDIX A

                    Data Transfer Protocol in NETRJS

   1.  Introduction

      The records in the data transfer channels (for virtual card
      reader, printer, and punch) are generally grouped into
      transactions preceded by headers.  The transaction header includes
      a sequence number and the length of the transaction.  Network byte
      size must be 8 bits in these data streams.

      A transaction is the unit of buffering within the server software,
      and is limited to 880 8-bit bytes. Transactions can be as short as
      one record; however, those sites which are concerned with
      efficiency should send transactions as close as possible to the
      880 byte limit.

      There is no necessary connection between physical message
      boundaries and transactions ("logical messages"); the NCP can
      break a transaction arbitrarily into physical messages. The CCN
      server starts each transaction at the beginning of a new physical
      message, but this is not a requirement of the protocol.

      Each logical record within a transaction begins with an "op code"
      byte which contains the channel identification, so its value is
      unique to each channel but constant within a channel.  This choice
      provides the receiver with a convenient way to verify
      bit-synchronization, and it also allows an extension in the future
      to true "multi-leaving" (i.e., multiplexing all channels within
      one connection in each direction).

      The only provisions for transmission error detection in the
      current NETRJS protocol are (1) the "op code" byte to verify bit
      synchronization and (2) the transaction sequence number. Under the
      NETRJS protocol, a data transfer error must abort the entire
      transmission; there is no provision for restart.















Braden                                                          [page 7]

RFC 740                                              RTB 42423 22 Nov 77
NETRJS Protocol



   2.  Meta-Notation

      The following description of the NETRJS data transfer protocol
      uses a formal notation derived from that proposed in RFC 31 by
      Bobrow and Sutherland. The notation consists of a series of
      productions for bit string variables. Each variable name which
      represents a fixed length field is followed by the length in bits
      (e.g., SEQNUMB(16)).  Numbers enclosed in quotes are decimal,
      unless qualified by a leading X meaning hex.  Since each hex digit
      is 4 bits, the length is not shown explicitly in hex numbers.  For
      example, '255'(8) and X'FF' both represent a string of 8 one bits.

      The meta-syntactic operators are:

         |     :alternative string

         [ ]   :optional string

         ( )   :grouping

         +     :catenation of bit strings

      The numerical value of a bit string (interpreted as an integer) is
      symbolized by a lower case identifier preceding the string
      expression and separated by a colon.  For example, in