My first computer weighed over three tons and filled an entire room. The CPU alone was about 5 feet by 3 feet by 6 feet and weighed nearly a ton. The power supply was about the same size as the CPU but weighed in at nearly one and a half tons, and that wasn't the complete machine. There was also an input/output unit that was about half the size of the CPU but managed to tip the scales at over half a ton. My first computer was the IBM 650. (See http://www.users.nwark.com/~rcmahq/jclark/ibm650.htm for a photo.)
The IBM 650 was the first computer on which IBM made a meaningful profit, selling around 2000 of them. The CPU was built to access a rotating drum that acted as a memory unit for both instructions and data. The drum had a capacity of 2000 10-digit decimal words; you could, allegedly, add additional drums for a total of 10,000 words of memory, though I never saw such an upgrade in my time programming the IBM 650. Although the programmer could access any address on the drum, the drum's rotation speed was a bottleneck. The drum had a revolution time of slightly less than 5 milliseconds, so if you placed your instructions sequentially onto the drum, you would have to wait for a complete rotation of the drum before the CPU could obtain the next instruction. Since many instructions on the 650 could execute in around 3 milliseconds, you would try to optimize your code by placing the instructions on the drum in such a way that it would not take the drum a full revolution to access your next instruction. This could be very tricky.
At first, programmers were given an IBM memory chart on which were printed 200 rows and 10 columns. The theory was that as you wrote your code, you would place your instructions and data in an optimal location and then mark that memory location off on the chart. This sounded great until you actually started modifying a large program that nearly filled the drum. You soon took what you could get. IBM then released their Symbolic Optimal Assembly Program (SOAP) that would automate the optimization. Some 650 purists remember it as clumsy, but I recall it as a great help. The machine had three arithmetic registers that dealt with the actual programming. There was an Upper and a Lower Accumulator, which acted as arithmetic and logical operation registers, and a Distributor, which I suppose could be called a fast intermediate storage buffer between the accumulators and the drum memory. The first computer-programming textbook, Programming the IBM 650, came out at this time.
The machine was very expensive. The CPU together with the power supply rented for about $3200/month while the input/output unit rented for another $550/month. You could buy entire machine for about a half a million dollars. These were 1956 prices, and by 1959, when I entered the picture, the prices had gone up. In 1960, a brand new Mercury Comet automobile cost about $2500 and a small house in Los Angeles could be purchased for about $13,000. I wasn't buying either, though. I was majoring in mathematics at California State College at Los Angeles and dreading a course called "Numerical Analysis." Those who had struggled through the course called it "Numerical Paralysis" because of the many hours spent hunched over a desk calculator, long hours often spent repeating the same tedious calculations over and over, manually cranking out solutions to numerical equations. If this weren't tough enough, the input to a calculation could be determined by the output from the previous calculation. All you could do was pray you didn't make an error near the beginning that compounded as you struggled along.
However, fate took a hand. The mathematics department scheduled a new course called "An Introduction to Digital Computer Programming." You could substitute that for the paralysis course. I knew nothing about computers, but then the mathematics professor who was assigned to teach the course didn't know anything about them, either. Few universities and colleges had such a thing as a computer science curriculum in those days. Most people came into the field with mathematics or engineering degrees.
Our college had no computer for its students. Therefore, it was arranged that our class would meet at an IBM installation on Wilshire Boulevard and learn on one of their computers. Of course, IBM wouldn't assign any of their programmers to help us. All we had to guide us was our kindly yet befuddled professor.
The machine we used was located near the window in a large room on the first floor of an ultra-modern glass and chrome laboratory. The window, which was room-wide and full-length, faced directly onto the Wilshire Boulevard sidewalk so any passerby could stop and watch the computer lights flash. I still remember how we gathered around the machine. It was even more fascinating to watch than the "electro-mechanical brains" in the Saturday afternoon Flash Gordon movie serials I grew up on as a kid. None of us could wait to get our hands on it. The problem was that we all had to go through our professor.
All input and output to the IBM 650 was done through punched cards, which were the prevailing method of transmitting data to and from computers in the 1950s and 1960s. (See http://www.users.nwark.com/~rcmahq/jclark/ibm650.htm for a photo of an IBM 650 punched card.) The standard punched card was 7.375 inches long and 3.25 inches high, and contained 80 columns and 12 rows of data. Each column contained the printed numbers zero through nine. There were also two unprinted fields directly above each column, called the "eleven and twelve punch," that were used to define alphanumeric characters. Thus, a twelve punch together with a punch in column one could define an "A." Only upper case characters were allowed.
Punched cards were actually invented about 75 years before computers came into general use. Herman Hollereth developed a punched card to be used in the 1880 U.S. census. Census data was punched on cards and machines were used to sort and tabulate the results. Consequently, punched cards were often called "tab cards." Hollereth's cards, in turn, had their predecessor: in 1801, a system of punched cards was used in France to direct the weaving pattern of the automatic Jacquard loom.
Since our school had no computers, it also had no cardpunches. Each week we were given the next week's assignment, for which we would spend the week writing the machine code. Then, if we arrived at IBM early enough, we could use their cardpunches to put together our programs. In theory, this might have worked, but in practice it didn't. There were not enough cardpunches allotted to us and, on top of that, sometimes the IBM programmers who were working late were actually using these cardpunches (nerve!). Assuming you were able to punch up your deck, you then got into the computer line to hand your card deck to the professor. God willing, he would succeed in reading your cards into the computer.
If your program read in, several things could happen. Either it would complete execution or it wouldn't. If it completed execution, the punched card output might or might not be correct. If your program didn't complete execution, it would either hang the machine (which was easy to spot) or go into a loop (which, for some people, was not easy to spot.) The trick for our inexperienced professor was to determine just how long to allow a program to run before manually halting the machine. Although he alone had this power, arguments over his decision were not uncommon.
The bottom line was you then had to stare at your punched card output (if any) and go on from there. If you wanted to list any cards, you entered yet another line to use yet another mammoth clunker, the IBM 407 Accounting Machine. Whatever you did, you had to try to figure out what was wrong with your program. Once you had an idea, you would struggle to get a turn at a cardpunch. You would quickly punch up your changes, because there was always somebody breathing down your neck and waiting impatiently behind you. After this, you would get back into the computer line and repeat the entire process again.
Of the other things that could go wrong, the most common was a card reader jam. Over time, cards often became wrinkled. When the card reader jammed, you had to remove your card deck from the reader, thus losing your place in the computer line. You then had to get in line for a cardpunch and wait your turn to replace the offending card or cards. If you were really jinxed, the cardpunch printing system that printed on top of the card would fail and you would have to read the actual punched holes in your cards. If you didn't want to do that, you could wait in line again at the 407 Accounting Machine to list your cards yet again. In any case, you then went into the computer line once more. With a little bad luck, this process could take a half hour, and with a little more bad luck, you could go through it three or four times during the evening and get absolutely nothing useful accomplished.
There were other incidents that were just as frustrating. Once our professor misplaced the SOAP deck and it seemed like the end for our session, but we were rescued from our troubles by a passing IBM programmer who obtained a new SOAP deck for us. Another time, a student managed to get peanut butter and jelly on his cards, and this completely clogged up the card reader. Nobody ran anything after that. (Of course, you weren't supposed to eat in the IBM laboratory.)
Yet, in spite of all this, we managed to learn; and sometimes—rarely—when things were slow, we were allowed to hand debug our programs on the computer itself for a few minutes. We would sit at the console, and cycle through our programs instruction by instruction, and watch the computer lights change as the values we calculated changed. This was a high point for me. That was when the IBM 650 became my first "personal computer"—as it was really built to be. The IBM 650 was designed to be programmer friendly. It was a decimal rather than a binary machine. It was made to be hands-on.
There were tricks, too. A programmer I knew didn't get the raise he expected. He therefore modified his program so it ran about ten times slower. He also changed his coding to generate a spectacular display from the console lights, designed to impress and awe his manager (who knew very little about programming). It worked; he received a "catch-up" raise.
I was lucky after graduation. My first programming job was with an insurance company that had two IBM 650 computers for me to play with. I had arrived. Now, over forty years later, I am a retired. But I would wager that I could program the IBM 650 today.
Reference
Reinhold, Arnold G., Essays on Early Computers, http://world.std.com/~reinhold/early.computers.html
Back in the Good Old Days, http://www.users.nwark.com/~rcmahq/jclark/ibm650.htm
Miller, Art, The IBM 650, http://www.mta.ca/~amiller/cs3711/ibm650/ibm650.htm
Herb is a retired programmer, and can be reached at [email protected]
