lundi, novembre 19, 2007

NACA [4]: exemple de programme transcodé de Cobol vers Java - plugin Eclipse

UPDATE 01-2012: Le projet NACA a donné naissance à Eranea, société dédiée à la migration 100% automatisée de grandes applications métier vers Java et Linux. Voir  www.eranea.com ou email à contact@eranea.com pour plus d'informations
_______________________________________________________________________
Mise à jour: le code source des outils du transcodage NACA est maintenant en Open Source. Voir http://media-tech.blogspot.com/2008/07/les-outils-du-projet-naca-de-publicitas.html.
[Introduction: cet article fait partie d'une série qui décrit le projet NACA ayant conduit au remplacement d'un mainframe IBM sous MVS/OS390 par des serveurs Intel sous Linux. Le projet a été lancé en Janvier 2003 et s'est terminé avec succès au 30 Juin 2007.

Il a été réalisé volontairement de manière 100% iso-fonctionnelle (i.e. sans aucune modification pendant et par le transcodage) pour l'application et a engendré la conversion automatisée de 4 millions de lignes de Cobol vers leur équivalent Java. L'économie en cash-outs - paiements externes - est de plus de 85% de leur montant annuel = initial d'environ 3 millions d'euros annuels

Articles déjà parus:
]

Le billet de la "saga" NACA d'aujourd'hui sera bref: il s'agit de produire un exemple concret de programme transcodé dans le fichier pointé par ce lien. Ce programme était l'un de nos programmes Cobol qui tournait sur le mainframe IBM avant la migration vers les serveurs Linux sur plate-forme Intel.

Vous y verrez que la largeur des lignes est importante: pour chaque ligne de Java généré, on retrouve à droite en commentaire la ligne de Cobol initiale dont a découlé la nouvelle ligne Java. La symétrie entre Cobol et Java est clairement mise en évidence.

Vous y verrez également les efforts de syntaxe faits au niveau Java pour que la construction syntaxique du Java soit la plus proche possible de la source Cobol.

Je rappelle les objectifs de tout ce travail de présentation du nouveau code Java (voir le billet [2] pour tous les détails):
  • lisibilité: dans la phase de mise au point initiale de notre transcodeur, il était fort utile d'avoir le parallèle structurel et la quasi-identité syntaxique
  • maintenabilité: même si nous travaillons à l'évolution / remplacement de Pub2000, l'application originelle, nous pensons qu'il faudra encore au moins 5 ans (voire 7 ans...) avant que le dernier programme Cobol transcodé ne disparaisse. Il est donc essentiel de favoriser par tous les moyens la productivité de nos programmeurs applicatifs. Ils sont maintenant formés à Java: ils peuvent donc entreprendre "l'objectification" des programmes transcodés pour revenir à un Java plus orthodoxe. Mais sans stress ...
Plugin Eclipse

Toujours dans le but d'améliorer la productivité de nos développeurs applicatifs, nous avons réalisé une plugin Eclipse (qui est devenu le nouvel environnement de développement maison). Il permet ainsi de travailler le Cobol / Java transcodé avec les meilleurs outils du moment.

Ci-dessous un screenshot de cette interface Eclipse pour notre transcodeur (cliquer l'image pour l'avoir en grandeur nature)


Ce plugin donne une interface graphique et interactive à notre transcodeur:
  • il permet la saisie /modification du code Cobol (pour la maintenance durant la migration) directement dans Eclipse: Les fonctions de coloration de mots de Eclipse sont utilisées pour rendre l'interface plus ergonomique.
  • il transcode automatiquement ce code source Cobol en code source Java puis génère ensuite le fichier .class. Les éventuels soucis dans le Cobol au moment du transcodage sont signalés dans l'onglet "Problems" (voir image ci-dessus): explication du problème, nom du fichier Cobol, numéro de ligne en erreur
  • il exécute ensuite Eclipse ce code généré via un conteneur Tomcat piloté par Eclipse via un autre plugin
  • il offre ainsi la possibilité d'utiliser le débogueur Java d'Eclipse pour éliminer les bugs. C'est un moyen très élégant (et gratuit!... cf le coût d'un poste de travail développeur Microfocus ) d'amener un debugger interactif dans le monde Cobol. Il est clair que cela n'est réaliste que grâce à la parfaite symétrie ligne à ligne entre Cobol et Java évoquée plus haut.
Au travers que représente ce qui précède, j'espère qu'il paraît maintenant limpide que nous avons fait tous les efforts possibles pour rendre cette migration iso-fonctionnelle de l'application Pub2000 la plus confortable donc la plus efficace possible!

Comme je l'ai dit dans les premier et second billets, c'est pour nous un clef essentielle de la réussite de notre projet.

Source: blog Media & Tech (par didier durand)

6 commentaires:

Anonyme a dit…

Je trouve ce projet particulièrement intéressant et souhaiterai savoir si il sera prochainement disponible en téléchargement ?

d.durand a dit…

Bonjour Anonyme,

A priori pas pour l'instant. En ces de besoins particulier, contactez-moi sur mediaandtech@gmail.com

cordialement
didier

Ontologiae a dit…

Très intéressant, j'avais suivi les deux premiers sur LinuxFr.
Mais cela signifie que lorsqu'on modifie le code Java, on doit rester dans la logique Cobol (car comme on le voit sur l'exemple, le code Java représente l'arbre syntaxique du code Cobol) ? Ce n'est pas trop dangereux de mixer les deux logiques par la suite ?
Pas trop difficile de migrer vers une logique beaucoup plus objet en utilisant des framework classiques comme hibernate, spring, etc ... ?

Anonyme a dit…

La Suite ! La suite du billet NACA...
Quels ont été les point durs ? Et les écueils à bien faire attention ? Au départ, combien de MIPS aviez vous en z/OS ? Quelle correspondance approximative n MIPS --> Intel ? Votre DB2, quel surface en Go ? Sur quel OS tourne aujourd'hui votre/vos UDB ? J'ai hâte de vous lire... Bien cordialement.

d.durand a dit…

Bonjour Anonyme,

J'ai en préparation le billet sur les points durs (juste le rush de fin d'année me freine un peu dans sa finalisation...)

Pour les autres infos, il faudra me contacter (adresse dans colonne de droite du blog) car je ne peux les publier toutes "froidement". Je me ferai par contre, un plaisir de répondre en 1 to 1.

PS: vous dites "du billet", je pense que vous voulez dire "des billets". Avez-vous lu les 3 autres en plus de celui-là?

cordialement
didier

d.durand a dit…

Bonjour Ontologiae,

Bien sûr que ce n'est pas simple de passer à du "vrai Java" avec Spring (que nous utilisons par ailleurs)

Mais, je rappelle notre objectif principal:
- réduire les coûts au plus vite (voir article 1) et ne pas noyer les développeurs de l'application initiale avec un déluge de technos.

Maintenant, avec les économies en poche, nous avons le temps de les laisser apprendre et refaire des pans entiers "proprement" (i.e. en vrai mode OO)

cordialement
didier