Summary

  • UCLA-CCN’s NETRJS let a remote host act like a virtual batch terminal for an IBM 360/91, submitting card-image jobs and retrieving print or punch output.
  • The service was more than a file transfer: separate channels carried the operator console, input cards and returned output, while 1973 records show both its scale and its delivery problems.

The user could leave before the output came back

A batch job could be out of sight before it was finished. With UCLA’s NETRJS service, a remote user sent a job over the ARPANET to the Campus Computing Network, signed off, and could sign on later to collect the result. The network carried work to the computer and the computer’s output back to the user. The useful unit was the round trip, not the moment a remote host opened a connection.

A virtual terminal made batch work network-addressable

The 1977 RFC calls NETRJS a “private protocol” defined by UCLA-CCN for batch submission to an IBM 360 Model 91. The same Remote Job Service also served real batch terminals over direct communications lines. That qualification matters: NETRJS was one computing service reachable in more than one way, not evidence that every ARPANET job ran through UCLA or that the network had become one giant mainframe.

The job was not complete until the output arrived

To make the exchange intelligible, NETRJS represented the remote endpoint as a Virtual Remote Batch Terminal. It had a virtual card reader for incoming job streams, a virtual printer and punch for returned results, and an operator console for sign-on, commands, status and errors. The submitted records were card images of up to 80 characters, with job-control language. The server queued the jobs for execution according to priority and returned print or punch output to the same virtual terminal. A user could wait for the output, or leave and return later.

The design separated control from data. The operator console used a full-duplex Telnet connection; card-reader, printer and punch streams each had their own simplex channel. Up to five connections could exist between user and server processes. The data channels only needed to be open while in use, and reader, printer and punch work could operate at the same time. This let a remote process manage a batch device model rather than treat the mainframe as an interactive terminal.

The service had a history before the 1977 document. RFC 88 described NETRJS in 1971; RFC 599 updated it in 1973; RFC 740 superseded both RFC 189 and RFC 599. The 1973 update provides a rare operating snapshot: during October, CCN submitted 1,373 jobs through NETRJS; 1,105 were printed and none punched. It records 49,400 cards read, 822,900 lines and 18,907 pages printed, and 393.6 connection hours. These are figures for that UCLA service and month, not a network-wide measure. The RFC called an average job of 360 input lines (“cards”) and 745 output lines over 17.1 pages fairly typical.

Those counts did not mean that a job’s result was safely home. The 1973 update describes a “squish” failure: under NCP buffering, the batch host could dequeue and discard a short output file before the first message had actually reached the remote machine. A remote crash or cancellation could leave the user without a recoverable copy. The fix was to make NETRJS wait for the network’s RFNM confirmation of the end-of-data mark before telling the batch service to discard the output. Completion therefore crossed both a computing boundary and a delivery boundary.

Character sets created another boundary. UCLA’s IBM 360 processed EBCDIC, while remote user processes could be ASCII. In 1972, users at RAND, Utah and Illinois reported deficiencies in the original mapping. UCLA changed the mapping and added another; the 1977 protocol let a virtual terminal select EBCDIC, ASCII-68 or ASCII-63, with translation on card input and printer output where needed.

NETRJS shows an Internet that could carry scheduled work, not just live conversation. Its remote user submitted a structured job, the service decided when to run it, and separate channels returned a durable result. The RFCs expose the practical contract: who could sign on, how card images entered, how output was requested, how character sets were reconciled, and what acknowledgement protected the final copy. The network made the batch computer reachable; the service made the whole job usable.

Primary sources