メインフレームの「心臓」をJavaへ！PL/Iのデータ型とJava移行の落とし穴を攻略しよう
こんにちは。長年、IBMメインフレームの暗い機械室でコンパイラと格闘してきたシステムアーキテクトです。
最近、基幹システムのモダナイゼーション案件で「PL/IからJavaへのリプレイス」を相談されることが増えました。PL/Iは、1960年代に生まれた非常に多機能で強力な言語ですが、現代のJavaエンジニアから見ると「えっ、何この宣言？」と戸惑うような独特のクセがありますよね。
今回は、PL/IからJavaへ移行する際に多くのプロジェクトが泣きを見る「FIXED DECIMALの魔力」と「文字コードの迷宮」について、現場の視点から紐解いていきましょう。
—
そもそもPL/Iの「基本構造」ってどうなってるの？
PL/Iのプログラムは、いわば「箱の中に箱を入れる」ような構造をしています。Javaのクラス構造に近いですが、もっと柔軟で、ある意味で大雑把です。
1
/ プログラムの入り口はPACKAGEやPROCEDUREで定義されます /
MAIN_PROG: PACKAGE;
/ OPTIONS(MAIN)は、ここがプログラムの開始点だよ！という目印です /
MY_PROCESS: PROCEDURE OPTIONS(MAIN);
/ ここにメインのロジックを書きます /
PUT SKIP LIST (‘Hello, Modernization!’);
END MY_PROCESS;
END MAIN_PROG;
PL/Iが面白いのは、`PACKAGE`の中に複数の`PROCEDURE`を詰め込めるところです。Javaで言うところの「一つのファイルに複数のクラスやメソッドが同居している」状態に近いですが、スコープ（変数の有効範囲）の管理がPL/Iは非常に強力かつ複雑です。
—
1. FIXED DECIMALとJavaの`BigDecimal`：精度の戦い
PL/Iを触っていて最も遭遇するのが、`DCL (宣言)`でのこの記述です。
1
/ 10桁の数字で、小数点以下2桁。合計10桁という定義 /
DCL AMOUNT FIXED DECIMAL(10, 2);
これはCOBOLの`PIC S9(8)V99`と同じ概念です。Java初心者がこれを`double`や`float`に変換すると、間違いなく痛い目を見ます。
なぜ`double`ではダメなのか？
浮動小数点型である`double`は、内部的に2進数で数値を保持します。そのため、0.1のような「10進数では綺麗でも2進数では無限小数になる数」を扱うと、わずかな誤差（丸め誤差）が発生します。銀行のシステムで1円でも残高がズレたら大変ですよね。
Javaへの移行の正解
必ずJavaの `java.math.BigDecimal` を使いましょう。ただし、PL/I側の精度（Precision）と位取り（Scale）を厳密に継承する必要があります。
// PL/Iの FIXED DECIMAL(10, 2) のイメージ
BigDecimal amount = new BigDecimal(“12345678.90”);
// 計算時は必ずスケールと丸めモードを指定する
amount = amount.setScale(2, RoundingMode.HALF_UP);
「面倒くさいな」と思うかもしれませんが、この「面倒くささ」こそが基幹システムの信頼性を守る最後の砦なんです。
—
2. EBCDICからUnicodeへの「文字コードの罠」
メインフレームの世界では、長らくEBCDIC（エビディック）というIBM独自の文字コードが使われてきました。これを現代のUTF-8（Unicode）へ変換する際、単に「文字をコピー」するだけでは不十分なケースが多々あります。
罠1：ソート順の違い
EBCDICとASCII/Unicodeでは、文字の「並び順（コードポイント）」が全く違います。
- EBCDIC: A～I, J～R, S～Z の順
- Unicode: アルファベット順
もし、プログラム内で「文字の大小比較」をしているロジックがあったら、Java移行後に並び順が変わってバグになる可能性があります。
罠2：日本語の扱い（シフトコード）
日本のメインフレームでは、半角カタカナや漢字を扱うために「シフトコード（SO/SI）」という制御文字を文字の前後に入れます。Javaの`String`クラスはこれらを「ただの文字」として扱おうとするため、不要な制御文字が混入して画面が崩れたり、DB検索でヒットしなかったりします。
解決のヒント：
Javaへ移行する際は、単に変換するのではなく、必ず「文字コード変換後のバリデーション」を行いましょう。特に、メインフレーム特有の「空白（Space）」の定義（EBCDICの`X’40’`）とUnicodeのスペースの違いには要注意です。
—
最後に：怖がらなくて大丈夫です
PL/IからJavaへの移行は、単なるプログラミング言語の置き換えではありません。「メインフレームが数十年かけて守ってきたデータの整合性」を、Javaの作法で再定義する作業です。
最初は難しく感じるかもしれませんが、PL/Iの宣言を一つずつ「この変数は、メモリ上でどう表現されているか？」と追いかけていくと、Javaの型システムがより深く理解できるようになります。
もしコードを読んでいて「これ、どういう意味？」と迷ったら、いつでも聞いてくださいね。現場のアーキテクトとして、皆さんのモダンな開発を全力でサポートします！
それでは、今日も堅牢なコードを書いていきましょう。
