Discussion :

[Pierre Louis Chevalier]

Le langage de programmation COBOL a cinquante ans

COBOL est un langage de programmation créé en 1959 et il signifie : Common Business Oriented Language et à été créé principalement pour développer des applications de gestions utilisant des fichiers pour les mainframes IBM. Le langage COBOL était de loin le langage le plus employé des années 1960 à 1980.

D'après une enquête de Micro Focus, cette années seulement 18% des personnes interrogées avaient déjà entendu parler de COBOL. Pourtant, il existe plus de 200 milliards de lignes de code COBOL qui ont étés écrites, et de nombreuses autres sont créés chaque jour.

Selon Mike Gilpin, analyste chez Forrester Research : 32% des entreprises utilisent encore COBOL pour le développement ou la maintenance. "COBOL est l'une des rares langues écrites au cours des 50 dernières années, c'est lisible et compréhensible, dit-il. "Langages de programmation modernes sont ridiculement difficile à comprendre."

Un exemple de programmation Hello World en COBOL :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
IDENTIFICATION DIVISION.
      PROGRAM-ID. HELLO-WORLD.
      PROCEDURE DIVISION.
          DISPLAY 'Hello, world'.
          STOP RUN.

Lire aussi :
Le forum d'entraide COBOL
Emploi : une pénurie alarmante de compétences dans le domaine du « Mainframe » ?


Source :

MICRO FOCUS WISHES COBOL HAPPY 50TH BIRTHDAY
World’s most pervasive computer language first named 50 years ago
Help celebrate COBOL’s 50th birthday at www.cobol.com

NEWBURY, England, 18 September 2009 - Micro Focus® (LSE.MCRO.L), a leading provider of enterprise application management, testing and modernisation solutions, today celebrates fifty years since the name COBOL was given to the computer language which continues to underpin the modern world.

The name COBOL (COmmon Business-Oriented Language) was agreed during a meeting of the Short Range Committee, the organisation responsbile for submitting the first version of the langauge, 18th September 1959. This followed a meeting at the Pentagon where guidelines for COBOL were first laid down.

Despite its age, COBOL still plays a pivotal role in running most of the world’s businesses and public services, from powering almost all global ATM transactions, running nearly three quarters of the world’s business applications, and booking hundreds of holidays every single day. There is understood to be over 200 billion lines of COBOL code in existence, with hundreds more being created every single day.

In May this year, Micro Focus published research which showed that people still use COBOL at least ten times throughout the course of an average working day. Yet, despite using the technology so often, only 18% of those surveyed had ever actually heard of COBOL. Equivalent research conducted by Micro Focus in the US showed Americans rely on COBOL even more, using it at least 13 times per day.

Stuart McGill, CTO, Micro Focus says “COBOL can trace its origins to the very start of the computer age, yet its applications continue to deliver to businesses and the public sector every single day. In an industry constantly driven by innovation and the ‘next big thing’, it is a real testament to the language’s resilience, flexibilty and relevance to the task at hand that it is still so widely used today. Customers come to us to modernise their business critical applications – not rip them out – because they hold deep business intelligence and continue to deliver value every single day. The vast majority of these applications have been written in mature languages, such as COBOL. Very few languages could make the same claim fifty years on,” concludes McGill.

Mike Gilpin, analyst at Forrester research and former COBOL programmer states, “…32% of enterprises say they still use COBOL for development or maintenance… COBOL is one of the few languages written in the last 50 years that's readable and understandable… Modern programming languages are ridiculously hard to understand."

About Micro Focus
Micro Focus, a member of the FTSE 250, provides innovative software that allows companies to dramatically improve the business value of their enterprise applications. Micro Focus Enterprise Application Modernization, Testing and Management software enables customers’ business applications to respond rapidly to market changes and embrace modern architectures with reduced cost and risk. For additional information please visit www.microfocus.com

Qui à fait du Cobol, ça vous à plut ?

[entreprise38]

Yep, et tout comme ADA, pour rien au monde je ne retoucherai à un truc pareil. Il n'y a bien qu'un évangéliste COBOL pour dire que c'est plus clair qu'un langage ne datant pas du temps des dinosaures.

Bon, après, je suis de la "jeune génération" hein. Sûr que les futurs p'tits geeks de dans 25 ans se moqueront de mon amour pour Java et C#, prétextant que c'est moche et moins facile à lire que leur SMS.Net, langage numéro un de l'an 2035.

Parcontre une chose m'étonne : "18% des personnes interrogées avaient déjà entendu parler de COBOL".
Ils n'ont interrogé que des jeunes de moins de 25 ans, ou bien le développeur moyen n'a t-il aucune connaissance en informatique autre que les deux-trois trucs appris à la fac ? C'est quand même basique, ne serait-ce que le nom, tout comme Basic ou ADA
Plus j'avance, et plus je me dits : "mince, sois je suis doué pour m'entourer de gars pas malins (ou qui n'aiment pas leur métier), soit il y a vraiment un problème ...", et ça fait peur *.

* d'une certaine manière, ça expliquerait les bugs Windows ^^

[Pierre Louis Chevalier]

Il y à des Facs ou ils apprennent plus ni le Cobol ni le Pascal ni le C : ils apprennent directement Java, aux USA par exemple, voila pourquoi...

Et il doit pas y avoir de "cours d'histoire"

[entreprise38]

Ni le C ?? Ha ouaip quand même, c'est bien dommage, j'étais loin d'imaginer ça....
La réalité est parfois bien cruelle. J'ai beau avoir maudit sur 35 générations les inventeurs du C et de l'assembleur, je suis content d'avoir mis au moins une fois les mains dans le cambouis, comme on dit, ne serait-ce que pour comprendre un peu comment ça se passe, le temps de quelques TP.

[smyley]

Non mais apprendre le COBOL aujourd'hui c'est dingue ... c'est comme un peut comme apprendre du Latin pour se préparer à une vie dans la finance : ça sert à rien à part sortir des citations latines pour se faire passer pour plus intelligent (sauf que je ne suis pas convaincu que sortir du COBOL aie le même effet )

[entreprise38]

Yes, sauf si tu veux bosser dans une banque ?
Je dis peut être une bêtise (je l'espère sincèrement), mais mes profs disaient souvent que nombre de banques utilisent et maintiennent des applis en COBOL, et ne sont pas prêtes d'évoluer vers autre chose. Après, je ne suis pas allé vérifier ça.

[Degourth]

Bon, après, je suis de la "jeune génération" hein. Sûr que les futurs p'tits geeks de dans 25 ans se moqueront de mon amour pour Java et C#, prétextant que c'est moche et moins facile à lire que leur SMS.Net, langage numéro un de l'an 2035.

pourquoi attendre 2035 ?

http://lolcode.com/

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
HAI
CAN HAS STDIO?
VISIBLE "HAI WORLD!"
KTHXBYE

[Homer-ac]

Juste par curiosité personnelle Hédhili, as tu eu l'occasion de comparer les performances de COBOL ILE et RPG (et/ou autres) sur AS/400 ? J'ai vu du RPG (ex GAP si c'est la même filiation) il y a bien lontemps sur les systèmes IBM DOS, et peut être au début de MVS, et complètement perdu de vue depuis (pas un mal d'ailleurs, langage trop redoutablement positionnel à mon goût, mais ça a peut être évolué ?. A ma connaisance, RPG a disparu des MVS quand s'est généralisé la notion de réentrance des programmes (pour les programmes CICS en particuliers). Mais je fais peut-être erreurs ? En tous cas je n'ai aucune idée des performances d'un programme RPG.

nb. J'ai aussi voté pour 'autres raisons'. Celles évoquées par Hédhili Jaïdane tout d'abord, mais auusi parce que :
- Si je le laisse derrière moi dans une société un programme COBOL Ansi 85, j'ai la certitude qu'il restera exécutable sans correctifs si on installe une nouvelle version du compilateur (sans citer de noms, au fait, j'ai encore une nouvelle fois une proposition de MAJ de JAVA (6 V15) sur mon portable ! Je n'en dirai pas autant d'autres langages plus 'modernes'). Au pire, en cas de maintenance évolutive, il restera encore longtemps des gens capables de prendre en charge.
- Je peux sans doute encore faire plus performant en Assembleur. Mais si je fais attention à ma programmation COBOL, le bénéfice sera assez à la marge et il y aura moins, voire pas du tout sur cerains sites z/OS, de candidats à la maintenance.
- Enfin on peut programmer en pire ou meilleur avec tout langage. Si on a le choix des armes, autant choisir celle que l'on manie le mieux par expérience (le rejoins une fois encore Hédhili sur ce point).

[Hédhili Jaïdane]

Juste par curiosité personnelle Hédhili, as tu eu l'occasion de comparer les performances de COBOL ILE et RPG (et/ou autres) sur AS/400 ? J'ai vu du RPG (ex GAP si c'est la même filiation) il y a bien lontemps sur les systèmes IBM DOS, et peut être au début de MVS, et complètement perdu de vue depuis (pas un mal d'ailleurs, langage trop redoutablement positionnel à mon goût, mais ça a peut être évolué ?. A ma connaisance, RPG a disparu des MVS quand s'est généralisé la notion de réentrance des programmes (pour les programmes CICS en particuliers). Mais je fais peut-être erreurs ? En tous cas je n'ai aucune idée des performances d'un programme RPG....

Bonjour.
En fait j'ai fait du RPG, juste après les mainframes (Cobol, Fortran et Assembleur) pendant un an ou un an et demi parce que j'intervenais sur des machines 3/10, 3/15 et 34 et que l'on ne pouvait pas faire autrement.

D'un côté sa rigidité dans la codification (positionnel, cycle, indicateurs, etc...) ne m'encourageais pas à l'utiliser parce que simplement chose nouvelle pour moi ayant toutes les facilités de Cobol.

Mais d'un autre côté les possibilités qu'il offrait pour faire des traitements batch ou interactifs en quelques instructions et son cycle de base, la gestion des ruptures, des récapitulatifs ont fait que je l'ai utilisé, aussi curieux que cela puisse paraître, en même temps que Cobol.

Les performances du RPG et Cobol ont toujours été similaires avec des avantages tantôt pour l'un tantôt pour l'autre aussi bien sur le S/36 que sur l'AS/400 : nombre d'indicateurs, longueur des noms de variables, taille totales des clés, nombre de zones constituant les clés, et bien d'autres différences qui sont disparues avec les versions ILE. Bien sûr uniquement sur AS/400, il n'y a pas de ILE sur S/36 même si dernier existe en tant qu'environnement de développement et d'exécution sur l'AS/400 même dans ses nouvelles versions (iSeries, System i).

Sur l'AS/400, le RPG a évolué vers le RPG IV (4) ou ILE RPG et offre aujourd'hui la possibilité du codage en FREE tout en gardant tout ce que ses prédécesseurs offraient. Il y a eu cependant une rupture de compatibilité des sources, mais on avait un convertisseur pour ça, chose qu'on avait pas eue en Cobol. Des incompatibilités similaires des sources se trouveront entre les versions OPM et ILE, mais là c'est toute une autre paire de manches.

Tout ce qui peut se programmer ou s'utiliser sur l'AS/400 peut se faire indifféremment dans les deux langages : compatibilités des outils, des techniques de gestion des écrans, de la base de données, etc...sauf le tri interne (dont j'aimerais pas en parler, mais Cobol l'a gardé).

Ce que IBM offre aujourd'hui sur les iSeries et System i (héritiers de l'AS/400) en matière de l'environnement ILE se trouve aussi bien en RPG qu'en Cobol

Certains de nos membres sont très compétents en RPG, ils pourront mieux en parler et le comparer au Cobol qu'ils connaissent aussi bien.

[Mjm]

Ben, moi, ma banque elle ne fait (presque) jamais d'erreur dans les transactions me concernant. Donc que leur logiciel soient en COBOL ou en Foulfoudé je m'en tape un peu

[smyley]

Ben, moi, ma banque elle ne fait (presque) jamais d'erreur dans les transactions me concernant.

Comment peux-tu en être sur ? parce qu'elle ne te dit jamais "oops, on a oublié de vous verser 100€" ?

[Homer-ac]

Mais question performance le C/C++ est aussi une bête qui a fait ses preuves. Pour traiter 2 millions de quoique ce soit on a pas besoin d'un supercalculateur non plus ...

Pour avoir eu l'accasion de le vérifier sur un mainframe z/OS, et bien non.
Chaque langage à sa place et ses raisons. C'est une erreur je pense de croire que COBOL perdure parce que les banques ou assurances rechignent aux coûts de transposition. C'est possible pour une part mais la raison essentielle est probablement ailleurs. Prenons une grande banque qui a investi dans un z/series (très très cher, et plutôt 2 d'ailleurs pour raison de backup) ou une plus petite avec un i/series (pas non plus dans mes moyens). Il veulent un outil fiable et robuste capable de traiter un maximum d'informations en un minimum de temps. Une logique de traitement transactionnel pour les interrogations/mises à jour (là COBOL c'est vrai a certainement de moins et moins sa place) mais AUSSI une logique BATCH pour éditer par exemple des millions d'extraits de compte dans la nuit (comme l'a d'ailleurs fait remarquer El-Slapper). Là COBOL garde nettement l'avantage. Parce que c'est un language basique certes mais bien conçu pour ce type de gestion, calculs relativement simples et éditions. Pourquoi ? Un exécutable COBOL sera 20 fois moins gros qu'un C iso-fonctionnel, et quoi que l'on puisse dire beaucoup plus rapide, simplement parce que le code généré est at-minima. Un language c'est un outil, on le choisit donc comme n'importe lequel : rapport coût/efficacité. Un exemple ? Compilez et sutout linkéditez (bindez pour ceux qui préfèrent = rendre un programme executable) un COBOL qui écrit juste Bonjour en COBOL sous z/OS. Rien que pour ça, hors exécutions donc,1 Mega de mémoire (mémoire virtuelle, z/OS est très fort pour cette gestion) et 20 Méga en C (parce ce qu'une floppée de RUNTIME sont nécessaires à l'exécution). Ne vous trompez pas, les banquiers comme les cies d'assurances sont des financiers et quand ils investissent dans, par exemple pour les plus importants, au moins 2 z/series et tous les produits qui sont nécessaires pour les exploiter, ils en veulent pour leur argent.

[bonano]

Bonjour,

Je voi que chacun parmis vous, essay de defondre son langage qui utilise, sans savoir vraiment est ce le meilleur. A mon avis, il faut voir, surtout, par rapport au traitement qu'on souhaite faire et au aussi au type de données à traiter. L'ideal c'est d'avoir une architecture dans laquelle on peut utiliser et exploiter les avantages de chaque langage. Pour mon cas je suis accro à java, et en ce moment je fait de java et cobol dans une banque (tous ce qui est interface graphique, navigation et affichage en java et le métier (regles de gestion en cobol) . Mais c'est vrai faire que de cobol je ne pourrai pas le supporter. C'est donc cool de développer sous RAD 7 en java et Interroger mainframe à partir de java.

Mais biensure java c'est le top ....

[Hédhili Jaïdane]

Bonjour.

Je pense que l'essentiel a été dit. Je n'ai rien à rajouter. D'aucuns me diraient que ce n'est pas parce que n'ai rien à dire que je dois la fermer. Ceux qui savent l'ont bien dit à ceux qui ne savent pas.

J'ai voté "Autres" pour la simple raison qu'à part quelques infidélités avec Assembleur, Fortran, RPG et Basic, j'ai de tout temps programmé en Cobol sur mainframe, S36, S38, AS/400 (iSeries) et PC et que si hier, aujourd'hui et demain on me demandait de programmer dans un autre langage autre que Cobol je laisserais tomber le projet ou même complètement le client. Il est vrai que je suis en fin de carrière, l'apprentissage et l'utilisation d'un autre langage me seront fastidieuses et laborieuses pour atteindre le même niveau de maîtrise que j'ai avec Cobol ou que j'ai eu naguère avec Fortran.

A part ma période mainframe, j'ai programmé, comme tant d'autres, en Cobol dans des PME et non dans des grandes entreprises. C'est pour dire que Cobol n'est pas synonyme d'entreprises financières.

N'en déplaise à certains allergiques, je continue à programmer en Cobol, oui je programme toujours, et à former des jeunes à l'utilisation et la maîtrise de ce langage.

En passant, c'est le RPG qui est naturellement utilisé sur AS/400 (iSeries) et non le Cobol.

[gd_dev]

... C'est une erreur je pense de croire que COBOL perdure parce que les banques ou assurances rechignent aux coûts de transposition. ..
.... Ne vous trompez pas, les banquiers comme les cies d'assurances sont des financiers et quand ils investissent dans, par exemple pour les plus importants, au moins 2 z/series et tous les produits qui sont nécessaires pour les exploiter, ils en veulent pour leur argent.

Je n'ai pas d'apriorique quand à Cobol ou a tout autre langage d'habilleur, mais à mon avis les grand décideurs sont des moutons comme tous le monde. 99% de mes copains banquier ou assureur utilise l'AS/400 avec le programme XYZ alors moi aussi.

Et la migration de plus de 10 ans donnée d'une base de données qui ne prenait pas en charge les type de données d'aujourd'hui et le tout lié avec une application qui a quand même plus de 10 ans de vie, donc pratiquement 0 bug aujourd'hui. A mon avis ce n'est pas rien. Surtout, que cette nouvelle application n'apporterais rien de plus sur le plan fonctionnel ou autre. Alors pourquoi changer?

La réponse à cette question pourrait venir prochainement si plus personne n'apprend le COBOL.

[xfanx]

Je n'ai pas d'apriorique quand à Cobol ou a tout autre langage d'habilleur, mais à mon avis les grand décideurs sont des moutons comme tous le monde. 99% de mes copains banquier ou assureur utilise l'AS/400 avec le programme XYZ alors moi aussi.

Oo un banquier ou un assureur utilisera plutot un Z/OS, voir 2 pour les PRA comme le dit Homer-ac
j'imagine mal toute la production de ma boite (une banque, et j'entends ici par production toutes les fonctions Backoffice bien sur, pas le Front ) tourner sur un AS/400 ni toute autre machine qu'un Z/os

Et la migration de plus de 10 ans donnée d'une base de données qui ne prenait pas en charge les type de données d'aujourd'hui

a bon? nous sommes à 90% Cobol sous DB2 UDB V8. c'est quoi les types de données d'aujourd'hui dont tu parles?

et le tout lié avec une application qui a quand même plus de 10 ans de vie, donc pratiquement 0 bug aujourd'hui. A mon avis ce n'est pas rien. Surtout, que cette nouvelle application n'apporterais rien de plus sur le plan fonctionnel ou autre. Alors pourquoi changer?

oui, oui largement plus de 10 ans même.. les process développés dans les années 80 sont encore tres présent. et pourquoi les refaire? ils fonctionnent et répondent aux besoins.

Quant à Cobol, en tant que language, je ne comprends pas trop les reproches qui lui sont fait. Ce language est l'idéal pour toute application de gestion.Sous Z/os, comme le dit aussi Homer-ac, hormis l'assembleur c'est le language le plus performant.

c'est sur que si on veut faire du Front en cobol, de jolies pages web ..etc c'est assez suicidaire d'imaginer l'utiliser.

ce langage n'est pas plus mauvais qu'un autre, il faut simplement l'utiliser pour ce qu'il sait faire le mieux. la gestion. a contrario , je trouverais assez suicidaire de faire de la gestion en java voir en C/C++ d'ailleurs .

Chaque langage a ses avantages et ses inconveniants; Dans ma boite, toutes les parties visibles par l'utilisateurs (pages Web) sont en java sous Websphere sous unix/sun mais tout les moteurs fonctionnels sont sous Z/os et en cobol. Pour deux raisons bien simple. La réutilisation et la centralisation des regles fonctionnelles à un seul endroit et la puissance de calcul et la rapidité qu'apporte un Z/os.

personnellement je suis support technique dans ma boite; je suis donc amené à développer des outils pour nos MOE. je n'ai aucun apriori sur aucun langage. je peux en faire un ou une partie en assembleur ou C parceque cobol n'a pas les fonctions nécessaires sans que ça ne me pose le moindre problèmes d'appartenance; mais je privilégierai toujours la maintenabilité et la simplicité et la, j'ai pas trouvé mieux que Cobol.

quand je lis tous ce fil, c'est limite si je sens pas que je devrais avoir honte d'utiliser encore Cobol. Franchement, oui c'est pas un langage particulièrement sexy, mais il fait parfaitement bien ce pour quoi il a été conçu et dans une banque ou une assurance pour du backoffice c'est largement suffisant. je vois pas l'interret pour ue société d'investir dans une Rolls alors qu'une 106 suffirait ; c'est pas l'informatique qui génère de l'argent c'est le flux financier.
et puis ce n'est qu'un langage. on pourra toujours imaginer le meilleurs langage possible pour une application, si elle est mal pensée, mal conçue ça sera toujours une grosse daube; Le métier d'informaticien ne se résume pas à la connaissance et la maitrise d'un langage plutôt qu'un autre il me semble...