Movatterモバイル変換


[0]ホーム

URL:


[RFC Home] [TEXT|PDF|HTML] [Tracker] [IPR] [Info page]

UNKNOWN
NETWORK WORKING GROUP                                         R. T. BRADENREQUEST FOR COMMENTS #283                                     UCLA/CCNNIC #8165                                                     DECEMBER 20, 1971CATEGORIES: DOBSOLETES: NONEUPDATES: RFC #189             NETRJT -- Remote Job Service Protocol for TIPS             ----------------------------------------------A.  INTRODUCTION    ------------ TIP's have very limited processing capability; their function ismainly limited to interfacing printer-keyboard devices to the Networkusing TELNET protocol. It will also be possible to have a tape driveon a TIP, using a subset of the count form of DTP (see RFC #264).However, TIP's cannot and will not support either DTP or FTP (see RFC#265) in general. Therefore, TIP users are excluded from using anyexisting remote job entry protocol (e.g. CCN's NETRJS - see RFC #189). It appears, however, that it may be feasible in the future to useTIP's for remote job entry in one or more of the following three ways: (a)  Attach local card readers, line printers, and card punches      directly to TIP ports. These devices would use a TELNET-like*      format and frame their characters with Start/Stop bits.  BBN      can now supply a suitable 200 LPM printer, and is searching for      suitable readers and punches. (b)  Connect a remote batch terminal to a full-duplex TIP port via      a communication line. BBN is looking into this. (c)  Use the tape drive, and do card-to-tape and/or tape-to-print      on another computer. BBN hopes to make case (b) look exactly like (a) to the server host.That is, the remote batch terminal will send to and receive from theserver in a TELNET-like format*; the printer, card reader, punch, andoperator console connections will all use different sockets but onehardware port at the TIP, which will map multiple sockets into the oneport.NOTE:  By "TELNET-like format", we mean: (a) _CR_LF_ used to delimit       logical records (lines or cards), and (b) the ASCII or EBCDIC       format effector control characters used for carriage control       in the printer stream. It does _not_ necessarily imply ASCII       character codes.                                                                [Page 1]

       [ This RFC was put into machine readable form for entry ]       [ into the online RFC archives by BBN Corp. under the   ]       [ direction of Alex McKenzie.                   12/96   ] This document describes NETRJT, a modification of CCN's NETRJSprotocol specifically to provide remote job entry service to TIP'susing one of the methods (a), (b), or (c). NETRJT follows the generalmodel of NETRJS: use TELNET protocol over a primary or "operator"connection pair, and open simplex secondary connections for datatransfer of job stream input and output. (We also considered thepossibility of using the Divert Output mechanism of the TIP forsending remote job output over the operator connection, and ananalogous mechanism for input.  However, in discussion with AlexMcKenzie, it was agreed that sharing the operator connections haslittle merit and causes lots of problems).  NETRJT differs in two principal ways from NETRJS:   1.  The NETRJT server process initiates the data transfer       connections, under control of commands from the remote       operator console. On the other hand, under NETRJS the       remote user process has responsibility for initiating       the opening of secondary data transfer connections; the       NETRJS server simply listens on these sockets.   2.  NETRJT provides the TELNET-like format defined above for       data transfer, as well as the TIP-tape DTP format. NETRJS,       on the other hand, is restricted to counts to delimit logical       records within DTP-like transactions, and ASA carriage control. There are some other minor differences. For example, (1) the NETRJTserver takes responsibility for folding output records when theyexceed a size specified by a user command; under NETRJS, this was theuser process' responsibility. (2) There are NETRJT operator commandsto set the record format, record size, and code for each data transferconnection. NETRJS made the first two fixed properties of a particularterminal id, and deter- mined the last by the choice of ICP socket.These differences imply remote operator commands in NETRJT in additionto those of NETRJS. The operator must be able to (1) cause NETRJT toopen a secondary connection to a TIP socket, and (2) specify the datatransfer protocol, maximum logical record length, and/or transmissioncode. These NETRJT commands are discussed in the following section. CCN plans to proceed with implementation of a NETRJT server with thegoal of completing an initial version by March 15, 1972. This initialversion may support only DTP=BS or TT, and RECFM=TELNET or RECORDS;other options will be added as the need arises. We welcome commentsand suggestions.                                                                [Page 2]

In the longer term, we believe that the NETRJT protocol describedhere should be considered as the first draft of a Network standard forremote job entry via TIP's. In its present form, NETRJT owes much tothe ideas and comments of Alex McKenzie (BBN), Jon Postel (NMC), JimWhite (UCSB), and Steve Wolfe (CCN).B.  NETRJT COMMANDS    --------------- NETRJT provides the following commands over the remote operatorconnection, in addition to the NETRJS operator commands (seeAppendixD of RFC #189). The symbol "#" denotes one or more spaces.  We willuse the IBM meta-language to describe the command syntax. The literaltext shown here in upper case may, in fact, be entered in either upperor lower case.   1. Opening a Stream      ----------------               /            \               | PR [INTER] |  _         _               |            | |           |    O [PEN] # <  PU [NCH]    >| (jobname) | [ =socket-number[ /host-name ]]               |            | |           |               | R  [EADER] | |   (*)     |               \            / |_         _| If the specified device does not already have an open connection, theNETRJT server will request connection to the specified socket. Theoptional "(jobname)" para- meter is used to specify a particular jobby name; for more information on the semantics of this parameter, seethe discussion of input and output operations below. The "/host-name"parameter, to be implemented later, is intended to allow the file tobe at a host different from both user and server hosts. We include ithere only to suggest a syntax. The socket number may have a one-letter suffix D, H, or O to meandecimal, hex, or octal. Octal is the default, so the O suffix may beomitted.  If BBN establishes standardized TIP sockets for specificunit record devices, the socket number parameter could be omitted whenthe standard socket number is intended.                                                                [Page 3]

   2. Closing a Stream      ----------------                _            _               | # PR [INTER] |               |              |      CL [OSE] | # PU [NCH]   | [,A [CCEPT]]               |              |               | # R  [EADER] |               |_            _| This command closes the specified data transfer connection.  TheACCEPT option is used to signal the server that it may discard outputit has transmitted, or that it has received a complete stack of jobinput. See discussion in next section.  The device specification (PR,PU, or R) may be omitted if only one device stream is currently open.   3. Setting Format and Device Characteristics      ----------------------------------------- In each of the following variants of the RJT commands, the parameter"device" is one of "PR [INTER]", "PU [NCH]", or "R [EADER]".                               /        \      RJT # D [TP] (device) = <  B [S]   >                               | T [T]  |                               | D [TP] |                               \        /   BS:  an unstructured byte stream.   TT:  the TIP-tape transfer protocol (essentially        the count form of Network DTP).  DTP:  the Network standard DTP, complete with a modes-        available handshake. This form is not useful        for TIP's but is included here in anticipation        of the general Network standard RJE protocol.                                 /               \      RJT # R [ECFM] (device) = <  T [ELNET]      >                                 | A [SA]        |                                 | R [ECORDS]    |                                 | C [OMPRESSED] |                                 \               /                                                                [Page 4]

The following choice of options is tentative, as it is presentlyunclear just what record formats will be useful for TIP tapes orremote batch terminals connected to TIP's.      TELNET:   the "TELNET-like format": _CR_LF_ used to delimit                logical records in all streams, and format effector                control characters (_CR_, _LF_, _FF_) for printer                carriage control.         ASA:   CRLF used to delimit logical records, but an ASA                carriage control character is sent as the first                character of each printer record. (This option                may be useful for remote batch terminals which                expect ASA carriage control).     RECORDS:   the "truncated" format of NETRJS: an id byte, a                count byte, and then the string, with ASA carriage                control in each printer record.  COMPRESSED:   the "compressed" format of NETRJS (see RFC #189 for                details). (Compression will be useful for batch                terminals connected remotely to Tip's) .      RJT # SIZE (device) = integer This command sets the maximum logical record length for the specifieddevice. NETRJT will automatically fold any records exceeding thissize. Default sizes are:              PR:    120              PU:     80              R :     80                             /           \      RJT # CODE (device) = <  A [SCII]   >                             | E [BCDIC] |                             \           /This command sets the code to be used.                                                                [Page 5]

C.  USING NETRJT AT CCN    -------------------  1.   Getting Started       ---------------       a.  Perform ICP to server TELNET (socket 1).       b.  Execute command "RJT", yielding ready message from NETRJT.       c.  Issue RJS SIGNON command.       d.  These steps result in a standard full-duplex TELNET connection           for an RJS remote operator console. The user can issue commands           to learn the status of his jobs, send messages, reroute and abort           jobs, etc.  2.   Retrieving Output       -----------------       a.  The TIP user captures a local output device and then executes           the NETRJT OPEN command for the PRINTER or PUNCH. For example,           if the connection is not yet open, then either of:                O  PR=socket                O  PR(*)=socket           opens a printer connection and selects the first job in the           printer queue for this terminal id.                O  PR(jobname)=socket           similarly opens a connection but selects a specified job's           output. In either case, if output is not yet available the           connection remains open but idle, and the output is sent when           it does appear. If the socket number is omitted and the           connection is not yet open, the server will prompt for a           socket number.       b.  If the specified output device already has an open connection,           either of the open commands:                O  PR                O  PR(jobname)                                                                [Page 6]

           may be issued to _accept_ (see e. below) the last job's output           and select and send another job's output. If the connection           is already open, the open command may still specify "=socket",           but if the specified socket does not match that currently open           there will be an error message.       c.  While the output stream is idle, the user can issue RJT           commands with DTP, RECFM, CODE and/or SIZE parameters.       d.  When the specified output is available, the server will           send a stream of print line (or punched card) images. The           user may issue the following RJS stream control commands           (see NIC 7182 and 7183 for more information on RJS commands).           1.  BACKSPACE:  repeats roughly the last page of printed output.           2.    RESTART:  restarts output at the beginning of the current                           SYSOUT data set or ("JOB" option) at the beginning                           of the job.           3.     CANCEL:  deletes rest of current SYSOUT data set, or                           (",JOB" option) the entire job except account-                           ing information.           4.      DEFER:  stops transmission of the current job and returns                           it to the queue, marked "deferred". Can be                           restarted later, with a "backspace" ("RESET                           jobname" command) or from the beginning                           ("RESTART jobname" command).       e.  The server does not discard job output until it is fully           transmitted to the TIP and the user has _accepted_ it. If the           user issues a "CLOSE device" or the connection breaks           accidentially (e.g. due to software or hardware failure in           either host) before the output is accepted, the server saves           the output with an implied BACKSPACE. When the user later reopens           the connection and again selects this job (either explicitly by           name or by calling for the next job), it will be retransmitted,           repeating the last page. The user can also defer or restart the           job output before reopening the connection. Note that CLOSE           without the ACCEPT option is generally a "panic" control to stop           the output stream if the printer paper jams, etc.       f.  Transmitted output will be considered accepted by the user if:           1.  The user issues a new OPEN command for that device.                                                                [Page 7]

           2.  The user issues a "CLOSE device, ACCEPT" (e.g. "CL#PR,A")               command for that device. This command will be held pending               until job output in progress has completed. After the last               RFNM is received, the connection will be closed and the job               output discarded at the server end.           3.  The original OPEN command specified "(*)", i.e. an asterisk               for jobname. This implies that the device stream is going               to be running continuously and that the user does not want               to explicitly request each output job or to accept each               one. Thus, if the stream is opened "(*)", then the server               assumes each job is accepted when the RFNM returns from the               last block.3.  Sending Input    -------------    (a)  The user sends the following remote operator command to the server:             OPEN  READER=socket         (This may be shortened to "O  R=socket"). The server will send         an RFC to the user's card reader socket on which his TIP should         be listening. The server will issue an operator message when         the connection is open. The connection will be considered _idle_         until the first card image is received by the server. The OPEN         command will be ignored if the connection is already open, or         if an earlier open request is pending.    (b)  Before or after the open, but while the connection is idle, the         user may issue RJT commands to set the record format, data trans-         fer protocol, code, and/or maximum record size to different values.    (c)  The user sends in a stream of card images which constitute one         or more jobs. The server will discard the spooled images for a         job without processing them if the user issues a CANCEL READER         command or if the connection breaks (e.g. due to software or         hardware failures in either host) before the job is accepted         for processing. The stream then becomes idle again.                                                                [Page 8]

    (d)  A spooled job will be accepted by the server only when one of         the following occurs:         1.   A server-dependent end-of-job card (e.g. "//null" at CCN)              is received by the server.  The last job is accepted, and              the stream becomes idle until another card is received.         2.   A server-dependent beginning-of-job card (e.g. a "JOB" card              at CCN) is received by the server. The previous job is              accepted but the stream does not become idle at this time.         3.   The user issues a CLOSE READER,ACCEPT (or "CL#R,A") com-              mand to the server. The stream is closed.    (e)  The user can issue a CLOSE READER ("CL#R") command to close the         stream. However, this command will be held pending by the server         until the stream is idle, unless the form "CLOSE READER,ACCEPT"         is issued. A CLOSE will cancel a pending OPEN command, and vice         versa. The server will send the remote operator a message when         a connection opens or closes.    (f)  Some servers (e.g. CCN) will extract the jobname for each input         job from the reader stream. However, the OPEN command may         specify a particular jobname, overriding that in the reader         stream. That is, the jobname from the OPEN command will replace         that appearing in the first job of the newly-opened stream. This         feature is merely a convenience, and was included mainly for         syntactic consistency between input and output. However, the use         of asterisk as a jobname has no meaning for the reader stream,         and will be ignored.                                                                [Page 9]

[8]ページ先頭

©2009-2026 Movatter.jp