An Interview with Raymond E. DeSaussure
RD = Raymond E. DeSaussure
GAM = George Michael
GAM: It's March 6, 1995, and we are interviewing Ray DeSaussure. Tell us where you went to school, what your degree was, when you came to the Lab, and so forth, Ray.
RD: I went to the University of California at Berkeley and took a degree in physical chemistry. I think it was in '52 or '53. When I was in the cooler, I worked on the unclassified part of a computer program for something in chemistry. While waiting for my green badge, I was assigned two jobs: One was to work on that Chemistry program. It was the very large code. It was, roughly, 100 equations with 100 unknowns. I had to develop methods for solving this system. That was a tough one.
Previously, on my own, before coming to the Lab, I had worked on solving a series of carbonate equations of about five equations, five unknowns and spent six months on that, which only gave nominal results.
I tried using the same methods on this new code, but the matrix, being so large, made it very tricky. It was the type of thing that if you were half an hour into it and someone opened the door, you lost it. Actually, we worked on this code for quite a few years. Nobody actually went into the matrix again because they had trouble following it. We were able to get good results so they took it for granted that it worked.
The other thing that I worked on at that time actually turned out to be a precursor for FORTRAN. I'm not even sure of the name. I want to say K3, but I'm not sure that's right.
GAM: You mean the Kompiler that was being developed by Kent Ellsworth? It was a compiler spelled with a "K".
RD: One of the interesting things about the Kompiler was the decision to use 3-card/line input. (Ed: This was probably the worst decision that could have been made, but at that time, no one had enough experience or foresight to recognize it.) We kept trying to find out information about this choice, but nobody could explain it. John Hudson, who was our supervisor at that time, said we should simply go ahead as planned. We finally found that there were some experts around the Lab. John promised to run down their names. When they got back to us (there were three of them), it turns out we knew at least as much as they did. So, that didn't do much good either. When I got my clearance, I was very inexperienced. I was assigned to Dorothy Monk's group shortly before she quit. I was working on a new design code that Roland Herbst and Bill Schultz were developing. The first computer we had to use was the IBM 701.
At that time, our job was not only to prepare the input decks but also to actually run the Kompiler. In those days, the programmers would run the computers. We were using punched cards in the input decks, and there was a lot of trouble. They kept changing the equations, so we had to continually revise the Kompiler statements. That three-card system caused us a lot of trouble, but we finally got things stabilized and the work progressed. Eventually, we developed a new job category, "Production Assistant," and an elaborate set of rules for running the computers, so the programmers could get back to working on writing programs and solving equations.
After working on the IBM computers, I shifted to the PDP-1 from the Digital Equipment Corporation. I think my supervisors were first Clarence Badger and then Hans Bruijnes. The PDP-1 was one of the earliest mini-computers. There, I worked with the Eyeball, a digitizing input device. In fact, I started working with all kinds of input/output devices. The PDP-1 was ideal for testing out these things.
One of the main advantages of that machine was that it was very easy to develop interfaces to these input/output devices, and it was better than the big machines because it had a lot of input/output facilities that the larger ones really didn't have. You could adapt these, readily, to codes all over the Lab. People who had smaller problems couldn't get on the larger machines in the Computation center, or they had taken some of their raw data in formats that couldn't be accommodated on the big machines.
All over the Lab, people were using paper tape to save their experimental data, but there were no standards, so we tried to develop our own standards. It was chaos. Every tape had its own format. When people developed their instrumentation, they didn't know anything about standards. In every case, we had to go in and clean up and figure out how to read the paper tape, and then quickly write a small program to map it to the standard. There were many, many codes. We gradually got these methods cleaned up over the years.
We had some fantastic cases. One time—I think in chemistry—they told a summer employee to collect data, except they forgot to tell him what sampling interval to use. He took the very highest speed time limit. They ended up with a boxcar of tapes, but most of the data wasn't usable because they didn't have suitable processing programs for so much data. They had to go back and do the experiments again. That was easier, they said, than figuring out how to read all those tapes. So, I finally worked out a method that solved the problem for them. The trick in doing I/O was in planning general programming strategies that could adapt to various memory sizes. At that time, we were almost always faced with not enough computer memory.
Originally, the PDP-1 had a 4K memory, and then we upped it to 8K. Once, we had a chance to add another 4K (giving us the unusual size of 12K) at the exorbitant price of $40,000. We decided to turn it down. We were determined to make do with "just" 8K.
The PDP-1 had a cycle time of 5 microseconds. It was a very reliable machine and had very good instructions. It did have drawbacks, particularly in the arithmetic handling. It had strange ways of doing that—strange from our point of view. It was actually quite hard to get used to but, eventually, we managed.
When we did I/O, we used the dead time of the I/O to execute fast instructions in the computer itself (at that time it seemed like a fast cycle). We had these long runs, and we wanted to balance the two. It was always a question of trying to see whether we should use more memory to speed it up, or use less memory, thereby slowing the program down.
One of the slowest instructions was division. The location immediately after a division instruction was called a halt. A successful division skipped the halt. When the program got tight for space, we would store constants in the halt location. There were many little tricks like that, that we used.
When we ran the Eyeball, the machine took quite a while to process the number of signals. We could actually have three signals going through the machine simultaneously. Different parts of the I/O and the program got fairly tricky to keep properly sequenced.
At that time, proper control of the Eyeball was very tricky. Fundamentally, the Eyeball was a programmable spot scanner (logically an analogue to digital converter) that used a photomultiplier to measure photographic density. However, the photomultiplier at that time had instabilities that couldn't guarantee that we would get the same reading if we read the same spot twice. To get around that, we programmed the photomultiplier to integrate its sample for a longer period, thereby improving the signal to noise ratio. From a programmer's point of view, this variable logic made for tricky programs.
The PDP-1 had more diverse I/O capability than any other computer around the Lab, at the time. In fact, the PDP-1 blew away the IBM 7094 on tape handling.
In addition to the paper tapes and console CRT display, we had magnetic tape readers, card readers, printers, the Eyeball for digital input and output, and we had some typewriters that were the original prototype for the Octopus remote terminals. There was also a light pen and, later, a RAND tablet.
One of the very interesting experiences was developing on a mouse. We went down to visit Doug Englebart at SRI. He and Bill English had a little device, called a "mouse", that they developed. It seemed like a very nice form of input. So we came back to the Lab and talked to Phil Seaman's, who put together the Lab's version of a mouse.
The first one was large and wasn't very good. It was, sort of, over-balanced, so when you put it down, it sank back to the back wheels. It had two black buttons; it looked more like a rat that a mouse. It always seemed to be staring at us.
Phil continued to refine the design and did a much better job with a three-button model, which was a very good one. One can't help but notice that, at that time, it was easy to work with the other Laboratories. We shared mouse designs. I took one down to SRI and showed it to Englebart and English. They liked it so much that they even wanted the drawings for it. That turned out to be a hassle. The drawings had to be prepared for publication before we gave them to SRI. I had to write an abstract for the drawings. Since it became a document, it had to go through the patent office. I've forgotten all we had to do. There was a ton of red tape before we finally got them the information. As far as I know, that was the first use of a mouse. Credit should go to Doug Englebart contrary to many reports that came out later saying that it was invented somewhere else.
It was fun to show visitors a lot of the innovations we made on the PDP-1. In fact, we used some of them on Family Days. That was one of the pleasures of the PDP-1—we could set it up to interact with visitors. One time, for example, we turned the whole computer into a conversationalist, using the analogue-to-digital converter to sample the visitor's voice. You could then have computers listening and talking to people.
We wrote many programs that were very useful beyond Family Days for debugging other programs and doing unusual kinds of I/O. I wrote a program called The Big Typewriter. It used the printer buffer, which was separate from the online printer. I took letters typed on the typewriter and put them into the buffer. That meant we could do a number of other things with the printer, such as go back and strike over a character, make subscripts and superscripts, and so forth. The result was that we could produce a memory dump, then enter this other routine, type out comments about the dump, and have that come out right behind your memory dump.
Another program I wrote speeded up the I/O for people who used paper tapes. There were many different models of tape readers and various way to read the bits. It seemed that each person had a pet format scheme and, once they had something running, would use the same set-ups all the time. It was a pain to re-enter all these options every time a particular user's program ran. I set up a program to read the first paper tape that had all the decisions we needed and had worked out. The program asked a number of questions online: "Do you want this part?...yes/no?...This part?...yes/no?..." You had a certain amount of time to answer the questions before it automatically went on to the next question. All these settings were stored on the tape. At the end, the program would ask "do you want to run an automatic code using this data?" If you said "Yes", all you had to do was hit the return key and your program would run automatically based on the decisions you had made.
This approach speeded up the process so much that one person, who had complained bitterly about the whole process being too slow, now complained, after he first ran this process, that it ran so fast that he got his fingers nicked by the tape recorder.
GAM: Before we've gone too far, go back to your time with Dorothy Monk. What were you doing with her?
RD: She was a supervisor in the cooler then. She was over John Hudson. Except John Hudson was the one who picked on her most of the time. And Dorothy Monk was picked on royally.
GAM: She was? I always thought of her as connected with the PDP-1.
RD: I didn't really do much PDP-1 work at that time. That came in much later.
GAM: You were doing something else for her?
RD: I can't remember the details other than working on the chemistry group's development and using the Ruby code.
GAM: So you were doing applications programming?
RD: Yes, I was working with someone in my group I can't remember his last name. Shortly after that, Dorothy Monk left the Lab.
Then, again, it was a question of writing for the various machines, each with its own idiosyncrasies. For instance, There was a IBM 704 card reader that was some kind of a pain to work with. We would open the thing and kick the board at the bottom and then it would run again. There would be a few things of that type that we just got used to. I recall being impressed by Norman Hardy's use of the computer.
We did a certain amount of travel. The Lab was always short on computer time because many of these codes ran for 50 hours apiece. My earlier version of codes had much shorter runs. Whenever the Lab could get it, we would travel to these other locations and run on those other machines. This was particularly interesting since it was classified data. We would do it under conditions that would be absolutely deplorable now. We carried the code on tapes over the whole country. One example was when we went to Ford Aerospace. We would clear the room, then set up and run the codes. When we got finished, we would erase the data that was in the computer and carry the tapes away. By present standards, it was terribly lax, but it worked. There was one erase routine called Pink Pearl; we used that to erase the tapes.
Another time, we ran at the IBM Center in New York City. They used to have a center that was all glassed in for computer techs and the public could see these wonderful, large machines. We would go ahead and run these classified codes in front of all the public peering in the windows.
GAM: I heard another story about that. They didn't like your appearance. You were all scruffy, so they put up curtains. Bob Abbott was among the people who went back there and that's what he told me was the rule.
RD: IBM was very straight-laced at the time.
Going back to PDP-1, there was another Family Day routine. One of the very first games to show up—what did they call it? Storm Wars?
GAM: Space Wars.
RD: Yes. We implemented that. That was a great hit. The trouble was that it became such a hit, that people wouldn't get off the machine. They wanted to play all the time. We had to do something about that. We had put several innovations into the code, various things such as the Nova. We would write things like hyperspace where you would jump. We put a security routine on the front, practically unknown then. It would first let you run. You would start up the program, but within a certain length of time, unknown to those who weren't in on it, you had to hit the "RETURN" bar. If you hit the return bar, then it would say "Give official space admiral designation." There were five initial letters. Five words and it would light a light on the central lights. Each light would give you a clue to some letter of the alphabet. You did this for all five digits. If you did all this correctly, you were allowed to continue playing the game. Otherwise the computer just quit.
If the "RETURN" bar had not been hit, the security routine was not started. Instead, the program would start putting zeros into the memory all around the area where you were working. Just erase everything until it got down to the tiniest pocket. It put some of that on tape, or actually the tape directory was always in that pocket. We had figured out a way for the tape to erase itself. All of a sudden, everything went blank. I think you got one big glow before it went blank. When you went in to see what had happened, everything was gone and no clue as to what happened. That worked very effectively.
GAM: I should hope so. Why don't you talk about how you got into this business of showing that small computers were important at the Lab? You know we really had a director who didn't believe it.
RD: That's true. The PDP-1 was given marginal support. Well, one of the codes I worked on, the Ruby Code, seemed like it had a lot more challenging problems. There were some early experiments in graphics that, I think, you participated in.
I tried to do graphics. It looked like an interesting problem. We had done some graphics up to the 704. Very awkward. Hard to program. Didn't look very well. It looked like the PDP-1 had more possibilities. That is why I shifted over to that. As things went along, I also became involved in some of the earlier small computers that came to the Lab.
Some of the other divisions made strong cases for needing to take data with a computer. Originally, they would just use the machines as paper tape recorders. But they actually wanted to have something beyond what. We had machines like the PDP-5, the PDP-8, and PDP-8S.
RD: The 8S was a serial version. We started working with some of the engineers and electronic personnel, who were the ones in charge of these computers on some of the instrumentation problems. I did the programming for them. In the end, most of the electronic controls needed extra development. Some of these units were quite early, too, like one of the first pulse-height analyzers. As far as I know, these units were also developed at the Lab where there were special conditions. This went on, with these people building more elaborate systems, and the Computation department, liking it less and less because it seemed like it subtracted support from the main computers. Well, it did. The main computers weren't answering all the needs of the Laboratory. There was a very intense need for computing power to be at the location where the experiments were.
I was involved from the beginning, in just about every small computer procurement at the Lab for many years. I was involved in the procurement and installation of all the mini-computers outside the Computation Department, and most of the small computers inside the Computation department, where I had a hand in programming and helping set-up.
Somewhere along in that early period, I started working with Ed LaFranchi in Electronics. We would help people with specifications on mini-computers. Eventually, Ed moved on and designated Glen Strahl. For many years, Glen Strahl and I worked with people developing mini-computer specifications. As we did this, over and over, we were able to refine things fairly well: What you should put into a spec; what you should avoid; what the booby traps were; that sort of thing. This number built up to the point, where it began to be hard to keep track of, even though I had my own files.
At some point, I decided I ought to check with the Computation Department to learn about all the small computer information they had. I discovered that Computation Department didn't have any idea where all these things were. In fact, on further checking, I discovered that no one at the Lab knew where all these small computers were. Because of this, I put together the first small-computer inventory. To do that, I even had to go back to the manufacturers and get information from them on what they had sold to the Lab.
I finally built up the first of the small-computer inventories. Somewhere along the line, Computation decided that was something they should have under the control of the Department. Eventually, they took over the inventory. I was very heavily involved with that for a short time. Jim Fiske, of the Computation department, took over that part of it. That was the first of the inventories in which I was involved.
Glen and I kept on polishing the small-computer specifications, and putting in various clauses. Somewhere along the line, we were given signature authority so we were able to sign off on such procurements. I guess maybe that was at the beginning when LaFranchi designated Glen and I as the Lab contacts for small computer procurements. Again, we simply worked with the administration. I think, in general, we kept them from making some pretty bad mistakes. We had one or two of our own. Sometimes it was hard to see a need for some things that were more readily seen by the people in the field. We came to the recognition that they had been right. We had been wrong. But that didn't happen often—I think we did fairly well, on the average.
We were also instrumental in pushing manufacturers in the directions that were favorable to the development of small computers. Some of the directions that we moved in worked; sometimes they didn't work. For example, we pushed DEC into the pulse-height analyzer market. This turned out to be a very major one for DEC. They sold an enormous number of the early machines. Incidentally, at that time, the Lab was by far, DEC's most important customer.
One time, I convinced Varian to buy a small computer outfit. They did look into the possibility and decided to go along with the one I suggested. Do you remember what happened to Varian? They bought DMI and, based on that ground work, developed their own computer line.
I did a lot of arguing with Hewlett Packard. The early Hewlett Packard machines weren't all that solid; they had a lot of weaknesses, as I recall.
We set things up so that there were always three bidders for each machine. We worked with the users so that they could specify very tightly what their needs were and were generally able to find the best machines and the best parts for the jobs. That worked quite well. We had very tight bidding rules. For some reason, there was a bit of a problem because we always wanted to get three bidders and the ground rules, I discovered after talking to various companies, were that some companies would not bid unless they figured that they had at least a fifty-fifty chance of winning. Obviously, somebody had to be misinformed. But, there was enough demand for mini-computers to keep all of them happy, and eventually, they did manage to work with that. But this meant that DEC was not our sole supplier. Data General started up. What was the name of the guy who started Data General?
GAM: Ed DeCastro.
RD: Right. He left DEC. Bankers were highly interested and Data General thought they had something to compete in what was clearly a Varian/DEC market. They made a machine that was actually somewhat inferior. It was based on the earlier DEC approach.
They were working with the PDP-8 model. There were legal difficulties when they tried to copy the PDP-11 model, that was a more modern machine that DEC had and was a radical departure from the PDP-8 machines.
The Data General machines were actually not quite as good. That wasn't apparent at first, but in the long run, they just appeared to have more reliability problems because of using a very large motherboard.
At a still later date, there was an attempt in which DOD would try to estimate the number of all the computers that were going to be bought. This would all be made into one big single contract and sent out.
I strongly opposed that on several grounds. First of all, it took away the flexibility from the end user, even though flexibility was one of the prime goals for this period. I felt that if you had a unified contract, you would lock out the people who were willing to take risk to do something innovative. The idea that one size fits all just doesn't work.
Secondly, when you have a large contract and ask people to designate, in advance, you slow down the whole problem because, if you're truly doing research, you don't know what you may need six months from now. If you're doing developmental work, you may. But when you do research, you're taking risk into unknown areas. You have to be prepared for things to change. If you're not, you're not doing proper research.
The third major factor was, of course, as the contract got bigger, it would become attractive to Washington to oversee, and we would have a lot more micro-management of the whole situation. For these reasons, I opposed the concept of having a unified purchase specification. This was backed by the Business Procurement Department and Ed LaFranchi. I got a bit of a squabble on that. I think in the long run, that was a very good decision, because it gave people the authority to go out on their own. It gave the people the capability of truly, looking at their own needs. They could stay in the mode of evaluating their own information. Our service was an advisory service that they could use or not. In the end, it was the customer's decision.
About that time, in the early seventies, John McCall, who was in L-Division, decided they needed to put together a system to read real-time tapes that were coming from the Nevada test site. This was very high-speed data.
GAM: I remember John McCall instrumented the Nevada test site quite thoroughly.
RD: Yes. In the case of Nevada, we came under very heavy fire from the Computation Department—Sid in particular. Since this had a larger machine, it was intruding into Computation's domain.
We started working with John McCall who was operating under Harry Reynolds, who was in L Division at the time. Harry wanted to see if such a system could be built. John and I worked on this. We did lots of traveling and lots of digging into it. We finally came up with quite a high-speed system based on the DMR, (Department of Mechanical Research) 6130 computer that then was by far the fastest machine for the job. A lot of capability and a lot of power. Eventually, L Division won the battle because it was clear that it gave the Lab a capability that Computation didn't supply. Clearly, the IBM mini-computers, as proposed by Sid, were orders of magnitude too slow to handle such a job.
GAM: Did the EMI machine eventually come to the Lab?
RD: Yes. Somebody named George Bush was involved with that. It ran for many years.
GAM: That was the place where they did tape analog-to-digital conversions?
RD: Yes, we had to process these ultra high-speed tapes. I've forgotten some of the details. But we took these very high bandwidth tapes and ran the data through the analogue/digital converters just as fast as we could to fill up memory, and then write it digitally onto tapes, getting farther and farther behind. One just couldn't keep up. These were the Newell Data Recorders that ran at 100 megabytes per second.
Those things were fast! Even at that speed, they did a data-validity check. Because there were these ultra-high speeds, they tested them out to two sigma. Then all of the sudden, when the thing was already committed, they discovered at three sigma, that they had a horrendous instability, when the spike would just lift upward. They tried to salvage the whole thing, but it seemed kind of dubious for a while. But, it was put together, and was a major step forward in processing the Nevada data. As a result of that, at some later date, when Jim Carothers took over from Harry Reynolds as head of L Division, EG&G wanted Jim to buy a whole bunch of scopes and other stuff from them. Jim was interested in the possibility for a while and thought maybe of going through them and accepting their proposal, instead of us building the tape center. But we got the job of automating Nevada data processing. We were very anxious for the assignment and we had carte blanche to do everything and ask questions about the entire data processing scheme. This was just great. We could visit all the classified areas. We felt what we had to do is to form a picture statement. We looked at that whole situation. Again, we went all over the country. Talking to everybody under the sun, anybody who had any big machines that might remotely fit this job.
We had decided on a fairly large machine that would act as a center to replace the PDP-8 and actually be operating at the test site. It was either another 6130 or a Hewlett Packard machine. I can't remember now what the decision was. I know that those were in the running at the time.
I left on vacation and I was thinking about it. I realized we were making a horrible mistake by going with two smaller machines. What we should be aimed at was to go out and get the largest machine DEC had at the time. I think that was the PDP-10; I think that we looked at the 10 earlier on the 6130 job.
Ken Larsen came out and visited us, but he was somewhat dubious because he had problems with the PDP-6. In Ken's mind, he was hearing the same thing on the PDP-6 that he was hearing on the PDP-10. He finally decided against meeting the same specification.
When I came back and talked to McCall I said, "I decided we shouldn't go with the machines we were going to use." He said "Oh, you think we should go the other way?" I said, "No, we were going to go with a fifth one." He said "No way!"
I laid out all my reasons. He decided he agreed with me. The two of us had to talk to EG&G. EG&G also had a say. They said "No way—you can't have everything!" Finally, EG&G came around.
Rather amusing in some ways, I think. I produced a one-page report. Sort of an outline of this whole thing. At each step that the report went out, people would add things on both sides. By the time it finally came out of EG&G, the report of the whole thing was, probably, two inches thick. One page in the middle listed the horror stories. Eventually, it did go down to Ralph and that was the process there.
GAM: They had a whole lot of System's Concepts stuff, remember? John took the plunge and brought their display hardware.
RD: That came a little earlier. There is background history to that too. We had built, in Computation, a computer to do graphics, the Sigma 7. We had talked to a lot of people about building up new graphic displays, fairly advanced at the time. We talked to Information International and any number of other people.
Among the ones we had talked to was System's Concepts. The whole idea was to have a very powerful graphic stations—again, this was one of these computers which was posing a threat to Computation, from Sid's point of view. Sid finally decided on a method in which people would give him money and he would buy it. Computation would supposedly be charged and support it.
System's Concepts was, shall we say, an unorthodox firm. They would make even many of the present day people in Silicon Valley look extremely right wing. This was at a time when not much of that was done. System's Concepts had a little second-story place on Second Street in San Francisco. They ate and slept in it, and every now and then went out for Chinese food. I think there was three of them.
GAM: There were just two, Mike Leavitt and Stu Nelson. They added Peter Samson later.
RD: That's right. Everything was going along until the Purchasing Department decided to make a visit to Systems Concepts. When I heard that, I knew System's Concepts didn't have a chance. They would squelch the idea of buying from them. But their equipment was good and, so, when we got into acceptance testing, we had a chance to prove to them that System's Concepts terminals were good. The upshot was that Nevada was able to get them, the Lab didn't. Again, going back to Sigma 7, it never really got the support it should have had.
GAM: I really don't believe that. I think that there are other sociological factors that worked against it. It got plenty of support. Some of the best Computation programmers designed and produced a time-sharing system for it. The entire Computation Department supported it. They had full time programmers.
RD: The Sigma 7 project was a very large step.
GAM: That's true, but the Sigma 7 part worked well and did get used. First of all, one thing that was wrong with the remote, was that people who wanted to use it had to come to the machine instead of being able to use it in their offices.
RD: Yes, you're right. That's true. There were a lot more complications.
GAM: We had that flaky thing that was Sigma 2 that sat at the other end. And they were trying to do data transfers. It was just a mistake. We would have been better off with System's Concepts.
RD: Yes. I agree with that. There was another machine that disappeared, a competitor to Sigma 7. It was a very powerful machine. It would have run rings around the Sigma 7. The trouble was, that the company tried to recover all their R&D costs on the first one they sold. I kept telling them that what they should do, was to price it competitively because it didn't have all the software it needed.
The programmers that were building the programs would have put the machine out of the price range—they wanted to get back their R&D money. So they came in with an exceedingly high bid, although, technically it was by far the best bid. When they didn't get it and they didn't get any of the others, I guess about after a year, they came to me and announced that they finally had done what I told them to do in the first place. By that time it was too late to capture the market. They lost out and eventually went bankrupt.
GAM: What's the name?
RD: I can't recall it now. The records still exist at the Lab, I think. I had to file on every small computer and on all the bids. Against a lot of opposition, I kept hanging onto the files. I had files on every small computer and all the bids. I heard that some of them eventually went to computer-history project that was just beginning. I gave Barbara Costello a lot, but I don't know if she kept them all. There were some files that were so big that I don't know what they've done with them. I never threw any of that material out. Other people could have. People seem to ignore the value of these old records. I tried to hang onto them, but I remember continuous pressure for space and everything else.
GAM: Eventually Jim Carothers had that job of head historian. Barbara and Alice were mainly saving things for Computation. Carothers is gone now, and so is the guy who was the Lab historian, Barton Hacker. [Note added: All the Lab's computer history stuff was given to the Computer History Center now located at Moffett Field.]
GAM: You mentioned the last part of your career at the Lab was working with ADP?
RD: Yes. Eventually the PDP-1 job grew into that. In the meantime, I was pretty much running on the PDP-1, although that was getting less and less support. It was a simple point where you could interchange files between the various machines and try out new ideas.
So eventually, I guess Don was going to move to BioMed. He'd gotten his MBA. So, Bill Masson asked me to take over the ADP. I was a little unsure about that because it meant giving up all the technical work that I wanted to continue. And, at the same time, things were getting more and more constrained. I wanted to finish the work I'd started. I felt that some of the earlier technical work had been fairly useful, and I had had a good hand in things that I liked. Another system that I helped put together for radiochemistry was for doing multi-channel pulse-height analyses. At that time, they were using three competing methods for data processing, and I blended them all together. I wanted to continue doing these sorts of things, but it was clear they wanted me in the ADP function. so I accepted the offer—to take it over and make it into a group. The first thing I did was to totally revise the Lab inventory in the accounting system's files.
It was utter chaos. I just had to start from scratch. I went around to every customer, to reconfirm all the data and everything else. They actually were already doing that but they got kind of messed up. I established several priorities within. One is the nurturing support of the group itself. To that I added the challenge that I wanted all of the people in the group to be computer literate. And I wanted them to truly understand computer literacy, to the point that I was sitting down and giving programming lectures to my staff. It got a lot of interest and compliments. They had a lot better understanding afterwards then they had before. In fact, some of them actually went on to use computers eventually. I was also able to add people to the group.
A service that we provided, a very helpful one, was that, on our own, we would eliminate as much red tape as possible. What couldn't be eliminated, we would act to shield the Lab from it or guide them through it. We had the goal of trying to give the user as much information as possible about the equipment. How it would work, how to compare prices, what maintenance services were needed and so on. I think that was fairly successful and I think we did manage to shield the Lab, over a number of years, from a number of fairly major problems.
I'm happy to remember that our efforts were applauded by both DoE headquarters and the local office. As a result, we were granted higher and higher authority to sign off on things at the Lab. I can't remember the exact authority, but I know that, in some cases, I had signature authority for up to a million dollars. While I think Berkeley was still at $50,000 because SAN didn't trust Berkeley that much.
We often got complimented when the Lab did cooperative projects with other agencies like the Army and Air Force. Those contracts were always written so the Lab would do the computing procurement, because we could do it in a very short time.
GAM: That's because they lived under the Brooks Bill and we didn't?
RD: Right! The difference in regulations was just enormous. Actually, to some extent, the Brooks Bill did cover us too.
GAM: I believe that Sid was instrumental in helping places like the Lab avoid falling completely under the Brooks bill.
RD: That was one decision that turned out to be a very good one. In the early period after computers first started showing up, I was able to successfully argue that microcomputers weren't really computers. They were really electronic circuit boards. As such, they were exempt from computer regulations. Nobody at the time cared about microcomputers—obviously, they didn't have any power or anything. Therefore, I was able to get this exception set up. Later on, as microcomputers began taking over from mini computers, we were in a wonderful position, because all of procurements were exempted from regulations. Finally, Bill Buzbee at Los Alamos came screaming in asking for the same privilege, because they were just getting so tied in knots they couldn't move. We did manage to save the Lab that headache.
GAM: Someone also got the Lab, for instance, to put microcomputers as store's items. That was very welcome.
RD: Yes, that was part of the same thing. You see, by eliminating the computers, then they could become store's items. Later on, we also developed a thing called a procurement report that outlined to the users what they had to go through to satisfy the regulations and various steps.
The other area I got into, almost by default, was a question of computer security. In the early period, there was really not too much in the way of computer security. You had a sort of catch-as-catch-can of things you couldn't do.
For example, at a relatively early stage, I recognized that the small computer inventory should not be handed out outside the Lab. It told an awful lot about the Lab. If you looked at the inventory, where the computers were and what configurations they were in and everything else, you could make very strong deductions about directions that were classified. While I didn't classify the document, I did take it to the point where we would only hand it out within the Lab.
A little farther along, we had requirements where we would need to start looking at the security aspects of the computers. I worked with Bob Schmidt, who eventually died. He and I worked on this for a long period. Well, eventually, on his death, George Bush took over that function. Still later, I was a member of the computer security committee, which was chaired by Bill Masson. Chuck Cole was on it. I think Bob Abbot was on the earlier committee. I can't remember the full composition. This must have been 1981. Bill set up Chuck Cole head of the computer security group. He had people under George Bush eventually. George Bush had transferred from L-Division to security. That was sort of the origins of the corporate computer security effort. But, I was fairly disturbed by the lot of them. When we started, we needed the security. At the same time, the handwriting was on the wall that they were going to totally tie us in knots with some of the regulations. To some extent, I think they did do that. I think they increased the complexity of security even more after I left. In fact, one of the reasons I decided to retire was that I could see that I wasn't going to fight that off any longer, and I wasn't sure I wanted to live under some of the things that they were putting through.
GAM: So, when did you retire?
RD: In 1988.
GAM: That's only twenty-nine years?
RD: Yes! As a result of all that and my own financial situation. I decided it was getting less and less fun.
GAM: Yes, I agree.
RD: When you could really guide the technologies, it was very interesting. When you just become part of a work-a-day mill, a lot of the attraction simply disappears. Another period that forgot about, was building up of the graphics lab.
GAM: You and Steve Levine?
RD: Right. This was about '75, give or take a year. It had come about due to an item in the budget which called for a large video disk based on the earlier system that had been developed at the Lab. The disk was used to refresh terminals.
Bob Lee was head of the graphics group. He gave Steve the job of doing something with the disk utilization. At that time, I was on the same floor as the graphics division, a couple of doors down the hall from Steve. I still had a very high interest. This was before I went over to take on the PDP project. Steve came down and asked if I would work with him on it. I said "Sure." It was a very interesting project.
We took off and ran with that. We built up a graphics lab by hanging it all on the initial line item, the video disk. We decided that the best strategy was to make colored movies; just do the whole job. I was involved 100% in designing of a laboratory components; what equipment went into the lab and how it would be interconnected; how it would interact, and everything else. Steve and I did a tremendous amount of work on that. We got some pretty advanced pieces of equipment for the lab.
GAM: Perhaps the most important was the Dicomed, a new film recorder. We put them into business.
RD: Yes. That's quite correct. Dicomed, prior to that, knew a lot about color film but they didn't know much about computers. Some of the other people knew all about computers but they didn't know about color. After we looked at the situation, we decided color is more complex. We purchased our Dicomed and worked with them very directly, designing the original Dicomed. Getting the original lens for it, which was a key part for exposing the film. The Dicomed has a very well matched lens, the Nikkor. They were very cooperative.
GAM: Lee Huelskoetter was the president. Who was the other guy?
RD: John Grimaldi was their engineer.
GAM: Yes. I remember him.
RD: Anyway, we built it up. Probably, their closest competition was Information International but they weren't willing to be as flexible. They felt that they know exactly how to do it. Their system was kludgey compared to what we put together for Dicomed.
GAM: Well I don't know. There were all kinds of things to compare; after all, we already had several of their FR-80s doing microfiche recording. We could have a big philosophical argument about it. But a big plus for the DICOMED machine was that it was quite a bit less costly. The thing that was wrong with the graphics lab, in the final analysis, that it didn't all come together in any timely way, so no one could use it.
RD: Well again, it didn't have any personnel to support it. That was what killed it. The equipment was there and a few people used it very well and they did it on their own. For example, Nelson Max went in and made movies and developed techniques that became internationally recognized. Generally, the graphics group and graphics Lab did some outstanding stuff that was world recognized. We were producing pictures and things that were so far ahead of anything that anybody else was doing; there was no comparison. In fact, it led a number of other people to want to do the same type thing. Like the New York Institute of Technology and later at Lucas Films—they all had their roots in some of the stuff we did first at that time.
We looked at some really interesting equipment. When Steve and I were traveling around, at one point, we were considering the possibility of using a laser. I remember visiting the CBS studios and looking at all their best laser recorders. They could do some impressive things. In fact, I was very impressed by how good the scanner could operate equipment. Far superior to anything that seems to be around here today.
And there were many problems; problems that I tried to get the Lab to look into, that were never really pushed that much. For example, I wanted to get a unified method for transforming color between different pieces of equipment, where you would choose a given monitor based on a set of parameters. Then you would develop for it so that when your signal came into that monitor, it would adopt its parameters, so that the color would line up across all the devices and on the print out and everything else. Well nobody worked with that for a very long time.
GAM: They still don't, really. If you mean completely automatically, I'm not sure that's a solved problem
RD: It's not complete, but it's certainly a long way along the course. Again, all this had to do with getting in there and digging into color. I won't say, understanding it, but trying to understand it.
GAM: Or at least part that effects your eye.
RD: Yes.
GAM: This looks like a good place to stop. Ray, I want to thank you for taking the time to talk to us about your career.