Enable JavaScript.

1975: The Future Systems Project

The last project I worked on in IBM's Endicott programming center was the infamous Future Systems or FS project. An attempt to leapfrog IBM's own System/360 mainframes, the FS project was a huge, tremendously expensive failure whose development had spanned IBM laboratories throughout the United States and Europe. Some people said FS was too grandiose to ever succeed; others blamed the number of people and laboratories that tried to grab a chunk of it; and still others blamed the need for compatibility with IBM's existing System/360 technologies.

A lowly Senior Associate Programmer, I only saw a small piece of the project and was mostly oblivious to the political turmoil that surrounded FS. I was part of a department assigned to design the performance measurement and tuning component of the new operating system. We never got very far into this task, but I got to read the FS "Requirements and Objectives" documents and I got to study the system's overall design. Someone had done a wonderful piece of work! In particular, the hodgepodge of memory management techniques then found in most systems was to be replaced by a single, uniformly addressed memory space. "Objects" representing data and system resources were automatically managed in that address space by the system itself.

After the death of FS, the Endicott programming center was like a morgue. No one seemed to have any idea what we should work on next. Management was scurrying around looking at possibilities, but the people who should have been brimming with ideas for new projects, the senior technical staff, were ominously quiet. Perhaps FS had burned them out. On one occasion, my second line manager came to work carrying shopping bags full of paperback books, mostly Science Fiction. He passed them out and said to keep things quiet until management figured out what to do next. This went on for many months.

I worked on graduate school projects and completed our section of the FS specifications. Everyone told me this work was pointless, but I thought the topic of system performance tuning was interesting, and that someone in the future might want to develop it further. The latter was pure day-dreaming; that sort of reuse never occurs in IBM. The real point of finishing it was that I was enjoying the work. It was my first experience in high-level system architecture, a line of work I would later do full time, in preference to programming.

The best thing Endicott management found was to take over VM/CMS, an operating system for mainframes, from the IBM laboratory in Boeblingen, Germany. I wasn't interested in working on this, but could see no alternatives until I saw a job opening posted on the bulletin board. Anyone in the Endicott programming center who was interested could apply. The attraction for me was irresistible, a chance to work on the Pacific project, a new computer for small business using some of the best ideas of the Future Systems project.

I had seen the future of computing, and it had died. Or at least, the parts managed by IBM's big East Coast laboratories had died. But that still left Pacific, a small derivative project in the corn fields of Minnesota, just far enough away to be ignored by the powers that be in Armonk, at IBM headquarters.

The IBM Rochester factory and programming center had been built in the mid 1950's primarily because Thomas J. Watson, Sr., then IBM's CEO, was a member of the Mayo Clinic's Board of Trustees, and he liked what he saw in the small city of Rochester. IBM has always had a penchant for small, isolated cities The company was started in Endicott, NY and over the years built its plants and development laboratories in "metropolises" like Poughkeepsie, Kingston, and East Fishkill, and in "cosmopolitan centers" like Burlington, Boca Raton, and San Jose. Rochester fit the mold. It had a hardworking, well-educated labor pool, good social amenities, and most importantly, it was distant from any companies that might compete for its employees or tempt them into joining unions.

The mission of IBM Rochester was the development and production of small-scale computers such as the System/32 and System/34 that were sold to small companies. The Pacific system would be sold, at least initially, in the same market under the name System/38, though it bore little resemblence to its Rochester predecesors. Because of the "small system" mentality of Rochester, the initial versions of the System/38 did not have sufficient memory or processor power. Its successors, the AS/400 and its follow-ons, eventually realized the full potential of Pacific's FS architecture.

When my wife Lois learned that the new project was in the Rochester in Minnesota and not the Rochester in New York, she wasn't at all enthused. Moving to Minnesota would take us a thousand miles away from our families, she had a teaching job she liked, and she had made numerous friends in Endicott. But I was burning with enthusiasm for the new project. After some discussion, she agreed, however reluctantly, to the transfer and I was on my way to Rochester, the Pacific project and promotion to Staff Programmer.

1975: Le projet pour les systèmes d'avenir

Le dernier projet sur lequel j'ai travaille dans le centre de la programmation d'IBM à Endicott était le projet infâme des systèmes d'avenir, ou en anglais, le projet « Future Systems ou FS ». Un essai dans le but de dépasser les Système/360 ordinateurs d'IBM lui-même, le projet était un grand et très cher échec dont le développement avait occupé les laboratoires d'IBM partout aux États-Unis et en Europe. Certaine ont dit que FS était trop grandiose pour ne jamais réussir ; d'autres ont blâmé le nombre de personnes et de laboratoires qui avaient essayé d'en saisir une partie ; et encore d'autres ont blâmé le besoin pour compatibilité avec la technologie de Systême/360.

Un humble programmeur au grade « Associé Supérieur », j'ai vu seulement une petite partie du projet et je n'avais pas conscience de l'agitation politique qui entourait FS. J'étais membre d'un département consacre au dessin d'un élément du nouveau système d'exploitation pour mesurer et mettre au point les caractéristiques des systèmes. Nous n'avons pas travaillé trop loin sur ce tâche, mais je pouvais lire les documents sur « les besoins et les objectifs » et je pouvais aussi étudier le grand dessin du système. Quelqu'un avait fait un travail merveilleux ! En particulier, l'hotchpotch des techniques pour l'exploitation de la mémoire trouvée dans tous les autres systèmes avait été remplacé par un seul espace de mémoire adressée d'une façon uniforme. Des « objets » qui représentaient les données et les ressources du système étaient administrés dans cet espace par le système lui-même.

Après la mort de FS, le centre de programmation d'Endicott était comme une morgue. Personne n'avait idée de ce que nous devions faire en suite. L'administration du laboratoire examinait d'autres possibilités à toute allure. Le personnel qualifié, qui devrait avoir des bonnes idées sur la technologie, est resté silencieux. Cela ne présageait rien de bon. Peut être qu'ils avaient été épuisés à cause de FS. À une occasion, notre directeur venait au travail en apportant des sacs de livres de poche, pour la plupart des livres de Science-Fiction. Il les a distribués et a dit de rester calme jusqu'aux ce que l'administration détermine ce que nous ferions. Cela s'est passé pendant plusieurs mois.

J'ai travaillé sur des projets pour le troisième cycle d'université et j'ai achevé notre partie de la spécification de FS. Tout le monde m'a dit que ce travail était inutile, mais j'ai pensé que le sujet des caractéristiques des systèmes était intéressant et que quelqu'un dans l'avenir voudrait le développer. Cela était une rêve ; cela n'arrive pas à IBM. La vraie raison pour l'achever était que j'avais trouvé du plaisir avec le travail. C'était ma première expérience avec l'architecture de système, un travail que je ferais plus tard à plein-temps, de préférence sur la programmation.

La meilleure chose que l'administration d'Endicott a trouvée était de reprendre VM/CMS, un système d'exploitation pour les ordinateurs centraux, du laboratoire d'IBM à Boeblingen en Allemagne. Je n'avais aucun intérêt dans ce travail, mais je ne pouvais pas voir d'alternatifs jusqu'à ce que je me sois aperçu d'une publicité sur le tableau d'affichage pour des nouveaux postes. Quelqu'un dans le centre de programmation d'Endicott pouvait faire une demande pour ces postes. L'attrait pour moi était irrésistible, une chance de travailler sur le projet Pacific, un nouvel ordinateur qui utiliserait des meilleurs idées du projet FS pour les petites entreprises.

J'avais vu l'avenir de l'informatique et il était mort ; tout au moins, les parties qui étaient administrées par les grands laboratoires d'IBM sur la côte Est étaient mortes. Cependant, cela avait laissé Pacific, un projet dérivé de FS, dans les champs de maïs de Minnesota, tout juste assez loin des pouvoirs qui étaient à Armonk, le siège d'IBM.

L'usine et le centre de programmation à Rochester avaient été construit dans les années 50 parce que M. Thomas J. Watson père, le chef d'IBM dans ces années-là, était membre du conseil de la Clinique Mayo et il aimait ce qu'il a vu de la petite ville de Rochester. IBM aimait toujours les petites villes isolées. L'enterprise avait commencé à Endicott et depuis des années avait construit ses usines et laboratoires dans d'autres « métropoles » comme Poughkeepsie, Kingston et East Fishkill et dans des « centres cosmopolites » comme Burlington, Boca Raton et San Jose. Rochester faisait partie de ces lieux. Elle a un population bien éduquée qui travaillait bien, un bonne cadre de vie et surtout elle était loin d'autres entreprises qui pouvaient être en concurrence pour ces salariés ou pouvaient les séduire de rejoindre des syndicats.

La mission de Rochester était le développement et la production des ordinateurs à petite échelle, comme le Système/32 and Système/34 qui étaient vendus aux petites entreprises. Le système Pacific serait vendu, au debut, dans le même marché sous le nom Système/38, bien qu'il ne soit pas semblable à ces prédécesseurs de Rochester. À cause de la mentalité pour les petits systèmes à Rochester, les premières versions du Système/38 n'avaient pas de mémoire ou de puissance des processeurs suffisants. Ces successeurs, comme le AS/400 et ces successeurs, ont réalisé le plein potentiel de l'architecture FS de Pacific.

Quand ma femme Lois a appris que le nouveau projet était à Rochester dans l'État de Minnesota et pas à Rochester dans l'État de New York, elle n'était pas très enthousiaste. Un déménagement au Minnesota nous prendra à un millier mile plus loin de nos familles ; elle avait un travail comme enseignant qu'elle aimait beaucoup ; et elle s'était faite plusieurs amies à Endicott. Mais j'ai eu beaucoup d'enthousiasme pour le nouveau projet. Après quelques discussions, elle a consenti, à contrecoeur, au déménagement et j'étais sur le chemin de Rochester, le projet Pacific et avancement au grade de « Programmeur chef-adjoint ».