Posté par Luc-Skywalker .
Évalué à 4 (+2/-0).
Dernière modification le 31 décembre 2025 à 01:44.
COBOL c'est
une secte, une conspiration, un troll from outer space, le blob qui dirige le monde (des mainframe seulement), le grand tout et plus ?
COBOL c'est
bien ?
"Si tous les cons volaient, il ferait nuit" F. Dard
C'est intéressant de lire cet article juste à còté d'un autre sur la préservation des premières versions de UNIX. Les deux ont à peu près le même âge. Les deux sont toujours très utilisés aujourd'hui, sous des formes qui ont bien sûr beaucoup évolué depuis. Pourtant, il y en a un dont tout le monde semble souhaiter la disparition, et pas l'autre.
COBOL a su traverser des gros chantiers comme le bug de l'an 2000 et le passage à l'euro, des crises comme l'éclatement de la bulle internet, certains de ces systèmes ont commencé leur vie à l'époque du traitement par lots et sont capables aujourd'hui de s'interfacer avec les toutes dernières technologies web et les applications mobiles, ou même l'internet des objets.
Le tout avec des taux de disponibilité élevés (les pannes arrivent parfois dans le secteur bancaire, mais c'est quand même très rare). Et un système distribué qui fait que si une banque rencontre une panne, les autres continuent de fonctionner.
Pourquoi on considère qu'il faudrait tout jeter et recommencer dans un autre langage? Alors qu'il faudrait plutôt célébrer un succès retentissant de l'informatique? Est-ce que les développeurs COBOL s'ennuient avec cette infrastructure qui fonctionnent trop bien, et rêvent d'un langage comme le C où on peut corrompre la mémoire, ou à défaut, de Java et ses NullPointerExceptions, pour pimenter un peu leur quotidien?
Je pense que ce sont les vendeurs de solutions (et non les cobolistes) qui souhaitent sa mort : avec ce truc dans les pattes c’est toujours moins de trucs éphémères supposés révolutionner le précédent qui ne se vend pas…
Tu verras, si dans la dystopie ils font tomber cette cathédrale, ils s’en prendront ensuite à FORTRAN et ADA pour mieux assoir leur châteaux de cartes en sable.
“It is seldom that liberty of any kind is lost all at once.” ― David Hume
Mais, mais… comment trouver du boulot si on ne peut pas récrire nos programmes tous les 6 mois parce que (choix multiples possibles)
□ optimisation du code (parce qu'on a codé comme des pieds mais ça faut pas le dire au client)
□ sécurisation du code (parce qu'on a codé comme des pieds mais ça faut pas le dire au client)
□ nouvelle fonctionnalité du code qui nécessite une nouvelle architecture (parce qu'on a codé comme des pieds mais ça faut pas le dire au client)
□ nouveau langage à la mode qui permet d'avoir la même mais en mieux (parce qu'on a codé comme des pieds mais ça faut pas le dire au client)
□ code non maintenable (parce qu'on a codé comme des pieds mais ça faut pas le dire au client)
□ code non documenté (parce qu'on a codé comme des pieds mais ça faut pas le dire au client)
□ le concurrent le fait (parce qu'on a codé comme des pieds mais ça faut pas le dire au client)
□ tu peux pas cap' c'est nous les experts (parce qu'on a codé comme des pieds mais ça faut pas le dire au client)
Le problème du Cobol c'est qu'il faut redoubler d'efforts pour se trouver des excuses. Heureusement avec un peu de bouteille nous y arrivons aussi. D'autant plus que les pratiquants ne sont pas souvent informaticiens de métier mais ce sont retrouvés là-dedans par nécessité (ce qui soit dit en passant signifie que c'est pas trop dans les mœurs de vouloir recoder juste pour la beauté du geste).
Ce qui est paradoxal étant donné la nature du langage et l'écosystème dans lequel il est utilisé on est un peu obligé de savoir un minimum coder et architecturer (c'est-à-dire pas juste compter sur un gestionnaire de librairie et une base de code bullet-proof qu'on se contenter de télécharger/appeler, mais écrire de vrais algos avec nos petites mains - heureusement 99% du temps c'est assez trivial).
V’là, on fait des pieds et des mains pour que les Néo langes rattrapent les balles que l’on se tire dans les pattes de gnome velus ;)
Pour la petite histoire, on n’a toujours pas patché JVM pour que le rêve de remplacer tout le code bancaire advienne. On a fini par faire de belles bitumes modernes à côté des routes romaines increvables (c’est de l’analogie…)
“It is seldom that liberty of any kind is lost all at once.” ― David Hume
Pourquoi on considère qu'il faudrait tout jeter et recommencer dans un autre langage?
Parce que contrairement à ce qui est écrit dans l'article, COBOL n'a pas su évoluer ou en tout cas pas assez.
Java, PHP, Python ou Javascript ont la trentaine et se sont énormément modernisés au niveau du langage, des outils, des bibliothèques. On peut lancer des nouveaux projets avec eux en ayant confiance dans l'avenir et sans souci de recrutement / formation.
COBOL reste du legacy qui ne meurt jamais.
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
Au passage c'est un peu se tirer une balle dans le pieds. Parser du JSON ou du XML (par exemple) ça coûte bien cher (en volume et en temps) par rapport à une bon vieux record format fixe. Dans le même genre IBM a bien fait de la merde avec leur usine à gaz qui est supposé remplacer Pacbase (j'attendais le moment où on me parlerait de l'IA pour gé(né)rer du Cobol, voilà qui est chose faite avec l'article du lien…)
Et la grande joie de mon métier c'est quand même de voir la tête en décomposition des informaticiens qui ne jurent que par la techno MODERNE lorsque je leur annonce la volumétrie qui passera dans les tuyaux.
Même les cobolistes ne savent (souvent) pas que COBOL évolue…
En vrac :
- INITIALIZE permet de récupérer les VALUE et permet encore d'autres choses ;
- user defined functions (permet d'appeler nested programme comme une fonction : on peut enfin passer des paramètres en COBOL comme dans les autres langages avec des arguments entre parenthèse) ;
- user defined type : on peut définir des type génériques, ce qui fait par exmple qu'on peut créer montant qui sera TOUJOURS en S9(09)V99.
- on peut faire de COPY REPLACING dans un COPYBOOK ;
- il est possible d'exploiter la compilation conditionnelle : on peut positionner des variables qui détermineront si oui ou non certaine partie du code seront incluses dans LOAD produit ;
- depuis longtemps : PARSE XML, mais c'est beaucoup trop lourd ;
- depuis moins longtemps et surtout de manière bien plus simple PARSE JSON, devenu vraiment exploitable en V6.2 : on récupère en un SEUL ordre le JSON dans la structure COBOL désignée : trop top (Là ou le parse XML est une vraie plaie);
- non exhaustif…
« Y a même des gens qui ont l’air vivant, mais ils sont morts depuis longtemps ! »
Et pour les technologies du futur qu'on attend partout ailleurs (et le pourquoi que le mainframe n'est pas remplacé malgré qu'IBM et d'autres du secteur se gavent)
- analyse des requêtes SQL à la compilation (aucune injection possible, optimisation de la stratégie, séparation stricte de la donnée et du code).
- description portable, simple, très performante et orientée métier des données.
- rétro-compatibilité+++ (faut que ça tourne dans 50 ans) c'est pas du code vieux qu'on manipule, mais du code pérenne (avec effectivement ce problème du sachant et de la doc qui se perdent)
- type décimal natif avec calcul exact sans arrondis.
- aucun soucis d'adressage mémoire.
- t'as aussi des trucs autour de DB2 (et ptet même Cobol), qui peut exposer des services HTTP.
- la notion de partition et toute la gestion matérielle et des droits pour concevoir les environnements prod/hors-prod et gérer les, milliers, d'utilisateurs
- accès bien contrôlé des ressources fichiers/db
- Services Unix (c'est… spécial… on n'est pas sur du Linux), y'a un serveur SSH et même un client git.
- système batch ET temps réel
C'est aussi un savoir-faire : faire un tri puis une rupture ou une jointure sans taper dans une base de donnée SQL pour un oui ou un non, une bonne part des cobolistes savent faire. Produire un MPD qui tienne à peu prêt la route. Savoir écrire du code modulaire (pas le choix en Cobol!). Écrire et maintenir du code sur plusieurs décennies, c'est pas un problème de langage mais d'interface chaise-clavier. Ce sont des attendus de base de toute personne du métier et expérimentée mais qui ne sont pas si bien acquises (voire parfois les soit-disantes bonnes pratiques de l'informatique sont des anti-patterns). Raison pour laquelle tant et tant de projets de migration se cassent la gueule. Y'a aussi l'architecture qui est déjà bien assez compliquée et serait un vrai casse-tête à s'arracher les cheveux sur système distribué.
Posté par alkino .
Évalué à 10 (+9/-1).
Dernière modification le 31 décembre 2025 à 11:16.
Désolé d'avance de mes remarques discriminatoires envers les développeurs venant d'autres branches (ingé méca, ingé physique théorique, …).
J'en ai beaucoup fréquenté durant mon travail et ils souvent très enthousiastes et heureux d'apprendre.
Je les retrouve principalement dans les équipes de tests. Boulot que nous informaticiens de formation, on rechigne un peu à faire. Je leur suis très reconnaissant de prendre à cœur des tâches un peu moins dures techniquement.
Beaucoup après plusieurs années deviennent indissociables et extrêmement doués.
Certains resteront toujours un cran en dessous par manque de passion (ce qui m'anime dans mon boulot). Mais bon c'est normal d'être plus ou moins intéressé.
Je suis dev C++ et dans nos équipes beaucoup critiquent Java. Je me dis souvent que le problème n'est pas le langage mais la facilité d'accès de ce dernier. Les débutants mi-motivés y vont pour ne pas trop souffrir et au final empilent des bout de code bancales à coup de framework.
Tout ça pour en venir au point que l'article me semble être écrit par ce genre de personne. "COBOL c'est rapide, la preuve Java c'est lent", "On est tous issus d'autres secteurs que l'informatique et les autres ne comprennent rien à notre code", "on a empilé des milliards de ligne de code que nous ne comprenons pas nous même", "Agile ne nous correspond pas et cycle en V non plus".
J'ai eu des discussions semblables des fois hallucinantes avec les gens du CERN gérant le développement qui viennent de doctorats en physique "git ça ne marche pas, du coup on a notre propre framework", "les std::vector sont défectueux on a les nôtres qui sont bien meilleurs", "pourquoi changer un code qui marche la plupart du temps ?". La plupart des informaticiens que j'ai croisé qui y étaient passé en gardaient des terreurs nocturnes. Il y en avait plusieurs dans mon équipe, des fois ils partaient en fou rire diabolique en en parlant à la pause café (je ne rigole pas).
Bref, le genre d'environnement qui ne donnent pas envie de bosser pour des passionnés : "la qualité du code ça ne sert à rien, on fixe des bugs au hasard puis on part en week-end ".
Et pourtant mon dernier boulot consistait à nettoyer du code en neurobiologie qui datait des années 60. Tout ça en marchant sur des oeufs pour ne rien casser vu le nombre d'utilisateurs dans la nature. Mais bon l'outil de regex maison était tout pété, ils avaient des structures de données incompréhensibles, genre une liste où l'élément interne peut se retrouver balancé au milieu d'un tree. Par chance les devs issus de la neurobiologie avaient conscience de leurs lacunes en code et étaient enthousiastes à ce que le nouveau code puisse être lu par d'autres.
Du même coup, j'évitais de leur faire des remarques sur le choix des equadiff de propagation de signaux neuronaux. Je fermais ma gueule et appliquait scrupuleusement leur choix.
Disons que les préjugés sont partagés : il y une vrai volonté actuellement de passer du site central au Cloud essentiellement parce que le site central est jugé trop coûteux sans réfléchir à la qualité de service associée, mais qui est plus due à une culture qu'à une technologie. Le souci est surtout de vouloir faire table rase de cette culture, sous couvert cette fois-ci de ringardise, voire d'obsolescence. Bref comme souvent, du pilotage par le budget et non par le besoin.
« Y a même des gens qui ont l’air vivant, mais ils sont morts depuis longtemps ! »
Posté par raum_schiff .
Évalué à 6 (+5/-0).
Dernière modification le 31 décembre 2025 à 13:10.
Un bon article ; qui se penche sur l’aspect générationnel de la chose, en tout cas c’est pour ça qu’il m’a intéressé, d’autant plus que je fais partie de la classe d’âge des personnes interrogées.
2 cents de ma vie puis retour au point :
Au milieu des années 90, il y avait pas mal de jeunes en déshérence universitaire qui arrivés entre la licence et la maîtrise se posaient la question de leur avenir pécuniaire, et j’en faisais partie.
Tu connais un peu l’informatique, tu as de la jugeote; le secteur recrute avec formation en alternance avec stage rémunéré, et zou !
J’ai eu des « profs » de COBOL, qui une fois balayé les bases, t’imprimaient les docs plus des exos et ne venaient plus en cours; en ayant expliqué avant, de façon honnête, que la formation était en partie financée par leur boite et que celle-ci recrutait sur cinq postes de dev, que c’était très bien payé et que le triage des candidats s’effectuait par la "sélection naturelle" : En gros, tu as la doc et les bases et si tu réussis les exos sans aide externe, c’est dans la poche … grok or die !
Heureusement que les 30 autres "non élus" dont je faisais partie ont eut des cours de Pascal et de Merise pour ne pas sortir de la formation en slip.
Et le point (IMHO):
COBOL c’est de la banque et de l’industrie avec un passif informatique des années 60 basé sur du gros travail d’équipe hiérarchisé en chefs de projet et pisses-code. La dette n’est pas tant technique que sociale; ce monde fonctionne encore, mais ceux qui le font tourner vieillissent. Je pense qu’ils vont arriver à recruter (c’est juste une question de disposition d’esprit), mais ils doivent le faire avant que ceux qui sont censés "passer la balle" ne partent en retraite et laissent plein de morceaux de code imbitable sauf pour les initiés.
C’est comme les cultes à secret dont les membres les plus éminents trépassent avant d’avoir transmis leur savoir; sauf qu’en informatique, le secret c’est qu’il n’y a pas de secret, juste du code.
C'est en fait tout l'écosystème qu'il faudrait changer, et là c'est une autre paire de manche.
Pour ceux qui ne connaissent pas z/OS, il faut comprendre que comme sur un PC, une partition n'est pas livrée « nue », et que la configuration est quasi la même partout.
C'est la très grande force du z : même s'il y a des (parfois grandes) différences culturelles entre sites, on retrouvera quasiment toujours :
- un TSO : l'interface 3270 standard. Mais qu'on se rassure, on peut utiliser VScode (un vrai bonheur !), Eclipse (qui a révolutionné l'expérience développeur site central), même si beaucoup d'outils système n'existent qu'en interface 3270 ;
- qui donne un accès au spool (sur les z les log sont centralisées : pas besoin de chercher où peut bien être cachée cette foutue log, elle est nécessairement sous SDFS ou sous l'outil d'archivage du site) ;
- un DB2 ;
- un moniteur transactionnel IMS ou CICS ;
- un moniteur de transfert, au hasard CFT ;
- du JCL comme langage de script qui avec DFSORT permet de triturer un fichier comme on le souhaite ;
- différents outils permettant de lire les fichiers en mode tabulaire (en exploitant la structure COBOL) ;
- Un ordonnanceur permettant de lancer les tâches planifiée ;
- différents outils permettant de visualiser les tables DB2 dont OPTIM qui permet en y déclarant le MCD de littéralement se promener dans les données ;
- tout un tas d'outils de supervision permettant de couper la tête à celui qui s'est amusé à rechercher la date du jour à la lecture de chaque ligne d'un fichier…
- un outil de GCL pour gérer les différentes version des source COBOL et JCL et leur déploiement dans les environnement hors prod et de prod ;
- et pour ceux qui ne jurent que par l'Unix, l'USS : la partition UNIX !
Cette très forte intégration fait que plein de sujets « open » (non z/OS) n'ont pas cours sur site central, et qui permet une disponibilité d'au moins 99,99 %.
Par exemple, il y a quelques années, il y a eu une volonté de se lancer dans le Zdevops sur mon site. Mais piloté par une personne ne connaissant pas le z/OS, il lui a fallu 3 (longues) années avant de comprendre que pour nous, compiler (builder), déployer tout ça tout ça était un non sujet (pas besoin de s'appuyer sur chaîne d'outils qui changent constamment de version pour des raisons des sécurité : on a des outils très bien fait pour ça comme ISPW - CodePipeline, son nouveau nom): ça marche correctement depuis au moins 30 (voire 50) ans, avec des hauts et des bas, mais ça on sait (très bien) faire.
Le vrai sujet Zdevops, c'est le test : mais là aussi, avec des outils aussi puissant qu'OPTIM, ou des suites du marché, ça n'est pas vraiment un problème. Le seul problème du Zdevops, c'est d'accepter d'inverser la pyramide des tests.
Mais on part sur un autre débat ! (^ _ ^ )
« Y a même des gens qui ont l’air vivant, mais ils sont morts depuis longtemps ! »
# Super article !
Posté par Luc-Skywalker . Évalué à 4 (+2/-0). Dernière modification le 31 décembre 2025 à 01:44.
COBOL c'est
une secte, une conspiration, un troll from outer space, le blob qui dirige le monde (des mainframe seulement), le grand tout et plus ?
COBOL c'est
bien ?
"Si tous les cons volaient, il ferait nuit" F. Dard
# Pourquoi casser ce qui fonctionne
Posté par pulkomandy (site web personnel, Mastodon) . Évalué à 10 (+7/-0).
C'est intéressant de lire cet article juste à còté d'un autre sur la préservation des premières versions de UNIX. Les deux ont à peu près le même âge. Les deux sont toujours très utilisés aujourd'hui, sous des formes qui ont bien sûr beaucoup évolué depuis. Pourtant, il y en a un dont tout le monde semble souhaiter la disparition, et pas l'autre.
COBOL a su traverser des gros chantiers comme le bug de l'an 2000 et le passage à l'euro, des crises comme l'éclatement de la bulle internet, certains de ces systèmes ont commencé leur vie à l'époque du traitement par lots et sont capables aujourd'hui de s'interfacer avec les toutes dernières technologies web et les applications mobiles, ou même l'internet des objets.
Le tout avec des taux de disponibilité élevés (les pannes arrivent parfois dans le secteur bancaire, mais c'est quand même très rare). Et un système distribué qui fait que si une banque rencontre une panne, les autres continuent de fonctionner.
Pourquoi on considère qu'il faudrait tout jeter et recommencer dans un autre langage? Alors qu'il faudrait plutôt célébrer un succès retentissant de l'informatique? Est-ce que les développeurs COBOL s'ennuient avec cette infrastructure qui fonctionnent trop bien, et rêvent d'un langage comme le C où on peut corrompre la mémoire, ou à défaut, de Java et ses NullPointerExceptions, pour pimenter un peu leur quotidien?
[^] # Re: Pourquoi casser ce qui fonctionne
Posté par Gil Cot ✔ (site web personnel, Mastodon) . Évalué à 3 (+2/-1).
Je pense que ce sont les vendeurs de solutions (et non les cobolistes) qui souhaitent sa mort : avec ce truc dans les pattes c’est toujours moins de trucs éphémères supposés révolutionner le précédent qui ne se vend pas…
Tu verras, si dans la dystopie ils font tomber cette cathédrale, ils s’en prendront ensuite à FORTRAN et ADA pour mieux assoir leur châteaux de cartes en sable.
“It is seldom that liberty of any kind is lost all at once.” ― David Hume
[^] # Re: Pourquoi casser ce qui fonctionne
Posté par Nicolas (site web personnel) . Évalué à 2 (+2/-0).
Mais, mais… comment trouver du boulot si on ne peut pas récrire nos programmes tous les 6 mois parce que (choix multiples possibles)
□ optimisation du code (parce qu'on a codé comme des pieds mais ça faut pas le dire au client)
□ sécurisation du code (parce qu'on a codé comme des pieds mais ça faut pas le dire au client)
□ nouvelle fonctionnalité du code qui nécessite une nouvelle architecture (parce qu'on a codé comme des pieds mais ça faut pas le dire au client)
□ nouveau langage à la mode qui permet d'avoir la même mais en mieux (parce qu'on a codé comme des pieds mais ça faut pas le dire au client)
□ code non maintenable (parce qu'on a codé comme des pieds mais ça faut pas le dire au client)
□ code non documenté (parce qu'on a codé comme des pieds mais ça faut pas le dire au client)
□ le concurrent le fait (parce qu'on a codé comme des pieds mais ça faut pas le dire au client)
□ tu peux pas cap' c'est nous les experts (parce qu'on a codé comme des pieds mais ça faut pas le dire au client)
Le problème du Cobol c'est qu'il faut redoubler d'efforts pour se trouver des excuses. Heureusement avec un peu de bouteille nous y arrivons aussi. D'autant plus que les pratiquants ne sont pas souvent informaticiens de métier mais ce sont retrouvés là-dedans par nécessité (ce qui soit dit en passant signifie que c'est pas trop dans les mœurs de vouloir recoder juste pour la beauté du geste).
Ce qui est paradoxal étant donné la nature du langage et l'écosystème dans lequel il est utilisé on est un peu obligé de savoir un minimum coder et architecturer (c'est-à-dire pas juste compter sur un gestionnaire de librairie et une base de code bullet-proof qu'on se contenter de télécharger/appeler, mais écrire de vrais algos avec nos petites mains - heureusement 99% du temps c'est assez trivial).
[^] # Re: Pourquoi casser ce qui fonctionne
Posté par Gil Cot ✔ (site web personnel, Mastodon) . Évalué à 3 (+1/-0). Dernière modification le 31 décembre 2025 à 09:23.
V’là, on fait des pieds et des mains pour que les Néo langes rattrapent les balles que l’on se tire dans les pattes de gnome velus ;)
Pour la petite histoire, on n’a toujours pas patché JVM pour que le rêve de remplacer tout le code bancaire advienne. On a fini par faire de belles bitumes modernes à côté des routes romaines increvables (c’est de l’analogie…)
“It is seldom that liberty of any kind is lost all at once.” ― David Hume
[^] # Re: Pourquoi casser ce qui fonctionne
Posté par devnewton 🍺 (site web personnel) . Évalué à 3 (+1/-1).
Parce que contrairement à ce qui est écrit dans l'article, COBOL n'a pas su évoluer ou en tout cas pas assez.
Java, PHP, Python ou Javascript ont la trentaine et se sont énormément modernisés au niveau du langage, des outils, des bibliothèques. On peut lancer des nouveaux projets avec eux en ayant confiance dans l'avenir et sans souci de recrutement / formation.
COBOL reste du legacy qui ne meurt jamais.
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Pourquoi casser ce qui fonctionne
Posté par Gil Cot ✔ (site web personnel, Mastodon) . Évalué à 7 (+5/-0).
Tu crois vraiment que COBOL n’a pas évolué ? Ah les croyances…
“It is seldom that liberty of any kind is lost all at once.” ― David Hume
[^] # Re: Pourquoi casser ce qui fonctionne
Posté par Nicolas (site web personnel) . Évalué à 8 (+8/-0).
Au passage c'est un peu se tirer une balle dans le pieds. Parser du JSON ou du XML (par exemple) ça coûte bien cher (en volume et en temps) par rapport à une bon vieux record format fixe. Dans le même genre IBM a bien fait de la merde avec leur usine à gaz qui est supposé remplacer Pacbase (j'attendais le moment où on me parlerait de l'IA pour gé(né)rer du Cobol, voilà qui est chose faite avec l'article du lien…)
Et la grande joie de mon métier c'est quand même de voir la tête en décomposition des informaticiens qui ne jurent que par la techno MODERNE lorsque je leur annonce la volumétrie qui passera dans les tuyaux.
[^] # Re: Pourquoi casser ce qui fonctionne
Posté par PhRæD . Évalué à 1 (+1/-1).
Je ne suis pas d'accord sur partie JSON : l'ordre PARSE JSON est vraiment efficace. Pour XML je partage.
Et on est d'accord : on a pas fait mieux que le fichier plat !
« Y a même des gens qui ont l’air vivant, mais ils sont morts depuis longtemps ! »
[^] # Re: Pourquoi casser ce qui fonctionne
Posté par devnewton 🍺 (site web personnel) . Évalué à 10 (+8/-0).
Tu peux peut être nous faire un journal ou une dépêche expliquant ces évolutions ?
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Pourquoi casser ce qui fonctionne
Posté par PhRæD . Évalué à 7 (+6/-0).
Même les cobolistes ne savent (souvent) pas que COBOL évolue…
En vrac :
- INITIALIZE permet de récupérer les VALUE et permet encore d'autres choses ;
- user defined functions (permet d'appeler nested programme comme une fonction : on peut enfin passer des paramètres en COBOL comme dans les autres langages avec des arguments entre parenthèse) ;
- user defined type : on peut définir des type génériques, ce qui fait par exmple qu'on peut créer montant qui sera TOUJOURS en S9(09)V99.
- on peut faire de COPY REPLACING dans un COPYBOOK ;
- il est possible d'exploiter la compilation conditionnelle : on peut positionner des variables qui détermineront si oui ou non certaine partie du code seront incluses dans LOAD produit ;
- depuis longtemps : PARSE XML, mais c'est beaucoup trop lourd ;
- depuis moins longtemps et surtout de manière bien plus simple PARSE JSON, devenu vraiment exploitable en V6.2 : on récupère en un SEUL ordre le JSON dans la structure COBOL désignée : trop top (Là ou le parse XML est une vraie plaie);
- non exhaustif…
« Y a même des gens qui ont l’air vivant, mais ils sont morts depuis longtemps ! »
[^] # Re: Pourquoi casser ce qui fonctionne
Posté par Nicolas (site web personnel) . Évalué à 5 (+5/-0).
Support unicode aussi.
Et pour les technologies du futur qu'on attend partout ailleurs (et le pourquoi que le mainframe n'est pas remplacé malgré qu'IBM et d'autres du secteur se gavent)
- analyse des requêtes SQL à la compilation (aucune injection possible, optimisation de la stratégie, séparation stricte de la donnée et du code).
- description portable, simple, très performante et orientée métier des données.
- rétro-compatibilité+++ (faut que ça tourne dans 50 ans) c'est pas du code vieux qu'on manipule, mais du code pérenne (avec effectivement ce problème du sachant et de la doc qui se perdent)
- type décimal natif avec calcul exact sans arrondis.
- aucun soucis d'adressage mémoire.
- t'as aussi des trucs autour de DB2 (et ptet même Cobol), qui peut exposer des services HTTP.
- la notion de partition et toute la gestion matérielle et des droits pour concevoir les environnements prod/hors-prod et gérer les, milliers, d'utilisateurs
- accès bien contrôlé des ressources fichiers/db
- Services Unix (c'est… spécial… on n'est pas sur du Linux), y'a un serveur SSH et même un client git.
- système batch ET temps réel
C'est aussi un savoir-faire : faire un tri puis une rupture ou une jointure sans taper dans une base de donnée SQL pour un oui ou un non, une bonne part des cobolistes savent faire. Produire un MPD qui tienne à peu prêt la route. Savoir écrire du code modulaire (pas le choix en Cobol!). Écrire et maintenir du code sur plusieurs décennies, c'est pas un problème de langage mais d'interface chaise-clavier. Ce sont des attendus de base de toute personne du métier et expérimentée mais qui ne sont pas si bien acquises (voire parfois les soit-disantes bonnes pratiques de l'informatique sont des anti-patterns). Raison pour laquelle tant et tant de projets de migration se cassent la gueule. Y'a aussi l'architecture qui est déjà bien assez compliquée et serait un vrai casse-tête à s'arracher les cheveux sur système distribué.
# Pas taper
Posté par alkino . Évalué à 10 (+9/-1). Dernière modification le 31 décembre 2025 à 11:16.
Désolé d'avance de mes remarques discriminatoires envers les développeurs venant d'autres branches (ingé méca, ingé physique théorique, …).
J'en ai beaucoup fréquenté durant mon travail et ils souvent très enthousiastes et heureux d'apprendre.
Je les retrouve principalement dans les équipes de tests. Boulot que nous informaticiens de formation, on rechigne un peu à faire. Je leur suis très reconnaissant de prendre à cœur des tâches un peu moins dures techniquement.
Beaucoup après plusieurs années deviennent indissociables et extrêmement doués.
Certains resteront toujours un cran en dessous par manque de passion (ce qui m'anime dans mon boulot). Mais bon c'est normal d'être plus ou moins intéressé.
Je suis dev C++ et dans nos équipes beaucoup critiquent Java. Je me dis souvent que le problème n'est pas le langage mais la facilité d'accès de ce dernier. Les débutants mi-motivés y vont pour ne pas trop souffrir et au final empilent des bout de code bancales à coup de framework.
Tout ça pour en venir au point que l'article me semble être écrit par ce genre de personne. "COBOL c'est rapide, la preuve Java c'est lent", "On est tous issus d'autres secteurs que l'informatique et les autres ne comprennent rien à notre code", "on a empilé des milliards de ligne de code que nous ne comprenons pas nous même", "Agile ne nous correspond pas et cycle en V non plus".
J'ai eu des discussions semblables des fois hallucinantes avec les gens du CERN gérant le développement qui viennent de doctorats en physique "git ça ne marche pas, du coup on a notre propre framework", "les std::vector sont défectueux on a les nôtres qui sont bien meilleurs", "pourquoi changer un code qui marche la plupart du temps ?". La plupart des informaticiens que j'ai croisé qui y étaient passé en gardaient des terreurs nocturnes. Il y en avait plusieurs dans mon équipe, des fois ils partaient en fou rire diabolique en en parlant à la pause café (je ne rigole pas).
Bref, le genre d'environnement qui ne donnent pas envie de bosser pour des passionnés : "la qualité du code ça ne sert à rien, on fixe des bugs au hasard puis on part en week-end ".
Et pourtant mon dernier boulot consistait à nettoyer du code en neurobiologie qui datait des années 60. Tout ça en marchant sur des oeufs pour ne rien casser vu le nombre d'utilisateurs dans la nature. Mais bon l'outil de regex maison était tout pété, ils avaient des structures de données incompréhensibles, genre une liste où l'élément interne peut se retrouver balancé au milieu d'un tree. Par chance les devs issus de la neurobiologie avaient conscience de leurs lacunes en code et étaient enthousiastes à ce que le nouveau code puisse être lu par d'autres.
Du même coup, j'évitais de leur faire des remarques sur le choix des equadiff de propagation de signaux neuronaux. Je fermais ma gueule et appliquait scrupuleusement leur choix.
[^] # Re: Pas taper
Posté par PhRæD . Évalué à 1 (+0/-0).
Disons que les préjugés sont partagés : il y une vrai volonté actuellement de passer du site central au Cloud essentiellement parce que le site central est jugé trop coûteux sans réfléchir à la qualité de service associée, mais qui est plus due à une culture qu'à une technologie. Le souci est surtout de vouloir faire table rase de cette culture, sous couvert cette fois-ci de ringardise, voire d'obsolescence. Bref comme souvent, du pilotage par le budget et non par le besoin.
« Y a même des gens qui ont l’air vivant, mais ils sont morts depuis longtemps ! »
# Matière grise en train de blanchir
Posté par raum_schiff . Évalué à 6 (+5/-0). Dernière modification le 31 décembre 2025 à 13:10.
Un bon article ; qui se penche sur l’aspect générationnel de la chose, en tout cas c’est pour ça qu’il m’a intéressé, d’autant plus que je fais partie de la classe d’âge des personnes interrogées.
2 cents de ma vie puis retour au point :
Au milieu des années 90, il y avait pas mal de jeunes en déshérence universitaire qui arrivés entre la licence et la maîtrise se posaient la question de leur avenir pécuniaire, et j’en faisais partie.
Tu connais un peu l’informatique, tu as de la jugeote; le secteur recrute avec formation en alternance avec stage rémunéré, et zou !
J’ai eu des « profs » de COBOL, qui une fois balayé les bases, t’imprimaient les docs plus des exos et ne venaient plus en cours; en ayant expliqué avant, de façon honnête, que la formation était en partie financée par leur boite et que celle-ci recrutait sur cinq postes de dev, que c’était très bien payé et que le triage des candidats s’effectuait par la "sélection naturelle" : En gros, tu as la doc et les bases et si tu réussis les exos sans aide externe, c’est dans la poche … grok or die !
Heureusement que les 30 autres "non élus" dont je faisais partie ont eut des cours de Pascal et de Merise pour ne pas sortir de la formation en slip.
Et le point (IMHO):
COBOL c’est de la banque et de l’industrie avec un passif informatique des années 60 basé sur du gros travail d’équipe hiérarchisé en chefs de projet et pisses-code. La dette n’est pas tant technique que sociale; ce monde fonctionne encore, mais ceux qui le font tourner vieillissent. Je pense qu’ils vont arriver à recruter (c’est juste une question de disposition d’esprit), mais ils doivent le faire avant que ceux qui sont censés "passer la balle" ne partent en retraite et laissent plein de morceaux de code imbitable sauf pour les initiés.
C’est comme les cultes à secret dont les membres les plus éminents trépassent avant d’avoir transmis leur savoir; sauf qu’en informatique, le secret c’est qu’il n’y a pas de secret, juste du code.
# En vrai, COBOL n'est pas le sujet…
Posté par PhRæD . Évalué à 5 (+5/-1).
C'est en fait tout l'écosystème qu'il faudrait changer, et là c'est une autre paire de manche.
Pour ceux qui ne connaissent pas z/OS, il faut comprendre que comme sur un PC, une partition n'est pas livrée « nue », et que la configuration est quasi la même partout.
C'est la très grande force du z : même s'il y a des (parfois grandes) différences culturelles entre sites, on retrouvera quasiment toujours :
- un TSO : l'interface 3270 standard. Mais qu'on se rassure, on peut utiliser VScode (un vrai bonheur !), Eclipse (qui a révolutionné l'expérience développeur site central), même si beaucoup d'outils système n'existent qu'en interface 3270 ;
- qui donne un accès au spool (sur les z les log sont centralisées : pas besoin de chercher où peut bien être cachée cette foutue log, elle est nécessairement sous SDFS ou sous l'outil d'archivage du site) ;
- un DB2 ;
- un moniteur transactionnel IMS ou CICS ;
- un moniteur de transfert, au hasard CFT ;
- du JCL comme langage de script qui avec DFSORT permet de triturer un fichier comme on le souhaite ;
- différents outils permettant de lire les fichiers en mode tabulaire (en exploitant la structure COBOL) ;
- Un ordonnanceur permettant de lancer les tâches planifiée ;
- différents outils permettant de visualiser les tables DB2 dont OPTIM qui permet en y déclarant le MCD de littéralement se promener dans les données ;
- tout un tas d'outils de supervision permettant de couper la tête à celui qui s'est amusé à rechercher la date du jour à la lecture de chaque ligne d'un fichier…
- un outil de GCL pour gérer les différentes version des source COBOL et JCL et leur déploiement dans les environnement hors prod et de prod ;
- et pour ceux qui ne jurent que par l'Unix, l'USS : la partition UNIX !
Cette très forte intégration fait que plein de sujets « open » (non z/OS) n'ont pas cours sur site central, et qui permet une disponibilité d'au moins 99,99 %.
Par exemple, il y a quelques années, il y a eu une volonté de se lancer dans le Zdevops sur mon site. Mais piloté par une personne ne connaissant pas le z/OS, il lui a fallu 3 (longues) années avant de comprendre que pour nous, compiler (builder), déployer tout ça tout ça était un non sujet (pas besoin de s'appuyer sur chaîne d'outils qui changent constamment de version pour des raisons des sécurité : on a des outils très bien fait pour ça comme ISPW - CodePipeline, son nouveau nom): ça marche correctement depuis au moins 30 (voire 50) ans, avec des hauts et des bas, mais ça on sait (très bien) faire.
Le vrai sujet Zdevops, c'est le test : mais là aussi, avec des outils aussi puissant qu'OPTIM, ou des suites du marché, ça n'est pas vraiment un problème. Le seul problème du Zdevops, c'est d'accepter d'inverser la pyramide des tests.
Mais on part sur un autre débat ! (^ _ ^ )
« Y a même des gens qui ont l’air vivant, mais ils sont morts depuis longtemps ! »
Envoyer un commentaire
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.