|
L'équipe de Control
Data |
|
L'équipe de Control
Data |
Aussi curieux que ça vous semble, que au début je n'avez 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 une 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 finis 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 constitué en vérifier et de régler des unité de bande, comme sur l'image ci-contre que montre un 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-avait des milliers de fils d'interconnexion. Ces fils étaient branchés par un équipe de production, mais malgré le soin qu'ils portaient à leur travail, il était inévitable que à chaque livraison à notre atelier de contrôle, qu'il-y-avait quelques douzaines d'erreurs de tout genre. Il faillait commencer par suivre une liste de contrôle, puis débouger tout les erreurs, faire des ajustements, et faire en dernière lieu le test final sur une ordinateur, même pour l'époque (1969 - 1971) déjà un peu vieillot. Sur la liste de l'Electrofact étaient également des lecteurs de cartes perforées, pour ceux qui sont entrée plus récemment dans l'Informatique, c'est l'appareil un première 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.à.d. 20 à la seconde, imaginez vous donc un bourrage à ce vitesse là. Le résultat c'est comme aujourd'hui avec une bourrage d'une imprimante laser; vous poussez quelques injures ensuite vous démontez tout et vous aller enlever la demi douzaine des cartes coincé à l'intérieur de l'engin. |
|
|
|
C'est donc à la fin du mois de Juin 1971 que je suis arrivé à la gare Cornavin de Genève. Après d'avoir passée 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 finis 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 que ici il fallait faire de la maintenance préventive sur tout sortes 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.
|
|
Les photos à coté montrent la salle informatique du site C.E.R.N. de l'époque. 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 de unités centrales, car il-y-en avait des spécialistes pour cela. 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 une service de garde, dites “On Call” en plus de des deux équipes. Et avec un équipe de spécialistes système trop réduite, ces pauvres étaient dérangée un peu trop souvent. Les premières temps les autres et moi, on à d'abord appris les premières notion 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 éventuel 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 a après coup. Il fallait donc enlever des fils, et en mettre des autres. C'est plus simple dit que fait, car il faut bien s'imaginer que le tapis des fils dans les châssis de mémoire et de la unité de calcul pouvaient avoir plusieurs dizaines de centimètres. Dans ces conditions il était pas évident d'enlever p.e. un fil sur module K18 pignoche 22, surtout que celui se trouvait sous un bonne dizaine de centimètres de fils bien tendues, en plus il fallait vraiment faire attention de ne pas enlever celui à côté. Après cette période d'introduction, j'étais envoie 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. |
|
|
|
|
|
|
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 à la unité de calcul, non, c'est une disque dur de 600 Mo, sur laquelle il fallait aussi du maintenance de temps à l'autre. Par exemple nettoyer des plateaux, remplacer des têtes devenus trop faibles, vérifier les circuits hydrauliques qui servaient à la positionnement des têtes, e.t.c. 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 grande décalage entre deux signaux il fallait soit essayer de changer la module suspect, sinon l'autre alternative était de changer la longueur des fils, car comme tout le monde sait l'électricité voyage à la vitesse du lumière, et 30 cm de fils correspondait à une nano (10 -9) secondes. En règle général un changement de longueur d'un fils dans l'ordre d'un mètre était suffisant. Le plus ardu en dépannage était le Control Data 7600 (photo ci-desous), ceci était d'un 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, le 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 la dépannage. |
|
|
|
|
|
Voilà, le Control Data 7600, c'est sur cette machine que je ai passé un grande partie de mon temps, pendant mes dernières années au site du C.E.R.N. Dans une première temps j'ai fait la même chose que des autres, c.à.d. 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. C'est ainsi que j'étais envoyé à Frankfort pour une 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 un nouvelle instruction à chaque cycle d'horloge (27 ns). Le unité centrale lui même était découpée en unités de traitement séparées, dont chacun pouvait opérer d'un façon individuel, et certain unités étaient capable de traiter plusieurs opérandes à la fois. La mémoire à lui avait un temps d'accès inférieur à 80 nano-secondés, c.à.d. les données étaient disponible au cours du troisième cycle d'horloge (27 Ns), donc entre 54 et 81 nano-secondés, après cet accès il fallait attendre 270 nano-secondes que la section adressée soit à nouveau disponible. Le 7600 contenait en total 32 de ces sections organisée 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 petites, spécialisée en entrée - sortie, c'était à eux de ce fatiguer avec les disques et autres.
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 étaient pas cela qu'on utilise aujourd'hui dans la domaine de 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ée dans la gestion. La deuxième langue que j'ai appris à l'époque, était le Fortran, mais c'était pour faire des programmes de tout 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.
Mon tâche était en première lieu de seconder l'analyste en place en compiler et assembler le système d'exploitation pour le client, faire la suivi 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.a.d. des listing de la mémoire et certains registres survenues après une problème, ou plantage système. Parfois en 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 une correctif, soit il fallait envoyer une bande au centre de support en Etats 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 personnelle, moi pour ma part j'avais surtout besoin de quelque chose qui me permettait de faire un connexion au centre du support et télécharger des correctifs et petits documents en forme électroniques. La méthode utilisée par mon collègue analyste était de lister tout sur une 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 le même manipulation en sens envers, c.à.d. 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 à cet époque acquis une machine sous CPM 80 avec une processeur Z80. (mais oui à l'époque on pouvais encore choisir autres choses que Intel-Microsoft!). C'est cette machine qui était ensuite programmée pour faire ces genre de tâches, c'était plus facile, rapide et plus fiable. Ensuite ma petite machine Z80 était largement employé 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.à.d. On fait 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 eu 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 actuel de la langage 'C' d'aujourd'hui.
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 le 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. Survenus sont en même temps également de dépannages ainsi que l'assistance aux clients finals, qui n'étaient pas une luxe avec des systèmes MS-DOS. (Il-y-avaient des mauvaise langues qui l'appellent 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 une stage de Chef de Projet, qui en fait contenait tout les éléments qu'on a besoin pour gérer son affaire. Sont suivi aussi des formations complémentaires dans le domaine de Windows et son programmation.
Finalement pendant la période fin 1993 et début 1995 que j'ai continué la formation professionnelle en direction UNIX - ORACLE - RESEAUX, 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 faut pas oublier que la zone Ile 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' ai habité, ce qui fait une différence non négligeable.
|
Wolter Smit, Technicien micro informatique indépendant, assure le support, l'installation et le maintenance des systèmes Windows, Linux, Unix, ainsi que les systèmes de bases de données Oracle, PostgreSQL et MySQL. ainsi que des pages Web HTML, JSP (Java Server Pages). Support technique, assistance utilisateurs, Installation | ||||||
| Entrée principale | Home | Artistes favoris | Personalités | Science | Was this Atlantis ? | Mes Blogs |
