365 RFCs

by Darius Kazemi, April 15 2019

In 2019 I'm reading one RFC a day in chronological order starting from the very first one. More on this project here. There is a table of contents for all my RFC posts.

Remote jobs

RFC-105 is titled “Network Specifications for Remote Job Entry and Remote Job Output Retrieval at UCSB”. It's authored by James (Jim) E. White of UC Santa Barbara, dated March 1971 with no specific date.

A business note: my ten-month Mozilla Fellowship has supported this project up until now, but that has ended. If you like what I'm doing here, please consider supporting me via my Patreon.

The technical content

This RFC discusses UCSB's implementation of Remote Job Entry (RJE), an idea first proposed in RFC-88 by Braden and Wolfe of UCLA. As I explained in that blog post, RJE lets you

enter a batch of Fortran commands on a punch card system and then send them over the network to a computer to process as a “job”. You can also log in to the remote computer and ask it for the status of your job. You can submit a “stack of consecutive jobs” as well.

Specifically, this document explains to any ARPANET user how they can connect to the UCSB Computer Center and submit jobs for the computer there to run.

They reserve a specific socket for incoming remote job submissions. This socket number is denoted x'200', which is FORTRAN hexadecimal notation, which means that's a decimal (base 10) vaue of 512. You have to register for an account with the Computer Center before accessing remote job services.

The Computer Center already has a job control language system; this document assumes you already know how to use that. The RJE is specifically a way to talk to their job control language from a remote site, and this document talks about how you would do that.

Like the RJE in RFC-88, this is a third-level protocol and routes through the network control program (NCP). RJE only accepts one user at a time, queueing any requests it gets if it's currently serving a user. To prevent someone from just sitting on the RJE and preventing everyone else from using it, the RJE kicks off a user if they aren't processing recordings at a certain rate. (In a sense this is the opposite of a “rate limited” API — you get kicked off for NOT using the service!)

RJE accepts multiple data formats, including a stream-based option (not fixed length) where the user needs to specify a break character in the header.

Getting the output

RJE is about submitting jobs to the computer to process; this RFC has a second section about the Remote Job Output Retrieval (RJOR) system. This is about obtaining the results of your calculations from a remote site (it wouldn't be very useful if you had to print your output at a school 1,000 miles away and have to ask them to mail it to you).

RJOR listens on socket x'300' and allows one user at a time with a similar queuing system to the one in RJE described above. When you connect to RJOR you send it commands for the kind of output you want, and then it will open socket x'301' and attempt to connect to a socket at your own Host site numbered one less than the socket from which you initiated your connection. (This adjacent-socket approach is a pretty common pattern in ARPANET applications at this time.) It will then send your output (or some kind of status info) back to you over this new connection.

Analysis

The document opens with a note:

     In the discussions that follow, 'byte' means 8 bits, with those eight bits numbered 0-7 from left to right.

It's important to note that the number of bits in a byte was not standardized (even informally!) until very recently in computing history. Here's a quote from Wikipedia's page on “byte”:

The size of the byte has historically been hardware dependent and no definitive standards existed that mandated the size – byte-sizes from 1 to 48 bits are known to have been used in the past. Early character encoding systems often used six bits, and machines using six-bit and nine-bit bytes were common into the 1960s.

I like that this document specifies that its NCP “operates under the Host-Host protocol of 3 August 1970”. Because the protocol is always changing, that's a level of necessary specificity that some other RFCs don't provide.

Further reading

Their computer runs a variant of OS/360 called MVT or Multiprogramming with a Variable number of Tasks, which by 1971 supported time sharing and batch jobs. It also runs something called HASP, the Houston Automatic Spooling Priority system, which is a complex I/O manager for remote job control and printing, among other things. Basically this machine seems perfectly configured for remote job processing!

How to follow this blog

You can subscribe to this blog's RSS feed or if you're on a federated ActivityPub social network like Mastodon or Pleroma you can search for the user “@365-rfcs@write.as” and follow it there.

About me

I'm Darius Kazemi. I'm an independent technologist and artist. I do a lot of work on the decentralized web with both ActivityPub and the Dat Project. You can support my work via my Patreon.