Discussion :

[autran]

Bonjour JPLAROCHE, j’ai peur que ton exemple ne soit pas très bien choisi. Car ces 2 langages n’ont rien en commun.
Le langage C a plus de 50 ans, et le langage Cobol surement 10 de plus ce qui les classe tous les 2 dans la catégorie des langages « Anciens ».
Néanmoins le C portait une modernité liée à UNIX. C’est donc un langage « objet » qui continue à bénéficier d’une inertie importante. Il est d’ailleurs souvent le premier langage enseigné en école d’ingénieur ou en université (branche scientifique).
Il est utilisé pour écrire beaucoup de systèmes modernes en production pour encore quelque temps. De plus, 90% des langages modernes présentent des syntaxes issues du C. Seul le C permet de comprendre les arcanes de linux.
Bref, le langage C n’est donc absolument pas à classer dans la catégorie « Legacy »
Attention je ne dis pas que d’ici quelques années Rust ne prendra pas la place de C. Je dis seulement que le langage C est encore moderne et porté par l’industrie en tant que tel. D’ailleurs de nombreux jeunes développeurs se lancent dans une carrière C en premier job.

[jpouly]

Ça me rappel il y a quelques années, du temps ou les fermes de serveurs étaient à la mode. Résultat : les mainframes sont toujours là.

Et puis, Java au niveau performance, c'est quand même pas génial. Surtout quand il faut traiter quelques millions de comptes en banques ou de transactions bancaires en quelques minutes.

Et puis le cloud, c'est bien gentil, mais à qui appartient les données ? Parce que là, on parle de données confidentiels.

D'ici qu'un juge américain demande l'accès aux comptes en banque de tous les français, anglais, allemands, ...

[autran]

Et puis le cloud, c'est bien gentil, mais à qui appartient les données ? Parce que là, on parle de données confidentiels.

D'ici qu'un juge américain demande l'accès aux comptes en banque de tous les français, anglais, allemands, ...

il n'y a pas que AWS AZURE ou GCP. On trouve aussi des clouds souverains pour couvrir le risque de compromission d'origine géopolitique

[JPLAROCHE]

Bonjour JPLAROCHE, j’ai peur que ton exemple ne soit pas très bien choisi. Car ces 2 langages n’ont rien en commun.
Le langage C a plus de 50 ans, et le langage Cobol surement 10 de plus ce qui les classe tous les 2 dans la catégorie des langages « Anciens ».
Néanmoins le C portait une modernité liée à UNIX. C’est donc un langage « objet » qui continue à bénéficier d’une inertie importante. Il est d’ailleurs souvent le premier langage enseigné en école d’ingénieur ou en université (branche scientifique).
Il est utilisé pour écrire beaucoup de systèmes modernes en production pour encore quelque temps. De plus, 90% des langages modernes présentent des syntaxes issues du C. Seul le C permet de comprendre les arcanes de linux.
Bref, le langage C n’est donc absolument pas à classer dans la catégorie « Legacy »
Attention je ne dis pas que d’ici quelques années Rust ne prendra pas la place de C. Je dis seulement que le langage C est encore moderne et porté par l’industrie en tant que tel. D’ailleurs de nombreux jeunes développeurs se lancent dans une carrière C en premier job.

Bonjour, juste pour compléter mon exemple.

Sans remettre en cause

Néanmoins le C portait une modernité liée à UNIX. C’est donc un langage « objet » qui continue à bénéficier d’une inertie importante. Il est d’ailleurs souvent le premier langage enseigné en école d’ingénieur ou en université (branche scientifique).

mon exemple de dire que le C est aussi un langage qui date, n'est pas de comparer les 2 langages, je ne comprends pas pourquoi le Cobol-ILE n'aurait pas évolué qui lui est beaucoup plus jeune que C/C++, et sa dernière mise à jour est de 2021, donc n'est pas un langage « Legacy », il est utilisé dans les banques et assurance c'est un langage Objet , comme le C++ mise à part la 40 d'ordres (pour de la gestion) qu'il a en commun avec le Cobol des années 80 sa conception est complètement différente, et très spécifique à la plateforme IBM et tourne sur OS400, le Cobol-ILE est un Cobol moderne.

Ici j'ai cru que l'on parlait de migration des mainframes, en conséquence j'ai pensé que le plus facile pour des cobolistes c'est de passer au Cobol-ILE pour avoir des exemples vivant ces dernières années par des amis très proches encore en activité. L'OS400 je ne dis pas AS400 qui lui est un type d'ordinateur, car l'OS400 est un "Système dit system i " porté sur les IPOWER qui eux sont comparables aux très gros mainframe et joue dans la même catégorie, c'est d'ailleurs un cheval de bataille chez IBM tant pour la modernisation que performance tout en restant sur du mainframe.

Dès le début, j'ai parlé de Cobol-ILE,il est complètement orienté Objet pour plus d'information ce reporter à la documentation.
pour information sur les IPOWER peuvent tourner conjointement OS400 UNIX WINDOWS LINUX
exemple : un programme exécutable fait appel à une lib(BNDSRVPGM) qui comporte des modules en export/import et dont les "data structure" sont transmises par pointeur etc... conception propre à ILE chose qui n'existait pas en OPM; le system CISC utilisait le model OPM les system RISC le model ILE y est fortement solicité

Rational Developement Studio for i, ILE COBOL Programmer's Guide
de la documentation pour ceux qui voudraient avoir des explications plus approfondies.

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).

Linux est en C et seulement maintenant on entrevoit RUST et seulement dans les pilotes... alors OUI RUST n'est pas "Legacy" mais peut-on en dire autant de C !!!

sur wikipédia:
à propos du C
Ses principaux inconvénients sont :

• le peu de vérifications offertes par les compilateurs d'origine (K&R C), et l'absence de vérifications à l'exécution, ce qui fait que des erreurs qui auraient pu être automatiquement détectées lors du développement ne l’étaient qu’à l'exécution, donc au prix d’un plantage du logiciel ;
  
  • sous UNIX, on pouvait utiliser les utilitaires lint et cflow pour éviter de tels mécomptes,
  • des vérifications sont ajoutées avec le temps, mais elles restent partielles,
  
  
• son approche de la modularité restée au niveau de ce qui se faisait au début des années 1970, et largement dépassée depuis par d'autres langages :
  
  • il ne facilite pas la programmation orientée objet,
  • il ne permet pas de créer des espaces de noms,
  
  
• la gestion d'exceptions très sommaire ;
• le support très limité de la généricité, malgré l’introduction des expressions à type générique en C11 ;
• les subtilités de l'écriture de programmes portables, car le comportement exact des exécutables dépend de l'ordinateur cible ;
• le support minimaliste de l'allocation de mémoire et des chaînes de caractères, ce qui oblige les programmeurs à s'occuper de détails fastidieux et sources de bugs ; il n'y a notamment pas de ramasse-miettes standard ;
• les bugs graves qui peuvent être causés par un simple manque d'attention du développeur ; tel le dépassement de tampon qui constitue une faille de sécurité informatique exploitable par les logiciels malveillants ;
• certaines erreurs ne peuvent être détectées automatiquement qu'à l'aide d'outils supplémentaires et non standardisés, comme lint et Valgrind ;

[autran]

Bonjour JPLAROCHE, je suis content que tu reviennes vers la problématique initiale de migration car le combat sur les langages n’est pas très productif.
N’étant pas du tout un expert du Cobol, je te crois sur parole quand tu me dis que le nouveau COBOL ILE est aussi Objet et portable que Java. Mais il n’en demeure pas moins que bien des entreprises souhaitent migrer leurs plate-forme COBOL faute de ressources sur ce merveilleux langage. Donc leurs proposer de se débarrasser de leur vieux COBOL pour le nouveau COBOL ILE sorti en 2021 mais que personne ne connait ne sera pas acceptable.
Et pour généraliser je dirai que la problématique est similaire pour le FORTRAN où la encore je ne critique pas les performances du langage ni son âge. Mais les développeurs fortran sont des ressources tout aussi particulièrement difficile à trouver.
Alors oui je pense que le fond du problème est bien de changer de langage. Quant à l’architecture qui permet cette migration, c’est un chantier annexe.

[JPLAROCHE]

Merci autran moi aussi je suis d'accords sur le problème...

[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).

[thamn]

L'exemple de la factorielle utilisé pour illustrer la récursivité en COBOL, n'est pas un bon exemple, on la fonction interne FACTORIAL :
https://www.ibm.com/docs/ro/cobol-zo...ions-factorial

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
Format

>>-FUNCTION FACTORIAL--(--argument-1--)------------------------><

Ca ressemble a du Brainfuck
Pourquoi est-ce qu'il y a tous ces caractères qui semble ne pas porter de sens (les -, >, <)
Je vois que ça a l'air en rapport au format, mais je comprends pas très bien (ça semble pareil pour toutes les autres fonctions).

En fouillant les internets, je suis tombé sur des gens qui expliquaient que techniquement il y avait des barrières a la possibilité pour le COBOL d'appeler une procédure récursivement et que c’était la raison qui explique c’était pas du tout possible.
Je trouve aussi qu'il serait possible d’exécuter un programme qui s'appelle lui même (c'est aussi ce que disait JPLAROCHE).

[nicolasg.terrier]

[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