メインフレームの心臓部を揺るがす「SIZE条件」の深層
金融機関の勘定系や、数百万件のレコードを夜通し処理する巨大なバッチ基幹システム。そこで稼働するPL/Iプログラムは、30年以上の長きにわたり企業の信頼を背負ってきました。しかし、現代のオープン系エンジニアや、これからJava/C#へのマイグレーション（レガシー移行）を控えたテックリードたちが最も頭を悩ませるのが、この「数値データの精度とオーバーフロー」にまつわる挙動です。
特に `FIXED DECIMAL` や `FIXED BINARY` で定義された変数が、演算の結果として宣言された桁数・精度を超えたとき、PL/Iの世界では何が起きるのか。そして、なぜそれが予期せぬアベンド（ABEND）や、さらに恐ろしい「サイレント・データ破損」を引き起こすのか。今回は、コンパイラの内部挙動から実務のエッジケースまで、システムアーキテクトの視点で徹底的に紐解いていこう。
—
1. FIXED DECIMAL / BINARY と SIZE条件のメカニズム
PL/Iにおける固定小数点数は、単なる数値コンテナではありません。宣言された精度（Precision）は、コンパイラに対して「この変数が保持すべき有効桁数」を厳密に指示する契約です。
例えば、以下のような宣言を考えてみます。
DCL WK-AMT FIXED DECIMAL(5, 2) VALUE(0);
DCL WK-EXT FIXED DECIMAL(7, 2) VALUE(0);
`WK-AMT` は整数部3桁、小数部2桁（全体で5桁）のゾーン十進数またはパック十進数としてメモリ上に配置されます。ここに何らかの演算の結果、`1000.00` が代入されようとした瞬間、整数部が溢れます。この時、PL/Iランタイムが検知するのが `SIZE` 条件 です。
C言語やJavaのプリミティブ型であれば、単に上位ビットが切り捨てられたり、オーバーフローした値がそのままラップアラウンドして格納されたりするところですが、PL/Iは違います。デフォルトでは、`SIZE` 条件が発生するとプログラムは即座にインタラプトされ、お馴染みのシステムABEND（IBM汎用機であれば `ASRA` や特定のエラーコード、あるいはユーザーUxxxx）へと直行します。
OVERFLOW条件との違い
ここでよく混同されるのが `OVERFLOW` 条件です。
- `OVERFLOW` 条件: 浮動小数点数（FLOAT）の指数部が表現限界を超えたときに発生します。
- `SIZE` 条件: 固定小数点数（FIXED）において、有効桁数の損失（Significant digits loss）が発生したときに発生します。
基幹システムで扱う金額や数量はすべて `FIXED` です。したがって、私たちが警戒すべきは常に `SIZE` 条件なのです。
—
2. ON UNIT による例外制御と動的メモリ・ポインタの罠
PL/Iの優美でありながら時に諸刃の剣となる機能が、この例外条件を捕捉する `ON` ユニットです。
ON SIZE
BEGIN;
/ ログ出力や代替処理をここに記述 /
DISPLAY(‘【警告】SIZEオーバーフローを検出しました。安全値にフォールバックします。’);
WK-AMT = 999.50; / 緊急回避的な丸め処理 /
END;
一見すると、この `ON SIZE` ユニットはバッチ処理の堅牢性を高める万能薬に見えます。しかし、ここにベース変数（Based変数）とポインタ（Pointer）を組み合わせた動的ストレージ操作が絡むと、途端に地獄のようなデバッグ迷宮が幕を開けます。
例えば、ストレージ管理を自前で行うために `ALLOCATE` で獲得した領域内で `SIZE` が発生し、その `ON` ユニットの中でさらに動的変数を操作、あるいはポインタ経由で別のストレージを書き換えるような設計にしている場合、割り込みコンテキストの複雑化により、スレッドセーフティや再入可能性（Reentrancy）が崩壊します。
コンパイラオプションで `CHECK(SIZE)` や `STGIO` などを適切に付与していなければ、ポインタ経由の不正参照と `SIZE` オーバーフローが複合し、ストレージの踏みつけ（Storage Overwrite）を引き起こして、何関係のない別のトランザクションを巻き込んでダウンするという、メインフレーム特有の難解な障害に発展します。
—
3. コンパイラオプションによる最適化と「隠れた危険」
IBM Enterprise PL/Iコンパイラを使用する際、私たちは常にパフォーマンスと安全性のトレードオフに直面します。ここで注意すべきが、コンパイラ最適化レベル（`OPT(2)` や `OPT(3)`）と `NOSIZE` / `SIZE` オプションの関係です。
コンパイル時に `NOSIZE`（デフォルトであることが多い）を指定している場合、PL/Iコンパイラは「演算結果がオーバーフローしない」という前提でコードを最適化します。つまり、桁あふれを検知するためのマシン語命令（パッキング十進数の演算における桁あふれチェックなど）がコードから削ぎ落とされます。
これが何を意味するか？
オーバーフローが発生しても検知されず、上位の桁がサイレントに切り捨てられたまま、誤った金額データがDB2のテーブルやVSAMファイルに書き込まれるという、基幹システムにとって最も恐ろしい「データの腐敗」が発生するのです。
テックリードとしてプロジェクトを率いる場合、新規開発や改修時には必ず以下のポリシーを徹底すべきです。
- テスト環境（IT・ST環境）： `SIZE` オプションを有効化し、潜在的な桁あふれを確実に捕捉する。
- 本番環境： パフォーマンスを極限まで追求するバッチにおいて、厳密な入力バリデーションが上流で担保されているという前提のもとで `NOSIZE` を選択する場合もあるが、金額計算ロジックを含むモジュールでは必ず `SIZE`（または局所的な `REVERSIBLE` なガード）を維持する。
—
4. エッジケース：埋め込みSQL（DB2）とパックデシマルの内部符号反転バグ
実務で最もシビれるシチュエーションの一つが、CICSオンラインやバッチから呼び出されるDB2（埋め込みSQL）とのデータのやり取りです。
データベース側のカラムが `DECIMAL(9,2)` で定義されており、PL/I側のホスト変数も `FIXED DECIMAL(9,2)` で完全に一致させているにもかかわらず、特定のレコードをフェッチした瞬間に `SIZE` またはデータ例外（S0C7など）が発生することがあります。
これは、DB2側から返されたパックデシマル（Packed Decimal）の最下位ニブル（ゾーン/符号部）が、何らかの原因（外部からの不正データインポートやレガシーなファイル移行時の文字コード変換ミスなど）で、正しい符号（`C`, `D`, `F` 等）以外の不正なビットパターンを持っている場合に発生します。
/ DB2からのフェッチ処理例 /
EXEC SQL
SELECT TRANSACTION_AMT
INTO :H-TRAN-AMT
FROM ACCT_LEDGER
WHERE ACCT_ID = :I-ACCT-ID;
/ この直後にH-TRAN-AMTの演算を行うと、不正符号によるS0C7やSIZEが発生する /
このようなエッジケースに対し、単に `ON SIZE` でトラップするだけでは不十分です。データアクセス層に入る前に、あるいはDB2から取得した直後に、ホスト変数の有効性を検証するサブルーチンを挟むか、あるいはマイグレーション時にオープン系のRDBへ移行する際、データ型のマッピング定義（例えばJavaの `BigDecimal` への変換ルール）において、符号部やスケールの丸め誤差の挙動を完全に一致させる設計が不可欠となります。
—
5. レガシー移行（Java/C#）におけるアーキテクチャ設計の急所
メインフレームからJavaやC#へのマイグレーションを行う際、最も多くのプロジェクトが暗礁に乗り上げるのが、この「固定小数点の丸めとオーバーフローの挙動の差異」です。
Javaの `BigDecimal` を用いる場合、演算結果のスケールや丸めモード（`RoundingMode`）を明示的に指定しないと、PL/Iの `FIXED DECIMAL` が持つ暗黙の切り捨て・四捨五入ルールと一致しません。さらに、JavaにはPL/Iの `ON SIZE` に相当する大域的な例外捕捉機構はありません。すべての演算において、オーバーフローの可能性を考慮したバリデーションコード、あるいはカスタムのラッパーライブラリを設計する必要があります。
移行設計の現場では、以下のステップを踏むことが鉄則です。
1. PL/Iソースコードの静的解析: すべての `FIXED` 変数の宣言と、演算が行われている箇所を網羅的に洗い出す。
2. 有効桁数マトリクスの作成: 各変数が取りうる最大値・最小値を定義し、移行先の型（`int`, `long`, `BigDecimal(p,s)`) がそれを完全に包含できるか検証する。
3. 例外ハンドリングの等価性担保: メインフレームで `ON SIZE` がアベンドを引き起こしていた箇所について、移行先システムでも同等のトランザクション異常終了（ロールバック）を引き起こすか、あるいは厳格なログ出力とエラーキューイングを行うようビジネスロジックを再構築する。
—
結びに代えて
PL/Iの `FIXED DECIMAL / BINARY` と `SIZE` 条件は、単なるエラー処理の構文ではありません。それは、数兆円規模の資金移動や、一秒を争うロジスティクスを支え続けるメインフレームが、自らのデータの「整合性と高潔さ」を保つために備えた、極めて厳格な自己防衛システムです。
この言語仕様の深層を理解せずして、真のレガシー移行は語れません。コンパイラの挙動を熟知し、メモリの隅々まで目を光らせるシステムアーキテクトの知見こそが、新時代への確実な橋渡しとなるのです。
