こんにちは！メインフレームの世界へようこそ。
JavaやCOBOLといったモダン、あるいはビジネス向けのプログラミング言語を一通り経験された方にとって、IBMメインフレームの「PL/I（ピーエルアイ）」は、少しユニークで、時におっかない黒魔術のように見えるかもしれません。
特に「ポインタ」や「メモリ管理」と聞くだけで、C言語時代のメモリリークの悪夢を思い出し、冷や汗が出てしまう方もいらっしゃるのではないでしょうか？
でも、安心してくださいね。PL/Iの `CONTROLLED` 属性と `ALLOCATE` / `FREE` を使った動的メモリ管理は、基本のルールさえ掴んでしまえば、決して怖いものではありません。今日は、JavaのガベージコレクションやCOBOLの固定長の世界とは一味違う、PL/Iならではのスマートなメモリの操り方を、一緒にゆっくり紐解いていきましょう。
—
1. 他言語からの挑戦者たちが驚く、PL/Iの「予約語がない」世界
本題に入る前に、PL/Iのちょっと面白い（そして最初は戸惑う）特徴についてお話しさせてください。
JavaやCOBOLには、変数名として使ってはいけない「予約語（キーワード）」がたくさんありますよね。例えば `IF` や `DATA` といった単語をそのまま変数名にすると、コンパイラに怒られてしまいます。
しかし、PL/Iには原則として予約語というものが存在しません。
どういうことかと言うと、PL/Iは文脈（コンテキスト）から「あ、これは命令だな」「ここは変数名だな」と賢く判断してくれます。そのため、以下のような驚きのコードも（やろうと思えば）コンパイルを通すことができます。
1
/ PL/Iのちょっとユニークな世界観の例 /
DECLARE IF FIXED BIN(31); / 「IF」という名前の数値型変数 /
IF = 10; / 変数IFに10を代入 /
「えっ、じゃあ `IF` 文はどうなるの？」と思われるかもしれませんが、そこは長年の実績を持つメインフレームのコンパイラ。人間が読むときと同じように文脈を理解するので、正しく解釈してくれます。
とはいえ、現場の保守性を考えると、わざわざこんな紛らわしい名前をつける人はいません（笑）。ただ、「PL/Iはルールがガチガチに固定された融通の利かない言語に見えて、実は懐が深いんだな」と、心の片隅に置いておいてくださいね。
—
2. スタックとは違う！PL/Iのヒープ管理：`CONTROLLED` 属性とは？
さて、ここからが今回のメインテーマです。
プログラムの中でデータを扱うとき、通常は `AUTOMATIC`（自動割り当て）属性が使われます。これはJavaでいうメソッド内のローカル変数のようなもので、そのブロックに入ったときにメモリが確保され、抜けたら自動的に消えてなくなります。
しかし、こんな要望が出てきたことはありませんか？
- 「データが何件来るか、プログラムを実行するまで全く分からない…」
- 「必要な時だけメモリをデカく確保して、使い終わったら綺麗に片付けたい…」
ここで登場するのが、`CONTROLLED`（コントロールト）属性です。
`CONTROLLED` 属性を持つ変数は、JavaやC言語でいう「ヒープ領域」のような場所で、あなたの意のままに（明示的に指示したタイミングでしか）メモリ上に現れません。
イメージしてみましょう
`CONTROLLED` 変数は、いわば「折りたたみ式のマイテント」のようなものです。
普通（AUTOMATIC）の荷物は部屋に最初から置いてありますが、テントは普段、袋にしまわれていて部屋のスペースを圧迫しません。「さあ、キャンプを始めるぞ！」と号令をかけたとき（`ALLOCATE`）に初めて組み立てられ、「片付けよう」と号令をかけたとき（`FREE`）に綺麗に畳まれて消えていきます。
—
3. 実践！`ALLOCATE` と `FREE` で動的メモリを操る
百聞は一見に如かず。実際に `CONTROLLED` 属性を使ったPL/Iのコードを見てみましょう。
基幹システムのバッチ処理などでよく見られる、可変長のデータを安全に取り扱う実用的なサンプルです。
1
/ ========================================================== /
/ CONTROLLED属性による動動的メモリ管理のサンプルプログラム /
/ ========================================================== /
MEMBER_MGMT: PROC OPTIONS(MAIN);
/ 1. CONTROLLED属性を持つ構造体の宣言 /
/ まだこの時点ではメモリは確保されていません（名前の登録だけ） /
DECLARE 1 MBR_REC CONTROLLED,
2 MBR_ID CHAR(5), / 会員ID /
2 MBR_NAME CHAR(30), / 会員名 /
2 MBR_POINT FIXED BIN(15); / 保有ポイント /
DIRECT_SIZE FIXED BIN(31) INIT(100); / 確保したいサイズ（例） /
/ 2. ALLOCATE文でメモリを動的に獲得する（テントを組み立てる！） /
DISPLAY(‘— メモリの動的割り当てを開始します —‘);
ALLOCATE MBR_REC;
/ 3. 確保したメモリ領域に値を設定する /
MBR_ID = ‘A0001’;
MBR_NAME = ‘山田 太郎’;
MBR_POINT = 1500;
/ 設定されたデータの確認出力 /
DISPLAY(‘会員ID : ‘ || MBR_ID);
DISPLAY(‘会員名 : ‘ || MBR_NAME);
DISPLAY(‘保有ポイント: ‘ || LTRIM(CHAR(MBR_POINT)));
/ 4. FREE文でメモリを明示的に解放する（テントを畳む！） /
/ これを忘れるとメモリリークの元になります /
FREE MBR_REC;
DISPLAY(‘— メモリを安全に解放しました —‘);
END MEMBER_MGMT;
どうでしょうか？コードの流れはとてもシンプルですよね。
ポイントは、`DECLARE` しただけではメモリは確保されず、`ALLOCATE MBR_REC;` を実行した瞬間にOS（正確にはPL/Iランタイム環境）からメモリが切り出されるという点です。
—
4. レガシー現場の落とし穴：メモリリークを防ぐ管理戦略
ここで、シニアアーキテクトからの大切なアドバイスです。
動的メモリ管理の最大の敵、それは「メモリリーク（メモリの切りっぱなし）」です。
Javaであれば使わなくなったオブジェクトはGC（ガベージコレクション）が勝手に回収してくれますが、PL/Iの世界（特に古いバージョンや特定の環境）では、あなたが責任を持って後始末をしなければなりません。
⚠️ やってはいけない「二重割り当て（Stacked Allocation）」の罠
`CONTROLLED` 変数のユニークな（そして少し厄介な）仕様として、同じ変数に対して `ALLOCATE` を連続して実行できるという点があります。
1
ALLOCATE MBR_REC; / 1回目：メモリ確保 /
/ …何か処理… /
ALLOCATE MBR_REC; / 2回目：さらに上書き（古いメモリは背後に隠れる） /
これをやってしまうと、1回目に確保したメモリ領域へのアドレスが分からなくなってしまい、プログラムが終了するまで二度と解放できなくなります。これがPL/Iにおける代表的なメモリリークのパターンのひとつです。
💡 現場で使える安全対策の鉄則
1. 「1つの ALLOCATE には必ず 1つの FREE をセットにする」
原則として、同じサブルーチンやブロック内で確保と解放を完結させるのが最も安全です。
2. スタックのように積み上がっているか確認する
もし複数回 `ALLOCATE` した場合は、`FREE` も同じ回数だけ実行しなければ、一番底にある最初のメモリは解放されません。
3. ALLOCATE状態をチェックするビルトイン関数を使う
PL/Iには、その変数が現在メモリ上に存在するかどうかを調べる `ALLOCATION` という便利な関数があります。不安な時は以下のようにガードをかけましょう。
1
/ すでにメモリが割り当てられていないか確認してから解放する /
IF ALLOCATION(MBR_REC) > 0 THEN
FREE MBR_REC;
この `ALLOCATION(変数名)` を覚えておくだけで、バッチ処理の異常終了時におけるメモリ管理の堅牢性が劇的に向上します。ぜひ実務のコードでも取り入れてみてくださいね。
—
おわりに
PL/Iの `CONTROLLED` 属性と動的メモリ管理、いかがでしたでしょうか？
「レガシー言語」と聞くと難解なルールに縛られているイメージを抱きがちですが、その実態は、プログラマがメモリのライフサイクルをきめ細やかにコントロールできる、非常に合理的でパワフルな仕組みです。
JavaやCOBOLの経験があるあなたなら、その仕組みの本質を理解するのに時間はかからないはずです。「テントを立てたら、必ず綺麗に畳んで片付ける」。このシンプルなアウトドアのルールさえ守れば、PL/Iでのプログラミングは怖くありません。
日々のメインフレーム開発やマイグレーション作業において、この記事があなたの不安を解消し、少しでも「PL/Iって面白いかも」と感じるきっかけになれば幸いです。それでは、次回のレガシー探訪もお楽しみに！
