こんにちは！メインフレームの世界へようこそ。
JavaやCOBOLといったモダン、あるいはビジネスチルドレンな言語をバリバリ書いてきた方にとって、IBMメインフレームの「PL/I（ピーエルワン）」という名前を聞くだけで、なんだか古めかしい呪文のような威圧感を感じてしまうかもしれませんよね。
「なんだこの独特な書き方は……」
「変数の宣言を見ただけで頭がクラクラする……」
でも、どうぞご安心ください。怖がる必要はまったくありません。今回は、PL/Iのデータ制御において避けて通れない、しかし避けると痛い目をみる「`FIXED BINARY(p,q)` の精度管理と、知られざる変換コストの秘密」について、現場のノウハウを交えながら、じっくりと紐解いていきます。
Javaの `int` や `long`、COBOLの `PIC S9(9) COMP` とは何が違うのか？ 一緒に見ていきましょう！
—
1. まずは基本！PL/Iの数値データ型ってどうなっているの？
JavaやCOBOLを経験した方なら、「数値を扱うなら整数か小数かで分ければいいんでしょ？」と思われるでしょう。もちろん、PL/Iにも大別して「10進数（DECIMAL）」と「2進数（BINARY）」があります。
- DECIMAL（10進数）: 人間が普段使う10進数そのままで計算します。COBOLの `COMP-3`（パック十進数）に近い感覚です。
- BINARY（2進数）: コンピュータが大好きな2進数で、CPUが直接計算できるスピードスターです。
さて、今回スポットを当てるのは、この2進数の固定小数点数である `FIXED BINARY(p, q)` です。
ここで、カッコの中にある `(p, q)` が初学者の最初の関門になります。
- `p` (Precision): 全体の精度（ビット数）を表します。符号ビットを含みます。
- `q` (Scale): 小数点以下の桁数（2進数の桁数ではなく、小数点位置のスケールです）を表します。
> 💡 ここがポイント！
> COBOLの `PIC S9(4) COMP` なら「4桁の10進数」ですが、PL/Iの `FIXED BINARY(15, 0)` は「15ビットの2進数」を意味します。この「桁数（DECIMAL）」と「ビット数（BINARY）」の勘違いが、移行初期によくあるバグの温床になります。
—
2. なぜ `FIXED BINARY(p,q)` の精度管理がシビアなのか？
基幹システムのバッチ処理などで、突然「S0C7（データ例外）」や、意図しない数値の丸め誤差（精度落ち）に悩まされたことはありませんか？
PL/Iの計算ルールは、コンパイラが非常に「良かれと思って」色々な自動変換を行ってくれる反面、それが災いしてパフォーマンスの低下や予期せぬ精度喪失を招くことがあります。
悲劇の例：暗黙の型変換コスト
例えば、次のようなコードがあったとします。
1
/ ————————————————– /
/ 異なるデータ型が混ざった演算の例 /
/ ————————————————– /
DCL WS_COUNT FIXED BIN(15, 0) INIT(100); / 16ビット相当の整数 /
DCL WS_RATE FIXED DEC(5, 2) INIT(1.25); / 10進数の小数 /
DCL WS_RESULT FIXED BIN(31, 2); / 結果を受け取る変数 /
/ 演算実行 /
WS_RESULT = WS_COUNT WS_RATE;
一見、何の問題もなさそうに見えますよね。「100に1.25をかけて125.00になるだけだろ？」と。
しかし、裏側でメインフレームのCPUとコンパイラは、次のような大忙しの作業（変換ルーチンの生成）を行っています。
1. 2進数 (`WS_COUNT`) を一旦 10進数 に変換する
2. `WS_RATE`（元々10進数）と掛け算をするために、DECIMAL用の演算ルーチンを呼び出す
3. 計算結果を、今度は代入先の `WS_RESULT` の属性（`FIXED BINARY`）に合わせて再度 2進数 に逆変換する
……お気づきでしょうか？
「2進数 ⇄ 10進数」の往復ビンタが、たった1行の掛け算の裏で行われているのです。これが、基幹システムで何百万件ものループ回数の中で実行されたとき、どれほどのCPU時間を無駄に消費するか……想像に難くないですよね。
—
3. 内部表現を知れば怖くない！「効率の良い」宣言のコツ
では、この無駄な変換コストを防ぎ、さらに精度の喪失（オーバーフローや丸め誤差）を防ぐにはどうすればよいのでしょうか。
答えはシンプルです。「計算に関わる変数のデータ属性をできる限り統一する」こと。そして、PL/Iの内部表現のサイズ（境界）を意識することです。
プラグマ的・実用コード例
メインフレームのアーキテクチャ（IBM Z）において、CPUが最も効率よく処理できるのは 31ビット（フルワード） または 15ビット（ハーフワード） のバイナリです。
1
/ ————————————————– /
/ 効率的かつ安全なFIXED BINARYの宣言と演算の例 /
/ ————————————————– /
ANALYZE_BATCH: PROC OPTIONS(MAIN);
/ 処理件数やカウンターは 15ビット（ハーフワード）で十分 /
DCL L_INDEX FIXED BIN(15, 0) INIT(0);
/ 金額や単価など、計算スピードが命の項目は BINARYで統一 /
DCL L_UNIT_PRICE FIXED BIN(31, 2) INIT(1000.00);
DCL L_QTY FIXED BIN(31, 0) INIT(50);
DCL L_TOTAL FIXED BIN(31, 2);
/ 型が完全に一致（ともに FIXED BINARY）しているため、 /
/ 余計な変換ルーチンは生成されず、CPUがダイレクトに高速演算します！ /
L_TOTAL = L_UNIT_PRICE L_QTY;
PUT SKIP LIST (‘計算結果（総額）: ‘, L_TOTAL);
END ANALYZE_BATCH;
このコードでは、計算に関わる `L_UNIT_PRICE` も `L_QTY` も、そして結果を受け取る `L_TOTAL` も、すべて `FIXED BINARY` で統一されています。これにより、コンパイラは余計な変換コードを一切生成せず、ハードウェア命令（マシーン語）を直接吐き出すため、爆速で処理が完了します。
—
4. アーキテクトからのアドバイス：レガシー移行時のチェックリスト
JavaやCOBOLからPL/Iの世界へ移行する際、または既存のPL/Iプログラムを保守する際には、次のポイントを必ず頭の片隅に置いておいてください。
1. 「なんとなくDECIMAL、なんとなくBINARY」をやめる
- 画面入出力や帳票の外部インターフェース項目は `DECIMAL`（または `CHARACTER`）でも良いですが、内部のカウンタや複雑な算術演算を行うループ内では、極力 `FIXED BINARY` へ寄せるとパフォーマンスが劇的に向上します。
2. 精度のビット数（`p`）の境界を意識する
- `FIXED BIN(15, q)` は 2バイト（ハーフワード）
- `FIXED BIN(31, q)` は 4バイト（フルワード）
- これ以外の半端なビット数（例えば `FIXED BIN(10, 0)` など）を指定すると、コンパイラが余計なマスク処理を挟む場合があり、かえって効率が落ちることがあります。基本は 15 か 31 を選ぶのがプロの技です。
3. 割り算（DIVISION）のスケールに注意
- PL/Iでは、割り算を行った際の自動的な結果の精度（`p, q`）の決定ルールが非常に複雑です。予期せぬオーバーフローや「FIXEDOVERFLOW」のシステム異常終了を防ぐため、演算結果を受け取る変数の桁数は、元の変数よりも十分に余裕を持たせるか、組み込み関数（`DIVIDE`関数など）を使って明示的に精度をコントロールしましょう。
—
おわりに
PL/Iの `FIXED BINARY(p,q)`、最初は厳格なルールや独特の表記に戸惑うかもしれません。でも、その仕様の裏側には「限られたメインフレームの資源をいかに極限まで効率よく動かすか」という、先人たちの知恵と工夫がぎっしり詰まっています。
「なぜこの型で宣言されているのか？」
その理由が分かれば、レガシーシステムのコードを読むのが、まるでパズルを解くように楽しくなってきますよ。
日々のマイグレーションや保守作業、大変なこともあるかと思いますが、一つひとつ紐解いていけば必ず理解できます。あなたのメインフレームライフを、心から応援しています！
