I did a tour of duty as a CPU logic designer at Amdahl. The POO was my bible, although it was the 370 version in those days. The thing to remember about ISA specs like this is that they are works of fiction. The contract goes: “If you programmers are willing to pretend this is how the machines work, we will build a machine that pretends to work that way.” That concept is the key innovation of the 360 system architecture, attributed to Gene Amdahl.
After leaving Amdahl I worked for a while in Electronic Design Automation. One year at the IEEE Design Automation Conference I met a random person at a happy hour who was an ex-IBM OS programmer. He said that he once spent a year rewriting a part of the OS to use a particular instruction entirely because “Amdahl didn’t have it yet.” Says I: “When was this?” ... “Ah, at that time part of my job was adding that instruction to the Amdahl CPU.”
The conversation felt like an old Mad Magazine “Spy vs. Spy” cartoon. We were both bemused.
By pure random luck and if you know, has Amdahl's UTS survived anywhere? Mainframe software seems to simply disappear into the void after its useful life is over.
I did about 5 years of assembler in the late 80’s for a major bank (IMS and CICS systems). A set of structured macros supposedly from NASA, made it quite readable. These added if/else, case, loop constructs, etc.
Around 2012(?), working for another major bank, I was asked to make an enhancement to a funds transfer system written in assembler, as no one else left in the pool of programmers had any experience. I had to dig out my old text book which I luckily found, and my old yellow card, and relearned enough to make the change.
When IBM introduced the AP (attached processor) and MP (multi-processor) systems, they had to add instructions that were guaranteed to be atomic since both processors had uniform access to main memory. Interestingly enough, they only added two instructions (compare and swap, compare double and swap) to support these configurations.
(I think there might have been one or two other supervisor mode-instructions, but there were weirdos like "stop the other processor", for example).
I remember reading a similar document for my shop's IBM 4381.
When I started mainframe programming, I was given a pocket-sized 'yellow card' that listed all the machine instructions and arguments. It was invaluable for dump-reading.
My co-workers (who were all older when I started) had similar cards, except in different colors. There were white, pink and green cards, too. You could tell when somebody started programming by the color of their card.
Coincidentally, I finished reading "IBM's 360 and Early 370 Systems" earlier today. I highly recommend it and its predecessor, "IBM's Early Computers" from the MIT press. The business aspect is there, of course, but it's really about the development of the machines themselves, down to how they developed the transistors they used along with who did it.
>BYTE criticized The Adolescence of P-1 for what it stated were unrealistic expectations for an artificial intelligence running on 1970s IBM mainframes. It suggested that the author could have set the novel in the 1990s and use fictional future IBM computers to make the plot more plausible.
Heh - had to go look up storage protect, aka 'red light errors' . Kept getting in trouble in the beginning of my career when I didn't realize snooping about lit up lights on the front panel . :-)
That's the easy one. z/Arch is way more intricate. As noted in my moniker, you can do fun stuff with BXLE,as described in the "Difficult Code" section on FINCH (aka program fetching) in an OS/360 PLM (Program Logic Manual).
This was my bible for many years. We called it POOP (Principles Of OPeration. I loved assembler on the 360 and the 370. I learned Assembly Language by cross listing my COBOL programs and using POOP to find out what the op codes meant.
System 370 assembler was the first language I worked in professionally. We called it the POPS manual. As I recall it was a paragon of technical writing. I learned how to read technical documentation on this manual.
He does. He's been a great help as I try to piece together enough stuff to function as a system element. And thank you for that redbook link; I have a load of stuff, but somehow missed that one. Thanks!
The MP3000 (Multiprise 3000) is the smallest mainframe IBM ever made, weighing in at only about 300 lbs. Using the vanilla Hercules, it can be MIPS limited to act mostly like a MP3000 System/390 machine and run the same OSes.
To me, it's a realistic introduction it's just that as computers became ubiquitous, marketing them as easy to use was the dominant strategy. It's been very successful. People will shop weeks on faith in silver bullets to avoid four hours RTFM'ing.
It's certainly a gentler introduction than the current, 2,000-page z/Arch Principles!
And along similar lines, it's kind of fun, if not at all useful in any economically rational sense of the term, to write nontrivial source- and binary-compatible code that builds and runs on everything from a 40-year-old 370 to a current-model Z (speaking hypothetically, as I don't actually have access to even a reasonable facsimile of the latter; I have, however, tested as far forward as late-model OS/390 running in 64-bit z/Arch mode on emulated hardware).
It's a typical programmer's hardware manual for the period.
More or less until the IBM PC, it was normal for computer vendors to supply a detailed bit-level breakdown of instructions, memory operation, data formats, interrupt structure, and so on.
Things were different in the early days. In the 1970's I worked at a company that had an IBM S/370 and a clone, an Itel AS/5.
IBM supplied hardware schematics and microcode listings for their S/370 hardware. They were in the machine room and freely available for perusal by us.
In a bit of irony, they also supplied schematics and microcode for the Itel clone. That's because the Itel was a true clone. It was designed by copying IBM's circuitry, but implemented in Motorola 10K series ECL instead of IBM's proprietary technology.
You read that right. In order to debug a problem with the Itel, the Itel field service engineers used IBM's schematics.
I think a lot of this free availability was because IBM was facing antitrust pressure from the US government. I don't know all the details.
Although similar information was of course also available for the IBM PC even if it wasn't as routinely used. An assembly language reference for a PC contains much of the same information as a POO for a mainframe or mini.
After leaving Amdahl I worked for a while in Electronic Design Automation. One year at the IEEE Design Automation Conference I met a random person at a happy hour who was an ex-IBM OS programmer. He said that he once spent a year rewriting a part of the OS to use a particular instruction entirely because “Amdahl didn’t have it yet.” Says I: “When was this?” ... “Ah, at that time part of my job was adding that instruction to the Amdahl CPU.”
The conversation felt like an old Mad Magazine “Spy vs. Spy” cartoon. We were both bemused.