導入
メインフレーム開発において、手続きの再帰呼び出し（Recursive Call）はアルゴリズムを簡潔に記述する強力な手法ですが、不用意な実装はシステム障害に直結します。特に、再帰深さが想定を超えた場合に発生する「STORAGE条件（S0C4やS80Aアベンド）」は、運用担当者を悩ませる典型的な課題です。本稿では、LE（Language Environment）環境下におけるスタック（DSA: Dynamic Storage Area）の物理リミットを理解し、堅牢なプログラムを設計するための勘所を解説します。
基礎知識
メインフレームのLE環境では、各手続きが呼び出されるたびに、その変数を保持するためのメモリ領域である「DSA」がスタック上に確保されます。再帰処理を行うと、このDSAが呼び出しの深さ分だけ積み上がります。
ここで重要なのが、JCLのREGIONパラメータと、LEのランタイムオプションであるSTACK設定です。これらは「プロセスが使用可能なメモリの総量」と「一度の拡張で確保されるメモリ単位」を制御しており、再帰の深さがこの上限を超えると、OSはメモリ割り当てを拒否し、プログラムは強制終了（アベンド）します。
実装/解決策
再帰処理を安全に実装するためには、以下の2点に注力する必要があります。
1. 再帰深さの静的見積もり: 最大再帰回数をロジック上で制限し、スタック消費量を計算可能な状態にする。
2. ランタイムオプションの適正化: `STACK(初期サイズ, 増分サイズ, ANYWHERE)` を指定し、必要に応じてメモリが動的に拡張されるよう構成する。特に、スタックを「31ビット領域（ANYWHERE）」に置くことで、24ビット領域の枯渇を回避するのが現場の鉄則です。
サンプルプログラム
以下は、スタック溢れを未然に防ぐためのチェックロジックを組み込んだCOBOLの例です。
IDENTIFICATION DIVISION.
PROGRAM-ID. RECURSIVE-CHECK.
- 再帰処理におけるスタック溢れ防止サンプル
WORKING-STORAGE SECTION.
01 WS-RECURSION-COUNT PIC 9(04) VALUE 0.
01 WS-MAX-LIMIT PIC 9(04) VALUE 100.
PROCEDURE DIVISION.
ADD 1 TO WS-RECURSION-COUNT.
- 再帰回数が限界に達していないかチェック
IF WS-RECURSION-COUNT > WS-MAX-LIMIT THEN
DISPLAY ‘エラー: 再帰深さが限界を超えました’
GOBACK
END-IF.
- 再帰処理の実行
CALL ‘RECURSIVE-CHECK’
SUBTRACT 1 FROM WS-RECURSION-COUNT.
GOBACK.
応用・注意点
現場で陥りやすい罠として、Java等のオープン系言語へ移行する際の「スタックサイズの不一致」があります。Javaでは `-Xss` でスタックサイズを制御しますが、メインフレームのLE環境と全く同じ挙動を再現するのは困難です。
移行を検討する際は、「再帰アルゴリズムをスタックを使わないループ構造に書き換える（反復処理への転換）」ことを優先してください。また、デバッグ時には `RPTSTG(ON)` オプションを指定して実行することで、プログラム終了時にスタックの使用状況がSysoutへ出力されます。これを確認し、ピーク時のスタック消費量を把握しておくことが、安定稼働への近道です。
コメント