An Interview with Bob Hughes
BH = Bob Hughes
GAM = George Michael
GAM: It's May 9, 1997, and we are interviewing Bob Hughes. Bob,
can you start by saying when you got to the Laboratory and where you came
from?
BH: OK. I graduated from high school in 1944, during World War
II, and was immediately drafted into the United States Army. I pretty much
had to sit out the war, basic training and that sort of thing. When I left
the military service in 1946, it was difficult getting into college, especially
the top schools, if you didn't have an "A" average or something of that
nature. Because of the GI Bill, there was a big rush for enrollment. Finally,
I was accepted at Duquesne University in Pittsburgh, Pennsylvania, as a
freshman. The next year, I transferred to Western Reserve University in
Cleveland where I recieved my BS degree in 1949 or 1950. After Western
Reserve, I worked on my Masters at the University of Michigan for a year.
They had a one-year Masters program there. I finished that year and I ran
out of money and the GI Bill, so I decided to visit a friend from the army
who lived in Oakland. I came out and bummed off him for a while until I
got a job. I worked at odd jobs like at the Post Office. And one day, a
friend of mine, Bob Abbott, told me about Lawrence Livermore Laboratory
where he'd just begun to work. I asked him what he did and he said he was
programming a computer and I said, "Well, come up to my apartment and tell
me what you do and how you do it". I looked at it and I said, "Well, I
could do that".
GAM: What year was this?
BH: This would be 1954. That's when I was hired. But I came to
California in September of 1951. I came to California straight from the
University of Michigan. And I'd been here for three or four years or so,
but I couldn't find a meaningful job. Outside of a letter carrier or working
with people unloading a truck or something. So, finally, I heard about
the Lawrence Livermore Laboratory though Bob Abbott and I went to the University
of California for an interview and the person was impressed with my mathematics.
I had a pretty much an "A" average in math, or close to it. But, anyway,
within three weeks I was invited to Livermore by Doctor Sidney Fernbach
to join his group.
GAM: Great. What was your first job?
BH: Well, when I got my security clearance after about two months,
I went up to see Doctor Fernbach and said, "Here I am, what do you want
me to do?" And, in a classic way of assigning things in those days, he
said, "Well, just walk down the hall and find something to do." I ran into
a group of Physicists and they asked me if I would be interested in working
on a Monte Carlo simulation.
GAM: Whom did you talk to?
BH: It was a group of three Physicists headed by Ed Leshan. I
forget who the other two were.
GAM: Was Art Biehl was one of them?.
BH: That may be. The name doesn't ring a bell, though. But, anyway
they said, "We need a computer program to build a Monte Carlo neutron transport
simulation. Do you think you'd be interested in something like that?" I
said, "Sure". I went back to my office and said, "Well, Hughes, you've
really gotten yourself into trouble now because you've got to admit that
you didn't understand a word that man said." But then, I thought for a
few minutes and said, "Now, wait a minute, Monte Carlo. Monte Carlo. Oh,
that's a gambling town, statistics; oh, this is the statistical methods
for determining the outcome of an event, you know. I thought about it
a while and I went back to talk about this further, and they had all the
equations set up and things I might need to turn this into a computer program.
So, I guess the moral is, if anybody asks you if you can do something,
always say "Yes".
BH: So, I set up a Monte Carlo program for them. And, later on,
I also set up a novel way of handling neutron cross sections. I'd write
out a cross-section file from the data on IBM cards, and I would use that
to compute the probabilities that a neutron would go a distance "Delta
X" through a region containing some material "Y". It's based on an initial
configuration but, anyway, it was a fascinating experience and it went
into production. That was for the IBM 701, which was hand coded for the
machine, and when the IBM 704 came out it was still a production code,
but now we could write it in FORTRAN. Later, as you know, we were short of
computer time at the Lab. And so, one summer, IBM decided they could sell
us a block of time if we were willing to take the 12 midnight to 6 o'clock
in the morning shift to do our work. So, I was sent to New York, and that's
how I gained experience on the 704. We had one too, of course, but I was
sent to New York, several times. I had to go back to run this Monte Carlo
problem for the group of physicists at the Laboratory. One interesting
thing happened: One night, I was given the whole time from midnight to
five in the morning. Since I could run this problem anytime I wanted to,
I had it set up as a production run; where someone else could just run
the problem for me. So, this one night, I got a call from the engineers
that the IBM 704 had stopped while my program was executing. I went in
and found that there was some sort of a malfunction which caused the green
"Run" light to be on at the same time that the red "Stop" light was on.
This implied that the machine was both running and stopped at the same
time. It made no difference to me because my problem was producing good
answers. I ignored the condition. But I was called the next morning about
7 o'clock by a vice-president from IBM saying, "We have a problem here
with your usage." I don't know how much they were charging me an hour maybe
$100 or $200 an hour. But, anyway, I had used about $6000 for computer
time. And they were wondering why this program showed it was hung from
3:00 AM and now who was going to pay for this three or four hours of computer
time? I said, "Well my program worked. What's the problem?" They said,
"We don't know yet, our engineers are working on it." It turned out that
a problem in the IBM 704 logic design, under certain conditions, if they failed
to clear the MQ (multiply-quotient) register, the accumulator got bad
data. If the MQ is not cleared, then you would end up with the machine
stopping, and the red light on saying "I'm stopped" and green light on
saying, "I'm running." I asked the vice-president, "Have you been able
to find anyplace in your documentation where it says that MQ has to be
cleared?" He says, "That's just the problem, we can't find it anywhere.
I've called up our designers in Hartford, Connecticut and Chicago, but
we can't find it, it's not documented." So I was off the hook.
GAM: But, it wasn't your responsibility to clear it anyway.
BH: It was a flaw. They could have put a chip or something in
there to clear the MQ, but it turned out to be an oversight. They did write
it in later on. But, at the time, he said, "I can't charge you because
it's not documented." And my heart went back to beating at the normal rate.
So, that's how I got to learn the IBM 704.
GAM: This has to be the years 1954 and 1955. And around 1956,
you got involved with the FORTRAN Project?
BH: We got wind of the FORTRAN Project late in 1955. Dr. Fernbach
came into my office and said that John Backus was amenable to having someone
from the Lab come to work with him. So, he asked me if I would go and,
as usual, if you don't know how to do something, you say, "Yes."
GAM: That's great. That was a career-enhancing assignment. That's
a really important thing.
BH: That's right. It's amazing how fast you learn what's going
on. In less than three or four months, with the FORTRAN development group,
I became a confirmed compiler advocate.
Well, I say that rather than rambling around, I started at the Laboratory
on my birthday, which was February 23, 1954. I retired on my birthday,
February 23, 1987, for an even 34 years at the Laboratory. And, as I mentioned,
the UNIVAC 1 was still in operation when I started, but I didn't get to
work on it. It was the first large-scale digital computer of the stored-program
type. But the new 701, IBM's first machine, was taking over due to its
superior speed and larger memory.
GAM: It may have been faster, but it kept making errors all the time.
BH: True, you know, the UNIVAC had those duplicated Mercury delay
lines, and they checked everything. Nothing was checked in the 701.
GAM: Yes, the UNIVACdid a periodic memory check every second.
BH: Yes, you fetched the same item from two different places and
compared the results. They had to agree or the machine stoped.
GAM: Yes, but on the 701, there was no checking.
BH: That's known as the single fault error checking chain.
My first job was to develop that Monte Carlo physics code for the 701.
GAM: When you went to the FORTRAN project, did you have a specific
assignment or was it just to go back there and tell them about the kind
large codes we were developing?
BH: No, no, no. Each person in the FORTRAN development group
had a specific assignment. Holland Herrick, for example, was in charge
of all tape I/O; that was his baby. To backtrack, FORTRAN was a table driven
scheme.
GAM: Oh?
BH: Many tables. TEIFNO was a typical table of IF and GOTO entries.
"TEIFNO" stood for the Table of External Form of the IF Number versus its
internal form. There were also "close-up" tables to close everything when
finished. There were just tables, tables, tables. Later on, they discovered
that the way to compile really fast was to collect everything and assemble
it in a single symbol table. But, in those days, we were still learning
how to walk and so, initially, it was a table-driven scheme.
One person, Peter Sheridan, had the responsibility for parsing the computer's
mathematical equation-generating instructions. That was one of the most
important areas of the whole code. And so, in that fashion, each person
was responsible for a specific part of the compiler. Roy Nutt, in Hartford,
Connecticut, handled all the formatted I/O. He was head of the computing
group in Hartford. He took care of all of the background work involving
I/O and input/output statements. And so, each person had a hunk of the
compiler. When I first got there, I noticed that IBM used the closed-shop
technique. You programmed, but you didn't have to see a computer. If you
had a problem to run, you would submit your deck and take your turn. You'd
come back in the morning and the listings would be on your desk. And that's
the way you worked.
BH: I'm forgetting my point here. Everybody had a specific task.
And they knew that I was unfamiliar with their schemes, so they would just
hand me the code listings. They'd say "Herrick has this problem and we
need a flow chart for that". I would read his machine language code and
turn it into a flow chart. Then we could see errors and we could make changes
to the program. So, now he has something that will serve him as a programming
aid without wasting his time chasing around randomly. I worked on what
they called the "first-level" documentation. And I made the biggest mistake
of my life by not bringing a copy of that home. Now you understand why
I missed making my first million dollars.
GAM: Most of us are still working on that, don't worry about
it.
BH: Each person was assigned to a major section of the compiler
and each person had his own set of tables to work with. And I would put
the pieces together and then, somewhere along the line, there was what
we call a "Semantics Synthesizer", where it all comes together into a machine
language code that would run on the machine. It was a fascinating experience.
GAM: It must have been exciting too.
BH: Oh, it was. They were the nicest group of people you've ever
met, all of them. If a computer conference was being held in Washington,
D.C., then IBM would notify us and send the whole group to the conference
and we'd come back and continue working. It was quite an experience.
GAM: Well that's great. And when you got back from IBM?
BH: I should mention that, one day, John Backus, the head of
the group, called me into his office and said he'd like to get my ideas
of what I thought of the project. About FORTRAN and in general. I said
that, "Well, there�s one thing that I worry about; you're only putting out a
main program. There are no user-defined subprograms. At the Lawrence
Livermore Laboratory," I said, "there's some programs with many
sub-programs, but you're just putting out a main code. You're allowing for
system functions like square roots and science and trigonometric functions,
and so on. but we use lots of user defined sub programs, and also, you're
assuming that the program can be memory contained but, we almost never get the
memory contained with the big problems at Livermore, so we use a program
design that can be chewed up into modules. Actually, we almost never
get the memory contained with the big problems at Livermore. He said,
"Well, I understand that but, in this particular
case, I want to prove first that a computer can generate good code, and that
a compiler can be written to generate a good program that rivals the
efficiency that the hand programmer can produce." And he said, "That's
going to be the important thing, I think you can lay it right there."
He said, "Then we can get together later on and add all the other factors
that need to be added in to make it even more convenient. But, I've got
to get over that first hurdle to demonstrate that the compiler can generate
good code, and of course, he was right.
GAM: Also, on your first swing back there, you started the idea
that if a variable's name began with i, j, k, l, m or n, it's an integer.
BH: Yes, and for all other letters, it was a floating point quantity
by default. Well, later on and when we started doing our own compilers,
all those features were added. Different groups came up with different
ideas when produced the second version of FORTRAN. I think even IBM allowed you
to override the i, j, k, l, m, n convention.
GAM: Not at first.
BH: Not at first? OK. And that's what LRLTRAN at Livermore was
all about.
GAM: That's one of the things.
BH: Another was mixed-mode arithmetic. In the first FORTRAN,
you couldn't do mixed-mode arithmetic. An expression had to evaluate to
be a real or an integer. We got around those hurdles by allowing the programmer
to declare any main variable to be integer or real. There was quite a bit
of awkwardness in the original FORTRAN. Using numbers for statement numbers.
You had to number your statements, as opposed to allowing alphanumeric
statement numbers. There were a number of other embellishments, such as
IF-THEN-ELSE logic, In the 1970's, structured programs tried to avoid the
use of statement labels. I don't know if the IF-THEN-ELSE logic was ever
put into the IBM FORTRAN. We put it into ours.
GAM: I think an early real mistake in their first FORTAN, which
induced us to have bad habits, was the three-way branching IF statement.
That wasn't very good.
BH: Oh, sure. Then they introduced IFs where you could have two
branches. Less than or greater than.
GAM: Well, true or false.
BH: Yes, it was a logical step.
GAM: So, when you came back, having worked through this development
of FORTRAN and stuff like that, were you the Lab's missionary for FORTRAN
then, or did you just go back to writing Applied Physics Codes?
BH: No, that got me into the language game. When I got back,
there was a lot of excitement. I got into a Language Group with Kent Elsworth
and Dorothy Monk. With my experience in FORTRAN, they formed the K3 Compiler
Group. We had the three-line input, whereby you could put the variable
on the middle line and the superscripts and subscripts on the line above
and the line below to make it look more like a mathematical language. Believe
it or not, after a year and a half or so, we actually got the thing running,
but I don't think anyone ever used it.
GAM: It was very hard, I tried to use it for my code. You had
to get everything in the right column all the time. That is what was wrong.
BH: Yes, you had to worry about getting everything exactly aligned,
and that was a losing proposition from the start. For a while, there was
fear that mathematicians would not accept standard FORTRAN. For example,
A**B means A to the B power because we didn't have any way to keypunch
AB.
GAM: That's a big concession to the IBM keypunch symbol table.
They didn't even have anything like a square root.
BH: Yes, this was all invented.
GAM: Invented to get around the IBM keypunch?
BH: But there were a lot of efforts.
GAM: So, you worked with Kent on what he called the Kompiler.
BH: Right, we called it the K-O-M-P-I-L-E-R, Kompiler. But it
became the world's second "Spruce Goose".
GAM: How do you mean "Spruce Goose"?
BH: It taxied well, but it never took off.
GAM: Well, we tried to use it, but that input deck was so voluminous.
Basically it was three times the size it should be.
BH: Oh yes, in those days. Yes, it took three cards per line.
That was another problem. If we�d had display tubes, or something like that,
where you didn't have to worry about punch card data, it may have run.
Let's see, in 1960, I did another Physics code for the Remmington Rand
LARC (the Livermore Automatic Research Computer), and I forget what that
was all about. I began doing systems programming on the LARC, our last
decimal machine. The Remington Rand-UNIVAC division, built it for us, and
I did some systems programming on it. I probably converted one of the physics
codes I already had to run on the LARC, either because of FORTRAN or it
being an extra big problem. And I started a special systems program for
the LARC to go between decimal and binary formats. The decimal representation,
for a digit, in the LARC took much more room than it did in an IBM computer
and therefore, their tape drives ran much slower than IBM tape drives.
So we decided to fix it so the LARC could use IBM binary formatted tapes.
GAM: Yes, I remember that.
BH: Well, Jim Moore, the electrical engineer in charge, was assigned
the job of rewiring the LARC tape handler. They rewired the tape synchronizer,
and then I had to write the software for converting the binary data on
the tape to the decimal format that the LARC wanted. But that way, we
got the benefit of high-speed IBM tape drives running on a decimal machine.
GAM: So, you had to write the tape handling routines for the
LARC?
BH: It was what they called the I/O processor, the part of the
LARC that managed all the I/O processes. The I/O commands that the programmer
issued were re-interpreted by my software. Not from the programmer's point
of view, but the electronic signals that came in had to be mapped.
When the Lab decided to buy the STRETCH machine, Dr. Fernbach had me
do a benchmark because IBM had announced that the STRETCH would be 10 times
faster than brand X. And so my job was to take a program that was running
on the LARC and set it up to run on the STRETCH. I did that and published
the test results and gave them to Dr. Fernbach. It turned out that the
STRETCH wasn't 10 times faster than brand X; it was barely a factor of
two. So, in negotiating with IBM, the STRETCH price was cut quite a bit.
GAM: Yes, I remember they couldn't meet their own specifications.
Sid tried to cancel the contract and to avoid that, IBM cut the price;
something like 48%. Actually, they made a lot of money on
the components that they developed for STRETCH and used in the 7094 and the
1401 sustems, and still they could charge all the STRETCH costs off as
tax losses.
BH: That all happened around 1960. Then, about 1965, Sam Mendicino,
George Sutherland, and others were working on compilers for the Control
Data machines. They came up with the first compiler compiler. And so we
really got going big and got to work on our own FORTRAN compiler. We never
did use the manufacturer's compilers. Well, they were there, some people
did but, from day one, we focused on developing our own FORTRAN.
So, from there on in, I sort of gravitated into the language end of
the business, strictly compilers. But I did a lot of other things along
the way. In the 1970s, the UC business group that handled the Lab's administrative
computing, moved to the Lab. And they wanted COBOL, so Pat Gray asked me
to modify one of the existing LRLTRAN compilers to accept and produce COBOL,
I think that's when he became a division leader, and he was trying to satisfy
that group. I don't know how far that got, but I rewrote the front-end
of our FORTRAN compiler to read the COBOL Language.
GAM: Would you say that was your most exciting period then, when
you worked on our FORTRAN?
BH: Oh Yes, it was fascinating, because we knew everything about
everything.
GAM: Oh, I understand. It's a nice thing to have the big picture.
BH: It's nicer to be a big duck in a little pond, than a little
duck in a big pond. The pond got pretty big later on.
GAM: And it's not stopped growing yet.
BH: But it was fascinating. Actually fascinating to me. Because
it was always a challenge. There was always a better way of doing things.
It was never boring. Sometimes you'd wake up in the middle of the night
and you'd want to run out to the Lab and start work on this new great idea
you had.
GAM: Yes, I've done that.
BH: But I also worked on assemblers in the old days. Matter of
fact, I wrote an assembler for Dr. Von Holdt. After everyone had turned
to FORTRAN, he still used my old assembler. And I had one of the first
text alteration routines.
GAM: I thought that was a great thing.
BH: Yes? Well, the Alter would allow you to make modifications
to the existing program. This was a simulated program. You referred to
things by line number. You know, do you want commas here, delete lines
one through three, replace it with the following lines in here until you
see a card marked such and such.
GAM: I made very heavy use of that.
BH: It also made changes in your program, sort of a poor man's
text editor. And it also put out a relocateable binary module that you
could load back into your program. But then we really got to going strong.
We got to the point where we were all LRLTRAN/FORTRAN and had our own compiler
group set up. But I've worked on just about every compiler after they came
along from the time I started at the Laboratory.
Let's see, Sam Mendicino and George Sutherland did the first bootstrap.
You know FORTRAN/FORTRAN. They used FORTRAN to write a FORTRAN file.
BH: And that was a Godsend. The program meant that there were
no more single language programs.
GAM: It grew into LRLTRAN eventually, didn't it?
BH: Yes. That's what I mentioned, at that point around 1965 onward
we were sort of on our own. We had our own language, our own version of
FORTRAN. We were compatible with standard FORTRAN and still had special
features for the Lab.
GAM: I don't remember that. I remember for instance, you guys
had something about the Divide that you rounded before it was completed
or you didn't put it in the hierarchy of operations in the right place
or something.
BH: Well, you'll probably find that in all the conversion estimates,
whether or not you round or not. You probably will find that that's a problem
that won't go away. In one part of the country they are rounding in some
instance, in another part of the country they are not rounding in this
case. That's just an incompatibility in the numbering base. For one thing,
that's in the binary and when you chop a binary bit that's one-fourth of
a decimal digit maybe.
GAM: Right, I agree with that. I thought that it was very important
that all the FORTRAN's had the same behavior.
BH: Well, the different machine word sizes tie you up.
GAM: I guess I understand that.
BH: It's another problem beyond the size of memory.
GAM: There was this guy from England, Pyle, who designed these
"Encode and Decode" statements that re-adjusted the formats so that you
could move iotems from one to the other and back pretty easily.
BH: Well, in the division in each machine you're going to end
up with a non-terminating decimal fraction someplace along the line when
you get past the integer, past the decimal point. Wherever you chop there's
an error, so a given specific rounding procedure isn't going to be any
help. I mean the problem's not going to go away.
GAM: With all this programming, you found time to become a golf
expert too?
BH: Oh yes, in my spare time. In those days, I would only golf
on the weekends, once a week maybe on Saturdays if I could afford the time
or maybe on Sunday or a day off, or vacation; things like that. I never
was a "leave my work to go play golf" type. I was not that much of a fan.
But, as the years went on, it turned out to be the most fascinating thing
in the world. Golf wasn't as popular in those days as it is now.
GAM: But in those days you thought about how you might use computer
programming to interact with the game?
BH: No, but in those days, when you're young you just stop off
on the way home from work. You think, "I'll just play 9 holes on the way
home. You then get home late and stay up half the night. It's a fascinating
sport, I love to play it, and always will. I started playing golf around
1962.
GAM: OK. Did you have anything to do with the STAR?
BH: That was the Control Data STAR, the vector machine, right?
GAM: Yes.
BH: That was sort of a turning point for me. I sort of got out
of the compiler business for a month or so and I started working with the
System Utility Group for the STAR. Harry Nelson was benchmarking the STAR
and had done a lot of work. I guess he was in charge of the system development
there. He came by my house one day and said he needed a utility for comparing
two files, which was a big thing in the computer world. He wanted to make
sure the file they had been keeping around had not changed. He was interested
in getting an efficient code, as opposed to saying "fetch word one, subtract
word two, and record the result". Since the STAR was a vector machine where
you could refer to an entire array with one instruction, there should be
some very efficient ways to do comparisons. He wanted me to find out if
there was some keen or slick way. After a week or so of playing around
and thinking things out, I finally looked at the HEX FF instruction which
was designed to tell you where a subset occurred within a larger set. I
said, "Well, if I make the subset as big as the set, I can compare two
files very fast." What an instruction. It would only tell you that the
files did match. If they didn't, it didn't tell you where the mismatch was.
But that was half the battle because, most of the time, you were only interested
in knowing that nothing had changed. So I hedged that bet. But, if you
wanted to find out where, then it was not efficient. Then you had to look
at it one word at a time to get down to the point where it had failed.
And then look to where you could fix it if you wanted to move ahead.
GAM: Well, you use all the methods that you need.
BH: I was happy about that. I got a one-word program. So, I managed
to get involved somehow with all the machines that came along. But I didn't
do any programming on the STAR; I just worked applications while I was
there.
GAM: How about the STRETCH? Did you work on the STRETCH?
BH: Yes, I worked on the STRETCH, in 1965 we did an LRLTRAN FORTRAN
compiler developed on the LARC and STRETCH for the Control Data 6600. What
we were doing was preparing a compiler for the new machine that was coming
in. I think that was one of the first FORTRAN-to-FORTRAN bootstraps that
came along. I know that Sam Mendicino had a lot to do with that, and I
was working with Sam at the time.
GAM: OK, that's great. What else do you have?
BH: Well, John Ranelletti and I were office mates for years.
In the 1960s and 1970s we were always office mates. As a matter of fact,
going back to the 1950s. After I left the K3 compiler group and FORTRAN
came along, I would work with John Ranelletti and Sam Mendicino in the old
Navy barracks building where we had offices. Sam Mendicino, John Ranelletti
and I were always in the same office. And we worked generally on the same
things including the first bootstrap, Sam was in charge of that first bootstrap.
So, by hook or by crook, I got involved with just about every computer
that came through the door, in some capacity or another.
GAM: Did you ever develop an opinion for which computer you liked
the best?
BH: I think the computer I liked the best was the Control Data
6600 or the 7600.
GAM: That's pretty much a general reaction.
BH: I loved the assembly language. The instructions that you
used didn't need addresses. That was a Seymour Cray invention. Like A,
I, J, K. You referred to registers. If you wanted to store the operand,
it had to be in the correct register; the register which had the pipe to
the memory. You would say, multiply register 1 by register 2 and put the
result in register 3. It was likely stored in memory depending on how you
indexed. It was easy to understand. Matter of fact, I wrote an assembler
for the 6600.
GAM: What else did you work on?
BH: I guess the other item I got involved in was the Summer Institute,
as the technical coordinator for some visiting professors during the summers.
I was involved with this from 1975 through 1979.
I served as the affirmative action coordinator for the Livermore Computer
Center, and I got involved with documentation/education group. I call that
a low point because I got out of touch with reality at that point.
GAM: Well, it's certainly different in the sense that here you
are confronting people from a different discipline who are trying to learn
something about what is going on at the Lab. That's a nice opportunity.
BH: No, no, I didn't mean the Summer Institute. No, that was
great. That was interesting. I was referring to the documentation/education
group. And that part didn't pan out too well. I was in a no man's land.
You don't know what to do. Or you don't know how to do what it is that
you want to do. The Summer Institute was fascinating, and it didn't cost
us much time.
GAM: It was useful letting the visitors learn about things they
they ordinarily run into in their schools.
BH: Well, that was part of the affirmative action program. Allowing
the visiting professors from predominately minority and female institutions
to spend time at the Laboratory and getting to participate in ongoing research.
I would take them all around to the various departments and special seminars.
GAM: Great! Thanks, Bob, for taking the time to share your memories
with me. Your Lab career has certainly been fascinating.
