1. 導入：なぜ「終わり」を意識するのか
ベテランの現場では、コンパイラが自動的に判断してくれるからと「終わり」を曖昧にしているソースコードをよく見かけます。しかし、Procedure Divisionの終端を適切に制御することは、単にコンパイルを通すためだけのものではありません。プログラムの物理的な境界を明確にすることは、他者による誤ったコード追記を防ぎ、大規模なバッチ処理において「どこまでがこのモジュールの責任範囲か」をコンパイラと開発者の双方に正しく伝えるための重要な作法です。
2. 基礎知識：手続き部のスコープとEND PROGRAM文
COBOLのProcedure Divisionは、プログラムの処理ロジックを記述する領域です。この領域は「物理的なファイルの末尾」まで、あるいは「END PROGRAM文」が登場するまで続きます。
特に現代のCOBOL開発では、1つのソースファイル内に複数のプログラムを記述する「入れ子（ネスト）構造」や、モジュール分割を前提とした構成が一般的です。ここでEND PROGRAM文を明示的に記述しないと、どの範囲がどのプログラムに属するのかが読み手にとって不明瞭になり、意図しないスコープの拡大によるバグを誘発する原因となります。
3. 実装/解決策：END PROGRAMを習慣化する
解決策はシンプルです。プログラムの最後には必ず「END PROGRAM プログラム名.」を記述すること。これにより、コンパイラに対してプログラムの終端を明確に宣言できます。また、入れ子プログラムを使用する場合は、内側のプログラムから順にEND PROGRAMを閉じることで、構造的な整合性を保つことが可能です。
4. サンプルプログラム
以下は、保守性を考慮した標準的な構造です。そのままコピー＆ペーストして、各環境のコンパイラで検証してください。
IDENTIFICATION DIVISION.
PROGRAM-ID. SAMPLE01.
PROCEDURE DIVISION.
MAIN-LOGIC.
- メイン処理の開始
DISPLAY “プログラムを開始します。”
PERFORM SUB-ROUTINE
DISPLAY “プログラムを正常終了します。”
GOBACK.
SUB-ROUTINE.
- サブルーチン処理
DISPLAY “サブルーチンを実行中…”.
- ここにEND PROGRAMを記述することで、
- プログラムの終わりが明確になり、誤編集を防ぎます
END PROGRAM SAMPLE01.
5. 応用・注意点：現場で陥りやすい罠
現場で注意すべきは「コンパイルエラーにはならないが、バグの温床になるケース」です。例えば、END PROGRAMの後に誤って不要な記述を残してしまった場合、コンパイラによってはそれを「後続のプログラム」と誤認し、予期せぬリンクエラーを引き起こすことがあります。
また、古いCOBOL規格の資産を扱う際は、END PROGRAM句がサポートされていないコンパイラが存在する場合もあります。その際は、コメント行で「 END OF PROGRAM 」のように視覚的に境界を明示するのもベテランの知恵です。常に「次にこのコードを読む人のために境界を定義する」という意識を持ってコーディングに臨んでください。それが結果として、あなたのコードの品質を一段と高めることになります。
コメント