As per Relevance of the word connection, we have this rfc below:
(Oct. 16, 1972)
RFC 407 NIC 12112
Robert Bressler, MIT-DMCG Obsoletes RFC 360
Richard Guida, MIT-
Alex McKenzie, BBN-
REMOTE JOB ENTRY PROTOCOL
REMOTE Job Entry
(Oct. 16, 1972)
RFC 407 NIC 12112
REMOTE JOB ENTRY
Remote job entry is the mechanism whereby a user at one
causes a batch-processing job to be run at some other location.
protocol specifies the Network standard procedures for such a user
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.
protocol uses a TELNET connection (to a special standardized logger
not socket 1) for all control communication between the user and
server RJE processes. The server-site then uses the File
Protocol to retrieve the job-input file and to deliver the
file(s).
There are two types of users: direct users (persons) and
processes. The direct user communicates from an interactive
attached to a TIP or any host. This user may cause the input and/
output to be retrieved/sent on a specific socket at the
host (such as for card readers or printers on a TIP), or the user
have the files transferred by file-id using File Transfer Protocol
The other type of user is a RJE User-process in one remote
communicating with the RJE Server-process in another host. This
of user ultimately receives its instructions from a human user,
through some unspecified indirect means. The command and
streams of this protocol are designed to be readily used
interpreted by both the human user and the user process
A particular user site may choose to establish the TELNET
connection for each logical job or may leave the control
open for extended periods. If the control connection is left open
then multiple job-files may be directed to be retrieved or
(to servers that are able to determine the end of one logical job
the input stream and form several jobs out of one input file)
continuous retrieval may be done (as from a TIP card reader).
then forms a "hot" card reader to a particular server with the
connection serving as a "job monitor". Since the output is
transferred job at a time per connection to the output socket,
output from this "hot" reader would appear when ready as if to
"hot" printer. Another possibility for more complex hosts is
attach an RJE User-process to a card reader and take
from a lead control card, causing an RJE control TELNET to be
to the appropriate host with appropriate log-on and input
commands. This card reader would appear to the human user as
Network "hot" card reader. The details of this RJE User-process
beyond the scope of this protocol
1
REMOTE Job Entry
(Oct. 16, 1972)
RFC 407 NIC 12112
GENERAL
A human user at a real terminal or a process that supplies
command control stream causing a job to be submitted remotely
be termed the User. The procedure by which a process
receives its instructions is beyond the scope of this protocol
User
The User communicates its commands over the Network in
Virtual Terminal code through a User TELNET process in the User'
Host. This User TELNET process initiates its activity via ICP
the standard "RJE Logger" socket (socket 5) at the
RJE-server Host
RJE-Server
The RJE-server process receives its command stream from and
its response stream to the TELNET channel through an RJE-
TELNET process in the server host. This process must listen
the ICP on the "RJE Logger" socket (and cause appropriate
socket shifting).
TELNET
The command and response streams for the RJE mechanism are via
TELNET-like connection to a special socket with
specifications according to the current NWG TELNET protocol
RJE-
The RJE-Server process resides in the Host which is
Remote Batch Job Entry service. This process receives input
the RJE-server TELNET, controls access through the "log-on
procedure, retrieves input job files, queues jobs for execution
the batch system, responds to status inquiries, and transmits
output files when available
User
All input and output files are transferred under control of
RJE-server process at its initiative. These files may be
transferred via Request-for-connection to a specific Host/
or they may be transferred via File Transfer Protocol. If
latter method is used, then the RJE-server acts through its
User FTP process to cause the transfer. This process
2
REMOTE Job Entry
(Oct. 16, 1972)
RFC 407 NIC 12112
activity by an active Request-for-connection to the "FTP Logger
in the foreign host
Server
This process in a remote host (remote from the RJE-server)
for an ICP from the User FTP and then acts upon the commands
the User FTP causing the appropriate file transfer
When File Transfer Protocol is used for RJE files, the
FTP mechanism is used as fully specified by the current
FTProtocol
RJE Command
The RJE system is controlled by a command stream from the
over the TELNET connection specifying the user's
(log-on), the source of the job input file, the disposition of
job's output files, enquiring about job status, altering
status or output disposition. Additional commands
output disposition are includable in the job input file.
command language is explicitly specified in a following section
this protocol
RJE Command
Every command input from the User via TELNET calls for a
message from the RJE-server to the User over the
connection. Certain other conditions also require a
message. These messages are formatted in a standardized manner
facilitate interpretation by both human Users and User processes
A following section of this protocol specifies the
messages
3
REMOTE Job Entry
(Oct. 16, 1972)
RFC 407 NIC 12112
RJE COMMANDS OVER TELNET
GENERAL
1. Each of the commands will be contained in one input
terminated by the standard TELNET "crlf". The line may be of
length desired by the user (explicitly, not restricted to
physical terminal line width). The characters "cr" and "lf"
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
then contain recognized syntactic element strings and free-
variable strings (for user-id, file-ids, etc.). Recognized
consist of alphanumeric strings (letters and digits)
punctuation. Recognized alphanumeric string elements must
separated from each other and from unrecognizable strings by
least one blank or a syntacticly permitted punctuation.
blanks may be used freely as desired before or after any
element ("blank" is understood here to mean ASCII SPACE (
040); formally: ::= | ;
thus, a sequence of SPACES is also permissible in place
, although there is no syntactic necessity for there to
more than one). The "=" after the command name in all
except OUT and CHANGE is optional
3. Recognized alphanumeric strings may contain upper case letters
lower case letters in any mixture without
differentiation. Unrecognizable strings will be used exactly
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
imbedded. Final strings appear as the last syntactic element of
command and are parsed as beginning with the next non-
character of the input stream and continuing to the last non-
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
undelimited since they must only be recognizable by the server
which hopefully can recognize its own job-ids and file-names
The following command descriptions are given in a BNF syntax.
within angle brackets are non-terminal syntactic elements which
expanded in succeeding syntactic equations. Each equation has
4
REMOTE Job Entry
(Oct. 16, 1972)
RFC 407 NIC 12112
defined name on the left of the ::= and a set of
definitions, separated by vertical lines "|", on the right
This command puts the user into a state identical to the
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
of all INPUT, OUTPUT and ID information. Naturally, the
is still responsible for any usage charges incurred prior
his REINIT command. The TELNET connection is not affected
any way
User =
This command must be the first command over a new
connection. As such, it initiates a "logon" sequence.
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
change Users. Further input will then be charged to the
user. A server may refuse to honor a new user command if it
not able to process it in its current state (during input
transfer, for example), but the protocol permits the
command at any time without altering previous activity.
incorrect subsequent USER command or its following PASS
are to be ignored with error response, leaving the
User logged-in
It is permissable for a server to close the TELNET
if the initial USER/PASS commands are not completed within
server specified time period. It is not required or
that the "logged-on" User's user-id be the one used for
transfer or job execution, but only identifies the submitter
the command stream. Servers will establish their own
relating user-id with the job-execution-user for Job or
alteration commands
Successful "log-on" always clears any previous Input or
default parameters (INID, etc.).
5
REMOTE Job Entry
(Oct. 16, 1972)
RFC 407 NIC 12112
Pass = <password
This command immediately follows a USER command and
the "log-on" procedure. Although a particular Server may
require a password and has already indicated "log-on ok"
the USER command, every Server must permit a PASS command (
possibly ignore it) and acknowledge it with a "log-on ok"
the log-on is completed
This command terminates a USER and requests the RJE server
close the TELNET connection. If input transfer is not
progress, the TELNET connection may be closed immediately;
input is in progress, the connection should remain open
result response and then be closed. During the interim, a
USER command (and no other command) is acceptable
An unexpected close on the TELNET connection will cause
server to take the effective action of an ABORT and a BYE
INID/
INID =
INPASS = <password
The specified user-id and password will be sent in the
Transfer request to retrieve the input file. These
are not used by the Server in any other way. If this
does not appear, then the USER/PASS parameters are used
INPATH/
INPATH =
INPUT =
NOTE: The following syntax will be used for output as well
::= |
::= , |
no part implies the User-site
::=
::=
6
REMOTE Job Entry
(Oct. 16, 1972)
RFC 407 NIC 12112
::= D | O |
H<hexadecimal-integer
::= /<pathname
::= | :<transmission>
<transmission>::= | T | A |
implies default which is N for Input
and A for Output
T specifies TELNET-like coding with
"crlf" for new-line, "ff" for new-
N specifies FTP blocked transfer with
marks but without other carriage-
A specifies FTP blocked records with
carriage-
(column 1 of image is forms control
::= |
specifies NVT ASCII
E specifies
<pathname>::= recognized by the FTP Server
the site of the file
The syntax is the general RJE mechanism
specifying a particular file source or destination for input
output. If the form is used then direct
will be made by the RJE-Server to the named socket using
specified . If the form is used
the RJE-server will call upon its local FTP-user process to
the actual transfer. The data stream in this mode is
TELNET-like ASCII or blocked records (which may use column 1
for ASA carriage-control). Although A mode is permitted
input (column 1 is deleted) the usual mode is the default N
The output supplies carriage-control in the first character
each record ("blank" = single-space, "1" = new-page, etc.),
while the optional N mode transfers the data only (as to a
punch, etc.).
The <pathname> is an arbitrary Unrecognized string which
saved by RJE-server and sent back over FTP to the FTP-server
retrieve or store the appropriate files
INPATH or INPUT commands first store the specified
one is supplied, and then the INPUT command initiates input
The INPATH name may be used to specify a file-id for
input and the INPUT command without file-id will cause input
initiate over a previously specified file-id. An INPUT "crlf
command with no previous specified is illegal
7
REMOTE Job Entry
(Oct. 16, 1972)
RFC 407 NIC 12112
This command aborts any input retrieval in progress,
already received records, and closes the retrieval connection
Note: ABORT with parameters is an Output Transmission
(see below).
OUTUSER/
OUTUSER =
OUTPASS = <password
The specified user-id and password will be sent in the
Transfer request to send the output file(s). These
are not used by the Server in any other way. If this
does not appear, then the USER/PASS parameters are used
OUT =
::= |
implies the primary print file of the
::= representing a specific output
from the job as recognized by the Server
::= | (H) | (S)|(D
specifies Transmit then
(H) specifies Hold-only, do not
(S) specifies Transmit and
(D) specifies discard without
Note: Parentheses are part of the above elements
::= (same as for INPUT command
This command specifies the disposition of output file(s
produced by the job. Unspecified files will be Hold-only
default. The OUTUSER, OUTPASS, and OUT commands must
specified before the INPUT command to be effective.
commands will affect any following jobs submitted by this
over this RJE-TELNET connection. A particular job may
these commands by NET control cards on the front of the
file
Once output disposition is specified by this OUT command or
a NET OUT card, the information is kept with the job
final output disposition, and is modifiable by the
command
8
REMOTE Job Entry
(Oct. 16, 1972)
RFC 407 NIC 12112
On occasion, the server may find that the destination for
output is "busy" (i.e., RFC to either Server-FTP or
socket is refused), or that the host which should receive
output is dead. In these cases, the server should wait
minutes and then try to transmit again
OUTPUT RE-
CHANGE =
This command changes the output disposition supplied with
job at submission. The is assumed recognizable by
RJE-server, who may verify if this USER is authorized to
the specified job. After the job is identified, the
information has the same syntax and semantics as the
OUT command. CHANGE command may be specified for a job-file-
which was not mentioned at submission time and has the
effect as an original OUT command
OUTPUT CONTROLS DURING
::= RESTART | RECOVER | BACK | SKIP |
ABORT |
These commands specify (respectively):
Restart the transmission (new RFC, etc.)
Recover restarts transmission from last
Restart-marker-
(see FTP).
Back up the output "count"
Skip the output forward "count"
Abort the output, discarding
Abort the output, but Hold
::= |
implies 1 where
::= @ |
::= (same as for OUT command
::= (same as for INPUT command
::= (same as for INPUT command
::= recognized job identifier which was
at INP completion by the server
::= recognized file identifier or if
then the prime printer output of the
job
9
REMOTE Job Entry
(Oct. 16, 1972)
RFC 407 NIC 12112
This collection of commands will modify the transmission of
in progress or recently aborted. If output transmission
cut-off before completion, then the RJE-server will either try
resend the entire file if the file's
Transmit-and-discard or will Hold the file for further
control if the was (S) transmit-and-Save. Either
transmission, during the Save part of a transmit-and-Save, or
a Hold-only file, the above commands may be used to control
transmission. The @ form of is permitted only
transmission is actually in progress
If the file's state is inconsistent with the command, then
command is illegal and ignored with reply
STATUS
STATUS
These commands request the status of the RJE-server,
particular job, or the transmission of an output or input file
respectively. The information content of the Status reply
site dependent
CANCEL/
CANCEL
ALTER
These commands change the course of a submitted job.
specifies that the job is to be immediately terminated and
output discarded. ALTER provides for system dependent
such as changing job priority, process limits, Teminate
Cancel, etc
OP (any string
The specified string is to be displayed to the Server
operator when any following job is initiated from the
queue of the Server. This command usually appears in the
file as a NET OP control card, but may be a TELNET command.
is cancelled as an all-jobs command by an OP "crlf" command (
text supplied).
10
REMOTE Job Entry
(Oct. 16, 1972)
RFC 407 NIC 12112
RJE CONTROL CARDS IN THE INPUT
Certain RJE commands may be specified by control cards in the
of the input file. If these controls appear, they take
over the same command given thru the RJE-TELNET connection and
only this specific job. All these RJE control cards must appear
the first records of the job's input-file. They all contain
control word NET in columns 1 through 3. Scanning for these
stops when the first card without NET in col 1-3 is encountered
The control commands appear in individual records and are
by the end-of-record (usually an 80 column card-image).
is permitted onto the next record by the appearance of NET+
columns 1-4 of the next record. Column 5 of the next
immediately follows the last character of the previous record
NET OUTUSER =
NET OUTPASS = <password
NET OUT =
NET OP
See the corresponding TELNET command for details. One
permitted by the NET OUTUSER and NET OUT controls not possible
the TELNET connection is specification of different OUTUSERs
different OUTS, since the TELNET stored and supplies only an
OUTUSER, but the controls may change OUTUSERs before each OUT
is encountered
RJE USE OF FILE TRANSFER
Most non-TIP files will be transferred to or from the RJE-
through the FTP process. RJE-server will call upon its
FTP-user supplying the Host, File-pathname, User-id, Password,
Mode of the desired transfer. FTP-user will then connect to
FTP-server counterpart in the specified host and set up a
path. Data will then flow through the RJE-FTP interface in
Server, over the Network, from/to the foreign FTP-server and
from/to the specified File-pathname in the foreign host's
storage space. On output files, the file-pathname may be
by the foreign host as directions to a printer or the file may
be stored; a User-RJE-process can supply an output
default which is recognized by its own Server-FTP as routing to
printer
Although many specifics of the RJE-Server/User-FTP interface
going to be site dependent, there are several FTP options which
be used in a standard way by RJE-Servers
11
REMOTE Job Entry
(Oct. 16, 1972)
RFC 407 NIC 12112
1. A new FTP connection will be initiated for each file to
transferred. The connection will be opened with the RJE
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
the RJE transfer direction (I/O), and the <transmission>
options supplied by the User
I/O FTP-TYPE FTP-STRUCTURE FTP-
I* N - A R
I N E E R
I T - A F
I T E E F
I A - P R
I A E F R
O* A - P R
O A E F R
O N - A R
O N E E R
O T - A F
O T E E F
(*indicates default
4. The service commands used will be Retrieve for input and
(with create) for output. The FTP pathname will be
<pathname> supplied by the RJE User
5. On output in B form, the User-FTP at the RJE-Server site
send Restart-markers at periodic intervals (like every 100
lines, or so), and will remember the
Restart-marker-reply with the file. If the file transfer
not completed and the is (S) then the file will be
pending User intervention. The User may then use the
command to cause a FTP restart at the last
Restart-marker-reply
6. The FTP Abort command will be used for the RJE ABORT and
commands
7. For transfers where the FTP-MODE is defined as B, the user
may optionally attempt to use H mode
The specific form of the FTP commands used by an RJE-Server site,
the order in which they are used will not be specified in
protocol
12
REMOTE Job Entry
(Oct. 16, 1972)
RFC 407 NIC 12112
Errors encountered by FTP fall into three categories: a)
errors or no storage space error; b) command format errors; and c
transfer failure errors. Since the commands are created by
RJE-Server process, an error is a programming problem and should
logged for attention and the situation handled as safely as possible
Transmission failure or access failure on input cause an
ABORT and user notification. Transmission failure on output
RESTART or Save depending on (see OUT command).
failure on output is a problem since the User may not be accessible
A status response should be queued for him, should he happen
inquire; a = (S) file should be Held; and a =
transmit-and-discard file should be temporarily held and
discarded if not claimed. "Temporarily" is understood here to
at least several days, since particularly in the case of jobs
generate voluminous output at great expense to the User, he should
given every chance to retrieve his rightful output. Servers
elect, however, to charge the User for the file-storage
occupied by the held output
13
REMOTE Job Entry
(Oct. 16, 1972)
RFC 407 NIC 12112
REPLIES OVER THE TELNET
Each action of the RJE-server, including entry of each
command, is noted over the TELNET connection to the User.
RJE-server replies are formatted for Human or Process interpretation
They consist of a leading 3-digit numeric code followed by a
followed by a text explanation of the message. The numeric codes
assigned by groups for future expansion to hopefully cover
protocols besides RJE (like FTP). The numeric code is designed
ease of interpretation by processes. The three digits of the
are interpreted as follows
The first digit specified the "type" of response indicated
000
These "replies" are purely informative, and are
voluntarily by the Server to inform a User of some state of
server's system
100
Replies to a specific status inquiry. These replies serve
both information and as acknowledgment of the status request
200
Positive acknowledgment of some previous command/request.
reply 200 is a generalized "ok" for commands which require
other comment. Other 2xx replies are specified for
successful actions
300
Incomplete information supplied so far. No major problem,
activity cannot proceed with the input specified
400
Unsuccessful reply. A request was correctly specified,
could not be correctly completed. Further attempts
require User commands
500
Incorrect or illegal command. The command or its
were invalid or incomplete from a syntactic view, or
command is inconsistent with a previous command. The
in question has been totally ignored
14
REMOTE Job Entry
(Oct. 16, 1972)
RFC 407 NIC 12112
600-900
Reserved for
The second digit specifies the general subject to which the
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
ability to access a secondary service (RJE must log-on to
remote FTP service).
x50
FTP results
x60
RJE results
x70-x99
Reserved for expansion
The final digit specifies a particular message type. Since the
is designed for an automaton process to interpret, it is
necessary for every variation of a reply to have a unique number
only that the basic meaning have a unique number. The text of
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
a complete reply message. If it is necessary to continue the text
a reply onto following lines, then those continuation replies
the special reply code of three blanks
15
REMOTE Job Entry
(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
050 FTP commentary or user
060 RJE or Batch system commentary or
100 System status
150 File status
151 Directory listing
160 RJE system general status
161 RJE job status
200 Last command received
201 An ABORT has terminated activity, as
202 ABORT request ignored, no activity in
203 The requested Transmission Control has taken
204 A REINIT command has been executed, as
230 Log-on
231 Log-off completed, goodbye
232 Log-off noted, will complete when transfer
240 File transfer has
250 FTP File transfer started
251 FTP Restart-marker-
Text is: MARK yyyy =
where yyyy is data stream marker value (yours
and mmmm is receiver's equivalent mark (mine
252 FTP transfer completed
253 Rename
254 Delete
260 Job accepted for
261 Job completed, awaiting output
262 Job Cancelled as
263 Job Altered as requested to state
264 Job , transmission in
300 Connection greeting message, awaiting
301 Current command not completed (may be sent
suitable delay, if not "crlf")
330 Enter password (may be sent with hide-your-input mode
360 INPUT has never specified an
400 This service is not
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
432 User not valid for this
434 Log-out forced by operator action, please phone
435 Log-out forced by system
436 Service shutting down,
440 RJE could not log-on to remote FTP for input
441 RJE could not access the specified input file thru
442 RJE could not establish input
16
REMOTE Job Entry
(Oct. 16, 1972)
RFC 407 NIC 12112
443 RJE could not log-on to remote FTP for output
444 RJE could not access file space given for
445 RJE could not establish output
450 FTP: The named file does not exist (or access denied
451 FTP: The named file space not accessable by
452 FTP: Transfer not completed, data connection
453 FTP: Transfer not completed, insufficient storage
460 Job input not completed, ABORT
461 Job format not acceptable for processing,
462 Job previously accepted has mysteriously been
463 Job previously accepted did not
464 Job-id referenced by STATUS, CANCEL, ALTER, CHANGE,
Transmission Control is not known (or access denied
465 Request Alteration is not permitted for the specified
466 Un-deliverable, un-claimed output for
467 Requested REINIT not
500 Last command line completely
501 Syntax of the last command is
502 Last command incomplete, parameters
503 Last command invalid, illegal parameter
504 Last command invalid, action not possible at this
505 Last command conflicts illegally with previous command(s
506 Requested action not implemented by this
507 Job last command line completely
508 Job syntax of the last command is
509 Job last command incomplete, parameters
510 Job last command invalid, illegal
511 Job last command invalid, action impossible
this
512 Job last command conflicts illegally with
command(s
SEQUENCING OF COMMANDS AND
The communication between the User and Server is intended to be
alternating dialogue. As such, the User issues an RJE command
the Server responds with a prompt primary reply. The User
wait for this initial success or failure response before
further commands
A second type of reply is sent by Server asynchronously with
to User commands. These replies report on the progress of a
submission caused by the INPUT command and as such are
replies to that command
The final class of Server "replies" are strictly informational
may arrive at any time. These "replies" are listed below
spontaneous
17
REMOTE Job Entry
(Oct. 16, 1972)
RFC 407 NIC 12112
COMMAND-REPLY CORRESPONDENCE
COMMAND SUCCESS
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/
/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
is provided (507-512). Since these error replies
"asynchronously" sent, and thus could cause some confusion if
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
(Oct. 16, 1972)
RFC 407 NIC 12112
TYPICAL RJE
TIP USER WANTING HOT CARD READER TO
1. TIP user opens TELNET connection to HOSTX socket 5
2. Commands sent over TELNET to
USER=
PASS=
OUT=H70002
INPUT=H50003
3. RJE-server connects to the TIP's device 5 and
reading. When end-of-job card is recognized, the job
queued to run. The connection to the card reader is
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
NVT stream
5. Continue at any time with another deck at step 3.
TIP WITH JOB-AT-A-TIME CARD
1. thru 4) the same but User closes Reader after the
2. The output finishes and the printer connection closes
3. INPUT may be typed any time after step 3 finishes
another job will be entered starting at 3.
19
REMOTE Job Entry
(Oct. 16, 1972)
RFC 407 NIC 12112
HOSTA USER RUNS JOB AT HOSTC, INPUT FROM
1. User TELNET connects to HOSTC socket 5 for
USER=
PASS=
OUTUSER=roundab
OUT=:E/.
OUT puncher = (S)HOSTB:NE/my.
INUSER=
INPASS=x.x.
INPUT=HOSTB:E/my.
2. The RJE-server has FTP retrieve the input from HOSTB
User-id of "rounder" and Password of "x.x.x" for file
"my.jobinput".
3. The job finishes. RJE-server uses FTP to send two files
the print output is sent to HOSTA in EBCDIC with
carriage control to file ".sysprinter" while the file
as "puncher" is sent to HOSTB in EBCDIC
carriage-control to file "my.savepunch".
4. when the outputs finish, RJE-server at HOSTC discards
print file but retains the "puncher" file
5. The User who has signed out after job submission has
his output and checked his file "my.savepunch" at HOSTB.
deletes the saved copy at HOSTC by re-calling RJE at HOSTC
USER=
PASS=
ABORT job 123
CHANGE job 123 puncher = (D
20
if you see any problems within the linking, don't worry be happy,
this is version 0.1 of the Relevance System and you gotta expect some crappy subroutines sometimes,
just be content we did not write this in Java, which would have made this "bigger and better" HAHAHHA.
RFC documents can be found at I.E.T.F.
Relevance System Copyright © 2002 Spectrum WorldResearch
other technical nosh by ServerMasters Corporation
collaboration of BobX
