Enable JavaScript.

Cover of the DRDA Reference Manual

1988-1990: DDM & DRDA

One of the many trips I took while working on IBM's

(DDM) was to IBM's , a ten week school for technical personnel in New York City. I had previously attended SRI and had found it a tremendously rewarding experience. This time, I visited Charlie Bontempo, the SRI professor who taught classes on databases. I gave Charlie my DDM presentation and he found it interesting but dated. No, he said, the future of data management was not with record oriented files, it was with the relational databases (RDBs) that had come out of IBM Research.

In Charlie's opinion, I should have been working on support for RDBs distributed across a network. In his view, data tables and indexes should be on whatever system had the most use for them, in whole, in part, replicated as necessary, and accessible from anywhere on a network via the Structured Query Language (SQL). Great, but that was not what the products implementing DDM wanted, at least not yet. There was really nothing I could do about it until it was wanted by at least one of IBM's four RDB products.

That happened sooner than I thought it would. Scientists at IBM's Almaden Research Laboratory, near San Jose, CA, had been working on System/R*, a prototype of a distributed RDB. They felt it was now time to turn it into a marketable product. The problem was that System/R* was based on System/R, the research prototype of a RDB. The four RDB products being marketed by IBM were the following and they could not interact with each other:

Roger Reinsch, a Senior Programmer in the DB2 group of IBM's Santa Theresa Programming Laboratory (also near San Jose, CA) took on the task of leading a cross-product team to define a Distributed Relational Database Architecture (DRDA). He enlisted:

  • Bruce Lindsay, a System/R* researcher as a consultant,
  • a representative from the Systems Network Architecture (SNA) group (from Raleigh, NC) who had designed its Advanced Program to Program Communications (APPC) facility,
  • Paul, Roever (from Sindelfingen, Germany), who had developed a specification for describing data,
  • Rick Sanders and me from the DDM architecture team (from Rochester, MN) to define appropriate messages and replies,
  • and representatives from each of the RDB products.

The communications part was the easiest to resolve. The already documented DDM Conversational Communications Manger was suitable with only minor enhancements. However, Rick and I had trouble convincing the others of this fact as they initially viewed DDM as only being about message formats. It helped that we were able to easily extract a subset of the DDM specifications that they could more easily evaluate and accept. (See

for more on this issue.)

A RDB is actually an implementation of SQL that includes the creation, management, querying, updating, indexing and interrelationships of tables of data. An interactive user or program can issue SQL statements to the RDB and receive tables of data and status indicators in reply. The specification of appropriate DDM messages for this was straightforward. However, SQL statements can also be compiled and stored in the RDB and then invoked by name. This is important for the efficient operation of application programs that issue complex, high-frequency queries. It is especially important when the tables to be accessed are located in remote systems. Here things became considerably more difficult as each of the IBM RDB products had its own interfaces for compiling and invoking SQL packages. Defining supporting DDM messages in this area required many months of negotiations within the DRDA group. This was an area where the RDB product representatives had to take the lead, but Rick Sanders and I did our best to explain the results in the DDM specifications.

So far so good, but one more issue remained. The four IBM RDBs also encoded and stored data in different ways: EBCDIC vs ASCII encoding of character data, hexadecimal vs IEEE encoding of numbers in scientific notation, big-endian vs little-endian encoding of integers, and so forth. The data in the tables returned by a target RDB had to be described so that the source RDB could convert the data to a form usable by the original issuer of the SQL statement. Roger had enlisted Paul Roever for the data description aspect of DRDA. He had been working on this issue at the behest of IBM's Mixed Object Document Content Architecture (MODCA), and he had a design in place that he called Formatted Data: Object Content Architecture (FD:OCA). The only problem was that it was one of those bit-mapped designs that I had rejected for DDM because I found it difficult to understand, create and interpret.

Meanwhile, I had been working on an extension to DDM called

(DD&C) for the mainframe products that were implementing a DDM record-oriented server. Suffice it to say that neither Paul nor Roger was happy when I proposed a purely DDM/DD&C solution. work out a compromise with Paul was not successful; he wasn't about to give up a key user of FD:OCA, and multiple attempts to work with FD:OCA had convinced me it was not a good design. We next locked horns at a meeting of the DRDA control board. I presented the DDM/DD&C solution and asked the DRDA product representatives to choose. They chose the DDM/DD&C solution, because it was easier to understand and because they already had the programming to work with DDM objects and did not want to have to do something radically different.

I assumed that a final decision had been made, but such was not the case. At this time, IBM was attempting to rationalize its support for application programming across its various system products. Systems Application Architecture (SAA) was essentially an attempt to select and bless acronyms as being IBM's official application strategy. Systems Network Architecture (SNA) Advanced Program to Program Communications (APPC), SNA Distribution Services Architecture (SNADS), MODCA, DDM, and DRDA had all been so blessed.

Unknown to me, Roger Reinsch and Paul Roever had done some back room lobbying and asked that FD:OCA also be blessed for DRDA use. I was asked to justify why DDM's data description specifications should be used instead. Arguments of design quality, processing efficiency and product choice fell on deaf ears. I hadn't been astute enough a politician, so I had no choice but to define a DDM object to carry FD:OCA as its data as it flowed between DRDA systems. Unlike other aspects of DDM and DRDA, I did not attempt to describe FD:OCA descriptions in any way; that was Roger and Paul's problem.

Sometime after the SAA meeting that blessed FD:OCA for DRDA, I was approached by Sam Resch, the AS/400 representative on the DRDA work group. He had learned that I was continuing work on DD&C. He objected, saying that I should drop it in favor of the SAA blessed FD:OCA. I explained that I had other, non-DRDA, products that had already expended considerable effort implementing DD&C and did not want to use FD:OCA; that I had no choice but to continue. This argument did not impress him. (See

for the rest of this story.)

Level 3 of DDM Architecture, which included DRDA, was published at the same time that DRDA was publicly announced. Awards were given to the key participants in the design of DRDA; Rick Sanders received a second Outstanding Contribution Award and Roger Reinsch and I received Outstanding Innovation Awards, again with nice checks. We also participated in a US patent application. Shortly afterwards, Rick left the DDM architecture team and returned to the Rochester laboratory; I continued to work on DD&C. Further DDM architectural work on DRDA was done by Jan Fisher and Sunil Gaitonde in the years after both Rich Sanders and I had left the DDM architecture team.

A small argument ended my participation in the DRDA effort. I saw DDM as the encompassing architecture, with DRDA being DDM's support for distributed RDBs. After all, DDM architecture provided the conceptual models, the messages and the protocols of DRDA. It even carried FD:OCA objects. There really wasn't much else to DRDA beyond a separate reference manual. Roger Reinsch did not see things this way. For him, DRDA was the encompassing architecture and he sold it that way. I should have realized that this was an ego issue and not an argument worth having.

References

  • R. Reinsch, Distributed database for SAA, IBM systems Journal, Vol. 27, No. 3, 1988, p. 362
  • Distributed Relational Database Architecture Reference, IBM SC26-4651-0, 1990.

1988-1990: DDM & DRDA

 

Désolé, pas encore traduit.



IBM Outstanding Innovation Award for Development of SAA Distributed Relational Database Architecture

US Patent for query language execution on heterogeneous database servers

US Patent for describing and converting data beteween heterogenous database servers