RFC 407

Remote Job Entry Protocol

📅 published October 1972, from ietf

RFC 407: REMOTE JOB ENTRY PROTOCOL 💖

Date: Oct. 16, 1972 🗓️ RFC: 407 · NIC: 12112 🎀 Authors: Robert Bressler (MIT-DMCG), Richard Guida (MIT-DMCG), Alex McKenzie (BBN-NET) 🫶 Obsoletes: RFC 360 🍓

Okay bestie, this is the one where the MIT and BBN crew wrote down how you ask a faraway computer to run your batch job and send the results back to you. It literally replaces RFC 360, so this is the new canon ✨

INTRODUCTION 🎀

Okay so remote job entry is when a user in one place makes a batch-processing job run somewhere else. This protocol spells out the standard Network procedures for that user to talk to a remote batch-processing server over the Network. The server then grabs a job-input file, processes the job, and delivers the job's output file(s) to a remote location. It's giving full remote control 💅

Here's the setup 🧚 The protocol uses a TELNET connection for all the control chatter between the user and the server's RJE processes. That connection goes to a special standardized logger, not socket 1, so don't go poking at the wrong socket 😭 The server side then uses the File Transfer Protocol to pull the job-input file and push the output file(s) back.

There are two kinds of users, and both are iconic 👑 The first is the direct user, a real person at an interactive terminal attached to a TIP or any host. A direct user can make input and/or output move over a specific socket at a specified host (think card readers or printers on a TIP), or can have files transferred by file-id using File Transfer Protocol. The second is the RJE User-process, which lives in one remote host and talks to the RJE Server-process in another host. This one gets its instructions from a human user, just through some unspecified indirect means 🦋 The command and response streams are designed so that both the human user and the user process can easily use and understand them. Two audiences, one protocol, no cap 🌈

Lowkey the TELNET control connection can be handled two ways. A site can open a fresh connection for each logical job, or it can keep the connection open for a long time 🌸 If it stays open, several job-files can be told to get retrieved. Alternatively, and only for servers that can figure out where one logical job ends by reading the input stream and split one input file into several jobs, one continuous retrieval can happen, like a TIP card reader. That makes a "hot" card reader for a particular server, with the TELNET connection acting as a "job monitor" 🔥 Output always goes over per connection to the output socket one job at a time, so output from the "hot" reader shows up when it's ready, just like a "hot" printer.

For more complex hosts there's another move. You can attach an RJE User-process to a card reader and let it take instructions from a lead control card. That opens an RJE control TELNET to the right host, with the right log-on and input retrieval commands. To the human user, this card reader looks like a Network "hot" card reader 💜 The details of that RJE User-process are outside the scope of this protocol, so we're leaving that one for another day 🙈

GENERAL SPECIFICATIONS ⭐

User

A human user at a real terminal, or a process that supplies the command control stream that gets a job submitted remotely, is called the User 🫶 How a process user gets its instructions is outside the scope of this protocol.

User TELNET

The User sends commands over the Network in Network Virtual Terminal code, through a User TELNET process on the User's Host. This User TELNET process starts its activity with ICP to the standard "RJE Logger" socket (socket 5) on the desired RJE-server Host ✨

RJE-Server TELNET

The RJE-server process gets 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 it also has to cause the appropriate ICP socket shifting 🧚

TELNET Connection

The command and response streams for the RJE mechanism run over a TELNET-like connection to a special socket. Its full specifications follow the current NWG TELNET protocol 🎀

RJE-Server

The RJE-Server process lives in the Host that provides Remote Batch Job Entry service. It's the main character 👑 It 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 they're available.

User FTP

All input and output files get transferred under the control of the RJE-server process, at its own initiative 💅 Files can be transferred directly through a Request-for-connection to a specific Host/socket, or they can be transferred via File Transfer Protocol. If it's the latter, the RJE-server works through its local User FTP process to make the transfer happen. That process starts its activity with an active Request-for-connection to the "FTP Logger" on the foreign host 🦋

Server FTP

This process runs on a remote host (remote from the RJE-server). It listens for an ICP from the User FTP, then acts on the commands from the User FTP to make the appropriate file transfer happen 🌸

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. The commands specify the user's identity (log-on), the source of the job input file, the disposition of the job's output files, enquiries about job status, and changes to job status or output disposition. Additional commands that affect output disposition can be included in the job input file 🌈 This command language gets explicitly specified in a following section of this protocol.

RJE Command Replies

Every command the User sends over TELNET calls for a response message from the RJE-server back to the User over the TELNET connection. Certain other conditions need a response message too 🫶 These messages are formatted in a standardized way, so they're easy to read for both human Users and user processes. A following section of this protocol specifies the response messages.

RJE COMMANDS OVER TELNET CONNECTION 🌟

GENERAL CONVENTIONS

  1. Each command goes in one input line, ended by the standard TELNET "crlf". The line can be any length the user wants. It isn't restricted to a physical terminal line width 🔥 The characters "cr" and "lf" get ignored by the RJE-server, except when they appear in the exact order "crlf". They can be used however needed for local terminal control.
  2. Every command starts with a recognized command name. It may then contain recognized syntactic element strings and free-form variable strings (for user-id, file-ids, etc.). Recognized words are 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 mark. Other blanks can be used freely before or after any syntactic element. Here "blank" means ASCII SPACE (octal 040). Formally: <blank>::= <blank><ASCII SPACE> | <ASCII SPACE>. So a sequence of SPACES is also allowed in place of a <blank>, even though there's no syntactic need for more than one 💅 The "=" after the command name is optional in all commands except OUT and CHANGE.
  3. Recognized alphanumeric strings can mix upper and lower case letters in any combination, with no syntactic difference between them ✨ Unrecognizable strings are used exactly as presented, with full differentiation of upper and lower case input, unless the host that finally uses the string defines it otherwise.
  4. There are two types of unrecognizable strings: final and imbedded. Final strings appear as the last syntactic element of a command. They're parsed as starting at the next non-blank character of the input stream and running through 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. For now these fields are left undelimited, since they only need to be recognizable by the server host, which hopefully can recognize its own job-ids and file-names 🙈

SYNTAX

The command descriptions below are given in a BNF syntax 🎀 Names inside angle brackets are non-terminal syntactic elements, which get expanded in the equations that follow. Each equation has the defined name on the left of the ::=, plus a set of alternative definitions on the right, separated by vertical lines "|" 🦋

REINITIALIZE

REINIT

This command puts the user into a state identical to the one right after a successful connection to the RJE-server, before any commands were sent over the TELNET connection 💜 The effective action is an ABORT, plus a flushing of all INPUT, OUTPUT and ID information. The user is still responsible for any usage charges incurred before their REINIT command. The TELNET connection isn't affected in any way ✨

USER

User = <user-id>

This command must be the first command over a new TELNET connection. As such, it starts 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).

The User can send another USER command at any time to change Users. Further input is then charged to the new user. A server may refuse to honor a new user command if it isn't able to process it in its current state (during an input file transfer, for example). Even so, the protocol permits the USER command at any time without altering previous activity 🌸 An incorrect subsequent USER command, or its following PASS command, is to be ignored with an error response, which leaves the original User logged-in.

It's permissible for a server to close the TELNET connection if the initial USER/PASS commands aren't completed within a server-specified time period 🔥 It's not required or implied that the "logged-on" User's user-id be the one used for file transfer or job execution. The user-id only identifies the submitter of the command stream. Servers establish their own rules relating the user-id to 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 one's the PASS command, the last piece of the log-on handshake 🔐✨ It comes right after USER, and even if a Server doesn't ask for a password, it still has to accept PASS (and it's allowed to ignore it), then reply "log-on ok" once you're in 💖

BYE

BYE

okay so BYE ends your USER session and tells the RJE server to close the TELNET connection 👋 If no input transfer is happening, the connection can close right away. If input is in progress, it should stay open long enough for the result response, and then close 🌸 While that's happening, the only thing you can send is a new USER command. Nothing else 🙈

⚠️ If the TELNET connection closes unexpectedly, the server acts as if it got an ABORT and a BYE. Lowkey dramatic, but that's the rule 💀

INID/INPASS

INID = <user-id>
INPASS = <password>

These are the user-id and password that get sent in the File Transfer request to pull down your input file 🎀 The server doesn't use them for anything else. If you don't send this command at all, the USER/PASS values get used instead 💅

INPATH/INPUT

INPATH = <file-id>
INPUT = <file-id>
INPUT

Note: the same syntax gets used for output too 👀

<file-id>::= <host-socket> | <host-file>
<host-socket>::= <host>,<socket><attributes> |
                 <socket><attributes>
<host>::= <integer>
<socket>::= <integer>
<integer>::= D<decimal-integer> | O<octal-integer> |
             H<hexadecimal-integer>
<host-file>::= <host><attributes>/<pathname>
<attributes>::= <empty> | :<transmission><code>
<transmission>::= <empty> | T | A | N
<code>::= <empty> | E
<pathname>::= <any string recognized by the FTP Server at
              the site of the file>

If there's no <host> part, it means the User-site host 🏠

The <transmission> options work like this:

  • <empty> means the default, which is N for input files and A for output files 🌷
  • T is TELNET-like coding, with embedded "crlf" for new-line and "ff" for new-page 📄
  • N is FTP blocked transfer with record marks, but no other carriage-control 🧚
  • A is FTP blocked records with ASA carriage-control (column 1 of the image is forms control) 🦋

And the <code> options:

  • <empty> means NVT ASCII code 💜
  • E means EBCDIC 🌈

<file-id> is the general RJE way of naming where a file comes from or goes to, for input or output 🎯 If you use the <host-socket> form, the RJE-Server transfers directly to the named socket using your <attributes>. If you use the <host-file> form, the RJE-server calls on its own local FTP-user process to do the actual transfer 🚀 In this mode the data stream is either TELNET-like ASCII or blocked records (which can use column 1 for ASA carriage-control). A mode is allowed on input (column 1 gets deleted), but the usual mode is the default N 🙌 On output, the first character of each record is the carriage-control ("blank" = single-space, "1" = new-page, etc.). The optional N mode transfers only the data, like sending to a card punch or something similar 🃏

The <pathname> is an arbitrary string that the RJE-server saves and sends back over FTP to the FTP-server so it can retrieve or store the right files 📂

INPATH or INPUT commands first store the <file-id> if you give one, and then the INPUT command starts the input 🏁 INPATH can set a file-id for later, and a plain INPUT with no file-id will start input using a file-id you set before. An INPUT "crlf" command with no previous <file-id> specified is illegal 🚫

ABORT

ABORT

This one stops any input retrieval that's going on, throws away records that already came in, and closes the retrieval connection 🛑 Heads up: ABORT with parameters is actually an Output Transmission control (more on that below) 👀

OUTUSER/OUTPASS

OUTUSER = <user-id>
OUTPASS = <password>

These are the user-id and password that get sent in the File Transfer request to send your output file(s) 📤 The server doesn't use them for anything else. If you don't send this command, the USER/PASS values get used instead 💖

OUT

OUT <out-file> = <disp>

<out-file>::= <empty> | <job-file-id>
<job-file-id>::= <string representing a specific output file
                 from the job as recognized by the Server>
<disp>::= <empty><file-id> | (H) | (S)<file-id>|(D)
<file-id>::= (same as for INPUT command)

Note: the parentheses are part of the elements above ✨

<out-file> can be empty, which means the primary print file of the job. Otherwise it's a <job-file-id>, a string the Server recognizes as one specific output file from the job 🖨️

The <disp> options are:

  • <empty><file-id> means transmit, then discard 📨
  • (H) means Hold-only, don't transmit 🫸
  • (S)<file-id> means transmit and save 💾
  • (D) means discard without transmitting 🗑️

This command sets what happens to the output file(s) from the job. Anything you don't specify is Hold-only by default 🌸 OUTUSER, OUTPASS, and OUT all have to come before the INPUT command to work. They'll affect any jobs you submit after that over this RJE-TELNET connection. A particular job can override them with NET control cards at the front of its input file 🎀

Once the output disposition is set, either by this OUT command or a NET OUT card, the job keeps that info until final output disposition, and the CHANGE command can still modify it 🔁

Sometimes the server finds that the output's destination is "busy" (meaning an RFC to either Server-FTP or the specified socket got refused), or that the host that should get the output is dead 😵 When that happens, the server should wait several minutes and then try transmitting again ⏳

OUTPUT RE-ROUTE

CHANGE <job-id><blank><out-file> = <disp>

CHANGE swaps out the output disposition that was given when the job was submitted 🔄 The server recognizes the <job-id> and may check that you're allowed to modify that job 🕵️‍♀️ After the job is identified, the rest has the same syntax and meaning as the original OUT command. You can use CHANGE on a job-file-id that wasn't mentioned at submission time, and it works the same as an original OUT command 🦋

OUTPUT CONTROLS DURING TRANSMISSION

<command><blank><count><blank><what>

<command>::= RESTART | RECOVER | BACK | SKIP |
             ABORT | HOLD
<count>::= <empty> | <integer>
<what>::= @<file-id> | <job-id><job-file-id>
<disp>::= (same as for OUT command)
<file-id>::= (same as for INPUT command)
<integer>::= (same as for INPUT 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>

Here's what each command does:

  • RESTART restarts the transmission (new RFC, etc.) 🔁
  • RECOVER restarts transmission from the last FTP Restart-marker-reply (see FTP) 🩹
  • BACK backs up the output "count" blocks ⏪
  • SKIP skips the output forward "count" blocks ⏩
  • ABORT aborts the output and discards it 💀
  • HOLD aborts the output but holds it 🤚

<count> can be empty, and an empty count means 1 wherever it's defined 🔢

These commands change output that's being transmitted right now, or output that got aborted recently 🎬 If transmission gets cut off before it finishes, the RJE-server will either try to resend the whole file (if its <disp> was transmit-and-discard), or hold the file for more User control (if the <disp> was (S), transmit-and-save) 😤 During transmission, during the save part of a transmit-and-save, or for a Hold-only file, these commands can control things. The @<file-id> form of <what> only works if transmission is actually in progress 🙏

If the file's state doesn't match the command, the command is illegal and gets ignored, with a reply 🙅‍♀️

STATUS

STATUS <job-id>
STATUS <job-id><blank><job-file-id>

These ask for the status of the RJE-server, a particular job, or the transmission of an output or input file, respectively 📊 What's in the Status reply depends on the site 🤷‍♀️

CANCEL/ALTER

CANCEL <job-id>
ALTER <job-id><blank><site dependent options>

These change the course of a job you already submitted 🛤️ CANCEL means the job gets terminated right away and any output gets discarded 💥 ALTER handles system-dependent options, like changing job priority, process limits, "Teminate without Cancel", etc. ⚡

OP

OP (any string)

The string you give gets shown to the Server site operator whenever a job after this one is started from the Server's batch queue 📢 This usually shows up in the input file as a NET OP control card, but it can also be a TELNET command. To cancel it for all jobs, send an OP "crlf" command with no text 🫧

RJE CONTROL CARDS IN THE INPUT FILE

Some RJE commands can be given as control cards at the front of the input file 🗂️ When these show up, they take precedence over the same command sent through the RJE-TELNET connection, and they only affect this one job 💅 All the RJE control cards have to be the first records of the job's input file. They all have the control word NET in columns 1 through 3. Scanning for these controls stops when the first card without NET in col 1-3 shows up 🛑

Each control command goes in its own record and ends at the end-of-record (usually an 80 column card-image) 📇 To keep going onto the next record, put NET+ in columns 1-4 of that next record. Column 5 of the next record picks up right where the last character of the previous record ended 🧵

NET OUTUSER = <user-id>
NET OUTPASS = <password>
NET OUT <out-file> = <disp>
NET OP <any string>

Check the matching TELNET command for the details 🔍 One thing the NET OUTUSER and NET OUT controls can do that the TELNET connection can't is give different OUTUSERs for different OUTs. The TELNET connection only stores and supplies one initial OUTUSER, but the controls can change the OUTUSER before each OUT control comes up 🌟

RJE USE OF FILE TRANSFER PROTOCOL 📂✨

okay so, most files that aren't TIP files get moved to or from the RJE-server through the FTP process 🦋 the RJE-server calls its local FTP-user and gives it the Host, File-pathname, User-id, Password, and Mode for the transfer. then the FTP-user connects to its FTP-server counterpart on that host and sets up a transfer path 🔥 data then flows through the RJE-FTP interface in the Server, across the Network, to or from the foreign FTP-server, and finally to or from the File-pathname in the foreign host's file storage space 💖 for output files, the file-pathname might get read by the foreign host as instructions to send it to a printer, or the file might just get stored 🖨️ a User-RJE-process can also supply an output <file-id> by default, and its own Server-FTP will recognize that as routing to a printer 🎀

bestie, a lot of the RJE-Server/User-FTP interface is going to depend on the site 🌸 but there are several FTP options that RJE-Servers will use in a standard way 💅

  1. A new FTP connection gets opened for each file being transferred. The connection is opened with the User-id (OUTUSER or INUSER) and Password that the RJE User supplied 🔐
  2. The data bytesize is 8 bits 🧚
  3. The FTP Type, Structure, and Mode parameters are decided by the RJE transfer direction (I/O) and by the <transmission> and <code> options the User picked 🍓 here's the table, it's giving organized:
I/O   <TRANS>   <CODE>   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)
  1. The service commands are Retrieve for input and Append (with create) for output 💜 the FTP pathname is the <pathname> the RJE User supplied ✨
  2. On output in B form, the User-FTP at the RJE-Server site sends Restart-markers at periodic intervals (like every 100 lines, or so) and remembers the latest Restart-marker-reply for the file 🫶 if the file transfer doesn't finish and the <disp> is (S), the file gets held until the User steps in 🙈 the User can then use the RECOVER command to make FTP restart at the last remembered Restart-marker-reply 🔁
  3. The FTP Abort command handles the RJE ABORT and CANCEL commands 🛑
  4. For transfers where the FTP-MODE is defined as B, the user FTP may optionally try H mode 🌈

the specific form of the FTP commands an RJE-Server site uses, and the order it uses them in, aren't specified in this protocol 🤷‍♀️

errors from FTP come in three flavors 🚨: a) access errors or no storage space error; b) command format errors; and c) transfer failure errors. since the RJE-Server process creates the commands, an error is a programming problem 👩‍💻 it should be logged for attention, and the situation should be handled as safely as possible 🛡️

transmission failure or access failure on input causes 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 because the User might not be reachable 📵 a status response should be queued for them in case they happen to ask 📬 a <disp> = (S) file should be Held 🧊 and a <disp> = <empty> transmit-and-discard file should be held temporarily and then discarded if nobody claims it 🗑️ "temporarily" here means at least several days ⏳ since jobs that churn out huge output at great expense to the User deserve every chance to get their output back 💸 servers may choose, though, to charge the User for the file-storage space the held output takes up 🧾

REPLIES OVER THE TELNET CONNECTION 💬

every action the RJE-server takes, including each TELNET command entered, gets noted over the TELNET connection to the User 📣 these RJE-server replies are formatted so a Human or a Process can read them 🤖 each one is a leading 3-digit numeric code, then a blank, then a text explanation of the message 🎀 the numeric codes are assigned in groups so there's room to grow and cover other protocols besides RJE (like FTP) 🌱 the code is built to be easy for processes to read, and the three digits work like this 🔢

the first digit specifies the "type" of response:

  • 000 these "replies" are purely informative, and the Server issues them voluntarily to tell a User about some state of the server's system ℹ️
  • 100 replies to a specific status inquiry 🔍 they're both information and an acknowledgment of the status request
  • 200 positive acknowledgment of some earlier command or request ✅ the reply 200 is a generalized "ok" for commands that need no other comment, and other 2xx replies are specified for specific successful actions 🎉
  • 300 incomplete information supplied so far 🧩 no major problem, but activity can't go ahead with the input given
  • 400 unsuccessful reply 😿 a request was specified correctly but couldn't be completed correctly, and further attempts will need User commands
  • 500 incorrect or illegal command 🚫 the command or its parameters were invalid or incomplete from a syntax point of view, or the command doesn't match a previous command 🙅‍♀️ the command in question has been totally ignored
  • 600-900 reserved for expansion 🔮

the second digit specifies the general subject the response refers to:

  • x00-x29 general purpose replies, not assignable to other subjects 🧺
  • x30 primary access 🔑 these replies are about the attempt to "log-on" to a Server service (RJE, FTP, etc.)
  • x40 secondary access 🚪 the primary Server comments 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 isn't necessary for every variation of a reply to get a unique number, only that the basic meaning has one 🤖 the text of a reply can explain the specific reason for it to a human User 💕

each TELNET line from the Server (ended by "crlf") is meant to be a complete reply message 📝 if a reply's text needs to keep going onto the following lines, those continuation replies carry 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
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 <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>
264 Job <job-id>,<job-file-id> 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 <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 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 <job-id> 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 <job-id> last command line completely unrecognized
508 Job <job-id> syntax of the last command is incorrect
509 Job <job-id> last command incomplete, parameters missing
510 Job <job-id> last command invalid, illegal parameter
   combination
511 Job <job-id> last command invalid, action impossible at
   this time
512 Job <job-id> last command conflicts illegally with previous
   command(s)

SEQUENCING OF COMMANDS AND REPLIES ✨

okay so the User and Server are supposed to have an alternating dialogue, like a super organized group chat 💬. The User sends an RJE command, and the Server answers with a prompt primary reply. The User SHOULD wait for that first success-or-failure response before sending anything else. no double-texting the server 🙈

A second type of reply comes from the Server asynchronously, meaning whenever it feels like it, not in response to the User's commands. These replies report on how a job submission caused by the INPUT command is going, so they're secondary replies to that command. 🧚

The last class of Server "replies" is purely informational and MAY arrive at any time. These are listed below as spontaneous. bestie, the server just be sharing updates 💅

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). 🚨 this is the part where it gets messy, so the server has to say exactly which job is broken

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
  1. 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. 🃏✨
  2. 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. 🖨️
  3. 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. 💖

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
  1. 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". 📂
  2. 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". 🌈
  3. when the outputs finish, RJE-server at HOSTC discards the print file but retains the "puncher" file. 🗑️
  4. 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)

that's the whole RJE scenario tour, bestie! 🌈💅

📦 where this page comes from