境界なき悪夢：ON SUBSCRIPTRANGEで暴く「見えないメモリ破壊」の深淵
メインフレームの現場で、夜中の3時に呼び出される悪夢の筆頭は、いつだって「原因不明のABEND」だ。特に、数百万行におよぶ枯れたレガシーコードの中で発生する、不可解なデータ破壊。
「なぜか計算結果が合わない」「なぜか別の変数の値が化けている」。
これらは往々にして、配列の境界を超えたアクセス——いわゆるバッファオーバーフロー（またはアンダーフロー）が引き金となっている。JavaやC#の世界では例外が飛ぶような事象も、PL/Iの古のコンパイラ設定次第では、黙って隣接するメモリ領域を書き換え、後続の処理で静かに爆発する。
今日は、この「静かなる破壊者」を炙り出すための`ON SUBSCRIPTRANGE`の活用法と、その先にあるモダン移行を見据えたアーキテクチャ設計について語ろうと思う。
—
1. コンパイラオプションの隠された本質
まず、基本を再確認しよう。PL/Iにおいて添字チェックを行うには、コンパイラオプションで`SUBSCRIPTRANGE`を指定する必要がある。
1
/ コンパイルオプション例:
PROCESS SUBSCRIPTRANGE, OPTIMIZE(0)
注意: 本番環境で常に有効にするのはパフォーマンス上の禁じ手だ /
多くの若手エンジニアは「なぜデフォルトでONになっていないのか？」と問うが、答えはシンプルだ。「命令サイクルを浪費するから」だ。汎用機において、1命令の重みは現代のサーバーとは桁が違う。しかし、デバッグや品質保証工程においてこれをOFFにするのは、目隠しをして高速道路を走るようなものだ。
実践：ON SUBSCRIPTRANGEによるハンドリング
以下のコードは、境界外アクセスを検知した際にログを吐き出し、即座に異常終了させるためのイディオムである。
1
/ 異常検知の定石 /
ON SUBSCRIPTRANGE
BEGIN;
PUT SKIP LIST (‘— ARR-ERR: 配列境界外アクセスを検知 —‘);
PUT SKIP LIST (‘ERROR AT: ‘ || ONLOC());
/ ダンプを出力して解析の糸口を残す /
CALL CEEDUMP;
STOP;
END;
—
2. ポインタとベース変数：現代の移行設計における地雷原
特に危険なのは、`BASED`変数と`POINTER`を用いた動的メモリ操作だ。メインフレームのマイグレーションプロジェクトにおいて、Javaの`ByteBuffer`やC#の`Unsafe`コードへの書き換えを行う際、最も手こずるのがこの「メモリの直接操作」である。
PL/Iのポインタは、単なるメモリアドレスではない。コンパイラは`SUBSCRIPTRANGE`のチェックを、宣言された配列に対しては行えるが、ポインタ経由で計算されたオフセット先に対しては、チェック能力が著しく低下することがある。
内部符号反転バグとの共犯関係
ここで厄介なのが、パックデシマル（`FIXED DECIMAL`）の内部表現だ。ポインタ操作で誤ってパックデシマルの符号ビットを破壊すると、計算結果が反転するだけでなく、比較命令で予測不可能な挙動を示す。
- 対策: 移行設計においては、ポインタ演算を排除し、`STRUCTURE`のコピーや、型安全なデータオブジェクトへのマッピングを優先すべきだ。ポインタを多用するレガシーモジュールは、マイグレーション時に「ブラックボックスの最たるもの」となる。
—
3. ABEND解析の極意：CICSとDB2の狭間で
CICSオンラインやDB2埋め込みSQLと混在している環境では、`ON SUBSCRIPTRANGE`が発生した際、単に`STOP`するだけでは不十分だ。
1. CICSの整合性: `ABEND`を発生させる前に、`EXEC CICS SYNCPOINT ROLLBACK`を発行しなければ、DB2のコミット未完了データが中途半端に残る。
2. ダンプの真実: `SYSUDUMP`や`CEEDUMP`を解析する際、単に「どこで落ちたか」だけを見てはいけない。「配列のインデックスがどの変数の計算結果から導き出されたか」、そして「その変数が直前の処理でどう汚染されたか」を遡る必要がある。
—
4. アーキテクトとしてのアドバイス
もし君が今、レガシーシステムの延命、あるいはJava/C#への移行を主導しているなら、以下の視点を忘れないでほしい。
- 移行前: 現行システムのバッチジョブには、一時的に`SUBSCRIPTRANGE`を有効にしたビルドを投入し、夜間バッチの境界チェックを徹底せよ。これだけで「潜在的な時限爆弾」の3割は駆逐できる。
- 移行後: 「PL/Iのポインタ演算」を「Javaのポインタもどき（ByteBuffer等）」で再現しようとしてはいけない。それは地獄への片道切符だ。境界チェックが自動的に行われる、高水準なコレクションクラスへと設計を抽象化する勇気を持つことだ。
PL/Iは、ハードウェアの限界までをコードで制御できる、美しくも危険な言語だ。境界チェックを軽んじることは、その言語の最も優れた機能の一つを放棄することに他ならない。
デバッグの最前線にいる諸君、コードが静かに語る「境界の向こう側の景色」を、決して見逃さないでほしい。
