メインフレームの残光：PL/Iにおける動的メモリ管理の「深淵」とダングリングポインタの呪縛
メインフレームのシステムアーキテクトとして30年、数多のCOBOLからPL/Iへの移植、あるいはその逆、そして昨今のJava/C#への大規模マイグレーションを主導してきた私にとって、PL/Iの`FREE`文ほど、技術者の力量を如実に物語る命令はない。
`ALLOCATE`で確保したメモリを`FREE`する。この一見単純な操作の背後には、メインフレーム特有の「メモリの生存期間」に対する厳格な規律と、それを怠った瞬間に待っている悲惨なシステムアベンド（ABEND）の罠が潜んでいる。
1. 動的メモリ管理の現在地：なぜ「NULL代入」が不可欠か
PL/Iにおいて、`BASED`変数とポインタを使いこなすことは、基幹システムにおける高効率なバッファ処理の要だ。しかし、多くの開発者が陥る過ちがある。それは、`FREE`文を実行した後に、そのメモリを指していたポインタ変数をそのまま放置することだ。
/i
/ — 動的メモリ確保と解放のアンチパターン例 — /
DCL PTR_DATA POINTER;
DCL 1 MY_REC BASED(PTR_DATA),
2 KEY_ID CHAR(4),
2 VALUE FIXED DEC(9);
/ メモリの確保 /
ALLOCATE MY_REC;
/ … 何らかの処理 … /
/ 解放 /
FREE MY_REC;
/ ここが重要：ポインタを無効化しないとダングリングポインタが残る /
/ PTR_DATA = NULL(); / この一行を忘れると、後に予期せぬABENDを招く /
このポインタ変数は、`FREE`後も「かつて存在したアドレス」を指し示し続ける。これが「ダングリングポインタ（ぶら下がりポインタ）」だ。もし、後続処理でこのポインタを誤って参照し、その領域が既に別タスクに再割り当てされていたらどうなるか。データは破壊され、原因不明のS0C4アベンドに頭を抱えることになる。
私が現場で強制しているのは、`FREE`をラップした専用のプロシージャを用意し、必ず`NULL()`を代入してポインタを物理的・論理的に「無」に戻すことだ。
2. コンパイラ最適化と「見えないバグ」
PL/Iのコンパイラオプション（`OPTIMIZE(3)`など）を有効にすると、生成されるオブジェクトコードは極限まで高速化されるが、同時にソース上の「曖昧なポインタ参照」に対して非常に厳格になる。
特に恐ろしいのが、パックデシマル（FIXED DEC）の内部符号反転に関わるバグだ。メモリを`FREE`したつもりで解放済み領域を再利用していると、コンパイラが「ここは定数であるはずだ」と予測して最適化した処理と、実際に書き換わった値の整合性が取れなくなり、DB2への埋め込みSQLで不正な値が渡されるケースがある。
CICSのオンライン処理であれば、このメモリ汚染は即座にトランザクションの異常終了を招き、最悪の場合、共用ストレージの破壊（Storage Violation）に繋がり、システム全体を停止させる。
3. アベンド（ABEND）解析の哲学
システムがS0C4（Protection Exception）で落ちた時、ダンプリストを眺めるのが我々アーキテクトの仕事だ。まず確認するのは「ポインタ変数が指しているアドレス」と「実際にアクセスしたアドレス」の乖離である。
もしあなたがマイグレーションの設計者なら、移行先であるJavaのガベージコレクション（GC）の挙動を、PL/Iの`FREE`と比較してはならない。GCは「いつか誰かが掃除してくれる」という甘美な世界だが、PL/Iのメモリ管理は「開発者が自らの手で領域を管理する」という、古き良き、しかし油断のならない職人の世界だ。
4. 移行を見据えたアーキテクチャの提言
基幹システムのマイグレーションにおいて、PL/Iの動的メモリ操作をそのままJavaの`new`に置換すれば済むと考えるのは危険極まりない。
- 構造体の配置: `BASED`変数で定義されたメモリレイアウトは、アライメントやパディングの観点からJavaのオブジェクト構造とは全く異なる。
- 埋め込みSQL: `EXEC SQL`でホスト変数としてポインタを使用している場合、そのメモリの実体がいかに管理されているかを完全にトレースしなければならない。
私の信条はこうだ。「PL/Iで書かれたロジックは、メモリ管理の責任がコードのどこに帰属するかを常に明確にせよ」。
もし、貴方のチームのコードで、ポインタ変数がただの「アドレス記憶装置」として放置されている箇所があれば、今すぐ見直すべきだ。`FREE`は単なる解放ではない。それは、そのメモリ領域との「契約終了」を宣言する神聖な儀式なのだ。
この領域のバグは、修正するのに数週間かかることもある。しかし、一度体系的なルールを確立すれば、メインフレームの堅牢さは次世代のアーキテクチャにも確実に継承できる。技術は進化しても、メモリを管理する規律だけは、不変なのだ。
