メインフレームの深淵：BEGINとPROCEDUREのメモリ管理、その「スタック」の行方
基幹システムの現場で、数十年生き続けてきたPL/Iコードをメンテナンスしていると、ふと壁にぶつかることがある。「なぜ、この変数はここで解放されるのか？」「なぜ、この動的ストレージがS0C4を招くのか？」。
多くのエンジニアはPL/Iを「古き良き言語」と形容するが、私はそうは思わない。PL/Iは、今日の高レイヤー言語が隠蔽してしまったメモリ管理の「生の挙動」を、極めて厳密に制御できるアーキテクチャそのものだ。特に、`PROCEDURE`ブロックと`BEGIN`ブロックのメモリ管理の差異は、バッチ処理の性能やCICSオンラインの信頼性を左右する決定的な差を生む。
1. スタックフレーム生成の決定的な差異
まず、この2つのブロックのメモリに対する「構え」を理解しておく必要がある。
- PROCEDUREブロック: 呼び出されるたびに新しいスタックフレームを生成する。「境界」である。引数の受け渡し（BYADDR/BYVALUE）や、レジスタの退避・復元、そして新たな自動変数の割り当てが行われる。
- BEGINブロック: 既存のプロシージャのコンテキスト内で実行される「スコープの区切り」に過ぎない。新しいスタックフレームを作成するオーバーヘッドは最小限であり、変数の生存期間を局所化するためにある。
ここで注意すべきは、動的ストレージの割り当て（ALLOCATE文）の寿命だ。
1
/ PROCEDURE内でのALLOCATEとBEGINブロックの生存範囲 /
PROC_MAIN: PROC OPTIONS(MAIN);
DCL P PTR;
/ BEGINブロックの開始 /
BEGIN;
DCL LOCAL_VAR CHAR(100) AUTOMATIC;
ALLOCATE BUFFER_STR SET(P); / ここでヒープから獲得 /
/ BEGINを抜けるとポインタPは無効になるが、
ヒープ上のメモリはALLOCATEされたままである（明示的FREEが必要） /
END;
/ 恐ろしいのはここだ。自動変数はBEGINのENDで消えるが、
ALLOCATEしたメモリはPROCEDUREの最後、あるいはFREEされるまで残り続ける /
END PROC_MAIN;
Javaのガベージコレクションに慣れたマイグレーション設計者が陥る罠がここにある。`BEGIN`ブロックをJavaの `{ }` ブロックと同義と捉えると、メモリリークの温床となる。PL/Iにおいて`ALLOCATE`は常に明示的な`FREE`を要求する。これを忘れると、数百万件のレコードを処理するバッチで、あっという間にシステム全体をアベンド（S806やS0C4）へ追い込むことになる。
2. ポインタ操作とアベンド解析の勘所
移行プロジェクトで最も神経を使うのが、ポインタを用いた構造体操作だ。特に、`DEFINED`属性や`BASED`変数を駆使した古いコードは、現代のコンパイラ最適化の裏をかくことがある。
例えば、パックデシマル（FIXED DECIMAL）の内部表現だ。PL/Iでは、パックデシマルは符号付きニブルで表現されるが、ポインタで強引に構造体をキャストして値を書き換える際、符号ビット（0xC/0xD/0xF）を考慮しないと、DB2へ値を渡す直前に「データ例外（S0C7）」が発生する。
1
/ ポインタを用いた構造体操作のデバッグ例 /
DCL 1 MY_STRUCT BASED(P),
2 VAL_PKD FIXED DEC(5,0);
/ 不適切なポインタ操作による内部表現の破壊を防ぐ /
/ ダンプ解析時、VAL_PKDの末尾が0x0Cか0x0Dでない場合、S0C7は確定 /
IF P /= NULL() THEN DO;
VAL_PKD = 12345; / 正しい符号が生成される /
END;
ダンプ解析の際、`CEE3608I`のようなシグナルが出た場合、まず疑うのは`PROCEDURE`を跨いだポインタの生存期間と、`ALLOCATE`された領域のオーバーレイだ。特にCICS環境では、同一タスク内でポインタを使い回すことが多いため、あるBEGINブロックで`FREE`したメモリを、別のポインタが掴んだままアクセスしていないか、ストレージ・チェーンを追う必要がある。
3. マイグレーションに向けたアーキテクチャ的提言
もしあなたが、このPL/I資産をJavaやC#へ移行しようとしているなら、以下のポイントを設計指針に入れてほしい。
1. 自動変数のスコープを厳密にマッピングせよ: `BEGIN`ブロックをそのままメソッド分割に置き換えると、メモリ管理の整合性が崩れる。`AUTOMATIC`変数の寿命は、そのスコープ（ブロック）の開始と終了に厳密に依存させること。
2. パックデシマルの型変換を甘く見るな: Javaの`BigDecimal`に変換する際、PL/Iの内部表現（符号ビットの挙動）をそのまま模倣できるクラスをラップしないと、計算結果の不整合が必ず発生する。
3. OPTIONS(MAIN)の責務を分離せよ: メインフレームのMAINプロシージャは、環境変数の取得やファイルオープンを兼ねていることが多い。これをそのままメインクラスに持っていかず、責務を分離したDI設計に落とし込むことが、メンテナンス性の鍵だ。
最後に：枯れた技術という「幻想」
PL/Iのコードは、時に難解で無愛想だ。しかし、システムアーキテクトの視点で見れば、これほどまでにメモリの物理的な配置を意識させ、ハードウェアの挙動に直結した設計を可能にする言語は他にない。
「動いているから触るな」は、技術者としては敗北だ。スタックフレームの深層に何が隠されているのか。なぜそのブロックが`BEGIN`でなければならなかったのか。コンパイラのリストファイル（LST）を読み込み、アセンブラ出力を眺める。その泥臭い作業の先にこそ、真のレガシー移行の成功がある。
あなたのコードが、今日も無事に終了コード0で終わることを願っている。
コメント