Les cartes perforées.

Qui n’a pas connu, dans les années 70, les affres d’un paquet renversé lors des manipulations. Cartes qu’il fallait alors re-trier à l’aide du dernier listing disponible.

Ceci est une carte perforée. Chaque colonne porteuse de plusieurs perforations, est porteuse d’un code de caractère. Souvent les cartes comportaient en première ligne, en haut de la carte, l’impression du caractère correspondant à la colonne. Ce n’est pas le cas ici, remettre la carte au bon endroit passe de la gageure à l’exploit!

Cependant, pour gagner du temps et économiser du papier, il arrivait pour des modifications supposées simples de ne pas éditer de listing à chaque passage.

La remise en ordre du paquet devenait alors plus problématique…

De plus le risque de mauvaise manipulation n’était pas si rare que cela, car la capacité du bac du lecteur de cartes était plus faible que la taille des paquets des programmes. Le désir d’aller vite de l’analyste et le côté facétieux des paquets de cartes, toujours prompts à se répandre sur le support où on les avait délicatement posés ou l’intervention supposée de Trolls , pouvait mener à de fastidieux exercices de tri.

Paris 1974 : Exercice de frappe sur perfo-vérif. Au deuxième plan on voit le calculateur C2 (scientifique) avec son pupitre ses dérouleurs de bandes et le lecteur perfo de ruban papier. On remarquera, en partie caché derrière la poignée de la porte, le lecteur de cartes initial. Les Trolls ne sont pas visibles.

Pour éviter ce type de travail trop fastidieux, chacun avait sa (ou ses) méthode(s).

• Numéroter les cartes, en prenant soin de ménager des trous dans la numérotation, pour les adjonctions futures (exemple numéroter de 10 en10 au départ), ce qui ralentissait la saisie puisque les numéros étaient attribués et tapés « à la main » et qui s’oubliait au fur et à mesure que l’on s’éloignait du dernier incident.
• Barrer, sur la tranche, le paquet de cartes d’un trait de feutre oblique, ce qui permettait en cas d’accident de faire un premier classement grossier limitant les recherches pour interclassement à un nombre de cartes plus réduit.
• Passer les cartes par petits paquets en les entourant d’un élastique…

Au-delà des maladresses de manipulations des cartes, le lecteur de cartes jouait aussi son rôle de trouble-fête. Alors que les derniers lecteurs étaient relativement fiables grâce à des systèmes de soufflerie pour décoller les cartes les unes des autres en entrée et un système d’aspiration pour les présenter au système de lecture, les premiers lecteurs étaient entièrement mécaniques. Une lame, de l’épaisseur d’une carte, dotée d’un mouvement alternatif poussait, dans un fracas important et des vibrations impressionnantes, la carte dans une fente calibrée pour laisser passer une carte mais pas deux. Un spécialiste réglait régulièrement cette épaisseur. Mais, les cartes perforées, sensibles à l’humidité ou à une certaine détérioration après plusieurs passages pouvaient dépasser l’épaisseur requise… Il s’en suivait un bourrage nécessitant de retaper les cartes détériorées et de reprendre à zéro le processus de lecture, après appel de la maintenance, heureusement sur place, pour recaler la hauteur de la fente.

A l’inverse la lecture simultanée de deux cartes « minces » donnait des résultats plus divers (erreur du lecteur, ligne de programme correspondant à la superposition de trous des deux cartes totalement aléatoire, non significative et générant une erreur à la compilation ou à l’assemblage…).

Une autre facétie de ce lecteur, plus subtile, m’avait fait perdre un temps non négligeable. Le chariot de réception des cartes en sortie du lecteur a eu un point dur, ce qui fait qu’au lieu de descendre régulièrement à l’arrivée de chaque carte supplémentaire il était resté légèrement bloqué un temps limité qui avait suffi à ce que les cartes se mélangent après le passage dans le lecteur. Le phénomène ayant eu lieu après lecture des cartes, le programme produit a fonctionné correctement. Suite à une demande du dispatching lors de la présentation du logiciel, je dus faire une modification mineure de changement de la logique de l’affichage d’un symbole. La modification effectuée rapidement, j’ai relancé la chaîne de production de l’exécutable et ai constaté avec surprise que le programme ne fonctionnait plus correctement. J’ai donc effectué une relecture fouillée du code nouveau et n’ai rien trouvé d’anormal. Je suis donc passé à la mise en place de traces autour de la modification sans aucun résultat. Ne comprenant plus pourquoi cela ne fonctionnait plus j’ai repris le processus habituel de débogage de l’ensemble du code et me suis donc aperçu de la présence de cartes permutées. Avec l’aide de la maintenance locale le problème a enfin pu être identifié et réparé. Mais, en sachant, que le processus de production d’un programme prenait environ une heure à chaque passage, il est aisé de comprendre comment un simple point dur a pu faire perdre plus d’une journée pour une modification simpliste.

Le ruban perforé.

A la fin de chaque assemblage ou compilation on sortait un ruban perforé représentant le module objet correspondant à la source traitée. Puis on rentrait dans le lecteur les différents modules objets et la table des symboles dont on souhaitait faire l’édition de lien et on produisait un exécutable dont on perforait l’image.

L’image n’est pas d’un dispatching, mais elle conforte le fait que nous n’étions pas les seuls à avoir des problèmes à gérer le ruban papier!

Malgré l’expérience, deux perturbations majeures pouvait affecter le développeur.

• La mauvaise (ou l’absence d’) estimation de la longueur restante de ruban. En général, et en application des lois de Murphy,  c’est quelques secondes avant la fin de la perforation souhaitée que le ruban s’avérait trop court, obligeant à reprendre le processus depuis le début….
• Le déchirement. Une fois le ruban entièrement perforé, celui-ci gisait sur le sol. Il fallait le récupérer, le placer sur un enrouleur, afin de pouvoir le ranger soigneusement ou de pouvoir le réutiliser dans la suite du processus. Lors de la phase d’enroulement, il arrivait que le ruban se tournant sur lui-même fasse un nœud et se déchire en arrivant sur l’enrouleur. Plus fréquent encore était le pied du développeur posé malencontreusement sur le ruban qui se vengeait en cassant. Deux écoles pour y remédier : recommencer la production du ruban abimé ou se lancer dans un recollage du ruban et la reconstitution des perforations abimées par la déchirure à l’aide d’un appareil  rustique ad hoc.