An Interview with Jack Noonan

JN = Jack Noonan
GAM = George Michael

GAM: Today, 10/23/96, we are interviewing Jack Noonan. I'd like you to start Jack by telling us where you came from and when you got to the Lab, what was your training, who were your supervisors, that type of information.

JN: Well, I arrived at the Lab in March of 1957. I had just gotten out of the Air Force. I'd gone though electronics training in the Air Force and I worked flight simulators, analog computers really. That made me curious about digital computers, so I interviewed at the Lab. They said that occasionally jobs came open in the area and that they would put my name down and, if one came up in a year or two, they would tell me about it. I was in what was then called "the cooler" and I was repairing cables and testing tubes, where they put all new technicians and engineers. I suppose I'd been there, maybe, three weeks and a job came open, so I went over to the UNIVAC maintenance group and got the training and learned all about the UNIVAC while I was getting my Q-clearance. They were able to clear the UNIVAC area at night so that I was able to go to work. There were at least four or five of us who did that, it was just a stroke of luck. I thought it was going to be years.

GAM: Yes, I think that it really turned out that there was a crying need for computer technicians, that was a brand new factor. The computers were brand new.

JN: Yes, that's right. I worked on the UNIVAC, I guess, for a couple of years and then the LARC came along. I was one of the crew that went back and got the training on the LARC, and I guess I was involved in the acceptance test too. I stuck around and, probably, was one of the last ones to leave to come back to Livermore once the acceptance tests were over. After we got back, we were maintaining the LARC and, somewhere along the line, and I guess I'm not sure exactly the time frame, Nevin Sherman had an orbiting-type code. I'm not sure, but it was an astronomy-type of calculation where he had a large need for great accuracy. He was concerned about the round-off error, so he started checking his numbers and he found that he had some strange results. Eventually, he found what appeared to be, intermittently, an error in about three places. I guess it must have been the twenty-second place. It would be off by one at random times. He went to, I suppose it was Jim Moore, who was in charge of the LARC at that time; he must have been the person they first approached. First, I went through the procedure by hand, following the algorithm, and Jim wrote some code to do the calculations using the same algorithm, and we found that there were errors. Indeed, if you did it the long way (by hand) it was correct, but if you used the computer it was incorrect in that one digit. Then, Jim gave it to me to figure out where the problem was. So, I went through a lot of hand calculations and I went through the algorithm in the arithmetic unit, and I thought twice I had discovered what the problem was, and we fixed it, but each time the problem just became more intermittent. The problem was, it was double precision and when you combine partial products you do some shifting; they shift right and then, depending whether the number is positive or negative, and depending on the circumstances, you would stuff a nine or a zero into the most significant digit position. The algorithm was incorrect under certain circumstances.

GAM: The algorithm or the wiring of the hardware?

JN: Well, it couldn't have been the algorithm because Jim had checked that out. It was the hardware that didn't quite follow the algorithm. The way the arithmetic unit was designed, I used that algorithm. He used the algorithm we thought was correct. If I remember correctly, his answers were right and I found my answers were incorrect if I followed the arithmetic unit algorithm. Then I implemented a couple of changes and, as I say, the first two attempts the problem improved, but it just became more intermittent. Finally, I think maybe it was the third attempt, we rewired the system and it worked. We started getting the correct answers. One other interesting thing I guess I should mention, when we started really zeroing in on this, we discovered it actually failed very, very seldom. But maybe, possibly, the ninth digit, I don't remember, but it was up high, the floating point positions, the exponent took up so many positions, so it was a few digits in from the floating point exponent and I don't know where that was. So it would fail in a very significant digit.

GAM: The failure is consistent in what?

JN: It would be off by one, because you stuffed the wrong character, you stuffed maybe a zero and maybe you should have stuffed a nine, so you'd be off by one and in the ninth digit, I think, which was very significant. In the other case, the one that Nevin uncovered initially, I think it was in the twenty-second place. But that occurred much more frequently than in the ninth place. It was Jim's code that uncovered the error in the ninth place. It took some time to do that. I don't know if you recall what the wiring looked like in the LARC. It was many inches deep and you had to use a Bore Scope to get in to see where you were going to wire, so it took a fair amount of time to rewire in the arithmetic section.

GAM: After you discovered it and, perhaps I should say, got publicity about it, was there any reaction from the Lab or Remington Rand Co?

JN: None that I knew of. In talking to Nevin, I think that we sent the change, and the problem, to the other people who had a LARC, but we never heard anything about it.

GAM: The David Taylor Model Basin?

JN: Yes, and Brookhaven? I think Brookhaven had one also, but no one seemed to be concerned about it.

GAM: They want to run fast, they don't care if it is accurate or not! Well, go on, that's a great story.

JN: Well, that kind of covers that part of it anyway. I can't think of anything else to add to that right now. I don't know when that date was, it might have been '61 or '62. We'd had the machine some time. It was well into the operating phase. We wrote the compiler. When I say we, the Lab wrote the compiler.

GAM: Yes, Lee Kryder did.

JN: Yes, so all of that stuff was working at that time. We really had the computer in operation, the way I recall.

GAM: I remember many, many alterations on the LARC. We put on IBM tapes, because the LARC tapes didn't quite stand to the gaff.

JN: Yes, they weren't nearly as fast and they weren't nearly as dense. I was involved in that too. I helped design some of that along with Jim Moore and Chuck Cole and, I suppose, Ervie Ferris. I don't know for sure, but I know he was the type that would have been involved in that, but I don't remember the details.

GAM: Well, that was a long time ago. What did you do when the LARC left, I don't remember exactly when that was, but it was in the '60's.

JN: Yes, I guess the next thing I was involved in was, I went back on the PDP-1. I was there for the acceptance test, again in Maynard, Massachusetts, with DEC for six weeks, I think. Then, I'm not sure of the time frame, but the OCTOPUS was in there at some point right about that time, and I was involved in testing and maintaining the equipment that we put together. You know, the PDP-6, first, and then the PDP-10. Then, somewhere in there, I got the AEC Technician Scholarship and went to San Jose State and got my Bachelor's Degree in Electrical Engineering and then came back to the Lab. I guess that must have been 1969.

GAM: That's marvelous. I would be interested in your, I'd say, candid memory of the difference in LARC logic and DEC logic as far as the "This is how you'd put a machine together". The UNIVAC and LARC were decimal machines, while the PDP-1 was a binary machine, and there was quite a difference.

JN: Yes, well, the arithmetic units of a decimal machine have to be far more complex. In the LARC they really had to play some games on "how do you do division and multiplication." For example, they stored several integral multiples of a value and they had a doubler; they stored two times the "multiplicand" and then they had a doubler; so, if you had two times the value, you could double that and get four times the initial value. Really faster than a regular multiply. Then, the way that they pathed it, if you needed three times you added the doubled value to the single value. Then, there was a five times complement value. So it was a pretty sophisticated arithmetic unit, obviously, that's why the wiring error crept in there. Then the DEC machine was a binary computer and they didn't even do much to speed up the divide and multiply.

GAM: Right, they had a divide step and a multiply step, one binary bit at a time.

JN: Yes, but in the LARC, you had a twenty-two-digit multiplication and division and in decimal. It was very sophisticated. It was a lot of fun, it really was.

GAM: Looking back on it now, do you feel a preference for either style?

JN: Sure, the decimal machine is so complex, and so much larger...

GAM: And hard to maintain.

JN: Well, I don't know that it was hard to maintain, except there was just more of it, whereas the binary machine is much more efficient.

GAM: We used to call the PDP-1 our romper room machine. We were like kids learning all this stuff; we threw everything on that little machine. We had an IBM printer eventually and an IBM card reader. Do you remember the up-time card reader when we first started with the PDP-1? It read two thousand cards a minute and when it jammed the cards went into a great big fountain eight feet high. That was when we learned the value of sequence numbering. That was the first machine where we really had some fun on the displays and that sort of thing. They had a little CRT we could play with and it was just great.

JN: Oh yes, there were a lot of things that went on there. I remember the family days; it was always the star of the family days because there were so many things involved there.

GAM: Yes, well you could show the power that you could bring to bear on a simple machine and make it do very strange and wondrous things.

JN: I guess one other thing that you might really think about is the memory that we were involved in. In the LARC, we had 20,000 words of memory,

GAM: 30,000?

JN: We increased it to 30,000. Each memory box was quite large. I'm guessing they must have been sixteen or twenty feet long, something like that, and probably eight or nine feet tall, and two or three feet deep. Later, with the PDP-10, we started purchasing units that were just a single bay, but now we get more memory on a single chip than you can get on an entire bay.

GAM: Yes, I remember those things. Well, after the PDP-1 and the OCTOPUS and all the things that went on with that, there was some point where you left all the maintenance work and went on to something else?

JN: Yes, right. I went to San Jose State and got a Bachelor's Degree and came back to the Lab and worked in a group for awhile doing some design work. Then I left the Lab and went to work for Hewlett Packard. Actually, now that I think about it, I was involved in sort of the birth of another machine, the HP-3000. I was the project manager for the manufacturing release. Now they had another project manager who oversaw the design, there were two of them that shared that. Then they went off to some other quarry, but to get it working, to get the environmental tests, and get it all documented and get the last glitches out of it and get it from the lab into manufacturing, that was my job. So I was involved in the birth of the HP-3000.

GAM: That's a great machine.

JN: Yes, let me tell you a very interesting thing happened, very strange. Hewlett Packard is usually very conservative in what they do, and the designers made estimates on the capability of the machine, how many terminals they could put on it. They felt they could have real-time, time-share, and batch, with thirty-two terminals. The machine that we produced and sold was choking at about five; we never ever had real time. The machine was never sold with real time. So, Hewlett Packard being the type of company that it is, went out to everybody that had ordered and everybody that had purchased a 3000 and told them that they could cancel their orders and they would take the machines back. It was really a disaster and everybody that worked on the project felt really bad and they were really unhappy about the situation. But a really interesting thing happened. The batch of the people that had them ordered, sent them back, they cancelled their orders. The people that had the machines, nobody paid any attention, but they ordered more, which is strange. It didn't meet the performance that we said it would; however, it was better price performance than was available. It took Hewlett Packard some time to realize what they had done, that it really was a good machine, that maybe they'd overstated the case, but indeed they were getting more orders from the people who owned the machines, which should be the proof of the situation. But they didn't recognize it immediately, it actually took a couple of years before they realized it and the situation sort of cleared up and they started putting more into the HP-3000.

GAM: Well, I think that the people who made the estimates are the real, not culprits, but the people who made the errors. The misunderstanding of the nature of real-time versus time-sharing versus batch, I mean, we are barely able today to handle that mix of problems on machines much larger than the HP-3000.

JN: Yes, they had done a sort of a seat of the pants guess at what it could do.

GAM: Yes, but the real fly in the ointment was the operating system.

JN: Yes. Well, I think they are getting to be fairly stable now in some respects. Actually what we did, and I was involved in trying to improve things a little bit, is we tried to put more of the operating system into the microcode. That would speed things up.

GAM: Well, Jack, one can see, thanks to your recollections, that being an engineer in the early days of computing was an exciting job. All you guys just exuded enthusiasm, but these days, things are more systematized and it looks now, like there is less freedom to explore. It's a rougher situation that we have right now. OK, we will stop at this point and I want to thank you for taking the time to share some of your memories.