PL/Iの「ENTRY宣言」を制する者が、レガシー移行の聖域へ到達する
メインフレームの心臓部で数十年動き続けるPL/Iプログラム。その保守やJava/C#への移行に携わる際、最も「バグの温床」となりやすいのが、別コンパイル単位（モジュール）を呼び出す際のインターフェース不整合です。
PL/Iのコンパイラは強力ですが、リンク時（LNKEDIT）には型チェックが緩くなるという、現代の言語にはない特有の「罠」があります。今日は、`ENTRY`属性による厳密な型定義と、移行プロジェクトで必ず直面する境界問題について、アーキテクトの視点から紐解いていきましょう。
—
1. なぜ「ENTRY宣言」を疎かにしてはいけないのか
多くの現場で、「とりあえず`CALL SUB_A;`で動くからいいや」と放置されたコードを見かけます。しかし、宣言なしで呼び出すと、コンパイラは引数が何であるかを推測（デフォルト属性）に頼ることになります。これが後々、パックデシマル(FIXED DECIMAL)の桁数不一致による異常終了や、アドレスの不整合によるS0C4アベンドを引き起こす引き金となります。
以下のコード例を見てください。これが我々が推奨する「防衛的コーディング」の基本形です。
1
/ 外部プログラムを明示的に定義する /
DCL SUB_PROG ENTRY (
FIXED BIN(31,0), / 第1引数: 32bit整数 /
CHAR(10), / 第2引数: 固定長文字列 /
PTR / 第3引数: 動的メモリへのポインタ /
) OPTIONS(ASSEMBLER); / CICSやAssembler混在時はLINKAGEを意識せよ /
/ 呼び出し側 /
DCL MY_PTR PTR;
DCL MY_DATA CHAR(10) INIT(‘TEST_VAL’);
DCL MY_CNT FIXED BIN(31,0) INIT(1);
/ ポインタ経由のメモリ操作は、ベース変数を活用する /
/ 構造体のアドレスをセットし、動的にマッピングする /
CALL SUB_PROG(MY_CNT, MY_DATA, MY_PTR);
2. 移行スペシャリストが震える「パックデシマル」の罠
Javaへの移行時、最も頭を抱えるのがPL/I特有の`FIXED DECIMAL`です。PL/Iは内部的にパックデシマル形式（1バイトに2桁、最後の4ビットに符号）で保持します。
もし、呼び出し先が宣言と異なる型（例えば`FIXED BIN`を期待しているのに`FIXED DEC`を渡した）であれば、データがレジスタ上でどう解釈されるか。最悪の場合、符号ビットが誤認され、計算結果が正負反転する、あるいは極めて大きな数値に化けるといった、ダンプを読まないと絶対に辿り着けないバグを生みます。
実務的アドバイス:
移行設計において、全ての外部呼び出しには`INCLUDE`ファイルで共通化された`DECLARE`文を強制してください。各モジュールに場当たり的な宣言を書かせない。これが、数千万行規模のシステムをマイグレーションする際の「正攻法」です。
3. ポインタとベース変数：現代的言語への橋渡し
ポインタ操作はPL/Iの醍醐味ですが、JavaやC#には「生のメモリ番地」という概念がありません。
1
/ ベース変数を用いた動的メモリ操作 /
DCL 1 MY_STRUCT BASED(PTR_VAR),
3 FIELD_A FIXED DEC(5),
3 FIELD_B CHAR(20);
/ メモリ確保 /
ALLOCATE MY_STRUCT;
/ この構造体全体を他プログラムへ渡す際、ポインタ渡しは必須 /
/ Java移行時は、ここをDTO（Data Transfer Object）へのマッピングに置き換える /
この「ポインタ渡し」をいかにオブジェクトに変換するか。移行プロジェクトにおいては、`CALL`の引数を一度インターフェース用の構造体にコピーし、それをJSONやシリアライズ可能な形式に変換する「アダプター層」を設ける設計が不可欠です。
4. アベンド（ABEND）解析という名の「深淵」
もし、あなたがS0C7（データ例外）やS0C4（プロテクション例外）を吐くプログラムと対峙しているなら、迷わずコンパイラリストの`OFFSET`を確認してください。
- コンパイラオプションの重要性: `LIST`, `MAP`, `OFFSET`を付与してコンパイルし、コンパイラリストを生成すること。これがない状態でダンプを見るのは、地図なしで密林を歩くのと同じです。
- DB2埋め込みSQL: SQLCODEのチェックを怠ると、予期せぬNULL値が入り込み、PL/I側の構造体との不整合でアベンドします。必ず`WHENEVER SQLERROR`を適切に配置し、エラーハンドリングをルーチン化しておくこと。
最後に：技術的負債を「技術的資産」へ
PL/IからJava/C#への移行は、単なる言語変換ではありません。「物理メモリの制約と戦ってきた時代のロジック」を「オブジェクト指向の抽象化」へと昇華させる作業です。
ENTRY宣言でインターフェースを厳格化することは、今のシステムを守るだけでなく、未来の移行を確実にするための「投資」です。泥臭いダンプ解析や、型定義との格闘こそが、真のシステムアーキテクトを形作ります。
もし、現場で「動けばいい」という空気が流れたら、この記事のことを思い出してください。PL/Iの厳密さは、あなたのコードを守る最強の盾なのです。
