have been DL/1 support, but it never happened.
Roger Miller: Exactly. We had the spec, we had the
running code, we kept going, and we said, “Can we ship a product that is this way?” From IBM we just said, “Here’s the product; we can ship it, but will customers accept it?” We tried it on a couple of customers, and “Heck, no!” was the kindest they said. It was nice to have customers who were honest with us.
Franco Putzolu: Was it performance, was it page-locking,
was it functionality?
Roger Miller: Performance was a negative, but the primary
issue was the inability to tell if the conversion would work. Remember, this is building the calls at runtime, and we had three or four per cent of the calls which were not going to work. There isn’t any code inspector that could determine when they were using a function that would fail. So until you can get to one hundred per cent, it’s not acceptable. Some of the Brand X vendors can get away with a little less than we can, but the real killer was: you could never tell when it was safe to convert.
Franco Putzolu: When did it die?
Roger Miller: Release 2, essentially. Because we had
Release 2 of DB2, which was a 1986 GA. We switched over in about 1984 or 1985 to say we can’t do DL/1, so let’s go pedal to the metal. Let’s support relational, and do what relational DBMS needs to make those customers successful.
Don Slutz: I’m not sure when it was, maybe Don
[Chamberlin] can help, but Frank King had Bob Taylor and myself go off for a couple of months and look at supporting DL/1 calls – I think 1978 or 1979; do you know? I was working for you; did you know?
Roger Miller: The team that essentially built it for us were:
Sid Kornelis, who came from IMS. Sid knew IMS backwards, forwards, left, and right.
Jim Gray: It had fifty thousand test cases …
Roger Miller: Yes, we had the IMS regression test bucket.
Jim Gray: … fifty thousand, which was a number that
boggles the mind.
Roger Miller: We had Lloyd Harper, who had the long
history of many, many products that never shipped. We had Bob Engles, doing the part working for Homer [Leonard], and Homer was right in line with Bob Evans, down saying, “Well, gee, this product is only a toy until it supports DL/1.” They were going to get it to ship until we came to the realization that it didn’t matter if we did or not; we couldn’t sell it if it did.
Mike Blasgen: And none of the good guys won, right?
[laughter]
Jim Gray: I think Oracle. [laughter]
???: No, he meant Tandem. [laughter]
Mike Blasgen: Oh, SQL, this is an SQL review. SQL won.
Josephine Cheng: Well, I was really fortunate. Once I
graduated from school, I joined IBM, and I worked in the project Eagle. At that time there were walls and doors that kept everyone out. You know, in Santa Teresa, we have towers that are all connected. They specifically put in doors to separate all the connections to other buildings – you needed a special badge to get in. So I joined the project, and Franco was working diligently; Irv was on an assignment to STL also working very diligently. Occasionally I saw Jim [Gray] and also occasionally I heard loud voices shouting, and I knew it was Andy [Heller].
I worked on the Buffer Manager for about two years, and then I transferred to John Nauman’s department. Let me share a couple of experiences I had on our productization of Research code.
Mike Blasgen: You’re supposed to be kind.
Josephine Cheng: Yes. Maybe next time I won’t be invited.
[laughter] I always have to have many system R papers all over my desk to help me understand the code. For instance, there’s the part that talks about PTREE nodes. The Parse Tree node has fields called P1, P2, P3, P4, P5. And so in order to know the meaning, you have to go and look at the reference: P1 has different meanings for different node types. If this is a column node, P1 must mean “pointer to the table node” and P2 means “pointer to the descriptor.” I ended up having little pieces of paper hanging all over my office.
In one of the modules – I don’t know who wrote that – it was about a semantic routine that checks on type
compatibility. Franco wrote that? It had this interesting algorithm for checking type compatibility. You take “modulo” four and compare the result with the generic type to see if they are the same. You wondered, “Why modulo four?” It turned out that modulo four gives you four bits to use. I thought the designer must have thought that four bits was enough to cover any foreseeable type. If you have numeric types (two to the power four), you can have sixteen different numeric types; should be enough, right?
Unfortunately, we have NULL and non-NULL, so that takes up two. Later on, we added Kanji support, which reserved double-byte NULL and double-byte non-NULL. So each numeric type took up four codes. Then we had INTEGER and SMALL INTEGER, which took up eight codes. When we productized the code, we had to add DECIMAL and FLOATING POINT. That took up all 16 codes.
Unfortunately, once we got the code out the door, customers asked for short FLOAT instead of long FLOAT to save disk space, and some asked for 16-byte FLOAT and 31-byte DECIMAL for more precision. So much for modulo four!
As I mentioned before, I always admire all the System R people. I think they’re great inventors, not only on
algorithms and doing all the great work, but they are also very good in creativity, in inventing things, such as words like “Search Argument” making it into an adjective:
sargable67 So when I talk to a customer, I always say, “This is a sargable predicate.” They look at me and say, “What?”
Jim Gray: Everybody has sargable predicates now: Sybase
and Oracle …
Josephine Cheng: Yes, and customers diligently look up
the meaning in the dictionary. So the people who write the manuals – our ID68 folks – they didn’t like that. And they named it Type 1 predicate: that means it can be processed by the Data manager; Type 2 predicate: by RDS – I don’t like that; I really want to call them sargable predicate.
Anyway, I had lots of fun looking at System R code and productizing it. As a matter of fact, when we finished our first driver, we felt such relief – if we had not taken the System R code, I don’t think we would have made our DB2 Release 1.
Bob Yost: What were your instructions? Were you told to
take basically the RDS, because you had another Data Manager? It wasn’t going to be the one from System R, but you were taking the top half of the System R technology as sort of a blue-print. Were you inspired by it, or were you to look at the code and try to translate it? Now when they went to Endicott, they just said, “Take the code. Just translate it; don’t even think about it.” But you must have had different instructions.
Josephine Cheng: Well our instructions were to make it
work. [laughter] The first thing that we did was to try to understand it, so I think I contacted every single person in the room: Mario, Pat, Don – trying to decipher and understand what it’s trying to do. For our first release, we would translate all that code so it would work with our system code: the storage manager, and trace, accounting – you know, all the productization work. We tried also to add some features to the Release 1, but not really that many – only those that we needed for commercial use. So we added floating point, and decimal. At the time, I took Optimizer; Jerry Baker took ASLGEN; and Nick Nomm took
ODEGEN. Back then machine time was more expensive than human salary, so we went to work on Saturdays and Sundays. The three of us were occupying the whole floor on
67
The RSS supported a simple search capability: you could specify a “search argument” (SARG) of a simple
comparison in canonical form (e.g., salary greater than constant) and the RSS would perform the search along a specified path. This offered performance advantage. To use this the higher level software had to recognize when SARGs could be used. If the SQL statement itself contained a predicate that could fit the SARG model, then the predicate was called sargable.
68
ID stands for Information Developer.
Saturdays and Sundays. We did all the RDS work and Jerry had the idea that we should go and support symmetric view. It means when you select something from a view, you should get a failure code if you try to insert out of the scope of the view. So we also added the symmetric view function to Release 1. So the goal of Release 1 was essentially trying to make it work, add very minimum function, and get it out of the door as soon as possible.
John Nauman: It was a lot of the same stuff that was going
on at Endicott; that is, there was a translation from PL/1 to PL/S; we had to do that.
Josephine Cheng: That was already done by Endicott.
John Nauman: So we had to do that, but that was done by
Endicott, so we could take that. The amount of additional work was relatively small, except in the precompiler area, where we did, I think, quite a bit of things.
Roger Miller: Where we had to refit and refit and refit
because we learned what the System R code needed. I built the PTREE many times.
Josephine Cheng: Anyway, that was a really fun
experience.