PL/Iの深淵：AUTOMATIC変数のスタック管理と、その先にある「死の淵」
メインフレームの現場で何十年も生き抜いてきた我々にとって、PL/Iの `AUTOMATIC` 属性は空気のような存在だ。`PROCEDURE` に入ればメモリが確保され、`END` に達すれば消える。だが、この「当たり前」の裏側で何が起きているか、考えたことはあるだろうか？
今日は、基幹システムのアーキテクトとして避けては通れない、スタック領域のメモリ管理と、それが引き起こす「静かなる崩壊」について語ろうと思う。
1. AUTOMATIC属性のライフサイクルとスタックの物理的挙動
PL/Iにおいて `AUTOMATIC` 変数は、実行時スタック（DSA: Dynamic Storage Area）上に展開される。手続きの呼び出しごとにDSAが積み上げられるが、この領域は有限だ。
/i
MAIN_PROC: PROCEDURE OPTIONS(MAIN);
/ ここで宣言されたAUTOMATIC変数は、PROCEDURE開始時にスタックに積まれる /
DCL WORK_AREA CHAR(32000) AUTOMATIC;
CALL RECURSIVE_SUB(1);
END MAIN_PROC;
RECURSIVE_SUB: PROCEDURE(LVL);
DCL LVL FIXED BIN(31);
/ 再帰呼び出しのたびにスタックが消費される。
深い再帰はS0C4やS0C1のアベンドを招くリスクを孕む /
DCL LOCAL_BUFFER CHAR(8000) AUTOMATIC;
IF LVL < 100 THEN CALL RECURSIVE_SUB(LVL + 1); END RECURSIVE_SUB; このコード、一見何の問題もなさそうに見えるだろう。だが、`LOCAL_BUFFER` のサイズを少し大きくし、再帰の深さを変えるだけで、あっという間にスタックオーバーフローだ。特にCICSオンライン処理において、この手の「スタック肥大化」は命取りになる。オンライン環境ではスタックサイズが厳格に制限されているからだ。
2. 移行プロジェクトで直面する「負の遺産」の解析
JavaやC#へのマイグレーションを行う際、最も厄介なのが、この `AUTOMATIC` 変数に依存したロジックの変換だ。
- ポインタによる動的メモリ操作:
PL/Iでは `BASED` 変数と `ADDR` 関数を使い、スタック外のメモリ（`HEAP`）を自由に操作できる。これをJavaの `new` に置き換えるのは容易だが、PL/I特有の「メモリの重ね合わせ（Overlay）」や、パックデシマル（`FIXED DEC`）の内部表現が絡むと一気に難易度が跳ね上がる。
- パックデシマルの落とし穴:
特に注意すべきは、バイナリデータとして扱われるパックデシマルの符号ビットだ。CICSのCOMMAREAでデータをやり取りする際、PL/Iが想定する内部符号と、移行先が想定するビットパターンが一致しない場合、計算結果が反転するバグが頻発する。ダンプ解析を行う際は、必ず `DISPLAY` で数値を追いかける前に、メモリ上の16進ダンプを指先で追う癖をつけておくべきだ。
3. アベンド（ABEND）解析の哲学
システムが `S0C4`（保護例外）で止まったとき、君はどうする？
多くのエンジニアは、とりあえずコンパイラオプションの `LIST` や `MAP` を眺めるが、真のアーキテクトは「スタックの巻き戻し」を追う。
/i
/ コンパイラオプションのヒント:
TEST(SYM, NOHOOK) などを付与することで、
CEE DUMP出力時にローカル変数の内容が詳細に追跡可能になる。
/
もし、スタックの破壊が疑われるなら、`DSA` の先頭アドレスを特定し、そこから前後のメモリをチェックしてくれ。往々にして、配列の境界値チェック（`SUBSCRIPTRANGE`）をあえて無効化していた古いコードが、隣接する領域を破壊しているケースが多い。
4. アーキテクトへの助言：移行の設計思想
レガシー移行は単なる「言語の翻訳」ではない。PL/Iの `AUTOMATIC` がスタックに依存していたという「物理的制約」を、現代の言語が持つ「ヒープ管理とガベージコレクション」にどうマッピングするか。その設計思想こそがプロジェクトの成否を分ける。
1. 静的解析: 全ての `PROCEDURE` のスタックサイズを概算せよ。
2. カプセル化: `BASED` 変数によるポインタ操作は、徹底的にクラスやデータ構造に隔離する。
3. 信頼性: 埋め込みSQL（DB2）のホスト変数が `AUTOMATIC` である場合、SQL発行後のポインタ整合性が保たれているかを、マルチスレッド環境の観点から再検証せよ。
PL/Iは、ハードウェアの挙動を直接制御できる最後の「高級言語」だ。この言語で鍛え上げたメモリ管理の勘所は、どれほど技術が進化しても、君たちの強力な武器であり続けるはずだ。
さて、そろそろメインフレームのログを確認する時間だ。コンソールの向こう側で何が起きているか、想像力を働かせることを忘れるな。それが、真のシステムスペシャリストへの道だ。
