Stretch Reunion Special Lecture Fred Brooks, George Grover, Harwood Kolsky, Erich Bloch September 28, 2002 Computer History Museum

IBM 7030 (“STRETCH”) REUNION TRANSCRIPTS

General Notes
On September 28-30, 2002, a unique group of computer professionals met in Poughkeepsie, New York, to celebrate the IBM 7030 (aka “Stretch”) computer. This computer, first shipped in 1961 and over five years in the making, is one of the most remarkable computer products ever designed. With dozens of new architectural concepts that revolutionized the industry as well as the nascent field of computer science, Stretch embodied the very best of IBM—the best people, the best technology, the most demanding customers.
This transcript is a verbatim transcript of interviews conducted during the course of the Reunion. The Computer History Museum, home to the world’s largest single collection of computer artifacts, is proud to offer this series of transcripts as part of its ongoing mission to preserve and present the artifacts and stories of the information age.
Every effort has been made to check the accuracy of this transcript. All interviewees were asked to verify the relevant transcript. When they replied with changes or comments, this is indicated in the footer of each document’s pages by the phrase “Checked by Interviewee.” Note that most of the subjects did not respond to CHM’s request to proofread their comments.
If you have any questions or feedback relating to this transcript, please contact Dag Spicer, spicer@computerhistory.org.

Fred Brooks: I teach Computer Science at the University of North Carolina in Chapel Hill and my first job after graduate school was as associate engineer working for Werner Buccholz on the Stretch. I've been asked to lead off this afternoon by talking a little bit about the influence of Stretch on later machines, and that many of you in this room who are able to do that better than I but Gerry Blaauw and I wrote a book that went through the evolution of computer architecture and the process and we had an opportunity to look at that question, so at least I'm prepared .

I am indeed heavily indebted to the book that Bashe, Johnson, Palmer, and Pugh--and I guess Emmerson is here--did and I found many facts that my aging memory wouldn’t dredge up , I'm indebted to the work that Gerry did in preparing that joint book. The story that I had up on the first slide I think is the story in a nutshell and that is stretching is great exercise--it prepares you to win--and I think it's very evident from looking at the history that this was the reason why Ralph Palmer wanted to see the corporation undertake a super computer effort that I think he was under no illusions as to whether it would make money or not, but he knew that the company, and it was part of this thing, the company was behind in circuits, in packaging, in memories and needed a push to get it into position.

Now that strategy worked great, but it worked even greater than he had anticipated because of the fact that along came the opportunities to bid on the four computers that Sylvania was buying for the BMEWS system and the requirement was they had to be transistorized computers, they had to be high-performance computers, and they had to be delivered eighteen months after the proposal . Well, they were, the first one was delivered in November, the bid was made I believe in May or June of the year before, that’s eighteen months from start to finish. Now the strategy which was adopted--and this is George Monroe who was engineering manager of that program--the strategy was worked out between George, Ralph Palmer and others, and that was to take Stretch circuits, Stretch memories, Stretch I/O devices and take 709, not only the 709 architecture and manual, but the 709 logical equations and implementation and run ‘em at a faster clock rate and it was only by this using a pre-designed implementation, a pre-designed architecture and a pre-designed technology that it was possible to do it.

Well the 7090 went to become the dominant scientific computer in the United States of its time, it went through generations, the 7094 and then later the 7094 model 2, several hundred of ‘em were sold and that was an immense number of computers of that size in those days. The same strategy was later applied to update and transistorize the 705 model 3 to make the 7080 and then the I don’t know what, I think was the 7080 model 3 was it , and maybe some of you know the degree to which the Stretch technology was also used to make the 7074 which was a transistorized- . . . were the same, my recollection is the memories are the same, does anybody know . I believe that the Stretch technology became the basis for the DSD whole product line including the 7074.

Then along came the system 360 concept which was a cross division, and that’s where Bob Evans and I fought on opposite sides for six months because I wanted to get the 8000 series, a DSD product line out now and he was willing to say let's wait two years but go for one stretching across the whole company product line and he won and he was right and I was wrong. And then to my other amazement he asked me to run the system 360 effort and I was dumbstruck, because in the middle of that six month product fight at one point at the end of February, we started to fight in January and we fought ‘til June , he called me on the phone and he said “Fred”, he said “I want you to know you got a raise”, and he gave me the amount, I said “Well Bob, thank you very much”, I was surprised but we were really going at it, he said “I want you to know I have nothing to do with it” . And he didn’t raise his voice.

Alright, well the 360 story was one of more market dominance, if you look at the annual reports for those years you suddenly see this going along like this and then it goes like that and that was the result of many, many people’s efforts and many of whom are in this room, but it directly derived from Stretch, and I'm going to tell that story again and again in a nutshell.

So let's start with the circuits. I think a lot of the initiatives saying that the IBM corporation had to move from vacuum circuits to transistor circuits was in fact Ralph Palmer’s. Bob Henley came on and was a key there and he hired Joe Loeb who said he said we oughta be moving to drift transistors instead o’ surface barrier transistors and Palmer’s leadership took effect when the time came to bid a supercomputer for Livermore and they were bidding against Sperry Rand. Their proposal was one in which I think Livermore wanted to pay a couple o’ million of dollars or thereabouts, Palmer said we oughta use this as a vehicle for carrying us into the drift transistor circuits and proposed essentially a non-responsive machine, that is one that was way overpriced by those standards and was gonna be late. And Livermore chose the Sperry Rand bid which Pres[per] Eckert and others had prepared for and the LARC was built by Sperry Rand and delivered to Livermore. But then the team started looking for an opportunity to bid that machine that was made out of drift transistor circuits and get somebody to sign on for it as a way of dragging it into existence. Along came the opportunity to bid for Los Alamos and that is then what happened. So key technical concepts were the notion of drift transistors and then Hannon York came up with the current switching circuits as a way of handling the noise that was created, and although Stretch started out like advertised as a ten megahertz--ten megapulse machine the--Loge and Dunne will finally agree according to the Emmerson and others’ book on the 29 nanosecond per gate goal and in fact that’s about what was done.

Meanwhile, as the early computers book describes a major effort was going on in packaging in Endicott and the SMS packaging came in and made it possible to provide really an effective package for the transistorized circuits. When they tried to put it into the Stretch technology, Eric [Bloch] who by this time was engineering manager of the Stretch program, Joe Loeb had been the first one, saw that the signal length problem of how you get all these things close enough together to get wires shorten up just wasn’t gonna be solved that way and he made a push for a double card package which became then the standard technology for the high-performance machines. And so as I've already said, this was crucial for the 90’s, for the 7090’s, crucial for the 7080’s, crucial for the 74, and indeed it was the technology for the data systems division to hold the high performance machines until the SLT packaging with the semi-integrated circuits came along.

Now there’s a similar story for memories. Work had been going on a new ferrite core memory. I think it started out the early core memories as I recall were 50 mil inside and 80 mil outside and they were working that awhile and then said okay we ought to be able to get the windings into a 30 mil inside. You know, there's a standard story that the generations of cores they used the punched out hole of the previous generation 80/50, 50/30, 30/22 and so forth were the sizes. Greg Constantine had come up with the load-sharing matrix driver as a way of managing the currents against those back voltages and this was a hot memory, so a lot of things were tried including Freon as a ways of cooling it. Eric can tell you more of that story. They ended up with transformer oil and so the memory as delivered on Stretch was an oil-cooled memory. Later it used smaller cores--esed the old holes--and made it air cooled and got it on later 7030’s and 7090 programs down to 2 microsecond cycle time. Stretch was the first machine that I know of to use four-way interleaving on the memories, and so the instruction memories that were two instruction memory boxes and they were two-way interleaved and the data memories were four-way interleaved and very important was the notion that, you know, we might not be able to make memories work infallibly.

Of course on the 701 and 704 there hadn’t been any checking at all and on the vacuum Williams tube memories, you know, I remember the 701 was the machine I learned to program on, it made a main free error time of about five minutes, between five and ten minutes , you had to roll out the drum every five minutes and you had a real good chance of getting it to go again. But when they put checking on those memories they had to throw the memories away because, you know, this was the 702, because it failed often enough that if you were checking and found out it was failing you couldn’t make any progress and so . The 705 switched from a William speed memory to a core memory and got to the next level of reliability.

What Stretch was talking about doing lots of operations per second and it needed a higher degree of reliability and one of the luckiest decisions, not just wisest but luckiest decisions and it's as important to be lucky as it is to be wise sometimes, was to put single error correction, double error detection [SECDED] on that memory. This had two consequences, one is since the word length was 64 bits this added 8 bits and so, you know, that’s a twelve-and-a-half percent increase in cost if you didn’t have any logic circuitry. But guess what, when the 7090 needed a memory they could get two 36 bit words, of course unchecked alright , give me that 72-bit word length and so that’s what I mean by lucky, that’s just lucky.

Alright, now the other place where the wisdom showed was in the acceptance test, and Harwood can correct me on this, but my understanding is that the requirement was that it run for a month I think at something above, and I forget, 90-what percent, 92, 95, something like that, and she went chugging along great and was just hovering right above the line there and then one of the memory . . . either one bit drivee or else one sense amplifier failed completely, and for the rest of the acceptance test they just ran it the way it was, there wasn’t time to stop and fix it, it would’ve ruined the statistics and so it went along single error correcting every single memory [access] .

Well as I said this memory made the 7090, which was six times the 709, possible and it became the standard memory, meanwhile the memory group developed what started out to be half-microsecond memory and ended up as delivered as a seven-tenths microsecond memory, if I recall--Emmerson, is this right--I think it was a two core per bit memory to get that speed, I think that’s what was delivered on purpose . Certainly more intensely motivated and publicized .

Emerson Pugh: I think you’ve read my book more recently that I .

Audience member: It was word-oriented, word-oriented.

Fred Brooks: Okay, alright, so originally that was gonna be part of the Stretch delivery and that got taken out of that contract for scheduling and other reasons. But it is what was built and used on Harvest for fourteen years.

Another important story, and Harwood [Kolsky] can tell you this one in a lot more detail, was the notion of instruction pipeline. Any of you who have a PC today are aware of the kind of performances the machines will deliver, anybody’s laptop is faster than Stretch. In many cases this is the only technology I know in which over this length of time we’ve seen more than a thousand-fold increase in performance-to-cost ratio and you can take it either as performance or as cost, and I know of no other technology where you have that choice, okay. So you can get one that costs a thousandth as much and runs as fast, or one that runs a thousand times-and as a matter of fact the ratio’s bigger than a thousand now. Well a key part of this concept today people we’re talking about, you know, maybe, maybe even though any individual instruction takes several clock times, maybe we can pipeline it so that we are able to issue one instruction per clock. Now a days people issue four instructions per clock, six instructions per clock, but it's the same pipelining concept that John [Cocke] and Harwood came up with and tested on Stretch.

If I recall correctly Stretch had eleven instructions could be in execution at the same time, some of ‘em being prepared, some of ‘em waiting data fetches, some of ‘em having indexing done, and then some of ‘em, after execution, some of ‘em waiting to be stored. And now, Seymour Cray built a machine that had similar kind of properties like that afterwards and he made a different decision: that is if you want to worry about whether you were interfering between the fetch that you're about to make and the store you just specified that’s your problem and you better program around it ‘cause you're gonna be hand probing this thing. Not Stretch. In Stretch the logic is there, it automatically did that scheduling and of course you had the same kind of concerns that you could have with today’s machines about whether you're gonna have pipeline delays because you’ve misprogrammed it and you can speed up a program by getting rid of the delays. But it would run riot okay? The simulator was crucial and I think Harwood principally did the simulator and, at one point according to Emmerson’s book, more than a thousand simulator runs were made to change the speed and tune the speed on application kind of problems. A crucial concept in anybody’s processor from a PC on up to date.

The arithmetic started out to be a 1 microsecond--well matter of fact first quote was like seven-tenths microsecond floating ADD promised the kind of a 1, came in at 1.4, with only a 2.5 microsecond floating multiply on a nine microsecond floating device. Now most of you will recall that in multiplication, the length of time the number of things you have to do goes as the square of the word length, and we’re talking about a much longer word length, 64 bits of which 48 bits are fractions, so you think multiply would take a-a lot longer than floating add. Well I think it was magic here and Owen McSorley was kind of the leader of the group that took on the multiplication challenge, and built a the most sophisticated multiply that had ever been built up to that time and one of the most sophisticated multipliers ever built that would handle up to six multiply digits at a clip, alright. So if you had six zeroes and six ones it was one add cycle would take care of that, and in and for cases where they weren't all zeroes and ones then you still would get many multiplier digits.

Well it turns out divide is a lot harder to accelerate and so when the smoke cleared not as much circuitry was put into it but an important lesson was learned, and that is on the 704, and therefore on the 7090, multiply and divide took the same length of time, well really divide’s a lot harder to do, but people were used to ‘em taking the same length of time and so if you wanted to divide something by 2 you divided it by 2, but you don’t have to divide it by 2 if multiply is really faster than divide you’d multiply it by a half and it's just as well. And it turned out that when we did compile our studies something like half of all the divides in 704 and 7090 programs were divided by constants and could be replaced by multiplications. And so consequently it wasn’t nearly so important to get the floating point divide time down once this fact was discovered.

Now, our next big important notion here which had been seen as important in the business computers, the 702, the 705, the 705 model 3, the 7080, the 650, was fully checked, the arithmetic, I think 650 may have been—-well Univac I was the first machine that was fully checked from one end to the other, all the way through. Well so was Stretch arithmetic fully checked and it used a fast carry ripple adder and this arithmetic concepts and especially the multiplication concepts were picked up and directly used in the 360 models 70, 91, 95, arithmetic units, you know, that’s just one of the places where Stretch technology just carried over.

Input / output is another place, the child concept had been developed for the 709 and I see Larry Kanter here and he’s one of the well, you know, were there four of you that shared, three of you, who were the other two?

Larry: George Monroe and Carl Christensen.

Fred Brooks: Carl Christensen, alright, shared the patent award for inventing the notion of a channel. What is a channel, well it's another computer, it's really a multiprocessor, where you have a specialized computer that does I/O feeding into the same memory in which you have your main processor. A concept that has been—[that] everybody uses. Now the Stretch team made another step forward and that is what today we would call a virtual channel. It had sixteen channels but it had only one set of channel hardware, and so because of the fact that I/O operations are inherently slower byte-by-byte, it's possible to timeshare that hardware among the sixteen channels. And the planning on this was done by Werner Buchholz here, and the engineering team was led by Herb Wild, there’s several important advances here. One was Werner came up with this general I/O instruction set, before that machines had had bushels of different I/O instructions, you know, rewind tape, move disk arm, poke card out in the stacker , Well, Werner generalized these to say there are two directions in which you move data--in and out--and there are two things you do with it, either you put it on the medium or else you use it to control the mechanism. And so that led to a general clean set of I/O ops [operations], and the first standard I/O interface. It was not the standard I/O interface the corporation standardized on for 360 because that technology had moved on, but it was the first concept of having a standard interface in which you could plug I/O units and channels across from each other. And these concepts were exploited all over system 360, the multiplexer channel, for example, even on the smallest little 360 model, 20, 30, were virtual channels with up to 256 terminal channels being handled by one set of hardware and, on the model 20 and 30, that was the same hard-identical hardware that was also the mainframes, timeshared every which way. And the selected channels on the models 20 and up were essentially using this same kind of concept of timeshared virtual channels, so.

A machine like Stretch which essentially started out as a one of a kind, you don’t want to spend a lot of money doing development of new I/O devices for them. And one of the strengths of the IBM 704 against the Univac 1103A its chief competitor in the market, was the rich collection of I/O devices that the IBM machine offered on the channel directly available as opposed to offline kind of stuff. And so the notion that Stretch would be equipped with a full set of I/O was important but it was essentially a full set of standard I/O except it needed a high-performance memory backup contraption. And so what was proposed and developed and later turned into the product that was used on the 360 as well, was a disk in which, instead of activating one read hit at a time one disk at a time, you comb moved all the heads in and out and all the heads were active and you read it off in parallel. Well notice that this conceptually means that at any given setting of the comb you have a magnetic drum just going around and you're reading the data in parallel from it, but you can choose among your drums at very high speeds. And in fact the Stretch disk as proposed--Eric says in fact it's deliberate--and alright, had two combs and is that-is that right, everybody remember that, one on each side, two combs going in and out so that you could up an eight million bit per second transfer rate, some of you may remember the 360’s we got up to three million bits per second and that’s on the standard I/O channel. It only had two million words and that seems laughable to us today, sixteen million bytes, well, you know, how many-how many . But remember the main memory on Stretch, which was an important advance, was a quarter of a million words, a million bytes and was eight times larger than the 7090 memory so a memory jump was really important an advance. So was this disk.

Now in architecture I think the most important contribution and one that we later adopted in the 360, was the notion of switching from a six-bit byte, which would not accommodate lower case characters, to an eight-bit byte which would, and this was Werner and Steve’s passion and they made it happen, we later adopted it after another fight to the whole product line. Now the economic consequences of making that shift are immense, because you have to--if you're going to do it for a whole product line--you have to redo every I/O device, every one, and that’s a big deal. But I think it was very--it was full of foresight to say it was gonna be important to process language with these machines, and to process language we’re gonna need to be able to deal gracefully with upper and lower case characters, and the eight, you know, you could do it with a 7-bit byte, the 167 did it and I think the switch to eight was very wise, the big memory was very wise and a thing of great importance was the notion that you should put in a machine all the facilities necessary for the program to keep control so that the operator becomes only the hands and feet and not the guiding mind for the operation of the machine. And that requires an interrupt mechanism, a real time clock of some sort that they can interrupt you to stop close the loops, memory protection so you don’t write on some--on the operating system just ‘cause you were stupid or not malicious, and privileged modes. So that became very important and then that meant then that you could do multiprogramming and you could do the multiprocessing I/O in a more general way than just with the basic channel.

Another important concept was lots of address registers. Now the Stretch only had two data registers, that we can relate, and we later generalized from that, but it already had the sixteen index registers, up from three in the 709 and 7090. Variable field made alphabetic and decimal data integrated indexing and I/O and then the 64-bit floating point which has slowly become a standard.

Then the last thing I want to talk about before Tom [?] takes over is software and George Grover can elaborate on this, but the operating system did provide some supervisory capability. It was an important Fortran compiler and an assembler and I'm sure George will talk more about that. But I do wanna specially mention Ted Codd’s experimental operating system. Ted said “Now we can multiprogram in this machine, it should be possible if we design an operating system right, to multiprogram programs that were not designed to be run together”. In other words I can fence ‘em apart and turn ‘em loose going at the same time, and because I/O is so much slower than internal processing, I can take jobs that have lots of I/O and jobs that have lots of internal processing and share the machine and get more total work done. And so Ted and his team, some of whom are here today, built the first multiprocessing operating system, I remember reading in a British conference report and I think it was Stratchie who said, you know, it should be possible to build a machine that will run multiple programs at the same time and enable you to do kind of timesharing. And at the end during the comment period Ted got up and said “We have done it” , and went on to elaborate a little bit in the comments. Major contribution, crucial background for all the later multiprocessing operating systems. So at that point let me conclude and let Eric assemble the panel.



George Grover: This is not a new situation for software to be in at the hands of hardware engineering . I want to begin by saying I am gonna speak from the software perspective, great to see so many software faces in the audience. I have not written a book on this subject, but I will and I will not be able to do justice to all of the things mentioned, the good things that so many of you have done, but I’ll try to hit the highlights. We were faced from day one on the software side with schedules for shipping that seemed very ornery. We were faced from the outset with very difficult schedules to meet and our first priority throughout was to undo whatever had to be done to be able to ship to the hardware. We had two different compilers, Fortran for Stretch and the scientific market, and Alpha for Harvest and cryptological applications. And that was a tall order and so to try to make it a little more easy to handle we came up with a scheme for doing one common compiler and feeding at the top the source languages then and mapping into a macro language interface just below and going down through various phases and out the bottom with software for Stretch on one side and Stretch Harvest on--Harvest on the other.

The result of this approach was a mixed success. We met our schedules, we, on the Alpha side, things went pretty well. On the Fortran side, the performance was somewhat disappointing and to the point that we then subsequently, after the first release at some point, put out a second Fortran compiler which had substantially better performance and in part due to an outstanding optimization job governed by Ken Planbeck. Looking at that project from a development perspective it was somewhat mixed, but from an add-tech [?] perspective looking at the ultimate consequences on other products it was a success and it was more of a success than I realized until fairly recently.

Today, IBM’s main product and compiler is called the XL family, compiles many languages to many target systems and it is a direct descendant of our forty year ago common compiler system. It has a similar cascading design, and there were a number of intermediate events along the trail from the one to the other and the key to a lot of this was that Fran Allen was involved in a number of compiler efforts. And I have to say, I used to say Fred, I saw the tongue-in-cheek, but I used to say that software technology doesn’t exist, it's only folklore and therefore the best way to transfer the technology is to transfer the folk . And that’s not doing software is well the prime technology today, but nonetheless it is also true that that’s the best way to transfer and this was an outstanding example of that. There was an ACS research project compiler which focused very much on optimization methods with a scientific basis. And also which was able to get good results on a number of different languages, so it was--for a large class of languages, it was a language-independent optimization scheme.

The next stop was the PLA compiler for IBM RISC projects, and here in Research both Fred and John Cocke were very active in this area. And then they came up with a variant of the common compiler system, combined with these ACS optimization methods. And they processed two input languages, one the PLA and the other Fortran, through the same common compiler. This product then just kind of evolved and became--by incrementalisms and improvements--it became the XL compiler product that is there today and is so powerful.

So this is a pretty good story, and now I’d like to jump back to the-something very close to the hardware interface. I heartily agreed with Fred’s perspective that the possibilities of multiprogramming and multitasking were huge implications for software, that they came of Stretch. So much so that it was adequate to keep software developers busy for multi-years , multi-releases. The hardware interface, strengthened still further in the 360s with the addition of base registers, there and later in the 370s with dynamic hardware relocate. So it was a long story to get there, and I cannot resist remarking that when the Windows, well DOS and then Windows, PC saga has been a very long one in this respect, and it's not clear to me that they're yet, and I speak from the Millennium [Windows Me] level, and that basically they’re trying to do the same thing that we did quite a long [time] ago. The thing that makes it so difficult in my mind is these two small words, multiprogramming and multitasking. The key requirement is that all resources are shared dynamically, everything, memories, real, virtual, caches, disks, access times, CPU-CPU’s and tie helped itself in the case of reentrant stuff, communication bandwidths, etcetera, just profound implication on the software structure.

George Grover: (cont’d) … both at the prospects and made a decision not to go for full multiprogramming and multitasking because we didn’t--we thought the risk was too great and against those schedules. But instead we picked a special case which was spool, and which involved a good deal of multiprogramming. The spool program was a special program, which was part of the system, and that had some advantages, a fixed storage amount, you could use the “disable interrupts” function when it was necessary to avoid synchronization problems, and spooling essentially carried forth a software level in all the future systems. We did a little overlapping through our job scheduler of MCP with tape mounting and that again was carried out and we utilized the interrupt system as had been planned to improve the error alarms and diagnosis and so forth.

I agree strongly with what Fred had talked about on Ted Codd’s project. This was not a development product but it was a very good running prototype. It was an ad hoc effort which was extremely successful, in my mind it assured the concept feasibility with running code and it assured some hardware design to do that. And as most of you probably know Ted was an amazing guy, he followed this by going out to California and bringing relational databases into the fold which is a now just huge achievement.

This is my last foil, I just wanna say a little bit about the Alpha language which was designed by Fran Allen, it was for Harvest, was a very high-level language, it had some properties which later appeared in other high level languages. It simplified the streaming unit usage, particularly on the Harvest machine, so that the programmer could utilize it without having to understand it, and that was quite an achievement . The whole system was just amazing, it had tractor tapes, you could . . . one statement in the Alpha language could be executed for days . It was the first high level language to allow multiple data types to be assigned to a single data set, which was a useful thing, and which got added to some other languages later. It had an implicit data declaration, wherever it was possible, when you had a calculation, you didn’t have to define the results, they were inferred from the operands and from the input data types and it did this for very large complex structures.

Some other high level languages took the same direction but none ever went as far as Alpha did. The other thing is that the Alpha language was a successful enough that the customer later made a version of it called the Beta language which was extended in a way that it could run on hardware other than ours. So and this was, as you all know this was a customer who had a lot of machines . That’s a very highlighted look at it.

My position on the project was really sort of unusual because I was working at Los Alamos as a physicist and we had a lot of machines at that time too, card machines and probably what was available in the marketplace. And when the 701 came out we had version model number one of the 701s was delivered to Los Alamos and I was one of the people who had pushed hard that we get this machine because we had been using IBM and its punch card machines, mostly the card programmed calculators, CPC at that time was a very popular--I used to refer to it as the Model T of the computing industry---it spread throughout the industry and got people used to the idea of programming problems rather than just plugboard wiring them.

Anyway, as part of this the proposal that was made to Los Alamos which was this--it was mentioned earlier--was part of the rivalry between Livermore and Los Alamos which was sort of friendl. Rivalry but it goes on to this day, you know, so if Livermore is gonna get a supercomputer then by gosh we’re gonna get one, you know. And so when IBM came with their proposal it was very it was really received with a great deal of enthusiasm. I’d say by everybody except the members of the group that was building MANIAC computers which was a Los Alamos home-built machines and they were a fairly powerful group at that time. Anyway, the Los Alamos IBM mathematical planning group was set up, there were nine members from Los Alamos on the team and they included chairman Bengt Carlson, who was the head of the computing center, Max Goldstein, Ed Vorhees, and Jack Worlton, they were all from the computer center. Then there was Roger Lazarus and Mark Wells who were members of the MANIAC team, and Roger was certainly a good friend and we used to debate endlessly about the virtues of different machines, and then Bob Frank, Dave Woods and I were the people who represented the users of the big machines.

In 1957 I joined IBM and continued on the committee except sitting on the other side of the table now and which resulted in, well if not a split personality at least a Stretched personality, and Cuthbert Hurd of course and who all of you I suspect know at least by reputation was very happy to have me on the team, just as because I've been one of the 701 supporters but he sort of wondered whether. . . questioned my wisdom when I discussed it with him whether I should join IBM or not, and I think he was, you know, probably less concerned about my career than he was about that I was more valuable as a customer than an employee .

Anyway it's very nice to have the book here, I think that Eric Knutsen did a tremendous job on the book for this event and dedicating it to Steve Dunwell and to Sully Campbell was a excellent idea and so I’d like to just say give a sort of a personal note about an experience that I had with each of those two gentlemen,

Certainly Steve was one of the people who convinced me that I should join IBM and we certainly all owe a debt of gratitude to him for keeping the project going against an unbelievable amount of opposition within the company. I can recall, after I joined IBM, sitting and reading which people were saying nasty things about these people trying to build things out of transistors, you know, after all ninety percent of the money is coming from punch cards . Anyway, of course, Steve ended up because of the fact that the Stretch machine was not considered financially successful,l they wanted the very same people who were manufacturing hundreds of 7090’s were complaining about Stretch being a financial failure but anyway there was an incredible number of ideas and things came up in all the discussions among the Stretch people and projects and somebody would say “What about doing this, what about doing this” and so on and I know a lot of these ideas should've been recorded at the time because they would’ve been the source of future patents and so on, and I'm sure that, for example, John Cocke’s ideas bubbled from him, you know, like water from a spring and even if half of them had got written down we would be way ahead of the game.