War Stories From an Old Code-Slinger

5 Pages

I started programming on the IBM mainframe in 1966. Of course we didn’t call them mainframes then; they were simply computers, being the only kind of computer there was. That date doesn’t exactly classify me as a pioneer, but I was in the first wave of business programmers on the mighty IBM 360.
 

There was no education to be had in those days, no computer science degrees, no courses. My total education consisted of a two-week course from IBM on Assembler language, taught by a one-armed IBM Systems Engineer (SE) named E.Z. Million (that’s his real name and he was an interesting guy). IBM used to educate their SEs by making them teach a course on something they knew nothing about, and E.Z. was only a few pages ahead of the rest of us. He taught us the instruction set, but not how to deal with input/output devices. We had to dig that out of the manuals ourselves.

Ah, what a machine, the 360. It had 64KB of memory! That’s right, 65,536 bytes of memory, of which the operating system used 20KB. That left room for three partitions of around 15KB, each of which could run a separate program at the same time! The 360 was IBM’s first offering that did multi-programming; it was a giant step forward from the 1401, which had 4KB of memory.

Now keep in mind that the word “virtual” had not yet entered our vocabulary. No virtual memory, VSAM, VTAM, VS, VSE, nothing with a “V.” Most everything started with “B,” for “basic.”

The console of the 360 looked like the cockpit of a 747. It had rows and rows of blinking lights, dozens of toggle switches and dials, and buttons to push. But the lights weren’t just for show; they had a purpose. They were laid out in rows of 32 lights in groups of four, eight lights per group. Each light represented a bit and 32 bits made up an address. As programs executed, the current Program Status Word (PSW) address displayed in one bank of lights, each light blinking on if the corresponding bit was a “1” in the address, off if it was “0.” It was fascinating to watch, especially in the dark.

You could do more than just watch. There were other banks of lights where you could dial up an address in memory, read the bit setting to make sure you were in the right spot, then dial in up to four bytes that you wanted to replace at the address, press the magic “Store” button, and you had effectively altered the instruction at that memory address.

So why do that? Generally, it was a time-saving device. Developing a program then consisted of coding it in pencil on a specially designed coding pad, then sending it to keypunch, where a fleet of (usually) women would enter it on a keypunch machine and hand you back a deck of punched cards. The programmer then punched the Job Control Language (JCL) cards to wrap around the program to assemble it. This went into the card reader, assembled and punched out an object deck while outputting a listing on the printer. More JCL cards wrapped around that, and with another trip through the card reader, the program was linked and cataloged into a load library where it could be executed. Ever wonder why output queues are sometimes still called “punch” queues and why the standard size of a PDS source record is 80 bytes? It goes all the way back to punched cards.

So, when it came to debugging your program, you got your listing, ran the program, diagnosed a dump (again on paper) when it blew up, then marked the corrections on the listing with a pencil. Now you had a choice. You could paw through the deck of source statements looking for the offending code, find it and take it to the keypunch where you punched a new source statement, then go back through the assemble and link process for the next test …

Or, to save time, you could just dial in and “zap” memory. When you had too many zaps to continue, you went to the keypunch and made all your source changes. You had to understand machine language, of course, to alter memory, but that’s a byproduct of Assembler programming.

No one had ever heard of a text editor then, and there were no terminals to work on anyway. Terminals didn’t come along until 1968 or so, and they were 2260s, not 3270s. The 2260 was a primitive, archaic device that was almost more trouble than it was worth.

5 Pages