【PL/Iの真髄】CONTROLLED属性による動的メモリ管理と、現場で生き残るための「スタック」との使い分け
メインフレームの現場で長くPL/Iを触っていると、「なぜこのプログラムはこんなにメモリを食うのか」あるいは「なぜこのポインタが意図しない場所を指すのか」という壁にぶつかることが必ずある。
COBOLの固定的なデータ領域に慣れた若手が、PL/Iの`CONTROLLED`属性に出会うと、その自由度の高さゆえに混乱することが多い。今日は、単なるマニュアルの解説ではなく、バッチの安定稼働とリソース効率を左右する「動的メモリ管理」の深淵について解説しよう。
1. なぜ「CONTROLLED」なのか？
PL/Iには、静的（STATIC）、自動（AUTOMATIC）、そして制御（CONTROLLED）というストレージクラスがある。`AUTOMATIC`はブロックに入ると生成され、出ると消える。これはスタック管理だ。しかし、巨大なVSAMレコードを読み込む際や、実行時までデータ件数がわからないような場合、スタックのサイズ制限（いわゆるストレージオーバー）に怯えながら開発するのは非効率だ。
`CONTROLLED`属性は、プログラマが明示的に`ALLOCATE`と`FREE`を制御する。これにより、必要な時に必要な分だけヒープ領域からメモリを確保できる。これは、大規模バッチにおけるメモリ節約の切り札だ。
2. 実践：ALLOCATEとFREEの正しい作法
まずは、基本的な構文を見てほしい。ポイントは、`ALLOCATE`した後は必ず責任を持って`FREE`することだ。この「責任の放棄」が、本番稼働中のメモリリークを引き起こし、深夜の呼び出しの原因となる。
/i
/ — サンプル：可変長データ領域の動的確保 — /
DCL DATA_BUFFER CHAR(32767) BASED(P_BUFFER);
DCL P_BUFFER PTR;
/ 制御される領域の宣言 /
DCL MY_RECORD_STORAGE CHAR(1024) CONTROLLED;
/ 処理開始 /
ALLOCATE MY_RECORD_STORAGE;
/ 読み込み処理（例えばVSAMアクセス） /
CALL READ_VSAM_DATA(MY_RECORD_STORAGE);
/ 領域の解放 /
FREE MY_RECORD_STORAGE;
現場の知恵：スタック管理との違い
スタック（AUTOMATIC）は、再帰呼び出しやサブルーチン呼び出しにおいて非常に高速だが、領域を確保しすぎると「Storage Overflow」が発生する。一方、`CONTROLLED`はヒープを消費する。大規模なワークエリアを確保する場合は、スタックを温存するために`CONTROLLED`を使うのが、ベテランの設計判断だ。
3. ONユニットとメモリ解放の罠
ここで一つ、現場でよくある失敗談を共有しよう。`ALLOCATE`した後に、エラーハンドリング（ONユニット）で`GOTO`を使って処理を抜けてしまうケースだ。
/i
ON CONDITION(FATAL_ERROR) BEGIN;
/ ここでFREEを忘れると、スタックは戻ってもヒープが残る /
PUT SKIP LIST(‘FATAL ERROR OCCURRED’);
STOP;
END;
ALLOCATE MY_RECORD_STORAGE;
/ もしここで例外が発生し、ONユニットへ飛ぶとメモリリークが確定する /
CALL DO_SOMETHING(MY_RECORD_STORAGE);
FREE MY_RECORD_STORAGE;
例外発生時にも確実に`FREE`を走らせるためには、`FINISH`条件のONユニットを利用するなどの工夫が必要だ。あるいは、設計段階で「メモリの所有権」をどこに持たせるかを明確にすること。これが、保守性の高いコードを書くための鉄則である。
4. 識別子の命名規則とPL/Iの自由度
PL/Iの素晴らしい点（そして恐ろしい点）は、予約語が極めて少ないことだ。`IF`や`THEN`さえも変数名に使えてしまう（推奨はしないが）。
/i
/ こんな定義も構文上は通ってしまう（絶対にやるな！） /
DCL IF CHAR(10);
しかし、実務では「大文字・アンダースコア・プレフィックス」の命名規則を徹底すべきだ。特に`CONTROLLED`変数には`C_`というプレフィックスを付けるなどして、一目で「あ、これは動的確保が必要なやつだ」と分かるようにしておくこと。数年後の自分が改修する際、この配慮が命を救うことになる。
結びに：なぜ今、PL/Iを極めるのか
最近はJavaやPythonなどのモダンな言語が主流だが、銀行や公共機関の根幹を支えるメインフレームでは、PL/Iの高度なポインタ操作やメモリ制御能力は、今なお現役の「最強の武器」だ。
メモリを直接操作できるということは、それだけシステムのリソースを極限まで絞り出せるということ。`ALLOCATE`と`FREE`を制する者は、バッチの実行速度と安定性を制する。
後輩の諸君、マニュアルを写すのではなく、コードがメモリ上でどう動いているかを想像してほしい。何かあれば、いつでも相談に乗る。大規模バッチの改修は、時に格闘技だが、正しい技術があれば必ず突破できる。
健闘を祈る。
