Discussion :

[thamn]

Le COBOL IBM sous Z/OS reste la référence de ce langage dans le monde IT, les autres sont sans doute très bons aussi : https://www.cobol-it.com , https://www.microfocus.com/fr-fr/pro...cobol/overview , et il y a une version pour l'UNIX d'IBM, AIX : https://www.ibm.com/products/cobol-compiler-aix

LOG4J est développé en JAVA, et les conditions de maintenance sont tout simplement honteuses, et la possibilité de détournement de son usage est tout simplement aussi une vraie honte.
Du coup des centaines de milliers de sites peuvent être attaqués. JAVA est une vraie passoire en terme de sécurité.

Pour revenir au COBOL, la récursivité existe, mais pas au niveau de l'ordre PERFORM mais au niveau de l'ordre CALL associé à la clause RECURSIVE dans le paragraphe PROGRAM-ID...
Lire https://www.ibm.com/docs/en/cobol-zo...ecursive-calls.
En informatique de gestion, je ne suis pas convaincu de l'utilité de la récursivité. Si cette possibilité est si tardive par rapport à d'autres langages déjà assez anciens, c'est sans doute pour cette raison.

Sur ce plan la, j'ai envie de vous dire que tout les problèmes de sécurité lié au applications COBOL reste simplement a découvrir, et qu'elles sont probablement aussi scandaleuses voir pire que ce qui se trouve découvert dans tout projet informatique de taille conséquente. Et c'est certainement encore bien pire pour ce qui tourne sur des Mainframe, parce ce que si on trouve des problèmes dans les projets ouverts, c'est parce que des gens les cherche. Si personne ne peux chercher, ou ne veut chercher, bien entendu on ne trouvera rien.

Et encore une fois, ce n'est pas parce que Log4J est écrit en Java que Log4J contient des vulnérabilités. En revanche, oui un programme écrit en C ou en C++ aura des vulnérabilité lié au langage a cause de du modèle mémoire, mais ce n'est pas le cas du Java.

Vous parlez des conditions de maintenance de Log4J, mais je pense que vous ne vous rendez pas compte: on parle d'un projet ouvert, que tout le monde peut auditer, c'est sain d'y trouver des problèmes, ça veut dire qu'on les regles. Vous voulez vraiment comparer avec ce qui tourne sur des Mainframes? Simplement la machine requise pour faire tourner le programme (et donc investiguer de possible vulnerabilités) n'est d’après les responses que j'ai eu dans ce meme thread pas accessible ou emulable correctement.. Ça demande quand meme pas mal d'aveuglement selon moi..

[walfrat]

Bien que j'ai que 32ans j'ai travaillé sur quelques problématiques lié au Cobol à savoir :

• Voir si je peux faire tourner du COBOL de leur application avec un compilateur Open Source gratuit pour se séparé du propriétaire.
• Etudier un outil qui propose de migrer du Cobol vers un framework Java concu par leur soins pour que les développeurs CoBOL puissent l'utiliser
  

Pour le premier cas ma réponse a été que ça ne se fera pas de façon magique et que certaines instructions ne sont clairement pas prise en charge (j'avais eu la réponse en posant la question sur le forum du dit compilateur). EN bref il faudrait un certain effort et vu que ce n'était qu'un étude qu'on m'a fait faire vite je ne pouvais certainement pas m’engage sur la possibilité définitive de faire cela.

Pour le second point :

Je n'ai aucun doute que leur outils de migrations COBOL vers leur framework Java fonctionne cependant la façon dont est fait l'outil est désespérant :

• Chaque classe Java est dans un classpath séparé, seul les librairies du framework et de base du JRE sont disponible
• Si tu veux faire des appels entre différentes classes, tu dois construire des hashmap<String,Object> et appelé des procédure à la main. Ces classes doivent être spécifiquement enregistrées comme "procédure"
• Mon impression global sur cette outil est qu'on a fait un framework qui dépouille Java (ou n'importe quel langage) de toute capacité d'être manipulé comme un langage de développement et a la place pouvoir être utiliser par des "secrétaires". Je comprend l'intérêt ne pas vouloir forcément faire monter pleinement en compétence d'ancien développeur COBOL en Java, pas besoin de connaître Java en profondeur pour faire de la base de données et des formulaires, mais je pense qu'il y avait moyen de faire mieux. Pour moi, si tu veux travailler sur ce framework, tu cherches un boulot gagne pain dont la compétence requise en tant que "développeur" est proche du zéro absolu.

[Mat.M]

ps: en entreprise je pratique le C depuis 1985 et bien-sur le C++ et sur OS400 depuis 1995 date d'arrivée du compilateur "C" et je n'ai jamais dit que les deux langages était comparable, mais juste sur le fait que leurs origines qui commencent à dater. (Cobol et C).

le plus important c'est de savoir si le COBOL permet de créer des objets métiers comme il est possible dans un langage objet comme Java ou C++
Je ne peux pas répondre à ce questionnement car je n'ai jamais programmé en COBOL.
Parce que si vous devez développer un projet tout en procédural bref sans objets bonjour la maintenance du code...
c'est là le plus important c'est de créer des objets métiers réutilisables et modulaires

[chaton-garrou]

le plus important c'est de savoir si le COBOL permet de créer des objets métiers comme il est possible dans un langage objet comme Java ou C++
Je ne peux pas répondre à ce questionnement car je n'ai jamais programmé en COBOL.
Parce que si vous devez développer un projet tout en procédural bref sans objets bonjour la maintenance du code...
c'est là le plus important c'est de créer des objets métiers réutilisables et modulaires

Je ne comprends pas en quoi cela à une importance,
à l'origine le cobol n'est pas orienté objet, et j'en aurais une utilité tellement minime que ça n'en vaudrais pas le coup.
Le terme objet au sens où on l'entends deviendrais très vite abstrait dans le milieux bancaire selon moi.
Je n'ai pas encore la "vision" pour concevoir ça, mais nous avons tellement d'équipes qui travaillent sur des sujets touchants aux mêmes "objets" mais sur des points tellement différents que j'ai peur que ça ai un coté 'objet fourre-tout'.

Sinon oui beaucoup travaillent en procédural, mais on utilise plutôt le terme de "module métiers",
ils permettent de rassembler des traitements pour gérer un aspect d'une application.

Un grossier exemple:
un métier de consultation pour l'équipe crédit permet de restituer les différentes listes de crédits avec les contrôles de données, ou la simple visualisation du détail d'un crédit.
Donc tu te retrouve avec un découpage fonctionnel du métier d'un "objet" (constituer dans l'exemple par un ensemble d'enregistrements constituant un crédit)

C'est un peu brouillon comme exemple, et il y a beaucoup de styles d'écritures, mais c'est une pratique qui est pas mal propre (par rapport à certaines vraiment flippantes).

[autran]

Bonne année 2022,
On arrive à plus de 40 réponse en réaction à cette news et j’ai peur que nous ne dérivions vers l’éternelle bataille entre les pro-Cobol contre les Pro-Java/C++.
Ce type de confrontation ne nous mènera pas un consensus, puisque chacun défendra son pré carré.
En revanche la problématique sous-jacente n’est que peu adressée dans ce fil. Et cette problématique ce résume de manière très pragmatique par le questionnement suivant : Comment fait une entreprise qui dispose d’un Système d’information développé en Cobol ou Fortran lorsque son sachant part à la retraite ?
A mon sens il y a 3 options :

• Appeler une SSII qui va lui tondre la laine sur le dos au prétexte que c’est une architecture et un langage de niche
• Embaucher un jeune sachant (de 55 ans) à prix d’or dont l’entreprise deviendra captive et qui la placera dans 10 ans devant le même problème.
• Migrer le SI vers un plateforme supporté par le marché

[Mat.M]

Je ne comprends pas en quoi cela à une importance,
Je n'ai pas encore la "vision" pour concevoir ça, mais nous avons tellement d'équipes qui travaillent sur des sujets touchants aux mêmes "objets" mais sur des points tellement différents que j'ai peur que ça ai un coté 'objet fourre-tout'.

l'intérêt de créer des objets métiers c'est aussi de pouvoir les vendre à des autres entreprises et de gagner de l'argent c'est surtout ça qui est important

[Escapetiger]

En revanche la problématique sous-jacente n’est que peu adressée dans ce fil. Et cette problématique ce résume de manière très pragmatique par le questionnement suivant : Comment fait une entreprise qui dispose d’un Système d’information développé en Cobol ou Fortran lorsque son sachant part à la retraite ?
A mon sens il y a 3 options :

• Appeler une SSII qui va lui tondre la laine sur le dos au prétexte que c’est une architecture et un langage de niche
• Embaucher un jeune sachant (de 55 ans) à prix d’or dont l’entreprise deviendra captive et qui la placera dans 10 ans devant le même problème.
• Migrer le SI vers un plateforme supporté par le marché

Tout à fait d'accord pour la problématique, il existe normalement la GPEC (Gestion prévisionnelle des emplois et compétences) dans les grosses structures.

Le client final (Entreprises hors SSII/ESN, Administrations) ne veut plus investir dans le legacy alors que dans d'autres secteurs où les compétences s'acquièrent sur un temps long (le nuclèaire, le pétrole, etc.), des actions de mentorat, transfert de connaissances des séniors vers les plus jeunes, ont été mises en place pour anticiper et lisser l'effet Papy-boom (désigne le grand nombre de départs à la retraite qui doivent avoir lieu entre 2006 et 2025 dans les pays développés.)

En France, le recours à la sous-traitance, le turnover induit (perte du savoir) et le taux d'emploi faible des séniors concourrent à une situation de blocage.

On sait qu'il faut environ 2 ans de pratique quotidienne pour maîtriser a minima un domaine, Cobol ou Java compris.

Que voit-on sur le marché ?
Des offres de re)conversion pour des jeunes Bac +5 scientifiques (moins de 28 ans pour la POEI - préparation opérationnelle à l’emploi individuelle - financée par l'état), comme avant l'an 2000 et le passage à l'Euro - on prend les mêmes recettes.

Certain.e.s sont devenus d'éminents professionnels, d'autres ont quitté le navire, changé de domaine d'activité, etc.

[thamn]

Je ne comprends pas en quoi cela à une importance,
à l'origine le cobol n'est pas orienté objet, et j'en aurais une utilité tellement minime que ça n'en vaudrais pas le coup.
Le terme objet au sens où on l'entends deviendrais très vite abstrait dans le milieux bancaire selon moi.
Je n'ai pas encore la "vision" pour concevoir ça, mais nous avons tellement d'équipes qui travaillent sur des sujets touchants aux mêmes "objets" mais sur des points tellement différents que j'ai peur que ça ai un coté 'objet fourre-tout'.

Sinon oui beaucoup travaillent en procédural, mais on utilise plutôt le terme de "module métiers",
ils permettent de rassembler des traitements pour gérer un aspect d'une application.

Un grossier exemple:
un métier de consultation pour l'équipe crédit permet de restituer les différentes listes de crédits avec les contrôles de données, ou la simple visualisation du détail d'un crédit.
Donc tu te retrouve avec un découpage fonctionnel du métier d'un "objet" (constituer dans l'exemple par un ensemble d'enregistrements constituant un crédit)

C'est un peu brouillon comme exemple, et il y a beaucoup de styles d'écritures, mais c'est une pratique qui est pas mal propre (par rapport à certaines vraiment flippantes).

C'est important pour éviter ce qu'on appelle les bases de code monolithique et permettre la réutilisation. Base de code monolithique qui sont, d’après ce que j'ai pu lire, particulièrement typique du COBOL.
Mais je trouve au final que l'orienté objet pose beaucoup de problème, notamment parce qu'on fait facilement n'importe quoi avec, combien de fois par semaine je découvre des interfaces qui n'ont aucune raison d’être, simplement crée parce que "c'est comme ça que je fais d'habitude", ce qui est selon moi un scandale absolu mais bon apparament faut que je vive avec ces gens qui pense que c'est la bonne façon de faire... Sans parler des methodes faite virtuelle "ben au cas ou je voudrai la surcharger" Bref personne n'a vraiment compris comment l'OO fonctionne, et c'est tellement devenu standard que tu passe pour un pointilleux quand tu rappel qu'une interface c'est pas fait pour te rassurer en faisant croire que ca te permettra de rattraper tes erreurs de design (ou plutot l'absence de design)..

[nicolasg.terrier]

[nicolasg.terrier]

Bien que j'ai que 32ans j'ai travaillé sur quelques problématiques lié au Cobol à savoir :

• Voir si je peux faire tourner du COBOL de leur application avec un compilateur Open Source gratuit pour se séparé du propriétaire.
• Etudier un outil qui propose de migrer du Cobol vers un framework Java concu par leur soins pour que les développeurs CoBOL puissent l'utiliser
  

Pour le premier cas ma réponse a été que ça ne se fera pas de façon magique et que certaines instructions ne sont clairement pas prise en charge (j'avais eu la réponse en posant la question sur le forum du dit compilateur). EN bref il faudrait un certain effort et vu que ce n'était qu'un étude qu'on m'a fait faire vite je ne pouvais certainement pas m’engage sur la possibilité définitive de faire cela.

Pour le second point :

Je n'ai aucun doute que leur outils de migrations COBOL vers leur framework Java fonctionne cependant la façon dont est fait l'outil est désespérant :

• Chaque classe Java est dans un classpath séparé, seul les librairies du framework et de base du JRE sont disponible
• Si tu veux faire des appels entre différentes classes, tu dois construire des hashmap<String,Object> et appelé des procédure à la main. Ces classes doivent être spécifiquement enregistrées comme "procédure"
• Mon impression global sur cette outil est qu'on a fait un framework qui dépouille Java (ou n'importe quel langage) de toute capacité d'être manipulé comme un langage de développement et a la place pouvoir être utiliser par des "secrétaires". Je comprend l'intérêt ne pas vouloir forcément faire monter pleinement en compétence d'ancien développeur COBOL en Java, pas besoin de connaître Java en profondeur pour faire de la base de données et des formulaires, mais je pense qu'il y avait moyen de faire mieux. Pour moi, si tu veux travailler sur ce framework, tu cherches un boulot gagne pain dont la compétence requise en tant que "développeur" est proche du zéro absolu.

[chrtophe]

Tout d'abord je précise que je ne connais pas du tout COBOL, mis à part son nom.

On en retrouve dans les très grandes structures (banques, assurances, etc.) donc des très gros programmes avec des très gros traitements, et en plus critique.
Cela représente donc beaucoup de lignes de codes à refaire, ou éventuellement à "mouliner" avec les contraintes problèmes y afférent. Le projet doit être réalisé par des personnes ayant à la foi des compétences en COBOL, et dans les technologies plus récentes remplaçantes, donc un profil assez rare.

Cela représente donc un cout conséquent, qui n'en vaut pas forcément la chandelle, l'existant répondant au besoin et surtout testé et approuvé.

Et pourtant, pour moi, la bascule va être inéluctable pour les raisons suivantes :
- les anciens maitrisant COBOL partent à la retraite sans remplacement en terme de compétence COBOL
- L'avenir n'est pas à mon avis aux mainframes, les derniers grands calculateurs étant plutôt des clusters de grosses machines standards qu'une très grosse machine spécifique. Ils ne vont pas disparaitre demain non plus, mais à terme oui.

Que COBOL soit remplacé par Java ou un autre langage ne représente pas le fond du problème.

Un cas de réussite de bascule a été évoqué, il aurait été intéressant d'avoir une estimation du cout, de temps passé et une volumétrie permettant d'estimer la taille du projet.

J’ai vu un cas de migration AS400 vers SAP, qui a été abandonné, mais c'est pas la technique le problème, c'est le cout, le temps, l’implication des participants, les bonnes analyses, etc. J'en ai vu aussi qui ont réussi.

A partir du moment ou on est sorti du mainframe, la question du cloud ou non ne se pose plus (AWS ou autre).

Les mainframe évoluant également, je pense qu'ils ne sont pas forcément compatible avec le cloud (reste à confirmer ou infirmer, je ne fais pas de maniframe).

Sur du moyen terme, je pense qu'on va plutôt sur du mainframe et cloud que du mainframe ou cloud.

[Stéphane le calme]

AWS Mainframe Modernization, un nouveau service géré permettant de migrer les charges de travail mainframe vers le cloud, est disponible.
Des analystes estiment que la dette technique d'un tel déploiement pourrait vous rattraper

Lors de l'édition 2021 de son événement re:Invent, qui s'est tenu du 29 novembre au 3 décembre à Las Vegas au Nevada, AWS a fait une flopée d'annonces, dont une a particulièrement retenu l'attention : le leader mondial des services de cloud computing a présenté AWS Mainframe Modernization, un nouveau service géré qui permet aux entreprises de migrer leurs charges de travail mainframe vers le cloud. Rendu en juin 2021, Amazon annonce sa disponibilité générale

AWS essaie d'aider les organisations à migrer leurs charges de travail basées sur le mainframe vers le cloud et potentiellement à les transformer en services cloud natifs modernes. L'initiative Mainframe Modernization a été dévoilée lors de la conférence Re:Invent de la grande enseigne du cloud à la fin de l'année dernière, où le PDG Adam Selipsky a affirmé que « les clients essaient de quitter leurs mainframes aussi vite qu'ils le peuvent ».

Que cela soit basé sur la réalité ou non, AWS admet qu'une telle migration impliquera inévitablement que le client passe par un processus long et complexe qui nécessite plusieurs étapes pour découvrir, évaluer, tester et exploiter les nouveaux environnements de charge de travail : « Aujourd'hui, de nombreux clients dans divers secteurs souhaitent moderniser leurs applications basées sur le mainframe pour tirer parti du cloud, mais pour ce faire, ils doivent passer par un processus long et complexe ».

Pour y parvenir, le service Mainframe Modernization propose un environnement de développement et d'exécution complet destiné à faciliter la modernisation et l'exécution de leurs charges de travail mainframe sur AWS. Alternativement, les clients peuvent conserver les applications existantes telles quelles et les reformer sur AWS avec des modifications de code minimales, explique AWS :

« Ce processus de modernisation des charges de travail mainframe à exécuter dans le cloud nécessite plusieurs étapes pour découvrir, évaluer, tester et exploiter les nouveaux environnements de charge de travail. Chaque étape peut être difficile et nécessite des outils personnalisés ou tiers qui doivent être calibrés pour chaque environnement client individuel, avant que les équipes de projet de modernisation puissent commencer la tâche complexe de transformer les programmes mainframe en services cloud. En raison de la complexité de la modernisation des applications mainframe, les entreprises se tournent généralement vers des consultants et des intégrateurs de systèmes (IS) pour mener des projets de modernisation mainframe. Les organisations sont également confrontées au défi de devoir configurer, exécuter et exploiter des systèmes mainframe avec les meilleures pratiques modernes de développement et de déploiement d'applications dans les nouveaux environnements cloud. Alors que de plus en plus de clients souhaitent moderniser leurs applications basées sur mainframe, ils peuvent tirer des avantages démesurés de meilleurs outils qui leur permettent d'exécuter plus facilement leurs charges de travail dans le cloud pour réaliser des coûts et une agilité améliorés ».

L'environnement d'exécution géré intégré au service Mainframe Modernization est conçu pour fournir le calcul, la mémoire et le stockage nécessaires pour exécuter des applications refactorisées et reformatées. Il automatise également le provisionnement des capacités, la sécurité, l'équilibrage de charge, la mise à l'échelle et la surveillance de l'état des applications.

Cette fonctionnalité est apparemment alimentée par Micro Focus Enterprise Server, un environnement de déploiement d'applications existant pour l'exécution d'applications mainframe IBM sous Linux ou Windows.

Phil Dawson, vice-président de Gartner Research, a averti que les entreprises qui migrent des charges de travail mainframe vers le cloud devront presque certainement les refactoriser ou les recoder à un moment donné dans le futur : « Un passage au cloud pour les applications COBOL peut sembler attrayant, mais la dette technique finira par vous rattraper », a-t-il déclaré.

On ne s'attend pas à ce que les clients fassent tout le travail eux-mêmes; AWS indique qu'avec les outils de modernisation du mainframe, les intégrateurs de systèmes peuvent découvrir les charges de travail du mainframe, évaluer et analyser la préparation à la migration, puis planifier des projets de migration et de modernisation.

L'un de ces intégrateurs est Infosys, qui a déclaré que le nouveau service lui permet d'aider les clients à obtenir les avantages du cloud tout en conservant les années de connaissances commerciales intégrées à leurs systèmes mainframe.

« Le service de modernisation du mainframe d'AWS nous permet d'offrir ces avantages à nos clients. Il a renforcé nos capacités déjà étendues de modernisation du mainframe et nous permet de créer plus rapidement des applications numériques natives modernes, évolutives, et à moindre coût et risque », a déclaré le président d'Infosys et le PDG Eric Paternoster dans un communiqué.

Pour le refactoring, AWS offre des capacités automatisées acquises grâce à l'achat du spécialiste de la migration Blu Age l'année dernière. Selon AWS, il peut convertir des applications écrites dans des langages tels que COBOL, PL/1, NATURAL, RPG/400 et COBOL/400 en services Java et en frameworks Web.

« AWS Mainframe Modernization fournit un environnement de développement et d'exécution complet qui permet aux clients de moderniser et d'exécuter plus rapidement et plus facilement leurs charges de travail mainframe sur AWS. AWS Mainframe Modernization intègre les outils nécessaires pour moderniser les applications mainframe à l'aide d'un environnement unique qui crée un pipeline de modernisation de bout en bout. Avec AWS Mainframe Modernization, les clients peuvent refactoriser leurs charges de travail écrites pour les mainframes vers des services cloud modernes. Ou bien, les clients peuvent conserver les applications existantes telles qu'elles ont été écrites et les reformer sur AWS avec des modifications de code minimales. Que les clients choisissent de refactoriser ou de reformater leurs charges de travail, AWS Mainframe Modernization fournit un environnement d'exécution géré et basé sur le cloud pour les applications modernisées qui permet d'automatiser le provisionnement de capacité, la sécurité, l'équilibrage de charge, la mise à l'échelle automatique et la surveillance de la santé des applications sans infrastructure sous-jacente pour y parvenir. AWS Mainframe Modernization fournit également des capacités d'intégration continue et de livraison continue (CI/CD) pour permettre les meilleures pratiques de développement et de déploiement d'applications modernes, afin que les clients puissent exploiter leurs charges de travail modernisées en production de manière continue avec l'agilité, l'élasticité et les économies supérieures de AWS. Les clients et les SI peuvent également utiliser AWS Mainframe Modernization pour aider les équipes à mieux évaluer la modernisation des applications mainframe et réduire les risques et accélérer la modernisation des charges de travail mainframe à l'aide d'AWS ».

« Les clients nous disent souvent qu'AWS est le meilleur endroit pour exécuter n'importe quel type d'application en raison de son étendue et de sa profondeur inégalées de services spécialement conçus. Cependant, les entreprises d'une grande variété d'industries se sont appuyées sur des mainframes pour exécuter des applications critiques pendant des décennies. Ces entreprises souhaitent naturellement moderniser leurs applications basées sur mainframe pour réduire les coûts et éliminer la dette technique, mais elles ne savent pas comment ni par où commencer », a déclaré William Platt, directeur général des services de migration chez AWS. « Avec AWS Mainframe Modernization, les clients et les intégrateurs de systèmes peuvent désormais refactoriser ou changer de plateforme plus rapidement et plus facilement aux applications mainframe pour qu'elles s'exécutent dans le cloud. AWS Mainframe Modernization fournit les outils nécessaires aux organisations pour tirer pleinement parti de l'élasticité, de l'évolutivité et de la fiabilité d'AWS, tout en économisant du temps et de l'argent ».

Mais existe-t-il vraiment une telle demande pour migrer les applications des systèmes mainframe vers AWS ?

De nombreux mainframes ont été acquis afin d'exécuter des services critiques dont dépendent les organisations, tels que CICS pour la gestion des transactions, et il est peu probable qu'ils soient déplacés vers une plateforme de cloud public.

L'analyste en chef d'Omdia, Roy Illsley, est d'accord, affirmant que le service de modernisation du mainframe s'adressera probablement principalement aux clients qui utilisent déjà AWS pour d'autres charges de travail et qui ont peut-être des applications mainframe qu'ils voudront peut-être moderniser.

« Le cloud n'est pas adapté à la plupart des charges de travail mainframe, et nos données ne montrent pas de migration massive de l'héritage vers le cloud. Je pense que c'est une offre dont ils ont besoin pour être complet », a-t-il déclaré.

Le vice-président directeur de Gartner, Mike Chuba, a déclaré que de nombreux projets de migration mainframe qu'il a vus ne se sont jamais achevés, ainsi que ceux qui ont tendance à être de plus petits ateliers mainframe ou des applications qui ne sont pas critiques.

« Le défi pour presque tous les utilisateurs de mainframe est que de nombreuses charges de travail sont souvent des applications critiques pour l'entreprise qui ne peuvent pas tomber en panne, car si elles le sont, l'entreprise est gravement menacée. En tant que tel, ils doivent être sûrs à 100% qu'une migration pourrait être faite, tout en veillant à ce que les SLA soient respectés », a-t-il expliqué.

Le service AWS Mainframe Modernization est généralement disponible dès maintenant dans les régions AWS couvrant les États-Unis, l'Asie-Pacifique (Sydney), le Canada, l'Europe et l'Amérique du Sud, avec des régions supplémentaires qui seront ajoutées dans les mois à venir, a déclaré AWS.

Source : AWS

Et vous ?

Que pensez du service géré AWS Mainframe Modernization ?
Pensez-vous que les mainframes vont effectivement disparaître ou resteront-ils encore longtemps ? Pourquoi ?

Voir aussi

AWS présente une flopée de nouveaux services de bases de données et de ML, et annonce en Preview version RDS Custom pour Microsoft SQL Server et AWS DMS Fleet Advisor
98 % des responsables informatiques envisageraient de migrer des mainframes vers le cloud, même si 96 % d'entre eux considèrent que les applications mainframe sont importantes, selon LzLabs
AWS présente Proton, le service de gestion des conteneurs, pour automatiser le développement et le déploiement des conteneurs et d'applications "serverless"

[TotoParis]

Attention, si vous votez "mal", si votre Gouvernement devient "agressif', alors vous subirez les mêmes sanctions que la Russie.

[Portekoi]

Bonjour à tous,

J'ai fait 12 ans de banque et à mon arrivée, j'ai découvert COBOL via l'AS400 et les écrans 52/50. Au début, je me disais que c'était vieillot, ayant une vision de développeur web à l'époque (Asp, Php, .Net naissant).

Puis je m'y suis mis par curiosité et j'ai adoré le langage COBOL.

Quand je lis ceci de @thamn :
> C'est important pour éviter ce qu'on appelle les bases de code monolithique et permettre la réutilisation. Base de code monolithique qui sont, d’après ce que j'ai pu lire, particulièrement typique du COBOL.

Oui et non : Cobol hérite de son histoire avec les cartes perforées. Mais cela n'en reste pas moins un langage de programmation : il y avait des développeurs qui faisaient des appels à des sous programmes (que l'on pourrait apparenter à des méthodes réutilisables) et d'autres qui codaient tout d'un bloc. Mais ça, cela ne dépend pas du langage mais bien du dev et pour terminer sur ce hors-sujet, JPLAROCHE a bien expliqué les tenants et aboutissants du Cobol moderne.

Maintenant, le souci de migration : en 12 ans, il a été évoqué une dizaine de fois et à chaque fois abandonné. Pourquoi ? Parce que le coût est trop important, le risque trop grand, que personne n'a connaissance de tous les programmes Cobol et qu'il faudrait en réalité retranscrire ligne à ligne chaque programme. Par exemple, les distributeur de billets ont un windows en front mais discutent en cobol en back.

On a quand même fait une "demi" migration : on a exposé des endpoints (exposant du XML de mémoire) depuis l'AS400 et recréé certains écrans sur du MVC C#. Cela fonctionnait très bien mais le coeur "métier" est resté en Cobol... au moins, nous n'avions plus à gérer les écrans.
Mais avec cette migration, on s'est aperçu que nos agents au comptoir perdaient énormément de temps avec la souris, qui n'existe pas vraiment sur les écrans 52/50 quand on maitrise les raccourcis.
On a donc ajouté des raccourcis clavier qui se rapprochaient un maximum des anciens écrans mais le mal était fait : la nouvelle génération clique, l'ancienne ignore le mulot

Maintenant pour la partie "réelle migration", la question était : où iront nos données ultra-sensibles (banque). Des acteurs comme Microsoft nous avaient contactés mais le fait que les données soient stockées à l'extérieur de la banque était impensable.

Donc la seule solution a été de former des jeunes au Cobol ou de prendre des prestataires chez SOPRA de mémoire et il en est encore aujourd'hui ainsi d'après mes collègues même si la question de migration revient encore très souvent dans les discussions au siège.

[orfraie]

Très bien, c'est ce que j'ai vu dans la réalité, ton intervention "éclaire cruement" le discours un peu commercial et un peu marketing de AWS.

Il a aussi été indiqué par un ponte du Gartner que les migrations MainFrame --> Open se plantent toutes ?!?
C'est faux , il y a des exemples, celui auquel je pense (Confidential, sinon, je citerais) qui a marché , c'est grâce au portage des points de fonction avec récriture complète pas une migration basée sur des moulinettes de code.
Et c'est vrai, car si celles qui marchent sont des reprises à partir de la fonctionnelle, est ce vraiment une migration technique ?

Enfin, dernier détail , le code sur MainFrame ( je ne connais pas du tout AS400) est rapide, voire très rapide, un portage doit non seulement fonctionner à l'identique , être épuré de dette technique mais aussi pédaler aussi vite que la version originelle y compris en cas de mode dégradé.
Bref , ce n'est pas simple.
Bonne journée à tous