なぜ「ENTRY宣言」をサボるのか？ ― 30年目のバッチが語る、型安全と悪夢のデバッグ
やあ、今日もメインフレームの保守お疲れ様。
最近、若手から「PL/Iって古臭いけれど、なんでこんなに細かく宣言を書かなきゃいけないんですか？」と聞かれることがある。その答えはシンプルだ。「沈黙するエラー」ほど、この世界で恐ろしいものはないからだよ。
特に、外部プロシージャを呼び出す際の`ENTRY`属性の宣言。これをいい加減にしていると、テスト環境ではたまたま動いていたものが、本番の深夜バッチでメモリを破壊し、原因不明の異常終了（S0C4やS0C7）を招くことになる。今回は、実務の現場で生き残るための「ENTRY宣言の流儀」について話そう。
—
ENTRY宣言は、コンパイラとの「契約」である
PL/Iは、コンパイル時に引数の整合性をチェックできる強力な言語だ。しかし、呼び出し側（Caller）で`ENTRY`宣言を省略したり、引数の属性を適当に書いたりすると、コンパイラは「たぶんこれで合っているだろう」と甘い判断を下す。
結果どうなるか？ 実行時にリンケージ規約が破綻し、データ領域のオーバーライトが発生する。特にVSAMファイルを扱うような基幹バッチでこれをやると、データセットの破損という最悪の事態になりかねない。
実践：正しいENTRY宣言の書き方
以下に、外部プロシージャを安全に呼び出すためのテンプレートを示す。
/i
/ 外部サブプロシージャの呼び出し例 /
MY_PROC: PROCEDURE OPTIONS(MAIN);
/ 1. ENTRY宣言：引数の型と属性を厳密に定義する /
/ 指定された引数が期待値と違う場合、コンパイル時に警告が出る /
DCL PROC_CALC_TOTAL ENTRY(FIXED BIN(31), CHAR(10), FIXED DEC(15,2));
DCL W_COUNT FIXED BIN(31) INIT(100);
DCL W_KEY CHAR(10) INIT(‘A001’);
DCL W_RESULT FIXED DEC(15,2);
/ 2. 組み込み関数を活用し、初期化は徹底的に /
ON ERROR BEGIN;
PUT SKIP LIST(‘予期せぬエラー発生。ダンプを確認せよ’);
SIGNAL FINISH;
END;
/ 呼び出し /
CALL PROC_CALC_TOTAL(W_COUNT, W_KEY, W_RESULT);
PUT SKIP LIST(‘計算結果:’, W_RESULT);
END MY_PROC;
—
なぜ「ENTRY」を省略してはいけないのか
もし`DCL … ENTRY(…)`を省略して呼び出すと、コンパイラは呼び出し側の引数から属性を推測する。しかし、もし呼び出し側と被呼び出し側の属性（例えば`FIXED BIN(31)`と`FIXED BIN(15)`の違いなど）が食い違っていたらどうなるか？
- コンパイル時: 何の警告も出ない。平和そのものだ。
- 実行時: 呼び出し側は32ビット分をスタックに積んだつもりでも、受け取り側は16ビット分しか読み込まない。結果、スタックのポインタがズレて、後続の変数がゴミ値に書き換わる。
この「ゴミ値」が、何時間も経ったあとの計算処理でS0C7（データ例外）を発生させる。デバッガを何時間回しても原因が掴めない、あの地獄のようなデバッグ体験をしたくなければ、宣言は必ず書くことだ。
—
現場で役立つ「鉄則」
1. INCLUDEファイル（コピーブック）の活用:
ENTRY宣言をソースコードにベタ書きするのは避けろ。共通のCOPYライブラリにENTRY宣言を格納し、それを`%INCLUDE`で読み込むのがプロの流儀だ。修正が必要なときに、全ソースを書き換えるなんてナンセンスだろう？
2. VSAMアクセスとONユニット:
VSAMのファイル操作を行う際、`ON ENDFILE`や`ON KEY`を適切に定義していないコードをよく見かける。`ENTRY`経由で渡したデータが不正だと、VSAMのI/Oモジュールが例外を投げる。その際、スタックトレースが破壊されていると、どこで落ちたのかすら追えなくなる。
3. OPTIONS(MAIN)の責務:
`OPTIONS(MAIN)`がついているメインプログラムは、いわばシステムの玄関だ。ここでの型定義が甘いと、下位のサブルーチンすべてにその甘さが伝播する。
—
結びに：コードは「対話」である
PL/Iという言語は、書き手に対して非常に正直だ。こちらが厳格に書けば、コンパイラは最強の守護者となり、こちらが怠慢になれば、容赦なく実行時の落とし穴を掘る。
後輩たちよ、ENTRY宣言を面倒だと感じるのは最初のうちだけだ。大規模な改修プロジェクトで、何万行ものコードを相手にする時、この「宣言の正確さ」だけが君たちの命綱になる。
もし、今君が保守しているシステムでENTRY宣言が欠落しているコードを見つけたら、それは「時限爆弾」だと思っていい。次回の改修機会に、一つずつ丁寧に取り除いていこう。それこそが、ベテラン・アーキテクトの仕事だよ。
さて、コーヒーでも飲んで、次のバッチ処理のチューニングに取り掛かるとしようか。何か詰まったら、いつでも聞きに来なさい。
