メインフレームの深淵：SUBSTRの「偽りの関数」と、左辺値に潜む禁断の果実
我々が日々向き合っているPL/Iという言語は、一見すると現代的な高級言語の装いをしている。しかし、その内実を紐解けば、レジスタの直接操作やメモリアドレッシングを隠蔽しつつも、ハードウェアの挙動を極めて忠実に反映させた「高級なアセンブラ」であることを痛感させられるはずだ。
今日は、若手エンジニアやマイグレーション専門のアーキテクトがしばしば見落とし、そして悪夢のようなデバッグを引き起こす`SUBSTR`関数の「左辺値（L-value）としての動作」について、現場の血肉となった知見を共有したい。
—
1. SUBSTRは「関数」ではなく「メモリアドレスの計算機」である
多くの開発者は`SUBSTR(STRING, START, LENGTH)`を単なる文字列抽出ツールと考えている。だが、PL/Iにおいて`SUBSTR`は、「対象変数のベースアドレスに対するオフセット計算と、長さの制約を伴う記述子（Descriptor）の生成」という、極めて低レベルなメモリアクセスを抽象化したものに過ぎない。
特筆すべきは、これが代入文の左辺に現れた時だ。
/i
DCL TARGET_STR CHAR(20) VAR INIT(‘ABCDEFGHIJ’);
/ TARGET_STRの3バイト目から4バイト分を’XXXX’で上書き /
SUBSTR(TARGET_STR, 3, 4) = ‘XXXX’;
この時、コンパイラは`TARGET_STR`のメモリ配置を指すポインタを計算し、そこに直接`’XXXX’`のバイト列をストアする命令を生成する。この挙動はC言語のポインタ演算に極めて近いが、PL/Iはこれを言語仕様として安全（という名の錯覚）の中に閉じ込めている。
—
2. 境界外アクセスの恐怖：アベンド（ABEND）の発生メカニズム
なぜ、このコードが「移行の鬼門」なのか。それは、境界外アクセスに対するコンパイラの寛容さと、それが引き起こす予測不能なサイドエフェクトにある。
`SUBSTR`で宣言された長さを超える代入を行った場合、`STRINGRANGE`条件が有効であれば`ON STRINGRANGE`で捕捉できるが、本番環境のパフォーマンスを優先してこのチェックをOFFにしているプロジェクトは少なくない。
- S0C4のアベンド: メモリ保護境界を越えてスタックや他の変数の領域を破壊した場合。
- 論理破壊の地獄: 運悪く境界を超えた先が別の変数だった場合、その変数の値が予告なく書き換わる。特に、パックデシマル（PIC S9(7) COMP-3など）の領域に文字列を書き込んでしまうと、内部符号（通常は最後のニブル）が破壊され、後続の演算命令で「データ例外（S0C7）」が誘発される。 これが夜間バッチの後半で発生した時の絶望感と言ったら、言葉では言い表せない。
実践的な防衛策
移行設計の際、私は必ずコンパイラオプションに `CHECK(SUBSCRRG, STRINGRG)` を一時的にでも有効化することを推奨している。パフォーマンス低下を懸念する声もあるが、本番環境で原因不明のデータ化けを追う工数に比べれば、微々たるコストだ。
—
3. マイグレーションにおける罠：ポインタと埋め込みSQLの親和性
C#やJavaへのリプレースを行う際、最も頭を悩ませるのが`ADDR`組み込み関数と`SUBSTR`の併用だ。
/i
DCL PTR POINTER;
DCL BUF CHAR(100) BASED(PTR);
/ ポインタ経由で特定位置を切り出す /
PTR = ADDR(RAW_DATA);
SUBSTR(BUF, 1, 10) = ‘HEADER ‘;
このような動的メモリ操作は、C言語の`memcpy`や`struct`へのキャストに近い。Javaへの移行において、この「何でもあり」のメモリ操作をオブジェクト指向へ転換するのは至難の業だ。私の経験上、ここでは`ByteBuffer`や`Unsafe`クラスを駆使するよりも、素直に「データレコードの構造体定義を再構築し、正規化する」という地道なリファクタリングが、将来的な保守性を担保する唯一の道となる。
—
4. 最後に：アーキテクトとしての矜持
メインフレームのコードを読み解くことは、先人が遺したハードウェアへの挑戦状を解読することに等しい。`SUBSTR`の左辺値利用に潜む罠を理解することは、単なるバグ回避ではない。それは、システムがどのようにメモリを呼吸し、どのようにCPUと対話しているかを理解することだ。
もし貴方が今、移行プロジェクトの暗闇の中でアベンドダンプと睨めっこしているのなら、まずは変数のメモリダンプを確認し、`SUBSTR`の代入対象が、意図せぬ他の変数の領域を侵食していないか確認してほしい。
「動いているから正しい」のではない。「なぜ動いているかを知っているから、修正できる」のだ。
健闘を祈る。我々の仕事は、このレガシーという名の巨大な知的資産を、次の時代の礎へと昇華させることなのだから。
