PL/Iの世界へようこそ！「自動変数」という名の頼れる相棒と、メモリの不思議
こんにちは。メインフレームの世界へようこそ。
JavaやCOBOLを触ってきた皆さんにとって、PL/Iという言語は少し「古風で威厳のある古本屋」のように見えるかもしれませんね。でも大丈夫です。PL/Iは、非常に柔軟で、かつ論理的な言語です。
今日は、PL/Iのプログラムを構成する心臓部「PROCEDURE」と、その中でひっそりと、しかし重要な役割を果たす「AUTOMATIC属性」について紐解いていきましょう。
—
1. プログラムの「枠組み」を知る
PL/Iのプログラムは、たとえるなら「家」のようなものです。
まず、全体を包む `PACKAGE`（敷地）があり、その中に実行単位である `PROCEDURE`（部屋）が存在します。
1
/ プログラムの入り口は OPTIONS(MAIN) で指定します /
MY_PROG: PROCEDURE OPTIONS(MAIN);
/ ここに処理を書きます /
PUT SKIP LIST(‘Hello, Mainframe World!’);
END MY_PROG;
`OPTIONS(MAIN)` は、OSに対して「ここがこのプログラムのスタート地点ですよ」と伝える大切な合図です。COBOLの `PROGRAM-ID` やJavaの `public static void main` に相当するものだと考えてください。
—
2. 「AUTOMATIC属性」は、使い捨てのメモ用紙
さて、今回の主役である「AUTOMATIC属性」です。
PL/Iで変数を宣言する際、特に指定しなければ（デフォルトの状態で）、変数は `AUTOMATIC` になります。
これは、「PROCEDUREが呼ばれた瞬間にメモリ上のスタック領域に場所を確保し、PROCEDUREが終わると同時に跡形もなく消え去る」という性質を持っています。
なぜ「自動」なのか？
皆さんがプログラミング中に「この変数はこの処理の間だけ必要だな」と考えることは多いはずです。AUTOMATIC変数は、まさにその「処理の間だけ」を自動的に管理してくれる賢い執事のような存在なんです。
1
CALC_PROC: PROCEDURE;
/ この変数は、CALC_PROCが呼ばれるたびに新しい領域が作られます /
DCL WORK_AREA CHAR(100) AUTOMATIC;
WORK_AREA = ‘計算開始’;
/ 処理終了と共に、WORK_AREAはメモリから解放されます /
END CALC_PROC;
—
3. 再帰呼び出しと「スタックオーバーフロー」という罠
ここで一つ、現場でよく遭遇する落とし穴をお話ししましょう。
「再帰呼び出し（関数が自分自身を呼び出すこと）」を使う場合、AUTOMATIC変数は少しだけ注意が必要です。
再帰呼び出しを行うたびに、そのPROCEDUREの新しい「層」がスタック領域に積み重なっていきます。もし、深すぎる再帰を行ったり、PROCEDURE内で巨大な配列をAUTOMATIC宣言したりすると、スタック領域の許容量を超えてしまい、システムから「異常終了（ABEND）」というお叱りを受けることになります。
イメージしてみましょう
スタック領域は「積み木」です。
1. PROCEDUREが呼ばれる（積み木を置く）
2. 再帰でまた呼ばれる（さらに積み木を置く）
3. 終わるまで積み木は増え続ける
積み木が高くなりすぎると、天井（メモリの限界）にぶつかって崩れてしまいますね。これが「スタックオーバーフロー」の正体です。
—
4. 実務で役立つアドバイス：メモリを大切に
もし皆さんが扱うデータが非常に巨大な場合、AUTOMATIC属性で宣言するのは避けたほうが賢明です。そのような時は、`STATIC`（プログラム実行中はずっと居座る）や、`CONTROLLED`（必要になったら自分でメモリを確保・解放する）といった属性を選択肢に入れてみてください。
【現場の知恵】
- 小さな変数はAUTOMATICでOK！：スタック管理はコンパイラが最適化してくれるので、基本はこれで大丈夫。
- 巨大な配列は要注意：数メガバイトを超えるような変数をAUTOMATICにすると、あっという間にスタックの天井に届いてしまいます。
- 再帰は慎重に：再帰を使うときは「どこで止まるか（終了条件）」を必ず明確にしましょう。
—
最後に：怖がることはありません
PL/Iの文法は確かに少し独特ですが、ルールを一つずつ理解していけば、これほど強力で頼りになる言語はありません。
「AUTOMATIC＝その場で生まれて、その場で消える、清潔なメモリ管理」というイメージだけ持っておけば、日々のコード改修も怖くありませんよ。
もし「この宣言はどういう意味？」と迷ったら、いつでも聞いてくださいね。皆さんのメインフレームエンジニアとしての旅路が、より快適なものになるよう応援しています！
