制御不能な「配列外アクセス」を飼い慣らす：PL/IにおけるSUBSCRIPTRANGEの賢明な運用術
メインフレームの現場で何十年と稼働し続けるPL/Iのバッチプログラム。その保守において、最も胃が痛くなるのは「なぜか計算結果が合わない」「突然、予期せぬタイミングでABENDする」といったメモリ破壊の兆候です。
特にPL/Iの配列操作において、宣言した境界を超えて値を書き込んでしまう「添字範囲外アクセス」は、C言語のバッファオーバーランと同等、あるいはそれ以上に質が悪い。なぜなら、PL/Iのコンパイラはデフォルトでこのチェックを行わず、隣接する変数の値をサイレントに破壊して突き進むからです。
本稿では、レガシー移行の設計者たる諸君に向け、`ON SUBSCRIPTRANGE`の真の価値と、それを本番環境で「無効化」しつつ開発環境で「武器」にするためのアーキテクチャ設計を解説します。
—
1. ON SUBSCRIPTRANGEのメカニズムと性能のトレードオフ
PL/Iプログラムの冒頭に以下の記述を加えるだけで、実行環境は配列の境界を監視し始めます。
1
/ 開発環境用: 添字範囲外アクセスを検知して制御を奪う /
ON SUBSCRIPTRANGE BEGIN;
PUT SKIP LIST (‘ERROR: 配列添字が範囲外です’);
/ ここでダンプを強制出力し、スタックトレースを記録する /
CALL PLIDUMP(‘T’, ‘添字範囲外エラー発生時のトレース’);
STOP;
END;
なぜ、これを常に有効にしておかないのか？ 答えは明白です。「パフォーマンス」です。
コンパイラオプションの`CHECK`を指定すると、実行時に全ての配列参照に対して境界チェック用の命令が挿入されます。数百万件のレコードを処理するバッチプログラムにおいて、このオーバーヘッドは無視できません。CPUサイクルの無駄遣いであると同時に、マイグレーション先（Java/C#等）での実行効率と比較した際の「レガシーの重さ」として測定されてしまうからです。
アーキテクトの知見：最適化とデバッグの分離
本番環境では`NOCHECK`でコンパイルし、高速性を担保する。その代わり、開発・テストフェーズでは必ず`CHECK`を有効にする。これが鉄則です。もし、「テスト環境だけなぜかABENDしない」という事態に陥ったら、それはテストデータの網羅性が低いか、あるいはデータ型（パックデシマルなど）の不整合によるメモリ破壊が、境界チェックの監視網をすり抜けている可能性があります。
—
2. 破壊的なバグ：ポインタとベース変数の危うい関係
PL/Iの真骨頂である`BASED`変数とポインタを使った動的メモリ操作は、自由度が高い反面、最も制御を失いやすい場所です。
1
DCL TABLE(10) FIXED BIN(31) BASED(P);
DCL P POINTER;
/ 悪夢の始まり：Pが指す先のメモリ領域を超えて書き込む /
DO I = 1 TO 20;
TABLE(I) = 0; / 11以降は領域外だが、ON SUBSCRIPTRANGEがなければ黙って進む /
END;
もし隣接する変数がパックデシマル（`PIC S9(7)V99 COMP-3`）だった場合、この境界外アクセスによって内部符号ビットが反転し、数値が異常値に化けるという、追跡困難なバグを引き起こします。
移行設計の現場では：
既存の`BASED`変数をJavaの`ByteBuffer`や構造体にマッピングする際、この「境界外への書き込み」が前提となっているコードがないかをソースコード解析ツールで洗い出す必要があります。もし存在すれば、それは「仕様」ではなく「技術的負債」です。移行先では例外を投げる設計に強制変換しなければなりません。
—
3. ABEND解析の極意：PLIDUMPとエッジケース
`ON SUBSCRIPTRANGE`が発火した際、単にログを出すだけでなく、`PLIDUMP`を活用してください。
- `T`オプション（Trace）: 呼び出し階層を追い、どのPROCEDUREのどの行で配列操作が暴走したかを特定する。
- `H`オプション（Hex）: 変数の生メモリをダンプし、パックデシマルの符号反転や、ポインタのオフセット値が意図通りかを確認する。
特にCICSオンライン処理でこのエラーが発生した場合、タスクが異常終了し、一時ストレージ（TS）や共有キューが汚染されるリスクがあります。オンライン処理では`ON`ユニットでエラーを捕捉し、即座にロールバック処理（`EXEC CICS SYNCPOINT ROLLBACK`）を実行した上で、異常系としてタスクを終了させる設計が不可欠です。
—
結論：レガシーを「制御可能な資産」へ
PL/Iの古いコードを現代のJavaやC#に移行する際、最も苦労するのは「言語仕様の厳密さの違い」です。PL/Iの曖昧さ（あるいは寛容さ）は、当時の限られたリソースで最大限の処理を行うための知恵でした。
しかし、今の我々には、コンパイラが提供するチェック機能を「設計の規律」として利用する義務があります。
- 開発時: `CHECK`オプションを有効にし、`ON SUBSCRIPTRANGE`で徹底的にバグを炙り出す。
- 移行時: 境界チェックで引っかかる箇所を、安全なコレクションオブジェクト（List等）へ変換し、インデックスチェックを強制するロジックに置き換える。
このプロセスこそが、枯れた技術をモダンなシステムへと昇華させる「アーキテクトの仕事」なのです。次にバッチプログラムのソースを開くときは、ぜひ`ON SUBSCRIPTRANGE`の記述があるか、確認してみてください。そこには、先人たちが苦労して構築した堅牢性の痕跡が残っているはずです。
