汎用機の深淵：CONTROLLED属性が支配する動的メモリの美学と罠
メインフレームの現場で、PL/Iの `CONTROLLED` 属性を単なる「動的メモリ確保」と捉えているなら、それは少々危険だ。JavaのガベージコレクションやC#のマネージドヒープに慣れ親しんだエンジニアが、このレガシーコードに触れた瞬間、真っ先に遭遇する壁が「スタック的な世代管理」の挙動である。
今日は、現代のマイグレーションプロジェクトにおいても避けては通れない、PL/Iの `CONTROLLED` ストレージの真実について、アーキテクトの視点から紐解いていく。
—
CONTROLLED変数の本質：世代管理という名のスタック
`CONTROLLED` 属性で定義された変数は、`ALLOCATE` されるたびにスタック状に積み上がる。これが `AUTOMATIC` と決定的に異なるのは、明示的に `FREE` されるまで、以前の世代（同じ変数名だが異なるメモリ空間）が隠蔽された状態で生存し続ける点にある。
1
/ CONTROLLEDによる世代管理の例 /
DCL MY_BUFFER CHAR(100) CONTROLLED;
ALLOCATE MY_BUFFER; / 世代1が生成される /
MY_BUFFER = ‘VERSION_1’;
ALLOCATE MY_BUFFER; / 世代2が生成される。世代1はスタックの下へ /
MY_BUFFER = ‘VERSION_2’;
FREE MY_BUFFER; / 世代2が解放され、世代1が再びアクティブになる /
この挙動は、再帰呼び出しや複雑なデータ構造のハンドリングには極めて強力だが、設計の不備は即座に `STORAGE` アベンド（S80AやS806等）や、予期せぬデータの残存を引き起こす。特にCICSオンライン処理において、この「解放し忘れ」が積み重なると、トランザクションの終了を待たずに領域が枯渇し、システム全体を巻き込むパニックに発展する。
—
ポインタとの共演：ベース付き変数（Based Variables）という禁断の果実
`CONTROLLED` に限界を感じたベテランは、往々にして `BASED` 属性とポインタ（`PTR`）を組み合わせた動的領域確保に走る。
1
/ BASED属性とポインタを用いた動的制御 /
DCL DATA_PTR PTR;
DCL MY_STRUCT BASED(DATA_PTR) CHAR(256);
/ 必要なサイズを算出してから確保する /
ALLOCATE MY_STRUCT;
ここで重要なのは、コンパイラが生成するコードの最適化だ。`OPTIONS(RENT)`（リエントラント）を付与してコンパイルされたプログラムでは、基底ポインタの管理がレジスタレベルで行われる。もし `ALLOCATE` 直後にポインタ値を誤って書き換えると、`FREE` を呼んだ瞬間にシステム領域を巻き込んでの `S0C4`（アドレッシング例外）が待っている。マイグレーション先がJavaであれば、この「ポインタの直操作」をどのようにオブジェクトモデルに落とし込むかが、アーキテクチャ設計の腕の見せ所となる。
—
アベンドとダンプ解析：現場の知恵
もし貴方が運用保守で `S0C7`（データ例外）に遭遇したなら、真っ先に疑うべきはパックデシマルの符号だ。PL/Iは内部的にパックデシマル（`PIC S9(7) COMP-3` 等）を扱う際、最下位ニブルで符号を判定する。CICSのCOMMAREAを介してデータが渡される際、外部から不適切なバイナリ値が混入すると、演算命令が即座にアベンドを引き起こす。
ダンプを解析する際、`CONTROLLED` 変数のアドレスは、静的なデータセクションではなく、常に動的に割り振られたヒープ上にある。`SYM` オプション付きでコンパイルされたロードモジュールであれば、ダンプツールからシンボル名での追跡が可能だが、最適化（`OPTIMIZE(2)` 以上）が効いている場合、変数はレジスタに保持され、ダンプ上からは「消滅」しているように見えることもある。
—
マイグレーションの心得：レガシーの論理をどう変換するか
JavaやC#への移行において、この `CONTROLLED` の挙動をどうエミュレートするか。単純な `ArrayList` や `Stack` で置き換えるのは早計だ。
1. 生存期間の整合性: `CONTROLLED` のスタック的な世代管理は、呼び出し元のスコープと密接に結びついている。これらを完全に破壊し、GCに委ねる設計にするには、ビジネスロジックそのものを「状態を持たない（Stateless）」方向へリファクタリングする必要がある。
2. DB2埋め込みSQLとの相性: `ALLOCATE` された領域をSQLの `INTO` 句に渡す場合、領域の境界チェック（`SUBSCRIPTRANGE`）を有効にしていないと、バッファオーバーフローがSQL処理を汚染するリスクがある。移行先では、PreparedStatementのバインド変数に正しくマッピングされるよう、型変換の厳密なバリデーションが必要だ。
結びとして
PL/Iの `CONTROLLED` 属性は、古き良き時代の「限られたリソースを極限まで使い倒す」というエンジニアの哲学の結晶だ。現代の潤沢なメモリ環境では不要に見えるかもしれないが、そのスタック管理の概念には、メモリ効率と実行速度を両立させるための深い洞察が隠されている。
もし、貴方が今、このレガシーなコードを紐解いているなら、単に新しい言語に書き換えるだけでなく、その背景にある「なぜそのようなメモリ管理が必要だったのか」という設計思想まで読み解いてほしい。それができるスペシャリストこそが、真に価値ある移行を実現できると私は確信している。
さあ、次のダンプが貴方を呼んでいる。コードの行間にある「汎用機の鼓動」を聞き逃さないように。
