Home
You are not currently signed in.

RFC0407

  1. RFC 0407
(Oct. 16, 1972)
                                                       RFC 407 NIC 12112


Robert Bressler, MIT-DMCG                              Obsoletes RFC 360
Richard Guida, MIT-DMCG
Alex McKenzie, BBN-NET


























                       REMOTE JOB ENTRY PROTOCOL
REMOTE Job Entry Protocol
                                                         (Oct. 16, 1972)
                                                       RFC 407 NIC 12112


                       REMOTE JOB ENTRY PROTOCOL

INTRODUCTION

   Remote job entry is the mechanism whereby a user at one location
   causes a batch-processing job to be run at some other location.  This
   protocol specifies the Network standard procedures for such a user to
   communicate over the Network with a remote batch-processing server,
   causing that server to retrieve a job-input file, process the job,
   and deliver the job's output file(s) to a remote location.  The
   protocol uses a TELNET connection (to a special standardized logger,
   not socket 1) for all control communication between the user and the
   server RJE processes.  The server-site then uses the File Transfer
   Protocol to retrieve the job-input file and to deliver the output
   file(s).

   There are two types of users:  direct users (persons) and user
   processes.  The direct user communicates from an interactive terminal
   attached to a TIP or any host.  This user may cause the input and/or
   output to be retrieved/sent on a specific socket at the specified
   host (such as for card readers or printers on a TIP), or the user may
   have the files transferred by file-id using File Transfer Protocol.
   The other type of user is a RJE User-process in one remote host
   communicating with the RJE Server-process in another host.  This type
   of user ultimately receives its instructions from a human user, but
   through some unspecified indirect means.  The command and response
   streams of this protocol are designed to be readily used and
   interpreted by both the human user and the user process.

   A particular user site may choose to establish the TELNET control
   connection for each logical job or may leave the control connection
   open for extended periods.  If the control connection is left open,
   then multiple job-files may be directed to be retrieved or optionally
   (to servers that are able to determine the end of one logical job by
   the input stream and form several jobs out of one input file) one
   continuous retrieval may be done (as from a TIP card reader).  This
   then forms a "hot" card reader to a particular server with the TELNET
   connection serving as a "job monitor".  Since the output is always
   transferred job at a time per connection to the output socket, the
   output from this "hot" reader would appear when ready as if to a
   "hot" printer.  Another possibility for more complex hosts is to
   attach an RJE User-process to a card reader and take instructions
   from a lead control card, causing an RJE control TELNET to be opened
   to the appropriate host with appropriate log-on and input retrieval
   commands.  This card reader would appear to the human user as a
   Network "hot" card reader.  The details of this RJE User-process are
   beyond the scope of this protocol.





                                   1
REMOTE Job Entry Protocol
                                                         (Oct. 16, 1972)
                                                       RFC 407 NIC 12112


GENERAL SPECIFICATIONS

   User

      A human user at a real terminal or a process that supplies the
      command control stream causing a job to be submitted remotely will
      be termed the User.  The procedure by which a process user
      receives its instructions is beyond the scope of this protocol.

   User TELNET

      The User communicates its commands over the Network in Network
      Virtual Terminal code through a User TELNET process in the User's
      Host.  This User TELNET process initiates its activity via ICP to
      the standard "RJE Logger" socket (socket 5) at the desired
      RJE-server Host.

   RJE-Server TELNET

      The RJE-server process receives its command stream from and sends
      its response stream to the TELNET channel through an RJE-server
      TELNET process in the server host.  This process must listen for
      the ICP on the "RJE Logger" socket (and cause appropriate ICP
      socket shifting).

   TELNET Connection

      The command and response streams for the RJE mechanism are via a
      TELNET-like connection to a special socket with full
      specifications according to the current NWG TELNET protocol.

   RJE-Server

      The RJE-Server process resides in the Host which is providing
      Remote Batch Job Entry service.  This process receives input from
      the RJE-server TELNET, controls access through the "log-on"
      procedure, retrieves input job files, queues jobs for execution by
      the batch system, responds to status inquiries, and transmits job
      output files when available.

   User FTP

      All input and output files are transferred under control of the
      RJE-server process at its initiative.  These files may be directly
      transferred via Request-for-connection to a specific Host/socket
      or they may be transferred via File Transfer Protocol.  If the
      latter method is used, then the RJE-server acts through its local
      User FTP process to cause the transfer.  This process initiates




                                   2
REMOTE Job Entry Protocol
                                                         (Oct. 16, 1972)
                                                       RFC 407 NIC 12112
                                                                        
                                                                        
      activity by an active Request-for-connection to the "FTP Logger"
      in the foreign host.

   Server FTP

      This process in a remote host (remote from the RJE-server) listens
      for an ICP from the User FTP and then acts upon the commands from
      the User FTP causing the appropriate file transfer.

   FTP

      When File Transfer Protocol is used for RJE files, the standard
      FTP mechanism is used as fully specified by the current NWG
      FTProtocol.

   RJE Command Language

      The RJE system is controlled by a command stream from the User
      over the TELNET connection specifying the user's identity
      (log-on), the source of the job input file, the disposition of the
      job's output files, enquiring about job status, altering job
      status or output disposition.  Additional commands affecting
      output disposition are includable in the job input file.  This
      command language is explicitly specified in a following section of
      this protocol.

   RJE Command Replies

      Every command input from the User via TELNET calls for a response
      message from the RJE-server to the User over the TELNET
      connection.  Certain other conditions also require a response
      message.  These messages are formatted in a standardized manner to
      facilitate interpretation by both human Users and User processes.
      A following section of this protocol specifies the response
      messages.

















                                   3
REMOTE Job Entry Protocol
                                                         (Oct. 16, 1972)
                                                       RFC 407 NIC 12112
                                                                        
                                                                        
RJE COMMANDS OVER TELNET CONNECTION

   GENERAL CONVENTIONS

   1. Each of the commands will be contained in one input line
      terminated by the standard TELNET "crlf".  The line may be of any
      length desired by the user (explicitly, not restricted to a
      physical terminal line width).  The characters "cr" and "lf" will
      be ignored by the RJE-server except in the explicit order "crlf"
      and may be used as needed for local terminal control.

   2. All commands will begin with a recognized command name and may
      then contain recognized syntactic element strings and free-form
      variable strings (for user-id, file-ids, etc.).  Recognized words
      consist of alphanumeric strings (letters and digits) or
      punctuation.  Recognized alphanumeric string elements must be
      separated from each other and from unrecognizable strings by at
      least one blank or a syntacticly permitted punctuation.  Other
      blanks may be used freely as desired before or after any syntactic
      element ("blank" is understood here to mean ASCII SPACE (octal
      040); formally:  <blank>::= <blank><ASCII SPACE> | <ASCII SPACE> ;
      thus, a sequence of SPACES is also permissible in place of
      <blank>, although there is no syntactic necessity for there to be
      more than one).  The "=" after the command name in all commands
      except OUT and CHANGE is optional.

   3. Recognized alphanumeric strings may contain upper case letters or
      lower case letters in any mixture without syntactic
      differentiation.  Unrecognizable strings will be used exactly as
      presented with full differentiation of upper and lower case input,
      unless the host finally using the string defines otherwise.

   4. There are two types of Unrecognizable strings:  final and
      imbedded.  Final strings appear as the last syntactic element of a
      command and are parsed as beginning with the next non-blank
      character of the input stream and continuing to the last non-blank
      character before the "crlf".

   Imbedded strings include "job-id" and "job-file-id" in the OUT,
   CHANGE, and ALTER commands.  At present these fields will be left
   undelimited since they must only be recognizable by the server host
   which hopefully can recognize its own job-ids and file-names.

   SYNTAX

   The following command descriptions are given in a BNF syntax.  Names
   within angle brackets are non-terminal syntactic elements which are
   expanded in succeeding syntactic equations.  Each equation has the




                                   4
REMOTE Job Entry Protocol
                                                         (Oct. 16, 1972)
                                                       RFC 407 NIC 12112
                                                                        
                                                                        
   defined name on the left of the ::= and a set of alternative
   definitions, separated by vertical lines "|", on the right.

   REINITIALIZE

      REINIT

         This command puts the user into a state identical to the state
         immediately after a successful connection to the RJE-server,
         prior to having sent any commands over the TELNET connection.
         The effective action taken is that of an ABORT and a flushing
         of all INPUT, OUTPUT and ID information.  Naturally, the user
         is still responsible for any usage charges incurred prior to
         his REINIT command.  The TELNET connection is not affected in
         any way.

   USER

      User = <user-id>

         This command must be the first command over a new TELNET
         connection.  As such, it initiates a "logon" sequence.  The
         response to this command is one of the following:

            1.  User code in error.
            2.  Enter password (if user code ok).
            3.  Log-on ok, proceed (if no password requested).

         Another USER command may be sent by the User at any time to
         change Users.  Further input will then be charged to the new
         user.  A server may refuse to honor a new user command if it is
         not able to process it in its current state (during input file
         transfer, for example), but the protocol permits the USER
         command at any time without altering previous activity.  An
         incorrect subsequent USER command or its following PASS command
         are to be ignored with error response, leaving the original
         User logged-in.

         It is permissable for a server to close the TELNET connection
         if the initial USER/PASS commands are not completed within a
         server specified time period.  It is not required or implied
         that the "logged-on" User's user-id be the one used for file
         transfer or job execution, but only identifies the submitter of
         the command stream.  Servers will establish their own rules
         relating user-id with the job-execution-user for Job or Output
         alteration commands.

         Successful "log-on" always clears any previous Input or Output
         default parameters (INID, etc.).



                                   5
REMOTE Job Entry Protocol
                                                         (Oct. 16, 1972)
                                                       RFC 407 NIC 12112
                                                                        
                                                                        
   PASS

      Pass = <password>

         This command immediately follows a USER command and completes
         the "log-on" procedure.  Although a particular Server may not
         require a password and has already indicated "log-on ok" after
         the USER command, every Server must permit a PASS command (and
         possibly ignore it) and acknowledge it with a "log-on ok" if
         the log-on is completed.

   BYE

      BYE

         This command terminates a USER and requests the RJE server to
         close the TELNET connection.  If input transfer is not in
         progress, the TELNET connection may be closed immediately; if
         input is in progress, the connection should remain open for
         result response and then be closed.  During the interim, a new
         USER command (and no other command) is acceptable.

         An unexpected close on the TELNET connection will cause the
         server to take the effective action of an ABORT and a BYE.

   INID/INPASS

      INID = <user-id>
      INPASS = <password>

         The specified user-id and password will be sent in the File
         Transfer request to retrieve the input file.  These parameters
         are not used by the Server in any other way.  If this command
         does not appear, then the USER/PASS parameters are used.

   INPATH/INPUT

      INPATH = <file-id>
      INPUT = <file-id>
      INPUT

         NOTE:  The following syntax will be used for output as well.

            <file-id>::= <host-socket> | <host-file>
            <host-socket>::= <host>,<socket><attributes> |
                             <socket><attributes>
               no <host> part implies the User-site host
            <host>::= <integer>
            <socket>::= <integer>



                                   6
REMOTE Job Entry Protocol
                                                         (Oct. 16, 1972)
                                                       RFC 407 NIC 12112


            <integer>::= D<decimal-integer> | O<octal-integer> |
                         H<hexadecimal-integer>
            <host-file>::= <host><attributes>/<pathname>
            <attributes>::= <empty> | :<transmission><code>
            <transmission>::= <empty> | T | A | N
                  <empty> implies default which is N for Input files
                          and A for Output files
                  T       specifies TELNET-like coding with embedded
                          "crlf" for new-line, "ff" for new-page
                  N       specifies FTP blocked transfer with record
                          marks but without other carriage-control
                  A       specifies FTP blocked records with ASA
                          carriage-control
                          (column 1 of image is forms control)
            <code>::= <empty> | E
                  <empty> specifies NVT ASCII code
                  E specifies EBCDIC
            <pathname>::= <any string recognized by the FTP Server at
                          the site of the file>

         The <file-id> syntax is the general RJE mechanism for
         specifying a particular file source or destination for input or
         output.  If the <host-socket> form is used then direct transfer
         will be made by the RJE-Server to the named socket using the
         specified <attributes>.  If the <host-file> form is used then
         the RJE-server will call upon its local FTP-user process to do
         the actual transfer.  The data stream in this mode is either
         TELNET-like ASCII or blocked records (which may use column 1
         for ASA carriage-control).  Although A mode is permitted on
         input (column 1 is deleted) the usual mode is the default N.
         The output supplies carriage-control in the first character of
         each record ("blank" = single-space, "1" = new-page, etc.),
         while the optional N mode transfers the data only (as to a card
         punch, etc.).

         The <pathname> is an arbitrary Unrecognized string which is
         saved by RJE-server and sent back over FTP to the FTP-server to
         retrieve or store the appropriate files.

         INPATH or INPUT commands first store the specified <file-id> if
         one is supplied, and then the INPUT command initiates input.
         The INPATH name may be used to specify a file-id for later
         input and the INPUT command without file-id will cause input to
         initiate over a previously specified file-id.  An INPUT "crlf"
         command with no previous <file-id> specified is illegal.







                                   7
REMOTE Job Entry Protocol
                                                         (Oct. 16, 1972)
                                                       RFC 407 NIC 12112
                                                                        
                                                                        
   ABORT

      ABORT

         This command aborts any input retrieval in progress, discards
         already received records, and closes the retrieval connection.
         Note:  ABORT with parameters is an Output Transmission control
         (see below).

   OUTUSER/OUTPASS

      OUTUSER = <user-id>
      OUTPASS = <password>

         The specified user-id and password will be sent in the File
         Transfer request to send the output file(s).  These parameters
         are not used by the Server in any other way.  If this command
         does not appear, then the USER/PASS parameters are used.

   OUT

      OUT <out-file> = <disp>

         <out-file>::= <empty> | <job-file-id>
               <empty> implies the primary print file of the job
         <job-file-id>::= <string representing a specific output file
                          from the job as recognized by the Server>
         <disp>::= <empty><file-id> | (H) | (S)<file-id>|(D)
               <empty> specifies Transmit then discard
               (H) specifies Hold-only, do not transmit
               (S) specifies Transmit and Save
               (D) specifies discard without transmitting
         Note:  Parentheses are part of the above elements.

         <file-id>::= (same as for INPUT command)

         This command specifies the disposition of output file(s)
         produced by the job.  Unspecified files will be Hold-only by
         default.  The OUTUSER, OUTPASS, and OUT commands must be
         specified before the INPUT command to be effective.  These
         commands will affect any following jobs submitted by this USER
         over this RJE-TELNET connection.  A particular job may override
         these commands by NET control cards on the front of the input
         file.

         Once output disposition is specified by this OUT command or by
         a NET OUT card, the information is kept with the job until
         final output disposition, and is modifiable by the CHANGE
         command.



                                   8
REMOTE Job Entry Protocol
                                                         (Oct. 16, 1972)
                                                       RFC 407 NIC 12112
                                                                        
                                                                        
         On occasion, the server may find that the destination for the
         output is "busy" (i.e., RFC to either Server-FTP or specified
         socket is refused), or that the host which should receive the
         output is dead.  In these cases, the server should wait several
         minutes and then try to transmit again.

   OUTPUT RE-ROUTE

      CHANGE <job-id><blank><out-file> = <disp>

         This command changes the output disposition supplied with the
         job at submission.  The <job-id> is assumed recognizable by the
         RJE-server, who may verify if this USER is authorized to modify
         the specified job.  After the job is identified, the other
         information has the same syntax and semantics as the original
         OUT command.  CHANGE command may be specified for a job-file-id
         which was not mentioned at submission time and has the same
         effect as an original OUT command.

   OUTPUT CONTROLS DURING TRANSMISSION

      <command><blank><count><blank><what>

      <command>::= RESTART | RECOVER | BACK | SKIP |
      ABORT | HOLD

      These commands specify (respectively):

         Restart the transmission (new RFC, etc.)
         Recover restarts transmission from last FTP
         Restart-marker-reply
         (see FTP).
         Back up the output "count" blocks
         Skip the output forward "count" blocks
         Abort the output, discarding it
         Abort the output, but Hold it

      <count>::= <empty> | <integer>
         <empty> implies 1 where defined
      <what>::= @<file-id> | <job-id><job-file-id>
      <disp>::= (same as for OUT command)
      <file-id>::= (same as for INPUT command)
      <integer>::= (same as for INPUT command)
      <job-id>::= <server recognized job identifier which was supplied
                  at INP completion by the server>

      <job-file-id>::= <server recognized file identifier or if missing
                       then the prime printer output of the specified
                       job>



                                   9
REMOTE Job Entry Protocol
                                                         (Oct. 16, 1972)
                                                       RFC 407 NIC 12112
                                                                        
                                                                        
      This collection of commands will modify the transmission of output
      in progress or recently aborted.  If output transmission is
      cut-off before completion, then the RJE-server will either try to
      resend the entire file if the file's <disp> was
      Transmit-and-discard or will Hold the file for further User
      control if the <disp> was (S) transmit-and-Save.  Either during
      transmission, during the Save part of a transmit-and-Save, or for
      a Hold-only file, the above commands may be used to control the
      transmission.  The @<file-id> form of <what> is permitted only if
      transmission is actually in progress.

      If the file's state is inconsistent with the command, then the
      command is illegal and ignored with reply.

   STATUS

      STATUS <job-id>
      STATUS <job-id><blank><job-file-id>

         These commands request the status of the RJE-server, a
         particular job, or the transmission of an output or input file,
         respectively.  The information content of the Status reply is
         site dependent.

   CANCEL/ALTER

      CANCEL <job-id>
      ALTER <job-id><blank><site dependent options>

         These commands change the course of a submitted job.  CANCEL
         specifies that the job is to be immediately terminated and any
         output discarded.  ALTER provides for system dependent options
         such as changing job priority, process limits, Teminate without
         Cancel, etc.

   OP

      OP (any string)

         The specified string is to be displayed to the Server site
         operator when any following job is initiated from the batch
         queue of the Server.  This command usually appears in the input
         file as a NET OP control card, but may be a TELNET command.  It
         is cancelled as an all-jobs command by an OP "crlf" command (no
         text supplied).







                                   10
REMOTE Job Entry Protocol
                                                         (Oct. 16, 1972)
                                                       RFC 407 NIC 12112
                                                                        
                                                                        
RJE CONTROL CARDS IN THE INPUT FILE

   Certain RJE commands may be specified by control cards in the front
   of the input file.  If these controls appear, they take precedence
   over the same command given thru the RJE-TELNET connection and affect
   only this specific job.  All these RJE control cards must appear as
   the first records of the job's input-file.  They all contain the
   control word NET in columns 1 through 3.  Scanning for these controls
   stops when the first card without NET in col 1-3 is encountered.

   The control commands appear in individual records and are terminated
   by the end-of-record (usually an 80 column card-image).  Continuation
   is permitted onto the next record by the appearance of NET+ in
   columns 1-4 of the next record.  Column 5 of the next record
   immediately follows the last character of the previous record.

      NET OUTUSER = <user-id>
      NET OUTPASS = <password>
      NET OUT <out-file> = <disp>
      NET OP <any string>

   See the corresponding TELNET command for details.  One option
   permitted by the NET OUTUSER and NET OUT controls not possible from
   the TELNET connection is specification of different OUTUSERs for
   different OUTS, since the TELNET stored and supplies only an initial
   OUTUSER, but the controls may change OUTUSERs before each OUT control
   is encountered.

RJE USE OF FILE TRANSFER PROTOCOL

   Most non-TIP files will be transferred to or from the RJE-server
   through the FTP process.  RJE-server will call upon its local
   FTP-user supplying the Host, File-pathname, User-id, Password, and
   Mode of the desired transfer.  FTP-user will then connect to its
   FTP-server counterpart in the specified host and set up a transfer
   path.  Data will then flow through the RJE-FTP interface in the
   Server, over the Network, from/to the foreign FTP-server and then
   from/to the specified File-pathname in the foreign host's file
   storage space.  On output files, the file-pathname may be recognized
   by the foreign host as directions to a printer or the file may simply
   be stored; a User-RJE-process can supply an output <file-id> by
   default which is recognized by its own Server-FTP as routing to a
   printer.

   Although many specifics of the RJE-Server/User-FTP interface are
   going to be site dependent, there are several FTP options which will
   be used in a standard way by RJE-Servers:





                                   11
REMOTE Job Entry Protocol
                                                         (Oct. 16, 1972)
                                                       RFC 407 NIC 12112
                                                                        
                                                                        
      1. A new FTP connection will be initiated for each file to be
         transferred.  The connection will be opened with the RJE User
         supplied User-id (OUTUSER or INUSER) and Password.

      2. The data bytesize will be 8 bits.

      3. The FTP Type, Structure, and Mode parameters are determined by
         the RJE transfer direction (I/O), and the <transmission> and
         <code> options supplied by the User:

     I/O   <TRANS>   <CODE>   FTP-TYPE   FTP-STRUCTURE   FTP-MODE
      I*      N        -         A             R            B
      I       N        E         E             R            B
      I       T        -         A             F            S
      I       T        E         E             F            S
      I       A        -         P             R            B
      I       A        E         F             R            B
   
      O*      A        -         P             R            B
      O       A        E         F             R            B
      O       N        -         A             R            B
      O       N        E         E             R            B
      O       T        -         A             F            S
      O       T        E         E             F            S
   
              (*indicates default)

      4. The service commands used will be Retrieve for input and Append
         (with create) for output.  The FTP pathname will be the
         <pathname> supplied by the RJE User.

      5. On output in B form, the User-FTP at the RJE-Server site will
         send Restart-markers at periodic intervals (like every 100
         lines, or so), and will remember the latest
         Restart-marker-reply with the file.  If the file transfer is
         not completed and the <disp> is (S) then the file will be held
         pending User intervention.  The User may then use the RECOVER
         command to cause a FTP restart at the last remembered
         Restart-marker-reply.

      6. The FTP Abort command will be used for the RJE ABORT and CANCEL
         commands.

      7. For transfers where the FTP-MODE is defined as B, the user FTP
         may optionally attempt to use H mode.

   The specific form of the FTP commands used by an RJE-Server site, and
   the order in which they are used will not be specified in this
   protocol.



                                   12
REMOTE Job Entry Protocol
                                                         (Oct. 16, 1972)
                                                       RFC 407 NIC 12112
                                                                        
                                                                        
   Errors encountered by FTP fall into three categories:  a) access
   errors or no storage space error; b) command format errors; and c)
   transfer failure errors.  Since the commands are created by the
   RJE-Server process, an error is a programming problem and should be
   logged for attention and the situation handled as safely as possible.
   Transmission failure or access failure on input cause an effective
   ABORT and user notification.  Transmission failure on output causes
   RESTART or Save depending on <disp> (see OUT command).  Access
   failure on output is a problem since the User may not be accessible.
   A status response should be queued for him, should he happen to
   inquire; a <disp> = (S) file should be Held; and a <disp> = <empty>
   transmit-and-discard file should be temporarily held and then
   discarded if not claimed.  "Temporarily" is understood here to mean
   at least several days, since particularly in the case of jobs which
   generate voluminous output at great expense to the User, he should be
   given every chance to retrieve his rightful output.  Servers may
   elect, however, to charge the User for the file-storage space
   occupied by the held output.


































                                   13
REMOTE Job Entry Protocol
                                                         (Oct. 16, 1972)
                                                       RFC 407 NIC 12112
                                                                        
                                                                        
REPLIES OVER THE TELNET CONNECTION

   Each action of the RJE-server, including entry of each TELNET
   command, is noted over the TELNET connection to the User.  These
   RJE-server replies are formatted for Human or Process interpretation.
   They consist of a leading 3-digit numeric code followed by a blank
   followed by a text explanation of the message.  The numeric codes are
   assigned by groups for future expansion to hopefully cover other
   protocols besides RJE (like FTP).  The numeric code is designed for
   ease of interpretation by processes.  The three digits of the code
   are interpreted as follows:

   The first digit specified the "type" of response indicated:

      000

         These "replies" are purely informative, and are issued
         voluntarily by the Server to inform a User of some state of the
         server's system.

      100

         Replies to a specific status inquiry.  These replies serve as
         both information and as acknowledgment of the status request.

      200

         Positive acknowledgment of some previous command/request.  The
         reply 200 is a generalized "ok" for commands which require no
         other comment.  Other 2xx replies are specified for specific
         successful actions.

      300

         Incomplete information supplied so far.  No major problem, but
         activity cannot proceed with the input specified.

      400

         Unsuccessful reply.  A request was correctly specified, but
         could not be correctly completed.  Further attempts will
         require User commands.

      500

         Incorrect or illegal command.  The command or its parameters
         were invalid or incomplete from a syntactic view, or the
         command is inconsistent with a previous command.  The command
         in question has been totally ignored.



                                   14
REMOTE Job Entry Protocol
                                                         (Oct. 16, 1972)
                                                       RFC 407 NIC 12112
                                                                        
                                                                        
      600-900

         Reserved for expansion

   The second digit specifies the general subject to which the response
   refers:

      x00-x29

         General purpose replies, not assignable to other subjects.

      x30

         Primary access.  These replies refer to the attempt to "log-on"
         to a Server service (RJE, FTP, etc.).

      x40

         Secondary access.  The primary Server is commenting on its
         ability to access a secondary service (RJE must log-on to a
         remote FTP service).

      x50

         FTP results.

      x60

         RJE results.

      x70-x99

         Reserved for expansion.

   The final digit specifies a particular message type.  Since the code
   is designed for an automaton process to interpret, it is not
   necessary for every variation of a reply to have a unique number,
   only that the basic meaning have a unique number.  The text of a
   reply can explain the specific reason for the reply to a human User.

   Each TELNET line (ended by "crlf") from the Server is intended to be
   a complete reply message.  If it is necessary to continue the text of
   a reply onto following lines, then those continuation replies contain
   the special reply code of three blanks.








                                   15
REMOTE Job Entry Protocol
                                                         (Oct. 16, 1972)
                                                       RFC 407 NIC 12112
                                                                        
                                                                        
   The assigned reply codes relating to RJE are:

   000 General information message (time of day, etc.)
   030 Server availability information
   050 FTP commentary or user information
   060 RJE or Batch system commentary or information
   100 System status reply
   150 File status reply
   151 Directory listing reply
   160 RJE system general status reply
   161 RJE job status reply
   200 Last command received ok
   201 An ABORT has terminated activity, as requested
   202 ABORT request ignored, no activity in progress
   203 The requested Transmission Control has taken effect
   204 A REINIT command has been executed, as requested
   230 Log-on completed
   231 Log-off completed, goodbye.
   232 Log-off noted, will complete when transfer done
   240 File transfer has started
   250 FTP File transfer started ok
   251 FTP Restart-marker-reply
      Text is:  MARK yyyy = mmmm
         where yyyy is data stream marker value (yours)
         and mmmm is receiver's equivalent mark (mine)
   252 FTP transfer completed ok
   253 Rename completed
   254 Delete completed
   260 Job <job-id> accepted for processing
   261 Job <job-id> completed, awaiting output transfer
   262 Job <job-id> Cancelled as requested
   263 Job <job-id> Altered as requested to state <status>
   264 Job <job-id>,<job-file-id> transmission in progress
   300 Connection greeting message, awaiting input
   301 Current command not completed (may be sent after
      suitable delay, if not "crlf")
   330 Enter password (may be sent with hide-your-input mode)
   360 INPUT has never specified an INPATH
   400 This service is not implemented
   401 This service is not accepting log-on now, goodbye.
   430 Log-on time or tries exceeded, goodbye.
   431 Log-on unsuccessful, user and/or password invalid
   432 User not valid for this service
   434 Log-out forced by operator action, please phone site
   435 Log-out forced by system problem
   436 Service shutting down, goodbye
   440 RJE could not log-on to remote FTP for input transfer
   441 RJE could not access the specified input file thru FTP
   442 RJE could not establish <host-socket> input connection



                                   16
REMOTE Job Entry Protocol
                                                         (Oct. 16, 1972)
                                                       RFC 407 NIC 12112
                                                                        
                                                                        
   443 RJE could not log-on to remote FTP for output delivery
   444 RJE could not access file space given for output
   445 RJE could not establish <host-socket> output connection
   450 FTP:  The named file does not exist (or access denied)
   451 FTP:  The named file space not accessable by YOU
   452 FTP:  Transfer not completed, data connection closed
   453 FTP:  Transfer not completed, insufficient storage space
   460 Job input not completed, ABORT performed
   461 Job format not acceptable for processing, Cancelled
   462 Job previously accepted has mysteriously been lost
   463 Job previously accepted did not complete
   464 Job-id referenced by STATUS, CANCEL, ALTER, CHANGE, or
      Transmission Control is not known (or access denied)
   465 Request Alteration is not permitted for the specified job
   466 Un-deliverable, un-claimed output for <job-id> discarded
   467 Requested REINIT not accomplished
   500 Last command line completely unrecognized
   501 Syntax of the last command is incorrect
   502 Last command incomplete, parameters missing
   503 Last command invalid, illegal parameter combination
   504 Last command invalid, action not possible at this time
   505 Last command conflicts illegally with previous command(s)
   506 Requested action not implemented by this Server
   507 Job <job-id> last command line completely unrecognized
   508 Job <job-id> syntax of the last command is incorrect
   509 Job <job-id> last command incomplete, parameters missing
   510 Job <job-id> last command invalid, illegal parameter
      combination
   511 Job <job-id> last command invalid, action impossible at
      this time
   512 Job <job-id> last command conflicts illegally with previous
      command(s)

SEQUENCING OF COMMANDS AND REPLIES

   The communication between the User and Server is intended to be an
   alternating dialogue.  As such, the User issues an RJE command and
   the Server responds with a prompt primary reply.  The User should
   wait for this initial success or failure response before sending
   further commands.

   A second type of reply is sent by Server asynchronously with respect
   to User commands.  These replies report on the progress of a job
   submission caused by the INPUT command and as such are secondary
   replies to that command.

   The final class of Server "replies" are strictly informational and
   may arrive at any time.  These "replies" are listed below as
   spontaneous.



                                   17
REMOTE Job Entry Protocol
                                                         (Oct. 16, 1972)
                                                       RFC 407 NIC 12112
                                                                        
                                                                        
COMMAND-REPLY CORRESPONDENCE TABLE

   COMMAND                    SUCCESS          FAILURE

   REINIT                     204              467,500-505
   USER                       230,330          430-432,500-505
   PASS                       230              430-432,500-505
   BYE                        231,232          500-505
   INID                       200              500-505
   INPASS                     200              500-505
   INPATH                     200              500-505
   INPUT                      240              360,440-442,500-505
      sec. input retrieval    260              460,461
      sec. job execution      261              462,463
      sec. output transmission -               443-445,466
   ABORT (input)              201,202          500-505
   OUTUSER                    200              500-505
   OUTPASS                    200              500-505
   OUT                        200              500-505
   CHANGE                     200              500-505
   RESTART/RECOVER/BACK
    /SKIP/ABORT (output)/HOLD 203              464,500-506
   STATUS                     1xx,264          460-465,500-505
   CANCEL                     262              464,500-506
   ALTER                      263              464,465,500-506
   OP                         200              500-505
   Spontaneous                0xx,300,301      434-436

   Note:  For commands appearing on cards, a separate set of error codes
   is provided (507-512).  Since these error replies are
   "asynchronously" sent, and thus could cause some confusion if the
   user is in the process of submitting a new job after the present one,
   the error replies must identify which job has the faulty card(s).



















                                   18
REMOTE Job Entry Protocol
                                                         (Oct. 16, 1972)
                                                       RFC 407 NIC 12112
                                                                        
                                                                        
   TYPICAL RJE SCENARIOS

      TIP USER WANTING HOT CARD READER TO HOSTX

         1. TIP user opens TELNET connection to HOSTX socket 5

         2. Commands sent over TELNET to RJE

            USER=myself
            PASS=dorwssap
            OUT=H70002
            INPUT=H50003

         3. RJE-server connects to the TIP's device 5 and begins
            reading.  When end-of-job card is recognized, the job is
            queued to run.  The connection to the card reader is still
            open for more input as another job.

         4. The first job finishes.  A connection to the TIP's device 7
            is established by RJE-server and the output is sent as an
            NVT stream.

         5. Continue at any time with another deck at step 3.

      TIP WITH JOB-AT-A-TIME CARD READER

         1. thru 4) the same but User closes Reader after the deck

         2. The output finishes and the printer connection closes.

         3. INPUT may be typed any time after step 3 finishes and
            another job will be entered starting at 3.




















                                   19
REMOTE Job Entry Protocol
                                                         (Oct. 16, 1972)
                                                       RFC 407 NIC 12112
                                                                        
                                                                        
      HOSTA USER RUNS JOB AT HOSTC, INPUT FROM HOSTB

         1. User TELNET connects to HOSTC socket 5 for RJE

            USER=roundabout
            PASS=aaabbbc
            OUTUSER=roundab1
            OUT=:E/.sysprinter
            OUT puncher = (S)HOSTB:NE/my.savepunch
            INUSER=rounder
            INPASS=x.x.x
            INPUT=HOSTB:E/my.jobinput

         2. The RJE-server has FTP retrieve the input from HOSTB using
            User-id of "rounder" and Password of "x.x.x" for file named
            "my.jobinput".

         3. The job finishes.  RJE-server uses FTP to send two files:
            the print output is sent to HOSTA in EBCDIC with ASA
            carriage control to file ".sysprinter" while the file known
            as "puncher" is sent to HOSTB in EBCDIC without
            carriage-control to file "my.savepunch".

         4. when the outputs finish, RJE-server at HOSTC discards the
            print file but retains the "puncher" file.

         5. The User who has signed out after job submission has gotten
            his output and checked his file "my.savepunch" at HOSTB.  He
            deletes the saved copy at HOSTC by re-calling RJE at HOSTC.

            USER=roundabout
            PASS=aaabbbcc
            ABORT job 123 puncher
                   or
            CHANGE job 123 puncher = (D)

















                                   20
  1. RFC 0407