COBOL

COBOL ⓘ

121px Der COBOL-60-Bericht an CODASYL (April 1960)
Paradigma	Prozedural, imperativ, objektorientiert
Entworfen von	Howard Bromberg, Norman Discount, Vernon Reeves, Jean E. Sammet, William Selden, Gertrude Tierney, mit indirektem Einfluss von Grace Hopper
Entwickler	CODASYL, ANSI, ISO/IEC
Erstes Erscheinen	1959; vor 64 Jahren
Stabile Version	ISO/IEC 1989:2014 / 2014
Disziplin der Typisierung	Schwach, statisch
Dateinamen-Erweiterungen	.cbl, .cob, .cpy
Wichtige Implementierungen
GnuCOBOL, IBM COBOL, Micro Focus Visual COBOL
Dialekte
COBOL/2, DEC COBOL-10, 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) COBOL85, Tandem (NonStop) SCOBOL, UNIVAC COBOL, Unisys MCP COBOL74, Unisys MCP COBOL85, Unix COBOL X/Open, Veryant isCOBOL, Wang VS COBOL
Beeinflusst durch
Ursprünglich: AIMACO, COMTRAN, FACT, FLOW-MATIC COBOL 2002: C++, Eiffel, Smalltalk
Beeinflusst
CobolScript, EGL, PL/I, PL/B
COBOL bei Wikibooks

COBOL (/ˈkoʊbɒl, -bɔːl/; ein Akronym für "common business-oriented language") ist eine kompilierte englischsprachige Computerprogrammiersprache, die für den Einsatz in Unternehmen konzipiert wurde. Es handelt sich um eine imperative, prozedurale und seit 2002 auch objektorientierte Sprache. COBOL wird hauptsächlich in Geschäfts-, Finanz- und Verwaltungssystemen für Unternehmen und Regierungen verwendet. COBOL ist immer noch weit verbreitet in Anwendungen, die auf Großrechnern eingesetzt werden, wie z. B. umfangreiche Batch- und Transaktionsverarbeitungsaufträge. Da die Popularität von COBOL jedoch abnimmt und erfahrene COBOL-Programmierer in den Ruhestand gehen, werden die Programme auf neue Plattformen migriert, in modernen Sprachen umgeschrieben oder durch Softwarepakete ersetzt. Die meisten Programmierungen in COBOL dienen heute nur noch der Pflege bestehender Anwendungen; viele große Finanzinstitute entwickelten jedoch noch bis 2006 neue Systeme in COBOL. ⓘ

COBOL wurde 1959 von CODASYL entwickelt und basierte teilweise auf der von Grace Hopper entworfenen Programmiersprache FLOW-MATIC. Sie entstand im Rahmen der Bemühungen des US-Verteidigungsministeriums, eine portable Programmiersprache für die Datenverarbeitung zu entwickeln. Ursprünglich war sie nur als Notlösung gedacht, aber das Verteidigungsministerium zwang die Computerhersteller umgehend, sie anzubieten, was zu ihrer weiten Verbreitung führte. Sie wurde 1968 standardisiert und seitdem viermal überarbeitet. Zu den Erweiterungen gehört die Unterstützung für strukturierte und objektorientierte Programmierung. Die aktuelle Norm ist ISO/IEC 1989:2014. ⓘ

COBOL-Anweisungen haben eine englischsprachige Syntax, die so konzipiert wurde, dass sie selbstdokumentierend und gut lesbar ist. Sie ist jedoch langatmig und verwendet über 300 reservierte Wörter. Im Gegensatz zu einer modernen, prägnanten Syntax wie y = x;hat COBOL eine eher englischsprachige Syntax (in diesem Fall, MOVE x TO y). COBOL-Code ist in vier Bereiche (Identifikation, Umgebung, Daten und Prozedur) unterteilt, die eine strenge Hierarchie von Abschnitten, Absätzen und Sätzen enthalten. In Ermangelung einer großen Standardbibliothek sind in der Norm 43 Anweisungen, 87 Funktionen und nur eine Klasse spezifiziert. ⓘ

Akademische Informatiker waren im Allgemeinen nicht an Geschäftsanwendungen interessiert, als COBOL entwickelt wurde, und waren auch nicht an seinem Entwurf beteiligt; es wurde (praktisch) von Grund auf als Computersprache für den geschäftlichen Bereich entwickelt, mit dem Schwerpunkt auf Ein- und Ausgaben, deren einzige Datentypen Zahlen und Textfolgen waren. COBOL wurde während seiner gesamten Lebensdauer wegen seiner Ausführlichkeit, seines Entwurfsprozesses und seiner mangelhaften Unterstützung für strukturierte Programmierung kritisiert. Diese Schwächen führen zu monolithischen, langatmigen (englischsprachigen) Programmen, die nicht leicht zu verstehen sind. ⓘ

Jahrelang wurde COBOL als Programmiersprache für Geschäftsvorgänge auf Großrechnern angenommen, obwohl in den letzten Jahren ein zunehmendes Interesse an der Migration von COBOL-Operationen in das Cloud Computing zu verzeichnen ist. ⓘ

COBOL ist eine Programmiersprache, die in der Frühzeit der Computerentwicklung, Ende der 1950er-Jahre, entstand und bis heute verwendet wird. Der Stil dieser Programmiersprache ist stark an die natürliche Sprache angelehnt und dient vor allem der Programmierung kaufmännischer Anwendungen. ⓘ

Geschichte und Spezifikation

Hintergrund

In den späten 1950er Jahren zeigten sich Computeranwender und -hersteller besorgt über die steigenden Kosten der Programmierung. Eine Umfrage aus dem Jahr 1959 ergab, dass die Programmierung einer Datenverarbeitungsanlage im Durchschnitt 800.000 US-Dollar kostete und dass die Übersetzung von Programmen zur Ausführung auf neuer Hardware 600.000 US-Dollar kosten würde. In einer Zeit, in der immer mehr neue Programmiersprachen aufkamen, schlug dieselbe Studie vor, dass die Konvertierung weitaus billiger und schneller vonstatten gehen würde, wenn eine gemeinsame geschäftsorientierte Sprache verwendet würde. ⓘ

Am 8. April 1959 berief Mary K. Hawes, Informatikerin bei der Burroughs Corporation, an der Universität von Pennsylvania ein Treffen von Vertretern aus der Wissenschaft, von Computeranwendern und Herstellern ein, um ein formelles Treffen über gemeinsame Geschäftssprachen zu organisieren. Zu den Vertretern gehörten Grace Hopper (Erfinderin der englischsprachigen Datenverarbeitungssprache FLOW-MATIC), Jean Sammet und Saul Gorn. ⓘ

Auf dem Treffen im April bat die Gruppe das Verteidigungsministerium (DoD) um Unterstützung bei der Entwicklung einer gemeinsamen Geschäftssprache. Die Delegation beeindruckte Charles A. Phillips, den Direktor des Data System Research Staff im Verteidigungsministerium, der der Meinung war, dass sie die Probleme des Verteidigungsministeriums "gründlich verstanden" hätten. Das Verteidigungsministerium betrieb 225 Computer, hatte weitere 175 in Auftrag gegeben und über 200 Millionen Dollar für die Implementierung von Programmen ausgegeben, die auf diesen Computern laufen sollten. Portable Programme würden Zeit sparen, die Kosten senken und die Modernisierung erleichtern. ⓘ

Charles Phillips erklärte sich bereit, die Tagung zu sponsern und beauftragte die Delegation mit der Ausarbeitung der Tagesordnung. ⓘ

COBOL 60

Am 28. und 29. Mai 1959 (genau ein Jahr nach dem Züricher ALGOL 58-Treffen) fand im Pentagon ein Treffen statt, bei dem die Entwicklung einer gemeinsamen Programmiersprache für Unternehmen diskutiert wurde. Es nahmen 41 Personen teil und Phillips führte den Vorsitz. Das Verteidigungsministerium war besorgt darüber, ob es die gleichen Datenverarbeitungsprogramme auf verschiedenen Computern ausführen könnte. FORTRAN, die einzige gängige Sprache zu dieser Zeit, verfügte nicht über die notwendigen Funktionen, um solche Programme zu schreiben. ⓘ

Mit Begeisterung beschrieben die Vertreter eine Sprache, die in einer Vielzahl von Umgebungen eingesetzt werden kann, von Banken und Versicherungen bis hin zu Versorgungsunternehmen und der Lagerverwaltung. Sie waren einhellig der Meinung, dass mehr Menschen programmieren können sollten und dass die neue Sprache nicht durch die Beschränkungen der heutigen Technologie eingeschränkt werden sollte. Die Mehrheit war sich einig, dass die Sprache möglichst viel Englisch verwenden, veränderbar, maschinenunabhängig und einfach zu benutzen sein sollte, auch wenn dies auf Kosten der Leistungsfähigkeit geht. ⓘ

Auf der Sitzung wurden ein Lenkungsausschuss sowie ein Kurz-, ein Zwischen- und ein langfristiger Ausschuss eingesetzt. Der Kurzzeitausschuss hatte bis September (drei Monate) Zeit, Spezifikationen für eine Interimssprache auszuarbeiten, die dann von den anderen Ausschüssen verbessert werden sollten. Der offizielle Auftrag lautete jedoch, die Stärken und Schwächen der bestehenden Programmiersprachen zu ermitteln, und enthielt keine ausdrückliche Anweisung, eine neue Sprache zu entwickeln. Die Frist wurde vom Kurzzeitausschuss mit Unverständnis aufgenommen. Ein Mitglied, Betty Holberton, bezeichnete die dreimonatige Frist als "groben Optimismus" und bezweifelte, dass die Sprache wirklich eine Notlösung sein würde. ⓘ

Der Lenkungsausschuss trat am 4. Juni zusammen und beschloss, der gesamten Aktivität den Namen "Committee on Data Systems Languages" (CODASYL) zu geben und einen Exekutivausschuss zu bilden. ⓘ

Der Kurzzeitausschuss setzte sich aus Mitgliedern zusammen, die sechs Computerhersteller und drei Regierungsstellen vertraten. Die sechs Computerhersteller waren Burroughs Corporation, IBM, Minneapolis-Honeywell (Honeywell Labs), RCA, Sperry Rand und Sylvania Electric Products. Die drei Regierungsbehörden waren die US Air Force, das David Taylor Model Basin der Navy und das National Bureau of Standards (heute das National Institute of Standards and Technology). Den Vorsitz des Ausschusses hatte Joseph Wegstein vom US National Bureau of Standards inne. Die Arbeiten begannen mit der Untersuchung der Datenbeschreibung, der Aussagen, der bestehenden Anwendungen und der Erfahrungen der Nutzer. ⓘ

Der Ausschuss untersuchte hauptsächlich die Programmiersprachen FLOW-MATIC, AIMACO und COMTRAN. Die FLOW-MATIC-Sprache war besonders einflussreich, weil sie bereits implementiert worden war und weil AIMACO ein Derivat dieser Sprache mit nur geringen Änderungen war. Die Erfinderin von FLOW-MATIC, Grace Hopper, diente dem Ausschuss auch als technische Beraterin. Die wichtigsten Beiträge von FLOW-MATIC zu COBOL waren lange Variablennamen, englische Wörter für Befehle und die Trennung von Datenbeschreibungen und Anweisungen. Hopper wird manchmal als "Mutter von COBOL" oder "Großmutter von COBOL" bezeichnet, obwohl Jean Sammet, einer der Hauptentwickler von COBOL, erklärte, dass Hopper "nicht die Mutter, Schöpferin oder Entwicklerin von Cobol" war. ⓘ

Die von Bob Bemer erfundene IBM-Sprache COMTRAN wurde von einem kurzfristigen Ausschuss, der sich aus Kollegen von Grace Hopper zusammensetzte, als Konkurrent von FLOW-MATIC angesehen. Einige ihrer Funktionen wurden nicht in COBOL übernommen, um den Eindruck zu vermeiden, dass IBM den Entwicklungsprozess dominiert hatte. Jean Sammet sagte 1981, dass einige Ausschussmitglieder (darunter auch sie selbst) eine "starke Anti-IBM-Einstellung" gehabt hätten. In einem Fall, nachdem Roy Goldfinger, Autor des COMTRAN-Handbuchs und Mitglied des Komitees für den mittleren Bereich, an einer Sitzung des Unterkomitees teilgenommen hatte, um seine Sprache zu unterstützen und die Verwendung algebraischer Ausdrücke zu fördern, schickte Grace Hopper ein Memo an das Komitee für den kurzen Bereich, in dem sie die Bemühungen von Sperry Rand um eine auf Englisch basierende Sprache wiederholte. 1980 bemerkte Grace Hopper, dass "COBOL 60 zu 95 % aus FLOW-MATIC besteht" und dass COMTRAN einen "extrem geringen" Einfluss gehabt habe. Außerdem sagte sie, dass sie behaupten würde, dass ihre Arbeit sowohl von FLOW-MATIC als auch von COMTRAN beeinflusst wurde, nur um "andere Leute bei Laune zu halten, damit sie nicht versuchen, uns zu verdrängen". Zu den Merkmalen von COMTRAN, die in COBOL übernommen wurden, gehörten Formeln, das PICTURE Klausel, eine verbesserte IF-Anweisung, die GO TOs überflüssig machte, und ein robusteres Dateiverwaltungssystem. ⓘ

Die Nützlichkeit der Arbeit des Ausschusses war Gegenstand heftiger Debatten. Während einige Mitglieder der Meinung waren, die Sprache weise zu viele Kompromisse auf und sei das Ergebnis des Entwurfs durch den Ausschuss, hielten andere sie für besser als die drei untersuchten Sprachen. Einige hielten die Sprache für zu komplex, andere für zu einfach. Zu den umstrittenen Merkmalen gehörten solche, die einige als nutzlos oder zu fortgeschritten für Datenverarbeitungsbenutzer betrachteten. Zu diesen Funktionen gehörten boolesche Ausdrücke, Formeln und Tabellen tiefgestellte Indizes (Indizes). Ein weiterer Streitpunkt war die Frage, ob Schlüsselwörter kontextabhängig sein sollten und welche Auswirkungen dies auf die Lesbarkeit haben würde. Obwohl kontextabhängige Schlüsselwörter abgelehnt wurden, wurde dieser Ansatz später in PL/I und teilweise in COBOL ab 2002 verwendet. Interaktivität, Interaktion mit Betriebssystemen (damals gab es nur wenige) und Funktionen (die als rein mathematisch angesehen wurden und für die Datenverarbeitung nicht von Nutzen waren) wurden kaum berücksichtigt. ⓘ

Die Spezifikationen wurden dem Exekutivausschuss am 4. September vorgelegt. Sie blieben hinter den Erwartungen zurück: Joseph Wegstein stellte fest, dass "sie grobe Stellen enthält und einige Ergänzungen erfordert", und Bob Bemer bezeichnete sie später als "Sammelsurium". Dem Unterausschuss wurde eine Frist bis Dezember eingeräumt, um ihn zu verbessern. ⓘ

In einer Sitzung Mitte September diskutierte der Ausschuss über den Namen der neuen Sprache. Vorgeschlagen wurden unter anderem "BUSY" (Business System), "INFOSYL" (Information System Language) und "COCOSYL" (Common Computer Systems Language). Es ist unklar, wer den Namen "COBOL" prägte, obwohl Bob Bemer später behauptete, es sei sein Vorschlag gewesen. ⓘ

Im Oktober erhielt der Zwischenausschuss Kopien der von Roy Nutt erstellten FACT-Spezifikation. Ihre Eigenschaften beeindruckten das Komitee so sehr, dass es einen Beschluss fasste, COBOL darauf aufzubauen. Dies war ein Rückschlag für den Kurzstreckenausschuss, der bei der Spezifikation gute Fortschritte gemacht hatte. Trotz seiner technischen Überlegenheit war FACT nicht mit Blick auf die Portabilität oder im Konsens mit Herstellern und Anwendern entwickelt worden. Außerdem fehlte es an einer vorzeigbaren Implementierung, so dass die Befürworter eines auf FLOW-MATIC basierenden COBOL die Resolution kippen konnten. Der RCA-Vertreter Howard Bromberg blockierte FACT ebenfalls, damit die Arbeit von RCA an einer COBOL-Implementierung nicht umsonst gewesen wäre. ⓘ

Es wurde bald deutlich, dass der Ausschuss zu groß war, um schnell weitere Fortschritte zu erzielen. Ein frustrierter Howard Bromberg kaufte einen 15-Dollar-Grabstein mit der Gravur "COBOL" und schickte ihn an Charles Phillips, um seinen Unmut zu zeigen. Es wurde ein Unterausschuss gebildet, der die bestehenden Sprachen analysieren sollte und aus sechs Personen bestand:

• William Selden und Gertrude Tierney von IBM,
• Howard Bromberg und Howard Discount von RCA,
• Vernon Reeves und Jean E. Sammet von Sylvania Electric Products. ⓘ

Der Unterausschuss leistete den größten Teil der Arbeit bei der Erstellung der Spezifikation und überließ es dem Kurzzeitausschuss, seine Arbeit zu überprüfen und zu ändern, bevor die fertige Spezifikation erstellt wurde. ⓘ

Die Spezifikationen wurden am 8. Januar 1960 vom Exekutivausschuss genehmigt und an die Regierungsdruckerei geschickt, die sie als COBOL 60 druckte. Die erklärten Ziele der Sprache waren die einfache Erstellung effizienter, portabler Programme, die Möglichkeit, mit minimalem Aufwand und geringen Kosten auf neue Systeme umzusteigen, und die Eignung für unerfahrene Programmierer. Der CODASYL-Exekutivausschuss gründete später den COBOL-Wartungsausschuss, um Fragen von Benutzern und Anbietern zu beantworten und die Spezifikationen zu verbessern und zu erweitern. ⓘ

Im Laufe des Jahres 1960 wuchs die Liste der Hersteller, die den Bau von COBOL-Compilern planten. Bis September waren fünf weitere Hersteller CODASYL beigetreten (Bendix, Control Data Corporation, General Electric (GE), National Cash Register und Philco), und alle vertretenen Hersteller hatten COBOL-Compiler angekündigt. GE und IBM planten, COBOL in ihre eigenen Sprachen, GECOM bzw. COMTRAN, zu integrieren. Im Gegensatz dazu plante International Computers and Tabulators, seine Sprache CODEL durch COBOL zu ersetzen. ⓘ

Inzwischen arbeiteten RCA und Sperry Rand an der Entwicklung von COBOL-Compilern. Das erste COBOL-Programm lief am 17. August auf einem RCA 501. Am 6. und 7. Dezember lief dasselbe COBOL-Programm (wenn auch mit geringfügigen Änderungen) auf einem RCA-Computer und einem Remington-Rand Univac-Computer, was bewies, dass Kompatibilität erreicht werden konnte. ⓘ

Der relative Einfluss der verwendeten Sprachen setzt sich bis heute in den empfohlenen Ratschlägen in allen COBOL-Referenzhandbüchern fort:

COBOL ist eine Industriesprache und ist nicht das Eigentum eines Unternehmens oder einer Unternehmensgruppe oder einer Organisation oder einer Gruppe von Organisationen.

Weder die Mitwirkenden noch der CODASYL-COBOL-Ausschuss übernehmen eine ausdrückliche oder stillschweigende Garantie für die Richtigkeit und Funktionsweise des Programmiersystems und der Sprache. Darüber hinaus wird von keinem der Mitwirkenden oder vom Ausschuss in diesem Zusammenhang eine Verantwortung übernommen. Die Autoren und Inhaber der Urheberrechte des hier verwendeten Materials sind wie folgt:

FLOW-MATIC (Warenzeichen der Unisys Corporation), Programming for the UNIVAC (R) I and II, Data Automation Systems, urheberrechtlich geschützt 1958, 1959, durch Unisys Corporation; IBM Commercial Translator Form No. F28-8013, urheberrechtlich geschützt 1959 durch IBM; FACT, DSI 27A5260-2760, urheberrechtlich geschützt 1960 durch Minneapolis-Honeywell.

Sie haben die Verwendung dieses Materials, ganz oder teilweise, in den COBOL-Spezifikationen ausdrücklich genehmigt. Diese Genehmigung erstreckt sich auf die Vervielfältigung und Verwendung der COBOL-Spezifikationen in Programmierhandbüchern oder ähnlichen Veröffentlichungen. ⓘ

COBOL entstand aus dem dringenden Wunsch, eine hardwareunabhängige, standardisierte, problemorientierte Sprache für die Erstellung von Programmen für den betriebswirtschaftlichen Bereich anwenden zu können. Die Programmierung kaufmännischer Anwendungen unterscheidet sich von technisch-wissenschaftlichen Anwendungen vor allem durch die Handhabung großer Datenmengen statt der Ausführung umfangreicher Berechnungen. Nachdem die Programmierung technisch-wissenschaftlicher Anwendungen durch FORTRAN bereits sehr vereinfacht worden war, sollte die neue Programmiersprache kaufmännische Problemstellungen, insbesondere die Handhabung großer Datenmengen und deren Ein- und Ausgabe stärker unterstützen – wozu bis dahin weitgehend Assemblersprachen verwendet wurden. ⓘ

Das Ergebnis wurde 1960 als COBOL-60 von CODASYL verabschiedet, in der Folgezeit weiterentwickelt und von nationalen und internationalen Normierungsinstituten (ANSI, ISO) standardisiert. ⓘ

COBOL fand schnell den Weg in die zivile Nutzung als eine der ersten kommerziell eingesetzten kompilierbaren Programmiersprachen und ist bis heute eine der am weitesten verbreiteten für kaufmännische Anwendungen. ⓘ

2020 entstand in den USA noch einmal Nachfrage nach COBOL-Entwicklern, als im Zuge der Corona-Pandemie die Arbeitslosenzahlen sprunghaft anstiegen, aber die Verwaltungssysteme der Arbeitslosenversicherung im US-Bundesstaat New Jersey der Nachfrage nicht mehr gewachsen waren. ⓘ

COBOL-61 bis COBOL-65

Es ist eher unwahrscheinlich, dass es Cobol bis zum Ende des Jahrzehnts noch geben wird.

Anonym, Juni 1960 ⓘ

In COBOL 60 wurden viele logische Fehler gefunden, was Charles Katz von GE zu der Warnung veranlasste, dass es nicht eindeutig interpretiert werden könne. Ein widerstrebendes Kurzzeit-Komitee führte eine vollständige Bereinigung durch, und im März 1963 wurde berichtet, dass die COBOL-Syntax genauso definierbar war wie die von ALGOL, obwohl semantische Unklarheiten bestehen blieben. ⓘ

Die frühen COBOL-Compiler waren primitiv und langsam. Eine Bewertung der US Navy aus dem Jahr 1962 ergab eine Kompiliergeschwindigkeit von 3-11 Anweisungen pro Minute. Bis Mitte 1964 stieg sie auf 11-1000 Anweisungen pro Minute an. Es wurde festgestellt, dass eine Vergrößerung des Speichers die Geschwindigkeit drastisch erhöhen würde und dass die Kompilierungskosten stark schwankten: Die Kosten pro Anweisung lagen zwischen 0,23 $ und 18,91 $. ⓘ

Ende 1962 gab IBM bekannt, dass COBOL ihre primäre Entwicklungssprache sein würde und dass die Entwicklung von COMTRAN eingestellt würde. ⓘ

Die COBOL-Spezifikation wurde in den fünf Jahren nach ihrer Veröffentlichung dreimal überarbeitet. COBOL-60 wurde 1961 durch COBOL-61 ersetzt. Diese wurde dann 1963 durch die erweiterten COBOL-61-Spezifikationen ersetzt, die die Sortier- und Report-Writer-Funktionen einführten. Die hinzugefügten Funktionen korrigierten Mängel, die Honeywell Ende 1959 in einem Schreiben an das Short-Range Committee festgestellt hatte. Die COBOL-Ausgabe 1965 brachte weitere Klarstellungen der Spezifikationen und führte Möglichkeiten zur Handhabung von Massenspeicherdateien und Tabellen ein. ⓘ

COBOL-68

Es begannen Bemühungen zur Standardisierung von COBOL, um Inkompatibilitäten zwischen den Versionen zu beseitigen. Ende 1962 bildeten sowohl die ISO als auch das United States of America Standards Institute (jetzt ANSI) Gruppen, um Standards zu schaffen. ANSI erstellte im August 1968 den USA Standard COBOL X3.23, der den Grundstein für spätere Versionen legte. Diese Version wurde als American National Standard (ANS) COBOL bekannt und wurde 1972 von der ISO übernommen. ⓘ

COBOL-74

Um 1970 war COBOL die weltweit am häufigsten verwendete Programmiersprache geworden. ⓘ

Unabhängig vom ANSI-Ausschuss arbeitete das CODASYL Programming Language Committee an der Verbesserung der Sprache. In den Jahren 1968, 1969, 1970 und 1973 wurden neue Versionen beschrieben, die u. a. neue Funktionen für die Kommunikation zwischen Programmen, die Fehlersuche und die Zusammenführung von Dateien sowie eine verbesserte Handhabung von Zeichenketten und die Einbindung von Bibliotheken enthielten. Obwohl CODASYL unabhängig vom ANSI-Komitee war, wurde das CODASYL Journal of Development vom ANSI benutzt, um Funktionen zu identifizieren, die populär genug waren, um eine Implementierung zu rechtfertigen. Der Programmiersprachenausschuss stand auch mit der ECMA und dem japanischen COBOL-Standardausschuss in Verbindung. ⓘ

Der Programmiersprachenausschuss war jedoch nicht sehr bekannt. Der Vizepräsident, William Rinehuls, beklagte, dass zwei Drittel der COBOL-Gemeinschaft nichts von der Existenz des Ausschusses wussten. Außerdem war er arm, da ihm die Mittel fehlten, um öffentliche Dokumente wie Sitzungsprotokolle und Änderungsvorschläge frei zugänglich zu machen. ⓘ

1974 veröffentlichte ANSI eine überarbeitete Version von (ANS) COBOL, die neue Funktionen wie Dateiorganisationen, das DELETE Anweisung und das Segmentierungsmodul. Gelöschte Funktionen waren die HINWEIS Anweisung, die EXAMINE Anweisung (die ersetzt wurde durch INSPECT) und das vom Implementierer definierte Modul für wahlfreien Zugriff (das durch die neuen sequentiellen und relativen E/A-Module ersetzt wurde). Insgesamt gab es 44 Änderungen, durch die bestehende Anweisungen nicht mehr mit dem neuen Standard kompatibel waren. Der Reportwriter sollte aus COBOL entfernt werden, wurde aber vor der Veröffentlichung des Standards wieder eingeführt. Die ISO nahm die aktualisierte Norm 1978 an. ⓘ

COBOL-85

Im Juni 1978 begann die Arbeit an der Überarbeitung von COBOL-74. Der vorgeschlagene Standard (gemeinhin als COBOL-80 bezeichnet) unterschied sich erheblich von der vorherigen Norm, was Bedenken hinsichtlich der Inkompatibilität und der Konvertierungskosten hervorrief. Im Januar 1981 drohte Joseph T. Brophy, Senior Vice-President von Travelers Insurance, das Standardkomitee zu verklagen, weil es nicht aufwärtskompatibel zu COBOL-74 war. Brophy bezeichnete frühere Konvertierungen ihrer 40 Millionen Zeilen umfassenden Codebasis als "unproduktiv" und als "völlige Verschwendung unserer Programmiererressourcen". Später im selben Jahr sprach sich die Data Processing Management Association (DPMA) "entschieden" gegen den neuen Standard aus und begründete dies mit "unerschwinglichen" Konvertierungskosten und Erweiterungen, die "dem Benutzer aufgezwungen" würden. ⓘ

Während der ersten öffentlichen Überprüfungsphase erhielt der Ausschuss 2.200 Antworten, von denen 1.700 negative Formbriefe waren. Andere Antworten waren detaillierte Analysen der Auswirkungen, die COBOL-80 auf ihre Systeme haben würde; die Konvertierungskosten wurden auf mindestens 50 Cent pro Codezeile geschätzt. Weniger als ein Dutzend der Antworten sprachen sich für den vorgeschlagenen Standard aus. ⓘ

ISO TC97-SC5 setzte 1979 auf Initiative von Wim Ebbinkhuijsen die internationale COBOL-Expertengruppe ein. Die Gruppe bestand aus COBOL-Experten aus vielen Ländern, darunter auch aus den Vereinigten Staaten. Ihr Ziel war es, gegenseitiges Verständnis und Respekt zwischen ANSI und dem Rest der Welt im Hinblick auf den Bedarf an neuen COBOL-Funktionen zu erreichen. Nach drei Jahren änderte die ISO den Status der Gruppe in eine formelle Arbeitsgruppe: WG 4 COBOL. Die Gruppe übernahm die Hauptverantwortung für die Entwicklung des COBOL-Standards, wobei ANSI die meisten Vorschläge machte. ⓘ

1983 zog das DPMA seinen Widerstand gegen die Norm zurück und begründete dies damit, dass der Ausschuss auf die Bedenken der Öffentlichkeit eingegangen sei. Im selben Jahr kam eine Studie des National Bureau of Standards zu dem Schluss, dass die vorgeschlagene Norm kaum Probleme aufwerfen würde. Ein Jahr später veröffentlichte DEC ein VAX/VMS-COBOL-80, in dem festgestellt wurde, dass die Konvertierung von COBOL-74-Programmen kaum Probleme bereitete. Die neue EVALUATE-Anweisung und das Inline-PERFORM wurden besonders positiv aufgenommen und verbesserten die Produktivität dank des vereinfachten Kontrollflusses und der Fehlersuche. ⓘ

Auf die zweite öffentliche Überprüfung gingen weitere 1.000 (hauptsächlich negative) Antworten ein, während auf die letzte nur 25 Antworten eingingen; zu diesem Zeitpunkt waren viele Bedenken bereits ausgeräumt. ⓘ

1985 akzeptierte die ISO-Arbeitsgruppe 4 die damalige Version des ANSI-Standardvorschlags, nahm einige Änderungen vor und legte ihn als neuen ISO-Standard COBOL 85 fest. Sie wurde Ende 1985 veröffentlicht. ⓘ

Sechzig Merkmale wurden geändert oder veraltet und 115 wurden hinzugefügt, wie z.B.:

• Bereichsabschlüsse (END-IF, END-PERFORM, END-READ usw.)
• Verschachtelte Unterprogramme
• CONTINUE, eine Nicht-Operations-Anweisung
• EVALUATE, eine Switch-Anweisung
• INITIALIZE, eine Anweisung, die Datengruppen auf ihre Standardwerte setzen kann
• Inline PERFORM-Schleifenkörper - früher mussten Schleifenkörper in einer separaten Prozedur angegeben werden
• Referenzmodifikation, die den Zugriff auf Teilstrings ermöglicht
• E/A-Statuscodes. ⓘ

Die neue Norm wurde von allen nationalen Normungsgremien, einschließlich ANSI, angenommen. ⓘ

Es folgten zwei Änderungen in den Jahren 1989 und 1993, wobei die erste intrinsische Funktionen einführte und die zweite Korrekturen enthielt. ⓘ

COBOL 2002 und objektorientiertes COBOL

1997 schätzte die Gartner Group, dass es insgesamt 200 Milliarden COBOL-Zeilen gab, auf denen 80 % aller Geschäftsprogramme liefen. ⓘ

Anfang der 1990er Jahre wurde damit begonnen, bei der nächsten vollständigen Überarbeitung von COBOL die Objektorientierung einzuführen. Die objektorientierten Funktionen wurden von C++ und Smalltalk übernommen. Ursprünglich war geplant, diese Überarbeitung bis 1997 abzuschließen, und ein ISO Committee Draft (CD) war 1997 bereits verfügbar. Einige Anbieter (darunter Micro Focus, Fujitsu und IBM) führten eine objektorientierte Syntax ein, die auf Entwürfen der vollständigen Überarbeitung basierte. Die endgültige ISO-Norm wurde Ende 2002 verabschiedet und veröffentlicht. ⓘ

Fujitsu/GTSoftware, Micro Focus und RainCode führten objektorientierte COBOL-Compiler für das .NET Framework ein. ⓘ

Es gab viele weitere neue Funktionen, von denen viele bereits seit 1978 im CODASYL COBOL Journal of Development enthalten waren und die es verpasst hatten, in COBOL-85 aufgenommen zu werden. Zu diesen anderen Funktionen gehören:

• Freiform-Code
• Benutzerdefinierte Funktionen
• Rekursion
• Lokalisierte Verarbeitung
• Unterstützung für erweiterte Zeichensätze wie Unicode
• Fließkomma- und Binärdatentypen (bis dahin wurden binäre Elemente auf der Grundlage der Basis-10-Spezifikation ihrer Deklaration abgeschnitten)
• Portable arithmetische Ergebnisse
• Bit- und boolesche Datentypen
• Zeiger und Syntax zum Abrufen und Freigeben von Speicher
• Die SCREEN-ABSCHNITT für textbasierte Benutzeroberflächen
• Die VALIDATE Einrichtung
• Verbesserte Interoperabilität mit anderen Programmiersprachen und Framework-Umgebungen wie .NET und Java. ⓘ

Für den Standard wurden drei Korrigenda veröffentlicht: zwei im Jahr 2006 und eine im Jahr 2009. ⓘ

COBOL 2014

Zwischen 2003 und 2009 wurden drei technische Berichte erstellt, die die Objektfinalisierung, die XML-Verarbeitung und die Sammelklassen für COBOL beschreiben. ⓘ

COBOL 2002 litt unter schlechter Unterstützung: Kein Compiler unterstützte den Standard vollständig. Micro Focus stellte fest, dass dies an der mangelnden Nachfrage der Benutzer nach den neuen Funktionen und an der Abschaffung der NIST-Testsuite lag, die zur Prüfung der Compiler-Konformität verwendet worden war. Auch der Standardisierungsprozess wurde als langsam und mit zu wenig Ressourcen ausgestattet eingestuft. ⓘ

COBOL 2014 enthält die folgenden Änderungen:

• Die portablen arithmetischen Ergebnisse wurden durch IEEE 754-Datentypen ersetzt.
• Wichtige Funktionen wurden optional gemacht, wie die VALIDATE-Funktion, der Report-Writer und die Screen-Handling-Funktion
• Überladen von Methoden
• Dynamische Kapazitätstabellen (eine Funktion, die aus dem Entwurf von COBOL 2002 gestrichen wurde) ⓘ

Altlasten

COBOL-Programme werden weltweit in Behörden und Unternehmen eingesetzt und laufen auf verschiedenen Betriebssystemen wie z/OS, z/VSE, VME, Unix, OpenVMS und Windows. Im Jahr 1997 berichtete die Gartner Group, dass 80 % der weltweiten Geschäftstätigkeit auf COBOL basiert, mit mehr als 200 Milliarden Codezeilen und weiteren 5 Milliarden Zeilen, die jährlich geschrieben werden. ⓘ

Gegen Ende des 20. Jahrhunderts stand das Jahr-2000-Problem (Y2K) im Mittelpunkt erheblicher COBOL-Programmieranstrengungen, manchmal von denselben Programmierern, die die Systeme Jahrzehnte zuvor entwickelt hatten. Der besondere Aufwand für die Korrektur von COBOL-Code wurde auf den großen Anteil an geschäftsorientiertem COBOL zurückgeführt, da Geschäftsanwendungen in hohem Maße Datumsangaben verwenden, sowie auf Datenfelder mit fester Länge. Einigen Studien zufolge entfallen bis zu 24 % der Reparaturkosten für Jahr-2000-Software auf Cobol. Nach der Bereinigung dieser Programme für das Jahr 2000 ergab eine Umfrage aus dem Jahr 2003, dass viele von ihnen weiterhin in Gebrauch sind. Die Autoren erklärten, dass die Umfragedaten darauf hindeuten, dass "die Bedeutung von COBOL in der Anwendungsentwicklung in den [folgenden] 10 Jahren allmählich abnehmen wird, es sei denn, die Integration mit anderen Sprachen und Technologien kann angenommen werden". ⓘ

In den Jahren 2006 und 2012 ergaben Computerworld-Umfragen (unter 352 Lesern), dass über 60 % der Unternehmen COBOL verwenden (mehr als C++ und Visual Basic .NET) und dass die Hälfte von ihnen COBOL für den Großteil ihrer internen Software einsetzt. 36 % der Manager gaben an, dass sie eine Migration von COBOL planen, und 25 % sagten, dass sie dies gerne tun würden, wenn es billiger wäre. Stattdessen haben einige Unternehmen ihre Systeme von teuren Mainframes auf billigere, modernere Systeme umgestellt, ihre COBOL-Programme aber beibehalten. ⓘ

Aus einer Aussage vor dem Repräsentantenhaus im Jahr 2016 geht hervor, dass COBOL noch immer von vielen Bundesbehörden verwendet wird. Reuters berichtete 2017, dass 43 % der Bankensysteme immer noch COBOL verwenden und über 220 Milliarden Zeilen COBOL-Code im Einsatz sind. ⓘ

Im Jahr 2019 wird die Zahl der COBOL-Programmierer aufgrund von Pensionierungen schnell schrumpfen, was zu einem drohenden Fachkräftemangel in Unternehmen und Behörden führen wird, die immer noch Mainframe-Systeme für die Verarbeitung großer Transaktionsvolumina verwenden. Bemühungen, Systeme in neueren Sprachen umzuschreiben, haben sich als kostspielig und problematisch erwiesen, ebenso wie die Auslagerung der Codewartung, so dass Vorschläge, mehr Menschen in COBOL auszubilden, befürwortet wurden. ⓘ

Während der COVID-19-Pandemie und des darauf folgenden Anstiegs der Arbeitslosigkeit meldeten mehrere US-Bundesstaaten einen Mangel an qualifizierten COBOL-Programmierern zur Unterstützung der für die Verwaltung der Arbeitslosenunterstützung verwendeten Altsysteme. Viele dieser Systeme waren bereits vor der Pandemie auf modernere Programmiersprachen umgestellt worden, aber der Prozess musste auf Eis gelegt werden. Auch die US-Steuerbehörde (Internal Revenue Service) beeilte sich, ihr COBOL-basiertes Individual Master File zu patchen, um die zig-Millionen-Zahlungen auszahlen zu können, die durch den Coronavirus Aid, Relief, and Economic Security Act vorgeschrieben waren. ⓘ

Merkmale

Syntax

COBOL hat eine englischsprachige Syntax, mit der fast alles in einem Programm beschrieben wird. Eine Bedingung kann zum Beispiel wie folgt ausgedrückt werden  x IST GRÖSSER ALS y oder prägnanter als  x GRÖSSER y  oder  x > y. Komplexere Bedingungen können "abgekürzt" werden, indem wiederholte Bedingungen und Variablen entfernt werden. Zum Beispiel,  a > b AND a > c OR a = d  kann abgekürzt werden zu a > b AND c OR = d. Um diese englischsprachige Syntax zu unterstützen, verfügt COBOL über mehr als 300 Schlüsselwörter. Bei einigen dieser Schlüsselwörter handelt es sich um einfache alternative oder pluralisierte Schreibweisen desselben Wortes, die für englischsprachige Aussagen und Klauseln sorgen; z. B. das IN und OF Schlüsselwörter können austauschbar verwendet werden, ebenso wie ZEIT und ZEITENund VALUE und VALUES. ⓘ

Jedes COBOL-Programm besteht aus vier grundlegenden lexikalischen Elementen: Wörter, Literale, Bildzeichenketten (siehe § PICTURE-Klausel) und Trennzeichen. Zu den Wörtern gehören reservierte Wörter und benutzerdefinierte Bezeichner. Sie sind bis zu 31 Zeichen lang und können Buchstaben, Ziffern, Bindestriche und Unterstriche enthalten. Zu den Literalen gehören Ziffern (z. B. 12) und Zeichenketten (z. B. 'Hallo!'). Zu den Trennzeichen gehören das Leerzeichen sowie Kommas und Semikolons gefolgt von einem Leerzeichen. ⓘ

Ein COBOL-Programm ist in vier Bereiche unterteilt: den Identifikationsbereich, den Umgebungsbereich, den Datenbereich und den Prozedurbereich. Der Identifikationsteil gibt den Namen und den Typ des Quellelements an und enthält die Angabe von Klassen und Schnittstellen. Die Umgebungsdivision spezifiziert alle Programmeigenschaften, die von dem System abhängen, auf dem das Programm läuft, wie Dateien und Zeichensätze. Die Datendivision wird zur Deklaration von Variablen und Parametern verwendet. Die Prozedurabteilung enthält die Anweisungen des Programms. Jede Abteilung ist in Abschnitte unterteilt, die wiederum aus Paragraphen bestehen. ⓘ

Metasprache

Die COBOL-Syntax wird in der Regel mit einer eigenen Metasprache beschrieben, die geschweifte Klammern, Balken und Unterstreichungen verwendet. Die Metasprache wurde für die ursprünglichen COBOL-Spezifikationen entwickelt. Obwohl die Backus-Naur-Form damals schon existierte, hatte der Ausschuss noch nichts davon gehört. ⓘ

Elemente der COBOL-Metasprache ⓘ

Element	Erscheinungsbild	Funktion
Alle Großbuchstaben	BEISPIEL	Reserviertes Wort
Unterstreichung	BEISPIEL	Das reservierte Wort ist obligatorisch
Klammern	{ }	Es darf nur eine Option ausgewählt werden
Klammern	[]	Es können null oder eine Option ausgewählt werden
Ellipse	...	Das vorangehende Element kann wiederholt werden
Balken	|}	Es können eine oder mehrere Optionen ausgewählt werden. Jede Option darf nur einmal ausgewählt werden.
	|]	Es können null oder mehr Optionen ausgewählt werden. Jede Option darf nur einmal ausgewählt werden.

Betrachten wir als Beispiel die folgende Beschreibung einer ADD-Anweisung: ${\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{ROUNDED}}}\,\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}}$ ⓘ

Diese Beschreibung lässt die folgenden Varianten zu:

ADD 1 TO x
ADD 1, a, b TO x ROUNDED, y, z ROUNDED <span title="Aus: Englische Wikipedia, Abschnitt &quot;Metalanguage&quot;" class="plainlinks">[https://en.wikipedia.org/wiki/COBOL#Metalanguage <span style="color:#dddddd">ⓘ</span>]</span>

ADD a, b TO c
    ON SIZE ERROR
        DISPLAY "Fehler"
END-ADD <span title="Aus: Englische Wikipedia, Abschnitt &quot;Metalanguage&quot;" class="plainlinks">[https://en.wikipedia.org/wiki/COBOL#Metalanguage <span style="color:#dddddd">ⓘ</span>]</span>

ADD a TO b
    NOT SIZE ERROR
        DISPLAY "Kein Fehler"
    ON SIZE FEHLER
        DISPLAY "Fehler"

ⓘ

Code-Format

COBOL kann in zwei Formaten geschrieben werden: fest (der Standard) oder frei. Im festen Format muss der Code so ausgerichtet werden, dass er in bestimmte Bereiche passt (ein Überbleibsel aus der Verwendung von Lochkarten). Bis COBOL 2002 waren dies folgende Bereiche:

Name	Spalte(n)	Verwendung ⓘ
Bereich für fortlaufende Nummern	1–6	Ursprünglich für Karten-/Zeilennummern verwendet (zur Erleichterung der maschinellen Lochkartensortierung, um die beabsichtigte Reihenfolge des Programmcodes nach der manuellen Bearbeitung sicherzustellen), wird dieser Bereich vom Compiler ignoriert
Indikator-Bereich	7	Die folgenden Zeichen sind hier erlaubt: * - Kommentarzeile / - Kommentarzeile, die auf einer neuen Seite eines Quelltext-Listings gedruckt wird - Fortsetzungszeile, in der Wörter oder Literale aus der vorherigen Zeile fortgesetzt werden D - Im Debugging-Modus aktivierte Zeile, die ansonsten ignoriert wird
Bereich A	8–11	Dieser Bereich enthält: DIVISION-, SECTION- und Prozedurenkopf; 01- und 77-Ebenen-Nummern und Datei-/Berichtsdeskriptoren
Bereich B	12–72	Jeder andere Code, der nicht in Bereich A erlaubt ist
Bereich für Programmnamen	73–	Historisch gesehen bis zur Spalte 80 für Lochkarten, wird er verwendet, um das Programm oder die Sequenz zu identifizieren, zu der die Karte gehört.

In COBOL 2002 wurden die Bereiche A und B zum Programmtextbereich zusammengelegt, der nun an einer vom Implementierer definierten Spalte endet. ⓘ

Mit COBOL 2002 wurde auch frei formatierter Code eingeführt. Frei formatierter Code kann, wie in neueren Programmiersprachen, in jeder Spalte der Datei platziert werden. Kommentare werden mit *> angegeben, die an beliebiger Stelle platziert werden können und auch in Quellcode mit festem Format verwendet werden können. Fortsetzungszeilen sind nicht vorhanden, und die >>PAGE-Direktive ersetzt den /-Indikator. ⓘ

Das traditionelle Kodierschema bei COBOL entspricht der Lochkarte mit ihren 80 Spalten, d. h. Schreibstellen. Dabei waren die ersten 6 Stellen für die Zeilennummerierungen reserviert. Spalte 7 wurde zur Kennzeichnung einer Kommentar- oder einer Fortsetzungszeile beziehungsweise einer, die nur für das Debugging übersetzt werden soll, reserviert. Spalte 8 bis 11 (Area A) beinhaltete die Namen von Divisions, Sections und Paragraphs. Die 12. bis 72. Spalte (Area B) beherbergten alles übrige, zum Beispiel Anweisungen (statements). Spalte 73 bis 80 waren für sonstige Markierungen wie z. B. den Namen des Programms oder Quelltext-Elementen vorgesehen. ⓘ

Die Standards ab 2002 kennen neben dem fixen Zeilenformat, das die Einteilung in Area A und Area B aufhebt, ein ganz freies Format, das in den Spalten 1 bis 255 alles erlaubt. Die Sonderrolle der Spalte 7 entfällt, da Kommentare mit *> eingeleitet, Literale mittels & zusammengesetzt und Debuggingzeilen mittels bedingter Übersetzung realisiert werden >>DEFINE … >>IF …. ⓘ

Ein fast minimales COBOL-Programm:

        Identification Division.
        Program-ID. HALLOPGM.
        Procedure Division.
            Display "Hallo Welt!".
            STOP RUN. <span title="Aus: Deutsche Wikipedia, Abschnitt &quot;Kodierung&quot;" class="plainlinks">[https://de.wikipedia.org/wiki/COBOL#Kodierung <span style="color:#dddddd">ⓘ</span>]</span>

Ursprünglich wurde COBOL nur in Großbuchstaben geschrieben, da nur Lochkarten und Zeilendrucker ohne Kleinbuchstaben zur Verfügung standen. Auch heute wird nicht zwischen Groß- und Kleinschreibung unterschieden. COBOL ist somit case insensitive. Ein COBOL-Programm ist in Teile (DIVISION), Kapitel (SECTION) und Abschnitte (PARAGRAPH) gegliedert. ⓘ

Die vier DIVISIONs sind in ihrer festgelegten Reihenfolge:

• Identification Division mit dem Programmnamen und einigen weitgehend obsoleten Paragraphen für Kommentare;
• Environment Division, wo Schnittstellen zum Betriebs- und dessen Dateisystem definiert werden;
• Data Division mit der Definition der Programmvariablen und Datenstrukturen und
• Procedure Division mit den prozeduralen Anweisungen. ⓘ

In der IDENTIFICATION DIVISION gibt es keine SECTIONs, und in der PROCEDURE DIVISION können neuerdings SECTIONs und auch PARAGRAPHs entfallen. ENVIRONMENT und DATA DIVISIONs können unter Umständen ganz entfallen. ⓘ

Hieran sieht man die strikte Trennung von Datendeklaration und prozeduralen Anweisungen, durch die sich COBOL auszeichnet. Im Prozedurteil kann man nur Variablen benutzen, die vorher im Datenteil deklariert worden sind. Auch das Aussehen von formatierten Ausgaben wird nicht im Prozedurteil, sondern im Datenteil durch die PICTURE-Klausel festgelegt. Der REPORT WRITER macht es möglich, die Struktur einer Druckliste komplett im Datenteil als physische Struktur von Seiten und logische Struktur von Postenzeilen mit Gruppensummen etc. zu beschreiben, ohne dass sich der Prozedurteil darum kümmern muss. ⓘ

Identifikationsteil

Die Identifikationsteilung identifiziert die folgende Codeeinheit und enthält die Definition einer Klasse oder Schnittstelle. ⓘ

Objektorientierte Programmierung

Klassen und Schnittstellen gibt es in COBOL seit 2002. Klassen haben Fabrikobjekte, die Klassenmethoden und Variablen enthalten, und Instanzobjekte, die Instanzmethoden und Variablen enthalten. Vererbung und Schnittstellen bieten Polymorphismus. Die generische Programmierung wird durch parametrisierte Klassen unterstützt, die instanziiert werden können, um jede Klasse oder Schnittstelle zu verwenden. Objekte werden als Referenzen gespeichert, die auf einen bestimmten Typ beschränkt sein können. Es gibt zwei Möglichkeiten, eine Methode aufzurufen: die INVOKE Anweisung, die ähnlich funktioniert wie die CALLoder durch den Inline-Methodenaufruf, der analog zur Verwendung von Funktionen ist. ⓘ

*> Diese sind gleichwertig.
INVOKE my-class "foo" RETURNING var
MOVE my-class:: "foo" TO var *> Inline-Methodenaufruf <span title="Aus: Englische Wikipedia, Abschnitt &quot;Object-oriented programming&quot;" class="plainlinks">[https://en.wikipedia.org/wiki/COBOL#Object-oriented_programming <span style="color:#dddddd">ⓘ</span>]</span>

In COBOL gibt es keine Möglichkeit, Methoden zu verstecken. Klassendaten können jedoch versteckt werden, indem man sie ohne ein PROPERTY Klausel deklariert werden, so dass der Benutzer keine Möglichkeit hat, auf sie zuzugreifen. Das Überladen von Methoden wurde in COBOL 2014 hinzugefügt. ⓘ

Bereich Umgebung

Die Environment-Division enthält den Konfigurationsabschnitt und den Input-Output-Abschnitt. Der Konfigurationsabschnitt wird verwendet, um variable Merkmale wie wie Währungszeichen, Gebietsschemata und Zeichensätze. Der Input-Output-Abschnitt enthält dateibezogene Informationen. ⓘ

Dateien

COBOL unterstützt drei Dateiformate, oder Organisationensequentiell, indiziert und relativ. In sequentiellen Dateien sind die Datensätze zusammenhängend und müssen ähnlich wie bei einer verketteten Liste sequentiell durchlaufen werden. Indizierte Dateien haben einen oder mehrere Indizes, die einen zufälligen Zugriff auf die Datensätze ermöglichen und nach ihnen sortiert werden können. Jeder Datensatz muss einen eindeutigen Schlüssel haben, aber andere, alternativenDatensatzschlüssel müssen nicht eindeutig sein. Die Implementierungen von Indexdateien variieren von Anbieter zu Anbieter, obwohl gängige Implementierungen, wie C-ISAM und VSAM, auf IBMs ISAM basieren. Relativdateien haben wie indizierte Dateien einen eindeutigen Datensatzschlüssel, aber sie haben keine Alternativschlüssel. Der Schlüssel eines relativen Datensatzes ist seine ordinale Position; so hat beispielsweise der 10. Dies bedeutet, dass die Erstellung eines Datensatzes mit dem Schlüssel 5 die Erstellung von (leeren) Vorgängersätzen erfordern kann. Relativdateien ermöglichen außerdem sowohl sequentiellen als auch zufälligen Zugriff. ⓘ

Eine übliche Nicht-Standard-Erweiterung ist die zeilensequentielle Organisation, die für die Verarbeitung von Textdateien verwendet wird. Die Datensätze in einer Datei werden durch einen Zeilenumbruch abgeschlossen und können unterschiedlich lang sein. ⓘ

Dateneinteilung

Die Datenabteilung ist in sechs Abschnitte unterteilt, in denen verschiedene Elemente deklariert werden: der Dateiabschnitt für Dateisätze; der Arbeitsspeicherabschnitt für statische Variablen; der lokale Speicherabschnitt für automatische Variablen; der Verknüpfungsabschnitt für Parameter und den Rückgabewert; der Berichtsabschnitt und der Bildschirmabschnitt für textbasierte Benutzeroberflächen. ⓘ

Aggregierte Daten

Datenelemente in COBOL werden hierarchisch durch die Verwendung von Ebenennummern deklariert, die angeben, ob ein Datenelement Teil eines anderen ist. Ein Element mit einer höheren Ebenennummer ist einem Element mit einer niedrigeren Nummer untergeordnet. Datenelemente der obersten Ebene, mit einer Ebenennummer von 1, werden als Datensätze. Elemente, die untergeordnete Aggregatdaten haben, werden als Gruppen-ElementeDiejenigen, die keine Aggregate haben, werden als Elementarteilchen. Die zur Beschreibung von Standarddatenelementen verwendeten Ebenennummern liegen zwischen 1 und 49. ⓘ

       01 some-record.                   *> Aggregat Gruppendatensatz Element
           05 num PIC 9(10).  *> Elementarer Eintrag
           05 the-date.                  *> Aggregat (Unter-)Gruppensatz-Element
               10 das-jahr PIC 9(4).   *> Elementarer Eintrag
               10 derMonat PIC 99.     *> Elementare Position
               10 der Tag PIC 99.     *> Elementare Position <span title="Aus: Englische Wikipedia, Abschnitt &quot;Aggregated data&quot;" class="plainlinks">[https://en.wikipedia.org/wiki/COBOL#Aggregated_data <span style="color:#dddddd">ⓘ</span>]</span>

Im obigen Beispiel ist die elementare Position num und die Gruppenposition das-datum sind dem Datensatz irgendein-Datensatzuntergeordnet, während die elementaren Elemente das Jahr, der-Monatund der Tag Teil der Gruppe item sind das-datum. ⓘ

Untergeordnete Elemente können mit dem IN (oder OF) Schlüsselwort. Betrachten Sie zum Beispiel den obigen Beispielcode zusammen mit dem folgenden Beispiel:

       01 sale-date.
           05 das-Jahr PIC 9(4).
           05 der-Monat PIC 99.
           05 der Tag PIC 99. <span title="Aus: Englische Wikipedia, Abschnitt &quot;Aggregated data&quot;" class="plainlinks">[https://en.wikipedia.org/wiki/COBOL#Aggregated_data <span style="color:#dddddd">ⓘ</span>]</span>

Die Namen das Jahr, der-Monatund der Tag sind an sich mehrdeutig, da mehr als ein Datenelement mit diesen Namen definiert ist. Um ein bestimmtes Datenelement zu spezifizieren, z. B. eines der Elemente, die in der Datei Verkaufsdatum Gruppe, würde der Programmierer Folgendes verwenden das-jahr-IN-verkauf-datum (oder das Äquivalent das-jahr-vom-verkaufsdatum). (Diese Syntax ähnelt der "Punktnotation", die von den meisten modernen Sprachen unterstützt wird). ⓘ

Andere Datenebenen

Eine Ebenennummer von 66 wird verwendet, um eine Umgruppierung von zuvor definierten Elementen zu deklarieren, unabhängig davon, wie diese Elemente strukturiert sind. Diese Datenebene, auf die auch die zugehörige RENAMES Klauselbezeichnet wird, wird selten verwendet und war um 1988 meist in alten Programmen zu finden. Aufgrund ihrer Fähigkeit, die hierarchischen und logischen Strukturdaten zu ignorieren, wurde ihre Verwendung nicht empfohlen, und viele Installationen verboten ihre Verwendung.

       01 kunden-datensatz.
           05 kunden-schlüssel PIC X(10).
           05 kunden-name.
               10 Kundenname-Vorname PIC X(30).
               10 cust-last-name PIC X(30).
           05 cust-dob PIC 9(8).
           05 cust-balance PIC 9(7)V99. <span title="Aus: Englische Wikipedia, Abschnitt &quot;Other data levels&quot;" class="plainlinks">[https://en.wikipedia.org/wiki/COBOL#Other_data_levels <span style="color:#dddddd">ⓘ</span>]</span>

       66 cust-personal-details RENAMES cust-name THRU cust-dob.
       66 cust-all-details RENAMES cust-name THRU cust-balance.

ⓘ

Eine Ebenennummer 77 zeigt an, dass es sich um eine eigenständige Position handelt, und entspricht in solchen Situationen der Ebenennummer 01. Der folgende Code deklariert zum Beispiel zwei Datenelemente der Ebene 77, Eigenschaft-Name und Verkaufsregiondeklariert, bei denen es sich um nicht gruppenspezifische Datenelemente handelt, die unabhängig von anderen Datenelementen sind (und diesen nicht untergeordnet sind):

       77 property-name PIC X(80).
       77 Verkaufsregion PIC 9(5). <span title="Aus: Englische Wikipedia, Abschnitt &quot;Other data levels&quot;" class="plainlinks">[https://en.wikipedia.org/wiki/COBOL#Other_data_levels <span style="color:#dddddd">ⓘ</span>]</span>

Eine 88-Ebenen-Nummer deklariert eine Bedingungsname (eine so genannte 88-Ebene), die wahr ist, wenn ihr übergeordnetes Datenelement einen der Werte enthält, die in ihrer VALUE Klausel angegebenen Werte enthält. Der folgende Code definiert beispielsweise zwei 88-stufige condition-name-Elemente, die je nach dem aktuellen Zeichendatenwert der Lohnart Datenelements abhängen. Wenn das Datenelement einen Wert von 'H'enthält, ist der Bedingungsname lohn-ist-stundenweise wahr, während er bei einem Wert von 'S' oder 'Y'enthält, ist der Bedingungsname lohn-ist-jährlich wahr ist. Wenn die Datenposition einen anderen Wert enthält, sind beide Bedingungsnamen falsch.

       01 lohnart PIC X.
           88 lohn-ist-stundenweise VALUE "H".
           88 lohn-ist-jährlich WERT "S", "Y". <span title="Aus: Englische Wikipedia, Abschnitt &quot;Other data levels&quot;" class="plainlinks">[https://en.wikipedia.org/wiki/COBOL#Other_data_levels <span style="color:#dddddd">ⓘ</span>]</span>

Datentypen

Standard-COBOL bietet die folgenden Datentypen:

Datentyp	Beispielhafte Deklaration	Hinweise ⓘ
Alphabetisch	PIC A(30)	Darf nur Buchstaben oder Leerzeichen enthalten.
Alphanumerisch	PIC X(30)	Darf beliebige Zeichen enthalten.
Boolesch	PIC 1 USAGE BIT	Daten, die in Form von 0en und 1en als Binärzahl gespeichert werden.
Index	USAGE INDEX	Wird verwendet, um auf Tabellenelemente zu verweisen.
National	PIC N(30)	Ähnlich wie alphanumerisch, aber unter Verwendung eines erweiterten Zeichensatzes, z. B. UTF-8.
Numerisch	PIC 9(5)V9(2)	Enthält genau 7 Ziffern (7=5+2). Das 'V' kennzeichnet die implizite Dezimalstelle in einer Festkommazahl.
Objekt	VERWENDUNG OBJEKTREFERENZ	Kann entweder auf ein Objekt oder auf NULL verweisen.
Zeiger	USAGE POINTER

Die Typsicherheit ist in COBOL variabel. Numerische Daten werden geräuschlos zwischen verschiedenen Darstellungen und Größen konvertiert, und alphanumerische Daten können in jedem Datenelement platziert werden, das als String gespeichert werden kann, einschließlich numerischer und Gruppendaten. Im Gegensatz dazu können Objektreferenzen und Zeiger nur aus Elementen desselben Typs zugewiesen werden und ihre Werte können auf einen bestimmten Typ beschränkt sein. ⓘ

PICTURE-Klausel

A PICTURE (oder PIC) ist eine Zeichenkette, die jeweils einen Teil des Datenelements und dessen möglichen Inhalt darstellt. Einige Bildzeichen geben den Typ des Elements an und wie viele Zeichen oder Ziffern es im Speicher einnimmt. Zum Beispiel zeigt ein 9 eine Dezimalstelle an, und ein S zeigt an, dass das Element vorzeichenbehaftet ist. Andere Bildzeichen (genannt Einfügung und Bearbeitung Zeichen) geben an, wie ein Element formatiert werden soll. Beispielsweise legt eine Reihe von + Zeichen die Zeichenpositionen sowie die Position eines Vorzeichens in den endgültigen Zeichendaten; das äußerste rechte nichtnumerische Zeichen enthält das Vorzeichen des Eintrags, während andere Zeichenpositionen, die einem + links von dieser Position entsprechen, ein Leerzeichen enthalten. Wiederholte Zeichen können prägnanter angegeben werden, indem man eine Zahl in Klammern nach einem Bildzeichen angibt; zum Beispiel, 9(7) ist gleichbedeutend mit 9999999. Bildangaben, die nur Ziffern (9) und Vorzeichen (S) enthalten, definieren reine numerische Datenelemente, während Bildspezifikationen, die alphabetische (A) oder alphanumerische (X) Zeichen enthalten, definieren alphanumerische Datenelemente. Das Vorhandensein von anderen Formatierungszeichen definiert bearbeitete numerische oder bearbeitete alphanumerische Datenelemente. ⓘ

Beispiele ⓘ

PICTURE Klausel	Wert ein	Wert aus
PIC 9(5)	100	00100
	"Hallo"	"Hallo" (dies ist legal, führt aber zu undefiniertem Verhalten)
PIC +++++	-10	" -10" (führende Leerzeichen beachten)
PIC 99/99/9(4)	31042003	"31/04/2003"
PIC *(4)9.99	100.50	"**100.50"
	0	"****0.00"
PIC X(3)BX(3)BX(3)	"ABCDEFGHI"	"ABC DEF GHI"

USAGE-Klausel

Die USAGE Klausel deklariert das Format, in dem die Daten gespeichert werden. Je nach Datentyp kann sie entweder ergänzend oder anstelle einer PICTURE Klausel verwendet werden. Sie kann zwar zur Deklaration von Zeigern und Objektreferenzen verwendet werden, ist aber hauptsächlich auf die Angabe numerischer Typen ausgerichtet. Diese numerischen Formate sind:

• Binär, wobei eine Mindestgröße entweder durch die PICTURE-Klausel oder durch eine USAGE-Klausel wie BINARY-LONG festgelegt wird.
• VERWENDUNGSBERECHNUNGwobei die Daten in einem beliebigen Format gespeichert werden können, das von der Implementierung bereitgestellt wird; oft gleichbedeutend mit  USAGE BINARY
• USAGE DISPLAYdas Standardformat, bei dem die Daten als Zeichenkette gespeichert werden
• Fließkomma, entweder in einem implementierungsabhängigen Format oder gemäß IEEE 754.
• USAGE NATIONAL, bei dem die Daten als Zeichenkette unter Verwendung eines erweiterten Zeichensatzes gespeichert werden
• USAGE PACKED-DECIMAL, bei dem die Daten im kleinstmöglichen Dezimalformat gespeichert werden (typischerweise gepackte binär codierte Dezimalzahlen) ⓘ

Berichtschreiber

Der Report Writer ist eine deklarative Funktion zur Erstellung von Berichten. Der Programmierer muss nur das Berichtslayout und die für die Erstellung des Berichts erforderlichen Daten angeben, so dass er keinen Code schreiben muss, um Dinge wie Seitenumbrüche, Datenformatierung, Überschriften und Fußzeilen zu behandeln. ⓘ

Berichte sind mit Berichtsdateien verknüpft, die nur mit Hilfe von Report-Writer-Anweisungen geschrieben werden können. ⓘ

       FD report-out REPORT Umsatzbericht. <span title="Aus: Englische Wikipedia, Abschnitt &quot;Report writer&quot;" class="plainlinks">[https://en.wikipedia.org/wiki/COBOL#Report_writer <span style="color:#dddddd">ⓘ</span>]</span>

Jeder Bericht wird in der Berichtssektion der Datenabteilung definiert. Ein Bericht ist in Berichtsgruppen aufgeteilt, die die Überschriften, Fußzeilen und Details des Berichts definieren. Berichte arbeiten mit hierarchischen Kontrollwechsel. Kontrollabbrüche treten auf, wenn eine Schlüsselvariable ihren Wert ändert; zum Beispiel könnte bei der Erstellung eines Berichts, der die Kundenbestellungen auflistet, ein Kontrollabbruch auftreten, wenn das Programm die Bestellungen eines anderen Kunden erreicht. Im Folgenden finden Sie eine Beispielbeschreibung für einen Bericht, der die Umsätze eines Verkäufers ausweist und vor ungültigen Datensätzen warnt:

       RD Umsatzbericht
           SEITENBEGRENZUNG 60 ZEILEN
           ERSTE DETAIL 3
           CONTROLS Verkäufer-Name. <span title="Aus: Englische Wikipedia, Abschnitt &quot;Report writer&quot;" class="plainlinks">[https://en.wikipedia.org/wiki/COBOL#Report_writer <span style="color:#dddddd">ⓘ</span>]</span>

       01 TYP SEITENÜBERSCHRIFT.
           03 COL 1 VALUE "Verkaufsbericht".
           03 SPALTE 74 WERT "Seite".
           03 SPALTE 79 BILD Z9 QUELLE SEITENZÄHLER. <span title="Aus: Englische Wikipedia, Abschnitt &quot;Report writer&quot;" class="plainlinks">[https://en.wikipedia.org/wiki/COBOL#Report_writer <span style="color:#dddddd">ⓘ</span>]</span>

       01 umsatz-am-tag TYP DETAIL, ZEILE + 1.
           03 COL 3 VALUE "Verkäufe am".
           03 COL 12 PIC 99/99/9999 SOURCE sales-date.
           03 COL 21 VALUE "waren".
           03 COL 26 PIC $$$$9.99 SOURCE sales-amount. <span title="Aus: Englische Wikipedia, Abschnitt &quot;Report writer&quot;" class="plainlinks">[https://en.wikipedia.org/wiki/COBOL#Report_writer <span style="color:#dddddd">ⓘ</span>]</span>

       01 ungültige-umsätze TYP DETAIL, ZEILE + 1.
           03 COL 3 VALUE "UNGÜLTIGER DATENSATZ:".
           03 COL 19 PIC X(34) SOURCE sales-record. <span title="Aus: Englische Wikipedia, Abschnitt &quot;Report writer&quot;" class="plainlinks">[https://en.wikipedia.org/wiki/COBOL#Report_writer <span style="color:#dddddd">ⓘ</span>]</span>

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

ⓘ

Die obige Berichtsbeschreibung beschreibt das folgende Layout:

Verkaufsbericht Seite 1 <span title="Aus: Englische Wikipedia, Abschnitt "Report writer"" class="plainlinks">[https://en.wikipedia.org/wiki/COBOL#Report_writer <span style="color:#dddddd">ⓘ</span>]</span>

Verkäufer: Howard Bromberg
  Die Verkäufe am 10/12/2008 betrugen $1000.00
  Die Verkäufe am 12.12.2008 betrugen $0.00
  Die Verkäufe am 13/12/2008 betrugen $31.47
  UNGÜLTIGER DATENSATZ: Howard Bromberg XXXXYY <span title="Aus: Englische Wikipedia, Abschnitt "Report writer"" class="plainlinks">[https://en.wikipedia.org/wiki/COBOL#Report_writer <span style="color:#dddddd">ⓘ</span>]</span>

Verkäufer: Howard Discount
...
Verkaufsbericht Seite 12 <span title="Aus: Englische Wikipedia, Abschnitt "Report writer"" class="plainlinks">[https://en.wikipedia.org/wiki/COBOL#Report_writer <span style="color:#dddddd">ⓘ</span>]</span>

  Der Umsatz am 08/05/2014 betrug $543.98
  UNGÜLTIGER DATENSATZ: William Selden 12O52014FOOFOO
  Die Verkäufe am 30/05/2014 betrugen $0.00

ⓘ

Vier Anweisungen steuern den Berichtschreiber: INITIATEbereitet den Report Writer auf den Druck vor; GENERATE, die eine Berichtsgruppe druckt; SUPPRESSunterdrückt den Druck einer Berichtsgruppe; und TERMINATEbeendet die Berichtsverarbeitung. Für das obige Beispiel des Umsatzberichts könnte die Prozeduraufteilung wie folgt aussehen:

           OPEN INPUT sales, OUTPUT report-out
           INITIATE Umsatzbericht <span title="Aus: Englische Wikipedia, Abschnitt &quot;Report writer&quot;" class="plainlinks">[https://en.wikipedia.org/wiki/COBOL#Report_writer <span style="color:#dddddd">ⓘ</span>]</span>

           AUSFÜHREN BIS 1 <> 1
               READ Verkäufe
                   AT END
                       PERFORM BEENDEN
               END-LEADEN <span title="Aus: Englische Wikipedia, Abschnitt &quot;Report writer&quot;" class="plainlinks">[https://en.wikipedia.org/wiki/COBOL#Report_writer <span style="color:#dddddd">ⓘ</span>]</span>

               VALIDIEREN des Verkaufsdatensatzes
               IF valid-record
                   GENERATE umsatz-am-tag
               ELSE
                   GENERIERE ungültige Verkäufe
               END-IF
           END-PERFORM <span title="Aus: Englische Wikipedia, Abschnitt &quot;Report writer&quot;" class="plainlinks">[https://en.wikipedia.org/wiki/COBOL#Report_writer <span style="color:#dddddd">ⓘ</span>]</span>

           TERMINATE Umsatz-Bericht
           CLOSE Verkäufe, Report-Out
           .

ⓘ

Die Nutzung der Report-Writer-Funktion variierte beträchtlich; einige Unternehmen nutzten sie ausgiebig, andere überhaupt nicht. Darüber hinaus waren die Implementierungen des Report Writers von unterschiedlicher Qualität, wobei die Implementierungen am unteren Ende der Skala manchmal übermäßig viel Speicher zur Laufzeit verbrauchten. ⓘ

Aufteilung der Prozeduren

Prozeduren

Die Abschnitte und Absätze in der Prozedurabteilung (zusammen Prozeduren genannt) können als Etiketten und als einfache Unterprogramme verwendet werden. Anders als in anderen Abteilungen müssen die Absätze nicht in Abschnitten stehen. Die Ausführung geht durch die Prozeduren eines Programms, bis es beendet wird. Um Prozeduren als Unterprogramme zu verwenden, muss der Befehl PERFORM Verb verwendet. ⓘ

A PERFORM Die PERFORM-Anweisung ähnelt in gewisser Weise einem Prozeduraufruf in einer modernen Sprache in dem Sinne, dass die Ausführung am Ende des aufgerufenen Codes zum Code zurückkehrt, der auf die PERFORM Anweisung folgenden Code zurückkehrt; sie bietet jedoch keinen Mechanismus zur Übergabe von Parametern oder zur Rückgabe eines Ergebniswertes. Wenn ein Unterprogramm mit einer einfachen Anweisung wie PERFORM Unterroutineaufgerufen wird, dann wird die Kontrolle am Ende der aufgerufenen Prozedur zurückgegeben. Allerdings, PERFORM ist jedoch insofern ungewöhnlich, als es zum Aufrufen eines Bereichs verwendet werden kann, der sich über eine Folge von mehreren benachbarten Prozeduren erstreckt. Dies geschieht mit der Anweisung PERFORM sub-1 THRU sub-n Konstrukt:

PROCEDURE so-und-so.
    PERFORM ALPHA
    ALPHA BIS GAMMA AUSFÜHREN
    STOPPEN LAUF.
ALPHA.
    DISPLAY 'A'.
BETA.
    ANZEIGE 'B'.
GAMMA.
    ANZEIGE 'C'. <span title="Aus: Englische Wikipedia, Abschnitt &quot;Procedures&quot;" class="plainlinks">[https://en.wikipedia.org/wiki/COBOL#Procedures <span style="color:#dddddd">ⓘ</span>]</span>

Die Ausgabe dieses Programms wird sein: "A A B C". ⓘ

PERFORM unterscheidet sich von konventionellen Prozeduraufrufen auch dadurch, dass es, zumindest traditionell, keinen Begriff für einen Aufrufstapel gibt. Infolgedessen sind verschachtelte Aufrufe möglich (eine Sequenz von Code, die PERFORM'ed kann eine PERFORM Anweisung selbst ausführen), erfordern aber besondere Sorgfalt, wenn Teile desselben Codes von beiden Aufrufen ausgeführt werden. Das Problem tritt auf, wenn der Code des inneren Aufrufs den Exit-Point des äußeren Aufrufs erreicht. Formaler ausgedrückt: Wenn die Kontrolle über den Exit-Point eines PERFORM Aufrufs durchläuft, der zuvor aufgerufen wurde, aber noch nicht abgeschlossen ist, legt der COBOL 2002-Standard offiziell fest, dass das Verhalten undefiniert ist. ⓘ

Der Grund dafür ist, dass COBOL nicht mit einer "Rücksprungadresse", sondern mit einer so genannten Fortsetzungsadresse arbeitet. Wenn der Kontrollfluss das Ende einer beliebigen Prozedur erreicht, wird die Fortsetzungsadresse nachgeschlagen und die Kontrolle an diese Adresse übertragen. Bevor das Programm läuft, wird die Fortsetzungsadresse für jede Prozedur auf die Startadresse der im Programmtext nächsten Prozedur initialisiert, so dass, wenn keine PERFORM Anweisungen passieren, die Kontrolle von oben nach unten durch das Programm fließt. Wenn jedoch eine PERFORM Anweisung ausgeführt wird, ändert sie die Fortsetzungsadresse der aufgerufenen Prozedur (oder der letzten Prozedur des aufgerufenen Bereichs, wenn PERFORM THRU verwendet wurde), so dass die Kontrolle am Ende an die Aufrufstelle zurückkehrt. Der ursprüngliche Wert wird gespeichert und anschließend wiederhergestellt, aber es gibt nur eine Speicherposition. Wenn zwei verschachtelte Aufrufe auf überlappendem Code arbeiten, können sie sich gegenseitig bei der Verwaltung der Fortsetzungsadresse auf verschiedene Weise stören. ⓘ

Das folgende Beispiel (entnommen aus Veerman & Verhoeven 2006) veranschaulicht das Problem:

LABEL1.
    ANZEIGE '1'
    LABEL2 BIS LABEL3 AUSFÜHREN
    STOPPEN LAUF.
LABEL2.
    ANZEIGE '2'
    LABEL3 BIS LABEL4 AUSFÜHREN.
LABEL3.
    ANZEIGE '3'.
LABEL4.
    ANZEIGE '4'. <span title="Aus: Englische Wikipedia, Abschnitt &quot;Procedures&quot;" class="plainlinks">[https://en.wikipedia.org/wiki/COBOL#Procedures <span style="color:#dddddd">ⓘ</span>]</span>

Man könnte erwarten, dass die Ausgabe dieses Programms "1 2 3 4 3" sein würde: Nach der Anzeige von "2" bewirkt die zweite PERFORM veranlasst die Anzeige von "3" und "4", und der erste Aufruf fährt mit "3" fort. In traditionellen COBOL-Implementierungen ist dies nicht der Fall. Vielmehr setzt die erste PERFORM Anweisung die Fortsetzungsadresse am Ende von LABEL3 so dass sie zurück zur Aufrufstelle innerhalb von LABEL1. Die zweite PERFORM Anweisung setzt den Rücksprung an das Ende von LABEL4 fest, ändert aber nicht die Fortsetzungsadresse von LABEL3nicht, da sie davon ausgeht, dass dies die Standardfortsetzung ist. Wenn also der innere Aufruf am Ende von LABEL3ankommt, springt er zurück zur äußeren PERFORM Anweisung zurück, und das Programm hört auf, nachdem es nur "1 2 3" gedruckt hat. In einigen COBOL-Implementierungen, wie dem Open-Source-Compiler TinyCOBOL, kommen sich die beiden PERFORM Anweisungen nicht ineinander, und die Ausgabe lautet tatsächlich "1 2 3 4 3". Daher ist das Verhalten in solchen Fällen nicht nur (vielleicht) überraschend, sondern auch nicht portabel. ⓘ

Eine besondere Folge dieser Einschränkung ist, dass PERFORM nicht verwendet werden kann, um rekursiven Code zu schreiben. Ein weiteres einfaches Beispiel, um dies zu veranschaulichen (leicht vereinfacht aus Veerman & Verhoeven 2006):

    MOVE 1 TO A
    PERFORM LABEL
    STOP RUN.
LABEL.
    A ANZEIGEN
    WENN A < 3
        ADD 1 TO A
        PERFORM LABEL
    END-IF
    DISPLAY 'END'. <span title="Aus: Englische Wikipedia, Abschnitt &quot;Procedures&quot;" class="plainlinks">[https://en.wikipedia.org/wiki/COBOL#Procedures <span style="color:#dddddd">ⓘ</span>]</span>

Man könnte erwarten, dass die Ausgabe "1 2 3 END END END" lautet, und in der Tat ist es das, was einige COBOL-Compiler erzeugen. Einige Compiler, wie IBM COBOL, erzeugen jedoch Code, der "1 2 3 END END END END ..." und so weiter ausgibt, wobei "END" immer wieder in einer Endlosschleife ausgegeben wird. Da der Platz zum Speichern von Backup-Fortsetzungsadressen begrenzt ist, werden die Backups bei rekursiven Aufrufen überschrieben, und alles, was wiederhergestellt werden kann, ist der Sprung zurück zu DISPLAY 'END'. ⓘ

Eine C-Schleife wie „for (i=0; i<10; ++i) {...}“ wird in COBOL mit PERFORM kodiert (COBOL85-Syntax):

    Perform Varying i From 0 By 1
              Until i >= 10
       ...
    End-Perform <span title="Aus: Deutsche Wikipedia, Abschnitt &quot;Schleifen&quot;" class="plainlinks">[https://de.wikipedia.org/wiki/COBOL#Schleifen <span style="color:#dddddd">ⓘ</span>]</span>

Anweisungen

COBOL 2014 hat 47 Anweisungen (auch als Verben), die sich in die folgenden großen Kategorien einteilen lassen: Kontrollfluss, E/A, Datenmanipulation und Report Writer. Die Report Writer-Anweisungen werden im Abschnitt Report Writer behandelt. ⓘ

Kontrollfluss

Die bedingten Anweisungen von COBOL sind IF und EVALUATE. EVALUATE ist eine switch-ähnliche Anweisung mit der zusätzlichen Möglichkeit, mehrere Werte und Bedingungen auszuwerten. Dies kann zur Implementierung von Entscheidungstabellen verwendet werden. Die folgende Anweisung könnte zum Beispiel zur Steuerung einer CNC-Drehmaschine verwendet werden: ⓘ

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
    WENN deckel geschlossen ALSO min-drehzahl THRU max-drehzahl ALSO GRÖSSER ALS SOLL-drehzahl
        PERFORM Verlangsamungs-Maschine
    WENN Deckel-geöffnet ALSO ALSO NICHT NULL
        PERFORM-Not-Halt
    WENN ANDERE
        FORTSETZEN
END-EVALUATE <span title="Aus: Englische Wikipedia, Abschnitt &quot;Control flow&quot;" class="plainlinks">[https://en.wikipedia.org/wiki/COBOL#Control_flow <span style="color:#dddddd">ⓘ</span>]</span>

Die PERFORM Anweisung wird verwendet, um Schleifen zu definieren, die ausgeführt werden bis eine Bedingung erfüllt ist (nicht während true, was in anderen Sprachen üblicher ist). Sie wird auch verwendet, um Prozeduren oder Bereiche von Prozeduren aufzurufen (siehe den Abschnitt Prozeduren für weitere Details). CALL und INVOKE rufen Unterprogramme bzw. Methoden auf. Der Name des Unterprogramms/der Methode ist in einer Zeichenkette enthalten, die ein Literal oder ein Datenelement sein kann. Parameter können als Referenz, als Inhalt (wenn eine Kopie als Referenz übergeben wird) oder als Wert (aber nur, wenn ein Prototyp verfügbar ist) übergeben werden. CANCEL entlädt Unterprogramme aus dem Speicher. SPRINGEN ZU veranlasst das Programm, zu einer bestimmten Prozedur zu springen. ⓘ

Die GOBACK Anweisung ist eine Rücksprunganweisung und die STOP Anweisung hält das Programm an. Die EXIT Anweisung hat sechs verschiedene Formate: Sie kann als Return-Anweisung, Break-Anweisung, Continue-Anweisung, Endmarkierung oder zum Verlassen einer Prozedur verwendet werden. ⓘ

Ausnahmen werden durch eine RAISE Anweisung ausgelöst und mit einem Handler abgefangen, oder deklarativeabgefangen, die in der Anweisung DECLARATIVES Teil der Prozedurabteilung definiert sind. Deklarative sind Abschnitte, die mit einem USE Anweisung beginnen, die die zu behandelnden Fehler angeben. Ausnahmen können Namen oder Objekte sein. RESUME wird in einem Deklarativ verwendet, um zu der Anweisung nach derjenigen zu springen, die die Ausnahme ausgelöst hat, oder zu einer Prozedur außerhalb der DECLARATIVES. Im Gegensatz zu anderen Sprachen führen nicht abgefangene Ausnahmen nicht zum Abbruch des Programms und das Programm kann unbeeinflusst fortgesetzt werden. ⓘ

E/A

Datei-E/A wird von der selbstbeschreibenden OPEN, CLOSE, READund WRITE Anweisungen sowie drei weitere: REWRITE, die einen Datensatz aktualisiert; START, die nachfolgende Datensätze für den Zugriff auswählt, indem sie einen Datensatz mit einem bestimmten Schlüssel findet, und UNLOCK, das die Sperre des zuletzt aufgerufenen Datensatzes aufhebt. ⓘ

Die Benutzerinteraktion erfolgt mit ACCEPT und ANZEIGEN. ⓘ

Datenmanipulation

Mit den folgenden Verben werden Daten manipuliert:

• INITIALIZE, die Datenelemente auf ihre Standardwerte setzt.
• MOVE, das Datenelementen Werte zuweist; MOVE CORRESPONDING weist entsprechende gleichnamige Felder zu.
• SET, das 15 Formate hat: Es kann unter anderem Indizes ändern, Objektreferenzen zuweisen und Tabellenkapazitäten ändern.
• ADD, SUBTRAHIEREN, MULTIPLY, TEILENund BERECHNENdie die Arithmetik behandeln (mit BERECHNEN Zuweisung des Ergebnisses einer Formel an eine Variable).
• ALLOCATE und FREE, die den dynamischen Speicher verwalten.
• VALIDATEValidieren und Verteilen von Daten, wie in der Beschreibung eines Elements in der Datenabteilung angegeben.
• STRING und UNSTRING, die Zeichenketten verketten bzw. aufteilen.
• INSPECTSTRING UNSTRING , die Instanzen bestimmter Teilzeichenketten innerhalb einer Zeichenkette zusammenfassen oder ersetzen.
• SUCHENsucht in einer Tabelle nach dem ersten Eintrag, der eine Bedingung erfüllt. ⓘ

Dateien und Tabellen werden sortiert mit SORT und der Funktion MERGE Verb führt Dateien zusammen und sortiert sie. Die RELEASE Verb liefert Datensätze zum Sortieren und RETURN ruft sortierte Datensätze in der richtigen Reihenfolge ab. ⓘ

Beendigung des Umfangs

Einige Anweisungen, wie z. B. IF und READ, können selbst Anweisungen enthalten. Solche Anweisungen können auf zwei Arten beendet werden: durch einen Punkt (implizite Beendigung), der alle enthaltenen nicht beendeten Anweisungen beendet, oder durch einen Scope-Terminator, der die nächstgelegene passende offene Anweisung beendet. ⓘ

*> Punkt als Abschluss ("implizite Beendigung")
IF ungültiger-Datensatz
    IF no-more-records
        NEXT SENTENCE
    ELSE
        READ record-file
            AT END SET no-more-records TO TRUE. <span title="Aus: Englische Wikipedia, Abschnitt &quot;Scope termination&quot;" class="plainlinks">[https://en.wikipedia.org/wiki/COBOL#Scope_termination <span style="color:#dddddd">ⓘ</span>]</span>

*> Bereichsterminatoren ("explizite Terminierung")
IF ungültiger-Datensatz
    IF no-more-records
        CONTINUE
    ELSE
        READ record-file
            AT END SET no-more-records TO TRUE
        END-READ
    END-IF
END-IF

ⓘ

Verschachtelte Anweisungen, die mit einem Punkt abgeschlossen werden, sind eine häufige Quelle von Fehlern. Betrachten Sie zum Beispiel den folgenden Code:

WENN x
    ANZEIGE y.
    ANZEIGE z. <span title="Aus: Englische Wikipedia, Abschnitt &quot;Scope termination&quot;" class="plainlinks">[https://en.wikipedia.org/wiki/COBOL#Scope_termination <span style="color:#dddddd">ⓘ</span>]</span>

Hier wird beabsichtigt, y und z anzuzeigen, wenn die Bedingung x wahr ist. Allerdings wird z unabhängig vom Wert von x angezeigt, da die IF-Anweisung durch einen fehlerhaften Punkt nach ANZEIGE y. ⓘ

Ein weiterer Fehler ergibt sich aus dem "dangling else"-Problem, wenn zwei IF-Anweisungen mit einem ELSE verknüpft werden können. ⓘ

IF x
    WENN y
        ANZEIGE a
ELSE
    ANZEIGE b. <span title="Aus: Englische Wikipedia, Abschnitt &quot;Scope termination&quot;" class="plainlinks">[https://en.wikipedia.org/wiki/COBOL#Scope_termination <span style="color:#dddddd">ⓘ</span>]</span>

In dem obigen Fragment ist das ELSE mit dem  IF y  Anweisung anstelle der  IF x  Anweisung, was einen Fehler verursacht. Vor der Einführung expliziter Bereichsabschlüsse hätte man zur Vermeidung dieses Fehlers  ELSE NÄCHSTER SATZ  nach dem inneren IF platziert werden. ⓘ

IF und ELSE funktionieren so, wie man es erwartet. Das End-If wurde erst mit dem COBOL85-Standard eingeführt. Im COBOL74-Standard wurde die IF-Anweisung noch durch einen Punkt beendet, was eine leicht zu übersehende Fehlerquelle darstellen konnte. ⓘ

COBOL68-Syntax:

    If Nenner > 0
         Compute Zahl = Zaehler / Nenner
    Else
         Display "Nenner sollte > 0 sein!"
         Move 0 To Zahl. <span title="Aus: Deutsche Wikipedia, Abschnitt &quot;IF/ELSE und EVALUATE&quot;" class="plainlinks">[https://de.wikipedia.org/wiki/COBOL#IF/ELSE_und_EVALUATE <span style="color:#dddddd">ⓘ</span>]</span>

EVALUATE macht die mehrfache Fallunterscheidung, womit jede Form von CASE oder Switch (wie in C), Folgen von IF/ELSIF/ELSIF/END-IF bis hin zu vollständigen Entscheidungstabellen dargestellt werden kann. Die Anweisung EVALUATE wurde erstmals in COBOL85 integriert, COBOL-Versionen vor der 85-Version kennen kein EVALUATE, so dass dort mehrfache Fallunterscheidungen über – teils schwierig zu lesende – IF-Konstrukte abgebildet werden mussten. ⓘ

    Evaluate True
        When  Nenner > 0
              Compute Zahl = Zaehler / Nenner
        When  Nenner < 0
              Compute Zahl = Zaehler / Nenner * -1
        When Other
              Display "Nenner sollte nicht 0 sein!"
              Move 0 To Zaehler
    End-Evaluate <span title="Aus: Deutsche Wikipedia, Abschnitt &quot;IF/ELSE und EVALUATE&quot;" class="plainlinks">[https://de.wikipedia.org/wiki/COBOL#IF/ELSE_und_EVALUATE <span style="color:#dddddd">ⓘ</span>]</span>

Selbstmodifizierender Code

Die ursprüngliche (1959) COBOL-Spezifikation unterstützte die berüchtigte  ALTER X TO PROCEED TO Y  Anweisung, für die viele Compiler selbstmodifizierenden Code erzeugten. X und Y sind Prozedurbezeichnungen, und die einzelne  SPRINGEN ZU  Anweisung in Prozedur X, die nach einer solchen ALTER Anweisung ausgeführt wird, bedeutet  GO TO Y  stattdessen. Viele Compiler unterstützen sie noch, aber sie wurde im COBOL-Standard 1985 als veraltet eingestuft und 2002 gestrichen. ⓘ

Die ALTER Die Anweisung GO TO Y war schlecht angesehen, weil sie die "Lokalität des Kontextes" untergrub und die Gesamtlogik eines Programms schwer verständlich machte. Wie der Lehrbuchautor Daniel D. McCracken 1976 schrieb, wenn "jemand, der das Programm noch nie zuvor gesehen hat, sich so schnell wie möglich damit vertraut machen muss, manchmal unter kritischem Zeitdruck, weil das Programm fehlgeschlagen ist ... der Anblick einer GO TO-Anweisung in einem Absatz allein, der die Existenz einer unbekannten Anzahl von ALTER-Anweisungen an unbekannten Stellen im Programm signalisiert, jagt auch dem mutigsten Programmierer Angst ein." ⓘ

Hallo, Welt

Ein "Hallo, Welt"-Programm in COBOL:

       IDENTIFIKATIONSABTEILUNG.
       PROGRAM-ID. hallo-world.
       PROZEDURABTEILUNG.
           DISPLAY "Hallo, Welt!"
           . <span title="Aus: Englische Wikipedia, Abschnitt &quot;Hello, world&quot;" class="plainlinks">[https://en.wikipedia.org/wiki/COBOL#Hello,_world <span style="color:#dddddd">ⓘ</span>]</span>

Als das - inzwischen berühmte - "Hello, World!"-Programmbeispiel in The C Programming Language 1978 zum ersten Mal veröffentlicht wurde, wäre ein ähnliches COBOL-Mainframe-Programmbeispiel über JCL übermittelt worden, höchstwahrscheinlich unter Verwendung eines Lochkartenlesers und 80-spaltiger Lochkarten. Das nachstehende Listing mit einer leeren DATA DIVISION wurde mit Linux und dem System/370 Hercules-Emulator unter MVS 3.8J getestet. Die JCL, die im Juli 2015 geschrieben wurde, stammt aus den Hercules-Tutorials und -Beispielen von Jay Moseley. Im Einklang mit der COBOL-Programmierung dieser Ära wird HELLO, WORLD in Großbuchstaben angezeigt. ⓘ

//COBUCLG JOB (001),'COBOL BASE TEST', 00010000
// CLASS=A,MSGCLASS=A,MSGLEVEL=(1,1) 00020000
//BASETEST EXEC COBUCLG 00030000
//COB.SYSIN DD * 00040000
 00000* VALIDIERUNG DER COBOL-BASISINSTALLATION 00050000
 01000 IDENTIFIZIERUNG DIVISION.                                         00060000
 01100 PROGRAMM-ID. 'HELLO'.                                             00070000
 02000 ABTEILUNG UMGEBUNG.                                            00080000
 02100 KONFIGURATIONSBEREICH.                                           00090000
 02110 QUELL-RECHNER.  GNULINUX.                                      00100000
 02120 OBJEKT-RECHNER.  HERCULES.                                      00110000
 02200 SPEZIAL-NAMEN.                                                   00120000
 02210 KONSOLE IST KONSL.                                            00130000
 03000 DATENAUFTEILUNG.                                                   00140000
 04000 VERFAHRENSTEILUNG.                                              00150000
 04100 00-MAIN.                                                         00160000
 04110 ANZEIGE 'HALLO, WELT' BEI KONSL.                           00170000
 04900 LAUF ANHALTEN.                                                    00180000
//LKED.SYSLIB DD DSNAME=SYS1.COBLIB,DISP=SHR 00190000
// DD DSNAME=SYS1.LINKLIB,DISP=SHR 00200000
//GO.SYSPRINT DD SYSOUT=A 00210000
// 00220000 <span title="Aus: Englische Wikipedia, Abschnitt &quot;Hello, world&quot;" class="plainlinks">[https://en.wikipedia.org/wiki/COBOL#Hello,_world <span style="color:#dddddd">ⓘ</span>]</span>

Nach dem Absenden der JCL wird die MVS-Konsole angezeigt:

    19.52.48 JOB 3 $HASP100 COBUCLG AUF READER1 COBOL BASE TEST
    19.52.48 JOB 3 IEF677I WARNMELDUNG(EN) FÜR JOB COBUCLG AUSGEGEBEN
    19.52.48 JOB 3 $HASP373 COBUCLG GESTARTET - INIT 1 - KLASSE A - SYS BSP1
    19.52.48 JOB 3 IEC130I SYSPUNCH DD ANWEISUNG FEHLT
    19.52.48 JOB 3 IEC130I SYSLIB DD ANWEISUNG FEHLT
    19.52.48 JOB 3 IEC130I SYSPUNCH DD ANWEISUNG FEHLT
    19.52.48 JOB 3 IEFACTRT - Schrittname Procstep Programm 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 +HALLO, WELT
    19.52.48 JOB 3 COBUCLG BASETEST GO PGM=*.DD RC= 0000
    19.52.48 JOB 3 $HASP395 COBUCLG BEENDET <span title="Aus: Englische Wikipedia, Abschnitt &quot;Hello, world&quot;" class="plainlinks">[https://en.wikipedia.org/wiki/COBOL#Hello,_world <span style="color:#dddddd">ⓘ</span>]</span>

Zeile 10 des obigen Konsolenlistings ist zur Verdeutlichung hervorgehoben, die Hervorhebung ist nicht Teil der eigentlichen Konsolenausgabe. ⓘ

Das zugehörige Compiler-Listing erzeugte mehr als vier Seiten mit technischen Details und Informationen zum Job-Lauf für die einzige Zeile der Ausgabe von 14 Zeilen COBOL. ⓘ

Empfang

Fehlende Struktur

In den 1970er Jahren setzte sich das Paradigma der strukturierten Programmierung immer mehr durch. Edsger Dijkstra, ein herausragender Informatiker, schrieb 1975 einen Brief an den Herausgeber der Communications of the ACM mit dem Titel "How do we tell truths that might hurt?" (Wie sagen wir Wahrheiten, die weh tun könnten), in dem er COBOL und mehrere andere zeitgenössische Sprachen kritisierte und bemerkte, dass "die Verwendung von COBOL den Verstand verkrüppelt". In einem veröffentlichten Widerspruch zu Dijkstras Ausführungen behauptete der Informatiker Howard E. Tompkins, dass unstrukturiertes COBOL tendenziell "von Programmierern geschrieben wird, die nie in den Genuss einer guten Ausbildung in strukturiertem COBOL gekommen sind", und vertrat die Ansicht, dass das Problem in erster Linie eine Frage der Ausbildung ist. ⓘ

Eine Ursache für den Spaghetti-Code war die SPRINGEN ZU Anweisung. Versuche, das SPRINGEN ZUs aus dem COBOL-Code zu entfernen, führten jedoch zu unübersichtlichen Programmen und einer geringeren Codequalität. SPRINGEN ZUs wurden weitgehend ersetzt durch die PERFORM Anweisung und Prozeduren ersetzt, die die modulare Programmierung förderten und einfachen Zugang zu leistungsstarken Schleifen ermöglichten. Allerdings PERFORM nur in Verbindung mit Prozeduren verwendet werden, so dass die Schleifenkörper nicht dort zu finden waren, wo sie gebraucht wurden, was das Verständnis der Programme erschwerte. ⓘ

COBOL-Programme waren berüchtigt für ihre Monolithizität und fehlende Modularisierung. COBOL-Code konnte nur durch Prozeduren modularisiert werden, die sich für große Systeme als unzureichend erwiesen. Es war nicht möglich, den Zugriff auf Daten einzuschränken, d. h. eine Prozedur konnte auf jede beliebige Datei zugreifen und diese verändern. jedes Datenelement. Außerdem gab es keine Möglichkeit, Parameter an eine Prozedur zu übergeben, ein Versäumnis, das Jean Sammet als den größten Fehler des Ausschusses bezeichnete. Eine weitere Komplikation ergab sich aus der Möglichkeit, eine PERFORM THRU eine bestimmte Abfolge von Prozeduren. Dies bedeutete, dass die Kontrolle zu jeder beliebigen Prozedur springen und von ihr zurückkehren konnte, was zu einem verworrenen Kontrollfluss führte und es dem Programmierer ermöglichte, die Regel "Single Entry - Single Exit" zu umgehen. ⓘ

Diese Situation verbesserte sich, als COBOL weitere Funktionen aufnahm. COBOL-74 fügte Unterprogramme hinzu und gab dem Programmierer die Möglichkeit, die Daten zu kontrollieren, auf die jeder Teil des Programms zugreifen konnte. COBOL-85 fügte dann verschachtelte Unterprogramme hinzu, die es den Programmierern ermöglichten, Unterprogramme zu verbergen. Eine weitere Kontrolle über Daten und Code kam 2002 hinzu, als die objektorientierte Programmierung, benutzerdefinierte Funktionen und benutzerdefinierte Datentypen eingeführt wurden. ⓘ

Dennoch verwenden viele wichtige COBOL-Altanwendungen unstrukturierten Code, der unwartbar geworden ist. Es kann zu riskant und kostspielig sein, auch nur einen einfachen Codeabschnitt zu ändern, da er an unbekannten Stellen auf unbekannte Weise verwendet werden könnte. ⓘ

Kompatibilitätsprobleme

COBOL sollte eine hochgradig portable, "gemeinsame" Sprache sein. Bis 2001 wurden jedoch etwa 300 Dialekte geschaffen. Eine Quelle für Dialekte war der Standard selbst: Der Standard von 1974 bestand aus einem obligatorischen Kern und elf Funktionsmodulen, die jeweils zwei oder drei Unterstützungsebenen enthielten. Dies ermöglichte 104.976 offizielle Varianten. ⓘ

COBOL-85 war nicht vollständig kompatibel mit früheren Versionen, und seine Entwicklung war umstritten. Joseph T. Brophy, der CIO von Travelers Insurance, setzte sich dafür ein, die COBOL-Benutzer über die hohen Umprogrammierungskosten zu informieren, die mit der Implementierung des neuen Standards verbunden waren. Daraufhin erhielt der ANSI COBOL-Ausschuss mehr als 2.200 Briefe aus der Öffentlichkeit, die meisten davon negativ, so dass der Ausschuss gezwungen war, Änderungen vorzunehmen. Andererseits ging man davon aus, dass die Umstellung auf COBOL-85 die Produktivität in den kommenden Jahren erhöhen würde, was die Umstellungskosten rechtfertigte. ⓘ

Ausführliche Syntax

COBOL: /koh′bol/, n.

Eine schwache, langatmige und schlaffe Sprache, die von Programmierern verwendet wurde, um langweilige, geistlose Dinge auf Dinosaurier-Mainframes zu erledigen. [...] Schon ihr Name wird selten ohne rituelle Ausdrücke des Ekels oder des Entsetzens ausgesprochen.

Die Jargon-Datei 4.4.8. ⓘ

Die COBOL-Syntax ist oft wegen ihrer Ausführlichkeit kritisiert worden. Befürworter sagen, dass dies dazu gedacht war, den Code selbstdokumentierend zu machen und die Programmwartung zu erleichtern. Außerdem sollte COBOL für Programmierer leicht zu erlernen und zu verwenden sein, aber auch für nichttechnisches Personal wie Manager lesbar sein. Der Wunsch nach Lesbarkeit führte zur Verwendung einer dem Englischen ähnlichen Syntax und von Strukturelementen wie Substantiven, Verben, Klauseln, Sätzen, Abschnitten und Unterteilungen. Doch 1984 hatten die Betreuer von COBOL-Programmen mit "unverständlichem" Code zu kämpfen, und die wichtigsten Änderungen in COBOL-85 dienten dazu, die Wartung zu erleichtern. ⓘ

Jean Sammet, ein Mitglied des Kurzzeitkomitees, merkte an, dass "wenig versucht wurde, den professionellen Programmierern entgegenzukommen; tatsächlich sind Leute, deren Hauptinteresse das Programmieren ist, sehr unglücklich mit COBOL", was sie auf die ausführliche Syntax von COBOL zurückführte. ⓘ

Isolation von der Informatikgemeinschaft

Die COBOL-Gemeinschaft war immer von der Informatik-Gemeinschaft isoliert. An der Entwicklung von COBOL waren keine akademischen Informatiker beteiligt: Alle Mitglieder des Ausschusses kamen aus der Wirtschaft oder der Regierung. Informatiker interessierten sich damals mehr für Bereiche wie numerische Analyse, Physik und Systemprogrammierung als für die kommerziellen Dateiverarbeitungsprobleme, mit denen sich die COBOL-Entwicklung befasste. Jean Sammet führte die Unbeliebtheit von COBOL auf eine anfängliche "Snob-Reaktion" zurück, die auf seine Ungeschicklichkeit, das Fehlen einflussreicher Informatiker, die am Entwurfsprozess beteiligt waren, und eine Geringschätzung der Datenverarbeitung in Unternehmen zurückzuführen war. Die COBOL-Spezifikation verwendete eine eigene "Notation" oder Metasprache, um ihre Syntax zu definieren, und nicht die neue Backus-Naur-Form, die dem Ausschuss nicht bekannt war. Dies führte zu "heftiger" Kritik. ⓘ

Später litt COBOL unter einem Mangel an Material, das es abdeckte; es dauerte bis 1963, bis Einführungsbücher erschienen (Richard D. Irwin veröffentlichte 1966 ein College-Lehrbuch über COBOL). Bis 1985 gab es in der Library of Congress doppelt so viele Bücher über FORTRAN und viermal so viele über BASIC wie über COBOL. Die Universitätsprofessoren lehrten modernere, dem Stand der Technik entsprechende Sprachen und Techniken anstelle von COBOL, dem man einen "Berufsschulcharakter" nachsagte. Donald Nelson, Vorsitzender des CODASYL-COBOL-Ausschusses, sagte 1984, dass "Akademiker ... COBOL hassen" und dass Informatikabsolventen "COBOL hassen" eingebläut worden sei. ⓘ

Mitte der 1980er Jahre wurde COBOL in der Geschäftswelt auch von Benutzern anderer Sprachen, z. B. FORTRAN oder Assembler, herablassend behandelt, indem man ihnen unterstellte, dass COBOL nur für weniger anspruchsvolle Probleme verwendet werden könne. ⓘ

Im Jahr 2003 war COBOL in 80 % der Lehrpläne für Wirtschaftsinformatik in den Vereinigten Staaten enthalten, was dem Anteil von C++ und Java entspricht. Zehn Jahre später ergab eine Umfrage von Micro Focus, dass 20 % der Hochschullehrer COBOL für veraltet oder tot hielten und 55 % der Meinung waren, ihre Studenten hielten COBOL für veraltet oder tot. Dieselbe Umfrage ergab auch, dass nur 25 % der Akademiker COBOL-Programmierung in ihrem Lehrplan hatten, obwohl 60 % der Meinung waren, dass sie es unterrichten sollten. ⓘ

Bedenken bezüglich des Entwurfsprozesses

Es wurden Zweifel an der Kompetenz des Normenausschusses geäußert. Das kurzzeitige Ausschussmitglied Howard Bromberg sagte, dass es "wenig Kontrolle" über den Entwicklungsprozess gab und dass er "von personellen Diskontinuitäten und ... einem Mangel an Talent geplagt war." Jean Sammet und Jerome Garfunkel merkten auch an, dass Änderungen, die in einer Revision des Standards eingeführt wurden, in der nächsten wieder rückgängig gemacht wurden, und zwar sowohl aufgrund von Änderungen in der Zusammensetzung des Standardkomitees als auch aufgrund objektiver Fakten. ⓘ

COBOL-Standards haben wiederholt unter Verzögerungen gelitten: COBOL-85 kam fünf Jahre später als erhofft, COBOL 2002 kam fünf Jahre zu spät, und COBOL 2014 kam sechs Jahre zu spät. Um den Verzögerungen entgegenzuwirken, erlaubte der Standardisierungsausschuss die Erstellung von optionalen Ergänzungen, mit denen Funktionen schneller hinzugefügt werden können, als wenn man auf die nächste Standardüberarbeitung wartet. Einige Ausschussmitglieder äußerten jedoch Bedenken über Inkompatibilitäten zwischen Implementierungen und häufige Änderungen der Norm. ⓘ

Einflüsse auf andere Sprachen

Die Datenstrukturen von COBOL haben nachfolgende Programmiersprachen beeinflusst. Seine Record- und Dateistruktur beeinflusste PL/I und Pascal, und die REDEFINES-Klausel war ein Vorläufer der Variant Records von Pascal. Explizite Definitionen von Dateistrukturen gingen der Entwicklung von Datenbankmanagementsystemen voraus, und aggregierte Daten waren ein bedeutender Fortschritt gegenüber den Arrays von Fortran. Die PICTURE-Datendeklarationen wurden mit geringfügigen Änderungen in PL/I übernommen. ⓘ

COBOLs COPY Funktion von COBOL, obwohl sie als "primitiv" angesehen wird, beeinflusste die Entwicklung von Include-Anweisungen. ⓘ

Der Schwerpunkt auf Portabilität und Standardisierung bedeutete, dass in COBOL geschriebene Programme portabel sein konnten, und erleichterte die Verbreitung der Sprache auf einer Vielzahl von Hardwareplattformen und Betriebssystemen. Außerdem beschränkt die klar definierte Divisionsstruktur die Definition externer Referenzen auf die Environment Division, was insbesondere Plattformwechsel vereinfacht. ⓘ

Prozedurale Anweisungen

Einfache Codeschnipsel

Zur Darstellung der Syntax wird einfache C-Syntax zu Hilfe genommen. ⓘ

• Eine Zuweisung a = b in C

entspricht in COBOL MOVE b TO a

• Arithmetische Ausdrücke und Zuweisungen:

• a = b + c

kann in COBOL folgendermaßen geschrieben werden: ADD b TO c GIVING a

oder alternativ COMPUTE a = b + c

• analog b = a - 1 in C

entspricht in COBOL SUBTRACT 1 FROM a GIVING b

• Der Inkrementoperator ++a in C

entspricht in COBOL ADD 1 TO a

• Der Dekrementoperator --a in C

entspricht in COBOL SUBTRACT 1 FROM a ⓘ

Entwicklung und Standardisierung

Erweiterungen durch X/Open, die Open Group

Im Rahmen der Bemühungen um einen Standard für das Betriebssystem Unix durch die Industrievereinigung X/Open wurden dafür auch Spezifikationen für COBOL vereinbart, deren jüngste von 1991 aus den höchsten Stufen der vorgeschriebenen Module von COBOL-85 besteht, mit der Erweiterung von 1989 durch die „Intrinsic Functions“, aber ohne Report-Writer, Segmentierung und Debugging, dafür aber mit eigenen Erweiterungen für Interaktion mit Bildschirmformularen (SCREEN SECTION und ACCEPT/DISPLAY), gemeinsamen Zugriff auf Dateien mit Sperren auf Dateien und Sätze, sowie Internationalisierung mit z. B. Doppelbyte-Zeichensätzen. ⓘ

Module und standardkonforme Implementierungen

COBOL-68, COBOL-74 und COBOL-85 ordneten die verschiedenen Features der Sprache einem Modul mit jeweils einem bis drei „Levels“ zu, woraus dann minimale und volle Implementierungen des Standards als Kombination von bestimmten Levels der jeweiligen Module definiert wurden. Eine mit COBOL-2002 konforme Implementierung muss den gesamten Sprachumfang implementieren. ⓘ

COBOL-Compiler

Für Computer der Klassen „Großrechner“ und „Mittlere Datentechnik“ boten und bieten deren jeweilige Hersteller – IBM, Unisys, Siemens, Fujitsu-Siemens, HP, Bull u. a. – auf ihre proprietären Betriebssysteme zugeschnittene COBOL-Compiler an, z. T. verschiedene Compiler, die beispielsweise verschiedenen Standards entsprechen. ⓘ

Für Betriebssysteme, die aus der UNIX- bzw. MS-DOS-Tradition entstanden sind, gibt es COBOL-Compiler von verschiedenen Software-Herstellern. Mit GnuCOBOL existiert eine quelloffene Implementierung der Programmiersprache. ⓘ

COBOL-Generatoren

Es gibt Codegeneratoren, die COBOL-Programme bzw. Teile davon generieren und so die Entwicklungsarbeit erleichtern. Dazu gehören zum Beispiel SWT01 und SWT/VDA von dem Hersteller FSP, CA Gen (ehemals Cool:Gen) von CA Technologies, sowie die Generatorsysteme ADSplus und SCORE von Delta Software Technology. ⓘ