Port 71: NETRJS — The First Channel to a Supercomputer

Port 71 is assigned to NETRJS-1, the first channel of the Remote Job Service protocol. It was one of the earliest application-layer protocols on the ARPANET, designed to let users at remote sites submit batch computing jobs to UCLA's IBM 360/91 supercomputer over the network.

If you have never heard of it, that is because the world it was built for no longer exists. But the world we live in was built on top of it.

What NETRJS Did

NETRJS (Network Remote Job Service) simulated a physical remote batch terminal over a network connection.¹ In the early 1970s, submitting a computing job meant physically carrying a stack of punch cards to a computer center, feeding them into a card reader, and waiting for the line printer to spit out your results. NETRJS made that process work across the ARPANET.

A user at a remote host would connect to port 71 and establish what the protocol called a "Virtual Remote Batch Terminal," or VRBT. This virtual terminal had virtual card readers, virtual line printers, and virtual card punches. The user would submit a stream of card images comprising one or more batch jobs, complete with IBM's Job Control Language (JCL), and the results would come back as printed output or punched card data.²

Port 71 was specifically the EBCDIC channel. Port 73 handled ASCII-68, and port 75 handled ASCII-63, reflecting the character encoding wars of the era.²

How the Protocol Worked

NETRJS used five separate network channels between each remote site and UCLA's Campus Computing Network (CCN):¹

1. Operator Input — Commands entered by the remote operator
2. Operator Output — Messages from the system back to the operator
3. Input Stream — A simulated card reader for job submission
4. Printer Stream — A simulated line printer for output
5. Punch Stream — A simulated card punch for binary data

Data traveled in variable-length blocks of up to 900 bytes (operator channels were limited to 130 bytes). The protocol included its own data compression, replacing repeated blanks and characters with repeat counts, which mattered when your line printer output was mostly whitespace.²

Connecting to port 71 initiated the operator console channels. From there, the user could open the additional channels for actual job submission and output retrieval. Users could even submit jobs, disconnect, and come back later to pick up their results.¹

The Story Behind Port 71

In January 1971, Robert Braden and Stephen Wolfe at UCLA's Campus Computing Network published RFC 88, defining NETRJS.¹ Braden had been given the job of connecting UCLA's IBM 360/91 to the ARPANET beginning in 1970, making it one of the first supercomputers accessible over a packet-switched network.³

The machine itself was extraordinary. UCLA's 360/91KK had 4 million bytes of main memory, one of only two Model 91s with that configuration (the other belonged to a classified facility in the Washington, D.C. area).⁴ It ran at roughly 3 million instructions per second. By the standards of 1971, this was among the most powerful computers on the planet.

The problem Braden faced was practical: the ARPANET connected a handful of research sites across the country, and many of them needed access to serious computing power. UCLA had the machine. The network existed. But there was no protocol for saying "here is a job, run it, send me back the output." NETRJS was that protocol.

Braden would go on to become one of the architects of TCP/IP, writing one of the five original experimental implementations in the late 1970s.³ But NETRJS came first — a protocol for a world where computing was something that happened somewhere else, and the network's job was to carry your work there and bring the results back.

The Character Encoding Problem

One detail reveals how different that era was: NETRJS defaulted to EBCDIC, IBM's proprietary character encoding, because the host was an IBM mainframe.² The protocol had to offer three separate ports for three different character encodings. In 1972, Braden published RFC 338 specifically to address the EBCDIC/ASCII mapping problem for network remote job entry.⁵

Today we take UTF-8 for granted. In 1971, the question of how to represent a letter "A" when two computers disagreed on what number "A" was — that was a real engineering problem that required its own RFC.

Port 71 Today

No modern system runs NETRJS. The protocol is entirely historical. Port 71 should be closed on any production system, and traffic on this port in the wild would be anomalous enough to warrant investigation.

If you want to check whether anything is listening on port 71:

# macOS/Linux
sudo lsof -i :71

# Or with netstat
sudo netstat -tlnp | grep :71

# Or with ss
sudo ss -tlnp | grep :71

# Windows
netstat -an | findstr :71

If something responds, it is not NETRJS. Investigate it.

The Significance of Port 71

Port 71 belongs to the well-known port range (0–1023), reserved by IANA for established services. Ports 71 through 74 were allocated as a block for NETRJS channels, reflecting a protocol design where a single service used multiple ports for different data streams — a pattern that later protocols like FTP (ports 20 and 21) would also follow, but that largely fell out of favor as protocol design matured.⁶

NETRJS matters not because anyone uses it, but because it represents one of the first answers to a question the Internet is still answering: how do you let someone use a computer that is far away? Remote job entry became remote login (Telnet, SSH). Remote login became remote procedure calls. Remote procedure calls became APIs. APIs became cloud computing.

Port 71 is where that lineage begins. A graduate student in Boston submitting a stack of virtual punch cards to a supercomputer in Los Angeles, over a network that connected fifteen sites, using a protocol written in the same month that Apollo 14 landed on the Moon.