【テクニカル・上級編】CONTROLLED属性によるスタック管理とALLOCATE/FREEのスタック挙動 – PL/Iの基本構文とデータ制御実践ガイド

はじめに：PL/I「CONTROLLED変数」という名の諸刃の剣

基幹システムの現場で長年生き抜いてきたシニアアーキテクトなら、深夜の稼働監視画面に突如として点灯する「S30Cアベンド（ストレージ不足）」の赤い文字に、背筋が凍るような思いをした経験が一度や二度はあるはずだ。

現代のJavaやC#のエンジニアであれば、ガーベージコレクタ（GC）がすべてをよしなにやってくれる世界観に慣れ親しんでいる。しかし、われわれが対峙するIBMメインフレームのPL/I世界において、メモリ管理の責任は常にプログラマ、そしてシステムアーキテクトの肩に重くのしかかっている。

特に、今回焦点を当てる `CONTROLLED`属性 と、それを制御する `ALLOCATE` / `FREE` の仕組みは、PL/Iが持つ数ある強力な機能の中でも、最も美しく、そして一歩間違えればシステムを破滅へと導く危険な諸刃の剣だ。

C言語の `malloc` / `free` とは一線を画す、PL/I独自の「スタック構造による世代管理（Generation Management）」の本質を、コンパイラの内部挙動や実務のエッジケースを交えながら徹底的に解き明かしていこう。

—

1. CONTROLLED変数の本質：スタック構造と世代管理のメカニズム

PL/Iの `CONTROLLED` 変数（以下、CTL変数）は、単なる動的メモリ割り当ての道具ではない。その本質は、「同一の変数名に対して、LIFO（Last-In, First-Out：後入先出）のスタック構造を持つ複数の世代（Generation）を動的に積み重ねる」点にある。

以下のコード例を見てほしい。

DCL WK_REC CHAR(100) CONTROLLED; / CONTROLLED属性の宣言 /

/ 1回目の割り当て（第1世代の生成） /
ALLOCATE WK_REC;
WK_REC = ‘FIRST GENERATION’;
DISPLAY(‘ジェネレーション1: ‘ || WK_REC);

/ サブルーチン等の内部スコープを想定した入れ子のブロック /
BEGIN;
/ 同名のCTL変数に対する2回目の割り当て（第2世代の生成） /
/ これにより、第1世代はスタックの奥底に隠蔽（プッシュ）される /
ALLOCATE WK_REC;
WK_REC = ‘SECOND GENERATION’;
DISPLAY(‘ジェネレーション2: ‘ || WK_REC);

/ 第2世代の解放（ポップ） /
/ 解放すると、自動的に隠蔽されていた第1世代が表舞台に戻る /
FREE WK_REC;
END;

DISPLAY(‘ポップ後のジェネレーション1: ‘ || WK_REC);
FREE WK_REC; / 最終世代の解放 /

コンパイラから見たスタックの裏側

コンパイラ（Enterprise PL/Iコンパイラなど）は、`CONTROLLED` 変数に対して、実行時スタック上にアンカーブロック（Anchor Block）と呼ばれる制御構造を割り当てる。
`ALLOCATE` が実行されるたびに新しいメモリ領域がヒープ（またはスタックプール）から切り出され、既存のアンカーにチェーニング（LIFO構造で接続）される。

ここで重要なのは、「現在アクセス可能なのは常に最新の世代（Top of Stack）のみである」という点だ。`FREE` を実行すると、最新の世代が破棄され、その直前に隠れていた古い世代が再び有効になる。この挙動は、再帰呼び出し（Recursive Call）を行うプログラムにおいて、ローカル変数を安全に退避・復元するための強力な武器となる。

—

2. ポインタとベース変数（POINTER & BASED）との決定的な違い

マイグレーション案件などでよく見かけるアンチパターンが、「C言語のポインタ感覚で `BASED` 変数とポインタを使い回し、メモリリークや不正参照の嵐を引き起こす」というケースだ。

ここで `CONTROLLED` と `BASED` の挙動を明確に比較しておこう。

もし、あなたが設計しているバッチプログラムが「単に可変長のワークエリアを確保したいだけ」であれば、`BASED` 変数よりも `CONTROLLED` 変数を選択する方が、コンパイラによる世代管理の恩恵を受けられるため、圧倒的に安全性が高い。

—

3. 実務の現場で遭遇する「地雷」とエッジケース対策

では、実際の基幹システムやオンライン（CICS）、データベース（DB2）連携の現場において、どのようなトラブルが発生し得るのか。実務的な視点で深掘りする。

① 埋め込みSQL（DB2）との組み合わせにおける罠

カーソル処理や動的SQLのフェッチにおいて、`CONTROLLED` 変数をバッファとして使う設計を見かけることがある。しかし、ここで注意すべきは 「PL/Iの管理するCTL変数のアドレスが、DB2のプリコンパイラ（SQL言語プロセッサ）の期待するライフサイクルとズレる」 現象だ。

特に、CICSのタスクライフサイクル内で `ALLOCATE` したまま正常な `FREE` を行わずにスレッドがプーリングされた場合、世代の不整合やストレージの断片化（Fragmentation）を引き起こし、やがて `S0C4`（保護例外）や `S30C` アベンドへと直結する。DB2ホスト変数としてCTL変数を使用する場合は、同一スコープ内で確実に `ALLOCATE` と `FREE` が対になっていることを、コードレビューで血眼になって確認する必要がある。

② パックデシマル（FIXED DECIMAL）の内部符号反転バグとCTL変数の再割り当て

CTL変数の中に `FIXED DECIMAL` 項目を定義し、ループ内で何度も `ALLOCATE` と `FREE`（あるいは再割り当て）を繰り返すロジックにおいて、古い世代のメモリ領域が初期化されないまま（あるいは誤ったポインタ操作の巻き添えで）残存した場合、符号ニブル（ゾーン部の最下位4ビット）が破壊される事故が発生する。

メインフレーム特有のS390/Zアーキテクチャでは、パックデシマルの符号不正（例：`C`, `D`, `F` 以外の値が入り込む）は一発で データ例外（S0C7アベンド） を引き起こす。
CTL変数を再利用する際は、単に `ALLOCATE` するだけでなく、必ず初期化（INITIAL値の指定や明示的な代入）を行う防衛的プログラミングが不可欠である。

—

4. ダンプ解析の現場から：S30C/S0C4アベンドの看破方法

万が一、生産機でストレージ関連のアベンドが発生した際、システムアーキテクトが頼るべきは IPCS（Interactive Problem Control System） を用いたコアダンプ解析だ。

1. トランスラート結果の確認：
リスト出力（LISTオプション）を確認し、該当変数がどのオフセットでCTLアンカーに結びついているかを特定する。
2. ストレージリークの兆候：
ダンプ内のヒープ領域（Subpool 2またはユーザーヒープ）をスキャンし、同一サイズのブロックが `FREE` されずに単調増加している場合、ループ内のどこかで `ALLOCATE` に対する `FREE` が漏れている。
3. 多重フリー（Double Free）の検知：
すでに解放済みのCTL変数に対して再度 `FREE` を実行した場合、PL/Iのランタイムライブラリ（CEEEV003など）が検知してエラーメッセージを出力するが、最悪の場合は制御ブロックが破壊され、原因不明の `S0C4` や `S0C1` として表出する。

—

5. モダナイゼーション（Java/C#移行）への処方箋

もし、あなたがこのレガシーなPL/IシステムをJavaやC#へマイグレーションする立場にあるなら、この `CONTROLLED` 変数の仕様をどのように現代の言語に翻訳すべきか、頭を悩ませていることだろう。

Javaへのマッピング：

JavaにはPL/Iのような「同名変数のLIFOスタック世代管理」という言語機能は直接存在しない。これを安全に再現するためには、`Deque`（両端キュー／スタック）を用いたオブジェクトの明示的なプッシュ・ポップ構造設計が必要となる。また、ローカルスコープであれば、メソッドの再帰呼び出しとローカル変数の自動スタックがそのままJavaのコールスタックに対応するため、多くの場合、Javaの標準的なメソッドスコープ変数へのリファクタリングで十分に代替可能だ。

C#へのマッピング：

C#の `stackalloc` や `Span` はメモリ効率を追求する上で強力だが、PL/Iの動的世代管理の挙動とは異なる。ビジネスロジックの意図（なぜここで世代を分ける必要があったのか）を解体し、オブジェクト指向のスコープ管理（`using` ステートメントによる破棄など）へと昇華させるアーキテクチャ設計が求められる。

—

おわりに

PL/Iの `CONTROLLED` 属性は、一見すると古臭いレガシーの遺物に見えるかもしれない。しかし、その裏側にある挙動は、限られたメインフレームのリソースを極限まで効率的に使い倒すための、先人たちの知恵と美学に満ちている。

基幹システムの改修やマイグレーションを成功させるカギは、単にコードを別の言語に機械的に置き換えることではない。そのコードが語る「メモリと時間の歴史」を深く理解し、意図された設計思想をモダンなシステムへと正確に継承することなのだ。

次回のバッチ改修やトラブルシューティングの際には、ぜひこのスタック挙動のメカニズムを思い出してほしい。あなたのシステムが、今日も堅牢に稼働し続けることを願って。