Eranea : presentation technique de la solution de transcodage Cobol vers Java, automatique et iso-fonctionnel

Technologie Eranea
migration 100 % automatique et iso-fonctionnelle
vers x86, Linux & Java
02 Juillet 2015
Table des Matières
1.Préambule................................................................................................................................................1
2.Introduction.............................................................................................................................................2
3.Analyse du marché..................................................................................................................................3
3.1.Solutions alternatives......................................................................................................................3
3.2.Comparaison au transcodage iso-fonctionnel..................................................................................3
3.2.1.Synthèse...................................................................................................................................3
3.2.2.Rehosting <> transcodage.......................................................................................................4
3.2.3.Transformation <> transcodage...............................................................................................5
4.Solution de Migration Eranea.................................................................................................................7
4.1.Principes..........................................................................................................................................7
4.2.Méthodologie...................................................................................................................................8
4.3.Technologie...................................................................................................................................12
4.3.1.Transcodage...........................................................................................................................13
4.3.2.Framework d'exécution..........................................................................................................15
4.3.3.Environnement de développement........................................................................................16
5.Architecture technique Eranea..............................................................................................................16
5.1.Objectifs fonctionnels....................................................................................................................16
5.2.Composants techniques.................................................................................................................16
5.2.1.Serveurs x86 et stockage.......................................................................................................16
5.2.2.Virtualisation..........................................................................................................................18
5.2.3.Distribution Linux.................................................................................................................19
5.2.4.Application Server (AS) Java................................................................................................20
5.3.Architecture transactionnelle.........................................................................................................21
5.4.Architecture batch.........................................................................................................................23
1. Préambule
1. Pour toute question ou information complémentaire, merci d'envoyer un mail à
contact@eranea.com. Un Proof of Concept (PoC) est également réalisable de manière simple et
rapide.
2. Pour la concision des textes, le mot « Cobol » est utilisé de manière systématique dans la suite
02 juillet 2015 © 2015 Eranea – http://www.eranea.com Page 1 de 24

pour décrire le code de l'application mais il faut lire en fait à chaque fois « le code source de
l'application à laquelle la solution est appliquée » : cela peut être PacBase, CoolGen, RPG,
Ideal-Datacom, EasyTrieve, etc.
3. Voir http://www.eranea.com/presentation pour une illustration graphique de l'ensemble des
informations ci-après
2. Introduction
Ce document présente la solution de migration Eranea du monde mainframe / Cobol (IBM z/OS, Bull
GCOS, etc.) vers une plate-forme x86 / Linux / Java avec interface web/ajax. Elle est également
applicable à toute application Cobol fonctionnant dans un autre environnement (AS/400, AIX, Solaris,
OpenVMS, etc.)
La nouvelle plate-forme cible est désormais le plus souvent une infrastructure de type « private
cloud » : l'application dans sa nouvelle forme Java est directement installée sur une plate-forme de
déploiement et d'administration de cloud privé comme, par exemple, CloudStack, OpenStack (elle-
même basée sur Java), etc.
Un tel choix permet de profiter de tous les gains de productivité en termes de gestion apportés par ces
technologies et de tout leur potentiel de croissance efficace à très grande échelle. Cette infrastructure
privée peut ensuite donner naissance à un cloud hybride où l'application est partiellement migrée vers
un opérateur public, voire à une externalisation complète sur le cloud de cet opérateur afin d'atteindre
une optimisation économique maximale.
Les deux apports majeurs de la technologie Eranea sont :
• une très forte modernisation : l'obsolescence de la plate-forme mainframe est remplacée par
un nouveau système respectant tous les standards d'infrastructure (x86, Linux) et d'applications
(Java, web/ajax) actuels. Une partie de la modernisation est effectuée à travers la migration elle-
même mais, de plus, cette dernière offre à l'application le potentiel de mettre en œuvre à court
terme toutes les fonctions de la nouvelle plate-forme non directement utilisées durant le projet.
• des économies massives : de manière consistante à travers différents projets, Eranea permet à
ses clients de réaliser une économie toujours supérieure à 80 % , voire 90 % dans les situations
les plus favorables lors de la sortie d'un mainframe vers une plate-forme x86. Cela signifie donc
des millions d'euros d'économies effectives, annuellement récurrentes, en matériels et logiciels.
Ce résultant très attrayant est par ailleurs atteint fluidement, sans aucun risque, grâce à la méthodologie
de migration incrémentale d'Eranea sans « Big Bang ». Elle est sous-tendue par les caractéristiques de
sa technologie, spécifiquement développée pour permettre cette approche particulièrement adaptée à la
migration des applications métier critiques des très grands comptes.
En effet, la technologie dispose de deux caractéristiques distinctives par rapport à la concurrence :
• automatisation continue à 100 % : l'application originale est transformée vers Java et web/ajax
sans aucune intervention humaine. Cette transformation automatique, appelée transcodage, peut
donc être répétée aussi souvent que nécessaire (chaque 24h voire N fois par jour) pour

introduire en continu et automatiquement les dernières modifications de l'application originale
en Cobol dans sa version Java, et permettre ainsi la poursuite de la maintenance durant toute la
durée du projet de migration sans travail à double.
• iso-fonctionnalité stricte : l'application Java génère exactement les mêmes résultats que
l'application originale « au bit près ». Les données qu'elle produit sont donc indiscernables de
celles produites par l'application originale.
La combinaison de ces deux caractéristiques permet une migration totalement incrémentale : chaque
utilisateur transactionnel ou chaque traitement batch peut être migré vers la nouvelle version java/web
sur x86 sans aucune corrélation avec ses pairs (dans l'absolu, un par un et en totale indépendance). Tous
restent cependant parfaitement intégrés au système global par le travail en direct, permis par l'iso-
fonctionnalité, sur la base de données originale de l'application mainframe.
3. Analyse du marché
3.1. Solutions alternatives
La solution de transcodage d'Eranea est souvent comparée à 2 types de solutions :
• les solutions de « rehosting » qui transportent l'application dans son état courant (Cobol, 3270,
etc.) vers une plate-forme beaucoup plus économique en lui apportant le moins de changements
possibles : Cobol reste Cobol, interface homme-machine reste de type « écran passif », etc. On
utilise un compilateur Cobol ciblant Linux pour exécuter les modules sources inchangés sur la
nouvelle plate-forme. Les APIs système (CICS, batch, etc.) sont apportées par l'environnement
d'exécution du compilateur et des modules tiers complémentaires.
• les solutions de « transformation » qui changent une ou plusieurs technologies de départ pour
les faire évoluer vers l'état de l'art. Elles apportent aussi le plus souvent des améliorations
structurelles ou fonctionnelles dans l'application. Elles sont le plus souvent basées sur des outils
d'analyse du patrimoine applicatif, puis de régénération de celui-ci dans une forme qui se veut
optimisée.
3.2. Comparaison au transcodage iso-fonctionnel
3.2.1. Synthèse
Au vu de l'analyse ci-après, le transcodage iso-fonctionnel, tel que pratiqué par Eranea, apparaît comme
la meilleure synthèse entre les avantages du rehosting et de la transformation, sans les inconvénients
majeurs de ces 2 types de solutions. Cette synthèse, qu'est le transcodage, souhaite traiter les deux pans
du problème posé au responsable informatique pour la sortie du mainframe : les aspects tactiques de
l'exploitation (« Run ») qui doit toujours être réalisée pour un coût moindre sur des plates-formes
technologiques pérennes et les aspects stratégiques du développement (« Build ») qui doit protéger les
lourds investissements applicatifs déjà réalisés en les transportant de manière agile et rapide, à travers

les générations technologiques, vers les outils de développement les plus productifs du moment, afin de
maximiser en permanence la compétitivité de l'entreprise face à sa concurrence et à face l'évolution
permanente de son métier.
Pour ce faire, le transcodage iso-fonctionnel rassemble les caractéristiques suivantes :
• comme le rehosting, et contrairement à la transformation, il définit une cible parfaitement claire
et objective : un système qui produit les mêmes résultats que le système original afin, d'une
part, d'en faciliter les tests et d'en rendre la validation totalement quantifiable et objective et,
d'autre part, de permettre une migration transparente pour les utilisateurs.
• comme le rehosting (quand il est lui aussi strictement iso-fonctionnel), et contrairement à la
transformation, il permet une migration très fluide et incrémentale, éliminant tous les risques et
préservant la continuité des affaires.
• comme le rehosting, il apporte des gains économiques très substantiels (> 80 % des coûts
initiaux).
• à l'opposé du rehosting, et comme la transformation, il transporte l'application vers une nouvelle
plate-forme technologique plus moderne (Java + interface web) dont il utilise directement une
partie des possibilités, mettant le reste du potentiel à disposition des développeurs qui
poursuivront la maintenance évolutive de l'application après le projet.
• comme la transformation, le transcodage place l'application sur de nouvelles bases
technologiques très pérennes qui lui offrent une extension massive de sa durée de vie et une
agilité nouvelle très importante, afin de maximiser son ouverture et sa vitesse d'évolution ainsi
que la productivité des développeurs.
• à l'opposé de la transformation, le transcodage place « le chemin vers le but » (= les différentes
étapes de la migration) en priorité maximale, en le favorisant par rapport même au maximum de
transformation possible. La volonté est de rendre la plate-forme cible atteignable par une série
de multiples d'étapes simples, minimales et maîtrisées (et le plus souvent réversibles) pour
maximiser le succès du projet en réduisant son taux de risque à zéro. Cette priorité se fait bien
sûr au détriment de certaines transformations structurelles qui restent bien sûr possibles par les
développeurs à l'issue du projet.
• à l'opposé de la transformation, l'automatisation totale est le choix privilégié afin de contenir les
coûts et délais du projet. Elle permet la continuité de la maintenance de l'application originale,
le plus souvent barrée durant une transformation profonde. Cette automatisation totale donne
également lieu à une méthodologie de tests efficace et objective. La validation du projet est
alors très « mécanique » au meilleur sens du terme alors que la transformation amène toujours
le projet dans des zones plus subjectives de validation.
3.2.2. Rehosting <> transcodage
• Le rehosting a pour principal but d'atteindre les mêmes économies très fortes que le
transcodage. Il y parvient le plus souvent même si l'analyse des licences de runtime doit être

menée a priori pour le garantir.
• son iso-fonctionnalité parfaite n'est pas toujours garantie. Il ne peut alors pas être « raccordé »
directement au système à migrer. Il conduit alors à la construction d'un système parallèle avec
tout le danger que cela comporte (voir ci-dessous la section « transformation »)
• de même, certaines constructions Cobol ou API mainframes ne sont pas toujours supportées par
le compilateur Linux. Elles nécessitent l'adjonction d'outils qui réalisent des modifications « les
plus compatibles possibles ». Ces outils d'adaptation doivent être totalement automatisés sans
aucune intervention manuelle sous peine d'empêcher la répétabilité de la compilation pour les
nouvelles versions de l'application quand sa maintenance doit continuer en parallèle de la
migration.
• le principal défaut du rehosting est de laisser l'application du client dans sa technologie
d'origine, en voie d'obsolescence, qui doit alors continuer à être maîtrisée et utilisée par des
développeurs Cobol.
• en ce sens, il ne résout par le problème de raréfaction (donc de cherté croissante) des ressources
humaines compétentes dans ces technologies en fin de vie. La masse des développeurs
« pointus » dans ces secteurs est actuellement en train de s'approcher de la retraite.
• une problématique sous-jacente est que le rehosting perpétue les technologies obsolescentes
avec la fourniture par les prestataires de librairies reproduisant les interfaces du mainframe
(CICS, batch, Cobol). Ce sont des librairies maintenues sous forme propriétaire avec une
pérennité non garantie. Le transcodage s'appuie quant à lui sur un socle technologique très
ouvert et portable (Java) dans toutes ses couches, qui sont toutes disponibles en Open Source,
gage total d'autonomie complète pour le client en cas de nécessité. Ce socle est d'ailleurs celui
des plus grands systèmes informatiques du moment (Google, Facebook, Amazon, etc.)
En synthèse, l'approche « rehosting » a des apports économiques très solides, similaires au transcodage.
Sa parfaite iso-fonctionnalité doit être vérifiée a priori pour éviter toute obligation de migration en
mode « Big Bang ». Par contre, le rehosting ne résout pas les problèmes cruciaux actuels pour nombre
de responsables informatiques : obsolescence des technologies de base et raréfaction rapide de la main
d’œuvre compétente nécessaire pour faire vivre les systèmes les utilisant.
Bien sûr, il apporte l'un des avantages également obtenu par le transcodage : la perpétuation de la
structure organisationnelle et des algorithmes de l'application originale car il maintient finalement
celle-ci totalement dans son contexte original.
Il est juste donc de voir le rehosting comme une solution aux problèmes tactiques de l'exploitation
(coûts) mais pas à ceux du développement, cependant beaucoup plus stratégiques pour le long terme
puisqu'il en va de la protection des lourds investissements en compétences métier par leur transposition
vers un contexte technologiquement pérenne.
3.2.3. Transformation <> transcodage
Le parti pris initial des solutions de transformation est justement de modifier l'application initiale pour

la moderniser et lui ajouter, si possible, de nouvelles fonctions par différents outils de « traduction ».
Les transformations apportées sont souvent doubles : technologiques (passage à Java, à html/ajax) et
fonctionnelles (restructuration structurelle, orientation objet, modification des processus, etc.).
Ces solutions de transformation ont pour objectif un bond fonctionnel en avant maximal : il n'est
clairement pas dans leurs objectifs de se soucier de l'iso-fonctionnalité assurant la compatibilité avec le
système à migrer.
De cette volonté d'évolution maximale découlent les quatre soucis principaux de la solution :
• Le taux de modifications fonctionnelles et algorithmiques est intrinsèquement très important. Il
est souvent très dur à ingérer par les développeurs en place qui passent, en général, par un
énorme « trou de productivité », le temps de reprendre pied dans les millions de lignes de code
source massivement restructuré qui leur sont livrés en fin de projet. Leur « prise en main »
nécessite toujours un fort investissement pour revenir au même niveau de maîtrise que celui des
codes sources de l'application originale. Des modifications trop importantes peuvent parfois
conduire à un rejet complet de cette forme de transformation.
• Une partie de ces transformations est le plus souvent manuelle : elles ne peuvent donc être
répétées qu'un nombre limité de fois durant le projet, sous peine d'en grever dangereusement les
coûts. Par ailleurs, cette même contrainte bloque le plus souvent la poursuite de la maintenance
de l'application dans sa forme originelle durant le projet de transformation. Ce point peut
devenir particulièrement gênant quand les contraintes du métier (réglementation, marché,
concurrence, etc.) lui imposent une évolution très rapide.
• Le nouveau système n'est pas compatible avec l'ancien. La migration offre alors seulement deux
voies vers ce nouveau système indépendant et parallèle :
◦ la migration « Big Bang » où tous les utilisateurs et traitements sont basculés ensemble au
Jour J : nombre de projets de migration de ce type sont tristement célèbres pour les dégâts
irréversibles (retours arrières très pénibles, etc.) qu'ils ont parfois causés. Il y a de toute
façon une taille limite et une criticité maximale du système initial au-delà desquelles ce
genre de migration est hors sujet !
◦ la migration incrémentale entre les deux systèmes (ancien et nouveau) fonctionnant en
parallèle : cette forme de migration donne alors naissance - obligatoirement - à un troisième
système, le plus caché possible, assurant la synchronisation des données entre les deux
systèmes. La problématique associée devient alors quasi-systématiquement celle de la
complexité de mettre en phase des systèmes conçus sans objectif de cohérence particulier.
Cette complexité s'accroît encore quand la synchronisation des données doit être à la fois
bidirectionnelle et en temps réel (ce qui est toujours le cas sur les plus grandes applications).
Il peut alors arriver que coûts et délais explosent sous les contraintes de ce système de
synchronisation, souvent sous-estimé dans les phases initiales du projet.
• La problématique des tests associés à la validation du nouveau système peut devenir
conséquente : ils doivent être bâtis à partir de rien. Ils sont donc générateurs de coûts bien
supérieurs à ceux produits très naturellement par la vérification directe de l'iso-fonctionnalité.

Enfin, l'acceptation du nouveau système doit se faire sur des critères comportant nécessairement
une part de subjectivité qui est totalement absente du transcodage iso-fonctionnel, strictement
objectif et quantifié dans sa validation.
Les objectifs d'une solution de transformation peuvent être extrêmement ambitieux tant sur les plans
technique que fonctionnel. Ils peuvent l'être d'autant plus que le prestataire est déchargé de la
responsabilité de compatibilité avec l'existant.
La contre-partie est celle de la création du système de synchronisation parfois fort complexe. La
validation du nouveau système peut également s'avérer pénible et coûteuse car ses tests de validation
sont à bâtir sans le support du système existant et ses critères de validation comportent une part de
subjectivité.
Il est donc juste de voir la transformation comme une protection de toute la propriété intellectuelle et
les compétences métier intégrées par le client dans son application à migrer. En cela, la problématique
stratégique du développement est correctement traitée. Mais, c'est le chemin de transition que cette voie
peine à définir correctement : il est soit impraticable par ses risques (Big Bang), soit extrêmement
coûteux et complexe (synchronisation). Il faut ajouter à cela un risque très fort de perte de maîtrise sur
la nouvelle version de l'application de par sa structure bouleversée.
4. Solution de Migration Eranea
Cette section rappelle les principes généraux de la technologie et de la méthodologie Eranea quand
elles sont utilisées dans le cadre d'une migration de mainframe vers architecture x86.
Il apparaît intéressant de décrire le mode opératoire d'une migration habituelle afin de voir les
avantages classiques de la technologie Eranea. Ils peuvent ensuite être adaptés à des cas plus
spécifiques : L4G comme Pacbase, Ideal-Datacom, besoins particuliers des éditeurs de logiciel,
simulateur indépendant basé sur une application opérationnelle, etc.
N.B. : dans un but de généralité et de clarté, la présentation ci-après est faite sur la base d'un contexte
système limité à z/OS, CICS, DB2. Elle est transposable à d'autres contextes (AIX, OS/400, Solaris,
OpenVMS, etc. à la place de z/OS, IMS comme moniteur transactionnel au lieu de CICS, Oracle
comme cible au lieu de DB2 LUW, présence de fichiers VSAM, etc.) le cas échéant.
4.1. Principes
La solution migratoire d'Eranea permet d'éviter toute migration brutale de type « Big Bang » pour des
systèmes complexes dans leur architecture et critiques pour le métier. Ces migrations brutales sont le
plus souvent vouées à l'échec et nécessairement très dangereuses pour les activités industrielles et
commerciales que le système supporte.
Au contraire, Eranea propose une méthodologie favorisant l'absence totale de risque et la forme
incrémentale complète du processus migratoire, tout en garantissant la poursuite des évolutions du
système sans aucune interruption de maintenance due à cette migration.
Pour les utilisateurs finaux, l'iso-fonctionnalité parfaite du nouveau système a un impact positif

essentiel : ils peuvent passer au nouveau système sans aucune nécessité de formation supplémentaire.
C'est un point essentiel pour la flexibilité de cette mutation. Par ailleurs, cette absence de formation
diminue d'autant les coûts du projet.
A la fin de la migration, les développeurs peuvent poursuivre sans perte de productivité l'évolution du
nouveau système nativement en Java. En effet, ils y retrouvent sans effort toutes les constructions
algorithmiques et syntaxiques familières du système originel. Ils poursuivent cette évolution dans le
cadre d'outils au niveau de l'état de l'art : IDE Eclipse, outils de qualité Java, etc.
Eranea contribue, par ailleurs, à l'amélioration de cette productivité en fournissant un plugin pour
Eclipse (adaptable aux autres IDEs) qui permet, entre autres, une édition efficace du code source
original Cobol (si le besoin persiste pour certains développeurs fortement réfractaires à Java), un
transcodage instantané dans l'IDE, un debugging interactif orienté vers le langage original
(visualisation des structures de variables avec leurs valeurs, etc.)
L'ensemble du système informatique migré est alors conforme à l'état de l'art aussi bien pour
l'exploitation que pour le développement.
4.2. Méthodologie
Eranea a développé sa technologie pour satisfaire les contraintes de la méthodologie de migration
qu'elle juge optimale : complètement incrémentale et sans aucun risque. Elle est fondée sur l'utilisation
des bases de données en tant que « pivot » et vecteur de communication / collaboration en temps réel
entre l'ancien et le nouveau système.
Ses outils permettent une migration :
• 100 % automatisée : le code source originel est transformé vers Java / JEE et html/ajax sans
aucune intervention manuelle. Ceci est réalisé, par exemple, en moins de 15 minutes pour une
application de plus de 10 millions de lignes de code source.
• parfaitement iso-fonctionnelle : le code Java produit les mêmes résultats « au bit près » dans
sa version Java que via le code original. Les algorithmes et leur structure de codage sont
rigoureusement conservés dans le code traduit. En conséquence, les résultats stockés en base de
données partagée par le Java transcodé sont indiscernables de ceux fournis par l'application
originale. De même, pour l'utilisateur final, l'ergonomie de l'interface homme-machine est
absolument identique dans la technologie html/ajax résultante : mêmes champs dans les mêmes
écrans, mêmes séquences de saisie et d'enchaînement inter-écrans.

migration incrémentale via automatisation 100% et iso-fonctionnalité intégrale (1)
migration incrémentale via automatisation 100% et iso-fonctionnalité intégrale (2)
De ces 2 caractéristiques fondamentales découlent les avantages essentiels de la méthodologie :
1. équivalence fonctionnelle : l'automatisation totale de la conversion permet de transcoder les
nouvelles versions de l'application dans leur langage original au fur et à mesure de la
maintenance. Le système Java peut donc être mis à jour exactement en même temps que le
système original : il reste ainsi au même niveau fonctionnel tant que les 2 fonctionnent en
parallèle.

2. continuité de l'évolution : le point précédent permet de continuer la maintenance et les
évolutions du système au fil des contraintes réglementaires, des changements du métier, des
nouveaux produits introduits sur le marchà, etc. C'est un critère très important lorsque la
migration est appelée à durer longtemps pour des raisons de sécurité (incrémentalité maximale)
ou de taille (forte échelle du projet).
3. fonctionnement parallèle collaboratif : l'application transcodée est connectée à la base de
données de l'ancien système (via JDBC et DRDA) comme seule source de données. Cette base
de données sert donc de pivot et de vecteur de collaboration entre le monde Java et celui du
mainframe.
Les résultats produits par l'ancien code et le nouveau code Java sont indiscernables. Il suffit
donc que la base de données soit commune aux 2 systèmes pour que leurs utilisateurs y
partagent le fruit de leur travail et donc collaborent en temps réel exactement comme ils le font
dans le système original isolé : à travers les informations stockées.
La base de données utilisée est donc celle du système original durant toute la migration des
traitements. Quand cette phase est terminée et que l'arrêt total du système initial est visé,
la base de données peut être migrée sur système ouvert.
Si un système de messagerie asynchrone du type MQ Series, ou un outil similaire est utilisé, le
serveur central reste sur z/OS durant la migration puis bascule vers Linux et JMS, selon le
niveau d'utilisation de MQ, en fin de projet.
4. Incrémentalité de la migration : le point précédent permet une migration très incrémentale.
Pour le système dans son ensemble, les résultats persistants en base de données d'un traitement
sont les mêmes, qu'ils soient exécutés sur la version originale ou Java. Puisque la base de
données est unique, il est donc indifférent qu'un traitement soit exécuté sur le mainframe ou sur
son homologue Java. En conséquence, il est possible de déplacer individuellement chaque
utilisateur interactif ou chaque étape de traitement d'un travail batch selon des contraintes ou
objectifs qui peuvent être externes au projet de migration lui-même. La vitesse d'exécution du
projet pourra donc être adaptée au contexte opérationnel du moment chez le client, afin d'en
maximiser l'efficacité.
5. absence de risque : l'incrémentalité de la migration permet d'éliminer les risques car les
utilisateurs ou traitements batch peuvent être transférés 1 par 1 sur le nouveau système. Tous les
risques globaux d'une migration de type Big Bang sont ici totalement absents ! Il ne faut que
quelques « pionniers » pour valider chaque composant migré : leur travail quotidien via ces
nouveaux composants sert de validation sans perte de productivité puisque les pionniers sont
connectés à la même base de données que leurs collègues encore sur l'ancien système. Ensuite,
le « gros de la troupe » peut arriver par vagues successives de plus en plus importantes au fil de
la prise de confiance sur le nouveau système. C'est la technique des « petits pas continus vers
l'avant » : elle induit une certaine durée mais donne de bien meilleures garanties de succès !
6. tests continus : le niveau de risque est encore abaissé par la mise à disposition d'un système de
tests automatisés. En effet, l'iso-fonctionnalité permet en permanence de tester
« mécaniquement » et automatiquement la validité du système.

Des scénarios de référence capturés sur l'ancien système via 3270 peuvent être rejoués à la
demande sur le système Java pour en comparer l'identité des résultats (tant au niveau de la base
de données que des écrans). Il en est de même pour les traitements batchs. Le système
mainframe sert donc de « spécifications live » tant qu'il existe et en comparaison duquel la
validité du nouveau système Java peut être garantie en permanence. En conséquence, les mises
en production mainframe + Java simultanées évoquées plus haut sont réalisées avec une
garantie parfaite de qualité, d'ailleurs tant pour le système mainframe que pour le système Java.
Ces tests unitaires qualitatifs sont également utilisés sous forme de tests de charge par exécution
parallèle multiple afin de valider le bon comportement lors des pointes d'activité.
7. incréments et investissements minimaux : dans l'absolu, un seul et unique serveur x86 est
nécessaire pour héberger les premiers traitements migrés. Le coût d'investissement pour le
démarrage initial du projet est donc absolument minimum. De même, les serveurs
correspondants à la croissance ultérieure du système pourront être acquis et mis en service de
manière unitaire au fil des besoins. Ils peuvent bien sûr être strictement identiques aux modèles
déjà standardisés par le client. Des instances Linux virtualisées dans le cadre d'un hyperviseur
de virtualisation déjà en place chez le client sont également possibles.
8. maintenabilité : le code source Java généré à partir de l'application originale est destiné à être
maintenu en tant que nouveau code source de référence à la fin du projet. Eranea a donc fait de
gros investissements pour en assurer la lisibilité et la maintenabilité. De plus, d'importants
investissements ont été également réalisés pour simplifier aussi la migration des développeurs
vers leur nouveau patrimoine logiciel.
Les algorithmes et structures syntaxiques sont préservés au maximum afin de leur « faciliter la
vie » et de préserver toutes leurs compétences métier (finalement, le plus important de leurs
savoirs !) dans du logiciel dont ils connaissent et maîtrisent parfaitement la structure.

Eranea a donc fait le choix délibéré de favoriser la productivité des développeurs dans leur
nouvel environnement et leur adhésion au projet plutôt que l'orthodoxie théorique du code
généré.
Il serait en effet contre-productif voire irréaliste et même dangereux de les « ensevelir » sous
des millions de lignes de code source certes iso-fonctionnelles mais totalement restructurées et
donc longues (voir impossibles) à assimiler dans le seul but de les rendre plus conformes
aux formes canoniques de la programmation orientée-objet.
4.3. Technologie
La technologie Eranea comporte 5 domaines :
• Les composants de transcodage utilisés durant le projet tant que Java n'est pas intégralement
devenu le nouveau langage de référence.
• Le framework d'exécution utilisé durant et après le projet, aussi longtemps que le code Java
maintenu fait appel à des méthodes d'iso-fonctionnalité et d'émulation livrées par ces librairies.
• Un système d'intégration continue permettant l'automatisation complète du transcodage au
déploiement multi-serveurs sur Cloud privé des nouvelles versions des applications.
• Un framework et une application de monitoring / alerting temps-réel pour permettre aux
équipes système / exploitation un suivi centralisé des multiples serveurs d'applications.
• Les composants IDE : plugin Eclipse (ou autre IDE) permettant l'édition de l'application
originale (si souhaité) et l'accès efficace aux fonctions de gestion du cycle de vie du logiciel.
Eranea a développé en interne l'intégralité de sa technologie spécifique de transcodage, de
développement, de déploiement, d'exécution, et de suivi des applications. Les librairies et composants
tiers sur lesquelles elle s'appuie comptent parmi les plus grands standards de l'Open Source (Java JEE,
Apache Commons, Jenkins, Subversion, etc.). Notre solution offre donc toutes les garanties nécessaires
de qualité, de pérennité et d'évolutivité.

4.3.1. Transcodage
système de transcodage
Pour atteindre les avantages clefs décrits dans le paragraphe précédent, Eranea installe pour chaque
projet son système de transcodage automatique au sein des infrastructures du client. Il se compose
essentiellement :
• d'un entrepôt logiciel basé sur Subversion et alimenté en continu depuis le mainframe par les
évolutions du code applicatif original et du code Java résultant de son transcodage
• d'un moteur d'intégration continue sur base Jenkins en charge de l'exécution de tous les travaux
automatisés :

intégration continue : synoptique
◦ alimentation en code source à partir du mainframe puis stockage dans l'entrepôt logiciel,
◦ analyse structurelle /syntaxique et structuration du code source original,
◦ transcodage vers Java des programmes et copybooks applicatifs, vers XML pour les
descriptions d'écrans (BMS, etc.) et JCLs,
◦ compilation du code Java produit,
◦ packaging Java : war, ear, etc.
◦ déploiement automatique sur les multiples niveaux systèmes de développement, tests
d'intégration et production
◦ [selon l'organisation classique du monde mainframe, les étapes « transcodage » à
« déploiement » sont en fait le plus souvent exécutées plusieurs fois en parallèle pour gérer
des codes sources différents en fonction de leur niveau de validation dans les différents
environnements du client (développement, intégration / recette, formation, production, etc.)
• du système de capture et exécution automatisée des tests comparatifs 3270 <> html/ajax. Il est
en fait intégré à NeaControlCenter (auparavant nommée Integrate - voir ci-dessous) pour sa
partie interactive et déclenché par le moteur d'intégration continue pour sa partie batch. Ce
système de capture est également utilisé pour la capture et le replay de tests de programmes
batchs.
• de la base de données relationnelles stockant tous les éléments précédents :
◦ rapports d'analyse et structuration du code original et du code Java : erreurs, suggestions
d'améliorations du codage Cobol initial, etc.
◦ définition des tests et compte-rendus de leurs exécutions
◦ journaux de tous les travaux exécutés par le moteur d'intégration continue
◦ logs et informations diverses remontées des systèmes opérationnels
• de l'application NeaControlCenter permettant :
◦ la consultation de la base de données contenant les informations précitées et le
déclenchement manuel direct de certaines actions et traitements : transcodages,
déploiements, etc.
◦ la consultation des données d'inventaire du client (liste des applications, programmes,
copybooks, …) avec des fonctionnalités avancées de recherche par références croisées, taux
de couverture par tests unitaires ou simplement full-text.
La pratique habituelle consiste à héberger chaque composant Eranea (entrepôt logiciel, base de
données, moteur d'intégration, application NeaControlCenter) sur une instance Linux séparée.

4.3.2. Framework d'exécution
association transcodeur + runtime
Plusieurs librairies composent le framework d'exécution NeaRuntime. Elles assurent toutes les
fonctions d'iso-fonctionnalité (sémantiques du autre langage de programmation, APIs transactionnelle
et batch, interface homme-machine) et d'émulation (moniteur transactionnel, interface homme-
machine, fonctions batch, etc.) de l'environnement initial.
Elles sont automatiquement insérées dans les paquetages Java (war, ear, etc.) correspondant aux
applications transcodées fabriquées par le moteur d'intégration continue.
Les JCL des programmes batch sont eux transcodés vers une structure XCL (format XML spécifique
développé par Eranea) qui transpose iso-fonctionnellement les directives JCL originales. Ces structures
XCL pour les différents travaux sont traitées par un interpréteur idoine pour assurer l'enchaînement des
steps d'appels de programmes ou utilitaires tiers (SORT, etc.) selon les directives ou paramètres initiaux
du JCL.
L'ensemble de NeaRuntime est très fortement instrumenté au standard JMX pour donner accès à des
centaines de métriques (valeurs instantanées, compteurs, états, etc.) concernant tous les objets actifs à
l'exécution (programmes, zones mémoire, cpu, queues, terminaux, sessions, etc.) pour répliquer /
dépasser le niveau de transparence des moniteurs transactionnels et batchs du mainframe.
Toutes ces métriques peuvent être visualisées dans toute console compatible standard JMX (Zabbix,
Centreon, etc.) pour être consultées en live ou historisées afin offrir aux équipes d'exploitation toute la
transparence de fonctionnement dont elles peuvent avoir besoin. L'application NeaControlCenter utilise
également toutes ces métriques pour répliquer en mode web tous les outils auxquels les exploitants sont
habitués sur le mainframe.

4.3.3. Environnement de développement
Un plugin Eclipse (ou autre IDE) est installé sur la station de travail des développeurs. Il étend les
fonctions standard de l'IDE autour de Java afin de permettre de visualiser et éditer facilement le code
source original Cobol durant et après le projet tant qu'il en est fait usage : Java doit devenir le nouveau
langage de référence mais certains développeurs Cobol ont besoin d'un temps d'adaptation parfois
supérieur à la durée du projet pour passer à Java. Le plugin leur permet donc de continuer à faire
évoluer leurs programmes en Cobol et il les transforme « au vol » en Java.
Java doit à terme devenir le langage de référence pour pouvoir faire un levier maximum sur le nouveau
code source généré par les outils Eranea : toutes les fonctions spécifique à Java / JEE ne peuvent être
intégrées que de cette manière.
Ce plugin permet également un accès simplifié aux fonctions de gestion du cycle de vie du logiciel
fournies par la plate-forme Eranea et / ou celle du client.
5. Architecture technique Eranea
Cette section présente brièvement les divers composants de l'architecture technique standard proposée
par Eranea. Elle permet de mieux cerner les contours de l'infrastructure matérielle et logicielle du
système résultant d'une migration de mainframe vers x86.
5.1. Objectifs fonctionnels
L'architecture technique mise en place délivre les mêmes garanties de service en termes de qualité de
service (« Service Level Agreements » - SLAs - sur temps de réponse, débit global, disponibilité,
reprise après désastre / catastrophe, etc.) que le système original.
Les briques technologiques de base décrites ci-dessous sont combinées pour atteindre les exigences de
ces SLAs.
5.2. Composants techniques
5.2.1. Serveurs x86 et stockage
Eranea n'a pas de spécifications particulières pour le choix des fournisseurs de serveurs x86
(processeurs Intel Xeon) et du stockage. Elle peut s'appuyer sur les standards déjà en place chez le
client.
Concernant le stockage, il est cependant quasi-impératif qu'il soit centralisé sur un SAN commun à tous
les serveurs du nouveau système afin de ne pas limiter les possibilités apportées en termes de haute
disponibilité et de performances (migration inter-serveurs d'instances, cloning « live » d'instances, etc.)
par les instances virtualisées sur l'hyperviseur.
En complément, les couches de virtualisation propriétaire (VMWare) ou ouvertes (kvm) offrent toutes
des fonctions nécessaires de tolérance aux pannes et haute disponibilité.

Elles amènent une très forte activité de communication entre la machine hébergeant une instance
sécurisée et celle hébergeant son clone de secours. En effet, tous les secteurs de disque et les zones
mémoires modifiés sont transférés en temps réel vers l'autre machine de même que, par exemple, les
informations sur les connexions TCP.
Dans de telles situations, l'interconnexion entre les machines (switches de réseau local) ainsi que
l'architecture d'accès au stockage permanent doivent être particulièrement disponibles et performantes.
Le recours à des systèmes spécialisés (« engineered systems » - type IBM PureFlex, Cisco UCS ou
Oracle ExaLogic) peut s'avérer nécessaire si des très forts débits sont à atteindre sur des instances
critiques.
Équivalence x86 <> processeurs propriétaires PowerPC, Sparc, etc
Enfin, il est à noter, au vu du graphique ci-dessus que la puissance nominale des processeurs x86 est
actuellement identique (voire supérieure) à celle des processeurs propriétaires (y.c les processeurs
mainframe) qui, dans le passé, justifiaient leur prix plus élevé par une puissance supérieure.

dominance de l'architecture x86
Intel et AMD disposent désormais d'une part de marché plus que dominante sur le marché des
processeurs pour serveurs de tout type : bien au-delà des 2/3 en valeur (voir graphique ci-dessus) et
encore bien davantage en nombre d'unités : 9'850'000 serveurs x86 par an contre 210'000 serveurs Risc
et moins de 4'000 mainframes de type z/OS. Cette dominance très forte leur permet d'offrir la même
puissance de calcul que leurs concurrents à un prix beaucoup plus faible.
En effet, ils produisent un nombre de pièces très élevé dont le prix est de plus en plus défini par la
quantité de R&D qu'elles incluent. Intel et AMD peuvent donc amortir cette R&D sur beaucoup plus
d'unités et donc être imbattables en termes de ratio prix-performances. Les benchmarks de type TPC-C,
par exemple, démontrent ceci sans ambiguïté.
Ce processeur, qui est, par ailleurs, le seul utilisé dans les plus grandes infrastructures mondiales
(Google, Facebook, Amazon, etc.), est clairement le meilleur choix du moment pour délivrer
l'infrastructure la plus efficace possible en termes économiques. Ce processeur profite d'ailleurs du
« bouillonnement innovateur » de ces grands systèmes pour s'améliorer en permanence par une
collaboration étroite entre les clients et le fondeur de silicium.
Tout ceci sans compter que le développement de l'architecture x86 est, en sus, mutualisé par son emploi
décliné dans des versions adaptées sur d'autres plates-formes : PCs de bureaux, ordinateurs portables,
etc.
5.2.2. Virtualisation
Dans les comptes satisfaits par les outils qu'ils ont mis en place, Eranea utilise la virtualisation
existante pour autant qu'elle permette de réaliser le niveau de service souhaité par le client en termes de
haute disponibilité et de tolérance aux pannes.

Dans les comptes « vierges » sur le sujet et recherchant des coûts optimaux, Eranea recommande une
stratégie Open Source.
Satisfaisant les critères précédents, c'est la plate-forme kvm (déclinée éventuellement en RedHat RHEL
pour une version supportée ) qu'Eranea recommande pour un choix de virtualisation OSS dans un
compte « vierge » de standard : l'appui architectural fort de kvm sur le noyau Linux en fait
l'hyperviseur qui évolue le plus vite actuellement de part la taille de la communauté de développement
du noyau, ce qui indirectement contribue de manière massive et continue aux performances et aux
fonctionnalités de kvm.
5.2.3. Distribution Linux
Dans le cas d'un cloud privé type CloudStack ou OpenStack, la distribution Linux est apportée par la
solution globale. Dans une architecture plus traditionnelle, elle est choisie selon les principes suivants.
Eranea utilise la distribution Linux en place chez ses clients.
Pour ceux à la recherche d'une situation plus classique avec un fournisseur supportant officiellement ce
système d'exploitation, Eranea recommande la distribution RHEL de Redhat :
• Elle a obtenu, en termes de sécurité, la certification EAL4+ , niveau identique aux autres
systèmes et plates-formes standards du marché (Solaris, AIX, VMWare, etc.).
• Elle fait partie d'une suite d'outils Redhat (Satellite, etc.) qui permet une gestion efficace
(configuration, patching, monitoring, etc.) de multiples instances.
• Elle dispose d'un support commercial adapté aux grandes entreprises et possède des références
prestigieuses dans ces entreprises. C'est la distribution leader du marché professionnel.
• Elle permet d'avoir une bonne connexité avec le serveur Java AS si celui-ci est JBoss et donc
de réduire le nombre de fournisseurs.
Eranea n'a pas réellement de dépendance envers Linux pour le système cible : certains projets terminés
fonctionnent sous MS-Windows qui est aussi la plate-forme quotidienne de travail d'une partie
importante de nos développeurs. Des tests voire des projets ont également été faits sur Solaris, AIX et
sur z/OS lui-même. La devise « Write Once, Run Anywhere » de Java est donc abondamment vérifiée
et a été un critère décisif du choix exclusif de Java par Eranea.
Cependant, il est clair que la prédominance de Linux dans le monde des serveurs d'entreprise s'accroît
au fil des ans en tant que solution fortement éprouvée à très grande échelle et financièrement optimale.

évolution du marché des systèmes d'exploitation
Dans le cas d'environnements de grande échelle, le recours à Linux permet l'utilisation de composants
système nécessaires à l'élaboration d'architectures apportant hautes performances, haute disponibilité et
tolérance aux pannes. Elles s'appuient sur le serveur web Apache, ses extensions ainsi que des
composants de type HAProxy, etc. qui permettent la construction de clusters très puissants et solides
dans leurs couches basses. (voir ci-après)
5.2.4. Application Server (AS) Java
Pour les projets transactionnels peu complexes, Eranea recommande Apache Tomcat.
Par ailleurs, Eranea respecte les interfaces JEE : elle peut donc s'adapter à tout serveur d'application qui
les respecte aussi et peut de toute façon adapter son code à un AS qui s'en écarterait. JBoss de Redhat,
WebLogic d'Oracle et Websphere d'IBM sont 3 choix possibles.
Pour les contextes favorables à l'Open Source et à l'efficacité financière résultante, Eranea
recommande, pour la compatibilité JEE, la voie JBoss (version communautaire AS7 ou version
supportée commercialement EAP-6 actuellement) de Redhat car elle offre :
• une sophistication très élevée, allant jusqu'à compléter le standard JEE par ses propres
solutions (cache-mémoire, communications multicast, gestion par domaine, etc.) dans les
domaines où ce standard ne définit rien (haute disponibilité, etc.). Certaines de ces fonctions
avancées (cache, load balancing, etc.) sont impératives pour les plus grands projets.
• une garantie officielle de compatibilité JEE : Oracle a certifié JBoss AS7 comme « fully-
compliant » au niveau 6 (le dernier) des spécifications du standard JEE.
• un niveau de prix très bas : soit la gratuité totale pour la version communautaire, soit des
redevances modestes pour la version commerciale (issue d'ailleurs de la version
communautaire et très proche de celle-ci)

• un fournisseur identique à Linux (si RHEL est choisi par ailleurs) donc une simplification
organisationnelle.
5.3. Architecture transactionnelle
Dans le cadre de partitions z/OS indépendantes ou de paires de partitions couplées par Sysplex, le
cluster de traitement décrit ci-après pourra en fait être réalisé à plusieurs exemplaires indépendants de
plus faible échelle pour augmenter encore la flexibilité et l'efficacité économique du système résultant.
Une infrastructure constituée de multiples serveurs x86 est donc pleinement justifiée. Ils doivent
cependant être placés « au pied du mainframe » (i.e sur le même réseau local, avec un nombre
minimum de hops et avec un fort débit LAN : > 1 Gbps) durant la migration afin que les accès aux
données via JDBC / DRDA ne soient pas grevés par des temps d'aller-retour vers le mainframe trop
longs.
La bonne connectivité au mainframe doit permettre de rendre la durée de ces allers-retours sans
impact : dans ses projets avec une infrastructure idoine, Eranea limite le temps réseau autour de 1 ms.
Pour les transactions, les temps de réponse seront alors préservés. Pour les batchs, les mécanismes de
prefetch vers DB2 au niveau des curseurs SQL annihileront l'impact de ces allers-retours
d' « approvisionnement en données ».
cluster de traitement multi-étages
L'architecture proposée pour ce cluster de traitement est à 3 étages :
• unification (1er étage) : un groupe très limité de machines (ou instances) pour unifier l'accès au
cluster, visible finalement à travers une seule adresse IP. Cette adresse masque les étages
supplémentaires, et donc leur sophistication ainsi que leur évolution au fil du temps. Équipé
principalement de HAProxy associé au module VRRP, ces machines se surveillent

mutuellement pour recevoir et traiter les requêtes TCP de création de sessions http.
Puis, elles passent les requêtes aux machines du 2ème étage du cluster selon des algorithmes
très simples (round robin, nombre de sessions actives, etc.) après s'être assurées de leur
présence.
Ainsi, le nombre et la configuration réseau des machines de distribution et traitement du cluster
peuvent évoluer librement sans qu'il soit nécessaire de reporter ces évolutions au niveau des
machines des utilisateurs ou d'autres serveurs d'infrastructure (DNS, etc.). Si un tel dispositif
existe déjà par ailleurs dans le système sous une forme de matériel spécialisé (type Cisco ACE
ou équivalent chez F5, etc.), il pourra remplacer l'étage 1 du cluster.
• distribution (2ème étage) : un ensemble de machines équipées d'Apache Web Server configuré
avec des modules qui permettent un dialogue dynamique bidirectionnel avec les instances d'AS
Java.
Ces instances d'AS peuvent ainsi renseigner Apache sur leur charge en temps réel. Apache peut
alors dispatcher les requêtes de transaction entrantes vers la machine la plus adaptée (i.e la
moins chargée) après la satisfaction des autres contraintes (entité organisationnelle source, type
de transaction, type de SLA, etc.).
Cet étage peut aussi éventuellement prendre en charge l'authentification et les autorisations si
l'architecture applicative le permet. Les machines du 3ème étage sont alors déchargées d'autant.
Cet étage peut s'appuyer totalement ou partiellement sur les fonctions de haute disponibilité /
tolérance aux pannes de la couche de virtualisation, ceci pour atteindre la satisfaction des
niveaux de contraintes les plus élevés des divers SLAs.
• traitement (3ème étage) : un ensemble de machines équipées de Java et de l'AS qui hébergent
le code des applications transcodées et l'exécutent au fil des demandes utilisateurs.
Les mécanismes de haute disponibilité / tolérance aux pannes au niveau Java AS sont combinés
de manière idoine avec ceux offerts par la couche virtualisation (voir plus haut) pour satisfaire
les divers niveaux de SLA.
Ces configurations spécifiques par niveau de SLA peuvent conduire une forme de spécialisation
des machines de l'étage 3. Cette spécialisation est connue de l'étage 2 pour dispatcher vers les
bonnes machines selon les contraintes des activités demandées.
L'ensemble de ces machines ne contient aucune donnée applicative spécifique. Elles sont donc très
similaires dans leur configuration (selon les étages et les niveaux de SLA) et peuvent ainsi être gérées
par des outils efficaces de pilotage /administration global au niveau des arrêts, démarrages, mises à jour
logicielles, etc.

5.4. Architecture batch
Elle est fondée sur 5 composants essentiels :
 L'ordonnanceur batch (Control/M de BMC, par exemple, mais valide aussi pour Autosys, TWS,
etc.) : il assure le séquencement des travaux selon la logique consignée dans le plan commun, ainsi
que la centralisation des événements asynchrones (fin de jobs, apparition de fichiers, etc.) et la
gestion du calendrier horaire pour déclencher les travaux pour lesquels toutes les conditions
d'exécution sont réunies. Son architecture permet une exécution distribuée mais un contrôle
centralisé des travaux s'exécutant sur les diverses plates-formes : un serveur central donne les
ordres d'exécution des travaux aux agents situés sur les diverses machines. Les rapports d'exécution
et le suivi des performances sont ensuite centralisés sur le serveur central depuis lequel l'ensemble
du suivi / administration du système, à travers une interface utilisateur riche, peut être réalisé sans
inefficacité particulière due au nombre de machines impliquées. Il permet également une bonne
coordination / synchronisation des chaînes de traitement incluant des travaux s'exécutant
successivement sur les différentes plates-formes : les conditions « OUT » générées par certains
jobs qui deviennent les conditions « IN » des jobs dépendants sont répercutées en transparence par
l'ordonnanceur d'un environnement à l'autre (z/OS <> Linux). De même, dans le cadre d'une
architecture x86 où le nombre de machines physiques / d'instances est multiplié, les travaux sur
chacune d'elles sont coordonnés strictement par un accès global efficace à ces conditions.
 Les exécuteurs batch : sous le contrôle de leur agent piloté par l'ordonnanceur central, ces
exécuteurs déroulent les scripts XCL et exécutent les chaînes de traitement applicatif par

l’enchaînement des appels aux programmes applicatifs et utilitaires tiers selon les sollicitations du
plan d'ordonnancement central.
 Le système de gestion de bases de données DB2 d’IBM qui reste le seul gestionnaire de base de
données. Il est accessible directement depuis les nouveaux composants x86/Linux/Java :
infrastructure de tests applicatifs, serveurs d’applications opérationnels, postes de développement.
Au niveau de ces systèmes, la connectivité à DB2 est vue sous forme JDBC depuis les composants
JAVA. Elle est ensuite effectivement assurée par un lien DRDA vers le mainframe.
 Le serveur NFS de partage des fichiers : il offre à toutes les instances de Linux, amenées à utiliser
des fichiers séquentiels, un accès partagé et uniforme aux fichiers permanents utilisés par le
système du client. Il s'appuie sur le SAN (existant ou futur) pour stocker effectivement ces données
et en assurer la sauvegarde (backup), ainsi que le mirroring synchrone si il est nécessaire aux
niveaux de services garantis formellement aux utilisateurs. Il peut être associé aux services HFS de
z/OS qui rendent accessibles sur le même mode des fichiers qui doivent encore être partagés entre
z/OS et Linux.
 Les machines (instances) délivrant les éventuels services complémentaires indispensables : pilotage
des sorties, impressions effectives, envoi de mails, etc. Ces services sont accessibles par toutes les
machines exécutant les diverses chaînes en batch.

Eranea : presentation technique de la solution de transcodage Cobol vers Java, automatique et iso-fonctionnel

Recommended

Recommended

More Related Content

Similar to Eranea : presentation technique de la solution de transcodage Cobol vers Java, automatique et iso-fonctionnel

Similar to Eranea : presentation technique de la solution de transcodage Cobol vers Java, automatique et iso-fonctionnel (20)

Eranea : presentation technique de la solution de transcodage Cobol vers Java, automatique et iso-fonctionnel