COBOL- _COBOL

COBOL

Le rapport COBOL 60 à CODASYL (avril 1960)
Paradigme	Procédure , impératif , orienté objet , générique
Conçu par	Howard Bromberg , Norman Discount , Vernon Reeves , Jean E. Sammet , William Selden , Gertrude Tierney , avec une influence indirecte de Grace Hopper
Développeurs	CODASYL , ANSI , ISO / CEI
Première apparition	1959 ; il y a 64 ans ( 1959 )
Version stable	ISO/CEI 1989:2023 / 2023
Discipline de frappe	Faible , statique
Extensions de nom de fichier	.cbl, .cob,.cpy
Principales implémentations
GnuCOBOL , IBM COBOL , Micro Focus Visual COBOL
Dialectes
COBOL/2, DEC COBOL-10, DEC PDP-11 COBOL, DEC PDP-11 COBOL-85, DEC VAX COBOL, DOSVS COBOL, Envyr ICOBOL, Fujitsu COBOL, Hitachi COBOL2002, HP3000 COBOL/II, IBM COBOL SAA, IBM COBOL /400, IBM COBOL/II, IBM Enterprise COBOL, IBM ILE COBOL, IBM OS/VS COBOL, ICL COBOL (VME), Micro Focus ACUCOBOL-GT, Micro Focus COBOL-IT, Micro Focus RM/COBOL, Micro Focus Visual COBOL , Microsoft COBOL, Raincode COBOL, Realia COBOL, Ryan McFarland RM/COBOL, Ryan McFarland RM/COBOL-85, Tandem (NonStop) COBOL, Tandem (NonStop) SCOBOL, UNIVAC COBOL, Unisys MCP COBOL74, Unisys MCP COBOL85, Unix COBOL X /Open, Veryant est COBOL, Wang VS COBOL
Influencé par
Initial : AIMACO , COMTRAN , FACT , FLOW-MATIC COBOL 2002 : C++ , Eiffel , Smalltalk
Influencé
CobolScript , EGL , PL/I , PL/B
COBOL sur Wikibooks

COBOL ( / ˈ k oʊ b ɒ l , - b ɔː l / ; un acronyme pour « common business oriented language ») est un langage de programmation informatique compilé de type anglais conçu pour une utilisation professionnelle. C'est un langage impératif , procédural et, depuis 2002, orienté objet . COBOL est principalement utilisé dans les systèmes commerciaux, financiers et administratifs des entreprises et des gouvernements. COBOL est encore largement utilisé dans les applications déployées sur les ordinateurs centraux , telles que les tâches de traitement par lots et transactionnelles à grande échelle . Cependant, en raison de sa popularité décroissante et du départ à la retraite de programmeurs COBOL expérimentés, les programmes sont migrés vers de nouvelles plates-formes, réécrits dans des langages modernes ou remplacés par des progiciels. La majeure partie de la programmation en COBOL consiste désormais uniquement à maintenir les applications existantes ; cependant, de nombreuses grandes institutions financières développaient encore de nouveaux systèmes en COBOL jusqu'en 2006.

COBOL a été conçu en 1959 par CODASYL et était en partie basé sur le langage de programmation FLOW-MATIC conçu par Grace Hopper . Il a été créé dans le cadre d'un effort du département américain de la Défense pour créer un langage de programmation portable pour le traitement des données. Il était à l'origine considéré comme un palliatif, mais le ministère de la Défense a rapidement forcé les fabricants d'ordinateurs à le fournir, ce qui a entraîné son adoption généralisée. Il a été normalisé en 1968 et a depuis été révisé quatre fois. Les extensions incluent la prise en charge de la programmation structurée et orientée objet . La norme actuelle est ISO / CEI 1989:2014 .

Les instructions COBOL ont une syntaxe de type anglais, qui a été conçue pour être auto-documentée et très lisible. Cependant, il est verbeux et utilise plus de 300 mots réservés . Contrairement à la syntaxe moderne et succincte comme , COBOL a une syntaxe plus proche de l'anglais (dans ce cas, ). y = x;MOVE x TO y

Le code COBOL est divisé en quatre divisions (identification, environnement, données et procédure) contenant une hiérarchie rigide de sections, paragraphes et phrases. Faute d'une grande bibliothèque standard , la norme spécifie 43 instructions, 87 fonctions et une seule classe.

Les informaticiens universitaires n'étaient généralement pas intéressés par les applications métier lorsque COBOL a été créé et n'ont pas été impliqués dans sa conception ; il a été (en fait) conçu dès le départ comme un langage informatique pour les entreprises, en mettant l'accent sur les entrées et les sorties, dont les seuls types de données étaient des nombres et des chaînes de texte.

COBOL a été critiqué tout au long de sa vie pour sa verbosité, son processus de conception et sa mauvaise prise en charge de la programmation structurée . Ces faiblesses se traduisent par des programmes monolithiques et verbeux (destinés à ressembler à l'anglais) qui ne sont pas facilement compréhensibles.

Pendant des années, COBOL a été considéré comme un langage de programmation pour les opérations commerciales dans les mainframes, bien que ces dernières années, un intérêt croissant ait augmenté pour la migration des opérations COBOL vers le cloud computing .

Histoire et spécifications

Arrière-plan

À la fin des années 1950, les utilisateurs et les fabricants d'ordinateurs s'inquiétaient de l'augmentation du coût de la programmation. Une enquête de 1959 avait révélé que dans toute installation de traitement de données, la programmation coûtait en moyenne 800 000 $ US et que la traduction des programmes pour qu'ils s'exécutent sur du nouveau matériel coûterait 600 000 $. À une époque où les nouveaux langages de programmation proliféraient à un rythme de plus en plus rapide, la même enquête suggérait que si un langage commun orienté métier était utilisé, la conversion serait beaucoup moins chère et plus rapide.

Le 8 avril 1959, Mary K. Hawes , une informaticienne de la Burroughs Corporation , a convoqué une réunion de représentants du milieu universitaire, d'utilisateurs d'ordinateurs et de fabricants de l' Université de Pennsylvanie pour organiser une réunion formelle sur les langages commerciaux courants. Les représentants comprenaient Grace Hopper (inventeur du langage informatique de type anglais FLOW-MATIC ), Jean Sammet et Saul Gorn .

Lors de la réunion d'avril, le groupe a demandé au ministère de la Défense (DoD) de parrainer un effort visant à créer un langage commercial commun. La délégation a impressionné Charles A. Phillips, directeur de l'équipe de recherche sur les systèmes de données au DoD, qui a pensé qu'ils "comprenaient parfaitement" les problèmes du DoD. Le DoD exploitait 225 ordinateurs, en avait commandé 175 autres et avait dépensé plus de 200 millions de dollars pour mettre en œuvre des programmes à exécuter dessus. Les programmes portables permettraient de gagner du temps, de réduire les coûts et de faciliter la modernisation.

Charles Phillips a accepté de parrainer la réunion et a chargé la délégation de rédiger l'ordre du jour.

COBOL 60

Les 28 et 29 mai 1959 (exactement un an après la réunion Zürich ALGOL 58 ), une réunion a eu lieu au Pentagone pour discuter de la création d'un langage de programmation commun pour les entreprises. Il a réuni 41 personnes et était présidé par Phillips. Le ministère de la Défense se demandait s'il pouvait exécuter les mêmes programmes de traitement de données sur différents ordinateurs. FORTRAN , le seul langage courant à l'époque, ne disposait pas des fonctionnalités nécessaires pour écrire de tels programmes.

Les représentants ont décrit avec enthousiasme un langage qui pourrait fonctionner dans une grande variété d'environnements, de la banque et de l'assurance aux services publics et au contrôle des stocks. Ils ont convenu à l'unanimité que davantage de personnes devraient pouvoir programmer et que le nouveau langage ne devrait pas être limité par les limites de la technologie contemporaine. Une majorité a convenu que la langue devrait utiliser au maximum l'anglais, être capable de changer, être indépendante de la machine et être facile à utiliser, même au détriment du pouvoir.

La rencontre a abouti à la création d'un comité de pilotage et de comités à court, moyen et long terme. Le comité de courte durée s'est donné à septembre (trois mois) pour produire un cahier des charges pour une langue provisoire, qui serait ensuite améliorée par les autres comités. Leur mission officielle, cependant, était d'identifier les forces et les faiblesses des langages de programmation existants et ne leur demandait pas explicitement de créer un nouveau langage.

Le délai a été respecté avec incrédulité par le comité à court terme. Un membre, Betty Holberton , a décrit le délai de trois mois comme un "optimisme grossier" et a douté que la langue soit vraiment un palliatif.

Le comité directeur s'est réuni le 4 juin et a convenu de nommer l'ensemble de l'activité sous le nom de Comité sur les langages des systèmes de données , ou CODASYL , et de former un comité exécutif.

Les membres à court terme du comité représentaient six fabricants d'ordinateurs et trois agences gouvernementales. Les fabricants d'ordinateurs étaient Burroughs Corporation , IBM , Minneapolis-Honeywell (Honeywell Labs), RCA , Sperry Rand et Sylvania Electric Products . Les agences gouvernementales étaient l' US Air Force , le David Taylor Model Basin de la Marine et le National Bureau of Standards (aujourd'hui le National Institute of Standards and Technology). Le comité était présidé par Joseph Wegstein du National Bureau of Standards des États-Unis. Les travaux ont commencé par une enquête sur la description des données, les déclarations, les applications existantes et les expériences des utilisateurs.

Le comité a principalement examiné les langages de programmation FLOW-MATIC , AIMACO et COMTRAN . Le langage FLOW-MATIC a été particulièrement influent parce qu'il avait été implémenté et parce qu'AIMACO en était un dérivé avec seulement des modifications mineures. L'inventeur de FLOW-MATIC, Grace Hopper, a également servi de conseiller technique au comité. Les principales contributions de FLOW-MATIC à COBOL étaient les longs noms de variables, les mots anglais pour les commandes et la séparation des descriptions de données et des instructions.

Hopper est parfois appelée "la mère de COBOL" ou "la grand-mère de COBOL", bien que Jean Sammet , un concepteur principal de COBOL, ait déclaré que Hopper "n'était pas la mère, le créateur ou le développeur de Cobol".

Le langage COMTRAN d'IBM, inventé par Bob Bemer , était considéré comme un concurrent de FLOW-MATIC par un comité de courte portée composé de collègues de Grace Hopper. Certaines de ses fonctionnalités n'ont pas été incorporées dans COBOL afin qu'il ne semble pas qu'IBM ait dominé le processus de conception, et Jean Sammet a déclaré en 1981 qu'il y avait eu un "fort parti pris anti-IBM" de la part de certains membres du comité (elle-même incluse). Dans un cas, après que Roy Goldfinger, auteur du manuel COMTRAN et membre du comité à portée intermédiaire, ait assisté à une réunion du sous-comité pour soutenir son langage et encourager l'utilisation d'expressions algébriques, Grace Hopper a envoyé une note au comité à courte portée réitérant les propos de Sperry Rand. efforts pour créer une langue basée sur l'anglais.

En 1980, Grace Hopper a déclaré que "COBOL 60 est à 95% FLOW-MATIC" et que COMTRAN avait eu une influence "extrêmement faible". En outre, elle a déclaré qu'elle prétendrait que le travail était influencé à la fois par FLOW-MATIC et COMTRAN uniquement pour "rendre les autres heureux [afin qu'ils] n'essaient pas de nous assommer".

Les fonctionnalités de COMTRAN incorporées dans COBOL comprenaient des formules, la PICTUREclause , une instruction améliorée IF, qui évitait le besoin de GO TO , et un système de gestion de fichiers plus robuste.

L'utilité des travaux du comité a fait l'objet d'un grand débat. Alors que certains membres pensaient que le libellé comportait trop de compromis et était le résultat d' une conception par un comité , d'autres estimaient qu'il était meilleur que les trois langages examinés. Certains estimaient que le langage était trop complexe ; d'autres, trop simples.

Les fonctionnalités controversées comprenaient celles que certains considéraient comme inutiles ou trop avancées pour les utilisateurs de traitement de données. Ces fonctionnalités comprenaient des expressions booléennes , des formules et des indices de table (indices). Un autre point de controverse était de savoir s'il fallait rendre les mots clés contextuels et l'effet que cela aurait sur la lisibilité. Bien que les mots clés contextuels aient été rejetés, l'approche a ensuite été utilisée en PL/I et partiellement en COBOL à partir de 2002. Peu d'attention a été accordée à l'interactivité , à l'interaction avec les systèmes d'exploitation (peu existaient à l'époque) et aux fonctions (considérées comme purement mathématiques). et sans utilité dans le traitement des données).

Le cahier des charges a été présenté au comité exécutif le 4 septembre. Ils n'ont pas répondu aux attentes: Joseph Wegstein a noté qu '"il contient des aspérités et nécessite quelques ajouts", et Bob Bemer les a décrits plus tard comme un " méli-mélo ". Le sous-comité a eu jusqu'en décembre pour l'améliorer.

Lors d'une réunion à la mi-septembre, le comité a discuté du nom de la nouvelle langue. Les suggestions comprenaient "BUSY" (Business System), "INFOSYL" (Information System Language) et "COCOSYL" (Common Computer Systems Language). On ne sait pas qui a inventé le nom "COBOL", bien que Bob Bemer ait affirmé plus tard que c'était sa suggestion.

En octobre, le comité de la gamme intermédiaire a reçu des copies de la spécification du langage FACT créée par Roy Nutt . Ses fonctionnalités ont tellement impressionné le comité qu'il a adopté une résolution pour baser COBOL dessus.

Ce fut un coup dur pour le comité courte portée, qui avait bien avancé sur le cahier des charges. Bien qu'il soit techniquement supérieur, FACT n'a pas été créé dans un souci de portabilité ou par consensus entre fabricants et utilisateurs. Il manquait également une implémentation démontrable, permettant aux partisans d'un COBOL basé sur FLOW-MATIC d'annuler la résolution. Le représentant de RCA, Howard Bromberg, a également bloqué FACT, afin que le travail de RCA sur une implémentation COBOL ne soit pas gâché.

Il est vite devenu évident que le comité était trop grand pour que d'autres progrès puissent être réalisés rapidement. Un Howard Bromberg frustré a acheté une pierre tombale de 15 $ avec "COBOL" gravé dessus et l'a envoyée à Charles Phillips pour démontrer son mécontentement.

Un sous-comité a été formé pour analyser les langues existantes et était composé de six personnes :

• William Selden et Gertrude Tierney d'IBM,
• Howard Bromberg et Howard Discount de RCA,
• Vernon Reeves et Jean E. Sammet de Sylvania Electric Products.

Le sous-comité a effectué la majeure partie du travail de création de la spécification, laissant au comité à court terme le soin d'examiner et de modifier son travail avant de produire la spécification finale.

Les spécifications ont été approuvées par le comité exécutif le 8 janvier 1960 et envoyées à l'imprimerie gouvernementale, qui les a imprimées en COBOL 60 . Les objectifs déclarés du langage étaient de permettre l'écriture facile de programmes efficaces et portables, de permettre aux utilisateurs de passer à de nouveaux systèmes avec un minimum d'efforts et de coûts, et de convenir aux programmeurs inexpérimentés.

Le comité exécutif de CODASYL a ensuite créé le comité de maintenance COBOL pour répondre aux questions des utilisateurs et des fournisseurs et pour améliorer et étendre les spécifications.

Au cours de 1960, la liste des fabricants prévoyant de construire des compilateurs COBOL s'est allongée. En septembre, cinq autres fabricants avaient rejoint CODASYL ( Bendix , Control Data Corporation , General Electric (GE), National Cash Register et Philco ), et tous les fabricants représentés avaient annoncé des compilateurs COBOL. GE et IBM prévoyaient d'intégrer COBOL dans leurs propres langages, GECOM et COMTRAN, respectivement. En revanche, International Computers and Tabulators prévoyait de remplacer son langage, CODEL, par COBOL.

Pendant ce temps, RCA et Sperry Rand ont travaillé sur la création de compilateurs COBOL. Le premier programme COBOL a fonctionné le 17 août sur un RCA 501. Les 6 et 7 décembre, le même programme COBOL (bien qu'avec des modifications mineures) a fonctionné sur un ordinateur RCA et un ordinateur Remington-Rand Univac, démontrant que la compatibilité pouvait être obtenue .

Les influences relatives des langages utilisés se poursuivent à ce jour dans l'avis recommandé imprimé dans tous les manuels de référence COBOL :

COBOL est un langage industriel et n'est pas la propriété d'une entreprise ou d'un groupe d'entreprises, ou d'une organisation ou d'un groupe d'organisations.

Aucune garantie, expresse ou implicite, n'est donnée par un contributeur ou par le comité CODASYL COBOL quant à l'exactitude et au fonctionnement du système et du langage de programmation. De plus, aucune responsabilité n'est assumée par un contributeur, ou par le comité, à cet égard. Les auteurs et les détenteurs des droits d'auteur du matériel protégé par le droit d'auteur utilisé ici sont les suivants :

FLOW-MATIC (marque déposée d' Unisys Corporation ), Programmation pour UNIVAC (R) I et II, Data Automation Systems, copyright 1958, 1959, par Unisys Corporation ; IBM Commercial Translator Form No. F28-8013, protégé par copyright 1959 par IBM ; FACT, DSI 27A5260-2760, copyright 1960 par Minneapolis-Honeywell.

Ils ont expressément autorisé l'utilisation de ce matériel, en tout ou en partie, dans les spécifications COBOL. Cette autorisation s'étend à la reproduction et à l'utilisation des spécifications COBOL dans les manuels de programmation ou publications similaires.

COBOL-61 à COBOL-65

De nombreuses failles logiques ont été trouvées dans COBOL 60 , ce qui a conduit Charles Katz de General Electric à avertir qu'il ne pouvait pas être interprété sans ambiguïté. Un comité à court terme réticent a décrété un nettoyage total et, en mars 1963, il a été signalé que la syntaxe de COBOL était aussi définissable que celle d' ALGOL , bien que des ambiguïtés sémantiques subsistaient .

COBOL est un langage difficile pour lequel écrire un compilateur, en raison de la grande syntaxe et des nombreux éléments facultatifs dans les constructions syntaxiques ainsi que de la nécessité de générer un code efficace pour un langage avec de nombreuses représentations de données possibles, des conversions de types implicites et des ensembles nécessaires. ups pour les opérations d'E/S. Les premiers compilateurs COBOL étaient primitifs et lents. Une évaluation de la marine américaine de 1962 a révélé des vitesses de compilation de 3 à 11 déclarations par minute. Au milieu de 1964, ils étaient passés à 11 à 1 000 déclarations par minute. Il a été observé que l'augmentation de la mémoire augmenterait considérablement la vitesse et que les coûts de compilation variaient énormément : les coûts par relevé se situaient entre 0,23 $ et 18,91 $.

À la fin de 1962, IBM a annoncé que COBOL serait leur principal langage de développement et que le développement de COMTRAN cesserait.

La spécification COBOL a été révisée trois fois au cours des cinq années suivant sa publication. COBOL-60 a été remplacé en 1961 par COBOL-61. Cela a ensuite été remplacé par les spécifications étendues COBOL-61 en 1963, qui ont introduit les fonctionnalités de tri et d'écriture de rapports. Les installations ajoutées ont corrigé les défauts identifiés par Honeywell à la fin de 1959 dans une lettre au comité à courte portée. COBOL Edition 1965 a apporté des précisions supplémentaires aux spécifications et introduit des fonctionnalités de gestion des fichiers et des tables de stockage de masse .

COBOL-68

Des efforts ont commencé à standardiser COBOL pour surmonter les incompatibilités entre les versions. À la fin de 1962, l'ISO et l'Institut de normalisation des États-Unis d'Amérique (aujourd'hui ANSI ) ont formé des groupes pour créer des normes. L'ANSI a produit la norme américaine COBOL X3.23 en août 1968, qui est devenue la pierre angulaire des versions ultérieures. Cette version était connue sous le nom de COBOL American National Standard (ANS) et a été adoptée par l'ISO en 1972.

COBOL-74

En 1970, COBOL était devenu le langage de programmation le plus utilisé au monde.

Indépendamment du comité ANSI, le comité du langage de programmation CODASYL travaillait à l'amélioration du langage. Ils ont décrit de nouvelles versions en 1968, 1969, 1970 et 1973, y compris des modifications telles que de nouvelles fonctionnalités de communication inter-programmes, de débogage et de fusion de fichiers, ainsi que des fonctionnalités améliorées de gestion des chaînes et d'inclusion de bibliothèques .

Bien que CODASYL soit indépendant du comité ANSI, le CODASYL Journal of Development a été utilisé par l'ANSI pour identifier les fonctionnalités suffisamment populaires pour justifier leur mise en œuvre. Le comité des langages de programmation a également assuré la liaison avec l'ECMA et le comité japonais COBOL Standard.

Le comité du langage de programmation n'était cependant pas bien connu. Le vice-président, William Rinehuls, s'est plaint que les deux tiers de la communauté COBOL ne connaissaient pas l'existence du comité. Il manquait également de fonds pour rendre les documents publics, tels que les procès-verbaux des réunions et les propositions de changement, librement accessibles.

En 1974, l'ANSI a publié une version révisée de (ANS) COBOL, contenant de nouvelles fonctionnalités telles que les organisations de fichiers , la DELETEdéclaration et le module de segmentation . Les fonctionnalités supprimées comprenaient l' NOTEinstruction, l' EXAMINEinstruction (qui a été remplacée par INSPECT) et le module d'accès aléatoire défini par l'implémenteur (qui a été remplacé par les nouveaux modules d'E/S séquentiels et relatifs). Celles-ci constituaient 44 modifications, qui rendaient les déclarations existantes incompatibles avec la nouvelle norme. Le rédacteur du rapport devait être supprimé de COBOL, mais il a été réintégré avant la publication de la norme. L'ISO a ensuite adopté la norme mise à jour en 1978.

COBOL-85

En juin 1978, les travaux ont commencé sur la révision de COBOL-74. La norme proposée (communément appelée COBOL-80) différait considérablement de la précédente, ce qui suscitait des inquiétudes concernant l'incompatibilité et les coûts de conversion. En janvier 1981, Joseph T. Brophy, vice-président principal de Travelers Insurance, a menacé de poursuivre le comité de normalisation parce qu'il n'était pas compatible avec COBOL-74. M. Brophy a décrit les conversions précédentes de leur base de code de 40 millions de lignes comme "non productives" et un "gaspillage complet de nos ressources de programmation". Plus tard cette année-là, la Data Processing Management Association (DPMA) a déclaré qu'elle était "fermement opposée" à la nouvelle norme, citant des coûts de conversion "prohibitifs" et des améliorations "obligées à l'utilisateur".

Au cours de la première période d'examen public, le comité a reçu 2 200 réponses, dont 1 700 étaient des lettres types négatives. D'autres réponses ont été des analyses détaillées de l'effet que COBOL-80 aurait sur leurs systèmes ; les coûts de conversion devaient être d'au moins 50 cents par ligne de code. Moins d'une douzaine de réponses étaient en faveur de la norme proposée.

L'ISO TC97-SC5 a installé en 1979 le groupe international d'experts COBOL, à l'initiative de Wim Ebbinkhuijsen . Le groupe était composé d'experts COBOL de nombreux pays, dont les États-Unis. Son objectif était de parvenir à une compréhension et un respect mutuels entre l'ANSI et le reste du monde en ce qui concerne le besoin de nouvelles fonctionnalités COBOL. Après trois ans, l'ISO a changé le statut du groupe en un groupe de travail formel : WG 4 COBOL . Le groupe s'est principalement approprié et a développé la norme COBOL, où l'ANSI a fait la plupart des propositions.

En 1983, la DPMA a retiré son opposition à la norme, invoquant la réactivité du comité aux préoccupations du public. La même année, une étude du Bureau national des normes a conclu que la norme proposée poserait peu de problèmes. Un an plus tard, DEC a publié un VAX / VMS COBOL-80 et a noté que la conversion des programmes COBOL-74 posait peu de problèmes. Les nouveaux EVALUATEinstructions et inline PERFORMont été particulièrement bien accueillis et ont amélioré la productivité, grâce à un flux de contrôle et un débogage simplifiés .

Le deuxième examen public a attiré 1 000 autres réponses (principalement négatives), tandis que le dernier n'en a attiré que 25, date à laquelle de nombreuses préoccupations avaient été résolues.

En 1985, le groupe de travail 4 de l'ISO a accepté la version de l'époque de la norme proposée par l'ANSI, a apporté plusieurs modifications et l'a définie comme la nouvelle norme ISO COBOL 85. Elle a été publiée à la fin de 1985.

Soixante fonctionnalités ont été modifiées ou obsolètes et 115 ont été ajoutées, telles que :

• Terminateurs de portée ( END-IF, END-PERFORM, END-READ, etc.)
• Sous-programmes imbriqués
• CONTINUE, une instruction de non-opération
• EVALUATE, une instruction switch
• INITIALIZE, une instruction qui peut définir des groupes de données sur leurs valeurs par défaut
• Corps de boucle en ligne PERFORM- auparavant, les corps de boucle devaient être spécifiés dans une procédure distincte
• Modification de référence, qui permet d'accéder aux sous-chaînes
• Codes d'état des E/S.

La nouvelle norme a été adoptée par tous les organismes nationaux de normalisation, y compris l'ANSI.

Deux modifications ont suivi en 1989 et 1993, la première introduisant des fonctions intrinsèques et l'autre apportant des corrections.

COBOL 2002 et COBOL orienté objet

En 1997, Gartner Group estimait qu'il existait un total de 200 milliards de lignes de COBOL, qui exécutaient 80 % de tous les programmes commerciaux.

Au début des années 1990, les travaux ont commencé sur l'ajout de l'orientation objet dans la prochaine révision complète de COBOL. Les fonctionnalités orientées objet ont été empruntées à C++ et Smalltalk .

L'estimation initiale était d'avoir cette révision achevée en 1997, et un projet de comité ISO (CD) était disponible en 1997. Certains fournisseurs (dont Micro Focus , Fujitsu et IBM ) ont introduit une syntaxe orientée objet basée sur des ébauches de la révision complète. La norme ISO approuvée finale a été approuvée et publiée fin 2002.

Fujitsu/GTSoftware, Micro Focus et RainCode ont introduit des compilateurs COBOL orientés objet ciblant le .NET Framework .

Il y avait beaucoup d'autres nouvelles fonctionnalités, dont beaucoup figuraient dans le CODASYL COBOL Journal of Development depuis 1978 et avaient raté l'occasion d'être incluses dans COBOL-85. Ces autres fonctionnalités comprenaient :

• Code de forme libre
• Fonctions définies par l'utilisateur
• Récursivité
• Traitement basé sur les paramètres régionaux
• Prise en charge des jeux de caractères étendus tels que Unicode
• Types de données à virgule flottante et binaires (jusque-là, les éléments binaires étaient tronqués en fonction de la spécification en base 10 de leur déclaration )
• Résultats arithmétiques portables
• Types de données bit et booléen
• Pointeurs et syntaxe pour obtenir et libérer de l'espace de stockage
• Le SCREEN SECTIONpour les interfaces utilisateur textuelles
• L' VALIDATEétablissement
• Interopérabilité améliorée avec d'autres langages de programmation et environnements de framework tels que .NET et Java .

Trois corrigenda ont été publiés pour la norme : deux en 2006 et un en 2009.

COBOL 2014

Entre 2003 et 2009, trois rapports techniques ont été produits décrivant la finalisation d'objets , le traitement XML et les classes de collection pour COBOL.

COBOL 2002 souffrait d'un support médiocre : aucun compilateur ne supportait complètement la norme. Micro Focus a constaté que cela était dû à un manque de demande des utilisateurs pour les nouvelles fonctionnalités et à l'abolition de la suite de tests NIST , qui avait été utilisée pour tester la conformité du compilateur. Le processus de normalisation s'est également avéré être lent et manquer de ressources.

COBOL 2014 inclut les modifications suivantes :

• Les résultats arithmétiques portables ont été remplacés par les types de données IEEE 754
• Les principales fonctionnalités ont été rendues facultatives, telles que l' VALIDATEinstallation, l'éditeur de rapport et l'installation de gestion d'écran
• Surcharge de méthode
• Tables de capacité dynamiques (une fonctionnalité supprimée du projet de COBOL 2002)

Héritage

Les programmes COBOL sont utilisés dans le monde entier dans les gouvernements et les entreprises et s'exécutent sur divers systèmes d'exploitation tels que z/OS , z/VSE , VME , Unix , NonStop OS, OpenVMS et Windows . En 1997, le groupe Gartner a signalé que 80 % des activités mondiales fonctionnaient sur COBOL avec plus de 200 milliards de lignes de code et 5 milliards de lignes supplémentaires écrites chaque année.

Vers la fin du 20e siècle, le problème de l'an 2000 (Y2K) a fait l'objet d'importants efforts de programmation COBOL, parfois par les mêmes programmeurs qui avaient conçu les systèmes des décennies auparavant. Le niveau d'effort particulier requis pour corriger le code COBOL a été attribué à la grande quantité de COBOL orienté métier, car les applications métier utilisent fortement les dates, et aux champs de données de longueur fixe. Certaines études attribuent jusqu'à "24 % des coûts de réparation des logiciels Y2K à Cobol". Après l'effort de nettoyage mis dans ces programmes pour l'an 2000, une enquête de 2003 a révélé que beaucoup restaient en usage. Les auteurs ont déclaré que les données de l'enquête suggèrent "un déclin progressif de l'importance de COBOL dans le développement d'applications au cours des 10 années [suivantes] à moins que ... l'intégration avec d'autres langages et technologies ne puisse être adoptée".

En 2006 et 2012, les enquêtes de Computerworld (sur 352 lecteurs) ont révélé que plus de 60 % des organisations utilisaient COBOL (plus que C++ et Visual Basic .NET ) et que pour la moitié d'entre elles, COBOL était utilisé pour la majorité de leurs logiciels internes. 36 % des managers ont déclaré qu'ils prévoyaient de migrer depuis COBOL, et 25 % ont déclaré qu'ils aimeraient le faire si c'était moins cher. Au lieu de cela, certaines entreprises ont migré leurs systèmes de mainframes coûteux vers des systèmes moins chers et plus modernes, tout en conservant leurs programmes COBOL.

Un témoignage devant la Chambre des représentants en 2016 a indiqué que COBOL est toujours utilisé par de nombreuses agences fédérales. Reuters a rapporté en 2017 que 43 % des systèmes bancaires utilisaient encore COBOL avec plus de 220 milliards de lignes de code COBOL en cours d'utilisation.

En 2019, le nombre de programmeurs COBOL diminuait rapidement en raison des départs à la retraite, entraînant un déficit imminent de compétences dans les entreprises et les organisations gouvernementales qui utilisent encore des systèmes mainframe pour le traitement des transactions à volume élevé. Les efforts pour réécrire les systèmes dans des langages plus récents se sont avérés coûteux et problématiques, tout comme l'externalisation de la maintenance du code, c'est pourquoi des propositions visant à former davantage de personnes au COBOL sont préconisées.

Pendant la pandémie de COVID-19 et la flambée du chômage qui a suivi, plusieurs États américains ont signalé une pénurie de programmeurs COBOL qualifiés pour prendre en charge les anciens systèmes utilisés pour la gestion des allocations de chômage. Bon nombre de ces systèmes étaient en cours de conversion vers des langages de programmation plus modernes avant la pandémie, mais le processus a été suspendu. De même, l' Internal Revenue Service des États-Unis s'est empressé de corriger son fichier maître individuel basé sur COBOL afin de verser les dizaines de millions de paiements mandatés par le Coronavirus Aid, Relief, and Economic Security Act .

Caractéristiques

Syntaxe

COBOL a une syntaxe de type anglais, qui est utilisée pour décrire presque tout dans un programme. Par exemple, une condition peut être exprimée sous la forme   ou de manière plus concise sous la     forme ou   . Des conditions plus complexes peuvent être "abrégées" en supprimant des conditions et des variables répétées. Par exemple,     peut être raccourci en . Pour prendre en charge cette syntaxe de type anglais, COBOL a plus de 300 mots-clés . Certains des mots-clés sont de simples orthographes alternatives ou pluralisées du même mot, ce qui fournit des déclarations et des clauses plus proches de l'anglais; par exemple, les mots clés et peuvent être utilisés de manière interchangeable, tout comme et , et et . x IS GREATER THAN yx GREATER yx > ya > b AND a > c OR a = da > b AND c OR = dINOFTIMETIMESVALUEVALUES

Chaque programme COBOL est composé de quatre éléments lexicaux de base : des mots, des littéraux, des chaînes de caractères image (voir § Clause PICTURE ) et des séparateurs. Les mots incluent des mots réservés et des identificateurs définis par l'utilisateur. Ils comportent jusqu'à 31 caractères et peuvent inclure des lettres, des chiffres, des traits d'union et des traits de soulignement. Les littéraux incluent les chiffres (par exemple 12) et les chaînes (par exemple 'Hello!'). Les séparateurs incluent le caractère espace et les virgules et points-virgules suivis d'un espace.

Un programme COBOL est divisé en quatre divisions : la division identification, la division environnement, la division données et la division procédure. La division d'identification spécifie le nom et le type de l'élément source et c'est là que les classes et les interfaces sont spécifiées. La division d'environnement spécifie toutes les fonctionnalités du programme qui dépendent du système qui l'exécute, telles que les fichiers et les jeux de caractères . La division de données est utilisée pour déclarer des variables et des paramètres . La division procédure contient les instructions du programme . Chaque division est subdivisée en sections, qui sont constituées de paragraphes.

Métalangage

La syntaxe de COBOL est généralement décrite avec un métalangage unique utilisant des accolades, des crochets, des barres et un soulignement. Le métalangage a été développé pour les spécifications COBOL d'origine. Bien que la forme Backus – Naur existait à l'époque, le comité n'en avait pas entendu parler.

À titre d'exemple, considérons la description suivante d'une ADDinstruction :

${\displaystyle {\begin{array}{l}{\underline {\text{ADD}}}\,{\begin{Bmatrix}{\text{identifier-1}}\\{\text{literal-1} }\end{Bmatrix}}\dots \;{\underline {\text{TO}}}\,\left\{{\text{identifier-2}}\,\left[\,{\underline {\text {ARRONDI}}}\,\right]\right\}\dots \\\quad \left[\left|{\begin{array}{l}{\text{ON}}\,{\underline {\text {SIZE}}}\,{\underline {\text{ERROR}}}\,{\text{imperative-statement-1}}\\{\underline {\text{NOT}}}\,{\text{ ON}}\,{\underline {\text{SIZE}}}\,{\underline {\text{ERROR}}}\,{\text{imperative-statement-2}}\\\end{array}} \right|\right]\\\quad \left[\,{\underline {\text{END-ADD}}}\,\right]\end{array}}}$

Cette description autorise les variantes suivantes :

ADD 1 TO x
ADD 1, a, b TO x ROUNDED, y, z ROUNDED

ADD a, b TO c
    ON SIZE ERROR
        DISPLAY "Error"
END-ADD

ADD a TO b
    NOT SIZE ERROR
        DISPLAY "No error"
    ON SIZE ERROR
        DISPLAY "Error"

Format de code

Jeu de cartes perforées du programme COBOL, des années 1970

L'apogée de la popularité de COBOL a coïncidé avec l'ère des machines à perforer et des cartes perforées . Le programme lui-même était écrit sur des cartes perforées, puis lu et compilé, et les données introduites dans le programme étaient parfois également sur des cartes.

COBOL peut être écrit en deux formats : fixe (par défaut) ou libre. Dans un format fixe, le code doit être aligné pour s'adapter à certaines zones (résidus liés à l'utilisation de cartes perforées). Jusqu'à COBOL 2002, il s'agissait de :

Dans COBOL 2002, les zones A et B ont été fusionnées pour former la zone de texte du programme, qui se termine désormais par une colonne définie par l'implémenteur.

COBOL 2002 a également introduit du code au format libre. Le code au format libre peut être placé dans n'importe quelle colonne du fichier, comme dans les nouveaux langages de programmation. Les commentaires sont spécifiés à l'aide de *>, qui peuvent être placés n'importe où et peuvent également être utilisés dans le code source au format fixe. Les lignes de continuation ne sont pas présentes et la >>PAGEdirective remplace l' /indicateur.

Service d'identification

La division d'identification identifie l'entité de code suivante et contient la définition d'une classe ou d'une interface.

Programmation orientée objet

Les classes et les interfaces sont en COBOL depuis 2002. Les classes ont des objets de fabrique, contenant des méthodes et des variables de classe, et des objets d'instance, contenant des méthodes d'instance et des variables. L'héritage et les interfaces fournissent le polymorphisme . La prise en charge de la programmation générique est assurée par des classes paramétrées, qui peuvent être instanciées pour utiliser n'importe quelle classe ou interface. Les objets sont stockés sous forme de références qui peuvent être limitées à un certain type. Il existe deux manières d'appeler une méthode : l' INVOKEinstruction, qui agit de manière similaire à CALL, ou via l'invocation d'une méthode en ligne, qui est analogue à l'utilisation de fonctions.

*> These are equivalent.
INVOKE my-class "foo" RETURNING var
MOVE my-class::"foo" TO var *> Inline method invocation

COBOL ne permet pas de masquer les méthodes. Les données de classe peuvent cependant être masquées en les déclarant sans PROPERTYclause, ce qui laisse l'utilisateur sans aucun moyen d'y accéder. La surcharge de méthode a été ajoutée dans COBOL 2014.

Pôle Environnement

La division environnement contient la section configuration et la section entrée-sortie. La section de configuration est utilisée pour spécifier des fonctionnalités variables telles que les symboles monétaires, les paramètres régionaux et les jeux de caractères. La section d'entrée-sortie contient des informations relatives au fichier.

Des dossiers

COBOL prend en charge trois formats de fichiers, ou organisations : séquentiel, indexé et relatif. Dans les fichiers séquentiels, les enregistrements sont contigus et doivent être parcourus de manière séquentielle , comme dans une liste chaînée . Les fichiers indexés ont un ou plusieurs index qui permettent d' accéder de manière aléatoire aux enregistrements et qui peuvent être triés sur ceux-ci. Chaque enregistrement doit avoir une clé unique , mais les autres clés d'enregistrement alternatives ne doivent pas nécessairement être uniques. Les implémentations des fichiers indexés varient d'un fournisseur à l'autre, bien que les implémentations courantes, telles que C-ISAM et VSAM , soient basées sur ISAM d' IBM . les autres implémentations sont Record Management Services sur OpenVMS et Enscribe sur HPE NonStop (Tandem). Les fichiers relatifs, comme les fichiers indexés, ont une clé d'enregistrement unique, mais ils n'ont pas de clés alternatives. La clé d'un enregistrement relatif est sa position ordinale ; par exemple, le 10e enregistrement a une clé de 10. Cela signifie que la création d'un enregistrement avec une clé de 5 peut nécessiter la création d'enregistrements précédents (vides). Les fichiers relatifs permettent également un accès séquentiel et aléatoire.

Une extension courante non standard est l' organisation séquentielle des lignes , utilisée pour traiter les fichiers texte. Les enregistrements d'un fichier se terminent par une nouvelle ligne et peuvent être de longueur variable.

Division des données

La division des données est divisée en six sections qui déclarent différentes rubriques : la section fichier, pour les enregistrements de fichiers ; la section working-storage, pour les variables statiques ; la section local-storage, pour les variables automatiques ; la section de liaison, pour les paramètres et la valeur de retour ; la section rapport et la section écran, pour les interfaces utilisateur textuelles .

Données agrégées

Les éléments de données en COBOL sont déclarés hiérarchiquement grâce à l'utilisation de numéros de niveau qui indiquent si un élément de données fait partie d'un autre. Un élément avec un numéro de niveau supérieur est subordonné à un élément avec un numéro inférieur. Les éléments de données de niveau supérieur, avec un numéro de niveau de 1, sont appelés records . Les éléments qui ont des données agrégées subordonnées sont appelés éléments de groupe ; ceux qui ne le sont pas sont appelés éléments élémentaires . Les numéros de niveau utilisés pour décrire les éléments de données standard sont compris entre 1 et 49.

       01  some-record.                   *> Aggregate group record item
           05  num            PIC 9(10).  *> Elementary item
           05  the-date.                  *> Aggregate (sub)group record item
               10  the-year   PIC 9(4).   *> Elementary item
               10  the-month  PIC 99.     *> Elementary item
               10  the-day    PIC 99.     *> Elementary item

Dans l'exemple ci-dessus, l'élément élémentaire numet l'élément de groupe the-datesont subordonnés à l'enregistrement some-record, tandis que les éléments élémentaires the-year, the-monthet the-dayfont partie de l'élément de groupe the-date.

Les éléments subordonnés peuvent être désambiguïsés avec le mot-clé IN(ou OF). Par exemple, considérez l'exemple de code ci-dessus avec l'exemple suivant :

       01  sale-date.
           05  the-year       PIC 9(4).
           05  the-month      PIC 99.
           05  the-day        PIC 99.

Les noms the-year, the-monthet the-daysont ambigus en eux-mêmes, car plusieurs éléments de données sont définis avec ces noms. Pour spécifier un élément de données particulier, par exemple l'un des éléments contenus dans le sale-dategroupe, le programmeur utiliserait the-year IN sale-date(ou l'équivalent the-year OF sale-date). Cette syntaxe est similaire à la "notation par points" prise en charge par la plupart des langages contemporains.

Autres niveaux de données

Un numéro de niveau de 66 est utilisé pour déclarer un regroupement d'éléments définis précédemment, quelle que soit la structure de ces éléments. Ce niveau de données, également désigné par la RENAMESclause associée , est rarement utilisé et, vers 1988, se trouvait généralement dans les anciens programmes. Sa capacité à ignorer les données de structure hiérarchique et logique signifiait que son utilisation n'était pas recommandée et de nombreuses installations interdisaient son utilisation.

       01  customer-record.
           05  cust-key            PIC X(10).
           05  cust-name.
               10  cust-first-name PIC X(30).
               10  cust-last-name  PIC X(30).
           05  cust-dob            PIC 9(8).
           05  cust-balance        PIC 9(7)V99.
           
       66  cust-personal-details   RENAMES cust-name THRU cust-dob.
       66  cust-all-details        RENAMES cust-name THRU cust-balance.

Un numéro de niveau 77 indique que l'élément est autonome et, dans de telles situations, équivaut au numéro de niveau 01. Par exemple, le code suivant déclare deux éléments de données de niveau 77, et , qui sont des éléments de données non property-namegroupés sales-regionqui sont indépendants (et non subordonnés) à tout autre élément de données :

       77  property-name      PIC X(80).
       77  sales-region       PIC 9(5).

Un numéro de niveau 88 déclare un nom de condition (appelé niveau 88) qui est vrai lorsque son élément de données parent contient l'une des valeurs spécifiées dans sa VALUEclause. Par exemple, le code suivant définit deux éléments de nom de condition de niveau 88 qui sont vrais ou faux selon la valeur de données de caractère actuelle de l' wage-typeélément de données. Lorsque l'élément de données contient une valeur de 'H', le nom-condition wage-is-hourlyest vrai, tandis que lorsqu'il contient une valeur de 'S'ou 'Y', le nom-condition wage-is-yearlyest vrai. Si l'élément de données contient une autre valeur, les deux noms de condition sont faux.

       01  wage-type          PIC X.
           88  wage-is-hourly VALUE "H".
           88  wage-is-yearly VALUE "S", "Y".

Types de données

Le COBOL standard fournit les types de données suivants :

La sécurité des types est variable en COBOL. Les données numériques sont converties silencieusement entre différentes représentations et tailles et les données alphanumériques peuvent être placées dans n'importe quel élément de données pouvant être stocké sous forme de chaîne, y compris les données numériques et de groupe. En revanche, les références d'objet et les pointeurs ne peuvent être attribués qu'à partir d'éléments du même type et leurs valeurs peuvent être limitées à un certain type.

Clause IMAGE

Une clause PICTURE(ou PIC) est une chaîne de caractères, dont chacun représente une partie de l'élément de données et ce qu'il peut contenir. Certains caractères d'image spécifient le type de l'élément et le nombre de caractères ou de chiffres qu'il occupe en mémoire. Par exemple, a 9indique un chiffre décimal et an Sindique que l'élément est signé . D'autres caractères d'image (appelés caractères d'insertion et d'édition ) spécifient comment un élément doit être formaté. Par exemple, une série de +caractères définit les positions des caractères ainsi que la manière dont un caractère de début doit être positionné dans les données de caractère finales ; le caractère non numérique le plus à droite contiendra le signe de l'élément, tandis que les autres positions de caractère correspondant à a +à gauche de cette position contiendront un espace. Les caractères répétés peuvent être spécifiés de manière plus concise en spécifiant un nombre entre parenthèses après un caractère d'image ; par exemple, 9(7)est équivalent à 9999999. Les spécifications d'image contenant uniquement des chiffres ( 9) et des signes ( S) définissent des éléments de données purement numériques , tandis que les spécifications d'image contenant des caractères alphabétiques ( A) ou alphanumériques ( ) définissent des éléments de données alphanumériques . La présence d'autres caractères de formatage définit des éléments de données numériques ou alphanumériques édités . X

Clause USAGE

La USAGEclause déclare le format dans lequel les données sont stockées. Selon le type de données, il peut soit compléter soit être utilisé à la place d'une PICTUREclause. Bien qu'il puisse être utilisé pour déclarer des pointeurs et des références d'objets, il est principalement orienté vers la spécification de types numériques. Ces formats numériques sont :

• Binaire, où une taille minimale est spécifiée soit par la PICTUREclause, soit par une USAGEclause telle queBINARY-LONG
• USAGE COMPUTATIONAL, où les données peuvent être stockées dans n'importe quel format fourni par l'implémentation ; souvent équivalent à  USAGE BINARY
• USAGE DISPLAY, le format par défaut, où les données sont stockées sous forme de chaîne
• Virgule flottante, soit dans un format dépendant de l'implémentation, soit selon IEEE 754
• USAGE NATIONAL, où les données sont stockées sous forme de chaîne à l'aide d'un jeu de caractères étendu
• USAGE PACKED-DECIMAL, où les données sont stockées dans le plus petit format décimal possible (généralement décimal codé en binaire compressé )

Rédacteur du rapport

L'éditeur de rapport est une fonction déclarative pour créer des rapports. Le programmeur n'a qu'à spécifier la mise en page du rapport et les données requises pour le produire, ce qui lui évite d'avoir à écrire du code pour gérer des éléments tels que les sauts de page, le formatage des données, les en-têtes et les pieds de page.

Les rapports sont associés à des fichiers de rapport, qui sont des fichiers qui ne peuvent être écrits que par le biais d'instructions de rédacteur de rapport.

       FD  report-out REPORT sales-report.

Chaque rapport est défini dans la section rapport de la division des données. Un rapport est divisé en groupes de rapports qui définissent les en-têtes, les pieds de page et les détails du rapport. Les rapports contournent les ruptures de contrôle hiérarchiques . Les ruptures de contrôle se produisent lorsqu'une variable clé change sa valeur ; par exemple, lors de la création d'un rapport détaillant les commandes des clients, une rupture de contrôle peut se produire lorsque le programme atteint les commandes d'un autre client. Voici un exemple de description de rapport pour un rapport qui donne les ventes d'un vendeur et qui avertit de tout enregistrement invalide :

       RD  sales-report
           PAGE LIMITS 60 LINES
           FIRST DETAIL 3
           CONTROLS seller-name.

       01  TYPE PAGE HEADING.
           03  COL 1                    VALUE "Sales Report".
           03  COL 74                   VALUE "Page".
           03  COL 79                   PIC Z9 SOURCE PAGE-COUNTER.

       01  sales-on-day TYPE DETAIL, LINE + 1.
           03  COL 3                    VALUE "Sales on".
           03  COL 12                   PIC 99/99/9999 SOURCE sales-date.
           03  COL 21                   VALUE "were".
           03  COL 26                   PIC $$$$9.99 SOURCE sales-amount.

       01  invalid-sales TYPE DETAIL, LINE + 1.
           03  COL 3                    VALUE "INVALID RECORD:".
           03  COL 19                   PIC X(34) SOURCE sales-record.

       01  TYPE CONTROL HEADING seller-name, LINE + 2.
           03  COL 1                    VALUE "Seller:".
           03  COL 9                    PIC X(30) SOURCE seller-name.

La description du rapport ci-dessus décrit la mise en page suivante :

Sales Report                                                             Page  1

Seller: Howard Bromberg
  Sales on 10/12/2008 were $1000.00
  Sales on 12/12/2008 were    $0.00
  Sales on 13/12/2008 were   $31.47
  INVALID RECORD: Howard Bromberg             XXXXYY

Seller: Howard Discount
...
Sales Report                                                            Page 12

  Sales on 08/05/2014 were  $543.98
  INVALID RECORD: William Selden      12O52014FOOFOO
  Sales on 30/05/2014 were    $0.00

Quatre instructions contrôlent le rédacteur de rapport : INITIATE, qui prépare le rédacteur de rapport pour l'impression ; GENERATE, qui imprime un groupe de rapports ; SUPPRESS, qui supprime l'impression d'un groupe d'états ; et TERMINATE, qui termine le traitement du rapport. Pour l'exemple de rapport de ventes ci-dessus, la division de procédure pourrait ressembler à ceci :

           OPEN INPUT sales, OUTPUT report-out
           INITIATE sales-report
 
           PERFORM UNTIL 1 <> 1
               READ sales
                   AT END
                       EXIT PERFORM
               END-READ
 
               VALIDATE sales-record
               IF valid-record
                   GENERATE sales-on-day
               ELSE
                   GENERATE invalid-sales
               END-IF
           END-PERFORM
 
           TERMINATE sales-report
           CLOSE sales, report-out
           .

L'utilisation de la fonction Report Writer a tendance à varier considérablement ; certaines organisations l'utilisent abondamment et d'autres pas du tout. De plus, les implémentations de Report Writer variaient en qualité, celles de niveau inférieur utilisant parfois des quantités excessives de mémoire lors de l'exécution.

Division de la procédure

Procédures

Les sections et les paragraphes de la division des procédures (collectivement appelées procédures) peuvent être utilisés comme étiquettes et comme simples sous-programmes . Contrairement aux autres divisions, les paragraphes n'ont pas besoin d'être dans des sections.

L'exécution suit les procédures d'un programme jusqu'à ce qu'il soit terminé. Pour utiliser des procédures comme sous-routines, le PERFORMverbe est utilisé.

Une PERFORMinstruction ressemble quelque peu à un appel de procédure dans un langage plus récent en ce sens que l'exécution revient au code suivant l' PERFORMinstruction à la fin du code appelé ; cependant, il ne fournit pas de mécanisme pour passer des paramètres ou pour renvoyer une valeur de résultat. Si une sous-routine est invoquée à l'aide d'une instruction simple telle que , le contrôle revient à la fin de la procédure appelée. Cependant, est inhabituel en ce sens qu'il peut être utilisé pour appeler une plage couvrant une séquence de plusieurs procédures adjacentes. Cela se fait avec la construction : PERFORM subroutinePERFORMPERFORM sub-1 THRU sub-n

PROCEDURE so-and-so.
    PERFORM ALPHA
    PERFORM ALPHA THRU GAMMA
    STOP RUN.
ALPHA.
    DISPLAY 'A'.
BETA.
    DISPLAY 'B'.
GAMMA.
    DISPLAY 'C'.

La sortie de ce programme sera : "AAB C".

PERFORMdiffère également des appels de procédure conventionnels en ce qu'il n'y a, du moins traditionnellement, aucune notion de pile d'appels. Par conséquent, les invocations imbriquées sont possibles (une séquence de code en cours d' PERFORMédition peut exécuter une PERFORMinstruction elle-même), mais nécessitent une attention particulière si des parties du même code sont exécutées par les deux invocations. Le problème survient lorsque le code de l'invocation interne atteint le point de sortie de l'invocation externe. Plus formellement, si le contrôle passe par le point de sortie d'un PERFORMappel qui a été appelé plus tôt mais qui n'est pas encore terminé, la norme COBOL 2002 stipule que le comportement est undefined .

La raison en est que COBOL, plutôt qu'une "adresse de retour", fonctionne avec ce que l'on peut appeler une adresse de continuation. Lorsque le flux de contrôle atteint la fin d'une procédure, l'adresse de continuation est recherchée et le contrôle est transféré à cette adresse. Avant l'exécution du programme, l'adresse de continuation de chaque procédure est initialisée à l'adresse de début de la procédure qui vient ensuite dans le texte du programme afin que, si aucune PERFORMinstruction ne se produise, le contrôle circule de haut en bas dans le programme. Mais lorsqu'une PERFORMinstruction s'exécute, elle modifie l'adresse de continuation de la procédure appelée (ou la dernière procédure de la plage appelée, si elle PERFORM THRUa été utilisée), de sorte que le contrôle revienne au site d'appel à la fin. La valeur d'origine est enregistrée et restaurée par la suite, mais il n'y a qu'une seule position de stockage. Si deux invocations imbriquées fonctionnent sur du code qui se chevauche, elles peuvent interférer l'une avec l'autre dans la gestion de l'adresse de continuation de plusieurs manières.

L'exemple suivant (tiré de Veerman & Verhoeven 2006 ) illustre le problème :

LABEL1.
    DISPLAY '1'
    PERFORM LABEL2 THRU LABEL3
    STOP RUN.
LABEL2.
    DISPLAY '2'
    PERFORM LABEL3 THRU LABEL4.
LABEL3.
    DISPLAY '3'.
LABEL4.
    DISPLAY '4'.

On pourrait s'attendre à ce que la sortie de ce programme soit "1 2 3 4 3": Après avoir affiché "2", le second PERFORMprovoque l'affichage de "3" et "4", puis la première invocation continue avec "3" . Dans les implémentations COBOL traditionnelles, ce n'est pas le cas. Au lieu de cela, la première PERFORMinstruction définit l'adresse de continuation à la fin de LABEL3afin qu'elle revienne au site d'appel à l'intérieur de LABEL1. La deuxième PERFORMinstruction définit le retour à la fin de LABEL4mais ne modifie pas l'adresse de continuation de LABEL3, s'attendant à ce qu'elle soit la continuation par défaut. Ainsi, lorsque l'invocation interne arrive à la fin de LABEL3, elle revient à l' PERFORMinstruction externe, et le programme arrête d'avoir imprimé juste "1 2 3". D'autre part, dans certaines implémentations COBOL comme le compilateur open-source TinyCOBOL, les deux PERFORMinstructions n'interfèrent pas l'une avec l'autre et la sortie est bien "1 2 3 4 3". Par conséquent, le comportement dans de tels cas n'est pas seulement (peut-être) surprenant, il n'est pas non plus portable.

Une conséquence particulière de cette limitation est qu'elle PERFORMne peut pas être utilisée pour écrire du code récursif. Un autre exemple simple pour illustrer cela (légèrement simplifié de Veerman & Verhoeven 2006 ):

    MOVE 1 TO A
    PERFORM LABEL
    STOP RUN.
LABEL.
    DISPLAY A
    IF A < 3
        ADD 1 TO A
        PERFORM LABEL
    END-IF
    DISPLAY 'END'.

On pourrait s'attendre à ce que la sortie soit "1 2 3 END END END", et c'est en fait ce que certains compilateurs COBOL produiront. Mais d'autres compilateurs, comme IBM COBOL, produiront du code qui imprime "1 2 3 END END END END ..." et ainsi de suite, en imprimant "END" encore et encore dans une boucle sans fin. Comme il y a un espace limité pour stocker les adresses de continuation de sauvegarde, les sauvegardes sont écrasées au cours des appels récursifs, et tout ce qui peut être restauré est le saut vers DISPLAY 'END'.

Déclarations

COBOL 2014 comporte 47 instructions (également appelées verbes ), qui peuvent être regroupées dans les grandes catégories suivantes : flux de contrôle, E/S, manipulation de données et rédacteur de rapport. Les déclarations du rédacteur de rapport sont couvertes dans la section du rédacteur de rapport .

Flux de contrôle

Les instructions conditionnelles de COBOL sont IFet EVALUATE. EVALUATEest une instruction de type commutateur avec la capacité supplémentaire d'évaluer plusieurs valeurs et conditions. Cela peut être utilisé pour implémenter des tables de décision . Par exemple, les éléments suivants peuvent être utilisés pour contrôler un tour CNC :

EVALUATE TRUE ALSO desired-speed ALSO current-speed
    WHEN lid-closed ALSO min-speed THRU max-speed ALSO LESS THAN desired-speed
        PERFORM speed-up-machine
    WHEN lid-closed ALSO min-speed THRU max-speed ALSO GREATER THAN desired-speed
        PERFORM slow-down-machine
    WHEN lid-open ALSO ANY ALSO NOT ZERO
        PERFORM emergency-stop
    WHEN OTHER
        CONTINUE
END-EVALUATE

L' PERFORMinstruction est utilisée pour définir des boucles qui sont exécutées jusqu'à ce qu'une condition soit vraie (pas tant que vraie, ce qui est plus courant dans d'autres langages). Il est également utilisé pour appeler des procédures ou des plages de procédures (voir la section procédures pour plus de détails). CALLet INVOKEappeler des sous-programmes et des méthodes, respectivement. Le nom du sous-programme/de la méthode est contenu dans une chaîne qui peut être un littéral ou un élément de données. Les paramètres peuvent être passés par référence , par contenu (où une copie est passée par référence) ou par valeur (mais uniquement si un prototype est disponible). CANCELdécharge les sous-programmes de la mémoire. GO TOfait sauter le programme à une procédure spécifiée.

L' GOBACKinstruction est une instruction de retour et l' STOPinstruction arrête le programme. L' EXITinstruction a six formats différents : elle peut être utilisée comme instruction de retour, instruction break , instruction continue , marqueur de fin ou pour quitter une procédure.

Les exceptions sont déclenchées par une RAISEinstruction et interceptées avec un gestionnaire, ou déclaratif , défini dans la DECLARATIVESpartie de la division de procédure. Les déclaratifs sont des sections commençant par une USEinstruction qui spécifient les erreurs à gérer. Les exceptions peuvent être des noms ou des objets. RESUMEest utilisé dans un déclaratif pour sauter à l'instruction après celle qui a déclenché l'exception ou à une procédure en dehors du DECLARATIVES. Contrairement à d'autres langages, les exceptions non interceptées peuvent ne pas terminer le programme et le programme peut continuer sans être affecté.

E/S

Les E/S de fichier sont gérées par les instructions auto-descriptives OPEN, CLOSE, READet , WRITEainsi que par trois autres : REWRITE, qui met à jour un enregistrement ; START, qui sélectionne les enregistrements suivants auxquels accéder en trouvant un enregistrement avec une certaine clé ; et UNLOCK, qui libère un verrou sur le dernier enregistrement accédé.

L'interaction avec l'utilisateur se fait à l'aide ACCEPTde et DISPLAY.

Manipulation de données

Les verbes suivants manipulent des données :

• INITIALIZE, qui définit les éléments de données sur leurs valeurs par défaut.
• MOVE, qui attribue des valeurs aux éléments de données ; MOVE CORRESPONDING affecte les champs de même nom correspondants .
• SET, qui a 15 formats : il peut modifier les index, attribuer des références d'objets et modifier les capacités des tables, entre autres fonctions.
• ADD, SUBTRACT, MULTIPLY, DIVIDE, et COMPUTE, qui gèrent l'arithmétique (avec COMPUTEaffectation du résultat d'une formule à une variable).
• ALLOCATEet FREE, qui gèrent la mémoire dynamique .
• VALIDATE, qui valide et distribue les données comme spécifié dans la description d'un élément dans la division des données.
• STRINGet UNSTRING, qui concatènent et divisent les chaînes , respectivement.
• INSPECT, qui correspond ou remplace les instances des sous-chaînes spécifiées dans une chaîne.
• SEARCH, qui recherche dans une table la première entrée satisfaisant une condition.

Les fichiers et les tables sont triés à l'aide de SORTet le MERGEverbe fusionne et trie les fichiers. Le RELEASEverbe fournit des enregistrements à trier et RETURNrécupère les enregistrements triés dans l'ordre.

Résiliation de la portée

Certaines instructions, telles que IFet READ, peuvent elles-mêmes contenir des instructions. De telles instructions peuvent être terminées de deux manières : par un point ( terminaison implicite ), qui termine toutes les instructions non terminées contenues, ou par un terminateur de portée, qui termine l'instruction ouverte correspondante la plus proche.

*> Terminator period ("implicit termination")
IF invalid-record
    IF no-more-records
        NEXT SENTENCE
    ELSE
        READ record-file
            AT END SET no-more-records TO TRUE.

*> Scope terminators ("explicit termination")
IF invalid-record
    IF no-more-records
        CONTINUE
    ELSE
        READ record-file
            AT END SET no-more-records TO TRUE
        END-READ
    END-IF
END-IF

Les instructions imbriquées terminées par un point sont une source courante de bogues. Par exemple, examinez le code suivant :

IF x
    DISPLAY y.
    DISPLAY z.

Ici, l'intention est d'afficher yet zsi la condition xest vraie. Cependant, zsera affiché quelle que soit la valeur de xcar l' IFinstruction se termine par un point erroné après . DISPLAY y

Un autre bogue est le résultat du problème du reste suspendu , lorsque deux IFinstructions peuvent être associées à un ELSE.

IF x
    IF y
        DISPLAY a
ELSE
    DISPLAY b.

Dans le fragment ci-dessus, le ELSEs'associe à l'     instruction au lieu de l'     instruction, provoquant un bogue. Avant l'introduction de terminateurs de portée explicites, l'empêcher nécessiterait     d'être placé après le . IF yIF xELSE NEXT SENTENCEIF

Code auto-modifiable

La spécification COBOL originale (1959) prenait en charge la tristement célèbre     déclaration, pour laquelle de nombreux compilateurs généraient du code auto-modifiable . et sont des étiquettes de procédure, et la seule     instruction dans la procédure exécutée après une telle instruction signifie     à la place. De nombreux compilateurs le supportent toujours, mais il a été jugé obsolète dans la norme COBOL 1985 et supprimé en 2002. ALTER X TO PROCEED TO YXYGO TOXALTERGO TO Y

La ALTERdéclaration a été mal considérée car elle sapait la «localité du contexte» et rendait la logique globale d'un programme difficile à comprendre. Comme l'a écrit l'auteur de manuels Daniel D. McCracken en 1976, lorsque "quelqu'un qui n'a jamais vu le programme auparavant doit se familiariser avec lui le plus rapidement possible, parfois sous une pression de temps critique parce que le programme a échoué ... la vue d'un GO TO dans un paragraphe à lui seul, signalant comme il le fait l'existence d'un nombre inconnu d'instructions ALTER à des endroits inconnus tout au long du programme, fait peur au cœur du programmeur le plus courageux."

Bonjour le monde

Un programme " Hello, world " en COBOL :

       IDENTIFICATION DIVISION.
       PROGRAM-ID. hello-world.
       PROCEDURE DIVISION.
           DISPLAY "Hello, world!"
           .

Lorsque le – désormais célèbre – "Hello, World!" exemple de programme dans le langage de programmation C a été publié pour la première fois en 1978, un exemple de programme COBOL mainframe similaire aurait été soumis via JCL , très probablement à l'aide d'un lecteur de cartes perforées et de cartes perforées à 80 colonnes. La liste ci-dessous, avec une DATA DIVISION vide , a été testée avec Linux et l' émulateur System/370 Hercules exécutant MVS 3.8J. Le JCL, écrit en juillet 2015, est dérivé des tutoriels et exemples Hercules hébergés par Jay Moseley. Conformément à la programmation COBOL de cette époque, HELLO, WORLD est affiché en majuscules.

//COBUCLG  JOB (001),'COBOL BASE TEST',                                 00010000
//             CLASS=A,MSGCLASS=A,MSGLEVEL=(1,1)                        00020000
//BASETEST EXEC COBUCLG                                                 00030000
//COB.SYSIN DD *                                                        00040000
 00000* VALIDATION OF BASE COBOL INSTALL                                00050000
 01000 IDENTIFICATION DIVISION.                                         00060000
 01100 PROGRAM-ID. 'HELLO'.                                             00070000
 02000 ENVIRONMENT DIVISION.                                            00080000
 02100 CONFIGURATION SECTION.                                           00090000
 02110 SOURCE-COMPUTER.  GNULINUX.                                      00100000
 02120 OBJECT-COMPUTER.  HERCULES.                                      00110000
 02200 SPECIAL-NAMES.                                                   00120000
 02210     CONSOLE IS CONSL.                                            00130000
 03000 DATA DIVISION.                                                   00140000
 04000 PROCEDURE DIVISION.                                              00150000
 04100 00-MAIN.                                                         00160000
 04110     DISPLAY 'HELLO, WORLD' UPON CONSL.                           00170000
 04900     STOP RUN.                                                    00180000
//LKED.SYSLIB DD DSNAME=SYS1.COBLIB,DISP=SHR                            00190000
//            DD DSNAME=SYS1.LINKLIB,DISP=SHR                           00200000
//GO.SYSPRINT DD SYSOUT=A                                               00210000
//                                                                      00220000

Après avoir soumis le JCL, la console MVS affiche :

    19.52.48 JOB    3  $HASP100 COBUCLG  ON READER1     COBOL BASE TEST
    19.52.48 JOB    3  IEF677I WARNING MESSAGE(S) FOR JOB COBUCLG  ISSUED
    19.52.48 JOB    3  $HASP373 COBUCLG  STARTED - INIT 1 - CLASS A - SYS BSP1
    19.52.48 JOB    3  IEC130I SYSPUNCH DD STATEMENT MISSING
    19.52.48 JOB    3  IEC130I SYSLIB   DD STATEMENT MISSING
    19.52.48 JOB    3  IEC130I SYSPUNCH DD STATEMENT MISSING
    19.52.48 JOB    3  IEFACTRT - Stepname  Procstep  Program   Retcode
    19.52.48 JOB    3  COBUCLG    BASETEST  COB       IKFCBL00  RC= 0000
    19.52.48 JOB    3  COBUCLG    BASETEST  LKED      IEWL      RC= 0000
    19.52.48 JOB    3  +HELLO, WORLD
    19.52.48 JOB    3  COBUCLG    BASETEST  GO        PGM=*.DD  RC= 0000
    19.52.48 JOB    3  $HASP395 COBUCLG  ENDED

La ligne 10 de la liste de la console ci-dessus est surlignée pour effet, la surbrillance ne fait pas partie de la sortie réelle de la console .

La liste du compilateur associée a généré plus de quatre pages de détails techniques et d'informations sur l'exécution des tâches, pour la seule ligne de sortie des 14 lignes de COBOL.

Réception

Manque de structure

Dans les années 1970, l'adoption du paradigme de la programmation structurée se généralisait de plus en plus. Edsger Dijkstra , un informaticien éminent, a écrit une lettre au rédacteur en chef de Communications of the ACM , publiée en 1975 et intitulée "Comment dire des vérités qui pourraient blesser?", Dans laquelle il critiquait COBOL et plusieurs autres langages contemporains; remarquant que "l'utilisation de COBOL paralyse l'esprit".

Dans une dissidence publiée aux remarques de Dijkstra, l'informaticien Howard E. Tompkins a affirmé que le COBOL non structuré avait tendance à être "écrit par des programmeurs qui n'ont jamais bénéficié du COBOL structuré bien enseigné", arguant que le problème était principalement un problème de formation.

L'une des causes du code spaghetti était la GO TOdéclaration. GO TOCependant, les tentatives de suppression des s du code COBOL ont abouti à des programmes alambiqués et à une qualité de code réduite. GO TOs ont été en grande partie remplacés par l' PERFORMinstruction et les procédures, qui favorisaient la programmation modulaire et donnaient un accès facile à de puissantes fonctions de bouclage. Cependant, PERFORMne pouvait être utilisé qu'avec des procédures, de sorte que les corps de boucle n'étaient pas situés là où ils étaient utilisés, ce qui rendait les programmes plus difficiles à comprendre.

Les programmes COBOL étaient réputés pour être monolithiques et manquer de modularité. Le code COBOL ne pouvait être modularisé qu'au moyen de procédures, qui se sont révélées inadéquates pour les grands systèmes. Il était impossible de restreindre l'accès aux données, ce qui signifie qu'une procédure pouvait accéder et modifier n'importe quelle donnée. De plus, il n'y avait aucun moyen de passer des paramètres à une procédure, une omission que Jean Sammet considérait comme la plus grande erreur du comité.

Une autre complication provenait de la capacité à PERFORM THRUune séquence spécifiée de procédures. Cela signifiait que le contrôle pouvait sauter et revenir de n'importe quelle procédure, créant un flux de contrôle alambiqué et permettant à un programmeur d'enfreindre la règle de l'entrée unique et de la sortie unique .

Cette situation s'est améliorée à mesure que COBOL adoptait davantage de fonctionnalités. COBOL-74 a ajouté des sous-programmes, donnant aux programmeurs la possibilité de contrôler les données auxquelles chaque partie du programme pouvait accéder. COBOL-85 a ensuite ajouté des sous-programmes imbriqués, permettant aux programmeurs de masquer les sous-programmes. Un contrôle supplémentaire sur les données et le code est venu en 2002 lorsque la programmation orientée objet, les fonctions définies par l'utilisateur et les types de données définis par l'utilisateur ont été inclus.

Néanmoins, de nombreux logiciels COBOL hérités importants utilisent du code non structuré, qui est devenu pratiquement impossible à maintenir. Il peut être trop risqué et coûteux de modifier même une simple section de code, car elle peut être utilisée à partir d'endroits inconnus de manière inconnue.

Problèmes de compatibilité

COBOL était destiné à être un langage "commun" hautement portable. Cependant, en 2001, environ 300 dialectes avaient été créés. Une source de dialectes était la norme elle-même : la norme de 1974 était composée d'un noyau obligatoire et de onze modules fonctionnels, chacun contenant deux ou trois niveaux de support. Cela a permis 104 976 variantes possibles.

COBOL-85 n'était pas entièrement compatible avec les versions antérieures et son développement était controversé. Joseph T. Brophy, le CIO de Travelers Insurance , a dirigé un effort pour informer les utilisateurs COBOL des coûts élevés de reprogrammation liés à la mise en œuvre de la nouvelle norme. En conséquence, le comité ANSI COBOL a reçu plus de 2 200 lettres du public, pour la plupart négatives, demandant au comité d'apporter des modifications. D'autre part, la conversion au COBOL-85 était censée augmenter la productivité dans les années à venir, justifiant ainsi les coûts de conversion.

Syntaxe détaillée

La syntaxe COBOL a souvent été critiquée pour sa verbosité. Les partisans disent que cela visait à rendre le code auto-documenté , facilitant ainsi la maintenance du programme. COBOL a également été conçu pour être facile à apprendre et à utiliser pour les programmeurs, tout en restant lisible pour le personnel non technique tel que les gestionnaires.

Le désir de lisibilité a conduit à l'utilisation d'une syntaxe et d'éléments structurels de type anglais, tels que les noms, les verbes, les clauses, les phrases, les sections et les divisions. Pourtant, en 1984, les mainteneurs des programmes COBOL avaient du mal à gérer le code "incompréhensible" et les principaux changements apportés au COBOL-85 étaient là pour faciliter la maintenance.

Jean Sammet, membre du comité à court terme, a noté que "peu d'efforts ont été faits pour répondre aux besoins du programmeur professionnel, en fait les personnes dont l'intérêt principal est la programmation ont tendance à être très mécontentes de COBOL", ce qu'elle a attribué à la syntaxe verbeuse de COBOL.

Isolement de la communauté informatique

La communauté COBOL a toujours été isolée de la communauté informatique. Aucun informaticien universitaire n'a participé à la conception de COBOL : tous les membres du comité venaient du commerce ou du gouvernement. Les informaticiens de l'époque s'intéressaient davantage à des domaines tels que l'analyse numérique, la physique et la programmation système qu'aux problèmes de traitement de fichiers commerciaux auxquels le développement COBOL s'attaquait. Jean Sammet a attribué l'impopularité de COBOL à une première "réaction snob" due à son inélégance, au manque d'informaticiens influents participant au processus de conception et à un dédain pour le traitement des données d'entreprise. La spécification COBOL utilisait une "notation" unique, ou métalangage , pour définir sa syntaxe plutôt que la nouvelle forme Backus-Naur que le comité ne connaissait pas. Cela a entraîné des critiques "sévères".

Plus tard, COBOL a souffert d'une pénurie de matériel le couvrant; il a fallu attendre 1963 pour que des livres d'introduction paraissent (avec Richard D. Irwin publiant un manuel universitaire sur COBOL en 1966). En 1985, il y avait deux fois plus de livres sur FORTRAN et quatre fois plus sur BASIC que sur COBOL à la Bibliothèque du Congrès . Les professeurs d'université ont enseigné des langages et des techniques plus modernes et à la pointe de la technologie au lieu de COBOL, qui aurait une nature « d'école de métiers ». Donald Nelson, président du comité CODASYL COBOL, a déclaré en 1984 que "les universitaires ... détestent COBOL" et que les diplômés en informatique "avaient la "détestation de COBOL" en eux".

Au milieu des années 1980, il y avait également une condescendance importante envers COBOL dans la communauté des affaires de la part des utilisateurs d'autres langages, par exemple FORTRAN ou assembleur , ce qui implique que COBOL ne pouvait être utilisé que pour des problèmes simples.

En 2003, COBOL figurait dans 80 % des programmes d'enseignement des systèmes d'information aux États-Unis, soit la même proportion que C++ et Java . Dix ans plus tard, un sondage réalisé par Micro Focus a révélé que 20 % des universitaires pensaient que COBOL était obsolète ou mort et que 55 % pensaient que leurs étudiants pensaient que COBOL était obsolète ou mort. Le même sondage a également révélé que seuls 25 % des universitaires avaient la programmation COBOL dans leur programme, même si 60 % pensaient qu'ils devraient l'enseigner.

Préoccupations concernant le processus de conception

Des doutes ont été émis quant à la compétence du comité des normes. Howard Bromberg, membre du comité à court terme, a déclaré qu'il y avait "peu de contrôle" sur le processus de développement et qu'il était "en proie à la discontinuité du personnel et ... au manque de talents". Jean Sammet et Jérôme Garfunkel ont également noté que les changements introduits dans une révision de la norme seraient annulés dans la suivante, en raison autant de changements dans la composition du comité de normalisation que de preuves objectives.

Les normes COBOL ont souffert à plusieurs reprises de retards : COBOL-85 est arrivé cinq ans plus tard que prévu, COBOL 2002 avait cinq ans de retard et COBOL 2014 avait six ans de retard. Pour lutter contre les retards, le comité standard a autorisé la création d'addenda optionnels qui ajouteraient des fonctionnalités plus rapidement qu'en attendant la prochaine révision standard. Cependant, certains membres du comité ont soulevé des inquiétudes concernant les incompatibilités entre les implémentations et les modifications fréquentes de la norme.

Influences sur d'autres langues

Les structures de données de COBOL ont influencé les langages de programmation ultérieurs. Sa structure d'enregistrement et de fichier a influencé PL/I et Pascal , et la REDEFINESclause était un prédécesseur des enregistrements de variantes de Pascal. Les définitions explicites de la structure des fichiers ont précédé le développement des systèmes de gestion de base de données et les données agrégées constituaient une avancée significative par rapport aux baies de Fortran.

PICTUREles déclarations de données ont été incorporées dans PL/I, avec des modifications mineures.

L'installation de COBOL COPY, bien que considérée comme "primitive", a influencé le développement des directives include .

L'accent mis sur la portabilité et la normalisation signifiait que les programmes écrits en COBOL pouvaient être portables et facilitait la diffusion du langage sur une grande variété de plates-formes matérielles et de systèmes d'exploitation. De plus, la structure bien définie des divisions restreint la définition des références externes à la Division Environnement, ce qui simplifie notamment les changements de plate-forme.

Voir également

• Liste alphabétique des langages de programmation
• BLIS/COBOL
• CODASYL
• Comparaison des langages de programmation
• Liste générationnelle des langages de programmation § Basé sur COBOL
• Liste des compilateurs § Compilateurs COBOL

Remarques

Les références

Citations

Sources

Liens externes

• COBOL chez Curlie
• Norme de langage COBOL (1991; COBOL-85 avec amendement 1), de The Open Group