PL/IのSTATICストレージ：その沈黙の初期化と、モジュール間共有の落とし穴
メインフレームの現場で長く生きていると、ふとした瞬間に「なぜこの変数はこのタイミングで初期化されるのか」という原点に立ち返らされることがある。特に、現代のJavaやC#のメモリ管理に慣れた若手エンジニアから見れば、PL/Iの`STATIC`ストレージは「魔法の箱」のように映るかもしれない。しかし、その中身はコンパイラとリンカが精密に編み上げた、極めて静的で冷徹なメモリ構造だ。
今日は、基幹システムの保守やマイグレーションの最前線で、我々を悩ませるSTATIC変数の真実について深掘りしよう。
—
1. STATIC変数の「生まれる瞬間」を知る
PL/Iにおける`STATIC`ストレージは、プログラムがロードされた瞬間にメモリ上に固定配置される。これはスタック上に配置される`AUTOMATIC`変数とは決定的に異なる。
重要なのは、「初期化タイミングはプログラムの実行開始時（ENTRY）ではなく、ロードモジュールが制御を得る前」という点だ。コンパイラは、ソースコード内で与えられた初期値を、実行形式（ロードモジュール）のデータセクションに直接焼き付ける。
/i
/ STATIC変数による制御用フラグの例 /
DCL INIT_FLAG BIN FIXED(31) STATIC INIT(0);
/ プログラムロード時に0で初期化される。
再入可能(REENTRANT)なプログラムでは、
この値はタスク間で共有されるため注意が必要 /
もし、あなたがこの変数をCICSオンラインプログラムで不用意に書き換えた場合、それは「全ユーザー共通のフラグ」として機能する。この挙動を知らずにマルチスレッド的な設計を持ち込むと、原因不明の「特定条件下でしか起きないバグ」という悪夢を見ることになる。
2. EXTERNAL属性：モジュールを超えた「記憶の共有」
複数のロードモジュール間でデータを共有する際、`EXTERNAL`属性は強力だが、諸刃の剣だ。
/i
/ モジュールAで定義 /
DCL SHARED_BUFFER CHAR(1024) STATIC EXTERNAL;
/ モジュールBで参照 /
DCL SHARED_BUFFER CHAR(1024) STATIC EXTERNAL;
ここで注意すべきは、リンカ（BINDER）の挙動である。異なるコンパイル単位間で、属性（型や長さ）が不一致のまま`EXTERNAL`宣言を記述した場合、コンパイラは警告を出すかもしれないが、リンカは黙々とメモリを重ね合わせる。結果、パックデシマル(FIXED DECIMAL)の桁数不一致により、上位バイトが誤って解釈され、数値が化けるといった致命的な事態を招く。
実務の知見： 共有するデータ構造は必ず「COPY句（Includeファイル）」で管理し、絶対に手打ちで再定義してはならない。これは移行プロジェクトにおける鉄則である。
3. アベンド（ABEND）解析とデータ構造の罠
稼働中のシステムでS0C7（データ例外）が発生した際、ダンプリストを眺める場面があるだろう。`STATIC`変数はダンプの特定のセクションに固まって存在する。
特に注意が必要なのが、パックデシマルの内部符号だ。`PIC S9(7) COMP-3`のような変数が、初期化漏れや不正なキャストによって`X’0000000F’`以外の無効な符号（例えば`X’0000000A’`など）を持った場合、演算時に容赦なくS0C7を叩き出す。
/i
/ 危険なポインタ操作の例 /
DCL P_DATA PTR;
DCL T_DATA CHAR(10) BASED(P_DATA);
/ 明示的にストレージを割り当てずにポインタ操作を行うと、
STATIC領域の先頭を破壊する可能性がある /
P_DATA = ADDR(SHARED_BUFFER);
T_DATA = ‘ERR_DATA’; / 共有領域を直接書き換える危険性 /
マイグレーション時にJavaの`ByteBuffer`等へ置き換える際、この「メモリの物理的配置」という概念がごっそり抜け落ちることが多い。ポインタを用いた動的操作をJavaで再現する場合、`Unsafe`クラスや`ByteBuffer`の絶対位置指定が必要になるが、これは本来のJavaの流儀ではない。設計の段階で、PL/Iのメモリレイアウトを「データ転送用オブジェクト」として再定義する勇気が必要だ。
4. 最適化とエッジケース対策
コンパイラオプションの`OPTIMIZE(2)`以上を適用すると、コンパイラは「この変数はプログラム内で不変である」と判断し、レジスタにキャッシュすることがある。しかし、外部からの割り込みや、別のロードモジュールによるメモリ破壊が起きている場合、このキャッシュが仇となり、最新の値が取得できないケースがある。
もし、変数の値が予期せず書き換わるような不安定なコードがある場合、`VOLATILE`属性（最近のコンパイラであれば有効）を付与するか、最適化レベルを落とすのが、戦場での現実的な解となる。
結びに代えて：アーキテクトとしての視点
PL/Iのコードを読んでいて思うのは、それが書かれた当時のエンジニアたちの「ハードウェアと対話する精神」だ。現代の高級言語はメモリを抽象化しすぎている。しかし、基幹システムの根幹を支えるのは、依然としてこの「バイト単位の厳密な管理」である。
マイグレーションを担当するなら、単にPL/Iの構文を変換するのではなく、「なぜこの変数がSTATICなのか」「なぜこのタイミングで初期化が必要なのか」という、当時の設計意図を読み解いてほしい。その先にこそ、真に堅牢な新システムへの道が開かれているはずだ。
技術は変わっても、メモリ上のデータが嘘をつかないという事実は、メインフレームの時代から何も変わっていないのだから。
