Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter
Vous la connaissez sans doute
C'est l'histoire du développeur COBOL qui a fait fortune avec les maintenances liées au passage à l'an 2000. Avec son argent, il décide de se faire cryogéniser et de tomber dans un sommeil (presque) éternel.
Un jour quelqu'un le met au micro-onde et le réveille. Le développeur COBOL ouvre les yeux et demande: pourquoi vous me réveillez ? L'autre lui répond: on est en l'an 9999 , et il paraît que vous savez développer en COBOL...
COBOL ne s'improvise pas
J'ai déjà eu l'occasion de m'exprimer sur ce sujet, je ne résiste pas. COBOL est un langage fantastique, en fait. J'ai maintenu des applications (bancaires) écrites par des comptables sans aucune connaissance informatique vers la fin des années 70, qui tournaient encore en 2014. Ce fut un boulot de détective, et j'ai fait d'autres choses de bien plus intéressantes, mais tout de même : Ces sources ont passé sur au moins trois plateformes différentes, IBM, BULL, puis VMS, et sous VMS sont passées de VAX à IA64.
Ce sacré langage offre dans un même paquet tout ce qu'il faut pour gérer une boîte. Vous y décrivez vos données, créez votre base de données locale (l'ISAM et la gestion de fichiers en général est très performant) ou vous utilisez un pré-compilateur qui se chargera de l'interface avec un SGBDR, vous créez vos écrans (bien que sur grands systèmes on utilise plutôt des outils spécialisés) et vos rapports. Que demander de plus ?
Il n'est pas à la mode, il est verbeux, la plupart de ses fonctions intéressantes sont complexes à mettre en oeuvre et ou en oublie vite les finesses si on ne l'utilise pas souvent. Mais je me réjouis de voir dans trente ans une application écrite en Swift ou en Java (une vraie, pas juste un gadget qui fait bouger des Mickeys sur un écran) maintenue et portée de plateforme en plateforme, des Core ix à la troisième génération de processeurs quantiques. On va se marrer ! Alors que par sa structure, cette mutation est possible pour du COBOL, très fortement normé.
Enfin, de par sa singularité, il ne faut pas penser qu'on peut se mettre au COBOL comme je l'ai fait récemment à Python, par exemple : Il est indispensable de l'apprendre, à fond, en commençant par la définition des structures de données (eh oui, des structs en quelque sorte), en passant par la gestion des différents types de fichier et leur usage (si on n'utilise pas de SGBD externe), puis en pratiquant les fonctions complexes comme STRING...UNSTRING, SORT, j'en passe et j'en oublie. Ah, et PERFORM, évidemment ! Et la SCREEN SECTION, et la REPORT SECTION, aussi... A ce propos, j'ai généré des millions de pages en postscript à partir de COBOL, les estimations de comptes destinées à la clientèle d'une banque privée. Ce sont des gens qui aiment les jolies choses, jusqu'aux listings qu'ils reçoivent de leur banque.
Bref, COBOL est un monde en soi, si on veut y entrer il faut faire un effort. En comparaison je suis un cours formel de C sur edX (celui de Dartmouth, excellent, entre nous soit dit), c'est bien plus facile que les cours COBOL que j'ai suivis à l'époque. Et il y a quarante ans, j'étais plus frais qu'aujourd'hui (bien qu'il reste encore de beaux restes, en toute modestie !).
Quant à ceux qui méprisent ce langage juste parce qu'il serait passé de mode, la seule chose que je puisse dire est qu'ils sont encore bien jeunes, et qu'à mon point de vue, l'informatique sérieuse ce n'est pas HTML, JavaScript et une librairie ou un framework. Même si ça peut rendre service. Parfois.
Hugh. Papy a parlé !
J'ai programmé en COB1, puis COBOL85, puis COBOL 2000 sur Mainframe Siemens BS2000 de 1986 à 2006.
Mais ce n''est pas mon langage favori, loin de là.
En 2019, le COBOL n'a pratiquement plus rien pour lui si ce n'est que son code est plus secret que les autres langages et qu'il résiste "peut-être" mieux aux attaques virales.
Si je me demande ce que faisait de mieux le Cobol par rapport aux autres langages, je dirais
1. était capable de traiter de l'indexé séquentiel avec lecture directe, en avant et en arrière.
2. il était capable de faire du calcul très précis au niveau des montants avec une précision correcte au niveau des arrondis DE MANIERE TRES SOUPLE.
Depuis 1986, j'ai également écrit des applications en VB6, SQL, VB.Net, C++ et Java et pour chacun de ces langages j'ai plus de 5 ans d'expérience.
Par rapport aux 3 points ci-dessus, l'indexé séquentiel n'est plus utilisé et je ne voudrais plus en faire tellement les recherches SQL que l'on peut faire maintenant sont puissantes.
Le calcul sur des montant peut-être fait simplement en utilisant l'objet CDecimal en VB.Net ou BigDecimal en Java sauf que je ne vous conseille pas le Java tellement l'écriture de formule en BigDecimal est illisible car Sun et Oracle n'ont jamais accepté que Java puisse surcharger des opérateurs. En Java, si l'on utilise BigDecimal, il faut donc utiliser les méthodes Add() et Multiply().
Je pense que le COBOL est mort avec les Mainframes et disparaitra avec les derniers survivants.
Pour info, je n'ai jamais fait de COBOL graphique comme il est possible de le faire avec MicroFocus. Les écrans COBOL étaient destinés à être affichés sur des terminaux de 25 lignes et 80 caractères.
Les API VB.Net avec WinForms ou WPF ou les API Java de type Swing ou Primefaces sont bien plus agréables à utiliser.
Pour moi le COBOL est mort, vive le VB.Net.
Euh ... pas compris là ...Envoyé par patrick72
Euh, ben oui, mais VB.NET c'est un peu Windows-centrique, ça, non ? Que ferez-vous lorsque vous devrez passer à Linux ? Ou Mac ? Bon, j'ai aussi fait quelques belles choses en Delphi.
Mais avez-vous noté aussi combien il reste difficile de sortir des écrans tabulaires dans les applications de gestion ? Vous parlez des 25 x 80, aujourd'hui on met plus de caractères, certes, mais d'après ce que je constate on n'a pas quitté cette approche. C'est fort dommage, en exploitant les modes graphiques nous devrions pouvoir offrir quelque chose de plus intuitif et plus explicite aux utilisateurs professionnels. Mais non, faute d'imagination, on continue comme avant.
J'ai livré une application de trading développée en Delphi qui utilise une présentation tabulaire mais offre du drag/drop pour réaliser les deals, l'augmentation de qualité, la diminution d'erreurs et l'efficacité de la chaîne ont été considérablement augmentées. Pourtant j'ai dû faire très vite et n'ai implémenté qu'une petite partie de ce que je désirais. C'est facile à concevoir, et permet d'offrir une expérience utilisateur stable et rassurante pourtant. Ça juste pour dire que tant qu'on fait de la grille, COBOL c'est très bien et qu'il n'y a pas trop de raison d'en sortir ! (Je plaisante quand même, mais pas complètement).
réponse à Luc
A propos des nombres, je veux dire que lorsque je programmais en Cobol, la précision du calcul était assurée par le compilateur beaucoup plus précisément qu'en C ou en C++ lorsqu'on utilise les types du langage courant que sont 'float' ou 'double'.
En effet, en Cobol, nous disposons de plusieurs types de variable numérique
PIC 9(4) = chaine de 4 caractères numériques
PIC 9(4) COMP-3 ou PACKED-DECIMAL
Aucun des nombres ci-dessus défini comme PIC 9(4) ne peut être strictement plus grand que 9999.
En COBOL, la définition des limites des valeurs numériques est plus près de l'humain que de la machine.
Bien sûr, en COBOL, il existe l'équivalent du 'float' ou 'double' connu en C ou C++ ou Java.
c'est PIC 9(4)V9(2) COMP-4 ou BINARY.
Les calculs scientifiques basés sur les BINARY ne sont pas toujours exploitables dans les applications commerciales.
Lorsque je suis repassé du COBOL au C ou C++, il n'y avait pas d'équivalent dans ces langages pour faire correctement et simplement des calculs avec des arrondis corrects.
Le problème des arrondis en utilisant les type 'float' ou 'double' en C, C++ ou Java est clairement expliqué sur le site de StackOverflow.
https://stackoverflow.com/questions/...16601#42416601
@TJ1985:
Premièrement, en 2019, faire du VB.Net ce n'est plus centré exclusivement sur Windows puisque une application VB.Net peut fonctionner sous Linux et iOS !
Lorsque Microsoft a développé C# et par la même occasion son RunTime .Net, cela a été fait spécifiquement pour Windows. Maintenant, le RunTime .Net a été porté pour être multiplateforme.
Comme d'habitude, Microsoft a mis le temps; mais une fois la machine lancée (vers 2020), on ne saura plus l'arrêter d'autant plus qu'Oracle commence à vouloir faire payer Java.
Deuxièmement, ne n'est pas parce que COBOL est bon pour gérer les grilles qu'il faut continuer d'utiliser COBOL.
Au 21ème siècle, les tableaux que COBOL dessinaient n'existent plus et ont été remplacés par des tableaux dynamiques d'objets (et non de caractères) filtrables et triables à volonté comme s'il s'agissait d'un tableau sous Excel.
Les tableaux peuvent contenir des caractères en Unicode ou même des images ou des formules mathématiques.
Je ne voudrais jamais faire de tels tableaux en COBOL.
C'est fou le nombre de gens qui parlent du COBOL, en général pour le critiquer ... Faudrait juste qu'ils le connaissent un peu ...
Ce format, d'USAGE implicite DISPLAY est réservé à l'affichage et doit être évité pour les calculs
C'est PACKED et pas PACKAGED et même PACKED-DECIMALPIC 9(4) COMP-3 ou PACKAGED
Et mieux vaut le coder signé PIC S9(4) PACKED-DECIMAL.
BINARY est l'équivalent d'integer en C.Bien sûr, en COBOL, il existe l'équivalent du 'float' ou 'double' connu en C ou C++ ou Java.
c'est PIC 9(4) COMP-4 ou BINARY.
@schlebe
Je CONSTATE qu'on utilise toujours une représentation tabulaire pour la plupart des applications de gestion, alors que des alternatives existent, basées sur des analogies graphiques. Après, que ce soit fait en COBOL ou autre chose importe peu : L'esprit ne change pas, donc a priori le besoin de changer d'outil ne s'impose pas.
Deuxièmement j'ai précisé que j'ai développé une "petite" application de trading en sortant un peu de ces limites, et que pour ce faire je suis revenu à Pascal et Delphi, plus précisément. Sans regrets.
Pour finir, je n'aime pas la critique systématique d'un langage qui a permis de gérer tout ce qui se passait sur la planète durant une bonne trentaine d'années, pour ne pas dire plus. Parti de rien, COBOL a inventé énormément de concepts et de manières de les implémenter. Aujourd'hui, je vois fleurir tous les quinze jours un nouveau langage révolutionnaire, et je constate en parallèle la dégradation des applications fournies notamment par les administrations. Je ne peux pas m'empêcher de faire un parallèle, et j'en viens à dire que je préfère mille fois un COBOListe compétent plutôt que Swifteux débutant.
On en reparlera dans quinze ans, comme d'habitude !
@Luc Orient
Merci pour les remarques. J'ai corrigé mon message en conséquence.
Il faut dire que j'ai arrêté de programmer en COBOL en 2006.
@Luc Orient
C'est faux. Les formats numériques natifs en COBOL s'expriment bien sous la forme PIC S9(4)V99, c'est leur forme canonique. Si je ne mélange pas tout, ce format code le numérique en Binary Coded Decimal, en gros chaque digit est codé sur huit bits. On n'a donc pas une représentation en binaire, contrairement à ce dont nous avons l'habitude dans d'autres langages.
Si vous voulez du numérique édité, vous passerez à quelque chose comme PIC -9(4).99 à condition d'avoir défini DECIMAL POINT IS COMMA en ENVIRONMENT DIVISION. Les formats COMP sont apparus tardivement, et n'offrent pas les mêmes avantages en précision de calcul que le format natif. Leur usage naïf peut expliquer pourquoi on entend des gens parler de précision d'arrondi assez bonne. Elle n'est pas assez bonne, elle est absolue quand on utilise le format natif. C'est pourquoi sans bibliothèque spécialisée, COBOL reste incontournable lorsqu'on fait des calculs financiers.
Bien sûr, les formats COMP permettent d'aligner la taille des variables sur les mots natifs des processeurs, ça peut donc accélérer marginalement les opérations arithmétiques. D'expérience je doute toutefois que ça ait une influence réelle, même sur de gros traitements pas lots (comptabilité d'une banque gérant 200 Mrds). Mais il est vrai que je n'ai pas fait de comparaison sur ce plan. Par contre l'usage de l'extension COMPUTE qui permet d'écrire les opérations arithmétiques "comme d'habitude" est, elle, une très grosse consommatrice de ressources.
En voulant vérifier ce que je viens d'écrire dans l'espoir d'éviter d'écrire une ânerie de plus, j'ai constaté qu'il faut toujours acheter la norme COBOL environ 200€ pour apprendre le langage. Et après on s'étonne de le voir moins enseigné ? Pas moi, en tout cas ! Quand je pense que je me suis débarrassé du petit bouquin NCR à la fin de mes cours, quel idiot j'ai été...
.
Que d'erreurs, d'approximation, de contre vérités et de légendes urbaines en 15 lignes environ sur COBOL ... Allons y ...
Non, c'est toi qui a tout faux. La représentation interne d'une variable numérique en COBOL ne dépend pas, ou peu, de la clause PICTURE mais bien de la clause USAGE.C'est faux. Les formats numériques natifs en COBOL s'expriment bien sous la forme PIC S9(4)V99, c'est leur forme canonique.
Si cette clause est absente, puisqu'elle est facultative, comme souvent en COBOL, c'est la clause USAGE DISPLAY qui est prise par défaut, Comme son nom l'indique l'USAGE DISPLAY signifie que la variable est réservée à l'affichage. Bien sûr, on peut faire des calculs avec de telles variables, mais on oblige le compilateur à générer des instructions de conversion vers un format reconnu par le processeur avant de faire une opération numérique, quelle qu'elle soit. Un simple regard sur le code machine généré par le compilateur suffit à le prouver. En matière de performances, on a fait mieux ...
Oui, tu mélanges tout. Le BCD, à condition d'avoir la bonne clause USAGE, fait que les chiffres ne sont pas codés sur 8 bits mais sur 4 bits. 4 bits sont largement suffisants pour coder en binaire les chiffres de 0 à 9.Si je ne mélange pas tout, ce format code le numérique en Binary Coded Decimal, en gros chaque digit est codé sur huit bits. On n'a donc pas une représentation en binaire, contrairement à ce dont nous avons l'habitude dans d'autres langages.
La représentation en binaire (représentation en complément à 2) est tout à fait disponible en COBOL, il suffit, encore une fois, d'avoir la bonne clause USAGE ( BINARY ou COMP ).
Faux. Archi faux. le format "natif" n'a pas de sens en COBOL.Les formats COMP sont apparus tardivement, et n'offrent pas les mêmes avantages en précision de calcul que le format natif. Leur usage naïf peut expliquer pourquoi on entend des gens parler de précision d'arrondi assez bonne. Elle n'est pas assez bonne, elle est absolue quand on utilise le format natif.
.
Tu aurais dû. On ne parle pas là de problème d'alignement sur des mots machine, mais de formats numériques reconnus par les instructions du processeur sans avoir besoin de passer par des instructions de conversion, forcément coûteuses.Bien sûr, les formats COMP permettent d'aligner la taille des variables sur les mots natifs des processeurs, ça peut donc accélérer marginalement les opérations arithmétiques. D'expérience je doute toutefois que ça ait une influence réelle, même sur de gros traitements pas lots (comptabilité d'une banque gérant 200 Mrds). Mais il est vrai que je n'ai pas fait de comparaison sur ce plan.
Légende urbaine totale ... ça peut être été vrai dans les années 60 quand l'instruction est apparue pour la première fois, et encore je ne suis même pas sûr, mais désormais, avec les compilateurs modernes, on sait traiter de manière efficace et optimisée toutes les formules de calcul possible. Tous les langages disposent de cette facilité d'écriture et on voit mal pourquoi le compilateur COBOL ferait moins bien que ceux des autres langages.Par contre l'usage de l'extension COMPUTE qui permet d'écrire les opérations arithmétiques "comme d'habitude" est, elle, une très grosse consommatrice de ressources.
Pas la peine d'acheter la norme COBOL, toute la documentation COBOL IBM est disponible sur le net gratuitement.En voulant vérifier ce que je viens d'écrire dans l'espoir d'éviter d'écrire une ânerie de plus, j'ai constaté qu'il faut toujours acheter la norme COBOL environ 200€ pour apprendre le langage.
CQFD.
PS. Je parle du COBOL Mainframe IBM.
Après un certain temps de recherche, sur le site de IBM, j'ai fini par trouver :
- Enterprise COBOL for z/OS: Language Reference (Version 4 Release 2) (août 2009) (700 pages) (lien vers le PDF)
- Enterprise COBOL for z/OS: Programming Guide (Version 4 Release 2) (août 2009) (930 pages) (lien vers le PDF)
Par contre, je n'ai rien trouvé de gratuit pour COBOL 2014 (actuellement la dernière version du COBOL).
PS : Je ne suis pas développeur COBOL.
Coup de frais !
@Luc Orient
Tu as raison sur le bitage, évidemment, c'est 4 et non 8 bits par digit. Pour le reste, le COMPUTE j'avais vérifié à l'époque, COBOL 85 sous VMS.
Pour l'USAGE, franchement, je ne peux pas me défendre. J'ai appris tout ça en 1987, puis j'ai essentiellement pratiqué, en commençant par du portage et de la maintenance. J'ai transcrit l'usage que nous en avions, et les raisons que nous nous donnions.
Un truc clair est que nous ne spécifiions jamais l'USAGE DISPLAY puisque nous passions par des gestionnaires d'écran. Et nous évitions absolument les COMP pour retrouver nos petits à l'époque des portages, car les chaînes batch passaient par des fichiers séquentiels. Ensuite, tu me mets le doute, mais je crois fermement me rappeler que nous appelions nos routines d'interface aux bases de données en évitant soigneusement tout ce qui pouvait ressembler à du binaire.
Bref. Fait pas beau devenir vieux, surtout quand on était un jeune con !
Mais bon, je respecte toujours ce vieux langage, même si je lui préfère Pascal - Delphi.
La dernière version du COBOL IBM Mainframe est la 6.2. La version 4 commence un peu à dater ...
Tout est là
Je complète les propos que j'approuve de Luc Orient
Je ne reviendrai pas sur le format "natif", Luc Orient a clairement expliqué ce qu'il en était (ou plutot n'en était pas)
Au sujet de l'apparition "tardive" du type "COMP" je demande à voir, il était déjà présent dans la version 74 de COBOL et je doute que qui que ce soit présent sur ce forum ait pratiqué des versions antérieures
L'alignement des variables sur les frontières de mots est sans rapport avec le type des données, il est conditionné par le "niveau" de déclaration
Seuls les niveaux "01" sont alignés sur un mot contrairement aux niveaux inférieurs
Depuis pas mal de temps déjà, les niveaux "77" sont traités comme des "01" à cet égard. Ce n'était pas le cas jadis.
Par contre, au sujet de la différence de performances entre COMPUTE et les autres opérations, ce n'est pas une légende urbaine, on pouvait autrefois vérifier dans le généré assembleur qu'un COMPUTE était plus couteux qu'un ADD
Mais cette différence a disparu despuis bien longtemps et il n'est donc plus nécessaire de s'en préoccuper.
Pour en revenir aux différences de performances entre un type COMP et les autres types numériques, je m'étais amusé il y a longtemps à comparer le coût CPU respectif d'une boucle ADD répétée des millions de fois pour que l'écart soit mesurable. Le numérique étendu coutait 8 fois plus en CPU que du binaire (du COMP donc) et 4 fois plus que du packé (COMP-3).
Autant dire que l'écart est arithmétiquement très significatif, mais, comme dans la plupart des traitements de gestion écrits en cobol, le coût des opérations de calcul est le plus souvent très marginal, chercher à optimiser ce point est très luxueux. Priorité doit être donnée à l'architecture et aux I/O (requêtes ensemblistes notamment)
Je "plussoie" allégrement ce point. Effectivement ce qui coûte cher de nos jours plus que les calculs se sont les nombreux I/O entre modules. Les vieux modules tapaient généralement dans une seule table à la fois entraînant une multiplication des accès.Autant dire que l'écart est arithmétiquement très significatif, mais, comme dans la plupart des traitements de gestion écrits en cobol, le coût des opérations de calcul est le plus souvent très marginal, chercher à optimiser ce point est très luxueux. Priorité doit être donnée à l'architecture et aux I/O (requêtes ensemblistes notamment)
Du linéaire A au français
Et bien oui, le COBOL reste encore massivement utilisé par de très riches entreprises, qui ont fait basculer leur gestion de documents (et transactions), du mode papier/secrétaire, vers l'IA/mainframe. Le proglème est que COBOL, est ancien, très ancien, environ 20 générations de processeurs (une tout les 3 ans en moyenne). C'est comme si on codait et communiquait avec une forme de langage figée depuis 5 siècles (humains). Ce qui serait plutôt difficile.
Sans être impossible a faire, écrire du code en COBOL requiert un suivit assez lourd et étrange de contraintes concernant l'écriture du code (sans parler des limites dans la gestion de variables et de la mémoire système). Oui, COBOL reste encore utilisé. Oui, COBOL ne va pas disparaitre de suite. Mais, COBOL est inadapté aux évolutions techniques depuis plus de 25 années. Le développement de processeurs multi-coeurs, à fréquence variable. L'usage de systèmes de stockage de données reposant sur des supports mélangés (cartouches magnétiques, HDD, SSD, optiques, et autres). Evolution des technologies de communication, de la variation de signal électrique modulé pour aboutir (aujourd'hui), à l'usage de la lumière pour transmettre des paquets de données mélangées via fibre optique. Cela COBOL ne le gère pas en direct, mais fait appel à des bibliothèques de fonctions écrites en assembleur, pour chaque module utilisé.
Et je ne parle pas des problèmes de sécurité des communications, et de ceux liés à la conservation des données (ainsi que leur authentification). Car, oui les grands groupes restent sous COBOL, plus par paresse (et avarice fonctionnelle), que pour offrir une réelle sécurité.
Et non, COBOL (et ses utilisateurs), vont devoir rattraper le reste du monde. Sans oublier le principal problème, pour les développeurs informatiques : se former à ce langage. Car les lieux de formation sont rares, et donc cela coûte cher. Sans compter les EDI, peu nombreux, développés en mode fermé (donc de fiabilité non garantie, sinon par leurs propres fournisseurs, ce qui est de confiance faible, voire nulle). Et le principal problème, le vieillissement des systèmes basés sur COBOL.
La durée de vie d'un système de gestion (mainframe/station de travail/poste d'accès aux données/data center/ et autres) reste limitée. L'usure physique des composants (qu'il s'agisse des disques durs ou des processeurs et des cables de communication) est réelle. Un CPU peut tenir jusque 30 ans (si bien fabriqué, et jamais stressé), de même qu'une cartouche de données (bandes magnétiques IBM par exemple). Mais le reste du système, n'a pas cette chance. Comme la carrosserie d'une voiture, et ses pneus. Le moteur d'une voiture peut rester fonctionnel des décennies, mais le reste (amortisseurs, pneus, capot, sièges, etc.), tout ça provoque la destruction de toute la voiture.
Alors, oui, allez-y apprenez COBOL, foncez vers les banques, assurances, gouvernements, et autres grandes institutions qui refusent d'évoluer. Mais quand leurs systèmes seront vraiment dépassés, et surtout hors d'usage et sans maintenance possible (absence de pièces détachées pour réparer), il sera trop tard pour tout. Durée de migration des données, services proposés, sécurité des communications, tout cela ne pourra plus être fournit avec COBOL.
Même RSA est fragile. Son asymétrie ne garantit pas son infaillibilité (sans parler de l'algorithme de base).
Donc, pour moi COBOL doit être remplacé par un langage beaucoup plus récent, et surtout construit pour aller avec le matériel actuel dès sa conception. Sinon, malgré sa continuation, son ancienneté causera sa perte. Comme une vieille espèce animale face à un nouveau virus.
Et encore une couche supplémentaire d'erreurs, d'approximations, de contre vérités et de légendes urbaines en quelques lignes sur COBOL ... Allons y ...
En informatique, le matériel évolue beaucoup plus vite que le logiciel. On continue à programmer en FORTRAN (apparu dans les années 50), en BASIC (années 60) et en C (années 60/70). Donc l'argument est difficilement recevable.
Mais quelles contraintes et limites ? On aimerait savoir.Sans être impossible a faire, écrire du code en COBOL requiert un suivit assez lourd et étrange de contraintes concernant l'écriture du code (sans parler des limites dans la gestion de variables et de la mémoire système).
Bien sûr que non, COBOL ne gère pas en direct ces technologies, mais il s'appuie considérablement sur d'autres logiciels qui eux, savent les gérer.Oui, COBOL reste encore utilisé. Oui, COBOL ne va pas disparaitre de suite. Mais, COBOL est inadapté aux évolutions techniques depuis plus de 25 années. Le développement de processeurs multi-coeurs, à fréquence variable. L'usage de systèmes de stockage de données reposant sur des supports mélangés (cartouches magnétiques, HDD, SSD, optiques, et autres). Evolution des technologies de communication, de la variation de signal électrique modulé pour aboutir (aujourd'hui), à l'usage de la lumière pour transmettre des paquets de données mélangées via fibre optique. Cela COBOL ne le gère pas en direct, mais fait appel à des bibliothèques de fonctions écrites en assembleur, pour chaque module utilisé.
Et je ne parle pas des problèmes de sécurité des communications, et de ceux liés à la conservation des données (ainsi que leur authentification). Car, oui les grands groupes restent sous COBOL, plus par paresse (et avarice fonctionnelle), que pour offrir une réelle sécurité.
Là l'argument est plutôt recevable.Et non, COBOL (et ses utilisateurs), vont devoir rattraper le reste du monde. Sans oublier le principal problème, pour les développeurs informatiques : se former à ce langage. Car les lieux de formation sont rares, et donc cela coûte cher.
Sur ce plan, IBM et Microfocus, par exemple,ont une offre tout à fait pertinente.Sans compter les EDI, peu nombreux, développés en mode fermé (donc de fiabilité non garantie, sinon par leurs propres fournisseurs, ce qui est de confiance faible, voire nulle).
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 le principal problème, le vieillissement des systèmes basés sur COBOL.
La durée de vie d'un système de gestion (mainframe/station de travail/poste d'accès aux données/data center/ et autres) reste limitée. L'usure physique des composants (qu'il s'agisse des disques durs ou des processeurs et des cables de communication) est réelle. Un CPU peut tenir jusque 30 ans (si bien fabriqué, et jamais stressé), de même qu'une cartouche de données (bandes magnétiques IBM par exemple). Mais le reste du système, n'a pas cette chance. Comme la carrosserie d'une voiture, et ses pneus. Le moteur d'une voiture peut rester fonctionnel des décennies, mais le reste (amortisseurs, pneus, capot, sièges, etc.), tout ça provoque la destruction de toute la voiture.
J'ai eu peur, j'ai craint d'avoir émis encore une série d'âneries sur le domaine. Puis j'ai réalisé que, finalement, tu réagissais au post qui m'avait aussi dérangé, mais sur lequel je n'ai pas osé intervenir cette fois, par crainte d'en rajouter une couche ;-)
Car, oui, j'ai été très surpris d'apprendre que c'est le programmeur qui définit l'architecture pour laquelle il écrit. Bien que beaucoup de mes connaissances formelles de COBOL se soient évaporées au fil du temps, comme je l'ai abondamment démontré par ailleurs, il me restait la conviction que le compilateur avait peut-être un rôle à jouer en la matière, associé à l'éditeur de liens.
Dire que je lui ai attribué injustement le mérite d'avoir porté des applications écrites sur IBM, puis portées sur CIIHB puis sur VAX-VMS, puis sur AXP-VMS, puis sur IA64-VMS, alors que c'étaient juste mes doigts magiques qui se chargeaient de l'allocation mémoire, des accès aux ressources système et tout et tout... Décidément, vieillir ne nous arrange pas, en tout cas pas moi !
Bon, sérieusement, je ne peux pas dire que j'ai aimé COBOL. Mais je ne l'ai pas détesté non plus. En 25 ans il m'a permis de bien manger, et surtout il a permis à mon client principal de fonctionner et de grandir à frais raisonnables. Depuis le passage à des outils "modernes", les budgets ont explosés, la qualité ne s'est pas améliorée, les équipes ont été multipliées par dix alors que l'amplitude du problème n'a que peu varié et sa nature pas du tout.
Il est je pense toujours assez simple de comprendre ce que fait un programme COBOL écrit "normalement", alors que piger les subtilités d'un serveur C++ appuyé sur CORBA... on s'amuse. J'y ai été formé lors d'une formation complémentaire en emploi, dans les années 1987. Une année à raison de 4 heures deux fois par semaine si mon souvenir est bon. Nous pouvions utiliser des manuels de NCR je crois... Après une année, nous avons été capables d'écrire un petit soft de gestion d'une boîte de confection textile, fonctionnel. Nous avons travaillé en équipes de trois ou quatre. Le jour de la recette nous avons déversé nos sources dans une arborescence convenue, avons compilé le tout et ça a presque fonctionné du premier coup (un groupe avait un peu oublié de prévenir les autres d'une variation de la structure d'un fichier, mise en place de leur fichier d'inclusion en remplacement de l'officiel et c'était bon). Ca en dit assez long sur la difficulté d'apprentissage du langage, je crois...
Mais bon, balai neuf balaie bien, et c'est vrai que la programmation pensée, réfléchie, modélisée semble de moins en moins pratiquée. Même par moi.
Vous avez un bloqueur de publicités installé.
Le Club Developpez.com n'affiche que des publicités IT, discrètes et non intrusives.
Afin que nous puissions continuer à vous fournir gratuitement du contenu de qualité, merci de nous soutenir en désactivant votre bloqueur de publicités sur Developpez.com.
Répondre avec citation
Partager