COBOL – Wikipedia

Programmiersprache mit englischähnlicher Syntax

COBOL

Das Cover der COBOL 60 Bericht an CODASYL (April 1960)
Paradigma	Prozedural, Imperativ, Objektorientiert
Entworfen von	Howard Bromberg, Norman-Rabatt, Vernon Reeves, Jean E. Sammet, William Selden, Gertrude Tierney, mit indirektem Einfluss von Grace Hopper[1]
Entwickler	CODASYL, ANSI, ISO
Erstmals erschienen	1959; Vor 62 Jahren (1959)
Stabile Version	ISO/IEC 1989: 2014 / 2014
Schreibdisziplin	Schwach, statisch
Dateinamenerweiterungen	.cbl, .cob, .cpy
GnuCOBOL, IBM COBOL, Micro Focus Visual COBOL
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
Initial: AIMACO, COMTRAN, FACT, FLOW-MATIC COBOL 2002[a]: C++, Eiffel, Smalltalk
CobolScript,[5]EGL,[6]PL/I,[7]PL/B[citation needed]

COBOL (; ein Akronym für “Common Business-Oriented Language”) ist eine kompilierte englischähnliche Computerprogrammiersprache, die für den geschäftlichen Gebrauch entwickelt wurde. Sie ist eine zwingende, prozedurale und seit 2002 objektorientierte Sprache. COBOL wird hauptsächlich in Geschäfts-, Finanz- und Verwaltungssystemen für Unternehmen und Regierungen verwendet. COBOL wird immer noch häufig in Anwendungen verwendet, die auf Mainframe-Computern bereitgestellt werden, beispielsweise bei umfangreichen Batch- und Transaktionsverarbeitungsaufträgen. Aufgrund der sinkenden Popularität und des Ausscheidens erfahrener COBOL-Programmierer werden Programme jedoch auf neue Plattformen migriert, in modernen Sprachen umgeschrieben oder durch Softwarepakete ersetzt.^[8] Die meisten Programmierungen in COBOL dienen heute ausschließlich der Wartung bestehender Anwendungen; Viele große Finanzinstitute entwickelten jedoch noch 2006 neue COBOL-Systeme.^[9]

COBOL wurde 1959 von CODASYL entworfen und basierte teilweise auf der Programmiersprache FLOW-MATIC von Grace Hopper. Es wurde als Teil der Bemühungen des US-Verteidigungsministeriums entwickelt, eine tragbare Programmiersprache für die Datenverarbeitung zu entwickeln. Es wurde ursprünglich als Notlösung angesehen, aber das Verteidigungsministerium zwang Computerhersteller umgehend dazu, es bereitzustellen, was zu seiner weit verbreiteten Akzeptanz führte.^[10] Es wurde 1968 standardisiert und seitdem viermal überarbeitet. Erweiterungen umfassen die Unterstützung für strukturierte und objektorientierte Programmierung. Der aktuelle Standard ist ISO/IEC 1989: 2014.^[11]

COBOL-Anweisungen haben eine englischähnliche Syntax, die selbstdokumentierend und gut lesbar ist. Es ist jedoch ausführlich und verwendet über 300 reservierte Wörter. Im Gegensatz zu moderner, prägnanter Syntax wie y = x;, COBOL hat eine eher englischähnliche Syntax (in diesem Fall MOVE x TO y). COBOL-Code ist in vier unterteilt Divisionen (Identifikation, Umgebung, Daten und Verfahren) mit einer starren Hierarchie von Abschnitten, Absätzen und Sätzen. In Ermangelung einer großen Standardbibliothek spezifiziert der Standard 43 Anweisungen, 87 Funktionen und nur eine Klasse.

Akademische Informatiker waren bei der Entwicklung von COBOL im Allgemeinen desinteressiert an Geschäftsanwendungen und waren nicht an dessen Design beteiligt; es wurde (effektiv) von Grund auf als Computersprache für Unternehmen entwickelt, mit einem Schwerpunkt auf Ein- und Ausgaben, deren einzige Datentypen Zahlen und Textketten waren.^[12]
COBOL wurde während seiner gesamten Lebensdauer für seine Ausführlichkeit, seinen Designprozess und seine schlechte Unterstützung für strukturierte Programmierung kritisiert. Diese Schwächen führen zu monolithischen, ausführlichen (als Englisch angedachten) Programmen, die nicht leicht verständlich sind.

Geschichte und Spezifikation[edit]

Hintergrund[edit]

In den späten 1950er Jahren machten sich Computerbenutzer und Hersteller Sorgen über die steigenden Programmierkosten. Eine Umfrage aus dem Jahr 1959 hatte ergeben, dass die Programmierung in jeder Datenverarbeitungsanlage durchschnittlich 800.000 US-Dollar kostete und dass die Übersetzung von Programmen für die Ausführung auf neuer Hardware 600.000 US-Dollar kosten würde. In einer Zeit, in der sich immer mehr neue Programmiersprachen ausbreiteten, ergab dieselbe Umfrage, dass die Konvertierung bei Verwendung einer gemeinsamen geschäftsorientierten Sprache viel billiger und schneller wäre.

Am 8. April 1959 berief Mary K. Hawes, Informatikerin bei Burroughs Corporation, ein Treffen von Vertretern aus Wissenschaft, Computeranwendern und Herstellern an der University of Pennsylvania ein, um ein formelles Treffen über gängige Geschäftssprachen zu organisieren.^[14] Zu den Vertretern gehörten Grace Hopper (Erfinder der englischähnlichen Datenverarbeitungssprache FLOW-MATIC), Jean Sammet und Saul Gorn.

Bei der Sitzung im April bat die Gruppe das Verteidigungsministerium (DoD), die Bemühungen zur Schaffung einer gemeinsamen Geschäftssprache zu unterstützen. Die Delegation beeindruckte Charles A. Phillips, Direktor des Data System Research Staff am DoD,^[17] die dachten, dass sie die Probleme des DoD “ganz und gar verstanden” hätten. Das DoD betrieb 225 Computer, hatte weitere 175 bestellt und über 200 Millionen US-Dollar für die Implementierung von Programmen ausgegeben, die darauf ausgeführt wurden. Portable Programme würden Zeit sparen, Kosten senken und die Modernisierung erleichtern.

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

COBOL 60[edit]

Am 28. und 29. Mai 1959 (genau ein Jahr nach dem Zürcher ALGOL 58-Treffen) fand ein Treffen im Pentagon statt, um die Schaffung einer gemeinsamen Programmiersprache für die Wirtschaft zu diskutieren. Es wurde von 41 Personen besucht und wurde von Phillips geleitet.^[20] Das Verteidigungsministerium war besorgt darüber, ob es die gleichen Datenverarbeitungsprogramme auf verschiedenen Computern ausführen könnte. FORTRAN, die damals einzige Mainstream-Sprache, hatte nicht die nötigen Funktionen, um solche Programme zu schreiben.

Die Vertreter beschrieben begeistert eine Sprache, die in einer Vielzahl von Umgebungen funktionieren könnte, von Banken und Versicherungen bis hin zu Versorgungsunternehmen und Bestandskontrolle. Einstimmig waren sie sich einig, dass mehr Menschen programmieren können sollten und dass die neue Sprache nicht durch die Grenzen der heutigen Technologie eingeschränkt werden sollte. Eine Mehrheit stimmte darin überein, dass die Sprache das Englische maximal nutzen, veränderbar, maschinenunabhängig und einfach zu bedienen sein sollte, auch auf Kosten der Macht.

Das Treffen führte zur Bildung eines Lenkungsausschusses sowie kurzer, mittlerer und langfristiger Ausschüsse. Der Kurzstreckenausschuss wurde bis September (drei Monate) Zeit gegeben, um Spezifikationen für eine Übergangssprache zu erstellen, die dann von den anderen Ausschüssen verbessert werden sollte. Ihre offizielle Mission bestand jedoch darin, die Stärken und Schwächen bestehender Programmiersprachen zu identifizieren und sie nicht explizit anzuweisen, eine neue Sprache zu entwickeln. Die Frist wurde vom Kurzstreckenausschuss mit Unglauben erfüllt. 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 tagte am 4. Juni und vereinbarte, die gesamte Aktivität als Ausschuss für Datensystemsprachen, oder CODASYL, und einen Exekutivausschuss zu bilden.

Der Kurzstreckenausschuss setzte sich aus Mitgliedern von sechs Computerherstellern und drei Regierungsbehörden zusammen. 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 (jetzt das National Institute of Standards and Technology). Vorsitzender des Ausschusses war Joseph Wegstein vom US National Bureau of Standards. Die Arbeit begann mit der Untersuchung von Datenbeschreibungen, Aussagen, bestehenden Anwendungen und Benutzererfahrungen.

Der Ausschuss befasste sich hauptsächlich mit den Programmiersprachen FLOW-MATIC, AIMACO und COMTRAN. Die Sprache FLOW-MATIC war besonders einflussreich, weil sie implementiert wurde und AIMACO mit nur geringen Änderungen davon abgeleitet war.^[32]
Die Erfinderin von FLOW-MATIC, Grace Hopper, diente dem Komitee 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 “die Mutter von COBOL” oder “die Großmutter von COBOL” bezeichnet.^[34][35][36] obwohl Jean Sammet, ein leitender Designer von COBOL, erklärte, dass Hopper “nicht die Mutter, der Schöpfer oder Entwickler von Cobol war”.^[37][1]

IBMs COMTRAN-Sprache, erfunden von Bob Bemer, wurde von einem aus Kollegen von Grace Hopper bestehenden Kurzstreckenkomitee als Konkurrent von FLOW-MATIC angesehen. Einige seiner Funktionen wurden nicht in COBOL integriert, damit es nicht so aussah, als hätte IBM den Designprozess dominiert, und Jean Sammet sagte 1981, dass es von einigen Ausschussmitgliedern (sie selbst eingeschlossen) eine “starke Anti-IBM-Voreingenommenheit” gegeben habe. In einem Fall schickte Grace Hopper, nachdem Roy Goldfinger, Autor des COMTRAN-Handbuchs und Mitglied des Mittelstreckenausschusses, an einer Sitzung des Unterausschusses teilgenommen hatte, um seine Sprache zu unterstützen und die Verwendung algebraischer Ausdrücke zu fördern, ein Memo an das Kurzstreckenkomitee, in dem sie Sperry Rands Bemühungen, eine auf Englisch basierende Sprache zu schaffen. 1980 kommentierte Grace Hopper, dass „COBOL 60 zu 95% FLOW-MATIC ist“ und dass COMTRAN einen „extrem geringen“ Einfluss gehabt habe. Darüber hinaus sagte sie, dass sie behaupten würde, dass die Arbeit sowohl von FLOW-MATIC als auch von COMTRAN beeinflusst wurde, nur um “andere Menschen glücklich zu machen”. [so they] würde nicht versuchen, uns auszuschalten”.^[43]
Funktionen von COMTRAN, die in COBOL enthaltene Formeln integriert sind, die 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 großer Debatten. Während einige Mitglieder der Meinung waren, dass die Sprache zu viele Kompromisse aufwies und das Ergebnis eines Entwurfs des Ausschusses war, hielten andere sie für besser als die drei untersuchten Sprachen. Einige hielten die Sprache für zu komplex; andere, zu einfach. Zu den kontroversen Funktionen gehörten diejenigen, die für Datenverarbeitungsbenutzer als nutzlos oder zu fortschrittlich angesehen wurden. Zu diesen Funktionen gehörten boolesche Ausdrücke, Formeln und Tabellen tiefgestellte (Indizes). Ein weiterer kontroverser Punkt war die Frage, ob Schlüsselwörter kontextsensitiv gemacht werden sollten und welche Auswirkungen dies auf die Lesbarkeit haben würde. Obwohl kontextsensitive Schlüsselwörter abgelehnt wurden, wurde der 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 (als rein mathematisch gedacht) wurde wenig berücksichtigt und ohne Verwendung für die Datenverarbeitung).

Die Spezifikationen wurden dem Exekutivausschuss am 4. September vorgelegt. Sie blieben hinter den Erwartungen zurück: Joseph Wegstein bemerkte, dass “es raue Stellen enthält und einige Ergänzungen erfordert”, und Bob Bemer bezeichnete sie später als “Durcheinander”. Dem Unterausschuss wurde bis Dezember Zeit gegeben, um es zu verbessern.

Auf einer Sitzung Mitte September diskutierte der Ausschuss den Namen der neuen Sprache. Zu den Vorschlägen gehörten “BUSY” (Business System), “INFOSYL” (Information System Language) und “COCOSYL” (Common Computer Systems Language). Es ist unklar, wer den Namen “COBOL” geprägt hat, obwohl Bob Bemer später behauptete, es sei sein Vorschlag gewesen.^[55][56][57]

Im Oktober erhielt das Mittelklasse-Komitee Kopien der von Roy Nutt erstellten FACT-Sprachspezifikation. Seine Eigenschaften beeindruckten das Komitee so sehr, dass sie eine Resolution verabschiedeten, um COBOL darauf aufzubauen. Dies war ein Schlag für das Kurzstreckenkomitee, das bei der Spezifikation gute Fortschritte gemacht hatte. Obwohl FACT technisch überlegen ist, wurde es nicht im Hinblick auf Portabilität oder im Konsens zwischen Herstellern und Benutzern entwickelt. Es fehlte auch eine nachweisbare Implementierung, die es Anhängern eines FLOW-MATIC-basierten COBOL ermöglichte, die Resolution zu kippen. RCA-Vertreter Howard Bromberg blockierte auch FACT, damit die Arbeit von RCA an einer COBOL-Implementierung nicht umsonst war.

Es stellte sich bald heraus, 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 demonstrieren.^[b][60]
Zur Analyse bestehender Sprachen wurde ein Unterausschuss gebildet, der sich aus sechs Personen zusammensetzte:

• 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 erledigte die meiste Arbeit bei der Erstellung der Spezifikation, während der Kurzstreckenausschuss seine Arbeit überprüfen und ändern konnte, bevor er die fertige Spezifikation erstellte.

Die Spezifikationen wurden am 8. Januar 1960 vom Exekutivkomitee genehmigt und an die Regierungsdruckerei übermittelt, die diese als COBOL 60. Die erklärten Ziele der Sprache bestanden darin, effiziente, portable Programme einfach zu schreiben, Benutzern den Umstieg auf neue Systeme mit minimalem Aufwand und Kosten zu ermöglichen und für unerfahrene Programmierer geeignet zu sein. Das CODASYL Executive Committee gründete später das COBOL Maintenance Committee, 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 COBOL-Compiler bauen wollten. Bis September hatten sich fünf weitere Hersteller CODASYL angeschlossen (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 planten International Computers and Tabulators, ihre Sprache CODEL durch COBOL zu ersetzen.

Währenddessen 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 die Erzielung der Kompatibilität demonstrierte.^[68]

Die relativen Einflüsse der verwendeten Sprachen setzen sich bis heute in den empfohlenen Hinweisen fort, die in allen COBOL-Referenzhandbüchern abgedruckt sind:

COBOL ist eine Branchensprache und nicht Eigentum eines Unternehmens oder einer Unternehmensgruppe oder einer Organisation oder Unternehmensgruppe.

Keiner der Mitwirkenden oder das CODASYL COBOL-Komitee geben eine ausdrückliche oder stillschweigende Garantie für die Genauigkeit und Funktion des Programmiersystems und der Programmiersprache. Darüber hinaus wird keine Verantwortung von den Mitwirkenden oder dem Ausschuss in diesem Zusammenhang übernommen. Die Autoren und Urheberrechtsinhaber des hier verwendeten urheberrechtlich geschützten Materials sind wie folgt:

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

Sie haben die Verwendung dieses Materials ganz oder teilweise in den COBOL-Spezifikationen ausdrücklich genehmigt. Diese Berechtigung erstreckt sich auf die Vervielfältigung und Verwendung von COBOL-Spezifikationen in Programmierhandbüchern oder ähnlichen Veröffentlichungen.^[69]

COBOL-61 bis COBOL-65[edit]

Viele logische Fehler wurden gefunden in COBOL 60, was Charles Katz von GE dazu veranlasste, zu warnen, dass es nicht eindeutig interpretiert werden könne. Ein widerstrebendes kurzfristiges Komitee führte eine totale Säuberung durch, und im März 1963 wurde berichtet, dass die Syntax von COBOL genauso definierbar war wie die von ALGOL, obwohl semantische Mehrdeutigkeiten bestehen blieben.

Frühe COBOL-Compiler waren primitiv und langsam. Eine Auswertung der US-Marine aus dem Jahr 1962 ergab Kompilationsgeschwindigkeiten von 3–11 Statements pro Minute. Bis Mitte 1964 waren sie auf 11 bis 1000 Kontoauszüge pro Minute angestiegen. Es wurde beobachtet, dass eine Erhöhung 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 US-Dollar.

Ende 1962 kündigte IBM an, 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. Dies wurde dann 1963 durch die erweiterten COBOL-61-Spezifikationen ersetzt, die die Sortier- und Berichtschreiberfunktionen einführten. Die hinzugefügten Einrichtungen korrigierten Mängel, die Honeywell Ende 1959 in einem Brief an das Kurzstreckenkomitee identifizierte. COBOL Edition 1965 brachte weitere Klarstellungen zu den Spezifikationen und führte Möglichkeiten zur Handhabung von Massenspeicherdateien und -tabellen ein.

COBOL-68[edit]

Es wurden Anstrengungen unternommen, COBOL zu standardisieren, um Inkompatibilitäten zwischen den Versionen zu überwinden. Ende 1962 bildeten sowohl die ISO als auch das United States of America Standards Institute (jetzt ANSI) Gruppen, um Standards zu erstellen. ANSI produziert USA-Standard COBOL X3.23 im August 1968, der zum Grundstein für spätere Versionen wurde. Diese Version war als American National Standard (ANS) COBOL bekannt und wurde 1972 von der ISO übernommen.^[75]

COBOL-74[edit]

1970 war COBOL die am weitesten verbreitete Programmiersprache der Welt.

Unabhängig vom ANSI-Komitee arbeitete das CODASYL Programming Language Committee an der Verbesserung der Sprache. Sie beschrieben neue Versionen in den Jahren 1968, 1969, 1970 und 1973, einschließlich Änderungen wie neuer Kommunikation zwischen Programmen, Debugging- und Dateizusammenführungsfunktionen sowie verbesserter String-Handling- und Bibliotheksintegrationsfunktionen. Obwohl CODASYL vom ANSI-Komitee unabhängig war, CODASYL Zeitschrift für Entwicklung wurde von ANSI verwendet, um Funktionen zu identifizieren, die beliebt genug waren, um eine Implementierung zu rechtfertigen. Das Programming Language Committee stand auch in Kontakt mit ECMA und dem japanischen COBOL Standard Committee.

Das Programming Language Committee war jedoch nicht bekannt. Der Vizepräsident William Rinehuls beklagte, dass zwei Drittel der COBOL-Gemeinschaft nichts von der Existenz des Komitees wussten. Es war auch schlecht, es fehlten die Mittel, um öffentliche Dokumente wie Sitzungsprotokolle und Änderungsvorschläge frei zugänglich zu machen.^[79]

1974 veröffentlichte ANSI eine überarbeitete Version von (ANS) COBOL, die neue Funktionen wie Dateiorganisationen, die DELETE Stellungnahme^[80] und das Segmentierungsmodul. Gelöschte Funktionen enthalten die NOTE Aussage, die EXAMINE Aussage (die ersetzt wurde durch INSPECT) und das vom Implementierer definierte Direktzugriffsmodul (das durch die neuen sequentiellen und relativen E/A-Module ersetzt wurde). Dabei handelte es sich um 44 Änderungen, die bestehende Aussagen mit dem neuen Standard unvereinbar machten.^[82]
Der Verfasser des Berichts sollte aus COBOL entfernt werden, wurde jedoch vor der Veröffentlichung des Standards wieder eingestellt.^[83][84] Die ISO übernahm den aktualisierten Standard später im Jahr 1978.^[75]

COBOL-85[edit]

Im Juni 1978 begannen die Arbeiten zur Überarbeitung von COBOL-74. Der vorgeschlagene Standard (allgemein als COBOL-80 bezeichnet) unterschied sich erheblich vom vorherigen, was zu Bedenken hinsichtlich Inkompatibilität und Konvertierungskosten führte. Im Januar 1981 drohte Joseph T. Brophy, Senior Vice-President der Travellers Insurance, das Standardkomitee zu verklagen, weil es nicht aufwärtskompatibel mit COBOL-74 sei. Herr Brophy beschrieb frühere Konvertierungen ihrer 40 Millionen Zeilen umfassenden Codebasis als “nicht produktiv” und als “völlige Verschwendung unserer Programmierressourcen”.^[85]
Später in diesem Jahr sagte die Data Processing Management Association (DPMA), sie sei „stark gegen den neuen Standard“ und verwies auf „unerlaubte“ Konvertierungskosten und Verbesserungen, die „dem Benutzer aufgezwungen“ wurden.^[86][87]

Während der ersten öffentlichen Begutachtungsperiode erhielt der Ausschuss 2.200 Antworten, davon 1.700 negative Serienbriefe.^[88]
Andere Antworten waren detaillierte Analysen der Auswirkungen von COBOL-80 auf ihre Systeme; Konvertierungskosten wurden mit mindestens 50 Cent pro Codezeile prognostiziert. Weniger als ein Dutzend der Antworten befürworteten den vorgeschlagenen Standard.^[89]

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

1983 zog das DPMA seinen Widerspruch gegen den Standard zurück und verwies auf die Bereitschaft des Ausschusses für öffentliche Anliegen. Im selben Jahr kam eine Studie des National Bureau of Standards zu dem Schluss, dass der vorgeschlagene Standard wenig Probleme bereiten würde.^[87][90] Ein Jahr später wurde ein COBOL-80-Compiler für DEC VAX-Benutzer freigegeben, die feststellten, dass die Konvertierung von COBOL-74-Programmen nur wenige Probleme bereitete. Das neue EVALUATE Anweisung und Inline PERFORM wurden besonders gut angenommen und die Produktivität dank vereinfachtem Kontrollfluss und Debugging verbessert.^[91]

Die zweite öffentliche Überprüfung führte zu weiteren 1.000 (hauptsächlich negativen) Antworten, während die letzte nur 25 erhielt, und zu diesem Zeitpunkt waren viele Bedenken ausgeräumt.^[87]

1985 akzeptierte die ISO-Arbeitsgruppe 4 die damalige Version des von ANSI vorgeschlagenen Standards, nahm mehrere Änderungen vor und legte sie als neuen ISO-Standard COBOL 85 fest. Er wurde Ende 1985 veröffentlicht.

Sechzig Funktionen wurden geändert oder veraltet und viele^[quantify] wurden hinzugefügt, wie zum Beispiel:^[93]

• Scope-Terminatoren (END-IF, END-PERFORM, END-READ, etc.)
• Verschachtelte Unterprogramme
• CONTINUE, eine Nicht-Operation-Anweisung
• EVALUATE, eine switch-Anweisung
• INITIALIZE, eine Anweisung, die Datengruppen auf ihre Standardwerte setzen kann
• Im Einklang PERFORM Schleifenkörper – bisher mussten Schleifenkörper in einem separaten Verfahren angegeben werden
• Referenzänderung, die den Zugriff auf Teilzeichenfolgen ermöglicht
• E/A-Statuscodes.

Die neue Norm wurde von allen nationalen Normungsgremien, einschließlich ANSI, übernommen.^[75]

1989 und 1993 folgten zwei Änderungen, wobei die erste intrinsische Funktionen einführte und die andere Korrekturen vorsah.^[75]

COBOL 2002 und objektorientiertes COBOL[edit]

1997 schätzte die Gartner Group, dass es insgesamt 200 Milliarden COBOL-Leitungen gab, die 80 % aller Geschäftsprogramme liefen.^{[94][better source needed]}

In den frühen 1990er Jahren wurde damit begonnen, die Objektorientierung in der nächsten vollständigen Überarbeitung von COBOL hinzuzufügen. Objektorientierte Funktionen wurden aus C++ und Smalltalk übernommen.^[2][3]
Die anfängliche Schätzung war, dass diese Überarbeitung bis 1997 abgeschlossen sein sollte, und bis 1997 lag ein ISO Committee Draft (CD) vor. Einige Hersteller (einschließlich Micro Focus, Fujitsu und IBM) führten objektorientierte Syntax basierend auf Entwürfen der vollständigen Überarbeitung ein. Die endgültige genehmigte ISO-Norm wurde Ende 2002 genehmigt und veröffentlicht.^[95]

Fujitsu/GTSoftware,^[96] Micro Focus und RainCode führten objektorientierte COBOL-Compiler ein, die auf das .NET Framework abzielen.

Es gab viele andere neue Funktionen, von denen viele in der CODASYL COBOL Zeitschrift für Entwicklung seit 1978 und hatte die Chance verpasst, in COBOL-85 aufgenommen zu werden.^[97] Zu diesen weiteren Funktionen gehörten:

Für den Standard wurden drei Berichtigungen veröffentlicht: zwei im Jahr 2006 und eine im Jahr 2009.^[100]

COBOL 2014[edit]

Zwischen 2003 und 2009 wurden drei technische Berichte erstellt, die die Objekt-Finalisierung, XML-Verarbeitung und Sammlungsklassen für COBOL beschreiben.^[100]

COBOL 2002 litt unter schlechter Unterstützung: Kein Compiler unterstützte den Standard vollständig. Micro Focus stellte fest, dass dies auf mangelnde Benutzernachfrage nach den neuen Funktionen und auf die Abschaffung der NIST-Testsuite zurückzuführen war, die zum Testen der Compiler-Konformität verwendet wurde. Der Standardisierungsprozess erwies sich auch als langsam und mit unzureichenden Mitteln ausgestattet.^[101]

COBOL 2014 enthält die folgenden Änderungen:

• Portable arithmetische Ergebnisse wurden durch IEEE 754-Datentypen ersetzt
• Wichtige Funktionen wurden optional gemacht, wie z VALIDATE Einrichtung, der Berichtschreiber und die Bildschirmbearbeitungsfunktion
• Methodenüberladung
• Dynamische Kapazitätstabellen (eine Funktion, die aus dem Entwurf von COBOL 2002 entfernt wurde)^[103]

Erbe[edit]

COBOL-Programme werden weltweit in Regierungen und Unternehmen eingesetzt und laufen auf verschiedenen Betriebssystemen wie z/OS, z/VSE, VME, Unix, OpenVMS und Windows. 1997 berichtete die Gartner Group, dass 80 % des weltweiten Geschäfts auf COBOL liefen, wobei über 200 Milliarden Codezeilen und 5 Milliarden weitere Zeilen jährlich geschrieben werden.^[104]

Gegen Ende des 20. Jahrhunderts stand das Jahr-2000-Problem (Y2K) im Mittelpunkt erheblicher COBOL-Programmierarbeiten, manchmal von denselben Programmierern, die die Systeme Jahrzehnte zuvor entworfen hatten. Der besondere Aufwand für die Korrektur des COBOL-Codes wurde zugeschrieben^{[by whom?]} auf die große Menge an geschäftsorientiertem COBOL, da Geschäftsanwendungen stark Daten verwenden, und auf Datenfelder mit fester Länge. Nach den Aufräumarbeiten für diese Programme für das Jahr 2000 ergab eine Umfrage aus dem Jahr 2003, dass viele davon weiterhin verwendet wurden. Die Autoren sagten, dass die Umfragedaten “einen allmählichen Rückgang der Bedeutung von Cobol in der Anwendungsentwicklung über die [following] 10 Jahre, es sei denn, … die Integration mit anderen Sprachen und Technologien kann übernommen werden”.

2006 und 2012, Computerwelt Umfragen ergaben, dass über 60 % der Unternehmen COBOL verwenden (mehr als C++ und Visual Basic .NET) und dass bei der Hälfte von ihnen COBOL für den Großteil ihrer internen Software verwendet wurde.^[9][107] 36 % der Manager sagten, dass sie eine Migration von COBOL planten, und 25 % sagten, sie würden dies gerne tun, wenn es billiger wäre. Stattdessen haben einige Unternehmen ihre Systeme von teuren Mainframes auf billigere, modernere Systeme umgestellt, während sie ihre COBOL-Programme beibehalten.^[9]

Zeugenaussagen vor dem Repräsentantenhaus im Jahr 2016 zeigten, dass COBOL immer noch von vielen Bundesbehörden verwendet wird.^[108]Reuters berichtete im Jahr 2017, dass 43 % der Bankensysteme immer noch COBOL verwenden, wobei über 220 Milliarden Zeilen COBOL-Code verwendet werden.^[109]

Bis 2019 schrumpfte die Zahl der COBOL-Programmierer aufgrund von Pensionierungen schnell, was zu einer drohenden Qualifikationslücke in Unternehmen und Regierungsorganisationen führte, die immer noch Mainframe-Systeme für die Verarbeitung von Transaktionen mit hohem Volumen verwenden. Bemühungen, Systeme in neueren Sprachen umzuschreiben, haben sich als teuer und problematisch erwiesen, ebenso wie das Outsourcing der Codepflege, daher werden Vorschläge befürwortet, mehr Leute in COBOL zu schulen.^[110]

Während der COVID-19-Pandemie und des daraus resultierenden Anstiegs der Arbeitslosigkeit meldeten mehrere US-Bundesstaaten einen Mangel an qualifizierten COBOL-Programmierern, um die Altsysteme für die Verwaltung der Arbeitslosenunterstützung zu unterstützen. Viele dieser Systeme befanden sich vor der Pandemie im Prozess der Umstellung auf modernere Programmiersprachen, der Prozess musste jedoch auf Eis gelegt werden.^[111] In ähnlicher Weise beeilte sich der US Internal Revenue Service, sein COBOL-basiertes Individual Master File zu patchen, um die zig Millionen Zahlungen auszuzahlen, die vom Coronavirus Aid, Relief and Economic Security Act vorgeschrieben wurden.^[112]

Merkmale[edit]

Syntax[edit]

COBOL hat eine englischähnliche Syntax, die verwendet wird, um fast alles in einem Programm zu beschreiben. Eine Bedingung kann beispielsweise ausgedrückt werden als x IS GREATER THAN y oder prägnanter als x GREATER 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 gekürzt werden zu a > b AND c OR = d. Um diese englischähnliche Syntax zu unterstützen, hat COBOL über 300 Schlüsselwörter.^[c] Einige der Schlüsselwörter sind einfache alternative oder pluralisierte Schreibweisen desselben Wortes, was für mehr englischähnliche Aussagen und Klauseln sorgt; zB die IN und OF Schlüsselwörter können austauschbar verwendet werden, ebenso wie IS und ARE, und VALUE und VALUES.

Jedes COBOL-Programm besteht aus vier grundlegenden lexikalischen Elementen: Wörtern, Literalen, Bildzeichenfolgen (siehe § PICTURE-Klausel) und Trennzeichen. Wörter umfassen reservierte Wörter und benutzerdefinierte Bezeichner. Sie sind bis zu 31 Zeichen lang und können Buchstaben, Ziffern, Bindestriche und Unterstriche enthalten. Literale beinhalten Ziffern (z. B. 12) und Zeichenfolgen (zB 'Hello!'). Trennzeichen sind Leerzeichen, Kommas und Semikolons gefolgt von einem Leerzeichen.

Ein COBOL-Programm ist in vier Abteilungen unterteilt: die Identifikationsabteilung, die Umgebungsabteilung, die Datenabteilung und die Prozedurabteilung. Die Identifikationsabteilung gibt den Namen und Typ des Quellelements an und ist dort, wo Klassen und Schnittstellen angegeben werden. Die Umgebungsabteilung spezifiziert alle Programmfunktionen, die von dem System abhängen, auf dem sie ausgeführt wird, wie Dateien und Zeichensätze. Die Datenteilung wird verwendet, um Variablen und Parameter zu deklarieren. Die Prozedurdivision enthält die Anweisungen des Programms. Jeder Bereich ist in Abschnitte unterteilt, die aus Absätzen bestehen.

Metasprache[edit]

Die Syntax von COBOL wird normalerweise mit einer einzigartigen Metasprache beschrieben, die geschweifte Klammern, Klammern, Striche und Unterstreichungen verwendet. Die Metasprache wurde für die ursprünglichen COBOL-Spezifikationen entwickelt. Obwohl die Backus-Naur-Form zu dieser Zeit existierte, hatte das Komitee noch nichts davon gehört.

Betrachten Sie als Beispiel die folgende Beschreibung von an ADD Stellungnahme:

Diese Beschreibung lässt folgende Varianten zu:

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

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

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

Codeformat[edit]

COBOL kann in zwei Formaten geschrieben werden: fest (Standard) oder frei. Im Festformat muss der Code in bestimmten Bereichen ausgerichtet werden (ein Überbleibsel bei der Verwendung von Lochkarten). Bis COBOL 2002 waren dies:

In COBOL 2002 wurden die Bereiche A und B zusammengeführt, um den Programmtextbereich zu bilden, der nun an einer vom Implementierer definierten Spalte endet.

COBOL 2002 führte auch Freiformatcode ein. Frei formatierter Code kann wie in neueren Programmiersprachen in jede beliebige Spalte der Datei eingefügt werden. Kommentare werden mit . angegeben *>, die überall platziert werden kann und auch in fest formatiertem Quellcode verwendet werden kann. Fortsetzungszeilen sind nicht vorhanden, und die >>PAGE Richtlinie ersetzt die / Indikator.

Identifikationsabteilung[edit]

Die Identifikationsabteilung identifiziert die folgende Code-Entität und enthält die Definition einer Klasse oder Schnittstelle.

Objekt orientierte Programmierung[edit]

Klassen und Interfaces sind seit 2002 in COBOL enthalten. Klassen haben Factory-Objekte, die Klassenmethoden und Variablen enthalten, und Instanzobjekte, die Instanzmethoden und Variablen enthalten. Vererbung und Schnittstellen bieten Polymorphismus. Unterstützung für generische Programmierung wird durch parametrisierte Klassen bereitgestellt, 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 Aussage, die ähnlich wirkt wie CALL, oder durch einen Inline-Methodenaufruf, der der Verwendung von Funktionen entspricht.

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

COBOL bietet keine Möglichkeit, Methoden auszublenden. Klassendaten können jedoch ausgeblendet werden, indem sie ohne a . deklariert werden PROPERTY -Klausel, die dem Benutzer keine Möglichkeit gibt, darauf zuzugreifen. Das Überladen von Methoden wurde in COBOL 2014 hinzugefügt.

Abteilung Umwelt[edit]

Die Umgebungsabteilung enthält den Konfigurationsabschnitt und den Eingabe-Ausgabe-Abschnitt. Der Konfigurationsabschnitt wird verwendet, um variable Funktionen wie Währungszeichen, Gebietsschemas und Zeichensätze anzugeben. Der Eingabe-Ausgabe-Abschnitt enthält dateibezogene Informationen.

Dateien[edit]

COBOL unterstützt drei Dateiformate, oder Organisationen: sequentiell, indiziert und relativ. In sequentiellen Dateien sind Datensätze zusammenhängend und müssen sequentiell durchlaufen werden, ähnlich wie bei einer verketteten Liste. Indizierte Dateien haben einen oder mehrere Indizes, die einen wahlfreien Zugriff auf Datensätze ermöglichen und nach denen sortiert werden kann. Jeder Datensatz muss einen eindeutigen Schlüssel haben, aber andere, wechseln, Datensatzschlüssel müssen nicht eindeutig sein. Die Implementierungen indizierter Dateien variieren je nach Anbieter, obwohl gängige Implementierungen wie C-ISAM und VSAM auf IBM ISAM basieren. Relative Dateien haben wie indizierte Dateien einen eindeutigen Datensatzschlüssel, aber keine alternativen Schlüssel. Der Schlüssel eines relativen Datensatzes ist seine Ordinalposition; zum Beispiel hat der 10. Datensatz den Schlüssel 10. Das bedeutet, dass das Erstellen eines Datensatzes mit dem Schlüssel 5 die Erstellung von (leeren) Vorgängersätzen erfordern kann. Relative Dateien ermöglichen auch sequenziellen und wahlfreien Zugriff.

Eine übliche nicht standardmäßige Erweiterung ist die zeilensequentiell Organisation, die zur Verarbeitung von Textdateien verwendet wird. Datensätze in einer Datei werden durch einen Zeilenumbruch abgeschlossen und können unterschiedlich lang sein.^[124]

Datenteilung[edit]

Die Datenabteilung ist in sechs Abschnitte unterteilt, die verschiedene Elemente deklarieren: den Dateiabschnitt für Dateiaufzeichnungen; der Arbeitsspeicherabschnitt für statische Variablen; der Local-Storage-Abschnitt für automatische Variablen; der Linkage-Abschnitt für Parameter und den Rückgabewert; der Berichtsteil und der Bildschirmteil für textbasierte Benutzeroberflächen.

Aggregierte Daten[edit]

Datenelemente in COBOL werden hierarchisch durch die Verwendung von Ebenennummern deklariert, die anzeigen, ob ein Datenelement Teil eines anderen ist. Ein Artikel mit einer höheren Level-Nummer ist einem Artikel mit einer niedrigeren untergeordnet. Datenelemente der obersten Ebene mit einer Ebenennummer von 1 werden aufgerufen Aufzeichnungen. Elemente mit untergeordneten Aggregatdaten werden aufgerufen Elemente gruppieren; die, die es nicht tun, heißen elementare Gegenstände. Level-Nummern, die zur Beschreibung von Standarddatenelementen verwendet werden, liegen zwischen 1 und 49.

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

Im obigen Beispiel elementares Element num und Gruppenelement the-date sind dem Rekord untergeordnet some-record, während elementare Elemente the-year, the-month, und the-day sind Teil des Gruppengegenstandes the-date.

Untergeordnete Elemente können mit dem disambiguiert werden IN (oder OF) Stichwort. Betrachten Sie beispielsweise den obigen Beispielcode zusammen mit dem folgenden Beispiel:

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

Die Namen the-year, the-month, und the-day sind für sich genommen mehrdeutig, da mehr als ein Datenelement mit diesen Namen definiert ist. Um ein bestimmtes Datenelement zu spezifizieren, zum Beispiel eines der Elemente, die im sale-date Gruppe, würde der Programmierer verwenden the-year IN sale-date (oder das Äquivalent the-year OF sale-date). (Diese Syntax ähnelt der “Punktnotation”, die von den meisten zeitgenössischen Sprachen unterstützt wird.)

Andere Datenebenen[edit]

Eine Ebenennummer von 66 wird verwendet, um eine Neugruppierung zuvor definierter Elemente zu deklarieren, unabhängig davon, wie diese Elemente strukturiert sind. Diese Datenebene, auch von den zugehörigen RENAMES Klausel, wird selten verwendet^[127] und wurde um 1988 normalerweise in alten Programmen gefunden. Seine Fähigkeit, die hierarchischen und logischen Strukturdaten zu ignorieren, bedeutete, dass seine Verwendung nicht empfohlen wurde und viele Installationen ihre Verwendung verboten.

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

Eine 77-Ebenennummer gibt an, dass das Element eigenständig ist, und entspricht in solchen Situationen der Ebenennummer 01. Der folgende Code deklariert beispielsweise zwei 77-Ebenen-Datenelemente: property-name und sales-region, bei denen es sich um Nicht-Gruppen-Datenelemente handelt, die unabhängig von (nicht untergeordneten) anderen Datenelementen sind:

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

Eine 88 Level-Nummer erklärt a Bedingungsname (ein sogenannter 88-Level), der wahr ist, wenn sein übergeordnetes Datenelement einen der in seinem . angegebenen Werte enthält VALUE Klausel. Der folgende Code definiert beispielsweise zwei 88-stufige Bedingungsnamenelemente, die je nach aktuellem Zeichendatenwert des wahr oder falsch sind wage-type Datenelement. Wenn das Datenelement einen Wert von enthält 'H', der Bedingungsname wage-is-hourly wahr ist, wohingegen wenn es einen Wert von enthält 'S' oder 'Y', der Bedingungsname wage-is-yearly ist wahr. Wenn das Datenelement einen anderen Wert enthält, sind beide Bedingungsnamen falsch.

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

Datentypen[edit]

Standard-COBOL bietet die folgenden Datentypen:

Typsicherheit ist in COBOL variabel. Numerische Daten werden geräuschlos zwischen verschiedenen Darstellungen und Größen konvertiert, und alphanumerische Daten können in jedes Datenelement eingefügt werden, das als Zeichenfolge gespeichert werden kann, einschließlich numerischer und Gruppendaten. Im Gegensatz dazu dürfen Objektreferenzen und Pointer nur von Items des gleichen Typs zugewiesen werden und ihre Werte können auf einen bestimmten Typ beschränkt werden.

PICTURE-Klausel[edit]

EIN PICTURE (oder PIC)-Klausel ist eine Zeichenfolge, von denen jedes einen Teil des Datenelements darstellt und was es enthalten kann. Einige Bildzeichen geben den Typ des Elements an und wie viele Zeichen oder Ziffern es im Speicher belegt. Zum Beispiel a 9 zeigt eine Dezimalstelle an und ein S zeigt an, dass das Element signiert ist. Andere Bildzeichen (genannt Einfügen und Bearbeitung Zeichen) geben an, wie ein Element formatiert werden soll. Zum Beispiel eine Reihe von + Zeichen definieren Zeichenpositionen sowie wie ein führendes Zeichen innerhalb der endgültigen Zeichendaten zu positionieren ist; das ganz rechte nicht-numerische Zeichen enthält das Vorzeichen des Elements, während andere Zeichenpositionen a + links von dieser Position enthält ein Leerzeichen. Wiederholte Zeichen können prägnanter spezifiziert werden, indem eine Zahl in Klammern nach einem Bildzeichen angegeben wird; zum Beispiel, 9(7) ist äquivalent zu 9999999. Bildspezifikationen, die nur Ziffern enthalten (9) und unterschreiben (S) Zeichen definieren rein numerisch Datenelemente, während Bildspezifikationen mit alphabetischen (A) oder alphanumerisch (X) Zeichen definieren alphanumerisch Datenelemente. Das Vorhandensein anderer Formatierungszeichen definiert bearbeitet numerisch oder alphanumerisch bearbeitet Datenelemente.

USAGE-Klausel[edit]

Diese Abteilung fehlen Informationen über COMPUTATIONAL-5. Bitte erweitern Sie den Abschnitt um diese Informationen. Weitere Details können auf der Diskussionsseite enthalten sein. (April 2021)

Die USAGE -Klausel deklariert das Format, in dem die Daten gespeichert werden. Je nach Datentyp kann sie entweder ergänzen oder anstelle von a . verwendet werden PICTURE Klausel. Während es zum Deklarieren von Zeigern und Objektreferenzen verwendet werden kann, ist es 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 a USAGE Klausel wie BINARY-LONG.
• USAGE COMPUTATIONAL, wobei Daten in jedem von der Implementierung bereitgestellten Format gespeichert werden können; oft gleichbedeutend mit USAGE BINARY
• USAGE DISPLAY, das Standardformat, in dem Daten als String gespeichert werden
• Gleitkomma, entweder in einem implementierungsabhängigen Format oder gemäß IEEE 754.
• USAGE NATIONAL, wobei Daten als String mit einem erweiterten Zeichensatz gespeichert werden
• USAGE PACKED-DECIMAL, wobei die Daten im kleinstmöglichen Dezimalformat gespeichert werden (typischerweise gepackte binär codierte Dezimalzahlen)

Berichtschreiber[edit]

Der Report Writer ist eine deklarative Einrichtung zum Erstellen von Berichten. Der Programmierer muss nur das Berichtslayout und die zu seiner Erstellung erforderlichen Daten angeben, sodass er keinen Code schreiben muss, um Dinge wie Seitenumbrüche, Datenformatierung sowie Überschriften und Fußzeilen zu verarbeiten.

Berichte sind mit Berichtsdateien verknüpft, bei denen es sich um Dateien handelt, in die nur über Anweisungen des Berichtsautors geschrieben werden kann.

       FD  report-out REPORT sales-report.

Jeder Bericht wird im Berichtsabschnitt der Datenabteilung definiert. Ein Bericht ist in Berichtsgruppen unterteilt, die die Überschriften, Fußzeilen und Details des Berichts definieren. Berichte funktionieren hierarchisch Kontrollpausen. Kontrollunterbrechungen treten auf, wenn eine Schlüsselvariable ihren Wert ändert; Wenn Sie beispielsweise einen Bericht erstellen, der die Bestellungen von Kunden detailliert beschreibt, kann es zu einer Kontrollunterbrechung kommen, wenn das Programm die Bestellungen eines anderen Kunden erreicht. Hier ist eine Beispielberichtsbeschreibung für einen Bericht, der die Verkäufe eines Verkäufers angibt und vor ungültigen Datensätzen warnt:

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

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

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

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

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

Die obige Berichtsbeschreibung beschreibt das folgende Layout:

Sales Report                                                             Page  1

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

Seller: Howard Discount
...
Sales Report                                                            Page 12

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

Vier Aussagen steuern den Berichtsschreiber: INITIATE, die den Berichtsschreiber für den Druck vorbereitet; GENERATE, das eine Berichtsgruppe druckt; SUPPRESS, die das Drucken einer Berichtsgruppe unterdrückt; und TERMINATE, wodurch die Berichtsverarbeitung beendet wird. Für das obige Beispiel für einen Verkaufsbericht könnte die Verfahrenseinteilung wie folgt aussehen:

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

Die Nutzung der Report Writer-Funktion variierte stark; einige Organisationen nutzten es ausgiebig und andere überhaupt nicht. Darüber hinaus schwankten die Implementierungen von Report Writer in der Qualität, wobei diejenigen am unteren Ende manchmal übermäßig viel Speicher zur Laufzeit verbrauchen.

Verfahrensteilung[edit]

Verfahren[edit]

Die Abschnitte und Absätze in der Prozedurabteilung (zusammen Prozeduren genannt) können als Label und als einfache Unterprogramme verwendet werden. Im Gegensatz zu anderen Abteilungen müssen Absätze nicht in Abschnitten sein. Die Ausführung durchläuft die Prozeduren eines Programms, bis es beendet wird. Um Prozeduren als Unterprogramme zu verwenden, PERFORM Verb verwendet wird.

EIN PERFORM -Anweisung ähnelt in gewisser Weise einem Prozeduraufruf in einer modernen Sprache in dem Sinne, dass die Ausführung zu dem Code zurückkehrt, der dem PERFORM Anweisung am Ende des aufgerufenen Codes; es bietet jedoch keinen Mechanismus zur Parameterübergabe oder zum Zurückgeben eines Ergebniswerts. Wenn eine Unterroutine mit einer einfachen Anweisung wie aufgerufen wird PERFORM subroutine, dann kehrt die Steuerung am Ende der aufgerufenen Prozedur zurück. Jedoch, PERFORM ist insofern ungewöhnlich, als es verwendet werden kann, um einen Bereich aufzurufen, der eine Sequenz mehrerer benachbarter Prozeduren umfasst. Dies geschieht mit der PERFORM sub-1 THRU sub-n konstruieren:

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

Die Ausgabe dieses Programms ist: “AABC”.

PERFORM unterscheidet sich auch von herkömmlichen Prozeduraufrufen dadurch, dass zumindest traditionell kein Begriff von einem Aufrufstapel vorhanden ist. Infolgedessen sind verschachtelte Aufrufe möglich (eine Codesequenz ist PERFORM‘ed darf a ausführen PERFORM -Anweisung selbst), erfordern jedoch besondere Sorgfalt, wenn Teile desselben Codes von beiden Aufrufen ausgeführt werden. Das Problem tritt auf, wenn der Code im inneren Aufruf den Austrittspunkt des äußeren Aufrufs erreicht. Formaler gesagt, wenn die Kontrolle durch den Austrittspunkt von a . geht PERFORM Aufruf, 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 anstelle einer “Rückkehradresse” mit einer sogenannten Fortsetzungsadresse arbeitet. Wenn der Kontrollfluss das Ende einer Prozedur erreicht, wird die Fortsetzungsadresse nachgeschlagen und die Kontrolle wird an diese Adresse übertragen. Vor dem Programmablauf wird die Fortsetzungsadresse für jede Prozedur auf die Startadresse der nächsten Prozedur im Programmtext initialisiert, so dass bei nein PERFORM Anweisungen passieren, die Kontrolle fließt von oben nach unten durch das Programm. Aber wenn a PERFORM -Anweisung ausgeführt wird, ändert sie die Fortsetzungsadresse der aufgerufenen Prozedur (oder der letzten Prozedur des aufgerufenen Bereichs, wenn PERFORM THRU verwendet wurde), sodass die Kontrolle am Ende an die Anrufseite zurückgegeben wird. Der ursprüngliche Wert wird gespeichert und anschließend wiederhergestellt, es gibt jedoch nur eine Speicherposition. Wenn zwei verschachtelte Aufrufe mit überlappendem Code arbeiten, können sie die Verwaltung der Fortsetzungsadresse auf verschiedene Weise gegenseitig stören.^[139][140]

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

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

Man könnte erwarten, dass die Ausgabe dieses Programms “1 2 3 4 3” lautet: Nach der Anzeige von “2” wird die zweite PERFORM bewirkt, dass “3” und “4” angezeigt werden, und dann wird der erste Aufruf mit “3” fortgesetzt. Bei herkömmlichen COBOL-Implementierungen ist dies nicht der Fall. Eher die erste PERFORM -Anweisung setzt die Fortsetzungsadresse am Ende von LABEL3 damit es zurück zur Anrufseite im Inneren springt LABEL1. Der Zweite PERFORM -Anweisung setzt die Rückgabe am Ende von LABEL4 ändert aber nicht die Fortsetzungsadresse von LABEL3, wobei davon ausgegangen wird, dass es sich um die Standardfortsetzung handelt. Wenn also die innere Anrufung am Ende von ankommt LABEL3, es springt zurück nach außen PERFORM -Anweisung, und das Programm hört auf, nur “1 2 3” ausgegeben zu haben. Auf der anderen Seite sind in einigen COBOL-Implementierungen wie dem Open-Source-Compiler TinyCOBOL die beiden PERFORM -Anweisungen stören sich nicht und die Ausgabe ist tatsächlich “1 2 3 4 3”. Daher ist das Verhalten in solchen Fällen nicht nur (vielleicht) überraschend, es ist auch nicht portabel.^[140]

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

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

Man könnte erwarten, dass die Ausgabe “1 2 3 END END END” ist, und tatsächlich wird dies von einigen COBOL-Compilern erzeugt. Aber einige Compiler, wie IBM COBOL, erzeugen Code, der “1 2 3 END END END END …” und so weiter ausgibt, wobei “END” in einer Endlosschleife immer wieder ausgegeben wird. Da der Platz zum Speichern von Backup-Fortsetzungsadressen begrenzt ist, werden die Backups bei rekursiven Aufrufen überschrieben, und es kann nur der Sprung zurück zu DISPLAY 'END'.^[140]

Aussagen[edit]

COBOL 2014 hat 47 Aussagen (auch genannt Verben), die in die folgenden groben Kategorien eingeteilt werden können: Kontrollfluss, E/A, Datenmanipulation und Berichtersteller. Die Aussagen des Berichtsautors werden im Abschnitt des Berichtsautors behandelt.

Kontrollfluss[edit]

Die bedingten Anweisungen von COBOL sind IF und EVALUATE. EVALUATE ist eine schalterähnliche Anweisung mit der zusätzlichen Möglichkeit, mehrere Werte und Bedingungen auszuwerten. Dies kann verwendet werden, um Entscheidungstabellen zu implementieren. Zur Steuerung einer CNC-Drehmaschine könnte beispielsweise Folgendes 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
    WHEN lid-closed ALSO min-speed THRU max-speed ALSO GREATER THAN desired-speed
        PERFORM slow-down-machine
    WHEN lid-open ALSO ANY ALSO NOT ZERO
        PERFORM emergency-stop
    WHEN OTHER
        CONTINUE
END-EVALUATE

Die PERFORM -Anweisung wird verwendet, um Schleifen zu definieren, die ausgeführt werden bis um eine Bedingung ist wahr (nicht während wahr, was in anderen Sprachen häufiger vorkommt). Es wird auch verwendet, um Prozeduren oder Prozedurbereiche aufzurufen (weitere Informationen finden Sie im Abschnitt Prozeduren). CALL und INVOKE Aufruf von Unterprogrammen bzw. Methoden. Der Name des Unterprogramms/der Methode ist in einem String enthalten, der ein Literal oder ein Datenelement sein kann. Parameter können per Referenz, per Inhalt (wo eine Kopie per Referenz übergeben wird) oder per Wert (aber nur wenn ein Prototyp verfügbar ist) übergeben werden.CANCEL entlädt Unterprogramme aus dem Speicher. GO TO bewirkt, dass das Programm zu einer angegebenen Prozedur springt.

Die GOBACK -Anweisung ist eine Rückgabeanweisung und die STOP -Anweisung stoppt das Programm. 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 a . ausgelöst RAISE -Anweisung und mit einem Handler erwischt, oder deklarativ, definiert im DECLARATIVES Teil der Verfahrensabteilung. Deklarative sind Abschnitte, die mit a . beginnen USE -Anweisung, die die zu behandelnden Fehler angibt. Ausnahmen können Namen oder Objekte sein. RESUME wird in einem Deklarativ verwendet, um zu der Anweisung nach der Anweisung zu springen, die die Ausnahme ausgelöst hat, oder zu einer Prozedur außerhalb der DECLARATIVES. Im Gegensatz zu anderen Sprachen beenden nicht abgefangene Ausnahmen das Programm möglicherweise nicht und das Programm kann unbeeinflusst weiterlaufen.

E/A[edit]

Datei-I/O wird vom selbstbeschreibenden OPEN, CLOSE, READ, und WRITE Aussagen zusammen mit drei weiteren: REWRITE, die einen Datensatz aktualisiert; START, das nachfolgende Datensätze für den Zugriff auswählt, indem ein Datensatz mit einem bestimmten Schlüssel gefunden wird; und UNLOCK, die eine Sperre für den zuletzt aufgerufenen Datensatz aufhebt.

Die Benutzerinteraktion erfolgt über ACCEPT und DISPLAY.

Datenmanipulation[edit]

Die folgenden Verben manipulieren Daten:

• INITIALIZE, wodurch Datenelemente auf ihre Standardwerte gesetzt werden.
• MOVE, das Datenelementen Werte zuweist ; ENTSPRECHEND BEWEGEN weist entsprechende gleichnamige Felder zu.
• SET, das 15 Formate hat: Es kann unter anderem Indizes ändern, Objektreferenzen zuweisen und Tabellenkapazitäten ändern.
• ADD, SUBTRACT, MULTIPLY, DIVIDE, und COMPUTE, die Arithmetik behandeln (mit COMPUTE das Ergebnis einer Formel einer Variablen zuordnen).
• ALLOCATE und FREE, die dynamischen Speicher verarbeiten.
• VALIDATE, die Daten wie in der Beschreibung eines Artikels in der Datenabteilung angegeben validiert und verteilt.
• STRING und UNSTRING, die Zeichenfolgen verketten und aufteilen.
• INSPECT, die Instanzen von angegebenen Teilzeichenfolgen innerhalb einer Zeichenfolge auszählt oder ersetzt.
• SEARCH, die eine Tabelle nach dem ersten Eintrag durchsucht, der eine Bedingung erfüllt.

Dateien und Tabellen werden sortiert mit SORT und der MERGE verb führt Dateien zusammen und sortiert sie. Die RELEASE Verb bietet Datensätze zum Sortieren und RETURN ruft sortierte Datensätze der Reihe nach ab.

Scope-Beendigung[edit]

Einige Aussagen, wie z IF und READ, können selbst Anweisungen enthalten. Solche Erklärungen können auf zwei Arten beendet werden: durch einen Zeitraum (implizite Beendigung), die endet alle nicht abgeschlossene Anweisungen enthalten sind, oder von einem Gültigkeitsbereich-Terminator, der die nächste übereinstimmende offene Anweisung beendet.

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

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

Verschachtelte Anweisungen, die mit einem Punkt abgeschlossen werden, sind eine häufige Fehlerquelle. Untersuchen Sie beispielsweise den folgenden Code:

IF x
    DISPLAY y.
    DISPLAY z.

Hier soll angezeigt werden y und z wenn Bedingung x ist wahr. Jedoch, z wird unabhängig vom Wert von . angezeigt x weil das IF Anweisung wird durch einen irrtümlichen Zeitraum beendet, nachdem DISPLAY y.

Ein weiterer Fehler ist das Ergebnis des Dangling-Else-Problems, wenn zwei IF Aussagen können mit einem in Verbindung gebracht werden ELSE.

IF x
    IF y
        DISPLAY a
ELSE
    DISPLAY b.

Im obigen Fragment ist die ELSE assoziiert mit dem IF y Aussage statt der IF x -Anweisung, die einen Fehler verursacht. Vor der Einführung expliziter Geltungsbereichs-Begrenzer wäre es erforderlich, dies zu verhindern ELSE NEXT SENTENCE nach dem inneren platziert werden IF.

Selbstmodifizierender Code[edit]

Die ursprüngliche COBOL-Spezifikation (1959) unterstützte die berüchtigten ALTER X TO PROCEED TO Y -Anweisung, für die viele Compiler selbstmodifizierenden Code generierten. X und Y sind Verfahrensbezeichnungen, und die einzelnen GO TO Aussage im Verfahren X ausgeführt nach einem solchen ALTER Aussage bedeutet GO TO Y stattdessen. Viele Compiler unterstützen es immer noch,^[148]
Sie wurde jedoch im COBOL-Standard von 1985 als veraltet erachtet und 2002 gestrichen.

Die ALTER -Anweisung wurde wenig beachtet, weil sie die “Lokalität des Kontexts” 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 gesehen hat, sich so schnell wie möglich damit vertraut machen muss, manchmal unter kritischem Zeitdruck, weil das Programm gescheitert ist … der Anblick eines GO TO -Anweisung in einem Absatz allein, die die Existenz einer unbekannten Anzahl von ALTER-Anweisungen an unbekannten Stellen im gesamten Programm signalisiert, lässt selbst den tapfersten Programmierer Angst haben.”

Hallo Welt[edit]

Ein “Hallo Welt”-Programm in COBOL:

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

Als das – mittlerweile berühmte – „Hallo Welt!“ Programmbeispiel in Die Programmiersprache C 1978 erstmals veröffentlicht wurde, wäre ein ähnliches COBOL-Programmbeispiel für Großrechner über JCL eingereicht worden, sehr wahrscheinlich mit einem Lochkartenleser und 80 Spaltenlochkarten. Die Auflistung unten, mit einer leeren DATA DIVISION, wurde mit Linux und dem Emulator System/370 Hercules mit MVS 3.8J getestet. Die im Juli 2015 geschriebene JCL ist aus den Hercules-Tutorials und -Beispielen abgeleitet, die von Jay Moseley gehostet werden.^[151] Im Einklang mit der damaligen COBOL-Programmierung 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* VALIDATION OF BASE COBOL INSTALL                                00050000
 01000 IDENTIFICATION DIVISION.                                         00060000
 01100 PROGRAM-ID. 'HELLO'.                                             00070000
 02000 ENVIRONMENT DIVISION.                                            00080000
 02100 CONFIGURATION SECTION.                                           00090000
 02110 SOURCE-COMPUTER.  GNULINUX.                                      00100000
 02120 OBJECT-COMPUTER.  HERCULES.                                      00110000
 02200 SPECIAL-NAMES.                                                   00120000
 02210     CONSOLE IS CONSL.                                            00130000
 03000 DATA DIVISION.                                                   00140000
 04000 PROCEDURE DIVISION.                                              00150000
 04100 00-MAIN.                                                         00160000
 04110     DISPLAY 'HELLO, WORLD' UPON CONSL.                           00170000
 04900     STOP RUN.                                                    00180000
//LKED.SYSLIB DD DSNAME=SYS1.COBLIB,DISP=SHR                            00190000
//            DD DSNAME=SYS1.LINKLIB,DISP=SHR                           00200000
//GO.SYSPRINT DD SYSOUT=A                                               00210000
//                                                                      00220000

Nach dem Senden der JCL zeigte die MVS-Konsole Folgendes an:

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

Zeile 10 der obigen Konsolenauflistung ist zur Wirkung hervorgehoben, die Hervorhebung ist nicht Teil der eigentlichen Konsolenausgabe.

Die zugehörige Compiler-Auflistung generierte über vier Seiten technische Details und Informationen zur Jobausführung für die einzelne Ausgabezeile der 14 COBOL-Zeilen.

Rezeption[edit]

Fehlende Struktur[edit]

In den 1970er Jahren wurde das Paradigma der strukturierten Programmierung zunehmend verbreitet. Edsger Dijkstra, ein herausragender Informatiker, schrieb einen Brief an den Herausgeber von Communications of the ACM, veröffentlicht 1975 mit dem Titel “Wie sagen wir Wahrheiten, die weh tun könnten?”, in dem er COBOL und mehrere andere zeitgenössische Sprachen kritisierte; bemerkt, dass “die Verwendung von COBOL den Verstand lähmt”.^[152]
In einem veröffentlichten Dissens zu Dijkstras Bemerkungen behauptete der Informatiker Howard E. Tompkins, dass unstrukturiertes COBOL dazu neigt, “von Programmierern geschrieben zu werden, die nie die Vorteile von strukturiertem COBOL gut gelehrt haben”, und argumentierte, dass es in erster Linie um die Ausbildung gehe.^[153]

Eine Ursache für Spaghetti-Code war der GO TO Stellungnahme. Versuche zu entfernen GO TOs von COBOL-Code führte jedoch zu verschachtelten Programmen und reduzierter Codequalität.GO TOs wurden weitgehend ersetzt durch die PERFORM Anweisungen und Prozeduren, die die modulare Programmierung förderten und einen einfachen Zugriff auf leistungsstarke Schleifenfunktionen ermöglichten. Jedoch, PERFORM konnte nur mit Prozeduren verwendet werden, so dass Schleifenkörper nicht dort lokalisiert waren, wo sie verwendet wurden, was die Verständlichkeit von Programmen erschwerte.

COBOL-Programme waren berüchtigt dafür, monolithisch zu sein und keine Modularisierung zu haben.^[156]
COBOL-Code konnte nur durch Verfahren 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. ein Verfahren konnte darauf zugreifen und es ändern irgendein Datenelement. Außerdem gab es keine Möglichkeit, Parameter an ein Verfahren zu übergeben, eine Unterlassung, die Jean Sammet als den größten Fehler des Ausschusses ansah. Eine weitere Komplikation ergab sich aus der Fähigkeit, PERFORM THRU eine festgelegte Reihenfolge von Verfahren. Dies bedeutete, dass die Kontrolle zu jeder Prozedur springen und von ihr zurückkehren konnte, was einen komplizierten Kontrollfluss erzeugte und es einem Programmierer ermöglichte, die Single-Entry-Single-Exit-Regel zu brechen.

Diese Situation verbesserte sich, als COBOL mehr Funktionen einführte. COBOL-74 fügte Unterprogramme hinzu, die Programmierern die Möglichkeit geben, die Daten zu kontrollieren, auf die jeder Teil des Programms zugreifen kann. COBOL-85 fügte dann verschachtelte Unterprogramme hinzu, sodass Programmierer Unterprogramme ausblenden können. Eine weitere Kontrolle über Daten und Code kam 2002, als objektorientierte Programmierung, benutzerdefinierte Funktionen und benutzerdefinierte Datentypen aufgenommen wurden.

Nichtsdestotrotz verwendet viele wichtige Legacy-COBOL-Software unstrukturierten Code, der nicht mehr wartbar geworden ist. Es kann zu riskant und kostspielig sein, auch nur einen einfachen Codeabschnitt zu ändern, da er von unbekannten Orten auf unbekannte Weise verwendet werden kann.^[160]

Kompatibilitätsprobleme[edit]

COBOL sollte eine hochportable, “gemeinsame” Sprache sein. Bis 2001 waren jedoch rund 300 Dialekte entstanden.^[161] 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 erlaubte 104.976 offizielle Varianten.^[162]

COBOL-85 war mit früheren Versionen nicht vollständig kompatibel und seine Entwicklung war umstritten. Joseph T. Brophy, der CIO von Travellers Insurance, leitete die Bemühungen, COBOL-Benutzer über die hohen Kosten für die Neuprogrammierung der Implementierung des neuen Standards zu informieren. Infolgedessen erhielt der ANSI COBOL-Ausschuss mehr als 2.200 Briefe aus der Öffentlichkeit, meist negative, die den Ausschuss zu Änderungen aufforderten. Andererseits wurde angenommen, dass die Umstellung auf COBOL-85 die Produktivität in den kommenden Jahren steigern würde, was die Umstellungskosten rechtfertigte.

Ausführliche Syntax[edit]

Die COBOL-Syntax wurde oft wegen ihrer Ausführlichkeit kritisiert. Befürworter sagen, dass dies dazu gedacht war, den Code selbstdokumentierend zu machen, was die Programmwartung erleichtert. COBOL sollte auch für Programmierer leicht zu erlernen und zu verwenden sein, während es für nicht-technisches Personal wie Manager lesbar ist. Der Wunsch nach Lesbarkeit führte zur Verwendung einer englischähnlichen Syntax und Strukturelementen wie Substantiven, Verben, Klauseln, Sätzen, Abschnitten und Divisionen. 1984 hatten die Betreuer von COBOL-Programmen jedoch Schwierigkeiten, mit “unverständlichem” Code umzugehen, und die wichtigsten Änderungen in COBOL-85 dienten dazu, die Wartung zu erleichtern.^[88]

Jean Sammet, ein Mitglied des Kurzstrecken-Komitees, bemerkte, dass “wenig versucht wurde, den professionellen Programmierer zu bedienen, tatsächlich neigen Leute, deren Hauptinteresse das Programmieren ist, dazu, mit COBOL sehr unzufrieden zu sein”, was sie der ausführlichen Syntax von COBOL zuschrieb.

[edit]

Die COBOL-Community war schon immer von der Informatik-Community isoliert. An der Entwicklung von COBOL waren keine akademischen Informatiker beteiligt: ​​Alle Mitglieder des Ausschusses kamen aus der Wirtschaft oder der Regierung. Die damaligen Informatiker interessierten sich mehr für Bereiche wie numerische Analysis, 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” aufgrund seiner Uneleganz, den Mangel an einflussreichen Informatikern, die am Designprozess beteiligt waren, und eine Verachtung für die Geschäftsdatenverarbeitung zurück. Die COBOL-Spezifikation verwendete eine einzigartige “Notation” oder Metasprache, um ihre Syntax zu definieren, und nicht die neue Backus-Naur-Form, von der das Komitee nichts wusste. Dies führte zu “starker” Kritik.

Später litt COBOL unter Materialmangel; es dauerte bis 1963, bis einführende Bücher erschienen (Richard D. Irwin veröffentlichte 1966 ein College-Lehrbuch über COBOL).^[177] 1985 gab es in der Library of Congress doppelt so viele Bücher über Fortran und viermal so viele über BASIC wie über COBOL. Universitätsprofessoren lehrten modernere, auf dem neuesten Stand der Technik befindliche Sprachen und Techniken anstelle von COBOL, das den Charakter einer “Handelsschule” hatte. Donald Nelson, Vorsitzender des CODASYL COBOL-Komitees, sagte 1984, dass “Akademiker … COBOL hassen” und dass Informatikabsolventen “COBOL hassen” eingedrillt hätten.^[179] Eine Umfrage von Micro Focus aus dem Jahr 2013 ergab, dass 20 % der Universitätsakademiker COBOL für veraltet oder tot hielten und dass 55 % glaubten, dass ihre Studenten COBOL für veraltet oder tot hielten. Dieselbe Umfrage ergab auch, dass nur 25 % der Akademiker COBOL-Programmierung auf ihrem Lehrplan hatten, obwohl 60 % der Meinung waren, dass sie es unterrichten sollten.^[180]
Im Gegensatz dazu war COBOL 2003 in 80 % der Lehrpläne für Informationssysteme in den Vereinigten Staaten enthalten, der gleiche Anteil wie C++ und Java.

Es gab auch erhebliche Herablassung gegenüber COBOL in der Geschäftswelt von Benutzern anderer Sprachen, zum Beispiel FORTRAN oder Assembler, was bedeutete, dass COBOL nur für nicht anspruchsvolle Probleme verwendet werden konnte.^{[citation needed]}

Bedenken bezüglich des Designprozesses[edit]

An der Kompetenz des Normenausschusses wurden Zweifel geäußert. Das kurzfristige Ausschussmitglied Howard Bromberg sagte, es gebe “wenig Kontrolle” über den Entwicklungsprozess und er sei “geplagt von Personaldiskontinuität und … Mangel an Talenten”. Jean Sammet und Jerome Garfunkel stellten auch fest, dass Änderungen, die in einer Revision des Standards eingeführt wurden, in der nächsten wieder rückgängig gemacht würden, sowohl aufgrund von Änderungen der Mitglieder des Standardkomitees als auch aufgrund objektiver Beweise.^[182]

COBOL-Standards haben wiederholt unter Verzögerungen gelitten: COBOL-85 kam fünf Jahre später als erhofft an,^[183]
COBOL 2002 war fünf Jahre zu spät,^[2]
und COBOL 2014 war sechs Jahre zu spät.^[95][184]
Um Verzögerungen entgegenzuwirken, erlaubte das Standardkomitee die Erstellung optionaler Ergänzungen, die Funktionen schneller hinzufügen würden, als auf die nächste Standardrevision warten zu müssen. Einige Ausschussmitglieder äußerten jedoch Bedenken hinsichtlich Inkompatibilitäten zwischen Implementierungen und häufigen Änderungen des Standards.^[185]

Einflüsse auf andere Sprachen[edit]

Die Datenstrukturen von COBOL beeinflussten nachfolgende Programmiersprachen. Seine Datensatz- und Dateistruktur beeinflusste PL/I und Pascal, und die REDEFINES -Klausel war ein Vorläufer von Pascals Variant-Records. Explizite Dateistrukturdefinitionen gingen der Entwicklung von Datenbankverwaltungssystemen voraus, und aggregierte Daten waren ein bedeutender Fortschritt gegenüber den Arrays von Fortran.PICTURE Datendeklarationen wurden mit geringfügigen Änderungen in PL/I aufgenommen.

COBOLs COPY Obwohl die Einrichtung als “primitiv” angesehen wurde, beeinflusste sie die Entwicklung von Include-Richtlinien.

Der Fokus auf Portabilität und Standardisierung bedeutete, dass in COBOL geschriebene Programme portierbar waren und die Verbreitung der Sprache auf eine Vielzahl von Hardwareplattformen und Betriebssystemen erleichterte.^[187] Zudem schränkt die klar definierte Divisionsstruktur die Definition externer Referenzen auf die Environment Division ein, was insbesondere Plattformwechsel vereinfacht.^[188]

Siehe auch[edit]

Verweise[edit]

Zitate[edit]

Quellen[edit]

Externe Links[edit]