Port 74: NETRJS-4 — The Last Channel of Remote Job Entry

Port 74 carries the designation NETRJS-4, the fourth channel of the Network Remote Job Service protocol. It is the last in a block of four ports (71 through 74) that together formed one of the ARPANET's earliest application-layer protocols, allowing researchers at distant universities to submit batch computing jobs to UCLA's IBM 360/91 supercomputer and receive their results back over the network.¹

You will almost certainly never see traffic on port 74 today. But the story of how it got its number is the story of how the Internet learned to do work.

What NETRJS Was

In the early 1970s, computing meant batch processing. You wrote your program, punched it onto cards, handed the deck to an operator, and waited. Sometimes hours. Sometimes overnight. The output came back on fan-fold paper from a line printer, or on more punched cards from a card punch.

NETRJS virtualized this entire process over the ARPANET.² Instead of physically walking your card deck to the computer room, you could submit jobs from any connected host on the network. Your terminal became a "Virtual Remote Batch Terminal," simulating the card reader, the printer, and the card punch across hundreds or thousands of miles of network.

The protocol needed separate channels for each virtual device. That's why it consumed four ports:

Port 74 specifically carried card punch output, the stream of data that would have been punched onto physical cards at the remote end. It was the last channel, the final device in the standard remote batch terminal configuration.³

The Machine at the Other End

The server that answered on ports 71 through 74 was UCLA's IBM System/360 Model 91, operated by the Campus Computing Network (CCN). This was not an ordinary computer. The Model 91 was IBM's most powerful machine, first delivered to NASA's Goddard Space Flight Center in 1968. It was the first IBM computer to support out-of-order instruction execution. It could execute up to 16.6 million instructions per second.⁴

Only 15 Model 91s were ever manufactured. UCLA's was one of only two in the world with 4 megabytes of main memory. The other belonged to a facility in the DC area whose identity was classified.

Resource usage on the machine was billed in "Machine Unit Seconds," abbreviated MUS, which the staff pronounced "Moose."

Bob Braden and the Protocol

NETRJS was created by Robert T. Braden and Steve Wolfe at UCLA's CCN. The first specification appeared as RFC 88 in January 1971.⁵ Braden was the engineer responsible for connecting the IBM 360/91 to the ARPANET, a task that began in 1970.

Braden's motivation was practical. UCLA had this extraordinary machine, and DARPA was funding the network. "We needed the money," Braden later said, "so we had to say 'yes.'" But what emerged was more than a funding arrangement. NETRJS demonstrated that the ARPANET could be used not just for interactive terminal sessions and file transfers, but for real production computing, submitting heavyweight batch jobs across the country and getting results back.

The protocol evolved through several RFCs: RFC 189 in 1971, RFC 599 in 1973, and the final consolidated specification in RFC 740, published November 22, 1977.⁶

Braden went on to become one of the most important figures in Internet history. He served on the Internet Architecture Board for 13 years, co-edited the RFC series after Jon Postel's death, developed one of the five original TCP/IP implementations (for the IBM 360/91, which survived the Big Switch from NCP to TCP/IP in January 1983), and wrote the first relay connecting the Internet to the UK academic X.25 network. He received the Internet Society's Postel Service Award in 2006. He passed away in April 2018.⁷

How It Worked

A NETRJS session began with an Initial Connection Protocol (ICP) handshake to port 71, which established the operator console channel using the Telnet protocol. The user would issue a SIGNON command with their assigned 8-character terminal ID.⁸

Once signed on, additional connections were opened for the data channels. The card reader channel (port 72) accepted job streams as series of 80-character logical records, complete with JCL (Job Control Language). NETRJS could parse the JCL well enough to recognize where one job ended and the next began, so users could submit entire stacks of jobs through a single reader session.

After execution, output flowed back through ports 73 and 74. Print output (the line printer stream) returned on port 73. Punch output (virtual card images) returned on port 74. The protocol included data compression, replacing repeated blanks with repeat counts, a practical necessity when transmitting printer output that was mostly whitespace.

Users could wait for their output or sign off and reconnect later to collect it. The STATUS command showed all jobs belonging to that terminal, with their processing state.

Security Considerations

NETRJS had no encryption, no authentication beyond the terminal ID, and no access controls beyond what the host operating system provided. This was standard for the era. The ARPANET was a trusted network of research institutions, and security meant physical access to the IMP (Interface Message Processor).

Port 74, like all well-known ports (0 through 1023), requires elevated privileges to bind to on Unix-like systems. No modern software is known to use this port. If you see traffic on port 74, it is almost certainly either a misconfiguration or something worth investigating.

How to Check What's Listening on Port 74

Linux:

sudo ss -tlnp | grep ':74\b'
sudo lsof -i :74

macOS:

sudo lsof -i :74

Windows:

netstat -ano | findstr ":74"

Why This Port Matters

Port 74 is a fossil. It preserves, in the IANA registry, the shape of a protocol that mapped physical devices onto network connections. Each port was a wire. Each channel was a machine you could hear and touch: the clatter of the card reader, the hammering of the line printer, the chunk-chunk-chunk of the card punch.

The designers of NETRJS didn't think in abstractions. They thought in devices. And they gave each device its own port because that's what made sense when you were virtualizing a room full of hardware across a continent of telephone lines.

We don't allocate ports this way anymore. Modern protocols multiplex everything over a single connection. But ports 71 through 74 remind us that the Internet's numbering system started with something concrete: the sound of a card punch, carried across the ARPANET, arriving on port 74.