EDITOR’S NOTE: This article is part of a series inspired by an interview with the late Dr. John Ehrman, conducted by Reg Harbeck at SHARE Atlanta in 2012. Catch up on the series by reading Reg’s introductory article here and Part I by M. Ray Mullins here.
It didn’t take long in conversation with Dr. John Ehrman for it to become apparent why he was considered the father of mainframe assembler. Indeed, as the below excerpt from our interview demonstrates, he had a cycle-logical mastery:
“In 1966, when I was working at SLAC1, the computer science department at Stanford down on the campus […] was still teaching 7090 programming and they had just gotten in a 360 model 67 on campus. And since I had had some experience with that, I volunteered to do some teaching of an introductory programming class on the 360 machine on campus.
“The professor who had been teaching the course, I was supposed to talk to before they would decide whether or not to let me teach. And, I wandered into his office, and he was on the phone, so I stood in the corner and looked at his blackboard, and I saw this piece of code for the 7090, which counted the number of 1 bits in a 36-bit word. And so, when he got off the phone, he pointed to it and said, ‘That’s my professor’s solution. It takes only 216 cycles and most of the students take anywhere from 240 to 250.’ And, I looked at him for a moment, and I said, ‘Oh, I know how to do that in 36 cycles.’ I was not greeted with the greatest warmth at that point but . . .” (chuckles) “they did agree to let me teach that.”
And that was what knowing, speaking with, and learning from Dr. John Ehrman was like. He’d literally been there and done that, and not merely gotten the tee-shirt but become the teacher. You could base three entire courses on taking apart those two paragraphs: one about the early history of mainframe computing, one about machine architecture, and one about the experience and culture of assembler programming.
In my conversation with him at SHARE Atlanta, John continued, “At the time, the 360/67 was not completely installed, so I would take decks of cards from the students for their programming problems and take them up the hill to SLAC and run them on our model 50 and then bring the cards and the listings back. So it was not very efficient, but the students got started on it.
“Once the model 67 was installed, we could run the programs there. We found fairly quickly that—because the system they were running was MFT, the multi-programming with a fixed number of tasks—the student programs, which would sometimes go into a loop, would splatter characters all over memory, including the last 8 bytes. [This] turned out to be where the resume PSW for the next partition was, so the system would crash. So, student assembly programs were looked on rather negatively by the manager at the comp center and so he agreed to provide some time on the machine for us to write a student assembler.”
In less than three minutes, John had covered enough ground to keep serious researchers Googling and reading Wikipedia and other reference sources for hours. Or, for those of us who recognize all the jargon and concepts, enough ground to validate and build on our insights and experience as mainframers.
So I have a challenge for you: stop here and take the above paragraphs to someone who is serious about learning the mainframe and has progressed sufficiently to have some idea what they are saying, then answer their questions until they fully understand the circumstances that are described. You’ll be amazed how much learning results!
And we’ve only just begun, but we’ll BR 14 at this point. Until next time!
1 Stanford Linear Accelerator Center