コボル

コボル

CODASYLへのCOBOL 60レポート(1960 年 4 月)
パラダイム	手続き型、命令型、オブジェクト指向、汎用
デザイン：	ハワード・ブロムバーグ、ノーマン・ディスカウント、ヴァーノン・リーブス、ジーン・E・サメット、ウィリアム・セルデン、ガートルード・ティアニー、間接的にグレース・ホッパーの影響を受けた[1]
開発者	CODASYL、ANSI、ISO / IEC
初登場	1959年; 66年前 （1959年）
安定版リリース	ISO/IEC 1989:2023 / 2023
タイピングの規律	弱い、静的
ファイル名拡張子	.cbl、、.cob​.cpy
主な実装
GnuCOBOL、IBM COBOL、 Micro Focus Visual COBOL
方言
COBOL/2、DEC COBOL-10、DEC PDP-11 COBOL、DEC PDP-11 COBOL-85、DEC VAX COBOL、DOSVS COBOL、Envyr ICOBOL、富士通 COBOL、日立 COBOL2002、HP3000 COBOL/II、IBM COBOL SAA、IBM COBOL/400、IBM COBOL/II、IBM Enterprise COBOL、IBM ILE COBOL、IBM OS/VS COBOL、ICL COBOL (VME)、Micro Focus ACUCOBOL-GT、Micro Focus COBOL-IT、Micro Focus RM/COBOL、Micro Focus Visual COBOL、Microsoft COBOL、Raincode COBOL、Realia COBOL、Ryan McFarland RM/COBOL、Ryan McFarland RM/COBOL-85、Tandem (NonStop) COBOL、Tandem (NonStop) SCOBOL、 UNIVAC COBOL、Unisys MCP COBOL74、Unisys MCP COBOL85、X/Open COBOL、[2] Veryant isCOBOL、Wang VS COBOL、WATBOL
影響を受けた
初期: AIMACO、COMTRAN、FACT、FLOW-MATIC COBOL 2002: [a] C++、Eiffel、Smalltalk
影響を受けた
CobolScript、[6] EGL、[7] PL/I、[8] PL/B [9]
Wikibooks の COBOL

COBOL（/ ˈ k oʊ b ɒ l、 - b ɔː l / ; 「共通ビジネス指向言語」の頭字語）は、ビジネス用に設計された英語に似たコンパイル型のコンピュータプログラミング言語です。命令型、手続き型、および2002年以降はオブジェクト指向言語です。COBOLは主に企業や政府のビジネス、金融、および管理システムで使用されています。COBOLは、大規模なバッチ処理やトランザクション処理ジョブなど、メインフレームコンピューターに展開されるアプリケーションで今でも広く使用されています。多くの大手金融機関は、2006年までこの言語で新しいシステムを開発していましたが、^[10]今日COBOLでプログラミングされているほとんどのプログラミングは、既存のアプリケーションを純粋に維持するためのものです。プログラムは新しいプラットフォームに移行されたり、最新の言語で書き直されたり、他のソフトウェアに置き換えられたりしています。^[11]

COBOLは1959年にCODASYLによって設計され、グレース・ホッパーによって設計されたプログラミング言語FLOW-MATICを部分的にベースとしています。これは、データ処理用の移植可能なプログラミング言語を作成するという米国国防総省の取り組みの一環として作成されました。当初は一時的な解決策と見なされていましたが、国防総省はすぐにコンピュータメーカーにそれを提供するよう圧力をかけ、広く採用されるようになりました。^{[12] 1968年に}標準化され、5回改訂されています。拡張には、構造化プログラミングとオブジェクト指向プログラミングのサポートが含まれます。現在の標準はISO / IEC  1989:2023です。^[13]

COBOL ステートメントには、などの散文構文があり、自己文書化され、管理者などの非プログラマーにとって非常に読みやすいように設計されています。ただし、他の言語の簡潔で数学的な構文と比較すると 冗長であり、300 を超える予約語を使用します。MOVE x TO y

COBOL コードは 4 つの部分(識別、環境、データ、および手順) に分かれており、セクション、段落、および文の厳格な階層構造が含まれています。大規模な標準ライブラリがないため、この標準では 43 のステートメント、87 の関数、および 1 つのクラスのみが指定されています。

COBOLが作られた当時、学術的なコンピュータ科学者は一般的にビジネスアプリケーションに興味がなく、その設計にも関わっていなかった。COBOLは（事実上）ビジネス用のコンピュータ言語としてゼロから設計され、入力と出力に重点が置かれ、データ型は数字とテキストの文字列だけだった。^[14]

COBOL は、冗長性、設計プロセス、構造化プログラミングのサポート不足などの点で批判されてきました。これらの弱点により、ローカルでは読みやすいものの、全体としては理解しにくいモノリシックなプログラムが生まれます。

長年、COBOLはメインフレームでの業務処理のためのプログラミング言語として想定されてきましたが^[15]、近年では多くのCOBOL処理がクラウドコンピューティングに移行されています^[16]。

1950年代後半、コンピュータユーザーとメーカーはプログラミングコストの上昇を懸念し始めた。1959年の調査では、データ処理設備のプログラミングコストは平均80万ドル、新しいハードウェアで実行できるようにプログラムを変換するには60万ドルかかることが判明した。新しいプログラミング言語が急増していた当時、同じ調査では、共通のビジネス指向言語を使用すれば、変換ははるかに安価で迅速になると示唆されていた。^[17]

1959年4月8日、バローズ社のコンピュータ科学者であるメアリー・K・ホーズは、ペンシルバニア大学で学界、コンピュータユーザー、メーカーの代表者を集め、共通ビジネス言語に関する正式な会議を開催した。^[18]代表者には、グレース・ホッパー（英語風データ処理言語FLOW-MATICの発明者）、ジーン・サメット、ソール・ゴーンが含まれていた。^{[19] [20]}

4 月の会議で、このグループは国防総省(DoD) に、共通のビジネス言語を作成する取り組みを後援するよう要請した。この代表団は、国防総省のデータ システム リサーチ スタッフのディレクターであるチャールズ A. フィリップスに感銘を与えた。^[21]彼は、代表団が国防総省の問題を「完全に理解している」と考えていた。国防総省は 225 台のコンピューターを運用し、さらに 175 台を発注しており、それらのコンピューターで実行するプログラムの実装に 2 億ドル以上を費やしていた。ポータブル プログラムがあれば、時間を節約し、コストを削減し、近代化を容易にすることができる。^[22]

チャールズ・フィリップスは会議の主催に同意し、代表団に議題の起草を任せた。^[23]

1959年5月28日と29日（チューリッヒALGOL 58会議のちょうど1年後）、ペンタゴンでビジネス用の共通プログラミング言語の作成について議論する会議が開催されました。41人が出席し、フィリップスが議長を務めました。 ^[24]国防総省は、同じデータ処理プログラムを異なるコンピューターで実行できるかどうかを懸念していました。当時唯一の主流言語であったFORTRANには、そのようなプログラムを書くために必要な機能が欠けていました。 ^[25]

代表者たちは、銀行や保険から公共事業や在庫管理まで、さまざまな環境で機能する言語について熱心に説明した。彼らは、より多くの人がプログラミングできるようにすべきであり、新しい言語は現代の技術の限界によって制限されるべきではないことに全会一致で同意した。大多数は、その言語は英語を最大限に活用し、変更が可能で、マシンに依存せず、パワーを犠牲にしても使いやすいものでなければならないことに同意した。^[26]

この会議の結果、運営委員会と短期、中期、長期の各委員会が設立された。短期委員会には暫定的な言語の仕様を作成するために9月（3か月）までが与えられ、その後他の委員会によって改良されることとなった。^{[27] [28]}しかし、彼らの公式の使命は既存のプログラミング言語の長所と短所を特定することであり、新しい言語を作成するように明示的に指示されたわけではなかった。^[25]

短期委員会は期限に驚きを隠さなかった。^[29]委員の一人、ベティ・ホルバートン氏は3ヶ月という期限を「非常に楽観的」と評し、その文言が本当に一時的な解決策になるのか疑問視した。^[30]

運営委員会は6月4日に会合を開き、活動全体をデータシステム言語委員会（CODASYL）と命名し、執行委員会を設置することに合意した。^[31]

短期委員会のメンバーは、6つのコンピュータメーカーと3つの政府機関を代表していた。コンピュータメーカーは、バローズ・コーポレーション、IBM、ミネアポリス・ハネウェル（ハネウェル研究所）、RCA、スペリー・ランド、シルバニア・エレクトリック・プロダクツである。政府機関は、米国空軍、海軍のデビッド・テイラー・モデル・ベイスン、および国立標準局（現在の米国国立標準技術研究所）である。^[32]委員会の議長は、米国国立標準局のジョセフ・ウェグスタインであった。作業は、データの説明、ステートメント、既存のアプリケーション、およびユーザーエクスペリエンスの調査から始まった。^[33]

委員会は主にFLOW-MATIC、AIMACO、COMTRANプログラミング言語を検討した。^{[25] [34]} FLOW-MATIC言語は実装されており、AIMACOはわずかな変更を加えた派生言語であったため、特に影響力があった。^{[35] [36]} FLOW-MATICの発明者であるグレース・ホッパーも委員会の技術顧問を務めた。^[29] FLOW-MATICがCOBOLにもたらした主な貢献は、長い変数名、コマンドの英語の単語、データ記述と命令の分離であった。^[37]

ホッパーは「COBOLの母」や「COBOLの祖母」と呼ばれることもあるが^{[38] [39] [40] 、COBOLの主任設計者である}ジャン・サメットはホッパーは「COBOLの母でも、創造者でも、開発者でもない」と述べている^{[41] [1] 。}

ボブ・ベマーが発明したIBMのCOMTRAN言語は、グレース・ホッパーの同僚で構成された短期委員会によってFLOW-MATIC ^{[42] [43]}の競合相手とみなされた。 ^[44]その機能の一部は、IBMが設計プロセスを支配したようには見えないようにCOBOLには組み込まれなかった。^[27]また、ジャン・サメットは1981年に、一部の委員会メンバー（彼女自身も含む）から「強い反IBM的偏見」があったと述べた。^[45]あるケースでは、COMTRANマニュアルの著者であり中期委員会メンバーであるロイ・ゴールドフィンガーが、彼の言語をサポートし代数式の使用を奨励するために小委員会の会議に出席した後、グレース・ホッパーは、英語に基づく言語を作成するスペリー・ランドの努力を繰り返すメモを短期委員会に送った。^[46]

1980年、グレース・ホッパーは「COBOL 60は95%がFLOW-MATIC」であり、COMTRANの影響は「極めて小さい」とコメントした。さらに、彼女は、この作業がFLOW-MATICとCOMTRANの両方から影響を受けていると主張するのは、「他の人を満足させ、彼らが私たちを追い出そうとしないようにするため」だけだと述べた。^[47]

COBOLに取り入れられたCOMTRANの機能には、数式^[48]、PICTURE句^{[49] 、} GO TOIFの必要性を排除した改良されたステートメント、より堅牢なファイル管理システム^{[42]などがありました。}

委員会の作業の有用性は大きな議論の的となった。委員の中には、この言語には多くの妥協があり、委員会による設計の結果であると考える者もいたが、検討した3つの言語よりも優れていると考える者もいた。言語が複雑すぎると考える者もいれば、単純すぎると考える者もいた。^[50]

議論を呼んだ機能には、データ処理ユーザーにとって役に立たない、あるいは高度すぎると考えるものもあった。そのような機能には、ブール式、数式、表の添え字（インデックス）などがある。^{[51] [52]もう一つの議論のポイントは、キーワードを文脈依存にするかどうかと、それが読みやすさに与える影響だった。 [51]}文脈依存のキーワードは却下されたが、このアプローチは後にPL/Iで使用され、2002年からはCOBOLでも部分的に使用された。 ^{[53 ]}対話性、オペレーティングシステムとの対話（当時はほとんど存在しなかった）、関数（純粋に数学的でデータ処理には役に立たないと考えられていた）についてはほとんど考慮されなかった。 ^{[54] [55]}

仕様は9月4日に執行委員会に提出されたが、期待に応えられなかった。ジョセフ・ウェグスタインは「粗雑な部分があり、追加する必要がある」と指摘し、ボブ・ベマーは後に「寄せ集め」と評した。委員会には12月までに改善するよう命じられた。^[29]

9月中旬の会議で、委員会は新しい言語の名前について議論した。提案には「BUSY」（ビジネスシステム）、「INFOSYL」（情報システム言語）、「COCOSYL」（共通コンピュータシステム言語）などがあった。^[56]「COBOL」という名前を誰が作ったのかは不明だが、^{[57] [58]}ボブ・ベマーは後にそれが自分の提案だったと主張した。^{[59] [60] [61]}

10月に中級委員会はロイ・ナットが作成したFACT言語仕様のコピーを受け取りました。その機能に委員会は非常に感銘を受け、COBOLをそれに基づいて作成するという決議を可決しました。^[62]

これは、仕様策定で大きな進展を遂げていた短期委員会にとって打撃となった。技術的には優れているものの、FACTは移植性を考慮して開発されておらず、メーカーとユーザーの合意も得られていなかった。また、実証可能な実装も欠いており、^[29] FLOW-MATICベースのCOBOLの支持者が決議を覆すことができた。RCA代表のハワード・ブロムバーグもFACTを阻止し、RCAのCOBOL実装の取り組みが無駄にならないようにした。^[63]

委員会が大きすぎて、すぐにはそれ以上の進展が見込めないことがすぐに明らかになった。苛立ったハワード・ブロンバーグは「COBOL」と刻まれた15ドルの墓石を購入し、チャールズ・フィリップスに不満を表明するために送った。^{[b] [65] [66]}

既存の言語を分析するために小委員会が結成され、6人のメンバーで構成されました。^{[25] [67]}

• IBMのウィリアム・セルデンとガートルード・ティアニー、
• RCAのハワード・ブロムバーグとハワード・ディスカウント、
• シルバニア・エレクトリック・プロダクツのヴァーノン・リーブス氏とジーン・E・サメット氏。

小委員会は仕様作成の作業のほとんどを行い、短期委員会にその作業のレビューと修正を任せて、最終的な仕様を作成しました。^[25]

仕様は1960年1月8日に執行委員会で承認され、政府の印刷局に送られ、COBOL 60として印刷されました。この言語の目的は、効率的で移植性の高いプログラムを簡単に作成できるようにすること、ユーザーが最小限の労力とコストで新しいシステムに移行できるようにすること、そして経験の浅いプログラマーにも適していることでした。^[68]

CODASYL執行委員会は後に、ユーザーやベンダーからの質問に答え、仕様を改善・拡張するためにCOBOL保守委員会を設立した。^[69]

1960年、COBOLコンパイラーの開発を計画しているメーカーのリストは増えていった。9月までにさらに5社のメーカーがCODASYLに加わり（Bendix、Control Data Corporation、General Electric (GE)、National Cash Register、Philco）、参加メーカーはすべてCOBOLコンパイラーを発表した。GEとIBMは、それぞれGECOMとCOMTRANという自社の言語にCOBOLを統合することを計画していた。対照的に、International Computers and Tabulatorsは自社の言語CODELをCOBOLに置き換えることを計画していた。^[70]

一方、RCAとスペリーランドはCOBOLコンパイラの作成に取り組んでいた。最初のCOBOLプログラムは8月17日にRCA 501で実行された。^[71] 12月6日と7日には、同じCOBOLプログラム（若干の変更はあるものの）がRCAコンピュータとレミントンランドのUnivacコンピュータで実行され、互換性が実現できることが実証された。^[72]

使用された言語の相対的な影響は、すべての COBOL リファレンス マニュアルに印刷されている推奨アドバイスに今でも示されています。

COBOL は業界言語であり、いかなる企業または企業グループ、あるいはいかなる組織または組織グループの所有物でもありません。

明示的または黙示的を問わず、いかなる貢献者も CODASYL COBOL 委員会も、プログラミング システムおよび言語の正確性および機能に関して一切の保証を行いません。また、いかなる貢献者も委員会も、これに関して一切の責任を負いません。ここで使用されている著作権で保護された資料の著者および著作権所有者は次のとおりです。

FLOW-MATIC ( Unisys Corporationの商標)、UNIVAC (R) I および II、データ自動化システムのプログラミング、1958 年、1959 年、Unisys Corporation が著作権を取得; IBM Commercial Translator Form No. F28-8013、1959 年、IBM が著作権を取得; FACT、DSI 27A5260-2760、1960 年、Minneapolis-Honeywell が著作権を取得。

彼らは、この資料の全部または一部をCOBOL仕様で使用することを明示的に許可しています。このような許可は、プログラミングマニュアルや同様の出版物におけるCOBOL仕様の複製および使用にも適用されます。^[73]

COBOL 60には多くの論理的欠陥が発見され、ゼネラル・エレクトリックのチャールズ・カッツは、COBOL 60 は明確に解釈できないと警告した。消極的な短期委員会が全面的なクリーンアップを実施し、1963年3月までに、意味の曖昧さは残るものの、COBOL の構文はALGOLと同様に定義可能であると報告された。^[70]

COBOL は、構文が大きく、構文構造内にオプション要素が多数あるため、コンパイラを書くのが難しい言語です。また、多くのデータ表現、暗黙の型変換、I/O 操作に必要なセットアップを備えた言語に対して効率的なコードを生成する必要があります。^[75]初期の COBOL コンパイラは原始的で低速でした。1962 年の米国海軍の評価では、コンパイル速度は 1 分あたり 3 ～ 11 ステートメントでした。1964 年半ばまでに、1 分あたり 11 ～ 1000 ステートメントに増加しました。メモリを増やすと速度が大幅に向上し、コンパイル コストは大きく異なることが確認されました。1 ステートメントあたりのコストは 0.23 ドルから 18.91 ドルでした。^[76]

1962年後半、IBMはCOBOLを主な開発言語とし、COMTRANの開発を中止すると発表した。^[76]

COBOL仕様は、発行後5年間で3回改訂されました。COBOL-60は1961年にCOBOL-61に置き換えられました。これは1963年にCOBOL-61拡張仕様に置き換えられ、ソート機能とレポートライター機能が導入されました。^[77]追加された機能は、1959年後半にハネウェルが短期委員会に宛てた手紙で特定した欠陥を修正しました。^[71] COBOLエディション1965では、仕様がさらに明確化され、大容量ストレージファイルとテーブルを処理する機能が導入されました。^[78]

COBOLのバージョン間の非互換性を克服するために標準化の取り組みが始まりました。1962年後半、ISOと米国規格協会（現在のANSI）の両方が標準を作成するためのグループを結成しました。ANSIは1968年8月に米国規格COBOL X3.23を作成し、これが後のバージョンの礎となりました。^[79]このバージョンはアメリカ国家規格（ANS）COBOLとして知られ、1972年にISOに採用されました。^[80]

1970年までに、COBOLは世界で最も広く使用されるプログラミング言語になりました。^[81]

ANSI委員会とは独立して、CODASYLプログラミング言語委員会が言語の改良に取り組んでいた。委員会は1968年、1969年、1970年、1973年に新しいバージョンを発表し、プログラム間通信、デバッグ、ファイルマージ機能などの新しい機能や、文字列処理やライブラリインクルード機能の改善などの変更点を盛り込んだ。^[82]

CODASYLはANSI委員会から独立していたが、CODASYL開発ジャーナルはANSIによって、実装に値するほど人気のある機能を特定するために使用されていた。^[83]プログラミング言語委員会は、ECMAおよび日本のCOBOL標準委員会とも連携していた。^[82]

しかし、プログラミング言語委員会はあまり知られていなかった。副委員長のウィリアム・ラインハルスは、COBOLコミュニティの3分の2が委員会の存在を知らないと不満を述べた。また、会議の議事録や変更提案などの公開文書を無料で公開するための資金も不足していた。^[84]

1974年、ANSIは(ANS)COBOLの改訂版を発行した。これにはファイル編成、ステートメントDELETE[ ^85]、セグメンテーションモジュール^[86]などの新機能が含まれていた。削除された機能にはNOTE、ステートメント、EXAMINEステートメント(に置き換えられたINSPECT)、実装者定義のランダムアクセスモジュール(新しいシーケンシャルI/Oモジュールと相対I/Oモジュールに置き換えられた)などがあった。これらは44の変更点となり、既存のステートメントは新しい標準と互換性がなくなった。^[87]レポートライターはCOBOLから削除される予定だったが、標準が発行される前に復活した。^{[88] [89]}その後、ISOは1978年に更新された標準を採用した。^[80]

1978 年 6 月、COBOL-74 の改訂作業が開始されました。提案された標準 (一般に COBOL-80 と呼ばれています) は以前の標準とは大きく異なり、非互換性と変換コストに関する懸念が生じました。1981 年 1 月、トラベラーズ インシュアランスの上級副社長であるジョセフ T. ブロフィ氏は、標準委員会がCOBOL-74 と上位互換性がないとして訴訟を起こすと脅しました。ブロフィ氏は、4,000 万行のコード ベースの以前の変換を「非生産的」で「プログラマー リソースの完全な無駄」と表現しました。^[90]その年の後半、データ処理管理協会(DPMA) は、新しい標準に「強く反対」すると述べました。その理由として、「法外な」変換コストと「ユーザーに強制される」機能強化を挙げました。^{[91] [92]}

最初の公開レビュー期間中、委員会は2,200件の回答を受け取り、そのうち1,700件は否定的な定型文でした。^[93]その他の回答は、COBOL-80がシステムに与える影響の詳細な分析であり、変換コストはコード1行あたり少なくとも50セントになると予測されていました。回答のうち、提案された標準に賛成したのは12件未満でした。^[94]

ISO TC97-SC5 は、1979 年にWim Ebbinkhuijsenの主導により、国際 COBOL 専門家グループを設立しました。このグループは、米国を含む多くの国の COBOL 専門家で構成されていました。その目標は、新しい COBOL 機能の必要性に関して、ANSI と世界のその他の国々の間で相互理解と尊重を達成することでした。3 年後、ISO はグループのステータスを正式なワーキング グループWG 4 COBOLに変更しました。このグループは COBOL 標準の主要な所有権と開発を引き継ぎ、ANSI がほとんどの提案を行いました。

1983年、DPMAは委員会が国民の懸念に応えたことを理由に、標準への反対を撤回した。同年、国立標準局の調査では、提案された標準にはほとんど問題がないとの結論が出された。^{[92] [95]} 1年後、DECはVAX/VMS COBOL-80をリリースし、COBOL-74プログラムの変換にはほとんど問題がないことを指摘した。新しいEVALUATEステートメントとインラインは特に好評で、制御フローとデバッグがPERFORM簡素化されたため、生産性が向上した。^[96]

2回目の公開レビューではさらに1,000件の（主に否定的な）回答が寄せられたが、最後のレビューではわずか25件しか寄せられず、その時点では多くの懸念事項が対処されていた。^[92]

1985 年、ISO ワーキング グループ 4 は、当時の AN​​SI 提案標準を承認し、いくつかの変更を加えて、新しい ISO 標準 COBOL 85 として設定しました。これは 1985 年後半に公開されました。

60の機能が変更または廃止され、115の機能^[97]が追加されました。^{[98] [99]}

• スコープターミネータ ( END-IF、END-PERFORM、END-READなど)
• ネストされたサブプログラム
• CONTINUE、無操作ステートメント
• EVALUATE、スイッチ文
• INITIALIZEデータのグループをデフォルト値に設定できるステートメント
• インラインPERFORMループ本体 - 以前は、ループ本体は別の手順で指定する必要がありました。
• 参照変更により部分文字列へのアクセスが可能
• I/O ステータス コード。

この新しい規格はANSIを含むすべての国家標準化団体によって採用された。^[80]

1989年と1993年に2度の改正が行われた。最初の改正では固有機能が導入され、他の改正では修正が行われた。^[80]

1997年、ガートナーグループは、 COBOLの総行数は2000億行に達し、ビジネスプログラムの80%がCOBOLで実行されていると推定した。^{[c] [100]}

1990年代初頭、COBOLの次の全面改訂版にオブジェクト指向を追加する作業が開始されました。オブジェクト指向の機能はC++とSmalltalkから取り入れられました。^{[3] [4]}

当初の見積もりでは、この改訂は1997年までに完了する予定であり、ISO委員会草案（CD）は1997年までに利用可能になった。一部のベンダー（Micro Focus、Fujitsu、IBMなど）は、完全な改訂の草案に基づいてオブジェクト指向構文を導入した。最終的に承認されたISO標準は、2002年後半に承認され、公開された。^[101]

富士通/GTSoftware、^{[102] Micro Focusは、} .NET Frameworkをターゲットとしたオブジェクト指向COBOLコンパイラを導入しました。

他にも多くの新機能があったが、その多くは1978年以来CODASYL COBOL Journal of Developmentに掲載されていたが、COBOL-85に収録される機会を逃していた。^[103]その他の機能には以下のものがある: ^{[104] [105]}

• 自由形式のコード
• ユーザー定義関数
• 再帰
• ロケールベースの処理
• Unicodeなどの拡張文字セットのサポート
• 浮動小数点およびバイナリデータ型 (それまでは、バイナリ項目は宣言の10 進数指定に基づいて切り捨てられていました)
• ポータブルな演算結果
• ビットおよびブールデータ型
• ストレージの取得と解放のためのポインタと構文
• テキストベースのSCREEN SECTIONユーザーインターフェース
• 施設VALIDATE​
• .NET やJavaなどの他のプログラミング言語やフレームワーク環境との相互運用性が向上しました。

この規格については3つの訂正が発行された。2006年に2つ、2009年に1つである。 ^[106]

2003年から2009年にかけて、COBOLのオブジェクトファイナライゼーション、XML処理、コレクションクラスについて説明した3つの技術レポートが作成されました。 ^[106]

COBOL 2002 はサポートが不十分で、標準を完全にサポートするコンパイラはありませんでした。マイクロフォーカスは、新機能に対するユーザーの需要が不足していることと、コンパイラの適合性をテストするために使用されていたNISTテストスイートが廃止されたことが原因であると判断しました。標準化プロセスも遅く、リソースが不足していることも判明しました。^[107]

COBOL 2014には以下の変更が含まれています。^[108]

• ポータブルな演算結果はIEEE 754データ型に置き換えられました
• VALIDATE機能、レポート作成機能、画面処理機能など​​の主要な機能はオプションになっています。
• メソッドのオーバーロード
• 動的容量テーブル（COBOL 2002のドラフトから削除された機能）^[109]

COBOL 2023 標準では、いくつかの新機能が追加されました。

• SENDおよびRECEIVEステートメントを使用した非同期メッセージング構文^[110]
• トランザクション処理機能とCOMMIT[ ROLLBACK^110]
• XOR論理演算子^[110]
• このCONTINUEステートメントは、指定された期間プログラムを一時停止するように拡張することができる^[111]
• 声明^[111DELETE FILE ]
• LINE SEQUENTIALファイル構成^[112]
• 無限ループの定義はPERFORM UNTIL EXIT^[111]
• SUBSTITUTE異なる長さの部分文字列の置換を可能にする組み込み関数^[111]
• CONVERT基数変換関数^[111]
• ブールシフト演算子^[113]

この標準の完全な実装はまだ知られていない。^{[引用が必要]}

COBOLプログラムは世界中の政府や企業で使用されており、z/OS、z/VSE、VME、Unix、NonStop OS、OpenVMS、Windowsなどのさまざまなオペレーティングシステムで実行されています。1997年にガートナーグループは、世界のビジネスの80％がCOBOLで実行されており、2000億行を超えるコード^[c]があり、毎年50億行以上が書かれていると報告しました。^[114]

20 世紀末近く、2000 年問題(Y2K) は COBOL プログラミングの重要な取り組みの焦点となり、数十年前にシステムを設計したプログラマーによって対処されることもありました。COBOL コードの修正に特に多くの労力が必要になったのは、ビジネス アプリケーションで日付が頻繁に使用されるためビジネス指向の COBOL が多く、データ フィールドが固定長だったためです。^[115]一部の調査では、「Y2K ソフトウェアの修復コストの 24% が COBOL によるもの」とされています。^[116]これらのプログラムに Y2K のクリーンアップ作業が行われた後も、2003 年の調査では、多くのプログラムが引き続き使用されていました。^[117]著者らは、調査データから「他の言語やテクノロジとの統合が採用されない限り、アプリケーション開発における COBOL の重要性は [今後] 10 年間で徐々に低下する」ことが示唆されていると述べています。^[118]

2006年と2012年にComputerworldが実施した調査（352人の読者を対象に実施）によると、60%以上の組織がCOBOLを使用しており（C++やVisual Basic .NETよりも多い）、その半数では社内ソフトウェアの大半にCOBOLが使用されていた。^{[10] [119]管理者の36%がCOBOLからの移行を計画していると答え、25%は}レガシーコードの書き換え費用がかからないのであれば移行すると答えた。一方、一部の企業はCOBOLプログラムをメインフレームからより安価で高速なハードウェアに移行している。^[10]

2016年の下院での証言では、COBOLは依然として多くの連邦機関で使用されていることが示された。^[120] ロイターは2017年に、銀行システムの43％が依然としてCOBOLを使用しており、2200億行を超えるCOBOLコードが使用されていると報じた。^[121]

2019年までに、COBOLプログラマーの数は退職により急速に減少し、大量のトランザクション処理にメインフレームシステムを依然として使用している企業や政府機関では、差し迫ったスキルギャップが生じています。システムを新しい言語で書き直す作業は、コードメンテナンスのアウトソーシングと同様に、費用がかかり問題が多いことが判明しているため、より多くの人々にCOBOLのトレーニングを行う提案が提唱されています。^[122]

COVID-19パンデミックとそれに続く失業者の急増の間、米国のいくつかの州は失業手当管理に使用されているレガシーシステムをサポートする熟練したCOBOLプログラマーが不足していると報告した。これらのシステムの多くはパンデミック以前からより現代的なプログラミング言語への移行過程にあったが、そのプロセスは保留されていた。^[123]同様に、米国国税庁はコロナウイルス救済・救援・経済安全保障法で義務付けられた数千万件の支払いを行うために、COBOLベースの個人マスターファイルに急いでパッチを当てた。^[124]

COBOL には英語に似た構文があり、プログラム内のほぼすべての記述に使用されます。たとえば、条件は または として表現できます  が、より簡潔には または    と  表現できます。より複雑な条件は、繰り返される条件と変数を削除することで省略できます。たとえば、    は と短縮できます。この構文をサポートするために、COBOL には 300 を超えるキーワードがあります。^{[125] [d]}キーワードの一部は、同じ単語の単純な代替または複数形のスペルであり、より文法的に適切なステートメントと節を提供します。たとえば、とキーワードは、と、およびと のように、互換的に使用できます。 x IS GREATER THAN yx GREATER yx > ya > b AND a > c OR a = da > b AND c OR = dINOFTIMETIMESVALUEVALUES

各 COBOL プログラムは、単語、リテラル、ピクチャー文字列 (§ PICTURE 句を参照)、および区切り文字という4 つの基本的な語彙項目12で構成されています。単語には予約語とユーザー定義の識別子が含まれます。最大 31 文字の長さで、文字、数字、ハイフン、およびアンダースコアを含めることができます。リテラルには数字 (例) と文字列 (例'Hello!') が含まれます。^[127]区切り文字には、スペース文字と、スペースが続くカンマとセミコロンが含まれます。^[128]

COBOL プログラムは、識別部、環境部、データ部、および手続き部の 4 つの部分に分かれています。識別部では、ソース要素の名前とタイプを指定し、クラスとインターフェイスを指定します。環境部では、ファイルや文字セットなど、プログラムを実行するシステムに依存するプログラム機能を指定します。データ部は、変数とパラメータを宣言するために使用されます。手続き部には、プログラムのステートメントが含まれます。各部は、段落で構成されるセクションにさらに分割されます。

COBOLの構文は通常、中括弧、角括弧、縦棒、下線を使用した独自のメタ言語で記述されます。^[129]このメタ言語は、オリジナルのCOBOL仕様のために開発されました。

例として、次のADDステートメントの説明を考えてみましょう。

 ${\displaystyle {\begin{array}{l}{\underline {\text{ADD}}}\,{\begin{Bmatrix}{\text{identifier-1}}\\{\text{literal-1}}\end{Bmatrix}}\dots \;{\underline {\text{TO}}}\,\left\{{\text{identifier-2}}\,\left[\,{\underline {\text{ROUNDED}}}\,\right]\right\}\dots \\[1em]\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]\\[1em]\quad \left[\,{\underline {\text{END-ADD}}}\,\right]\end{array}}}$

この説明では、次のバリエーションが許可されます。

xに1を加算xに1 、a 、bを加算切り捨て、y 、zを切り捨て  
         

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


a をbに追加サイズエラーなし「エラーなし」と表示サイズエラーあり「エラー」と表示   
      
        
      
        

COBOLの人気が最高潮に達したのは、キーパンチマシンとパンチカードの時代と一致した。プログラム自体はパンチカードに書き込まれ、読み込まれてコンパイルされ、プログラムに入力されるデータもカード上にあることがあった。^[130]

COBOL は、固定形式 (デフォルト) と自由形式の 2 つの形式で記述できます。固定形式では、コードを特定の領域に収まるように配置する必要があります (パンチ カードの使用から引き継がれています)。COBOL 2002 までは、次の形式がありました。

COBOL 2002では、領域AとBが統合されてプログラムテキスト領域が形成され、実装者が定義した列で終了するようになりました。^[131]

COBOL 2002では、自由形式のコードも導入されました。自由形式のコードは、新しいプログラミング言語と同様に、ファイルの任意の列に配置できます。コメントは を使用して指定されます。*>これはどこにでも配置でき、固定形式のソースコードでも使用できます。継続行は存在せず、>>PAGE指示子がインジケータに置き換わります/。^[131]

識別部は、次のコード エンティティを識別し、クラスまたはインターフェイスの定義を含みます。

クラスとインターフェースは2002 年から COBOL に存在しています。クラスには、クラスメソッドと変数を含むファクトリオブジェクトと、インスタンスメソッドと変数を含むインスタンスオブジェクトがあります。^[132]継承とインターフェースはポリモーフィズムを提供します。汎用プログラミングのサポートは、任意のクラスまたはインターフェースを使用するためにインスタンス化できるパラメータ化されたクラスを通じて提供されます。オブジェクトは参照として保存され、特定の型に制限される場合があります。メソッドを呼び出すにはINVOKE、 と同様に動作する ステートメントCALLと、関数を使用するのと類似したインラインメソッド呼び出しの 2 つの方法があります。^[133]

*> これらは同等です。
INVOKE my-class "foo" RETURNING var MOVE my-class :: "foo" TO var *> インラインメソッド呼び出し    
    

COBOLではメソッドを隠す方法は提供されていない。ただし、クラスデータはPROPERTY句なしで宣言することで隠すことができ、外部コードからはアクセスできなくなる。^[134] メソッドのオーバーロードはCOBOL 2014で追加されました。^[135]

環境部には、構成セクションと入出力セクションが含まれます。構成セクションは、通貨記号、ロケール、文字セットなどの変数機能を指定するために使用されます。入出力セクションには、ファイル関連の情報が含まれます。

COBOL は、シーケンシャル、インデックス、相対の3 つのファイル形式、つまり編成をサポートしています。シーケンシャル ファイルでは、レコードは連続しており、リンク リストと同様に、シーケンシャルにトラバースする必要があります。インデックス ファイルには 1 つ以上のインデックスがあり、レコードにランダムにアクセスしたり、インデックスに基づいてソートしたりできます。各レコードには一意のキーが必要ですが、その他の代替レコード キーは一意である必要はありません。インデックス ファイルの実装はベンダーによって異なりますが、C-ISAM やVSAMなどの一般的な実装はIBM のISAMに基づいています。その他の実装には、OpenVMSのRecord Management ServicesやHPE NonStop (Tandem)のEnscribe があります。相対ファイルは、インデックス ファイルと同様に、一意のレコード キーを持っていますが、代替キーはありません。相対レコードのキーはその順序位置です。たとえば、10 番目のレコードのキーは 10 です。つまり、キーが 5 のレコードを作成するには、(空の) 先行レコードの作成が必要になる場合があります。相対ファイルでは、順次アクセスとランダムアクセスの両方が可能です。^[136]

一般的な非標準拡張は、テキストファイルの処理に使用される行順次編成です。ファイル内のレコードは改行で終了し、長さはさまざまです。^[137]

データ部は、異なる項目を宣言する 6 つのセクションに分かれています。ファイル レコード用のファイル セクション、静的変数用の作業記憶域セクション、自動変数用のローカル記憶域セクション、パラメーターと戻り値用のリンケージ セクション、テキストベースのユーザー インターフェイス用のレポート セクションと画面セクションです。

COBOL のデータ項目は、データ項目が他のデータ項目の一部であるかどうかを示すレベル番号を使用して階層的に宣言されます。レベル番号が高い項目は、レベル番号が低い項目に従属します。レベル番号が 1 の最上位データ項目はレコードと呼ばれます。従属集約データを持つ項目はグループ項目と呼ばれ、従属集約データを持たない項目は基本項目と呼ばれます。標準データ項目を記述するために使用されるレベル番号は 1 から 49 です。^{[138] [139]}

       01   some-record . *> 集合グループレコード項目05   num PIC 9(10) . *> 基本項目05   the-date . *> 集合 (サブ) グループレコード項目10   the-year PIC 9(4) . *> 基本項目10   the-month PIC 99 . *> 基本項目10   the-day PIC 99 . *> 基本項目                   
                         
                             
                     
                      
                        

上記の例では、基本項目numとグループ項目 はthe-dateレコード に従属していますsome-recordが、基本項目the-year、the-month、 はthe-dayグループ項目 の一部ですthe-date。

IN従属項目は(または) キーワードで区別できますOF。たとえば、上記のサンプル コードと次の例を検討してください。

       01  販売日. 
05  年PIC 9(4) . 05  月PIC 99 . 05  日PIC 99 .                  
                 
                   

the-year、、および という名前はthe-month、the-dayそれらの名前で複数のデータ項目が定義されているため、それ自体ではあいまいです。特定のデータ項目、たとえばグループ内に含まれる項目の 1 つを指定するにはsale-date、プログラマーはthe-year IN sale-date(または同等のthe-year OF sale-date) を使用します。この構文は、ほとんどの現代言語でサポートされている「ドット表記」に似ています。

レベル番号66は、以前に定義された項目の構造に関係なく、それらの項目の再グループ化を宣言するために使用されます。このデータレベルは、関連するRENAMES節でも参照されますが、めったに使用されず^[140]、1988年頃には古いプログラムでよく見られました。階層構造と論理構造のデータを無視できるため、その使用は推奨されず、多くのインストールで使用が禁止されていました。^[141]

       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 cust-name THRU cust-dobに名前が変更されます。66   cust-all-details cust-name THRU cust-balanceに名前が変更されます。                       
           
                
                 
                       
                   
           
             
                  

レベル番号 77 は、項目がスタンドアロンであることを示し、このような状況ではレベル番号 01 と同等です。たとえば、次のコードでは、2 つの 77 レベルのデータ項目、およびを宣言しています。property-nameこれらsales-regionは、他のどのデータ項目からも独立した (従属しない) 非グループ データ項目です。

       77  物件名PIC X(80) . 77  販売地域PIC 9(5) .      
              

88レベル番号は、親データ項目にその節で指定された値の1つが含まれている場合に真となる条件名（いわゆる88レベル）を宣言しますVALUE。^[142]たとえば、次のコードは、wage-typeデータ項目の現在の文字データ値に応じて真または偽となる2つの88レベル条件名項目を定義します。データ項目に の値が含まれている場合'H'、条件名は真ですが、またはwage-is-hourlyの値が含まれている場合は、条件名は真です。データ項目に他の値が含まれている場合は、両方の条件名が偽です。 'S''Y'wage-is-yearly

       01  賃金種別PIC X . 88  賃金は時間単位VALUE "H" . 88  賃金は年単位VALUE "S" , "Y" .          
            
             

標準COBOLでは以下のデータ型が提供されています。^[143]

COBOLでは型の安全性は可変です。数値データは異なる表現やサイズの間で暗黙的に変換され、英数字データは数値やグループデータを含む文字列として保存できる任意のデータ項目に配置できます。^[144]対照的に、オブジェクト参照とポインタは同じ型の項目からのみ割り当てることができ、その値は特定の型に制限される場合があります。^[145]

PICTURE(または)節PICは文字列であり、各文字列はデータ項目の一部と、その内容を表します。一部のピクチャ文字は、項目のタイプと、メモリ内で項目が占める文字数または桁数を指定します。たとえば、 は910 進数を示し、 はS項目が符号付きであることを示します。その他のピクチャ文字 (挿入文字および編集文字と呼ばれる) は、項目のフォーマット方法を指定します。たとえば、一連の+文字は、文字の位置と、先頭の符号文字を最終文字データ内に配置する方法を定義します。右端の非数値文字には項目の符号が含まれ、+この位置の左側の に対応するその他の文字位置にはスペースが含まれます。繰り返し文字は、ピクチャ文字の後に括弧で数字を指定することによって、より簡潔に指定できます。たとえば、 は9(7)と同等です。数字 ( ) と符号 ( )9999999文字のみを含むピクチャ指定は、純粋に数値データ項目を定義しますが、英字 ( ) または英数字 ( ) 文字を含むピクチャ指定は、英数字データ項目を定義します。その他の書式設定文字の存在は、編集された数値または編集された英数字データ項目を定義します。^[146]9SAX

句USAGEは、データが格納される形式を宣言します。データ型に応じて、句を補完したり、PICTURE句の代わりに使用したりできます。ポインタやオブジェクト参照を宣言するために使用できますが、主に数値型を指定するために使用されています。これらの数値形式は次のとおりです。^[147]

• バイナリでは、最小サイズはPICTURE句またはUSAGE次のような句によって指定されます。BINARY-LONG
• USAGE COMPUTATIONAL、データは実装が提供する任意の形式で保存される。多くの場合、  USAGE BINARY
• USAGE DISPLAYデフォルトの形式では、データは文字列として保存されます
• 浮動小数点数（実装依存形式またはIEEE 754準拠）
• USAGE NATIONAL拡張文字セットを使用してデータが文字列として保存される
• USAGE PACKED-DECIMALデータは可能な限り小さい10進数形式（通常はパックされた2進化10進数）で保存されます。

レポートライターは、レポートを作成するための宣言的な機能です。プログラマーはレポートのレイアウトとレポートを作成するために必要なデータを指定するだけでよく、改ページ、データの書式設定、見出しや脚注などを処理するコードを記述する必要がありません。^[148]

レポートはレポート ファイルに関連付けられており、レポート ライター ステートメントを通じてのみ書き込むことができるファイルです。

       FDレポート出力REPORT販売レポート。   

各レポートは、データ部のレポート セクションで定義されます。レポートは、レポートの見出し、フッター、および詳細を定義するレポート グループに分割されます。レポートは、階層的なコントロール ブレークを回避して動作します。コントロール ブレークは、キー変数の値が変わると発生します。たとえば、顧客の注文の詳細を示すレポートを作成する場合、プログラムが別の顧客の注文に到達したときにコントロール ブレークが発生する可能性があります。以下は、営業担当者の売上を示し、無効なレコードがあれば警告するレポートのレポート記述の例です。

       RD販売レポートページ制限60行最初の詳細3コントロール販売者名。 
             
             
            

       01  タイプページヘッダー. 03  列1                    値"販売レポート" . 03  列74                   値"ページ" . 03  列79                    PIC Z9ソースページ カウンター.  
            
            
              

       01  売上日タイプ詳細、行+ 1 。03  列3                    値"売上日" 。03  列12                   写真 99/99/9999ソース売上日。03  列21                   値"だった" 。03  列26                   写真 $$$$9.99ソース売上額。    
            
              
            
              

       01  無効な販売タイプ詳細、行+ 1 。03  列3                    値"無効なレコード:" 。03  列19                    PIC X(34)ソース販売レコード。    
            
              

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

上記のレポートの説明では、次のレイアウトについて説明しています。

売上レポート ページ 1

販売者: ハワード・ブロムバーグ
  2008年10月12日の売上は1000ドルでした
  2008年12月12日の売上は$0.00でした
  2008年12月13日の売上は31.47ドルでした
  無効なレコード: Howard Bromberg XXXXYY

販売者: ハワードディスカウント
...
売上レポート 12 ページ

  2014年8月5日の売上は543.98ドルでした
  無効なレコード: William Selden 12O52014FOOFOO
  2014年5月30日の売上は$0.00でした

4 つのステートメントがレポート ライターを制御します。INITIATEはレポート ライターの印刷準備をします。GENERATEはレポート グループを印刷します。SUPPRESSはレポート グループの印刷を抑制します。TERMINATEはレポート処理を終了します。 上記の売上レポートの例では、手続き部は次のようになります。

           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 .    
            
 
              
                
                    
                        
               
 
                
                
                    
               
                    
               
           
 
            
             
           

レポートライター機能の使用状況は大きく異なる傾向があり、広範囲に使用している組織もあれば、まったく使用していない組織もあります。^[149]さらに、レポートライターの実装の品質にはばらつきがあり、品質の低い実装では実行時に過剰な量のメモリを使用することがありました。^[149]

手続き部内のセクションと段落（まとめて手続きと呼ばれる）は、ラベルや単純なサブルーチンとして使用できます。他の部とは異なり、段落はセクション内にある必要はありません。^[150]

プログラムは終了するまで、その手順に沿って実行されます。^[151] 手順をサブルーチンとして使用するには、PERFORM動詞を使用します。

ステートメントは、呼び出されたコードの最後でステートメントPERFORMに続くコードに実行が戻るという意味で、新しい言語のプロシージャ呼び出しに多少似ていますが、パラメータを渡したり結果値を返したりするメカニズムは提供されません。 のような単純なステートメントを使用してサブルーチンが呼び出されると、制御は呼び出されたプロシージャの最後に戻ります。ただし、 は、複数の隣接するプロシージャのシーケンスにまたがる範囲を呼び出すために使用されるという点で異なります。これは、次の構文を使用して行われます。 PERFORMPERFORM subroutinePERFORMPERFORM sub-1 THRU sub-n

手順. ALPHAを実行. ALPHAからGAMMAまで実行停止実行. ALPHA . 'A'を表示. BETA . 'B'を表示. GAMMA . 'C'を表示. 
     
       
     

    

    

    

このプログラムの出力は「AAB C」になります。

PERFORMまた、従来のプロシージャ呼び出しとは異なり、少なくとも従来は、呼び出しスタックの概念はありません。その結果、ネストされた呼び出しが可能になります (ネストされた一連のコード自体がステートメントPERFORMを実行する場合がありますPERFORM) が、両方の呼び出しで同じコードの一部が実行される場合は特別な注意が必要です。問題は、内側の呼び出しのコードが外側の呼び出しの終了ポイントに到達したときに発生します。より正式には、PERFORM以前に呼び出されたがまだ完了していない呼び出しの終了ポイントに制御が渡された場合、COBOL 2002 標準では動作が未定義であると規定されています。

その理由は、COBOL は「戻りアドレス」ではなく、継続アドレスと呼ばれるものを使用して動作するからです。制御フローがいずれかのプロシージャの最後に到達すると、継続アドレスが検索され、制御がそのアドレスに転送されます。プログラムが実行される前に、すべてのプロシージャの継続アドレスは、プログラム テキスト内で次に来るプロシージャの開始アドレスに初期化されます。そのため、PERFORMステートメントが発生しない場合は、制御はプログラムの上から下へ流れます。ただし、PERFORMステートメントが実行されると、呼び出されたプロシージャ (または、呼び出された範囲の最後のプロシージャ (使用された場合)) の継続アドレスが変更されPERFORM THRU、最後に制御が呼び出しサイトに戻ります。元の値は保存され、後で復元されますが、ストレージ位置は 1 つだけです。2 つのネストされた呼び出しが重複するコードで動作する場合、継続アドレスの管理がさまざまな方法で互いに干渉する可能性があります。^{[152] [153]}

次の例 (Veerman & Verhoeven 2006 より引用) は、この問題を示しています。

LABEL1 .
表示'1' LABEL2からLABEL3を実行停止実行. LABEL2 .表示'2' LABEL3からLABEL4を実行. LABEL3 .表示'3' . LABEL4 .表示'4' .    
       
     

    
       

    

    

このプログラムの出力は「1 2 3 4 3」になると思われるかもしれません。「2」を表示した後、2 番目のPERFORM呼び出しによって「3」と「4」が表示され、最初の呼び出しが「3」で続行されます。従来の COBOL 実装では、これは当てはまりません。むしろ、最初のPERFORM文は の末尾に継続アドレスを設定しLABEL3、 内の呼び出しサイトに戻るようにしますLABEL1。2 番目のPERFORM文は の末尾に return を設定しますLABEL4が、 の継続アドレスは変更せずLABEL3、デフォルトの継続であると想定します。したがって、内部呼び出しが の末尾に到達するとLABEL3、外部の文にジャンプしPERFORM、プログラムは「1 2 3」のみを出力して停止します。一方、オープンソースの TinyCOBOL コンパイラなどの一部の COBOL 実装では、2 つの文PERFORMは互いに干渉せず、出力は確かに「1 2 3 4 3」になります。したがって、このような場合の動作は (おそらく) 驚くべきものであるだけでなく、移植性もありません。^[153]

この制限の特別な結果は、PERFORM再帰的なコードを記述するために使用できないことです。これを説明するための別の簡単な例（Veerman & Verhoeven 2006 から少し簡略化されています）:

    1 をPERFORMラベル Aに移動する、STOP RUN . LABEL . DISPLAY A、IF A < 3、ADD 1 TO A PERFORMラベルEND-IF、DISPLAY 'END' .  
     
     

     
       
          
         
    
    

出力は「1 2 3 END END END」であると予想されるかもしれませんし、実際に一部の COBOL コンパイラはそれを生成します。しかし、IBM COBOL などの他のコンパイラは、「1 2 3 END END END END ...」などと出力し、無限ループで「END」を何度も出力するコードを生成します。バックアップ継続アドレスを格納するスペースが限られているため、バックアップは再帰呼び出しの過程で上書きされ、復元できるのは へのジャンプだけですDISPLAY 'END'。^[153]

COBOL 2014には47の文（動詞とも呼ばれる）があり、^[154]これらは制御フロー、I/O、データ操作、レポートライターの4つの大まかなカテゴリに分類できます。レポートライターの文については、レポートライターのセクションで説明します。

COBOL の条件文はIFと ですEVALUATE。は、複数の値と条件を評価する機能が追加されたswitch のような文EVALUATEです。 これを使用して、決定表を実装できます。 たとえば、次の文を使用してCNC 旋盤を制御できます。

評価TRUEかつ希望速度かつ現在の速度かつ蓋が閉じている場合かつ最小速度から最大速度かつ 希望速度未満実行マシンのスピードアップかつ蓋が閉じている場合かつ最小速度から最大速度かつ希望速度以上実行マシンのスローダウンかつ蓋が開いている場合 かつ任意かつゼロ以外実行緊急停止かつその他の場合続行 終了評価     
             
         
             
         
          
         
     
        

文は、条件が真になるまで（他の言語でより一般的な、真である間ではPERFORMなく）実行されるループを定義するために使用されます。また、プロシージャまたはプロシージャの範囲を呼び出すためにも使用されます（詳細については、プロシージャのセクションを参照してください）。 およびは、それぞれサブプログラムとメソッドを呼び出します。サブプログラム/メソッドの名前は、リテラルまたはデータ項目である可能性のある文字列に含まれます。^{[155]パラメータは、}参照、コンテンツ（コピーが参照によって渡される場合）または値（プロトタイプが使用可能な場合のみ）によって渡すことができます。 ^{[156] は、}サブプログラムをメモリからアンロードします。は、プログラムを指定されたプロシージャにジャンプさせます。 CALLINVOKE CANCELGO TO

文はreturn文GOBACKであり、文はプログラムを停止します。文には6つの異なる形式があります。return文、 break文、continue文、終了マーカーとして使用したり、手順を終了するために使用できます。^[157]STOPEXIT

例外は文によって発生し、手続き部の 部分に定義されたRAISEハンドラまたは宣言によってキャッチされます。宣言とは、処理するエラーを指定する文で始まるセクションです。例外は名前またはオブジェクトです。は、宣言内で使用され、例外を発生させた文の後の文、または の外部の手続きにジャンプします。他の言語とは異なり、キャッチされない例外によってプログラムが終了しないことがあり、プログラムは影響を受けずに続行できます。 DECLARATIVESUSERESUMEDECLARATIVES

ファイル I/O は、自己記述型のOPEN、CLOSE、READ、WRITEステートメントに加えて、REWRITEレコードを更新する 、START特定のキーを持つレコードを検索してアクセスする後続のレコードを選択する 、および最後にアクセスしたレコードのロックをUNLOCK解除するの 3 つのステートメントによって処理されます。

ACCEPTユーザーインタラクションはおよびを使用して行われますDISPLAY。

次の動詞はデータを操作します。

• INITIALIZEは、データ項目をデフォルト値に設定します。
• MOVEはデータ項目に値を割り当てます。MOVE CORRESPONDING は対応する同名のフィールドを割り当てます。
• SETには15のフォーマットがあり、インデックスの変更、オブジェクト参照の割り当て、テーブル容量の変更などの機能があります。^[158]
• ADD、、、、およびは算術演算（数式の結果を変数に割り当てる）をSUBTRACT処理します。MULTIPLYDIVIDECOMPUTECOMPUTE
• ALLOCATEおよびは動的メモリFREEを処理します。
• VALIDATEデータ部門のアイテムの説明に指定されたとおりにデータを検証し、配布します。
• STRINGおよび はUNSTRING、それぞれ文字列を連結および分割します。
• INSPECT文字列内の指定された部分文字列のインスタンスを集計または置換します。
• SEARCH条件を満たす最初のエントリをテーブルで検索します。

ファイルとテーブルは を使用してソートされSORT、MERGE動詞はファイルをマージしてソートします。RELEASE動詞はソートするレコードを提供し、RETURNソートされたレコードを順番に取得します。

IFや などの一部のステートメントREADには、それ自体に ステートメントが含まれる場合があります。このようなステートメントは、ピリオド (暗黙的な終了) によって終了され、含まれているすべての終了していないステートメントが終了されます。または、スコープ ターミネータによって終了され、最も近い一致するオープン ステートメントが終了します。

*> 終了ピリオド ("暗黙の終了") 
IF invalid-record IF no-more-records NEXT SENTENCE ELSE READ record-file AT END SET no-more-records TO TRUE . 
     
         
    
         
                 

*> スコープ終了子 (「明示的な終了」) 
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 
     
        
    
         
                 
        
    

ピリオドで終了するネストされた文は、バグの一般的な原因です。^{[159] [160]}たとえば、次のコードを調べてください。

x の場合はyを表示します。zを表示します。 
     
     

ここでの意図は、条件が真の場合にyと を表示することです。ただし、の後の誤ったピリオドによって文が終了しているため、の値が何であっても が表示されます。 zxzxIFDISPLAY y

もう 1 つのバグは、2 つのステートメントが に関連付けられる場合の、ぶら下がり else 問題の結果です。 IFELSE

x の場合y の場合a を表示し、それ以外の場合はb を表示します。 
     
         

     

上記のコード例では、 は文  ではなく 文  ELSEに関連付けられている  ため  、バグが発生しています。明示的なスコープターミネータが導入される前は、これを防ぐには、    内側の の後に を配置する必要がありました。^[160]IF yIF xELSE NEXT SENTENCEIF

オリジナルの（1959年）COBOL仕様では  、多くのコンパイラが自己変更コードを  生成した悪名高い文をサポートしていました。および はプロシージャラベルであり、  そのような文の後に実行される  プロシージャ内の単一の文は、代わりにを意味します    。多くのコンパイラはまだそれをサポートしていますが、^[161] COBOL 1985標準では廃止とみなされ、2002年に削除されました。 ^[162]ALTER X TO PROCEED TO YXYGO TOXALTERGO TO Y

このALTER文は「文脈の局所性」を損ない、プログラム全体のロジックを理解しにくくするため、あまり評価されていませんでした。^[163]教科書の著者であるダニエル・D・マクラッケンは1976年に、「プログラムを見たこともない人が、プログラムが失敗したために時間的に厳しいプレッシャーを感じながら、できるだけ早くプログラムに慣れなければならないとき、段落の中にGO TO文が1つだけあるのを見ると、プログラム全体の未知の場所に未知の数のALTER文が存在することを示し、どんなに勇敢なプログラマでも恐怖を感じます。」と書いています。^[163]

COBOL の「Hello, World!」プログラム:

       識別部.プログラム ID . hello-world .手続き部. 「Hello, world!」と表示. 
        
        
           
           

1978年に『プログラミング言語C』の今では有名な「Hello, World!」プログラム例が初めて出版されたとき、同様のメインフレームCOBOLプログラムサンプルがJCLを通じて提出されたと思われます。おそらくパンチカードリーダーと80列のパンチカードが使われていたのでしょう。以下のリストは、DATA DIVISIONが空で、LinuxとMVS 3.8Jを実行するSystem/370 Herculesエミュレーターを使用してテストされました。2015年7月に書かれたJCLは、Jay MoseleyがホストするHerculesチュートリアルとサンプルから派生したものです。^[164]当時のCOBOLプログラミングに合わせて、HELLO, WORLDはすべて大文字で表示されています。

// COBUCLG JOB ( 001 )、'COBOL BASE TEST' 、00010000 // CLASS = A 、MSGCLASS = A 、MSGLEVEL = ( 1 、1 ) 00020000 // BASETEST EXEC COBUCLG 00030000 // COB . SYSIN DD * 00040000 00000 * BASE COBOL INSTALLの検証00050000 01000 IDENTIFICATION DIVISION . 00060000 01100 PROGRAM-ID . 'HELLO' . 00070000 02000 ENVIRONMENT DIVISION . 00080000 02100 CONFIGURATION SECTION . 00090000 02110ソースコンピュータ。GNULINUX。00100000 02120オブジェクト コンピュータ。HERCULES。00110000 02200特殊名。00120000 02210コンソールはCONSLです。00130000 03000データ部。00140000 04000手続き部。00150000 04100 00 -メイン。00160000 04110      CONSL時に' HELLO , WORLD 'を表示し     ます     。00170000 04900停止、実行。00180000 // LKED . SYSLIB DD DSNAME = SYS1 . COBLIB 、DISP = SHR 00190000 // DD DSNAME = SYS1 . LINKLIB 、DISP = SHR 00200000 // GO . SYSPRINT DD SYSOUT = A 00210000 // 00220000                                    
                                     
                                                   
                                                          
                                     
                                          
                                              
                                             
                                            
                                        
                                        
                                                   
                                              
                                                    
                                               
                                                         
                             
                                                     
                              
                                        
                                                 
                                                                      

JCL を送信すると、MVS コンソールに次のように表示されました。

    19.52.48 ジョブ 3 $HASP100 COBUCLG ON READER1 COBOL ベース テスト
    19.52.48 ジョブ 3 IEF677I ジョブ COBUCLG の警告メッセージが発行されました
    19.52.48 ジョブ 3 $HASP373 COBUCLG 開始 - INIT 1 - クラス A - SYS BSP1
    19.52.48 ジョブ 3 IEC130I SYSPUNCH DD ステートメントがありません
    19.52.48 ジョブ 3 IEC130I SYSLIB DD ステートメントがありません
    19.52.48 ジョブ 3 IEC130I SYSPUNCH DD ステートメントがありません
    19.52.48 ジョブ 3 IEFACTRT - ステップ名 プロセスステップ プログラム戻りコード
    19.52.48 ジョブ 3 COBUCLG ベーステスト COB IKFCBL00 RC= 0000
    19.52.48 ジョブ 3 COBUCLG ベーステスト LKED IEWL RC= 0000
    19.52.48 ジョブ 3 +HELLO, WORLD
     19.52.48 ジョブ 3 COBUCLG BASETEST GO PGM=*.DD RC= 0000
    19.52.48 ジョブ 3 $HASP395 COBUCLG 終了

上記のコンソール リストの 10 行目は効果を上げるために強調表示されていますが、強調表示は実際のコンソール出力の一部ではありません。

関連するコンパイラ リストでは、14 行の COBOL からの 1 行の出力に対して、4 ページを超える技術詳細とジョブ実行情報が生成されました。

1970年代には、構造化プログラミングパラダイムの採用がますます広まっていった。著名なコンピュータ科学者であるエドガー・ダイクストラは、 1975年に出版されたCommunications of the ACMの編集者に「人を傷つけるかもしれない真実をどうやって伝えるのか？」と題する手紙を書いた。その中で彼はCOBOLや他のいくつかの現代の言語を批判し、「COBOLの使用は精神を麻痺させる」と述べた。^[165]

コンピュータ科学者のハワード・E・トンプキンスは、ダイクストラの発言に対する反対意見を発表し、非構造化COBOLは「構造化COBOLを十分に学んだことのないプログラマーによって書かれる」傾向があり、問題は主にトレーニングの問題であると主張した。^[166]

スパゲッティコードの原因の1つは文でしたGO TO。GO TOしかし、COBOLコードから文を削除しようとすると、プログラムが複雑になり、コードの品質が低下しました。^[167] GO TO文は主に文と手続きに置き換えられPERFORM、モジュールプログラミングが促進され^[167]、強力なループ機能に簡単にアクセスできるようになりました。ただし、文PERFORMは手続きでしか使用できなかったため、ループ本体は使用される場所に配置されず、プログラムが理解しにくくなりました。^[168]

COBOLプログラムはモノリシックでモジュール化されていないことで悪名高かった。^[169] COBOLコードはプロシージャを通じてのみモジュール化できたが、これは大規模システムには不十分であることが判明した。データへのアクセスを制限することは不可能であり、プロシージャはあらゆるデータ項目にアクセスして変更することができた。さらに、プロシージャにパラメータを渡す方法がなかったが、ジャン・サメットはこれを委員会の最大の失敗とみなした。^[170]

もう一つの複雑さは、特定の手順のシーケンスを実行する能力から生じましたPERFORM THRU。これは、制御が任意の手順にジャンプしたり、任意の手順から戻ったりできることを意味し、複雑な制御フローを作成し、プログラマーが単一エントリ単一終了ルールを破ることを可能にしました。^[171]

COBOLがより多くの機能を採用するにつれて、この状況は改善されました。COBOL-74ではサブプログラムが追加され、プログラマーはプログラムの各部分がアクセスできるデータを制御できるようになりました。その後、COBOL-85ではネストされたサブプログラムが追加され、プログラマーはサブプログラムを非表示にできるようになりました。^[172] 2002年には、オブジェクト指向プログラミング、ユーザー定義関数、ユーザー定義データ型が組み込まれ、データとコードに対するさらなる制御が可能になりました。

しかしながら、重要なレガシーCOBOLソフトウェアの多くは非構造化コードを使用しており、実質的に保守不可能になっています。未知の場所から未知の方法で使用される可能性があるため、コードの単純な部分を変更することさえリスクが高く、コストもかかります。^[173]

COBOLは、移植性の高い「共通」言語となることを目指していました。しかし、2001年までに約300の方言が作成されました。^[174]方言の1つのソースは標準そのものでした。1974年の標準は、1つの必須の核と、それぞれ2つまたは3つのレベルのサポートを含む11の機能モジュールで構成されていました。これにより、104,976の可能なバリアントが許可されました。^[175]

COBOL-85は以前のバージョンと完全に互換性がなく、その開発は議論を呼んだ。トラベラーズ保険のCIOであるジョセフ・T・ブロフィは、新しい標準を実装するための多大な再プログラミングコストをCOBOLユーザーに知らせる取り組みの先頭に立った。^[176]その結果、ANSI COBOL委員会は一般の人々から2,200通を超える手紙を受け取り、そのほとんどは否定的で、委員会に変更を加えるよう要求した。一方、COBOL-85への移行は将来の生産性を向上させると考えられ、したがって移行コストは正当化された。^[177]

COBOLの構文は冗長性が高いと批判されることが多い。支持者によると、これはコードを自己文書化してプログラムのメンテナンスを容易にすることが目的だったという。^[179] COBOLはまた、プログラマーが簡単に学習して使用できるように設計されており、^[180]管理者などの非技術者にも読みやすいものであった。^{[181] [182] [183]​​ [184]}

読みやすさへの欲求は、名詞、動詞、節、文、節、および区分などの英語のような構文と構造要素の使用につながりました。しかし、1984年までに、COBOLプログラムの保守者は「理解できない」コードに対処するのに苦労しており^[183] ​​、COBOL-85の主な変更は保守を容易にするためのものでした。^[93]

短期委員会メンバーの Jean Sammet は、「プロのプログラマーのニーズに応えるための試みはほとんど行われておらず、実際、プログラミングに主な関心を持つ人々は COBOL に非常に不満を抱いている傾向がある」と指摘し、その原因を COBOL の冗長な構文にあるとしている。^[185]

その後、COBOL はそれを扱う資料の不足に悩まされ、入門書が登場したのは 1963 年になってからでした (リチャード・D・アーウィンが 1966 年に COBOL の大学教科書を出版しました)。^[187] CODASYL COBOL 委員会の委員長であるドナルド・ネルソンは 1984 年に「学者は COBOL を嫌っている」と述べ、コンピュータ サイエンスの卒業生は「『COBOL を嫌う』という教えを叩き込まれている」と述べました。^[188]

1980年代半ばまでに、ビジネス界ではFORTRANやアセンブラなどの他の言語のユーザーからCOBOLに対してかなりの軽蔑の念が生まれ、COBOLはそれほど難しくない問題にしか使用できないと思われていました。^[189]

2003年、COBOLは米国の情報システムカリキュラムの80%に採用されており、これはC++やJavaと同率である。^{[190] 10年後、}マイクロフォーカス社による世論調査では、大学の教員の20%がCOBOLは時代遅れか死んだと考えており、55%が学生もCOBOLは時代遅れか死んだと考えていることがわかった。また、同じ世論調査では、教員の60%がCOBOLプログラミングを教えるべきと考えているにもかかわらず、カリキュラムにCOBOLプログラミングを含めている教員はわずか25%であることもわかった。^[191]

標準委員会の能力については疑問が提起されている。短期委員のハワード・ブロムバーグは、開発プロセスに対する「管理がほとんどなく」、それは「人員の不連続性と才能の不足に悩まされていた」と述べた。^[81]ジーン・サメットとジェローム・ガーファンクルも、標準委員会のメンバーの変更と客観的証拠のせいで、標準の1つの改訂版で導入された変更が次の改訂版で元に戻されることを指摘した。^[192]

COBOL標準は繰り返し遅延に見舞われてきた。COBOL-85は期待より5年遅れて登場し、^[193] COBOL 2002は5年遅れ、^[3] COBOL 2014は6年遅れた。^{[101] [194]}遅延に対処するため、標準委員会は、次の標準改訂を待つよりも早く機能を追加できるオプションの補遺の作成を許可した。しかし、一部の委員会メンバーは、実装間の非互換性や標準の頻繁な変更について懸念を表明した。^[195]

COBOLのデータ構造はその後のプログラミング言語に影響を与えた。そのレコードとファイル構造はPL/IとPascalに影響を与え、句はPascalのバリアントレコードの前身となった。明示的なファイル構造の定義はデータベース管理システムREDEFINESの開発に先行し、集約データはFortranの配列よりも大きな進歩であった。^[196]

PICTUREデータ宣言は、わずかな変更を加えて PL/I に組み込まれました。

COBOLのCOPY機能は「原始的」であると考えられていたものの、^[197] includeディレクティブの開発に影響を与えました。^[196]

移植性と標準化に重点を置いたことで、COBOLで書かれたプログラムは移植可能となり、さまざまなハードウェアプラットフォームやオペレーティングシステムへの言語の普及が促進されました。^[198]さらに、明確に定義された部門構造により、環境部門への外部参照の定義が制限され、特にプラットフォームの変更が簡素化されます。^[199]

• プログラミング言語のアルファベット順リスト
• BLIS/COBOL
• コダシル
• プログラミング言語の比較
• プログラミング言語の世代別リスト § COBOLベース
• コンパイラの一覧 § COBOL コンパイラ