【入門編】JavaマイグレーションにおけるBigDecimalへの変換 – PL/Iの基本構文とデータ制御実践ガイド

こんにちは！メインフレームの底知れぬパワーと、そこに眠るPL/Iというちょっぴり古風で奥深い言語の世界へようこそ。

JavaやCOBOLの経験はあるけれど、「なんだこのPL/Iっていう呪文みたいなコードは……？」と戸惑っていませんか？大丈夫です。怖がる必要は全くありません。今日は、基幹システムの移行現場で誰もが一度は頭を抱える「FIXED DECIMAL（固定小数点数）」からJavaの「BigDecimal」への変換について、現場の知見をたっぷり交えながら、優しく紐解いていきますね。

—

そもそも `FIXED DECIMAL` ってなに？（怖くないデータ型の話）

Javaの世界では、正確な金額計算には `BigDecimal` を使いますよね。浮動小数点数（`double` や `float`）を使うと、10進数の「0.1」が正確に表せなくて「あれ、1円足りない？！」なんて大惨事になることを、皆さんはご存知のはずです。

PL/Iの `FIXED DECIMAL`（略して `FIXED DEC`）も、まさに「お金や厳密な数値を絶対に狂わせたくない！」という強い意志から生まれた10進数型のデータです。

奇妙なデータ宣言の裏側を覗いてみよう

PL/Iのコードを見ると、こんな宣言によく出会います。

1
DCL
WK-AMT-TOTAL FIXED DEC(9, 2) VALUE(0),
WK-TAX-RATE FIXED DEC(3, 3) VALUE(0);

なんだか数学の座標みたいな `(9, 2)` や `(3, 3)` がついていて怯みますよね。でも、これはすごくシンプルなルールでできています。

第一引数（全体の桁数・精度）： 符号を含まない、その数字が表現できる全体の最大桁数です。
第二引数（小数点以下の桁数・スケール）： そのうち、小数点より下が何桁あるかを示します。

先ほどの例で見てみましょう。

`FIXED DEC(9, 2)` は、「全体で9桁、そのうち小数点以下が2桁」という意味です。つまり、整数部分は 9 – 2 = 7桁入ります。最大で `9999999.99` まで扱える、お小遣い帳から会社の売上管理まで安心のサイズ感ですね。
`FIXED DEC(3, 3)` は、「全体で3桁、ぜーんぶ小数点以下」です。つまり `0.999` などの率（レート）を表すときに使います。

—

なぜJavaマイグレーションでハマるのか？

Javaに移行する際、この `FIXED DEC(p, q)` をそのまま `java.math.BigDecimal` にマッピングすることになります。

// こんな風に変換したくなりますよね
BigDecimal wkAmtTotal = new BigDecimal(“0.00”);

ここで、Javaエンジニアの皆さんが盛大にハマるポイントが2つあります。「スケール（小数点以下の桁数）の維持」 と 「丸めモード（端数処理）」 です。

ハマりポイント1：スケールが勝手に変わっちゃう？

Javaの `BigDecimal` は、演算をするとスケールが勝手に変わることがあります。例えば、`10.00` と `2` を掛け算すると、Javaは気を利かせて計算結果のスケールを変えてしまうことがあります。

しかし、PL/Iの世界では、「変数の宣言通りの桁数と小数点位置を絶対に死守する」という厳格なルールがあります。もしPL/I側で `FIXED DEC(9, 2)` と定義されているなら、Java側でも常に小数点以下2桁（スケール＝2）を維持してあげないと、後続のプログラムやDB登録で「桁あふれ」や「フォーマット不正」の怒りのエラーを食らうことになります。

ハマりポイント2：四捨五入の「お作法」

メインフレームの算術演算とJavaのデフォルトの丸めモードでは、端数の処理方法（四捨五入、切り捨て、切り上げなど）のデフォルト挙動が異なる場合があります。
金融系システムで「1円のズレ」は許されない大問題。「あれ、PL/Iで動かしてた時と、Javaに移行したら最後の1円の端数が違うぞ……？」なんてことにならないよう、丸めモードは必ず明示的に指定する必要があります。

—

現場で使える！PL/IからJava（BigDecimal）への安全な変換レシピ

それでは、実務のバッチ改修や移行設計でそのまま使える、具体的なアプローチを見ていきましょう。

1. 宣言の読み解き方早見表

2. Java側での安全なスケールと丸め設定のコード例

PL/Iの厳格な振る舞いをJavaで再現し、安全に数値を扱うためのスニペットです。移行先のJavaバッチ基盤などで共通部品としてよく使われるパターンを再現しました。

import java.math.BigDecimal;
import java.math.RoundingMode;

public class Pl1ToBigDecimalConverter {

PL/Iの FIXED DEC(9, 2) 相当の制約をJavaで安全にエミュレートするメソッド
@.PL/I定義: DCL IN-PRICE FIXED DEC(9, 2);

/
public static BigDecimal convertAndAdjustAmount(BigDecimal rawValue) {
if (rawValue == null) {
return BigDecimal.ZERO.setScale(2, RoundingMode.UNNECESSARY);
}

// 1. PL/Iの定義に合わせて小数点以下2桁（スケール2）に丸める
// ※メインフレームのデフォルト挙動や業務仕様に合わせて RoundingMode は適切に選択してください
// ここでは一般的によく使われる「四捨五入 (HALF_UP)」を指定しています。
BigDecimal adjusted = rawValue.setScale(2, RoundingMode.HALF_UP);

// 2. 整数部が許容桁数（全体9桁 – スケール2 = 7桁、つまり最大 9999999.99）に収まっているかチェック
// 超過している場合は、メインフレーム同様にOverflow例外をスローして異常終了させます
if (adjusted.precision() – adjusted.scale() > 7) {
throw new ArithmeticException(“Numeric overflow: 許容される整数桁数を超えています。”);
}

return adjusted;
}
}

—

まとめ：レガシーの数字は怖くない！

ここまで見てきたように、PL/Iの `FIXED DECIMAL` も、Javaの `BigDecimal` も、根っこにある思想は同じです。「数値を正確に、狂いなく扱いたい」というエンジニアの切なる願いの表れです。

宣言されている `(全体桁数, 小数点以下桁数)` をしっかり確認する。
Java側でも `setScale()` と `RoundingMode` を使って、その精度をガチガチに守る。

この2点さえ押さえておけば、メインフレームからのJavaマイグレーションはもう怖くありません。「なんだ、COBOLやJavaと考え方は一緒じゃないか」と気づけるはずです。

移行プロジェクトの現場は時に泥臭く、予期せぬデータに悩まされることもありますが、一つひとつ紐解いていけば必ず道は開けます。あなたのマイグレーションの旅がスムーズに進むよう、心から応援しています！