Proposed Remote Job Entry Protocol
RFC 360

Document Type RFC - Unknown (June 1972; No errata)
Obsoleted by RFC 407
Last updated 2013-03-02
Stream Legacy
Formats plain text html pdf htmlized bibtex
Stream Legacy state (None)
Consensus Boilerplate Unknown
RFC Editor Note (None)
IESG IESG state RFC 360 (Unknown)
Telechat date
Responsible AD (None)
Send notices to (None)
Network Working Group                                         C. Holland
Request for Comments: 360                                        UCSD-CC
Category: Protocols, RJE                                       June 1972
NIC: 10602


   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

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


   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

   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
Show full document text