Enable JavaScript.

IBM System/38

IBM System/38 Control Program Facility (CPF) design control group.
From left: Dave Harvey (manager), Rich Demers, Hank Norten, Howard Botterill,
Toby Barksdale, Ron Fess, Dave Truxal, Curt Pinnow, Tom Cook, John Fetvedt

1976: The Pacific Project


Imagine what it must have been like to be part of the team that sent a man to the moon: the challenge, the excitement, the sense of accomplishment at a job well done. IBM's Pacific project was that experience for me. OK, it wasn't a moon shot, but it was a large, complex project that consumed the best efforts of a large group of talented people for several years. It was also, for me, an opportunity to show what I could do as a software architect.

"I'll take Common Data Management." Ron Fess said.

"OK, that leaves the Message Handler. " Lee Laske said. "Is that all right with you, Rich?"

"Sure." I responded. I really didn't know enough about the project at that point to have any preferences.

Ron and I had transferred to Rochester, MN from Endicott, NY. We drove west together, each pulling a trailer with a boat because IBM's Moving and Living allowances did not include moving boats. We stored both boats in the garage of my new house because Ron's wasn't finished yet. The next day we reported to Lee Laske, our new manager, for assignments. I was glad to be in Rochester and working on the Control Program Facility (CPF) of the Pacific project, a new midrange computer for small businesses that would eventually be marketed as The IBM System/38.

What made Pacific so attractive to me were its carefully layered structure and its support for encapsulated objects in a huge, single level memory. This was a far cry from what I had learned about mainframe operating systems (S/360-370 MVS), and a real advance in operating systems technology. I knew that many of the basic ideas of the Pacific project had come from the abandoned Future Systems project, but their continued existence in Pacific was because of one man, Glenn Henry, the driving force behind the whole project. At the time, he was only a distant figure in my management hierarchy, but I later learned that it was his will and drive that had kept Pacific alive when FS failed.

It wasn't quite correct to say that the CPF was an operating system, because there was a major layer of programming under it, the Vertical Microcode or VMC layer, that did a lot of the work typically associated with operating systems. Instead, the CPF was more like a layer to make it easy to program, operate, and use the system. The VMC layer defined the Machine Interface (MI), the instructions that the CPF and all other programs could execute.

The VMC was in an advanced state of design and development when Ron and I joined the Pacific project, but the CPF layer was sketchy at best. CPF programming teams were already in place for many of its components, but a couple of important components still remained to be staffed. One of these was the Common Data Management component, that Ron decided to work on. It provided a single set of interfaces for working with the database, with with various devices and with communications. This made it easy to redirect the input and output of data in various ways.

Another was the Message Handler, a messy component with many seemingly unrelated requirements. Whenever a user or program needed to communicate with another user or program, it would send a message to a named queue, where it would be received and processed. Some of these messages were impromptu text, others were system commands entered by users, and still others would be predefined messages with variables for substituting data from the sender. Some messages would be received by programs, some would be printed, others would be stored in job logs or in a system history log, and still others would be displayed to users at terminals. And to make things more interesting, all of this needed to be integrated with the exception signaling and handling mechanisms of the MI. Altogether, this would be an interesting challenge, one in which I could test my abilities as a software architect.

First, I had a lot of learning to do. For the first month, I attended classes on the MI that Bob Tracy was teaching, and generally spent the bulk of my time reading and studying project specifications. Although I did quite a bit of thinking about the Message Handler, I was intent on gaining a solid understanding of the overall system before committing a specific design to paper. But there were other people who needed to understand what the Message Handler's interfaces would be. It was the one component that would be used by every other component of the CPF.

One day, I overheard Tom Schwalen talking to Howard Botterill in Howard's office. Our offices were in a converted discount store and their walls, although eight feet tall, didn't reach anywhere near the ceiling. Private conversations were nonexistent.

"Has Rich even gotten started on the Message Handler?" Tom asked.

"I don't think so." Howard replied. "He spends all of his time reading the specs. Maybe some one should tell him how badly we need to pin down the Message Handler's interfaces."

I had heard them, and soon I passed out a first draft of a design. The basic ideas were in place, but there were still aspects of the design that bothered me, loose ends that just didn't fit in my design. But at least the programmers could start using the interfaces I had pinned down!

The toughest of the loose ends I had to consider was the integration of the exception handling facilities of the MI with CPF message handling. An exception is a notification that an error has been detected, such as an attempt to divide by zero. Exceptions are signaled by MI instructions, but they can also be signaled by programs for any abnormal conditions they detect. A program can monitor for an exception that might be signaled to it and then handle it in some way appropriate to it. Often, this involves a branch to error handling logic, away from the program's normal logic flow.

The traditional alternative to exceptions is the use of return codes that convey how an operation concluded, but their use in the CPF was outlawed. Testing return codes after each operation is a nuisance and they tend to be ignored, which allows errors to propagate in a system. In contrast, if an exception is ignored, the Message Handler catches it and takes default action, such as taking a memory dump and recording a message in the system log. These actions make the immediate cause of the error obvious. The result is a much more stable and reliable system.

The proper relationship between MI exception handling and the CPF Message Handler gnawed at my mind for several weeks. They seemed to be just different ways of doing the same things, but each had strengths the other lacked. Then, on a Saturday morning, while alone in a our converted discount store, the solution came to me in a flash of insight. Drawing rapidly on my white board, I sketched out the correct relationship between MI instructions, program invocations in a process stack, the message handler, the job log and even command entry by interactive users. I returned home that day excited that I had found an elegant and creative solution. The month of studying I had done had really paid off.

The next week, I presented this design to Dave Harvey's Design Control Group, to other key technical people, and to key CPF managers. The design was quickly accepted as the right way to go, but almost every CPF programmer wanted my head. In spite of the fact that the changes they had to make to accommodate the new design were modest, no changes at all were acceptable to them; they had schedules to meet. It was only the fact that the new design was so clearly superior that allowed me to proceed with its adoption. But even so, I had to spend much of the following two years teaching people the basic ideas of the message handler and writing "best practice" papers about its use.

In a large project, creativity is sorely needed to find the good designs. But good designs don't come full blown from the foreheads of geniuses. They're the result of hard work over time as relationships are understood among components and as further problems are uncovered. To the extent possible, design changes must be accommodated, but the closer a project is to its deadlines, the more difficult change becomes. Software development is not like research, where there is the luxury to experiment with a variety of designs until an optimal one is found. Still, some changes may be necessary, even if they are a bit painful.

I considered the design of the Message Handler to be my best and most creative work to date. More than twenty years later, and four years after leaving IBM, I ran into Dave Dykstal at the OOPSLA'96 conference in San Jose, CA. He had also been involved in those early days of the Pacific project. During a conversation about object design issues, Dave commented that the difference between good design and great design was largely a matter of aesthetics. I agreed with him, but I also knew that good aesthetics were the result of intensive study and hard work.

1976: Le projet Pacific


Imaginez comment il aurait été de faire partie de l'équipe qui a envoyé l'homme sur la Lune : le défi, l'excitation, le sentiment de satisfaction d'un travail bien accompli. Le projet Pacific d'IBM a été presque la même expérience pour moi. OK, ce n'était pas un « tir vers la Lune », mais c'était un grand et complexe projet qui a drainé les meilleurs efforts d'un grand groupe de personnes talentueux pendant plusieurs années. C'était aussi, pour moi, une occasion de montrer ce que je pouvais faire comme architecte de logiciels.

« Je vais prendre la composante de Gestation des Données en Commun, » a dit Ron Fess.

« Bien, cela nous laisse le Gestionnaire des Messages, » a dit Lee. « C'est bien pour vous, Rich ? » m'a-t-il demandé.

« Bien sûr » j'ai répondu. En fait, je n'ai pas de connaissance suffisante à ce point-là pour n'avoir aucune préférence.

Ron et moi avons déménagé de Endicott dans l'État de New York à Rochester dans l'État de Minnesota. Nous avons conduit vers l'ouest ensemble, chacun dans sa propre voiture en remorquant son bateau parce qu'IBM ne payerait pas pour le transport des bateaux. Nous avons garé les bateaux dans le garage de ma nouvelle maison parce que la maison de Ron n'était pas encore finie. Le lendemain matin, nous nous sommes présentés à Lee Laske, notre nouveau patron, pour nos missions. J'étais heureux d'être à Rochester pour travailler sur le « Control Program Facillity (CPF) » du projet Pacific, un nouvel ordinateur de gamme moyenne, pour les petites sociétés, qui serait commercialisé comme Le System/38 d'IBM.

Ce qui m'a attiré à Pacific était sa structure bien multi-niveaux et son soutien pour des objets mis en capsules dans une grande mémoire qui avait un seul niveau. Ceci était très différent des systèmes d'exploitation des ordinateurs centraux (S/360-370 MVS) que j'avais appris et une vraie avancée dans la technoligie des systèmes d'exploitation. J'ai su que plusieurs idées du projet Pacific étaient venues du projet abandonné pour Les systèmes d'avenir (Future Systems ou FS), mais leur existence a continué dans le projet Pacific grace à un homme, Glenn Henry, l'énergie derrière tout le projet. À ce moment-là il était seulement une figure distante dans ma hierarchie d'administration, mais j'ai appris plus tard que c'était sa volonté et son énergie qui avaient gardé Pacific en vie quand FS est mort.

Ce n'était pas correct de dire que le CPF était un système d'exploitation parce qu'il y avait un niveau de logiciel majeur au-dessous du CPF, le « Vertical Microcode (VMC) », qui faisait tant de travail d'un système d'exploitation. Au contraire, le CPF était niveau pour faciliter la programmation, l'opération et l'utilisation du système. Le niveau VMC définissait « l'Interface de la Machine (MI) », les instructions que le CPF et tous les autres programmes pouvaient exécuter.

Le design et le développement du VMC était dans un état avancé quand Ron et moi avons rejoint le projet Pacific, mais le design du CPF était incomplet. Les équipes étaient déjà en place pour quelques composantes, mais il y avait encore des composantes qui avaient besoin de personnel. Une de ces pièces était la composante de Gestation des Données en Commun sur laquelle Ron avait décidé de travailler. Cette composante fournissait un seul ensemble d'interfaces pour utiliser la base de données, tous les appareils et les communications. Ceci le rendrait plus facile pour réadresser les entrées et les sorties de données de plusieurs façons.

Un autre composante était le Gestionnaire des Messages, une composante très compliquée, avec beaucoup de besoins qui semblaient être sans rapport. Quand une personne ou programme devait communiquer avec une autre personne ou programme, il pouvait envoyer un message à une queue nommée, où il pouvait être reçu et traité. Certaines messages seraient des textes impromptus, d'autres seraient des commandes au système entrés par des utilisateurs et d'autres messages seraient des textes définis en avance avec des variables dans lesquelles les données pouvaient être substituées. Certaines messages seraient reçues par des programmes, d'autres seraient emprimés, d'autres seraient gardés dans l'historique du travail et encore d'autres seraient présentés aux personnes sur les terminaux. Et pour rendre des choses plus intéressantes, tout ceci devait être intégrer avec les mécanismes du MI pour communiquer et écouter les exceptions. En tout, cette composante serait un bon défi, un sur lequel je pouvais tester mes capacités comme architecte de logiciels.

D'abord, j'avais beaucoup à apprendre. Pendant le premier mois, j'ai suivi un cours sur le MI que Bob Tracy à disponser et j'ai passé beaucoup de temps à lire les spécifications du projet. Même si j'ai réfléchi au sujet du Gestionnaire des Messages, j'étais résolu à comprendre le système dans son ensemble avant que je ne dessine pour ça. Mais il y avait d'autres personnes qui devaient comprendre les interfaces et les facilités du Gestionnaire des Messages. C'était la seule composante qui serait utilisée par tous les autres composantes du CPF.

Un jour, j'ai écouté Tom Schwalen parler avec Howard Botterill dans le bureau de Howard. Nos bureaux étaient dans un magasin rénouvé et ses murs de 2.4 mètres de haut n'atteignaient pas le plafond. Les conversations privées n'existaient pas.

« Est-ce que Rich a déjà commencé son travail sur le Gestionnaire des Messages ? » a demandé Tom.

« Je ne pense pas, a répondu Howard. Il passe tous son temps à lire les spécifications. Peut être qu'il faudrait lui dire à quel point nous avons besoin des interfaces du Gestionnaire des Messages. »

Je les ai entendus et bientôt j'ai publié la première ébauche du dessin. Les principales idées étaient en place, mais il y avait des aspects du dessin qui m'inquiétaient, des choses désœuvrées qui n'étaient pas mises en bonne place dans le dessin. Mais, au moins, les programmeurs pouvaient commencer à utiliser les interfaces que j'avais mises sur pied.

Le plus difficile des désoeuvrés que je devais considérer était l'intégration des mécanismes du MI pour envoyer et écouter les exceptions avec le Gestionnaire des Messages du CPF. Une exception est une notification qu'une erreur a été détectée, tel qu'un tentative de diviser par zéro. Les exceptions sont envoyées par des instructions du MI, mais elles pouvaient être envoyées par des programmes pour des conditions anormales qu'ils avaient détectées. Un programme peut écouter les exceptions qui lui sont envoyé et puis traiter de la façon appropriée. Fréquemment, ceci occasionne d'aller à une branche dans la logique pour traité l'erreur, loin du circuit normal dans la logique du programme.

L'alternatif traditionnel aux exceptions est les codes de retour qui communiquaient qu'une opération était terminée, mais leurs utilisations dans le CPF étaient interdites. Faire des tests sur les codes de retour après chaque opération est agaçant et ils sont normalement ignorés. Ceci a permis aux erreurs de se propager dans le système. Au contraire, si une exception est ignorée, le Gestionnaire des Messages l'attrape et prend des actions par défaut, telles que imprimer la mémoire du programme et enregistrer un message dans l'historique du système. Ces actions rendent la cause immédiate de l'erreur évidente. Le résultat est un système qui est plus stable et plus sûr.

Le rapport propre entre les facilités du MI pour communiquer et écouter les exceptions et le Gestionnaire des Messages a rongé mon esprit pendant quelques semaines. Ils semblaient qu'il y avait deux manières de faire la même chose, mais chacune avait les forces que l'autre manquait. Puis, un samedi matin, pendant que j'étais seul dans notre magasin converti, la solution m'est venue tout à coup. Dessinant rapidement sur mon tableau blanc, j'ai esquissé le rapport entre les instructions du MI, les invocations des programmes dans la pile d'un processus, le Gestionnaire des Messages, l'historique du travail et même l'entrée des commandes au système par les utilisateurs. Je suis retourné chez moi ce jour-là excité d'avoir trouvé une solution creative et élégante. Le mois dans lequel j'avais étudié m'avait remboursé.

La semaine suivante, j'ai soumis ce dessin au « Groupe pour le Control du Dessin » de Dave Harvey, aux personnes techniques et aux dirigeants hauts placés. Le dessin a été adopté comme le meilleur chemin à suivre, mais presque tous les programmeurs voulaient avoir ma tête. En dépit du fait que les changements qu'ils devaient faire étaient modestes, pas de changement de tout étaient acceptables pour eux ; ils avaient des dates limites de satisfaire. C'était seulement le fait que le nouveau dessin était clairement supérieur qui m'a permis d'avancer avec ces adoptions. Mais même si, je devais passer les plupart des deux années suivantes à enseigner à des programmeurs au sujet du Gestionnaire des Messages et à écrire des articles sur le « meilleures pratiques » à propos de ces utilisations.

Dans un grand projet, la créativité est bien nécessaire pour trouver les meilleurs dessins. Mais les meilleurs dessins n'arrivent pas du front des génies. Ils sont le résultat de gros travail pendant le temps où les rapports sont compris parmi les composantes et pendant que des problèmes sont découverts. À l'étendue possible, les changements de dessin devaient s'accommoder, mais plus proche le projet de ses dates limites, plus difficiles les changements sont. Le développement des logiciels n'est pas comme la recherche, où on s'offre le luxe de faire des expériences avec un variété des dessins jusqu'à-ce que la meilleure soit trouvée. Tout de même, quelques changements peuvent être nécessaires, même s'ils sont un peu pénibles.

J'ai considéré le dessin du Gestionnaire des Messages comme mon meilleur et mon plus créatif travail à cette époque. Plus de vingt années plutard et quatre années après que je sois parti d'IBM, j'ai rencontré Dave Dykstal à la conférence de OOPSLA'96 à San Jose, dans l'État de Californie. Il avait été impliqué dans les premiers jours du projet Pacific. Pendant une conversation au sujet de dessin avec des objets, il a commenté que la différence entre un bon dessin et un meilleur dessin n'était pour la plupart qu'une question d'esthétique. J'étais d'accord avec lui, mais j'ai su que les bonnes esthétiques étaient le résultat d'une étude intensive et d'un travail énorme.

Cartoon about handling an exception (unknown artist from the Pacific Project).