INITIAL属性の深淵：メモリのライフサイクルと「予期せぬ初期化」の罠
メインフレームの現場で何十年と稼働し続けるPL/Iプログラム。そのコードの端々には、現代の言語設計者が忘れてしまった「メモリに対する厳格な規律」が刻まれています。
今日は、若手エンジニアが移行の過程で必ずと言っていいほど躓く、`INITIAL`属性と変数のライフサイクルについて深く掘り下げてみます。単なる初期値の設定と侮るなかれ。この挙動の理解こそが、アベンド（ABEND）を未然に防ぐ最後の砦です。
—
1. 静的(STATIC)と自動(AUTOMATIC)の境界線
PL/Iにおいて、変数がいつ「誕生」し、いつ「初期化」されるのか。このタイミングを把握していないと、CICSやバッチ処理で致命的なバグを埋め込むことになります。
STATIC変数：コンパイル時の「固定客」
`STATIC`属性を持つ変数は、プログラムのロード時に一度だけメモリ領域が確保され、初期化されます。
/i
DCL COUNTER FIXED BIN(31) STATIC INITIAL(0);
この`COUNTER`は、プログラムがロードされた時点でデータ領域に配置されます。注意すべきは、複数回呼び出されるサブルーチン内でのSTATIC変数です。一度値を更新すると、次回呼び出し時にもその値が保持されます。移行先のJava等でインスタンス変数と混同しやすいポイントですが、PL/Iにおいては「プログラム単位のグローバル変数」として振る舞うため、再入可能性（Reentrancy）を損なう原因となります。
AUTOMATIC変数：プロシージャ毎の「使い捨て」
デフォルトである`AUTOMATIC`は、`PROCEDURE`が呼び出されるたびにスタック上でメモリが確保され、初期化されます。
/i
PROCEDURE_A: PROC;
DCL WORK_AREA CHAR(10) INITIAL(‘INITIAL’); / プロシージャ開始毎に再初期化 /
…
END PROCEDURE_A;
ここでのポイントは、コンパイラの最適化オプションです。最適化レベルを上げると、未使用の変数や初期化が不要と判断された領域のロード処理が省略されることがあります。ダンプ解析を行う際、「ソースコード上は初期化しているのに、ダンプ上ではゴミが入っている」という事象が発生した場合、それはコンパイラの最適化によるメモリ再利用が疑われます。
—
2. 動的メモリ（BASED変数）とALLOCATEの魔術
ポインタと`BASED`変数を用いた動的メモリ操作において、`INITIAL`属性は「アロケーション時」にのみ評価されます。
/i
DCL PTR POINTER;
DCL MY_DATA CHAR(8) BASED(PTR) INITIAL(‘READY’);
ALLOCATE MY_DATA; / この瞬間にメモリが確保され、’READY’が書き込まれる /
移行設計において最も恐ろしいのは、ポインタの解放漏れと再確保です。`FREE`命令を実行してもメモリの内容が即座にゼロクリアされるわけではありません。次に`ALLOCATE`した際、初期化を忘れると、前回の処理の残骸がそのまま残ります。これがパックデシマル（`FIXED DEC`）の変数であれば、内部表現の誤りによるS0C7アベンドの引き金となります。
—
3. 実務で直面するエッジケースと対策
パックデシマルの符号反転バグ
外部システム（Java側）から送られてきたデータが、PL/Iの内部形式（特にパックデシマル）の符号ニブル（`C`や`D`、`F`など）と適合せず、演算時にアベンドすることがあります。
`INITIAL`属性で安全な値をセットしていても、外部から`READ`や`SQL FETCH`で領域を上書きする際、物理的なデータ破壊が起きると初期化の意味を成しません。
対策:
構造体（`LEVEL 1`）全体を`UNSPEC`関数や`PLIFILL`等の組み込み関数で初期化し、メモリレイアウトを強制的に正常化する手法を推奨します。
CICS環境での注意点
CICSオンライン処理では、プログラムがタスク終了までメモリを保持し続ける場合があります。`STATIC`変数にタスク間の共有データを不用意に置くと、データの競合が発生します。CICSでの開発では、`INITIAL`属性は最小限に留め、`DFHGETMAIN`等で取得した領域を明示的に`INIT`する癖をつけてください。
—
アーキテクトからの提言
PL/IからJavaやC#への移行を行う際、単に「初期化処理をコンストラクタに移す」だけでは不十分です。PL/Iの`INITIAL`は、宣言と同時に「その変数の状態を確定させる」という強い意図を持っています。
- ダンプ解析のヒント: アベンドが発生した際、変数が`INITIAL`で期待した値になっているかを確認してください。もし期待値と異なれば、それはメモリ破壊か、あるいは意図しないプロシージャの再突入が原因です。
- 移行の極意: 既存の`INITIAL`値を、移行先の言語の「デフォルト値」として定義するのではなく、ビジネスロジックの開始地点における「状態の整合性チェック」として再定義してください。
基幹システムのコードは、単なる命令の羅列ではありません。数万行の歴史が、メモリ上のビット単位で精密に制御されています。その複雑さを「レガシー」として切り捨てるのではなく、構造的な美しさと捉え、次世代のシステムへと昇華させること。それこそが、我々メインフレーム・アーキテクトの使命です。
次回の技術ブログでは、「ON条件とエラーハンドリングの再構築」について、実戦的な実装パターンを紐解いていきます。ご期待ください。
