From 4bfd864f10b68b71482b35c818559068ef8d5797 Mon Sep 17 00:00:00 2001 From: Thomas Voss Date: Wed, 27 Nov 2024 20:54:24 +0100 Subject: doc: Add RFC documents --- doc/rfc/rfc407.txt | 1214 ++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 1214 insertions(+) create mode 100644 doc/rfc/rfc407.txt (limited to 'doc/rfc/rfc407.txt') diff --git a/doc/rfc/rfc407.txt b/doc/rfc/rfc407.txt new file mode 100644 index 0000000..3fa2aeb --- /dev/null +++ b/doc/rfc/rfc407.txt @@ -0,0 +1,1214 @@ + (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: ::= | ; + thus, a sequence of SPACES is also permissible in place of + , 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 = + + 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 = + + 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 = + INPASS = + + 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 = + INPUT = + INPUT + + NOTE: The following syntax will be used for output as well. + + ::= | + ::= , | + + no part implies the User-site host + ::= + ::= + + + + 6 + + REMOTE Job Entry Protocol + (Oct. 16, 1972) + RFC 407 NIC 12112 + + + ::= D | O | + H + ::= / + ::= | : + ::= | T | A | N + 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) + ::= | E + specifies NVT ASCII code + E specifies EBCDIC + ::= + + The syntax is the general RJE mechanism for + specifying a particular file source or destination for input or + output. If the form is used then direct transfer + will be made by the RJE-Server to the named socket using the + specified . If the 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 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 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 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 = + OUTPASS = + + 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 = + + ::= | + implies the primary print file of the job + ::= + ::= | (H) | (S)|(D) + 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. + + ::= (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 = + + This command changes the output disposition supplied with the + job at submission. The 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 + + + + ::= 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 + + ::= | + implies 1 where defined + ::= @ | + ::= (same as for OUT command) + ::= (same as for INPUT command) + ::= (same as for INPUT command) + ::= + + ::= + + + + 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 was + Transmit-and-discard or will Hold the file for further User + control if the 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 @ form of 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 + + 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 + ALTER + + 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 = + NET OUTPASS = + NET OUT = + NET OP + + 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 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 and + options supplied by the User: + + I/O 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 + 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 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 (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 = (S) file should be Held; and a = + 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 accepted for processing + 261 Job completed, awaiting output transfer + 262 Job Cancelled as requested + 263 Job Altered as requested to state + 264 Job , 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 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 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 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 last command line completely unrecognized + 508 Job syntax of the last command is incorrect + 509 Job last command incomplete, parameters missing + 510 Job last command invalid, illegal parameter + combination + 511 Job last command invalid, action impossible at + this time + 512 Job 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 -- cgit v1.2.3