こんにちは！メインフレームの世界へようこそ。
JavaやCOBOLといったモダン、あるいはビジネス寄りの言語をバリバリ書いてきた方にとって、IBMの汎用機（メインフレーム）やPL/Iという言語は、どこか要塞の壁のように高く、冷たく感じられるかもしれません。
特に「浮動小数点数」の話になると、電卓の画面の向こう側で何が起きているのか、途端にブラックボックス化して不安になりますよね。でも、安心してください。怖がる必要は全くありません。今回は、JavaやCOBOLとは一味違う、PL/Iにおける浮動小数点数（`FLOAT`）の深淵――「IEEE 754形式」と「IBM独自のレガシー形式」のせめぎ合いについて、一緒に優しく紐解いていきましょう。
実務のマイグレーション現場で「あれ？テスト結果の桁が微妙にズレるぞ…？」と冷や汗をかく原因の多くは、ここを知るだけでスッキリ氷解しますよ。
—
1. そもそもPL/Iの「識別子」と「予約語」の優しいお話
本題に入る前に、PL/Iのちょっと変わった性格をご紹介させてください。
JavaやCOBOLでは、`if` や `class`、`DISPLAY` といったキーワードは「予約語」と呼ばれ、変数名として使うことは厳禁ですよね。もし使ったらコンパイルエラーで怒られてしまいます。
しかし、PL/Iには「予約語」という概念がほぼ存在しません。
どういうことかと言うと、PL/Iのコンパイラは、前後の文脈（Context）を見て、「あ、ここで使われている `FLOAT` はデータ型だな」「こっちの `FLOAT` は変数名だな」と空気を読んで賢く判断してくれます。
例えば、こんなコードが書けてしまいます。
1
/ PL/Iの驚きの柔軟性（コンテキスト依存） /
DCL FLOAT FIXED(5) INIT(100); / 変数名に FLOAT を使っちゃった例 /
DCL 1 DATA_REC,
2 VALUE FLOAT; / こっちは本当のデータ属性としての FLOAT /
/ 文脈で判断されるため、コンパイルエラーにはなりません /
FLOAT = FLOAT + 10;
初めて見たときは「なんて自由奔放な言語なんだ…！」と驚きますよね。レガシー言語でありながら、この柔軟性はどこかモダンですらあります。
—
2. 浮動小数点数（FLOAT）の基本と、見えない落とし穴
さて、本題の `FLOAT` です。
金利計算や厳密な通貨計算では固定小数点（`FIXED` / COBOLの `COMP-3` など）を使いますが、科学技術計算や確率統計、あるいは巨大な売上予測のシミュレーションなどでは、桁数がダイナミックに変わる浮動小数点数（`FLOAT`）が必須になります。
PL/Iでは、大きく分けて以下の2種類の `FLOAT` を宣言できます。
1. `FLOAT DECIMAL`（10進浮動小数点）
2. `FLOAT BINARY`（2進浮動小数点）
ここでJavaエンジニアの皆さんなら、「あれ、Javaの `float` や `double` はIEEE 754の2進数だよね」とピンと来るはずです。COBOLでも `COMP-1`（単精度）や `COMP-2`（倍精度）として扱われます。
しかし、IBMメインフレーム（ z/Architecture ）には、歴史的な背景から「2つの顔」を持っています。それが今回の主役である 「IBM独自形式（十六進浮動小数点数: HFP）」 と 「IEEE 754形式（二進浮動小数点数: BFP）」 です。
—
3. IBM形式 vs IEEE 754：何が違うの？
ここからが、マイグレーション時のトラブルの温床になりやすいポイントです。
① IBM形式（HFP：Hexadecimal Floating-Point）
メインフレームの歴史の始まりから存在する、いわば「古き良きIBM専用のモノサシ」です。
- 特徴: 基数が「16（16進数）」です。
- メリット: 昔のハードウェア上で非常に高速に動作するように設計されました。
- デメリット（ここが重要！）: 10進数の「0.1」を正確に表現できません。人間が「0.1」と書いても、16進数の世界に無理やり変換して丸めるため、計算を繰り返すうちに誤差が蓄積しやすいというクセがあります。
② IEEE 754形式（BFP：Binary Floating-Point）
現代のオープン系サーバーやJava、PCの世界で標準となっている「世界共通のモノサシ」です。
- 特徴: 基数が「2（2進数）」です。
- メリット: 世界中のシステムとデータ互換性があり、誤差の振る舞いが予測しやすいです。
- IBMでの扱い: 最近の z/Architecture プロセッサ（ z10 以降など）では、ハードウェアレベルでこのIEEE 754をネイティブに高速処理できるようになっています。
—
4. 実務で遭遇する「丸め誤差」とマイグレーションの罠
例えば、COBOLやオープン系のJavaから移行してきたシステムと、長年動き続けているメインフレームのPL/Iバッチの間で、「最終的な集計結果の末尾数セント（あるいは小数点第5位）が一致しない！」という怪奇現象が起きることがあります。
犯人は大抵、この「IBM形式（HFP）」と「IEEE 754（BFP）」の丸め方の違いです。
- IBM形式：16進数ベースなので、シフト演算の刻みが「4bit単位」になります。
- IEEE 754形式：2進数ベースなので、「1bit単位」の細かい刻みになります。
この違いにより、同じ数式を計算させても、中間バッファやファイル（外部データ）に書き出す際の「丸め（Rounding）」のタイミングで、微小な差が生まれてしまうのです。
—
5. PL/Iでの実際のコード例と書き方
PL/Iでそれぞれの形式を明示的に使い分けてみましょう。
実務のマイグレーションでは、コンパイルオプション（`AFP` や `FLOAT` サブパラメータなど）と合わせて、ソースコード側でも意図を明確にすることが大切です。
1
/ ======================================================== /
/ 浮動小数点数（FLOAT）の宣言と演算のサンプルプログラム /
/ ======================================================== /
TEST_FLOAT: PROC OPTIONS(MAIN);
/ 1. IBM形式（デフォルトの十六進浮動小数点 HFP）の宣言 /
/ ※プレシジョン（精度）を指定して倍精度（LONG）にする場合 /
DCL IBM_VAL_D FLOAT DECIMAL(16); / 約16桁の10進精度 /
DCL IBM_VAL_B FLOAT BINARY(53); / 約53桁の2進精度（長精度） /
/ 2. IEEE 754形式（二進浮動小数点 BFP）を明示的に指定する場合 /
/ z/OSのPL/IコンパイラではIEEE属性を指定できます /
DCL IEEE_VAL FLOAT BINARY(53) IEEE;
/ 値の代入 /
IBM_VAL_D = 12345.6789012345;
IEEE_VAL = 12345.6789012345;
PUT SKIP LIST (‘— 浮動小数点数の比較テスト —‘);
PUT SKIP EDIT (‘IBM形式 (DEC): ‘, IBM_VAL_D) (A, F(20,10));
PUT SKIP EDIT (‘IEEE形式(BIN): ‘, IEEE_VAL) (A, F(20,10));
/ 注意喚起のコメント：
もし外部ファイルやDB2を介してJava側とデータをやり取りする場合、
IBM形式のまま渡すと、Java側（IEEE 754前提）で数値の不一致が起きます。
マイグレーション時はコンパイルオプションや属性（IEEE）の付与を検討しましょう。
/
END TEST_FLOAT;
—
6. まとめ：怖がらなくて大丈夫です
いかがでしたでしょうか？
「IBMメインフレームの浮動小数点」と言われると、何やら難解な呪文のように聞こえますが、要するに「使っているモノサシの目盛りが、16進数（IBM独自）なのか、2進数（世界共通IEEE 754）なのかの違い」それだけです。
もし今後、移行プロジェクトなどで「数値の端数が合わない！」という壁にぶぶんだときは、
1. ソースコードの `FLOAT` 宣言に `IEEE` 属性が抜けていないか？
2. コンパイラオプションの浮動小数点デフォルト設定はどうなっているか？
3. 入出力ファイル（QSAMやVSAM）のデータ構造が異なっていないか？
この3点をそっと確認してみてください。必ず原因を見つけ出すことができます。
レガシーシステムの海原は広大ですが、一つひとつの波のうねりを理解していけば、決して怖い場所ではありません。あなたのメインフレームの旅が実り多いものになるよう、これからも応援しています！
