Td corrigé Contribution à l'histoire d'Unix chez Bull - FEB-patrimoine pdf

Contribution à l'histoire d'Unix chez Bull - FEB-patrimoine

On remarquera à ce sujet que les implémentations d'Unix sur des architectures ... Le T15/27 était un système à base de multiples processeurs Intel 8086 (une .... ce microprocesseur a été utilisé par HISI pour la réalisation d'un processeur ...




part of the document



Processor ou DNS), au sein de l’organisation dirigée par Claude Boulle, je me suis intéressé à d’autres applications potentielles du Mini 6.
La première de ces applications potentielles a été le projet TPO (Très Petit Ordinateur). Nous avons été chargés (avec Claude Gouin et Georges Krystal) de cette étude en avril 1977, c’est à dire lors de la mise en place effective de la fusion entre la CII et Honeywell-Bull. Bien que ce projet nécessite un papier à lui seul, il n’est pas inutile d’en dire quelques mots ici.
La cible marché du TPO était les PME/PMI, un exemple de produit concurrent était le System/36 d’IBM. Le TPO était donc le successeur potentiel du DPS 61 et, dans une moindre mesure, du DPS 4. Deux approches techniques concernant la plate-forme devant servir de support pour le TPO existaient :

Approche 61 défendue par l’équipe 61 de Claude Bouvier avec notamment Pierre Tassin qui participait à notre étude ;
Approche Mini 6 défendue par l’équipe « Produits » de François Sallé, notre correspondant dans la ligne de produits étant Douglas Jackson.

Plutôt que de partir dans une approche « partisane » du style « c’est comme ça dans le 61 ou dans le Mini 6 (selon notre interlocuteur), c’est donc comme ça dans le TPO », nous avons choisi une démarche logique consistant à faire, dans un premier temps, une spécification fonctionnelle du TPO (i.e. qu’est ce que c’est qu’un TPO) et, dans un second temps, à évaluer les qualités des plates-formes pouvant supporter le TPO et proposer les compléments nécessaires.

Nous avons donc développé les spécifications du TPO en quelques semaines. En ce qui concerne les plates-formes, il est apparu rapidement que les limitations de l’architecture du 61 (capacité d’adressage essentiellement) ne permettaient pas de le considérer. Le Mini 6, malgré quelques réserves en ce qui concernait les projets de Billerica en matière de mécanisme de gestion de mémoire virtuelle, semblait un bien meilleur véhicule.
Indépendamment de ces considérations techniques, le « vent politique» était nettement en faveur du Mini 6.
Une mission à Boston, du 10 au 15 octobre 1977, nous avait permis de chiffrer les compléments minimaux nécessaires pour faire du Mini 6 un TPO. Après la présentation de ce projet, le processus de décision s’enlisa. En conséquence, après cet avant-projet mené tambour battant, d’autres activités ont été recherchées.

Sans grande surprise, c’est autour du Mini 6 que ces activités se sont organisées. En 1978/1979, le paysage Mini 6, en termes de systèmes d’exploitation, était plutôt encombré : MOD 400 et MOD 600 développés à Boston, TPS 6 qui était un système transactionnel organisé autour d’une base de données spécifique et avait été développé par Honeywell en Angleterre, les projets MOD200 et MOD100 pour le support des satellites. Dans un but de simplification, j’écarte de ce paysage le frontal qui avait son propre système d’exploitation.

J’avais proposé de porter Unix sur Mini 6. Il me semblait qu’Unix pouvait prendre la place de MOD600, au moins pour certains des objectifs de ce dernier. Le portage d’Unix aurait nécessité l’introduction d’un nouveau mode sur Mini 6 avec les deux modifications techniques suivantes :

Une unité de gestion de mémoire virtuelle (MMU Memory Management Unit) en mode plat (i.e. à la IBM/370) en lieu et place du mécanisme dérivé de Multics qui était proposé ;
La suppression de l’index flottant (i.e. la valeur d’un registre d’index était considérée comme un ordinal puisqu’il y avait multiplication de la valeur du registre d’index par la longueur de l’élément de tableau avant calcul d’adresse). La suppression de l’index flottant aurait permis l’assimilation faîte implicitement par C qu’un pointeur est un entier (et donc non-sujet au mécanisme d’auto-décalage).

En 1979, cette idée n’a pas reçu d’écho. Une implémentation d’Unix a été faîte sur DPS 6 et, apparemment, elle ne rencontra guère de succès. Je ne saurai pas en parler plus car, au moment de ce projet, je ne faisais plus partie de la Compagnie l’ayant quittée pour Transac-Alcatel.

Parallèlement à cette proposition, Jean-Claude Sinthomez, qui devait appartenir à la direction « Produit » de François Sallé mais pas dans la partie « ligne de produit 64 », avait proposé de porter Unix sur le 64. Cette idée n’avait pas non plus entraîné l’adhésion des personnes concernées à ce moment. De fait, à la ligne de produits DPS7/GCOS7, Jean Papadopoulo fut chargé, en 1983, de la définition d’une stratégie Unix pour cette ligne. Unix a été porté sur le DPS 7 et a servi de base des produits d’interconnexion et interopérabilité avec les systèmes standards (i.e. Unix et assimilés et Windows) . On remarquera à ce sujet que les implémentations d’Unix sur des architectures propriétaires n’ont pas connu de succès, la pauvreté du catalogue d’applications et les prix d’accès relativement élevés (pour des clients initiaux) sont certainement des causes de ces insuccès. Il faut noter les efforts actuels d’IBM sur les zSeries avec son offre Linux (sur machines virtuelles) alors que son offre d’une interface Unix sur MVS n’avait rencontré que peu de succès. Il sera intéressant d’observer la pénétration de cette offre, surtout en dehors des clients « traditionnels » des zSeries.
Transac Alcatel

Arrivé chez Transac-Alcatel en septembre 1980, j’étais en charge avec Jacques Péping (nous étions tous deux de la Direction Technique dirigée par Roger Thévenet) et Fouad Elamrani (Ligne de Produit dirigée par Jacques Lefèvre) de la définition du successeur du T15/27. Le T15/27 était un système à base de multiples processeurs Intel 8086 (une structure avec multiprocesseurs spécialisés) avec un système d’exploitation multi-utilisateurs spécifique (MPOS), un compilateur COBOL (développé pour le T15 par Realia, Realia porta ensuite, avec un certain succès, ce compilateur dans le monde PC), une gestion de fichier et une gestion de données complète, le logiciel de programmation TDDP pour les applications de saisie intelligente de données (compatibilité avec les générations précédentes) ainsi que TMF un gestionnaire d’écran (plus moderne que TDDP),…

Pour ce successeur, nous nous orientions naturellement vers une machine 32 bits, mémoire virtuelle et sous Unix. Nous avons analysé les offres des différents fournisseurs de microprocesseurs. Voici, en résumé, le résultat de notre analyse tel qu’il se présentait, début 1983, lorsque le rapprochement avec Bull a été mis en oeuvre :

Intel. Le 286, qui nous avait été présenté lors d’un grand show Intel à Bruxelles en octobre 1980 n’avait pas été retenu. Il s’agissait d’un processeur 16 bits uniquement et dont le mécanisme de gestion mémoire (segmentation avec longueur variable, quatre anneaux et absence de pagination) était potentiellement porteur de difficultés.
Intel 432, lui aussi présenté lors du show de Bruxelles. Il s’agissait d’une nouvelle famille, incompatible avec le 8086, avec une architecture à capacités (capability-based addressing). Le 432 souffrait de plusieurs difficultés parmi lesquelles l’absence de mémoire virtuelle, le très faible niveau de performance ainsi que la quasi-absence de logiciel. Cette architecture n’a pas été considérée.
Motorola. Le 68020 était prometteur mais la partie mémoire virtuelle était loin d’être convaincante : spécifications non figées, grande complexité, disponibilité problématique. Nous n’avions pas retenu cette famille.
National. La famille 320xx nous avait semblé attractive : notion de famille (8, 16 et 32 bits), en 32 bits produit complet avec un coprocesseur flottant et surtout un MMU « simple et de bon goût », disponibilité d’un système de développement sous Unix.
Pour l’exhaustivité, nous devons aussi mentionner quelques autres architectures ou propositions d’architecture que nous avons examinées (sur une période couvrant non seulement Transac mais aussi Bull) telles que : AT&T 3200, Texas Instrument 32 bits, Zilog. Aucune de celles-ci n’a retenu notre attention.

Notre orientation chez Transac Alcatel était pour la famille National. L’une de nos inquiétudes au sujet de cette famille était l’adhésion d’autres industriels. Comme la suite le montrera, l’utilisation de cette architecture sera marginale : Burroughs avait en développement une gamme de produits qui ne vit jamais le jour et quelques start-ups (dont Tolerant Systems dont nous reparlerons).

Notons aussi que cette orientation Unix se matérialisait par l’acquisition d’un VAX 11/780 sous Unix (Interactive – pas un très bon choix – dans un premier temps qui fut remplacé ensuite par la référence du moment qu’était BSD 4.2 lorsque nos compétences internes en Unix eurent atteint un niveau satisfaisant) pour le support des développements logiciels. Le rapprochement avec CII-HB n’entraîna pas, contrairement à nos craintes, la remise en cause de ce choix (au profit par exemple d’un DPS 6).
Bull Transac

Le rapprochement entre CII-HB et Transac entra dans une phase active le 28 février 1983. Un groupe technique de travail commun avait été créé entre les deux entités. Ce groupe avait pour mission de définir la politique produit de Bull Transac. Un groupe « managérial » fonctionnait en parallèle. Cette séparation a permis au groupe technique de travailler dans la sérénité.

Le groupe technique était composé de :

Pour CII-HB : Guy Lang, Christian Le Baron, Jean-François Mescam, David Smithson ;
Pour Transac-Alcatel : René Chevance, Fouad Elamrani, Jacques Péping.

Ce document concernant Unix, nous n’évoquerons pas les circonstances qui conduisirent la Compagnie à choisir les produits NGEN (New GENeration) de Convergent Technologies (CT) qui furent appelés Questar 400. Le premier grand meeting technique chez Convergent Technologies débuta le 25 avril 1983.
Si les développements internes en serveur 16 bits (MPOS pour Transac et MP/M pour CII-HB) ont été abandonnés au profit des produits de CT (le NGEN de CT étant désigné sous le nom de TG1 pour Tête de Grappe 1), l’idée de développement interne d’un serveur Unix 32 bits (désigné sous le nom de TG2) était adoptée.
Notons que CT proposait le Megaframe qui était un système Unix avec des ensembles processeur/mémoire spécialisés : un processeur (68020) pour le support des applications, un File Processor et un Terminal Processor tous deux sous CTOS (fondés sur 286). L’adoption de ce système aurait placé la Compagnie dans une position de dépendance trop forte vis-à-vis de CT et le Megaframe était un objet un peu « hors normes » dans le monde Unix (ce concept d’architecture spécialisée pour le support d’Unix n’a d’ailleurs pas eu d’héritiers ; avec le successeur appelé Mighty Frame, CT revint d’ailleurs à une architecture classique). Il faut noter qu’il y avait une forte pression, tant de la part de CT que du réseau commercial de Bull, pour l’introduction du Megaframe : il s’agissait de répondre aux besoins de la BNP pour le support de grandes grappes de stations (i.e. jusqu’à 48 postes ce qui était au-delà de 10-12 qui constituait la limite de l’offre standard de CT avec les produits NGEN) et aussi pour faire face à Burroughs qui proposait le Megaframe. Il nous semblait que l’offre Questar 400 pouvait suffir à satisfaire les besoins de la BNP.
Nous avions aussi fait l’acquisition d’un Megaframe afin de faire des tests de performance (et aussi de faire patienter durant la validation de notre approche).

Les études du TG2 ont débuté dans l’année 1983 (René Chevance et Jacques Péping en tant qu’architectes, Fouad Elamrani pour la ligne de produits, et, les leaders des équipes de développement : Claude Avril pour le matériel, Christian Baillif pour le firmware, Denis Adda et Bernard Lansac pour le logiciel). Francis Couppié, rejoint ensuite par Jean-Pierre Goursaud, était en charge des aspects modélisation et mesures de performance.

En octobre 1983, nous avons entrepris, avec François Avilès (Technologie Groupe) et (prénom ?) Breugnon (Achats Groupe) une tournée des fournisseurs potentiels de microprocesseurs 32 bits : NCR (un cœur 32 bits sur lequel il fallait développer un interpréteur du code souhaité, ce microprocesseur a été utilisé par HISI pour la réalisation d’un processeur DPS4000), Motorola (68020), NSC (32032), Intel (386) et AMD (fournisseur de microprocesseurs en tranches et qui servaient à la réalisation de processeurs spécifiques au moyen de l’écriture d’un interpréteur). Nous avons retenu la famille NS (tout en conservant un œil attentif sur l’évolution dans ce secteur).

Le choix du groupe en matière de bus étant Multibus 2, le TG2 était organisé autour de ce bus et était fondé sur NS 32032. La carte « réseau » était fondée sur 286 et fonctionnait sous CTOS de façon à pouvoir réutiliser les logiciels de communication du TG1. Les disques (technologie 5 pouces) étaient en interface SCSI.

Afin de pouvoir capitaliser sur les investissements (accords OEM avec Convergent Technologies et développements internes) nous avions prévu une première version du TG2 présentée en coffret style TG1 (Questar 400) et ayant le X-Bus pour le raccordement des périphériques. Il convient de reconnaître qu’il s’agissait d’un être hybride (créé pour des raisons de politique interne essentiellement) qui ne vit heureusement pas le jour.

Pour la version définitive du TG2, nous avions prévu un packaging de type servante avec accès par les faces avant et arrière uniquement. Ce packaging avait été conçu dans l’optique de la maintenance participative : le système était très aisément démontable (nous y reviendrons), les nappes (de câbles) avaient été supprimées au profit de cartes/bandeaux de raccordement et les disques étaient conditionnés en CRU (Customer Replaceable Unit).

Quelques mots sur les aspects commerciaux lors de l’introduction d’Unix dans le réseau Bull (je n’ai pas tous les chiffres pour étayer ce qui suit et mon opinion peut être sujette à la subjectivité). Le souhait de ne pas créer de réseau dédié à Unix a conduit à saupoudrer la formation Unix. De ce fait, les commerciaux n’avaient pas une connaissance approfondie des produits et de ceux de la concurrence (les prospects avaient souvent une meilleure connaissance du monde Unix que celle des commerciaux). Unix aurait dû être un vecteur privilégié pour le « hors parc », de fait, on a surtout (à l’origine) vendu sur parc en remplaçant les ventes de produits à forte marge (les différents DPS) par des produits Unix à marge plus faible (car les prix de vente pour de tels produits sont imposés par la concurrence). Notons que les stratèges du Groupe, qui étaient des ardents promoteurs d’Unix, ne sont pas réellement posé la question de savoir comment conserver l’équilibre de Bull en remplaçant des produits à forte marge par des produits à plus faible marge. Compte tenu de ce contexte, les lignes de produits « propriétaires » livrèrent un combat contre les produits Unix de Bull jusqu’au début des années 90.
Recherche d’un partenaire Unix

Dès le début de l’étude TG2, nous étions conscients des limitations d’Unix pour les applications de gestion et les fonctions « serveur ». Nous ne rappellerons pas ici ces limitations. Il convient aussi de rappeler qu’à l’époque il y avait une demande (au moins au niveau marketing et stratégique) pour des systèmes à continuité de service.
Nos objectifs pour TG2 étaient un système Unix  doté des caractéristiques complémentaires suivantes :

Robustesse du système et en particulier du système de fichiers ;
Croissance modulaire de type cluster  i.e. la capacité à suivre la croissance des besoins sans rupture (on dirait maintenant scalabilité);
Transactionnel ;
Continuité de service ;
Concept de famille permettant de faire évoluer, sur site, un système unique (TG2) en cluster.

Conscients aussi de nos relatives faiblesses en Unix (à la fois en termes de compétences et de forces de développement car les équipes étaient absorbées par les opérations d’adaptation des produits de Convergent Technologies) pour entreprendre les améliorations souhaitables, nous nous sommes mis à la recherche d’un partenaire.

Avec Georges Lepicard de la Direction Stratégie (Michel Bloch) (et aussi quelques autres participants), nous avons visité un grand nombre de Sociétés aux USA, à partir de mai 1984, parmi lesquelles :

CCI, Computer Consoles Inc (mai 1984). Société de la côte Est spécialisée à l’origine dans les équipements péri-téléphoniques. CCI avait développé son propre mini « propriétaire » (le 6/32), un logiciel de bureautique sous Unix : Office Power qui sera adopté par l’Unité Bureautique du Groupe (mais ceci est une autre histoire) et des systèmes Unix fondés sur la famille Motorola 680x0. Nous retrouverons d’ailleurs plus tard CCI lors de notre quête d’une architecture RISC. CCI avait aussi développé, et c’était l’une des raisons de nos contacts, un système à continuité de service. Le système d’exploitation s’appelait PerpOS (Perpetual Operating System). Il nous a semblé qu’il s’agissait d’un développement spécifique (ayant probablement été fait dans le cadre d’une affaire). Le devenir de ce système était loin d’être clair à cette époque (lors d’une visite ultérieure à CCI, le statut de PerpOS était encore plus flou, et tout ceci a disparu) ;
Tolerant Systems (mai 1984). Société californienne développant un système à continuité de service et croissance modulaire (approche Tandem transposée dans le monde Unix). Nous aurons l’occasion de revenir sur cette société avec l’épisode TRIX ;
Parallel Systems (mai 1984), Société californienne qui avait développé un système « Fault Tolerant » sur base 680x0. Ce système était fondé sur le principe d’un doublement du couple processeur/mémoire avec exécution simultanée du même ensemble de processus sur les deux couples processeur/mémoire. Sur certains événements (e.g. à chaque entrée-sortie), il y avait une comparaison de l’état des deux ensembles processeur/mémoire. En cas de divergence, une procédure permettait de déterminer lequel des deux ensembles était en défaut. Le traitement continuait alors avec l’ensemble processeur/mémoire restant. Cette Société fut ensuite rachetée par la Société anglaise IMP, la technologie fut revendue à Motorola (j’ai eu des contacts avec Motorola sur le produit qu’ils avaient développé sur cette technologie dans le cadre des projets Power PC, voir ci-après) et aussi à Sun (produit NETRAft). Malgré toutes les demandes d’explication, la façon de déterminer quel est le couple processeur/mémoire fautif ne m’est jamais apparue clairement ;
Logabax/Stratus (janvier 1985). Logabax avait un accord avec Stratus pour la diffusion des systèmes à continuité de service (solution au niveau du matériel). Ces systèmes sur base Motorola 680x0 utilisaient le principe de « Pair and Spare » : doublement complet du matériel, exécution d’un même processus, sur une carte processeur, par deux processeurs en parallèle et comparaison continuelle des résultats. En cas de divergence, l’autre carte processeur prend le relais. Stratus avait développé un système transactionnel propriétaire : VOS (Virtual Operating System). VOS avait été complété par Unix. Avec Claude Boulle, nous eûmes un meeting avec Marc Bourin. Il convient de mentionner que les ingénieurs de Logabax que nous avons alors rencontrés lors de ce meeting n’avaient pas une connaissance approfondie de Stratus ;
Counterpoint (janvier 1985), Société californienne dirigée par la séduisante Pauline Acker. Cette société développait une station de travail fondée sur 68020. Ce produit était éloigné de notre objectif, Pauline Acker avait tenté de nous démontrer que les compétences de ses équipes en matériel et en Unix alliées aux connaissances de Bull dans les mainframes devaient porter leurs fruits. Au cours de cet exposé, nous avons été frappés, Kazimir Turckiewicz (Responsable de la stratégie de Bull Transac) et moi-même, par la connaissance que Pauline Acker avait de nos projets « internes » ;
Enmasse (février 1985), Société de la côte Est, qui avait en cours de développement un système Unix fondé sur 680x0 réputé couvrir les besoins transactionnels grâce à un SGBD relationnel « maison » et « miracle ». Cette magnifique perspective s’écroula lorsque nous abordâmes (avec Claude Boulle) le planning de développement qui nous apparu comme étant totalement surréaliste. Ceci fut confirmé lors de notre visite sur la plate-forme où un terminal affichant une bannière de type Informix attira mon attention. En interviewant discrètement le technicien qui travaillait sur ce terminal, celui-ci me confirma que le SGBD miracle n’était autre qu’Informix. Quelques dirigeants de cette société avaient travaillé à Billerica, Claude Boulle les y avait rencontré et son souvenir de leur propension au « bidonnage » confirma notre impression. Cette société disparut rapidement sans laisser de traces ;
Synapse (mars 1985), Société californienne qui avait développé un système propriétaire transactionnel fondé sur 68010. D’une façon classique, le temps nécessaire au développement et à la mise au point du logiciel avait largement dépassé les prévisions. Avec le retard accumulé et le manque de finances, le matériel était devenu obsolète et la demande pour des systèmes Unix était devenue importante. Une couche de compatibilité Unix avait été ajoutée au système. Le système était positionné très haut en prix : pratiquement au niveau des petits S/390 ; l’espoir des dirigeants était d’obtenir l’équilibre avec les ventes qu’ils espéraient faire avec les quelques rares prospects en cours. Je conserve de cette visite l’image d’une « société qui coulait mais dans la dignité, l’équipe dirigeante était sur le pont et tenait des paroles d’espoir sans toutefois cacher et se cacher les difficultés du moment ». Cette société disparut rapidement sans laisser de traces ;
Areté (mars 1985), Société californienne qui avait développé un système Unix multiprocesseur asymétrique fondé sur 680x0 ;
MAD (mars 1985). Société californienne qui développait des stations et des petits serveurs sur base Intel (286) et qui avait en projet un serveur sur base 68020 ;
Convergent Technologies (voir ci-dessus), qui outre le Megaframe déjà évoqué ci-dessus, préparait le Mighty Frame qui était un système Unix à base de 68020 de facture « classique » (i.e. sans les processeurs spécialisés du Megaframe). Cette piste n’a pas été poursuivie en raison de notre dépendance déjà très forte vis-à-vis de cette société ;
Britton Lee (avril 1985). Société californienne qui avait développé des machines bases de données sur base Zilog Z8000. Ce type de système tomba en désuétude devant la poussée des serveurs Unix dotés de SGBD standard tandis que Teradata dont le positionnement était en haut de gamme avait encore quelques belles années à vivre ;
Altos (juin 1985), Société californienne, qui développait des petits serveurs classiques Unix sur base 680x0 ;

De cette analyse, nous avons retenu la poursuite de nos développements internes et un transfert de technologie avec Tolerant Systems.

Commentaire : Avec le raccourci que donne ce rappel, on pourrait s’interroger sur l’intérêt de telles visites. De fait, ces visites, dans la mesure où elles sont accompagnées de comptes-rendus circonstanciés, permettent de glaner beaucoup d’informations (tant d’ordre technique que stratégique) et aussi de nouer des relations. Nous aurons l’occasion d’y revenir lors d’un autre commentaire.

Parallèlement à ces actions, nous avions aussi entrepris une recherche de convergence avec SEMS autour du SPS7 (1er meeting le 29 février 1984).
La RD0 du TG2 eut lieu le 7 novembre 1984. La décision de convergence TG2/SPS7 fut prise entre fin 1984 et début 1985. La CDR de TG2 eut lieu le 27 mars 1985. Le produit prit la dénomination commerciale DPX2000.
Une petite anecdote concernant les luttes entre lignes de produit. Lors de la préparation d’une IPR de TG2, le message (discret) suivant m’était parvenu en provenance de la ligne DPS6000 : le TG2 ne doit pas dépasser x MIPS et ne pas supporter plus de 20 terminaux. En prévision de cette revue, j’inventai un benchmark transactionnel et je confiai à Francis Couppié le soin de modéliser, avec QNAP, la performance de TG2 dans cet environnement applicatif. Lorsque Francis vint me présenter les résultats, il me dit « Ton pifomètre est bien réglé car nous en sommes à 19 postes au maximum !». Lors de cette revue, je fis, comme prévu, un exposé sur les performances en ne donnant que le chiffre en Dhrystones (le standard du moment, chiffre que je savais ne pas être disponible pour le DPS6000) et les résultats de la modélisation pour le benchmark que j’ai présenté comme un standard de l’industrie dans le monde Unix. Tout se passa sans problème sur ces aspects performance.
La CDR du SPS7/7x (7/70 sans mémoire virtuelle et 7/75 avec mémoire virtuelle) eut lieu le 24 juillet 1985.
Tolerant Systems et TRIX

En ce qui concerne Tolerant Systems (San José CA), nous avons découvert, avec Jacques Péping, ce système à l’occasion de la lecture d’un article paru dans un magazine US en mars ou avril 1983. Ce système correspondait tout à fait à nos objectifs et, de plus, il était fondé sur la famille NS 32x32. Nous avons donc pris contact avec Tolerant Systems, la première visite eu lieu en mai 1984 et le premier meeting technique fut organisé en juin 1984.
Tolerant Systems avait développé un système fondé sur Unix (BSD 4.2) dont la description aurait pu se résumer de la façon suivante : système de type Tandem (croissance modulaire, transactionnel et tolérance aux fautes) fondé sur microprocesseur standard et sur le système Unix.
Ses caractéristiques fonctionnelles et architecturales peuvent se résumer de la façon suivante :
Fonctionnalité :
Cluster Unix avec croissance modulaire et File System unique pour le cluster ;
File System supportant une notion de volume logique ainsi que la journalisation pour les méta-données (afin de permettre le recouvrement rapide suite à une défaillance) ;
File System « clusterisé » i.e. donnant aux utilisateurs du cluster la visibilité d’un File System unique ;
Introduction d’une logique transactionnelle dans les primitives d’accès aux fichiers ;
Continuité de service pour les applications transactionnelles (notion de processus de secours) ;
Architecture :
Système dérivé de BSD 4.2. BSD supportait la mémoire virtuelle et la pagination à la demande, cette fonctionnalité était nécessaire pour l’implémentation de la continuité de service (i.e. prise d’un point de reprise fondé sur l’image du processus en ne stockant que les pages modifiées depuis le point de reprise précédent). Note : La version contemporaine d’AT&T ne supportait pas encore la mémoire virtuelle ; celle-ci ne vint qu’avec System V, c’est-à-dire bien après le début des développements de Tolerant System ;
Cluster fondé sur la juxtaposition de servantes interconnectées par un double « Thin Ethernet » (prises RJ 45) ;
Architecture fondée sur NS 32x32. Chacun des nœuds du cluster avait deux processeurs spécialisés : UPU (User Processing Unit) et RPU (Real time Processing Unit). Sans entrer dans les détails de fonctionnement, l’UPU prenait en compte les demandes locales (i.e. celles émanant des applications se déroulant sur le nœud) non compris la gestion des entrées-sorties physiques alors que le RPU prenait en compte la réalisation des entrées-sorties ainsi que la prise en compte des demandes d’opération provenant des autres nœuds ;
Disques 8 pouces SMD ;

Tolerant Systems était, initialement, intéressé par un accord OEM. Avec une telle option, nous perdions l’un de nos objectifs qui était la synergie avec les systèmes Unix « de base » (i.e. la mise en commun du maximum d’éléments et la capacité de faire évoluer, sur site, un système « standard » en système à continuité de service par adjonction d’une servante). En effet, le système de Tolerant Systems se positionnait, en raison de leurs choix technologiques, beaucoup plus haut en prix (de revient) que le projet TG2.
La performance du système étant l’une de nos préoccupations, nous fîmes, dès juillet 1984, une mission avec Francis Couppié avec l’objectif de modéliser le comportement du système. Nous installâmes QNAP (l’outil de modélisation que nous utilisions) sur l’un des VAX de Tolerant Systems. En interrogeant Gef Peck (l’un des concepteurs du système et celui qui avait certainement la meilleure vision du fonctionnement du système), nous pûmes construire un modèle et le valider en l’espace d’une petite semaine de travail. Ce modèle nous servit pour le développement du TG2-F. Au cours de ce meeting, nous apprîmes énormément de choses sur l’architecture et le fonctionnement de TX.

Nous fîmes plusieurs visites chez Tolerant Systems pour affiner notre approche : nous nous dirigions vers un accord de licence de TX (le nom de baptême du système) et un portage sur base 68020, car depuis notre premier contact, une synergie entre TG2 et le SPS7 avait été décidée (ce qui se traduisait par l’abandon de la famille NS32x32). Si le choix commun de l’architecture NS32x32 était un motif de rapprochement lors de nos contacts initiaux avec Tolerant Systems, mais ce n’était plus le cas depuis fin 1984 et 1985 lorsque l’arrêt du TG2/NS32x32 a été prise au profit d’une convergence sur la base SPS7. Notons que le choix de la famille NS32x32 n’était pas particulièrement heureux, cette gamme souffrit de retards dans le développement des nouvelles versions et surtout d’un manque d’adhésion de l’industrie.

Dans nos travaux d’architecture, Jacques Péping eut l’idée d’utiliser un unique PC, sous Windows, pour contrôler le fonctionnement du système en lieu et place d’un terminal asynchrone par servante (la solution classique sous Unix, à l’époque, était d’avoir un terminal asynchrone pour contrôler le fonctionnement du système). De cette façon, on associait une fenêtre à chacune des machines composant le cluster et une fenêtre pour le système complet. Ce concept fut repris sur la ligne DPS7000 notamment.

L’accord de licence fut signé durant l’été 1985 et Philippe de Rivet rejoignit Bull Transac pour prendre la responsabilité de l’équipe chargée du portage de TX sur TG2-F. Bernard Martin, ex-INRIA et CNAM, vont rejoindre l’équipe. Le nom de code de ce projet était TRIX (pour Transactionnel Unix). La formation de l’équipe de portage commença à Massy en janvier 1986.
En novembre 1985, nous avons eu, comme nous l’avions demandé lors de la négociation des accords, une revue technique du système TG2-F (Fault Tolerant ou Final) par les équipes de Tolerant Systems.
La CDR de TG2-F eut lieu en juillet 1986. Le système fut baptisé DPX3000 en référence au TG2-I (Intermédiaire) qui avait reçu la dénomination commerciale de DPX2000.

Par rapport au DPX2000 (base matérielle SPS7/75 et avec l’UE Com : carte de communication sous CTOS), le DPX3000 se caractérisait, sur le plan matériel, par l’utilisation de cartes développées spécifiquement :

Unité de traitement de type RPU avec 68020 et mémoire locale ;
Contrôleur disque supportant deux bus SCSI (nécessaire pour la continuité de service) et capable d’accéder directement (i.e. par DMA) à la mémoire. Ceci permettait d’éviter les déplacements d’information par une unité de traitement lors des opérations d’entrées-sorties (caractéristique typique de l’architecture SM90) et donc d’améliorer la performance ;
Mémoire avec code détecteur et correcteur d’erreur.

Lors de l’élaboration de l’architecture du DPX3000 nous avons eu le double objectif de minimiser l’effort de portage de TX d’une part et de minimiser les modifications par rapport au DPX2000. Les études initiales menées par Denis Adda et Bernard Lansac avaient conclut à l’infaisabilité du portage de TX sur un seul processeur (de fait, le RPU utilisait un exécutif de type temps réel). Notons qu’à part la carte RPU, le contrôleur disque double SCSI et la mémoire ECC n’étaient pas spécifiques à TRIX et pouvaient parfaitement être utilisées sur SPS7/75 et sur DPX2000 (les personnes en charge des interfaces disque à la SEMS étaient très favorables à ESDI et non pas à SCSI pour des raisons qui me sont restées mystérieuses).

Peu de temps après l’annonce du DPX3000, plusieurs évènements dont le regroupement des activités de développement, sous la direction de Christian Joly, la création de Bull XS, le souhait de regrouper les activités Unix à Grenoble et d’y déplacer le projet TRIX ainsi que l’hostilité plus ou moins avouée de certaines lignes de produits conduisirent à l’abandon de ce produit. Notons toutefois que l’absence de SGBD adapté à l’architecture cluster était une lacune importante (voir ci-après).
L’arrêt de TRIX fut une belle manifestation de la capacité de nos managers : au lieu de n’annoncer l’arrêt du projet que lorsque le devenir des différents membres de l’équipe ait été défini, on s’empresse d’annoncer l’arrêt et on laisse l’équipe patauger avec des objectifs plus ou moins vagues. Ceci conduisit à la dispersion de l’équipe et à la perte du savoir accumulé (beaucoup de personnes quittèrent la Compagnie, les meilleurs en tête bien évidemment).
De son côté, Tolerant Systems connaissait des difficultés : les retards accumulés dans les développements, l’essor de System V comme version de référence, retards dans les développements, manque de compétitivité de la famille NS32x32, absence de débouchés commerciaux, … ont conduit à la fin de Tolerant Systems.
Nous eûmes aussi des contacts avec une société danoise : RC qui réalisait un portage de TX sur 68020. RC fut rachetée par ICL.
Veritas, une nouvelle jeune pousse, fut créée par les sociétés de Capital Risque qui avaient supporté Tolerant Systems afin d’exploiter l’acquis logiciel de TX. Veritas a rendu portables des éléments de TX tels que le File System et son gestionnaire de volumes logiques et, plus récemment, le File System « clusterisé ». Cette société est, au début des années 2000, l’un des leaders dans le domaine de la gestion des données sous Unix. Bull aurait pu aussi exploiter l’acquis logiciel mais le bébé a été jeté avec l’eau du bain ! Nous eûmes des contacts avec Veritas en avril 1991.

Le bilan de cette opération est donc bien maigre.

Le tableau suivant résume les points positifs et les points négatifs de TRIX.

NégatifPositifPas de SGBD adapté
Manque d’intérêt pour les accès fichiers « transactionnels »
Manque d’applications exploitant les spécificités de TX
Compatibilité System V imparfaite
Pas de support multiprocesseurFile System amélioré
File System « clusterisé »
Approche cluster avec les avantages associés : croissance modulaire et continuité de service
Synergie avec le produit Unix de base
Lors de nos premiers contacts, Tolerant Systems avait en projet un port adapté d’Oracle sur TX. Les retards et les difficultés financières ne permirent pas la réalisation de cet objectif. De notre côté, nous prîmes conscience de cette lacune et nous entreprîmes la recherche d’une solution. C’est ainsi qu’en septembre 1986, je visitais Oracle, Ingres et Informix (DB2 n’était pas encore disponible en dehors de la base IBM).
Oracle et Ingres travaillaient sur des versions adaptées au cluster de leurs SGBDs. Indépendamment de l’orientation Oracle prise par le Groupe Bull, Oracle présentait la meilleure opportunité technique en termes de cluster. L’adaptation d’Oracle Parallel Server (appelé maintenant Oracle Real Application Cluster) nécessitait quelques ajouts à TRIX tels qu’une interface pour le gestionnaire de verrous distribué (i.e. un Distributed Lock Manager, ou DLM, inspiré du DLM de VMS) et une méthode d’accès de base fondée sur la notion de bloc et autorisant les entrées-sorties asynchrones. J’avais d’ailleurs rédigé la spécification associée (méthode d’accès orientée bloc et entrées-sorties asynchrones).

SM90 et la SEMS

Bull avait acquis la licence de la SM90, machine développée par le CNET. Les équipes d’Echirolles étaient en charge de ce projet. Les caractéristiques majeures de cette architecture peuvent se résumer de la façon suivante :

Architecture organisée autour d’un bus propriétaire, le SM Bus, initialement 16 bits et ensuite étendu à 32 bits ;
Cartes intelligentes (toutes, sauf la mémoire) de format double Europe et appelées unités ;
Deux types d’unités :
Unités de traitement capables de dialoguer sur le bus ;
Unités d’échange dont le fonctionnement est asservi à celui des unités de traitement : outre l’initialisation et la fin des opérations d’entrée-sortie, les unités de traitement ont la responsabilité du mouvement des données entre les mémoires locales des unités d’échange et la mémoire ;
Plusieurs types d’unités de traitement étaient prévues : Motorola, National (et Intel ?). L’axe principal des développements étant toutefois la famille Motorola. Ceci était, d’une certaine façon, lié à l’accord de seconde source de Motorola avec Thomson (accord qui ne se matérialisa pas pour la famille 32 bits).
Module de maintenance et de surveillance (MMS), carte intelligente interfaçant avec le terminal asynchrone « console » et capable de connexion à distance.

Bien que n’ayant pas été impliqué dans cet accord de licence, il m’a semblé qu’il y a eu une certaine ambiguïté autour de la SM90 : la direction de Bull pensait avoir acquis la licence d’un produit alors qu’il ne s’agissait que d’un prototype. Le travail d’industrialisation fut plus long que prévu. Le développement de la version 32 bits du bus et des cartes associées intervint aussi dans ce retard. J’ajouterai, sans toutefois avoir d’éléments concrets à mettre en avant, que le fait d’imposer un matériel sous licence (et qui plus est un prototype) à une équipe qui espérait réaliser son propre système (cf. le projet briques) n’est pas un facteur très motivant.
Bull SEMS était dirigé par Georges Grunberg, Jean Hélein était en charge de la stratégie, Yves Thorn était responsable de la ligne de produits SPS9 (produit Ridge que nous évoquerons ci-après), Claude Camozzi était responsable de la ligne SPS7 (le nom de baptême de la SM90 chez Bull) et Jean-Claude Chupin était le directeur technique.
Nous eûmes de nombreux contacts avec la SEMS car le désir de la direction de Bull de faire converger rapidement TG2 et SPS7 était grand. Michel Véran, qui avait à ce moment le rôle d’architecte, était notre contact privilégié. Le développement majeur en cours était la version 32 bits sur base 68020.
Entre fin 1984 et début 1985, la décision fut prise d’arrêter le développement TG2 en cours et d’exploiter la base SPS7. L’adaptation du SPS7 à nos besoins consista, pour l’essentiel, à développer un packaging spécifique. En effet, le packaging d’origine SEMS était une servante de taille importante (capacité à accueillir 20 cartes), beaucoup de câbles et de nappes pour la connexion entre les cartes et les prises ou périphériques et surtout accès par les côtés. Ce dernier point n’était pas compatible avec les objectifs cluster. En effet, il était classique, à cette époque, de juxtaposer les servantes composant un cluster et les accès ne peuvent donc se faire que par l’avant ou l’arrière des servantes. Nous avons donc repris les concepts développés pour le projet de TG2 « Transac »: accès par l’avant ou l’arrière, absence de câbles et de nappes, périphériques magnétiques SCSI conditionnés « à la CRU ». Ces principes de packaging ont d’ailleurs été repris sur la NCL.
Les adaptations pour TRIX ont été décrites dans le paragraphe consacré à ce projet.
Guerson Essayag, au sein de la ligne de produits Bull Transac, était responsable de TG2.
L’une des différences entre le produit SPS7 32 bits (le SPS7/300 alias SPS7/7x) et le produit TG2 (Questar 700) se situait dans le domaine des communications. Afin de capitaliser sur les développements faits par Bull sur le Questar 400, Claude Boulle, Directeur technique de Bull Transac, avait poussé une solution à base d’un contrôleur fondé sur Intel 286 et fonctionnant sous CTOS. Nous avons déjà eu l’occasion de commenter ce choix.
Il convient aussi de rappeler l’opposition farouche à TCP/IP : « le transport ISO allait balayer cette hérésie technique qu’était TCP/IP » clamaient les thuriféraires du modèle ISO. TCP/IP s’est imposé et a été un superbe exemple de la standardisation faite par le produit plutôt que par un comité.
Il convient aussi de noter l’opposition de l’establishment d’obédience ISO aux terminaux asynchrones et de militer pour leur remplacement par des terminaux en « mode bloc » (tels les terminaux VIP de Bull ou 3270 d’IBM). Or, Unix n’était adapté qu’aux terminaux asynchrones et la prise en compte de terminaux modes bloc était loin d’être évidente. J’ai eu l’occasion, dans le Groupe Alcatel, de me servir d’un terminal 3270 pour accéder à Unix, c’était particulièrement pénible et édifiant …. Lorsque l’on veut faire dans le standard, c’est tout ou rien !
Pour illustrer cette opposition à TCP/IP et ses conséquences, on peut rappeler le long et douloureux portage de PCI-Locus, dont Bull Transac avait acquis une licence. Ce produit, qui permettait d’interfacer des PC et Unix, se devait, comme tout « bon » produit Bull, de remplacer sa communication native TCP/IP par ISO et sur un avatar réseau StarLAN dont Bull Transac avait fait un cheval de bataille (un Ethernet du pauvre à 1 Mbits qui n’eut aucun succès). Après avoir constaté des performances désastreuses avec le transport ISO classe 4 (imprudemment baptisé « Turbo » lors du démarrage du développement !), on a fini par se rabattre sur du TCP/IP au dessus d’Ethernet.
L’annonce conjointe, en 1986, du SPS7/300 et du Questar 700 fut un grand moment : deux produits très similaires présentés au même moment avec quelques différences histoire de perdre encore un peu plus les commerciaux, les journalistes et les clients.
Compte tenu de l’orientation scientifique et technique du SPS7/300, TCP/IP était proposé. Sous forme de boutade, je disais que la différence entre les deux produits trouvait à la jonction incompatible de deux fonctionnalités : pas possible d’avoir COBOL (Questar 700) et TCP/IP (SPS7/300) sur la même machine !
La convergence entre les deux lignes de produits fut favorisée par le regroupement de SEMS et de Transac sous une direction commune (Georges Grunberg) et une direction technique commune (Claude Boulle). Le regroupement des lignes de produits sous la direction d’un nouvel arrivant dans le Groupe : Bruno Fontaine (mars 1987), acheva cette convergence (Yves Thorn et Claude Camozzi dépendant de Bruno Fontaine).
Il convient de mentionner aussi le DPX1000, une station de travail 68020 développée par le GIPSI. Le GIPSI était dirigé par Jean-François Abramatic et avait développé un prototype baptisé LEWS (Low End Work Station). Le système était fondé sur une grande carte intégrant la majorité des fonctions. Ceci était favorable au prix de revient mais pas à l’évolution ( un changement de modèle de processeur imposait de revoir la conception de la carte). L’industrialisation du produit prit beaucoup de retard.
Ridge

Je n’ai pas participé aux contacts initiaux avec Ridge aussi je tiens à indiquer que cette partie peut contenir des inexactitudes mais il m’a semblé que cette contribution à l’histoire d’Unix chez Bull ne pouvait pas ne pas intégrer ce produit.
A la suite du projet 801 d’IBM (John Cocke), des universités (Berkeley avec David Patterson ce qui conduisit à SPARC et Stanford avec John Hennessy ce qui conduisit à MIPS) et deux jeunes pousses (Pyramid et Ridge) se sont lancées dans la technologie RISC (Reduced Instruction Set Computer). Rappelons simplement que le principe du RISC est de diminuer la complexité du répertoire d’instructions afin d’optimiser les performances (à « budget transistor » fixé, moins de transistors utilisés pour l’implémentation du répertoire d’instructions donc plus de transistors pour implémenter des dispositifs améliorant les performances tels que pipeline, cache, superscalaire, …).
Les deux sociétés pionnières furent Pyramid et Ridge qui introduisirent leurs produits en 1983 et 1985 respectivement. HP introduisit les produits fondés sur son architecture RISC (HPPA pour HP Precision Architecture) en 1986.
Pyramid abandonna son architecture RISC propriétaire au profit de MIPS. Nous eûmes des contacts avec Pyramid dans nos recherches de partenariat Unix haut de gamme et machines massivement parallèles (voir le paragraphe correspondant). Ensuite, Pyramid fut racheté par Siemens dans la seconde moitié des années 90.
D’après ce qui m’a été rapporté, l’objectif initial de Ridge était de développer une station de travail. De cet objectif découlait l’architecture du système d’exploitation propriétaire : ROS (Ridge Operating System). Les performances de ROS n’étaient pas bonnes en multi-utilisateur.
ROS avait été complété par une couche de compatibilité Unix. De station de travail, le Ridge avait évolué vers un serveur scientifique et technique (CAO) qui se positionnait par rapport à la référence du moment : le Vax 11/780. La faiblesse de ROS en multi-utilisateur n’aidait pas à la pénétration sur le marché.
SEMS avait conclut, en 1984, un accord OEM avec Ridge, le produit étant dénommé SPS9. Les performances de ROS étaient un sujet de préoccupation majeur. Un gourou Unix fut recruté à prix d’or mais les effets se firent attendre. Les détails de cette affaire, qui sont à la fois édifiants et, pour certains d’entre eux, assez croustillants, mériteraient d’être comptés mais je préférerai qu’ils viennent d’un témoin direct.
La décision de remplacer ROS par un portage de System V fut donc prise et les équipes SEMS se chargèrent de cette opération.
Il y avait deux développements en parallèle pour une nouvelle génération du SPS9 :

Sunrise, projet Ridge, fondé sur un Gate Array Fujitsu (le même ayant servi à l’implémentation du premier SPARC) ;
Aurore, projet de la Direction Recherche de Bull avec Jean-Michel Pernot.

J’ai fait partie du bureau d’une CDR d’Aurore tenue en septembre 1986. Au cours de cette CDR, nous avons mis en évidence des difficultés dont :

Absence pratiquement totale d’implication des équipes SEMS d’Echirolles tant au niveau du développement d’un système autour du chip qu’au niveau du logiciel (portage d’Unix) ;
Absence de liaison avec les compilateurs (d’origine Green Hills) et avec Ridge pour les aspects optimisation du code engendré en fonction de la micro-architecture du processeur.

Un autre élément nous est apparu : ce développement était fait en complète isolation des développements de microprocesseur DPS7 qui avaient lieu au même moment sur le même site (Les Clayes) ! Il semblerait que le but du projet, au niveau de son management uniquement, n’était pas faire un nouveau microprocesseur pour le SPS9 mais de démontrer la supériorité de l’équipe VLSI de la Recherche sur les équipes de développement DPS7.
La décision d’arrêt d’Aurore fut annoncée en mars 1987 à l’équipe de développement (sans signe avant-coureur apparemment). Le motif invoqué lors de cette annonce est que Ridge avait trouvé un financement pour le développement de Sunrise. Dès ce moment, la ligne de produit comptait uniquement sur le Sunrise de Ridge.
Il convient de noter, car la chose est suffisamment rare pour mériter d’être soulignée, qu’une destination (i.e. un autre projet) était proposée à la plupart des membres de l’équipe Aurore lors même de l’annonce de l’arrêt.
Durant le développement de Sunrise, la recherche d’une solution RISC (voir le paragraphe spécifique) me menait souvent en Californie et, à la demande de la Ligne de Produits, je rendais visite, pratiquement à chaque voyage, à Ridge pour faire l’état sur le planning de développement.
Les simulations n’avaient probablement pas été suffisantes car lorsque le premier chip a été testé, il est apparu que le chip ne pouvait fonctionner qu’à la moitié de la fréquence prévue (en raison d’une chaîne dont le temps de traitement n’avait pas été identifié).
De ce fait, la performance du processeur était pratiquement divisée par deux ce qui lui ôtait toute compétitivité. Les retards accumulés, les difficultés financières et la lassitude des responsables de Ridge (Ed Basart, Hugh Martin et John Sell) conduisirent à l’arrêt des activités.
Bien que les considérations suivantes fassent logiquement partie de l’épisode RISC, il me semble plus logique de le rapporter ici.
Lors de la recherche d’une solution RISC, l’hypothèse Ridge fut examinée. L’architecture Ridge présentait les difficultés suivantes :

Instructions de longueur variable ;
Petit nombre de registres ;
Absence d’architecture 64 bits ;
Maîtrise limitée des compilateurs.

Quelques commentaires sur ces difficultés. Les instructions de longueur variable ne facilitent pas le décodage des instructions. Le faible nombre de registres est un facteur limitatif de la performance car il induit des rangements et des rechargements de registres pour la sauvegarde de résultats intermédiaires.
On pourra objecter à ces difficultés qu’Intel obtient des performances remarquables avec son architecture IA-32 (alias x86) qui présente les mêmes difficultés. Les performances des implémentations d’IA-32 sont obtenues au moyen de techniques sophistiquées (décodage et traduction dynamique des instructions en micro-opérations, renommage des registres), les volumes de vente de ces microprocesseurs permettent de dégager les ressources financières nécessaires à ces développements complexes et de les amortir.
Les compilateurs de Ridge étaient fournis par Green Hills. Pour le développement d’une architecture, RISC en particulier, il doit exister un couplage étroit entre les optimisations développées dans le compilateur et les techniques d’accélération mises en œuvre dans la micro-architecture des processeurs. Le volume de ventes prévisible pour les systèmes n’était pas suffisamment attractif pour un fournisseur externe de compilateurs.
Il convient aussi de noter que l’équipe Ridge nous avait proposé, lors de réunions dès décembre 1987, des modifications d’architecture avec notamment une augmentation du nombre de registres, l’extension de l’adressage à 64 bits (qui était l’une de nos exigences pour le choix d’une architecture RISC) et des instructions de longueur fixe. Avec ce nouveau répertoire d’instructions, nous nous embarquions dans une nouvelle aventure (toutefois pas à partir d’une feuille totalement blanche). Ceci nécessitait des ressources mais qu’il n’était pas possible de libérer compte tenu du fait qu’il était impératif de mener à bien le développement de Sunrise.
Ce sont les raisons qui nous ont conduit à ne pas considérer l’architecture Ridge. Dans le même temps, la disparition de Ridge rendit cette hypothèse caduque.

Rachat d’Honeywell Information Systems : Bull XS et DPX2 – Développement de la NCL – BULL XS

En mai 1987, en prélude au rachat d’HIS par Bull, un rapprochement entre les activités Unix de Bull et de la branche italienne d’HIS fut initialisé.
Il convient de mentionner que nous avions eu un meeting avec HISI (à Jouy en Josas le 5 septembre 1985) organisé par Georges Lepicard et qui réunissait toutes les lignes de produits de Bull ayant une activité ou des plans Unix.
La branche italienne d’HIS (HISI), basée à Prégnana dans la banlieue de Milan, avait développé le XPS, un système SMP (Multiprocesseur symétrique) fondé sur 68020 et le bus VME. HISI avait pu obtenir d’AT&T la licence d’une version SMP d’Unix. D’après mes souvenirs, Bull avait manqué de peu l’obtention de cette licence (je souhaite que les témoins directs s’expriment).
Du côté de Bull MTS (le nom donné au rapprochement de Micral, Transac et SEMS car nous avions échappé de peu à une MST !), avec Jacques Péping, nous avions envisagé des améliorations de la gamme existante qui devaient logiquement nous permettre de tenir quelques années et nous avions esquissé les principes d’une future gamme (appelée Treestar).

Les directives de la direction de Bull, pour le groupe de travail créé à cette occasion, étaient claires :

Limitation des développements des gammes existantes Bull et HISI à ce qui était strictement nécessaire pour maintenir la compétitivité de l’existant avant l’apparition de la nouvelle ligne commune ;
Développement d’une nouvelle famille de systèmes avec SMP fondés sur 68030 (et successeurs) et Multibus 2 : la NCL (New Common Line).

La composition du groupe de travail initial était la suivante :

MTS : René Chevance, Gerson Essayag, Jacques Péping, Jacques Talbot ;
HISI : Vitorio Cajani, Giancarlo Mismasi, Angelo Ramolini.

Le leader de cette opération était Lucio Pinto, une personne qui avait réellement un esprit d’entrepreneur.
Après le round d’observation, classique dans ce genre d’opération, l’équipe se mit très rapidement au travail et définit la gamme NCL avec deux produits parfaitement identifiés :

EL (Entry Level), un système monoprocesseur très intégré ;
MR (Medium Range), un système quadriprocesseur.

Les deux systèmes étaient prévus initialement en 68030 et devaient évoluer vers 68040. La responsabilité du développement de l’EL revint à Yves Fantino (Echirolles) et celle du MR à Angello Ramolini (Prégnana).
Comme j’ai pu le constater à plusieurs reprises dans ce genre d’opération de rapprochement, l’entente fut excellente au sein du groupe de travail, les difficultés apparaissant lorsque la définition des projets se matérialise et qu’il faut décider de la répartition du travail et des responsabilités entre les équipes de développement.
Le MR avait une architecture originale en ce sens que chaque processeur avait une mémoire physiquement locale mais reflétant, par duplication et pour une partie seulement, une mémoire commune (concept appelé SLM pour Shared Local Memory). Ce choix d’architecture avait été fait pour simplifier l’implémentation au niveau du matériel. Pour répondre aux attentes de la clientèle XPS notamment, une adaptation VME sur Multibus 2 a été développée.
Le packaging reprenait les principes développés pour le DPX/2000.
Le développement de cette nouvelle ligne de produits connut les difficultés habituelles : retards au niveau des études, retards du fournisseur de microprocesseurs,….

De fait, le développement de la NCL était loin d’être une nécessité. En effet, la nouvelle génération n’apportait pas grand chose par rapport aux gammes existantes (DPX et XPS). En ce qui concerne le DPX, la dimension multiprocesseur aurait pu être apportée sans remise en cause de l’architecture (moyennant le fait de disposer d’une version adéquate d’Unix).
Le développement de la NCL a complètement absorbé les forces de développement d’Echirolles et de Prégnana ne laissait de pas de possibilités pour le développement d’une génération réellement nouvelle. Si le souci de la Compagnie de ne pas pérenniser les deux lignes existantes et de les voir sombrer dans une guerre de tranchées était louable, les conséquences n’en furent pas moins désastreuses à court terme avec la recherche d’un partenaire Unix (IBM en l’occurrence, voir le paragraphe spécifique).

Notons aussi que les choix Motorola et Multibus 2 étaient loin d’être les meilleurs :

Le choix initial de Motorola n’était pas un mauvais choix mais Motorola, après l’introduction du 68030, a accumulé les retards dans les développements de la génération suivante : le 68040 ce qui précipita la fin de cette lignée (pour les serveurs car pour les stations, les jeux étaient déjà faits). De plus, Motorola n’a pas réussi à imposer un standard binaire pour la famille 680x0 sous Unix. Cette absence de standard n’a pas favorisé la disponibilité des applications et a donc desservi l’essor de la famille 680x0 ;
Même au démarrage des études de la nouvelle ligne commune, les chances de Multibus 2 de s’imposer comme un standard étaient déjà bien faibles. On rejoint là le problème des mythes et surtout des dogmes de la Compagnie dans toutes ces années : douter de la pertinence des choix stratégiques n’était pas permis. L’acharnement autour de l’OSI (et donc contre TCP/IP) en est, malheureusement, une magnifique illustration.

Toutefois, le travail en équipe entre les équipes d’origine italienne et les équipes d’origine française sous la direction de Lucio Pinto fut une expérience tout à fait enrichissante et enthousiasmante. Comme indiqué ci-dessus, Lucio Pinto avait un réel esprit d’entreprise et savait transmettre cet esprit par son sens de l’animation des équipes.
Une filiale spécifique fut crée pour l’occasion : Bull XS, de fait la société s’appelait X3S « Société pour les Systèmes Standards ». Des personnes de HIS Italy et de Bull furent détachées dans cette société qui s’installa à Massy. XS avait essentiellement des fonctions de ligne de produit, les développements étaient effectués par les directions techniques et la commercialisation par les réseaux commerciaux. Marcello Ardizzone était responsable de la coordination avec les engineerings, Giancarlo Collina de la stratégie et Armand Malka du marketing.
A la fin de l’existence de Bull XS (début 1991), les personnes détachées furent réintégrées au sein du Groupe.

Pour être complet sur la politique produit XS, il convient d’y ajouter le High End (voir le paragraphe spécifique La Saga du High End) et le VEL (Very Entry Level). Le VEL a été inventé pour des raisons politiques. Le rachat de l’informatique de Honeywell par Bull n’a pas donné lieu à une prise de pouvoir des français. C’est Jacques Weber qui avait été choisi pour diriger la partie nord-américaine de la compagnie. Toutefois, au lieu d’y mettre de l’ordre, il a semblé avoir pris fait et cause pour les exigences des américains qui arguaient de leur connaissance du marché US pour traiter les européens comme si ils (eux) étaient toujours les chefs. Ainsi a-t-on vu tous les choix de XS systématiquement critiqués et remis en cause (voir par exemple les manœuvres concernant les bases de données évoquées plus loin) et, en particulier, une exigence d’inclure dans la ligne un serveur à base de processeur Intel 386. Il fallait bien sûr que ce modèle soit compatible avec les modèles Motorola ( !), il n’avait pratiquement pas de budget et devait compter sur la synergie avec la ligne PC, il devait posséder la même couverture logicielle, etc… La stratégie du Groupe s’en est mêlée avec joie et délectation. Lucio Pinto, un vrai ingénieur pourtant, connaissait bien la compagnie et comment faire pour y réussir, il a donc introduit le VEL pour répondre à ces demandes disparates. Le réseau commercial Bull ne ressentait aucun besoin en la matière et a fourni des prévisions de ventes ridicules (de mémoire 100-120 unités) qui normalement auraient du faire arrêter immédiatement le projet. Jean Papadopoulo, qui avait été nommé chef de produit de cette brillante invention, présenta ces chiffres à une réunion de décision (RD0 en langage interne) en insistant sur le bilan financier désespérément négatif de ce projet. Tous les membres du bureau de cette revue ont néanmoins voté en sa faveur, car c’était paraît-il un projet stratégique ! Au moins cette plaisanterie n’aura pas coûté très cher, la base utilisée étant un Acer 1100 (BM 600 ?) introduite par ailleurs par la ligne PC (Michel Roux). Plus tard, la filiale américaine prit encore plus de poids avec le venue de Ron Pampel, D Wartluft et John Robotham inventèrent la PWS, une « station de travail professionnelle » Unix à base de 486 qui, elle, donna lieu à un design spécifique de carte mère (voir plus loin le paragraphe spécifique) . Il serait intéressant de savoir combien tout cela a coûté à la compagnie…

La recherche d’une solution RISC – Première époque

Les développements de la NCL à peine mis sur les rails et conscients du manque de compétitivité potentiel des microprocesseurs Motorola, nous avons, dès novembre 1987, amorcé la recherche d’une solution RISC. Un groupe d’étude composé de René Chevance, Angelo Ramolini et Serge Sorkine fut chargé de cette investigation.
Les solutions impliquant un accord avec un concurrent de Bull furent exclues du champ d’analyse : on souhaitait avoir une relation avec un fournisseur de technologie (microprocesseurs, compilateurs et Unix) et, éventuellement, une possibilité d’OEM afin de servir de « stop gap » entre la NCL et la future génération à base RISC. Cette précision a son importance : les solutions HP et IBM furent écartées car elles impliquaient une dépendance dans laquelle la société ne souhaitait pas se trouver. Pratiquement toutes solutions a priori ouvertes à des accords avec Bull furent analysées en détails.
Comme toujours, à l ‘émergence d’une nouvelle technologie, il y avait un florilège de solutions potentiellement disponibles, parmi lesquelles il convenait de faire le tri.
Après un inventaire du champ des possibilités (hors HPPA Precision Archirtecture de HP et Power d’IBM), notre premier objectif fut d’aboutir à une « short list »  à partir de laquelle on pouvait procéder au choix final. Notre groupe de travail avait élaboré une liste de critères de choix des différentes solutions et la matrice de comparaison correspondante.
Quelques commentaires sur ces différentes architectures et possibilités associées :

AMD. A cette époque, AMD était un leader dans le domaine des processeurs en tranches et un fournisseur de microprocesseurs compatibles Intel. AMD, qui désirait se diversifier, proposait une nouvelle architecture : le 29000. Le cœur de cible était le support des fonctions de type contrôleur, ce qui correspondait au marché d’AMD avec les microprocesseurs en tranches et aux talents de ses forces commerciales. Souhaitant élargir cette cible, AMD courtisait les constructeurs informatiques. Nous eûmes ainsi droit à une action intensive des forces d’avant-vente d’AMD. La difficulté était qu’AMD n’avait aucune stratégie logicielle (logiciel de base et surtout logiciel d’application) autour du 29000. Le point d’orgue de cette action fut un repas à Palo Alto au restaurant Chantilly. Avec Angelo Ramolini et Serge Sorkine nous étions en mission dans la région et nous avions déjà écarté AMD de nos investigations. AMD avait réussi à nous localiser et nous n’avions pu faire autrement que d’accepter une invitation à un dîner. Durant ce dîner, qui dû coûter une petite fortune à AMD, nous eûmes d’âpres discussions avec les représentants d’AMD au cours desquelles nous tentâmes de les convaincre de restreindre le 29000 à son cœur de cible et de poursuivre parallèlement le développement de ses microprocesseurs compatibles Intel ;
Intel 860. Le 860 avait été développé initialement par un centre de recherches Intel en Israël. La cible initiale un coprocesseur pour le calcul numérique intensif. L’engouement pour le RISC poussa Intel à transformer ce projet en processeur à part entière. Avant qu’Intel ne se lance dans cette opération, le marketing Intel utilisait le terme YARP (Yet Another RISC Processor) pour désigner, péjorativement, les processeurs RISC. Le 860 souffrait d’un certain nombre de déficiences : plan logiciel peu développé, difficulté de prise en compte des exceptions (vidage de l’état interne du processeur sur la pile, charge au système de déterminer ce qui est arrivé !),… Le 860 n’attira pratiquement aucun constructeur : un constructeur de stations de travail et Stratus qui développa un système à continuité de service (principe de fonctionnement fondé sur le matériel avec doublement) ;
MIPS. Cette startup avait développé 3 générations de processeurs RISC (R1000, R2000 et R3000) sur la base de son architecture (dérivant des travaux de l’Université de Stanford). On peut considérer que les systèmes à base de R3000 étaient réellement ses premiers produits industriels. MIPS avait un plan complet tant logiciel que matériel autour de la nouvelle génération : le R4000. MIPS avait aussi lancé un programme (Synergy) pour constituer un catalogue d’applications. Le plan R4000 était prometteur (performance, multiprocesseur,…).
Motorola 88000. Ce projet avait dû naître dans un contexte particulièrement conflictuel chez Motorola : lors de nos visites à Austin, les équipes 680x0 et 88000 défilaient successivement dans la salle de réunion, la « pérennité de l’institution » étant assurée par les seuls représentants marketing. C’est ainsi que nous n’eûmes aucune réponse valable à notre question concernant la transition ou la co-existence entre notre gamme 680x0 et une nouvelle gamme 88000. La situation étant tellement perceptible (à l’extérieur de la compagnie) que Motorola fusionna les deux divisions et nomma un responsable commun. La conséquence directe fut le départ de Roger Ross et de quelques hommes clés du 88000. Le point le plus intéressant du 88000 était son bus multiprocesseur (dont la famille Power PC s’inspira). L’architecture n’avait pas un nombre de registres suffisant (flottant). L’implémentation faisait que la taille du cache associé à un processeur diminuait lorsque l’on augmentait le nombre de processeurs en configuration SMP (ce point fut corrigé par l’implémentation suivante). Là aussi, les aspects logiciel étaient peu satisfaisants. Le 88000 n’attira pas grand monde à l’exception de Data General et de Stratus.
SPARC. L’introduction de SPARC par Sun fut le véritable déclencheur de la vague RISC. La première implémentation était simple, elle utilisait un Gate Array de Fujitsu ( de l’ordre de 20 000 portes si ma mémoire est bonne). Le plan était complet en particulier sur le plan logiciel (y compris les compilateurs). A cette époque, Sun était essentiellement un fournisseur de stations de travail mais avait l’ambition de devenir un fournisseur de serveurs. Ainsi, Sun nous présenta un projet de système à 64 processeurs. Sun était très intéressé par une collaboration avec Bull. Il y avait, outre le fait d’avoir un partenaire de plus embarqué sur le navire SPARC, deux raisons majeures à cet intérêt : tirer profit de l’expérience de Bull dans les serveurs (lire mainframes) d’une part et accéder aux clients de Bull avec sa future offre de serveurs d’autre part. A mes yeux, la coopération avec Sun présentait un risque potentiel pour Bull car Bull n’était pas prêt –à cette époque- à remplacer les mainframes par des serveurs Unix. Sun étant une société sans complexes et sans états d’âme, Bull risquait de se trouver en difficulté sur son propre marché. Notons aussi que le mythe OSF ne facilitait pas un accord avec Sun (l’ennemi juré avec son actionnaire ATT).

Nous passerons sous silence certaines propositions qui ne résistaient pas à un premier niveau d’analyse. Mentionnons toutefois, CCI avec son projet Regulus. C’était une nouvelle architecture destinée à remplacer le mini 6/32 que nous avions examiné lors de notre première recherche d’un partenaire Unix. CCI ne semblait pas avoir les moyens de mener ce programme à bien et les volets logiciels (applicatifs en particulier) étaient bien faibles. Bien évidemment, lors de nos meetings techniques nous avons posé la question des compilateurs optimisants.

Les différents critères retenus par le groupe de travail étaient :

Partenariat stratégique
Disponibilité de produits
Système d’exploitation Unix
Disponibilité d’applications Unix
Performance
Acceptation par le marché
Scalabilité
Stratégie du fournisseur
Support d’OSF
Viabilité à long terme
Multi-source/Source majeure
Architecture/Technologie/adressage 64 bits

L’ordre dans lequel cette liste est présentée ne reflète pas le poids des différents critères.

La décision finale fut pour MIPS. Ce choix était conforté par le choix de l’architecture MIPS par un certain nombre de concurrents : Digital, NEC et SIEMENS notamment.
L’accord fut signé officiellement le 27 septembre 1989 par Francis Lorentz.
Afin de ne pas impacter la NCL qui n’était d’ailleurs pas encore annoncée, il fut décidé de ne pas introduire de produits à base de R3000. En revanche, pour satisfaire à des demandes (des US en particulier) de système Unix de haut de gamme (la saga du haut de gamme fait l’objet d’un prochain chapitre), on décida d’introduire un système, en OEM, à base de R6000. L’une des raisons de la demande pour un Unix haut de gamme venait du besoin de remplacer les systèmes Multics qui arrivaient largement en fin de vie et comme rien n’avait été réellement prévu pour leur succession, on rechercha à la hâte des palliatifs. Parmi les demandes du marketing US, si mon souvenir est exact, il y avait une demande pour le support d’un nombre pharamineux de terminaux asynchrones (plusieurs centaines)….
Le R6000 était une implémentation en ECL de l’architecture MIPS (version monoprocesseur). Le processeur était développé par une petite société : BIT (Bipolar Integrated Technology) et le système était développé par MIPS. Ce système a tardé à « tomber en marche »  et n’a pas rencontré de marché. Je me souviens, quelque temps après, d’avoir tenté de persuader des collègues universitaires d’acheter à prix de faveur quelques systèmes R6000 qui étaient restés en stock chez Bull. Notons qu’une version ECL d’un processeur RISC n’était pas propre à MIPS puisqu’il y avait aussi, chez BIT si ma mémoire est bonne, un projet de processeur SPARC en ECL (projet qui n’a pas abouti si je me souviens bien). Notons aussi, qu’un startup, Prisma, avait travaillé sur un projet de système haut de gamme Unix sur l’architecture SPARC (ECL ou AsGa ?), Pete Wilson connaît bien cette histoire.
L’activité autour de MIPS se concentrait donc sur le R4000, nouvelle génération en cours de développement. Le R4000 supportait le multiprocesseur et MIPS développait le M5, un système à 8 processeurs.

Les retards accumulés par MIPS dans le développement du R4000 et les désillusions en matière de performance (en contexte système), la désaffection de Digital qui avait introduit son architecture Alpha, la pauvreté du catalogue d’applications, etc. firent que cette filière technologique perdit de sa compétitivité et de son attrait.

Notons aussi que lors la recherche d’un partenaire RISC, le reciblage de la ligne DPS6000 sur l’architecture RISC avait été décidé sous l’impulsion de Ron Pampel. Il avait en effet décidé de ne plus financer le développement de matériel spécifique DPS6000 ni DPS4000.
La situation du DPS4000 était plus favorable que celle du DPS6000 : absence de développement en assembleur ou assimilé, forte isolation entre les utilisateurs/programmeurs et le système,….
Différentes études avaient été menées pour le reciblage du DPS7000 et, dans une moindre mesure pour le DPS9000, sur l’architecture RISC. Pour le DPS7000, deux hypothèses techniques avaient fait l’objet d’investigations (à des époques différentes) : une émulation par logiciel et une technique de traduction dite « transcompilation ». En ce qui concerne la première approche, la conclusion avait été négative, la performance « native » des microprocesseurs n’étant pas suffisante (la conclusion fut positive quelques années après avec le projet Diane). Quant à la transcompilation, elle conduisait à des encombrements de code prohibitifs.
La conclusion pour le DPS8000 (émulation par logiciel), était négative. Notons que les processeurs du DPS9000 avaient une performance intrinsèque supérieure à ceux du DPS7000 et, surtout, que l’architecture 36 bits entraînait une complexité et, par voie de conséquence, un fort impact sur la performance d’un émulateur. Les possibilités offertes par les microprocesseurs avaient changé lors du projet V9000.

Rétrospectivement, nous pouvons dire que l’un de nos torts, tant pour l’épisode MIPS que pour l’épisode Power PC/IBM (voir ci-après), est de pas avoir considéré suffisamment Intel x86 et le poids de la « machine à dollars » que représentaient (et que représentent toujours) les ventes de PC. En effet, sur la base d’une architecture (ISA Instruction Set Architecture) peu propice aux hautes performances, Intel a réussi à développer des implémentations parfaitement compétitives (sauf en virgule flottante, mais ce n’est pas la tasse de thé de la clientèle de Bull). Intel présentait l’avantage de fournir des systèmes en OEM et on a pu noter, au cours du temps, une synchronisation de plus en plus fine entre : la disponibilité des microprocesseurs, les chip sets associés et les systèmes pour les OEM, rendant difficile la compétition directe avec Intel sur ces systèmes en terme de « Time to Market ». Notons, toutefois, qu’Intel, avec ses « Reference Design » interdisait à ses OEM de le concurrencer. Cela obligeait les OEM à trouver, pour leurs propres systèmes, à trouver des domaines complémentaires à ceux déjà couverts (et à devoir en trouver de nouveaux lorsque Intel décidait d’investir le domaine). Intel semblait ouvert à la coopération, il nous l’a montré au début du projet FAME (voir plus loin le paragraphe spécifique). Bien sûr, Intel ne proposait pas, en 1990, d’architecture viable 64 bits. Bien que les architectures 64 bits aient mis du temps à se matérialiser et à se répandre et qu’une architecture 64 bits n’était pas nécessaire sur le marché en 1990, il convient de noter que l’existence de plans solides dans ce domaine était un critère de choix important.
La recherche d’un partenaire RISC-Unix

Dans la foulée de la désillusion MIPS et sous l’égide de la Direction Stratégie de Bull (avec Steve Bagby et Georges Lepicard), la phase active de la recherche de partenariat Unix fut entreprise en octobre 1991. L’objectif de cette recherche était de développer une alliance stratégique avec un partenaire majeur dans le domaine des systèmes Unix. Un autre objectif était de procurer du travail aux équipes d’Echirolles et de Prégnana.
Trois constructeurs avaient été retenus pour le premier tour de piste : Digital, HP et IBM. Digital ne fut pas retenu pour le second round.
Deux groupes de travail furent constitués côté Bull pour mener cette investigation : un groupe de niveau « manager » et un groupe technique appelé Back Office. Histoire de brouiller les pistes, deux noms de code furent attribués à nos partenaires potentiels : HP était Austin et IBM était Waco (ville US rendue tristement célèbre par la fin tragique des membres d’une secte). Pour IBM, Bull était Dallas et pour HP, Bull était China me semble-t-il (la signification étant peu flatteuse : « Elephant in a China shop »).
Le groupe technique était composé de : René Chevance, Michel Guillemet, Carlos Michberg, Bernard Nivelet, Jean-Jacques Pairault et Angelo Ramolini.

Plusieurs meeting furent organisés, en France et aux Etats Unis. Il apparut très rapidement que les possibilités de coopération avec HP étaient beaucoup plus limitées qu’avec IBM. En effet, HP avait une gamme de systèmes complète avec des multiprocesseurs alors qu’IBM venait d’introduire des systèmes monoprocesseurs à base de sa nouvelle architecture Power. Cette architecture faisait suite à l’introduction malheureuse du RT PC. IBM ne disposait pas d’une version d’Unix multiprocesseur. IBM avait signé un accord stratégique autour de la technologie Power PC avec Motorola et Apple.
Dans le cadre de ce partenariat, un centre commun de conception (le Somerset Design Center) avait été créé, entre IBM et Motorola à Austin (Pete Wilson qui y fut détaché par Bull pourrait apporter son témoignage ; Pete est actuellement chez Motorola). Plusieurs microprocesseurs étaient au programme : 601, 603 (monoprocesseur et basse consommation), 604 et le 620. Le bus multiprocesseur du Power PC s’inspirait de celui du 88000 de Motorola.
Nous eûmes un meeting avec Motorola sur le programme microprocesseur Power PC en novembre 1991. Dès cette époque, nous avions émis quelques doutes sur la faisabilité d’un programme aussi ambitieux : il était prévisible qu’il y ait quelques loupés d’autant que Motorola était intéressé par les objets à grand volume (Apple) plutôt que par des microprocesseurs haut de gamme à faible volume. On peut dire, que, contrairement aux affirmations ayant présidé à son lancement, que Power PC n’a pas été une architecture ouverte, IBM se réservant notamment la possibilité de développer ses propres microprocesseurs pour son propre usage (nous y reviendrons)…..

En ce qui concerne HP, je me souviens d’un meeting à Palo Alto, en décembre 1991, au cours duquel HP nous présenta Emerald, son système haut de gamme à 8 processeurs. A la question, « Que pourrions-nous faire comme développement ? », HP nous répondit « Vous pourriez faire, sur la base de cette technologie, un système optimisé à 4 processeurs ». Constat peut enthousiasmant qui fut encore assombri quelques petites semaines plus tard lors d’un meeting à Paris où HP nous présenta Kitty Hawk, un système quadri-processeur optimisé réalisé sur une seule carte…. Pour l’anecdote et pour illustrer l’attitude de HP vis-à-vis des partenariats, lors d’une visite à Palo Alto, je vis un système Séquoia (système Unix Fault Tolerant que j’avais analysé dans le cadre d’une investigation Fault Tolerant, voir le paragraphe spécifique). Pour les besoins du marché des Telcos, HP venait de signer un accord de distribution avec Sequoia. J’étais avec Wim Roelands (VP Unix), et je l’interrogeais sur ce système, il partit alors dans une diatribe contre les systèmes développés en dehors du sérail…. Un heureux présage pour les partenaires potentiels !

L’accord avec IBM se présentait sous de meilleurs auspices, IBM n’avait pas de version multiprocesseur d’AIX tandis que Bull possédait une telle version, le plan microprocesseur était supporté par un fabricant important, Apple ne se présentait pas comme un concurrent, …. A l’opposé, HP maîtrisait la technologie multiprocesseur Unix, ne fournissait que lui-même en microprocesseurs,…. Bien évidemment, l’aspect favorable de l’accord avec IBM ne valait que pour le court terme. Comme on le verra dans la suite de l’exposé, IBM ayant acquis ma maîtrise du matériel et du logiciel Unix multiprocesseur n’avait plus besoin de la compétence de Bull.

L’accord avec IBM se fit sur la base technique suivante (dans les grandes lignes) :

développement d’un SMP fondé sur Power PC devant accommoder les différentes versions de microprocesseurs : 601, 604 et 620. Pegasus était le nom de code de ce système. Bull (Pregnana) était responsable du développement du cœur du système (architecture fondée sur un cross bar pour les données et un bus d’adresses) tandis qu’IBM était responsable du développement de la puce d’interface avec le bus d’entrées-sorties. Pregnana (Angelo Ramolini) était en charge du développement ;
développement en coopération d’AIX, Bull (Echirolles) apportant la dimension multiprocesseur à AIX (voir l’article de Jacques Talbot dans les actes de la conférence USENIX 1995). IBM assurait l’intégration du système et conservait la maîtrise de l’ensemble.

Nous eûmes un grand meeting technique organisé à Austin chez IBM autour de cet accord en décembre 1991. Nous avons trouvé une certaine communauté d’état d’esprit avec nos homologues d’IBM : mêmes expériences, mêmes difficultés,… Une anecdote pour illustrer cette communauté : lors d’un dîner texan organisé par IBM dans les environs d’Austin, nous avions raconté à nos partenaires les notions de base de gestion de projet chères à Lucien Nègre : le RQCV et le RQCM. Ces abréviations rencontrèrent immédiatement un vif succès ce qui fut pour nous une double satisfaction : l’apport de Lucien Nègre avait franchi l’Atlantique (en dehors du contexte Bull) d’une part et nos nouveaux partenaires avaient suffisamment vécu pour en percevoir tout le sel d’autre part.

Le développement de Pegasus a subi les aléas habituels accentués par les retards des microprocesseurs. Dans ce domaine, le 620 a établi des records, on peut dire qu’il n’est jamais réellement « tombé en marche » alors que Bull avait fondé de grands espoirs sur cette puce. Le système Pegasus était commercialisé conjointement par Bull et par IBM.
En ce qui concerne AIX, Bull avait l’ambition d’utiliser le nom BOS-X (Bull Operating System) pour désigner le système AIX. C’est là que l’on commença à percevoir les limites d’un partenariat avec IBM : les fournisseurs de logiciel (tel Oracle par exemple) demandaient alors des redevances pour la qualification du portage du produit (portage parfaitement virtuel puisqu’il ne s’agissait que d’un changement « marketing » du nom). La solution la plus rapide et la plus économique qui s’imposait était alors un alignement strict sur IBM en abandonnant le sigle BOS-X.
Sur la base de Pegasus, on décida de développer un système optimisé pour 4 processeurs : Pegakid en ciblant le 620, une solution de repli sur le 604 a été demandée lors de la revue de conception.

Avec Alain Couder à la direction d’OSS (Open Systems ans Software) et l’arrivée de Didier Bretonen tant que manager d’Unix et du pôle Echirolles/Pregnana Bull a été entraîné progressivement dans une dépendance de plus en plus grande vis-à-vis d’IBM. Didier Breton, en outre, poursuivait le rêve d’un accord OEM avec Apple autour d’un système bas de gamme (station/serveur) qui aurait été un produit à grand volume. Un tel accord ne s’est jamais matérialisé mais la poursuite de ce mythe eut des effets négatifs sur les possibilités de différentiation de Bull : les investissements qui n’étaient pas dans l’axe de ce produit à grand volume étaient systématiquement mis en veilleuse. Cette dérive fut plus marquée à Echirolles qu’à Pregnana ; ceci amena Jean Papadopoulo à formuler sa célèbre règle de trois :

On ne fait rien
Mais c’est en coopération avec IBM
Et cela se passe à Echirolles

Cette formulation peut sembler brutale et il convient de ne pas en rendre le personnel d’Echirolles totalement responsable. Après la phase de participation active lors de transformation d’AIX en multiprocesseur, l’alignement systématique sur IBM et la dépendance qui en résultait, a placé les gens d’Echirolles dans une situation particulièrement inconfortable : soit on ne fait rien et cela se remarque, , soit on rame à contre courant et cela est mal perçu, soit on « bricole » en coopération avec IBM et cela est bien perçu car cela va dans le sens du courant…. Dans d’autres contextes, on a connu sous le nom de « job protection » ou avec la technique des « deux vestes » des comportements tout aussi efficaces et tout aussi rentables.

Cette stratégie OEM « à tout prix » a eu des conséquences fâcheuses tant sur la rentabilité de l’activité que sur les initiatives de développement. A toute proposition de développement, même modeste, la réponse était invariablement :

Si IBM ne l’a pas fait, c’est que cela ne sert à rien (ou ne répond à aucune demande du marché) ;
Si c’est intéressant, IBM le fera et ce n’est donc pas la peine qu’on le fasse.

Je me souviens d’avoir un peu bagarré lors d’une CDR à Echirolles pour que l’on investisse sur Fibre Channel alors que les équipes ne voulaient que suivre IBM et sa technologie propriétaire SSA. Une autre illustration est avec le File System « clusterisé » (i.e. vision unique du File System dans un environnement cluster quels que soient les nœuds qui supportent les fichiers). Dans le cadre d’un projet de recherche sur une technologie de mémoire distribuée partagée, j’avais suggéré que l’on démontre cette technologie en développant un File System « clusterisé ». IBM tardait à introduire un tel File System dans son offre HACMP, il y avait là une bonne opportunité pour Bull (la trajectoire logique consistant à revendre ensuite cette implémentation à IBM). Le prototype existait et était fonctionnel : pas de décision. Résultat, les personnes (de bon niveau) qui avaient développé ce File System ont quitté Bull…

Un effet de bord de cet alignement sur IBM s’est manifesté dans les équipes des Clayes en charge du High End (voir ci-après la Saga du High End) : le plus important était de monter une coopération avec IBM, la définition et l’adéquation du système au marché étant assez secondaires… (en exagérant à peine).

J’avais déjà rencontré cette situation lors de l’accord avec Convergent Technologies (CT) autour du Questar 400. Périodiquement, lors des meetings avec les représentants marketing de ses OEMs, CT testait les projets potentiels avec quelques présentations baptisées « Coming Attractions ». Les hommes du marketing avaient tendance à prendre ces présentations comme argent comptant et refusaient toute initiative dans les domaines concernés. J’avais même surnommé, par dérision, ces présentations de « Comic Attractions ».

Une petite note sur la culture du cycle de vie des produits. J’ai participé à deux CDR : Pegasus le 2 juin 1992 et Pegakid le 27 février 1995. Il s’agissait de CDR mixtes tant au niveau du « board » qu’au niveau de l’équipe projet intégrant des représentants de Bull et d’IBM ou de Motorola. Ces revues se sont parfaitement déroulées, nos partenaires étant parfaitement rompus à cet exercice, les quelques différences de vocabulaire ayant été rapidement aplanies.

En ce qui concerne les activités, Echirolles se consacrait au logiciel tandis que Pregnana se consacrait au matériel. La dépendance de plus en plus accrue vis-à-vis d’IBM conduisit Bull à se séparer de Pregnana avec la création d’une société indépendante de développement nommée, non sans humour, CIAO Engineering.

A partir du développement de Pegasus et de Pegakid, les sujets de coopération avec IBM s’étaient raréfiés. IBM avait acquis, grâce à Bull, la maîtrise de la dimension SMP dans AIX. IBM n’attendait plus Bull pour développer du matériel SMP. L’échec du 620 et la fin de l’opération Somerset Design Center eurent pour conséquence que Motorola se cantonna dans le développement de microprocesseurs pour Apple et pour les applications embarquées et que le développement des microprocesseurs pour SMP haut de gamme était le seul fait d’IBM. Sur ce dernier point, IBM était peu enclin a donner à Bull un accès à ses microprocesseurs, IBM préférait largement vendre des systèmes en OEM à Bull. Afin de faire le point sur les développements futurs Power PC chez IBM, j’eu, en mars 1999, un meeting à Austin. Ce meeting fut très instructif mais il confirma (si besoin était) qu’en dehors de l’OEM il n’y avait point de salut.

Pour être complet, on mentionnera le système d’entrée de gamme monoprocesseur baptisé Estrella en provenance de Motorola (système qui accumula aussi quelques retards). Ce système fonctionnait soit sous AIX soit sous NT 3.51. Il y avait, pour Didier Breton en particulier, l’espoir d’atteindre avec NT des produits à grand volume. Cet espoir disparut fin 1996 avec l’abandon de la filière NT sur Power PC.

En plus de ces difficultés structurelles, Didier Breton, auquel il convient de reconnaître un dynamisme et une capacité d’entraînement, avait une façon très personnelle (au sens du jeu sportif, formule que les amateurs de sports collectifs comprendront aisément) de gérer les relations avec IBM ainsi qu’avec Motorola. Si quelques personnes étaient au fait de certains aspects des dossiers, personne, en dehors de Didier Breton, n’en avait une vision globale. Comme on l’a évoqué ci-dessus, Didier Breton souhaitait prendre le maximum d’éléments chez IBM, on a ainsi faillit introduire le SP d’IBM. Tout ceci entraîna Bull dans une dépendance de plus en plus grande vis-à-vis d’IBM. Comme par ailleurs, le Power PC n’avait pas attiré suffisamment de partenaires « système » et que Motorola ne jouait pas et n’avait apparemment pas l’intention de jouer, sur la base de Power PC, le même jeu qu’Intel, tout ceci contribua à placer Bull dans une position de dépendance de plus en plus étroite vis-à-vis d’IBM (avec des conséquences désastreuses sur les marges).
La Saga du High End

Plusieurs tentatives de projet (Unix) High End furent lancées aux Clayes. J’essayerai de retracer les tendances globales et non pas le détail de ces tentatives. Il y avait souvent derrière ces tentatives, l’objectif pour ou moins avoué d’établir une coopération avec IBM…. Citons quelques têtes de file (par ordre alphabétique et non chronologique) : Jean Bellec, Paul Couhault, Bernard Nivelet, Elen Park, Michel Sakarowitch.
Ces tentatives ont toutes connu le même sort. Beaucoup de ces tentatives se situaient au niveau MRO (Market Requirements and Objectives) et PRO (Product Requirements and Objectives), la partie architecture était moins développée.

Cette Saga ne saurait être complète (elle ne l’est probablement pas d’ailleurs) sans y intégrer l’épisode VLMP. L’idée du VLMP (Very Large MultiProcessor) avait été lancée par Jean-Jacques Guillemaud, qui était en charge des études et des mesures de performances pour la gamme DPS7000, dans la seconde moitié des années 80. L’idée directrice du VLMP était d’avoir un environnement mixte : GCOS7 et Unix sur un grand multiprocesseur mêlant des processeurs natifs GCOS7 et des processeurs RISC. Sur les processeurs Unix/RISC, on faisait tourner les logiciels « standard » type SGBD relationnels, pile TCP/IP, middlewares,… Progressivement, au fur et à mesure de l’évolution des besoins, on faisait varier le ratio GCOS7/Unix. Cette idée avait séduit Jacques Stern. Une étude fut lancée aux Clayes sous la direction de Jean-Jacques Pairault. Bien qu’un tel projet comporte une part logiciel importante, les quelques forces d’étude dédiées à cette étude n’étaient qu’axées sur le matériel. Il semblerait que « l’establishment Engineering» ne croyait pas à l’avenir de ce projet et n’attendait qu’une bonne occasion de « torpiller » le projet, occasion qui bien sûr se présenta… Nous eûmes les premiers contacts avec Jean-Jacques Guillemaud sur le VLMP en avril 1989. Les ressources allouées au projet étaient plus que modestes : 4 personnes à plein temps, 3 personnes pour la performance (temps partiel), une personne pour la liaison série et la conception VLSI et 3 ou 4 architectes matériel. L’équipe devait monter à 15 personnes en janvier 1990. Les objectifs de date étaient : CDR en 2Q ou 3Q 1990 et FCS fin 1992. Compte-tenu de la modestie des ressources, Jean-Jacques n’était guère optimiste (il n’était d’ailleurs pas en charge du projet).

On a relaté ci-dessus, l’accord avec MIPS et l’introduction de la machine haut de gamme Unix R6000 (monoprocesseur en ECL). Il existait deux demandes, émanant des US : un système capable de supporter un grand nombre de terminaux asynchrones et un remplaçant de Multics. Comme on l’a indiqué, le R6000 n’a pas été un succès.

Les réflexions sur NCL3 débutèrent en février 1988. Suite au démarrage de Bull XS, un petit groupe de travail piloté par Giancarlo Collina se chargea de la définition (PRO – Product Requirements and Objectives) des objectifs d’un High End Unix. Une présentation de cette PRO eut lieu à Massy en octobre 1990. Les deux représentants des lignes DPS7000 et DPS9000 qui assistaient à cette présentation devaient la juger peu palpitante puisqu’ils discutaient du contenu du catalogue de la Foire aux Vins d’Auchan….

En mars 1991, nous eûmes quelques réunions internes sur un projet baptisé Perseus. Les hypothèses techniques étaient un système à 32/64 processeurs MIPS  HYPERLINK "mailto:R4000@100Mhz" R4000 à 100 Mhz tirant profit des études VLMP. La question du modèle global d’architecture n’était pas réglée. Des groupes de travail avaient été initialisés : Applications, Dimensionnement, Propriétés d’un Unix « mainframe » et DB/TP. Les premières conclusions des groupes furent présentées au cours d’un séminaire en avril 1991. Les efforts se sont ensuite dilués.

En 1992, un projet d’IBM connu sous le nom de Live Oak suscita un certain intérêt. Il s’agissait de la réunion de stations de travail pour constituer une machine puissante avec une particularité architecturale : une mémoire partagée entre les différentes stations RS/6000 qui composaient le cluster. Une revue interne Live Oak se tint en mars 1993. Cette particularité architecturale faisait perdre à Live Oak la propriété fondamentale des clusters qu’est la haute disponibilité : suite à la défaillance de l’un des nœuds, on n’a aucune assurance sur la cohérence des informations placées dans cette et la prudence veut que l’on procède à une réinitialisation complète du cluster. Les accords de coopération avec IBM étaient dans une impasse, IBM préférant semble-t-il « poubeller » le projet plutôt que d’en laisser ne fut-ce que des miettes à Bull aussi ont-ils demandé des sommes démesurées qu’ils savaient hors de portée de Bull. Live Oak fut abandonné par IBM et le projet sombra sans faire de bruit…. Compte tenu de tout ce qui précède, il n’y a rien à regretter pour Bull de ne pas s’être aventuré dans cette histoire.
IBM avait deux produits haut de gamme : le cluster RS/6000 appelé HACMP (High Availability/Cluster MultiProcessing) et la machine massivement parallèle SP. Il convient aussi de noter que l’Unix du SP (MPP) et HACMP n’avait rien de commun : ils avaient été développés de façon totalement indépendante (HACMP par une société indépendante CLAM que nous visitâmes en mars 1995) et l’Unix du SP par les équipes de Kingston. Après la commercialisation des produits, IBM envisagea un plan de convergence entre ces deux logiciels. En effet, la base système pouvait être la même, les versions pour le cluster et le MPP correspondant à deux points d’optimisation différents : HACMP est orienté vers la continuité de service tandis que le système du SP est orienté vers la haute performance. Compte tenu de la cible marché de Bull à cette époque et de la compétence du réseau commercial, la continuité de service était un objectif plus attractif que les applications parallèles.

En novembre 1992, Jean Bellec avait initialisé une réflexion sur un système haut de gamme baptisé Centaurus. Contrairement à d’autres tentatives dans le même domaine, Jean Bellec n’avait pas pour objectif majeur de « décrocher » une coopération avec IBM. Un séminaire Centaurus fut organisé en janvier 1993. Ce séminaire n’a pas permis d’atteindre des conclusions claires entre les tenants d’une démarche logique orientée vers les besoins de Bull et les tenants d’une coopération à tout prix avec IBM. Sur le plan technique, Jean Bellec proposait (avec clairvoyance) un packaging en rack.

Voyant que les activités sur le High End avaient du mal à se mettre en place, je lançais en avril 1993 l’idée du HACMP++. Il s’agissait d ‘examiner les améliorations que l’on pouvait apporter à HACMP sans trop diverger si possible. L’un des objectifs du système High End étant de supporter un SGBD, je me suis lancé dans l’analyse de l’architecture d’Oracle Parallel Server avec l’objectif d’identifier les points possibles d’amélioration. Cette compréhension du fonctionnement d’Oracle Parallel Server était tout à fait car si beaucoup de personnes en parlaient de ce produit, bien peu connaissaient la façon dont il fonctionnait effectivement. Mes souvenirs de l’étude SGBD menée pour TRIX et les manuels (forts bien faits) d’Oracle m’ont facilité la tâche. Comme les autres, cette idée a tourné court.

En 1993, Bernard Nivelet avait lancé Mississipi (appelé ainsi suite aux inondations que cette région venait de subir). Une CDR eut lieu en novembre. Les résultats n’étaient pas encourageants surtout sur les aspects logiciel.

Il est difficile de parler des projets High End sans évoquer la liaison série proposée par Roland Marbot appelée ISL (pour Inter System Link). Roland Marbot avait inventé une liaison série rapide et fort simple. Pour les besoins de validation et de démonstration de la technologie, une maquette à base de cartes PC avait été développée (de fait, un kit d’évaluation). Ce projet avait peu de moyens, le développement d’un chip interfaçant sur le bus 620 fut entrepris (Alain Boudu et Jean Furelaud). Nous présentions de façon quasi systématique cette liaison lors de nos contacts avec d’autres sociétés avec l’espoir de recueillir leur adhésion (en étant toutefois conscients de la réalité de la situation mais l’adhésion de partenaires pouvait donner l’occasion de passer à la vitesse supérieure). L’implication modeste de Bull sur ce projet ne permit jamais de passer à la vitesse supérieure. Roland Marbot quitta Bull pour ST et l’affaire ISL s’arrêta pratiquement là.

Il convient de dire quelques mots de Sagister dont la CDR se tint en 1997. Le projet était né au sein de Enterprise System. L’idée était d’assembler et de qualifier un ensemble d’applications sur un système Unix complété par une structure d’accueil destinée à lui conférer, ainsi qu’aux applications du marché qu’il supportait, les propriétés que l’on attendait des mainframes (i.e. les « mainframe disciplines »). Du logiciel spécifique devait donc être mis en œuvre pour fournir une structure d’accueil et d’intégration d’un ensemble sélectionné d’applications. On retrouvait là des écueils rencontrés avec la Professional Work Station (voir ci-après) : le choix des applications, l’effort d’intégration entraîne des retards, la difficulté de synchronisation des versions (soit on peut accepter de n’être pas à jour dans les versions ou soit on vit dans un état d’intégration permanent). Ce projet, qui avait fait l’objet d’une campagne de promotion, tourna court.

Cette Saga ne serait pas complète sans mentionner les contacts que nous avons eu avec différentes sociétés pour examiner les possibilités de coopération (à des degrés divers) dans le domaine des systèmes (certaines de ces sociétés ayant déjà été rencontrées pour d’autres motifs) : Data General, HP, Pyramid, Tandem, Sequent, …...

Peu de choses résultèrent de tous ces essais. L’affaire Polykid prit une autre ampleur.

Episode Polykid.

Fin 1994 et début 1995, les discussions entre les lignes GCOS (Enterprise Systems ou ES, dirigée par Jean-Claude Albrecht) et la ligne Unix (OSS - Open Systems and Software, dirigée par Alain Couder) étaient vives autour d’un haut de gamme Unix. ES travaillait sur l’hypothèse d’introduire des systèmes Sequent, ES était en relation sur ce sujet avec NEC qui travaillait, entres autres, sur cette hypothèse.
NEC avait bien caché ses intentions à ES car, peu après une mission au Japon (Jean-Claude Albrecht et Alain Bron) au cours de laquelle NEC confirmait la direction Sequent, NEC annonça un accord avec HP. L’annonce de cet accord provoqua la stupeur chez Bull. Si cet accord pouvait faire sens au Japon où HP n’avait alors qu’une faible implantation, cet accord aurait été destructeur pour Bull en Europe compte tenu de la forte présence de HP d’une part et de notre partenariat avec IBM d’autre part.
Sequent commercialisait un système SMP sur la base de processeurs Intel (IA-32) supportant jusqu’à 32 processeurs. Sequent avait aussi en cours de développement un système de type CC-NUMA (Cache Coherent – Non Uniform Memory Access) de nom de code Sting. Le système était constitué par l’assemblage de modules quadri-processeurs (module étroitement dérivé de la carte SHV d’Intel) interconnectés par un réseau rapide à interface physique conforme au standard SCI (Scalable Coherent Interface). Sequent avait développé son propre protocole de cohérence au-dessus de cette interface. Le système fut commercialisé par Sequent sous le nom de NUMA-Q (Sequent a été racheté ultérieurement par IBM). Ce projet nous avait été très rapidement présenté en mai 1994 lors d’une visite chez Sequent.
OSS poussait l’idée du clustering sur la base de l’offre Pegasus avec HACMP, la version cluster d’AIX. Pour améliorer cette offre, les architectes pensait utiliser la liaison série inventée par Roland Marbot (voir ci-dessus).

OSS était opposé à l’introduction de systèmes Sequent, il convenait donc de proposer une solution alternative. Un petit groupe de travail fut constitué mi-1995 avec Angelo Casamatta, René Chevance, Angelo Ramolini, Jacques Talbot et Pete Wilson. En deux meetings consécutifs, l’un à Echirolles et l’autre à Prégnana fin juillet/début août 1995, nous définîmes le projet YANG (qui fut ensuite baptisé Polykid). YANG signifiait Yet Another New Generation. Il s’agissait de l’assemblage de modules Pegakid (quadri-processeur 620) pour former d’un système CC-NUMA. Les grandes lignes de l’architecture, le plan de développement et les performances potentielles furent élaborées durant ces deux meetings. La faisabilité de Polykid reposait sur les deux hypothèses fortes suivantes :

Disponibilité du 620 à la date et aux performances annoncées ;
Mises à disposition de moyens de développement suffisants tant pour le matériel que pour le logiciel.

Aucune de ces hypothèses ne s’est confirmée, le 620 a accumulé les retards et les performances n’étaient pas au rendez-vous (déficit que les retards aggravaient encore plus). Les ressources sur le plan du matériel étaient comptées (au profit de projets de systèmes de bas de gamme, nous y avons déjà fait allusion) et l’investissement sur le logiciel était timide. Autant l’équipe de Pregnana se montrait dynamique, autant l’équipe d’Echirolles se montrait timorée (voir le syndrome cité précédemment : si IBM ne le fait pas c’est que cela n’a pas d’intérêt et, si cela a un intérêt, IBM le fera). Ces points étaient particulièrement visibles lors des multiples revues Polykid auxquelles j’ai participé (revue préliminaire le 21 septembre 1995, CDR le 10 avril 1996, 2ième CDR le 27 novembre 1996, revue performance le 29 mai 1997). Toutes les CDR avaient en commun trois risques inacceptables : les plans du 620 et le besoin de faire évoluer AIX pour supporter correctement ce système, tout en garantissant la compatibilité binaire avec l’AIX d’origine. Sur ce dernier point, Bull qui avait cherché à intéresser IBM à la technologie CC-NUMA de Polykid, n’a jamais eu que des réponses dilatoires.

Toutefois, le lancement de ce projet eut pour effet de stopper les velléités d’Enterprise System d’introduire un système haut de gamme en OEM.

L’abandon du 620, le manque de moyens et la lassitude eurent raison de ce projet. Notons que l’acquisition de Sequent par IBM permit à IBM d’accéder à la technologie CC-NUMA (surtout sur les aspects logiciels) ; il faut toutefois reconnaître que Sequent était bien plus avancé que Bull dans le domaine avec, notamment quelques systèmes NUMA-Q livrés (systèmes qui avaient toutefois une performance déplorable).

Toujours dans le domaine du High End Unix, il faut mentionner les contacts que nous eûmes avec NEC. Comme on vient de l’évoquer, NEC avait analysé plusieurs hypothèses pour un haut de gamme Unix avec notamment Sequent et HP pour annoncer, à la surprise de Bull, un accord OEM avec HP. Un groupe de travail commun Bull/NEC (René Chevance, Jean Papadopoulo, Jean-Jacques Pairault et Gérard Roucairol du côté de Bull) fut mis en place pour rechercher une convergence entre les projets respectifs. Le premier meeting eut lieu le 10 septembre 1995. Ces contacts ne se déroulaient pas dans un excellent climat : les luttes politiques internes à Bull avaient (d’une certaine façon) été « exportées » chez NEC, le mode de travail des japonais était aux antipodes du notre, il est très difficile pour les Japonais de répondre « Non » et nous devions nous adapter à leur rythme particulièrement lent,….
NEC avait une vision très orientée sur son marché local pour l’Unix haut de gamme. L’accord faisait sens car HP avait une position faible au Japon (ce qui était loin d’être le cas en Europe sans parler des US). NEC prétendait que HP-UX allait devenir le standard Unix haut de gamme au détriment de AIX et de Solaris (entre autres). Ainsi, suite à une requête de NEC, nous avons demandé à Jacques Talbot de faire une évaluation du coût et du délai de portage de HP/UX sur Power PC. Fort heureusement, cette hérésie (de l’ordre de 100 Hommes/an !) n’a pas dépassé le stade de l’évaluation … Un autre volet de cette discussion surréaliste de convergence a été ISM (ensuite appelé Open Master) versus OpenView (d’HP).
Les systèmes Fault Tolerant

En décembre 1989, on me demanda de mener une investigation sur les systèmes Fault Tolerant (une de plus !). L’un des objectifs était la satisfaction des marchés demandant ce type de système (Telco en particulier). Compte tenu que l’épisode TRIX (voir paragraphe spécifique) n’avait pas été couronné de succès, que le cluster n’était pas encore à la mode (il le devint avec HACMP) et que l’on souhaitait investir un minimum de ressources de développement sur une telle offre, la recherche d’une solution OEM s’imposait.
C’est ainsi que l’investigation fut menée autour des systèmes proposés par IMP, Sequoia et Tandem. Stratus ne faisait pas de cette liste, ceci peut paraître surprenant car Stratus était, avec Tandem, l’un des deux leaders sur le marché des systèmes Fault Tolerant. Autant au début des années 80, il était difficile de considérer un partenariat avec Stratus car celui-ci était déjà engagé par des accords OEM avec IBM d’une part et Logabax/Olivetti d’autre part. Je n’ai pas de souvenir précis des raisons qui avaient conduit à exclure Stratus de la liste des partenaires potentiels.

IMP était une petite société anglaise qui avait repris la technologie développée par Parallel Systems (voir le paragraphe sur la recherche d’un partenaire Unix). IMP avait développé un système Fault Tolerant de type hardware fondé sur le doublement de la fonction processeur/mémoire (exécutant le même ensemble de processus) et la création de points de rendez-vous (e.g. demande d’entrée-sortie) au cours desquels l’état des deux sous-ensembles processeur/mémoire est comparé. En cas de non-identité, on détermine quel est le sous-ensemble fautif et le traitement continue avec l’autre sous-ensemble. Voici expliqué très schématiquement le mode de fonctionnement, je dois dire que je n’ai jamais pu obtenir d’explication convaincante sur la façon de déterminer quel est le sous-ensemble fautif. Le système IMP n’avait pas réalisé une percée sur le marché, très restreint d’ailleurs, des systèmes Fault Tolerant. La technologie a été acquise par Motorola et par Sun (offre NetraFT pour le marché des Telco). Cette offre présentait peu d’intérêt pour Bull.

Sequoia avait développé un système Fault Tolerant fondé sur une approche matérielle assez originale. Le système était un SMP sur base Motorola 680x0.
Le principe était fondé sur un principe inspiré du transactionnel mais appliqué au niveau du matériel : lorsqu’un processus débutait son exécution, toutes les écritures mémoire étaient faîtes dans le cache (la mémoire n’était pas mise à jour). L’image mémoire était enregistrée en double (deux modules mémoire indépendants). Lorsque le processus cessait son exécution (quantum de temps écoulé, demande d’entrée-sortie, cache plein,…), les mises à jour des images mémoire étaient faites à partir des blocs modifiés du cache. En cas de défaillance d’un processeur avant l’écriture des deux images, l’exécution du processus pouvait être reprise à partir de l’image mémoire qui représentait l’état du processus au début de sa tranche d’exécution. Voici expliqué, très schématiquement, le mode de fonctionnement. Il faut reconnaître que le matériel datait fortement : Sequoia avait mis beaucoup de temps à développer son logiciel (système transactionnel propriétaire) qu’il avait dû ensuite compléter par une interface compatible Unix (la loi de Hofstadter avait encore frappé). Ron Pampel poussait fortement à un accord avec Sequoia (le CEO de Sequoia, Grabe Fusco, était un ami de Ron Pampel). Hormis l’intérêt que Ron Pampel pouvait porter à Sequoia, ce système n’était pas attractif compte tenu de la vétusté de son matériel d’une part et du peu de ressources que l’état financier de Sequoia permettait de mettre en place pour le renouvellement de son système.

En parallèle avec ses systèmes transactionnels à continuité de service (Systèmes connus ensuite sous le nom d’Himalaya avec le système d’exploitation Guardian) et dont la tolérance aux fautes était fondée sur une approche de type cluster, Tandem avait lancé le développement du S2 : un système Fault Tolerant Unix fondé sur MIPS et dont la tolérance aux fautes était fondée sur approche matérielle (système développé à Austin alors que les systèmes propriétaires étaient développés en Californie). Un accord avec Tandem sur les systèmes transactionnels étant exclu a priori pour des raisons évidentes de télescopage avec les lignes GCOS 7 et 8, notre analyse porta sur le système S2. S2 était un système logiquement monoprocesseur, de fait les processus étaient exécutés par trois processeurs et un vote majoritaire périodique (sur des événements tels que demande d’écriture en mémoire) permettait de contrôler le bon fonctionnement de l’ensemble et d’assurer la continuité de service en écartant le processeur divergent (i.e. dont les résultats n’étaient pas conformes à celui fourni par les deux autres). Le défaut majeur de ce système était son manque de scalabilité : système monoprocesseur uniquement, la seule possibilité étant d’attendre l’intégration d’un microprocesseur plus performant (fréquence ou nouvelle génération). Les difficultés de mise au point de ce type de système font qu’il y a toujours un retard important entre l’introduction d’un processeur sur un système Fault Tolerant par rapport à son introduction sur un système classique.

Nous avons passé, rapidement, en revue les aspects techniques de ces différents systèmes et aucun d’entre eux ne se révélait très attractif. Un exercice de rentabilité montra que la rentabilité était problématique (ce qui était évident a priori pour ce type de système mais il fallait faire l’exercice au moins pour calmer l’ardeur de Ron Pampel à promouvoir Sequoia) et cette idée fut abandonnée.

Notons aussi que les solutions (à la continuité de service) au niveau du matériel ne permettent que de résister aux défaillances du matériel qui ne représentent qu’une faible partie (moins de 20%) des causes des défaillances.

Note : L’analyse des différentes solutions pour satisfaire les besoins d’un marché dont on sait que la rentabilité ne sera pas au rendez-vous peut sembler une perte de temps et d’argent. Toutefois, de telles analyses ont des effets de bord très intéressants : connaissance des projets en cours, évaluation des capacités de concurrents potentiels, informations sur les marchés,…. Toutefois, pour que les retombées soient exploitables, il est indispensable que les rapports circonstanciés (i.e. pas la diffusion des copies des présentations) soient établis et diffusés systématiquement après chaque meeting. Ce qui était loin d’être le cas général mais le management était, dans ce domaine, particulièrement laxiste tant pour lui-même que pour ses subordonnés…..

Toujours sur ce sujet, je suis entré en contact en mars 1991 avec Tolerance Computer, startup française créée par François Gernelle, créateur du premier PC chez Micral. La première mouture du projet incluait le développement de matériel sur base Intel et utilisant une liaison série rapide (100 Mbits/s sur le chip Taxi d’AMD). Le principe était la duplication des processus et la synchronisation lors des appels systèmes. Le système était Chorus MIX avec une interface compatible SCO (pour l’accès aux applications SCO). On rencontre ici la même difficulté qu’avec le système d’origine IMP : la détermination du processus fautif. Devant les difficultés de développement (le premier planning était particulier optimiste), le projet évolua vers l’utilisation de PCs après l’abandon du matériel « propriétaire ». Cette société rencontrait des difficultés structurelles et nous ne poursuivîmes pas cette hypothèse. Tolerance Computer acheva son développement et j’ai eu l’opportunité de voir une démonstration du système lors du Fault Tolerant Computing Symposium de Toulouse en juin 1993.

Toujours sur ce sujet, il faut évoquer la mémoire stable. Ce concept avait été élaboré par Jean-Pierre et Michel Banâtre de l’lRISA (branche rennaise de l’INRIA). Les frères Banâtre avaient développé un système à continuité de service pour les salles de marché (agricole). Ce système, fort justement appelé Enchères en raison de sa destination première, était fondé sur le concept d’une mémoire stable réalisée au niveau du matériel. Via une mémoire double et un mécanisme de validation de type transactionnel, on était assuré de la cohérence du contenu de cette mémoire. La mémoire était en double accès entre deux systèmes. Ce projet nous fut présenté à plusieurs reprises (dès avril 1985); nous n’avions pas d’intérêt pour cette approche car elle impliquait un matériel spécifique et surtout de structurer le système sous forme de transactions. Les équipes de l’IRISA développèrent différentes versions de leur système en fonction de la stratégie Bull du moment mais, lorsqu’ils avaient achevé leur développement, Bull avait changé de stratégie produit…. Devant ce constat, on décida, en mars 1993, de mettre en place un comité de pilotage dont j’assurai la direction. Au même moment, l’équipe projet avait obtenu un contrat du CNET pour le développement d’un système à continuité de service pour l’annuaire téléphonique. Le CNET avait imposé une double contrainte : utilisation de matériel et de logiciel standard. Ces travaux sont à l’origine de la boîte à outils Safekit de Bull. Sur la base de cette technologie, des produits à continuité de service ont été développés par Bull tels qu’un Firewall.

Toujours sur ce sujet, on ne peut pas manquer de citer Max/Delta 4. Ce projet avait initié par Pascal Martin à la SEMS. Différents laboratoires (dont le LAAS de Toulouse) étaient associés à ce projet dans le cadre de financements Esprit. Pascal Martin avait un côté « locomotive » fort sympathique mais le réalisme manquait parfois. Le projet initial utilisait un réseau Token Ring modifié. Le principe était une diffusion « multicast » fiable. Il y eut une revue Delta 4 en mai 1985 à laquelle étaient invitées toutes les lignes de produit. Les différents représentants ne voyaient aucune difficulté à ce que la SEMS développe ce produit mais leur position changea totalement lorsqu’il furent informés (par Michel Véran si ma mémoire est bonne) qu’il fallait que leurs systèmes soient modifiés pour pouvoir profiter des bénéfices de ce projet. Le projet continua néanmoins mais toujours sur financement externe. Pascal Martin fut appelé à d’autres fonctions et le projet fut repris par Marc Chérèque. Devant la nécessité de prendre une décision sur le devenir de ce projet, on me demanda de conduire, en avril 1991, une revue chargée de préparer une recommandation. Avec Marc Chérèque, le projet reposait sur des hypothèses plus solides. Notre recommandation fut de développer un kit à base de carte réseau local PC et d’outils logiciels pour la réalisation d’applications industrielles à continuité de service. Malgré nos différentes actions d’explication, l’entité du réseau commercial en charge de l’industrie n’avait aucune envie d’investir et le projet s’arrêta.

Bien que le sujet ne s’apparente pas totalement à la continuité de service, je mentionnerai les contacts avec Encore sur la mémoire réflective. Nous eûmes un premier meeting le 13 novembre 1991. Le principe était une mémoire logiquement partagée reposant sur un mécanisme réplication des mises à jour entre des mémoires (physiques) appartenant à des systèmes interconnectés par un réseau local. Ceci n’est pas particulièrement adapté à la continuité de service car, si un système « déraille », on ne sait pas ce qu’il a pu déposer dans la mémoire partagée. Dans ce cas, la prudence veut de causer l’arrêt complet du système. Digital avait acquis la licence de ce cette technologie qui ne connut pas de percée sur le marché.

Les machines massivement parallèles

Durant l’été 1991, avec Roland Marbot et Jacques Péping, nous fîmes une note présentant le résultat de nos réflexions sur les besoins en capacité de traitement pour de nouvelles applications (telles queles traitements liés à l’imagerie médicale, la recherche dans les documents multimédia,….). Cette analyse concluait au besoin de systèmes de grande puissance de traitement hors du champ atteignable pour des architectures SMP classiques. Pour satisfaire ces nouveaux besoins, les architectures MPP (Machines Massivement Parallèles) semblaient une voie prometteuse. L’engouement sur ce type d’architecture semblait confirmer l’analyse préliminaire. Notons que Bull avait introduit Teradata (vers 1986) qui étaient des systèmes MPP dédiés au décisionnel et connectés aux mainframes.
Je pris en charge, vers fin 1991, une analyse des possibilités de partenariat autour des MPPs.systèmes avec Brian Parker (de la Direction Stratégie de Michel Bloch).
Nous eûmes un certain nombre de meetings, nous allons brièvement passer en revue les différents fournisseurs potentiels :

Le SP d’IBM est l’un des rares MPPs qui ait rencontré un succès commercial. Nous avons eu un meeting à Kingston en février 1993. Le contraste entre les équipes Unix d’Austin et celles de Kingston était frappante, notre réflexion (avec Carlos Milchberg et Xavier Stéfani) en entrant dans la salle de réunion et en voyant nos interlocuteurs a été unanime « Ça sent le mainframe ! ». Témoin de cet état d’esprit, la taille du matériel d’interconnexion placé au bas des armoires du SP ; interrogés sur le prix de cet équipement ($75000), la réponse fut très simple : « le prix est élevé non seulement en fonction du matériel mis en œuvre mais aussi par ce qu’il faut que le client apprécie la valeur de ce qu’il achète ». Didier Breton était favorable à l’introduction de ce système ;
ICL avait développé, dans le cadre d’un contrat Esprit (auquel Bull participait mais uniquement pour des aspects logiciels) un système massivement parallèle de nom de code Gold Rush sur base SPARC. J’ai rencontré cette équipe en décembre 1992. Compte tenu de l’éloignement de nos filières technologiques, l’intégration de ce produit aurait été problématique ;
Intel avait développé un système MPP (Paragon) initialement sur la base du 860 et ensuite sur la base x86. Le meeting eut lieu en octobre 1992. L’engagement d’Intel ne semblait pas très affirmé sur ce type de produit. De fait, les équipes de Paragon ont été réorientées vers les serveurs « entreprise » (Enterprise Server Group) ;
KSR (Kendall Square Research) avait développé un système multiprocesseur symétrique fondé sur l’architecture COMA (Cache Only Memory Architecture). La visite à KSR eut lieu en octobre 1992 (en compagnie de Jean-Jacques Pairault qui s’était intéressé à l’architecture COMA dans le cadre du projet VLMP). KSR avait développé entièrement son matériel y compris son propre processeur. Rappelons brièvement que dans l’architecture COMA, le système est composé par la fédération de groupes processeurs/mémoire, chacune des mémoires de ces groupes étant considérée comme un cache. L’information migre de groupe en groupe en fonction des besoins. Le système avait beaucoup d’originalité, y compris du point de vue du packaging. Un système a été acquis par l’INRIA. Le pari technologique était risqué, comme pour toute société qui cherche à innover sur tous les fronts en même temps, et KSR a rapidement disparu ;
Maspar avait développé un système fondé sur le principe SIMD (Single Instruction Multiple Data). Nous les rencontrâmes en septembre 1992. Cette société a rapidement disparu ;
Meiko était une société anglaise qui avait développé un système massivement parallèle à base de SPARC. Le support des bases de données était annoncé comme un objectif majeur. Ma première visite eut lieu en novembre 1992. Cette filière n’a pas été exploitée en raison de l’éloignement des bases technologiques et de la viabilité de cette société. Notons toutefois qu’il en est quand même resté la partie réseau d’interconnexion : Quadrics qui réunit les restes de Meiko est le leader incontesté pour l’interconnexion de systèmes dans le TOP500 ;
Ncube, rencontré en octobre 1992, était une société américaine qui avait développé un système propriétaire (y compris le processeur) utilisant une topologie hypercube pour le réseau d’interconnexion. Cette société, en partenariat avec Oracle, s’était lancée sur la voie du vidéo-serveur et a disparu ensuite ;
Parsytec était une société allemande basée à Aix la Chapelle qui avait développé un système MPP fondé sur le Transputer d’INMOS. Le manque de crédibilité d’INMOS ne plaidait en faveur de cette filière. Parsytec a ensuite développé un système fondé sur PowerPC et utilisant la liaison ISL (licence achetée à Bull) ;
Pyramid, société californienne qui fut ensuite rachetée par SNI, avait en projet une machine massivement parallèle de nom de code Meshline. J’ai eu un premier contact avec ce projet lors d’une téléconférence, en octobre 1992 depuis Phoenix en compagnie de Charlie Clingen, avec Ross Bott (architecte de Pyramid), contact qui fut suivi d’une visite en juillet 1993. Le système avait des nœuds mono-processeur et était fondé sur MIPS R4000 ;
Teradata (j’ai conservé le nom d’origine car la société est passée entre les mains d’AT&T et puis de NCR). Teradata était bien connue de Bull qui avait des systèmes Teradata en connexion avec les GCOS7 et les GCOS8. J’ai visité Teradata en octobre 1992. A cette époque, Teradata évoluait vers des solutions à base de nœuds standard (des serveurs quadriprocesseurs à base Intel de NCR) et le système Unix. Restait bien évidemment en exploitation le SGBD de Teradata. Le système avait toujours le même positionnement en serveur pour le décisionnel (la performance en transactionnel n’était pas le point fort de Teradata);
Thinking Machine était un des pionniers du MPP avec la Connection Machine. La santé financière de cette société n’était pas très florissante, je n’ai eu des contacts que lors d’expositions Unix. Cette société a abandonné la commercialisation de systèmes et s’était orientée vers le logiciel.

Parallèlement à cette analyse, la « mousse » était retombée sur les MPP. Les perspectives de marché nous ont conduit à abandonner cette voie.
Fame

En février 1996, les équipes de développement HPDA (Hardware Development Paris Angers) manifestèrent avec une certaine force auprès de la direction générale de Bull leur souhait de connaître leur devenir à la fin du développement de Jupiter (système haut de gamme DPS9000 en technologie CMOS et dans le cadre d’un accord OEM avec NEC).
Parallèlement à la recherche d’activités potentielles, on fit une évaluation des compétences des équipes de HDPA au moyen d’interviews.
Comme rien de précis n’était réellement prévu, Khaled Marrei (qui dirigeait le regroupement de Enterprise Systems et de Open Systems and Software) lança un groupe de travail pour identifier et évaluer les différentes activités potentielles. Ce groupe de travail comprenait : Pascale Charrier, René Chevance, Yves Fantino, Jean-Jacques Pairault, Jean-Pierre Tual ainsi qu’un consultant extérieur Michel Ortonne. Jean Papadopoulo, qui était en vacances au moment du lancement du groupe de travail, nous rejoignit à son retour.
Parmi les 4 groupes de travail créés, l’un de ces groupes présidé par Jean Papadopoulo (avec Michel Hennette, Michel Philonenko, Jean Furelaud) a recommandé un développement de machine reconfigurable en dimension cluster et SMP, utilisant la techno ISL.
Je ne traiterai pas ici des autres hypothèses d’activité pour HDPA car c’est une autre histoire.

Il convient de mentionner que l’hypothèse d’un High End sur base Intel 64 était un sujet sur lequel nous avions commencé à réfléchir avec Jean-Jacques Pairault, Jean Papadopoulo et Gérard Roucairol.
Ensuite Michel Guillemet et Gérard Roucairol ont demandé l’étude de HENT (High End NT) à base Intel, le groupe de travail formé pour cela comportait Jean-François Autechaud, René Chevance, Sylvie Lesmane, Jean-Paul Mesnage, Jean-Jacques Pairault et Jean Papadopoulo. Cette étude a repris l’idée du réseau d’interconnexion reconfigurable.

Nous avons visité Microsoft pour NT avec NEC en juillet 1996.
Nous avons fait (avec Jean-Jacques Pairault et Gérard Roucairol) une mission chez Intel à Portland (Oregon) en novembre 1997 au cours de laquelle nous avons passé en revue les possibilités offertes par la première génération de processeurs IA-64 (nom commercial Itanium et nom de code Merced). Intel était très favorable à voir une partie de notre activité s’orienter vers IA-64. Nous y avions rencontré Jim Allchine responsable de l’activité Enterprise Systems. Ce meeting s’était déroulé dans un excellent climat, Jim Allchine exposant le souhait de Microsoft d’adresser les besoins de ce marché tout en reconnaissant humblement que la démarche serait longue et qu’il y avait beaucoup à apprendre de ceux dont le c’était métier. Lors de ce meeting, Microsoft nous fit part de son peu d’empressement à maintenir le support de Power PC par NT (ce qui était une indication claire sur ce qui allait arriver). A notre retour, notre alerte resta sans écho (comme le dit le proverbe : « il n’est pire sourd que celui qui ne veut pas entendre »).

Pour faire avancer cette idée de projet, il a fallu biaiser car nous étions en présence de l’équation suivante Unix = Power PC et Power PC = IBM, donc en dehors d’IBM point de salut. Avec le sens de la dissimulation et la détermination qui peuvent caractériser ceux qui veulent faire avancer le schmilblic, nous proposâmes le projet d’un système NT à 64 processeurs sachant, qu’à ce moment là, NT ne supportait guère que 4 processeurs…. Nous avions donc une équation NT = Intel. Il convient de noter qu’Alain Couder et Didier Breton poussaient aux développements et au portage de logiciels Bull sur NT/Power PC (notamment sur le monoprocesseur Estrella d’origine Motorola). De fait, une enquête interne avait montré que tous les développements et les portages sur NT étaient faits sur base Intel….
L’annonce de l’alliance entre IBM et SCO (Santa Cruz Operation) pour l’élaboration d’une version ouverte (aux OEMs) d’AIX sur IA-64 permit de faire évoluer en douceur le projet vers un haut de gamme Unix. L’alliance IBM/SCO fit long feu, la version AIX 5L adaptée à IA-64 se révéla ensuite être réservée à IBM et aux clients OEM pour les systèmes d’origine IBM. Mais entre temps, les esprits avaient évolué, des responsables de Bull avaient changé, le « coup » était parti et Linux s’était imposé (voir le paragraphe spécifique),….
Avec FAME (Flexible Architecture for Multiple Environments), nous avions l’idée de développer un système flexible permettant de supporter sur la même base matérielle des SMP et des clusters de SMP. De cette façon, il est possible de bâtir une configuration de système qui s’adapte aux besoins des clients (e.g. fédération de SMP pour supporter les serveurs d’application et cluster de SMP pour supporter le SGBD et assurer ainsi la haute disponibilité). Du point de vue de l’architecture, cela suppose que l’interconnexion entre les modules (SMP de base, fondation du système) puisse supporter de façon sélective un protocole de cohérence de cache (à la CC-NUMA) et un mode de dialogue par message ou DMA (Dynamic Memory Access).
Différentes possibilités de coopération (partage des coûts de développement des chips nécessaires au support de l’architecture) furent explorées. Mais tout ceci est trop récent pour être relaté ici.
La première version du système a été annoncée en 2003 sous le nom de Novascale.
Linux

En 1997, l’idée Linux commençait à faire son chemin. Quelques investigations et quelques expérimentations avaient déjà été menées au sein du Groupe sur des initiatives plus ou moins personnelles.
J’ai émis, en juillet 1998, une petite note pour éveiller l’attention du management sur Linux en insistant sur l’économie que ce type de logiciel (de très faible coût de licence) permettait de réaliser pour des systèmes « embarqués » tels que des Fire Walls, des produits de communication,…
La mayonnaise prit assez rapidement et des actions furent entreprises : présence commerciale, offres de service autour de Linux, etc.

Miscellanées

Unix à base Intel

Bien que jusque dans la seconde moitié des années 90, le sujet Unix sur base Intel ait été considéré (chez Bull) comme tabou, nous avons entrepris avec Jacques Péping, en novembre 1985, une investigation sur un serveur à base Intel 386 autour de Multibus II. Cette étude montra très rapidement, comme il était prévisible, que le système n’était pas compétitif en termes de prix.

De la difficulté d’introduire une nouvelle famille de produits

Nous avons déjà évoqué, dans ce document, les difficultés d’introduction d’une nouvelle famille de produits (et pas uniquement chez Bull) dans un corps commercial peu ou pas préparé. Deux exemples me semblent significatifs. Le premier est PERQ (au début des années 80). PERQ était une station de travail étroitement inspirée des travaux de XEROX sur le STAR (l’inspirateur de nos stations de travail) réalisé sur technologie 680x0 (alors que XEROX utilisait des processeurs « propriétaires »). ICL avait pris une licence de distribution de PERQ. C’était un moment de divertissement et de joie, lors de salons professionnels, d’aller se faire expliquer les mérites de PERQ par les commerciaux d’ICL sur leur stand, la station étant souvent reléguée dans un coin, le stand étant largement occupé par les produits traditionnels d’ICL. Un deuxième exemple se trouve justement chez XEROX avec le Star. Au début des années 80 XEROX avait entrepris de commercialiser le Star. J’étais intéressé par l’acquisition d’un Star dans le but de faire du prototypage rapide des interfaces homme/machine en utilisant Smalltalk. L’interface étant validée, on aurait pu alors procéder au développement du produit en utilisant les outils de nos propres systèmes. Malgré des visites au stand XEROX sur plusieurs salons et des tentatives de contact, je n’ai jamais pu obtenir une proposition commerciale !

Audit SOFI2

Pas directement lié à Unix mais digne d’intérêt est l’épisode SOFI2. La CII avait développé sur base 10070/IRIS 80 un système spécifique pour les douanes. SOFI2 était appelé à remplacer et à étendre la portée de ces systèmes vieillissants. Le contrat avait été préparé par la SEMS (François Michel) avant le regroupement avec Bull. Dans ce contrat, Copernique était le sous-traitant désigné de Bull et se faisait financer le développement d’une machine base de données : le dorsal. L’architecture était composée de serveurs d’application (DPS6000 de Bull) et de machines Copernique en serveur de bases de données. Le logiciel d’application était développé par la SG2. Pour corser l’affaire, il était impératif que le système soit opérationnel à une date précise fixée par un traité européen (i.e. absence totale de flexibilité sur la date de livraison). Les équipes de Bull (Jean-Claude Brialy du côté technique) se sont émues des retards potentiels et ont donc demandé un audit. Le bureau était composé de Bernard Bastie (Chairman), René Chevance et Pierre Rigogne. Après une prise de contact global, nous entreprîmes une analyse détaillée du projet de Copernique. Les équipes de Copernique, bien que peu rompues à l’exercice de la revue ou de l’audit, jouèrent parfaitement le jeu.
L’audit de la partie application (SG2) ne faisait pas partie de notre périmètre, ce que je regrette car d’après ce que j’en ai appris durant notre audit, cela méritait le détour.
Au niveau du plan projet, il y avait une étape fatidique –qui était déjà passée- appelée le « point de non-retour » ou PNR. A une certaine date, on devait constater l’achèvement d’un certain nombre d’éléments et, décider alors de la poursuite du projet. J’avais trouvé ce concept très intéressant mais sa matérialisation dans le projet était beaucoup moins glorieuse : on avait bricolé la définition du PNR (que plus personne n’appelait le point de non-retour mais simplement le PNR, tout un symbole !) afin que le projet puisse continuer. Cette analyse s’étendit sur quelques semaines. Du point de vue technique, la machine supportait le navigationnel et le décisionnel sur les mêmes données. Le système était un mélange d’architecture Mitra (en raison de la récupération de logiciel d’origine Mitra) et de 68020. Après d’âpres discussions au sein du bureau, la conclusion de l’audit fut sans appel, les premiers mots de Bernard Bastie lors de la présentation furent « Tous les ingrédients d’un clash monumental nous semblent réunies ». Le contrat fut dénoncé aux torts de la SG2 le 5 décembre 1986 et une solution de remplacement sur base de systèmes classiques fut développée.

Un exemple du jeu habituel

En juillet 1986, il y eut, à l’instigation de la Stratégie Groupe, une demande de convergence entre TG2 et Libra (pas de gamme DPS7000). Le groupe de travail était animé par le Cabinet Bain, sous-traitant familier de la Stratégie Groupe ; en l’espèce il n’est pas faux de dire que les consultants de Bain ne brillaient pas par leurs compétences mais qu’ils savaient utiliser le Power Point du moment. Ces consultants reprochèrent au TG2 de na pas être fondé sur Multibus II, stratégie du Groupe Bull (alors que la direction de Bull nous avait demandé d’abandonner le projet sur Multibus II pour une synergie avec la SEMS autour du SM Bus). L’une des hypothèses était de réutiliser le packaging de Libra pour TG2. Cette affaire amusa le terrain pendant quelques semaines puis tomba dans l’oubli en particulier lorsque nous renversâmes la proposition : utiliser le packaging TG2 pour Libra. Ceci est une illustration de la petite guerre à laquelle se livraient des Lignes de Produits, guerre souvent attisée par la Stratégie Groupe. Beaucoup de temps et d’énergie ont été dépensés dans ces luttes fratricides tandis que la concurrence ne se gênait pas pour avancer (i.e. à quoi servait de freiner un projet Unix chez Bull alors que des concurrents étaient présents sur le marché et sur le parc de Bull). Là encore, le proverbe Shadock déjà cité trouve son illustration. Tout le jeu consistait à n’y passer que le temps que cela méritait et à former un écran suffisamment opaque pour isoler les équipes de développement.

Quelques bribes

En décembre 1986, nous eûmes un premier contact avec Chorus : startup de l’INRIA qui avait développé un système Unix fondé sur un micro-noyau. A chacun de nos contacts avec Chorus, nos hypothèses produit avaient changé (System V, RiscOS de MIPS, OSF, AIX) et le constat était toujours le même : ne maîtrisant pas notre propre système d’exploitation, nous ne pouvions pas intégrer Chorus sous peine de retard inadmissibles. De plus le fait de reposer sur un micro-noyau ne présente aucun avantage si l’on exploite pas les possibilités de distribution : le seul gain est un peu plus d’overhead !

En avril 1987, nous entrâmes en contact avec Edge, société basée à Phoenix et qui avait développé un processeur compatible 68020 en technologie ECL. C’était une solution potentielle pour le haut de gamme. Edge nous prêta une machine à Massy installée dans le bureau de Francis Couppié et Jean-Pierre Goursaud et sur laquelle ils firent des mesures (les mesures eurent lieu en juillet et ils purent ainsi constater que la technologie ECL dissipait beaucoup….). La machine n’était pas multiprocesseur et l’avenir de la société paraissait incertain.

Avec le GIE Emeraude, nous eûmes aussi un grand moment. Jean-Pierre Onimus vint nous demander, en juin 1987, de supporter Emeraude sur DPX2000-SPS7. Emeraude était un environnement pour le développement du logiciel développé dans le cadre du projet européen PCTE. Nous n’avions pas de prévention contre Emeraude mais son portage demandait des modifications du noyau de SPIX (un comble pour un environnement de développement fait par des grands spécialistes du génie logiciel donc connaissant a priori les contraintes de portabilité !). Notre position fut parfaitement nette : pas de modifications de SPIX, c’est au GIE de modifier Emeraude pour le rendre portable ! J’ignore la suite qui fut donnée à cette affaire.

DCM (Distributed Computing Model) fut aussi un grand moment dans l’histoire de Bull. En ce qui me concerne, j’eus une première réunion sur le sujet avec Georges Lepicard (Stratégie Groupe) en octobre 1987. IBM venait d’annoncer SAA (System Application Architecture) à grand renfort de trompettes et autres instruments à percussion. L’objectif technique de SAA était d’assurer la coopération et la portabilité des applications entre ses différentes lignes de produits. Il convient de noter que la réalisation de cet objectif entraînait des développements très importants et, à ma connaissance, le programme ne se matérialisa guère chez IBM.
En réaction à SAA, Bull lança un projet connu initialement sous le nom de BAA (Bull Application Architecture).
C’était aussi un moment où le message stratégique de Bull était du style « on va vers des systèmes « ouverts » mais ne vous inquiétez pas : rien ne change pour les produits que vous utilisez, tout continue ». Une petite anecdote à ce sujet, je me souviens d’un meeting assez surréaliste qui s’est tenu Avenue Malakoff mais dont je n’ai pas réussi à retrouver la trace dans mes notes. L’objectif de ce meeting était de proposer un discours marketing à partir de la stratégie du Groupe. Des représentants des différentes lignes de produits participaient à ce meeting organisé par Philippe Diebold (si ma mémoire est bonne). Un représentant de la Stratégie Groupe devait venir nous rappeler la stratégie du groupe. Il arriva tardivement et ne resta qu’un instant pour nous tenir le discours habituel : « vous connaissez tous la stratégie du Groupe et je ne la rappellerais pas, tout continue etc... ». Nous étions en présence d’un discours marketing plutôt que d’une stratégie, notre tâche se trouva réduite à sa plus simple expression, toutefois, selon une tradition solidement établie, on passa la fin de l’après-midi en réunion.
BAA fut ensuite désigné sous le nom de Purple Way, la raison de ce nom est pour moi mystérieuse. J’ai entendu parler de la couleur des marqueurs utilisés lors d’un meeting au cours duquel le nom du projet a été choisi ….
Avec DCE (Distributed Computing Environment) d’OSF, ce projet connut un début de matérialisation et fut baptisé DCM. Pour ma part, je n’ai jamais bien compris en quoi DCM se distinguait de DCE. La matérialisation de DCM se trouva dans quelques rares produits tels que l’impression distribuée. Je me souviens d’une présentation grandiose d’un éminent représentant de la Stratégie Groupe faîte au staff de Bull XS lors de laquelle cette personne nous démontrait les avantages de l’architecture distribuée. Pour appuyer sa démonstration, il prit l’exemple de l’impression distribuée : emporté par son élan, il n’hésita pas à affirmer que lorsque l’utilisateur demande un travail d’impression, celui-ci se moque totalement de l’endroit où se trouve l’imprimante. L’audience lui fit remarquer que c’était l’un des rares cas, dans l’informatique distribuée, où la localisation a toute son importance car il faut récupérer le papier imprimé !
DCM, après avoir agité les foules pendant quelques mois et provoqué des frais, disparut sans faire de bruit.

Super-calculateur

En janvier 1988, Jean-Pierre Bénatar (qui présidait aux destinées de Bull MTS) me demanda de faire un audit de Marie, projet de super-calculateur développé par CIMSA. Deux projets de super-calculateurs avaient été initialisés par la DRME : ISIS chez Bull et Marie à la CIMSA. CIMSA ne souhaitait plus continuer le projet et s’était tourné vers Bull pour reprendre le projet. C’est dans ce contexte que je fis, seul, cet audit « système » (un audit sur la technologie avait été fait par (prénom ?) Polonowski de la Stratégie Groupe). Le système reposait sur le postulat qu’il était possible d’extraire, au niveau de la compilation, le parallélisme des programmes. L’architecture avait quelques originalités (dont un réseau de communication entre les processeurs de type Data Flow). Sur ce projet, on mesure toute l’ambiguïté entretenue par ce type de contrat DRME : alors qu’il convenait, en bonne logique, de faire une preuve du concept, on développe un système. Si le développement de programme se déroulait sur une station de travail Unix, la CIMSA avait développé « from scratch » un compilateur Fortran alors qu’il aurait mieux valu partir d’une souche et développer seulement l’optimiseur. Par ailleurs, le projet était assez mal embarqué et ma conclusion fut négative. Le projet fut arrêté par la suite et de l’aveu même du chef de projet (rencontré ultérieurement dans le cadre d’une réunion Esprit), ce fut une bonne décision. Dans ce domaine, je ne saurais rien dire sur le projet ISIS car je n’en ai eu qu’une connaissance partielle : Claude Timsit m’avait contacté au moment de notre recherche RISC pour me proposer l’architecture processeur ISIS (partie scalaire).

OSF

Vers 1989, nous avons eu l’épisode OSF. Comme indiqué précédemment, OSF avait été créé face aux menaces potentielles que représentaient la participation financière d’AT&T dans Sun et la demande, aux US, de systèmes Unix pour les marchés d’état. L’objectif initial d’OSF était le développement d’un Unix libre de toute contrainte d’AT&T (au-delà d’une certaine version de System V). Bull était l’un des sponsors d’OSF. La base Unix initialement retenue était l’AIX d’IBM. Les adhérences entre la gestion de mémoire virtuelle de Power et AIX conduisirent OSF à s’orienter vers le système Mach, système Unix fondé sur un micro-noyau. Comme on l’a signalé au sujet de Chorus, le seul apport d’un micro-noyau, si l’on ne se sert pas des possibilités de distribution, est un peu plus d’overhead (i.e. une perte de performance).
OSF fonctionnait comme une coopérative : émission de requêtes pour technologie, choix de technologies, intégration et distribution (moyennant royalties). Comme on l’a signalé, l’alliance d’AT&T et de Sun tenait du mariage de la carpe et du lapin…. Comme il était prévisible, l’affaire OSF tourna court. Les seuls succès d’OSF n’ont pas été dans le domaine du système d’exploitation mais dans le domaine de la présentation (Motif) et d’un environnement pour système distribué (DCE). Malgré les discours enflammés de certains sponsors, les principaux d’entre eux continuaient avec leur propre Unix. Le système OSF n’a été proposé que par des constructeurs marginaux ou bien encore pour des produits marginaux chez des constructeurs plus importants.
Néanmoins, Bull enfourcha ce cheval et l’on chanta les louanges d’OSF pendant un bon moment. L’accord avec IBM rendit cette hypothèse caduque.

Professional Work Station

Dans le domaine des ratés, hélas plutôt nombreux, il est difficile de passer sous silence l’épisode PWS (Professional Work Station). Ce projet avait été initié par Ron Pampel et confié à John Robotham. C’était un PC (avec un grand écran) sous Unix offert avec un ensemble d’applications fixé. Ce produit avait une vocation interne tout autant qu’externe. Par vocation interne, on entend le souhait de Ron Pampel que les développeurs de Bull soient tous dotés d’une PWS. La vocation externe était la recherche d’un marché pour ce type de produit. J’ai participé à une IPR en juillet 1989 à Billerica. IPR un peu surréaliste car il n’y avait pas eu de CDR et un certain nombre de problèmes ont été identifiés lors de cette IPR tels que l’incapacité de l’usine d’installer le logiciel lors de la fabrication (ce qui laissait le soin à l’utilisateur de procéder à l’installation du système à base d’une quarantaine de disquettes !), le choix du bouquet d’applications est un sujet sans fin (il risque de ne convenir à personne), synchronisation des versions des applications (i.e. accepter de vivre en état d’intégration permanente et de livrer un grand nombre de mises à jour ou bien accepter d’avoir toujours un retard sur les versions des applications),… Malgré toutes les difficultés soulevées, comme Jacques Weber le souligna lors de la présentation des résultats de la revue, il était hors de question d’infléchir le programme : chasse gardée de Ron Pampel ! Les quelques PWS livrées, en interne, ont été reconverties en stations Windows ; une belle preuve de clairvoyance.
Au sujet de Ron Pampel, on peut noter que dans son action chez Bull, il tenait à prouver qu’il avait eu raison de faire ce qu’il avait tenté de faire chez Apollo (racheté et absorbé par HP). Il semble que Francis Lorentz se prêta au jeu de Ron Pampel : discuter sur le plan technique alors que la question fondamentale était beaucoup la rentabilité des activités de Bull aux US.

X-Open

En 1995, j’ai été nommé représentant de Bull au Board of Directors d’X/Open. Didier Breton m’avait clairement assigné une mission : désengager Bull de son rôle de sponsor d’X/Open (ce qui fut fait à fin 1995). Je n’ai participé qu’à un seul meeting, le 9 juin 1995, en Grande Bretagne. Rappelons qu’à cette époque Microsoft introduisait NT. Lors de ce meeting, j’ai cru assister à une pièce médiévale : personne ne mentionnait le nom du malin (le diable) mais tout le monde parlait de ses agissements à mots couverts. Bien que tout le monde craignait le malin et ses agissements, on devinait aisément que le regroupement des forces qui semblait s’opérer exploserait dès que la menace se serait éloignée ou bien que le malin ait pris possession des lieux. Bien sûr, dans ce dernier cas, les alliés d’un instant auraient fait la queue chez le malin pour lui offrir leur alliance. La seule personne ayant prononcé le nom de Microsoft était l’unique représentant d’utilisateurs (ce qui lui valut de n’être point supplicié). Plus sérieusement, ce meeting m’a semblé révélateur du monde des compétiteurs Unix : on ne s’allie qu’en présence d’un danger (e.g. lors de l’épisode Sun et AT&T, on crée OSF) et on reprend ses billes le plus vite possible dès que le danger s ‘éloigne (en ayant à supporter toutes les charges représentées par un Unix « maison » dont les coûts s’approchent de ceux d’un système « propriétaire »). L’arrivée de Linux a (provisoirement ?) changé la donne.

Cabinets de conseil

On a déjà relaté, dans ce document, l’action de cabinets de conseils et d’audit. Dresser la liste des différentes actions dont le pilotage avait été confié à ces cabinets externes serait assez fastidieux et, malheureusement, pas exhaustif car je n’en ai vécu qu’une faible partie….. Le bilan global, à mon sens, est négatif, sauf pour la santé financière de ces cabinets dont certains ont connu avec le Groupe une rente de situation.

Gestion des R&D

On doit noter la mise en œuvre, lors du rapprochement (vers 1985) entre Bull Micral, Bull Transac et Bull SEMS, d’une méthodologie proposée par Arthur D. Little. Cette méthodologie, qui fit ultérieurement l’objet d’un ouvrage tout à fait intéressant, consiste (de façon résumée) à partir d’une stratégie produit parfaitement identifiée à :

Identifier les technologies utilisées actuellement et celles qui seront nécessaires pour les futurs produits et les classifier sur deux classes de critères : courant et futur d’une part et leur nature de base, clé, émergente et prometteuse ;
Etablir le positionnement de l’entité de R&D sur ces différentes technologies : Dominante, Forte, Moyenne ou Faible
Le rapprochement des technologies et du positionnement permet déjà d’identifier les gaspillages (e.g. trop de ressources sur une technologie de base) et les lacunes (e.g. pas asqsez de ressources sur une technologie clé) ;
Dresser le portrait robot de l’entité R&D « idéale » pour le développement des produits envisagés ;
Mettre en œuvre les actions nécessaires pour évoluer de la situation vers le portrait « idéal ».

A Bull Transac, sous l’égide de Claude Boulle, nous fîmes cette démarche avec un certain sérieux. Elle ne fut que partiellement mise en œuvre dans les deux entités concernées par le rapprochement (Bull Micral et Bull SEMS). Ses résultats furent surtout utilisés pour la définition de la nouvelle organisation de la direction technique commune plus que pour la gestion des R&D. L’affaire en resta là pour un bon moment. Or, ce type d’approche, pour être pleinement profitable doit être une pratique permanente.
Au début des années 90, la stratégie Group lança le processus sur la base du livre de Arthur D. Little. La portée de l’exercice était nécessairement très limitée puisque la stratégie Groupe avait simplement omis de préciser la stratégie produit. Difficile dans ce cas de classer les technologies pour le futur, de tracer le portrait idéal des R&D et le chemin d’évolution vers ce portrait idéal… N’ayant pas manqué de signaler ce fait et la vacuité de l’exercice, je n’ai pas rencontré d’écho et l’on perdit un peu de temps à contribuer à cette opération qui s’est d’ailleurs éteinte sans effet et sans faire de bruit…

En septembre 1996, nous avons lancé avec Gérard Roucairol et Eric Bantégnie, des revues R&D. L’objectif de ces revues était de faire le point sur les différents développements en cours et de vérifier leur « alignement » avec les demandes des lignes de produits. Typiquement, une revue débutait par un exposé de la ligne de produit faisant la synthèse de ses besoins et de ces demandes. Ensuite, l’engineering présentait ses actions censées répondre aux demandes. Ces revues ont été menées en l’espace de 3 semaines. Elles ont permis de mettre en évidence un certain nombre de distorsions et de réviser et ré-orienter les budgets de R&D. Cette expérience n’a malheureusement pas été reconduite.
 D. M. Richie, K. Thompson « The UNIX Time-Sharing System » CACM vol.17 pp 365-375 July 1974
 Billerica était un centre de développement à l’origine d’Honeywell situé dans la banlieue de Boston. Par le jeu des rachats, il devint centre de développement Bull. Dans les années 70 et 80, son activité principale était le développement du DPS6000.
 Etait-il réellement question de prendre une décision ? En effet, il était apparu, au cours de notre étude, que la commercialisation d’un produit tel que TPO n’avait pas de justification économique avec le coût des structures commerciales de la Compagnie. En interne et sous forme de boutade, nous disions qu’il fallait faire distribuer le produit par Darty… En effet, les petits systèmes de gestion étaient vendus à l’unité ou par petites quantités et leur prix ne pouvait pas supporter les coûts de commercialisation qui existaient pour des systèmes coûteux ou encore des appareils vendus en quantité et souvent en accompagnement de systèmes importants (e.g. terminaux).
 Jean Papadopoulo proposa de porter Xenix (i.e. la version d’Unix proposée par Microsoft) car ce système disposait d’applications proches du segment de marché du DPS7. La ligne de produit n’était pas favorable au portage d’Unix (ou d’un de ses cousins), toutefois L’engineering (Philippe Radouan et Denis Attal) décida de porter Unix sur DPS7. Nous eûmes, le 5 septembre 1985, un grand meeting organisé par Georges Lepicard (Stratégie Groupe) autour des plans Unix des différentes lignes de produits du Groupe ainsi que d’Honeywell (Italie) et au cours duquel Jean Papadopoulo nous fît une présentation des plans Unix de la ligne DPS7 (ce meeting est relaté plus loin au sujet du rapprochement avec Honeywell). De mémoire, l’aspect intégration avec le DPS7 notamment au niveau du systèmes de fichiers (i.e. partage de fichiers « plats » entre les deux univers) n’était guère développé. Jean Papdopoulo, pour sa part, rejoignit peu après la ligne de produits Unix chez Bull Transac.
 Je préfère utiliser le terme « standard » pour désigner les systèmes tels que Unix/Linux et Windows plutôt que le terme « ouvert », le terme standard faisant ici référence à la situation d’un système sur le marché (et par voie de conséquence à des outils et à des compétences largement disponibles) et non à sa « labelisation » par un quelconque organisme. En effet, l’une des caractéristiques définissant un système ouvert est l’existence de plusieurs fournisseurs. Ce n’est évidemment pas le cas de Windows. A titre de boutade, on pourrait même dire qu’il y a trop de fournisseurs du côté d’Unix et assimilés et pas assez du côté de Windows !
 J’avais rédigé, suite à ce séminaire, une analyse critique du 286 concluant qu’il ne fallait considérer le 286 que dans son mode 8086 (donc comme un successeur plus rapide du 8086) et surtout ne pas utiliser son mode natif. Il semble que, sur ce point, l’histoire m’a donné raison puisque les systèmes d’exploitation fonctionnant sur processeurs IA-32 (et ayant rencontré une large audience) n’ont pas utilisé le mode d’adressage natif 286 mais un mode « plat » (pas de segmentation, deux anneaux uniquement et la pagination qui fut introduite avec le 386). Les difficultés architecturales liées à la segmentation de longueur variable étaient encore amplifiées par l’absence de pagination. Comme j’ai pu le remarquer en plusieurs occasions : la segmentation de longueur variable fonctionne d’autant mieux que tous les segments ont la même longueur !
 Tout comme pour le 286, j’avais rédigé une analyse critique de cette architecture mettant en évidence les difficultés qu’il y aurait à l’utiliser. L’expérience du projet Y (voir le papier correspondant sur le site de la FEB) m’a beaucoup aidé dans la préparation de ces analyses. Plus tard, lors de discussion « hors contexte » avec des personnes ayant participé à ce projet chez Intel, celles-ci m’ont confirmé que le développement du chip était prématuré compte tenu des possibilités de la technologie et du degré de maturation de l’architecture. La raison de cette « précipitation » était qu’Intel était une société produisant des chips et que la crédibilité d’un projet passait nécessairement par là. Le 432 n’a rencontré aucun débouché.
 Lors de l’introduction du 68020, une version simplifiée du MMU a été proposée. Certains constructeurs ont développé leur propre MMU. La spécification du PMMU (Paged Memory Management Unit) du 68020 intégrait des mécanismes complexes dont l’utilité était tout à fait contestable. Dixit un ingénieur de Motorola rencontré à Austin en 1984 : « la définition de ce PMMU intègre trop d’éléments marketing » (i.e. cette caractéristique est dans l’architecture de chez xxx, nous devons donc l’avoir dans notre produit). Le 68030 corrigera ce défaut.
 Bien que l’objet de ce document ne soit pas de relater le rapprochement de Transac avec Bull, il n’est pas inutile de dire quelques mots sur la mise en œuvre du plan qualité chez Bull. Ce contact avec cette culture « qualité » de Bull fut une surprise pour le personnel de Transac. Sans nier le fait que des efforts dans le domaine de la qualité aient été nécessaires, dans les différentes entités constituant le nouveau groupe, la mise en œuvre de l’action qualité n’a pas été à la hauteur des ambitions et revêtait des aspects caricaturaux. On notera la création d’une organisation spécifique et, comme souvent dans de telles opérations, la nomination de responsables dont la réputation ne contribuait pas à asseoir la crédibilité de l’opération. Le plan de formation systématique mis en place partait d’une bonne intention mais la transposition naïve d’une formation standard d’origine anglo-saxonne passait très mal auprès des équipes. Nous eûmes droit à de grandes messes sur la qualité qui faisaient dire « qu’il suffisait de chanter la messe mais qu’il n’était pas nécessaire d’y croire ». Il était de bon ton de tapisser les couloirs de tableaux de la chasse aux CONQs (Coûts de non qualité) et aux COCs (coûts de non conformité)… L’un de mes collègues, lors de sa formation qualité obligatoire (rares sont ceux qui ont pu y échapper), avait choisi comme thème de projet « Comment vendre un plan de formation qualité bidon à un grand groupe nationalisé ?». Bien que ce thème lui semblait bien refléter le contenu du cours, ce projet de thème fut assez mal accueilli par les formateurs….
 Dans le but de répondre aux besoins de ce type, nous avions développé le concept de « grosse grappe ». Une grosse grappe était composée de plusieurs têtes de grappe (TG1) supportant chacune une douzaine de postes de travail. Les TG1 étaient reliés entre eux par un réseau Ethernet. Une étude de modélisation avait été entreprise (Francis Couppié). Un modèle sous forme de réseau de files d’attente avait été défini et l’outil QNAP2/MODLINE de Simulog était utilisé pour résoudre ces réseaux de files d’attente. Cette étude avait conclu à la validité de l’approche mais, comme la configuration cible était très éloignée de celles qui avaient été observées jusqu’alors (i.e. afin d’obtenir les données nécessaires à la modélisation), il fut décidé de monter une configuration à 48 postes pour validation. Les mesures (après ajustement des paramètres des logiciels CTOS tels que le nombre de buffers pour Ethernet) ont confirmé les prédictions du modèle (à 5-10% près).
 Compte tenu de la complexité intrinsèque des logiciels de communication, encore accentuée par leur intégration dans l’univers Unix, il en a résulté une véritable usine à gaz (plumber’s nightmare pour les anglophiles). Je me souviens d’un épisode lors d’une revue de TRIX lors de laquelle Alain Berbonde fit une présentation de partie communication avec notamment un schéma d’architecture particulièrement complexe. Claude Camozzi demanda quel était le budget correspondant à cette partie et, à l’énoncé de la somme, fit la réflexion suivante : « A ce prix là, c’est un Rembrandt ! » (un tableau de Rembrandt venait d’être vendu aux enchères pour un prix pharamineux). Avec le recul du temps, le choix d’avoir les communications sous CTOS ne fut pas très judicieux : les produits de communication d’origine SEMS n’ont pas été abandonnés pour autant (multiplication des efforts de développement), la gestion complexe des deux environnements CTOS et Unix,…
 Après analyse, nous avions prévu de ne pas suivre les règles qui avaient été édictées au sein du Groupe pour le packaging matériel des systèmes avec maintenance participative tels que les cartes logiques entièrement encloses. En effet, nous considérions que l’arrivée de l’IBM PC avait changé les règles. Je me souviens d’avoir consulté les résultats d’une revue du M1C, qui allait devenir le BM30, dans laquelle un risque avait été émis car le M1C (produit compatible IBM PC) n’était pas conforme aux objectifs de la maintenance participative ! Avertis de cette belle preuve d’ouverture d’esprit, nous avions pris soin de ne pas positionner le TG2 comme un objet de type « maintenance participative ». Nous avions même inventé une terminologie spécifique avec la notion de TCRU (Trained Customer Replaceable Unit) qui impliquait, par rapport au concept de CRU identifié par Bull, un minimum de formation du client pour pouvoir procéder aux opérations d’échange.
 Avec des réseaux dédiés aux différentes lignes de produits, il y a le risque évident de concurrence interne : les commerciaux dénigrant les produits des autres réseaux (car ce sont les produits qu’ils connaissent le mieux). Résultat global, après avoir reçu les différents réseaux, le client est convaincu que tous les produits de la compagnie sont déficients.
 Bien que les multiprocesseurs symétriques fassent partie du paysage informatique depuis la fin des années 60, l’ampleur des développements nécessaires pour faire évoluer (de façon interne) Unix vers un système multiprocesseur nous avaient conduit à rechercher une solution de type cluster.
 Il m’a semblé que les contacts avec Counterpoint, qui avaient été initialisés par la SEMS me semble-t-il, tenaient plus au charme de Pauline Acker qu’à un réel intérêt technique. J’ai aussi été étonné par la propension des gens de Bull qui avaient rencontré Pauline Acker à en dire beaucoup de trop ; elle avait, en effet, une vision tout à fait précise des différents projets et de leurs difficultés. A partir de cela, elle avait élaboré une proposition de coopération dont, bien évidemment, Counterpoint était la pieere angulaire.
 Il s’agit d’une des nombreuses manifestations de la Loi de Hofstadter (Douglas Hofstadter « Escher, Gödel and Bach, An Eternal Golden Braid ») qui stipule que « les choses prennent plus de temps à faire que ce que l’on a initialement prévu, même si on a appliqué la Loi de Hofstadter». Cette loi empirique s’applique à de nombreux projets, notamment dans le développement du logiciel.
 On trouve là une illustration parfaite du proverbe Shadock qui dit que « Ce n’est parce que l’on joue à un jeu de con que l’on est obligé de se donner des règles ».
 Cette fonctionnalité était présente sur le système de Tandem dès son origine à la fin des années 1970 et sur le VaxCluster dès son introduction en 1983. Son introduction sur les clusters Unix prit beaucoup de temps puisque l’on ne la vit apparaître que vers la fin des années 90.
 QNAP avait été développé en partenariat entre la CII (Michel Véran) et l’INRIA/IRISA. Après une tentative infructueuse de commercialisation via la SEMA, une jeune pousse, Simulog, avait été créée par l’INRIA avec pour mission, entre autres, le développement et la commercialisation de cet outil. Le nom actuel du produit est MODLINE et QNAP2 est le moteur de résolution des réseaux de files d’attente au sein de ce package. Une petite anecdote concernant la commercialisation par la SEMA au début des années 80 : seules les plates-formes CII-HB étaient supportées. Jean-Louis Mansion (projet Y et puis Data Storage Machine) avait quitté, en 1980, le Groupe pour Thomson-CSF Téléphone ; adepte de la modélisation, il avait acquis, en supportant les frais de portage, auprès de la SEMA une version pour IBM MVS. Ayant aussi quitté le Groupe pour Transac Alcatel en 1980, j’avais œuvré pour l’utilisation de la modélisation au sein du groupe Alcatel. Je souhaitais mettre à la disposition des filiales l’outil QNAP sur un système IBM MVS en accès à distance. Le représentant de la SEMA me proposa de (re)payer intégralement le portage sur IBM (pour 200 KF) ! Outre l’escroquerie que représentait la facturation d’un travail déjà effectué, le prix demandé pour le portage était excessif, car pour avoir fait une génération de QNAP sur l’IRIS 80 de Louveciennes, je savais que le portage se limitait à une simple reprise du JCL ! Jean-Louis Mansion était parfaitement conscient du caractère exorbitant du prix mais la nécessité l’avait emporté. Malgré le développement de ces arguments, la SEMA ne voulut rien entendre. Lors de la fusion avec CII-HB, je pris contact avec l’équipe de Philippe de Rivet (alors responsable de l’activité performance au DPS7) et Dominique Chandéris vint réaliser le portage de QNAP sur le VAX 11/780 sous Unix installé à Massy.
 A un moment, lors de nos discussions initiales, il fut envisagé que Tolerant Systems puisse distribuer le TG2 en tant que bas de gamme d’Eternity.
 En ce qui concerne le DPS7000, je n’ai jamais compris pourquoi le logiciel du PC-console avait été développé en langage C alors q’il s’agissait, pour la quasi-totalité du logiciel, d’une application de gestion avec interface graphique et que le Visual Basic était à l’évidence le choix qui s’imposait. Est-ce là une illustration de l’ego des programmeurs système (qui considèrent qu’il y a des langages nobles et d’autres moins) ?
 Ceci avait été annoncé alors que le portage n’était pas achevé ! Voilà une belle démonstration de la façon de soigner le moral des troupes de la part du management.
 Une partie de l’équipe TRIX s’occupa de transactionnel. Les objectifs étaient pour le moins vagues. Il y eu un meeting TP avec des représentants de Bull US au cours duquel nous avons dû atteindre des sommets (à un point tel que je n’en ai pas retrouvé trace dans mes notes et que je n’ai aucun souvenir de ce qui s’y est dit !). Il faut dire que dans le nouveau groupe résultant du rachat d’Honeywell Bull, les bases de données et le TP avaient été confiés aux US. J’y ai vu une absence totale de clairvoyance de la part du management de Bull : ces logiciels étaient une part fondamentale de notre offre et on les laissait échapper pratiquement hors de tout contrôle. A titre d’illustration, les équipes en charge des bases de données se sont aventurées dans Ingres distribué (produit Diamond), ce produit ne fonctionnait pas de façon satisfaisante en cas de mise à jour. Le TP n’a guère été plus glorieux…. Nous avions amorcé, avant le rachat d’HIS, une recherche de partenariat avec Sybase (revue technique détaillée tenue en décembre 1988 et séjour de Bernard Lansac à Berkeley chez Sybase) avec pour objectif d’avoir une meilleure adaptation à nos systèmes Unix. Cette piste fut abandonnée au profit de Diamond pour les résultats que l’on connaît. Remarquons que le produit SQL/Server de Microsoft est un transfert de technologie depuis le produit de Sybase. Toujours sur ce sujet du rachat de HIS, il ne me semble pas que la direction de Bull avait une claire vision de ce qu’elle comptait en faire comme peut l’illustrer l’anecdote suivante. Avant la mise en œuvre effective de la nouvelle organisation, les principes de cette organisation avaient été publiés (les principes et non l’organisation car il aurait fallu préalablement consulter le CCE). Pour sonder le « moral des troupes », une enquête avait été diligentée auprès d’un cabinet spécialisé dans les enquêtes d’opinion. Etant le dernier entré dans ma direction, j’ai été désigné comme le « sondé ». L’entretien tourna court car la première question qui me fut posée était : « Que pensez-vous des principes de la nouvelle organisation ? » et ma réponse fut claire : « N’ayant pas été informé des marchés visés et de la stratégie du Groupe après intégration d’HIS, je ne peux rien dire de l’organisation car j’ai appris que la seule raison d’être d’une organisation doit être de mettre en œuvre une stratégie ». Il me semblait en effet que l’on prenait l’approche opposée : « On crée une organisation, en fonction de critères plus ou moins rationnels, et on verra bien ce qui va en sortir ! ». Comment pouvait-on lancer une telle enquête et oser poser de telles questions ? Il y aurait beaucoup à dire sur ce sujet, mais c’est une autre partie de l’histoire.
 Un package de compatibilité System V pour BSD 4.2 avait été porté sur TX. Toutefois, il existait quelques points durs tels que les « hard links » (pointeurs entre fichiers dans le File System) qui n’étaient pas supportés dans TX. Les limitations dans la compatibilité avec System V étaient l’un des chevaux de bataille des entités opposées à TRIX.
 Les primitives Unix d’accès aux fichiers avaient été étendues pour intégrer la dimension transactionnelle. La difficulté était qu’il n’y avait pas d’applications utilisant ces primitives et que les sociétés développant des applications n’étaient pas attirées vers de telles interfaces non-standard pour un système n’ayant qu’un faible potentiel de diffusion. Comme le montrera l’évolution de l’industrie dans le domaines des systèmes standards, c’est la dimension SGBD relationnel qui prit le pas sur les organisations traditionnelles.
 Ce terme avait été choisi à dessein (et non sans perversité compte tenu des bagarres internes), il indique que l’ajout d’un nœud au cluster augmente la puissance globale de traitement. Implicitement, certains auditeurs en déduisaient que la croissance était linéaire, et comme toute bonne droite qui se respecte, la pente ne pouvait être que de 1 ! Comme l’on montré des analyses ultérieures, pour les clusters, la croissance peut au mieux être linéaire dans certains contextes applicatifs (e.g. TPC-C) mais la pente est loin d’être 1 mais elle est pratiquement constante en fonction du nombre de processeurs. Notons aussi que les SMP n’ont pas une scalabilité parfaite, toutefois, mais leur croissance, dans leur domaine de configurabilité, est plus favorable que celle des clusters.
 Il convient de distinguer les SGBDs adaptés au cluster (que l’on peut qualifier de SGBDs parallélisés) et les SGBDs distribués. Un SGBD parallélisé est capable, dans un environnement clsuter, d’exploiter la puissance de traitement des différents nœuds pour l’accès à un même base de données. Un SGBD distribué donne une visibilité de base de donnée unique à un ensemble de bases de données (homogènes ou non) placées sur différents systèmes. Au moment de notre analyse, Ingres (Ingres Star) et Oracle avaient aussi en développement des versions distribuées de leurs produits. Bull (US) adopta la technologie Ingres Star, avec un succès très limité d’ailleurs. Il faut noter que les différents développements de SGBDs distribués ont été stoppés au profit de mécanismes d’accès distants et de réplication (voir, à ce sujet, mes supports de cours du CNAM accessibles depuis mon site www.chevance.com).
 De fait les premières implémentations tardaient à « tomber en marche » et il était nécessaire que les quelques constructeurs défendant cette approche s’entendent sur un ensemble réduit de profils communs afin de permettre l’interopérabilité. Compte tenu du temps et de l’énergie dépensés, il serait intéressant d’évaluer le coût que cette aventure ISO a coûté à Bull ; le rapprochement avec les résultats pourrait certainement donner le vertige...
 On comptait dans leurs rangs, les personnes ayant travaillé à DRCG (Direction Réseaux et Communication Groupe) dirigée par Claude Boulle (et successeurs) avant qu’il ne rejoigne Bull Transac en tant que Directeur Technique lors de la création de cette entité.
 Au moment du lancement du Questar 700, une règle particulièrement idiote, avait été édictée selon laquelle le Questar 700 ne pouvait se vendre que « par paquets de 50 » !
 La création d’une direction technique avec les efforts entrepris par Claude Boulle pour la « normalisation » des pratiques de gestion des développements, la coordination avec les lignes de produits et de suivi des projets mériterait un développement spécifique. L’arrivée de Francis Ackermann à Grenoble (1988 ou 1989 ?) mit fin à cette direction commune et les habitudes anciennes reprirent le dessus…
Notons que noue avions réalisé, au sein de Bull Transac en préalable à ce regroupement, une analyse du portefeuille de compétences suivant la méthode préconisée par le Cabinet Arthur D. Little. On reviendra sur ce point à la fin de ce document dans la partie « Miscellanées ».
 J’avais d’ailleurs surnommé le chef de projet « le roi du planning à roulettes ».
 Sur le plan des développements, un driver semble avoir été le seul résultat tangible. Toutefois, la présence de ce « gourou » incita quelques personnes à se lancer dans Unix. Cette présence a donc permis, de façon, indirecte d’accélérer la prise en compte d’Unix à la SEMS.
 Il semblerait que l’on puisse même parler de conflit de personnes entre Jean-Michel Pernot et Christian Joly.
 Si ‘absence d’adressage 64 bits n’était pas une difficulté lors de l’introduction des machines Ridge, elle constituait une difficulté pour le futur. Rappelons que l’architecture PA de HP, dont l’introduction est quasi contemporaine, prévoyait trois types d’implémentations en ce qui concernait l’adressage : 32, 48 et 64 bits. La version 32 bits était prévue pour les fonctions de type contrôleur, les premières versions de PA utilisaient la définition 48 bits.
 Le packaging du XPS était de facture tout à fait classique avec nappes, connecteurs,…. Je me souviens d’une présentation à Massy du DPX/2000 lors de laquelle (Prénom ?) Delmas demanda une pièce de monnaie à nos collègues italiens et, à l’aide de cette seule pièce, démonta puis remonta complètement la machine en un temps record. Nos collègues italiens furent réellement impressionnés par cette démonstration et les principes du packaging DPX/2000 furent intégralement repris pour la nouvelle ligne commune.
 Il ne me semble pas que Motorola ait eu la volonté de créer, à cette époque, le standard (par exemple, valider un standard de fait tel que celui des machines NCR de l’époque). Motorola ne s’est jamais distingué, dans le domaine des microprocesseurs, par une quelconque vision stratégique. Ceci était d’ailleurs un sujet de plaisanterie dans l’industrie comme le montre l’anecdote suivante. A la fin des années 80 lors de notre recherche d’une solution RISC, au cours d’une visite chez Intel au sujet du 860 (voir paragraphe spécifique), nous avons été reçus par Jean-Claude Cornet, VP de la division microprocesseurs à cette époque. Une présentation marketing vraiment peu convaincante nous fut faîte. A la suite de cette présentation et en guise de commentaire, je demandai à Jean-Claude Cornet si Intel avait embauché une personne venant de chez Motorola pour le marketing. Le commentaire de Jean-Claude fut simplement le suivant : « Tu es dur ! ». Notons toutefois, que Motorola avait compris la leçon sur le standard binaire et entrepris, pour le 88000, la promotion d’un standard (88 Open).
 Marcello Ardizzone fut retrouvé mort un matin dans son domicile parisien, une collègue italienne surprise de ne pas le retrouver, comme convenu, sur le quai du RER, donna l’alerte. Sa mort causa une vive émotion à tous ceux qui avaient eu l’occasion d’apprécier ses compétences techniques et ses qualités humaines.
 Notons que les engineerings étaient restés chez Bull sans lien direct avec XS ce qui contribua largement au bordel ambiant…
 Il n’est pas inutile d’évoquer le modèle générique des interactions avec la stratégie du Groupe, une fois un choix fait par une entité « produit » :

La stratégie : Avez-vous bien évalué xxxx ?
L’entité : Auriez-vous des éléments concrets pour xxxx ?
La stratégie : Je n’affirme rien, je pose simplement la question.
L’entité : Que recommandez-vous ?
La stratégie : La ligne de produit, c’est vous. C’est à vous de choisir !

Bien évidemment, cela prenait plus de temps que ce raccourci et consommait une certaine énergie !
 Toutefois, nous eûmes un meeting avec HP en 1988 au cours duquel HP nous fit une ouverture timide autour de HPPA. HP n’était pas organisé pour « vendre » ses microprocesseurs et ceci n’était pas en ligne avec notre objectif qui était de développer nos propres systèmes (ou toutefois d’avoir une part de développement significative).
 Les microprocesseurs en tranches permettaient, à des constructeurs de matériel, de réaliser des processeurs ayant l’architecture adéquate via la microprogrammation.
 Quelques mois après ce dîner, je fus invité par AMD en compagnie de différents clients européens à une magnifique soirée au château de Versailles. Au cours du dîner, l’un des participants du dîner de Palo Alto vint me voir et il m’indiqua que nos échanges lors de ce dîner avaient contribué à alimenter un débat (qui existait certainement à ce moment) au sein d’AMD. Le résultat fut qu’AMD abandonna toute velléité de faire du 29000 autre chose qu’un microprocesseur « embarqué » et renforça la stratégie « compatible Intel ». Il m’indiqua aussi que mon invitation à Versailles était la conséquence de ce dîner (car je n’étais en rien impliqué dans les achats de Bull auprès d’AMD).
 Intel avait utilisé une technique pour conserver la confidentialité et identifier la source d’éventuelles fuites : le processeur (de nom de code N10 chez Intel) recevait un nom différent et spécifique à chacun des clients potentiels. Pour Bull, le nom était « Race ».
 Il est intéressant de noter que MIPS avait mis en œuvre dans ses compilateurs une méthode d’optimisation globale qui avait été créée à la CII par Etienne Morel et Claude Renvoise (de l’équipe LIS de Jean Ichbiah). Je connaissais bien cette méthode pour avoir relu leurs thèses, en avoir discuté avec eux et intégré la description dans mon cours de compilation à Paris 6.
 Motorola n’avait pas donné suite à la requête de Sun qui lui demandait un microprocesseur RISC. Suite à ce refus, Sun développa SPARC sur la base des travaux de Berkeley.
 Notons à ce sujet que ceci ne constitue pas une exception. Bien plus tard, Intel n’a pas su ou voulu proposer une évolution « douce » vers le 64 bits à partir d’IA-32 (comme le propose AMD, et comme l’envisage Intel….).
 Roger Ross fonda Ross Technologies pour y développer des processeurs SPARC ! Une ou deux semaines avant son départ, Ross nous avait donné toute assurance quant à son support personnel pour nos développements sur la base du 88000.
 Stratus semblait décidément abonné aux mauvais choix : le 88000 après le N10. Ce phénomène a été encore confirmé il y a quelques années avec l’adoption de PA d’HP alors qu’HP était déjà bien embarqué dans IA-64 ! Stratus semble avoir bien tiré la leçon en adoptant l’architecture Intel (à moins qu’il ne s’agisse d’un mauvais présage pour Intel ?).
 Ce projet utilisait un bus d’origine Xerox. De fait, le produit Sun Enterprise 10000 est un héritage de Cray, SGI ne voulant pas prendre ce produit lors du rachat de Cray. Il dut y avoir une synergie entre les projets.
 Il faut y voir un compliment, car les visites chez Sun ont toujours été d’un grand intérêt tant technique que stratégique ainsi qu’une sorte de bain de jouvence (on en ressortait avec le sentiment qu’il devait être stimulant de travailler dans un tel contexte). Je me souviens d’un voyage où j’ai commencé par un meeting à Billerica suivi le lendemain même par un meeting chez Sun en Californie. Dire que le contraste était frappant serait un euphémisme ! Pour être un peu plus spécifique sur ce sujet, disons que la moyenne d’âge à Billerica était élevée dans les équipes du DPS6000 mais surtout que le comportement de certains ingénieurs en poste depuis longtemps n’était pas très porté vers l’innovation et la témérité des solutions proposées ; le tout étant compléter par un sacro-saint respect des consignes générales données par la hiérarchie même si cela devait faire capoter le projet. On devinait que les quelques jeunes ingénieurs recrutés ne tarderaient pas, leur première expérience faite, à voguer vers d’autres horizons plus porteurs. Il ne faut évidemment pas généraliser cette remarque, elle ne s’applique qu’à l’équipe DPS6000 que j’ai rencontrée et qui était en charge du projet de reciblage.
 Cette histoire est une bonne illustration du tigre de papier. Unix ayant réussit une percée certaine, les marché US (fédéraux en particulier) demandaient (et risquaient d’imposer) la fourniture de systèmes sous Unix. AT&T, qui détenait les droits et le code Unix, souhaitait se diversifier dans l’informatique avait prit une participation dans Sun. Les possibilités financières d’AT&T et le fait que Sun soit un constructeur ambitieux et « totalement Unix » avaient suscité les plus vives inquiétudes de la part des autres constructeurs (qui tous avaient une pléthore de systèmes d’exploitation). Les visites que l’on rendait à AT&T d’une part et à Sun d’autre part étaient de nature à dissiper toutes les inquiétudes quant aux possibilités de coopération effective (autre que financière) entre ces deux entités. Je me souviens d’une visite (quasiment surréaliste) que nous fîmes chez AT&T dans le New Jersey en 1985 et dont le sujet principal était le Unix PC. Cette station de travail à base 68020 avait été développée par Convergent Technologies pour le compte d’AT&T. Participaient à cette réunion l‘ancien et le nouveau chef de produit AT&T pour l’Unix PC. Quelle ne fut pas notre surprise lorsque nous rendîmes compte que ni l’un ni l’autre ne savaient à quelle clientèle ce produit était destiné, ni pourquoi faire et ni par quels canaux de distribution ce produit allait être diffusé… De fait, ce produit équipa les labos d’AT&T et l’on en entendit plus parler. Dans le même ordre d’idées, la visite du stand AT&T lors des Expos Unix était tout à fait édifiante : AT&T y démontrait des technologies et des produits, pour avoir des renseignements précis, il fallait y faire plusieurs visites, prendre un rendez-vous plus ou moins précis avec une personne supposée connaître le sujet. Lorsque l’on avait pu mettre la main sur l’homme de la situation et que l’on posait les questions du style : « Combien ? Quand ? » la personne ne dissimulait pas son embarras, nous demandait notre carte de visite, nous remerciait pour notre intérêt et les choses en restaient là. Les aventures d’AT&T dans le monde informatique prirent rapidement fin, ce qui n’empêcha pas le mythe OSF de hanter les rêves de certains stratèges….
 Une petite anecdote à ce sujet et qui a beaucoup amusé Serge Sorkine. CCI assurait le développement de ses propres compilateurs et le marketing nous promettait monts et merveilles. J’avais demandé, pour le meeting avec le responsable des compilateurs, que l’on me décrive en détails les optimisations prévues. Afin d’aller plus vite au cœur du sujet, je demandais à ce responsable de me décrire les optimisations mises en œuvre dans les termes de l’ouvrage de référence sur la compilation (« Compilers Principles, Techniques and Tools » de A.V. Aho, R. Sethi et J.D. Ullman) connu sous le nom de Dragon Book en référence à l’illustration de sa couverture. Le responsable ignorait l’existence cet ouvrage et la discussion qui suivit mit en évidence la pauvreté des optimisations projetées. Suite à cela, le Dragon Book devint un sujet de plaisanterie interne.
 Bien que d’une approche technologique plus classique, le DPS4000 –dont l’architecture processeur était dérivée de celle du DPS7000- était voisin, du point de vue de ses utilisateurs, d’un AS/400 (alias System/38 et maintenant iSeries). En d’autres termes, il s’agissait d’un système organisé autour d’une base de données et accessible uniquement au moyen de langages de haut niveau.
 Tant pour le DP7000 que pour le DPS9000, trois éléments –dont je ne chercherai pas à quantifier l’importance, ont concouru à rendre les solutions d’émulation applicables : la forte augmentation de la performance intrinsèque des microprocesseurs, les difficultés croissantes de financement des développements de processeurs propriétaires (en conservant bien évidemment un équilibre financier) et les esprits, au niveau de l’engineering, plus prêts à faire le pas.
 En ce qui concerne MIPS, notons qu’il existait, au moins sur le papier, autre possibilité : s’allier à NEC pour prendre une part active au développement de MIPS (NEC aurait même pu racheter une part importante du fabricant de microprocesseurs pour sécuriser ce choix). Cette proposition fut fortement combattue par les américains, la stratégie groupe et, il semblerait même, par le gouvernement socialiste de l’époque. Le message qu’on passait était qu’il fallait chercher une alliance avec les américains contre les japonais… Dans cette paranoïa, il y eu même des présentations, au siège du Groupe, parlant de MIPS comme des forces de l’axe, allusion à Siemens, Olivetti et NEC, tous licenciés de MIPS !
 Lors de l’introduction de ce nouveau système (de fait une station de travail) et afin de procéder à son analyse, j’avais fait l’acquisition d’un exemplaire qui fut installé à Massy et évalué par Francis Couppié et Jean-Pierre Goursaud (tous deux s’occupant des problèmes de performance et de modélisation dans notre cellule architecture). Ce système n’avait pas une performance renversante, surtout en virgule flottante (co-processeur flottant de la famille NS32000), ce qui n’était pas vraiment un avantage pour une station de travail ! L’implémentation d’Unix était bien particulière car le code Unix s’appuyait sur une couche d’abstraction appelé VRM (Virtual Resource Monitor). J’y avais trouvé une certaine parenté avec des concepts mis en œuvre dans l’AS/400 (iSeries maintenant). L’ergonomie avait fait l’objet d’un soin particulier. A propos de ce RT PC, il convient de noter les difficultés que j’ai rencontrées pour obtenir des compléments au produit (tels une carte co-processeur MS-DOS sur le bus d’entrées-sorties) et quelques informations auprès du service commercial d’IBM. En effet, l’introduction de cet objet dans le corps commercial d’IBM présentait tous les symptômes du rejet de greffe : méconnaissance du produit, méconnaissance d’Unix et des produits de ce domaine, manque d’allant commercial,….. A produit incertain, commerciaux incertains ? Je me garderai bien de faire un quelconque rapprochement avec la situation d’Unix dans le corps commercial Bull à la même période...
 Le bus MCA (Micro Channel Architecture) avait été retenu. On peut être surpris par ce choix compte tenu que PCI s’imposait, dès ce moment, comme le standard de facto. De fait, toute la gamme RS/6000 d’IBM utilisait le bus MCA et le choix avait été dicté par des raisons de continuité.
 Pour les non-initiés : dans tout projet il convient d’identifier le plus rapidement possible qui est le RQCV (Responsable Quand Ça Va) et le RQCM (Responsable Quand Ça Merde). On ajoutera qu’il s’agit rarement de la même personne….
 IBM a joué en la matière un rôle négatif majeur. Bien que les RS/6000 multiprocesseurs de la première génération étaient en tous points identiques aux Escala (Pegasus) de Bull (et pour cause puisqu’il s’agissait de systèmes Pegasus en OEM), ils ont toujours refusé que Bull fasse une déclaration de compatibilité binaire entre ces deux systèmes et ont saboté les efforts des autres participants à la PowerOpen Association de créer un vrai standard de compatibilité binaire qui aurait officialisé auprès des ISV le fait qu’une application portée sur un système conforme doit tourner sans portage ni validation complémentaire sur tout autre système conforme. IBM a en fait poursuivi de manière constante une stratégie de réduire Bull au rôle d’un simple OEM
 Il n’est pas faux de dire que Jean-Marie Descarpentries, alors PDG de Bull, n’était pas très familier avec le métier de constructeur informatique et qu’il ne disposait pas d’une équipe de direction suffisamment compétente pour appréhender les vrais problèmes et percevoir les risques potentiels. Avec l’objectif prioritaire de la privatisation, Jean-Marie Descarpentries avait alors probablement tendance à se fier aux messages que lui adressait le management d’IBM : « Nous collaborons bien avec les managers d’Unix de Bull ». L’alignement sur les souhaits d’IBM pouvait être perçu comme une façon rapide d’être en bonne position pour d’éventuelles promotions. Tout cet ensemble ne fit qu’aggraver la situation de dépendance dans laquelle la direction d’IBM entraînait Bull. On doit noter qu’Armand Malka a essayé, avec un certain courage, d’attirer l’attention du haut management sur l’impasse dans laquelle IBM nous entraînait. Les initiatives d’Armand Malka ont été rapidement marginalisées tant par le haut de la hiérarchie que par une partie de l’engineering. Deux phénomènes peuvent expliquer cette réaction de l’engineering :
Une large partie de l’engineering avait tendance à se prendre pour l’élite pour avoir participé à l’opération Pégasus ;
Armand Malka, en raison de son côté résolument « vendeur », ne bénéficiait pas d’un grand crédit auprès des équipes de développement.
Au sujet de la direction générale de Bull, on peut mettre au crédit du tandem dirigeant (Jean-Marie Descarpentries et Thierry Breton) le redressement du Groupe et le succès de l’opération de privatisation. Le seul bémol, mais d’importance, est qu’ils n’ont pas défini de stratégie pour le Groupe et, par voie de conséquence, ni mis en place les actions correspondant à sa mise en œuvre. En ce qui concerne l’action de leur successeur, Guy de Pannafieu, je n’en dirai rien, son bilan est suffisamment éloquent…
 Sans toutefois devoir ensuite la racheter à IBM dans le cadre des royalties sur AIX comme cela s’est passé (si j’ai bien compris) avec l’IPv6 développé par l’INRIA.
 Le dernier développement matériel d’importance conduit à Echirolles fut l’EL (Entry Level) de la NCL. Yves Fantino était le responsable technique de ce projet.
 Notons toutefois nos contacts avec Multiflow en juillet 1991 et avec Exponential en mai 1996. Ces sociétés avaient des projets de développement de microprocesseurs à haute performance. Aucune de ces solutions ne présentait un degré de viabilité suffisant.
 La mise en situation de dépendance de Bull semble avoir été un objectif stratégique de la part d’IBM et tout a été mis en œuvre pour y arriver. Pour en sortir, il aurait fallu que le management de Bull, au plus haut niveau, se batte pour rappeler que Bull a adhéré à Power Open avec la promesse d’ouverture, cela n’a pas eu lieu. Toute discussion interne sur ce sujet était vouée à l’échec… Sur le plan de la technologie, notons toutefois que la que le fourniture de microprocesseurs et de chip sets à des partenaires pour le développement de systèmes nécessite des investissements importants (documentation, support) par rapport à un développement de microprocesseurs, de chip sets et de systèmes « en interne » (i.e. au sein de la même entité). Comme Bull était pratiquement le seul client potentiel, que ses volumes n’étaient pas particulièrement attractifs et surtout que le management de Bull se satisfaisait de la situation…
 Jusqu’à mon départ de Bull (juin 1999), je publiais assez régulièrement la Road Map des microprocesseurs faisant la synthèse de nos informations sur les dates de disponibilités et les performances des microprocesseurs des différents constructeurs et fournisseurs. Le graphique de la Road Map était assorti de commentaires et d’analyses. En raison des glissements (plannings et performances) de Power PC, on me demanda d’en suspendre la publication durant un temps pour ensuite me demander de la rétablir (cf. la peur n’évite pas le danger….).
 Outre la fourniture de microprocesseurs, Intel est devenu fournisseur de chip sets (ensemble de composants accompagnant le microprocesseur et permettant de réaliser des systèmes) et surtout de systèmes qu’il vend en OEM exclusivement (pour ne pas être en concurrence avec ses propres clients OEM). Avec les moyens que ses ventes lui procurent, Intel synchronise le développement de ses chip sets et de ses systèmes avec celui de ses nouvelles générations de microprocesseurs. Dans les hypothèses envisagées pour la suite des activités de HDPA (voir épisode FAME), j’avais proposé d’investiguer la possibilité d’un accord Bull/Motorola dans lequel Bull aurait joué le rôle de « system house » et constituer ainsi un ensemble similaire à Intel mais pour le monde Power PC. Cette idée n’a pas rencontré d’écho.
 Jean-Jacques Guillemaud avait une forte personnalité. Pour s’occuper de performances, c’est une qualité indispensable. En effet, j’ai le souvenir de revues où le sujet performances faisait l’objet d’une présentation (ce n’était pas toujours le cas car ce sujet ne reçoit généralement pas le traitement qu’il mérite) et que les chiffres espérés ou attendus n’étaient pas au rendez-vous. Alors, il y avait un déchaînement de passions à l’encontre du responsable des performances, y compris de la part de l’équipe projet ! Cette personne était accablée de tous les maux de la terre (c’est vieux comme le monde : on coupe la tête du porteur de mauvaises nouvelles)… Avec Jean-Jacques Guillemaud, la situation était totalement différente. Jean-Jacques se faisait un devoir (et un plaisir) de démontrer que si les performances étaient mauvaises, c’était de la responsabilité des équipes de développement et de pointer les points critiques sur lesquels il avait préalablement essayé d’attirer l’attention des développeurs… La décision de transfert des activités « performance » à Echirolles provoqua la dispersion de l’équipe et le départ de Jean-Jacques Guillemaud. Voilà encore un exemple du soin apporté à la gestion des compétences (pourtant fort rares dans le domaine des performances). L’activité ne décolla pas réellement à Echirolles.
 Rappelons que cette mixité d’environnement a été mise en œuvre, dans le cadre de GCOS7, avec des implémentations d’Unix mais sur processeur natif DPS7000 pour « tourner » les logiciels du monde Unix.
 Note : la façon de s’affranchir de cette contrainte est de faire en sorte que toutes les mises à jour de la mémoire partagée soient faîtes sur la base d’une logique transactionnelle (hypothèse difficile à réaliser dans la pratique).
 Une petite anecdote. Il y avait, autour du haut de gamme, deux visions antagonistes (Jean Bellec d’une part et Michel Sakarovitch d’autre part). Je ne relaterai pas ici les raisons profondes de cet antagonisme, mais pour réconcilier les points de vue, j’ai choisi d’illustrer le projet lors de mon introduction au séminaire par un dessin extrait de la mythologie de Dubout. Ce dessin, que je ne décrirai pas en détail, illustre la perplexité de l’un des protagonistes en mettant en scène une jeune fille, une jument et un centaure…
 A signaler en particulier qu’Intel s’est un moment intéressé à cette technologie à l’époque où ils cherchaient à définir les spécifications de ce qui devait devenir l’USB.
 Cela tenait un peu, il faut le dire, de l’alchimie : on prenait des logiciels standards avec tous les défauts que cela suppose, et ils se transforment en logiciels fiables et performants grâce aux « disciplines ». Personne n’avait compris comment fonctionnait ce miracle, et peu osaient le reconnaître, car cela leur donnait l’air ringard. Un jour toutefois, le directeur d’EIS (Enterprise Information Systems) Khaled Marreï, a non seulement osé avouer et dire publiquement qu’il ne comprenait pas comment cela marchait mais il a même arrêté le projet à plus ou moins court terme….
 Une petite anecdote au sujet de la convergence. Le premier meeting se déroula à Louveciennes un samedi et les services d’une traductrice japonais/français/anglais avaient été requis par NEC. Jean Papadopoulo avait repéré que nos interlocuteurs utilisaient le mot « convergence » au lieu d’un équivalent japonais (qui nous aurait bien évidemment échappé). Jean demanda donc au cours du déjeuner si le mot « convergence » existait dans la langue japonaise, la réponse de nos partenaires fut embarrassée…
 A un point tel que j’avais même émis l’hypothèse suivante : « il n’est pas surprenant que les Japonais passent autant de temps au travail, vu la vitesse à laquelle ils comprennent…. ». Ceci n’est qu’un trait d’humour, il ne faut surtout pas y voir un commentaire de portée générale…. Dans ce domaine et pour l’anecdote, nous eûmes (Gérard Roucairol et moi-même) deux meetings en commun (Bull/NEC) aux US avec Microsoft et HP (en juillet 1996). La cadence était imposée par nos interlocuteurs US et nos partenaires de NEC avaient visiblement des difficultés à suivre et encore plus à participer aux échanges. A la fin de chacun des meetings, les représentants de NEC nous ont demandé d’avoir un débriefing….. Piètre consolation pour tout le temps perdu dans nos meetings et les interminables téléconférences matinales….
 Un groupe de travail commun Bull/Motorola avait été créé autour de ce type de système. Il y avait deux préoccupations : introduction de ce système par Bull pour le marché Telco d’une part et la définition de la gamme future d’autre part. J’étais surtout concerné par le second aspect. Après quelques travaux et un meeting à Phoenix en juillet 1996, le groupe s’est dilué. Il semblerait que Motorola ait mis en sommeil ses ambitions dans le domaine.
 On peut considérer que Tandem et ensuite Digital avec le Vax Cluster ont été les inspirateurs des clusters Unix.
 A ce sujet, et sans que mon commentaire concerne spécifiquement ce projet, une technique largement utilisée par les projets de recherche était d’avoir au moins deux sources de financement décalées : on terminait la prestation sur un contrat avec le financement du suivant. Le résultat net de cette approche est qu’il devient très difficile d’arrêter un projet de recherche. Toujours sur ce thème, l’une des décisions les plus importantes dans la gestion de la recherche est l’arrêt de projet. Soit une recherche a conclu à la faisabilité et au quel cas c’est aux lignes de produits de décider de la transformation du projet en produit, ou bien elle a démontré les raisons de l’infaisabilité et l’on doit consigner et faire connaître ce résultat et arrêter le projet. A défaut de ce mode de gestion, on a ainsi connu des projets de recherche sans fin. Avec le GIE Dyade réunissant des équipes de l’INRIA (y compris ses composantes provinciales), les lignes de produit Bull et quelques représentants des équipes R&D de Bull, un système beaucoup plus performant a été mis en place. Les projets étaient structurés en actions : une action avait un terme, un sponsor (une ligne de produits Bull) et l’ensemble des actions était périodiquement revu par un comité de pilotage. Les difficultés de Bull mirent un terme à Dyade (dont Gilles Bogo était responsable) mais je pense qu’il s’agissait d’un excellent schéma (qui devrait aussi être mis en œuvre dans le cadre d’une recherche interne).
 Dans le cadre de l’initiative européenne OMI (Open Microprocessor Initiative) j’ai eu des contacts avec INMOS. J’ai pu ainsi apprécier le manque de réalisme ce cette société, qui sur la base d’une bonne idée qui était l’intégration de liens de communication rapides au sein d’un microprocesseur, n’hésitait pas à faire une rupture de compatibilité à chaque nouvelle génération. Je me souviens de la réaction de David May (architecte en chef d’INMOS) durant un meeting Avenue Malakoff lorsque j’avais suggéré qu’INMOS fasse du compatible Intel agrémenté toutefois par la valeur ajoutée d’INMOS (l’intégration de liens rapides, ce que fit AMD bien plus tard sur ses microprocesseurs compatibles Intel). Le rachat d’INMOS par ST précipita la fin des rêves d’INMOS. INMOS était aussi fort connu pour ses retards dans la disponibilité des nouveaux microprocesseurs.
 Rappelons le proverbe shadock déjà cité « Ce n’est pas parce que l’on joue à un jeu de con qu’on est obligé de se donner des règles »….
 Contrairement à ce que quelques personnes avaient pu croire, le dorsal n’était pas un ordinateur à vocation militaire tirant son nom du fait qu’il était transporté à dos d’homme…
 Copernique présentait le type même d’organisation dite « solaire » : le président fondateur cumulant pratiquement l’ensemble des fonctions : stratégie, direction technique, direction industrielle, direction commerciale,…
 Il y eu une période, assez longue, lors de laquelle peu d’actions internes pouvaient être entreprises sans la participation du Groupe Bain. La compétence de leurs consultants étant plus que limitée, il fallait dépenser beaucoup de temps et d’énergie pour leur expliquer de quoi il retournait. Compte tenu que leur principale compétence était la préparation de présentations, il me semble que le Groupe aurait pu trouver des solutions de secrétariat nettement moins onéreuses.
 Pour limiter les pertes de temps en réunion, j’avais emprunté une pratique que Claude Kaiser, alors Président du Département Informatique au CNAM, mettait systématiquement en œuvre : il organisait les réunions d’enseignants à partir de 11 heures du matin : l’horaire de fermeture de la cafétéria constituait une butée infranchissable. Ayant pu mesurer l’efficacité de cette pratique, j’ai essayé de la mettre en œuvre chez Bull, malheureusement sans faire suffisamment d’émules.
 A titre de boutade au sujet de la définition de DCM, j’avais paraphrasé les propos de Lénine qui disait que « le socialisme, c’est les Soviets plus l’électrification du pays » en « DCM, c’est DCE plus la fourniture de courant électrique ».
 Philip A. Roussel, Kamal N. Saad, Tamara J. Erickson (Arthur D. Little) “Third Generation R&D Management“Harvard Business School Press 1991


 :