Sélectionner une page

Du temps des gros mainframes, fabriqués par IBM, UNIVAC, BULL, C2I, Burroughs, etc …. les terminaux (clavier/écran) étaient utilisés principalement par les gens de l’exploitation.

Les programmeurs, eux, écrivaient leurs programmes sur des feuilles de papier préimprimées avec un quadrillage délimitant les différents champs (étiquette, instruction, arguments) adaptés au langage de programmation utilisé. Chaque caractère du programme devant être écrit, en majuscule, dans une case.

Ces feuilles étaient transmises à des opérateurs qui saisissaient et créaient des cartes perforées en carton. On réalisait une double saisie, afin de détecter d’éventuelles erreurs de frappe.

Puis ces cartes étaient lues par un lecteur de cartes, qui envoyait ces données vers l’ordinateur central, qui compilait le source. En retour, une grosse imprimante imprimait, d’une part, le source (avec les erreurs éventuelles) et d’autre part le code machine généré. Puis, dernière étape, un perforateur générait les cartes qui constituaient le binaire exécutable à charger sur l’ordinateur cible.

Cet ensemble (unité centrale, terminal opérateur, lecteur de cartes, imprimante, perforateur de cartes, lecteur de bandes magnétiques, et souvent aussi traceur Calcomp ou Benson) constituait ce l’on appelait un « Terminal Lourd ».

Chaque constructeur avait son propre type de terminal lourd, avec son propre protocole de communication totalement adapté à cet emploi

Les organisations et les entreprises avaient donc ces terminaux lourds installés dans leurs locaux. Ils étaient reliés à l’ordinateur central, soit par des lignes dédiées (que l’on appelait lignes spécialisées) à 4800 ou 9600 bit/s, soit via un réseau commuté spécialisé (comme, en France, le réseau Caducée, qui pouvait atteindre 19200 bits/s en « bande de base » mais limité à quelques kilomètres).

Les protocoles de communication s’appelaient BSC, Multileaving pour IBM, TMMRB pour CII, GRTS, etc …. Quand une organisation avait besoin des services de plusieurs mainframes, il leur fallait un terminal lourd pour chaque type de mainframe.

En France, une société appelée Ordoprocesseurs eut l’idée d’émuler ces protocoles, et de réaliser un terminal lourd qui soit adapté à tous les types de mainframe.

Tout le hardware était conçu et réalisé par Ordoprocesseurs, ainsi que le système d’exploitation multitâches du terminal lourd. Plus d’une dizaine de protocoles de communication avaient été émulés.

Quelques temps plus tard, cette société a été rachetée par SFENA (Société Française Équipements de Navigation Aéronautique), qui a créé une nouvelle entité appelée SFENA Informatique. La ligne de produit s’est étendue, et un nouveau calculateur a été construit : le Co-Ordinateur 500, puis 550. Le système d’exploitation est devenu multi-utilisateurs, et s’est vu doté de méthodes d’accès fichiers en séquentiel indexé et en accès direct, puis d’un langage évolué : le LEM (Langage Evolué pour la Mini-Informatique). Ce langage utilisait des mots français, tels que « BOUCLER EN FAISANT VARIER » ou « TANT QUE .. ». Bien entendu, cela faisait rigoler les esthètes qui programmaient en Cobol ou Fortran, en anglais. L’armée française, qui possédait de nombreux Co-Ordinateurs, avait demandé la réalisation d’un portage du Cobol, ce qui fut fait par Jean Mourain et Suau. Mais, bizarrement, la majorité des clients continuèrent à programmer en LEM, malgré son coté ringard. Quelques années après, Jean Mourain portait le langage C, et un SGBD Entité Relation appelé « ESPACE » conçu par Georges Gardarin fut développé avec son langage de manipulation « Axel » (qui fut le SQL du moment). D’autres protocoles de communication furent développés, comme X25 pour les connexions au réseau Transpac, TMMVU pour CII, 3270 pour IBM etc …

Tout, dans cette machine, hardware comme Software, étaient réalisés à Vélizy/Villacoublay et aux Ulis/Courtaboeuf. Ils étaient l’œuvre de personnes que l’on associait à leur réalisation. On disait « le coupleur disque de Lévy », « le coupleur asynchrone d’Alalinarde », « l’unité centrale de Montéro-Ribas » (basée sur des processeurs en tranche), « le système Météor 4 et 5 de Christian Alessio », « le micro-programme de Geneviève », « le LEM d’Alborguetti », « le SNA 3270 de Lucien Roter et Jean-Jacques Boyer », « les couches X25 de Juteau, Morvan » puis Calinet et Person, et bien d’autres. Beaucoup de ces développements étaient réalisés en assembleur. Il n’y avait que le SGBD Entité-Relations qui avait été réalisé en langage C, par Patrick Grigy et son équipe, quand l’unité centrale fut basée sur des processeurs Intel 286. Puis, ce fut le développement des couches de communication OSI de l’ISO, dont on pensait que « c’était l’avenir ». SFENA n’était pas le seul constructeur à se lancer dans ce développement, tous les grands constructeurs s’y s’étaient mis …

Pistes de Blagnac. 2 mars 1969. Cliché pris lors du 1er vol d’essai du Concorde.
This photograph is part of the Fonds André Cros, preserved by the city archives of Toulouse and released under CC BY-SA 4.0 license by the deliberation n°27.3 of June 23rd, 2017 of the Town Council of the City of Toulouse.

Ce fut une époque merveilleuse. Mais on avait eu peut-être tort de ne pas assez regarder ce qui se passait de l’autre coté de l’Atlantique au même moment, alors que l’internet se préparait. Le plus fort, c’est que l’équipe de départ (qui développait X25) venait du projet Cyclades de Louis Pouzin, qui créait les concepts avant-gardistes de l’internet d’aujourd’hui.

SFENA Informatique abandonna donc sa propre unité centrale pour les processeurs d’Intel, et effectua un portage de son système sur ce nouvel environnement, puis un portage d’Unix système V d’ATT fut réalisé par Y.Ballaud et B.Hourdel. Ironie de l’histoire, devant la demande des clients, le langage LEM fut porté sous Unix pour assurer la transition, et c’est ainsi que le logiciel complexe de gestion du personnel, développée en LEM par L’Oréal, s’est retrouvé sous ULTRIX de Digital Equipment. Petit à petit, les commandes des clients se sont raréfiées, et l’entreprise fut rachetée par SMT GOUPIL, qui tenta de lui donner un nouveau départ.

Mais on était entré dans une autre ère… Et, malgré l’absence du constructeur, des sociétés de services ont perduré pendant plusieurs années et ont assuré la maintenance, évolution et migration vers Unix des nombreuses applications qui avaient été développées.