【入門編】FIXED DECIMAL(p,q)のパック10進数形式 – PL/Iの基本構文とデータ制御実践ガイド

皆さん、こんにちは！世界最高峰のIBMメインフレームシステムアーキテクトとして、皆さんのメインフレーム学習の旅をサポートします。

「メインフレーム？PL/I？なんだか古くて難しそう…」そんな風に思っていませんか？ご安心ください！JavaやCOBOLの経験がある皆さんなら、少し視点を変えるだけで、メインフレームの深い世界もきっと楽しくなってきますよ。

今回は、PL/Iのデータ型の中でも特に基幹システムで頻繁に利用され、かつその内部構造が面白い「FIXED DECIMAL(p,q)」に焦点を当てて、その秘密を紐解いていきましょう。COBOLの`COMP-3`、またはパック10進数と呼ばれる形式ですね。怖くないですよ、一つずつ丁寧に見ていけば、きっと「なるほど！」と唸るはずです。

—

メインフレームの世界へようこそ！PL/IのDECIMAL型を知る旅

メインフレームの基幹システムでは、お金や数量といった「正確さが命」のデータを扱うことが非常に多いですよね。小数点以下の誤差が許されない金融計算や、大量の在庫管理など、Javaでいう`BigDecimal`、COBOLでいう`COMP-3`のような、厳密な10進数演算が求められる場面が山ほどあります。

PL/Iでは、この厳密な10進数演算を担うのが「`FIXED DECIMAL`」というデータ型なんです。まずは、PL/Iプログラムの基本構造を軽くおさらいして、実際のコードを見ながら話を進めましょう。

PL/Iプログラムの基本構造（今回は軽く触れるだけ）

PL/Iのプログラムは、通常`PACKAGE`や`PROCEDURE`というブロックで構成されます。特に、プログラムのエントリーポイントとなるメインプロシージャは`OPTIONS(MAIN)`を指定します。

SAMPLE_PACKAGE: PACKAGE OPTIONS(MAIN);
/ ここにグローバルな宣言や、他のPROCEDUREを記述できます /

SAMPLE_PROCEDURE: PROCEDURE;
/ ここに実際の処理ロジックを記述します /

PUT SKIP LIST(‘Hello, PL/I World!’); / お決まりの挨拶ですね /

END SAMPLE_PROCEDURE;

END SAMPLE_PACKAGE;

今回はこの構造自体に深入りはしません。`FIXED DECIMAL`の話に集中できるよう、「ああ、こんなブロックの中にコードを書くんだな」くらいの理解で大丈夫です！

—

本題：FIXED DECIMAL(p,q) とは何か？

さあ、いよいよ本題の`FIXED DECIMAL(p,q)`です。

`FIXED DECIMAL(p,q)` は、その名の通り「固定小数点数の10進数」を扱うデータ型です。

`p`：その変数が保持できる総桁数（整数部と小数部を合わせた合計の桁数）
`q`：そのうちの小数部桁数

となります。

例えば、`FIXED DECIMAL(5,2)` と宣言すると、「合計5桁の10進数を扱うことができ、そのうち小数部が2桁ですよ」という意味になります。具体的には、`-999.99` から `+999.99` までの範囲の値を保持できる、ということですね。

COBOLのCOMP-3との関係性

COBOL経験者の方なら、「あれ？これってCOBOLの`COMP-3`と同じじゃない？」と感じるかもしれませんね。まさにその通り！PL/Iの`FIXED DECIMAL`は、COBOLの`PIC S9(n)V9(m) COMP-3`と同じ、パック10進数形式でデータを保持します。

ただし、`p`の定義が少し違います。

PL/Iの`p`: 総桁数（整数部＋小数部）
COBOLの`n`: 整数部桁数、`m`は小数部桁数

なので、PL/Iの`FIXED DECIMAL(5,2)`は、COBOLの`PIC S9(3)V9(2) COMP-3`と等価になります。どちらも「整数部3桁、小数部2桁で合計5桁」を意味しますね。

—

パック10進数の内部構造を徹底解剖！

ここからが本番です！このパック10進数が、メインフレームのメモリ上でどのように表現されているのかを深掘りしていきましょう。

パック10進数、別名`COMP-3`は、1バイト（8ビット）を2つの「ニブル」（nibble、半バイト、4ビット）に分割して使います。ちょうどお弁当箱が真ん中で仕切られているようなイメージですね。

各桁のニブル配置と符号ビットの秘密

1. 各桁が1ニブル:
各ニブルには、0から9までの10進数1桁が格納されます。例えば、`X’1’` は1、`X’9’` は9を表します。これが右詰めで、データが格納されるんです。

2. 符号ビット:
そして、一番右端のニブルの後半（下位4ビット）が、その数値の符号を表す特別な場所になります。

`X’C’` (1100) は正の符号
`X’D’` (1101) は負の符号
COBOLでは`X’F’` (1111) も正として扱われますが、PL/Iでは`X’C’`が標準的です。データ連携の際に、この符号の違いが思わぬトラブルの元になることもあるので、覚えておくと良いでしょう。

具体的な例でイメージを掴む

では、具体的な数値がどのようにメモリに格納されるか見てみましょう。
PL/Iの`FIXED DECIMAL(p,q)`のバイト長は、`CEIL((p + 1) / 2)` で計算されます（`CEIL`は切り上げ関数）。

例1: 正の数 `123.45` を `FIXED DECIMAL(5,2)` で格納する場合

総桁数 `p=5`、小数部 `q=2`。
バイト長は `CEIL((5 + 1) / 2) = CEIL(3) = 3` バイト。
数値は `12345` となり、右端のニブルに符号が付きます。

メモリ上ではこんな感じになります（各バイトを16進数で表現）：
`X’12345C’`

1バイト目: `X’12’` (1と2)
2バイト目: `X’34’` (3と4)
3バイト目: `X’5C’` (5と正の符号 ‘C’)

例2: 正の数 `12.34` を `FIXED DECIMAL(4,2)` で格納する場合

総桁数 `p=4`、小数部 `q=2`。
バイト長は `CEIL((4 + 1) / 2) = CEIL(2.5) = 3` バイト。

あれ？4桁なのに3バイト？そうなんです、この場合は先頭に暗黙的に `0` がパディングされます。

数値は `01234` となり、右端のニブルに符号が付きます。

メモリ上ではこんな感じになります：
`X’01234C’`

1バイト目: `X’01’` (0と1)
2バイト目: `X’23’` (2と3)
3バイト目: `X’4C’` (4と正の符号 ‘C’)

このように、`p`が偶数の場合でも、常にバイト長は「総桁数 + 符号桁」を2で割って切り上げた値になります。これにより、必ず右端に符号ニブルが来るように調整されるわけですね。

例3: 負の数 `-5.67` を `FIXED DECIMAL(3,2)` で格納する場合

総桁数 `p=3`、小数部 `q=2`。
バイト長は `CEIL((3 + 1) / 2) = CEIL(2) = 2` バイト。
数値は `567` となり、右端のニブルに負の符号が付きます。

メモリ上ではこんな感じになります：
`X’567D’`

1バイト目: `X’56’` (5と6)
2バイト目: `X’7D’` (7と負の符号 ‘D’)

これで、パック10進数の内部表現がイメージできたでしょうか？

—

演算時のオーバーヘッド：なぜ遅くなることがあるのか？

パック10進数の内部構造が分かったところで、次に気になるのが「じゃあ、これで計算するとどうなるの？」という点ですよね。
実は、`FIXED DECIMAL`の演算は、CPUによってはオーバーヘッドが発生しやすいという特性があります。

10進数演算の舞台裏

メインフレームのCPUは、通常は2進数で計算を行うように設計されています。皆さんが普段使っているPCのCPUも同じですよね。しかし、`FIXED DECIMAL`は10進数形式。ここに問題が発生します。

1. 変換: CPUが10進数形式のデータを受け取ると、まず内部で2進数に変換します。
2. 演算: 変換された2進数データを使って、加算や減算などの演算を行います。
3. 逆変換: 演算結果を、再び10進数形式（パック10進数）に戻します。

この「変換 → 演算 → 逆変換」という一連のステップが、一般的な2進数（`BINARY FIXED`など）の演算に比べて余分な処理となり、オーバーヘッドとして現れるのです。まるで、異なる言語を話す人同士が会話するために、間に通訳を挟むようなものですね。

それでもFIXED DECIMALを使う理由

では、なぜオーバーヘッドがあるにもかかわらず、メインフレームの基幹システムでこれほどまでに`FIXED DECIMAL`が使われるのでしょうか？

それは、ズバリ精度の保証です。
金融計算など、小数点以下のわずかな誤差も許されない業務では、2進数で表現しきれない10進数の値をそのまま扱う`FIXED DECIMAL`が不可欠なのです。パフォーマンスは多少犠牲になっても、計算結果の厳密な正確性が最優先されるため、このデータ型が選ばれ続けているわけですね。

—

PL/Iコード例で触ってみよう！

それでは、実際にPL/Iのコードで`FIXED DECIMAL`を使ってみましょう。

SAMPLE_PACKAGE: PACKAGE OPTIONS(MAIN);

SAMPLE_PROCEDURE: PROCEDURE;

/ FIXED DECIMAL変数の宣言 /
DECLARE MY_AMOUNT FIXED DECIMAL(7,2) INITIAL(1234.56); / 合計7桁、小数部2桁（例: 12345.67） /
DECLARE TAX_RATE FIXED DECIMAL(3,3) INITIAL(0.080); / 合計3桁、小数部3桁（例: 0.123） /
DECLARE TOTAL_PRICE FIXED DECIMAL(9,2); / 合計9桁、小数部2桁、結果格納用 /
DECLARE DISCOUNT FIXED DECIMAL(5,2) INITIAL(100.00); / 割引額 /
DECLARE NET_PRICE FIXED DECIMAL(7,2); / 割引後価格 /

PUT SKIP LIST(‘— FIXED DECIMALの計算例 —‘);

/ 値の表示 /
PUT SKIP LIST(‘初期金額:’, MY_AMOUNT); / MY_AMOUNTの値を表示 /
PUT SKIP LIST(‘税率:’, TAX_RATE); / TAX_RATEの値を表示 /
PUT SKIP LIST(‘割引額:’, DISCOUNT); / DISCOUNTの値を表示 /

/ 計算処理 /
TOTAL_PRICE = MY_AMOUNT (1 + TAX_RATE); / 金額に税率を乗じて合計金額を計算 /
NET_PRICE = MY_AMOUNT – DISCOUNT; / 金額から割引額を差し引いて正味金額を計算 /

/ 結果の表示 /
PUT SKIP LIST(‘税込合計金額:’, TOTAL_PRICE); / 計算結果を表示 /
PUT SKIP LIST(‘割引後金額:’, NET_PRICE); / 計算結果を表示 /

/ 桁あふれを意図的に起こす例 (SIZE条件) /
/ 以下の宣言では、MY_SMALL_DECはFIXED DECIMAL(3,0)なので、最大値は999 /
DECLARE MY_SMALL_DEC FIXED DECIMAL(3,0);

ON SIZE BEGIN; / SIZE条件が発生した場合の処理を定義 /
PUT SKIP DATA(MY_SMALL_DEC); / 桁あふれした変数の値を表示（不正確な値になる可能性があります） /
PUT SKIP LIST(‘!!! 桁あふれが発生しました (SIZE CONDITION) !!!’);
/ 実運用ではここでエラーログ出力やリカバリ処理を行います /
END;

MY_SMALL_DEC = 1000; / 意図的に桁あふれを発生させる /

PUT SKIP LIST(‘桁あふれ後のMY_SMALL_DEC:’, MY_SMALL_DEC);
PUT SKIP LIST(‘— 計算例終了 —‘);

END SAMPLE_PROCEDURE;

END SAMPLE_PACKAGE;

実行結果（例）：

— FIXED DECIMALの計算例 —
初期金額: 1234.56
税率: 0.080
割引額: 100.00
税込合計金額: 1333.32
割引後金額: 1134.56
MY_SMALL_DEC=999;
!!! 桁あふれが発生しました (SIZE CONDITION) !!!
桁あふれ後のMY_SMALL_DEC: 999
— 計算例終了 —

※`ON SIZE`コンディションは、桁あふれが発生した際にシステムが割り込む仕組みです。デフォルトではプログラムが異常終了しますが、このように`ON SIZE BEGIN; … END;`ブロックで捕捉することで、独自の処理を記述できます。この例では、`MY_SMALL_DEC = 1000;` と代入しようとした結果、`FIXED DECIMAL(3,0)`の定義（最大999）を超過したため、`SIZE`コンディションが発生し、値が切り詰められて`999`になっていますね。これはCOBOLの`ON SIZE ERROR`と同じような概念です。

—

よくある落とし穴とトラブルシューティング

最後に、`FIXED DECIMAL`を使う上で遭遇しやすいトラブルとその対処法について、現場の知見を交えながらお話ししましょう。

1. 桁あふれ (SIZE condition)

先ほどのコード例でも触れましたが、`FIXED DECIMAL`で定義した桁数を超える値が代入されたり、計算結果が桁あふれを起こしたりすると、`SIZE`コンディションが発生します。

症状: プログラムが異常終了したり、意図しない値（切り詰められた値）が格納されたりします。
原因: 変数の宣言時の`p`（総桁数）が不足している。特に、掛け算では結果の桁数が大幅に増えることがあるため、注意が必要です。
対策:
計算結果を格納する変数は、十分に大きな桁数で定義する。
`ON SIZE`ステートメントを使って、桁あふれが発生した際にエラーメッセージを出力したり、適切なリカバリ処理を行ったりする。本番システムでは必須の対応です。

2. 符号が化ける？データ連携時の落とし穴

メインフレームでは、PL/IだけでなくCOBOL、アセンブラ、さらには他のシステムとの間でデータをやり取りすることが頻繁にあります。

症状: ファイルやDBから読み込んだパック10進数の値が、PL/Iで表示すると全く違う数値になったり、エラーになったりする。
原因:
符号表現の違い: COBOLでは正の符号として`X’F’`も許容されますが、PL/Iでは`X’C’`が標準的です。古いデータや他のシステムからのデータには`X’F’`符号が多く、これが原因でPL/I側で不正なデータと見なされることがあります。
不正なニブル: 数字以外のニブル（`X’A’`, `X’B’`, `X’E’`, `X’F’`以外の符号ニブル）がデータ中に混入している場合。これはデータ入力ミスや、古いプログラムのバグで発生することがあります。
対策:
データ連携を行う際は、相手のシステムのパック10進数の符号表現を必ず確認する。
不正なニブルが含まれていないか、データチェックルーチンを挟むなどの防御的なプログラミングを心がける。特に外部からの入力ファイルは要注意です。
PL/Iでは`VERIFY`や`TRANSLATE`関数を使って、不正な文字をチェック・変換するテクニックもあります。

3. パフォーマンス問題

大量の`FIXED DECIMAL`演算が集中する処理では、前述のオーバーヘッドが積み重なり、処理時間が長くなることがあります。

症状: 特定のバッチ処理が想定以上に時間がかかる、CPU使用率が高い。
原因: 計算処理の大部分が`FIXED DECIMAL`の演算で占められている。
対策:
精度がそこまで厳密に求められない一時的な計算や、中間結果を格納する変数には、`BINARY FIXED`（2進数固定小数点数）など、CPUが直接処理しやすいデータ型を検討する。
計算ロジック自体を見直し、不要な`DECIMAL`演算を減らす。
（最終手段ですが）アセンブラなど、より低レベルな言語で処理を記述してパフォーマンスを向上させることもありますが、これはメンテナンス性とのトレードオフになります。

—

まとめ：FIXED DECIMALは怖くない！

今回はPL/Iの`FIXED DECIMAL(p,q)`、つまりパック10進数形式について、その内部構造から演算時の特性、そして現場で役立つトラブルシューティングまで、幅広く解説しました。

`FIXED DECIMAL`は、COBOLの`COMP-3`と同じパック10進数形式。
1バイトを2つのニブルに分け、各ニブルが10進数1桁を表す。
一番右端のニブルの後半が符号（`X’C’`で正、`X’D’`で負）。
精度が保証される反面、CPU内部での変換処理によりオーバーヘッドが発生することがある。
桁あふれやデータ連携時の符号の違いなど、特有のトラブルシューティングポイントがある。

メインフレームの世界は、一見すると「レガシー」や「複雑」というイメージが先行しがちですが、その一つ一つの仕様には、長年の実務で培われた深い知見と、システムの安定稼働を支える堅牢な思想が詰まっています。

今日ご紹介した`FIXED DECIMAL`も、金融システムをはじめとする基幹業務の「正確さ」を支える重要なデータ型なんです。その内部構造を理解すれば、プログラムの挙動や、なぜトラブルが起きるのかがクリアに見えてきますよね。

「怖くないですよ、一つずつ紐解けば簡単です！」この言葉を胸に、これからもPL/Iとメインフレームの世界を楽しんでいきましょう！何か困ったことがあれば、いつでも私に聞いてくださいね。