予約語なき言語の深淵：SUBSTR関数がメモリを操作する際、裏側で何が起きているのか
PL/Iという言語の特異性は、その「自由」にある。CやJavaのように厳格な予約語を持たないこの言語は、コンパイラに対して極めて高い抽象度と、同時にハードウェアへの無慈悲なまでの近さを要求する。
多くのモダン言語エンジニアが「PL/Iは古い」と一蹴するが、基幹システムの現場でS0C4（保護違反）やS0C7（データ例外）が起きたとき、そのメモリレイアウトを正確に把握できていない者が太刀打ちできるはずもない。今日は、最も基本的な関数でありながら、最も誤解されている`SUBSTR`の深層心理について語ろう。
—
1. SUBSTRと「見えざる一時領域」の物理学
`SUBSTR`関数は、単なる文字列の切り出しではない。特に、ソース変数（元データ）とターゲット変数（代入先）が同一のアドレス空間で重複している場合、PL/Iコンパイラは動的に「一時作業領域（Temp Storage）」を確保する。
DCL STR_DATA CHAR(100) VAR;
/ 自身の後ろ部分を前にコピーする、一見無害な処理 /
STR_DATA = SUBSTR(STR_DATA, 6, 95);
このコードを実行したとき、コンパイラは「オーバーラップが発生する可能性がある」と判断し、安全のために内部的なスタックまたはヒープに一時バッファを生成する。この「暗黙のメモリ確保」が、限られたCICSのタスク内メモリ（TD/LD）を圧迫し、極稀に`STORAGE`不足を招く。
これがマイグレーションの設計において重要となる理由は、Javaの`String.substring()`が「元の文字配列の参照を保持する」という軽量な実装であるのに対し、PL/Iは「コピーを強いる」という決定的な違いがあるからだ。このメモリ効率の差を無視した単純置換は、バッチ処理全体のメモリフットプリントを劇的に増大させる引き金となる。
—
2. ポインタ演算の危うさとコンパイラ最適化
PL/Iの真価は、`BASED`変数と`POINTER`型を組み合わせた動的メモリ操作にある。私が現場で最も恐れるのは、コンパイラオプション`OPTIMIZE(3)`を適用した際に発生する、予測不能なレジスタ最適化だ。
DCL P POINTER;
DCL BASED_STR CHAR(20) BASED(P);
/ アドレスをずらしてアクセスする危険な遊び /
P = ADDR(STR_DATA) + 5;
BASED_STR = ‘OVERWRITE’; / メモリ破壊の温床 /
この操作を行う際、もし`OPTIMIZE`レベルが高いと、コンパイラは「この変数は変更されない」と判断し、レジスタにキャッシュされた値を再利用することがある。結果、メモリ上では値が変わっているのに、処理は古い値で進むという悪夢のようなバグが発生する。
ダンプ解析の現場において、`SUBSTR`の結果が期待値と異なる場合、まずはレジスタ上の値と、`LOC`で指定された実メモリ上の値を比較せよ。多くの場合、コンパイラによる最適化の犠牲になっているか、あるいはアライメントの境界を超えたアクセスが原因だ。
—
3. パックデシマルと「符号」という名の時限爆弾
マイグレーション時に頻出する「データ例外（S0C7）」の首謀者は、多くがパックデシマル（`PIC S9(n) COMP-3`）だ。PL/Iは、このパックデシマルを計算する際、極めて寛容に振る舞う。
特に、DB2からFETCHした値が、COBOL等の他言語によって生成された「符号不整合（例えば、末尾ニブルが `F` ではなく `C` や `D` 以外になっている）」状態である場合、PL/Iの計算命令（`AP`命令等）が実行された瞬間にアベンドする。
現場での解決策:
移行先のJava/C#側で、数値を読み込む際に必ず「符号のバリデーション」を行うこと。PL/Iは「計算時に初めて爆発する」性質があるが、Java側で同じことをすれば、最初のデータ変換フェーズで検知可能だ。これは「移行時にこそエラーを早期発見する」という鉄則である。
—
4. アーキテクトへの提言：レガシーは「予測」である
CICSオンライン処理で`SUBSTR`を多用するコードをJavaへ移行する場合、単なるメソッド変換に留まってはならない。
1. メモリ境界の意識: 物理的なレコード長の制約が外れるJavaでは、`String`のサイズが膨れ上がり、GC（ガベージコレクション）の頻度を高める。
2. SQL埋め込みのエッジケース: `SUBSTR`と`||`（連結）の組み合わせがDB2のインデックススキャンを阻害していないか、実行計画を必ず確認せよ。
3. ポインタ操作の完全封印: `BASED`変数を用いた複雑な構造体マッピングは、クラス構造へのリファクタリング時に、メモリレイアウトの整合性を維持するための「デシリアライザー」を自作する必要がある。
PL/Iは、プログラマがハードウェアの主人であることを許容した、数少ない「紳士的」な言語だ。その裏側にある一時領域確保の仕組みや、コンパイラの最適化戦略を理解することは、過去の遺産を「動くゴミ」にしないための最後の防波堤となる。
次に君がダンプリストを広げるとき、そこに並ぶ16進数の羅列の向こう側に、コンパイラが描いた「見えざる設計図」が見えることを期待している。
