diff options
Diffstat (limited to 'doc/rfc/rfc360.txt')
| -rw-r--r-- | doc/rfc/rfc360.txt | 1011 |
1 files changed, 1011 insertions, 0 deletions
diff --git a/doc/rfc/rfc360.txt b/doc/rfc/rfc360.txt new file mode 100644 index 0000000..f4586dc --- /dev/null +++ b/doc/rfc/rfc360.txt @@ -0,0 +1,1011 @@ + + + + + + +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] + +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] + +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] + +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] + +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] + +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] + +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] + +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] + +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] + +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] + +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] + +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] + +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] + +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] + +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] + +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] + +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] + +RFC 360 REMOTE JOB ENTRY June 1972 + + + PASS=aaabbbcc + ABORT job123 puncher + or by + CHANGE job123 puncher = (D) + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Holland [Page 18] + |