Jim Gray: It was the 811 architecture.
Mike Blasgen: For System R architecture shipment, and of course they wound up being about three years later.
Jim Gray: But the project was called 811 because it was the ship date: eleventh month of 1978. And I think [Mike] Saranga and I ... I still haven't paid him off on the bet I had that they'd never ship anything.
Franco Putzolu: Was this VSS?
Jim Gray: Yes, well it turned into DB2. There was also hardware coming with it. It was the 811 architecture, so XA was part of the package.
Mike Blasgen: Thirty-one bit addressing.
Jim Gray: This was, "FS crashed; what are we going to do? So what we're going to do is go back and do a new database system for MVS. We're going to put in the XA architecture into the 370." This was not thirty-two bit addressing, this still twenty-four bit addressing. It was horizontal.
So something that hasn't come up is that Irv was loaned to Palo Alto, I think early on.
various: STL.
Mike Blasgen: No, twice; he was loaned twice.
Irv Traiger: First Leonard suggested that Franco and I start going up to Palo Alto, which was where we met Steve Weick, John Nauman, Bob Jackson, a bunch of other people on this huge FS project. I don't know if the interactions came to a whole lot. He was trying to get us educated about real systems.
Franco Putzolu: It was a strange interaction. This was a part of the big FS effort. We were supposed to be there as representatives of relational knowledge, relational wisdom. Of course, FS was covering everything in the world, so it had to cover relational. I was very uneasy because I didn't have much experience in database in these days. On the other hand, talking a little bit with these people ...
Mike Blasgen: ... made you feel a little better. [laughter]
Franco Putzolu: I knew I was kind of flaky, but these people, they were experts ...
Mike Blasgen: I worked on FS for two or three years in Poughkeepsie in Building 77.
Franco Putzolu: I worked for a year in Mohansic in FS.
Mike Blasgen: I was on it for two years. I worked for Rich Oehler, who worked for Pete Schneider, who worked for George Radin, who worked for Dick Case, who worked for Bob Evans. Bob Evans you know had basically all the development in IBM. Because the System Development Division developed all systems. So everything except typewriters, everything except Tom [Price][50]. I left FS because it was just too complicated, too hard to understand. Jim wrote a real long paper and said, "It's real attractive, but don't do it." Something like that, I forget exactly. Whatever it is, don't do it.
Jim Mehl: The thing in Palo Alto: was that called the Dawn Treader project?
John Nauman: No, that was different; that was in Palo Alto, too, but that was a different project than this.
Mike Blasgen: I have a technical notebook - the sort of slightly hard cardboard cover thing that were issued - dated November, 1974 on the cover. I have notes from all my meetings of Palo Alto with all these people, and names of people. These names are all lost. There are a few that are around. Steve Weick was one of them.
Franco Putzolu: Yes, Irv and I went for a couple of months. I don't know why we stopped; did FS die?
Irv Traiger: It was sort of creeping along. But we just didn't connect with anybody really well. We had meetings and they'd kind of pat us on the head and smile and get back to their work.
Tom Price: I remember when FS did die, and there were rumors it was dead like a year before they actually stopped the project. It was so funny - everybody working on this stuff they knew was dead, but they had to keep working on it.
Mike Blasgen: There is by the way a book that's just come out. I know Pat has a copy. It's Emerson Pugh's Building IBM[51]. It starts with Herman Hollerith. Actually, the first sentence is about something that happened in 1889, which is the day that the first patents were issued on Hollerith tabulators. And in there, quite toward the back, is a section on FS, which says, "It was the most expensive development failure in the company's history."[52] It's not usual to see stuff like that written about FS. We all knew that, but nobody ever actually wanted to write it down. Except for Jim, who said, "Don't do it" in the first place.
C. Mohan: Actually, the author has said that he was given complete access to all the IBM archives without any restrictions on what he was allowed to say. He didn't have to clear the manuscript with IBM before he published it.
Mike Blasgen: You know Pugh is no longer an IBM employee. So he wrote this as an independent author. He wrote three earlier books: Memories That Shaped an Industry, IBM's Early Computers, and IBM's 360 and Early 370 Systems, the last two of which were part of the IBM Technical History Project. He was an IBM employee and he had people working for him and relationship with publishers. And then he left IBM, but he continued it independently, and as a result had a little more editorial freedom than he would have, had he been an employee.
Jim, I think it's lunch time; what's the story on lunch?
Raymond Lorie: Speaking about the compiler, I'd like to thank Brad for the tremendous job. If you really want to know something about 360 and how base registers work, you should ask him; I think he still remembers.
Franco Putzolu: Do you remember that?
Mike Blasgen: I do remember one story about Brad's base registers and whatever. It's that the assembler sequences were in our code. So it said, "Load R1, whatever", and this would then be processed by something that would turn it into real machine code. We did a code review at Santa Teresa, because Santa Teresa was thinking about taking our code. They came back and said there are many bugs in this code, sorry many defects. And what were the defects? We were a little bit surprised, because we thought we'd coded it pretty clean. They said, "Well, you have literal references to registers. In other words, we really generated "Load one".
Tom Price: You didn't use EQUs.
Mike Blasgen: Right, we didn't equate anything. [laughter] But that's because this was the back end of a compiler. I mean, of course the back end of a compiler - I mean somebody has to decide which register it is. They were all upset, and they counted, you know, four hundred of these ...
Brad Wade: There were five hundred and seven defects per thousand lines in my code. [laughter]
Mike Blasgen: The rule at that time was, you know, point seven or something. And so Frank or one of us turned to the guy that was in charge of code quality, and said, "We'll just work this out." And the guy said, "We'll ship this code over my dead body." And we shipped it. [laughter]
C. Mohan: But in SQL/DS, right? Not DB2.
Mike Blasgen: Endicott shipped it, right.
Franco Putzolu: Didn't they rename everything? I remember that the RSS and RDS naming convention were quite liberal. It was either a Y or an X in front of a name. Didn't they rename everything when the code went to Endicott?
Bruce Lindsay: A01, A02, A03, yes, they recoded all the RDS modules in PL/S and they renamed all the modules with the Endicott naming convention, which was like seven characters for the product name and another character for the component, and the remaining character could be anything that you wanted. [laughter] I remember that I worked on Brad's authorization code in PL/1 and PL/S. I had a hard time when I worked on the PL/S version, because they used to have mnemonic names - at least three characters worth of mnemonic for what it was doing - and they had decided that the proper names were 01, 02, 03, 04. They never actually got up to 10, but ...
Tom Price: So you had a cross reference between the old names and the new ones.
Bruce Lindsay: Yes, I had to do that. IBM coding conventions were quite something in those days.
Jim Gray: So what happened next?
Mike Blasgen: There are a few things I want to do after lunch, if we have to go to lunch now.
Jim Gray: We have to go to lunch now.
Mike Blasgen: One is, as we're leaving, Brad can turn on the videotape, and we can see some of the stuff that's on this tape. The other thing is that after lunch I'd like to talk a little bit about the relationship between San Jose Research and Santa Teresa at this crucial time which eventually led to DB2 and SQL/DS. Particularly SQL/DS, which, while it was finished by Endicott, was actually started in Santa Teresa, with the DOS DL/1 successor, at least that was my recollection of what happened. And Bob Jolls was the manager of that whole effort, and he's here, and nobody's here to contradict you. I think you can kind of make up the story, you can tell them how you caused it all to happen. And we'll do that after lunch. That's what happened at the beginning, say through 1982, which culminated eventually with SQL/DS and DB2. Then there's the stuff afterwards; we should be able to have plenty of time after that to do that. So we're going to find out why Larry Ellison became rich and why Jim Gray left IBM and why Bob Jolls is living in Chapel Hill, and where Mario's going next month. Lots of interesting things. And that will be after we run the tapes. Here we go, look at Don Chamberlin wearing Brad Wade's mustache. [laughter]
Irv Traiger: It was Franco and I going up part time to Palo Alto, for FS. Both of us later had assignments at Santa Teresa Lab, during the initial work, and the key decision-making that led to DB2.
Franco Putzolu: Then Jim went.
Mike Blasgen: Then Jim went to Palo Alto, right, and you spent a year there.
Jim Gray: Right. And we moved to Santa Teresa in the process. So I ended up in Santa Teresa.
Mike Blasgen: So you were working on Eagle?
Jim Gray: Yes; it was called VSS at the time. John Nauman was part of the team, and Thomas Work was managing; [Steve] Weick was managing Thomas. Andy Heller was taking credit for it. In six months we were going to build a product which would replace IMS and do all of System R. Andy was even more aggressive in those days.
Mike Blasgen: I have an Andy Heller story about that. At the time that you were there I think was the time that Tom Price and I were writing a paper which we intended to publish and never did, called "How Database Systems Recover." We were going to try to document how recovery worked in several existing systems and then go on and speculate about generic stuff, which eventually led to those terms we used: "no-force", "steal/no-force", "no-steal/force"; all that stuff in part came out of work Tom and I were doing. We wanted to write down how VSS would work. So whenever Tom and I would see Andy in the Research building, we'd grab a hold of him and come in and say, "Well now, exactly how does it work in this situation?" Andy would say, "Blah, blah, blah", and we'd take notes, and then he'd leave. Then we'd sit around and try to write it down in such a way as you could understand it. And we never could. We'd get down to that point where suddenly it doesn't work anymore. And we'd wait until we saw Andy again and we'd bring him in, and we'd say this doesn't work. He's say, "No, no, no; that's not what I meant; it may be what I said." We must have met with him seven or eight times, and never were able to find out ... however, I will say, seven or eight algorithms that don't work were invented. [laughter] It was fantastic.
Franco Putzolu: We eventually got into an agreement that if you wanted to talk to Andy, he had to write it down, in all the details. Otherwise we wouldn't talk with him.
John Nauman: That stopped the interactions. [laughter]
Jim Gray: So after I left, then Franco went. And Franco was there for I think about ...
Franco Putzolu: Almost three years.
Jim Gray: Well, you were there for a year, and it was time for you to go back. He said, "It's time for me to go," and they said, "You can't go!" And he said, "Well, I'll make you a deal. If we don't have to go through the Santa Teresa process, then I'll stay. But here's the deal: no reports, no reviews. Once a month, we'll tell you what our status is." I may be missing something ...
Franco Putzolu: Yes.
Jim Gray: And they said, "Go pound sand." And so he came back to Research. About a month or two later, all of a sudden, you were back in Santa Teresa again. And there was this team that involved [Don] Haderle and Bob Gumaer and ...
Franco Putzolu: Let's see: that was 1977 to 1979, about three years.
Jim Gray: So 1978 is when ...
Franco Putzolu: Yes, there were some minor conflicts with management on that. [laughter]
Jim Gray: Franco wanted to convert the eighteen-step process to a two- or three-step process.
Franco Putzolu: Well, Santa Teresa was really paralyzed. They had this big group and they were changing project names continuously. First it was called VSS, and then DS/1, and then Eagle, and then Ampersand, which was the only cute name, because Ampersand stands for a variable in the SCRIPT language. This was supposed to be the system to replace all database systems. It was going to replace IMS, provide new fancy interfaces, provide all sorts of compatibility. There were three components. There was System Services, and that is the only part that survived. Things like logging, recovery, and locking; it's the only component that survived in DB2. There was the Data Communication Component that totally went away.
Jim Gray: I/O Subsystems; buffer management.
Franco Putzolu: No, that was added later on. And then there was the Future Database System, which went through a number of incarnations. For a while it was Chris Date's extension of PL/1.
Franco Putzolu: Think of it as a really low-impedance database system, using current Object terminology. And then for a while it was a system with many personalities: it had a hierarchical personality, a relational personality, a network personality; it had DL/1 sort of grafted into it. And this effort wasn't going too well. So when I joined Santa Teresa I decided that there was a clear need for a subsystem that would support all these external interfaces. I decided to work on a lower-level subsystem that would support all of these interfaces. This was an under-the-cover effort, because management was very intrusive in these days in Santa Teresa; they really wouldn't leave you much freedom. So this project was called Technology Evaluation. It didn't even have an IBM code name. I mean normally, any project in Santa Teresa would have a name of, I don't know, some pagan god, some beast, some blood-thirsty beast. But this thing was just called a Technology Evaluation, and only after a while we had a meeting and decided we could not have this name appearing in a product, and have customers seeing that they were using a Technology Evaluation database engine. It was simply renamed the Data Manager. Let's see; how many people were initially working on it? There were Josephine Cheng working on the cache, Dick Crus, Tim Malkemus, Sid Kornelis, Bob Gumaer, Ming Shan, and Jane Doughty, who eventually went to Sybase; she was the only one who got rich in the process.
Mike Blasgen: My impression at that time, with respect to the things that you were mentioning, that Santa Teresa was kind of doing their own thing; that System R, if it was relevant, well, it was a source of programmers. I mean, you could hire people like Franco. We negotiated; we got Bob Yost in return. I thought that was a good trade. I have a question: what did System R have to do with that?
Franco Putzolu: Well, the official position there for a long time was that System R did not count. What was important was to develop a network database system. Of all the interfaces - I mentioned five or six interfaces - that this ecumenical system was supposed to provide, the network interface was supposed to be the real interface; and it wasn't of course DBTG, it was something else.
C. Mohan: Was that because of Bob, what's his name?
Tom Price: Engles.
Franco Putzolu: Maybe it was Bob Engles; I don't remember.
Jim Gray: It was cultural: it was because of all that money coming in from IMS.
Franco Putzolu: IMS was supposed to be there as a graft. Just a piece of code to be grafted. So they let us work in peace for about three years. We knew that this subsystem was going to become part of a production system, so we tried to write good code, and unlike System R we had naming conventions; we tried to do decent software engineering.
Mike Blasgen: This led to a series of components that are now a part of DB2, is that right?
Franco Putzolu: Yes, I think most of it survives in DB2, and actually, I'd like to hear what happened to it after I left. [laughter]
Mike Blasgen: I would too, but let's finish this thing. So these components were developed. Those components had relatively little to do with System R, correct?
Franco Putzolu: Well, they were written assuming that System R interfaces would run on top of them. I was assuming that SQL would be one of the interfaces that were supposed to run on top of them, so it was also suitable for SQL.
The other major interface I was convinced would run on top of the Data Manager - or Technology Evaluation, same thing - was DL/1. And in fact we spent maybe thirty percent of the code, and of the time, writing special code in the Data Manager to support DL/1. There were all sorts of special DL/1 hooks. By 1979 we had a prototype running on VM. It was pretty functional, and we ran the first substantial tests on what later became DB2. These were the existing regression tests of DL/1 physical databases. It was quite interesting; it was running DL/1 pretty well.
[50] Tom Price later worked in the Office Products Division.
[51] Emerson Pugh. Building IBM. The MIT Press, Cambridge, Massachusetts (1995).
[52] Pugh, page 309.