Discussion :

[Darkzinus]

Aucun rapport, IBM a annoncé fin 2019, le z15, à savoir, la 15 ième génération de son Mainframe à base de CMOS. Le matériel dans les grands DATACENTER des entreprises qui utilisent COBOL est en constant renouvellement et parfaitement à jour technologiuement.

Et c'est pareil pour les systèmes I qui sont de plus en plus performants avec l'ajout sans cesse de nouvelles fonctionnalités !

[AlainFeler]

Je ne sais pas en quoi sont codés actuellement les programmes de gestion du cadastre français ( 100 millions de parcelles, quelques dizaines de millions de bâtiments et de propriétaires), mais les fichiers diffusés pour ce qu'on appelle la "matrice cadastrale" c'est-à-dire les propriétaires et leurs propriétés (terrains, lots, locaux, etc.) sont de bons vieux fichiers Cobol en RECORD VARYING qui paraissent très "exotiques" aux gens souvent jeunes qui doivent les lire avec des systèmes plus récents.

[TJ1985]

Par curiosité je me suis inscrit avant-hier en auditeur à un cours COBOL donné par IBM diffusé sur Coursera. Je n'avais jamais travaillé sur un système IBM, mon univers était VMS. Mais quel confort de retrouver un tel environnement... Franchement, en ce qui concerne la gestion, COBOL est toujours remarquablement actuel. Chapeau, Madame Hopper...

[escartefigue]

Et c'est pareil pour les systèmes I qui sont de plus en plus performants avec l'ajout sans cesse de nouvelles fonctionnalités !

Certes, mais ce qui pèche encore et toujours avec IBM, c'est le montant de la facture !
Les performances sont là, les fonctionnalités aussi, le support et la documentation sont au top, mais l'addition est salée

L'un de mes clients a choisi une refonte de de IBM DB2 pour Postgresql uniquement pour cette raison.
Au niveau performances il s'en mord les doigts mais les les financiers n'en ont cure, ils voient les lignes budgétaires qui ont fondu à vue d'oeil et c'est bien tout ce qui compte pour eux.
Les plans batch qui ne peuvent plus passer dans les nuits et les WE, c'est le problème des techniciens, pas celui des comptables ni des actionnaires

[TJ1985]

Autre surprise : il semble qu'on trouve un compilateur COBOL open source de bonne tenue : GNUCobol. J'ai un peu transpiré, mais j'ai pu le construire et le faire tourner sur un Ubuntu 18.04LTS. J'ai aussi installé (penser au tournevis...) OpenCobolIDE. Et je suis surpris, ça semble plutôt bien marcher.
Le plus surprenant est l'activité qui persiste autour de ces projets, dont les dernières mises à jour sont très récentes. De même sur les forums.
COBOL n'est ni Rust, ni C++, ni, ni, ni. J'ai eu à maintenir pas mal de code COBOL, ainsi que d'autres langages. Les problèmes que j'ai rencontrés ne venaient pas du langage mais des auteurs. Bien écrits, même sans documentation, les programmes COBOL permettent de se faire rapidement une idée de ce à quoi ils servent, de ce qu'ils traitent et comment. C'est rarement le cas pour les autres langages.
Je préfère Pascal, C++, j'aime bien Python, C, etc. Mais si je dois reprendre de l'existant, je souhaite que ce soit du COBOL, même mal écrit... Et comme il existe en OpenSource, pourquoi s'en priver

[el_slapper]

Le couple OpenCobolIDE/GNUcobol est pas mal, mais la dernière fois que j'avais posé mes mains dessus, ne permettait pas de faire de l'objet. Je n'ai jamais eu l'occasion d'en faire quand je bossais pour les grands comptes, et j'aimerais, une fois dans ma vie, invoquer une classe COBOL, juste pour pouvoir me dire que je sais faire.

Mais bon, 99,99% des applis COBOL n'en ont pas besoin, le procédural suffit pour ce qu'on en fait (j'ai même envie de dire : est plus performant).

[TJ1985]

Le couple OpenCobolIDE/GNUcobol est pas mal, mais la dernière fois que j'avais posé mes mains dessus, ne permettait pas de faire de l'objet. Je n'ai jamais eu l'occasion d'en faire quand je bossais pour les grands comptes, et j'aimerais, une fois dans ma vie, invoquer une classe COBOL, juste pour pouvoir me dire que je sais faire.

Mais bon, 99,99% des applis COBOL n'en ont pas besoin, le procédural suffit pour ce qu'on en fait (j'ai même envie de dire : est plus performant).

Lorsque j'ai appris COBOL, l'enseignant nous a habitué à placer toutes les définitions dans des fichiers d'inclusions. Ça obligeait à une forme structurée de développement, le programme ne consistant plus quasiment qu'en la procédure division. C'était propre et efficace...
Je n'ai jamais retrouvé cette approche par la suite, dans la vraie vie. J'ai bien tenté de l'appliquer, mais lorsqu'on s'appuie sur des bases de données la problématique est bien différente de celle des fichiers.
Quant à l'objet, effectivement, ça m'amuserait bien pour voir, mais franchement j'ai l'impression que c'est plus pour satisfaire à la mode que par nécessité.