Contrôle de qualité à
Electrofact.
Maintenance au
CERN.
Ingénieur
système CERN.
Le Control Data
7600.
Analyste sytsème
à l'EPFL à Lausanne.
Le début
du Micro Informatique.
|
L'équipe de Control
Data
au CERN
|
Contrôle de qualité chez Electrofact.
Aussi curieux que ça vous semble, qu'au début je
n'avais aucun envie d'aller “travailler avec les
Ordinateurs” comme on disait chez nous à l'époque.
Bon bref on cornait la suite!.
C'est par hasard que l'office du travail m'a fait parvenir un message
qu'il-y-avait un travail à “Amersfoort” qui
était susceptible de m'intéresser. Je
me suis donc rendu là bas pour me présenter, et je
finisais par signer un contrat de travail tant que contrôleur
de qualité pour des produits finis de “Control Data”
dans un de leurs usines de production, “Electrofact”
dans ce cas, qu'ils avaient acquis quelque temps auparavant.
|
Ce
contrôle de qualité se composait de la vérification
et réglage des unités de bande, comme sur l'image
ci-contre, qui montre une séance de réglage de
lecture - écriture.
Ce
travail était assez ardu, car sur le dos de ce châssis
qui figure sur l'image, il y en avait des milliers de fils
d'interconnexion. Ces fils étaient
branchés par une équipe de production, mais malgré
le soin qu'ils portaient à leur travail, il était
inévitable qu'à chaque livraison à notre
atelier de contrôle, qu'il y en avait quelques douzaines
d'erreurs de tout genre.
Il
faillait commencer par suivre une liste de contrôle, puis
dé-bouger toutes les erreurs, faire des ajustements, et
faire en dernier lieu le test final sur un ordinateur, qui était,
même pour l'époque (1969 - 1971), déjà
un peu vieillot.
Sur
le site de production de l'Electrofact étaient également
produits des lecteurs de cartes perforées.
Pour ceux qui sont entrée plus récemment dans
l'informatique, c'est l'appareil un premier plan sur deuxième
photo ci-contre.
Le
modèle sur l'image était capable de lire 1 200
cartes perforées à la minute, c'est à dire.
20 à la seconde, imaginez-vous donc un bourrage à
cette vitesse là. Le résultat
c'est comme aujourd'hui avec un bourrage d'une imprimante laser;
vous poussez quelques injures ensuite vous démontez le
tout et vous allez enlever la demie douzaine des cartes coincée
à l'intérieur de l'engin.
|
|
|
|
Maintenance au CERN.
C'est donc à la fin du mois de Juin 1971 que je suis arrivé
à la gare Cornavin de Genève. Après
en avoir passé la nuit à l'hôtel, un responsable
de Control Data est venu me chercher pour se rendre au site de
C.E.R.N., ou je devais prendre une poste comme Technicien de
Maintenance.
La durée était initialement prévue pour deux
ans, mais je finisais par rester en Suisse de 1971 à 1995, qui
font en tout vingt-quatre ans au lieu des deux initialement prévue.
Mon travail au C.E.R.N. était un peu près le même
que chez Electrofact avec la seule différence qu'ici il
fallait faire de la maintenance préventive sur tous sorts de
périphériques, lecteurs de carte, perforatrices de
carte, unité de bande, imprimantes et autres.
Le centre de calcul était ces jours à côte du
bâtiment administratif, et en cours de déménagement
vers un bâtiment tout neuve.
|
|
Ces quelques photos à coté montrent la salle
informatique du site C.E.R.N. de l'époque, que j'avais
commencé d'y travailler tant que technicien de maitenance.
La première photo montre la section ou se trouvaient
les unités centrales, la deuxième montre quelques
uns de l'équipe Control Data à l'oeuvre, et la
dernière photo montre la section ou étaient les
unités de bandes.
Bon ce qui me concerne, les premières années je
n'étais pas en charge des machines dites unités
centrales, car il y en avait des spécialistes pour cela.
Ma spécialisation dans ce domaine ne
venait que plus tard.
Mais après un certain temps, il était devenu
clair qu'il fallait repartir cette tâche sur plusieurs
personnes, car comme il était de coutume à
l'époque, il-y-avait un service de garde, dites “On
Call” en plus de des deux équipes.
Et avec une équipe de spécialistes système
trop réduite, ces pauvres étaient dérangés
un peu trop souvent.
Les premiers temps les autres et moi, ils nous avaient d'abord
appris les premières notions rudimentaires du dépannage
et identification de panne pour les machines dites “Front-End”,
les tout premières tâches étaient
d'identifier les problèmes de mémoire, et remplacer
les éventuels modules défectueux.
Au fil du temps, il fallait faire de plus en plus faire des
choses important, parmi eux par exemple installer des Field
Change Order, ce sont des corrections que Control Data fessait
porter à ces machines à après coup.
Il fallait donc enlever des fils, et en mettre des autres, qui est
plus simplement dit que fait, car il
faut bien s'imaginer que le tapis des fils dans les châssis
de mémoire et de l'unité de calcul pouvaient avoir
plusieurs dizaines de centimètres.
Dans ces conditions il n'était pas évident
d'enlever par exemple un fil sur module K18 pignoche 22, surtout
que celui se trouvait sous une bonne dizaine de centimètres
de fils bien tendus, en plus il fallait vraiment faire attention
de ne pas enlever celui à côté.
Après
cette période d'introduction, j'étais envoié
avec d'autres de mes collègues à Paris, ou se
trouvait un important centre de formation Control Data, pour me
former sur la machine la plus performante de cette époque,
le Control Data 7600.
|
|
|
|
|
Ingénieur système CERN.
|
Voilà, de retour de Paris, il fallait mettre en pratique
qu'on avait nous appris, maintenant j'avais aussi des doits,
c.à.d. surtout celui d'être dérangé
pendant la nuit comme des autres.
La première image ci-contre n'est pas unité
centrale ou autre pièce appartenant à l'unité
de calcul, non, c'est un disque dur de 600 Mo, sur laquelle il
fallait aussi de la maintenance de temps à l'autre.
Par exemple nettoyer des plateaux, remplacer des têtes
devenues trop faibles, vérifier les circuits hydrauliques
qui servaient au positionnement des têtes, et cetéra.
La deuxième image montre une tâche de mesure de
cohérence entre signaux à l'intérieure de la
machine même.
En car en cas d'un trop grand décalage entre deux signaux,
soit, il fallait essayer de changer le module suspect, sinon,
l'autre alternative était, d'essayer de changer la
longueur des fils, car comme tout le monde sait l'électricité
voyage à la vitesse de la lumière, et 30 cm de fils
correspondait à une nano (10 -9) seconde.
En règle générale un changement de la
longueur d'un fils dans l'ordre d'un mètre s'avérait
suffisant.
Le plus ardu en dépannage était le Control Data
7600 (photo ci-dessous), ceci était d'une conception RISC,
et était en mesure d'exécuter plusieurs
instructions en même temps, qui n'arrange pas du tout le
dépannage.
En plus qu'elle était en mesure d'exécuter
plusieurs instructions en même temps, la plupart de ces
instructions étaient prise en charge par des unités
séparées.
C'était peut-être bien pour la vitesse d'exécution,
mais c'était désastre pour le dépannage.
|
|
|
|
Le Control Data 7600.
|
|
Voilà, le Control Data 7600, c'est sur cette machine
que j'ai passé une grande partie de mon temps, pendant mes
dernières années au site du C.E.R.N.
Dans un premier temps je faisais la même chose que des
autres, c'est à dire; de la maintenance, le dépannage
et le service de garde.
Mais plus tard il était devenu de plus en plus clair
qu'il fallait familiariser une personne de l'équipe
technique avec le système de l'exploitation, pour pouvoir
analyser les causes d'une panne à partir d'un arrêt
intempestif.
C'est
ainsi que j'étais envoyé à Francfort pour un
stage d'analyse système, programmation système et
son paramétrage.
|
Le Control Data 7600 était une machine assez proche d'une
conception qui est aujourd'hui mieux connue sous nom RISC (Reduced
Instruction Set Computer). Le 7600 était
en fait théoriquement capable d'exécuter une nouvelle
instruction à chaque cycle d'horloge (27 ns). L'unité
centrale elle même était découpée en
unités de traitement séparées, dont chacun
pouvait opérer d'une façon individuelle, et certaines
unités étaient capables de traiter plusieurs opérandes
à la fois. La mémoire à
lui avait un temps d'accès inférieur à 80
nano-secondés, c'est à dire les données étaient
disponibles au cours du troisième cycle d'horloge (27 Ns),
donc entre 54 et 81 nano-secondes, après cet accès il
fallait attendre 270 nano-secondes que la section adressée
soit de nouveau disponible. Le 7600 contenait
en total 32 de ces sections organisées en mode “stripping”,
un peu comme du RAID 0 d'aujourd'hui. Le
bus de mémoire à lui avait un taux de transfert de 270
Mo / sec. En plus de ces éléments
les entrées-sorties n'étaient pas assurées par
le processeur central, le 7600 contenait dix processeurs plus petits,
spécialisée en entrée - sortie, c'était à
eux de ce fatiguer avec les disques et autres.
Analyste sytsème à l'EPFL à
Lausanne.
Après un certain temps je me
suis de plus en plus familiarisé avec le système
d'exploitation, mais aussi avec la programmation, même que les
langues employées n'étaient pas cela qu'on utilise
aujourd'hui dans le domaine de la gestion. Car
le code système était fait dans la langue assemblage de
Control Data dont la structure n'avait rien avoir avec les langues
utilisées dans la gestion. La deuxième
langue, que j'ai appris à l'époque, était le
Fortran, mais c'était pour faire des programmes de toute
nature sauf système.
C'était au milieu des années 1980, que j'étais
muté à Lausanne pour prendre une poste d'analyste
système, qui devenait disponible au site de l'E.P.F.L.
Ma tâche était en premier lieu de seconder l'analyste en
place en compiler et assembler le système d'exploitation pour
le client, faire suivre des pannes logicielles (ou bogues si vous
voulez) et autres problèmes. Il
fallait aussi adapter le système selon les besoins du client
avec chaque nouvelle version, vérifier et apporter des
adaptions locales aux nouveaux systèmes, et recompiler les
adaptions locales à ces occasions. Une
autre tâche était d'analyser les dites “Dump”
c'est à dire des listings de la mémoire et certains
registres survenus après un problème, ou plantage
système. Parfois, on pouvait
identifier l'erreur, soit matérielle, qui générée
à coup sûr la colère des collègues
techniciens qui manifetaient à coup sur leur désaccord,
soit l'erreur était identifiable et il existait un correctif,
soit il fallait envoyer une bande au centre de support en États Unis.
Comme mentionnée ci-desus, j'ai au début assisté
l'analyste système déjà en place, et c'était
lui qui s'en occupé l'assistance au client, mais quand il
était parti, c'était à moi d'assurer cette
tâche, avec de l'aide des spécialistes du bureau de
Zurich.
C'est à la fin du période Lausanne que j'ai commencé
avec la Micro Informatique de l'époque. Il
y avait déjà un certain nombre de mes collègues
qui avaient acquis un ordinateur personnel, moi pour ma part j'avais
surtout besoin de quelque chose qui me permettait de faire une
connexion au centre du support et télécharger des
correctifs et petits documents en forme électronique. La
méthode utilisée par mon collègue analyste était
de lister tout sur un terminal, d'enregistrer le contenue de l'écran
sur une cassette, changer ensuite la connexion de l'extérieur
vers l'ordinateur central et faire la même manipulation en sens
envers, c'est à dire c'est le contenue de la cassette qui
fessait office d'entrées au clavier. Dans
le but d'automatiser certains de ces tâches, j'avais à
cette époque acquis une machine sous CPM 80 avec un processeur
Z80. (Mais oui, à l'époque
on pouvait encore choisir d'autres choses que Intel-Microsoft!).
C'est cette machine qui était ensuite programmée pour
faire ces genres de tâches, c'était plus facile, rapide
et plus fiable. Ensuite ma petite machine Z80
était largement employée comme machine de
communication, et machine de transfert de données et je me
suis servi de cette petite machine pour saisir des programmes en mode
“off-line”, c'est à dire que je faisais d'abord la
saisi sur la machine en mode local, pour les transférer
ensuite en un seul coup sur l'ordinateur central pour traitement.
Mais avant que ça eût marché il fallait créer
des scripts de connexion et des programmes de transfert et autres.
C'est ces opérations de programmation
qui ont largement contribué à mes connaissances
actuelles du langage 'C' d'aujourd'hui.
Le début du Micro Informatique.
C'est après la fermeture des agences Control Data en
Suisse-Romande que je suis devenu technicien indépendant et
que j'ai commencé à travailler plus sérieusement
dans la Micro-informatique. Je pouvais en
fait assez rapidement commencer à collaborer avec un bureau de
consultation technique dans le bâtiment dans le Valais tout
près de chez moi. Je devais leur
remettre des programmes à jour, créer d'autres, les
refaire à neuve, ainsi que préparer les installations
pour ces clients, faire ensuite les installations définitives
chez les clients. Il fallait également
faire la suivi des éventuels problèmes. Ce
sont également survenus en même temps des dépannages,
ainsi que l'assistance aux clients finals, qui n'étaient pas
un luxe avec des systèmes MS-DOS. (Il y en avait des mauvaises
langues qui l'appelaient MESS-DOS)
Après un certain temps, le temps était venu de
continuer la formation professionnelle, spécialement celui de
la gestion. C'est pour ce but que j'ai suivi
un stage de Chef de Projet, qui en fait contenait tout les éléments
qu'on a besoin pour gérer son affaire. Ce
stage était suivi d'autres formations complémentaires
dans le domaine de Windows et sa programmation.
Finalement pendant la période fin 1993 et début 1995
que j'ai continué la formation professionnelle en direction
UNIX - ORACLE - RÉSEAUX, sur laquelle j'ai ajouté ce
jour le système LINUX en mode auto-formation.
C'est en cours de l'année 1994 que j'ai préféré
de continuer mon activité en France au lieu de la Suisse.
Car il ne faut pas oublier que la zone Île
de France à lui tout seule contient déjà 2 X
plus d'habitants et industrie que la Suisse en entier et même
55 X plus que le Valais ou j'habitais, ce qui fait une différence
non négligeable.
|
