PL/Iの「CONTROLLED属性」が支配する動的メモリの深淵：レガシー移行の設計判断基準
メインフレームの現場で長年PL/Iコードと対峙していると、時折、「なぜこの言語はこれほどまでに自由なのか」と驚かされることがある。現代のJavaやC#のようなガベージコレクションに守られたぬるま湯に浸かっていると、PL/Iの`CONTROLLED`属性によるメモリ管理は、まるで荒野を切り拓く開拓者の技術のように映るだろう。
今日は、その中でも特に扱いを誤ると致命的なABEND（異常終了）を招き、かつマイグレーションの設計において最大の障壁となる「動的メモリ管理」の核心について語りたい。
—
1. CONTROLLED属性の本質：スタック管理との決定的な違い
PL/Iにおける`CONTROLLED`属性とは、プログラマが明示的にメモリの割り当て（`ALLOCATE`）と解放（`FREE`）を制御する仕組みだ。
C言語等のスタック領域（Automatic変数）は、プロシージャの呼出し終了とともに自動的に破棄されるが、`CONTROLLED`はそうではない。生存期間（Extents）は、`ALLOCATE`が実行された時点から、`FREE`が実行されるまで、あるいはプログラムが終了するまで永続する。
なぜこれがレガシー移行で問題になるのか
Java等へ移行する場合、これらは「オブジェクトのライフサイクル」として再設計せねばならない。スタック管理と異なり、`CONTROLLED`変数は「再帰呼び出し」において独自のスタック（プッシュ・ポップ）構造を持つ。同じ変数名で何度も`ALLOCATE`すると、古いメモリは隠蔽され、新しいものがスタックの頂点に来る。この挙動を理解せずに「変数の生存期間」を誤解したコードは、マイグレーション時にメモリリークやヌルポインタ例外の温床となる。
/i
/ CONTROLLED属性を用いた動的領域の管理例 /
DCL MY_BUFFER CHAR(1024) CONTROLLED;
/ 割り当て実行：ここでヒープメモリが確保される /
ALLOCATE MY_BUFFER;
/ ここで処理を実行 /
MY_BUFFER = ‘DATA_PROCESSING_START’;
/
- 注意：FREEを忘れると、ループ内で何度もALLOCATEした場合、
- メモリを食いつぶし、最悪の場合はストレージ不足でS80A等のABENDを招く。
/
FREE MY_BUFFER;
—
2. ポインタとベース変数：現代的視点でのリスク管理
PL/Iの強力な武器である「ベース変数（`BASED`）」は、特定のメモリ番地を指し示すポインタと組み合わせることで、構造体のオーバーレイを可能にする。これはDB2のカーソル処理や、CICSの通信域（COMMAREA）を解析する際によく見かけるテクニックだ。
しかし、ここには「型安全性の欠如」という爆弾が潜んでいる。
パックデシマル（FIXED DECIMAL）の罠
特に注意すべきは、`BASED`構造体を用いて外部ファイルやDBから読み込んだデータをマップする際だ。PL/Iはパックデシマルの内部形式（例：`X’123C’`）を厳密にチェックするが、誤ったベースポインタを設定し、符号部（`C`や`D`）が期待と異なるデータ領域を参照した場合、演算時に「S0C7（データ例外）」が即座に発生する。
マイグレーション時に、「JavaのBigDecimalへの変換がうまくいかない」と相談を受けた際、原因の9割は元のPL/Iコードがこの「ポインタのオフセット計算のズレ」を許容していた（あるいは偶然動いていた）ことにある。
—
3. ABEND解析の現場知見：ダンプを読み解く哲学
もしシステムがS0C4（保護例外）で落ちたなら、まずは`ALLOCATE`の連鎖と、ポインタの有効範囲を疑うべきだ。
1. アライメントの不一致: `ALIGNED`属性を省略すると、コンパイラは`UNALIGNED`（詰め込み）を選択する。ベース構造体でこれを行うと、ポインタが構造体の途中のバイトを指すことになり、境界調整が必要な命令でCPUが悲鳴を上げる。
2. FREE後のダングリングポインタ: `FREE`した後、そのポインタをゼロクリア（`NULL()`を設定）する習慣がないコードは、将来のバグの温床だ。移行先がJavaであれば、ガベージコレクタが勝手にやってくれるが、PL/Iの世界では「自分で掃除する」のが鉄則である。
—
4. 移行設計のテックリードへ贈る提言
もしあなたが今、PL/Iからモダン言語への刷新を指揮しているなら、以下のルールを設計指針に加えてほしい。
- 「暗黙的な生存期間」を排除せよ: `CONTROLLED`属性に頼るコードは、移行先での「スコープ」と「ライフサイクル」が一致しないことが多い。クラス設計において、明示的な初期化・終了処理（`init()` / `close()`や`try-with-resources`）を強制する構造に変換せよ。
- 埋め込みSQL（DB2）との親和性: PL/Iの構造体とDB2のホスト変数をマッピングしている箇所は、そのままDTO（Data Transfer Object）へ置き換えるのが定石だが、その際のデータ型変換（特に`FIXED BIN`と`FIXED DEC`の精度）は、単なる自動変換ツール任せにせず、すべて手動で型合わせのテストケースを書くべきだ。
結び
PL/Iという言語は、コンピュータのメモリレイアウトを剥き出しのまま操作できる、極めて人間味のある（あるいは無慈悲な）言語だ。移行作業は単なるコードの翻訳ではなく、先人の意図した「メモリという資源との対話」を現代の言語仕様に再翻訳する作業に他ならない。
技術的な深淵を恐れず、しかしコンパイラの挙動という厳格な規律を尊重する。それが、レガシー移行を成功させる唯一の道であると私は信じている。
