Langages et bases de données GCOS64 / GCOS7

 

 

Jacques PRINTZ, Professeur au CNAM, Président du département Sciences et Technologies de l’Information et de la Communication

Ancien responsable des langages et bases de données chez Bull.

 

Sommaire

 

1       Les langages de programmation à la fin des années 60s. 1

2       L’offre langages de programmation de GCOS64 / GCOS7. 3

3       Architecture et stratégie d’implémentation des compilateurs. 5

3.1       Les standards de compilation. 5

3.2       Factoriser la génération de code – l’architecture OIL-CCG.. 5

4       Des fichiers aux bases de données. 8

5       Les débuts d’IDS2. 10

6       L’information centre et les débuts du relationnel 12

7       Passé, présent et futur 14

 

 

zzzzz

 

1    Les langages de programmation à la fin des années 60s

La fin des années 60s et le début des années 70 est une époque charnière de l’histoire des langages de programmation. Avec FORTRAN et COBOL, déjà « anciens », naît le concept de langage de haut niveau. Il devient possible de programmer les applications en « oubliant » les idiosyncrasies de la machine sous-jacente. C’est un énorme progrès car cela permet au programmeur de se concentrer sur son problème de conception et de travailler la lisibilité de son programme, plutôt que de se soucier du format des instructions ou de la topologie des données dans la mémoire de la machine ; avec les « overlay » c’était un réel casse tête.

Cependant, les « vrais » programmeurs d’alors mettent un point d’honneur à démontrer leur capacité en jonglant avec le langage assembleur de la machine, dont le niveau de symbolisme est réduit à sa plus simple expression ; la programmation directe en hexadécimal ou en octal n’est pas rare ! Sur les machines IBM de l’époque l’assembleur est un langage de programmation comme un autre et toutes les interfaces d’accès au système d’exploitation, ce que l’on n’appellent pas encore les APIs, sont disponibles en assembleur.

Toutefois, pour faciliter la programmation en assembleur on dispose de mécanismes de macro-génération qui permettent de programmer par « patterns » regroupant un ensemble d’instructions assembleur dans lesquelles on va venir insérer, là où sont définis les paramètres formels de la macro, les arguments fournis à l’appel de la macro. Ces mécanismes sont définis à « compile time » par opposition à ce qui est fait à « execution time » ou « run time », lors de l’exécution du programme. Ceci permet au programmeur de bien différencier le paramétrage statique à la construction de son programme, du paramétrage dynamique à l’exécution.

En matière de recherche, il y a des travaux intenses sur l’étude des langages en général et sur la fabrication des compilateurs qui sont les programmes, reconnus comme particulièrement difficiles à concevoir par la communauté informatique, qui traduisent les langages de haut niveau en assembleur. Cette recherche tire partie des travaux des logiciens, bien antérieurs à l’invention des premiers ordinateurs, dans les années 1920-30, qui ont mis au point les premiers systèmes formels. La notation dite « polonaise », très utilisée par les spécialistes de la compilation, a été inventée par le logicien polonais Lukasiewicz dans les années 20, pour s’affranchir des problèmes de ponctuation cauchemardesques résultant de notations comme celles des Principia mathematica de Withehead-Russel ; dans cette notation dite post-fixée[1], une expression comme  s’écrit simplement , et les ( ) ont disparu !

La notion de grammaire formelle arrive dans l’univers des langages de programmation, avec une notation qui va devenir célèbre, la BNF[2], inventée par John Backus, l’un des créateurs du langage FORTRAN chez IBM, et de nombreux autres auteurs. La BNF servira à spécifier de façon rigoureuse la syntaxe du langage ALGOL 60.

Le maniement de la notation devient un exercice de style imposé à tous ceux qui ont affaire aux langages de programmation. C’est une école de rigueur qui à le mérite de faciliter la mise en forme des différents niveaux qui concourent à la bonne définition des langages de programmation : le niveau lexical, le niveau syntaxique et le niveau sémantique.

Les architectes de compilateurs disposent, dès cette époque, d’une littérature de référence, comme par exemple le livre de David Gries, Compiler construction for digital computers, en 1972, et bien sûr la célèbre bibliothèque d’algorithmes que Donald Knuth, lui même grand spécialiste des langages, a publié sous le titre Art of computer programming, en trois volumes, à partir de 1968. Toutefois, la notation BNF n’est pas utilisée directement pour programmer les analyseurs lexicaux et syntaxiques intégrés dans les compilateurs. Les concepteurs de compilateurs travaillent directement sur les automates de reconnaissance que l’on sait déduire de la grammaire. La traduction automatique de la grammaire en automates est encore du domaine de la recherche[3], bien que les algorithmes de génération soient déjà connus, dont l’un a d’ailleurs été inventé par D.Knuth. Cependant, les automates produits par de tels algorithmes sont particulièrement inefficaces, et il faudra attendre un bonne dizaine d’années pour avoir des outils comme LEX et YACC que tous les programmeurs UNIX connaissent, dans la décennie 80.

Le langage de référence de la communauté informatique naissante est ALGOL 60[4], un « beau » langage qui n’aura aucun succès commercial mais que Burroughs utilisera comme modèle de langage de programmation pour ses systèmes de la série B6500.

La vraie innovation industrielle est proposée par IBM avec le langage PL1, inspiré d’ALGOL, supporté par un énorme investissement en R&D, en particulier au laboratoire IBM de Vienne, d’où sortira entre autre la notation VDM, bien connue des théoriciens ; elle servira de base à la définition de la sémantique du langage. On peut dire que l’architecture moderne des compilateurs est directement issue de ces travaux avec en particulier la distinction qui sera faite entre la syntaxe concrète, celle que le programmeur connaît, et la syntaxe abstraite qui est celle utilisé en interne par le compilateur ; ceci mériterai un développement qu’il serait trop long de détailler ici.

Personne n’envisage toutefois d’utiliser le PL1 comme langage de programmation d’un système d’exploitation, considéré comme un pari fou, même si cela est théoriquement envisageable ; et ceci pour plusieurs raisons : le compilateur du langage PL1 est d’une redoutable complexité, le code généré est relativement inefficace sauf à mettre en œuvre des techniques d’optimisation qui sont connues mais qui dégradent fortement les temps de compilation, certains traits du langage exigent des services relevant du système d’exploitation. C’est cependant le pari que va relever le MIT qui choisit le PL1 comme langage de programmation du système d’exploitation expérimental MULTICS qui restera l’un des modèles, sinon LE modèle, de tous les systèmes d’exploitation ultérieurs avec des concepts révolutionnaires comme l’édition de liens dynamique, l’adressage segmenté, la communication inter-processus (ancêtre des FORK et JOIN d’UNIX), un modèle de sécurité encore inégalé à ce jour, etc.

Ce pari aura une double conséquence sur la naissance de GCOS64 dont les architectes connaissent parfaitement ce qui se passe au MIT, et dont certains travaillent directement au Technology square, à Cambridge :

ü      Un sous-ensemble strict de PL1, facile à compiler, sans « run time », sera le langage de programmation du futur système d’exploitation GCOS64.

ü      Le système d’exploitation MULTICS, sur machine GE645, sera utilisé comme « software factory » du futur GCOS64.

Ceci veut dire que les premiers travaux se feront en PL1, dans un sous-ensemble intitulé HPL, développé initialement sur MULTICS, puis « bootstrapé » sur les premiers modèles de la nouvelle ligne avec des techniques de compilation croisée bien au point à l’époque (cf. par exemple un livre comme celui de Mc Keenan, Horning et alii, Compiler generator, 1972, qui décrit parfaitement ces mécanismes[5]).

2    L’offre langages de programmation de GCOS64 / GCOS7

Le pari des concepteurs de GCOS était extrêmement risqué mais il fut complètement assumé par nos collègues américains qui utilisèrent sans restriction le nouveau langage. Côté français, il fut jugé prudent de disposer d’une roue de secours qui pris la forme d’un macro-assembleur intitulé MLP utilisé initialement pour réaliser l’émulateur G100 destiné à la reprise des applications développées sur ce matériel d’origine italienne.

L’offre langage GCOS64 était double :

ü      D’une part les langages d’implémentation réservés aux équipes de développement de Bull.

ü      D’autre part les langages commerciaux, pour les utilisateurs, avec comme fer de lance le COBOL au niveau du standard 74.

Il faut comprendre que, à cette époque, priver les utilisateurs de l’assembleur demandait un certain courage, car ce n’était vraiment pas la tendance, tant au niveau technique qu’au niveau culturel. En dépit de certaines pressions, le cap fut fermement tenu !

L’offre en langages d’implémentation comportait :

ü      Un assembleur NAL couvrant l’intégralité du jeu d’instructions de l’« interior decor » qui était l’interface hardware-software de la machine ; développé par les équipes parisiennes, Avenue Gambetta.

ü      Un sous-ensemble PL1, intitulé HPL (Honeywell Programming Language) ; développé à Billerica, dans la banlieue de Boston, non loin de la route 128 (la « silicon valey » d’alors) par une équipe connaissant parfaitement les travaux du MIT sur le langage PL1.

ü      Un macro-générateur, MACPROC, développé à Paris[6] sur MULTICS, puis bootstrapé sur GCOS7 après un détour sur le 4A Back-up, avec lequel furent programmées toutes les interfaces avec le système d’exploitation, soit trois jeux de macros pour la génération en NAL, MLP et HPL. Je n’ai pas souvenir du volume de code, mais c’était très important, supérieur à 150.000 lignes.

ü      Un macro-assembleur, MLP, déjà mentionné, dont l’implémentation initiale fut faite avec MACPROC, avant d’être doté d’un compilateur écrit en MLP via les techniques de bootstrap indiquées précédemment.

L’offre en langages commerciaux comportait, au départ COBOL, FORTRAN, RPG, auxquels sont venus s’adjoindre ultérieurement BASIC, PL1, APL, PASCAL et C.

COBOL était le langage phare de la nouvelle gamme de matériels. A l’époque, c’était une façon de se démarquer d’IBM qui avait fait le pari de PL1, et qui ne s’était jamais investie sur COBOL. Le compilateur proposé implémentait strictement la nouvelle norme 74 et avait passé avec succès les tests de l’autorité du Department of commerce qui certifiait la bonne conformité de l’implémentation à la norme, via le Federal Compiler Testing Center. La conformité aux standards était un argument de poids, très ancrée dans la culture anglo-saxonne, alors que chez les français, un standard était plutôt fait pour être violé ! Une première version du compilateur, comme d’ailleurs les utilitaires SORT et MERGE, indispensables pour les applications de gestion, et interfacés avec le langage, avait été implémentée en HPL à Billerica, sous la direction de Ron Ham, puis rapatrié à Paris, avec l’ensemble des développements faits aux Etats-Unis en 76-77, sous la direction de Jean Bourgain.

FORTRAN avait été jugé indispensable, mais ce n’était pas une vraie cible commerciale car les machines n’étaient pas optimisées pour le calcul scientifique. Le compilateur, également aux normes, était développé à Paris par l’équipe de Jean Bourgain, avant qu’il ne reprenne le COBOL.

RPG était un langage très populaire à l’époque, avec une excellente facilité d’emploi pour les applications de gestion traditionnelles, qui était utilisé sur les machines G100 reprises en émulation par la nouvelle offre GCOS64. Très économe en lignes de code, on pouvait programmer de petites applications en seulement quelques instructions. Quelques années plus tard, IBM en fit le langage phare de sa nouvelle offre System 3, et surtout System 38, ancêtre de l’AS400 actuel, qui fut un énorme succès. Le compilateur RPG était développé à Paris par une petite équipe dirigée par Michel Mouchy.

APL, langage d’invention IBM, par le mathématicien Iverson, était également très populaire, surtout pour implémenter les premiers Information Centre, ce qui n’était pas la vocation initiale de son géniteur qui le voyait plutôt succéder à FORTRAN. Le langage fut développé à Paris avec comme particularité une tentative de micro-coder une partie de l’interpréteur APL, sous la responsabilité d’Emmanuel Nguyen. Le langage APL, de part ses caractéristiques dynamiques (une variable peut contenir un opérateur, etc.), ne peut pas être compilé de façon classique ; il doit être interprété à la volée. De ce fait, le programmeur APL, indépendamment du fait qu’il devait être bien formé pour assimiler une notation d’inspiration mathématique, était très productif, mais les programmes résultant étaient très inefficaces. Ce n’était pas gênant pour les programmes ne servant qu’une ou deux fois — ce qui était le cas dans les info centres ! —, mais cela était parfaitement rédhibitoire avec des programmes de calculs répétitifs ; d’où l’idée de faire une partie de l’interpréteur en micro-code, directement sur le hardware, comme le recommandait certaines équipes de recherche travaillant sur le concept de « Machine langage ». Le résultat fut décevant, car seule une partie de l’interpréteur pouvait être micro-codée, mais cette partie était insuffisante en poids (moins de 50% de temps CPU), ce qui ne permettait même pas de doubler les performances.

Ce fut une première grande leçon sur la prise en compte des contraintes de performances du point de vue de l’utilisateur, car ce n’est pas tout d’optimiser une partie à grand frais, encore faut-il que cette partie ait un poids significatif dans l’ensemble, y compris en comptant ce qui incombe au système d’exploitation ; à l’époque, le bon sens avait tendance à dire qu’il suffisait de l’implémenter en hardware, permettant une accélération d’une facteur 10 à 15, pour que le gain soit immédiatement perceptible, mais comme chacun sait aujourd’hui, rien n’est plus contre-intuitif que les performances. L’extension micro-codée ne fut en conséquence jamais commercialisée, car en prime cela augmentait la complexité des configurations installées.

3    Architecture et stratégie d’implémentation des compilateurs

Cette stratégie fut tout à fait remarquable et se déroula, pour résumer, en deux étapes : les standards de compilation, puis le langage intermédiaire commun permettant de factoriser la génération de code, i.e. l’architecture OIL-CCG

3.1         Les standards de compilation

La première étape consista à définir de façon rigoureuse un certain nombre de standards permettant à différents langages de cohabiter au sein d’une même application. C’était un héritage direct des architectes du système MULTICS. C’est ainsi que furent définis les deux standards fondamentaux :

ü      Le format standard des unités de compilation, le CU standard, format unique d’entrée de l’éditeur de liens, quel que soit le langage de programmation. NB : avec la notion de mémoire virtuelle, le rôle de l’éditeur de liens dans la chaîne de préparation des programmes était absolument fondamental.

ü      Le format d’appel des procédures et les règles de passage des paramètres d’appel, par valeur et/ou par référence, indispensable si l’on veut appeler du FORTRAN depuis COBOL, ou inversement, i.e. le Parameter passing standard. Ce standard s’appuyait sur les instructions de la machine permettant la gestion de pile hardware (là encore, une très grande innovation à l’époque, pour soutenir la programmation structurée et la compilation séparée).

Aujourd’hui, tout cela paraît bien banal, mais à l’époque c’était une innovation de très grande portée. La mixité des langages était très difficile sur les machines de la gamme IBM 360, où chacun était libre d’implémenter sa pile comme bon lui semblait, conséquence indirecte de la programmation en assembleur. Beaucoup plus récemment, dans les années 80s, cela fut une des causes de l’échec du langage Ada, qui bien sûr avait un format de passage des paramètres rigoureusement défini, mais généralement incompatible avec les langages natifs des systèmes, ce qui empêchait de partager, par exemple, les premières bibliothèques X-Windows écrites en C[7].

 

3.2         Factoriser la génération de code – l’architecture OIL-CCG

La seconde étape démarra à l’occasion du rapatriement de tous les développements sur Paris, en 1976-1977, juste avant la fusion de CII dans Honeywell-Bull.

Il fut proposé, et le management de l’époque en la personne de Michel Rocher accepta, le projet de réaliser une « compiler factory » avec comme objectif de :

a)      Factoriser les générateurs de code des différents langages .

b)      Factoriser les outils permettant de spécifier et de générer les éléments sensibles des compilateurs comme les analyseurs syntaxiques, ce qui était classique, mais surtout les générateurs de code, ce qui l’était beaucoup moins.

Le rôle du générateur de code commun était de concentrer toutes les adhérences à la machine dans un programme unique, et ce afin de faire bénéficier automatiquement les optimisations de code à tous les langages nécessitées par les évolutions des CPU. Il était clair, dès cette époque, que des innovations majeures se préparaient en matière de « pipe-line » d’instructions, de registres « mémoire » avec les architecture RISC, de parallélisme au sein même des CPU, d’instructions longues avec les architectures dites VLIW, etc. ; toutes ces innovations nécessitaient un traitement très sophistiqué au niveau des compilateurs de façon à générer un code permettait d’exploiter au mieux les nouvelles possibilités résultant de l’intégration des composants hardware en CMOS. Pour un constructeur d’ordinateurs, la stratégie à suivre était donc limpide.

Pour mettre en œuvre cette stratégie, il fallait d’abord définir une interface unique d’accès à ce nouveau générateur de code, en fait un langage intermédiaire, un concept familier des architectes de compilateurs. Ce langage, appelé OIL — pour Optimized Intermediary Language — , était un langage d’arbres, suffisamment abstrait pour, d’une part être commun à tous les langages de programmation connus, et d’autre part, permettre la génération sur des machines d’architecture différentes. Le principe de l’architecture OIL, résumé sur le schéma ci-dessous, était très simple.

 

 

Sur le plan des principes, personnes ne doutait que c’était faisable, mais encore fallait-il le faire ! Car cela revenait à modifier en profondeur tous les compilateurs (environ 500.000 lignes de code). Ce qui fut fait par l’équipe de développement des compilateurs de Bull.

L’architecture du générateur de code commun (CCG), qui comportait deux étages d’optimisation, locale sur une suite d’instructions source sans GOTO, globale sur tout le programme, débrayables sur options de compilation, est montré ci-dessous. Dans cette architecture, l’optimisation consiste à enrichir le texte OIL, en garantissant l’invariance de la sémantique, de façon à permettre au générateur de code d’effectuer des choix optimaux, en place et/ou en durée d’exécution. Les optimisations « trou de serrure » (i.e. peep-hole) étaient intégrées au générateur de code ; elles permettaient de supprimer des séquences d’instructions consécutives inutiles comme  qui ne modifie pas R1 (au dépassement de capacité près ! ), ou des GOTO en cascade (aux règles de sécurité près, avec la segmentation).

 

 

Plusieurs innovations très importantes furent réalisées à l’occasion de ces développements.

Le langage OIL tira pleinement parti des travaux effectués sur le compilateur PL1 MULTICS dont une variante fut d’ailleurs portée sur GCOS par l’un de ses auteurs : Robert Freighburghouse ; une performance absolument extraordinaire car il fit le travail seul, comme j’ai pu le constater en allant le visiter dans son « atelier » de Cambridge, au bord de la Charles’s River ! Le langage intermédiaire de ce compilateur était constitué d’arbres syntaxiques abstraits, directement issus des travaux de recherche intense effectués sur ce type de représentation. Notre apport fut d’effectuer une distinction radicale entre les calculs classiques faits sur les valeurs des variables, des calculs effectués sur les adresses de ces variables, car les optimisations à effectuer sur les unes et sur les autres étaient différentes, en particulier pour ce qui concerne la gestion des caches d’instructions et des pointeurs. L’adressage de la machine distinguait les registres dit « de base » des registres généraux habituels, pour les besoins de l’adressage segmenté hérité de MULTICS, ce qui est une distinction fondamentale car les sémantiques n’ont rien à voir, par exemple pour la sécurité des accès. Pour faire une incise sur la technologie des SGBD relationnels, dont l’architecture et le développement  nécessite une maîtrise parfaite des techniques de compilation, l’optimisation des requêtes SQL traite différemment les chemins d’accès aux données, des données elles-mêmes ; c’est exactement ce que permettait la distinction des REF et des VAL dans le langage OIL.

Dans le développement de cette architecture, OIL fut utilisé dans trois contextes bien contrastés : le DPS7 bien sûr, le processeur M68000 et le super calculateur ISIS, dont l’architecture était radicalement différente. Ce fut une vraie preuve de la solidité du langage OIL.

La génération de code était pilotée par des automates de génération, écrits dans un langage ad hoc que nous avions défini pour nos besoins propres : le langage META d’inspiration PASCAL/Ada avec un mécanisme de types abstraits à l’état de l’art ; aucun langage de ce type n’existait à l’époque, du moins à notre connaissance, pour concevoir la génération de code, mais le paramétrage des générateurs de code à l’aide de tables était bien sûr déjà connu et utilisé[8]. Les axes de recherche universitaire étaient plutôt de chercher une formulation à l’aide de grammaires, dont on sait l’équivalence avec les automates, mais cela était beaucoup moins naturel, et surtout moins lisible, d’où notre préférence pour une approche de type automate familière des programmeurs. Le langage META permettait aux concepteurs-programmeurs des générateurs de code de bien séparer la logique de génération, c’est à dire le choix de telle ou telle séquence d’instructions machine — c’est un problème combinatoire extrêmement complexe, qui est le cœur du générateur de code  — des autres fonctions de service de la génération de code comme le calcul des adresses, la fabrication des instructions elles-mêmes, etc. Les automates de génération avaient, vis à vis du langage OIL, la même fonction que les automates d’analyse syntaxique  vis à vis du langage source, à la réserve près que le texte OIL était exempt d’erreur de programmation, sauf celles faites par les concepteurs eux-mêmes.

La validation du générateur de code, grâce à la structure interprétative des automates de génération, était réalisée de façon semi-automatique, à partir des graphes de contrôle des automates. Dans cette architecture, il était possible de suivre pas à pas, de façon déterministe, toutes les transformations réalisées et de programmer de façon centralisée les assertions de contrôles garantissant la validité des transformations effectuées. Les jeux de tests produits à l’aide de cette méthode garantissaient une couverture des automates de génération à 100%. Lors de la mise en service du premier compilateur dans la nouvelle architecture, pour le langage HPL, tout le code HPL de GCOS fut recompilé sans aucune régression ni erreur, montrant ainsi l’efficacité de la méthode de test[9].

Aujourd’hui, ces architectures sont devenues classiques, mais à l’époque ce fut une grande première, à mettre au crédit des équipes de la division compilateurs et du directeur de la R&D GCOS7 qui en avait compris tout l’intérêt. Les techniques mises en œuvre dans ces développements sont fondamentales à plus d’un titre :

ü      Elles permettent d’exploiter de façon sûre le haut niveau de parallélisme offert par les micro-processeurs des années 90 (pipe-line d’instructions, le multiflow, les VLIW, etc.).

ü      Elles permettent d’analyser la sémantique statique du programme compilé car, par définition, toute l’information du programme, y compris d’éventuelles annotations, est disponible dans le graphe du programme sous la forme de son arbre abstrait OIL. Tous les outils d’analyse statique sont basés sur ces méthodes

ü      Elles permettent, à la demande, d’injecter de l’information complémentaire concernant la sémantique de programme, sous la forme d’assertions fournies par le programmeur, à des endroits bien précis du programme lors de son exécution, pour améliorer la validation dynamique de la sémantique du programme (ce que B.Meyer, l’inventeur du langage EIFFEIL, appela, beaucoup plus tard, la programmation par contrat).

Couplé aux mécanismes d’optimisation, il était clair que le pari initial du MIT et des concepteur de GCOS, de programmer le système d’exploitation en langage de haut niveau était définitivement gagné.

Les principaux contributeurs de cet effort furent Philippe Radouan, responsable de l’équipe FORTRAN, et Jean-Claude Bourhis, concepteur des optimiseurs du CCG, mais également Jean-Paul Ledur, à la créativité débordante, concepteur du générateur de code, Gérard Morganti, futur responsable de la division compilateurs, et Jacques Thibault, tous deux contributeurs d’une rigueur exceptionnelle.

4    Des fichiers aux bases de données

Au début des années 70s, le monde des fichiers est encore fondamentalement séquentiel. Cela tient évidemment à la nature des supports que propose la technologie de l’époque, largement dominée par les bandes magnétiques pour ne pas parler des rubans et des cartes perforés. Les premières méthodes d’accès que les utilisateurs de GCOS64 vont découvrir à travers COBOL sont séquentielles ; l’organisation des fichiers fait partie du standard COBOL.

Cependant, l’arrivée de nouveaux équipements comme les tambours magnétiques, mais surtout les disques magnétiques, vont autoriser la mise en œuvre d’autres modes d’adressages, bien mieux adaptés à la gestion des données que la simple lecture séquentielle. Le système MULTICS de Gambetta, installé en 72 pour la software factory des équipes parisiennes est équipé d’un tambour magnétique qui sert à gérer la mémoire virtuelle qui nécessite un accès direct aux pages de mémoire en « backing store ». Les tambours sont des équipements très fragiles, coûteux, qui seront très rapidement supplantés par les disques, beaucoup plus robustes.

Les disques vont permettre de développer des méthodes d’accès dites directes, où l’on peut adresser à la demande, via une adresse disque, le bloc qui contient les données intéressantes, sans avoir besoin de balayer tout le fichier. A côtés des enregistrements séquentiels, on peut aménager des zones d’extension pour des informations complémentaires. Une méthode d’accès comme MLDS, très populaire sur les petits systèmes GE58 et L62, préfigure en bien plus simple ce qui deviendra les bases de données.

Toutefois, il est clair pour tous que les fichiers indexés, mono puis multi index, mais surtout les bases de données vont connaître un développement très important. C’est l’époque où R.L.Nolan, un professeur de Harvard, très écouté des cabinets de consultants (et de nos stratèges du marketing), formule les lois dites de Nolan[10], qui théorisent l’évolution prévisible du data management dans les organisations, et la montée inexorable des bases de données. Mais rien ne laissait présager que la formidable accélération des années 80s se produirait aussi rapidement, tant la technologie s’était améliorée, en vitesse, mais surtout en capacité et en fiabilité.

Il était également clair que dans cette partie décisive, le hardware allait être mis à contribution. L’accès direct nécessitait des calculs de clé d’index très fréquents, d’où l’idée de mettre dans l’« interior decor » une instruction facilitant ce type de traitement, i.e. l’instruction HASH dont l’originalité mérite d’être expliquée. A partir d’une chaîne de caractères de longueur quelconque, mais , l’instruction HASH calculait une clé aléatoire sur 32 bits. Les algorithmes de hachage avaient fait l’objet de nombreuses études[11], et certains de ces algorithmes étaient expliqués dans le Knuth. Celui proposé via l’instruction HASH était vraiment très efficace, étalant très bien les clés, même pour des chaînes de caractères très voisines. Cependant une clé de 32 bits est une très grande clé qu’il fallait ramener dans un espace plus restreint de type 8 ou 16 bits, comme dans les pages ou les CI (intervalle de contrôle) de la méthode d’accès UFAS. Il fallait donc passer d’une clé de 32 bits à une clé beaucoup plus petite, sans perturber la distribution aléatoire des clés. La bonne technique consistait à diviser la clé par un nombre premier ad hoc, et ne surtout pas la tronquer brutalement car cela avait pour effet de détruire la randomisation, comme j’ai eu l’occasion de l’expliquer à beaucoup de développeurs GCOS. C’était bien sûr une instruction très utilisée dans les compilateurs pour gérer les tables de symboles, les tables de mots réservés (pour lesquels on pouvait construire des hachages « parfaits » sans collision), etc.

Il est impossible, pour les bases de données, de ne pas évoquer la mémoire de Charlie Bachman, une personnalité de premier plan, récipiendaire d’un Turing Award, décerné par l’ACM pour ses travaux sur le modèle réseau via le comité CODASYL, et inventeur du SGBD IDS1, puis IDS2 qui était le fleuron des système GCOS8, puis GCOS7 ; un vrai pionnier des bases de données. Le SGBD IDS2 était très supérieur à l’offre IBM IMS/DL1 sur les grands systèmes, mais bien sûr IBM travaillait déjà sur le modèle relationnel !

Charlie, que j’ai eu l’occasion de fréquenter d’assez près, à l’époque où Michel Rocher m’avait proposé de représenter Bull aux comités de normalisation à l’AFNOR et à l’ISO. Charlie étant membre du comité ANSI, avait également été l’un des contributeurs majeurs d’un rapport très célèbre dans le monde des bases de données connu sous l’appellation Rapport ANSI/SPARC. C’était une chance pour un jeune ingénieur de travailler avec lui car outre sa très grande culture, il était une source d’information et d’inspiration de toute première main.

5    Les débuts d’IDS2

Le rapport ANSI/SPARC réglait de façon définitive une des questions fondamentales posée par les bases de données, à savoir : comment faire évoluer la structure de la base sans avoir à recompiler (et donc re-valider) tous les programmes utilisateurs ? Problème connu comme celui de l’indépendance des données et des programmes, toujours actuel comme on l’a vu avec l’an 2000 et le passage à l’Euro.

Dans le SGBD IDS2, cela se faisait avec les notions de schémas et de sous schémas. Le schéma correspondait au modèle logique de la base de données complète ; le sous-schéma était une « vue » d’un sous-ensemble cohérent des données, utilisé dans tel ou tel programme, puis telle ou telle transaction quand tout la programmation de gestion bascula dans le transactionnel. Tous cela revenait à encapsuler soigneusement les données avec les programmes les utilisant ; c’était déjà de l’objet, avant même que le terme fut inventé, 15 ans plus tard !

Schémas et sous-schémas étaient écrits à l’aide du DDL, i.e. Data Definition Language.

Le DDL permettait de définir les structures de données nécessaires aux concepteurs de bases de données, structures hiérarchiques arborescentes bien sûr, mais surtout structures en réseaux sémantiques grâce à la notion de relation introduite explicitement dans le langage. C’était du modèle Entité-Relation-Attributs (ERA) à l’état pur, conforme aux orientations générales du rapport SPARC. Peter Chen, du MIT, suite à des discussions avec Bachman, avait donné une définition du modèle dans un article resté célèbre[12], complété quelques années plus tard par celui de Toby Theorey[13] ; mais bien sûr nous n’avions pas besoin de ces articles pour maîtrise notre sujet. Pour être parfaitement modeste, il faut dire que le modèle ERA ne devait rien aux informaticiens. Ce n’était ni plus ni moins que la théorie des ensembles et la théorie des relations, avec une pincée de logique, adaptées aux données informatiques. La bibliothèque personnelle de Bachman contenait d’ailleurs toutes les références utiles sur le sujet.

Le DML, Data Manipulation Language, permettait la manipulation des données ainsi modélisées. Il avait été conçu comme une extension de la norme COBOL 74, conforme au NDL (Network Data Language). Le langage était dit navigationnel car, à l’aide des instructions du langage, en particulier la FIND, le programmeur pouvait parcourir la structure, de record en record, jusqu’au but recherché. La communication que Bachman avait faite à l’occasion de son Turing Award s’intitulait d’ailleurs « The programmer as navigator ». La technique de navigation était à la fois un point fort et un point faible du modèle réseau NDL.

Point fort en ce sens que le programmeur savait exactement ce qu’il faisait, en particulier en matière de performance, ce qui était, et est toujours, une contrainte critique des bases de données. Point faible, car la navigation était considérée comme une programmation difficile, ce qui est objectivement vrai, pas tout à fait à la portée du programmeur COBOL moyen habitué au bons vieux fichiers séquentiels (les index étaient déjà considérés comme difficiles !). Maîtriser les subtilités du schéma et des sous-schémas nécessitait une vraie compétence, et surtout il fallait parfaitement comprendre la logique de l’architecture de la base de données : c’était du travail pour les architectes.

Pour concevoir puis spécifier les bases de données, Bachman avait inventé un langage graphique sous forme de diagrammes, que toute la communauté informatique de l’époque appelait les diagrammes de Bachman ; c’était en fait un modèle de classes, pour parler moderne, en quelques sortes de l’UML avec 20 ans d’avance, les IHM en moins, les terminaux graphiques n’étant pas encore inventés !

Les travaux de développement du produit IDS2 sur GCOS7 avaient démarré initialement à Billerica, puis avaient été repris à Paris lors du transfert de tous les développements, après une solide formation de toute l’équipe sur place. Le responsable de la nouvelle équipe qu’il avait fallu créer de toute pièce était Robert Fayot, un architecte et un ingénieur de première force, à qui revenait la mission difficile de « sortir » la première version.

Robert, avec qui j’ai travaillé directement pendant environ deux ans (j’avais développé la première version du pré-processeur DML, et les outils d’analyse syntaxique qui plus tard deviendraient le SDL, Syntax Description Language, de la compiler factory) était vraiment une personnalité et un chef de produit exceptionnel. Quelques anecdotes personnelles pour bien cerner la rigueur de pensée qu’il déployait dans tout ce qu’il faisait ; de nature modeste, c’était sa marque de fabrique, en quelque sorte son sceaux.

Les tables générées à partir du DDL étaient évidemment d’une très grande complexité. Spécifier et documenter ces tables dont tout dépendait, était une exigence qualité fondamentale pour garantir l’intégrité du produit et la compréhension qu’en avait toute l’équipe. Robert avait immédiatement compris que les diagrammes de Bachman s’appliquait parfaitement à la description des tables internes d’IDS2, ce qui fait que tout le design de ces tables cruciales fut réalisé à l’aide des diagrammes de Bachman ; c’était de la vraie bonne méthodologie, éclairée par une vision architecturale qui lui donnait tout son sens.

Les performances étaient un autre problème particulièrement critique de l’implémentation d’IDS2, et cela d’autant plus que le produit était tributaire d’UFAS pour le stockage des données, de TDS pour le transactionnel, d’IQS pour l’info-centre, et de toutes les fonctions de GCOS pour gérer la concurrence, le partage, les caches, etc. Il était donc essentiel de bien mesurer la consommation des ressources CPU, les entrées-sorties, la mémoire dans IDS2 lui-même, indépendamment du reste du système. Là encore, Robert réussit un classique du genre en intégrant d’entrée de jeu dans le produit une métrologie des performance permettant d’analyser en clair les résultats des mesures, dans la logique du produit ; c’était beaucoup plus simple que de procéder à posteriori, avec un produit comme SBR, i.e. du vrai bon capacity planning et une vraie leçon d’architecture testable.

Enfin, dernière anecdote, concernant la qualité du produit du point de vue des défauts résiduels. Robert était un vrai maniaque de la qualité, et lui même était un programmeur exceptionnel, programmant véritablement sans erreur (un club très fermé ne concernant pas plus de dix personnes, dans toute l’équipe GCOS qui en comptait environ 500 au pic d’effectif), ce qui ne l’empêchait pas d’être très exigeant en matière de tests, pour lui-même et pour les autres. Dans sa déontologie d’ingénieur, il était totalement exclu de livrer un module de code dont il pensait qu’il n’avait pas été testé à fond, y compris en robustesse. Cela n’allait pas sans quelques frictions avec le management parfois, mais c’est lui qui avait bien sûr raison. A l’époque, nous avions un débat de fond sur la méthode de test dite des couvertures[14] qui avait donné des résultats exceptionnels sur les compilateurs, mais que les responsables du noyau considéraient comme mal adaptée à la programmation événementielle, jugée plus délicate que la programmation d’algorithmes fussent-ils extrêmement complexes comme ceux des générateurs de code. Robert qui était un pragmatique, détestant les débats théoriques, montra (en cela bien aidé par un de ses adjoints, Christian Roussel) que cela marchait très bien avec IDS2, levant ainsi toutes les réserves de principe que pouvaient avoir ses collègues du noyau : il fallait simplement être imaginatif !

6    L’information centre et les débuts du relationnel

Comme on l’a vu rapidement ci-dessus, la programmation en DML n’était pas des plus facile. Il y avait une vraie difficulté pour les utilisateurs souhaitant programmer des requêtes inopinées sur leurs données, et ceci en évitant les lourdeurs des schémas, du COBOL, etc. complètement inadaptées au besoin de ce que l’on commençait à appeler les « information centre ».

Dans l’héritage des produits venant de la fusion de CII dans Honeywell-Bull, il y avait un produit très original résultat des travaux de Jean-Raymond Abrial : le SGBD SOCRATE. JR.Abrial était également une personnalité d’exception, du même calibre que Ch.Bachman, aimant plutôt travailler en solitaire, en totale liberté et hors de toute contrainte, inventeur du langage Z, etc. C’était, au sens littéral, l’inventeur de SOCRATE qui était un SGBD en modèle réseau, mais évidemment totalement incompatible avec IDS2. Dans la philosophie Honeywell-Bull axée sur les standards, SOCRATE n’avait aucune chance, mais le langage de manipulation de SOCRATE qui était plus orienté info-centre que ne l’était le DML, pouvait venir combler un vide qui devenait de plus en plus problématique.

C’est sur cette base que fut lancé le projet IQS (Interactive Query System), dont la responsabilité fut confiée à Jean-Jacques Laclaverie, un des piliers de SOCRATE à la CII, également très bon architecte, dans un registre très IHM et facilités d’emploi. Le produit interfacé avec UFAS et IDS2 pour les données, avec TDS pour le transactionnel fut un très grand succès, bien accueilli par les clients GCOS7 ; tout le mérite en revient à Jean-Jacques et à son équipe qui firent un travail magnifique.

Dans le courant des années 80s, grâce à tous ces développements, et d’autres dont on n’a pas parlé faute de place comme les journaux, le dictionnaire de données, le GAC, etc., CII-Honeywell-Bull disposait d’une équipe de première force, tout à fait capable de relever le défit du relationnel.

Au début des années 80s, le relationnel avait déjà une longue histoire derrière lui ; un prototype avait même été développé sur MULTICS, i.e. MRDS (MULTICS Relationnal Data Store). Les deux normes NDL et SQL avaient été éditées simultanément, bien que la norme NDL/CODASYL ait été prête bien avant la norme SQL. Mais le comité ISO n’avait pas voulu favoriser l’une par rapport à l’autre. Avec le relationnel, IBM avait joué très en finesse ; tout le contraire de ce qui s’était passé avec le PL1 dont l’échec était désormais patent. Une anecdote significative sur l’état d’esprit qui régnait dans le comité AFNOR, lui-même représenté à l’ISO, permet de bien se représenter les enjeux de cet affrontement industriel, et les comportements des uns et des autres. A l’AFNOR, on discutait de trois modèles : le modèle CODASYL/IDS2 proposé par Honeywell-Bull, le modèle franco-français SOCRATE proposé par CII et soutenu par l’INRIA, et le modèle relationnel proposé par IBM France ; épisodiquement, on entendait également parler d’ADABAS, le SGBD allemand. En bon gaulois, les tenants du modèle NDL avec ses deux implémentations (i.e. IDS2 et SOCRATE) guerroyaient entre-eux sur les mérites comparés des deux approches, avec des arguments quasi métaphysiques qui aujourd’hui feraient sourire si ce n’était l’importance industrielle des enjeux, et tout cela sous l’œil malicieux de Philippe Genuys, représentait IBM France, qui se contentait de compter les coups, et soufflait sur les braises quand le débat avait tendance à se calmer ; son but était évidemment de gagner du temps en faveur du SQL. Ph.Genuys, de la direction scientifique d’IBM France, était également un tempérament, une grosse pointure comme on dit, très connu dans la communauté informatique française, un homme d’une grande distinction, qui me donna une première leçon de stratégie industrielle lorsqu’il choisit de s’exprimer en français[15] dans les réunions ISO (NB : le français est une des langues officielle de l’ONU, donc de l’ISO), ce qui avait comme première conséquence de ralentir considérablement les débats, sans critiquer personne : du grand art !

Il y avait pourtant beaucoup à dire et à faire à propos du relationnel, où il y avait un affrontement féroce chez les américains entre les tenants de SQL et les tenants de QUEL (le futur langage du SGBD INGRES), mais cela ne transparaissait pas dans les organismes de normalisation, discipline anglo-saxonne oblige ! Même chez IBM, les débats étaient très chauds, puisque Ted Codd lui-même, l’inventeur du modèle relationnel, IBM fellow de surcroît, dut se rétracter après avoir violemment et publiquement critiqué une position défendue par IBM : un crime de lèse majesté qui le conduisit à quitter IBM peu après. Tout cela fit que la première annonce d’un produit commercial conforme au standard fut celle d’ORACLE, en 81 ou 82.

Chez Bull, il y avait un très grand scepticisme sur la capacité du modèle relationnel à tenir les performances, en particulier sur les transactionnels lourds où le couple IDS2-TDS gagnait quasiment tout ses benchmarks sur le couple IMS/IMS-TP/DL1. Ce scepticisme était justifié, compte tenu du haut niveau d’abstraction du langage SQL où la navigation avait complètement disparue au bénéfice de manipulations par des opérations de type algébrique sur les t-uples (i.e. les records, dans la terminologie du relationnel) ; le processus de compilation du langage, et surtout l’optimisation, était complexe, beaucoup de choses devant se faire dynamiquement, mais la vraie bonne question était surtout de savoir si ce scepticisme était fondé, c’est à dire sans solution technique : on connaît la réponse !

Avec le relationnel, IBM et les universités californiennes, en particulier Berkeley, réussirent à faire basculer tout le milieu académique dans SQL. Les Ph.D. de Berkeley, dont beaucoup travaillaient pour M.Stonebraker et ses deux collègues fondateurs de INGRES, tous trois professeurs à Berkeley, démontrèrent qu’il était possible d’optimiser les requêtes SQL avec des techniques directement issues des travaux sur la compilation ; d’autres s’employèrent à inventer des mécanismes de caches vraiment « intelligents ». Bref, le scepticisme initial était progressivement, mais radicalement balayé. Sur les aspects performances, l’effort de R&D d’IBM, à San José, fut évidemment décisif, avec l’annonce de DB2, très supérieur au produit initial SQL-DS (programmé en PL1) issu des laboratoires. La nouvelle offre tua instantanément des sociétés comme CULLINET (avec laquelle nous avions des discussions à propos des L4G) qui avait tout misé sur le NDL avec une offre IDMS, ADS-On-Line, etc. : une excellente gamme de produits mais exclusivement sur IBM, doublée d’une offre progiciels de type ERP.

Pour l’équipe GCOS7, le débat était relativement cornélien car le dilemme stratégique était : IDS2-IQS base de l’offre GCOS7 ou plus rien du tout pendant 4-5 ans si l’on voulait se mettre sérieusement au relationnel, alors que chez IBM, c’était IMS/DL1 (sans oublier l’étoile montante CICS, d’IBM UK) et le relationnel. Pour vraiment lutter, il aurait fallu d’autres choix stratégiques au niveau de la direction générale de Bull, comme par exemple éviter de s’embarquer dans l’aventure sans issue de l’IA avec le CEDIAG, mais ceci est une autre histoire !

Pour disposer d’une offre relationnelle, il ne restait plus à Bull que la solution du portage d’un produit existant. Après discussion et analyse des offres, et quelques voyages en Californie, ce fut finalement l’offre ORACLE qui fut proposée à la direction générale de Bull. Quoique moins original du point de vue innovation que INGRES, le produit ORACLE avait été d’entrée de jeu conçu en vue d’être porté sur de nombreuses plates-formes. Développé initialement en C sur VAX/VMS qui servait de software factory, à Palo-Alto tout à coté de Stanford, par une petite équipe[16] dirigée par le très charismatique Larry Ellison, l’architecture était tout à fait remarquable, montrant qu’en matière de portabilité, comme d’ailleurs de performance, c’est l’architecture qui fait toujours la décision. Les adhérences du noyau ORACLE au système d’exploitation sous-jacent étaient soigneusement contrôlées par une couche d’interfaces appelées OS-Dependent Routines, qui encapsulaient complètement l’OS. Pour porter le produit, il suffisait de reprogrammer les OSD, et tout le reste suivait. C’était du MDA (Model Driven Architecture, la dernière idée de l’OMG pour redorer le blason UML), avec vingt ans d’avance. Sur GCOS7, qui n’avait rien de commun avec VMS, le volume de programmation HPL nécessaire pour les OSD était de l’ordre de 30.000 lignes source : chapeau pour les architectes d’ORACLE, c’était une performance vraiment bluffante, une preuve absolue de la qualité de l’architecture du produit. Le portage d’ORACLE fut également l’occasion de réaliser, dans un délai très court, un compilateur C dans la nouvelle architecture OIL-CCG, bien intégré à GCOS7. Si ma mémoire est bonne, aucune modification de GCOS7 ne fut nécessaire au portage d’ORACLE, et les seuls problèmes rencontrés venaient du langage C lui-même, un « mauvais » langage au yeux des puristes, que les programmeurs aimaient bien car ils pouvaient bricoler, dont il existait de nombreux dialectes présentant quelques différences avec le standard qui venait de sortir ; mais c’était du second ordre ! C’est ainsi que démarra la coopération de Bull avec ORACLE qui devint le fournisseur attitré de la technologie relationnelle pour Bull.

7    Passé, présent et futur

Avec 20 à 25 ans de recul, l’aventure GCOS7 apparaît encore plus singulière que lorsque l’on était tous dans le feu de l’action.

Tous les compilateurs sont maintenant dans des architectures du type OIL-CCG. Il existe une compiler factory en Open Source via la Free Software Foundation de Richard Stallman où l’on retrouve les mêmes fonctionnalités. La performance potentielle des microprocesseurs n’est exploitable que si le compilateur « sait » organiser le code généré de façon ad hoc : le couple microprocesseur-compilateur est désormais indissociable, l’optimisation est un must ! Les outils de validation et test d’aujourd’hui sont à peine au niveau de ce dont disposait les équipes GCOS7 vers la fin des années 70s, aux IHM prêts bien sûr.

Avec les diagrammes de Bachman, le modèle de processus GCOS, le concept de transaction, les grammaires et les automates, nous avions la même richesse expressive, si ce n’est plus, que ce que l’on trouve aujourd’hui dans UML et XML réunis, sans les outils graphiques.

La rigueur logique du relationnel, sa capacité d’assimilation et son potentiel de développement, l’ont définitivement emporté sur tous ses rivaux. Les SGBD objets n’ont été qu’un intermède d’autant plus étonnant qu’ils remettaient à la mode le « vieux » concept de navigation qui reste la règle pour les structures de données complexes.

Le concept de software factory, qui était le mode de travail des équipes GCOS dès le démarrage du projet, héritage de MULTICS, est plus d’actualité que jamais, (mais l’usine à logiciel est peut être entrain de partir aux Indes ou en Chine). Il n’est qu’à regarder des environnements comme Websphere[17] pour s’en convaincre. Ce qu’on appelle aujourd’hui l’eXtreme Programming est un clone de la façon de travailler des équipes GCOS7 !

Ce qui reste pour moi un sujet d’interrogation, plus de quinze ans après mon départ de Bull, est l’étrange alchimie des équipes de développement dont certaines atteignent des sommets, en quelques années, mais jamais instantanément.

Il est clair que sans leader, il n’y a pas d’équipe, mais la compétence du leader n’est qu’une condition nécessaire, très loin d’être suffisante à elle seule. Si l’équipe n’a pas confiance en elle-même, si elle doute de ses capacités, si elle n’a pas le culte du dépassement et de la rigueur, si elle ne sait pas arbitrer ses conflits, inéluctables mais généralement enrichissants, de façon positive, elle n’atteindra pas les sommets. Dans toutes ces situations, le rôle du leader est fondamental, c’est lui le catalyseur qui fait que la situation va évoluer dans la bonne direction ou dégénérer, mais là encore ce n’est qu’une facette du problème.

Une bonne métaphore, à mon goût tout au moins, serait celle de l’orchestre de chambre, où tout le monde se doit d’être excellent à la place qui est la sienne, où chacun est tributaire des autres, où chacun à compris qu’il n’est rien sans les autres, où le leader est également un instrumentiste qui maîtrise la partition, où chacun recherche la perfection.

Le diable dit-on se cache dans les détails. Toutes les personnalités exceptionnelles qu’il m’a été donné de rencontrer durant ces vingt années passées chez Bull avaient toutes un souci du détail poussé à l’extrême, elles n’étaient jamais approximatives, toutes avaient le culte du projet.

Les équipes de développement, les projets en général, sont des structures humaines hautement instables où l’on est toujours surpris de la vitesse à laquelle le chaos peut se manifester. Quelques mois suffisent à détruire une construction qui a mis plusieurs années à naître, croître et se développer. Les conditions initiales du lancement, et le système immunitaire qui les accompagne, i.e. la rigueur architecturale et la méthode, jouent également un rôle déterminant. Il me paraît clair que ceux qui ont donné l’impetus initial du projet GCOS7, par leurs actes et leurs choix architecturaux, par l’attrait technique et le défi que représentait le projet pour des jeunes ingénieurs tout frais sortis du cocon de leurs écoles, ont su créer les conditions d’un exceptionnel succès dont ce trentenaire est le témoignage.