1. 導入：なぜピリオドではなく「END-CALL」なのか？
COBOLの現場で長年見かける「バグの温床」の一つが、ピリオド（.）の打ち間違いによる制御範囲のミスです。特に外部プログラムを呼び出すCALL文において、ピリオドをどこに打つかによって、ON OVERFLOW句の有効範囲が意図せず変化してしまうことがあります。これを解決し、プログラムの可読性と堅牢性を飛躍的に高めるのが『CALL … END-CALL』による構造化構文です。
2. 基礎知識：範囲終了指定の重要性
COBOLの伝統的な書き方では、文の終わりをピリオドで示します。しかし、複雑な条件分岐の中でピリオドを乱用すると、「どこまでがCALL文の影響範囲なのか」がプログラムの構造上見えにくくなります。
今回解説する『END-CALL』は、CALL文の終わりを明示的に宣言する「範囲終了指定」です。これを使うことで、ON OVERFLOW（呼び出し失敗時の処理）などのオプションが、どのCALLに対応しているのかが明確になり、メンテナンス時の誤解を未然に防ぐことができます。
3. 実装/解決策：論理的なカプセル化
構造化構文を利用する最大のメリットは、CALL文とその後のエラーハンドリングを「一つのブロック」として完全に独立させられる点にあります。これにより、IF文の中にCALL文をネストさせた場合でも、ピリオドの打ち間違いによるロジックの暴走を防ぐことが可能になります。
4. サンプルプログラム
以下のコードは、END-CALLを使って安全にサブルーチンを呼び出す実用的な例です。
IDENTIFICATION DIVISION.
PROGRAM-ID. CALL-SAMPLE.
DATA DIVISION.
WORKING-STORAGE SECTION.
01 WS-ERR-MSG PIC X(20) VALUE “呼び出し失敗”.
PROCEDURE DIVISION.
> 構造化構文により、CALLの範囲を明確にする
CALL “SUBPROG”
ON OVERFLOW
DISPLAY WS-ERR-MSG
PERFORM ERROR-HANDLING-ROUTINE
END-CALL.
DISPLAY “正常に処理が戻りました”.
STOP RUN.
ERROR-HANDLING-ROUTINE.
DISPLAY “システムログを記録します”.
EXIT.
5. 応用・注意点：現場で陥りやすい罠
ベテランとして一つアドバイスしておきます。既存の古いソースコードを改修する際、ピリオドで終わる古い書き方と、END-CALLを使う新しい書き方が混在すると、かえって可読性が下がることがあります。
また、END-CALLを使用する場合、文の途中にピリオドを置かないことが鉄則です。もしEND-CALLの前に誤ってピリオドを打ってしまうと、コンパイラはそこで文が完結したと見なしてしまいます。現代的なCOBOL開発では、可能な限りピリオドを文末以外で使わない「構造化コーディング」をチーム全体で徹底することをお勧めします。これだけで、デバッグの時間は確実に短縮されますよ。
コメント