Discussion :

[Francis Walter]

Les premiers mainframes d'IBM ont 50 ans,
et ils continuent à être utilisés dans de nombreuses entreprises

Le monde est aujourd’hui rempli de milliards d’ordinateurs composés de microprocesseur. Mais il y a plus d’un demi-siècle, un ordinateur avait la taille d’un salon. À la place des bus, les ingénieurs utilisaient des câbles pour transporter les données. Ce fut sans doute très impressionnant d’avoir de telles machines, capables de faire des calculs que le cerveau de l’Homme ne pouvait pas faire et de conserver des données que la mémoire de l’Homme ne pouvait pas. Les besoins ont varié, le monde avait besoin des ordinateurs personnels qu’on pouvait transporter partout où on voulait aller d’où la naissance des unités centrales.

Ce fut le 7 avril 1964 que le premier mainframe d’IBM a été dévoilé, soit exactement il y a 50 ans. Il s’agit du System 360 qui a valu 5 milliards de dollars comme investissement. Cette apparition a fait abolir l’avènement de leurs prédécesseurs qui occupaient un espace important dans les locaux. Aujourd’hui, il est difficile de se passer de la technologie, elle fait maintenant partie de notre vie quotidienne, on ne s’en lasse plus. Mais on oublie que ces mainframes sont la base de l’essor qu’a connu la technologie. Pour Charlie Ewen, directeur de l'information au Met Office utilisant les mainframes depuis environ 40 ans, les mainframes doivent être considérés comme un héritage pour la technologie.

Malgré leur vieillesse, les unités centrales continuent d’être exploitées dans de nombreuses entreprises. En tout cas, c’est ce qu’affirme Barry Heptonstall, un porte-parole d'IBM. La plupart des gros systèmes de traitement de données telles que les agences de réservations aériennes, les distributeurs de billets ou encore les systèmes de paiement par carte de crédit utiliseraient encore des unités centrales. Ils sont « résilients, robustes et très rentables pour une partie du travail que nous faisons » a déclaré Charlie Ewen. Le Met Office utilise encore les unités centrales pour faire environ 4 millions de prévisions par jour.

Les premiers claviers sont apparus au temps des premiers mainframes. Sur ces claviers, on pouvait voir des touches telles que « Escape », « SysRq » et « Request System ». Cette dernière permettait d’interrompre un programme en exécution et de passer à un autre. Rappelons que le langage du moment était le Cobol. Ce temps est maintenant révolu, les architectures parallèles sont d’actualités, plusieurs tâches peuvent être exécutées simultanément. Dans 50 ans, sans aucun doute, les besoins en technologies seront accrus, de nouvelles générations de machines seront d’actualités, mais les unités centrales resteront une base pour ces futures générations d’ordinateurs.

Source : BBC

Et vous ?
Utilisez-vous encore ces mainframes ? Pourquoi ?

[Paul TOTH]

d'après cet article on a l'impression qu'il y a des gens qui bossent encore comme il y a 50 ans...moi j'ai connu l'AS/400 d'IBM sur 15 ans il a énormément évolué, les premiers modèles que j'ai connu faisaient 1m50 de haut et 3m de large avec des disques dur de 30kg (le poids, pas la capacité), les derniers modèles que j'ai connu tout en étant plus puissant n'étaient pas plus gros qu'un PC.

après ça fait 4 ans que j'ai pas mis les pieds dans un Auchan ou un Boulanger, mais à l'époque ils étaient tous sous AS/400, ce qui largement suffisent pour saisir une commande client avec un système qui supporte des liaisons très bas débit si nécessaire.

c'est pas très fun de développer sur ces machines mais c'est tout à fait adapté pour des applications de gestion.

[fredinkan]

c'est pas très fun de développer sur ces machines mais c'est tout à fait adapté pour des applications de gestion.

Je plussoie clairement.
Je connais plein de gens qui sont parti d'AS/400 pour autre chose et qui n'ont jamais pu s'y faire.

C'était moche, mais ultrafonctionnel.

[Gugelhupf]

Cobol powa

[4sStylZ]

Je travaille dans une société originairement spécialisée dans le monde de l'AS-400.

Effectivement, les plus grande sociétés de France et d'ailleurs ont toujours des AS-400, notamment plus de 90 % des 100 plus grandes entreprises Françaises.

Comme cité plus haut, la grande distribution, Conforama, Boulanger etc fonctionnent toujours avec des AS, et je connais des vendeurs qui ne veulent pas voir un seul écran plus moderne, à cause de la latence.

La machine est d'une fiabilité énorme. La volumétrie des données traitée peut toujours être fantastique et n'a que peu d'égal à mes yeux.

Dans certain cas, Rien ne sert d'avoir un joli écran couleur alors que tout ce qui compte c'est une saisie extraordinairement rapide des données (commandes client, factures...).

DB2, le SGBD de l'AS-400 est très performant, et contrairement aux croyances, il peut être attaqué par d'autres clients que des écrans 52-50 noirs et verts qui malgré leur faible coût en UC sont démodés stylistiquement parlant ...

Nous générons par exemple des interfaces semblable à des sites web (En général avec des interfaces très simples et "industrielles" mais néanmoins rapides). Nous générons aussi des client Windows en C++ qui attaquent DB2 et les AS-400.

Des nouveaux projets de création et non de simple maintenances arrivent toujours pour des AS-400, indépendamment du langage (Orienté Web, en COBOL ou en RPG-IV ILE pur), même si la demande diminue évidemment.

Même si les écrans noirs et verts sont démodés, l'AS-400 est sans doutes possibles loin d'être morte. On aura encore des projets et des clients qui souhaiterons maintenir leurs applicatifs 400 dans 20 ans même si notre stratégie globale d'entreprise a évoluée depuis longtemps vers des technologies plus modernes et différentes.

[el_slapper]

J'ai longtemps bossé en MVS qu'en AS/400(c'est la gamme un peu plus puissante, ciblée grands comptes). Avec 2 anecdotes rigolotes.

(1) un grand compte veut refaire sa chaine marketing. Les données initiales sont sous UNIX. Le client JAVA qui permettra aux agents de le consulter est sous UNIX. Pourtant, on me demande de chiffrer la réalisation de la chaine. J'ai posé bêtement la question "mais pourquoi vous ne faites pas ça en JAVA, ça serait plus cohérent techniquement". Réponse : "parceque vous êtes deux fois moins cher". Moralité, même en essayant de scier la branche sur laquelle je suis assis, la réalité casse la scie, pas la branche.

(2) un autre grand compte a un système d'information complet en COBOL/MVS. Même les interfaces. Au lieu de faire comme tout le monde et de remplacer les interfaces par du JAVA ou du Delphi, et laisser les choses sérieuses sous MVS, décision est prise de tout remplacer. 5 ans plus tard, et après plus de 100M€ de dépenses, le nouveau projet JAVA gère 5% du périmètre. Là ou l'apli COBOL/MVS passe les 95% du traitement annuel comptable en moins d'une journée, l'appli JAVA passe les 5% en une semaine. Poubelle. Moralité : si les concurrents font des solutions hybrides, c'est parceque ça marche.

[Invité]

La volumétrie des données traitée peut toujours être fantastique et n'a que peu d'égal à mes yeux.

Effectivement, depuis mon pont de vue d'archi réseau, le mot "performance" est le premier qui me vienne à l'esprit.

Récemment, j'ai aidé au déploiement de deux Power 7 Plus sur des coeurs de réseau au travers d'aggrégats d'interfaces 10G.
Il faudrait que je retrouve les résultats de transferts de 10Go de données entre les 2 Power 7. Au début, je croyais que l'admin s'emmêlait les pinceaux entre les bytes et bits tellement c'était faramineux

Pis pour m'impressionner, il a refait le transfert du même fichier dans les 2 sens en même temps (chaque Power 7 était serveur et client). Les stats n'avaient pas bougé d'un poil. La bestiole avait encore du mou. Il a alors stoppé les tests de perfs et il s'est moqué de moi en prétendant qu'il pourrait faire fumer les Cisco
Frimeur d'admin de Power 7 Plus


Il y a quelques années, je travaillais sur un problème réseau qui hébergeait un S390. Une des interfaces IP du S390 était configurée sans gateway. Je vous passe les détails mais à ma grande stupeur, en regardant des traces, le S390 substituait parfois son adresse IP configurée sans gateway par une autre adresse IP locale, configurée elle avec une gateway
Et là, l'admin de conclure : "à ce prix, une telle machine doit sûrement avoir une certaine forme d'instinct de survie"


Enfin (je vais arrêter là parce que des histoires de guerre avec les mainframes IBM, j'en ai des tonnes), un pote aux US était confronté à un bug OSPF catastrophique sur des gros routeurs Cisco (le bug faisait redémarrer le Designated Router). No problemo. L'admin a gentiment "prêté" son S390. En une demi-journée, OSPF tournait sur le S390, comme OSPF DR, avec des milliers de Link States dans sa base de données. C'est resté en l'état pendant une semaine, le temps pour Cisco de sortir son fix... Ca ne dérangeait pas trop l'admin parce que ça ne prenait que 4 ou 5% de la CPU du S390

Les équipes mainframes, c'est une tribu à part entière. Ils ont leurs coutumes, leur langage. C'est une catégorie de geeks avec qui j'aime bien bosser

Maintenant, j'ose la question : est-ce que les équipes qui gèrent vos mainframes aiment aussi le ricard ?

Bon, ok, je sors

Steph

[Metalman]

Attention... "Mainframe" > "Minis" (> "Micros")....
Soit : MVS & z/OS > AS/400
Pour pas que d'autres confondent !

Bref : oui malheureusement les équipes mainframes "actuellement en place" ne disposent que de leur propre jargon, et il devient parfois TRES difficile de parler avec eux sur les notions non-mainframes ou même "génériques" à tout ordinateur quel qu'il soit....

Je suis d'accord avec Paul TOTH : l'article présente le mainframe comme un outil de la préhistoire qui "tourne très difficilement"... heureusement l'article parle des claviers à la fin, car il me semble que les premiers S360 fonctionnaient bel et bien en majorité avec de la carte perforée...
De plus : il n'y avait pas QUE le COBOL...

Enfin bref.... j'ai bien envie de faire un autre article ici même pour débroussailler le "mainframe" d'aujourd'hui et celui de l'époque.


Sinon aujourd'hui :
Il y a le fabuleux z/OS toujours en évolution...
...et le zLinux !
Et tous deux partagent les mêmes "grosses boîtes" avec des CPU à 5,5Ghz et sont "préemptifs"... Oui oui...
On ne fait pas qu'envoyer des tas de cartes perforées, appuyer sur des gros boutons rouges pour arrêter et tourner des manivelles pour revenir en arrière dans les steps...


EDIT : pour ceux qui voudraient contribuer à la rédaction d'explications que je propose, tout est ici

[camus3]

Je travaille dans une société originairement spécialisée dans le monde de l'AS-400.

Ta boite doit se faire un sacré pognon... Je connais un seul consultant COBOL (et FORTRAN) , il vit largement bien avec son salaire à 6 chiffres... comme quoi, tout ces derniers languages à la mode, ça paie pas autant qu'un bon vieux COBOL ...

[fredinkan]

Ta boite doit se faire un sacré pognon... Je connais un seul consultant COBOL (et FORTRAN) , il vit largement bien avec son salaire à 6 chiffres... comme quoi, tout ces derniers languages à la mode, ça paie pas autant qu'un bon vieux COBOL ...

Normal, peu de personnes veulent en faire, car "c'est pas à la mode".
Et plein d'autres ont peur (peut-être à raison) que ça ne dure que quelques années.

[Metalman]

Il y a de la demande COBOL chez les clients.... publiquement sous forme d'embauche d'experts avec 10~15 ans d'expérience, et en privé de tout ce qui a la formation minimum...
...les SSII essayent de trouver des gens répondant à ces critères, mais refusent de présenter publiquement des offres d'embauche pour "débutants", même si elles sont prêtes à faire des formations internes...
...les "jeunes" ne voient que les demandes d'experts avec 15 ans d'XP et croient donc que le secteur est mort comme aucun débutant n'est demandé...

=> et vous avez la formule parfaite pour fermer le petit monde et être certain de manquer de recrues

Comme tout le monde ignore ce qu'est le COBOL (un langage "strict" dans les formats d'entrées/sorties, de ce que j'ai pu voir jusqu'à maintenant), tout le monde pense à "quelque chose" qui doit être de l'assembleur... incompréhensible... bourré de bugs... et générant des programmes très peu stables...
Et en réalité on est sur quelque chose qui ne segfault pas contrairement au C et ses libertés (sachant que j'adore le C grâce aux pointeurs etc...), et qui du coup devient beaucoup plus facile et rapide à recetter... car on est directement plongé dans la partie métier !
...et ça 99% des "informaticiens" l'ignore ! Car personne ne fait d'effort pour en parler.

[Kropernic]

J'ai eu mon diplôme en 2006 après 3 ans d'études. Bin je sais pas si ça se fait encore partout mais en tout cas, j'ai encore eu cours de COBOL.

J'adorais ce langage car il fallait être hyper structuré et rigoureux pour pouvoir s'y retrouver (sous peine d'avoir des perform dans tous les sens et de plus rien biter au code).

J'devrais regarder les offres d'emploi en cobol pour voir tiens ^^.

[Remi.Net]

C'est toujours un plaisirs de voir le petit nouveaux, essayer de faire une requête ad-hoc sur MainFrame.

Les pupilles se dilatent dès l'ouverture de l'écran 3270! Puis l'incompréhension se manifeste devant le concept de CopyBook. Découvrir leur maladresse devant l'éditeur de texte. Exprimer son côté sadique lors des explications sur le JCL. Se décourager en essayant de leur expliquer les principes de base IMS.

Pour terminer bien examiner leur mine déconfit quand tu leur explique que l'essentiel du business de la boite est effectué à l'aide du MainFrame.

À l'occasion il a un petit nouveau qui sort de l'ordinaire et qui ne semble pas surpris de découvrir une mainframe dans la boîte, habituellement c'est ceux qui ont plus de potentielle.

[Invité]

Ils ont même fait un clip pour célébrer l'événement.

[Elepole]

Perso (comprendre, moi le jeune c** pour qui mainframe est la limite entre crétacé et préhistoire en informatique) quelque chose m'a toujours sidéré: pourquoi on a toujours pas réussit a faire des systèmes aussi performant malgré toutes les avance technologique des dernières années ? Pourtant, que ça soit au niveau hardware, os, ou logiciel on n'arrête pas de trouver des innovation pour améliorer les performance et autre, alors pourquoi ? Ou est la différence ?


Sinon, faut que je me mette au COBOL moi un de ces jours ...

[fsmrel]

Bonsoir,


@ Francis Walter

Il y a 50 ans je programmais à fond, et je peux vous dire que les ordinateurs que j’ai chahutés à l’époque n’avaient rien à voir avec la description surprenante, sinon sidérante que vous en faites... En passant vous confondez mainframe et système d’exploitation, vous n’avez sans doute connu COBOL que par le biais de gens à qui d’autres gens ont dit de façon condescendante, après l'avoir lu dans la presse du cœur : « beurk... » Bref, je vous recommande la méditation du 7e aphorisme de Ludwig Wittgenstein, (en fin de son Tractatus) :

« Sur ce dont on ne peut parler, il faut garder le silence ».

[Paul TOTH]

Perso (comprendre, moi le jeune c** pour qui mainframe est la limite entre crétacé et préhistoire en informatique) quelque chose m'a toujours sidéré: pourquoi on a toujours pas réussit a faire des systèmes aussi performant malgré toutes les avance technologique des dernières années ? Pourtant, que ça soit au niveau hardware, os, ou logiciel on n'arrête pas de trouver des innovation pour améliorer les performance et autre, alors pourquoi ? Ou est la différence ?


Sinon, faut que je me mette au COBOL moi un de ces jours ...

la différence c'est qu'on cherche à faire des choses beaucoup plus compliquées que de simple applications de gestion. Sur un MainFrame, difficile d'intégrer un SIG, difficile de faire un simple forum phpBB avec pièces jointes et coloration syntaxique des portions de code (je parle sur le terminal d'un mainframe, car il est tout à fait possible d'héberger un site web dessus qui offrira le même confort qu'un IIS ou qu'un Apache...si ce n'est pas directement Apache qui est installé).

Alors que le vendeur chez Auchan ou Boulanger il a juste besoin d'accéder aux articles et la fiche client pour établir un facture, ça ne va pas plus loin. Alors oui tu vas avoir des sociétés qui vont te vendre des logiciels de caisse avec géolocalisation, reconnaissance faciale, vue en 3D des articles et que sais-je encore, mais est-ce que cela va rendre le vendeur plus efficace dans son travail ?

Et le MainFrame c'est 0 déploiement, tout se passe sur la machine centrale, le terminal est semi-intelligent (il est capable mieux que HTML5 de valider des champs, traiter des cas d'erreur selon les spécifications du programme) mais il reste standard et figé, s'il ne fonctionne plus tu le changes car il n'y a pas de mise à jour d'OS ou quoi que ce soit (y'a sûrement une EPROM mais bon). Après si l'utilisateur a des besoins plus évolués à côté tu mets un bête terminal logiciel qui tient en une poignée de Ko avec peut-être de temps à autre une mise à jour quand tu changes de version d'OS...et encore.

[oboiteux]

Une précision : ce qui a été produit en 1964, c'est une gamme de machines reposant sur une architecture commune et décrite dans un document intitulé "Principle of Operations". Cette gamme s'appelle de nos jours Z quelque chose. L'AS400 a été développé dans les années 70/80 sur une architecture différente.

"Malgré leur vieillesse, les unités centrales continuent d’être exploitées dans de nombreuses entreprises. " euh, ça veut dire que mes comptes en banque et contrats d'assurance sont gérés par des brouettes fabriquées dans les années 60 ?
Bien sur que non, l'électronique d'aujourd'hui n'a rien à voir avec celle des années 60. Ce qui n'a pas changé, ce sont les instructions machine. Un programme assembleur écrit dans les années 60 fonctionne toujours sur une machine Z (avec plein de limites mais ça marche). Chaque instruction machine est implémentée via du micro-code (=instructions électroniques) qui, lui, évolue sans arrêt.
Je trouve curieux qu'IBM ne soit pas capable d'expliquer que les "mainframes" d'aujourd'hui sont des monstres de technologie avec changement de cartes CPU, mémoire, microcode à chaud, etc... sans parler du système d'exploitation.

"Rappelons que le langage du moment était le Cobol. Ce temps est maintenant révolu, les architectures parallèles sont d’actualités, plusieurs tâches peuvent être exécutées simultanément" non mais allo, quoi! C'est IBM qui a inventé la mémoire virtuelle, les mainframes sont multiprocesseurs depuis des dizaines d'années, etc... Pour le COBOL, voir http://blog.developpez.com/cobos/ , les bras m'en tombent.

[Paul TOTH]

Une précision : ce qui a été produit en 1964, c'est une gamme de machines reposant sur une architecture commune et décrite dans un document intitulé "Principle of Operations". Cette gamme s'appelle de nos jours Z quelque chose. L'AS400 a été développé dans les années 70/80 sur une architecture différente.

"Malgré leur vieillesse, les unités centrales continuent d’être exploitées dans de nombreuses entreprises. " euh, ça veut dire que mes comptes en banque et contrats d'assurance sont gérés par des brouettes fabriquées dans les années 60 ?
Bien sur que non, l'électronique d'aujourd'hui n'a rien à voir avec celle des années 60. Ce qui n'a pas changé, ce sont les instructions machine. Un programme assembleur écrit dans les années 60 fonctionne toujours sur une machine Z (avec plein de limites mais ça marche). Chaque instruction machine est implémentée via du micro-code (=instructions électroniques) qui, lui, évolue sans arrêt.
Je trouve curieux qu'IBM ne soit pas capable d'expliquer que les "mainframes" d'aujourd'hui sont des monstres de technologie avec changement de cartes CPU, mémoire, microcode à chaud, etc... sans parler du système d'exploitation.

"Rappelons que le langage du moment était le Cobol. Ce temps est maintenant révolu, les architectures parallèles sont d’actualités, plusieurs tâches peuvent être exécutées simultanément" non mais allo, quoi! C'est IBM qui a inventé la mémoire virtuelle, les mainframes sont multiprocesseurs depuis des dizaines d'années, etc... Pour le COBOL, voir http://blog.developpez.com/cobos/ , les bras m'en tombent.

sur AS/400 (eSeries il me semble aujourd'hui) aussi il y a une couche d'abstraction hardware, d'ailleurs sur nos AS/400 on faisait tourner des programmes S38, et ensuite on est passé de processeurs CISC à des processeurs RISC sans rien changer (en fait l'OS a migré tout de même les objets compilés mais sans avoir besoin des sources)...mais je viens de voir, qu'il n'en est plus à sa première migration

[oboiteux]

Oui, on pourrait même dire en exagérant un peu que l'AS400 est le corrigé de ce qui avait été fait pour le S/360 - c'est comme ça que ça s'appelait à l'époque - surtout au niveau du système d'exploitation d'ailleurs.