An Interview with Bill Masson
BM = Bill Masson
GAM = George Michael
GAM: We are interviewing Bill Masson today. Bill, why don't you start by telling us
something of your background and specifically, when you came to the Lab and what you
were doing and so-forth?
BM: I joined the Laboratory, actually in Berkeley, in 1960. I came to work in August,
1960 in the procurement department in Berkeley and my initial responsibilities were in
dealing with computer-related acquisitions. I was involved initially with the LARC,
particularly the LARC spare parts acquisition, and then the resolution of the STRETCH
negotiations between the Laboratory and AEC and IBM, where we were involved in the
reduction in price from the initial price of the STRETCH down to a much-reduced level
because of it's failure to perform to specifications.
GAM: I remember that.
BM: So, it was through these contacts that I met Sid Fernbach and he asked me to come to
Livermore. I did in 1961 and have been involved in computational activities from that time
till 1990, when I retired from the Laboratory.
GAM: Beautiful! So, you spent most of your time in the Administration part of the organization, we
didn't even really have a Computation Department when you first showed up, Theoretical
Physics and Computation were both under Sid.
BM: Yes, it was a Division at that time, and Sid was basically the Division Leader. He had
two rolls; he had Theoretical Physics as well as Computation and it was a kind of a loosely
assembled group of people. We had a number of what we called Supervisors in those days
and each one had varying sizes of groups and, of course, applications people and
operations people. And my initial roll was as kind of, well, an assistant to Sid, but then it
was kind of financial management. I was responsible for the budget and for many of the
contracting issues that were then becoming more and more the responsibility of the
Division. In a very early period, much of the computational procurements were
handled by Berkeley, and
GAM: Who was that there?
BM: Well, that was Don Bruce, the procurement manager and then Charlie Blue was made
the procurement manager in Livermore. And he handled procurements for Livermore when
the administration of the two facilities was split. In moving those procurement functions
out to Livermore, I played a key role in that because of my past.
So the earliest assignments with Sid dealt with developing a financial structure. We
had budgets and things like that, but, there was some degree of informality to that. We were
part of the Weapons Program, the Weapons Program funded 99.9% of the computer facility.
So little, if anything, was done, at least in the early days, to support the other programs and
their support was just peripheral to the Weapons Program. As things continued, and after
the early 60's, then, of course, there was increasing dependence on the other programs at the
Laboratory. It never became overwhelming until much later on.
GAM: Well, can you contrast the informality of the early years with the increasing
structuring of these procurement efforts as they went on.
BM: Oh, yes! In the very early days, we had a very easy and well understood partnership
with the AEC, with the University, and with the Laboratory.
It was easy to define needs and, once these were defined, then it was just a total
collaboration to achieve what ever that objective was. So, if you wanted a machine, or
needed a machine, and the Weapons Program could defend it's need, and it's availability,
that is, that the manufacturer was at least developing something in the direction that would
meet your needs, it was a very clear, (I wouldn't say simple) problem, because we had to
convince a lot of people. We had to convince Congress, we had to convince various
elements within the AEC. But, it was a very positive effort, there were few obstacles put
into our pathway. The greatest obstacles that we faced in that time were really the
manufacturers. It's not that they were unable to sell us things, it's just
simply that the technology, their plans for providing things, sometimes did not meet the
schedules that we had set for ourselves. Many of the machines were a little bit late, or quite
late, and slower than what we had anticipated. They had not reached the performance
expectations we needed; even Control Data later on in the mid 60's had troubles. The
compatibility issues from machine to machine were not solved. So, there were delays and
that kind of thing, going on. But, the climate to acquire equipment in those days was
nothing like it is today. It's almost a hostile climate today, as opposed to the period of the
early 60's and the mid 70's.
GAM: Well, I suppose that's a natural consequence of age, but I really feel that the people
they have running around there today, are not imbued with the same kind of missionary zeal
that we all had in the early days. It was, sort of, really exciting then.
BM: Yes, I think you're right. I think that's one of the major issues; the major explanation,
is that in those days the Laboratory had a clear cut mission and those missions were
understood by the people we had a deal with. Even the Congressional staffers that we had
to deal with understood the mission of the Laboratory well. Because of the classification,
there was a relatively small group of
review processes at the Congressional level and, so, the people you dealt with were the
same people you dealt with the previous year and the year before that. So, your history,
your performance, your accomplishments, were understood and appreciated. That's not
necessarily the case today where you have many, many, more committees. Many, many,
more people that are looking at various aspects. Within the DOE structure and from the
very beginning of the DOE organization as opposed to AEC, things changed and they
became much more regimented, they became much more subject to, I wouldn't say critical
review, I think they became subject to review by people who were considerably more
disinterested than they were in the early days.
GAM: Yes, in that Washington connection, can you outline or describe how you guys
interacted with these congressional committees?
BM: Well, in the early days, most of our interactions were with the controller of AEC, John
Abadessa, and he had a great deal of influence at the congressional level. And so, it was
almost like the same role that Duane Sewell played at the Laboratory. If you convinced
Abadessa, just as when you convinced Duane Sewell, things would happen. I mean all you
had to do was to inform Abadessa sufficiently as to what your needs were, and to what your
plan was, and your expectations for success, and if he was convinced he sold that to
Congress. And we didn't have to go before a congressional committee and testify, because
John Abadessa would carry that message for us, because of his influence and because of the
respect Congress held for him, those things were done in a rather straightforward fashion.
GAM: But you did deal with staffers and stuff like that?
BM: Yes, we did.
GAM: They come out to the Lab ever?
BM: Oh yes, they had a small, a very small, organization. I can't recall all the names, but
John Kirskey is the one that I remember. He had a small group of people, (today they are
represented by about 50 or 60 people.) He had maybe four or five people that handled all
of the computer tasks for AEC. This is, of course, before the Brooks bill and the other
limitations that were imposed on the acquisition of computers. In the scientific area,
computers were considered to be strange beasts, but something that was acceptable. Once
they became more prevalent in the administrative area, they took on a different rule.
Congress became fearful that they would be abused. That they would increase in numbers
astronomically, and people like Brooks, Jack Brooks from Texas, thought that they had to be
controlled. And once those controls, as they evolved out of the Brooks Bill, were put into place,
the freedom of acquisition and the speed of acquisition were slowed down immensely. It
got to the point where many organizations, not AEC so much because of it's scientific base,
but other organizations like the military, in particular. Their initiation-to-acquisition-to-use
was running seven to eight years as compared to the few years, one to two years, that it took
the Laboratory and the AEC to achieve the same things. It was really a very, very, difficult
time for a number of organizations. In fact, it got to the point where many of those very
organizations, the Army and other organizations would come to the Laboratory and seek
ways, or try and examine ways, for us to do something for them, to bypass because
our pathway was so broad and so uncluttered compared to theirs.
GAM: That's interesting, I didn't know that. That's an interesting possibility. We didn't do
much of that though, did we?
BM: No, because we really were very protective of the priviledges that we
enjoyed. When I say that, what I really mean is that we tried to keep our process as clean as
possible. We could have easily enjoyed buying things for other people and taking a little bit
off the top, but if we had we would have lost our uncluttered pathway.
GAM: Your purity!
BM: That's right, our virginity would have been lost.
GAM: Well, Los Alamos did, at least they have always had the DNA computer there. It
always pissed me off that we couldn't have something like that at Livermore, I think that we
would do a better job, but then...
BM: Well, part of it was we felt that we really had to meet our own needs and we tried
not to corrupt it. I think that they were really being abused. That is, these other organizations
because of interference by Congress and by people like Brooks. And so we just really did try and
keep a more pure approach to it. We made enough mistakes as it was, we didn't need to
compound it by any means.
GAM: I understand! What about the relationships, let's see, Sid had a staff that included
you and Wayne was there, but I don't really know anybody else, well, they had a secretary,
but
BM: Well, that really was the organization. Within a relatively short period of time,
Wayne Hudson became Sid's assistant in Theoretical Physics and so he no longer involved
himself in Computational activities at all. So within about a year after I joined, Wayne
Hudson and I became counterparts.
GAM: I understand.
BM: He was in Theoretical Physics and I was in Computation, and so, it was for many
years it was Sid who was Department Head or Division Leader, or whatever you wanted to
call them in that day, and then I was his assistant. Of course, Sid had a number of technical
supervisor's who had various roles throughout the organization.
GAM: It was a fairly flat organization then, right?
BM: Yes, it was. Yes, it was.
GAM: I think that's very good.
BM: Well, clearly, Sid was the head of the Department and there were many people who
made major, major, contributions, but it was easy to deal with a structure like that because
he was clearly the head of the Department.
GAM: Yea, well, you knew where the buck stopped.
BM: That's exactly right!
GAM: So, how about the relationships with the Director's office? What's going on there?
BM: Again, we were somewhat blessed. Because Computation was not an orphan. Sid was the equivalent
of an Associate Director under today's structure.
GAM: yea.
BM: Because he ran the computational activity and answered to people like Duane Sewell
and whoever was running the Weapons Program. And so, he had pretty well, throughout
the Laboratory, full responsibility for the computational activities.
GAM: Yes, I once asked (then Laboratory director) Mike May, why they never made Sid
an Associate Director because, clearly, he doing a fairly effective job, even if I didn't
always agree with him.. He said, "Sid will never be a Director because he doesn't have a
Program," and I wasn't smart enough then to realize that was maybe not the whole story.
The reason they never made him a Director is because he would have overmastered the
other ADs. He was so much more effective.
BM: For years and years, all computational activities were controlled by Computation, it
wasn't until considerably later that even the most powerful organizations got their own
computers.
GAM: Well, I think there were, (I don't mean to leap ahead to a conclusion,) two basic
mistakes that Sid made. One was that he wouldn't pay enough attention to the small
computers; he thought they were beneath his attention. And secondly, he got us two
STARS (CDC STAR 100s) instead of just one and I think that those two situations together
destroyed his empire.
BM: I think you may be right, I know that the pressure for dealing with local computational
activities was not within Sid's realm of interest at all and, therefore, he gave it little or no
attention. His total focus was on very large machines and large scale computations and he
almost resented the diversion of funds to any other activities. That applied to not only the
scientific side, but also to the administrative side and I think the Laboratory could have
fared better in the total computational area if more attention have been given to those two
aspects. The small machines and local computational needs, other than super computers,
and then administrative computational needs which were put off for such a long time. Long
after many other organizations had dealt with their administrative computational activities
in a much more generous fashion than we did. But his enthusiasm for the big machines also
stimulated the supercomputer market and if it hadn't been for that almost single-mindedness
the process would have been slower. You can fault the STAR's, you can fault other
activities but if they hadn't been undertaken, the process would have been slow.
GAM: I agree, I'm not faulting STAR's; the STAR was a very important machine; it just
didn't perform well on our big design programs.
BM: Yes, I know that. I think that Sid felt very strongly that he didn't want to abandon
Control Data and the STAR effort until it was a success. But, on the other hand, I think we
all now understand and appreciate what the CRAY's effect could have been. We would
have been better off if we had gotten the first CRAY 1 instead of Los Alamos. Because it
would have matured much faster here. It was just one of those technical decisions that was
based on Sid's intention that the STAR was going to work and he put all his energies into it,
just like he put all his energies all the other projects that he tried to support.
GAM: Can you just generally describe an average procurement process, from the point
that you discern you need a machine and you write a spec.
BM: In large part, much of the new acquisitions, that's the acquisitions of a new series
machine, were stimulated by the awareness that something was coming into being and Sid's
most frequent comment was that the shopping list of computational needs was so long that
all you could do was chip off a little bit each time to expand the ability to make the
computational calculation. So, maybe it was a larger mesh or a finer mesh or whatever it
was you had to deal with it in small increments. So, if something came along that looked
like it met those kinds of needs, then he would go and promote it. He would promote it first
to the Weapons people and, because of their insatiable appetite, they were ready listeners.
Super computers, or large machines, were the only thing they had lived with. We hadn't yet
evolved to the point where they could get it on their desk so they looked to the supercomputer
as the solution to their requirements, and they were an eager audience. Once that
promotion started inside it was very easy to define; the next set of items on that long
grocery list of things you would like to have but couldn't meet with the current capabilities.
The process, then, was to write a justification and convince the people in Washington, the
John Abedessas, and others later on, that you had that need. Once that was approved, then
the formal negotiations that established the contract, the specifications, the delivery, and so
forth, were started. In most cases, much of that was already being discussed. That is, we
would pursue the process in kind of a parallel fashion. One was to get approval from
Washington, the other was to start finalize the process with the manufacturer. In many of
the early transactions, we weren't dealing with a competitive process, we were really dealing
with whoever had the biggest, the best, the fastest available. In certain respects, it was
easier because few people came out simultaneously with an equally capable machine. They
kind of leap frogged one another so you could pick your candidate, and there was only one,
and then you would just concentrate on them. So, you would take these parallel paths. One,
the Washington path to get approval itself, the other to deal with the technical issues, how
the machine would be structured, whether it would meet your needs, what it's price would
be, when the delivery would be, those kinds of things. Once you got the approval, then all
those things you had been doing kind of in the background could be brought into the
foreground and they became the focus of the transaction.
GAM: Well, you set somebody to writing specs too, like Stu Stone, or I, for that matter,
occasionally wrote specs.
BM: Yes, but you see the last real set of specifications we wrote were for LARC. We
defined that machine and Remington Rand went out and built it. But STRETCH was an
IBM machine, the CDC 1604's, the 3600's and the 6600's, were Control Data's machines.
The 7600's were also Control Data's machines. The STAR was a Control Data machine and
the CRAY's were Cray's machine. So they were defined, really, by somebody else, and
molded by us. They were within a framework that would meet our needs and maybe we
skewed them somewhat, but primarily we were dealing with somebody else's design to
which we matched our problem. And so, the writing of specs really dealt with much of the
peripheral stuff. Things like mass storage and graphic systems and those kinds of things
where we tried to fill those special niches within our network that weren't really readily
available in the marketplace. Or somebody would come out with a product and we would
say "well, that just about meets our needs, but not quite", so we wrote a set of specifications
that would meet our needs. But the large machines, I can't really remember anything that
was done based upon "our specifications" that somebody else built it. It was really putting
in specifications in a contract if it was a solicitation that would allow what we wanted to be
responded to.
GAM: Well, you made the distinction between the solicitation and what?
BM: Well, of course, many of our acquisitions were really sole-sources. So that would be
the alternative, a sole-source acquisition. The sole-source acquisitions were based on the
fact that, for example, the 6600 was maybe 10 times faster than anything else in the
marketplace. So, we did not try to write a set of specifications that would allow the 6600 to
be bid and then allow somebody else to be bidding. We just simply said that we wanted the
6600 and we went out and got the 6600.
GAM: Yes, do you think that is possible today?
BM: I don't think so.
GAM: Even if we have machines that are so clearly superior to the run of the mill?
BM: No, I don't think so and I think it's to our disadvantage too.
GAM: Yes, I think that's just true.
BM: Because, I think what you do is slow down the whole process and then often you get
what is sometimes second best.
GAM: Indeed! Well, in the normal day-to-day things, I'm sorry to be jumping around like
this, but these thoughts just occur to me. Did you guy's use Sid and others around you to
meet once a week, or every day, just to discuss strategy or whatever else might have needed
to be discussed?
BM: We, of course, had regular staff meetings. But, many of the issues were just day-to-day
operational issues. Particularly in the early days, when a startling new machine was
evolving, there was kind of a single purposeness to it. There were few objections to these
new toys, and so there wasn't a great deal of debate. Most of the efforts, or contests,
occurred shortly before delivery. After the manufacturer was well along in the development
of it and we started testing it and developing operating systems for it, that kind of thing,
then the actual contests or the discussions went on between the technical people; as to
direction, course of action, that kind of thing. Those were generally technical arguments or
issues that I wasn't directly involved in that much. I was really more responsible for the
operational activities.
GAM: Well, apropos of that, can you describe the budget process? How did you get to
where you said that's the budget?
BM: Early on, again, it was a relatively simple process. We told the Weapons Program
how much it was going to cost to run the machines that they wanted and they put up the
money. We didn't have to solicit support from any other organization because they put up
all the money. When I first came to the Division, my first budget was 7.1 million dollars.
When I left, it was something like 61 million dollars, just to run one center. That's not the
two or three centers we were responsible for, that was just the weapons center. As the user
base became more complex and more diversified, we really got to the point where we were
negotiating with the Weapons Program to make room for other people. That was a process
that was very slow and very painful. The Weapons Program really didn't want to give up
very much of the machine time. But they also wanted to get it for nothing and so they really
couldn't have it both ways. The cost of the operation was reaching a point where they
literally had to have other participants and there were people clamoring for that
involvement. Of course the restrictions on the closed machine, that is, the classification
issues that we had to deal with, precluded many people from using the machines. That, of
course, opened the door for many of the small supporting systems that evolved throughout
the entire Laboratory. There were many groups that couldn't get into the computer in a
direct fashion, they had to do it in a very indirect fashion because of the lack of all the
networking capabilities that evolved after 1964 when we got the 6600's and started
developing the Octopus network and what not. From a budget point of view, we shared the
resource always, of course, deferring to the Weapons Program up until very recently. The
largest portion of the resource went to the Weapons Program in one fashion or another. Of
course, today it's considerably less than it was back in the 60's and 70's and early 80's when
it was really the only game in town and there was a difference.
GAM: Well, I remember everyone had to go the Weapons people to get time, even though
they were supporting the Weapons Programs themselves. Engineers, Chemists and so forth.
BM: Well, the Weapons Program took advantage of the fact that it was their money and so
they did not really allow us to sell time to their own Program. They allocated for
themselves what was going to go to those Programs and that gave them control. If we could
have treated Chemistry and Test Program and others as individual customers, we would
have been able to deal with them in a different fashion. But, the Weapons Program took a
different course and they basically said if they are going to support our Program they are
going to have to come through us to get the time and we'll allocate the time to them. And in
that fashion they did control the allocations of time.
GAM: It was a fairly relaxed thing though. I developed a whole bunch of diagnostic
programs for their testing of their devices and I merely told them that I was going to do that
and they said, "Swell, do it."
BM: Yes, and I think that is why that system worked for as long as it did. They were not
generous with their time, but whenever it was of interest to them they would readily give up
the time. They had no reservations.
GAM: It's interesting in all these interviews, there's a great flavor of nostalgia.
BM: Yes, the good ol days, it always comes through.
GAM: Well, that's good, really good. It's just amazing.
BM: I spent so much time doing basically the same kind of thing, I was a Physicist and
then I was assistant to the next Associate Director and then the next Associate Director and
the next Associate Director that had Computation and I saw this change in the attitude from
the AEC to ERDA to DOE and, God, I'm glad I'm out of that place.
GAM: Yes, I think that is what lot's of people are suggesting. Well, let's get to some of
these superlatives. Was there a particular procurement that stands out as the most
interesting or the most difficult or most pleasing? Something like that?
BM: Well, I think the whole series of early acquisitions with Control Data, that is, the
6600's and 7600's were exciting times. We had so many of them and they were almost
spilling over at times. Each one had it's own character. The first 6600 was a real adventure,
but the ones after that kind of cascaded so quickly that we seemed to be doing only that.
There was finally enough money to buy them or, later on, lease with purchase options and
the other kinds of financial restructuring, or financial shenanigans that we went through to
acquire them were very entertaining. But it was a period of very concentrated activity. I
mean we seemed to be doing a procurement constantly. The Test Program was starting to
be more and more controlled. They went to underground testing, of course, then the amount
of computational needs were increasing dramatically and it was an exciting time. Later on
it became very challenging to get the procurements through the process, they were much
more complex. The documentation you had to put together was much more broad. You had
to deal with many, many other issues than you did initially. Early on our justification was
primarily based upon a classified description of a particular problem. It might even be an
event, a test, a particular test that had some unique complexity. So you wrote a classified
technical justification and then wrapped it in an envelope and, in affect, dealt with the
administrative and contractual issues. You sent it off to a limited number of people,
because only so many people had access to that kind of information and you were finished.
Then, later on, these things were reviewed by so many facets of DOE and then by so many
committees within Congress that they were not classified documents, they were general
documents. They had added so many facets to the justification process that it read like a
book as opposed to a nice, neat, little tight argument that focused on one issue. You kind of
had to solve the problems of the world in one document as opposed to just one simple event.
GAM: In the middle 60's, we got the first 7090 or 7094, whatever it is, and another one that
was coming up at Christmas time from Los Angeles. The truck went over a cliff or
something like that? Can you tell us about that?
BM: I just remember, very vaguely, the failure on a transportation problem. The machine
was damaged, but it was replaced shortly.
GAM: Yes, that incurred for us the undying hatred of the University of Minnesota.
BM: Yes, because they were scheduled to get the next available machine. Back in those
days, there was a priority system that allocated scarce resources. One of the scarce resources
in the United States were major computer systems. We invoked the priority system
whenever there was a danger that a computer delivery would be too late to support the Lab's
test program. We had the privilege of imposing a DX (Defense priority) rating on a given
computer procurement. That meant that we could move to the head of the line and that's
what was done in this particular case, and the next person normally scheduled to get the
machine, lost it. The unfortunate thing is that after we
had done it for a few times, other people decided that they had comparable needs. Because
everybody wanted to impose them we had to make special pleas to AEC. AEC carried a
great deal of respect within the Congressional structure in those days. It was a very small
organization, not the bureaucracy it is today, and they were considered to be a highly
technical, scientifically oriented organization. Their level of respect was really held in high
regard. And so our DX rating was more DX than others.
GAM: Well, the real adventures I sort of enjoyed was the procurement of the IBM 1360 -
the photo digital store. That was a pretty interesting thing, it was something Norman and I
had schemed about for some time and it was a very elegant piece of machinery. You were
involved in that.
BM: Look at how long it lasted! More than 10 years! I mean can you imagine anyother
mass storage system that was conceived, built, and installed, and then worked for more
than 10 years, and at its departure was still at the near forefront of it's technology?
(Note added: The Photostore was delivered in 1967, went into full operation in 1969 and
was still fully operable when it was shut down in 1981 because spare parts were no longer
available.)
GAM: Well, it's still, in many respects, ahead of its time. Very few of the systems that are
available today have all of the features that the photo store had. But, they are certainly
getting bigger now, much bigger. I always liked to tell the people who visited the Lab that
when we put that thing on-line it doubled the memory capacity of the planet earth.
That was quite an achievement in 1967, but now, of course it's much different.
BM: Of course, not only that, but the reluctance of the people at the Laboratory to get off of
it. I mean, can you imagine, after 20 years of test results the people said "we need em, we
need em." It's capacity was just incredible, particularly when you consider its off-line
capacity.
GAM: Yes, you could put stuff on the shelf. Well, a great deal of that is credited to IBM,
but there is also great credit to Garrett Boer, in particular, and John Fletcher and
Clarence Badger, in general. They did a really good job putting that thing on-line and
making it trustworthy, so to say.
BM: It was so trustworthy that people didn't want to get rid of it.
GAM: Well, it met the need. It clearly can't today, but it certainly lasted longer than
anyone had a right to expect.
BM: Well, I think that those are the kinds of things, like the mass store that we did because
of a real need, and they were very important contributions to the emerging computer
technology.
GAM: Well, the TMDS was another thing that was a great success that is still used 30 years
later.
BM: Yes, those, I think, are really the major technical contributions that Computation made
to the industry as a whole. Those things never would have happened if the Laboratory
hadn't driven their development.
GAM: That's true, that's true.
BM: I think that the supercomputers would have been driven. What I mean by that is
without the operating system effort that we put in the 6600's, they would still have been
populated across the United States as quickly they had been. Because the need for fast
computation was felt all over the country and others quickly built parts of simple operating
systems, whereas our time sharing system was an envelope, or umbrella, that made it very
easy for CDC to just increase the 6600's popularity very quickly. On the other hand, from a
technical point of view, I think the things like the mass store would never been
accomplished if it hadn't been for the driving force of the Laboratory. There were other
areas like that where we really made major contributions too. We made major contributions
in the supercomputer area too, obviously. I don't think many organizations would have
taken the chance that we took with brand new products. That was something that gave
stimulus to the Control Data's and the CRAY's, and others, to do things because we were
willing to take some risks.
GAM: One of the things I think is a little sad, though maybe I'm over exaggerating, is the
lack of recognition that Seymour Cray has generally. He's really a national treasure. In our
case, since 1962, he's been the principal supplier of computers to support the Weapons
Program, not only at the Laboratory, but all over the Country.
BM: Well, actually, he's been the major contributor to supercomputing period. I mean one
single individual.
GAM: He's an amazing guy.
BM: I think there is that appreciation from the older hands at the Laboratory, but I'm not
sure that today many of the new computer scientists even know who Seymour Cray is.
GAM: Well, you may be right. We have strayed from the path in many respects. I'm not
sure if there's other things that we might talk about or anything like that.
BM: I'm not sure there is really anything that we haven't talked about. There are many new
events that have occurred, but I'm not sure they have any meaning to anyone other than you
or me. Part of the history of Computations is it's recent history and that's something I don't
think we want to ignore. There were a number of people who came later on who have
contributed to the evolution of Computation, Gus Durough is one. Gus, when he came in,
had to be exposed to computational activity. But, once exposed. he really made an effort to
carry on many of the ideas that Sid had fostered very strongly. For example, Gus was very
supportive of the creation of NERSC. (originally called MFECC), that could have fallen by
the wayside. There was a lot of resistance from the Laboratory, and outside of the
Laboratory, to bring that facility into Livermore. And, Sid played an enormous role in
achieving that, in fact he was the primary mover of that. But, with the new Associate
Director, that momentum could have been lost.
GAM: It's been suggested that putting it at Livermore and taking the stuff from inside
and converting it so it would run at MFECC saved them 5 years.
BM: Yes, I think that is very possible. So, if the momentum hadn't been maintained then, I
think, that would have had an effect on that large customer base that is now represented by
MFECC.
GAM: Apropos of that, I am reminded of another thing that Sid did which is rather
ironically interesting. He got those primitives at Los Alamos to start using time sharing.
He got our time sharing system down there and they took to it like a duck to water.
BM: After great reluctance, and frequent failures on the part of their own activities.
GAM: Yes, I understand, but now they are avid. In fact, it must be admitted, they did a
much better job of documentation than we did. Which is fine.
BM: They have actually done that in a number of instances. In their own history, they
maintained a well-defined history of their computational activities where we haven't done
that. We maintained millions and millions of lines of records, but they are basically
meaningless from a historical point of view unless you go through and analyze them, and
try and build all of the framework for which those documents had some meaning. I know
that is what your trying to do now.
GAM: Well, really, I've found out that I'm an amateur at the process. I'm just trying to
save some verbal history from you guys. Some of the guys are already dead. Bob Pexton is
dead, Chet Kenrich from the UNIVAC days is dead.
BM: One could take each one of those stages in the evolution of the computational
activities and base it on machine acquisitions, or whatever you wanted to do, or the
restructure of the department and it's evolution. You could do a great deal of work on each
one of those aspects. All of those records exist. There are stacks of those pieces of paper.
GAM: Carolyn Gousey was trying to do that.
BM: Yes, but that process died. I think it's unfortunate that the IBM antitrust suit occurred
when it did. Because, there was a whole series of actions that were literally boxed up and
set aside by the Justice Department edicts and the legal actions taken. Because we had to
preserve those records, those records were treated as kind of sacred and we did not do
anything, even though at that time Los Alamos was trying to build a relatively large group
that was actually writing the history of their computational activities. We didn't and we
should have, because the task would have been easier for you now if we had done that.
GAM: I suppose, you know you could just make the excuse that it's much more fun to do
than it is to recall, you know. Apropos again, of a remark you made earlier, Sid didn't pay
too much attention to the administrative aspects of computation or getting administrative
computational support. Did you guys have any computer assistance for the things you were
doing inside the Department?
BM: No, not really.
GAM: I remember I would see people running around with secret plots of salary curves and
stuff like that.
BM: Yes, we did many, many, things by hand. We really did, compared to today. Today,
there are so many readily available tools, but the financial management was done basically
with pencil and eraser. Never in ink.
GAM: That's amazing, Are you going to say the operation was simple enough so you could
do that, right?
BM: Well, yes, right, in part it was. We actually did the salary calculations by hand.
Today, of course, you wouldn't even consider that, but we really did all financial
management by hand. For salaries we would make the calculations on percentage of
increase and, what not, by hand and on an individual basis. So we didn't make any effort to
computerize many of our own operations. Our focus was on scientific computing. Now
that's what Sid's focus was, he was not intolerant of it, I'm sure he would have given me as
much latitude as I had asked for, but I guess I became indoctrinated too. It was sacred
ground that you didn't tread on. What I was referring to earlier, I was really talking about
the administrative activities at the Laboratory. Computation had an opportunity to assume
responsibility for administrative computing at the Laboratory at one time and Sid said,
"No." In effect he said, "I don't think we ought to do that; it's a meaningless activity and it
would be a diversion of funds." I think that slowed that process across the Laboratory and
it was to the Laboratory's disadvantage and to Computation's disadvantage. I think we
would have been better off just making that an extension of the computational activities and
letting people develop the expertise in administrative computational skills as well as
formulated scientific skills. It had a major impact later on, when there was such a broad
diversion of resources to personal computers and whatnot. Those could have all be under
the control of Computation at one time, as opposed to being a part of Engineering, and a
part of the Administration.
GAM: Bulkanized, as we say.
BM: Yes, that's right. If Sid had faults, this was one of them. He was very single-mindedly
focused on scientific computing. That's a fault only from the broadest point-of-view. It's
not a fault from the scientific point-of-view, because that's who really benefited from it.
GAM: Well, you know, when we had our memorial symposium for him, one of the things
that came through pretty clearly was that he was extremely highly regarded outside the
Laboratory. Much more than inside, to be honest. People from all over the world still
recognize him as a pretty interesting pioneer.
BM: Yes, he certainly was that. He was an incredibly interesting man to work with.
GAM: I want to interview Sid's wife, Leona Fernbach. She worked on
my original computation back in 1953 and 54. It's an amazing thing, it was a tight little
group.
BM: Actually, it was a pretty small organization for a long, long, time and then it grew to
be a very large organization. Then it was split up and now I hardly even recognize it.
GAM: It seems that no one wants to look at the lessons of history, at least with the idea
wanting to learn from them. That biggness is not good, etc. and certainly administration
ought to be focused a lot more than it is. Well, does anything else occur to you?
BM: No, not that I can think of.
GAM: Well, I'd like to thank you for coming by and doing this interview.