1981-1982: DDM and Golden Gate
Sometimes, you don't get what you bargained for. Returning to Rochester from my brief sojourn in IBM Research, I took a job as a software architect in the Golden Gate project. I really didn't want to go back into the System/38 group, and working on System/36 was of no interest to me at all, especially not after working on the System/38. While I had been aware of Golden Gate for several years, I hadn't paid much attention to it because it didn't seem to be going anywhere. But now, I wasn't in a position to be very choosy.
The Golden Gate project began in Rochester in 1978, but it had a history that went back several years earlier. IBM's Architecture and Technology (A&T) group in Raleigh, NC had been working on IBM's Systems Network Architecture (SNA) for many years. Initially, SNA was designed as a hierarchical network, with mainframe computers communicating with and controlling non-programmable terminals. But another dimension became increasingly important, that of peer-to-peer communications between systems. An enterprise might have computer systems in its headquarters, its branch offices, its factories and its warehouses. These computers needed to be able to communicate with each other, but a hierarchical topology wasn't appropriate because no single computer was in control. Instead, a more telephone-like model was developed in which any computer could call-up any other and either request services from it or transfer data to or from it.
A crucial aspect of peer-to-peer communications is that program A running on computer X can call-up computer B and ask it to start program Y so that programs X and Y can communicate with each other. For example, an Order Entry program running in a Branch Office computer can call-up a Warehouse computer and start-up its Inventory Query program. Then, as orders are entered, the availability of stock in the warehouse can be checked for each order.
SNA's Advanced Program to Program Communications (APPC) architecture was initially conceived in terms of application programs distributed throughout a network and working on various aspects of a total application. However, it was also clear that operating system programs in remote systems could also participate in APPC networks, and pushed to its logical conclusion, the result would be a distributed operating system. For example, if a headquarters application needed to print a report on the printer of a Branch Office computer, then the headquarters application could call-up the Printer Control program of the Branch Office computer's operating system.
Without much trouble, a number of such operating system services were identified as good candidates for a distributed operating system, and a series of meetings was held by the A&T group to define the formats and protocols to be used for requesting distributed system services. The initial interest in this effort was high, and representatives from IBM's mainframe and minicomputer systems participated. However, there were two factors working against it. First, mainframe communications remained predominately hierarchical, and there was no great customer demand for APPC at that time. And second, the services offered by IBM's operating systems varied greatly in both capabilities and interfaces. For example, the Printer Control programs all offered different services, through different interfaces. How could these differences be overcome?
There are two ways of solving this problem. The first is for some Czar to make a choice from among the services and interfaces offered by the communicating systems. For example, the Virtual Storage Access Method (VSAM) file services and interfaces of the Multiple Virtual Storage (MVS) mainframe operating system could have been chosen. Then, all client systems requiring access to remote files would have supported VSAM interfaces, and all systems providing distributed files services would have provided VSAM services. The second solution is to define a new set of services and interfaces that can be mapped to those of the communicating systems.
It quickly became apparent that it would not be possible to dictate the services and interfaces of any one existing system. To begin with, there was no Czar; IBM's systems programming had always been organized by system, and not by function. The managers of each system house were each responsible only for the success of their own system and they had no incentives for cooperating with each other. For example, instead of a single file system product ported to multiple systems, IBM had four file systems, each separately developed and with no communications among the development groups. The representatives of each IBM system house felt duty bound to protect the interests of their own system to the death. There was no way, for example, that the System/38 representatives, with their new and elegant operating system, could accept what they considered to be the tired technology of MVS, nor were the MVS representatives willing to give an ounce of credit to the System/38's requirements. After all, MVS was the big dog, and not the tail.
The A&T effort came unraveled and disbanded, but there was another factor that made continued effort on distributed services important to the System/36, and System/38 products of the Rochester lab. These systems were selling in multiples to single customers who demanded good ways of connecting them to each other. So, the Golden Gate project was started to provide distributed services among the Rochester products. At the time that I joined Golden Gate, about thirty people were assigned to it, roughly half devoted to defining the formats and protocols for the distributed services, and half devoted to planning, market analysis, and other related tasks. The project had been in operation for several years and had produced some initial specifications, but had no committed product plans.
The Golden Gate project was housed in Broadway Hall in offices above Rochester's downtown post office, one of several groups working off site because of space constraints at IBM's sprawling complex of offices, laboratories and factories in Rochester. When I arrived, Peter Hanson greeted me with some bad news and some good news. The bad news was that Golden Gate had folded because a sound business case for it could not be made. Everyone I talked to felt that it was just a matter of time before distributed services would become important, but they hadn't found a way to say when or how valuable it would be. The good news, however, was that a single architecture department would be left in place to continue design work. Peter was to be its manager and I was assigned to him as a software architect.
I had known Peter for some time and I thought he would be a pretty good manager to work for. A stocky man with a keen intellect, an assertive personality, and a nervous laugh, Peter had worked extensively with the Raleigh A&T group in the design of SNA APPC. But his apparent good cheer also hid a would-be tyrant. A typical saying of his in planning a meeting was "We'll nail the dogs to the table and force-feed them the raw meat." This attitude soon came out in his management of our department. It was not at all unusual to hear Peter bellowing at someone in his office, and if you happened to be his victim, the bellowing was often accompanied by Peter attempting to dominate you with his considerable bulk, literally throwing his weight around. Within a few months, the entire department was in rebellion, and nothing significant was being accomplished. This situation ended only when higher levels of management heard the complaints, and seeing no progress, finally disbanded the department. Peter returned to a purely technical role, and in the mid 1980's played a major role in the Silverlake project, which led to the development of the IBM Application System/400 (AS/400), essentially the System/38 with support for System/36 applications. He just didn't belong in management.
Once again, I was out of a job, and nothing in Rochester had much appeal to me. At this time, the major work underway in the Rochester lab was the development of release after release of both the System/36 and the System/38, nothing I wanted to sink my teeth into. Most of all, I wanted a project in which I could take the lead and develop it as my own baby.
My opportunity came in the form of a tall, hawk-nosed, bald-headed dynamo named John Bondy who had been part of the Golden Gate planning group. I barely knew him, but he gave me what I wanted and needed, an orphan project of potentially enormous importance that no one else wanted because of its long history of failure. Neither John nor I had any idea whether we would succeed or fail, but I didn't have anything to lose and John was a natural entrepreneur who knew a gem when he saw one. John convinced me that the distributed data management parts of Golden Gate, called
1981-1982: DDM et la Porte d'Or
Désolé, pas encore traduit.