path: root/doc/rfc/rfc360.txt

Network Working Group                                         C. Holland
Request for Comments: 360                                        UCSD-CC
Category: Protocols, RJE                                       June 1972
NIC: 10602


                   PROPOSED REMOTE JOB ENTRY PROTOCOL

   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 TELNET (to a special standardized logger, not socket 1)
   connection for all control communication between the user and the
   server RJE process.  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 pathname using File Transfer Protocol.
   The other type of user is an 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 location 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 logon and input retrieval



Holland                                                         [Page 1]
^L
RFC 360                     REMOTE JOB ENTRY                   June 1972


   commands.  This card reader would appear to the human user as a
   Network "host" card reader.  The details of this RJE User-process are
   beyond the scope of this protocol.

   GENERAL SPECIFICATIONS

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

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

   3.   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).

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

   5.   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
        "logon" procedure, retrieves input job files, queues jobs for
        execution by the batch system, responds to status inquiries, and
        transmits job output files when available.

   6.   User FTP - All input and output files are transferred under
        control of the RJE-server process at its initiative.  Those
        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 later method is used, then the RJE-
        server acts through its local User FTP process to cause the
        transfer.  This process initiates activity by an active
        Request-for-connection to the "FTP Logger" in the foreign host.







Holland                                                         [Page 2]
^L
RFC 360                     REMOTE JOB ENTRY                   June 1972


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

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

   9.   RJE Command Language - The RJE system is controlled by a command
        stream from the User over the TELNET connection specifying the
        user's identity (logon), the source of the job input file, the
        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.

   10.  RJE Command Replies - Every command input from the User via
        TELNET and certain other conditions calls for a response message
        from the RJE-server to the User over the TELNET connection.
        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.

   RJE COMMANDS OVER TELNET CONNECTION

   GENERAL CONVENTIONS

   1.   All 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 userid, pathnames, 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 syntactically permitted punctuation.  Other
        blanks may be used freely as desired before or after any
        syntactic element.  The "=" after the command name in all
        commands except OUT and CHANGE are optional.





Holland                                                         [Page 3]
^L
RFC 360                     REMOTE JOB ENTRY                   June 1972


   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 undelimitted 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-like
        syntax.  Parenthesized names are non-terminal syntactic elements
        which are expanded in succeeding syntactic equations.  Each
        equation has the defined name on the left of the ::= and a set
        of alternative definitions, separated by slashes "/", on the
        right.  The equations for (host-file) and (disp) use the
        characters "/" "( )" explicitly in their definitions.  In these
        cases the quotes are not part of the definition, but surround
        literal text which is part.

   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 either

      a) User code in error.
      b) Enter password (if usercode ok)
      c) Log-on ok, proceed.  (if no password required)

     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 stat (during input file transfer, for
     example), but the protocol permits the USER command at any time





Holland                                                         [Page 4]
^L
RFC 360                     REMOTE JOB ENTRY                   June 1972


     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 be the
     user-id 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.).

   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 if input transfer is not in
      progress, closes the TELNET connection.  If input is in progress,
      the connection will remain open for result response and will then
      close.  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 BYE.

   INID/INPASS

      INID = (user-id)
      INPASS = (password)






Holland                                                         [Page 5]
^L
RFC 360                     REMOTE JOB ENTRY                   June 1972


      The specified Userid 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 = (pathname)
      INPUT = (pathname)
      INPUT

      NOTE: The following syntax will also be used for output
      (pathname).

      (pathname)::= (host-socket) / (host-file)
      (host-socket)::= (host),(socket) / (socket)
           no (host) part implies the User-site host
      (host)::= (decimal-integer) / (standard-host-name)
      (socket)::= (decimal-integer) / PORT (decimal-integer)
           (decimal-integer) implies explicit socket, lower bit
                will be set appropriately for the direction
           PORT implies the specified port-sockets for a TIP
                Tip-Socket = Port * 2**16 + (2 or 3)
      (host-file)::= (host)(attributes)"/"(file-name)
      (attributes)::= (empty) / : (transmission)(code)
      (transmission)::= (empty) / T / A / N
           (empty) implies default which is
                N for Input files
                A for output files
           T specifies TELNET-like coding with imbedded "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 (TE not allowed)
      (file-name)::= (any string recognized by the
                 FTP Server at the site of the file)

   The (pathname) 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 TELNET-like ASCII.  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



Holland                                                         [Page 6]
^L
RFC 360                     REMOTE JOB ENTRY                   June 1972


   column 1 for ASA carriage-control).  Although A mode is permitted on
   input (column 1 is deleted) the usual mode would be the default N.
   The output default A would supply carriage-control in the first
   character of each record ("blank"= single-space, "1"=new-page, etc.),
   while the optional N mode would transfer the data only (as to a card
   punch, etc.).

   The (file-name) 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 (pathname) if one
   is supplied, and then the INPUT command initiates input.  The INPATH
   name may be used to specify a pathname for later input and the INPUT
   command without pathname will cause input to initiate over a
   previously specified pathname.  An INPUT "crlf" command with no
   previous (pathname) specified is illegal.

   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.

   OUTUSER/OUTPASS

      OUTUSER = (user-id) OUTPASS = (password)

      The specified Userid 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.
















Holland                                                         [Page 7]
^L
RFC 360                     REMOTE JOB ENTRY                   June 1972


   OUT

      OUT (out-file) = (disp)(pathname)

      (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) / "(H)" / "(S)" / "(D)"
           (empty) specifies Transmit then discard
           (H) specifies Hold-only, do not transmit
           (S) specifies Transmit and Save
           (D) specified discard without transmitting
         Note: Parentheses are part of the above elements.
      (pathname)  see 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 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.

   OUTPUT RE-ROUTE

      CHANGE (job-id)(out-file) = (disp)(pathname)

      This command changes the output disposition supplied with the job
      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.











Holland                                                         [Page 8]
^L
RFC 360                     REMOTE JOB ENTRY                   June 1972


   OUTPUT CONTROLS DURING TRANSMISSION

      (command)(count)(what)

      (command)::= RESTART / RECOVER / BACK / SKIP / ABORT / HOLD
           these commands specify
                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
                Hold the output after Aborting it
      (count)::= (empty) / (decimal-integer)
           (empty) implies  1 where defined
      (what)::= @(pathname) / (job-id)(job-file-id)
           (pathname) is as in the INP 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)

      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 @(pathname) 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
      STATUS (job-id)

      These commands request the status of either the RJE-server or a
      particular job respectively.  The information content of the
      Status reply is site dependent.






Holland                                                         [Page 9]
^L
RFC 360                     REMOTE JOB ENTRY                   June 1972


   CANCEL/ALTER

      CANCEL (job-id)
      ALTER  (job-id) (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, Terminate 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 servicing 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 a all-jobs command by an OP "crlf" command (no
      text supplied).

   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-2.  Scanning for these controls stop 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 = (userid)

   NET OUTPASS = (password)

   NET OUT (out-file) = (disp)(pathname)

   NET OP (any string)




Holland                                                        [Page 10]
^L
RFC 360                     REMOTE JOB ENTRY                   June 1972


   See the corresponding TELNET commands 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 stores 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 output (pathname) 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:

   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), the (transmission and (code)
        options supplied by the User:
















Holland                                                        [Page 11]
^L
RFC 360                     REMOTE JOB ENTRY                   June 1972


                I/O   (TRANS)   (CODE)   FTP TYPE   STRUCTURE   MODE
                ----------------------------------------------------
                I*      N        -       Ascii         R       Hasp
                I       N        E       Image         R       Hasp
                I       T        -       Ascii         F       Ascii
                I       A        -       Ascii         R       Hasp
                I       A        E       Image         R       Hasp

                O*      A        -       Ascii-print   R       Hasp
                O       A        E       Ebcdic-print  R       Hasp
                O       N        -       Ascii         R       Hasp
                O       N        E       Image         R       Hasp
                O       T        -       Ascii-print   F       Ascii

                 Note: The I* and O* are the default cases.

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

   5.   On output in Hasp 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.

   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.

   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 that user, 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 after a reasonable time if not claimed.



Holland                                                        [Page 12]
^L
RFC 360                     REMOTE JOB ENTRY                   June 1972


   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:

   a) The first digit specifies 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 server as
          both information and as acknowledgement of the status request.

      200 Positive acknowledgement 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 can not proceed with the input supplied.

      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.

      600-900 Reserved for expansion.

   b) 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.  There replies refer to the attempt to "log-
          on" to a Server service (RJE, FTP, etc.).




Holland                                                        [Page 13]
^L
RFC 360                     REMOTE JOB ENTRY                   June 1972


      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.

   c) The final digit specifies a particular message type.  Since the
      code is designed for an automation 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.

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



Holland                                                        [Page 14]
^L
RFC 360                     REMOTE JOB ENTRY                   June 1972


      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)
      300 Connection greeting message, awaiting input
      301 Current command not completed
             (may be sent after suitable delay, if no "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 through FTP
      442 RJE could not establish (host-socket) input connection
      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 accessible 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 Requested Alteration not permitted for the specified job
      466 Un-deliverable, un-claimed output for (job-id) discarded
      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







Holland                                                        [Page 15]
^L
RFC 360                     REMOTE JOB ENTRY                   June 1972


   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.

                    COMMAND-REPLY CORRESPONDENCE TABLE

   COMMAND                  Success        Fail
   -------                  -------        ----
   USER                     230,330        430,431,432,500-505
   PASS                     230            430,431,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,444,445,446
   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            464,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, the 200 is not sent
         but the 500-505 errors may be "asynchronously" sent.





Holland                                                        [Page 16]
^L
RFC 360                     REMOTE JOB ENTRY                   June 1972


   TYPICAL RJE SCENARIOS

   1. TIP USER WANTING HOT CARD READER TO HOSTX
      a) TIP user opens TELNET connection to HOSTX socket 5
      b) Commands sent over TELNET to RJE
         USER=myself
         PASS=dorwssap
         OUT=PORT 7
         INPUT=PORT 5
      c) RJE-server connects to the User's host port 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
      d) The first job finishes.  A connection to the Users host port 7
         is established by RJE-server and the output is sent as an NVT
         stream.
      e) Continue at any time with another deck at step c).

   2. TIP WITH JOB-AT-A-TIME CARD READER
      a) thru d) the same but User closes Reader after the deck
      e) The output finishes and the printer connection closes.
      f) INPUT may be typed any time after step c) finishes and another
         job will be entered starting at c).

   3. HOSTA USER RUNS JOB AT HOSTC, INPUT FROM HOSTB
      a) 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
      b) The RJE-server has FTP retrieve the input from HOSTB using
         Userid of "rounder" and Password of "x.x.x" for file named
         "my.jobinput".
      c) 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".
      d) when the outputs finish, RJE-server at HOSTC discards the print
         file but retains the "puncher" file.
      e) The User who had 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



Holland                                                        [Page 17]
^L
RFC 360                     REMOTE JOB ENTRY                   June 1972


         PASS=aaabbbcc
         ABORT job123 puncher
           or by
         CHANGE job123 puncher = (D)















































Holland                                                        [Page 18]
^L