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
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
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
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
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
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
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,
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
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.
For information about this page, contact us at: email@example.com