忘却された初期化の罠：PL/I `INITIAL` 属性とメモリの深淵
メインフレームの現場で、若いエンジニアから「なぜかバッチの2回目以降の実行で計算結果が狂う」という相談を受けることがある。デバッグログを追うと、特定の変数が前回の実行時の値を保持している。原因は決まって `INITIAL` 属性の解釈の甘さと、自動変数（AUTOMATIC）のメモリ管理に対する誤解だ。
PL/Iの `INITIAL` 属性は、一見するとC言語の初期化のように見えるが、その実態は「宣言時」ではなく「ブロック（PROCEDURE）へのエントリ時」にコードが注入される実行時の代入処理である。この本質を理解していないと、マイグレーション先で「なぜJavaのコンストラクタと挙動が違うのか」と頭を抱えることになる。
1. INITIAL属性とPROCEDUREエントリのメカニズム
PL/Iにおいて、`AUTOMATIC` 変数（デフォルトの記憶クラス）に `INITIAL` を指定した場合、その変数はブロックが呼ばれるたびに初期化される。
/ 典型的なバッチ処理のPROCEDURE例 /
PROC_MAIN: PROC OPTIONS(MAIN);
/ 毎回エントリ時に0で初期化される /
DCL COUNTER FIXED BIN(31) INITIAL(0);
CALL SUB_PROCESS;
CALL SUB_PROCESS; / ここでCOUNTERはどうなっているか？ /
SUB_PROCESS: PROC;
COUNTER = COUNTER + 1;
PUT SKIP LIST(‘COUNTER:’ || COUNTER);
END SUB_PROCESS;
END PROC_MAIN;
この挙動は一見安全に見えるが、システムアーキテクトとして注意すべきは、これがコンパイラによって実行時に生成された代入命令であるという点だ。もし、このプロシージャがCICSなどのオンライン処理で頻繁に呼び出される場合、あるいは大量のレコードをループ処理する中でスタックを消費する場合、無意識の初期化処理がわずかなオーバーヘッドを積み上げ、パフォーマンス劣化を引き起こす。
2. STATICとINITIALの危険な関係
移行現場で最も忌避すべきは、`STATIC` 属性と `INITIAL` を安易に組み合わせることだ。`STATIC` 変数の `INITIAL` は、プログラムロード時に一度だけ評価される。
DCL WORK_AREA CHAR(100) STATIC INITIAL(‘INIT_VAL’);
これが「前回の実行結果を保持してほしい」という意図なら問題ないが、再入可能性（Reentrancy）を損なう要因となる。CICS環境でマルチスレッドに近いタスク実行が行われる際、`STATIC` 変数は全タスクで共有されてしまう。あるタスクが値を書き換えれば、他のタスクにも即座に影響が及ぶ。これが、ダンプを見ても原因が特定しにくい「非決定的なアベンド」の主犯格である。
3. ポインタと動的割り当て（BASED変数）の真実
マイグレーション先のJavaやC#ではガベージコレクションがメモリを管理してくれるが、PL/Iの `BASED` 変数と `ADDR` を使った世界では、すべてがプログラマーの管理下にある。
特に `INITIAL` は `ALLOCATE` 文を実行したタイミングで発動する。
DCL P PTR;
DCL MY_STRUCT BASED(P) CHAR(10) INITIAL(‘READY’);
ALLOCATE MY_STRUCT;
/ このタイミングでメモリが確保され、’READY’がコピーされる /
ここで陥りやすい罠が、パックデシマル（FIXED DECIMAL）の内部表現だ。PL/Iの初期化でパックデシマルを扱う際、コンパイラが生成するビットパターンを意識しないままポインタで直接メモリを操作すると、符号ビット（C/D/Fなど）の破壊を招く。特にメインフレームの `0C7` アベンド（データ例外）の多くは、こうしたメモリ操作の不整合が原因だ。Javaへの移行時に `BigDecimal` に変換する際、この符号ビットの解釈を誤ると、バッチの集計値が1円単位で合わなくなる。
4. アーキテクトへの提言：移行設計の要諦
レガシー移行を成功させる鍵は、PL/Iの「暗黙の挙動」を、新しいプラットフォームで「明示的な設計」に落とし込むことにある。
- 初期化の明確化: `INITIAL` に頼らず、ビジネスロジックの開始時に明示的な `RESET` ロジックを配置することを推奨する。これにより、コードの可読性が向上し、言語依存の挙動から解放される。
- ダンプ解析の視点: もしABENDが発生し、ダンプに意図しない初期値が残っていた場合、それはコンパイラの最適化オプション（`OPT(2)` や `OPT(3)`）によるコード再配置の可能性がある。`LIST` オプションでコンパイラリストを出力し、実際の機械語命令の流れを追う胆力が必要だ。
- 埋め込みSQLとの整合性: DB2のホスト変数として `INITIAL` が設定された変数を使う場合、`FETCH` のたびに値が書き換わることを前提にせよ。初期値が残っているという幻想は、DB2のSQLCA（SQL Communication Area）の戻り値チェックを潜り抜ける致命的なバグを生む。
PL/Iは、ハードウェアの挙動を直接制御できる最後の砦に近い言語だ。`INITIAL` 属性一つをとっても、その背景にはコンパイラ設計者の意図と、効率化という当時の絶対的な制約がある。言語の仕様書をなぞるだけでなく、コンパイラが吐き出す「機械語の裏側」に思いを馳せることが、真のシステムアーキテクトへの道である。
次にコードを追うときは、`INITIAL` が単なる初期値ではなく、CPUが実行する「小さな仕事」であることを忘れないでほしい。それが、複雑怪奇なメインフレーム・システムを解き明かす第一歩となる。
