PL/Iの深淵：AUTOMATIC変数のスタック制御と再帰呼び出しの「終わりのない夢」
汎用機（メインフレーム）の心臓部で動くPL/I。JavaやC#といったマネージド言語の「ガベージコレクション」という甘美な言葉に慣れた世代には、PL/Iのメモリ管理は時に残酷で、時に官能的です。
特に `AUTOMATIC` 変数は、PROCEDUREが呼び出されるたびにスタック上に生成され、終了と共に消え去る。このライフサイクルは、まさに「一期一会」。しかし、このスタックの境界線を見誤った瞬間、基幹システムは容赦なく `S0C4` や `S80A` の阿鼻叫喚に包まれます。今日は、このスタック領域の深層心理について深掘りしましょう。
—
1. スタックの静寂：AUTOMATIC変数の正体
PL/Iにおいて変数を宣言する際、特に属性を指定しなければデフォルトで `AUTOMATIC` が割り当てられます。これはC言語における「ローカル変数」と似ていますが、スタックの積まれ方はコンパイラの最適化レベルやアラインメント設定に大きく依存します。
/i
/ 再帰呼び出しによるスタック消費の例 /
RECURSIVE_PROC: PROC(N) OPTIONS(MAIN RECURSIVE);
DCL N FIXED BIN(31);
DCL BUFFER CHAR(4096) AUTOMATIC; / 4KBのスタック消費 /
IF N <= 0 THEN RETURN; / ここでスタックを4KBずつ食い潰していく。 再帰の深さが深すぎると、LE(Language Environment)のスタック上限を突破する / CALL RECURSIVE_PROC(N - 1); END RECURSIVE_PROC; このコード、バッチ処理で深さを読み間違えると即座に `Storage Overrun` です。特にCICSオンライン処理でこれをやると、トランザクション全体が異常終了し、場合によってはタスク自体が再起動不能な状態に陥ります。
2. 再帰呼び出しとABENDの背後にあるもの
基幹システムのマイグレーションにおいて最も恐ろしいのは、レガシーなソースコードに含まれる「意図せぬ再帰」です。特に、古のCOBOLからPL/Iへ移行した際に、スタックサイズを考慮せずに変数を巨大化させてしまうケースが後を絶ちません。
- ダンプ解析の勘所: `CEE3501S` 等が発生した際、ダンプリスト上の `Storage Map` を見てください。`AUTOMATIC` なデータエリアがスタックのどのオフセットにあるか。そして、直前の呼び出し履歴（Traceback）を追跡し、スタック・ポインタがどの閾値を超えたのかを確認します。
- パックデシマルの罠: 再帰処理の中で `FIXED DECIMAL` を計算している場合、算術演算のオーバーフローがスタック破壊の引き金になることがあります。特に内部符号（X’C’やX’D’）が想定外のビットパターンに化けた際、コンパイラが生成したルーチンがスタックを不正アクセスするケースは、デバッグの難易度が極めて高い「迷宮」です。
3. ポインタによる動的メモリ管理への退避
スタックが危ういと判断したならば、`AUTOMATIC` を捨てて `BASED` 変数と `POINTER` を用いたヒープ領域の管理へ移行するのが、歴戦のアーキテクトの定石です。
/i
DCL P POINTER;
DCL MY_DATA CHAR(4096) BASED(P);
/ スタックではなく、ヒープにメモリを確保（GET STORAGE） /
ALLOCATE MY_DATA;
/ メモリ操作の後は必ず解放。これを忘れるとメモリリークでシステムが徐々に死ぬ /
FREE MY_DATA;
マイグレーション先のJavaやC#では「メモリを確保したらGCがやってくれる」のが常識ですが、PL/Iの `FREE` は開発者の良心そのものです。ここを突き詰めるのが、我々システムアーキテクトの矜持でもあります。
4. 移行設計へのアドバイス：CICS/DB2環境でのエッジケース
CICS環境下でのPL/I開発では、`OPTIONS(MAIN)` の設計に注意が必要です。特に埋め込みSQL（DB2）を利用している場合、スタックの消費量は単なる変数宣言だけでなく、DB2が保持するSQLCA（SQL通信領域）やカーソル制御ブロックのスタック退避分も考慮しなければなりません。
- コンパイラオプションの最適化: `TEST` オプションを付けたまま本番稼働させるのは、重い鎧を着てマラソンをするようなもの。パフォーマンスとデバッグの天秤を正しく測りましょう。
- マイグレーションの罠: C#等への移行時、PL/Iの「変数の初期値が必ずしもゼロではない（未定義値）」という挙動を、マネージド言語の「デフォルト初期化」へそのまま移植すると、隠れたロジックバグが顕在化します。
最後に
PL/Iは、汎用機の歴史そのものです。スタック領域の管理一つとっても、そこには計算機科学の黎明期からの知恵が詰まっています。
「なぜこの変数はスタックに積まれたのか」「なぜ再帰の深さを制限しなければならないのか」。この問いに対する答えをソースコードの中に探し出し、それを現代の分散システムへ昇華させる。それこそが、我々アーキテクトが担うべき、最も創造的な仕事です。
コードの最適化に魔法はありません。あるのは、メモリの挙動を完全に把握し、コンパイラの生成する機械語と対話できるという、静かな自信だけです。次回のプロジェクトでも、スタックの深淵を恐れず、果敢に挑んでいきましょう。
