Historique du système d'exploitation GCOS 7        

 

Claude CARRÉ

 

Septembre 2004


Table des matières

 

Contexte historique. 3

Période General Electric (1967-1970) 3

Premières ébauches. 3

Shangri-la. 3

Phase post-Shangri-la. 3

Fusion General Electric / Honeywell (1er semestre 1970) 5

Période Honeywell (à partir de mi-1970) et post-Honeywell 5

Responsabilités. 5

Les besoins marketing. 5

Élaboration de l'architecture du système d'exploitation. 6

Architecture. 7

Principes. 7

Espace d'adresse. 7

Protection. 8

Interactif et transactionnel 8

Performances. 9

Outils de développement du logiciel (Software Factory) 10

Langages de développement 10

Systèmes de développement sur Multics. 10

Mise au point sur systèmes P7. 10

Maintenabilité et opérabilité. 12

Système "fermé" 12

Support des grands clients. 12

Maintenance. 12

Ergonomie. 12

Conclusion. 13

Annexe 1 : Glossaire. 15

Annexe 2 : Schéma de fonctionnement d'une Entrée / Sortie. 16

 

Contexte historique

Période General Electric (1967-1970)

Premières ébauches

Fin 1966, General Electric arrête les études et la commercialisation (qui en était à ses débuts) du système Gamma 140 au profit du GE 400. En 1967, le département Etudes de Bull (BGE à l'époque) se trouve donc sans objectifs. C'est un vivier pour la CII en cours de création.

Un petit groupe d'ingénieurs (citons Georges Lepicard, François Sallé, Claude Chemla, Jacques Bienvenu, Henri Verdier, Claude Carré) réfléchit à l'architecture d'un système futur (Charlie Project). Les propositions sont probablement suffisamment intéressantes pour que General Electric les intègre à ses propres recherches en 1968 pour définir une nouvelle ligne de produits : l'APL (Advanced Product Line).

 

Toutes les études de l'époque General Electric étaient plutôt exclusivement menées par "l'engineering". Quelques personnes "product planning" (par exemple Philippe Buck) ont participé à plusieurs reprises à l'élaboration des spécifications; mais jamais n'a alors existé une spécification fonctionnelle qui eût pu être utilisée comme fil directeur par l'engineering.

 

Les premières études relatives au logiciel eurent réellement lieu en 1968 : écriture d'une spécification fonctionnelle (en dehors du product planning) par Jean Bellec.

Simultanément était élaboré à Phoenix pour General Electric par des anciens de Burroughs (entre autres Cal Zaethraeus, Jack Merner) au sein de la division recherche dirigée par John Weil un langage de développement de système de haut niveau, alors spécifique et appelé Q-language.

Shangri-la

Le chant du cygne de General Electric fut de tenter de définir une offre globale produits en 1969 au cours d'un séminaire de plusieurs mois en Floride (appelé "Shangri-La"). Concernant le logiciel d'exploitation, le résultat fut d'abord quelque peu confus entre les tenants d'un logiciel unique d'un bout à l'autre de la gamme – unicité qui aurait été, d'après eux, permise par les vertus supposées miraculeuses de la pagination -, et ceux qui prônaient des systèmes différents et adaptés à la taille de la configuration matériel. Cette dernière position était évidemment plus réaliste alors que le coût et les performances du matériel de cette époque limitaient fortement les ambitions logicielles.

À ce propos, il était notoire que Multics à ses débuts se faisait un prosélyte du tabagisme : On avait le temps de fumer une cigarette entre l'envoi d'une commande depuis le clavier d'un terminal et la réponse de la machine et cela n'était pas fait exprès pour faire une faveur aux fabricants de tabac.

 

Par ailleurs la recommandation de développer plusieurs systèmes n'était pas non plus innocente sur le plan des ambitions nationales, car elle permettait de maintenir et développer des centres de compétence – matériel et logiciel - à Pregnana (petits systèmes), à Paris (systèmes moyens) et à Phoenix (grands systèmes).

 

Après que cette dernière solution l'eut emporté , le débat se limita pour les moyens / grands systèmes à des discussions et argumentations sans fin sur les mérites et inconvénients respectifs de la pagination et/ou de la segmentation des programmes, celle-ci étant mise en avant prioritairement par les "Multicsiens" et les anciens de Burroughs de la division recherche de GE, celle-là par ceux qui vantaient les mérites de l'IBM 360/67 ou avaient peut-être des informations ou des pressentiments sur les annonces qu'IBM allait faire un an plus tard.

Phase post-Shangri-la

La phase post Shangri-la et pré-fusion avec Honeywell fut complètement engineering. Une organisation très orientée projet –il vaudrait d'ailleurs mieux dire "très orientée PERT", car la direction du projet était essentiellement exercée par des "project managers" qui se souciaient plus du respect du calendrier que de la qualité des spécifications émises a été mise en place.

 

Le management du logiciel était sous la responsabilité d'un ancien directeur d'un projet de système d'exploitation spécial basé sur matériel GE 600 modifié (défini et réalisé à Schenectady), lequel prétendait, à notre grand étonnement, que structurellement un processus n'avait jamais besoin d'accéder à un espace d'adresse de plus de… 21 segments.

C'est ainsi que plusieurs d'entre nous séjournèrent pendant plusieurs semaines au début de 1970 à Bridgeport (Connecticut) dans une ancienne usine électrique de GE. Les spécifications des interfaces du système d'exploitation avec les programmes d'application étaient confiées à un 'team" de trois ingénieurs (Ross Park de Phoenix, moi-même et un troisième larron dont je ne me souviens plus du nom). Il faut noter que les spécifications correspondantes des systèmes OS/MFT et MVT d'IBM constituaient pour nous une base de départ plus importante que celles des systèmes des GE 400 et 600.


Fusion General Electric / Honeywell (1er semestre 1970)

À la fusion avec Honeywell, l'état des études d'architecture du logiciel d'exploitation a été documentée (Overview of the APL Operating System - Jean Bellec, André Bensoussan, Claude Carré). La cohérence de ce document, bien que ne traitant pas encore de toutes les facettes d'un système d'exploitation, a certainement été très utile dans la définition des affectations de responsabilités qui allaient suivre.

 

Le cœur du système s'inspirait à la fois :

·       des travaux de E.W. Dijkstra sur :

§   l'architecture en niveaux de complexité croissante et ne communicant que par interfaces définies,

§   les processus et leur synchronisation par sémaphores (avec les célèbres opérations P et V);

·       des apports du système Multics, en particulier :

§   la segmentation des programmes et la mémoire virtuelle,

§   les propriétés des processus avec leur espace d'adresse segmenté (avec pagination possible des segments, mais non prioritaire) et leur pile (procedure stack) d'appel et de retour de procédure (la normalisation de Multics suivant la structure en niveaux de Dijkstra avait déjà été opérée par André Bensoussan),

§   les niveaux de privilège ou anneaux de protection (protection rings),

§   l'écriture du système dans un langage de haut niveau sous-ensemble de PL/1 se substituant au langage propriétaire Q-Language.

·       de la compatibilité avec IBM pour les fichiers :

§   compatibilité totale pour les fichiers sur mémoire secondaire (disques et bandes magnétiques) de types séquentiel, séquentiel indexé (utilisant des enregistrements de longueur variable sur disques et une clé reconnue par le matériel des contrôleurs de disques) et aléatoire,

§   analogie du système de fichiers (catalogue) optionnel et non intégré au cœur du système d'exploitation (à la différence de Multics).

 

Période Honeywell (à partir de mi-1970) et post-Honeywell

Responsabilités

Très vite après la fusion avec Honeywell, les responsabilités "système" ont été définies : L'affectation "nationaliste" telle qu'existante du temps de General Electric fut conservée, avec un élément de complexité supplémentaire : Il fallait faire de la place aux équipes engineering de Honeywell de Boston (Waltham et Billerica). Dans ce but, le système d'exploitation moyen a été subdivisé en "moyen inférieur" ou "Level 2A" -responsabilité à Paris-, et "moyen supérieur" ou "Level 2B" -responsabilité à Waltham.

Les deux systèmes d'exploitation devaient pouvoir s'exécuter à la fois sur un matériel "moyen inférieur" P7A défini et réalisé en France et un "moyen supérieur" P7B à Billerica. D'ailleurs, on retrouvera sensiblement la même problématique cinq ans plus tard lors de la fusion franco-française entre Honeywell Bull et CII, avec des décisions initiales analogues faites pour satisfaire les orgueils locaux, mais qui ne résisteront pas plus longtemps à la logique économique et au bon sens.

Pour simplifier et dans une optique de concurrence entre équipes et de réduction de coûts très illusoire, car génératrice de discussions sans fin et stériles entre Boston et Paris, il avait été décidé de plus que le système de fichiers, les méthodes d'accès aux fichiers, les interfaces télécommunications de Cobol et les compilateurs seraient communs entre Level 2A et Level 2B.

Pour corser l'affaire, le matériel P7B comme le système logiciel Level 2B manquaient de direction technique solide et unique; leurs spécifications collectionnaient tous les mécanismes alors en vogue dans le monde des main frames; en conséquence de quoi par exemple, pagination et segmentation figuraient évidemment au programme de même que l'allocation dynamique généralisée des ressources aux programmes.

L'arrêt du projet Level 2B interviendra en 1972 (et celui de P7B un peu plus tard). Dans la suite de ce document, les systèmes matériel P7B et logiciel Level 2B ne seront plus évoqués; nous parlerons uniquement de P7 et Level 2.

Les besoins marketing

Les systèmes moyens avaient comme objectifs :

·       la reprise des clients GE Gamma 100 (systèmes réalisés en Italie),

·       la reprise des clients Honeywell H 200 (et H 2000 plus tard, car en 1970, ces systèmes étaient encore commercialisés et des équipes matériel et logiciel H 2000 à Boston développaient des nouvelles versions),

·       la conquête de nouveaux clients, essentiellement des clients IBM qui se trouvaient confrontés à la transition IBM 360/30 vers le 370, le système IBM 370/145, le premier de la série 370 ayant été annoncé en septembre 1970.

La transition de ces systèmes vers le P7/Level 2 serait facilitée par des émulateurs (voir ce chapitre) pour éviter que les clients soient tentés par des offres concurrentes.

 

Les coûts du matériel limitaient singulièrement les configurations : Un système d'entrée devait se contenter d'une mémoire centrale de 192 K octets (pour 64 K octets vendus) et de deux disques amovibles de 17 M octets chacun. Avec cette configuration, on devait pouvoir exécuter un émulateur, un gestionnaire d'imprimante (output writer) et un petit programme d'application auquel pouvait être substitué, le cas échéant, un gestionnaire de lecteur de cartes perforées (input reader).

Le système devait traiter uniquement des lots de programmes introduits sur cartes perforées (batch processing), limitation d'ailleurs affirmée par note explicite du directeur de l'architecture de la nouvelle ligne en 1972. Les lignes de télécommunications avaient seulement pour but l'échange de données entre des terminaux (ou des appareils de lecture / perforation de bandes perforées) et des programmes Cobol.

Élaboration de l'architecture du système d'exploitation

L'architecture – matériel et logiciel - de la nouvelle ligne de Honeywell (NPL) était (ou était supposée être?) coordonnée entre les différentes organisations d'études (Phoenix, Boston, Paris, Milan) par un "Technical Office" sous la direction d'Ugo Gagliardi. En fait, chaque entité sous la direction d'un "Mission Assignee" (Marc Bourin pour les systèmes moyens) gardait une grande liberté de choix, ce qui était, vu de chacune de ces entités, à la fois une bonne chose évidemment pour ce qui les concernait personnellement et une chose très critiquable pour ce qui relevait des autres équipes…

Objectivement nous pouvons penser que l'absence de compatibilité ascendante complète entre Level 1 (devenu GCOS 62 à l'annonce en 1974) et Level 2 a coûté assez cher lors de la reprise du premier par le deuxième à la fin des années 1980. Mais que dire de la quasi absence de synergie entre des systèmes aussi différents que P7/Level 2 et les successeurs du GE 600 avec GCOS 3 devenu GCOS 66 puis GCOS 8 qui ont remplacé les projets P8/Level 3 de la NPL morts-nés ? Quasi absence qui a imposé le coût pendant des décennies d'équipes de développement et support dupliquées.

 

Pour ce qui est du logiciel Level 2, la définition du système a conservé les principes déjà énoncés plus haut et tels que documentés début 1970. Ceux-ci sont détaillés dans les sections suivantes.

Architecture

Principes

Un programme est défini comme un ensemble ou Groupe de Processus ou Process Group.

Chaque processus (on dirait maintenant thread) dispose d'un espace d"adresse (voir ci-dessous), c'est à dire de segments en propre qui contiennent les données statiques (au sens de Cobol) ou les piles (stack) d'appel/retour de procédure du processus. Tous les processus d'un Groupe de Processus partagent des segments qui contiennent le code ou leurs données communes, les sémaphores qui leur servent à communiquer et à se synchroniser ou ceux qui règlent l'accès aux données communes.

 

En fait, la plupart des programmes d'application usuels, tels que les compilateurs, les éditeurs, sont des Groupe de Processus mono-processus. Les Groupes de Processus multiprocessus sont destinés à des serveurs tels que les émulateurs (voir ce chapitre), les sous-systèmes transactionnels (TDS) ou UNIX (OPEN 7) et certains gestionnaires de périphériques (gestion de plusieurs imprimantes, par exemple).

 

Le système d'exploitation lui-même est un Groupe de Processus multiprocessus et il correspond avec les contrôleurs matériels de périphériques ou de télécommunications par l'intermédiaire de sémaphores, car ceux-ci sont vus du logiciel comme s'ils étaient des processus.

 

Chaque programme compilé donne naissance à une Unité de Compilation (ou Compile Unit, CU). Le format d'une CU n'est pas dépendant du langage source, ce qui permet la construction de programmes multi-CU et multilangages. C'est l'Éditeur de Liens (ou Static Linker) qui, avant exécution, réunit plusieurs Unités de Compilation et prépare les programmes pour être exécutés sous forme de modules chargeables (ou Load Modules, LM).

 

Pour qu'un programme puisse être exécuté, il faut donc préciser avant son exécution le nom du LM correspondant, les noms des fichiers et des terminaux qui lui seront nécessaires et la taille de mémoire centrale recommandée. Bien que le mécanisme de mémoire virtuelle permette en théorie de faire abstraction de cette dernière information, elle est nécessaire en pratique pour éviter les surcharges qui conduisent au thrashing, situation où le système d'exploitation passe plus de temps à se gérer lui-même qu'à réaliser des travaux utiles.

Les informations précédentes ainsi que celles relatives au séquencement des programmes sont fournies par le Job Control Language (ou JCL). Celui-ci fait une large utilisation de mots-clés pour en faciliter la lecture.

 

Lorsque l'accès interactif (Time-Sharing ou IOF pour Interactive Operator Facility) sera fourni en 1983, les principes énoncés ci-dessus resteront applicables. Néanmoins un langage de commande plus adapté au mode interactif sera alors réalisé, ce sera le GCL (pour GCOS Command Language).

Espace d'adresse

Toute instruction et toute donnée du système d'exploitation ou des programmes d'application appartiennent à des segments.

Les compilateurs ne génèrent que des segments de code purs où l'écriture est interdite par mécanisme matériel au cours de l'exécution de chaque instruction. On évite ainsi l'autodestruction potentielle accidentelle des programmes, cauchemar de beaucoup de systèmes et tous les programmes sont réentrants.

Les constantes sont aussi regroupées dans des segments de données où l'écriture est interdite.

"L'exécution" par inadvertance de segments de données est également interdite par mécanisme matériel.

 

Les descripteurs de segments contiennent des indicateurs tels que exécution, lecture ou écriture possibles ou interdites ainsi que le niveau de privilège (anneau de protection) où ces opérations sont possibles. Les descripteurs de segments sont groupés en tables de descripteurs. Chaque table de descripteurs a un type suivant le niveau de partage des segments qu'elle décrit. :

·       Type 3 : segments qui sont propres à un processus;

·       Type 2 : segments partagés par tous les processus d'un Groupe de Processus;

·       Type 1 et type 0 : Segments partagés entre tous les processus de tous les Groupes de Processus.

 

Les segments de type 0 sont des procédures et tables du système d’exploitation, par exemple les méthodes d’accès aux fichiers (UFAS), ce qui permet une multiprogrammation de niveau automatiquement adapté à la charge instantanée du système (sans avoir à configurer le nombre de processus du système).

Les segments de type 1 peuvent être attachés et détachés dynamiquement, par exemple le traitement des transactions d’un sous-système transactionnel TDS (les Transaction Processing Routines ou TPR).

 

L'Annexe 2 présente un schéma d'utilisation des concepts de processus, sémaphores et espace d'adresse par le sous-système d'entrées / sorties.

Protection

On a vu précédemment le haut niveau de protection qu'autorise la segmentation des programmes.

La pagination des segments introduite dans les années 1980 a été uniquement destinée à permettre une gestion plus simple de la mémoire par la manipulation d'objets (les pages) tous de même taille. Mais la pagination qui est invisible à l'utilisateur ne joue aucun rôle dans la protection

 

En outre, 4 niveaux de privilège ou anneaux de protection (ou protection rings), de 0 à 3 du plus privilégié au moins privilégié permettent une extension intéressante des niveaux maître et esclave qui étaient la règle jusque là : Le privilège 0 est réservé aux quelques procédures les plus critiques du système (par exemple, celles qui gèrent l'adressage de la mémoire centrale), le reste du système se satisfaisant du privilège 1. Les privilèges 2 et 3 sont disponibles pour les programmes d'application.

 

Le transfert d'un niveau vers un niveau plus privilégié n'est possible qu'à travers des points de passage obligés (appel de procédure avec ring crossing qui implique un changement automatique de pile – il y a, en effet, un segment pile par niveau de privilège).

Une instruction qui s'exécute avec un niveau de privilège donné ne peut évidemment accéder à des données dont le descripteur de segment ne permet l'accès qu'à des niveaux plus privilégiés.

Interactif et transactionnel

Le développement des fonctions transactionnelles et interactives fut l'occasion d'utiliser au mieux les concepts architecturaux qui avaient été prévus dès l'origine dans ce but.

 

Le mode transactionnel est rapidement apparu comme une nécessité commerciale : le produit TDS (Transaction Driven System) distribué sur les grands systèmes Bull était reconnu comme extrêmement compétitif; il était donc prioritaire de fournir un produit équivalent sur GCOS 64. Ce sera fait en 1977.

L'objectif était de fournir à de nombreux utilisateurs (d'abord quelques centaines, puis plusieurs milliers) l'accès à un ensemble fermé de commandes ou transactions depuis des terminaux permettant la lecture et/ou la modification de fichiers (principalement UFAS) et/ou bases de données IDS puis Oracle.

Les sous-systèmes transactionnels sont au cœur du fonctionnement des entreprises clientes; il était donc impératif de mettre l'accent sur la haute disponibilité du produit et l'intégrité des données qui furent permises par une gestion de verrous et des "journaux".

Un sous-système TDS est un groupe de processus comprenant N processus. N est défini statiquement et est très inférieur au nombre d'utilisateurs, à la fois pour des raisons d'encombrement des structures de contrôle et de limitation de l'architecture système; en conséquence, les utilisateurs sont multiplexés sur les N processus qui possèdent tous le même espace d'adresse de code et de constantes qui est partagé entre eux dans des segments de type 2.

Lorsque le nombre de transactions est important, celles-ci sont regroupées dans des tables de type 1 qui sont attachées et détachées dynamiquement des processus suivant les besoins à l'exécution.

 

Le mode interactif ou temps partagé (time sharing) correspond à l'utilisation des ressources programmes et fichiers du système par un opérateur depuis un terminal. C'était une fonction importante avant l'arrivée des ordinateurs individuels pour remédier à la lourdeur et au temps de réponse déplorable (vu des utilisateurs) du mode batch.

Le mode interactif appelé IOF (Interactive Operator Facility) sera commercialisé en 1978. Grâce aux concepts architecturaux évoqués précédemment, il n'a suscité aucun nouveau développement spécifique dans le cœur du système d'exploitation (gestion de mémoire, gestion des processus, gestion des travaux, etc.) ou dans les programmes d'application : L'exécution d'une commande d'un opérateur depuis un terminal est un groupe de processus monoprocessus comme l'était déjà auparavant un programme batch. Seules les données nécessaires à l'exécution du programme, au lieu d'être entrées depuis un fichier (créé au moment de la lecture des cartes perforées), sont lues depuis un terminal et inversement les résultats du programme au lieu d'être écrits sur un fichier (transcrit ultérieurement généralement sur une imprimante) sont envoyés au terminal.

Néanmoins des produits spécifiques à IOF ont évidemment été livrés conjointement avec celui-ci : éditeurs de texte, langage de commande GCL (GCOS Command Language) défini pour une ergonomie interactive, compilateurs de langages prévus pour la seule utilisation interactive (Basic, APL).

Performances

Les ressources matériel que le design, -disons de moyen/grand système - envisagé puis réalisé pour Level 2 a nécessitées, ont créé beaucoup de peines et bien du labeur pour essayer de "rentrer dans les clous" et cela pendant de nombreuses années. Les "clous" pour le product planning étaient initialement essentiellement représentés par le système IBM/DOS avec lequel Level 2 serait en compétition frontale.

 

D'un autre côté, les équipes engineering bostoniennes non soumises à cette contrainte, mais toujours responsables (jusqu'en début 1975) des systèmes de fichiers et des compilateurs avaient toujours tendance à demander plus de fonctionnalités. En particulier, la controverse était permanente sur le sujet de l'allocation des ressources aux programmes, statique pour Level 2, c'est à dire effectuée sinon à la construction, du moins généralement avant l'exécution, là pour le coup comme sur IBM/DOS et OS/MFT alors que Boston souhaitait le tout dynamique, c'est à dire une allocation au moment des besoins pendant l'exécution avec les risques sinon de blocage potentiel tout au moins d'overhead insupportable à l'exécution sur des petites configurations matériel.

 

Le chargement et l'exécution du logiciel Level 2 à ses débuts étaient sans doute un peu analogues au supplice que les Chinoises ont dû endurer pendant des siècles pour essayer de faire entrer leurs pieds dans des chaussures trop petites : Le système était trop gros pour la mémoire centrale, trop lent parce qu'il y avait trop d'instructions système à exécuter et trop d'entrées/ sorties sur disque dues en particulier à la mémoire virtuelle.

C'est d'ailleurs ce que John Weil dès 1973 avait pronostiqué : Lorsque le logiciel fonctionnerait, écrivait-il, il faudrait alors s'attaquer impérativement à un sévère problème de performances. Mais, à vrai dire, dans ce domaine, le pronostic n'est jamais trop difficile : Quel est le projet informatique qui n'a jamais souffert au moins à ses débuts d'un problème de performances ?

 

En ce qui concerne la mémoire virtuelle, il fallait être sur plusieurs fronts à la fois :

·       d'une part, certains architectes étaient troublés par l'annonce d'IBM de systèmes 370 purement paginés en mi-1970, alors que la segmentation pure, pour des raisons de bien meilleure sécurité des programmes, était le choix initial pour le P7 (sans exclure pour autant une pagination ultérieure des segments).

·       D'autre part, il y avait les tenants d'un système copie conforme (copycat) du DOS qui aurait, par exemple, contraint les programmeurs à la complexe tâche de définir avant exécution un découpage de leurs programmes en overlays.

 

Pour obtenir le niveau de performances souhaité, il fallait examiner à la loupe les endroits où le système d'exploitation passait l'essentiel de son temps, séquences de code et entrées/sorties sur disque, puis convaincre les programmeurs du système de revoir leur copie et améliorer certains algorithmes, bref limer, limer et encore limer… Une équipe sous la direction de Philippe de Rivet se consacrait uniquement à cette tâche. L'assistance ponctuelle de conseillers extérieurs de la CISI sous la direction de Jacques Weber fut également importante en 1975/1976 pour que le système soit nettement plus rapide que le SIRIS 8 de la CII et permettre la migration des clients de ce dernier vers le DPS 7.

Il a fallu néanmoins, pour permettre des performances correctes pendant plusieurs années à partir de l'annonce de 1974, livrer une certaine proportion de mémoire centrale cachée aux utilisateurs afin de ne pas effaroucher des clients qui n'auraient pas compris qu'un système du niveau de l'IBM DOS avait besoin d'une mémoire centrale beaucoup plus importante. À titre d'exemple, en 1974, pour un système commandé de 64 K octets, on livrait 192 K.

 

Outils de développement du logiciel (Software Factory)

Langages de développement

Très rapidement en 1970 la filiation Multics a conduit à la décision judicieuse de remplacer le langage d'implémentation Q-Language par HPL (Honeywell Programming Language), sous-ensemble de PL/1.

Celui-ci était complété par un langage d'assemblage NAL (New Assembly Language) pour les quelques modules du noyau du système qui nécessitent une optimisation poussée en performances ou bien utilisent des instructions qui ne sont pas accessibles depuis HPL. NAL accepte aussi bien les déclarations de données compatibles avec celles de HPL que les déclarations du type IBM / BAL et, de plus, toujours pour des besoins de performances, des séquences NAL peuvent être introduites dans une procédure HPL sans impliquer le coût d'un appel de procédure.

Les responsables du logiciel Level 1 n'ont pas souhaité sauter le pas HPL et sont restés fidèles au langage d'assemblage (NAL).

Pour des raisons d'organisation, un troisième langage d'implémentation du système – MLP – a aussi été utilisé (cf. le chapitre langages).

 

Systèmes de développement sur Multics

En revanche, cette même filiation Multics a aussi conduit à la décision malheureuse en 1970 d'utiliser ce dernier système comme outil de développement avant que les systèmes matériels P7 dits natifs soient disponibles. Décision malheureuse, car, à l'époque, Multics n'était pas commercialisé; le matériel n'existait qu'à l'état de quelques prototypes agrémentés de quelques pièces de rechange et il était exclu de faire fabriquer de nouveaux systèmes. En conséquence, la puissance de calcul nécessaire au développement rapide du logiciel par plusieurs dizaines d'ingénieurs de part et d'autre de l'Atlantique n'était pas au rendez-vous.

Un système multiprocesseur fut d'abord installé à Boston suivant le principe de "on n'est jamais mieux servi que par soi-même", mais aussi plus logiquement parce que les outils logiciels de développement sur Multics (compilateur SHPL, assembleur SNAL, System Linker, simulateur d'instructions) étaient produits à Boston.

Puis pour équiper Paris où était fabriqué le cœur du système, c'est à dire les modules à mettre au point en priorité, on "fabriqua" un système avec ce qui restait… Au début, pas de tambour (utilisé comme mémoire cache par le processeur central), un seul processeur, une capacité mémoire limitée, etc. Bref le système parisien ne supportait pas plus de 10 utilisateurs simultanés. La simulation d'instructions, très coûteuse en temps processeur, qui aurait pourtant été utile à la mise au point était interdite. Il fallait planifier l'utilisation des terminaux par tranches horaires et quelquefois séparer des développeurs qui pouvaient physiquement en venir aux mains pour accéder à cette ressource précieuse.

Heureusement le décalage horaire était mis à profit par les développeurs parisiens qui pouvaient se connecter le matin à travers une ligne spécialisée sur le système de Boston pendant le sommeil de leurs collègues américains.

La référence du code source était maintenue sur le système de Boston par envoi de bandes magnétiques. Puis en retour, le système de Boston générait des cartes perforées, puis aussi des bandes magnétiques contenant les premières versions du système d'exploitation. Pour ces transports transatlantiques, on utilisait les valises des nombreux voyageurs qui faisaient alors l'aller-retour et subissaient quelquefois à ce propos des questionnaires prolongés de la part des douaniers américains. Bien sûr, les systèmes générés à Boston ne marchaient pas toujours (certains diraient "fréquemment") du premier coup lorsqu'on les installait sur un prototype P7 à Paris.

Nous passerons alors sur les longues parties de ping-pong téléphoniques et "télécopieuses" engagées pour déterminer le module responsable de l'erreur et les arguties subtiles développées pour inciter un spécialiste bostonien du System Linker à venir en urgence à Paris. Le forum Multics jouait le rôle d'une messagerie électronique actuelle; il s'avérait néanmoins fort pratique aussi bien pour ces nombreux échanges que pour les communications entre développeurs, éventuellement même d'un bureau à l'autre de Gambetta !

Mise au point sur systèmes P7

On développa un petit système d'exploitation appelé SCP (System Control Program) qui se bootstrappait (s'amorçait) à partir de cartes perforées sur les premiers prototypes P7 en 1972. Ce système eut ensuite la possibilité de lire des données sur bandes et disques magnétiques.

Les cartes perforées arrivaient de Boston par avion (à raison d'un envoi au plus par jour). En cas d'erreurs ou de bourrage du lecteur de cartes, les virtuoses de la "P80" (citons Jean-Paul Mesnage, Daniel Poirson) montraient tout leur talent.

Par la suite, on remplaça petit à petit les modules embryonnaires de ce système par ceux de Level 2 - GCOS 64 pour obtenir la première version prototype de ce logiciel connue sous le nom de code J0. C'est David Slosberg qui s'attela à cette tâche difficile qui fut accomplie au premier trimestre 1973.

Le code machine correspondant venait encore, évidemment, de modules en langage source compilés par les compilateurs SHPL et SNAL de Multics. Cette situation perdura longtemps, car il fallait d'abord mettre au point les compilateurs HPL et NAL sur les prototypes P7 – Level 2. Puis il fallut convaincre les ingénieurs de développement d'abandonner SHPL et SNAL pour HPL et NAL; or, last but not least, ces derniers n'étaient plus tout à fait compatibles avec les premiers et ne bénéficiaient pas encore de la même fiabilité. C'est encore David Slosberg qui prit en charge cette transition ingrate.

Maintenabilité et opérabilité

Système "fermé"

Les clients du système étant majoritairement des entreprises moyennes, on souhaitait que les clients puissent se passer d'ingénieurs coûteux possédant des compétences système (à la différence d'IBM) et empêcher les modifications plus ou moins contrôlées du système. On voulait aussi diminuer les sources d'erreurs en clientèle et par là même les coûts de support et maintenance pour Bull.

 

De ce fait, le système a, dès le départ, été voulu "fermé", c'est à dire vu par les clients comme une boite noire, accessible uniquement à travers les run time packages des différents langages livrés.

Les langages d'implémentation du système (HPL, NAL) n'étant pas livrés, les interfaces du système disponibles aux programmeurs système ne l'étaient pas plus en clientèle. En contrepartie, cette politique a peut-être été trop généralisée et fut sans doute un des facteurs qui ne permit pas de livrer des systèmes à des centres de recherche fortement attirés par l'architecture et qui auraient souhaité, soit modifier le système d'exploitation, soit travailler sur machine nue ou même modifier certains microprogrammes (Ecole des Mines de Saint-Étienne, INRIA, Université de Grenoble).

Support des grands clients

Après 1975, le système a été livré à des grandes entreprises ou administrations (EDF, DGI, Swedish Taxes, etc.) qui possédaient souvent des équipes système importantes. La modification du système a alors été autorisée au coup par coup, sur une base contrôlée par une organisation créée spécifiquement à cet objectif en 1980 et dirigée initialement par Claude Rolland.

Un sous-ensemble du langage HPL sous le nom de GPL (GCOS Programming Language) ainsi que des interfaces vers le système et des user exits furent disponibles pour ces clients.

Maintenance

Tous les spécialistes ont souligné l'avantage sur les coûts de maintenance apporté par l'architecture du système en segments et processus : un programme qui n'est pas au point ne peut se modifier lui-même ni perturber un autre programme ou le système d'exploitation.

 

Pour pouvoir reproduire aisément les anomalies rencontrées par les clients et permettre à ceux-ci de bénéficier le plus rapidement possible de modifications et corrections dûment validées, on s'est efforcé en outre de limiter le nombre de versions du logiciel présent sur les sites des clients.

 

Enfin pour assurer un temps de correction satisfaisant sur les modules qui faisaient l'objet de développements importants avec de nouvelles versions tout en ayant d'anciennes versions présentes chez les clients, une organisation spécifique chargée de leur maintenance et/ou de légères améliorations a été mise en place; elle était placée initialement sous la responsabilité de Victor Thévenet.

Ergonomie

Dès 1975, l'ergonomie du système est devenue une préoccupation majeure : ce fut la mission d'une organisation spécifique appelée "Visibilité externe" et placée sous la direction de Marc Appell.

Des contacts ont alors été pris avec l'INRIA en vue d'améliorer l'ergonomie de l'interface de l'opérateur central avec le système. Très vite, des améliorations notables ont pu être apportées pour remédier à la logique des ingénieurs qui avait conduit quelquefois à des solutions au cartésianisme impeccable mais trop lourdes.

Conclusion

Résumé des dates clés de l'histoire du logiciel GCOS 7 :

 

Date

Évènement

Avril 1974

Mode G100, puis H200

Pas d’application native

Utilitaires natifs de gestion de périphériques

1976

Mode natif batch :

·       Programmes Cobol (et Fortran)

·       Fichiers compatibles IBM

1977

Mode transactionnel TDS

Fichiers UFAS et bases de données IDS 2

1978

Mode interactif IOF

1979

Modes SIRIS 8 et SIRIS 3

Support de frontaux télécom Datanet

Accès aux réseaux X25

1984

Support de matériels multiprocesseurs symétriques

Nouveau langage de commande GCL

Bases de données Oracle

1986

Gestion de mémoire virtuelle paginée

1990

Support de périphériques (disques, cartouches) standard du marché avec protocole SCSI

Contrôleurs d'entrées/sorties connectés sur bus standard Multibus II

200 utilisateurs IOF

1991

Support des disques miroirs

Sous-système UNIX (accès aux réseaux TCP/IP)

Mémoire centrale : 256 MO

1994

Support d’hexaprocesseurs

7000 utilisateurs TDS

 

 

Pour terminer, un témoignage, celui de Michel Vatoux :

"Tout frais émoulu de l'IRIA, je suis entré chez Bull en février 1973, j'y ai découvert sur le 64 et présent sur un seul système "tout ce dont j'avais rêvé sans jamais avoir osé le demander". Je ne puis que redire mon admiration devant les concepts de GCOS 64 et le regret que la culture du secret ait été si bien gardée chez Bull :

·       une machine à stack complète avec passage de paramètres et variables dynamiques

·       la notion interior decor de tableau (compute subscript)

·       la synchronisation par sémaphores

·       la segmentation (la pagination à l'époque n'était pas de mise)

·       la séparation naturelle entre code et données, la ré-entrance

·       une généralisation des modes Maitre et Esclave par les rings

·       l'extensibilité par la microprogrammation et la notion de modes

·       et en méthodologie de développement, le concept de software factorie :

o        écriture du système en langage de haut niveau

o        une gestion propre des primitives système via un macrogénérateur

o        les return-codes manipulables de façon symbolique

o        l'interactivité de Multics : gestion des sources, lancement des travaux

o        l'accés partagé à l'énergie informatique avec un travail en bascule sur Waltham le matin."

 

En partant (ou en dépit) d’objectifs très modestes, l’architecture définie il y a près de 35 ans fut suffisamment extensible pour satisfaire les clients actuels aux besoins importants, cela certes au prix de "quelques  souffrances" initiales…

 


Il est remarquable de noter qu'en l'espace de 35 ans, les capacités matériel supportées par le même système d'exploitation aient été augmentées dans des rapports considérables comme le montre le tableau ci-après :

 

1974 (1ère annonce)

2004

Rapport

Système monoprocesseur

De 1 à 24 processeurs (*)

24

Mémoire centrale minimum de 192 KO

Mémoire centrale jusqu'à 8 GB

40 000

Puissance CPU référence = 1

Puissance CPU = 3200

3 200

Connexion de 2 à 24 disques de 17 MO chacun

Jusqu'à 1500 GB

40 000

Pas d'utilisateur transactionnel

Jusqu'à 7000 utilisateurs transactionnels

-----

 

(*) 8 processeurs en 2004, car les processeurs actuels, beaucoup plus puissants ne nécessitent pas un tel parallélisme.

Annexe 1 : Glossaire

 

APL

Advanced Product Line (quand ce n'est pas le langage du même nom)

BGE

Bull General Electric

CII

Compagnie Internationale pour l'Informatique

CPU

Central Processing Unit

CU

Compile Unit (code binaire généré par les compilateurs)

DOS

Disc Operating System (IBM)

DPS

Distributed Product System

GCL

GCOS Command Language

GCOS

General purpose & Comprehensive Operating System

GE

General Electric

GECOS

General Electric Comprehensive Operating System

GO

Giga Octets (=1024 MO)

GPL

GCOS Programming Language (version de HPL commercialisée)

HPL

Honeywell Programming Language

IDS

Integrated Data System

Interior Decor

Interface entre le matériel et le logiciel (principalement le répertoire d'instructions)

IOF

Interactive Operator Facility, alias time sharing

JCL

Job Control Language

KO

Kilo Octets (=1024 octets)

LM

Load Module (programme binaire généré par le Static Linker, prêt à être exécuter)

MLP

MacroLangage de Programmation

MO

Mega Octets (=1024 KO)

NAL

New Assembly Language

NPL

New Product Line

OS/MFT

Operating System / Multiple & Fixed Tasks (IBM)

OS/MVT

Operating System / Multiple & Variable Tasks (IBM)

SCP

System Control Program

SHPL

Simplified HPL (HPL sur Multics)

SM

Sharable Module (ensemble de segments décrits par une table de type 1

SNAL

Simplified NAL (NAL sur Multics)

TDS

Transaction Driven System

TPR

Transaction Processing Routine

UFAS

Universal File Access System

 

Annexe 2 : Schéma de fonctionnement d'une Entrée / Sortie (E/S)

 

Application (processus)                                                          Processus système

 
 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 


Ce croquis schématise l'utilisation des différents processus, types de segments et sémaphores utilisés pour l'exécution d'une Entrée / Sortie (E/S).

La demande d'E/S est formulée par un processus d'application. S'il s'agit, par exemple, d'une méthode d'accès à un fichier (telle UFAS) qui doit garnir des tampons d'E/S, ce sera un segment partagé par tous les processus du système, donc de type 0.

La demande est concrétisée par un appel à un segment du système de type 0 qui s'exécute dans le même processus.

Si l'appareil sur lequel doit se faire l'opération est disponible, on voit que celle-ci est directement lancée depuis le processus d'application par une procédure du système.

En revanche, si l'appareil n'est pas disponible, alors un processus du système est notifié par une opération V sur sémaphore SEM1 qui comporte un message indiquant le nom du sémaphore SEMx sur lequel se fera dorénavant la communication entre le processus du système et le processus d'application.

On voit également que les contrôleurs d'E/S simulent des opérations V sur sémaphores (ici SEM0) lorsque une opération se termine.