メインフレームの深淵：PL/Iにおけるメモリ管理の「静」と「動」を極める
システムアーキテクトとして数多くの基幹系マイグレーションを見てきたが、JavaやC#のエンジニアがPL/Iのコードを読み解く際、最も躓くのが「ストレージクラス」の概念だ。現代のガベージコレクションに慣れた世代には、メモリの生死をコンパイラやOSの仕様と紐づけて制御する感覚は、もはや古典芸術のように映るかもしれない。
しかし、ミッションクリティカルなバッチ処理や、高負荷なCICSオンラインにおいて、メモリ配置の理解はアベンド（ABEND）を回避するための最後の砦となる。今日は、`STATIC`と`AUTOMATIC`、そしてその先にある動的メモリ操作の深淵について語ろう。
—
1. STATIC対AUTOMATIC：生存期間という名の運命
PL/Iにおいて、変数の寿命は宣言一つで決定される。
- AUTOMATIC（デフォルト）: ブロック（PROCEDUREやBEGIN）に入った瞬間にスタック領域に確保され、抜けた瞬間に解放される。再帰呼び出し（RECURSIVE）を行う場合、呼び出しごとに新しいインスタンスが生成されるため、意図せぬバグの温床になりやすい。
- STATIC: プログラムロード時に静的領域に配置され、終了までその値を保持する。
実践的なコード例：生存期間の制御
1
TEST_PROC: PROCEDURE OPTIONS(MAIN);
/ STATICはプログラム実行中、値が永続する。初期値はロード時のみ適用 /
DCL COUNTER FIXED BIN(31) STATIC INIT(0);
/ AUTOMATICは呼び出されるたびに初期化され、ブロック終了で消滅 /
DCL WORK_AREA CHAR(1024) AUTOMATIC;
COUNTER = COUNTER + 1;
PUT LIST(‘呼び出し回数:’, COUNTER);
END TEST_PROC;
ここで注意すべきは、「マルチスレッド環境やCICSにおけるSTATICの罠」だ。オンライン処理でSTATIC変数に状態を持たせると、別トランザクションの残滓が干渉するリスクがある。現代のアーキテクトとしては、可能な限り`AUTOMATIC`を基本とし、`THREAD`属性や`REENTRANT`（再入可能）な設計を優先すべきだ。
—
2. ポインタとベース変数：動的メモリの諸刃の剣
基幹システムでは、可変長レコードの解析や、DB2から取得したデータのバッファ操作でポインタを多用する。`BASED`属性を用いれば、任意のメモリ番地をPL/Iの構造体としてマッピングできる。
1
/ ポインタを用いた動的データアクセス /
DCL DATA_PTR POINTER;
DCL 1 MY_RECORD BASED(DATA_PTR),
2 KEY_ID CHAR(5),
2 VALUE FIXED DEC(9,2);
/ ストレージの確保 /
ALLOCATE MY_RECORD;
/ この時点で DATA_PTR は確保された領域を指す。
DB2のFETCHバッファをここにマッピングすれば高速な処理が可能 /
この際、最も恐ろしいのは「ポインタの浮遊」だ。`FREE`を実行した直後にそのポインタを参照すれば、当然ながらシステムダンプが待っている。ダンプ解析（CEE3DMP）の際、特定アドレスが「なぜそこに配置されているのか」を追う力は、レガシー移行における最強の武器となる。
—
3. 現場を泣かせる「パックデシマル」の落とし穴
マイグレーション時、最もトラブルが多いのが`FIXED DEC`（パックデシマル）の内部表現だ。特に、COBOLからPL/Iへの移行時や、外部システムとのバイナリ連携で頻発する。
パックデシマルは、末尾のニブル（4ビット）が符号を表す。`X’0C’`はプラス、`X’0D’`はマイナスだが、コンパイラオプションの`NOTEST`や`OPTIMIZE`の組み合わせにより、符号反転の挙動が最適化の過程で変わる場合がある。
- 鉄則: 外部IFで受け取ったデータは、必ず一度`VALIDATE`（あるいは独自チェックルーチン）を通すこと。不正な符号ビットを持つパックデシマルを演算に使うと、S0C7（データ例外）のアベンドが即座に発生する。
—
4. アーキテクトへの提言：モダナイゼーションを見据えて
PL/IのコードをJava等のオブジェクト指向言語へ移植する際、`STATIC`変数を`private static`なフィールドとして安易に変換してはならない。それは、メインフレーム特有の「一貫したメモリ空間」という前提を破壊することに繋がるからだ。
1. コンパイラ最適化の意識: `OPTIMIZE(2)`以上を適用する際、変数の寿命がコンパイラの推論で短縮されることがある。デバッグ時には必ず`NOOPTIMIZE`で解析し、挙動の違いを精査せよ。
2. ダンプの「読解」: ABEND発生時、汎用レジスタやストレージダンプから、現在実行中のプロシージャがどのメモリ領域を参照しているか（`AUTOMATIC`か`STATIC`か）を即座に判断できるスキルこそが、真のスペシャリストの証だ。
PL/Iは、ハードウェアを直接制御するような手応えがある、実に美しい言語だ。マイグレーションにおいても、単なる構文変換ではなく、その背後にある「メモリの寿命」をどう現代のアーキテクチャに再配置するか。それこそが、我々システムアーキテクトが担うべき真の責務である。
もし今、解析不能なアベンドに頭を抱えているなら、まずは`CEE3DMP`の出力と、その変数が宣言された`PROCEDURE`の`STORAGE`属性をもう一度見直してみてほしい。答えは必ず、そのメモリ配置のどこかに隠れているはずだ。
