現場で遭遇する「ENTRYステートメント」の深淵：複数エントリーポイントの正しい作法
現場の保守・開発に携わっていると、古参のPL/Iコードに遭遇し、思わず頭を抱える瞬間があるだろう。「なぜ一つの手続きの中に、ENTRYがいくつも散らばっているんだ？」と。
現代のソフトウェア設計から見れば、単一責任の原則に反するように見えるかもしれない。しかし、メインフレームの限られたメモリリソースの中で、共通の静的変数（STATIC）や初期化済みデータ構造を共有しつつ、処理の入り口を使い分けたいというニーズは、今も昔も変わらない。
今日は、そんな「ENTRYステートメント」の正当な使い方と、そこで避けては通れない「引数整合性」の罠について、実務の視点から解説する。
—
1. ENTRYステートメントの基本と「共有の魔力」
PL/Iにおいて、一つの`PROCEDURE`内に複数のエントリーポイントを定義する場合、`ENTRY`ステートメントを使用する。これは、プログラムの特定箇所から処理を開始しつつ、同じスタックフレームや変数のスコープを共有できるという強力な機能だ。
実践的なコード例：VSAMファイル更新と照会の一元管理
例えば、VSAMファイルに対して「単一レコードの読み込み」と「全件更新」という二つの顔を持つモジュールを想定してみよう。
1
/ VSAMレコード操作ユーティリティ /
VSAM_OPS: PROCEDURE OPTIONS(MAIN);
/ 共通変数の定義 /
DCL VSAM_FILE FILE RECORD ENV(VSAM KEYED);
DCL 1 REC_AREA,
5 KEY_FLD CHAR(10),
5 DATA_FLD CHAR(50);
/ — メインエントリー — /
/ 通常のメイン処理 /
OPEN FILE(VSAM_FILE);
/ … 処理 … /
CLOSE FILE(VSAM_FILE);
RETURN;
/ — 別エントリー：単一レコード取得 — /
GET_REC: ENTRY(P_KEY, P_DATA);
DCL P_KEY CHAR(10);
DCL P_DATA CHAR(50);
READ FILE(VSAM_FILE) INTO(REC_AREA) KEY(P_KEY);
P_DATA = DATA_FLD;
RETURN;
/ — ONユニットによる例外制御 — /
ON ENDFILE(VSAM_FILE) BEGIN;
PUT SKIP LIST(‘EOF REACHED’);
END;
END VSAM_OPS;
このように、`GET_REC`エントリーを設けることで、呼び出し元は`CALL GET_REC(K, D)`とするだけで、内部で定義された`VSAM_FILE`や`REC_AREA`をそのまま活用できる。これがPL/Iが持つ「手続きの柔軟性」だ。
—
2. 引数リストの整合性チェックという「落とし穴」
ここで最も注意すべきは、「呼び出し元と受け手で引数の属性（データ型・長さ）が一致しているか」という点だ。
PL/Iコンパイラは、別コンパイル単位（外部モジュール）からの呼び出しの場合、暗黙の型変換を行おうとする。これが曲者だ。もし呼び出し元が`CHAR(8)`を渡しているのに、ENTRY側で`CHAR(10)`を期待していれば、メモリ上の隣接データまで読み込んでしまう可能性がある。
実務での防衛策
1. INCLUDEメンバによる宣言の共通化:
`DECLARE`文を個別に書かず、必ず`COPY`（または`INCLUDE`）を使用して、呼び出し元と受け手で全く同じ属性定義を持つヘッダーファイルを共有すること。
2. BUILTIN関数の活用:
引数の境界チェックが不安な場合は、`ADDR()`や`LENGTH()`組み込み関数を駆使して、メモリ上の位置を明示的に制御する設計も検討しよう。
—
3. 制御フローとONユニットの「落とし穴」
ENTRYステートメントを使用する際、最も設計者が悩むのが`ON`ユニットの有効範囲だ。
`ENTRY`から入ったとしても、`ON`ユニットは基本的にその`PROCEDURE`ブロック全体で有効になる。もし、メインエントリーと`ENTRY`した先で、ファイルエラーの処理方法（リトライ回数やエラーログの出力形式）を分けたい場合は、`BEGIN; … END;`ブロックでスコープを限定するか、フラグ変数を用いて`ON`ユニット内で分岐させる必要がある。
ベテランからのアドバイス:
「とりあえずONユニットをメインの頭に書いておけ」というのは初心者の思考だ。複雑なENTRYを持つプログラムでは、特定の処理ブロック内でのみ有効なONユニットを記述する癖をつけよう。そうすれば、予期せぬ場所でエラーハンドリングが発火するバグを未然に防げる。
—
最後に：なぜ今、この知識が必要なのか
マイグレーション案件で、「このレガシーコードをJavaに書き換えてくれ」と依頼されたとき、ENTRYステートメントをどう解釈するかで腕の差が出る。
ENTRYステートメントは、単なる古い構文ではない。「どのデータがどこで共有されているか」という、モジュールの密結合を可視化する鏡なのだ。これを理解せずにリファクタリングを始めれば、必ずどこかでデータの不整合（データ化け）という悪夢を見ることになる。
もし現場で不可解なENTRYを見つけたら、「なぜ当時の設計者はここに共通性を見出したのか？」と背景を想像してみてほしい。その答えが、次のシステムアーキテクチャへのヒントになるはずだ。
困ったことがあれば、いつでもまた相談してくれ。メインフレームの深淵は、まだまだ奥が深い。
コメント