Re: The old days - Aboard the Apollo - 1973
I just noticed this discussion about computers. I spent my whole career as a COBOL programmer/systems analyst/consultant etc.
In 1971 I was a trainee accountant and my employers were getting a mainframe computer - a Honeywell 115. They wanted a trainee programmer so almost everyone in the company was given an aptitude test. They said the pass mark was 45% so anyone who could achieve this would be eligible.
Well, I got 85% and the next person to me got about 50%. The computer guys seemed to think I must be some sort of alien.
Anyway, I'd found my niche in life so I became a trainee COBOL programmer.
I was trained on-the-job for a couple of months then sent on a proper COBOL course. By that time I knew more than the instructor so he would check with me whenever he wasn't sure of something.
Yes, I remember punched cards. I used to use a hand punch myself to put my programs into the computer but later they had punch machines with female punch operators.
I remember once having a problem with a program I'd written and I announced to my co-workers that the reason my program wasn't working was because there was something wrong with the computer! I was serious.
It was a Univac 9480. I went to see the manager and told him to get the engineer out because the computer was making a mistake every time it ran my program! Needless to say I was treated like I was nuts but I persisted so they called out the engineer.
I told hime that there was something wrong with a particular part of the memory because every time my program was loaded into that section there was an error in calculations but whenever I loaded it into another area of memory the calculations were correct.
He checked it out and found a bent pin! I was right, the computer was wrong. I became an instant legend.
Great story! What a reputation you must have had at your company!! I thought that I had seen it all but never experienced anything like that. One thing that could have been done without bringing in an engineer to check out the computer would have been to simply run your program on another Univac 9480 computer, if they had more than one in your company. Had that been possible, your program would have run fine on any other Univac 9480 and immediately everyone would have known your machine was defective. Of course having more than one of those big main frame computers was rare. A small to medium size company likely would have had only one such machine. Only a huge operation such as NASA or maybe Lockheed or North American Aviation would have had more than one machine in house.
THE TOUGHEST DEBUG WHICH I EVER RAN INTO
At MacDonald Douglas, some new programmer had created a program. The company was using the IBM 7094 computer, one of the most powerful computers of it's day. The memory capacity was only 64,000 bytes, which is tiny when compared to the memory of even a small home computer today. A certain portion of the 64K memory was used for the computer system and software and the remainder was used for the program to be run and for data storage.
Every time this person ran his program, the computer would go wild and start storing data in the portion of the computer system which was reserved for the software. The computer run would blow up as a result because part of operating system was being over written. This programmer came to see me to get me to help him in debugging his program. By then, I thought I knew all the tricks of the debugging trade and told him that I would solve his problem in a day or two. I looked at his code and it wasn't done very efficiently but it should have worked but it didn't. I looked over every step of the program and nothing seemed to be wrong.
His program had what was called a "Do Loop". A programmer could write something like, DO 100, I EQUALS 1, 500, then the next command might be, GO TO 200. This command would tell the computer to do a mathematical operation 500 times, starting at location #100 and then branch to location #200 to continue with the next step. This program would get into the Do Loop and then blow up. it would never get to the next step at location 200. No matter what input data I tried, I could never get beyond that Do Loop. I went in and instead of ordering the computer to do the loop, 500 times, I tried 100 times, then I tried 10 times and them I tried 2 times and finally a tried just one time and the computer still blew up.
I suspected computer mal function similar similar to Thetan Exterior's situation. I had been debugging this program for nearly 2 weeks now and I could not debug it. I was down to my last resource and if this resource failed, I was ready to admit defeat and/or tell them that there was an error in the computer hardware, just like Thetan Exterior did.
My last trick was to order print outs, called "dumps" where we could have the computer print out the contents of various key registers inside the software portion of the memory. If there was a hardware failure, at least we would find out the exact point where it occurred.
I readied my run and decided to do what was called a P-DUMP every five commands and see at what point the computer program was blowing up. The computer blew up within the first commands, then I did my P-DUMP every 2 commands, it still blew up and then I printed out the P DUMP after every command and found that itl blew up at the first command of the "Do Loop".
I now had to look at the first command to see if there was anything wrong with it. If there was nothing wrong, then I was done, whatever the problem was, it had to be a hardware problem, or so I thought, in the computer hardware just like in Thetan Exterior's case.
The exact command where the computer program blew up was the at the "Do Loop", Do 100, I EQUALS 1, 500. This command looked okay, it ordered the computer to do a simple arithmetic operation 500 times, each time increasing the parameter "I" by a factor of "1" unil "I"reached 500 and then the computer program would just continue on its merry way. There just seemed to be nothing wrong. I decided to get out a magnifying glass and look at the command itself. What could be wrong here, why was something going wrong when the computer attempted to execute this simple "Do Loop"? I was just stumped, I was looking at the program with my magnifying class thinking that it just could not be a hardware problem, something had to be wrong with this "Do Loop". I refused to give up. Suddenly I saw an error, I'll never forget the feeling. In another instant I knew that the program was now debugged. I felt like Archimedes in the bath tub when he figured out the law of hydrolics or whatever it's called. I started running around the cubicle where I worked, saying to myself, "I found it, I found it!" Why didn't I think of this before? why didn't I see it on the first day?
What was the problem? The computer printer had two characters which looked almost exactly the same, the letter, capital "O", and the number zero, "0". The computer hardware did not make the number 0 narrower as my current text is showing. Instead, the convention in computing was to put a very light slash through a zero and the "0" with the slash, "/" through it was to be the letter, capital "O".
When this program originally got typed up, whoever did the keypunching miss typed a capital "O" and put the number "0" in for the letter "O", thus in the command DO such and such, it actually stated D0 such and such. The FORTRAN compiler should have flagged this when it converted the FORTRAN code into machine language. A really good FORTRAN compiler should have picked up this error the first time the program was ever run. When the FORTRAN compiler encountered something of this nature, it was supposed to stop compiling and print out the message, "SYNTAX ERROR" at line such and such of the program code. IBM was responsible for this error, the FORTRAN compiler was part of their software package.
Therefore my debug job, which took me two and a half weeks to solve could have been avoided but for two things, first a key punch error and then a deficiency in IBM's FORTRAN compiler software which should have but did not pick up this simple error. The program came into my hands with me not even considering the possibility of a keypunch error or a limitation in the effectiveness of the FORTRAN compiler software. That cost me 2 1/2 weeks of frustration. I added this new knowledge into my debugger's hat bag of tricks and I told all the programmers in my unit at Mac Donald Douglas what had happened. We never did report this to IBM but we all had a good laugh about it.
Sometimes a problem source is sitting there right in front of you and you can't even see it. You can waste weeks of intense effort when simply looking more closely at your problem wouold have enabled an instantaneous solution!!! There has got to be some sort of moral principle here which we all need to earn. Thanks to Thetan Exterior for his story and for reminding me of my story. Both stories showcase short but potentially powerful ways of quickly solving simple but tricky problems at waypoints along the path of life!
Lakey
All routines, sub-routines and calculations therein and whatnot looked fine, so why the fuck does the computer give wrong results? So now I put a "Watch" on a small bunch of variables, and stepped through the program; step, by step, by step - keeping a keen eye on every suspect variable.
when he was already on his phone: "Hi, gimme the leader on your development team." 