PL/Iの世界へようこそ！「自動変数」とスタック管理の意外な深淵を紐解く
こんにちは。IBMメインフレームの世界へようこそ。COBOLやJavaでバリバリとコードを書いてきた方にとって、PL/Iという言語は、どこか古風で、それでいて驚くほど自由奔放な「魔法の道具箱」のように見えるかもしれません。
今日は、PL/Iを学び始めた方が最初に少し戸惑う、「AUTOMATIC属性」と「スタック領域の管理」についてお話しします。難しく聞こえるかもしれませんが、現場で長年この言語と付き合ってきた私が、肩の力を抜いて解説しますね。
—
1. そもそもPL/Iには「予約語」がない？
まず、PL/Iの非常にユニークな点から触れておきましょう。JavaやCOBOLには「if」や「while」といった絶対に変数名に使えない「予約語」がありますよね。
ところが、PL/Iには原則として予約語が存在しません。例えば、こんなコードが書けてしまいます。
IF = 10; / 変数名にIFを使っても怒られません /
THEN = 20; / 変数名にTHENを使っても大丈夫 /
IF IF > THEN THEN = IF; / カオスですが、コンパイラは正しく理解します /
「えっ、何でもありなの？」と驚くかもしれませんが、これはPL/Iが「文脈」から判断する賢い言語だからです。とはいえ、可読性を考えると真似は禁物ですよ（笑）。この「自由さ」こそが、PL/Iの奥深さの入り口なんです。
—
2. 「AUTOMATIC属性」って何者？
さて、本題のAUTOMATIC（自動）属性です。これは、プロシージャ（関数）が呼び出されるたびに「新しく生まれ」、プロシージャを抜けると「消えてなくなる」変数のことです。
Javaでメソッド内のローカル変数を宣言するのと感覚は同じですが、PL/Iでは明示的に `AUTOMATIC` と書く（あるいはデフォルトなので省略する）ことができます。
PROCEDURE_NAME: PROCEDURE;
/ この変数は、このプロシージャが呼ばれるたびにスタック上に確保されます /
DCL WORK_AREA CHAR(80) AUTOMATIC;
WORK_AREA = ‘HELLO MAIN FRAME’;
/ 処理終了後、WORK_AREAは自動的に解放されます /
END PROCEDURE_NAME;
ここでのポイントは、「スタック領域」というメモリの使い道です。プロシージャに入るたびに「はい、あなたの作業机（スタック）はここですよ」と新しい場所が割り当てられ、帰る時にはその机ごと綺麗に片付けられる……そんなイメージを持ってください。
—
3. 再帰呼び出しとスタックの「限界」
ここで注意が必要なのが、「再帰呼び出し（Recursive Call）」です。自分自身を呼び出すような処理を行うと、どうなるでしょうか？
プロシージャが再帰するたびに、新しい `AUTOMATIC` 変数がスタック上に積み上がっていきます。まるで、パズルを組み立てる途中で、終わらないうちに次のパズルを渡されるような状態ですね。これが繰り返されると、いずれスタック領域が溢れてしまい、有名な 「S0C4（ストレージ保護違反）」 やスタックオーバーフローが発生します。
実践的なコード例：再帰とスタック
RECURSIVE_PROC: PROCEDURE(N) RECURSIVE;
DCL N FIXED BIN(15);
/ 再帰のたびに、この変数が別の領域としてスタックに積み上がります /
DCL LOCAL_VAL FIXED BIN(31) AUTOMATIC;
IF N > 0 THEN DO;
LOCAL_VAL = N 10;
CALL RECURSIVE_PROC(N – 1); / 再帰呼び出し /
END;
END RECURSIVE_PROC;
もし、この `LOCAL_VAL` が非常に巨大な配列だったり、再帰の深さが深すぎたりすると、メモリが足りなくなります。基幹システムでは、安易な再帰は厳禁とされることが多いのはこのためです。
—
4. 現場からのアドバイス：どう使い分けるか
PL/Iでのデータ設計において、私が皆さんにアドバイスしたいのは以下の2点です。
1. 小さなデータはAUTOMATICでOK:
関数内でしか使わない一時的な作業用変数は、`AUTOMATIC`（デフォルト）に任せて大丈夫です。スタック管理はコンパイラとOSが優秀にこなしてくれます。
2. 大きな領域はSTATIC属性を検討:
もし数百キロバイトにもなるような巨大な配列を扱うなら、`STATIC`（静的）属性を検討してください。これはプログラム実行中ずっとメモリに居座る変数です。スタックを圧迫しないので、システム全体の安定感が増しますよ。
—
まとめ
PL/Iの `AUTOMATIC` 変数は、プロシージャのライフサイクルに寄り添う「期間限定の親切なパートナー」です。予約語がないという自由な気質に少し戸惑うかもしれませんが、「どこで生まれて、どこで消えるか」さえ意識していれば、これほど頼もしい言語はありません。
もし、メインフレームのログでスタック関連のエラーに出くわしても、怖がる必要はありません。それは「あなたのコードが、今どの程度のメモリを必要としているか」を教えてくれているだけです。一つずつ紐解いていけば、必ず解決の糸口は見つかりますよ。
それでは、また次回のレガシー探訪でお会いしましょう！何か気になることがあれば、いつでも聞いてくださいね。
