Loading article…
COBOL（ Common Business - Oriented Language、/ ˈkoʊbɒl、-bɔːl /）[ 11 ]は、ビジネス用途向けに設計された、コンパイル型の英語に似たコンピュータプログラミング言語です。命令型、手続き型、そして2002年以降はオブジェクト指向言語です。COBOLは主に企業や政府のビジネス、金融、管理システムで使用されています。COBOLは、大規模なバッチ処理やトランザクション処理ジョブなど、メインフレームコンピュータに展開されるアプリケーションで今でも広く使用されています。多くの大手金融機関は2006年までこの言語で新しいシステムを開発していましたが[ 12 ]、今日ではCOBOLでのプログラミングのほとんどは、既存のアプリケーションの保守のみを目的としています。プログラムは新しいプラットフォームに移行されたり、最新の言語で書き直されたり、他のソフトウェアに置き換えられたりしています[ 13 ] 。
COBOL の設計は 1959 年にCODASYLによって開始され、グレース・ホッパーが設計したプログラミング言語FLOW-MATICを部分的にベースとしていました。これは、米国国防総省がデータ処理用の移植可能なプログラミング言語を作成する取り組みの一環として作成されました。当初は一時的なものと見なされていましたが、国防総省がコンピュータメーカーに提供するよう迅速に圧力をかけた結果、広く採用されるようになりました。[ 14 ] 1968 年に標準化され、5 回改訂されています。拡張には、構造化プログラミングとオブジェクト指向プログラミングのサポートが含まれます。現在の標準はISO / IEC 1989:2023 です。[ 15 ]
COBOLのステートメントは、自己説明的で読みやすいように設計された、散文的な構文を持っています。しかし、他の言語の簡潔で数学的な構文と比べると、冗長で300以上の予約語を使用しています。MOVExTOy
COBOLコードは、識別、環境、データ、プロシージャの4つの部門に分かれており、セクション、段落、文の厳格な階層構造で構成されています。大規模な標準ライブラリがないため、標準規格では43のステートメント、87の関数、そしてわずか1つのクラスのみが規定されています。
COBOLは、冗長性、設計プロセス、構造化プログラミングへのサポートの不十分さなどが批判されてきた。これらの弱点により、個々のコードの可読性は高いものの、全体として理解しにくい巨大なプログラムが生成されることが多い。
COBOLは長年にわたり、メインフレームでの業務運営のためのプログラミング言語として認識されてきましたが、[ 16 ]近年では多くのCOBOL業務がクラウドコンピューティングに移行しています。[ 17 ]
1950年代後半、コンピュータのユーザーとメーカーはプログラミングのコスト上昇を懸念し始めていた。1959年の調査では、データ処理設備のプログラミング費用は平均80万ドル、新しいハードウェアで実行できるようにプログラムを変換する費用は60万ドルであることが判明した。新しいプログラミング言語が次々と登場していた当時、同じ調査では、共通のビジネス指向言語を使用すれば、変換ははるかに安価かつ迅速になると示唆されていた。[ 18 ]
1959年4月8日、バローズ社のコンピュータ科学者メアリー・K・ホーズは、共通のビジネス言語に関する正式な会議を組織するために、ペンシルベニア大学で学界、コンピュータユーザー、製造業者の代表者を集めた会議を招集した。 [ 19 ]代表者には、グレース・ホッパー（英語に似たデータ処理言語FLOW-MATICの発明者）、ジーン・サメット、ソール・ゴーンなどが含まれていた。[ 20 ] [ 21 ]
4月の会議で、グループは国防総省（DoD）に共通のビジネス言語を作成する取り組みを支援するよう要請した。代表団は国防総省のデータシステム研究スタッフのディレクターであるチャールズ A. フィリップス氏に感銘を与え、フィリップス氏は彼らが国防総省の問題を「十分に理解している」と考えた。国防総省は225台のコンピュータを運用しており、さらに175台を発注済みで、それら上で動作するプログラムの実装に2億ドル以上を費やしていた。移植可能なプログラムは、時間を節約し、コストを削減し、近代化を容易にするだろう。[ 23 ]
チャールズ・フィリップスは会議のスポンサーになることに同意し、代表団に議題の作成を依頼した。[ 24 ]
1959年5月28日と29日、ペンタゴンでビジネス向け共通プログラミング言語の作成について話し合う会議が開催された（チューリッヒALGOL 58会議からちょうど1年後）。41人が出席し、フィリップスが議長を務めた。[ 25 ]国防総省は、異なるコンピュータで同じデータ処理プログラムを実行できるかどうかを懸念していた。当時唯一の主流言語であったFORTRANには、そのようなプログラムを作成するために必要な機能が欠けていた。 [ 26 ]
代表者たちは、銀行や保険から公益事業や在庫管理まで、幅広い環境で機能する言語について熱心に説明した。彼らは、より多くの人がプログラミングできるようになるべきであり、新しい言語は現代の技術の制約を受けるべきではないという点で全員一致した。大多数は、その言語は英語を最大限に活用し、変更可能で、機械に依存せず、たとえ処理能力を犠牲にしても使いやすいものであるべきだという点で同意した。[ 27 ]
この会議の結果、運営委員会と短期、中期、長期の各委員会が設立された。短期委員会には、暫定的な言語の仕様を作成するために9月（3か月）までが与えられ、その後、他の委員会によって改良されることになった。[ 28 ] [ 29 ]しかし、彼らの公式な任務は、既存のプログラミング言語の長所と短所を特定することであり、新しい言語を作成することを明示的に指示するものではなかった。[ 26 ]
短期委員会は、その期限を信じられない思いで受け止めた。[ 30 ]委員の一人であるベティ・ホルバートンは、3か月の期限を「とんでもない楽観主義」と評し、その言語が本当に一時しのぎになるとは思えないと疑問を呈した。[ 31 ]運営委員会は6月4日に会合を開き、活動全体をデータシステム言語委員会（CODASYL ）と命名し、執行委員会を設立することに合意した。[ 32 ]
短期委員会のメンバーは、6 社のコンピュータメーカーと 3 の政府機関を代表していた。コンピュータメーカーは、 Burroughs Corporation、IBM、Minneapolis-Honeywell (Honeywell Labs)、RCA、Sperry Rand、およびSylvania Electric Productsであった。政府機関は、米国空軍、海軍のDavid Taylor Model Basin、および国立標準局(現在の国立標準技術研究所) であった。[ 33 ]委員会の議長は、米国国立標準局のJoseph Wegsteinが務めた。作業は、データ記述、ステートメント、既存のアプリケーション、およびユーザー エクスペリエンスの調査から始まった。[ 34 ]
委員会は主にFLOW-MATIC、AIMACO、COMTRANプログラミング言語を調査した。[ 26 ] [ 35 ] FLOW-MATIC 言語は、実装されていたことと、AIMACO がわずかな変更を加えた派生言語であったことから、特に影響力があった。[ 36 ] [ 37 ] FLOW-MATIC の発明者である Grace Hopper も委員会の技術顧問を務めた。[ 30 ] COBOL に対する FLOW-MATIC の主な貢献は、長い変数名、コマンドの英語名、データ記述と命令の分離であった。[ 38 ] Hopper は「COBOL の母」または「COBOL の祖母」と呼ばれることもあるが、[ 39 ] [ 40 ] [ 41 ] COBOL の主任設計者であるJean Sammet は、Hopper は「COBOL の母でも、作成者でも、開発者でもない」と述べている。[ 42 ] [ 1 ]
IBMのCOMTRAN言語は、Bob Bemerによって発明され、 Grace Hopperの同僚で構成された短期委員会によってFLOW-MATIC [ 43 ] [ 44 ]の競合とみなされた。 [ 45 ] IBMが設計プロセスを支配したように見えないように、その機能の一部はCOBOLに組み込まれなかった[ 28 ] 。また、Jean Sammetは1981年に、一部の委員会メンバー（彼女自身も含む）から「強い反IBMバイアス」があったと述べている。[ 46 ]あるケースでは、COMTRANマニュアルの著者であり、中期委員会のメンバーであるRoy Goldfingerが、自身の言語を支持し、代数式の使用を奨励するために小委員会の会議に出席した後、Grace Hopperは短期委員会にメモを送り、Sperry Randが英語をベースとした言語を作成しようと努力していることを改めて強調した。[ 47 ]
1980年、グレース・ホッパーは「COBOL 60は95%がFLOW-MATICで、COMTRANの影響は極めて小さい」とコメントした。さらに彼女は、FLOW-MATICとCOMTRANの両方から影響を受けたと主張するのは「他の人々を満足させ、我々を潰そうとしないようにするため」だけだと述べた。[ 48 ]
COBOLに組み込まれたCOMTRANの機能には、数式[49]、句[ 50 ]、GO TOを不要にする改良されたステートメント、より堅牢なファイル管理システム[ 43 ]などがあった。PICTUREIF
委員会の活動の有用性については、大きな議論があった。一部の委員は、この言語には妥協が多すぎ、委員会による設計の結果だと考えたが、他の委員は、検討された3つの言語よりも優れていると感じた。言語が複雑すぎると感じる委員もいれば、単純すぎると感じる委員もいた。[ 51 ]
議論を呼んだ機能には、データ処理ユーザーにとって役に立たない、あるいは高度すぎると一部の人が考えたものがあった。そのような機能には、ブール式、数式、およびテーブルの添え字（インデックス）などがあった。[ 52 ] [ 53 ]もう一つの議論の的となったのは、キーワードをコンテキスト依存にするかどうか、そしてそれが可読性にどのような影響を与えるかということだった。[ 52 ]コンテキスト依存キーワードは却下されたものの、このアプローチは後にPL/Iで、そして2002年からはCOBOLで部分的に使用された。 [ 54 ]対話性、オペレーティングシステムとの相互作用（当時存在していたものは少なかった）、および関数（純粋に数学的なもので、データ処理には役に立たないと考えられていた）についてはほとんど考慮されなかった。[ 55 ] [ 56 ]
仕様書は9月4日に執行委員会に提出された。しかし、期待には及ばなかった。ジョセフ・ウェグスタインは「粗削りな部分があり、いくつか追加する必要がある」と指摘し、ボブ・ベマーは後に「寄せ集め」だと評した。委員会には12月までに改善するよう指示が出された。[ 30 ]
9月中旬の会議で、委員会は新しい言語の名前について議論した。提案には「BUSY」（Business System）、「INFOSYL」（Information System Language）、「COCOSYL」（Common Computer Systems Language）などがあった。[ 57 ]「COBOL」という名前を誰が考案したかは不明だが、[ 58 ] [ 59 ]ボブ・ベマーは後に自分の提案だったと主張した。[ 60 ] [ 61 ] [ 62 ]
10月、中間範囲委員会はロイ・ナットが作成したFACT言語仕様のコピーを受け取った。その機能に委員会は非常に感銘を受け、COBOLをそれに基づいて構築するという決議を可決した。[ 63 ]
これは、仕様策定で順調に進んでいた短期委員会にとって痛手となった。技術的には優れていたものの、FACTは移植性を考慮して作成されたものではなく、メーカーとユーザーの合意に基づいて作成されたものでもなかった。また、実証可能な実装も欠如していたため、[ 30 ] FLOW-MATICベースのCOBOLの支持者が決議を覆すことができた。RCAの代表であるハワード・ブロムバーグもFACTを阻止し、RCAのCOBOL実装に関する作業が無駄にならないようにした。[ 64 ]
委員会が大きすぎて、それ以上の進展をすぐには進めないことがすぐに明らかになった。苛立ったハワード・ブロムバーグは、「COBOL」と刻まれた15ドルの墓石（1959年当時、2025年換算で170ドル相当）[ 65 ]を購入し、不満を示すためにチャールズ・フィリップスに送った。[ b ] [ 67 ] [ 68 ]
既存の言語を分析するために小委員会が結成され、6人のメンバーで構成されました。[ 26 ] [ 69 ]
小委員会が仕様書の作成作業の大部分を行い、短期委員会は最終仕様書を作成する前にその作業をレビューおよび修正した。[ 26 ]
仕様は1960年1月8日に執行委員会によって承認され、政府印刷局に送られ、COBOL 60として印刷された。この言語の目的は、効率的で移植性の高いプログラムを簡単に作成できるようにすること、ユーザーが最小限の労力とコストで新しいシステムに移行できるようにすること、そして経験の浅いプログラマーにも適していることであった。[ 70 ]
CODASYL執行委員会は後に、ユーザーやベンダーからの質問に答え、仕様を改善および拡張するためにCOBOL保守委員会を設立した。[ 71 ]
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 に置き換える計画を立てていた。[ 72 ]
一方、RCAとスペリー・ランドはCOBOLコンパイラの開発に取り組んでいた。最初のCOBOLプログラムは8月17日にRCA 501で実行された。[ 73 ] 12月6日と7日には、同じCOBOLプログラム（若干の変更はあったものの）がRCAコンピュータとレミントン・ランド・ユニバックコンピュータで実行され、互換性が実現できることが実証された。[ 74 ]
使用された言語の相対的な影響力は、すべてのCOBOLリファレンスマニュアルに掲載されている推奨事項に依然として示されています。
COBOLは業界標準の言語であり、いかなる企業や企業グループ、あるいは組織や組織グループの所有物でもありません。
貢献者およびCODASYL COBOL委員会は、プログラミングシステムおよび言語の正確性および動作に関して、明示的または黙示的な保証を一切行いません。また、貢献者および委員会は、これに関して一切の責任を負いません。本書で使用されている著作物の著者および著作権者は以下のとおりです。
FLOW-MATIC（ Unisys Corporationの商標）、UNIVAC（R）IおよびII用プログラミング、データ自動化システム、1958年、1959年にUnisys Corporationが著作権を取得。IBM商用翻訳フォームNo. F28-8013、1959年にIBMが著作権を取得。FACT、DSI 27A5260-2760、1960年にMinneapolis-Honeywellが著作権を取得。彼らは、この資料の全部または一部をCOBOL仕様書で使用することを明示的に許可しています。このような許可は、プログラミングマニュアルや同様の出版物におけるCOBOL仕様書の複製および使用にも及びます。[ 75 ]
COBOLが今世紀末まで存続している可能性はかなり低いだろう。
COBOL 60には多くの論理的な欠陥が見つかり、ゼネラル・エレクトリックのチャールズ・カッツは、明確に解釈できないと警告した。しぶしぶの短期委員会が全面的な修正を行い、1963 年 3 月までに、意味的な曖昧さは残るものの、COBOL の構文はALGOLと同程度に定義可能になったと報告された。[ 72 ]
初期の COBOL コンパイラは原始的で低速でした。 COBOL は、構文が大きく、構文構造内に多くのオプション要素があること、また、多くの可能なデータ表現、暗黙的な型変換、および I/O 操作に必要なセットアップを備えた言語に対して効率的なコードを生成する必要があるため、コンパイラを作成するのが難しい言語です。[ 77 ] 1962 年の米国海軍の評価では、コンパイル速度は毎分 3 ～ 11 ステートメントであることがわかりました。1964 年半ばまでに、毎分 11 ～ 1000 ステートメントに増加しました。メモリを増やすと速度が大幅に向上し、コンパイル コストは大きく変動することが観察されました。ステートメントあたりのコストは $0.23 ～ $18.91 でした。[ 78 ]
1962年後半、IBMはCOBOLを主要な開発言語とし、COMTRANの開発を中止すると発表した。[ 78 ]
COBOL 仕様は、発行後 5 年間で 3 回改訂されました。COBOL-60 は 1961 年に COBOL-61 に置き換えられました。その後、1963 年に COBOL-61 Extended 仕様に置き換えられ、ソート機能とレポートライター機能が導入されました。[ 79 ]追加された機能は、1959 年後半に Honeywell が短期委員会への書簡で指摘した欠陥を修正しました。[ 73 ] COBOL Edition 1965 では、仕様がさらに明確化され、大容量ストレージファイルとテーブルを処理する機能が導入されました。[ 80 ]
COBOL のバージョン間の非互換性を克服するために、標準化の取り組みが始まった。1962 年後半、ISO と米国規格協会 (現在のANSI ) の両方が標準を作成するグループを結成した。ANSI は1968 年 8 月にUSA Standard COBOL X3.23を作成し、これが後のバージョンの基礎となった。[ 81 ]このバージョンは American National Standard (ANS) COBOL として知られ、1972 年に ISO に採用された。[ 82 ]
1970年までに、COBOLは世界で最も広く使われているプログラミング言語となった。[ 83 ]
ANSI委員会とは別に、CODASYLプログラミング言語委員会は言語の改良に取り組んでいた。彼らは1968年、1969年、1970年、1973年に新しいバージョンを発表し、プログラム間通信、デバッグ、ファイルマージ機能などの変更に加え、文字列処理とライブラリインクルード機能の改善も行った。[ 84 ]
CODASYLはANSI委員会とは独立していたが、 ANSIはCODASYL Journal of Developmentを利用して、実装に値するほど人気のある機能を特定した。[ 85 ]プログラミング言語委員会はECMAおよび日本のCOBOL標準化委員会とも連携していた。 [ 84 ]
しかし、プログラミング言語委員会はあまり知られていなかった。副会長のウィリアム・ラインハルスは、COBOLコミュニティの3分の2が委員会の存在を知らないと不満を漏らした。また、会議の議事録や変更提案などの公開文書を無料で提供するための資金も不足していた。[ 86 ]
1974 年、ANSI は (ANS) COBOL の改訂版を公表し、ファイル編成、DELETEステートメント[ 87 ]、セグメンテーションモジュール[ 88 ]などの新機能を追加しました。削除された機能にはNOTE、ステートメント、EXAMINEステートメント ( に置き換えられましたINSPECT)、実装者定義のランダム アクセス モジュール (新しいシーケンシャル I/O モジュールと相対 I/O モジュールに置き換えられました) などがありました。これらにより 44 の変更が行われ、既存のステートメントは新しい標準と互換性がなくなりました。[ 89 ]レポート ライターは COBOL から削除される予定でしたが、標準が公表される前に復活しました。[ 90 ] [ 91 ] ISO は後に 1978 年に更新された標準を採用しました。[ 82 ]
1978 年 6 月、COBOL-74 の改訂作業が開始されました。提案された標準 (一般に COBOL-80 と呼ばれています) は以前のものとは大きく異なっており、非互換性や変換コストに関する懸念が生じました。1981 年 1 月、トラベラーズ保険の上級副社長である Joseph T. Brophy 氏は、COBOL-74 との上位互換性がないとして、標準委員会を訴えると脅しました。Brophy 氏は、4,000 万行のコード ベースの以前の変換を「非生産的」で「プログラマー リソースの完全な無駄」と表現しました。[ 92 ]同年後半、データ処理管理協会(DPMA) は、変換コストが「法外」であり、「ユーザーに強制される」機能強化を理由に、新しい標準に「強く反対」すると表明しました。[ 93 ] [ 94 ]
最初の公開レビュー期間中、委員会は2,200件の回答を受け取り、そのうち1,700件は否定的な定型書簡でした。[ 95 ]その他の回答は、COBOL-80が自社のシステムに与える影響の詳細な分析であり、変換コストはコード1行あたり少なくとも50セントになると予測されていました。提案された標準に賛成する回答は12件未満でした。[ 96 ]
ISO TC97-SC5は、 Wim Ebbinkhuijsenの発案により、1979年に国際COBOL専門家グループを設立しました。このグループは、米国を含む多くの国のCOBOL専門家で構成されていました。その目的は、新しいCOBOL機能の必要性に関して、ANSIと世界の他の国々との間で相互理解と尊重を達成することでした。3年後、ISOはこのグループの地位を正式なワーキンググループであるWG 4 COBOLに変更しました。このグループはCOBOL標準の主要な所有権と開発を引き継ぎ、ANSIが提案の大部分を行いました。
1983年、DPMAは委員会が世間の懸念に迅速に対応したことを理由に、この規格に対する反対を取り下げた。同年、国立標準局の調査では、提案された規格にはほとんど問題がないと結論付けられた。[ 94 ] [ 97 ] 1年後、DECはVAX/VMS COBOL-80をリリースし、COBOL-74プログラムの変換にはほとんど問題がないと指摘した。新しいEVALUATEステートメントとインラインはPERFORM特に好評で、制御フローとデバッグの簡素化により生産性が向上した。[ 98 ]
2回目の公開レビューではさらに1,000件の（主に否定的な）回答が寄せられたが、最後のレビューではわずか25件しか寄せられず、その時点で多くの懸念事項が解消されていた。[ 94 ]
1985年、ISOワーキンググループ4は、当時ANSIが提案していた規格案を承認し、いくつかの変更を加えて、新しいISO規格COBOL 85として制定した。これは1985年末に発行された。
60 の機能が変更または廃止され、115 [ 99 ]が追加されました。例えば、次のとおりです。[ 100 ] [ 101 ]
END-IF、、END-PERFORMなどEND-READ）CONTINUE操作なしの声明EVALUATEswitch文INITIALIZEデータグループをデフォルト値に設定できるステートメントPERFORMループ本体 – 以前は、ループ本体は別のプロシージャで指定する必要がありました。この新しい規格は、ANSIを含むすべての国家標準化機関によって採用された。[ 82 ]
1989年と1993年に2つの改正が行われた。最初の改正では組み込み関数モジュールが導入され、後者では修正が行われた。[ 82 ]
1997年、ガートナーグループは、COBOLコードの総行数が2000億行に達し、全ビジネスプログラムの80%がCOBOLで実行されていると推定した。[ c ] [ 102 ]
1990年代初頭、COBOLの次期全面改訂版でオブジェクト指向プログラミングを追加する作業が始まった。オブジェクト指向機能はC++とSmalltalkから取り入れられた。[ 4 ] [ 5 ]
当初の見積もりでは、この改訂は1997年までに完了する予定であり、ISO委員会ドラフト（CD）は1997年までに利用可能でした。一部のベンダー（Micro Focus、富士通、IBMなど）は、完全な改訂のドラフトに基づいてオブジェクト指向構文を導入しました。最終的に承認されたISO規格は、2002年後半に承認され、発行されました。[ 103 ]
富士通/GTSoftware、[ 104 ] Micro Focusは.NET Frameworkをターゲットとしたオブジェクト指向COBOLコンパイラを導入した。
他にも多くの新機能があり、その多くは1978 年以来CODASYL COBOL Journal of Developmentに掲載されていたものの、COBOL-85 に収録される機会を逃していたものでした。[ 105 ]これらのその他の機能には以下が含まれます。[ 106 ] [ 107 ]
SCREEN SECTIONインターフェース向けVALIDATEこの規格には3つの訂正が発行された。2006年に2つ、2009年に1つである。 [ 108 ]
2003年から2009年の間に、 COBOLのオブジェクトファイナライゼーション、XML処理、コレクションクラスについて記述した3つの技術レポート（TR）が作成されました。 [ 108 ]
COBOL 2002 はサポートが不十分で、標準を完全にサポートするコンパイラは存在しませんでした。Micro Focus は、その原因は新機能に対するユーザーの需要の不足と、コンパイラの適合性をテストするために使用されていたNISTテストスイートの廃止にあることを突き止めました。標準化プロセスも遅く、リソース不足であることが判明しました。[ 109 ]
COBOL 2014 には以下の変更が含まれています: [ 110 ]
VALIDATE主要機能のうち、設備、レポート作成ツール、画面処理機能などはオプションとなっています。COBOL 2023規格では、いくつかの新機能が追加されました。
SENDandRECEIVEステートメントを使用します[ 112 ]COMMITとROLLBACK[ 112 ]XOR論理演算子[ 112 ]CONTINUEステートメントは、プログラムを指定された期間一時停止するように拡張できます[ 113 ]。DELETE FILELINE SEQUENTIALファイル編成[ 114 ]PERFORM UNTIL EXITSUBSTITUTE異なる長さの部分文字列置換を可能にする固有関数[ 113 ]CONVERT塩基変換のための関数[ 113 ]COBOL プログラムは、政府機関や小売、旅行、金融、医療などさまざまな業界で世界的に使用されています。2016年に米国下院監視・政府改革委員会で行われた証言によると、COBOL は米国農務省(USDA)、国土安全保障省(DHS)、保健福祉省(HHS)、米国司法省、米国財務省、米国退役軍人省(VA) [ 117 ]や内国歳入庁 (IRS) [ 118 ]など、多くの連邦機関で今も使用されています。
COBOLは現在、 z/OS、z/VSE、VME、Unix、NonStop OS、OpenVMS、Windowsなどの多様なオペレーティングシステム上で動作しています。1997年、ガートナーグループは、世界のビジネスの80%がCOBOL上で稼働しており、2000億行を超えるコードが存在し[ c ]、さらに毎年50億行が新たに記述されていると報告しました[ 119 ] 。 2020年現在、クレジットカードまたはデビットカードがスワイプされた時の95%で、COBOLがバックグラウンドプロセスを実行していました[ 120 ] 。
20世紀末近く、2000年問題（Y2K）は、COBOLプログラミングの大きな焦点となり、時には数十年前にシステムを設計したのと同じプログラマーによって行われた。COBOLコードの修正に要した特別なレベルの労力は、ビジネスアプリケーションが日付を多用することや、固定長データフィールドなど、ビジネス指向のCOBOLが大量に存在することに起因するとされている。[ 121 ]一部の研究では、「Y2Kソフトウェア修復コストの24%がCOBOLに起因する」とされている。[ 122 ] Y2K対策としてこれらのプログラムにクリーンアップ作業が行われた後、2003年の調査では、多くのプログラムが依然として使用されていることが判明した。[ 123 ]著者らは、調査データは「他の言語やテクノロジーとの統合が採用されない限り、今後10年間でアプリケーション開発におけるCOBOLの重要性が徐々に低下していく」ことを示唆していると述べている。[ 124 ]
2006年と2012年にComputerworldが行った調査（読者352名）によると、組織の60%以上がCOBOLを使用しており（C++やVisual Basic .NETよりも多い）、そのうち半数では、社内ソフトウェアの大部分にCOBOLが使用されていることがわかった。[ 12 ] [ 125 ]マネージャーの36%がCOBOLからの移行を計画していると回答し、25%がレガシーコードの書き換え費用がなければ移行すると回答した。あるいは、一部の企業はCOBOLプログラムをメインフレームからより安価で高速なハードウェアに移行している。[ 12 ]
2019年までに、退職によりCOBOLプログラマーの数は急速に減少しており、大量のトランザクション処理にメインフレームシステムを使用している企業や政府機関では、差し迫ったスキルギャップが生じている。COBOLシステムを新しい言語で書き換える試みは、コード保守のアウトソーシングと同様に、費用がかかり問題が多いことが判明しており、そのため、より多くの人にCOBOLを訓練するよう提案されている。[ 126 ]
いくつかの銀行は、数年にわたるCOBOLの近代化に取り組んできたが、その結果、広範囲にわたるサービス停止が発生し、罰金が科せられることもあった。[ 127 ]
COVID-19パンデミックとその後の失業者の急増の間、米国のいくつかの州では、失業給付管理に使用されているレガシーシステムをサポートする熟練したCOBOLプログラマーが不足していると報告されました。これらのシステムの多くは、パンデミック以前に、より現代的なプログラミング言語への移行を進めていましたが、そのプロセスは中断されました。 [ 128 ]同様に、米国国税庁は、コロナウイルス支援・救済・経済安全保障法によって義務付けられた数千万件の支払いを分配するために、COBOLベースの個人マスターファイルのパッチ適用を急ぎました。[ 129 ]
2024年、IRSはデジタルファーストイニシアチブのおかげでCOBOLからJavaへの移行を発表した。[ 118 ]
COBOL には英語に似た構文があり、COBOL プログラム内のほぼすべてのものを記述するために使用されます。たとえば、条件は または とより簡潔に または と表現できます。より複雑な条件は、繰り返される条件や変数を削除することで省略できます。たとえば、は に短縮できます。この構文をサポートするために、COBOL には 300 を超えるキーワードがあります。[ 130 ] [ d ]キーワードの中には、同じ単語の単純な代替スペルまたは複数形スペルがあり、より文法的に適切なステートメントや節を提供します。たとえば、およびキーワードは、および、 および と同様に、互換的に使用できます。 xISGREATERTHANy xGREATERy x>y a>bANDa>cORa=d a>bANDcOR =dINOFTIMETIMESVALUEVALUES
COBOL プログラムはそれぞれ、単語、リテラル、ピクチャ文字文字列、区切り文字の4 つの基本語彙項目で構成されています。単語には、予約語とユーザー定義の識別子が含まれます。単語は最大 31 文字の長さで、文字、数字、ハイフン、アンダースコアを含めることができます。リテラルには、数字 (例: 12) と文字列 (例: 'Hello!') が含まれます。[ 132 ]区切り文字には、スペース文字、カンマ、セミコロンの後にスペースが続くものが含まれます。[ 133 ]
COBOLプログラムは、識別部、環境部、データ部、手続き部の4つの部分に分かれています。識別部では、ソース要素の名前と型を指定し、クラスやインターフェースもここで指定します。環境部では、ファイルや文字セットなど、実行システムに依存するプログラム機能を指定します。データ部は、変数やパラメータを宣言するために使用されます。手続き部には、プログラムのステートメントが含まれます。各部分はさらに細分化され、各部分は段落で構成されます。
COBOLの構文は通常、中括弧、角括弧、横棒、下線を使用した独自のメタ言語で記述されます。 [ 134 ]このメタ言語は、オリジナルのCOBOL仕様のために開発されました。
例として、以下の記述を考えてみましょうADD。
この説明では、以下のバリエーションが認められます。
![{\displaystyle {\begin{array}{l}{\underline {\texttt {ADD}}}\,{\begin{Bmatrix}{\text{identifier-1}}\\{\text{literal-1}}\end{Bmatrix}}\dots \;{\underline {\texttt {TO}}}\,\left\{{\text{identifier-2}}\,\left[\,{\underline {\texttt {ROUNDED}}}\,\right]\right\}\dots \\[1em]\quad \left[\left|{\begin{array}{l}{\texttt {ON}}\,{\underline {\texttt {SIZE}}}\,{\underline {\texttt {ERROR}}}\,{\text{imperative-statement-1}}\\{\underline {\texttt {NOT}}}\,{\texttt {ON}}\,{\underline {\texttt {SIZE}}}\,{\underline {\texttt {ERROR}}}\,{\text{imperative-statement-2}}\end{array}}\right|\right]\\[1em]\quad \left[\,{\underline {\texttt {END-ADD}}}\,\right]\end{array}}}](https://wikimedia.org/api/rest_v1/media/math/render/svg/a8a894245501c861603ac07cf1d21766b453da59)
xに1を加算、a 、bをxに丸める、y 、zを丸めるADD a , b TO c ON SIZE ERROR DISPLAY "Error" END-ADDaをbに追加サイズエラーが発生しない場合は「エラーなし」と表示サイズエラーが発生した場合は「エラー」と表示
COBOLの人気がピークに達したのは、キーパンチ機とパンチカードの時代と重なっていた。プログラム自体はパンチカードに書き込まれ、読み込まれてコンパイルされ、プログラムに入力されるデータもカードに記録されることがあった。[ 135 ]
COBOLは、固定形式（デフォルト）と自由形式の2つの形式で記述できます。固定形式では、コードは特定の領域に収まるように整列する必要があります（パンチカードを使用していた時代の名残です）。COBOL 2002までは、これらの領域は次のとおりでした。
COBOL 2002では、領域AとBが統合されてプログラムテキスト領域が形成され、現在は実装者定義の列で終了するようになっています。[ 136 ]
COBOL 2002 では、自由形式コードも導入されました。自由形式コードは、新しいプログラミング言語と同様に、ファイルの任意の列に配置できます。コメントは を使用して指定され*>、これはどこにでも配置でき、固定形式のソース コードでも使用できます。継続行は存在せず、>>PAGEディレクティブがインジケータを置き換えます/。[ 136 ]
識別部は、以下のコード実体を識別し、クラスまたはインターフェースの定義を含みます。
COBOL には 2002 年以来クラスとインターフェースがあります。クラスには、クラスメソッドと変数を含むファクトリ オブジェクトと、インスタンス メソッドと変数を含むインスタンス オブジェクトがあります。[ 137 ]継承とインターフェースはポリモーフィズムを提供します。汎用プログラミングのサポートは、任意のクラスまたはインターフェースを使用するようにインスタンス化できるパラメータ化クラスによって提供されます。オブジェクトは、特定の型に制限できる参照として格納されます。メソッドを呼び出す方法は 2 つあります。INVOKEと同様に動作するステートメント、CALLまたは関数の使用に類似したインライン メソッド呼び出しです。[ 138 ]
*> これらは同等です。INVOKE my-class "foo" RETURNING var MOVE my-class :: "foo" TO var *> インラインメソッド呼び出しCOBOL にはメソッドを隠す方法がありません。ただし、クラスデータを句なしで宣言することで隠蔽することができPROPERTY、外部コードからアクセスできなくなります。[ 139 ]メソッドのオーバーロードは COBOL 2014 で追加されました。[ 140 ]
環境セクションには、設定セクションと入出力セクションが含まれます。設定セクションでは、通貨記号、ロケール、文字セットなどの可変機能を指定します。入出力セクションには、ファイル関連の情報が含まれます。
COBOL は、順次、索引付き、相対の 3 つのファイル形式または構成をサポートしています。順次ファイルでは、レコードは連続しており、リンク リストと同様に、順次走査する必要があります。索引付きファイルには、レコードにランダムにアクセスしたり、レコードに基づいてソートしたりできる1 つ以上の索引があります。各レコードには一意のキーが必要ですが、その他の代替レコード キーは一意である必要はありません。索引付きファイルの実装はベンダーによって異なりますが、C-ISAMやVSAMなどの一般的な実装は IBM のISAMに基づいています。その他の実装としては、OpenVMSのRecord Management ServicesやHPE NonStop (Tandem)のEnscribe があります。相対ファイルは、索引付きファイルと同様に、一意のレコード キーを持ちますが、代替キーはありません。相対レコードのキーは順序位置です。たとえば、10 番目のレコードのキーは 10 です。これは、キーが 5 のレコードを作成する場合、その前の (空の) レコードを作成する必要がある可能性があることを意味します。相対ファイルでは、シーケンシャルアクセスとランダムアクセスの両方が可能です。[ 141 ]
一般的な非標準拡張機能として、テキストファイルの処理に使用される行シーケンシャル編成があります。ファイル内のレコードは改行で終了し、長さは様々です。[ 142 ]
データ部は、ファイルレコード用のファイル部、静的変数用の作業記憶部、自動変数用のローカル記憶部、パラメータと戻り値用のリンク部、テキストベースのユーザーインターフェイス用のレポート部と画面部の6つのセクションに分かれています。
COBOL のデータ項目は、あるデータ項目が別のデータ項目の一部であるかどうかを示すレベル番号を使用して階層的に宣言されます。レベル番号が大きい項目は、レベル番号が小さい項目の下位になります。レベル番号が 1 の最上位のデータ項目はレコードと呼ばれます。下位の集計データを持つ項目はグループ項目と呼ばれ、持たない項目は基本項目と呼ばれます。標準データ項目を記述するために使用されるレベル番号は 1 ～ 49 です。[ 143 ] [ 144 ]
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句でも言及されるこのデータレベルはめったに使用されず[ 145 ]、1988年頃には古いプログラムでよく見られました。階層構造と論理構造のデータを無視できるため、その使用は推奨されず、多くのインストールでその使用が禁止されていました。[ 146 ]
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 .レベル番号77は、その項目が独立したものであることを示し、そのような状況ではレベル番号01と同等です。たとえば、次のコードは、77レベルのデータ項目property-nameとを2つ宣言します。sales-regionこれらは、他のデータ項目とは独立している（従属していない）非グループデータ項目です。
77 プロパティ名PIC X(80) 。77 販売地域PIC 9(5) 。88 レベルの番号は、その親データ項目が句で指定された値のいずれかを含む場合に真となる条件名(いわゆる 88 レベル)を宣言します。 [ 147 ]例えば、次のコードは、データ項目の現在の文字データ値に応じて真または偽となる 2 つの 88 レベルの条件名項目を定義します。データ項目に の値が含まれている場合、条件名は真となり、またはの値が含まれている場合、条件名は真となります。データ項目に他の値が含まれている場合、両方の条件名は偽となります。VALUEwage-type'H'wage-is-hourly'S''Y'wage-is-yearly
01 賃金タイプPIC X . 88 賃金は時給VALUE "H" . 88 賃金は年額VALUE "S" 、"Y" .標準COBOLでは、以下のデータ型が提供されています。[ 148 ]
COBOLでは型の安全性は可変です。数値データは異なる表現やサイズ間で暗黙的に変換され、英数字データは数値データやグループデータを含め、文字列として格納できる任意のデータ項目に格納できます。[ 149 ]対照的に、オブジェクト参照とポインタは同じ型の項目からのみ割り当てることができ、その値は特定の型に制限される場合があります。[ 150 ]
（PICTUREまたはPIC）句は文字列であり、各文字はデータ項目の一部と、それに含まれる内容を表します。一部のピクチャ文字は、項目のタイプと、メモリ内で占める文字数または桁数を指定します。たとえば、は910進数を示し、はS項目が符号付きであることを示します。その他のピクチャ文字（挿入文字および編集文字と呼ばれる）は、項目の書式を指定します。たとえば、一連の+文字は、文字の位置と、先頭の符号文字が最終的な文字データ内でどのように配置されるかを定義します。最も右の非数値文字には項目の符号が含まれ、+この位置の左側にあるに対応する他の文字位置にはスペースが含まれます。繰り返し文字は、ピクチャ文字の後に括弧で囲んだ数値を指定することで、より簡潔に指定できます。たとえば、9(7)はと同等です。数字（ ）と符号（）文字9999999のみを含むピクチャ指定は、純粋な数値データ項目を定義し、アルファベット（ ）または英数字（）文字を含むピクチャ指定は、英数字データ項目を定義します。その他の書式設定文字の存在は、編集された数値データまたは編集された英数字データ項目を定義します。[ 151 ]9SAX
このUSAGE句は、データが格納される形式を宣言します。データ型によっては、句を補完したり、PICTURE句の代わりに使用したりできます。ポインタやオブジェクト参照を宣言するために使用できますが、主に数値型を指定することを目的としています。これらの数値形式は次のとおりです。[ 152 ]
PICTURE句またはUSAGE句などによって指定されます。BINARY-LONGUSAGECOMPUTATIONALデータは実装が提供する形式であればどのような形式でも保存される可能性があります。多くの場合、 USAGEBINARYUSAGEDISPLAYデフォルトの形式で、データは文字列として保存されます。USAGENATIONALデータは拡張文字セットを使用して文字列として格納されます。USAGEPACKED-DECIMALデータは可能な限り最小の10進数形式（通常はパック2進化10進数）で格納されます。レポートライターは、レポートを作成するための宣言型機能です。プログラマーはレポートのレイアウトと作成に必要なデータを指定するだけでよく、ページ区切り、データフォーマット、見出しやフッターなどの処理コードを書く必要がなくなります。[ 153 ]
レポートはレポートファイルに関連付けられており、レポートファイルにはレポートライターのステートメントを通してのみ書き込みが可能です。
FDレポート出力レポート売上レポート。各レポートは、データ部門のレポートセクションで定義されます。レポートは、レポートの見出し、フッター、および詳細を定義するレポートグループに分割されます。レポートは、階層的な制御ブレークに対応しています。制御ブレークは、キー変数の値が変更されたときに発生します。たとえば、顧客の注文の詳細を示すレポートを作成する場合、プログラムが別の顧客の注文に到達したときに制御ブレークが発生する可能性があります。以下は、営業担当者の売上を表示し、無効なレコードがあれば警告するレポートのレポート記述例です。
RD売上レポートページ制限60行最初の詳細3コントロール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 "販売者:" . 03 COL 9 PIC X(30) SOURCE seller-name .上記のレポート説明では、以下のレイアウトについて説明しています。
売上報告書 1ページ目販売者: ハワード・ブロムバーグ 2008年10月12日の売上は$1000.00 2008年12月12日の売上は$0.00 2008年12月13日の売上は$31.47 無効なレコード: ハワード・ブロムバーグ XXXXYY販売者：ハワード・ディスカウント…売上報告書12ページ 2014年8月5日の売上は$543.98でした。 無効なレコード: William Selden 12052014FOOFOO 2014年5月30日の売上は$0.00でした。レポートライターを制御するステートメントは 4 つあります。1つINITIATE目は、レポートライターを印刷用に準備するステートメントGENERATE、2つ目は、レポートグループを印刷するステートメントSUPPRESS、3つ目は、レポートグループの印刷を抑制するステートメント、4つ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 。レポートライター機能の使用状況は組織によって大きく異なり、広く利用している組織もあれば、全く利用していない組織もあります。[ 154 ]さらに、レポートライターの実装の品質にもばらつきがあり、低品質の実装では実行時に過剰なメモリを使用する場合があります。[ 154 ]
手続き部（総称して手続きと呼ばれる）内のセクションと段落は、ラベルや単純なサブルーチンとして使用できます。他の部とは異なり、段落はセクションに含める必要はありません。[ 155 ]
実行は、プログラムが終了するまで、プログラムの手順を順に進んでいきます。[ 156 ] 手順をサブルーチンとして使用するには、PERFORM動詞が使用されます。
ステートメントは、呼び出されたコードの最後にステートメントの次のコードPERFORMに実行が戻るという点で、新しい言語のプロシージャ呼び出しにいくらか似ています。ただし、パラメータの受け渡しや結果値の返却のためのメカニズムは提供されません。 のような単純なステートメントを使用してサブルーチンが呼び出された場合、制御は呼び出されたプロシージャの最後に戻ります。しかし、 は、連続する複数のプロシージャの範囲を呼び出すために使用できるという点で特殊です。これは、次の構文を使用して行います。PERFORMPERFORMsubroutinePERFORMPERFORMsub-1THRUsub-n
PROCEDURE so-and-so . PERFORM ALPHA PERFORM ALPHA THRU GAMMA STOP RUN . ALPHA . DISPLAY 'A' . BETA . DISPLAY 'B' . GAMMA . DISPLAY 'C' .このプログラムの出力は次のようになります。AABC「。
PERFORMまた、従来のプロシージャ呼び出しとは異なり、少なくとも従来はコールスタックの概念がありません。そのため、ネストされた呼び出し（一連のコードがそれ自体でステートメントPERFORMを実行するPERFORM）は可能ですが、同じコードの一部が両方の呼び出しで実行される場合は、特に注意が必要です。問題は、内側の呼び出しのコードが外側の呼び出しの終了点に到達したときに発生します。より厳密には、以前PERFORMに呼び出されたもののまだ完了していない呼び出しの終了点を制御が通過する場合、COBOL 2002 規格では動作が未定義であると規定されています。
その理由は、COBOL では「戻りアドレス」ではなく、継続アドレスと呼ばれるものを使用するからです。制御フローがプロシージャの終わりに達すると、継続アドレスが検索され、制御はそのアドレスに転送されます。プログラムの実行前に、各プロシージャの継続アドレスは、プログラムテキストで次に続くプロシージャの開始アドレスに初期化されます。これにより、PERFORMステートメントが実行されない場合は、制御はプログラムの上から下へと流れます。しかし、PERFORMステートメントが実行されると、呼び出されたプロシージャ（または、が使用されている場合は呼び出し範囲の最後のプロシージャ）の継続アドレスが変更されPERFORM THRU、制御は最後に呼び出し元に戻ります。元の値は保存され、後で復元されますが、記憶位置は 1 つしかありません。ネストされた 2 つの呼び出しが重複するコードを操作すると、継続アドレスの管理がさまざまな方法で互いに干渉する可能性があります。[ 157 ] [ 158 ]
以下の例（Veerman & Verhoeven 2006より引用）は、この問題を例示している。
LABEL1 . DISPLAY '1' PERFORM LABEL2 THRU LABEL3 STOP RUN . LABEL2 . DISPLAY '2' PERFORM LABEL3 THRU LABEL4 . LABEL3 . DISPLAY '3' . LABEL4 . DISPLAY '4' .このプログラムの出力は次のようになると予想されるかもしれない。1 2 3 4 3": 表示後 "2「、2番目のPERFORM原因は3" そして "4「表示される」、そして最初の呼び出しは「3。従来の COBOL 実装では、これは当てはまりません。むしろ、最初のPERFORMステートメントは の末尾に継続アドレスを設定し、LABEL3内の呼び出し箇所にジャンプバックしますLABEL1。2 番目のPERFORMステートメントは の末尾にリターンを設定しますLABEL4が、 の継続アドレスは変更せずLABEL3、デフォルトの継続アドレスであると想定します。したがって、内部呼び出しが の末尾に到達するとLABEL3、外部ステートメントにジャンプバックしPERFORM、プログラムは を出力しただけで終了してしまいます。1 2 3一方、オープンソースのTinyCOBOLコンパイラのような一部のCOBOL実装では、2つのPERFORMステートメントは互いに干渉せず、出力は確かに「1 2 3 4 3したがって、このような場合の挙動は（おそらく）驚くべきものであるだけでなく、移植性もありません。[ 158 ]
この制限の特別な結果として、PERFORM再帰的なコードを記述するために使用することはできません。再帰ルーチンを記述するには、ネストされたサブルーチンを使用する必要があります。これを説明するもう1つの簡単な例（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' .出力は「1 2 3 終了 終了 終了実際、一部の COBOL コンパイラはこれを生成します。しかし、IBM COBOL のような他のコンパイラは、これを出力するコードを生成します。1 2 3 終了 終了 終了 終了 ...「などなど、印刷」終わり無限ループで何度も繰り返されます。バックアップ継続アドレスを格納するスペースが限られているため、バックアップは再帰呼び出しの過程で上書きされ、復元できるのは へのジャンプバックのみですDISPLAY 'END'。[ 158 ]
COBOL 2014 には 47 個のステートメント (動詞とも呼ばれる) があり、[ 159 ]は、制御フロー、I/O、データ操作、レポートライターという大まかなカテゴリに分類できます。レポートライターのステートメントについては、レポートライターのセクションで説明します。
COBOL の条件文はIFとですEVALUATE。は、複数の値と条件を評価する機能を追加したswitch 文のようなものEVALUATEです。これは、決定表を実装するために使用できます。たとえば、次のコードはCNC 旋盤を制御するために使用できます。
評価TRUEかつdesired-speedかつcurrent-speed蓋が閉じているとき かつmin -speedからmax-speedまでかつdesired-speedより小さい蓋が閉じているとき かつmin -speedからmax-speedまでかつdesired -speedより大きい蓋が開いているとき かつanyかつゼロでない緊急停止他 の場合継続評価終了このステートメントは、条件が真になるまでPERFORM実行されるループを定義するために使用されます(他の言語でより一般的なwhile true ではありません)。また、プロシージャまたはプロシージャの範囲を呼び出すためにも使用されます (詳細については、プロシージャのセクションを参照してください)。と は、それぞれサブルーチンとメソッドを呼び出します。サブルーチン/メソッドの名前は、リテラルまたはデータ項目である文字列に含まれています。[ 160 ]パラメータは、参照、内容 (コピーが参照で渡される場合)、または値(プロトタイプが利用可能な場合のみ) で渡すことができます。 [ 161 ] は、サブルーチンをメモリからアンロードします。は、プログラムを指定されたプロシージャにジャンプさせます。CALLINVOKECANCELGO TO
このGOBACK文は戻り文であり、STOPプログラムを停止させます。この文には 6 つの異なる形式があります。戻り文、 break 文、continue 文、終了マーカー、またはプロシージャの終了EXITに使用できます。 [ 162 ]
例外はステートメントによって発生し、プロシージャ部のセクションで定義されたRAISEハンドラまたは宣言によって捕捉されます。宣言は、処理するエラーを指定するステートメントで始まるセクションです。例外は名前またはオブジェクトになります。宣言では、例外を発生させたステートメントの次のステートメント、またはプロシージャ部外のプロシージャにジャンプするために使用されます。他の言語とは異なり、捕捉されない例外によってプログラムが終了しない場合があり、プログラムは影響を受けずに続行できます。DECLARATIVESUSERESUMEDECLARATIVES
ファイル入出力は、自己記述型の、、、およびステートメントと、さらに次の3つのステートメントによって処理されます。OPENレコードを更新する、特定のキーを持つレコードを検索してアクセスする後続のレコードを選択する、最後にアクセスしたレコードのロックを解除する。CLOSEREADWRITEREWRITESTARTUNLOCK
ACCEPTユーザーとのやり取りは、とを使用して行われますDISPLAY。
以下の動詞はデータを操作します。
INITIALIZEこれは、データ項目をデフォルト値に設定します。MOVEデータ項目に値を割り当てます 。MOVE CORRESPONDING は、対応する同名のフィールドを割り当てます。SET15種類のフォーマットがあり、インデックスの変更、オブジェクト参照の割り当て、テーブル容量の変更などの機能があります。[ 163 ]ADD、、、、およびは、算術演算（式の計算結果を変数に代入する）を処理しSUBTRACTます。MULTIPLYDIVIDECOMPUTECOMPUTEALLOCATEそして、動的メモリFREEを扱う。VALIDATEこれは、データ部門の項目の説明に指定されたとおりにデータを検証および配布します。STRINGおよび はUNSTRING、それぞれ文字列を連結および分割します。INSPECTこれは、文字列内の指定された部分文字列の出現回数をカウントまたは置換します。SEARCHこれは、条件を満たす最初のエントリをテーブル内で検索します。ファイルとテーブルはSORT、このMERGE動詞を使用してソートされ、ファイルのマージとソートが行われます。このRELEASE動詞は、ソート対象のレコードを提供し、RETURNソートされたレコードを順番に取得します。
IFやなどの一部のステートメントは、READそれ自体がステートメントを含む場合があります。このようなステートメントは、2つの方法で終了できます。1つはピリオド（暗黙の終了）で、含まれるすべての終了していないステートメントを終了させる方法、もう1つはスコープ終了子で、最も近い一致する開始ステートメントを終了させる方法です。
*> 終了期間（「暗黙の終了」）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ピリオドで終わるネストされたステートメントは、バグの一般的な原因です。[ 164 ] [ 165 ]例えば、次のコードを調べてみましょう。
x が真の場合、yを表示する。zを表示する。ここでは、条件が真の場合にyとを表示することを意図しています。しかし、の後に誤ったピリオドがあるため、 の値に関係なく が表示されます。zxzxIFDISPLAYy
もう1つのバグは、2つのステートメントが関連付けられる可能性がある場合に発生する、ぶら下がりelse問題の結果です。IFELSE
IF x IF y DISPLAY a ELSE DISPLAY b 。上記の断片では、 がステートメントではなく ステートメントELSEに関連付けられ、バグが発生します。明示的なスコープ終端記号が導入される前は、これを防ぐには、 を内側の の後に配置する必要がありました。[ 165 ] IFy IFx ELSENEXTSENTENCE IF
オリジナルの (1960 年) COBOL 仕様では、悪名高いステートメントがサポートされていました。このステートメントに対して、多くのコンパイラが自己修正コードを生成していました。とはプロシージャ ラベルであり、このようなステートメントの後に実行されるプロシージャ内の単一のステートメントは、代わりに を意味します。多くのコンパイラは今でもこれをサポートしていますが、[ 166 ] COBOL 1985 標準では廃止されたとみなされ、2002 年に削除されました。 [ 167 ] ALTERXTOPROCEEDTOY XY GOTO XALTER GOTOY
このALTER記述は「コンテキストの局所性」を損ない、プログラム全体の論理を理解しにくくするため、評判が悪かった。[ 168 ]教科書の著者であるダニエル・D・マクラッケンが1976年に書いたように、「これまでプログラムを見たことのない人が、プログラムが失敗したために時間的プレッシャーがかかっている場合もある中で、できるだけ早くプログラムに慣れなければならないとき、段落内に単独でGO TO文があると、プログラム全体にわたって未知の場所に未知の数のALTER文が存在することを示唆するため、最も勇敢なプログラマーの心にも恐怖が走る。」[ 168 ]
COBOLで書かれた「Hello, World!」プログラム：
IDENTIFICATION DIVISION . PROGRAM-ID . hello-world . PROCEDURE DIVISION . DISPLAY "Hello, world!" .1978 年に『C プログラミング言語』に掲載された、今では有名な「Hello, World!」プログラム例が最初に公開されたとき、同様のメインフレーム COBOL プログラム サンプルはJCLを介して送信され、おそらくパンチ カード リーダーと 80 列のパンチ カードが使用されていたでしょう。以下のリストは、空の を含めて、Linux とDATA DIVISIONMVS 3.8Jを実行するSystem/370 Hercules エミュレータを使用してテストされました。2015 年 7 月に作成された JCL は、Jay Moseley がホストする Hercules チュートリアルとサンプルから派生したものです。[ 169 ]当時の COBOL プログラミングに倣い、こんにちは世界すべて大文字で表示されます。
// COBUCLGジョブ( 001 ) 'COBOL ベース テスト' 、// CLASS = A 、MSGCLASS = A 、MSGLEVEL = ( 1、1 )// BASETEST EXEC COBUCLG// COB . SYSIN DD *00000 *ベースCOBOLインストールの検証01000識別課01100プログラムID . 'HELLO' .02000環境課02100設定セクション.02110ソースコンピュータ. GNULINUX .02120オブジェクト-コンピュータ.ヘラクレス.02200特別な名前.02210 コンソールはコンソールです。03000データ部門.04000手順部門.04100 00 -メイン.04110 コンソールに「HELLO, WORLD」を表示します。04900 停止実行。// LKED . SYSLIB DD DSNAME = SYS1 . COBLIB , DISP = SHR// DD DSNAME = SYS1.LINKLIB 、DISP = SHR// GO . SYSPRINT DD SYSOUT = A//JCLを送信した後、MVSコンソールには以下が表示されました。
19:52:48 ジョブ 3 $HASP100 COBUCLG ON READER1 COBOL BASE TEST 19:52:48 ジョブ 3 IEF677I ジョブ COBUCLG の警告メッセージが発行されました 19:52:48 ジョブ 3 $HASP373 COBUCLG 開始 - INIT 1 - CLASS 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 - ステップ名 Procstep プログラム Retcode 19.52.48 ジョブ 3 COBUCLG BASETEST COB IKFCBL00 RC= 0000 19.52.48 ジョブ 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 ジョブ 3 $HASP395 COBUCLG 終了上記のコンソールリストの10行目は、効果を高めるために強調表示されています。強調表示は実際のコンソール出力の一部ではありません。
関連するコンパイラリストは、14行のCOBOLコードから出力されるたった1行に対して、4ページ以上にわたる技術的な詳細情報とジョブ実行情報を生成した。
1970年代には、構造化プログラミングパラダイムの採用がますます広まっていた。著名なコンピュータ科学者であるエドガー・ダイクストラは、 1975年に発行されたCommunications of the ACMの編集者宛ての手紙「私たちはどのように傷つくかもしれない真実を伝えるのか？」の中で、COBOLや他のいくつかの当時の言語を批判し、「COBOLの使用は精神を麻痺させる」と述べている。[ 170 ]
ダイクストラの発言に対する反対意見を公表したコンピュータ科学者のハワード・E・トンプキンスは、非構造化COBOLは「構造化COBOLの適切な指導を受けたことのないプログラマーによって書かれている傾向がある」と主張し、問題は主にトレーニングにあると論じた。[ 171 ]
スパゲッティコードの原因の一つはステートメントでした。しかし、COBOL コードから をGO TO削除しようとすると、プログラムが複雑になり、コードの品質が低下しました。 [ 172 ]は主にステートメントとプロシージャに置き換えられ、モジュール型プログラミングが促進され[ 172 ]、強力なループ機能に簡単にアクセスできるようになりました。しかし、 はプロシージャでのみ使用できたため、ループ本体は使用場所に配置されず、プログラムの理解が難しくなりました。[ 173 ] 1985 年の標準が採用されて以来、 の必要性は動詞の豊富な機能によって完全に消滅しましたが、他の多くの言語と同様に、 は後方互換性のために残っています。GO TOGO TOPERFORMPERFORMGO TOPERFORMGO TO
COBOL プログラムは、モノリシックでモジュール化が不十分であることで悪名高かった。[ 174 ] COBOL コードはプロシージャによってのみモジュール化できたが、CALLプロシージャは大規模システムには不十分であることが判明した。そうでなければ、モジュール化のためにプログラムを個別にコンパイルする必要があった。COBOL-85 標準まではデータへのアクセスを制限することは不可能で、プロシージャは任意のデータ項目にアクセスして変更することができた。さらに、プロシージャにパラメータを渡す方法がなく、ジャン・サメットはこの欠落を委員会の最大の過ちとみなした。[ 175 ]この問題は、モジュール化とローカルに分離されたデータ項目を可能にするネストされたサブルーチンの導入により、COBOL-85 標準で解消された。
もう一つの複雑な問題は、特定の手順のシーケンスを実行できる機能から生じたPERFORM THRU。これは、制御が任意の手順にジャンプしたり、そこから戻ったりできることを意味し、複雑な制御フローを生み出し、プログラマが単一エントリ単一出口のルールを破ることを可能にした。[ 176 ]
COBOLがより多くの機能を採用するにつれて、この状況は改善されました。COBOL-74ではサブルーチンが追加され、プログラマはプログラムの各部分がアクセスできるデータを制御できるようになりました。COBOL-85ではネストされたサブルーチンが追加され、プログラマはサブルーチンを隠すことができるようになりました。[ 177 ]データとコードに対するさらなる制御は、オブジェクト指向プログラミング、ユーザー定義関数、ユーザー定義データ型が組み込まれた2002年に実現しました。[ 178 ]
しかしながら、重要なレガシーCOBOLソフトウェアの多くは非構造化コードを使用しており、事実上保守不可能になっています。コードの単純な部分でさえ変更するのは、未知の場所から未知の方法で使用される可能性があるため、リスクが高くコストもかかりすぎます。[ 179 ]
COBOLは、移植性の高い「共通」言語となることを意図して開発されました。しかし、2001年までに約300もの方言が作成されました。[ 180 ]方言の発生源の一つは標準規格そのものでした。1974年の標準規格は、1つの必須コアと11の機能モジュールで構成され、各モジュールには2つまたは3つのレベルのサポートが含まれていました。これにより、104,976通りのバリエーションが可能になりました。[ 181 ]
COBOL-85は以前のバージョンとの完全な互換性がなく、その開発は物議を醸しました。トラベラーズ保険のCIOであるジョセフ・T・ブロフィーは、COBOLユーザーに新しい標準を導入する際の多大な再プログラミングコストを知らせる取り組みを主導しました。[ 182 ]その結果、ANSI COBOL委員会には一般から2,200通以上の手紙が届き、そのほとんどが否定的なもので、委員会は変更を余儀なくされました。一方で、COBOL-85への移行は将来の生産性を向上させると考えられており、そのため移行コストは正当化されると考えられていました。[ 183 ]
古びたメインフレーム上で退屈で無意味な作業をするために、コードを書く人たちが使う、弱々しく冗長でだらしない言語。[...] その名前を口にすること自体、嫌悪感や恐怖感を込めた儀式的な表現なしにはめったに口にされない。
COBOL構文は冗長であるとして批判されることが多い。支持者は、これはコードの自己文書化を意図したものであり、プログラムの保守を容易にするためだと主張している。[ 185 ] COBOLはまた、プログラマーが簡単に学習して使用できるように意図されており、[ 186 ]マネージャーなどの非技術スタッフにも読みやすいように意図されている。[ 187 ] [ 188 ] [ 189 ] [ 190 ]
読みやすさへの要望から、名詞、動詞、節、文、セクション、区分など、英語のような構文と構造要素が使用されるようになった。しかし、1984 年までに COBOL プログラムの保守担当者は「理解不能な」コードに対処するのに苦労しており[ 189 ]、COBOL-85 の主な変更は保守を容易にするために行われた。[ 95 ]
短期委員会のメンバーであるジャン・サメットは、「プログラマーのニーズに応えようとする試みはほとんど行われておらず、実際、プログラミングを主な関心事とする人々はCOBOLに非常に不満を抱いている傾向がある」と指摘し、その理由としてCOBOLの冗長な構文を挙げた。[ 191 ]
学術界ではCOBOLは冗長で扱いにくく、洗練されていないと見なされがちで、無視されがちですが、実際にはFORTRAN、ALGOL、PL/Iを合わせたよりも多くのCOBOLプログラムとプログラマーが存在すると思われます。ほとんどの場合、COBOLの教育を提供しているのは、直接的な職業訓練を目的とする学校に限られています。
その後、COBOL はそれを解説する資料が不足するようになり、入門書が登場するまで 1963 年までかかりました (リチャード D. アーウィンが COBOL の大学教科書を出版したのは 1966 年です)。[ 193 ] CODASYL COBOL 委員会の委員長であるドナルド ネルソンは 1984 年に、「学者は COBOL を嫌っている」と述べ、コンピュータ サイエンスの卒業生は「COBOL を嫌うように叩き込まれている」と述べています。[ 194 ]
1980年代半ばまでに、ビジネス界では、FORTRANやアセンブラなどの他の言語のユーザーからCOBOLに対するかなりの見下しが見られ、COBOLは難易度の低い問題にしか使えないという考えが広まっていた。[ 195 ]
2003年、COBOLは米国の情報システムカリキュラムの80%に採用されており、 C++やJavaと同じ割合でした。[ 196 ] 10年後、マイクロフォーカスの調査によると、大学教員の20%がCOBOLは時代遅れか廃れており、55%が学生もCOBOLは時代遅れか廃れていると信じていることがわかりました。同じ調査では、COBOLプログラミングをカリキュラムに取り入れている教員はわずか25%で、60%が教えるべきだと考えていることもわかりました。[ 197 ]
標準化委員会の能力について疑問が呈されている。短期間委員を務めたハワード・ブロムバーグは、開発プロセスに対する「統制がほとんどなく」、「人員の断続性と才能の不足に悩まされていた」と述べた。[ 83 ]ジャン・サメットとジェローム・ガーファンケルも、標準化委員会のメンバーの変更と客観的な証拠の両方が原因で、ある改訂版で導入された変更が次の改訂版で元に戻されることを指摘した。[ 198 ]
COBOL 規格は度々遅延に見舞われてきました。COBOL-85 は期待より 5 年遅れて登場し[ 199 ] 、 COBOL 2002 は 5 年遅れ[ 4 ]、COBOL 2014 は 6 年遅れました[ 103 ] [ 200 ] 。遅延に対処するため、標準委員会はオプションのアドエンダの作成を許可し、次の標準改訂を待つよりも早く機能を追加できるようにしました。しかし、一部の委員会メンバーは、実装間の非互換性と標準の頻繁な変更について懸念を表明しました[ 201 ] 。
COBOLのデータ構造は、後続のプログラミング言語に影響を与えた。そのレコードとファイル構造はPL/IとPascalに影響を与え、句はPascalのバリアントレコードの前身となった。明示的なファイル構造の定義はデータベース管理システムREDEFINESの開発に先立ち、集約データはFortranの配列に比べて大きな進歩であった。[ 202 ]
PICTUREデータ宣言は、若干の変更を加えてPL/Iに組み込まれた。
COBOLのCOPY機能は「原始的」と見なされていたが[ 203 ] 、インクルードディレクティブの開発に影響を与えた[ 202 ]。
移植性と標準化に重点を置いたことで、COBOLで書かれたプログラムは移植可能となり、この言語がさまざまなハードウェア プラットフォームやオペレーティングシステムに普及しやすくなった。[ 204 ]さらに、明確に定義された部門構造により、外部参照の定義が環境部門に限定されるため、特にプラットフォームの変更が簡素化される。[ 205 ]
短期委員会は 1959 年 6 月以降、精力的に作業を進めたが、かなり大規模な委員会がプログラミング言語を作成しようとすると、大きな困難が生じた。11 月、短期委員会の委員長は、検討のための仕様を作成するために 6 人を任命した。William Selden と Gertrude Tierney (IBM)、Howard Bromberg と Norman Discount (RCA)、Vernon Reeves と Jean E. Sammet (Sylvania Electric Products)。私たちは 1959 年 11 月に 2 週間 (24 時間体制のセッションも含む) かけて作業し、提案された仕様を短期委員会全体に送付しました。委員会はそれらのほとんどすべてを受け入れました。 (同じ 6 人による) 編集の後、12 月に仕様を最終報告書として執行委員会に提出し、委員会は 1960 年 1 月にそれを受け入れました。 さらに編集した後、政府印刷局は Cobol 60 を発行しました。 [...] [グレース・ホッパー] は、直接委員会のメンバーであるスタッフに一般的な指導を行った以外は、その作業には参加していませんでした。したがって、彼女の間接的な影響は非常に重要でしたが、残念ながら、「グレース・ホッパーが Cobol を開発した」または「グレース・ホッパーは Cobol の共同開発者だった」または「グレース・ホッパーは Cobol の母である」という頻繁に繰り返される記述は全く正しくありません。
オブジェクト指向COBOLのスタイルは、SmalltalkとC++の影響を反映している。
…代替拡張COBOLまたはANSI COBOLへの変換は、可能だとしても非常に困難です。
(Grace Hopper) 「グランマ COBOL」という愛称で呼ばれるこのコードは、彼女の以前の仕事に基づいていた。噂を聞いた後、彼女の協力者の 1 人が花崗岩の墓石を買いに行ったと彼女は言った。「彼は墓石の前面に COBOL という文字を彫り、ペンタゴンのフィリップス氏に速達で着払いで送った」。国防総省でこのプロジェクトのリーダーを務めていたチャールズ・フィリップス氏へのいたずらは、権力者の注目を集め、転換点となったと彼女は言った。COBOL は、歴史上最も広く使われ、最も長く使われているコンピュータ言語になる。
農務省 (USDA)、国土安全保障省 (DHS)、保健福祉省 (HHS)、司法省、財務省、退役軍人省 (VA) など、いくつかの機関が、レガシー システムのプログラミングに、1950 年代後半から 1960 年代前半に開発されたプログラミング言語である共通ビジネス指向言語 (COBOL) を使用していると報告している。各機関が、適切かつ実現可能な範囲で、より近代的で保守しやすい言語に移行する必要があることは広く知られている。
{{cite web}}: CS1メンテナンス: アーカイブサービスは非推奨になりました (リンク)したがって、Y2Kの主な問題は、日付計算を行った際に結果が不正確になる問題です。
ALTER以下で確認できます。 The earliest date that a new COBOL standard could be developed and approved is the year 1980 [...].
a June 2008 revision of the COBOL standard
Micro Focus Visual COBOL delivers the next generation of COBOL development and deployment for Linux x86-64, Linux for System z, AIX, HP/UX, Solaris, and Windows.