はじめに：予約語を持たない言語、PL/Iの深淵とFIXEDの魔力
メインフレームの現場で30年以上、数々の勘定系システムや巨大バッチの荒波を越えてきた私にとって、PL/Iという言語は、美しさと危うさが同居する比類なき存在です。
現代のJavaやC#のエンジニアから見れば、PL/Iは「古い遺物」に映るかもしれません。しかし、この言語には他の言語が羨むほどの圧倒的な柔軟性があります。その最たる例が、「PL/Iには予約語が存在しない」という事実です。
`IF`や`THEN`、さらには今回焦点を当てる`FIXED`といったキーワードでさえも、コンパイラは文脈（Context）からそれが命令なのか、それともプログラマが定義した変数名なのかを完璧に判断します。
1
/ こんな狂気のようなコードも、PL/Iコンパイラは文脈を理解してコンパイルします /
DECLARE FIXED FIXED(5,0);
FIXED = FIXED(12345, 3, 2);
この「何でもあり」の自由度の裏返しとして、数値演算の精度（Precision）やスケールに関する設計を誤ると、商用環境の深夜バッチで突如として惨劇を引き起こします。今回は、その防衛策の要であるビルトイン関数 `FIXED`を用いた精度調整と、マイグレーション時の罠について、現場の知見を総動員して解説します。
—
1. FIXEDビルトイン関数の本質：切り捨てか、丸め（Rounding）か
金融や流通の基幹システムにおいて、数値の丸め誤差は1円のズレも許されない致命的なバグに直結します。PL/Iの `FIXED` 関数は、単なるデータ型のキャストではありません。指定した精度（Precision）とスケール（Scale）へ強制的に数値を収めるための強力なコンパイル時・実行時コントロールです。
基本構文とコンパイラの挙動
`FIXED(x [, p [, q]])`
- `x`: 対象となる数値式（固定小数点、浮動小数点、あるいはパック10進数など）
- `p`: 全体の桁数（精度）
- `q`: 小数点以下の桁数（スケール）
ここで多くのエンジニアが陥る誤解が、「`FIXED`関数は四捨五入（ROUND）を行ってくれるのか？」という点です。
結論から言いましょう。`FIXED` 関数自体は、単なる「切り捨て（Truncation）」を行います。 四捨五入を行いたい場合は、あらかじめビルトイン関数 `ROUND` と組み合わせるか、適切な加算を行う必要があります。この挙動を知らずに移行設計を行うと、Javaなどの `BigDecimal`（デフォルトで ROUND_HALF_UP などの丸めモードを持つ）との間で計算結果の末尾1桁が乖離し、監査ログで致命的な指摘を受けることになります。
—
2. 実務コード例：基幹バッチにおける金額計算とオーバーフロー防衛
実際の月次金利計算バッチを想定したPL/Iコードを見てみましょう。ここでは、浮動小数点演算の誤差を排除しつつ、`FIXED` 関数を用いて確実に小数点以下2桁へ丸め込み、さらにオーバーフロー（S0C7等のアベンド）を防ぐための実用的なパターンを提示します。
1
/ ————————————————————– /
/ 利率計算および金額端数処理モジュール /
/ ————————————————————– /
COMPUTE_INTEREST: PROC OPTIONS(MAIN);
DCL WS_PRINCIPAL FIXED DEC(15,2) INIT(123456789012.34); / 元本 /
DCL WS_RATE FIXED DEC(5,4) INIT(0.0275); / 利率: 2.75% /
DCL WS_RAW_RESULT FLOAT DEC(16); / 内部計算用（浮動小数点） /
DCL WS_FINAL_AMT FIXED DEC(13,2); / 最終金額（円未満切捨て） /
DCL WS_ROUNDED_AMT FIXED DEC(13,2); / 最終金額（四捨五入） /
/ 1. 浮動小数点による高精度な掛け算（中間バッファ） /
WS_RAW_RESULT = WS_PRINCIPAL WS_RATE;
/ 2. FIXED関数を用いた単なる切り捨て処理 /
/ 13桁の整数部、2桁の小数部に強制的にフォーマットし、あふれた上位桁は切り捨てる /
WS_FINAL_AMT = FIXED(WS_RAW_RESULT, 13, 2);
/ 3. ROUNDビルトイン関数とFIXEDの併用による四捨五入処理 /
/ 小数第3位を四捨五入して第2位までにする場合 /
WS_ROUNDED_AMT = FIXED(ROUND(WS_RAW_RESULT, 2), 13, 2);
PUT SKIP LIST(‘元本 : ‘, WS_PRINCIPAL);
PUT SKIP LIST(‘生計算結果 : ‘, WS_RAW_RESULT);
PUT SKIP LIST(‘切捨て結果 : ‘, WS_FINAL_AMT);
PUT SKIP LIST(‘四捨五入 : ‘, WS_ROUNDED_AMT);
END COMPUTE_INTEREST;
このコードのアーキテクチャ的ポイント
1. 中間変数の型選択: 巨大な元本に対して複雑な乗除算を行う場合、途中で桁あふれを起こさないように `FLOAT DEC` を一時的に経由させています。
2. `FIXED(WS_RAW_RESULT, 13, 2)` の意味: 単に代入するだけでなく、明示的に `FIXED` を挟むことで、コンパイラに対して「ここでコンパイル時または実行時に指定精度への切り詰めを行え」という強い意志を伝えています。これにより、意図しない精度の伝播を防ぎます。
—
3. レガシー移行（Java / C#）における致命的な罠
メインフレームからオープン系（Java等）へのマイグレーションプロジェクトにおいて、この `FIXED` 関数周辺の挙動差異は、幾多のプロジェクトを炎上させてきた「地雷原」です。
罠1：パックデシマルの内部符号反転とオーバーフロー
PL/Iの `FIXED DECIMAL` は、IBM汎用機のハードウェア命令（Decimal Instructions: `PACK`, `UNPK`, `ZAP`, `AP`, `SP` など）と1対1で結びついています。
例えば、メモリー上のゾーン10進数やパック10進数の最下位バイトの符号ニブル（C, D, Fなど）が不正な状態で `FIXED` 関数を通そうとすると、容赦なくS0C7アベンド（Data Exception）を引き起こします。
Javaの `BigDecimal` に移行する際、メインフレーム側から転送された電文（コボルコピー句やPL/IのSTRUCTURE）にゴミデータや空白（スペース）が混入していると、Java側で `NumberFormatException` が発生します。
移行設計では、PL/I側の `FIXED` による切り捨て・丸めロジックを、Javaの `BigDecimal#setScale(2, RoundingMode.DOWN)` や `RoundingMode.HALF_UP` に正確にマッピングし、さらにパース前のパディングチェック（Numeric Check）を厳密に実装する必要があります。
罠2：埋め込みSQL（DB2）との暗黙的キャスト
CICSオンラインやバッチ内でDB2を叩く際、HOST変数に `FIXED DEC` を使用しているケースは多々あります。
DB2の列定義（例: `DECIMAL(11,2)`）に対して、PL側の変数の精度が異なると、DB2プリコンパイラやランタイム（DSNLLIなど）が暗黙的なデータ変換を行います。この時、`FIXED` 関数で明示的に精度を合致させておかないと、SQLCODE = -407（NULL不許可列への不正値）や、最悪の場合は切り捨てによるデータ損失がサイレント（警告なし）で発生します。
—
4. コンパイラオプションと最適化の極意
IBM Enterprise PL/I コンパイラを使用する場合、数値演算や `FIXED` 関数の振る舞いはコンパイラオプションによって最適化の度合いが変わります。
- `TRUNC(BIN)` vs `TRUNC(STD)` vs `TRUNC(OPT)`:
これがバイナリ整数（FIXED BINARY）における最大の肝です。
`TRUNC(STD)` が指定されている場合、PL/I言語仕様に厳密に従い、算術演算のたびに宣言された桁数（精度）に合わせて切り捨て（あるいはマスク）が行われます。これがパフォーマンスのボトルネックになることがあります。
一方、`TRUNC(BIN)` を指定すると、コンパイラはハードウェアのレジスタ幅（32ビットまたは64ビット）のフルサイズで計算を行い、無駄なマスク命令を生成しません。
しかし、`TRUNC(BIN)` の下で `FIXED` 関数による明示的な精度調整を怠ると、予期せぬ大きな値が変数に保持され、後続のロジックでバグの原因になります。高速化のために `TRUNC(BIN)` を採用するアーキテクトは、必ずこの `FIXED` 関数によるガードをコードの要所に挟む必要があります。
—
おわりに：レガシーの知見を未来のアーキテクチャへ
PL/Iの `FIXED` ビルトイン関数は、単なる「型変換の道具」ではありません。それは、ハードウェアのアーキテクチャとダイレクトに通信し、数値を完全に支配するためのエンジニアの剣です。
モダンな言語へシステムを移行する際、私たちはコードのシンタックス（構文）を書き換えるだけでなく、「なぜその関数が存在し、どのようなハードウェア制約とビジネス要件の妥協点の上にそのコードが書かれているのか」という文脈を読み解く必要があります。
この深い背景を理解しているテックリードこそが、レガシー移行を成功に導く唯一の存在です。次のバッチ改修や移行設計の際には、ぜひこの `FIXED` 関数の裏側にあるコンパイラの息吹を感じながら、堅牢なコードを組み上げてください。
