John Nauman: ... at Tandem over there and I wrote the FULIST program. What he told me when I got there was you have to make some sort of contribution in terms of code, so I spent longer than I wished to learning about the vagaries of the [6520] terminal. What I hoped to do when I got there was to take a transaction system that they were starting to build and turn it into something that I thought we knew how to do based on what we'd done in System R: translate it into DB2. So through all the experiences with Eagle and all the underlying Lock Manager / Recovery Manager stuff, I thought there was a lot there we could learn from and do a lot better at Tandem, given their NonStop architecture.
Jim Gray: And we were convinced that IBM would never ship.
John Nauman: Right.
Jim Gray: Because, you know, the organization, I mean, I don't know if Plan B had turned into Plan A yet ...
John Nauman: Yes, it had. But you were convinced it would never ship; I thought they would in six months, remember. You were a lot closer to being right than I was. We brought Franco over to write the underlying data stuff for the relational database system that we wanted to build. And during the next, probably, three years, we tried to put together a NonStop SQL group, which was what the product eventually ended up being called. It was awful because there was a competing product. There's the FS story at IBM; there was a product called Rainbow[72], and Rainbow was the follow-on system. Rainbow was everything you ever ... that's where Jim actually worked when I joined. Very shortly after I joined, Jim left Rainbow, and came over and worked on the real system. But Rainbow was always pulling the resources away from what we were doing today, and looking at what we could do in six months, five years, ten years, sometime down the road. So this was a real problem. I can't remember the number of times Franco came into my office and explained to me how this Rainbow nonsense had to stop. We had to get serious and do a product. In about 1983, we had finally gotten to the point that we had critical mass, and we actually started to make some really good progress, I think. Franco was working with Andrea Borr and a couple of other people ...
Jim Gray: Louise Madrid had come in from Britton-Lee via Esvel.
John Nauman: She came in after Franco left and came back. But in any event, there was a critical mass team going on. Andrea moved over from TMF to work on the underlying file system stuff, and we were actually starting to make a lot of progress, and then Franco went away. This was ...
Franco Putzolu: ???
John Nauman: Yes, but I didn't know that at the time. This was real unpleasant. And then Franco came back, and Don [Slutz] joined us, and then things got a lot better.
C. Mohan: Why did he leave?
John Nauman: He didn't like his manager.
Tom Price: Kapali was going to make him rich.
John Nauman: I think it was the lure of a start-up.
Franco Putzolu: Yes, that's true.
Jim Gray: No, it was more complicated than that. There was this presentation; I was sitting there in a big auditorium. Dennis McEvoy, who's now head of Engineering at Sybase, stood up and talked about how wonderful Rainbow was going to be. And right in the middle of that meeting, Franco got up. He was sitting in the middle of the auditorium; he waded through a whole aisle of people; he marched down the aisle; he marched out; he went over to Esvel and accepted a job. It finally got to him.
John Nauman: I left Tandem before the NonStop SQL stuff got done, but it did get done, and from everything I've heard, it was an outstanding effort. The one thing I learned out of both the efforts that I worked on at IBM around FS and the Rainbow effort, and in every company I've ever worked for, it's the same situation: there's always the next-generation product. There's always the next thing that's going to solve all your problems, and that you should invest all your resources in, and basically stop working on what you're working on right now. Don't worry about that generation machine. That's the past; you have to look to the future. I have never worked in a company where that's worked. It is always the case that what you've got now - this is true of System R, as well - we had System R; that was something we should be working with. We shouldn't have been worried so much about changing the way SYSGEN worked, and getting rid of it, and a whole new hardware architecture, and a whole new software architecture, and objects that supported either relational views or network views or hierarchical views or whatever you wanted. We should have been trying to take slightly smaller steps but toward a much more attainable goal. That's awful to say, because it's so appealing to look at something and say, "We can change the world. We can go do something that's really important." But the problem is that there are very few of those that succeed. You look at all the successful software products I can think of - whether they're from IBM or Tandem or Microsoft - and what they are is the second or third time around of a product. Not the first time out where it's the glowing thing that everybody loves.
Mike Blasgen: Actually, one of the reasons we're here is that System R was one of the few times when a new approach was appropriate.
John Nauman: But not as a product.
Mike Blasgen: Improving the old approach is almost always the right thing to do. Improving IMS is almost always the right thing to do. But once in a while, there is an opportunity to do something new, and this was it.
John Nauman: But the difference was that System R wasn't IBM's future - FS was IBM's future, and Rainbow was Tandem's future, and whenever you've got your whole company bet on something, you start to lose ... I view System R as a very good idea that then made a lot of progress behind the scenes.
Mike Blasgen: I understand the distinction; you're right.
John Nauman: I worked at 3Com for a while, and at the time I worked there, Ethernet was just starting to become something that people recognized as being important. 3Com went off in a number of different directions, with these brave new systems, all of which caused problems in the company until they came back and focused on what their core business really was. It was Ethernet. Now they'd sort of invented that, and then carried it forward.[73] System R was something that got invented, but then got moved forward in a very logical, reasonable progression. It wasn't the thing that changed the world overnight. Those are the ones that I think are real dangerous. That's sort of my experience at Tandem. Franco, do you want to talk about how the NonStop SQL stuff actually got finished and released?
Franco Putzolu: It got finished actually pretty well. Let's see: we started in 1984 and we went to Beta in 1987, which I think is pretty reasonable.
Jim Gray: Can I interrupt you there and say something? We said in 1984, "It's going to take three years or four years, and you're not going to have a product until 1987." And Dennis McEvoy said, "What? I'm going to have to wait until 1987 to have a SQL system? Forget it." And so we gave him the fifty per cent confidence schedule, and the ninety per cent confidence schedule. The fifty per cent confidence schedule was 1986, and the ninety per cent confidence schedule was 1987. And he said, "Oh, OK."
John Nauman: But Franco's approach was that every time I go and ask him how long it was going to take, "Franco, when are you going to be done?" "I'll be done when I'm done."
Franco Putzolu: Yes, but the claim was we had to be out in 1987. We were off by about three months, which is not too bad, and I think it was a good system as far as the low-level engine; perhaps I am biased because I worked on it. I think it's still the best engine around. I mean it's the real engine that scales up as much as you want, recovers from failures in seconds, now has all sorts of on-line utilities, has locking done right - no other system does locking right. [laughter] On the other hand, there are some minuses, of course. Functionality is minimal: really basic, basic SQL. We made some major mistakes and I was responsible for some of them. We didn't try to really stick to ANSI; we tried to make it integrated with GUARDIAN: our own naming; our own security model. I think I'm guilty for the naming part, and that was a major, major mistake. It was fun to work on it. Jim, do you want to say something on it?
Jim Gray: Yes. Probably the key things about it were that the first release was for OLTP; first release was for transaction processing, and that was about 1987. People then went on and did a parallel SQL that shipped in about 1989, and I think Mike Pong could talk about that. In the last four or five years, they've worked hard to make it on-line, high-availability. So the particular things they've done is to make it possible to add indices while the database is being updated; to reorganize the database while it's being updated or accessed. These are interesting algorithms. They don't have referential integrity; they don't have triggers; they don't have foreign keys; and so on. But on the other hand, they have a lot of things that are useful for day in, day out data storage and data retrieval. It's going to be interesting to see what happens next.
Franco Putzolu: The engine is good, and it's actually interesting that back in 1989 we had parallel execution, and for about three or four years Tandem didn't do anything with parallel execution, and then all of a sudden they discovered this big DSS[74] market. But it was kind of late; other people had made the same discovery by that time.
Jim Gray: Mike Pong, do you want to say something about ...
Mike Pong: I joined the NonStop SQL project to work on the optimizer a couple months after it got started back in 1984. The part that I remembered most was that Franco had finished a large part of the executor when I joined. This stuck in my mind because everyone one else was still trying to figure out the complete design! In the first release, we did not take advantage of Tandem's parallel architecture for intra-query parallelism. Soon after we shipped the first release, another developer and I started to work on intra-query parallelism with the help of Jim and Franco. The design and implementation took about two years. When it was completed, we were very excited to actually see linear scale up and speed up for large queries. Unfortunately for Tandem, marketing for the feature did not exist until about two years ago.
Pat Selinger: Any more Tandem stories? Bob Jolls?
Bob Jolls: I can't add to that.
Pat Selinger: Perfect as is. Oracle's next then.
[72] Rainbow was an all-new system (architecture, operating system, database, etc.) intended to replace the T16. It was eventually canceled, and a project named Crystal was started to build a low-end, easy-to-use system. Crystal in turn was replaced by Catalyst, a highly-integrated, transaction-oriented, easy-to-use client/server (PC/T16) system. In about 1990, Catalyst was spun off as a new company named Cooperative Solutions founded by Dennis McEvoy, his wife Kim Worsencroft (who had been the Catalyst project leader and visionary), and several other Tandem folks. They eventually built a product called Ellipse based on OS/2 and Sybase. Cooperative Solutions was bought by Bachman Information Systems, which is now marketing Ellipse.
[73] Actually, Ethernet was invented at Xerox PARC.
[74] DSS stands for Decision-Support System.