An Interview with Sam Mendicino
SM = Sam Mendicino
GAM = George Michael
GAM: It's July 22, 1996, and we are interviewing Sam Mendicino, one of the
Computation Department managers from the earlier days at the Lab. Sam,
why don't you begin by telling us where you went to school and how you got
hired at the Lab and what is your degree, things like that.
SM: Let me state first that I was not a manager for many, many years. It was just
the last few years. Before that I did real work. Lets see, I was hired in October
of 1958. Hans Bruijnes and Dick Von Holdt hired me. I started out working
as an Applications Programmer for Sid Fernbach and Frank Bjorklund who
were working on the optical drop model of the nucleus. I showed some
interest in the innards of the computer rather than the applications so I think it
was Von Holdt, or Sid, moved me to Dorothy Monk's group. Dorothy Monk
had a pretty high-powered group there. It included Ken Tiede and John
Hudson, and a couple of other people, and they were working on a thing called
K-3, which was a compiler that had superscripts and subscripts. It took three
cards to specify a line. I worked on that project until it sort of fizzled. I guess
because it didn't produce a compiler that was competitive with IBM's early
FORTRAN compiler. It was cumbersome with three cards per line.
GAM: Kent Elsworth and Bob Kuhn among others started that.
SM: I was then transferred to a group under Hans Bruijnes, but I forget what it was
called; let's call it Language Development. What was happening there was
Dave Storch, George Sutherland, and I were working on doing lab-specific
modifications to the IBM monitor system and the IBM FORTRAN. George
Sutherland and I, specifically, worked on the IBM FORTRAN compiler,
which was written in assembly code. I forget the name of the assembler.
It was really very hard to work on. There were
all sorts of techniques which smart programmers at IBM used to produce all
sorts of tricks that sometimes took days to figure out what was going on
to make a modification on it without ruining the compiler. Somewhere
in that process, George and I decided that this would be a lot easier written in
FORTRAN. That's where the germ of that idea got started at the Lab. I think
it got started for FORTRAN right there. We discussed that notion with Hans
and he sometimes was able to see quickly the value of an idea. I don't mean
that offensively. Sometimes he was not willing to try new stuff, but other
times he was. So he gave us the go ahead on that and I think within four
months we had a working compiler. It didn't implement all of the complicated
statements, but it was basically enough to be clear to Fernbach that we had a
real tool there. The value of that tool at the Lab was this, basically: Sid was
buying a new machine, it seemed to me, every six months. They weren't
mostly just follow-ons, they were different machines and we needed a way to
move a compiler and the applications that were written for that compiler onto
the new machines very quickly. They were coming in so quickly that if you
didn't get on them quickly, they weren't used. We got more support,
we got a few more heads, John Ranelletti and Rich Zwakenberg were two of
them, and we were moving FORTRAN compilers from one machine to the
other fairly easily. And upgrading the thing as we went; we were putting in
things that only later compilers had, like address statements, and cliches,
which were like macros. Also structures, breaking up memory in ways other than
the word boundary restrictions that were there. Those were very useful, in
fact, in writing the compiler itself. They became useful new versions of the
compiler; we started using those statements for data tables, saving memory
and things of that sort. Then, I think, by 1963, there was an effort at the Lab
called GOB (Ed: an acronym for Generous Omnipotent Benefactor; also the
reverse of the Russian work for God), which was to produce a time sharing system.
It was, I think, modeled after the MIT MULTICS (Ed: and the UCB Genie project), and it
was being written in assembly code with macros. Hans' group had grown and
he'd added a few more people to it. He set those people to work on
implementing GOB, that early time-sharing system, using our FORTRAN
compiler. That work included Pete DuBois, and a few other people who were
added to that system group. It wasn't very long, I think a couple of years,
before we had a time-sharing system: The early system which lead to LTSS.
GAM: That's FROST?
SM: FROST was the first one, right, and then we went to LTSS. Then I started
writing loaders, very complicated loaders, for those days, using the compiler.
In fact, I left the compiler project and went into writing all sorts of tools for
system work, which were used by application programmers. All that was
good for what we were doing at the Lab. Things caught up with us, though:
We were, by this time, incompatible with the world and, I think, we would
have done better if, in the mid-70's, we had switched over and
started using things like UNIX rather than hanging on so long to the
non-standard stuff. When we did all this there was no standard stuff. We were
working on the edge of this field, a lot of those developments were original to
the Lab group, at least as far as I could tell, but now it doesn't really matter.
The time came when that line of work should have been phased out and a
moved to the manufacturers' standard operating systems. They had caught up
with us and in some specifics, gone beyond. Then I became a manager. One
thing led to the other and I became a manager. I still contributed ideas,
but it was mostly managerial work.
GAM: What was your first assignment as management?
SM: My first assignment in management was as a Group Leader. That was still
working management; the group leaders worked in those days. But, my first
assignment in real management was Division Leader under Bob Lee, who
became Department Head after Sid Fernbach. Then Ranelletti became
Department Head, I think in 1982 or '83, and I remained Division Leader for a
while, then became Deputy Department Head under John. Then, when
John got promoted to Deputy Associate Director under Bob Borchers, I was
made Department Head of the Livermore Computing Center (LCC). I did that for
about four years and then was replaced as Department Head and spent two
years just doing what I wanted. A little research here, a little hacking there,
and then I retired.
GAM: Quite an adventure. Then, of course, I guess it's easy to remember the things
you liked when you were "in the trenches". Like writing FORTRAN
FORTRAN (meaning the FORTRAN compiler written in FORTRAN). That was a great thing.
As I recall, there was this fellow from
England who produced this "Encode/Decode" feature that you could build
into FORTRAN and change a statement from one thing to another. Do you
remember that? His name was Pyle.
SM: Yes, I remember that. I don't know if that's the same "Encode/Decode" thing
that got added to our FORTRAN compiler. I think it was, but the
"Encode/Decode" was added to the Livermore compiler before IBM did it. I
frankly forget what the devil we used that for, I think the structure statement
GAM: I expect that's probably true.
SM: What "Encode/Decode" allowed you to do was to deal with memory on a
non-word boundary basis and that's what later structure and character
statements in the Livermore FORTRAN did. So I think we eliminated that
from the compiler after a while.
GAM: So, when you got moved into management and became a Division Leader,
you replaced Dave Pehrson?
SM: Yes, right.
GAM: Did that take some accommodation or growing into?
SM: Oh yes, you know wise-ass here becoming a Division Leader: He thought he
knew everything about management and people. I started falling all over
myself. You try to deal with people in the same way as you dealt with them in
the trenches and you found that when you talked to people you hurt their
feelings. Because now you are the boss and somehow what you said was
supposed to mean more than it did when you were in the trenches. It took me
a while to understand that.
GAM: Do you remember telling me that once you get into management the people
won't talk to you anymore?
SM: Yes, that's right. Well, you know, they literally saw you as something else.
Now, I never felt that way about Sid or Hans or John Ranelletti or any of the
others, because I dealt with them on the same basis that I dealt with
everybody else. They were the kind of people that liked that and could deal
with me that way. So I never really understood that managing people was
different than working with them.
GAM: I'm afraid it is, and it's hard to quantify, but you've uttered a great
SM: I got to the point where I was very careful about what I said and spent a lot of
time thinking about how a particular statement might be taken. Dreaming all
sorts of different images of what it could mean.
GAM: Well, you had experience dealing with Sid Fernbach, Bob Lee, John
Ranelletti, Bob Borchers, Gus Dorough, Walt Nervik. Do any of these people
stand out in your memory now?
SM: Well, I would have to say by far that Sid Fernbach and Bob Lee, (which
would surprise a lot of people), were standouts in my view. Sid for his style
of management, his willingness to take chances and his ability to see good
ideas and where they might lead and to protect you while you were doing it.
Because the pressure from Application Groups who thought the money that
they put into your budget was to be spent on exactly what they wanted; not
new stuff. The only new stuff would be done by them; we were just there to
provide tools. Sid stood up to that and so did Bob Lee. This is not to criticize
the other people, but it was, in my view, more of an issue in the days that Sid
and Bob were leading the department. John Ranelletti was in my view, the
manager's manager. He understood political correctness, he also understood
computing, in my view. He gave me lots of freedom to try new things in the
System Division that had to do with networking and multiple computer
GAM: Well, on who's watch was it when it was in your division that NLTSS,
whatever we first called it, saw the first light of day?
SM: Well, that was something that I started under Bob Lee and continued under
John Ranelletti. And it was, from a design point of view, very modern: It
wasn't just an improvement, it was, I thought, a giant step forward in modern
operating systems. The problem occurred when too many far out ideas got
thrown into it too quickly and it became un-implementable. What I mean by
un-implementable, it never got to a point where it worked well enough to get
the Livermore user community to commit to it. Although we did put it on the
machine, we had nothing but trouble because of its complexity. We hadn't a
single programmer, and we had some very bright ones, who had an
understanding of everything that was going on in that system. It felt like, from
the Division Leader point of view, that we had a tiger by the tail and we
weren't going to contain it. I think it was after a year or two of that kind of
environment and I think a real hostility from the user community that we
decided to move to the manufacturer's operating system.
GAM: In a way it's tragic, because none of the manufacturing systems had anywhere
near the capability of the NLTSS.
SM: Yes that's right, they didn't. But, they worked.
GAM: In a sense, NLTSS didn't have any of the friendliness of the manufacturer's system.
SM: Yes, when we put the manufacturer's system on the first machine, it was a
CRAY operating system, we breathed a sigh of relief. It went on real quick: It
should, it was only the Cray version of the UNIX operating system. People
moved to it and the user community quieted down and it was clear to me that
that was the right move. Maybe a little late, but the right move.
GAM: Frankly, I don't agree. I think the right move would have been to incorporate
the operating system into NLTSS. Because it had the right structure, the right
vision. So it didn't have the user interface, that could have been fixed.
SM: Well, the trouble was there was not a core of people around who understood
how to deal with that operating system. NLTSS had been implemented in
such a way that there were little sub-groups of programmers around who had
responsibility for stuff and they had not been managed as a group of people
working on one thing. There were lots of internecine battles going on and
under those circumstances, my feeling was, it could never be brought to
successful operating stage.
GAM: I think you're right. There's certainly no way of disproving it now, one way
or the other.
SM: Well, I think we gave it two years, and had numerous meetings with those
people and the person responsible for those various groups to correct that
problem and it never got corrected. It never really got fixed. All we got were
promises that it was going to happen in the next month or two. I had heard
those things many, many times.
GAM: Well, you sort of have had two real careers. In the first, the highlight in some
sense, was the development of FORTRAN FORTRAN. You got to throw a
lot of creativity at that. In the second, do you have a thing that you're pleased
with, that you remember well, when you were a manager?
SM: Well yes, I think NLTSS, as an operating system, as a concept, was a
highlight. It was not successful, not finally successful in the sense that it was
put on a machine and accepted and extensively used by the Laboratory. But,
as I remember it was a system that led by two or three years stuff that is
commonplace now in the industry.
GAM: In a sense it's commonplace now, but they haven't really caught up you know.
The need for big codes seems to have fallen by the wayside somewhat.
SM: Yes, an anti-highlight is the environment at the Laboratory became such that
trying new things of that scale in computing was completely discouraged and
not possible after a while. Not possible to stand up to the funding
organizations and I guess that's true for a lot of organizations, not just the
GAM: Do you remember any particularly exciting things that happened relative to
our procurement policies while you were in management?
SM: While I was managing? Well, I never had responsibilities for procurements in
the sense that Sid Fernbach did. Procurements were moved higher up in the
management chain by that time. I think they were done at the AD level. You
know procurements got spread out; we were not bringing in a new machine
every six months like we were in the 60's and 70's. Sometimes it would take
us several years to procure a machine, I think in large part due to the
procurement policies of the Federal Government. They became more and
more rigid and spread procurements out to the point that by the time you got a
machine it was almost obsolete. There were a few procurements done while I
was managing that I contributed to, but they were done at a different level in
multiprocessors. We bought a set of 20 or 30 IBM machines that we were
going to use as a cluster. That never really took off because it never got
supported. The idea was to bring in these 20 or 30 small machines and hook
them all together and let the manufacturer's operating system do the work.
The idea of putting one application on such a cluster was supposed to be what
happened there. It never happened. In fact, one of the discouraging things at
the Lab was that in procurements we were always out looking for
multiprocessors and when we got them, nobody did the multiprocessing
work. I know it would take a lot of effort, but you'd think that a group that
spent the money to bring in a multiprocessor would also spend the money to
make good use of it. But it was always the idea, well, this is not quite the one
we wanted; the one up the line will fit the effort and as far as I could tell, it
never got done. There were a few brave souls that went out and put a code or
two on them and multprocessed, but generally they were used like the large
machines instead of a multiprocessor. The highlight I remember while I was
still working, we got the STAR in and for all the criticism that Sid Fernbach
took over the STAR, that machine got used as a stream processor by several
large codes and paid for itself. It never became the big time-sharing machine
that was envisioned. But it was a good machine, it was a groundbreaker, I
think it was one of the machines that lead into the modern era.
GAM: I think you're right. I think the problem, correct me if I'm wrong, that the
management encountered at the Lab about the STAR, was not one STAR, but
two STARs. They could have tried getting one and learning about it and
learning about vectorization, but two of them, I claim, hurt the Lab.
SM: Yes, I think that STAR system involved a lot of politics and egos in
mismanagement. I think there were several people who didn't manage their
egos and should have known better.
GAM: Well, you know, it's not possible to rehash all of that. But there were lots of
pros and cons about the STAR. The STAR was not the model of reliability
that people had grown to expect out of the CRAY 1 or something like that,
any of the Seymour machines in general. They all had trouble, but the STAR
had more trouble.
SM: Yes, it seemed that that was the point at which Los Alamos took the lead, in a
sense, over the Lab in machine procurements. They were able, maybe
because there wasn't ego involved, to step away from the STAR and move on
to the CRAY, while for various reasons, the Laboratory seemed unable to do
GAM: That's quite true. But the Los Alamos people cancelled their STAR contract
by claiming the compiler, which they depended on, didn't work. I know that
because I heard them talk about it. Sid saved CDC in his own way by getting
the two STARs; I think I've heard that also.
SM: I think Sid had a bit of a messianic view of himself.
GAM: He'd been right so many times.
SM: But not only that, he was responsible. That is, the National Labs were
expected to foster computing and in doing so help to keep fledging computer
companies that were doing good work and advanced work alive. Keep them
healthy. That's what I mean, there was more of that in the STAR procurement
than just whether the machine was best. That was one of the major issues and
I think Sid got into trouble inside the Lab because he took that view. There
were some people in the Lab who's view was if we have trouble with it or if
there was something a little better out on the horizon, then screw that
particular company and let's jump to the other one irrespective of any other
consequences. That's a short-term view.
GAM: Yes, it is.
SM: Sid had the long view.
GAM: Another unfortunate aspect was, in a sense, the meddling of A Division. We
uncovered several applications for which the STAR was perfect. We did a lot
of stream calculations, but they weren't of interest to anyone at the Lab, they
were correcting satellite imagery and things like that. The STAR would have
eaten that alive - and special sorting programs. No one in A Division thought
the Lab should do that because that wasn't a weapon design.
SM: Well, yes that's what I meant. The organizations that were putting up the
money had the view, "It's our money and the tools should do what we want
done." Overall I would agree that the majority of the resource should be given
over to them. But to dictate which good applications could or couldn't go on
based strictly on what their work was, was probably too restrictive and
shortsighted. But that's a problem the whole country has. What I hear is our
major corporations have a short-term view of the bottom line, like every year,
whereas in other countries like the Japanese government, have a long-term
GAM: One of the ironies is that the people who lead that long-term view, MITI, in
Japan, are an agency that was formed by the American Government after the
SM: Yes, we also showed them how to build cars, didn't we? Sent a General
Motors Engineer over there after the war and he showed them how to do all
GAM: They followed that guy with this quality circle thing. He's revered over there
and we didn't pay any attention to him here.
SM: He was a General Motors executive, wasn't he?
GAM: I don't know, could be. That's interesting. You didn't mention this, but I will
just fill this in and see if you agree; first of all, you went to Ohio State and got
your degree in Philosophy?
GAM: Then you came to the Lab having been hired by Von Holdt or Bruijnes or
SM: Right, in those days they would hire someone with an English degree, there
were a number of people in the Computation Department who had English
GAM: Roger Fulton had a degree in History.
SM: I was in Philosophy. In those days, there was no such thing as Computing or
anything like that. I think what happened was they gave me a test that had
some logic and association testing. I scored a hundred on those tests and Von
Holtdt said to himself, I guess that someone who could get a hundred on
thinking that way can do this job. That's the way I got hired.
GAM: Yes, he was a great person. Well, I'd like you to add things if you can think
of them, otherwise we are done and you can look at the typescript when it's
ready and change anything you want anyway you want.
SM: OK, I have a publication or two if you're interested.
GAM: Those would be very interesting and we can add them to the typescript when
it's done. Any other things you think of jot them down and we can add them
later. Well Sam, thanks for taking the time to reminisce about the early days
in the Computation department.
For information about this page, contact us at: email@example.com