現場のエンジニアへ：配列境界外アクセスを「ON SUBSCRIPTRANGE」で制圧する作法
メインフレームの基幹バッチにおいて、最も恐ろしい敵の一つが「サイレント・データ破壊」だ。特に配列の添字（サブスクリプト）が定義域を逸脱した際、PL/Iはデフォルトのコンパイルオプション（`NOSUBSCRIPTRANGE`）では黙ってメモリを上書きし、後続の処理で不可解な異常終了を引き起こす。
「なぜか値が化けている」「たまにABENDするが再現しない」……そんなミステリーの犯人は、大抵この境界外アクセスだ。今回は、この悪夢を未然に防ぎ、開発効率を劇的に高めるための「ON SUBSCRIPTRANGE」の活用術を伝授する。
—
1. なぜ「SUBSCRIPTRANGE」が必要なのか
PL/Iの設計思想は極めて寛容だ。効率を最優先し、実行時のチェックを省くことがデフォルトとなっている。しかし、現代の保守現場において「実行速度の数マイクロ秒」より重要なのは「プログラムの堅牢性」だ。
`SUBSCRIPTRANGE`を有効にすると、添字が範囲外になった瞬間に`SUBSCRIPTRANGE`条件が発生する。これを捉え損ねると、制御はOS（ABEND）へ渡るが、ONユニットでハンドリングすれば、ログを出力してクリーンに終了させる、あるいは特定条件下でリカバリを試みることも可能になる。
2. 実装のセオリー：ONユニットの設置
まずは、以下のコード例を見てほしい。これが我々が現場で採用している、デバッグおよび障害検知の標準的なテンプレートだ。
1
TEST_SUBSCRIPT: PROCEDURE OPTIONS(MAIN);
/ コンパイラへの指示：範囲チェックを有効化 /
/ 実際にはJCLのコンパイルオプション PARM=’SUBSCRIPTRANGE’ で指定するのが通例 /
DCL ARRAY(10) FIXED BIN(31);
DCL I FIXED BIN(31);
/ ONユニットによる例外処理の定義 /
ON SUBSCRIPTRANGE
BEGIN;
PUT SKIP LIST(‘!!! 警告: 配列の添字範囲外アクセスを検知 !!!’);
PUT SKIP LIST(‘現在の不正な添字値: ‘, ONCHAR); / ONCHARで不正値を特定 /
/ ログを吐いて異常終了させるのが定石 /
SIGNAL ERROR;
END;
/ 意図的に境界外へアクセスしてみる /
DO I = 1 TO 11;
ARRAY(I) = I 10;
PUT SKIP LIST(‘ARRAY(‘, I, ‘) = ‘, ARRAY(I));
END;
END TEST_SUBSCRIPT;
ここがポイント：
- `ONCHAR`の活用: `SUBSCRIPTRANGE`発生時に発生元を特定する重要なビルトイン関数だ。これを使わずに「どこで落ちたか」を探すのは、広大なVSAMデータセットの中から1レコードを探すような徒労に終わる。
- `SIGNAL ERROR`の明示: ONユニット内で処理を終えるだけでなく、意図的にERROR条件を発生させることで、ジョブの戻り値（RC）を確実に非ゼロにする。これが監視ツールに正しく通知されるためのキモだ。
—
3. 実務における「落とし穴」と対策
現場では「デバッグ時は有効にしたいが、本番ではパフォーマンスのために無効にしたい」という議論が必ず出る。
1. JCLでの制御:
ソースコードにべた書きするのも手だが、基本はコンパイル時の`PARM`で制御すべきだ。開発・単体テスト環境では必ず`SUBSCRIPTRANGE`を指定し、リリース版で外すという運用が一般的だが、最近のメインフレームのCPUパワーなら、本番稼働させっぱなしでも大したオーバーヘッドにはならない。「安心料」として本番投入を推奨するのが、今の私の流儀だ。
2. VSAMアクセスとの相性:
VSAMのレコードバッファを配列にマッピングしている場合、レコード長が定義より短いと、配列の末尾へのアクセスで`SUBSCRIPTRANGE`が火を噴くことがある。これはバグではなく、「入力データが仕様を満たしていない」という通知だ。このエラーを握りつぶしてはいけない。仕様書と実際のデータが乖離している証拠なのだから。
—
最後に：エンジニアとしての姿勢
PL/Iは古い言語と言われるが、そのメモリ管理の精密さと、例外ハンドリングの柔軟性は今なお強力だ。`SUBSCRIPTRANGE`のようなチェック機能を「単なるデバッグ用」と捉えるか、「プログラムの品質を担保する防波堤」と捉えるかで、君が作るシステムの寿命は大きく変わる。
「動けばいい」コードから「壊れない（壊れても自己申告する）」コードへ。この小さなオプション設定一つが、君を一段上のメインフレーマーへと引き上げるはずだ。
もし大規模な改修案件で、「どれが原因か特定できないクラッシュ」に遭遇したら、まずはこのオプションを疑え。それが、長年この世界で生き残ってきた私の経験則だ。頑張ってくれ。
