メインフレームの深淵：AUTOMATIC変数のライフサイクルとスタック破壊を回避する流儀
若手のエンジニアからよく聞かれる質問がある。「なぜPL/Iには予約語が存在しないのか？」「AUTOMATIC変数を多用してスタックを飛ばしてしまうのはなぜか？」と。
これらは、メインフレームの基幹バッチで数百万行のコードを読み解いてきた者にとって、避けては通れない「PL/Iの美学と罠」だ。今日は、現代のマイグレーションや保守の現場でも頻発する、スタック管理の極意について語ろう。
1. 予約語なき言語の教訓：自由と混沌の境界線
PL/Iの設計思想において、`IF`や`THEN`といったキーワードは「文脈依存」で解釈される。つまり、`IF = 10;` と書けば、コンパイラは最初の`IF`を変数名として扱う。これは非常に強力だが、同時にコードの可読性を著しく損なう諸刃の剣だ。
現場のコーディング標準では、「予約語的な識別子は避ける」ことが鉄則だ。コンパイラは動くかもしれないが、保守担当者が「これは変数なのか構文なのか？」と悩む時間は、システム開発において最も無駄なコストになる。命名規則は、技術的な正しさよりも「他者への配慮」を優先せよ。
2. AUTOMATIC変数の生存圏（ライフサイクル）
`AUTOMATIC`属性は、プロシージャが呼び出された際にスタック領域（あるいはそれ相当のメモリ領域）に確保され、終了時に解放される。この自動変数の管理は、OS（z/OS）が提供するレジスタベースのスタックフレーム管理に強く依存している。
特に注意すべきは、再帰呼び出し（Recursion）だ。VSAMアクセスや複雑なONユニット処理の中で再帰を用いる際、各スタックフレームはそれぞれ独立して変数を保持する。これが積み重なると、あっという間にスタックオーバーフローを引き起こし、致命的な「S0C4」や「S80A」を誘発する。
3. 実践コード：VSAMアクセスとスタック管理の実際
大規模バッチの改修現場を想定し、VSAMファイルからの読み込みと再帰的な処理を組み合わせたコード例を見てみよう。
/i
/==================================================================/
/ サンプル：VSAM読み込みと再帰的な階層構造処理 /
/==================================================================/
PROCESS OPTIONS(MAIN, REORDER);
TEST_PROC: PROC OPTIONS(MAIN);
/ 巨大な構造体を自動変数で宣言するとスタックを圧迫するため注意 /
DCL VSAM_RECORD CHAR(1024) AUTOMATIC;
DCL EOF_FLAG BIT(1) INIT(‘0’B);
/ ONユニットによる例外制御 /
ON ENDFILE(VSAM_FILE) EOF_FLAG = ‘1’B;
OPEN FILE(VSAM_FILE) INPUT;
DO WHILE(^EOF_FLAG);
READ FILE(VSAM_FILE) INTO(VSAM_RECORD);
IF ^EOF_FLAG THEN DO;
/ 再帰呼び出しを行う関数をコール /
CALL RECURSIVE_PROCESS(SUBSTR(VSAM_RECORD, 1, 10));
END;
END;
CLOSE FILE(VSAM_FILE);
/ — 再帰処理関数 — /
RECURSIVE_PROCESS: PROC(DATA_KEY) RECURSIVE;
DCL DATA_KEY CHAR(10) PARM;
/ 自動変数は再帰の度にスタックを消費する /
DCL WORK_BUF CHAR(256) AUTOMATIC;
/ BUILTIN関数による処理 /
IF LENGTH(TRIM(DATA_KEY)) > 0 THEN DO;
/ ここで深い階層の再帰が発生するとスタックが枯渇する /
/ 必要に応じてSTATICやCONTROLLED属性を検討すること /
END;
END RECURSIVE_PROCESS;
END TEST_PROC;
4. 現場でトラブルを回避するための「三つの戒め」
1. スタックを過信しない:
`AUTOMATIC`変数は便利だが、メガバイト級のバッファをスタック上で確保してはならない。巨大なデータ領域が必要な場合は、`CONTROLLED`属性を使用するか、`GET MAIN`で動的メモリを獲得する手法に切り替えろ。
2. ONユニットの戻り先を意識せよ:
`ON`ユニット内で`GOTO`を使って制御フローを強制的に戻すと、スタックフレームのクリーンアップが正しく行われない可能性がある。これは「メモリリーク」ならぬ「スタックの断片化」を招く。原則として`SIGNAL`を適切に活用し、正常な終了フローを辿るべきだ。
3. BUILTIN関数の積極活用:
`SUBSTR`、`INDEX`、`TRIM`といった組み込み関数は、機械語レベルで最適化されている。自前でループを回して文字列処理を行うよりも、スタック消費を抑え、CPUサイクルを節約できる。
結びとして
メインフレームの保守は、過去のエンジニアたちが積み上げた「知恵の塔」を維持する作業だ。`AUTOMATIC`変数をどう扱うか、という小さな選択が、数年後のバッチ処理の安定性を左右する。
もし君が今、原因不明の異常終了に悩んでいるなら、まずはスタックの深さを疑え。プロシージャの入り口と出口で、スタックがどう振る舞っているか――それを想像できるようになった時、君は真のメインフレームアーキテクトへの道を一歩進んだことになる。
コードは嘘をつかない。だが、PL/Iはその自由さゆえに、書き手の品格をそのまま写し出す鏡なのだ。
