PL/Iの「境界なき世界」を歩む：ON SUBSCRIPTRANGEと守護者の矜持
メインフレームの現場で長くPL/Iと対峙していると、時折、C言語の`Segmentation Fault`が可愛く見える瞬間がある。PL/Iには、他言語のような厳格な「予約語」という概念が希薄だ。変数名に`IF`や`THEN`を使えてしまうこの仕様は、言語設計者の野心を感じさせる一方で、一度のタイポがコード全体をカオスに陥れる諸刃の剣でもある。
特に、基幹システムの心臓部である配列操作において、添字の範囲外アクセスは、単なるバグという言葉では片付けられない。今回は、PL/Iにおける配列境界チェックの要『ON SUBSCRIPTRANGE』と、その先にあるアーキテクトの美学について語ろう。
1. ON SUBSCRIPTRANGE：見えざる境界を守る防波堤
PL/Iでは、コンパイルオプションに `SUBSCRIPTRANGE` を指定することで、実行時に配列の添字が宣言範囲を超えていないかを監視できる。しかし、これをプロダクション環境で常にONにすることには、相応の覚悟が必要だ。
実行時オーバーヘッドと最適化のトレードオフ
`SUBSCRIPTRANGE`を有効にすると、すべての配列アクセスに対して境界チェック用の機械語命令が挿入される。小規模なプログラムなら誤差だが、数百万行のバッチ処理や、CICSのトランザクション内で頻繁に呼び出されるサブルーチンにおいては、CPUサイクルを浪費する「重い足枷」となり得る。
/i
/ コンパイラオプション例: RULES(SUBSCRIPTRANGE) を指定 /
/ 以下のコードは、通常ならアベンドに至るケースを捕捉する /
DCL ARR(10) FIXED BIN(31) INIT((10)0);
DCL I FIXED BIN(31);
/ ONユニットによる例外ハンドリング /
ON SUBSCRIPTRANGE BEGIN;
PUT SKIP LIST(‘警告: 配列の範囲外アクセスが発生しました’);
/ 必要に応じてログ出力やダンプを取得し、安全に終了させる /
CALL ABEND_ROUTINE;
END;
I = 11;
ARR(I) = 999; / ここで範囲外アクセスが発生し、ONユニットが発火する /
2. 基幹システムにおけるダンプ解析と「見えないバグ」
マイグレーション先のJavaやC#では例外（Exception）がスタックトレースを伴って飛んでくるが、レガシーな世界ではそうはいかない。`SUBSCRIPTRANGE`なしで範囲外アクセスが発生した場合、何が起きるか？ 運が良ければ `S0C4` アベンドで止まる。しかし、最悪なのは「隣のメモリを破壊して、数時間後に全く関係ない箇所で異常終了する」というケースだ。
特に危険なのが、パックデシマル（PIC S9(7)V99 COMP-3など）のオーバーレイだ。配列の境界を越えて書き込まれたデータが、符号ビットを反転させたり、数値を不正な値に書き換えたりする。これをダンプ解析で突き止めるのは、まさに砂漠で針を探す作業に等しい。
アーキテクトの視点：ポインタ操作との親和性
PL/Iのポインタ（`BASED`変数）を使用している場合、`SUBSCRIPTRANGE`によるチェックはさらに重要度を増す。メモリを直接アドレス指定する場合、コンパイラは配列のサイズなど知る由もない。
/i
DCL P PTR;
DCL ARR(10) BASED(P) FIXED BIN(31);
/ 動的メモリ確保時の境界管理はプログラマの責務 /
/ ここで確保したサイズと、後に使用する添字の整合性をどう保つか /
/ これが設計者の腕の見せ所となる /
3. マイグレーションの教訓：なぜ「言語仕様」に依存してはいけないか
現在、多くの金融機関がPL/IからJava/C#への移行を進めている。ここで最も危険なのは、「PL/Iの緩い仕様」をそのまま新しい言語に持ち込もうとすることだ。
- 予約語の欠如への対処: PL/Iでは変数名に制約がないため、古いコードには`SELECT`や`WHILE`といった文字列が変数名として混入している。これらは移行時のトークナイザを確実に混乱させる。
- DB2埋め込みSQLとの相性: CICS/DB2環境で`SUBSCRIPTRANGE`をONにしていると、DB2のホスト変数として渡す配列の境界判定で予期せぬアベンドを誘発することがある。SQLCAのハンドリングと、PL/I側のエラー検知のどちらを優先するかは、システムアーキテクチャ設計における「政治的な判断」が必要だ。
結論：技術はツールであり、防御は哲学である
`ON SUBSCRIPTRANGE`は、開発中のデバッグツールとしては極めて優秀だが、本番環境の恒久的な対策としては不十分だ。真に強固なシステムを作るのであれば、以下の3点を徹底してほしい。
1. 境界チェックは言語に頼らずロジックでガードする: 配列操作の直前には必ず `IF` 文で範囲を検証する。これはコンパイラの最適化を阻害せず、かつ移植性も高い。
2. ダンプ解析を恐れるな: 16進ダンプを読み解く能力は、現代のどのデバッガよりも深い洞察をあなたに与えてくれる。
3. レガシーを「ゴミ」と呼ぶな: そのコードがなぜその仕様で書かれたのか、当時のメモリ制約やCPUコストを想像せよ。それができるアーキテクトだけが、新しいシステムでも生き残ることができる。
PL/Iの自由度は、我々プログラマへの「信頼」の証でもある。その信頼を裏切らないコードを書くこと。それこそが、この難解で美しい言語を使いこなす唯一の道だ。
