Port 5: RJE — The Waiting Room of the Early Internet

What Port 5 Does

Port 5 is assigned to the Remote Job Entry protocol. RJE is the mechanism by which a user at one location submits a batch-processing job to a mainframe at another location, then receives the output when the job is finished.¹

In practice, this meant something specific: you sat at a terminal, connected to port 5 on a remote host, told the machine where to find your job input file (your stack of virtual punch cards), and the machine would retrieve your job, run it, and send the results back to wherever you specified. You submitted your work and you waited. That was the entire interaction.

No one connects to port 5 anymore. The protocol is historic, the mainframes it served have been decommissioned, and batch job submission now happens through entirely different mechanisms. But what port 5 invented while it was alive changed the shape of every protocol that came after it.

How It Worked

RJE was elegant in its layering. It did not try to do everything itself. Instead, it composed itself from two protocols that already existed on the ARPANET: Telnet and FTP.¹

The control channel was a Telnet connection to socket 5 on the server host. Through this channel, the user issued commands in plain ASCII text: USER and PASS to authenticate, INPUT to specify the job file, OUT to specify where output should go, STATUS to check on a running job, CANCEL to kill one.¹

The actual file transfers happened over FTP. When the server needed to retrieve your job input, it opened an FTP connection to fetch the file. When your job finished and produced output, the server opened another FTP connection to deliver the results. Each file got its own FTP connection, opened and closed for the purpose.¹

This separation was the key architectural insight. The control conversation happened on one persistent connection. The data moved on separate, ephemeral connections. This pattern, a persistent control channel paired with transient data channels, would reappear throughout networking history.

The "Hot Card Reader"

RFC 407 describes a mode of operation it calls a "hot card reader." You could keep your Telnet connection to port 5 open, continuously feeding jobs to the server, with the connection serving as a "job monitor." Output would stream back as each job completed, as if you had a physical card reader and printer wired directly to the mainframe. The network became invisible. The distance collapsed.¹

This was the promise of the ARPANET distilled to its simplest form: your terminal in one city, the computer in another, and the wire between them feeling like nothing at all.

The History

Before the Protocol

Before RJE had a standard protocol, submitting a batch job to a computer meant being physically present. You wrote your program on a keypunch machine, producing a deck of Hollerith punch cards. You carried that deck to a window in the computer room. You handed it to an operator. You left. Hours later, sometimes the next day, you came back to pick up your printout.

If your program had a bug, a single mistyped character, a 1 where there should have been an I, you repeated the entire process. Programmers at peak-usage installations would stay past midnight, hoping for faster turnaround when the lines were shorter.²

The IBM System/360, released in 1964, began to change this. Remote job entry hardware let card readers and line printers be installed at a distance from the mainframe, connected by telephone lines.³ But every vendor had its own protocol. IBM had HASP multileaving. Other manufacturers had their own schemes. There was no standard.

The ARPANET Changes Everything

When the ARPANET came online in 1969, one of its first three services (alongside Telnet and FTP) was remote job entry.⁴ In January 1971, Bob Braden and Steve Wolfe at UCLA published RFC 88, defining NETRJS, a protocol for submitting batch jobs to UCLA's IBM 360 Model 91 over the network.⁵ Soon after, RJE systems went live at UCLA and UC Santa Barbara.

But NETRJS was specific to UCLA. It spoke EBCDIC because the IBM 360 spoke EBCDIC. It used its own socket numbers (71, 73, and 75). It was a local solution to a universal problem.

The MIT Workshop

In April 1972, about twenty people gathered on the eighth floor of MIT Project MAC at 545 Technology Square in Cambridge for the Data and File Transfer Workshop.⁶ The workshop was organized by Abhay Bhushan, with attendees including Steve Crocker from ARPA and Bob Braden from UCLA. Their goal was to unify the ARPANET's data transfer conventions.

On the second day, a breakout group made a decision that would ripple forward for half a century: they would standardize error messages across RJE and FTP, even though those two protocols had not been designed to speak to each other.⁷

The Birth of the Three-Digit Code

Chuck Holland of UC San Diego wrote the first formal RJE specification, RFC 360, published June 24, 1972.⁸ Four months later, Robert Bressler and Richard Guida of MIT, along with Alex McKenzie of BBN, published the definitive version as RFC 407.¹

RFC 407 defined something that looked simple but turned out to be permanent: a reply code system. Every response from the server would be "a leading 3-digit numeric code followed by a blank followed by a text explanation of the message."¹

The first digit told you the category:

The specification noted that "the numeric codes are assigned by groups for future expansion to hopefully cover other protocols besides RJE."¹ It covered other protocols. It covered all of them.

The Inheritance

Two weeks after RJE's reply codes were published, the revised FTP specification (RFC 354) adopted the same three-digit scheme, explicitly noting that its codes were "assigned by groups and for ease of interpretation by programs in a manner consistent with other protocols such as the RJE protocol."⁹

FTP carried these codes for two decades. Then, in the early 1990s, Tim Berners-Lee and the HTTP working group needed a status code system for the World Wide Web. They were familiar with FTP. They borrowed its structure.⁷

And so the chain completes: RJE to FTP to HTTP. The "200 OK" that your browser receives billions of times a day is a direct descendant of the reply code system defined for port 5 in 1972. The "404 Not Found" that has entered common language in dozens of countries traces its lineage to a protocol for submitting punch card jobs to distant mainframes.⁷

Twenty people in a room at MIT. A weekend decision to standardize error messages. And now "404" is a word.

The Authors

Alex McKenzie worked at BBN from 1967 to 1996. BBN built the ARPANET's Interface Message Processors, the machines that made the network physically function. McKenzie was given the job of understanding how the ARPANET worked and explaining it to everyone else. He later managed BBN's Network Control Center, balancing the expectations of researchers who wanted to experiment with users who expected the network to work like a utility. He went on to chair the International Network Working Group from 1979 to 1982.¹⁰

Robert Bressler and Richard Guida worked at MIT's Dynamic Modeling/Computer Graphics group (MIT-DMCG), part of the same ecosystem that produced many of the ARPANET's foundational protocols.¹

Security Considerations

RJE was designed for an era when the ARPANET connected a small number of trusted institutions. Its security model reflects that trust.

Authentication consists of a USER and PASS command sent in plaintext over the Telnet control channel. The specification notes that these credentials identify the submitter of the command stream but do not necessarily match the credentials used for file transfer or job execution.¹ There is no encryption, no session tokens, no challenge-response mechanism.

This is not a criticism. In 1972, the ARPANET had fewer than 30 hosts, all at universities and government research labs. The idea that untrusted parties might intercept traffic was not yet a practical concern. Security on the early ARPANET was social, not technical.

Port 5 should not be open on any modern system. If you find something listening on port 5, it is not RJE.

Related Ports