Discussion :

[Bill Fassinou]

IBM crée un compilateur COBOL pour les systèmes GNU/Linux basé sur l'architecture x86
dont la disponibilité générale est annoncée pour le 16 avril

IBM a annoncé mardi un nouveau compilateur COBOL pour les systèmes GNU/Linux sur x86. Baptisé "IBM COBOL for Linux on x86", l'arrivée de ce compilateur prouve pour la énième fois que ce langage est loin d'être mort. Conformément à l'annonce de Big Blue, ce nouveau compilateur apporte les technologies et les capacités de compilation COBOL d'IBM à l'environnement Linux sur x86. L'entreprise pense en effet que les organisations possédant toujours des systèmes hérités avec du code COBOL pourraient avoir besoin de télécharger leurs applications dans un cloud hybride.

COBOL continue de fausser les statistiques prédisant sa mort. De nombreux systèmes hérités existent encore aujourd'hui dans plusieurs organisations dans le monde, notamment les banques et les administrations publiques. La raison ? Sa stabilité et son efficacité et les coûts élevés (et les risques) de la reprogrammation, avec des langages plus modernes, des processus qui se sont consolidés au fil du temps. Les développeurs doivent fournir de grands efforts de reprogrammation, même pour les plus petits changements, comme c'est le cas dans certains États américains avec leurs systèmes informatiques de chômage.

À titre d'exemple, l'Iowa, le New Jersey, le Kansas et l'Oklahoma ont toujours leurs systèmes de chômage écrits avec le langage COBOL. En dehors du coût élevé de la reprogrammation, les développeurs préfèrent souvent se consacrer à des langages plus modernes, ce qui explique le fait que les programmeurs capables de travailler avec des sources anciennes sont de plus en plus rares. Ces raisons expliquent pourquoi IBM, qui travaille aujourd'hui activement sur des technologies modernes telles que le cloud hybride, propose ce nouveau compilateur COBOL.

« COBOL for Linux on x86 1.1 est le dernier né de la famille des compilateurs COBOL d'IBM, qui comprend Enterprise COBOL for z/OS et COBOL for AIX », a écrit mardi IBM dans un billet de blogue décrivant le nouveau compilateur. Selon l'entreprise, COBOL for Linux on x86 est un environnement de développement productif et puissant pour la création et la modernisation d'applications COBOL. Il comprend un compilateur COBOL optimisant et une bibliothèque d'exécution COBOL. COBOL for Linux on x86 est basé sur la même technologie d'optimisation avancée que Enterprise COBOL for z/OS.

Selon Big Blue, il offre à la fois des performances et des capacités de programmation pour le développement d'applications COBOL critiques pour les systèmes Linux sur x86. En outre, l'autre idée derrière le lancement de compilateur est de donner la possibilité aux organisations ayant encore des applications écrites avec COBOL de les porter vers un cloud hybride. « COBOL for Linux on x86 est conçu pour accompagner les clients dans leur voyage vers le cloud. Il permet de déployer stratégiquement des applications critiques écrites en COBOL dans un environnement de cloud hybride », a expliqué IBM.

Cela peut signifier un mélange de z/OS, AIX, mainframes et Power Systems. En effet, les ateliers COBOL ont reçu la promesse que des efforts de personnalisation et des délais de livraison minimaux sont nécessaires pour déployer stratégiquement des applications COBOL/CICS développées pour z/OS vers des environnements Linux sur x86 et des clouds. La nouvelle offre y parvient en établissant un lien avec DB2 et le Customer Information Control System d'IBM, de sorte que les applications sur Linux utilisant x86 peuvent dialoguer avec les anciennes applications COBOL.

Big Blue a également intégré un support XML natif pour favoriser l'interopérabilité, et créé un utilitaire de conversion qui peut migrer le code source COBOL développé avec des compilateurs COBOL non IBM. Mais l'annonce suggère également qu'IBM ne croit pas complètement que cet outil a un avenir, car il conclut : « Cette solution offre également aux entreprises la possibilité de déplacer les charges de travail vers IBM Z si les exigences de performance et de débit augmentent, ou de partager la logique et les données de l'entreprise avec CICS Transaction Server pour z/OS ».

Quelle est la configuration requise ? Un serveur x86-64 avec l'une des distributions suivantes : Red Hat Enterprise Linux 7.8 (ou supérieures) ou Ubuntu Server 16.04 LTS, 18.04 LTS, ou une version supérieure. L'annonce d'IBM estime que le compilateur "COBOL for Linux on x86" sera disponible le 16 avril 2021.

Source : IBM

Et vous ?

Que pensez-vous du choix d'IBM de proposer un nouveau compilateur pour COBOL ?
Selon vous, pourquoi les banques et les administrations publiques s'en tiennent toujours à leurs vieux systèmes écrits avec COBOL ?
Pensez-vous que ce soient seulement la difficulté de la reprogrammation et son coût élevé qui expliquent la volonté de ces organisations de continuer à utiliser les anciens systèmes ?

Voir aussi

À plus de 60 ans, le langage COBOL est encore utilisé par des États américains, les laissant face à un manque de programmeurs et des coûts de développement énormes

Êtes-vous un développeur COBOL ? Si oui, il pourrait y avoir encore des opportunités pour vous dans le domaine de la finance

Micro Focus annonce la sortie de Visual COBOL pour Visual Studio 2017 qui offre aux développeurs COBOL la possibilité de coder avec l'EDI

Le langage de programmation Cobol fête ses 60 ans. Peut-il encore tenir longtemps face à la concurrence des nouveaux langages ?

[Nyrlodas]

Avant toute chose, je précise que je travaille sur du Mainframe IBM depuis 20 ans avec quelques expérience sur du COBOL microfocus pour UNIX. Je travaille essentiellement pour des grandes banques ou assurances.

Que pensez-vous du choix d'IBM de proposer un nouveau compilateur pour COBOL ?
C'est une bonne chose. Et de toute façon, ce n'est pas la première tentative d'IBM de faire du COBOL sur Linux, puisque il existe ZDT qui permet d'émuler une machine z sur un serveur linux.


Selon vous, pourquoi les banques et les administrations publiques s'en tiennent toujours à leurs vieux systèmes écrits avec COBOL ?
Pour commencer, le volume du code est parlant.
Ensuite, le code en lui même est le produit de dizaines d'année de création et modification. Le fonctionnement des grands comptes (banques/assurances) n'est pas que technique. Les règles de gestions sont complexes et nombreuses.
Les essais de transformation ont été nombreux et souvent non concluant (voir plus loin).


Pensez-vous que ce soient seulement la difficulté de la reprogrammation et son coût élevé qui expliquent la volonté de ces organisations de continuer à utiliser les anciens systèmes ?
Les tenants d'une transition vers des langages plus modernes ne voient souvent qu'un aspect du problème : le code.
Mais le mainframe à une longue histoire derrière lui. Et ce n'est pas un boulet à tirer (comme certains veulent le croire), mais une expérience et une culture.
J'ai fait plusieurs projets en coopération avec d'autres technologies, et je dois dire que ce que j'ai vu ne m'a pas convaincu.
De plus, les "nouvelles technologies" sont toujours "nouvelles", le coût de l'adaptation est assez grand. Alors qu'un DSI voudra privilégier la stabilité et prendra en compte le coût de maintenance total (y compris les transformations technologiques).

Un exemple :
Il y a trois ans, j'ai participé à un grand projet COBOL/JAVA pour une banque. Le projet s'accompagnait d'un changement de technologie de communication entre le Mainframe et l'IHM.
Auparavant, les règles de gestion étaient partagés entre les deux technologies. Avec ce nouveau projet, le DSI a imposé que l'intégralité des règles de gestion soit portée par le Mainframe. La partie webservice et IHM, n'avait même pas le droit de faire une addition ou même de gérer le paramétrage de l'affichage.

[Gugelhupf]

Je sais qu'il y a encore beaucoup de gens qui vont dire "COBOL va continuer à vivre très longtemps", qu'il y a une grosse base de code (comme s'il y en avait pas avec les autres langages), et que certains apprécient même beaucoup ce langage, mais si IBM prend ce type d'initiative pour moi l'idée est d'essayer de garder les clients IBM (en diminuant le prix du MIPS et connexion DB2, en proposant des alternatives qui tournent sur leur Mainframe, de faciliter l'utilisation de COBOL etc) qui passent vers les nouvelles technos et lorsque cela est possible légalement vers du cloud.

Les banques et assurances craignent la concurrence (GAFA, Bitcoin etc) et ce n'est pas avec ce type de techno qu'ils pourront garder l'emprise. Il n'y a qu'à aller dans une banque pour certains traitements, on vous demander d'attendre 24h, c'est-à-dire leur batch de nuit Donc tôt ou tard tous y passeront, mais si IBM peut les retarder en proposant des offres alternatives tant mieux pour lui

Un autre sujet plus tabou, ce sont la base d'employés (développeurs COBOL), ce n'est pas évident pour un développeur (quelque soit la techno qu'il utilise) de changer de langage et d'environnement qu'il a su apprécier, lui dire que la techno qu'il a pratiqué pendant au moins 10 ans "n'est pas foufou" et qu'il y a "mieux ailleurs" c'est l'insulter. Nombreux sont les facteurs pour rester sur du COBOL encore quelques années mais cela ne durera pas éternellement.

[smarties]

Les systèmes COBOL ont fait leur temps, mais le déficit de compétence (personnes qui partent à la retraite, peu de nouveaux) va obliger les entreprise à quand même changer de technologies.
Cela prendra du temps mais à long terme je pense que COBOL va disparaitre.

[TotoParis]

Préambule :
Je suis sur Mainframe depuis 1985...Donc mon vécu, mon expérience sont assez conséquents. J'ai même fait des applications en Assembleur à cette époque.
COBOL sur une architecture autre que mainframe sous Z/OS, ce n'est pas une nouveauté : AS400 (devenu 'i"), AIX (Unix d'IBM) existent depuis pas mal de temps.
Il était logique que les autres plate-formes en bénéficient un jour.

• Que pensez-vous du choix d'IBM de proposer un nouveau compilateur pour COBOL ?

C'est une bonne chose. Cela permet de porter des applications vers autre chose que du COBOL MICROFOCUS.
Mais ce n'est pas une alternative gratuite non plus ! Mais c'est un gage de sérieux.

• Selon vous, pourquoi les banques et les administrations publiques s'en tiennent toujours à leurs vieux systèmes écrits avec COBOL ?

C'est pour deux raisons très simples au fond :
Le coût de re-développement sans refonte fonctionnelle, sans plus value pour le client, n'est pas toujours une bonne chose.
Le risque d'accident industriel est souvent très gros. Ce ne sont pas des applications qui peuvent êtres mises à l'arrêt bien longtemps.
Donc, le mieux reste hélas souvent l'ennemi du bien.
Quant à faire rivaliser JAVA et COBOL en terme de performance, je pense que le second arrive haut en tête.
Bien des applications ne sont pas vieilles du tout, loin de là...
IBM est un fournisseur sérieux également, ce qui rassure les clients. C'est très important.
L'Open Source c'est chouette, jusqu'au jour où le software concerné est lâché par son fondateur...ou son éditeur (comme Google avec AngularJS remplacé par Angular "tout court").
COBOL a beaucoup évolué : on peut même faire du parsing XML avec DB2 (ce qui est très différent de l'instruction COBOL "XML PARSE"), c'est dire !

• Pensez-vous que ce soient seulement la difficulté de la reprogrammation et son coût élevé qui expliquent la volonté de ces organisations de continuer à utiliser les anciens systèmes ?

Pour des applications de gestion, COBOL (et PL/1) restent des langages tout à fait adaptés. Comme FORTRAN pour la calcul scientifique, et dont les dernières versions n'ont rien à envier à d'autres langages, que ce soit en termes de performance et de syntaxe. Des programmes COBOL sur Z/OS dialoguent avec des services web, ce qui n'est pas un mince exploit en fait. Quelle belle adaptation, non ?
Mais il reste le problème des compétences disponibles. Même si plein de jeunes sont formés régulièrement formés, les anciens très expérimentés s'en vont peu à peu, ou passent à d'autres fonctions. C'est particulièrement vrai en France. Donc on ne peut pas "bazarder tous les 4 matins" des applications d'au moins 1 million de lignes...

Conclusion :
Il manque quand même des aspects modernes à ce langage, comme pouvoir définir des fonctions comme on peut le faire en C ou en Pascal (même FORTRAN le permet depuis bien longtemps). De nouveaux types de données devraient pouvoir être implémentés : DATE, TIME, TIMESTAMP, sans avoir à passer par des bidouilles en DB2.
Mais surtout il manque des outils modernes : Il y a bien une version d'Eclipse, mais pas certain que le coût soit abordable, sans parler de la connectivité à un système Z/OS.
Et là on tombe dans le travers de cette modernité : alourdir considérablement le poste de travail quand Z/OS la garde en son sein (et n'oublions pas les gestionnaires de version : là aussi c'est un grand folklore sous UNIX ou WINDOWS).

[Escapetiger]

Je sais qu'il y a encore beaucoup de gens qui vont dire "COBOL va continuer à vivre très longtemps", qu'il y a une grosse base de code (comme s'il y en avait pas avec les autres langages), et que certains apprécient même beaucoup ce langage, mais si IBM prend ce type d'initiative pour moi l'idée est d'essayer de garder les clients IBM (en diminuant le prix du MIPS et connexion DB2, en proposant des alternatives qui tournent sur leur Mainframe, de faciliter l'utilisation de COBOL etc) qui passent vers les nouvelles technos et lorsque cela est possible légalement vers du cloud.

Les banques et assurances craignent la concurrence (GAFA, Bitcoin etc) et ce n'est pas avec ce type de techno qu'ils pourront garder l'emprise. Il n'y a qu'à aller dans une banque pour certains traitements, on vous demander d'attendre 24h, c'est-à-dire leur batch de nuit Donc tôt ou tard tous y passeront, mais si IBM peut les retarder en proposant des offres alternatives tant mieux pour lui

Un autre sujet plus tabou, ce sont la base d'employés (développeurs COBOL), ce n'est pas évident pour un développeur (quelque soit la techno qu'il utilise) de changer de langage et d'environnement qu'il a su apprécier, lui dire que la techno qu'il a pratiqué pendant au moins 10 ans "n'est pas foufou" et qu'il y a "mieux ailleurs" c'est l'insulter. Nombreux sont les facteurs pour rester sur du COBOL encore quelques années mais cela ne durera pas éternellement.

En sus de l'excellent sujet et des références de Bill Fassinou, un thème parfait pour les «anciens combattants du numérique» auxquels j'appartiens :

Sur developpez
Migration Zos vers UNIX/LINUX

Abandon du ZOS pour les systèmes distribués

Le prerequis a connaitre pour utiliser Cobol sous linux

Sur la toile
Les banques restent fidèles à Cobol, plus performant que Java - Le Monde Informatique

Cobol : un vieux langage terriblement à la mode - Le Monde Informatique


et, un peu plus loin dans le temps (décembre 2013) mais toujours d'actualité notamment en ce qui concerne les autorisations bancaires :

«
A priori Cobol est un langage dépassé, tombé dans les oubliettes de l’histoire informatique. D’ailleurs souvent on dit que l’acronyme ne veut pas dire COmmon Business Oriented Language mais Completely Obsolet Business Oriented Language. Mais est-ce si sûr ? J’ai écrit sur ce blog un court message le 19 décembre 2011 titré : « Quel avenir pour le Cobol ? ». C’était il y a deux ans ! Or aujourd’hui encore c’est un des textes les plus consultés du blog. Il se classe en second après celui sur : « La gestion de projet : peut mieux faire ». Ce texte représente 12% des consultations parmi la vingtaine de messages se trouvant sur le blog. L’analyse montre qu’une partie de ces lecteurs viennent par Google avec la recherche « avenir du cobol » ou « Cobol avenir ». Dans ces conditions on peut s’interroger et se demander si effectivement Cobol aurait un avenir ?

(.../...)

• Un silence étourdissant
• La concurrence était rude
• Les charmes de Java
• Un choix stratégique
• Y-a-t’il une autre solution possible ?
• Le problème de la formation au Cobol

(.../...)

Gary Barnett, directeur de la recherche chez Ovum estime que 90 % de toutes les transactions financière et 75 % de l’ensemble des transactions dans le monde allant du retrait d’argent à un DAB, à la réservation d’un billet d’avion ou à la saisie d’une facture se font à l’aide de programmes écrits en Cobol. Il évalue le nombre des transactions quotidiennes supportées par un programme écrit en Cobol à 30 milliards.

»

Source : Rapport Salzman: Le Cobol n’est toujours pas mort


[Edit]
Et en terme de connaissance du COBOL, du Mainframe, j'avais postulé fort de ma double compétence avec l'environnement Unix-Linux, il y a environ 10 ans (soit à l'âge avancé de 40 ans) auprès de prestataires informatique en France qui voulaient déja des personnes plus jeunes et immédiatement formatées formées; ce avec la bénédiction de leurs donneurs d'ordre, les grands comptes banque-assurances, grandes administrations , etc.

D'où le «succès» des formations de type Adaming comme ci-dessous:
Avis sur Adaming - SSII

[Edit2]
A propos de la mentalité en France voire en Europe sur la durabilité des développeurs (et IT professionnels en général), on pourra faire un tour ci-après :
Trolldi : à partir de quel âge est-il raisonnable pour un développeur de s’orienter ailleurs ?
Plus de développeurs en France? - Blogs - Forum du club des développeurs et IT Pro - VBurel

etc.

[alexvb6]

Je poste fréquemment au sujet de l'ASP Classic, langage capable d'incroyables prouesses et performances lorsque bien architecturé et employé. Super modulaire, donc ad-hoc pour des centaines de besoins différents.
Incroyablement rapide sur les machines actuelles.

Une grande majorité de mes clients développe quelques morceaux nouveaux dans d'autres langages, mais n'a, comme pour le COBOL, aucun intérêt à reprogrammer leur ASP Classic du fait de l'énorme risque industriel.

==> C'est vieux ? Oui.
==> Ça marche et permet de répondre à 90% de nos besoins ? Oui.
==> Les 10% restants sont-ils faciles à créer dans un autre langage et inter-opérables avec de l'ASP Classic ? Oui.

Bon alors la conclusion du SWOT est toute trouvée :

• Strengths : 100%
• Weakneses : 10%
• Opportunities : 90%
• Threats : 10%

[TJ1985]

COBOL, pour de la gestion, du business comme son nom l'indique, est idéal. Il permet de gérer les quantités financières exactement, s'écrit assez facilement, et surtout se relit facilement lorsqu'il a été fait proprement, a savoir sans spaghettis. Il offre en natif le nécessaire pour une gestion de fichiers sophistiquée et des interfaces efficaces vers les bases relationnelles. Il embarque aussi un reporting assez sophistiqué. Fortement normalisé, son code passe facilement d'une plateforme à l'autre.
Sous VMS (RIP) il était possible d'écrire des fonctions (sous-routines) de plusieurs manières, la capacité d'importer des fichiers source lors de la compilation permettait une bonne normalisation, les vitesses d'exécution obtenues et la consommation spartiate de ressources étaient d'excellents arguments.
J'ai participé au passage sur WINTEL vers 1995, et j'ai surtout constaté qu'à part quelques fonctions réellement graphiques d'analyse financière, la plupart des développeurs concevaient leurs GUIs comme des variations de la matrice 25x80...
En gros, pour de la gestion au niveau de l'entreprise, on pourrait globalement estimer que l'abandon des mainframes et ordinateurs départementaux n'a pas changé grand chose.
Je rigole encore plus lorsque je vois tout le monde se précipiter vers le Cloud, ce super-mainframe !
Pour moi, COBOL est une solution efficace, prouvée, à un ensemble de problèmes ciblés : Gérer les "comptabilités" et les relations d'une entreprise avec son environnement.
Je ne l'utiliserais pas pour de la modélisation scientifique, ni pour de l'IA, ni pour écrire un traitement de texte, ni, ni, ni... Mais pour de la gestion, oui, sans hésiter.