メインフレームの深淵：CONTROLLEDストレージが織りなす「動的メモリ」の美学
諸君、お疲れ様。今日も今日とてJCLの海を泳ぎ、ABENDコードと睨めっこしていることだろう。
PL/Iという言語は、現代の言語から見れば「化石」のように映るかもしれない。しかし、この言語が持つ「メモリを意のままに操る力」は、金融や公共の基幹システムを40年以上支え続けてきた真のプロフェッショナル・ツールだ。
今日は、若手エンジニアからよく質問を受ける「CONTROLLED（制御）ストレージクラス」について、現場の知見を交えて深く掘り下げていく。なぜこれを使うのか、そしてなぜ慎重に扱うべきなのか。その本質を叩き込んでほしい。
—
1. CONTROLLEDストレージとは何か？
通常の `AUTOMATIC` 変数は、プロシージャが呼ばれた瞬間にスタックに積まれ、終了と同時に消える。対して `CONTROLLED` は、開発者が `ALLOCATE` 文で生成し、`FREE` 文で破棄するまで、その命脈を保ち続ける。
ここで重要なのが、同一変数名に対する世代管理（スタック構造）だ。一つの変数名に対し、複数の実体をスタックのように積み上げることができる。これが、再帰呼び出しや複雑なデータ階層の処理において、PL/Iが最強の武器となる所以だ。
基本的な構文
/i
DCL MY_DATA CHAR(100) CONTROLLED;
ALLOCATE MY_DATA; / 第1世代の生成 /
MY_DATA = ‘FIRST’;
ALLOCATE MY_DATA; / 第2世代をPUSH（第1世代は隠蔽される） /
MY_DATA = ‘SECOND’;
FREE MY_DATA; / 第2世代を破棄し、第1世代が復元される /
—
2. 実践：VSAMレコード処理における世代管理の活用
現場でよくあるのは、VSAMから読み込んだ親レコードの配下にある、可変長の子レコードを一時的に保持するケースだ。`AUTOMATIC` で巨大な配列を確保してメモリを浪費するより、必要な分だけ `ALLOCATE` するのが「スマートなメインフレームエンジニア」の流儀だ。
以下に、VSAMアクセスを伴う実践的なサンプルを示す。
/i
TEST_PROC: PROCEDURE OPTIONS(MAIN);
/ VSAM定義等は適宜DCLされているものとする /
DCL WORK_REC CHAR(80) CONTROLLED;
DCL 1 VSAM_REC,
2 KEY_ID CHAR(4),
2 DATA_PART CHAR(76);
/ ONユニットで例外を捕捉し、安全に終了させるのが鉄則 /
ON ENDFILE(VSAM_FILE) BEGIN;
PUT SKIP LIST(‘処理終了：EOF到達’);
END;
/ メイン処理ループ /
DO WHILE(^ENDFILE(VSAM_FILE));
READ FILE(VSAM_FILE) INTO(VSAM_REC);
/ 条件に応じて動的にメモリを確保（世代管理を活用） /
IF VSAM_REC.DATA_PART ^= ‘ ‘ THEN DO;
ALLOCATE WORK_REC;
WORK_REC = VSAM_REC.DATA_PART;
/ ここで処理を実行（サブプロシージャ呼び出し等） /
CALL PROCESS_SUB(WORK_REC);
/ 処理が終われば必ず解放する。忘れるとメモリリークの元だ /
FREE WORK_REC;
END;
END;
PROCESS_SUB: PROCEDURE(P_DATA);
DCL P_DATA CHAR(80) CONTROLLED;
/ ここではP_DATAとして前の世代を参照可能 /
PUT SKIP LIST(‘PROCESS_SUB: ‘ || P_DATA);
END PROCESS_SUB;
END TEST_PROC;
—
3. 現場で生き残るための「鉄則」
CONTROLLEDストレージを扱う際、以下の3点は必ず守ってほしい。これは、数々の大規模改修で地獄を見た先人たちからの忠告だ。
1. ALLOCATEとFREEは「対」で書け
コードの離れた場所でALLOCATE/FREEを行うと、保守時に必ず悲劇が起きる。可能な限り同一スコープ内、あるいはTRY-CATCH（ONユニット）の管理下で完結させること。
2. スタックの深さを意識せよ
`ALLOCATE` をループ内で無闇に呼ぶと、スタック領域を食いつぶす。スタックの「深さ」を `ALLOCATION(変数名)` ビルトイン関数で監視できることを忘れてはならない。
/i
IF ALLOCATION(WORK_REC) > 10 THEN
SIGNAL ERROR; / 深すぎる場合は異常系へ /
3. ONユニットでの後処理
予期せぬエラーで異常終了した際、確保したメモリが放置されると、後続のジョブステップに影響を与える可能性がある。`ON CONDITION` や `ON ANY` を活用し、ABEND時でも `FREE` が走る仕組みを構築しておくのが、システムアーキテクトとしての矜持だ。
—
最後に：なぜ今、PL/Iなのか
最近の若手は「JavaやPythonの方が楽だ」と言う。確かにそうだ。しかし、ミリ秒単位の応答速度と、数テラバイトのトランザクションを確実に処理し続ける堅牢性は、PL/Iとメインフレームの組み合わせにしか出せない味がある。
CONTROLLEDストレージを使いこなすことは、単にメモリを節約することではない。「リソースを自ら管理し、システム全体を掌握する」というエンジニアとしての姿勢そのものだ。
もし、デバッグ中に「なぜこの変数の値が化けているのか？」と悩んだら、まず世代管理のスタックを疑え。大抵の場合、答えはそこに眠っている。
また何か壁にぶつかったら、いつでもここへ来るといい。我々メインフレームエンジニアは、いつだってコードの海で君を待っている。
