Port 72: NETRJS-2 — The Second Channel of Remote Job Entry

Port 72 is assigned to NETRJS-2, the second channel of the Network Remote Job Service protocol. It is one of four consecutive ports (71 through 74) that together simulated a remote batch terminal on the ARPANET, letting users across the network submit jobs to UCLA's IBM 360/91 supercomputer as if they were standing next to it, feeding it punch cards.¹

Nobody uses NETRJS anymore. The protocol is a fossil. But it's a fascinating one, because it shows you what "cloud computing" looked like in 1971: four network ports, a virtual card reader, and a queue.

What NETRJS Did

In the early 1970s, most serious computing meant batch processing. You wrote your program, punched it onto cards (or typed it into a terminal that simulated cards), submitted it to the mainframe, and waited. The mainframe ran your job when it got around to it, then printed the results.

NETRJS took this model and stretched it across the ARPANET. A user at a remote host would run a NETRJS client that simulated a "Virtual Remote Batch Terminal," or VRBT. The VRBT pretended to be a physical card reader, line printer, and operator console, all connected to UCLA's RJS (Remote Job Service) subsystem.²

The protocol needed multiple simultaneous connections to pull this off:

• An operator console for commands and status messages
• A card reader channel for submitting jobs
• A printer channel for receiving output
• A punch channel for receiving binary data

Ports 71 through 74 handled these channels. Each port corresponded to a different piece of the virtual terminal. Port 72, specifically, was the second of these channels.³

The Four-Port Block

IANA lists all four ports identically as "Remote Job Service":

In the original NETRJS specification (RFC 740), the Initial Connection Protocol used odd-numbered sockets (71, 73, 75) to select the character set: EBCDIC, ASCII-68, or ASCII-63. Once connected, derived even-numbered sockets handled the data channels. The IANA assignments for ports 71-74 reflect the consolidation of these channel assignments into the modern port numbering system.¹

Bob Braden and the IBM 360/91

NETRJS was created by Robert T. "Bob" Braden at UCLA's Campus Computing Network. Braden had the job of connecting UCLA's IBM 360/91 supercomputer to the ARPANET beginning in 1970. The 360/91 was a batch processing machine, tuned for long-running compute jobs. It didn't speak network protocols. Braden had to build the bridge.⁴

He published the first NETRJS specification as RFC 88 in January 1971, just over a year after the first ARPANET message traveled from UCLA to SRI.⁵ The protocol went through several revisions: RFC 189, RFC 599, and finally RFC 740 in November 1977, which remains the definitive specification.²

Braden went on to help develop TCP/IP, contributed to the design of FTP, and served on the Internet Architecture Board for 13 years. He received the Internet Society's Postel Award in 2006. When he died in 2018, he left behind a legacy woven into the foundations of the Internet itself.⁴

Why Four Ports for One Service?

This seems excessive by modern standards. Today, a single port handles multiplexed connections carrying arbitrary data. HTTP/2 runs dozens of concurrent streams over one TCP connection on port 443.

But in 1971, the network was different. The ARPANET's Host-to-Host protocol didn't have the multiplexing capabilities we take for granted. If you needed separate channels for separate functions, you used separate ports. A card reader stream and a printer stream had fundamentally different data flows, different character encodings, different error handling needs. Giving each its own port was the natural, correct design for that era.

Ports 71-74 are a snapshot of a time when network resources were precious enough that each channel was given its own dedicated door.

Security Considerations

NETRJS has no security to speak of. The protocol predates any concept of network encryption, authentication tokens, or access control at the transport layer. Users signed on to RJS with a username, transmitted in cleartext.

This is not a concern in practice. No modern system runs NETRJS. If you find something listening on port 72, it is not a Remote Job Service. It is something else entirely, and you should investigate immediately.

How to Check What's Listening on Port 72

Linux:

sudo ss -tlnp | grep :72
sudo lsof -i :72

macOS:

sudo lsof -i :72

Windows:

netstat -ano | findstr :72

On a modern system, port 72 should be silent. If something answers, find out what it is.