An Interview with Dave Storch
DS = Dave Storch
GAM = George Michael
GAM: I'm talking with Dave Storch on February 18, 1994. Dave began at the Laboratory many
years ago. Dave, why don't you start by telling us when you came here?
DS: I came here in February 1959. In 1959, I was still finishing up school at
San Jose State. I started as a computer operator. I got my degree that
quarter, in the spring of '59. I was a computer operator on the Univac One,
which I believe left the Lab about the same year, maybe early in 1960. I don't
remember�I think it might have left in 1959.
GAM: Pretty close to that, yes.
DS: I also operated the IBM 704s and 709s.
GAM: Did you work with Tom Wilder? Do you remember him?
GAM: He and Bob Price? They'd probably left by then.
DS: I don't remember either one of them.
GAM: Well, no matter. I was just curious. You certainly were interacting with
Cecilia Larsen, though.
DS: Oh yes.
GAM: She's a great, great person.
DS: Yes. Oh yes, I still get birthday cards from her.
GAM: Same here. So you operated the SCICR on the Univac, do you remember that?
You had to rewind the tape, and get past the errors and so on?
DS: I remember the printer on the tape drives giving a lot of trouble. They
used these heavy metal tapes like measuring tapes�stiff tape, very, very
GAM: It was oxide-coated metal tape.
DS: You wouldn't want to drop one on your toe.
GAM: And then you went on to the 701?
DS: I don't think I ever operated the 701. I operated 704s, including one that
we were renting time on in San Francisco. It was in the Bank of America
GAM: Well, we didn't get our first 704 until 1956, so, yes, you could have been
DS: Yes, the machine we were running on up there was probably the first 32K
setup I'd seen. The ones that we had here had 8,192 words of memory�36-bit
words. That was a 32K machine. We hauled boxes of tapes up there, and ran the
thing in the middle of the night. I was always operating on the owl shift, so
it was kind of quiet, except for the printers.
GAM: When did you transition to programming work?
DS: I think it was probably the summer of 1960. I was in operations for about
a year and a half, so sometime in 1960 I went into programming. Hans Bruijnes
may have been the overall supervisor of the operators at that time. I think he
was in charge of operations.
GAM: I will interview him later, and we'll get all that straightened out.
DS: Yes, I know he would occasionally show up there in the middle of the night
just to see what was going on. I think he found me fixing paper jams on one of
the printers a couple of times. But he brought me into programming as a
GAM: What kind of programming did you start with? I mean, were you writing I/O
routines, or overflow routines, or what?
DS: I think we were probably doing I/O library routines at the time initially.
I did a tiny bit of applications programming. It's the only applications
programming I've done in my whole career here, for a physicist whose name I've
forgotten. That was just for a month or two. I think we were primarily
working on the I/O library.
GAM: What language were you working were you using then?
DS: It would have been assembly language at that time for the
IBM�possibly the 709 or 7090. It think we were
still on the 709.
GAM: That was the so-called Monitor? That was the operating system?
DS: Well, the initial operating system was no operating system�you walked up
with your card deck and stuck it in the on-line card reader, read it in, ran
it, and probably dumped it to tape. It would be dumped to magnetic tape at
that time, and go away and get printed somewhere, and be analyzed. We
implemented the Monitor batch processing system initially on an IBM 709. We
would do off-line card to tape.
GAM: Yes, I remember that.
DS: Input decks would get stacked up on this off-line card reader. We'd
go card-to-tape with that, then the tape would be run on the 709 at our
scheduled time. Well, that was certainly an advance over the old way of
reading each card deck in. That system, I believe, was all in assembly
language, and I think the system originated at some other site, like possibly
an aircraft company. Boeing or somebody, I think, might have had the initial
Monitor concept. I don't know, I'm not completely sure of its origins. But we
did develop it, and run it here, and add features. So it was really the first
batch processing system here at the Laboratory.
We were also involved with the Stretch�the IBM 7030�at one time. And I
worked with George Sutherland to do a cross-compiler for that machine. This
was really a competitive effort, because I believe Bill Mansfield and Barbara
Schell, and I think Norm Hardy's wife, Ann Hardy�I think they and Bill
Mansfield were working on a compiler for the Stretch. Anyway, George
Sutherland and I developed it with Hans' encouragement and blessing. We
started a competitive compiler effort, where we essentially translated the
assembly language output of the IBM. I believe it was the 709, possibly�it
could have been 7090 or 7094�but one of the IBM compilers. We translated the
output and actually got one code running on the Stretch. I'm not sure what
happened ultimately. The project kind of faded, I guess. I don't know whether
the others finished or whether our other compiler got going, whether IBM
produced a compiler for the Stretch, or what. We did work on the Stretch for
GAM: Well it sort of faded, and was eclipsed by the 6600's arrival a couple of
years later. That changed things.
DS: That's right. The 6600 really had a tremendous impact here. It must have
been 1964, would be my guess, when it arrived.
GAM: Yes, that's right.
DS: Before that, we got the Control Data 3600�two of them�which were
installed in trailers outside of the machine room, near Building 162, which is
now gone. Let's see, earlier we also worked on a Control Data 1604.
GAM: Yes, that was Seymour Cray's first big machine.
DS: Yes, I think he started with the 160 possibly.
DS: But the 1604, I guess, was his first big computer.
GAM: Everyone who programmed on that machine liked it.
DS: Yes, it was a fun machine. The 3600s were kind of fun, too�I think all
the flashing lights were exciting. The 3600s, I believe, were interim machines
for the 6600, because I think the 6600 was originally supposed to be here in
1963, according to our Lab paper. It was a 1963 machine, but I guess it must
have been delayed for a year or so. So we got the interim machines. We had
quite a bit to do with the software that was put on the 3600s. I think that
was the beginning of our so-called FORTRAN-FORTRAN, our compiler written in a
high-level language. Ultimately it became LRLTRAN and CHAT. Well, I was
working on the I/O libraries for that and also on an assembler.
Bernie Thornquist and I wrote the Ultimate Assembler, which was used by the
compiler. It turned out not to be the "ultimate assembler," but that's what we
called it until it was abandoned. It was table-driven, and would assemble for
four machines that we had in the tables�the PDP-6, the 6600, the 3600, and
possibly the 709, probably 7090.
Anyway, we had four machines that we could assemble for, and the output of the
compiler at that time was assembly language. And our assembler was the last
pass in the compiler for quite a while. But, eventually it was replaced. We're
kind of jumping around chronologically, but I guess you'll put it all
GAM: Yes, that's no problem.
DS: The 6600 was the beginning of the time-sharing system at LLNL. It was
called GOB (Generous Omnipotent Benefactor).
GAM: Right. That was done by Norm Hardy, Bob Abbott, Shig Tokubo, Cliff
Plopper, Ed Nelson, and others I can't remember now.
DS: Yes, a number of them worked on that.
GAM: Well, it caused a lot of friction at that time. Hans kept trying to put
the Monitor on, and he did.
DS: I remember a historical meeting
GAM: Tell us.
DS: I guess this was a supervisors' meeting in Sid Fernbach's office. Sid,
Clarence Badger, and whoever else was in the administration at the time were
having a meeting�not us workers. Hans came out and brought me into this
meeting to hear the announcement by Sid. I guess that the Monitor was going to
be put on the 6600. This was a big event planned.
GAM: I should say.
DS: We did put it on there, but, ultimately, the time-sharing concept sold
itself. We became converts, and did the first time sharing system in a
high-level language. It was really a rewrite of the GOB system.
GAM: Was this FROST?
DS: That was FROST, yes. 
GAM: So FROST was a rewrite of GOB, but in FORTRAN.
DS: It was supposed to be functionally pretty much equivalent, certainly
preserving the time-sharing concepts�time-slicing concepts�that were
implemented. But it certainly made it easier to maintain and develop when we
got it into the higher-level language. You moved along faster, and it was
easier to modify. We were more productive with a higher-level language. We
still had to do some assembly language for the PPUs for I/O processing, but we
would handle the I/O on the 6600. I think the PPUs actually did the
time-sharing swapping and context switching.
GAM: The PPU did, yes.
DS: Yes, on the 6600. In the 7600, that control moved to the mainframe. But
those were interesting times, too, developing the operating system and
continuing the compiler development. I guess I should mention working with Sam
Mendicino and George Sutherland.
GAM: On the compiler compiler?
DS: I shared an office with them in Building 162, down near the fireplace. It
was near the center of the building. Initially, at least, I think there was
only one phone in the office. And that's where I developed the habit of
answering with my name. I do that to this day. Even though that phone number
belongs to me, and the caller was trying to call me when they dialed that
number, I still tell them that they've gotten me. When we shared a phone we
kind of had to do that�pass it off to whomever it was really for.
Well, Sam and George did work on the compiler compiler for a while. He
probably went into I/O libraries�I'm not sure chronologically where that
happened. You know, it was all involved�the compiler had to have I/O
libraries, and so we're really all working together by moving the libraries.
GAM: So you spent a great deal of your time in the I/O library world, then?
DS: Yes. Even in the days of the CDC 7600�1969 to 1970�my I/O group at that
time was responsible for the I/O driver portions of the operating system. We
did the lowest level of drivers and PPUs for disks and tapes, and so on, and
also did the interrupt handling routines in the central processor of the 7600.
That part of the operating system was still in assembly language�the interrupt
handling stuff was�it needed to be very tightly coded and efficient.
Compilers couldn't get the efficiency that you needed at that time. We had to
be efficient both with memory and with time on those machines, because we
didn't have that much memory to work with.
GAM: Well, was it your perception that architecturally the 6600 and the 7600
were difficult because they didn't have enough of those things that time-share
DS: Actually, both the 6600 and 7600 had bounds registers. You could protect
users from each other. They were not allowed by the hardware to step on each
other. They couldn't store outside of their range, so the 7600 and 6600 really
facilitated time sharing, because they did have the hardware features that you
needed to protect users from each other and from stepping on the operating
system as well.
I think the 7600 was made more difficult by the two-level memory. If Seymour
had been able to build that machine with just a small core memory, and did not
have to give us the big memory by doing with LCM, it would have been a lot
easier to handle it. It made life more difficult. You couldn't execute out of
the large core memory. You had to move code into the small core memory in
order to execute it. You could have data in either place. But it did make
life harder; in some respects it was easier on the 6600 to do an operating
system and manage user codes. But the 7600 was fast, it had a bigger memory,
and was a more powerful machine, so it was the next step in technology.
GAM: But we lost the ease that building the operating system had. Did it
return in Cray 1.
DS: Well, we kind of got it back in Cray 1, back to a one-level memory. The
operating system that we put on the Cray 1 was based on the 7600 operating
system. We ran a version of that operating system on the 7600 before the Cray
1 arrived. We went back to a one-level memory, and modified this operating
system, so it didn't worry about LCM. It was managing just one kind of memory.
And to some extent we got it debugged before the Cray 1 actually arrived on
site. So we had things working pretty quickly when the machine came in the
GAM: Great. Well, now, that means we've in a sense leap-frogged, because one
of the big changes in your career was leaving LCC (Livermore Computer Center)
and coming over to coming over to the Magnetic Fusion energy Computer Center being
established at LLNL. When did that happen?
DS: That was probably in the spring of 1974. I have an original organization
chart of the Computer Center behind you on the tack board here. You can see
there aren't very many names. I guess there were probably four programmers at
the time�Barry Howard, Paul Lund, Harriet Coverston, and me. Art Mirin was
our physicist. This chart is a little bit later�this is not at the exact time
that I came, because Harriet Coverston and Paul and I all came here to CTRCC at
that time. It was after Harriet had left, and then Barry Howard came, and so
it was probably spring.
I think the official starting date for this Computer Center was something like
March. Sometime in March 1974, I guess, the memo went out announcing the
formation of it and John Killeen as the head of the Computer Center. I think
it was in March of 1974. We're about to have a twentieth anniversary of the
Computer Center, but Hans and Dieter were working on it earlier than that.
They were working on the project possibly as much as a year earlier. But it's
close to twenty years from the official formation of the Computer Center.
Initially we only had partial use of the G Machine, which I think was our
original 6600. I think it was Serial 1�6600�was that the G Machine?
DS: So our computing resource at that time was part of the G Machine.
GAM: You had some PDP-10s and PDP-11s in here for communications and stuff like
DS: Yes, our initial procurement involved PDP-10s. And, let's see, we had a
6400. Our first big machine was the IBM 7600, and we got a 6400 supposedly to
front-end the 7600. Then we had a PDP-10 here. At our major sites at that
time�I think four or five remote sites�all had PDP-10s.
GAM: Yes, and each had a PDP-10 and PDP-11s.
DS: Yes, we initially leased ground lines for communications. And then a while
later we installed the satellite dishes here and at the remote sites. The
dishes are gone now.
DS: I assume it's because they just cost too much. You know, most of the
decisions are economic here. And the land lines have gotten better, and I'm
not sure. Certainly people still use satellites�they keep putting up
satellites. So I guess also the fiber optics stuff has gotten high enough
speed and reliable and the land lines are the way they're going now.
GAM: Yes. Well, at present will you hook to one of these remote sites�is it
over the Internet or over its own leased line?
DS: Most of it's over its own leased line. We are connected to the Internet,
but probably we'll need to get more detail from guys like Jim Leighton. But we
do have our own network to most of the major sites that connect. The smaller
sites can come in through various paths, including dialup, or by dialing up to
the closest major site.
GAM: Do you have any estimate about that sort of thing? You have these four or
five major sites, maybe more now, but how many individual users are there
around the country? I mean, you're hooked up to Japan.
DS: Japan and there's some in Brazil.
DS: I'm not sure about Australia.
DS: I think England is on, and probably Switzerland.
DS: There must be some in Germany.
DS: Well, I guess we probably keep track of over 4,000 users at all of these
sites, but active users are probably in the 1,000 to 1,500 range. A lot of the
4,000 users are fairly inactive.
GAM: Well, I imagine that the arrival of workstations and larger personal
computers and so forth has had some influence on the population.
DS: More people are doing more things on workstations in their offices. If
they don't have a huge problem that just overflows the capacity of their
workstation, then they can do it there.
GAM: Your Macintosh is more than a Univac.
DS: Yes, it's pretty amazing�the speed and the memory when you compare them to
the machines we had in those days. I guess I have the equivalent of 2 million
64-bit words on my Macintosh at home�17 megabytes. So, it's as big a memory
as the Cray 1-S, the second Cray that we got here at the Computer Center. I
don't know if it can crunch numbers as fast, at least as fast as the Cray.
GAM: But, you know, you consider the time that a person invests�maybe
overnight he's getting what he ordinarily would get in two or three minutes,
but he has to fight like hell to get those two or three minutes on a Cray.
GAM: He just sets it running overnight, and when he comes in the next morning,
he's got his results.
DS: Yes, you just work on his code, and it's always there to respond to him.
When the big machines get really busy, then things get sluggish, and you start
getting frustrated. And if you're just running it on a machine in your office,
you get response. It's always there.
GAM: Are you persisting or continuing in development of I/O library kind of
GAM: What are you doing now?
DS: Oh, I'm doing system administration kinds of things. We don't even do our
own operating systems anymore. We adopted the vendor operating system about
two years ago�UNICOS. So, the time sharing system that we invented
twenty-five years ago�
GAM: Is now on the shelf, yes.
DS: On the shelf, waiting for the appropriate time to completely bury it, I
GAM: Well, one never knows what's going to happen in that sense.
DS: Yes, we really don't do systems programming anymore. There are very few
people around who actually flowchart or program things. A lot of it is just
maintenance or integration of existing software packages. You do have to still
make decisions about how to run the system. You've got to adjust parameters.
You still want to avoid idle time on the mainframes. You'd like to have them
doing useful work as much as possible. I try to keep all of the processors
busy. The mainframes we have now have multiple processors, and I want to keep
GAM: Now these are YMPs?
DS: We have a YMP, a C-90. It's the most powerful mainframe on the floor right
now. We still have two Cray 2s�one 8-processor, one 4-processor. There's an
education machine, which is a 1-processor YMP with 8 megawords of memory, that
is not used by the majority of our users. It's exclusively for education
use�for high school teachers and high school students�to conduct research.
That is shortly going to be replaced by a Y-MP/EL, a newer technology machine,
but easier to maintain. It will have a bigger memory, but I think it is still
GAM: And this education use�this is over remote access?
DS: Yes, it's over dialup access.
GAM: Can any school participate, or do you have to sign up�become accredited
or something like that?
DS: I think any school that really wants to participate is welcome. As far as
I know it's not a contest right now. They're still growing, still welcoming
new users. I think it probably will reach the point where it's oversubscribed,
and we'll either have to get more hardware or limit the access.
GAM: Yes. Well, I think it's a healthy thing to permit these students to poke
into the machine�no question about that.
DS: Yes. It's good for the students. It's good for the teachers, too. That
program is getting more recognition recently, and even getting more official
funding, rather than having to scrounge money here and there. I think they're
getting some official funding, so it will be easier to grow.
GAM: This is the standalone machine? What do you do for storage?
DS: It has its own on-line disk, but it also has access to our CFS storage
system. It is accessible through the network, so these students don't all have
to come out. They could connect to a host that's close physically.
GAM: Yes, the Internet.
DS: Yes, they can come through the Internet. They have the same access that
our regular users do, but the accounts are controlled on those machines. Our
regular users don't have access to the education machine, and vice versa. The
students do not have access to the production Crays.
GAM: Well, that makes sense.
GAM: So, do you have any other memories of highlights of your illustrious
DS: Oh, I guess one thing I remember is going back to Chippewa Falls in the
middle of winter and working on the first 7600 system when they essentially
were still building it. We were developing software while they were putting
the machine together. It initially didn't have all of its memory. They were
still really doing the final checkout of the mainframe.
GAM: That was the first 7600.
DS: It was the first 7600 that was delivered anywhere.
GAM: The Serial 1 was delivered in 1969.
DS: It was 1969 when we were going back there. Yes, the Cray 1 was delivered
in 1978 or so, I believe. But in 1969 and '70 we were working pretty hard on
the machine. We would make trips back there every couple of weeks in winter and stay for up to a week at a time.
GAM: In the winter.
DS: In the winter. I remember it being as much as 18° below at times,
and icy. You'd have to come out and start the car half an hour before you
wanted to leave, to get things warmed up. And they always gave us the worst
shift. I don't know why they couldn't let us work in daytime. They made us
come in at 10:00 o'clock at night till 6:00 in the morning. And we'd go back
to the hotel and try to sleep for a few hours in the middle of the day, with
all the racket and people cleaning the place. We'd try to get some sleep, and
then go out to dinner, and go back at it the next day. Those were interesting
Sometimes the machine would be broken, and you'd go in there. I remember one
time when Les Davis, I believe, asked us if we could get by without X-7, one of
the two registers that you could store data in the memory with. So, in that
case we sat around and read newspapers until they got the machine fixed.
GAM: That's probably the best thing to do.
DS: Yes, you didn't know how long it was going to take, and if they got it
fixed in a half an hour or an hour, you'd get on and still get your shot.
GAM: Well, do you have any memories of the earlier times�jokes, or strange
events, things like that?
DS: I seem to forget jokes immediately.
GAM: Well, I don't mean jokes in the sense of a story, but, for instance, you
fix it up so that some guy gets a funny message from his machine and it just
blows his mind�that kind of stuff?
DS: Oh, I remember somebody playing a prank where you would log into the
machine and it�does this sound dumb�I'm trying to remember�I think it was at
Halloween time. Anyway, somebody did something to the system, I guess, and you
would log in and it would say OCT 31 = DEC 25. I know who it was, too. I
think it was John Hudson and Maryann Mansigh.
GAM: You know, speaking of Maryann Mansigh, when she first started here, they
told her to have the machines�the 701 or 704�to have her assembly listed on
line. And then the printer, the machine's printer, says, "What the hell are
you doing printing on line? Horrors, I say!" And she turned to the machine
console and she said, "They told me to!"
DS: Oh, God, that's a good one! John Hudson is one of the first ones that I
worked with here, actually when I was in the cooler. He was the first
programmer-type that I saw. He came over there and tried to keep us people in
the cooler amused. That was an interesting time, too, in the cooler. I was in
there for about three months; it was in the fall. That was normal for those
GAM: Yes, I believe so.
DS: And I was working on plasma research, I guess�actually, the beginnings of
the magnetic fusion stuff�Sterling Colgate.
GAM: I thought John Killeen had a lot to do with that. He was one of the first
people in the country who did a lot of mathematical simulation of plasmas and
containment vessels�magnetic containment vessels�and so forth.
DS: Yes, possibly. I don't think that I worked with him at that time, although
he was in that building.
GAM: Well, let's stop here.
 FROST stood for Fortran Resident Operating System for Timesharing.
For information about this page, contact us at: email@example.com