Introduction de "gcobol", un compilateur open source pour le langage Cobol basé sur les technologies GCC

Version imprimable

18/03/2022, 15h43
Bill Fassinou

1 pièce(s) jointe(s)

Introduction de "gcobol", un compilateur open source pour le langage Cobol basé sur les technologies GCC

Introduction de "gcobol", un compilateur open source pour le langage Cobol basé sur les technologies GCC
le code du projet est distribué sous la licence GPLv3

La liste de diffusion des développeurs de la suite de compilateurs GCC a présenté cette semaine le projet "gcobol", qui vise à créer un compilateur libre pour le langage de programmation Cobol. Dans sa forme actuelle, gcobol est développé comme un fork de GCC, mais une fois le projet finalisé et stabilisé, des changements sont prévus pour être proposés afin d'être inclus dans le noyau de GCC. Le code du projet est distribué sous la licence GPLv3.

Publié pour la première fois en septembre 1959, Cobol (Common Business Oriented Language) est un langage pour la programmation d'applications de gestion qui a été fortement adopté par les structures bancaires. Aujourd'hui encore, soit plus de 60 ans après son lancement, Cobol continue d'être utilisé dans certaines administrations, institutions financières et assurances, et IBM continue de proposer des mainframes prenant en charge le langage. Désormais, les développeurs de GCC veulent insuffler un nouvel élan au langage et ont présenté lundi le projet "gcobol", un nouveau compilateur libre et open source pour Cobol.

L'une des raisons sous-tendant la création d'un tel projet est le désir d'obtenir un compilateur pour Cobol, distribué sous une licence libre et simplifiant la migration des applications des mainframes IBM vers des systèmes utilisant Linux. La communauté développe depuis un certain temps un projet GnuCOBOL autonome et gratuit, mais il s'agit d'un traducteur qui traduit le code en C, et qui ne prend même pas entièrement en charge la norme Cobol-85 et ne passe pas un ensemble complet de tests de référence. Selon certains développeurs, cet état de choses décourage les institutions financières d'utiliser Cobol dans des projets professionnels.

Pièce jointe 615753

GnuCOBOL est une évolution d'OpenCOBOL. La FAQ d'OpenCOBOL note que : « OpenCOBOL a été initialement développé par Keisuke Nishida à partir de son expérience de travail sur TinyCOBOL développé à l'origine par Rildo Pragana ». En revanche, la présentation de gcobol explique que : « notre projet ne doit pas être confondu avec GnuCOBOL. Ce projet est un traducteur Cobol : il compile Cobol en C, et invoque GCC pour produire du code exécutable ». Un autre compilateur libre pour Cobol est "COBOL-IT". Ce projet français a développé une suite de compilateurs open source jusqu'à ce qu'il soit racheté par la société Micro Focus en 2017.

Le compilateur gcobol est basé sur la technologie éprouvée du GCC, et serait en cours de développement depuis plus d'un an, dans un mode de travail à plein temps, avec un seul ingénieur. Le backend GCC existant est utilisé pour générer des fichiers exécutables, tandis que le traitement du code source Cobol a été séparé dans un front-end séparé développé en interne. Dans les semaines à venir, gcobol prévoit d'inclure le support de l'ISAM (Indexed Sequential Access Method) et des extensions Cobol orientées objet. D'ici quelques mois, la fonctionnalité gcobol devrait passer la suite de tests de référence du NIST.

Le Cobol aura 63 ans cette année, et il reste l'un des plus anciens langages de programmation en activité, ainsi que l'un des plus importants en termes de quantité de code écrit. Le langage continue d'évoluer. Par exemple, la norme Cobol-2002 a ajouté des capacités de programmation orientée objet, et la norme Cobol-2014 a ajouté la prise en charge de la spécification à virgule flottante IEEE-754, des surcharges de méthodes et des tables extensibles dynamiquement. La quantité totale de code écrit en Cobol est estimée à 220 milliards de lignes, dont 100 milliards seraient encore utilisés, principalement dans les institutions financières.

Par exemple, en 2017, 43 % des systèmes bancaires continuaient à utiliser le Cobol. Le code Cobol serait utilisé pour traiter environ 80 % des transactions financières personnelles et 95 % des terminaux de paiement par carte bancaire. Du côté commercial, IBM a introduit un compilateur 64 bits pour AIX, puis un compilateur x86 natif. Visual COBOL de Micro Focus vous permet de construire pour .NET et Cloudflare l'exécutera dans le cloud. Comme suite de validation, les développeurs de gcobol travaillent à travers les programmes d'exemple du livre de 2014 "Beginning COBOL for Programmers", et gcobol compile avec succès une centaine d'entre eux.

Si vous êtes curieux, les programmes sont sur GitHub. Après cela, les développeurs prévoient de passer à la suite de test COBOL-85 du NIST. Par ailleurs, plusieurs rapports ont montré qu'il y a une demande considérable de programmeurs COBOL - depuis le problème de l'an 2000, les anciens sortent de leur retraite, à des prix élevés bien sûr. Mais aujourd'hui, beaucoup d'entre eux sont fatigués et les utilisateurs de COBOL, de plus en plus désespérés, ont lancé un appel aux volontaires pour les aider.

Source : gcobol (1, 2, 2)

Et vous ?

:fleche: Quel est votre avis sur le sujet ?
:fleche: Que pensez-vous du projet gcobol ?
:fleche: Selon vous, pourquoi le Cobol est encore tant utilisé dans le monde ?

Voir aussi

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

:fleche: AWS veut-il tuer les mainframes ? Le fournisseur de services de cloud computing veut remplacer les mainframes par des serveurs à grande échelle et COBOL par Java

:fleche: COBOL, VBA, MATLAB, NetBeans, Eclipse, IBM DB2, etc. Ces langages, EDI, et SGBD que les développeurs ne veulent plus utiliser. Quelles sont les technologies les plus aimées par les développeurs ?

:fleche: À 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
19/03/2022, 10h03
emilie77

Quelqu'un peut m'expliquer pourquoi, dans le monde du temps réel, le domaine bancaire a besoin de plusieur jour pour un virement? Je ne pense pas que le probleme soit pour le cobol
19/03/2022, 10h32
Luc Orient

Citation:

Envoyé par emilie77

Quelqu'un peut m'expliquer pourquoi, dans le monde du temps réel, le domaine bancaire a besoin de plusieur jour pour un virement? Je ne pense pas que le probleme soit pour le cobol

De nombreuses banques proposent des virements en temps réel, y compris à l'international ...
19/03/2022, 17h32
Invité

Le COBOL est surtout utile sur des OS spécifiques type IBM i. Les banques font le pari qu'il vaut mieux garder des vieux systèmes stables et robustes plutôt que de se risquer à une migration désastreuse, quitte à augmenter leurs coûts de maintenance de code et de développement.

C'est d'ailleurs la connaissance des systèmes IBM i / AS400 qui est recherchée par les banques, principalement. S'agissant de logiciels propriétaires qui n'ont pas d'usages grand public, la compétence est bien entendu de plus en plus difficile à trouver.

Même avec la meilleure volonté du monde, un "jeune" aura bien du mal à se former sur ces technologies. Le recours massif à la sous-traitance et au consulting n'aide pas non plus. On recherche des personnes "immédiatement opérationnelles", chose impossible dans ce contexte.
19/03/2022, 17h52
Luc Orient

Citation:

Envoyé par Jeff_67

Le COBOL est surtout utile sur des OS spécifiques type IBM i. Les banques font le pari qu'il vaut mieux garder des vieux systèmes stables et robustes plutôt que de se risquer à une migration désastreuse, quitte à augmenter leurs coûts de maintenance de code et de développement

Pour le monde bancaire, et en particulier les grandes Banques, c'est plutôt l'IBM Z qui est utilisé ...
20/03/2022, 11h36
TotoParis

Citation:

Envoyé par emilie77

Quelqu'un peut m'expliquer pourquoi, dans le monde du temps réel, le domaine bancaire a besoin de plusieur jour pour un virement? Je ne pense pas que le probleme soit pour le cobol

Vous parlez d'un virement au sein d'une même banque, ou entre deux banques françaises ou deux banques internationales ?

Dans le premier cas, à une époque pas si lointaine (les années 1990), tout passait par le SIT, le Système Interbancaire de Télé-compensation) puis les banques françaises, pas forcément futées, ont commencé à évoluer : la compensation interne n'avait aucun besoin de passer par le SIT "aller" pour revenir par le SIT "retour". Belle évolution...par rapport à l'échange de bandes magnétiques à la Chambre de Compensation ! Et je vous parle pas des chèques, et de leur stockage...

Dans le deuxième cas, il y a les virements interbancaires nationaux : là, il faut bien envoyer les remises de virements / prélèvements à une autre banque, que cette banque les réceptionne / les contrôle et les prennent en charge pour la tenue de comptes clients, puis la comptabilité bancaire. Tous ces processus sont bien plus complexes qu'insérer une ligne dans la table des comptes clients.

Pour le troisième cas, c'est en gros le même principe, mais avec des décalages horaires des back-offices. En Europe, il y a la norme SEPA en plus, à grand coups (et coûts !) de flux XML.

Un petit schéma https://www.comprendrelespaiements.c...res-en-france/ qui donne un aperçu des échanges interbancaires en France. Rajouter SWIFT pour l'international. Sans oublier des systèmes d'échanges, eux en vrai temps réel, pour les très gros montants (entre Etats, institutions financières).

Quant à la notion de temps réel, sachez qu'elle est une vue de l'esprit. Car pour cela, il faudrait que pour un mouvement bancaire, la totalité du processus de tenue de compte soit déroulé, et il est d'une certaine lourdeur, tant il y a de contrôles, du côté de la banque émettrice, comme de la banque réceptrice. Très peu de banques sont prêtes à le faire, tellement cela pose de problèmes techniques de charge machine en réalité (en effet, le client individuel, avec son point de vue forcément étriqué, n'est qu'un goutte d'eau dans la masse de la clientèle). Et donc ce n'est pas gratuit. Lire https://www.leparisien.fr/economie/v...18-7960293.php
20/03/2022, 12h32
Luc Orient

Citation:

Envoyé par TotoParis

Vous parlez d'un virement au sein d'une même banque, ou entre deux banques françaises ou deux banques internationales ?]

Je parle bien des trois cas, et je fait bien la distinction entre le virement lui même et sa comptabilisation, c'est à dire, son inscription au compte cible. Le montant viré apparaît alors dans une espèce de "sas" d'attente. Dans la banque que je connais on parle de "mouvement à venir" ou "mouvement prévisionnel". Je me limite aussi aux clients particuliers et aux virements unitaires, pour les entreprises et selon les montants concernés, ça peut être plus compliqué.

Donc, premier cas ( Banque à banque ), c'est presque toujours instantané, sauf quelques exceptions ( comptes à particularités par exemple ).

Second cas, ils est possible de faite un virement instantané mais très souvent payant.
https://www.leparisien.fr/economie/v...18-7960293.php

Enfin troisième cas, c'est possible aussi mais payant. On va alors passer par SWIFT qui est du temps réel ...
21/03/2022, 13h54
AoCannaille

Citation:

Envoyé par emilie77

Quelqu'un peut m'expliquer pourquoi, dans le monde du temps réel, le domaine bancaire a besoin de plusieur jour pour un virement? Je ne pense pas que le probleme soit pour le cobol

A mon avis c'est juste des choix architecturaux anté-dilivien qui traitaient ça dans des routines nocturnes, tandis que les ressources diurnes étaient dédiées au traitement des paiements des cartes de crédit. Mais j'avoue que ce n'est que spéculation...
21/03/2022, 14h40
escartefigue

Citation:

Envoyé par Luc Orient

Pour le monde bancaire, et en particulier les grandes Banques, c'est plutôt l'IBM Z qui est utilisé ...

En effet, qui plus est, le langage le plus répandu sur les systèmes I (AS-400) est le RPG (GAP) et non pas le COBOL
26/03/2022, 09h28
TJ1985

Le problème des temps de traitement est assez Franco-Français. Je travaille depuis des années avec Swissquote, les ordres de virement sont la plupart du temps exécutés dans la journée, et lorsque rien ne vient entraver le processus, les fonds sont disponibles le lendemain chez le destinataire.
26/03/2022, 10h56
Luc Orient

Une fois sur eBay, j'ai acheté en Belgique une BD d'occasion d'un montant assez faible. Le vendeur ne voulait pas être payé avec un chèque français parce ce que sa Banque Belge, pour encaisser le chèque, lui facturait une somme non négligeable J'ai donc fait procéder à un transfert SWIFT. Alors bon, chaque pays a des avantages et des inconvénients ...
26/03/2022, 22h41
TJ1985

Citation:

Envoyé par AoCannaille

A mon avis c'est juste des choix architecturaux anté-dilivien qui traitaient ça dans des routines nocturnes, tandis que les ressources diurnes étaient dédiées au traitement des paiements des cartes de crédit. Mais j'avoue que ce n'est que spéculation...

Les choix architecturaux antédiluvien étaient très légèrement contraints par le matériel de l'époque, qui dans ses meilleurs jours n'approchaient pas la performance d'un Raspberry Pi. Pourtant l'informatique mondiale est née à cette époque, avec ces moyens et a permis à de très grandes entreprises de se développer mondialement.

Accessoirement les modes que j'ai connus étaient : Traitement interactif et entrée de données (saisie, réseau,...) le jour, comptabilisation et bouclement en batch la nuit.

Aujourd'hui il est de bon ton de dénigrer tout ce qui date de plus d'une semaine. C'est une faute et la preuve d'une grande bêtise. En fait, tant que le problème n'a pas changé, pourquoi changer à grands frais de solution si celle en place est satisfaisante ? Pour pouvoir mettre une étiquette sexy sur le CV du responsable informatique ?

Notez que maintenir une plateforme est aussi une activité prenante, et il vient normalement un jour ou le domaine a suffisamment changé pour qu'une réécriture vaille la peine.

Alors imaginez : Faire tourner la gestion d'une boîte sur un Raspberry, en COBOL, c'est pas fun ? Ça tuerait les coûts matériels tout en assurant la qualité des calculs comptables. Le pied, non ?