メインフレームの「隠れ家」：PL/IのAUTOMATIC変数は、なぜ再帰で泣きを見るのか？
こんにちは。メインフレームの世界へようこそ。
Javaのガベージコレクションや、COBOLのWORKING-STORAGE SECTIONに慣れ親しんだ皆さんが、PL/Iのコードを初めて見たとき、「一体これは何なんだ？」と戸惑うのは当然のことです。
特に、PL/Iの「ストレージクラス」という概念は、一見すると魔術のように見えるかもしれません。今回は、皆さんが最も遭遇しやすく、かつバグの温床になりやすい「AUTOMATIC変数」と「再帰呼び出し（Recursive Call）」の危うい関係について、現場の視点から紐解いていきましょう。
—
1. そもそも「AUTOMATIC」って何者？
PL/Iにおいて、明示的に指定しない限り、PROCEDURE内で宣言される変数はデフォルトで `AUTOMATIC` 属性を持ちます。
これは、Javaでいえば「メソッド内で宣言したローカル変数」と同じです。その手続き（PROCEDURE）が呼ばれた瞬間にスタック領域に居場所が作られ、手続きが終了すると同時に跡形もなく消える、いわば「使い捨てのメモ帳」のような存在ですね。
1
MY_PROC: PROCEDURE;
/ この変数はAUTOMATIC。MY_PROCが呼ばれるたびにスタックに生成される /
DCL WORK_AREA CHAR(100);
/ 処理が終わればWORK_AREAは解放される。清潔そのものですね /
END MY_PROC;
COBOLのデータ部（WORKING-STORAGE）はプログラム実行中ずっと居座る「共有の巨大な掲示板」ですが、PL/IのAUTOMATICは「呼び出しごとに配られる付箋」だとイメージしてください。
—
2. 再帰呼び出しと「スタック」の限界
さて、ここからが本題です。再帰呼び出し（自分自身を呼び出す処理）を行うとき、この「付箋」の仕組みが牙を剥くことがあります。
再帰呼び出しが発生するたびに、PL/Iは新しいスタックフレームを確保します。呼び出しが深くなればなるほど、スタック領域には「前の呼び出しの変数」が積み重なっていきます。
現場でよくある「スタックオーバーフロー」の構図
「再帰で複雑なツリー構造を解析しよう」と意気込んだものの、データが想定より深く、再帰回数が限界を超えてしまった……。そんな時、メインフレームは無情にも「ストレージ不足」でABEND（異常終了）を叩きつけます。
1
RECURSIVE_PROC: PROCEDURE RECURSIVE;
DCL LARGE_BUFFER CHAR(32000) AUTOMATIC; / これが再帰のたびにスタックを圧迫！ /
DCL COUNTER FIXED BIN(31);
/ 再帰の深さが1000回になれば、32MBものスタックが食いつぶされます /
/ メインフレームのスタック領域は意外と狭いのです /
IF COUNTER < MAX_DEPTH THEN DO; CALL RECURSIVE_PROC; END; END RECURSIVE_PROC; このコードの何が怖いか分かりますか？ `LARGE_BUFFER` という大きな領域をAUTOMATICで宣言している点です。再帰のたびに32KBがスタックの肥やしとなり、あっという間にスタックの天辺に到達してしまうのです。 ---
3. トラブルを未然に防ぐための「現場の知恵」
「じゃあ、再帰は使っちゃダメなの？」と思われるかもしれません。いえ、そんなことはありません。適切に扱えば、PL/Iの再帰は非常に強力な武器になります。
知恵その1：大きなデータはAUTOMATICに置かない
巨大な配列や構造体を再帰内で使うなら、`STATIC`（静的確保）や、あるいはヒープ領域を使う制御を検討しましょう。スタックを汚さないことが、安定稼働の鉄則です。
知恵その2：再帰の深さを物理的に制限する
「再帰がどこまで深くなるか分からない」という設計は、メインフレームでは禁忌です。必ずカウンタを設け、再帰の上限をハードコードあるいは定数で管理してください。
知恵その3：コンパイラオプションの確認
もし皆さんの環境で「どうしても再帰が必要だがスタックが足りない」という事態に陥ったら、コンパイラオプションの `STACK` サイズを見直すのも一つの手です。ですが、これはあくまで対症療法。根本的な設計を見直すのが、真のプロフェッショナルの仕事です。
—
最後に：PL/Iは怖くない
初めてPL/Iに触れると、その独特な文法やメモリ管理の厳格さに驚くかもしれません。しかし、これらは全て「計算機資源が貴重だった時代」から受け継がれた、非常に合理的で計算コストを可視化しやすい設計に基づいています。
AUTOMATIC変数のライフサイクルさえ理解してしまえば、皆さんのプログラムはもっと洗練され、メインフレーム上で静かに、そして力強く動き続けるはずです。
もし分からないことがあれば、いつでも質問してください。このレガシーな世界の霧を、一緒に晴らしていきましょう。それでは、次回の記事でお会いしましょう！
