Discussion:Cobol

" l'incapacité de définir des variables locales, des fonctions récursives et d'allouer de la mémoire dynamiquement. Son manque de support de la programmation orientée objet est compréhensible, puisque le concept était inconnu à cette époque."

De fait, des fonctions récursives sont possibles avec des programmes inclus, et la programmation avec des objets est standardisé avec la version 2002 et est implementé par plusieurs compilers. --80.128.254.84 7 sep 2004 à 16:05 (CEST)

Cela a été corrigé dans des changements récents. CaféBuzz (discuter) 20 février 2022 à 12:13 (CET)

La regrettée Grace Hopper n'est pas citée.

Elle l'est dans la version actuelle. CaféBuzz (discuter) 20 février 2022 à 12:13 (CET)

COBOL s'écrit en majuscules si on s'en refère au comité ISO, il faudrais renommer la page et faire du rechercher remplacer dans toute la wikipédia. http://www.cobolstandard.info/wg4/standard.html#1989 http://www.iso.org/iso/en/CombinedQueryResult.CombinedQueryResult?queryString=Cobol 26 janvier 2006 à 20:49 (CET)~

Il a été pris la décision (voir plus bas) d'appliquer les règles usuelles concernant les acronymes (majuscule à la première lettre seulement pour un terme de 5 caractères), l'usage en français n'étant semble-t-il pas tranché dans ce cas précis. CaféBuzz (discuter) 20 février 2022 à 12:13 (CET)

Typo, 2002 plutôt que 2003

Le premier paragraphe mentionne le COBOL 2003 qui ne fait pas partie de la liste des standards COBOL. C'est une typo à remplacer par COBOL 2002. Caplan A+ 22 avril 2007 à 01:48(CET)

Cela n'est plus le cas dans la version actuelle. CaféBuzz (discuter) 20 février 2022 à 12:11 (CET)

« À ce jour, il n'existe pas de langage qui pourrait le remplacer »

L’entête du document dit : « À ce jour, il n'existe pas de langage qui pourrait le remplacer [réf. nécessaire] ». Au sujet du « réf. nécessaire » : je ne sais pas de quelle référence il pourrait s’agir, parce que j’imagine mal un texte officielle annoncer sérieusement « à ce jour aucun langage ne peut remplacer COBOL ». Par contre, il y a un fondement à cette affirmation : les nombres réels en point fixe, qui n’existe qu’en Ada et COBOL et dans aucun autre langage (sauf erreur). Cette raison est peut être considérée comme assez bien suffisante. --Hibou57 (d) 4 juin 2010 à 22:07 (CEST)

Ce genre de commentaire me paraît malheureusement guidé par la méconnaissance.

- la notion nombre réel signifie quelque chose de bien précis en mathématiques, qui n'est pas géré par le cobol. L'expression 'nombres entiers en postion décimale fixe' me semble plus exacte. Ceci est important afin d'éviter les confusions.

- cobol standard est limité à 18 chiffres, voire plus chez certains fournisseurs, mais la limite existe.

Comme indiqué dans la documentation de référence, la vraie limite est 31 octets (cela dépend du site, et non du fourmisseur)--Manu (discuter) 25 juillet 2011 à 11:15 (CEST)

- la déclaration du nombre à sa capacité maxi implique un gaspillage de mémoire si l'on utilise autre chose que des quantités proches des valeurs maxi. Y compris dans les fichiers.

- les calculs sont extraordinairement lents comparés même à du langage C.

- la virgule est virtuelle, les calculs internes et les stockages sont réalisés en entiers. Ceci pose problème quand on traite les données depuis le monde extérieur. D'autre part, même si la notion n'existe pas ailleurs, elle peut être émulée de façon triviale en utilisant des entiers divisés par le nombre correct de décimales, soit directement dans les calculs, soit par héritage d'un objet qui va gérer la position décimale, soit encore plus simplement par utilisation d'une classe décimale ayant un comportement équivalent, comme c'est le cas en python par exemple. Le fait que la notion n'existe pas ailleurs est inhérent aux faiblesses du langage, et il est pour le moins tendancieux de présenter cela comme un avantage. On sourirait de qui présenterait la machine à vapeur comme plus perfectionnée que le moteur diesel parce que ce dernier ne peut pas brûler de charbon...

Je suis d'accord avec la première partie du texte de Hibou57. J'ai souvent rencontré des membres du dernier carré des cobolistes, et ce sont souvent des gens qui, incapable de s'ouvrir à autre chose, prétendront jusqu'à leur dernier souffle que le cobol est le meilleur langage qui soit pour programmer.

Quant à la raison qui serait "bien assez suffisante", j'estime que l'argument ne résiste pas à l'examen.

Un exemple : en langage python, le programme ci-après ne s'arrête jamais, et arrive très vite à des nombres de plusieurs centaines de milliers de chiffres. Faire la même chose en cobol relève du fantasme.

i = 2
while True:
    i = i * i
    print i

J'ajouterais qu'on peut faire la même démonstration pour n'importe lequel des aspects du cobol.

Plus sérieusement, ce qui est communément admis, c'est que les outils cobol actuels sont utiles pour conserver les applications existantes. Cet argument est discutable du fait des tarifs démentiels pratiqués par le fournisseur institutionnel, et aussi du fait que la maintenance et l'évolution d'applications coûte de plus en plus cher. Pratiquement à chaque occasion, refaire coûte moins cher sur le long terme.

jmbc - 6-11-2010

— Le message qui précède, non signé, a été déposé par 83.114.252.214 (discuter), le 6 novembre 2010

Il y a du pour et du contre. Il faudrait apporter des bonnes sources, dans un sens comme dans l'autre. D'une part la quantité de code toujours existant en Cobol pose des difficultés de maintenance (manque de développeurs qualifiés, qui ne fait que s'accentuer avec le temps qui passe). D'autre part on a de multiples témoignages de grandes difficultés pour tout réécrire dans d'autres langages (souvent Java), avec un code à la maintenance cauchemardesque et beaucoup plus lent que COBOL dans le traitement de grandes bases de données. Cette page n'est pas un forum, nous ne sommes pas là pour papoter mais pour améliorer l'article, et pour cela la priorité est d'apporter des sources claires et informatives. CaféBuzz (discuter) 20 février 2022 à 12:11 (CET)

Objectivité dela page

A la relecture, la description du langage me paraît très peu objective, comme si elle était issue d'un auteur qui ne connaît aucune autre technique de programmation. jmbc

— Le message qui précède, non signé, a été déposé par l'IP 83.114.252.214 (discuter), le 6 novembre 2010 à 07:21

Critique peu constructive. Donner des exemples, des éléments de preuves, faites des propositions d'améliorations. Votre message remonte à plus de dix ans maintenant, l'article a largement évolué depuis, il n'y a rien qu'on puisse faire concrètement. CaféBuzz (discuter)

Un argument discutable ...

" Plus sérieusement, ce qui est communément admis, c'est que les outils cobol actuels sont utiles pour conserver les applications existantes. Cet argument est discutable du fait des tarifs démentiels pratiqués par le fournisseur institutionnel, et aussi du fait que la maintenance et l'évolution d'applications coûte de plus en plus cher. Pratiquement à chaque occasion, refaire coûte moins cher sur le long terme. "

Cette affimation est tout aussi discutable que l'argument qu'elle est censée réfuter. Son auteur ne démontre rien, ni ne cite aucune étude économique précise qui pourrait en renforcer la crédibilité.

— Le message qui précède, non signé, a été déposé par l'IP 90.3.17.205 (discuter), le 26 mars 2011 à 19:56

Réponse à la phrase précédente : Il n'y a rien à démontrer, le problème de la tarification des outils cobol est une réalité, et le reste de l'argumentation est basé sur 15 ans d'expérience comme consultant chez Microfocus et comme directeur technique pour Acucorp. Le rythme constant avec lequel les développeurs abandonnent le langage cobol est un fait.

J'ajouterais que le passage ou "cobol présente d'excellentes performances pour les traitements par lot et qu'on n'a pas fait mieux depuis" est au mieux très ingénu.

— Le message qui précède, non signé, a été déposé par l'IP 81.252.184.21 (discuter), le 15 avril 2011 à 14:41‎

Réponse à la phrase précédente : le fait d'avoir travaillé chez Microfocus / Acucorp ne me semble pas être un gage évident d'une parfaite objectivité économique. J'ajouterais que, dans l'environnement hyper concurentiel que sont les technologies de l'IT, je ne sais pas ce qu'est un "fournisseur institutionnel".

— Le message qui précède, non signé, a été déposé par l'IP 83.199.214.88 (discuter), le 17 avril 2011 à 08:57

Note ajoutée en réponse à la réponse : le "fournisseur institutionnel" est le seul fournisseur restant, qui fournit 99,9% des licences, et qui est en situation de monopole :-( Par ailleurs, vous avez raison, je ne suis pas forcément évidemment objectif. Et d'ailleurs ces considérations ne sont évidentes que pour ceux qui signent des bons de commande année après année.

Mon intervention initiale était motivée uniquement pour tempérer l'affirmation qui dit que le cobol est le plus performant. Ceci était peut-être vrai il y a 30 ans, à l'époque où Microfocus produisait un générateur optimiseur très bien fait. De nos jours, les optimiseurs des compilateurs C font bien mieux. C'est ce qui a d'ailleurs permis à Acucorp de rattraper Microfocus il y a une dizaine d'années sur le terrain de la rapidité, le cobol acucorp étant écrit en langage C. Les deux fournisseurs ne font plus qu'un depuis déjà plusieurs années, le cobol ne progresse plus depuis cinq ou six ans, et d'autres langages sont passés devant en termes de performances. Qui songerait sérieusement à l'utiliser aujourd'hui pour développer une nouvelle application ? Un programmeur qui ne connaîtrait que cela, et qui refuserait de se remettre en question...

— Le message qui précède, non signé, a été déposé par l'IP 83.114.118.186 (discuter), le 24 juillet 2011 à 17:19

Voir ma réponse ci-dessus (#« À ce jour, il n'existe pas de langage qui pourrait le remplacer »): tout est discutable, mais pas sur la base d'argumentations personnelles. Apportez des sources. CaféBuzz (discuter) 20 février 2022 à 12:11 (CET)

Histoire et spécifications

Ce langage ayant été conçu aux débuts de l'informatique, sa relative complexité rebute nombre de programmeurs de notre époque, ce qui lui a valu deux interprétations ironiques de son acronyme : Compiles Only Because Of Luck (fonctionne uniquement par chance) et Completly Obsolete Business Oriented Language (Langage orienté gestion complètement obsolète)

=> je ne suis personnellement d'accord ni avec les traductions (dont le texte original me parait pertinent) ni d'accord avec le sens que l'on donne à ces propos (du point de vue de mon utilisation professionnelle).

Ce qui rebute c'est (encore une fois un point de vue personnel qui peut se débattre) :

1) lenteur de développement : ce n'est pas un langage rapide à utiliser, les variables sont globales, etc
2) les possibles erreurs qui ne sont pas détectées à la compilation (notamment les erreurs de type de données la gestion des comp-3 par exemple etc)
3) les rapport d'erreurs en cas d'abend qui peuvent s'avérer imbouffables
4) On passe trop de temps à tenter se focaliser sur le code plutôt que sur le fonctionnel

— Le message qui précède, non signé, a été déposé par FKen (discuter), le 9 janvier 2015 à 09:43‎

Voir ma réponse ci-dessus (#« À ce jour, il n'existe pas de langage qui pourrait le remplacer ») ): il faut apporter des sources. CaféBuzz (discuter) 20 février 2022 à 12:11 (CET)

Demande de renommage de COBOL (h • j • ↵ • Ren.) vers Cobol (h • j • ↵)

Discussion copiée depuis Wikipédia:Demande de renommage

Requête acceptée - 14 mars 2019 à 19:32 (CET)

---

• Demandé par : Gkml (discuter) le 7 mars 2019 à 15:28 (CET)
• Justification de la demande : Acronyme (Cobol = Common Business Oriented Language) d'au moins quatre lettres ; cf. WP:TYPO#SIGLES. Notamment aussi comme pour le Fortran (également un acronyme : « Formula Translator »), ou Java (qui n'est pas un acronyme), etc. Aucune raison complémentaire de différenciation. Merci. — Gkml (discuter) 7 mars 2019 à 15:28 (CET)
  P.-S. : pour mémoire, les emplois sont équilibrés dans la littérature francophone ; l'application de nos conventions n'est donc pas susceptible de soulever le moindre problème. — Gkml (discuter) 7 mars 2019 à 16:19 (CET)
• Pour conforme aux conventions. --A1AA1A (discuter) 7 mars 2019 à 22:20 (CET)

Cordialement, Prométhée (discuter) 14 mars 2019 à 19:32 (CET).

.

Utilisation d'une syntaxe spécifique à Micro Focus Cobol

Bonjour,

Sauf erreur de ma part, l'exemple de programme "Bonjour" utilise une syntaxe spécifique de chez Micro Focus et ne reflète pas le Cobol standard. Il ne respecte pas non plus les colonnes. — Le message qui précède, non signé, a été déposé par Syneau (discuter), le 21 septembre 2019 à 16:18 (CEST) Réponse : Il s'agit de cobol 85, accepté par plusieurs compilateurs. Le colonage est optionnel dans cette norme, ce qui permet de dépasser les 72 colonnes

La question est: y a-t-il vraiment un Cobol standard ? Si oui, quelle implémentation en serait la référence ? CaféBuzz (discuter) 20 février 2022 à 12:11 (CET)

Effectivement, je ne sais pas si on peut parler d'un Cobol standard. Ceci étant dit, un développeur muni d'un manuel de koutchouk saura comment écrire du Cobol, que ce soit dans un environnement Mainframe ou dans un environnement qui a supprimé les restrictions héritées des cartes perforées. Si on prend l'exemple de l'étoile en colonne 7, tous les compilateurs savent que c'est une ligne commentaire, c'est, je crois, un standard. Par contre, le commentaire flottant, *>, introduit chez ibm dans la version 6 il me semble, n'est probablement pas un standard. Je suppose qu'on peut faire le même exercice avec les fonctions intrinsèques.

Le cobol respectant les colonnages/zone fonctionnera quelque soit le compilateur, et l'inverse n'est pas vrai. Syneau (discuter) 13 novembre 2022 à 20:14 (CET)

Summary of changes - 2014 + 2023 missing

ISO/IEC 1989:2014 lists:

Significant enhancements in this International Standard include:

• Dynamic-capacity tables
• Dynamic-length elementary items
• Enhanced locale support in functions
• Function pointers
• Increased size limit on alphanumeric, boolean, and national literals
• Parametric polymorphism (also known as method overloading)
• Structured constants
• Support for industry-standard arithmetic rules
• Support for industry-standard date and time formats
• Support for industry-standard floating-point formats
• Support for multiple rounding options

---

ISO/IEC 1989:2023 lists in its foreword (copied from the final Working Draft):

The main changes are as follows:

The following were general enhancements:

• An asynchronous messaging facility using the SEND statement and RECEIVE statement
• Boolean exclusive or operators
• Boolean shifting operators
• COBOL words may now be 63 characters long
• The PERFORM CONTINUE statement has been enhanced to specify a time period for pausing the program
• A DELETE FILE statement
• A nonfatal EC-I-O-WARNING exception condition to handle warnings for successful input-output statements
• EXTERNAL attributes checking between programs
• Infinite loop for the PERFORM statement using the UNTIL EXIT phrase— Inline exception handling using the exception-checking format of the PERFORM statement
• An Enhanced INSPECT statement to inspect backwards
• Line Sequential file organization
• The SET statement has been enhanced to allow the setting of the length of a dynamic length elementary item
• Alternate key suppression on indexed files using the SUPPRESS WHEN phrase of the ALTERNATE RECORD KEY clause
• An optional Commit and rollback processing facility using the COMMIT statement and ROLLBACK statement
• Unsigned Packed-Decimal items defined by the NO SIGN phrase of the USAGE clause
• User-defined PICTURE clause editing using the EDITING phrase of the PICTURE clause
• VALUE clause enhancements and changes for numeric-edited items
• Type declarations may now be external items

The following intrinsic functions were added or enhanced:

• BASECONVERT function
• CONCAT function
• CONVERT function
• EXCEPTION-FILE function and EXCEPTION-FILE-N function
• FIND-STRING function
• MODULE-NAME function
• SMALLEST-ALGEBRAIC function
• SUBSTITUTE function
• TRIM function

Additional compiler directives were added:

• COBOL-WORDS directive
• DISPLAY directive
• FLAG-14 directive
• POP directive
• PUSH directive
• REF-MOD-ZERO-LENGTH directive

McShark (discuter) 20 novembre 2023 à 12:04 (CET)