PL/Iの「CONTROLLED」が導く動的メモリ管理の深淵：レガシー移行における生存戦略
IBMメインフレームの世界において、`CONTROLLED`属性は、現代のJavaのようなガベージコレクション（GC）に甘やかされたエンジニアには少々「危険な香りのする」機能かもしれません。しかし、リソース制約が厳しく、かつ一瞬の誤りが数億円の損失に繋がる基幹系バッチ処理において、メモリをプログラムの意志で制御することほど、信頼性を高める術はありません。
今回は、この`CONTROLLED`属性の深淵と、それが現代のマイグレーションプロジェクトにおいてどのような地雷原となり得るのか、アーキテクトの視点から紐解いていきます。
—
1. CONTROLLED属性の哲学：スタックを超えて
PL/Iにおける`CONTROLLED`変数は、`ALLOCATE`と`FREE`という、C言語の`malloc/free`に似た明示的なライフサイクルを持ちます。しかし、決定的に異なるのは「スタック」ではなく「ヒープ」を使いつつ、スタックのような後入れ先出し（LIFO）のスタック構造を動的に生成できる点です。
1
/ 基幹バッチでの動的レコード処理の例 /
DCL BUFFER_AREA CHAR(4096) CONTROLLED;
/ 必要なタイミングでメモリを確保 /
ALLOCATE BUFFER_AREA;
/ ここでポインタ変数を使ってオフセット制御を行う /
DCL PTR_BUFFER PTR;
PTR_BUFFER = ADDR(BUFFER_AREA);
/ 処理終了後に明示的に解放 /
FREE BUFFER_AREA;
なぜ`CONTROLLED`を使うのか？ それは、データ長が実行時まで確定しない巨大なレコードや、再帰処理における作業領域を、OSのメモリ空間に対して「必要な時だけ」要求するためです。これにより、膨大なバッチ処理において常駐領域を最小化し、システム全体のCPU負荷とページング発生を抑制できます。
—
2. 現場のトラウマ：アベンド（ABEND）解析と「見えない壁」
移行プロジェクトで最も苦しむのは、`CONTROLLED`変数の解放漏れが引き起こす「S878アベンド（仮想記憶不足）」です。
特に、CICSオンライン処理とバッチが混在する環境では、`FREE`ステートメントが確実に実行される保証をどこに置くかが鍵になります。私が現場で遭遇した最悪のケースは、エラーハンドリング（`ON CONDITION`）の中で`FREE`を呼び出そうとして、その`ON`ユニット自体が無限ループに陥るという悲劇でした。
トラブルシューティングの知見：
- ダンプ解析の定石: `CEE3DMP`等でダンプを取る際、`CONTROLLED`変数は静的変数の領域には現れません。`PL/I Storage Report`（`PLIDUMP`オプション）を有効にし、`ALLOCATE`されたアドレスの断片化状況を追うのが鉄則です。
- ポインタの迷子: `ADDR(VAR)`で取得したポインタが、`FREE`後に「ダングリングポインタ」として残存し、別の処理で誤って書き換えを行うケース。移行先がJavaならば`null`チェックで済みますが、PL/Iのバイナリの世界では、黙って隣のメモリ領域を破壊します。
—
3. マイグレーションの最前線：Java/C#への移行という壁
レガシー移行の際、`CONTROLLED`属性のコードをそのままオブジェクト指向言語へ書き換えることは、単なる構文変換ではありません。
パックデシマル（COMP-3）の罠
PL/Iで`CONTROLLED`変数の内部にパックデシマル構造体（`PIC S9(7)V99 COMP-3`など）を保持している場合、移行先の言語では同様のバイナリ表現が存在しません。特に、パックデシマルの符号ビット（`C`や`F`など）の反転バグは、移行後のデータ検証フェーズで最も頻出するバグです。
アーキテクトとしての助言：
1. ラッパーの導入: 移行先の言語で、PL/Iの`CONTROLLED`メモリレイアウトを模倣する「メモリ管理クラス」を作成し、`allocate()`と`free()`をカプセル化してください。
2. DB2/CICSの制約: `EXEC SQL`を埋め込んでいる場合、`CONTROLLED`変数をホスト変数として渡す際には、必ずメモリがアライメントされていることを確認してください。CICSの`GETMAIN`とPL/Iの`ALLOCATE`が混在すると、メモリリークの温床となります。
—
結びに：PL/Iの「規律」を現代に引き継ぐ
`CONTROLLED`属性を使いこなすことは、単なる言語仕様の理解を超え、「システムのリソースを自ら支配する」という気概に繋がります。
昨今の高レイヤーな開発環境では、メモリ管理はランタイムのブラックボックスに隠蔽されています。しかし、大規模な基幹システムのメインテナンスや移行を担う我々にとって、メモリの確保と解放という「呼吸」を意識し続けることは、システムの安定稼働を維持するための最後の砦です。
もし今、あなたの抱えるPL/Iプログラムが謎のアベンドを繰り返しているなら、それはプログラムがあなたに「メモリの所有権」を再確認するよう求めているサインかもしれません。コードの裏側にあるバイナリの景色が見えたとき、移行の成功はすぐそこにあります。
