1. Hardware Reliability

There was an old joke that went around the early computer rooms. You purchased your IBM computer, and they put it in boxes and sent it to you. When you opened the boxes, you found in one of the boxes, a carton of IBM support technicians. You had to set up your support staff before you setup the computer.

This was pretty close to the truth. The old vacuum tube computers had rather poor mean-time-to-failure characteristics. IBM had a set of specifications for the environment needed for their computers that included space, power supply, air conditioning, and the office space for the IBM support staff.

The early vacuum tube computers had tremendous air conditioning requirements. So companies met these requirements. In a few years, when everything changed to solid state components, the computer room, on very hot days, was the most comfortable place in the building. It was over air conditioned at a time when air conditioning in staff offices was not common place. I am sorry I did not keep a list of the excuses given to spend a hot summer afternoon in the computer room.

2. Computational Reliability

There was much early skepticism as to whether these new machines were giving correct answers. One of the first machines, the Univac, had two arithmetic units. Each computation was performed twice and compared at the end of the process. Errors would be flagged. The Univac had a different type of computational logic than the IBM machines. It used a device called a Mercury Delay Line. I do not know if this mechanization was more error prone than that of the IBM machines.

When the IBM 700 series computer came out it did not have the same type of computational checking as the Univac, and this must have disturbed the early programmers. During the time my company was making the transition from the IBM 650 to the IBM 704, I was studying manuals about the machine and looking at assembler language code written for the machine. Actually the code had been written for the older but similar IBM 701. What surprised me about this code was that everything was computed twice using two separately written code blocks. The software compared the results of the two computations. Were these programmers trying to emulate the Univac?

3. Reliability of Data

One problem that I encountered, as a 1956 summer hire during graduate school, was the alignment of the punches on the punched card. What I mean by alignment is whether a correct punch is properly positioned on the card, or it is off-centered. The large data collection organization with which I was associated was having problems with off-centered punches. My task was to examine the distribution of off-centered punches, how they effected the data processing, and whether or not being off-centered horizontally was correlated with being off-centered vertically.

I had never before known this to be a problem with IBM equipment, but this organization used the Univac and products made by other manufacturers. I presume that IBM was aware that this was a problem, since the gauge that was use to measure the alignment of the punches was made by IBM.

I do not know if I helped my employer that summer, but the derivation of my mathematical model became my master's thesis.

4. Programming Procedures

In the mid-to-late 1950's, software development was in as primitive a state as hardware development. In the years before computers, we had performed our calculations with armies of clerks on calculators. The tendency was to develop algorithms to minimize the number of keystrokes needed to perform the calculations by increasing the number of logical decisions the clerk needed to make. Now the computer comes along. The computer cranked in numbers with ease, but had difficulty making the logical decisions needed for the algorithms that were executed by the humans who operated the calculators.

A major problem with computers was the limited word length, often shorter than what was available on a calculator. The computing algorithms for the computer needed to make maximum use of the shorter word length, at the expense of more arithmetic operations.

This problem came to an early realization when we started to invert matrices. Much time was lost in "debugging" correct programs that were trying to invert poorly conditioned matrices. Often the problem was not in the program logic, but in the underflow conditions that we were experiencing in the computer calculations.

One of my first memos on computing concerned the fact that we were not really programming the computer. Our programs represented a simulation of a clerk performing the calculations on a calculator.

Some of this simulation still goes on today. For example, if you balance your checkbook with a spreadsheet, and you follow the procedures described on your bank statement, you are performing this task in a manner analogous with the clerk simulation I have described. The proper way for a computer to do this task is to keep two balance columns in your spreadsheet, one for checkbook balance and one for bank balance. An entry is always added to or subtracted from the checkbook balance column, but is added to or subtracted from the bank balance column only when the "cleared" indication is set. Such a spreadsheet is simple to develop and use, but try to follow this procedure with a calculator, a sheet of paper and one hundred or more items in your checkbook.

5. Purchasing Software and Computer Time

The concept of software was unknown to the general public in the 1950's. Can you imagine how difficult it was in the corporate environment to purchase software? How do you explain to a purchasing agent, who had never seen a computer, what is this thing you are trying to purchase? As the story goes, one purchasing agent, who did not believe the engineer when he told the purchasing agent that you could not hold or see software, went snooping around the computer room looking for software. Finally, he found a stack of punch cards. He grabbed them and went back to the engineer, produced the cards and proudly proclaimed that he had found software. The engineer looked at him as said, "No, the cards are not the software, the holes are the software."

That is supposedly a true story, but I cannot verify it. However, I can verify the following situation that happened to me.

In 1960 and 1961, I was working with a government agency in the south-eastern part of Virginia, when I needed a computer that was bigger than the Royal-McBee available on site. So I had one of the purchasing agents contract, for computer time, with a different government agency in Washington, that had an IBM 704. The negotiations went well. All arrangements were made, and I planned to spend several weeks in Washington. When I got to Washington, I was told by head of the computer center, that after the arrangements had been made, the purchasing agent called the computer center to find out when they were going to ship the computer to Virginia.

6. Early Changes in Conventions

It is often said that it would be nice if everybody drove on the right hand side of the road. Fewer different car parts would be necessary, and any car model would be available for any country. Sweden, in 1969, was the last major country to make the change from left side driving to right side driving. The United Kingdom, Australia, New Zealand, Japan, and even the American Virgin Islands are all out of step with the rest of the world. Possibly, in the 1950's, with fewer cars on the road, all these countries could have changed their driving algorithms. But now is too late. Fortunately, the computer industry saw some early problems with some of the conventions that had been adopted and changed them before it was too late.

Originally, on spools of magnetic tape, file-protection-rings in tapes were file protection rings. If you put one on the tape it was protected, if you took it off it was not protected. Fortunately, this convention was reversed in the late 1950's or early 1960's. The file protection ring became a write enable ring.

In the days when programmers wrote their programs on coding forms and gave them to key punch operators to produce cards, it was extremely important to distinguish between the number 0, and the letter O; and the number 1 and the letter I. The original conventions were the following:

Put a slash through the Letter O

Put no slash through the Number 0.

Write the Letter I with short horizontal lines at the top and bottom

Write the Number 1 as a single vertical line.

With the early involvement of the military, it was evident the convention for O and 0 was bad since it was reversed from what had existed for many years in the military environment. Fortunately, this was reversed. However, it took time for some of the early programmers to break the habit of slashing the Letter O.

It is also fortunate that during this time period we only used upper case letters. However, if we had used both upper and lower case in the 1950's and 1960's we might not have the case-sensitivity problems we have today. Who has not ever been denied access to a computer because the "Caps Lock" was in the "on" position when the password was entered?

Early FORTRAN had some unusual function naming conventions. All functions ended with an "F". All integer functions started with an "X". The Sine function of "X" was written as SINF(X), the integer function of "X" was written as XINTF(X).

These conventions proved cumbersome but were part of both FORTRAN I and FORTRAN II. For years after this restriction was dropped, FORTRAN and other languages defined SIN( ) and SINF( ) as aliases. The restriction on integer functions beginning with "X" was confusing, since all integer variables in FORTRAN began with the letters I through N.

In FORTRAN II these conventions held only for Arithmetic Statement Functions (ASF), and not functions defined with a FUNCTION statement. Note that, in FORTRAN II, if you named a function MYFUN(X), it would return a floating point result if it was written as an ASF, but an integer result if it was written as a subprogram with a FUNCTION statement. This was because functions defined with FUNCTION statements followed the same naming rules as variables.

7. Character Sets

When input for computers was from cards, all character input to the computer came from the 48 valid combination of punches (including a null) in a card column. The first binary machines had 36 bit words that held six six-bit characters. The code was called BCD for Binary Coded Decimal. Hexadecimal arithmetic was unknown, and programmers who worked in binary-based arithmetic used octal instead of hexadecimal arithmetic. The only valid characters that could be represented in the IBM 704 was the 26 letters, 10 digits, a blank, and the 10 special characters that are in the string that I enclose in Quotes, below:

"+ - * / , . $ ( ) = "

This adds up to 47 characters. The minus sign had two representations to make up the 48 characters.

To complicate things, the BCD codes in the computer were not the same as the codes that were used on the spools of BCD magnetic tapes. Additionally, neither the tape codes nor the computer codes had a natural collating sequence. With the codes used in computer memory, the alphabetic and numeric card codes formed a natural collating sequence, except a blank collated between "R" and "S". With the codes used on magnetic tapes, the alphabet collated as if "S" were the first letter of the alphabet. These machines were not designed to simplify the task of sorting.

8. Epilog

We should feel lucky that the computer industry initially used 6-bit characters rather than the eventual standard of 8-bits. At least, when it became evident that we needed more than six bits per character, we were able to start over with a new character set and eliminate the mistakes made earlier. In defense of the early machines it should be noted that these machines were primarily manufactured to grind out mathematical computations. Working with alphabetic data was an afterthought. Working with graphics was non-existent.

Old habits don't die easily. New conventions required some alterations in mind patterning. At times it required some thought to remember whether to cross the "0" or the "O". It also took a while to get out of the habit of appending an "F" to the end of each function. However, we survived to the next generation of computers.