PL/Iの「見えない罠」を制する：ON SIZEによる算術オーバーフローの制御術
諸君、今日もメインフレームの迷宮で格闘していることと思う。
PL/Iという言語は、C言語のような「予約語によるガチガチの制約」を持たない、非常に自由度が高い言語だ。しかし、その自由さは時として「意図しない挙動」という形で牙を剥く。
特に、勘定系や大量の計算を伴うバッチ処理において、最も恐ろしいのは「計算結果の桁あふれ」だ。今回は、算術演算の安全性を担保する `ON SIZE` 条件と、それが引き起こすパフォーマンスへの影響について、実務の視点から紐解いていこう。
—
1. 予約語を持たないPL/Iと識別子の自由度
まず基本の確認だ。PL/Iは `IF` や `THEN` といったキーワードであっても、文脈によっては変数名として使用できてしまう。これは設計の歴史的経緯によるものだが、保守の現場では「悪夢」になり得る。
例えば `DECLARE IF FIXED BIN(31);` と書くような無茶は論外だが、システム全体で命名規則を厳格に定義しておかないと、コンパイラが「これは予約語か、それとも変数か？」と迷走し、結果として解析コストが増大する。大規模なマイグレーションの際、最も苦労するのがこの「自由すぎる識別子」の整理だ。命名はシンプルかつ一意に。これがバグを未然に防ぐ第一歩だ。
—
2. ON SIZE条件：算術オーバーフローとの対峙
PL/Iの算術演算において、`FIXED DECIMAL` や `FIXED BINARY` が定義された変数の桁数を超えた場合、デフォルトではエラーにならず、「黙って切り捨て」が発生することがある。これは金融計算では致命的だ。
そこで登場するのが `ON SIZE` 条件である。
実践的なコード例
以下に、VSAMファイルから読み込んだデータを計算し、オーバーフローを検知する標準的なコーディング例を示す。
/i
/ 算術オーバーフローの監視ブロック /
ON SIZE BEGIN;
/ エラーログ出力処理などをここに記述 /
PUT SKIP EDIT (‘ OVERFLOW DETECTED: 計算結果が桁あふれしました ‘) (A);
/ 必要に応じてリカバリー処理や異常終了処理へ分岐 /
GO TO ERROR_HANDLING;
END;
/ 計算処理の実行 /
BEGIN;
/ SIZE属性を有効にするためには、コンパイルオプションでSIZE指定が必要 /
/ ここでは演算結果を一時変数に格納 /
DCL WORK_AMT FIXED DEC(9, 2);
/ 大規模バッチでは、こうした演算で桁あふれが潜伏しやすい /
WORK_AMT = INPUT_AMT TAX_RATE;
END;
—
3. なぜ「SIZE属性」はパフォーマンスを落とすのか
ここでベテランとして警鐘を鳴らしておきたい。「安全のために全てに `ON SIZE` をつければいい」というのは短絡的だ。
PL/Iコンパイラにおいて `SIZE` オプションを有効にすると、生成されるオブジェクトコードには、すべての算術演算の直後に、結果が定義した精度内に収まっているかをチェックする命令（テスト命令）が挿入される。
- チェックなし: 数サイクルで終わる演算が、
- チェックあり: 比較命令と条件分岐が毎回挟まるため、CPUサイクルを浪費する。
大規模バッチで数億件のレコードを処理する場合、このオーバーヘッドは無視できない遅延となって現れる。
実務での判断基準
1. クリティカルな金銭計算: `SIZE` オプションおよび `ON SIZE` を必ず適用する。
2. 単なる集計・カウント: 計算範囲が論理的に保証されている場合は、`NOSIZE` でコンパイルし、高速化を優先する。
3. ハイブリッド戦略: 全体を `NOSIZE` でコンパイルしつつ、特に重要な計算ブロックの周辺で `CONDITION` を明示的に制御する。
—
4. エンジニアへのアドバイス：デバッグのコツ
もし現場で「計算結果がおかしい」というバグ報告が上がったら、まずはコンパイルリストの「OPTIONS」を確認してほしい。そこに `NOSIZE` と記載されていれば、それが犯人である可能性が高い。
また、`ON SIZE` を使用する際は、必ず `ONCODE` ビルトイン関数と組み合わせて詳細な診断ログを出力する癖をつけておくこと。
/i
ON SIZE BEGIN;
DCL ERR_CODE FIXED BIN(15);
ERR_CODE = ONCODE();
PUT SKIP EDIT (‘ERROR CODE:’, ERR_CODE) (A, F(5));
/ ここでダンプを採取するか、異常終了させるかの判断を行う /
END;
PL/Iは古い言語だが、その堅牢性は正しく扱えば最強の武器になる。コードの裏側でCPUが何をしているかを想像する。それができるアーキテクトこそが、メインフレームの明日を支えるのだ。
不明点があればいつでも相談してくれ。バッチのログには、常に真実が刻まれているものだからな。
