_______________________________________________________________________
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:
- Projet NACA [4]: exemple de programme transcodé de Cobol vers Java - plugin Eclipse
- Projet NACA [3]:présentation technique et économique globale du projet
- Projet NACA [2]: transcodage automatique vers Java de 4 millions de lignes Cobol
- Projet NACA [1]: motivations et stratégie
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 ...
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.
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:
Je trouve ce projet particulièrement intéressant et souhaiterai savoir si il sera prochainement disponible en téléchargement ?
Bonjour Anonyme,
A priori pas pour l'instant. En ces de besoins particulier, contactez-moi sur mediaandtech@gmail.com
cordialement
didier
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 ... ?
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.
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
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
Enregistrer un commentaire