Qui aurait pu croire que le COBOL serait toujours aussi actif à l'ère des langages objets.
Mais aujourd’hui les éditeurs de compilateurs COBOL manquent de politique tarifaire concurrentielle et c'est dans cette absence d'alternatives abordables que le logiciel Open Source s'est développé.
À l'instar de beaucoup d’outils de migration COBOL vers un autre langage, OpenCobol agit comme un pré-processeur COBOL vers C au même titre que ecpg de Postgres est un pré-processeur de Pro*C vers C. Et c'est là que se trouve le génie, même si certains pourraient considérer que conserver des programmes en COBOL est un handicap, tout le monde s’accorde pour en reconnaître la facilité de maintenance.
Tout code migré d'un langage vers un autre impose un effort technique louable, mais perd souvent en lisibilité. Et les équipes de développement s'attacheront davantage au langage cible qu'à l'esprit du langage source, voire aux fonctionnalités à maintenir.
COBOL est bien mieux adapté aux applications manipulant les chiffres et fournissant des rapports que tout autre langage comme le C, le java : gardons notre patrimoine COBOL et faisons des économies. Pour information OpenCobol sert de compilateur et de run-time pour le logiciel de paie de la préfecture de Nagasaki, pour le logiciel de comptabilité publique et budgétaire utilisé par le conseil général du Val de Marne (Progiciel d’environ 1,5 million de lignes COBOL).
Ce billet est là pour rappeler que toute technologie a pour objectif de rester innovante mais surtout d'être efficace.
Aller plus loin
- Site OpenCobol (1759 clics)
- Dernières nouvelles sur le site OpenCobol (365 clics)
- FAQ OpenCobol sur le site add1tocobol (114 clics)
# Cobol to java
Posté par Julien04 (site web personnel) . Évalué à 6.
Il y a aussi le projet NACA qui transcode vers Java.
Quelques journaux DLFP :
http://linuxfr.org/news/projet-naca-migration-mainframe-ibm-vers-serveurs-intellinux
http://linuxfr.org/news/outils-de-transcodage-cobol-vers-java-du-projet-naca-publi%C3%A9s-sou
http://linuxfr.org/news/projet-naca-2-transcodage-automatique-vers-java-de-4-millions
Ils ont même monté une entreprise pour proposer des services de migration.
A priori pour eux le but était surtout d'économiser sur les Mainframe IBM.
[^] # Re: Cobol to java
Posté par Jean-Max Reymond (site web personnel) . Évalué à 10.
J'ai porté près de 1,5 millions de lignes Cobol d'un logiciel de gestion financière de Cobol vers Java grâce à l'outil Open Source Naca et le résultat devrait rentrer ce mois ci en production dans de très grandes collectivités locales françaises pour la gestion de leurs finances.
Ce traducteur Naca génère exactement une ligne de code java pour une ligne de cobol, permettant ainsi à un programmeur Java de comprendre assez facilement de quoi il s'agit.
Le code généré est facilement tracable grâce aux outils log4j manipulables à distance via JMX permettant de tracer le runTime Naca jusqu'à l'affectation de chaque variable. Les performances sont tout à fait correctes et similaires à celles qu'on obtient en cobol. Par contre, l'approche une ligne cobol donne une ligne java rend très difficile une approche objet mais le traducteur aurait d mal à inventer ce qui n'existe pas au départ.
La solution OpenCobol avait été envisagée afin de s'affranchir des couts de runtime très élevées de la solution commerciale microFocus et le portage en OpenCobol puis tests montrent que cela fonctionne parfaitement bien pour peu d'avoir codé en Cobol standard. Ce qui a fait pencher vers une solution Java c'est qu'avec l'OpenCobol il y a obligation de maintenir le code Cobol car le code C généré est incompréhensible ce qui veut dire programmeurs Cobol qui sont rares sur le marché, facilité d'interopérer avec des briques java pour la solution Naca, tout le code traduit est tracable quasiment ligne par ligne.
Dans les deux cas, ce sont de très bonnes solutions OpenSource de qualité industrielle.
[^] # Re: Cobol to java
Posté par Didier DURAND (site web personnel) . Évalué à 5.
Bonjour Julien et Jean-Max,
Merci des appréciations flatteuses sur le projet Naca que j'avais lancé à l'époque puis open sourcé quand la 1ère migration fur terminée.
Je sais que l'approche ligne à ligne peut paraître surprenante voire iconoclaste mais c'est du pragmatisme: on permet une adaptation rapide des développeurs venant du Cobol.
Il y a une vraie demande: c'est pour cela que nous continuons à développer l'approche initiale Naca dans la société Eranea montée pour poursuivre le développements des outils.
Les besoins sont généralement doubles: économie et modernisation.
Et effectivement, la traçabilité (et les stack dumps…) de Java améliore la "transparence" du Cobol initial lors de débordements de tableaux et autres approximations coutumières de certains programmes Cobol. Sans parler du "plaisir" à pouvoir débugger du Cobol transcodé via le debugger Java d'Eclipse.
Nous utilisons ces outils actuellement à la migration (10M lignes de Cobol) d'une privée genevoise de renom. Me contacter pour détails.
PS: on voit aussi beaucoup de sociétés qui veulent passer au Cloud Computing vite mais qui sont bloquées par l'entrave que représente Cobol. Le transcoder vers Java lève l'écueil.
Bons projets de transcodage
A dispo si questions
didier
# Pas de bol, j'aime pas le COBOL
Posté par Enzo Bricolo 🛠⚙🛠 . Évalué à 8.
Quel est le discours des "rentiers" de la compilation COBOL concernant ces technos ?
J'avais évoqué le sujet avec le fournisseur d'une solution de gestion RH il y a quelques années et c'était très clair, le compilateur hors de prix au support douteux d'un éditeur tiers était "obligatoire" pour qu'il garantisse le support de l'application. Il voyait ça comme un "échange de bons procédés" entre les deux éditeurs.
# Objectivité zéro
Posté par gasche . Évalué à 10.
La dépêche commence mal avec une phrase d'une platitude incroyable :
Ensuite arrive la pépite :
Ah bon, et comment justifie-t-on cette affirmation ? Avez-vous des exemples de code pour nous convaincre ? N'est-il pas possible d'implémenter les fonctionnalités domaine-spécifiques de COBOL sous forme de bibliothèques logicielles en Java par exemple—comme le font d'ailleurs les nombreux acteurs proposant des outils de migration du code (exemple) ?
Cette dépêche présente un traducteur de Cobol vers C. Très bien. Il y a beaucoup de code COBOL encore en utilisation et à maintenir, on a compris. Mais pourquoi nous prendre le chou avec tout un blabla de justification du style « oui mais COBOL c'est pas si mal et il faut garder notre patrimoine et d'abord c'est facile à maintenir et c'est productif et les gens qui n'aiment pas COBOL sont des vilains » ?
[^] # Re: Objectivité zéro
Posté par Raoul Volfoni (site web personnel) . Évalué à 4. Dernière modification le 02 juin 2012 à 12:10.
Je partage entièrement ton point de vue et j'ajouterai que pour avoir bouffé du Cobol pendant plusieurs années notamment sur un projet de gestion financière de contrats multidevises ce dernier n'était pas capable de gérer plus de 5 chiffres après la virgule sans faire d'arrondi ou de troncature dans les opérations, ce que les comptables ne pouvaient évidemment accepter.
Je trouve donc l'affirmation du journal très mal venue.
D'autre part le Cobol était avant tout utilisé sur des départementaux (DEC, BULL, etc.) ou des sites centraux (IBM principalement).
Je me demande vraiment ce que ce compilateur vient faire sous Windows et Mac…
[^] # Re: Objectivité zéro
Posté par JGO . Évalué à 7.
Vu les performances des machines récentes, peut-être que certains envisagent de migrer certaines applications anciennement mainframe sur des machines plus légères ?
[^] # Re: Objectivité zéro
Posté par claudex . Évalué à 10.
Je pense que c'est surtout plus pratique pour les développeurs de pouvoir faire une partie des tests en local plutôt que d'occuper un mainframe pour ça.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: Objectivité zéro
Posté par Raoul Volfoni (site web personnel) . Évalué à 5.
Ca c'était à la mode il y a 20 ans, on a même inventé un mot pour ça: le downsizing. C'était juste après le revamping et avant le rightsizing. (oui je sais FOUTAISES !!! :)
Est-ce qu'il reste encore beaucoup d'applicatifs dont la migration vers le x86 soit possible ? Je connais des banques et assurances pour qui ce n'est absolument pas envisageable. Peut-être quelques structures intermédiaires oui.
[^] # Re: Objectivité zéro
Posté par PLuG . Évalué à 5.
Mais bien sûr qu'il en reste !
La plupart des applications mainframes n'evoluent que très peu, et sont hébergées sur des partitions de plus en plus restreintes par rapport à la puissance globale de la machine. Ce qui cause des problème :
- en dessous d'un certain pourcentage de performance de la machine ce n'est pas rentable de louer la partition.
- quand on loue une partie de la machine on est en collocation … synchronisation des changements de config hardware, … que du bonheur
Sans parler du cout de partitions supplémentaires pour faire du dev ou de la qualif … si jamais on veut faire évoluer l'application.
C'est donc sûr, il reste des applications mainframe a migrer. Il reste a trouver le bon levier (souvent financier, mais ça peut être le besoin de faire évoluer la solution) … et hop "downsizing" comme tu le dis.
Pour participer a ton business loto, je rajoute que en hébergeant la cible en n-tiers (data / traitement / …) il n'y a a priori pas de raison de "puissance" pour que la migration ne se fasse pas. les seules raisons de ne pas migrer c'est
- la peur du projet qui est souvent gigantesque (risque)
- le prix du projet (en combien de temps on l'amorti ?)
- la capacité à mener le projet (meme en sous traitant, il faut bien se tapper les tests…)
- avoir mieux a faire maintenant tout de suite, le projet est interessant mais… plus tard
mes 2c
# curiosité..
Posté par maboiteaspam . Évalué à 10.
Ne connaissant pas du tout cobol, j'aurais simplement voulu voir des exemples permettant d'apprécier que "COBOL est bien mieux adapté aux applications manipulant les chiffres et fournissant des rapports".
[^] # Re: curiosité..
Posté par FantastIX . Évalué à 3. Dernière modification le 04 juin 2012 à 12:01.
On va dire que si dans un an et un jour tu n'as pas de réponse, ce sera facile à déduire…
# Taille de code
Posté par spider-mario . Évalué à 6.
Je me demande combien de lignes de code comporterait le même programme écrit dans un autre langage.
[^] # Re: Taille de code
Posté par Lebas Sébastien . Évalué à 1.
Et la réponse … n'a strictement aucun intérêt ! Le seul intérêt des lignes de codes est de comprendre pourquoi le bouzin mets 10 heures à compiler, ou éventuellement de prouver que le soft existe depuis longtemps avec une politique de type "plat de spaghetti". Style "non mais mais on garde mais on mets une option de compilation pour ne plus compiler ce bout de code, on se sait jamais, ça peut toujours servir".
[^] # Re: Taille de code
Posté par lolop (site web personnel) . Évalué à 8.
Pas complètement. Il y a une corrélation entre le nombre de lignes écrites et le nombre de bugs, un langage qui permet de fournir les mêmes fonctionnalités en moins de lignes a à priori moins de bugs.
Python 3 - Apprendre à programmer dans l'écosystème Python → https://www.dunod.com/EAN/9782100809141
[^] # Re: Taille de code
Posté par DerekSagan . Évalué à -4.
D'où la quasi absence de bugs en C puisqu'on peut écrire tout le programme sur une seule ligne, au besoin elle est longue et elle contient beaucoup de points d'interrogation.
J'ai été assez loin dans l'absurde où il faut que je continue?
[^] # Re: Taille de code
Posté par Alek_Lyon . Évalué à 1.
Le nombre de lignes donne peut donner une très vague idée de la complexité d'un projet.
Cependant dans le cas du COBOL, on peut dire 1.5 million de ligne dans ce langage = 150 000 lignes en C. ;-) Bon j'exagère probablement, mais le COBOL est vraiment très verbeux et il ne faut pas se laisser tout de suite impressionner par un tel volume de code.
[^] # Re: Taille de code
Posté par romi . Évalué à 1.
sûrement bien moins!
je crois que COBOL est le langage qui produit le plus de lignes de code en moyenne
à moins qu'on ai fait pire depuis (ou mieux c'est selon…)
# Baratin et pas
Posté par rpnpif . Évalué à 9.
Baratin commercial. Non, une technologie n'a pas et ne devrait pas avoir pour objectif de faire du neuf pour du neuf, sauf les attrape-gogos de certaines marques. et pourtant c'est une opinion incrustée comme une bernique sur un rocher quiberonnais.
Exemple : MS Windows 7 innove par rapport à Windows XP. Ah bon ! Et alors ?
Yes ! Oui ! Voilà ce que doit être l'objectif d'une technologie.
Exemples : Linux versus MSW, Linus C versus Gates C++…
Quoi ? Il y a un problème ? ;-)
# Fortran c'est mieux
Posté par Marotte ⛧ . Évalué à 5.
Fortran vs Cobol
[^] # Re: Fortran c'est mieux
Posté par DerekSagan . Évalué à 8.
Peste vs Choléra ?
[^] # Re: Fortran c'est mieux
Posté par FantastIX . Évalué à 3.
Et Mono? La Syphilis?
--> []
[^] # Re: Fortran c'est mieux
Posté par Alex . Évalué à 3.
Pas la peine de partir, c'est une très bonne comparaison.
Dans les 2 cas tu as pris dans un premier temps du plaisir
# Capillotractage
Posté par Lol Zimmerli (site web personnel, Mastodon) . Évalué à 0.
Mais sait-on si COBOL utilise les little ou big endian ?
La gelée de coings est une chose à ne pas avaler de travers.
[^] # Re: Capillotractage
Posté par alaindominique . Évalué à 1.
D'après la FAQ opencobol :
"OpenCOBOL uses standard big-endian internal storage by default."
# Mauvaise approche
Posté par bugsan . Évalué à 0.
Bonjour,
Je me permets de commenter. Je suis développeur Java/JEE depuis 5ans, et chez un client dont le mainframe et le cobol sont sacro saint. Où les mythes du style "cobol c'est + mieux que vos jouets en java" sont fortement ancrés dans la tête des décideurs…
Il y a quelque points à aborder ici.
1) Il n'existe pas de benchmark opposant cobol à d'autres langages. Toutes les affirmations sur la célérité du cobol sont des paroles en l'air venant de manager dont le but est de justifier les facturations d'IBM.
De mon expérience personnelle, je peux affirmer qu'il n'y aucune raison pour qu'un programme cobol traite un fichier plus rapidement qu'un autre écrit en C ou Java. Deuxièmement, en ce qui concerne les accès transactionnels (TP), ils sont incroyablement peut performant en comparaison des serveurs d'application, notamment à cause des allocations mémoires aux couts stratosphérique.
A l'heure des google, facebook, twitter… cela fait pale figure. Quand on sait que derrière facebook il y a plusieurs "jouets" opensource comme Hadoop qui permettent de gérer des péta-octets de données. Tout ce petit monde est écrit en C/Java et ça fonctionne plutôt bien vous ne trouvez pas ? J'ai également en tête une société qui a mise au point un logiciel de trading, en java, capable de traiter 6 millions de transaction par seconde sur une "vulgaire" machine x86 de quelques milliers d'euros.
2) L'emprise des mainframe est problématique. Les entreprises françaises publiques comme privées sont pieds et poings liés à une société américaine (IBM). Bonjour la stratégie économique …
3) Convertir ligne à ligne des programmes écrits en COBOL dans un autre langage n'est pas du tout la bonne approche. La transcription de langage est à mon avis une catastrophe. La bonne approche est d'écrire un émulateur, une et une seule fois permettant de faire fonctionner l'ensemble des programmes cobol sur une plateforme pérenne. Cela a été fait pour la JVM. En effet on peut maintenant faire tourner des programmes cobol dans une JVM… et mieux que ça, on peut les déployer dans un Cloud. C'est à dire que l'on remplace le mainframe IBM qui coute des millions d'euros par des instances EC2. Les IHM restent en CICS 3270.
[^] # Re: Mauvaise approche
Posté par bugsan . Évalué à 0.
Oups j'ai parlé d'émulateur alors que la solution dont je parle est un compilateur Cobol=>bytecode. Aux temps pour moi ^
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.