導入：なぜ再帰処理の設計が重要なのか
メインフレーム開発において、COBOL等の言語で `RECURSIVE` 属性を用いたプロシージャを実装する際、最も注意すべきはメモリ管理です。手続きが自身を呼び出すたびに生成される `AUTOMATIC` 変数は、呼び出し階層ごとにスタックへ積まれます。この仕組みを理解せずに深い階層の再帰を行うと、リージョン不足による異常終了（ABEND）を招きます。本稿では、スタック消費のメカニズムと、安全な設計のためのTipsを解説します。
基礎知識：AUTOMATIC変数のライフサイクル
通常の `WORKING-STORAGE` で定義された変数は、プログラム実行中ずっと同じアドレスを占有する「静的」な領域です。一方、`AUTOMATIC` 変数は、プロシージャが呼び出されるたびに動的に割り当てられ、終了とともに解放されます。
再帰プロシージャの場合、この「割り当て」が呼び出しの深さ（ネスト数）の分だけ同時に存在することになります。つまり、1階層ごとにスタック領域が消費され、これがメインフレームの定義したリージョン・サイズを超えた瞬間に、システムはリソース不足を検知します。
実装：再帰の安全な管理手法
再帰を実装する際は、以下の3点を必ず設計に盛り込んでください。
1. 深さの制限値（上限フラグ）を設け、想定外のループを防ぐ。
2. `AUTOMATIC` で定義する変数のサイズを極力小さく抑える。
3. 処理コストとスタック消費のトレードオフを評価する。
サンプルプログラム：再帰処理と深度制限
以下は、再帰呼び出し時にスタックを消費しつつ、安全に深度を管理するCOBOLの例です。
IDENTIFICATION DIVISION.
PROGRAM-ID. RECURSIVE-SAMPLE.
- 再帰プロシージャの定義
PROCEDURE DIVISION RECURSIVE.
MAIN-LOGIC.
DISPLAY “処理開始”.
CALL “RECURSIVE-PROC” USING BY VALUE 1.
STOP RUN.
IDENTIFICATION DIVISION.
PROGRAM-ID. RECURSIVE-PROC.
DATA DIVISION.
WORKING-STORAGE SECTION.
- 定数：再帰の最大深度
01 MAX-DEPTH PIC 9(4) VALUE 100.
LINKAGE SECTION.
01 CURRENT-DEPTH PIC 9(4).
PROCEDURE DIVISION USING CURRENT-DEPTH.
- AUTOMATIC変数は呼び出しごとにスタックへ積まれる
- サイズを大きくしすぎないことがポイント
01 WORK-BUFFER PIC X(100) AUTOMATIC.
- 深度チェック：スタック溢れを未然に防ぐ
IF CURRENT-DEPTH > MAX-DEPTH
DISPLAY “エラー：再帰深度が限界を超えました”
EXIT PROGRAM
END-IF.
- 再帰呼び出し
COMPUTE CURRENT-DEPTH = CURRENT-DEPTH + 1.
CALL “RECURSIVE-PROC” USING BY VALUE CURRENT-DEPTH.
EXIT PROGRAM.
応用・注意点：将来的な移行を見据えて
現代のシステム移行プロジェクトにおいて、COBOLからJavaやPythonへマイグレーションするケースが増えています。これらオープン系言語のデフォルト・スタックサイズは、メインフレームのリージョン・サイズよりも小さく設定されていることが多く、メインフレームでは正常に動作していた再帰処理が移行先で `StackOverflowError` を引き起こすことがよくあります。
設計段階で「再帰をループ構造（Iterative）に書き換え可能か」を検討しておくことは、将来的な保守性や移行コストの低減に直結します。再帰アルゴリズムは美しいですが、実務においては「スタックを汚さない設計」を最優先してください。
コメント