迷宮の入り口：PL/Iにおける複数エントリーポイント（ENTRY）の深淵
メインフレームのコードベースを紐解くと、時折、単一の`PROCEDURE`の中に複数の`ENTRY`が定義された、一見すると「スパゲッティの温床」のような構造に出くわすことがある。現代のオブジェクト指向言語から来たアーキテクトには異様に映るかもしれないが、これはかつてメモリが極めて高価だった時代、モジュールサイズを削り、共通のスタティックストレージを共有するための、極めて合理的で、かつ危険な設計パターンだ。
今回は、この`ENTRY`ステートメントが持つ魔力と、それが現代のマイグレーションプロジェクトにおいてどのような地雷となり得るのかを、現場の視点から掘り下げてみたい。
1. ENTRYステートメントの構造と「共有される運命」
PL/Iにおける`ENTRY`は、単なる関数のオーバーロードではない。それは、一つのプロシージャ内に複数の「入り口」を設け、共通のスコープ（自動変数やスタティック変数）を共有する仕組みだ。
/i
MAIN_PROC: PROCEDURE(IN_DATA) OPTIONS(MAIN);
DCL IN_DATA CHAR(10);
DCL WORK_AREA FIXED BIN(31) STATIC; / 全エントリーで共有される /
/ メインエントリー /
/ … 処理 … /
RETURN;
/ 別途定義されたエントリーポイント /
SUB_ENTRY: ENTRY(IN_VAL);
DCL IN_VAL FIXED BIN(31);
WORK_AREA = IN_VAL 2;
/ ここでアベンドした場合、メインのスタックフレームが汚染される /
RETURN;
END MAIN_PROC;
この構造の最大の落とし穴は、「どのエントリーから入っても、呼び出し側のスタックフレームを共有し、変数の生存範囲（Extent）がプロシージャ全体に及ぶ」という点にある。Javaのメソッドのように独立したスコープを持っていないため、一方のエントリーで発生したポインタのオフセットミスが、もう一方のエントリーの変数に致命的な影響を与える。
2. 引数リストの整合性チェックと「暗黙の型変換」の罠
マイグレーション時に最も恐ろしいのは、呼び出し側のプログラムが、この`ENTRY`の引数構成を正しく理解していないケースだ。特に`FIXED DEC`（パックデシマル）を渡す際、コンパイラが「暗黙の型変換」を行い、内部符号（0xC/0xD）が期待通りに解釈されず、`S0C7`アベンド（データ例外）を叩き出すことは日常茶飯事である。
- 対策: `PROCEDURE`の先頭には、必ず`PROCEDURE`と`ENTRY`のインターフェースを定義したヘッダファイル（COPY句）を強制適用せよ。
- 動的メモリ操作: `BASED`変数と`ADDR`関数を駆使している場合、`ENTRY`境界を跨いでポインタを渡すと、コンパイラが最適化レベル（`OPTIMIZE(2)`以上）でポインタをキャッシュし、スタックの状態と不整合を起こすことがある。この場合、該当変数を`VOLATILE`属性で修飾し、コンパイラの過度な最適化を抑止するのが定石だ。
3. CICS/DB2環境におけるエッジケース：アベンド解析の勘所
もし君が担当しているシステムがCICSオンライン環境下であれば、`ENTRY`を使った再入不可（Non-reentrant）なコードは即座に排除対象だ。
CICSのタスクは擬似再入可能であることを要求される。`ENTRY`を使用して静的メモリ（`STATIC`）を多用するコードは、マルチタスク環境下で他タスクのデータを破壊する。
ダンプ解析のヒント:
`CEE3DMP`等でダンプを確認する際、`ENTRY`から呼び出された処理で異常終了した場合は、スタックトレース上の「オフセット」を注意深く見ろ。PL/Iコンパイラが生成するプロローグコードは、エントリーポイントごとにスタックポインタを調整する。アベンド発生時のレジスタR13が指すSAVE AREAが、どの`ENTRY`のものかを特定できなければ、原因の9割は見失っているに等しい。
4. マイグレーションへの提言
もし、この複雑怪奇な`ENTRY`構造を持つコードをJava等のモダン言語へ移行しようとしているなら、以下の指針を胸に刻んでほしい。
1. ロジックの分離: `ENTRY`を個別のクラスまたはメソッドに分解する際、共有されている`STATIC`変数を「共通のステートオブジェクト」として切り出せ。
2. 型安全性の確保: パックデシマル（`PIC S9(7)V99`など）を`BigDecimal`へ変換する際は、必ず符号の正規化処理を挟むこと。メインフレーム固有の符号表現は、モダンなライブラリが想定する値と異なるケースがある。
3. テスト駆動の限界: 既存のPL/I挙動をブラックボックスとしてテストし、移行後と比較する際、`ENTRY`ごとの呼び出しパターンを網羅しなければ、必ずと言っていいほど「隠れた副作用」が本番環境で露見する。
最後に
PL/Iの`ENTRY`ステートメントは、メインフレームの「限られた資源を限界まで使い倒す」という美学の結晶だ。しかし、その柔軟性は、現代の堅牢なシステム設計においては負債となり得る。
コードを書き換える際は、単に言語を変換するのではない。その裏にある「なぜ当時のアーキテクトがその設計を選んだのか」という文脈を読み解き、現代のハードウェアとソフトウェアの恩恵を受けられる形に再構築すること。それこそが、我々レガシー移行スペシャリストが果たすべき真の役割なのだ。
君の移行プロジェクトに、安定したパッチと、静かな本番稼働があらんことを。
コメント