Vous pouvez voir les deux types de travail c\u00f4te \u00e0 c\u00f4te dans Zetaly Automated Capacity (ZAC)<\/a>. Dans l'exemple client ci-dessous, une partition a une moyenne glissante sur quatre heures (R4HA) de 2 232 MSU, dont 1 709 MSU de travail legacy et 523 MSU de travail mobile.<\/p>\n\n\n\n La plateforme sous le code legacy est r\u00e9cente. IBM a mis le z17 en disponibilit\u00e9 g\u00e9n\u00e9rale le 18 juin 2025, avec un processeur Telum II qui embarque sur la puce un acc\u00e9l\u00e9rateur d'intelligence artificielle (IA) (IBM<\/a>). Le syst\u00e8me d'exploitation correspondant, z\/OS 3.2, est en disponibilit\u00e9 g\u00e9n\u00e9rale depuis le 30 septembre 2025 (IBM<\/a>).<\/p>\n\n\n\n La plupart des sites ne sont pas sur la derni\u00e8re version, mais ils en sont proches. Une mise \u00e0 niveau prend tant de temps que la version suivante est d\u00e9j\u00e0 sortie quand le projet se termine. C'est pourquoi certains sites restent sur une version plus ancienne, puis passent directement \u00e0 la plus r\u00e9cente. Le travail de mise \u00e0 niveau ne s'arr\u00eate jamais, et un site en retard l'est en g\u00e9n\u00e9ral parce que ce travail ne peut pas aller plus vite.<\/p>\n\n\n\n Les logiciels autour du syst\u00e8me d'exploitation suivent le m\u00eame cycle. Ils comprennent la base de donn\u00e9es Db2 et les moniteurs transactionnels CICS (Customer Information Control System) et IMS (Information Management System). Une application type est un programme COBOL qui tourne via CICS en temps r\u00e9el ou en batch, et qui lit ou met \u00e0 jour des donn\u00e9es dans Db2. Quand un client utilise une application mobile, celle-ci appelle ces m\u00eames transactions et lit ces m\u00eames donn\u00e9es. Le canal le plus r\u00e9cent de l'entreprise repose donc sur son code le plus ancien.<\/p>\n\n\n\n Le code continue de tourner, mais la connaissance n\u00e9cessaire pour le modifier dure moins longtemps. Trois causes expliquent cette perte.<\/p>\n\n\n\n La premi\u00e8re cause est le vieux code auquel personne n'ose toucher. Avant que des produits comme Db2 et CICS se g\u00e9n\u00e9ralisent, les d\u00e9veloppeurs \u00e9crivaient leurs propres \u00e9quivalents en assembleur, un langage proche du code machine. Certains de ces programmes des ann\u00e9es 1970 et 1980 tournent encore aujourd'hui, et chaque site mainframe en a. Ils sont critiques et ils fonctionnent, mais leur auteur est parti depuis longtemps sans documenter le code ni transmettre son savoir-faire. Avant l'an 2000, les entreprises ont revu leurs syst\u00e8mes pour v\u00e9rifier la gestion des dates. Ce nettoyage a supprim\u00e9 beaucoup de ces programmes, mais pas tous.<\/p>\n\n\n\n La deuxi\u00e8me cause, ce sont les fusions. Par exemple, un groupe bancaire fran\u00e7ais faisait tourner environ 50 syst\u00e8mes d'information distincts il y a 25 ans et n'en a plus qu'un aujourd'hui. Chaque regroupement a gard\u00e9 comme base le syst\u00e8me d'une ou deux entit\u00e9s et abandonn\u00e9 les autres. Une partie de l'histoire et de la connaissance est partie avec eux. Beaucoup des applications que personne ne sait expliquer aujourd'hui viennent de ces regroupements. Les \u00e9quipes travaillent \u00e0 les retirer, et leur nombre baisse avec le temps.<\/p>\n\n\n\n La troisi\u00e8me cause est la fa\u00e7on dont la connaissance est r\u00e9partie. Les grands centres de donn\u00e9es ont des architectes fonctionnels et des architectes techniques. Un architecte fonctionnel conna\u00eet un domaine en profondeur (par exemple, l'application de pr\u00eats dans une banque), mais ne sait pas d\u00e9crire ses liens avec les paiements par carte ou les retraits d'esp\u00e8ces. Un architecte technique fournit les bases de donn\u00e9es et les moniteurs transactionnels sur lesquels les d\u00e9veloppeurs construisent. Comme chacun conna\u00eet une partie, la plupart des entreprises n'ont personne capable de dessiner l'ensemble du syst\u00e8me d'information.<\/p>\n\n\n\n Certains co\u00fbts du mainframe ne sont jamais remis en question non plus, car chaque entreprise a des applications qu'elle ne limitera pas. Une banque ne limite pas les applications qui rapportent du chiffre d'affaires (banque en ligne, retraits d'esp\u00e8ces, paiements interbancaires). Si ces applications ont besoin de plus de MSU, elles en re\u00e7oivent plus. De m\u00eame, un constructeur automobile ne limite pas les applications qui g\u00e8rent l'approvisionnement des pi\u00e8ces en flux tendu, et une compagnie a\u00e9rienne ne limite pas celles qui g\u00e8rent le temps pass\u00e9 au sol par un avion. La capacit\u00e9 que ces applications utilisent est donc rarement examin\u00e9e.<\/p>\n\n\n\n La premi\u00e8re \u00e9tape pour combler ce manque de connaissance est de rendre le parc lisible. Zetaly Data Platform (ZDP)<\/a> collecte les donn\u00e9es op\u00e9rationnelles que le mainframe produit d\u00e9j\u00e0, et Zetaly Service Intelligence (ZSI)<\/a> transforme ces donn\u00e9es en tableaux de bord organis\u00e9s par domaine m\u00e9tier. Chaque \u00e9quipe voit ainsi ce que consomment ses charges de travail, sans sp\u00e9cialiste mainframe pour traduire. Les deux produits font partie de l'offre Observabilit\u00e9 Mainframe<\/a> de Zetaly.<\/p>\n\n\n\n L'urbanisme mainframe applique les principes de l'urbanisme des villes \u00e0 un environnement mainframe, pour le rendre plus modulaire et plus facile \u00e0 faire \u00e9voluer.<\/strong><\/p>\n\n\n\n![\"Zetaly](\"https:\/\/zetaly.io\/wp-content\/uploads\/2024\/05\/Imagemainframe.png\")
<\/figure>\n\n\n\nCe qui est r\u00e9cent sur un mainframe moderne<\/h2>\n\n\n\n
Ce qui vieillit mal sur un mainframe legacy : la connaissance<\/h2>\n\n\n\n