メインフレームの深淵：AUTOMATICとSTATICが織りなすメモリ生存期間の哲学
長年、IBMメインフレームの暗いデータセンターの片隅で、数百万行のコードと向き合ってきた者にとって、PL/Iという言語は単なるツールではなく、一種の「精密機械」である。
特に、変数の生存期間（Storage Class）を制御する`AUTOMATIC`と`STATIC`の理解は、我々が扱う基幹システムの安定性を左右する境界線だ。JavaやC#といったマネージド言語の世界から来たエンジニアが、マイグレーションの最中に「なぜこの変数は値が残っているのか？」あるいは「なぜ再帰呼び出しでデータが破壊されるのか？」と頭を抱えるのを何度も見てきた。
今日は、PL/Iのメモリ管理の心臓部について、実務的な洞察を交えて紐解いていく。
—
1. AUTOMATIC対STATIC：スタックとデータ領域の「生存」の定義
PL/Iにおいて、デフォルトで生成される`AUTOMATIC`変数は、その`PROCEDURE`または`BEGIN`ブロックがアクティブな間のみ、スタック上に生存する。これに対し、`STATIC`はロードモジュールのロードと同時に確保され、プログラムの終了までそのアドレスを保持し続ける。
/i
/ STATICとAUTOMATICの生存期間の違いを示すデモ /
TEST_PROC: PROCEDURE OPTIONS(MAIN);
DCL COUNT_STATIC FIXED BIN(31) STATIC INIT(0); / ロード時にメモリ確保、終了まで生存 /
CALL INCREMENT_ROUTINE;
CALL INCREMENT_ROUTINE;
INCREMENT_ROUTINE: PROCEDURE;
DCL COUNT_AUTO FIXED BIN(31) AUTOMATIC INIT(0); / 呼び出しの度にスタック確保・初期化 /
COUNT_STATIC = COUNT_STATIC + 1;
COUNT_AUTO = COUNT_AUTO + 1;
PUT SKIP LIST(‘STATIC:’, COUNT_STATIC, ‘AUTO:’, COUNT_AUTO);
END INCREMENT_ROUTINE;
END TEST_PROC;
このコードを実行すれば、`COUNT_AUTO`は何度呼んでも常に1であり、`COUNT_STATIC`は呼び出しごとに増分されることがわかるはずだ。この単純な違いが、CICSオンライン処理において致命的なバグを生む。
CICS環境における罠
CICSでは、`STATIC`変数は個別のタスク間で共有されることはないが、同一タスク内で再帰的に呼び出されるプログラムや、リンクされたモジュール間での「変数の持ち越し」に影響を与える。マルチスレッド的な挙動を意識しないまま`STATIC`を多用すると、後からデバッグ不可能なデータの不整合に泣くことになる。
—
2. 再帰呼び出しとアベンド（ABEND）の相関
マイグレーション時に特に注意が必要なのが、深い階層の再帰呼び出しだ。`AUTOMATIC`変数はスタックを消費する。メインフレームのスタック領域は無限ではない。
もし貴方の書いたコードで、再帰の深さがスタックの許容量を超えれば、`S0C4`（ストレージ保護例外）あるいは`S0C1`よりもタチの悪い「スタックオーバーフロー」による異常終了を招く。ダンプを解析する際、レジスタのポインタがスタックの境界を超えて、プログラムの命令領域を書き換えている形跡を見つけた時の絶望感は、言葉では言い表せない。
ポインタ操作時の注意点
`AUTOMATIC`変数のアドレスをポインタに格納し、そのブロックを抜けた後にそのポインタを参照する「ダングリングポインタ」の問題は、Javaエンジニアには馴染みが薄いかもしれないが、C言語的なメモリ管理をPL/Iでやる以上、避けては通れない道だ。
—
3. 実務で遭遇する「パックデシマル内部符号反転」の恐怖
基幹システムの移行で最も恐ろしいのは、計算ロジックのマイグレーションではない。`FIXED DECIMAL`（パックデシマル）の内部表現の差異だ。
PL/Iの`DCL VAR FIXED DEC(15,2)`は、内部的には符号付きのパック形式で格納される。このメモリ領域をポインタで操作したり、バイナリ転送を行ったりする際、コンパイラやアーキテクチャの都合で符号部（通常は末尾のニブル）が反転、あるいは破壊されることがある。
特に、`STATIC`領域に格納された構造体を、後続のプログラムで`REDEFINES`的にポインタで強引にキャストして読み込む場合、アライメントやパディングの差異で予期せぬアベンドを引き起こす。この手のバグは、本番稼働後の夜間バッチでしか顕在化しない。
—
4. コンパイラオプションと最適化の深淵
`OPTIMIZE(3)`をかけると、コンパイラは`STATIC`変数のロードをレジスタに保持し、メモリへの書き込みを遅延させる。これがデバッグを困難にする。
- ダンプ解析の極意: `LIST`オプション付きでコンパイルし、生成されたリスティングファイルと、`SYSUDUMP`で出力された16進のダンプを突き合わせる。`STATIC`領域のアドレスが、ロードモジュールマップ上のどのアドレスに対応しているかを見極める力こそが、真のスペシャリストの証だ。
—
最後に：移行設計者に贈る言葉
Javaへの移行時、PL/Iの`STATIC`を単なる`static`変数に置き換えるだけで済むと思ったら大間違いだ。PL/Iのメモリ管理は、ハードウェアの制約と密接に結びついている。
移行において重要なのは、変数一つひとつの生存期間（ライフサイクル）を正確にマッピングすることだ。`AUTOMATIC`なものはJavaのローカル変数へ、`STATIC`なものはシングルトンやコンテキスト管理オブジェクトへ。この設計思想の翻訳こそが、レガシーを健全なモダンシステムへと昇華させる唯一の鍵となる。
コードは嘘をつかない。たとえそれが40年前に書かれたものであっても、そこに流れるメモリの法則を理解すれば、どんなに難解なアベンドも必ず解明できる。健闘を祈る。
