IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)
Navigation

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

Cobol Discussion :

Le langage de programmation Cobol fête ses 60 ans


Sujet :

Cobol

  1. #21
    Candidat au Club Avatar de kaynun
    Profil pro
    Ingénieur R&D / Etude & Développement
    Inscrit en
    décembre 2012
    Messages
    1
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations professionnelles :
    Activité : Ingénieur R&D / Etude & Développement

    Informations forums :
    Inscription : décembre 2012
    Messages : 1
    Points : 4
    Points
    4
    Par défaut 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...

  2. #22
    Membre expérimenté

    Homme Profil pro
    Consultant informatique
    Inscrit en
    avril 2015
    Messages
    310
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Vendée (Pays de la Loire)

    Informations professionnelles :
    Activité : Consultant informatique
    Secteur : Finance

    Informations forums :
    Inscription : avril 2015
    Messages : 310
    Points : 1 528
    Points
    1 528
    Par défaut 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é !

  3. #23
    Membre régulier
    Homme Profil pro
    retraité depuis juin 2019
    Inscrit en
    février 2018
    Messages
    39
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 59
    Localisation : Belgique

    Informations professionnelles :
    Activité : retraité depuis juin 2019
    Secteur : High Tech - Produits et services télécom et Internet

    Informations forums :
    Inscription : février 2018
    Messages : 39
    Points : 123
    Points
    123
    Par défaut
    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.

  4. #24
    Membre expert
    Homme Profil pro
    Futur retraité
    Inscrit en
    octobre 2005
    Messages
    1 451
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 62
    Localisation : France, Seine Saint Denis (Île de France)

    Informations professionnelles :
    Activité : Futur retraité
    Secteur : Finance

    Informations forums :
    Inscription : octobre 2005
    Messages : 1 451
    Points : 3 187
    Points
    3 187
    Par défaut
    Citation Envoyé par patrick72 Voir le message
    ...
    En COBOL, les calculs sur les nombre sont fait avec leur "représentation graphique" ...
    Euh ... pas compris là ...

  5. #25
    Membre expérimenté

    Homme Profil pro
    Consultant informatique
    Inscrit en
    avril 2015
    Messages
    310
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Vendée (Pays de la Loire)

    Informations professionnelles :
    Activité : Consultant informatique
    Secteur : Finance

    Informations forums :
    Inscription : avril 2015
    Messages : 310
    Points : 1 528
    Points
    1 528
    Par défaut
    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).

  6. #26
    Membre régulier
    Homme Profil pro
    retraité depuis juin 2019
    Inscrit en
    février 2018
    Messages
    39
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 59
    Localisation : Belgique

    Informations professionnelles :
    Activité : retraité depuis juin 2019
    Secteur : High Tech - Produits et services télécom et Internet

    Informations forums :
    Inscription : février 2018
    Messages : 39
    Points : 123
    Points
    123
    Par défaut 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

  7. #27
    Membre régulier
    Homme Profil pro
    retraité depuis juin 2019
    Inscrit en
    février 2018
    Messages
    39
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 59
    Localisation : Belgique

    Informations professionnelles :
    Activité : retraité depuis juin 2019
    Secteur : High Tech - Produits et services télécom et Internet

    Informations forums :
    Inscription : février 2018
    Messages : 39
    Points : 123
    Points
    123
    Par défaut
    @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.

  8. #28
    Membre expert
    Homme Profil pro
    Futur retraité
    Inscrit en
    octobre 2005
    Messages
    1 451
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 62
    Localisation : France, Seine Saint Denis (Île de France)

    Informations professionnelles :
    Activité : Futur retraité
    Secteur : Finance

    Informations forums :
    Inscription : octobre 2005
    Messages : 1 451
    Points : 3 187
    Points
    3 187
    Par défaut
    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 ...

    Citation Envoyé par schlebe Voir le message
    ...
    En effet, en Cobol, nous disposons de plusieurs types de variable numérique
    PIC 9(4) = chaine de 4 caractères numériques
    Ce format, d'USAGE implicite DISPLAY est réservé à l'affichage et doit être évité pour les calculs


    PIC 9(4) COMP-3 ou PACKAGED
    C'est PACKED et pas PACKAGED et même PACKED-DECIMAL

    Et mieux vaut le coder signé PIC S9(4) PACKED-DECIMAL.

    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.
    BINARY est l'équivalent d'integer en C.

  9. #29
    Membre expérimenté

    Homme Profil pro
    Consultant informatique
    Inscrit en
    avril 2015
    Messages
    310
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Vendée (Pays de la Loire)

    Informations professionnelles :
    Activité : Consultant informatique
    Secteur : Finance

    Informations forums :
    Inscription : avril 2015
    Messages : 310
    Points : 1 528
    Points
    1 528
    Par défaut
    @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 !

  10. #30
    Membre régulier
    Homme Profil pro
    retraité depuis juin 2019
    Inscrit en
    février 2018
    Messages
    39
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 59
    Localisation : Belgique

    Informations professionnelles :
    Activité : retraité depuis juin 2019
    Secteur : High Tech - Produits et services télécom et Internet

    Informations forums :
    Inscription : février 2018
    Messages : 39
    Points : 123
    Points
    123
    Par défaut
    @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.

  11. #31
    Membre expérimenté

    Homme Profil pro
    Consultant informatique
    Inscrit en
    avril 2015
    Messages
    310
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Vendée (Pays de la Loire)

    Informations professionnelles :
    Activité : Consultant informatique
    Secteur : Finance

    Informations forums :
    Inscription : avril 2015
    Messages : 310
    Points : 1 528
    Points
    1 528
    Par défaut @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é...

  12. #32
    Membre expert
    Homme Profil pro
    Futur retraité
    Inscrit en
    octobre 2005
    Messages
    1 451
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 62
    Localisation : France, Seine Saint Denis (Île de France)

    Informations professionnelles :
    Activité : Futur retraité
    Secteur : Finance

    Informations forums :
    Inscription : octobre 2005
    Messages : 1 451
    Points : 3 187
    Points
    3 187
    Par défaut
    Citation Envoyé par TJ1985 Voir le message
    C'est faux ...
    .
    Que d'erreurs, d'approximation, de contre vérités et de légendes urbaines en 15 lignes environ sur COBOL ... Allons y ...


    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.
    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.
    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 ...


    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.
    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.
    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 ).


    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.
    Faux. Archi faux. le format "natif" n'a pas de sens en COBOL.

    .
    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.
    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.


    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.
    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.


    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.
    Pas la peine d'acheter la norme COBOL, toute la documentation COBOL IBM est disponible sur le net gratuitement.


    CQFD.

    PS. Je parle du COBOL Mainframe IBM.

  13. #33
    Expert confirmé
    Avatar de Pyramidev
    Homme Profil pro
    Développeur
    Inscrit en
    avril 2016
    Messages
    1 206
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Val de Marne (Île de France)

    Informations professionnelles :
    Activité : Développeur

    Informations forums :
    Inscription : avril 2016
    Messages : 1 206
    Points : 5 128
    Points
    5 128
    Par défaut
    Citation Envoyé par Luc Orient Voir le message
    Pas la peine d'acheter la norme COBOL, toute la documentation COBOL IBM est disponible sur le net gratuitement.
    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.

  14. #34
    Membre expérimenté

    Homme Profil pro
    Consultant informatique
    Inscrit en
    avril 2015
    Messages
    310
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Vendée (Pays de la Loire)

    Informations professionnelles :
    Activité : Consultant informatique
    Secteur : Finance

    Informations forums :
    Inscription : avril 2015
    Messages : 310
    Points : 1 528
    Points
    1 528
    Par défaut 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.

  15. #35
    Membre expert
    Homme Profil pro
    Futur retraité
    Inscrit en
    octobre 2005
    Messages
    1 451
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 62
    Localisation : France, Seine Saint Denis (Île de France)

    Informations professionnelles :
    Activité : Futur retraité
    Secteur : Finance

    Informations forums :
    Inscription : octobre 2005
    Messages : 1 451
    Points : 3 187
    Points
    3 187
    Par défaut
    Citation Envoyé par Pyramidev Voir le message
    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.
    La dernière version du COBOL IBM Mainframe est la 6.2. La version 4 commence un peu à dater ...

    Tout est

  16. #36
    Modérateur
    Avatar de escartefigue
    Homme Profil pro
    bourreau
    Inscrit en
    mars 2010
    Messages
    7 452
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Loir et Cher (Centre)

    Informations professionnelles :
    Activité : bourreau
    Secteur : Finance

    Informations forums :
    Inscription : mars 2010
    Messages : 7 452
    Points : 24 037
    Points
    24 037
    Billets dans le blog
    2
    Par défaut
    Je complète les propos que j'approuve de Luc Orient

    Citation Envoyé par TJ1985 Voir le message
    Les formats COMP sont apparus tardivement, et n'offrent pas les mêmes avantages en précision de calcul que le format natif.
    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


    Citation Envoyé par TJ1985 Voir le message
    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
    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)

  17. #37
    Expert éminent sénior
    Homme Profil pro
    Ingénieur d'Etude Mainframe/AS400
    Inscrit en
    novembre 2012
    Messages
    1 630
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 40
    Localisation : France, Hauts de Seine (Île de France)

    Informations professionnelles :
    Activité : Ingénieur d'Etude Mainframe/AS400
    Secteur : Finance

    Informations forums :
    Inscription : novembre 2012
    Messages : 1 630
    Points : 10 128
    Points
    10 128
    Par défaut
    Citation Envoyé par escartefigue Voir le message
    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.

  18. #38
    Nouveau membre du Club
    Homme Profil pro
    Ingénieur systèmes et réseaux
    Inscrit en
    septembre 2019
    Messages
    11
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 49
    Localisation : France, Ain (Rhône Alpes)

    Informations professionnelles :
    Activité : Ingénieur systèmes et réseaux
    Secteur : Administration - Collectivité locale

    Informations forums :
    Inscription : septembre 2019
    Messages : 11
    Points : 27
    Points
    27
    Par défaut 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.

  19. #39
    Membre expert
    Homme Profil pro
    Futur retraité
    Inscrit en
    octobre 2005
    Messages
    1 451
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 62
    Localisation : France, Seine Saint Denis (Île de France)

    Informations professionnelles :
    Activité : Futur retraité
    Secteur : Finance

    Informations forums :
    Inscription : octobre 2005
    Messages : 1 451
    Points : 3 187
    Points
    3 187
    Par défaut
    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 ...

    Citation Envoyé par gurkuru Voir le message
    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.
    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.


    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).
    Mais quelles contraintes et limites ? On aimerait savoir.


    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é.
    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.


    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.
    Là l'argument est plutôt recevable.


    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).
    Sur ce plan, IBM et Microfocus, par exemple,ont une offre tout à fait pertinente.


    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.
    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.

  20. #40
    Membre expérimenté

    Homme Profil pro
    Consultant informatique
    Inscrit en
    avril 2015
    Messages
    310
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Vendée (Pays de la Loire)

    Informations professionnelles :
    Activité : Consultant informatique
    Secteur : Finance

    Informations forums :
    Inscription : avril 2015
    Messages : 310
    Points : 1 528
    Points
    1 528
    Par défaut
    Citation Envoyé par Luc Orient Voir le message
    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 ...
    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.

Discussions similaires

  1. Le langage de programmation COBOL a cinquante ans
    Par Pierre Louis Chevalier dans le forum Cobol
    Réponses: 35
    Dernier message: 01/10/2012, 21h02
  2. IBM fête ses 100 ans
    Par Gordon Fowler dans le forum Hardware
    Réponses: 14
    Dernier message: 01/04/2011, 19h40
  3. Le langage de programmation COBOL a cinquante ans
    Par Pierre Louis Chevalier dans le forum Actualités
    Réponses: 12
    Dernier message: 20/09/2009, 19h53
  4. Oracle fête ses 20 ans
    Par Jaouad dans le forum Oracle
    Réponses: 5
    Dernier message: 26/05/2006, 10h11

Partager

Partager
  • Envoyer la discussion sur Viadeo
  • Envoyer la discussion sur Twitter
  • Envoyer la discussion sur Google
  • Envoyer la discussion sur Facebook
  • Envoyer la discussion sur Digg
  • Envoyer la discussion sur Delicious
  • Envoyer la discussion sur MySpace
  • Envoyer la discussion sur Yahoo