PL/I動的メモリ管理の深淵：ALLOCATE文、Dangling Pointer、そして移行の美学
メインフレームの世界では、メモリ管理は「OSの慈悲」を待つものではなく、プログラマがその挙動を支配すべき領域です。特にPL/Iにおける`ALLOCATE`文を用いたヒープ領域の操作は、往年のエンジニアにとっての腕の見せ所であり、同時に現代のマイグレーションプロジェクトにおいて最も「悪夢」を見やすい箇所でもあります。
今回は、基幹システムを支えるPL/Iの動的メモリ管理について、その危うさと深淵を紐解いていきましょう。
—
1. PL/Iの自由度と「予約語なき世界」の功罪
PL/Iが特異なのは、キーワードすら文脈によって変数名になり得るという、現代の言語設計からすれば信じがたい自由度（あるいは狂気）を持っている点です。
/i
/ 極端な例：ALLOCATEも変数名として定義可能 /
DCL ALLOCATE FIXED BIN(31) INIT(100);
/ この後でALLOCATE文を書くとコンパイラは混乱を極める /
この「予約語を持たない」仕様は、レガシーコードの解析において解析ツールをしばしば沈黙させます。マイグレーション時には、識別子の衝突を厳密にチェックするコンパイラオプション（`RULES(NOLAXDCL)`等）を必須とし、曖昧な参照を排除しなければなりません。
—
2. ALLOCATE文とヒープ管理のリアル
PL/Iの`ALLOCATE`は、単なるメモリ確保ではありません。`BASED`変数と`POINTER`変数を組み合わせることで、構造体の動的生成を直感的に記述できます。
/i
DCL MY_PTR POINTER;
DCL 1 MY_STRUCT BASED(MY_PTR),
2 ID FIXED BIN(15),
2 DATA CHAR(80);
/ メモリ確保。ヒープ領域が動的に食いつぶされる /
ALLOCATE MY_STRUCT;
/ データの操作 /
MY_STRUCT.ID = 1234;
ここで重要なのは、「メモリがどこから供給されているか」という意識です。PL/Iのランタイムライブラリは、内部的に`GETMAIN`（あるいは`STORAGE OBTAIN`）を呼び出し、ヒープを管理します。しかし、このヒープ管理アルゴリズムは、長期間稼働するCICSオンライン処理において「断片化（Fragmentation）」を引き起こすリスクを常に孕んでいます。
—
3. Dangling Pointer（宙吊りポインタ）の闇とアベンド
`FREE`文を実行した直後、ポインタ変数は解放されたメモリ領域を指したままになります。これが「Dangling Pointer」です。
/i
FREE MY_STRUCT;
/ ここでMY_PTRは解放済みの領域を指している！ /
/ 次の処理でこのポインタ経由でアクセスするとS0C4アベンド確定 /
MY_PTR -> ID = 9999;
実務の現場では、解放後にポインタを`NULL()`でクリアする習慣を徹底させることが重要です。しかし、大規模なバッチ処理で何千ものオブジェクトを扱う際、これを失念したことによるS0C4ダンプの解析は、まさに地獄への入り口です。
ダンプ解析の勘所
もしS0C4が発生した場合、まず`CEEDUMP`のスタックトレースを確認します。ヒープ領域の管理ヘッダが破壊されている場合、それはポインタの先でバッファオーバーフローが起きている証拠です。特にパックデシマル（`PIC S9(7) COMP-3`等）を操作する際、符号ビット（`0C`や`0D`）が破壊されると、計算命令実行時に`S0C7`（データ例外）が発生し、その原因が別の場所で確保したメモリの領域外アクセスにある、というケースは後を絶ちません。
—
4. マイグレーションに向けたアーキテクトの提言
JavaやC#への移行を検討する際、単なる構文変換は「翻訳」に過ぎません。PL/I特有の「メモリの物理的配置」への依存を、いかに論理的なオブジェクト管理に抽象化するかが鍵となります。
- エッジケース対策: DB2の埋め込みSQLと`ALLOCATE`を併用する場合、SQLの戻り値を受け取る変数のメモリ配置が適切か（アライメント問題）を検証してください。特に構造体のメンバー配置順序は、言語間でのパディングの扱いが異なるため、移行先でメモリ破壊の温床となります。
- 最適化の罠: `OPTIMIZE(3)`を指定した際のコンパイラ挙動は、時に「使用されていない」と判断したコードパスを削除し、デバッグを困難にします。信頼性を優先する基幹システムでは、まずは`OPTIMIZE(0)`または`1`で動作を安定させることが定石です。
最後に
PL/Iの美しさは、ハードウェアに肉薄するその表現力にあります。現代の言語が隠蔽してしまったメモリ管理の責任を、プログラマが直接引き受ける。この緊張感こそが、過去数十年にわたり金融・公共システムを支え続けてきた「圧倒的な堅牢性」の源泉です。
次にコードを修正する際は、`FREE`の後のポインタを一度見直してみてください。その小さな一手間が、深夜の緊急呼び出しを防ぐ唯一の盾となるのです。
