メインフレームの心臓部を握る「STORAGE属性」の真実
長年、金融や流通の基幹システムを支えてきたIBMメインフレームの心臓部であるPL/I。C言語やJavaしか知らない現代のエンジニアが、この世界に足を踏み入れて最初に直面し、そして密かに絶望するのは、ポインタや構造体のメモリレイアウトの厳密さではない。むしろ、言語仕様の根底にある「変数の生存期間と記憶クラス」の制御、すなわち `STORAGE` 属性の魔力である。
PL/Iの歴史は古く、その設計思想は「プログラマがハードウェアの挙動を完全に支配する」ことにある。特に `AUTOMATIC` と `STATIC` という2つのデフォルトストレージクラスの挙動、そしてそれらがスタック領域と静的領域のどこにどう配置され、再帰呼び出し（RECURSIVE）やCICSのタスク共用、果てはDB2の埋め込みSQLとどう絡み合うかを理解していないと、本番稼働後の夜間バッチで突如として発生する「原因不明のS0C4アベンド」や「サイレントデータ破損」の前に立ち尽くすことになる。
今回は、PL/Iにおける `AUTOMATIC` と `STATIC` のメモリ配置のメカニズムを解き明かし、マイグレーションやモダン化の現場で絶対に踏んではならない地雷について、アーキテクトの視点から深く掘り下げていこう。
—
1. スタック領域 vs 静的領域：メモリ配置の根本的な違い
PL/Iにおけるストレージクラスの指定は、単なる「変数のスコープ」の定義ではない。それは、MVS/ESA（あるいはz/OS）のアドレス空間における、どのセクションにメモリが割り当てられ、いつ解放されるかをコンパイラに命令する極めてハードウェア寄りの指示である。
STATIC（静的領域）の正体
`STATIC` 属性を持つ変数は、プログラムのロード時（正確にはタスクの初期化時）に、仮想記憶の静的データ領域（通常はセクション内のSD/EDエリア）に一度だけ割り当てられる。
- 生存期間: プログラムの実行開始から終了まで永続する。
- 初期化: 宣言時に指定した `INITIAL` 値は、プログラムの初回ロード時に一度だけ評価され、書き込まれる。2回目以降のプログラムの呼び出し（再入可能性 `REENTRANT` を考慮しない古い設計など）では、前回の実行時の値がそのまま残るという、現代のJavaプログラマから見れば悪夢のような挙動を示す。
AUTOMATIC（スタック領域）の正体
PL/Iにおけるデフォルトのストレージクラスであり、ブロック（PROCEDUREやBEGIN-ENDブロック）が活性化（Activation）されるたびに、タスクのスタック領域（SAVEAREAの延伸部分や専用のスタックフレーム）に動的に積み上げられる。
- 生存期間: ブロックの実行中のみ。ブロックを抜けると、スタックポインタが巻き戻され、メモリ領域は容赦なく破棄（あるいは別のデータで上書き）される。
- 初期化: ブロックに入るたびに、`INITIAL` 値が評価され再設定される。
ここで注意すべきは、PL/Iコンパイラ（Enterprise PL/Iなど）の最適化レベル（`OPT(2)` や `OPT(3)`）において、`AUTOMATIC` 変数は汎用レジスタ（R3〜R12など）に直接割り付けられる（Register Allocation）ことがある点だ。メモリ上にすら存在せず、CPUのレジスタ上で完結することもある。
—
2. 再帰呼び出し（RECURSIVE）とAUTOMATICの挙動
基幹システムの勘定計算や複雑な部品展開ロジックにおいて、再帰呼び出し（`RECURSIVE`）は避けられない手法である。ここで `STATIC` と `AUTOMATIC` の挙動の違いが生死を分ける。
以下のコードを見てほしい。勘定科目の階層を再帰的に走査するバッチプログラムの一部である。
CALC_TREE: PROC(P_ACCOUNT_ID) RECURSIVE OPTIONS(MAIN);
DCL P_ACCOUNT_ID CHAR(10) PARM;
/ 誤った実装：STATIC変数による再帰処理 /
DCL W_STATIC_TOTAL FIXED DEC(15,2) STATIC INIT(0);
/ 正しい実装：AUTOMATIC変数による再帰処理 /
DCL W_AUTO_TOTAL FIXED DEC(15,2) AUTOMATIC INIT(0);
DCL DB_STATUS CHAR(2);
/ — 処理ロジックの模擬 — /
W_AUTO_TOTAL = W_AUTO_TOTAL + 100.00;
W_STATIC_TOTAL = W_STATIC_TOTAL + 100.00;
IF HAS_CHILDREN(P_ACCOUNT_ID) THEN DO;
/ 再帰呼び出し /
CALL CALC_TREE(GET_NEXT_CHILD(P_ACCOUNT_ID));
END;
DISPLAY(‘AUTO_TOTAL : ‘ || W_AUTO_TOTAL);
DISPLAY(‘STATIC_TOTAL: ‘ || W_STATIC_TOTAL);
RETURN;
END CALC_TREE;
アーキテクトの眼：このコードの何が危険か？
`W_STATIC_TOTAL` は `STATIC` で宣言されているため、プログラム全体でたった一つのインスタンスしか存在しない。再帰呼び出しによって `CALC_TREE` が何段深く潜ろうとも、すべての階層のフレームが同じメモリ領域を指し示し、互いの値を上書きし合う。結果として、計算結果は完全に破壊され、予測不可能なバグ（データ汚染）を引き起こす。
一方、`W_AUTO_TOTAL` は `AUTOMATIC` であるため、再帰呼び出しが発生するたびに、新しいスタックフレーム上に新しいインスタンスが確保される。上位の階層の変数は、下位の呼び出しから完全に保護される。
再帰を使用するプログラム、あるいはCICS環境下でマルチスレッド的に呼び出されるサブプログラムでは、変数のデフォルトを過信せず、意図的に `AUTOMATIC` を明示する、あるいは `STATIC` の使用を厳しく制限するコードレビューの規し方が不可欠である。
—
3. 現場で遭遇するエッジケースとトラブルシューティング
長年運用されたメインフレームシステムの保守や、Java/C#へのマイグレーションプロジェクトにおいて、私たちが直面する具体的なトラブルとその対策を挙げる。
① パックデシマルの内部符号反転バグとスタック汚染
PL/Iの `FIXED DECIMAL`（パック10進数、COMP-3）は、メインフレームのハードウェア命令に直結しているため非常に高速だが、ストレージの境界やポインタ操作を誤ると、符号ニブル（最下位バイトの後半4ビット：C, D, Fなど）が破壊され、コンバージョンエラー（S0C7アベンドなど）を引き起こす。
特に、`AUTOMATIC` 変数のポインタを外部のサブプログラム（COBOLやアセンブラ）に渡し、向こう側で領域をはみ出して書き込み（バッファオーバーラン）を行った場合、スタック領域にある他の `AUTOMATIC` 変数が一瞬で破壊される。
ダンプ解析（CEEDUMPやSYSUDUMP）において、原因不明のデータ化けに直面した際、スタックトレースを辿り、隣接する `AUTOMATIC` 変数のメモリスナップを16進数で目視解析するスキルは、シニアアーキテクトにとって必須の技量である。
② 埋め込みSQL（DB2）とホスト変数のストレージ
DB2のプリコンパイラを通す際、ホスト変数（Host Variables）の定義には細心の注意が必要だ。
CICSオンラインやバッチのサブプログラムにおいて、ホスト変数を `STATIC` にすると、マルチタスク環境（CICSのタスク共用）や再入可能性（Reentrancy）の要件を完全に破壊する。別々の端末から同時に実行されたトランザクションが、同じ `STATIC` なホスト変数を読み書きし、他人のデータを画面に表示するという致命的なセキュリティインシデント（データ混信）を引き起こす。
したがって、DB2のホスト変数やCICSの通信領域（DFHCOMMAREAのマップなど）を受ける変数は、原則として `AUTOMATIC`（あるいは動的に取得したヒープ領域）でなければならない。
—
4. マイグレーション（Java/C#化）への影響と設計の急所
レガシーマイグレーションの現場において、PL/Iの `AUTOMATIC` と `STATIC` の違いを理解していないオフショア開発チームや、単なる構文変換ツール（トランスレータ）に頼った移行プロジェクトは、高確率で失敗する。
Java/C#への置き換えにおける罠
1. `STATIC` の誤用によるスレッドセーフティの崩壊
PL/Iの `STATIC` 変数は、Javaにおける `public static` フィールドやC#の `static` プロパティに機械的に変換されがちである。しかし、メインフレームの単一プロセス・タスクモデルで作られたレガシーロジックを、Webアプリケーションサーバー（TomcatやIIS）上のマルチスレッド環境でそのまま動かすと、`static` 変数は全スレッドから共有され、深刻な競合状態（Race Condition）を引き起こす。
2. 自動初期化の差異
PL/Iの `AUTOMATIC` 変数は、ブロックに入るたびに `INITIAL` 句の値でリセットされるが、Javaのローカル変数は明示的に初期化しないとコンパイルエラーになる。また、オブジェクトのインスタンス変数とローカル変数のライフサイクルの違いを正しくマッピングしないと、予期せぬメモリリークや状態の持ち越しが発生する。
移行設計を行う際は、単なるコードの1対1の置換ではなく、PL/Iのストレージクラスが持っていた「生存期間」と「スコープ」のコンテキストを完全に解体し、モダン言語における適切なスコープ（メソッドローカル、インスタンスフィールド、スレッドローカルストレージなど）に再設計しなければならない。
—
結びにかえて
PL/Iの `STORAGE` 属性、すなわち `AUTOMATIC` と `STATIC` の選択は、単なるプログラミングの作法ではない。それは、背後にあるハードウェアのメモリ管理機構と直接対話するための、極めてプリミティブで強力な契約である。
レガシーシステムのモダナイゼーションを成功させるカギは、古いコードを嫌うことではなく、そのコードがなぜそのように書かれなければならなかったのか、その物理的・アーキテクチャ的な背景を誰よりも深く理解することにある。
次回のバッチ改修や、難解なダンプ解析に直面したとき、この記事の記憶があなたの背中を支える盾となることを願う。
