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 replaced it.

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 management truth.

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 services.

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 Laboratory.

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 that.

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 view.

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 war.

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 this stuff.

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?

SM: Right.

GAM: Then you came to the Lab having been hired by Von Holdt or Bruijnes or which ever.

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 degrees.

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.