vendredi 05 février
Accueil :: Dépêches :: Entretiens :: Journaux :: Forums :: Sondages :: Suivi :: Statistiques :: Contact :: Plan

Liens connexes

Dépêche modérée par

Dépêche éditée par

: Outils de transcodage COBOL vers Java du projet NACA publiés sous GPL/LGPL

Posté par Didier DURAND (page perso, ). Modéré le 10 septembre 2008.
19
Publicitas met à disposition de la communauté Open Source sous licence GPL/LGPL les outils développés dans le cadre de son projet NACA de migration automatique de son mainframe IBM/zOS sous Cobol vers des serveurs Intel/Linux sous Java. Cette publication a été récemment annoncée aux RMLL2008 de Mont-De-Marsan.

Ce sont ainsi l'équivalent de plusieurs années-homme de travail qui sont retournées à la communauté du logiciel libre afin de catalyser pour d'autres le mouvement dont Publicitas a bénéficié en choisissant Linux comme plate-forme stratégique, il y a 5 ans maintenant.

Le but est de poursuivre via la communauté le taux de couverture du Cobol par ces outils afin de les rendre de plus en plus généraux.

> Lire la suite (18 commentaires, moyenne: 3,7).   [dépêche : 5809 caractères]

Cette version est clairement une première livraison (v1.0) : elle sera améliorée par les contributions (tierces) et documentée au fil du retour d'expérience donné par les testeurs externes qui feront fonctionner ces programmes Java sur leurs propres infrastructures. De nouvelles versions sont également à prévoir autour des bibliothèques JLib et NacaRT qui continuent, par leur fonction même, à être utilisées en production par Publicitas et étendues au fil des évolutions de nos systèmes.

La licence retenue est la licence GPL du projet GNU pour l'outil principal de transcodage et sa petite sœur LGPL pour les bibliothèques associées.

Pourquoi ce choix ? Parce que nous souhaitons éviter le détournement de notre travail par des prestataires de services à but lucratif souhaitant utiliser ces programmes pour leur seul bénéfice en le ramenant vers une zone propriétaire.

La GPL place pour ces prestataires sur les outils NACA un bon nombre de contraintes qui imposent le retour vers la communauté Open Source d'un maximum des améliorations faites par des tiers sur le transcodeur et ses bilbiothèques associées. Elle offre, par contre, une grande liberté aux sociétés utilisatrices finales.

La LGPL permet par ailleurs à des éditeurs de logiciels applicatifs de convertir leurs applications via nos outils (NacaTrans), de livrer nos bibliothèques runtime (NacaRT et JLib) en mode source mais de garder les bibliothèques de leur propre application en mode binaire afin de garder leur valeur compétitive dans le secteur industriel de leur application.

Les outils que nous publions aujourd'hui (v1.0) dans le fichier zip
Tous ces composants sont livrés avec les fichiers de description de projet au format Eclipse afin de faciliter leur prise en main via des outils standards du monde Java.

Maintenant, la question que vous vous posez sûrement : pourquoi cette démarche ?
Voilà, à vous de jouer : prenez le paquet complet indiqué ci-dessus et mettez-le en place dans votre contexte. Faites-nous part de vos suggestions par vos commentaires sur ce billet.

PS : pour des contacts autour de projets particuliers, vous pouvez nous contacter aussi plus spécifiquement par courriel à cette adresse : naca-contact at publicitas.com

Cette discussion est archivée, il n'est plus possible de laisser des commentaires.

Note : les commentaires appartiennent à ceux qui les ont postés. Nous n'en sommes pas responsables.

faut voir

Posté par volia () le 10/09/2008 à 11:18. (lien). Évalué à 4.

C'est bien de mettre son code à disposition.

Toutefois, toutes les expériences que j'ai eu avec des outils de traduction comme ça m'ont amené à penser qu'ils ne sont utiles que si on a vraiment pas le choix, et c'est rarement la meilleure solution. Le mieux c'est soit de réécrire, et d'en profiter pour repenser les applications (et le besoin ?), soit on garde l'existant.
J'ai souvenir d'un traducteur LISP vers Java... Le code est inmaintenable par la suite.

Et puis, je trouve bizarre l'idée de migrer COBOL vers Java. Une plateforme Unix n'est pas du tout comparable à un Mainframe. On n'y fait pas les choses de la même manière.

S'ils l'ont fait c'est qu'ils en avait besoin j'imagine, ou qu'ils ont cru en avoir besoin, mais ça me laisse perplexe.

Bon, je n'est pas regardé ce projet en particulier, peut-être qu'il est très bien quand même. Il n'y a pas des exemples de code traduit, histoire de se faire une idée ?

bravo

Posté par karmatronic () le 10/09/2008 à 11:46. (lien). Évalué à 4.

bravo pour l initiative,et chapeau parce qu il s agit d une tache dantesque que de rendre fonctionnel un tel transcodeur.
moi perso,je connais 2-3 entreprises françaises qui font tourner une grosse appli develloppée en cobol sous AS400,et qui aurait grandement besoin d evoluer vers du linux....!

Plateforme

Posté par pwet_ () le 10/09/2008 à 12:09. (lien). Évalué à 6.

Comment avez vous justifié auprès du client la perte de fiabilité en passant d'un mainframe à des pc ? Est-ce que le client a uniquement considéré l'aspect financier ou bien l'architecture système cible inclue-t-elle une forme de redondance ?

Revenir en haut de page

Run by Team LinuxFr.org

Cette page a été générée par Templeet en 0.1062s (dont 0.0183 de SQL).
Cette page est peut-être conforme xhtml 1.0.
Information sur le site.
Faire un don !