Did you miss Part 1? Go back and read it here.
if not carry on…
Part 2: The 1960s
By the early ‘60s, sane I/O architecture was emerging and the first real coupled products, like the IBM 7090/7040 “Direct Coupled System” came out. And then, in 1964, IBM blew the world away with the 360 series.
The IBM 360 defined a “channel” based I/O architecture, which mostly still survives on today’s mainframes, and influenced a huge number of future technologies like SCSI and Fibre Channel. And to connect a couple of 360s, they provided the “channel-to-channel” adapter (CTCA), whose hardware was remarkably easy to program.
I should clarify – writing a driver for the CTCA was easy; writing drivers for channel “programs” – not so much. Many people speak of “channel processors”, but they were not really fully programmable. More like glorified DMA engines. Compared to the CDC 6600, with its integrated I/O processors, it was quite primitive. So the 360 had DMA controllers while the CDC had Smart “NICs”.
Anyhoo, so once the computers could talk, what would they say? What was the protocol stack? Well, the protocols – data communication – were much more heavily influenced by the need to communicate remotely, e.g., cross-country, then by the lucky few who had more than one computer.
But remember all that punched card equipment? Data communications and protocols existed for them before computers! And it was bug ugly under the covers. But the basic idea was to get a “deck” of punched cards from point A to point B.
When the punched card equipment was hooked to computers, it was still about getting decks of cards from point A to point B. This was Job Entry – controlled by special cards using Job Control Language (JCL). When distant, it was Remote Job Entry – RJE.
So once computers could talk directly and quickly to each other on a CTCA, what did they say? – “Have I got a job for you!”, just like remote equipment, and just like Sneakernet. Because protocols are forever.
IBM had 2 competing software products for managing RJE to mainframes – HASP and ASP. HASP was for a single mainframe talking to lots of remotes; ASP worked better for small “clusters” of mainframes sharing lots of remotes.
HASP was developed for one customer – NASA – and stood for “Houston Automatic Spooling Priority”. BTW, “spooling” was the activity of moving tapes between systems. SPOOL was an early retronym – “Simultaneous Peripheral Operations OnLine”. HASP evolved to JES2 which is still commonly used in mainframes.
ASP was developed as a full-on ambitious IBM software product, and therefore did not work as well as HASP (sigh). ASP stood for “Attached Support Processor” but was later changed to mean “Asymmetric Multi-Processing”. ASP evolved to JES3, which after about 40 years is finally being deprecated in favor of JES2.
head over to Part 3 here.