RFC 105 (rfc105) - Page 2 of 9

Network Specifications for Remote Job Entry and Remote Job Output Retrieval at UCSB

RFC 105                       RJE at UCSB                     March 1971


complete, RJE will listen for and accept the next request (if any) in
its queue; if no requests are queued for it, it will terminate
execution, releasing the main storage it occupied.  At times when RJE
is not in core, the Logger listens on socket x'200', and will reject
the first call it receives, read RJE into core, and dispatch it.  RJE
will then list on that socket.  Thus to initiate a login sequence, the
user requests connection to socket x'200'.  If accepted, he is in
contact with RJE.  If rejected, he should reissue the connection
request; when accepted, he will be connected to RJE.  A second
rejection would indicate that the NCP's resources were exhausted.
Once the connection has been established, RJE will consider the user
logged in.

     To prevent RJE from being monopolized by a single user, provision
is made within the software for terminating a connection if RJE is
ever required to wait more than a certain amount of time for a
transmission from the connected user.  For now, this time limit has
been set at one minute per record, but it may be shortened or
lengthened as required in the future.  Barring such termination, RJE
will maintain its connection to the user indefinitely.  Card images
will be accepted over the connection, and each one will be passed to
HASP as it is received.  The user is expected to close the connection
once his file has been transmitted.  RJE will interpret that action as
an end-of-file indication, and the user will be considered logged off.

I.B - The RJE Connection

     RJE expects the first byte of data it receives over the
connection established with it to be zeros, indicating message Type 0;
it discards this byte unexamined, and thereafter, attaches no
significance to IMP-message boundaries.  The second byte of data
received is interpreted as flags specifying the format of the data
(file) to follow.  The byte is interpreted as follows:

     Bits 0-1 = 00:  file follows as Class A (stream-oriented)
                     input.
              = 01:  not defined, should not occur.
              = 10:  file follows as Class B (variable-length
                     record) input.
              = 11:  file follows as Class C (fixed-length record)
                     input.
     Bits 2-7     :  not examined, should be zeros.

Once made, this declaration prevails for the life of the connection.

     Regardless of the input class specified, the user transmits his
file as card images, each of which will be padded on the right with
blanks or truncated on the right to 80 bytes if necessary.  The file



White