こんにちは！メインフレームの世界へようこそ。
JavaやCOBOLといったモダン、あるいはビジネスチルドレンな言語をバリバリ書いてきた方にとって、IBMメインフレームの「PL/I（ピーエルワン）」という言語は、どこか古めかしく、かつ得体の知れない要塞のように見えるかもしれません。
特に、データ型の仕様書を開いた瞬間、こんな宣言に出くわすと、思わず冷汗が出てしまいますよね。
「なんだこれ、`FIXED BINARY` と `FIXED DECIMAL` が混ざって計算されてる……！？ 一体、内部で何が行われているんだ！？」
大丈夫です。怖がる必要はまったくありません。今回は、PL/Iが誇る「固定小数点数」の奥深い世界、特に異種格闘技戦である「FIXED BINARYとFIXED DECIMALの混在演算」について、現場のノウハウを交えながら優しく解きほぐしていきます。
—
1. そもそも `FIXED BINARY` と `FIXED DECIMAL` って何者？
他の言語（例えばCOBOLの `COMP-3` や `PIC 9`、Javaの `int` や `BigDecimal`）を経験している方なら、数字を扱うデータ型がある程度イメージできると思います。PL/Iにも、数字をキッチリ正確に扱うための「固定小数点数」という仕組みがあります。
ここに、PL/I特有の二大巨頭がいます。
- `FIXED DECIMAL`（パック十進数 / ゾーン十進数）
- 人間が普段使う「10進数」をそのままメモリに並べたものです。COBOLの `PIC S9(5)` の世界だと思ってください。
- 「お金（金額）」の計算など、1円の狂いも許されない領域で好んで使われます。
- `FIXED BINARY`（二進固定小数点数）
- コンピュータが大好きな「2進数（バイナリ）」の世界です。Javaの `short` や `int`、C言語の `long` に近い存在です。
- ループのカウンターや、内部的なフラグ、高速な算術演算の主役としてバリバリ働きます。
さて、この性質の全く異なる「10進数育ち」と「2進数育ち」のデータ同士を、うっかり同じ計算式（演算）で混ぜてしまったらどうなるでしょうか？
「おいおい、言葉が通じない相手同士で会話させたら喧嘩にならないか？」と心配になりますよね。でも、そこは百戦錬磨のPL/Iコンパイラ。ちゃんと裏側でスマートな「通訳」をしてくれているのです。
—
2. 混在演算の裏側：コンパイラは中で何をしているのか？
JavaやCOBOLであれば、型が違うとコンパイルエラーになるか、あるいはどちらかへ強制的にキャスト（型変換）されますよね。
PL/Iの場合、異種間の演算（例：`FIXED DECIMAL` ＋ `FIXED BINARY`）に出くわすと、コンパイラは次のような手順で暗黙の型変換（自動変換）を行います。
変換の基本原則：「十進数（DECIMAL）は、二進数（BINARY）に歩み寄る」
コンパイラは、計算を行う直前に、`FIXED DECIMAL` のデータを一時的な `FIXED BINARY` のワークエリアへこっそり変換します。
なぜ十進数を二進数に合わせるかというと、IBMメインフレームのCPU（System z）にとって、2進数の計算の方が圧倒的にネイティブで高速だからです。コンパイラは「どうせ計算するなら、こっちの土俵（二進数）に合わせてもらうぜ」とばかりに、裏でコソコソとデータを衣替えさせています。
—
3. ちょっと待って！「精度と桁あふれ（オーバーフロー）」の罠
ここで現場のエンジニアとして一番伝えたい、そして最もハマりやすい「落とし穴」のお話です。
コンパイラが自動で変換してくれるのはありがたいのですが、その際 「一時的な作業エリア（中間ワークエリア）の精度（桁数）」をどう決めるか というルールが存在します。
もし、あなたが次のような雑な宣言をしたとします。
- `DCL A FIXED DEC(15, 2);` （大きな金額）
- `DCL B FIXED BIN(15);` （ちっちゃなカウンター）
このふたつを足し算すると、コンパイラは `FIXED DEC` である `A` を `FIXED BINARY` に変換して計算します。この時、`A` の持っていた「15桁分の巨大な十進数の世界」を、`FIXED BINARY` の器に無理やり押し込めようとするため、思わぬ精度落ちや、最悪の場合はサイズ不足によるオーバーフロー（CrASH）を引き起こすことがあるのです。
「コンパイラが勝手にやってくれるから安心」ではなく、「コンパイラがどういうルールで器の大きさを決めているか」を知っておくことが、レガシーシステムの保全において非常に重要になります。
—
4. 実践！PL/Iコードで挙動を確認してみよう
百聞は一見にしかず。実際にどのようなコードで、どういった点に注意すべきかを見てみましょう。大文字ベースの典型的なPL/Iプログラムの断片です。
1
/ ======================================================= /
/ FIXED BINARY と FIXED DECIMAL の混在演算サンプル /
/ ======================================================= /
DEMO_CALC: PROC OPTIONS(MAIN);
/ データ定義 /
DCL WK_MONEY FIXED DECIMAL(9,2) INIT(12345.67); / 金額データ（10進数） /
DCL WK_COUNT FIXED BIN(15) INIT(10); / カウンター（2進数） /
DCL WK_RESULT FIXED DECIMAL(11,2) / 結果格納用 /
INIT(0);
/ 異なる基数同士の掛け算 /
/ WK_MONEY (DECIMAL) と WK_COUNT (BINARY) の混在 /
WK_RESULT = WK_MONEY WK_COUNT;
/ 結果の出力（PUT LIST） /
PUT SKIP LIST (‘計算結果は：’, WK_RESULT);
END DEMO_CALC;
このコードの裏側のストーリー
1. `WK_MONEY` は `FIXED DECIMAL(9,2)` です。
2. `WK_COUNT` は `FIXED BIN(15)` です。
3. `WK_RESULT = WK_MONEY WK_COUNT;` が実行される瞬間、PL/Iコンパイラは `WK_MONEY` を一時的に内部の `FIXED BINARY` 形式へと変換します。
4. 演算が完了した後、今度は代入先の `WK_RESULT`（`FIXED DECIMAL(11,2)`）の形に合わせるために、再び十進数へと戻して格納します。
「なるほど、ちゃんと辻褄が合うようにできているんだな」と思いましたか？
その通りです。基本的にはコンパイラが上手にハンドリングしてくれます。
しかし、実務の現場（特に何百万ステップもあるような古い基幹システムの改修）では、元の設計者が「なぜこの変数は BIN なのか、なぜこちらは DEC なのか」という意図を明確に残していないケースが多々あります。そこに安易に項を追加したり修正したりすると、この「暗黙の型変換と中間精度のマジック」によって、テストでは気づきにくい数円の端数ズレや、突発的なABEND（異常終了）を引き起こす原因になるのです。
—
5. まとめ：怖がらずに「型の意図」に寄り添おう
いかがでしたでしょうか？
`FIXED BINARY` と `FIXED DECIMAL` の混在演算は、一見すると呪文のように複雑に思えますが、突き詰めていえば以下のポイントだけ押さえておけば怖くありません。
- 基本はコンパイラの「十進数から二進数への歩み寄り（自動変換）」で行われる。
- ただし、中間ワークエリアの精度決定ルールにより、桁数や精度の思わぬ変化に注意する。
- 実務では、可能であれば演算の左右のデータ型を揃えてあげる（キャスト関数を使う、あるいは宣言を統一する）のが、バグを防ぐ一番の近道。
メインフレームの世界は、歴史が長い分、こうした細かいルールの積み重ねでできています。でも、一つひとつの仕様をこうして紐解いていけば、決して恐ろしいものではありません。
「あ、コンパイラは今、裏でこうやって通訳してくれてるんだな」と、愛着を持ってコードを眺められるようになると、あなたも立派なPL/I使いの仲間入りです。
日々のレガシーシステムとの格闘、ぜひ楽しんでいきましょう！
