メインフレームの深淵：AUTOMATICとSTATICが支配するメモリの生死学
PL/Iという言語は、現代のメモリ管理が抽象化されきったJavaやC#の世界から見れば、まさに「荒ぶる神」のような制御を我々に要求します。特に基幹システムの心臓部であるバッチ処理やCICSオンラインにおいて、`AUTOMATIC`と`STATIC`のストレージクラスを混同することは、致命的なアベンド（ABEND）への片道切符です。
今日は、システムアーキテクトの視点から、この二つのストレージ属性がシステムの再入可能性（Reentrancy）と信頼性にどう直結するか、そしてマイグレーション時に我々が何を恐れるべきかを紐解いていきましょう。
—
1. AUTOMATICとSTATICの「生存権」を見極める
PL/Iにおけるストレージ属性は、単なるメモリの場所取りではありません。それは「プログラムの実行コンテキストを誰が守るのか」という設計思想そのものです。
AUTOMATIC: スタックという名の「使い捨ての戦場」
`AUTOMATIC`は、PROCEDUREが呼び出されるたびにスタック上に確保され、終了とともに消滅します。これは再帰呼び出しや、マルチスレッド（CICSタスクなど）環境下で不可欠な「再入可能性」を担保するための大前提です。
STATIC: 永遠という名の「呪縛」
一方、`STATIC`はロードモジュールがメモリにロードされてから、終了（アドレス空間の開放）までその寿命を全うします。これは一見便利ですが、オンライン処理で「前回の処理の残骸」が変数に残るという、悪夢のようなバグの温床になります。
/i
/ STATIC変数は初期化が初回のみ。再入不可能（Not Reentrant）の元凶 /
DCL COUNTER FIXED BIN(31) STATIC INIT(0);
/ AUTOMATIC変数は呼び出しごとにクリーンな状態で生成される /
PROC_MAIN: PROCEDURE OPTIONS(MAIN);
DCL LOCAL_WORK FIXED BIN(31) AUTOMATIC;
COUNTER = COUNTER + 1; / ここがマルチタスクで競合すると地獄を見る /
LOCAL_WORK = 0; / 常に安全、再入可能 /
END PROC_MAIN;
—
2. マイグレーションを阻む「静的領域」の罠
Javaへの移行を検討する際、最も頭を抱えるのがこの`STATIC`の扱いです。メインフレームでは「静的領域への書き込み」がOSレベルで保護されていない場合、予期せぬ他タスクへのメモリ破壊を引き起こします。
パックデシマルの符号反転バグという教訓
かつて、あるレガシーシステムで「計算結果が時々マイナスになる」という不可解な事象がありました。原因は、`STATIC`で確保されたレコード領域の符号ビットが、別の非同期処理によって破壊されていたことでした。
PL/Iの`FIXED DECIMAL`（パックデシマル）は内部表現として`X’0C’`（正）や`X’0D’`（負）を持ちますが、メモリの境界整合性（Alignment）が不適切な`STATIC`領域をポインタで操作すると、隣接する変数の符号ビットが容易に反転します。
—
3. CICS環境下における「再入可能性」の鉄則
CICSオンラインプログラムにおいて、`STATIC`属性の使用は厳禁です。なぜなら、CICSのタスクは同一のロードモジュールを複数のユーザーで共有するからです。
- STATICの回避: すべての作業変数は`AUTOMATIC`にするか、あるいはCICSの`GETMAIN`を使用して、タスクごとのメモリを明示的に確保すべきです。
- ダンプ解析の定石: コンソールに`ASRA`（CICSの汎用アベンド）が吐かれた時、まずはメインストレージダンプ（MVSダンプ）を確認します。もし変数の値が「前回処理した別のユーザーのデータ」であれば、それは`STATIC`の無思慮な使用が原因です。
—
4. アーキテクトとしてのアドバイス：移行の勘所
もしあなたが今、PL/IからJava/C#への大規模マイグレーションを指揮しているならば、以下のチェックリストを心に刻んでください。
1. グローバル変数の撲滅: PL/Iの`EXTERNAL`や`STATIC`を多用しているコードは、Javaの`static`フィールドではなく、ステートレスなオブジェクト設計（DIコンテナの利用など）へと完全にパラダイムシフトさせること。
2. ポインタ操作の代替: `ADDR`関数と`DEFINED`属性を駆使したメモリハックは、マイグレーション時に最も技術負債となります。これらはJavaの`ByteBuffer`や`Unsafe`クラスで代替するのではなく、ビジネスロジックとして正しく型定義し直す機会と捉えてください。
3. コンパイラオプションの再確認: メインフレームの`RENT`オプション（再入可能）でコンパイルされていないモジュールは、現代の分散環境では即座にボトルネックとなります。
—
結びに代えて
PL/Iは、ハードウェアの制約を限界まで引き出し、計算機資源を極限まで使い倒すための美学に満ちた言語です。`AUTOMATIC`と`STATIC`の境界を理解することは、単なるメモリ管理術ではありません。それは、システムが「時間」という概念をどう扱うか、という哲学を理解することに他なりません。
レガシーシステムのバグに直面したとき、焦ってコードを書き換える前に、一度メモリダンプを眺めてみてください。そこには、過去の設計者が何を恐れ、何を信じてその`STATIC`を置いたのかという「技術的痕跡」が刻まれています。
我々アーキテクトの仕事は、その痕跡を尊重しながら、次世代の安定した堅牢なシステムへと、橋を架け替えることなのですから。
