「PL/Iの呪縛」を解く：Javaエンジニアのためのデータ型解体新書
こんにちは。メインフレームの世界へようこそ。
もしあなたが今、Javaなどのモダンな言語でバリバリ開発しているエンジニアなら、PL/I（ピーエル・アイ）という名前を聞いて「化石のような言語？」と少し身構えてしまうかもしれませんね。
でも、安心してください。PL/Iは非常に論理的で、かつ「至れり尽くせり」な言語です。今日は、Javaから見たときに最も「おや？」と首をかしげたくなる、PL/I特有のデータ型の正体と、そのJava移行における落とし穴について、現場の知見を交えて紐解いていきましょう。
—
1. PL/Iの「心臓部」：プログラム構造の基本
まずは基本の「キ」です。PL/Iのプログラムは、大きく分けて `PACKAGE` と `PROCEDURE` で構成されます。
/i
/ プログラムの入り口はPROCEDUREで定義し、OPTIONS(MAIN)でOSに「これが実行単位だ」と伝えます /
MY_PROGRAM: PROCEDURE OPTIONS(MAIN);
/ ここに処理を書いていきます /
PUT SKIP LIST(‘こんにちは、PL/Iの世界へ！’);
END MY_PROGRAM;
Javaの `public static void main` に相当するのが `OPTIONS(MAIN)` です。この指定がないと、OSはどこから処理を始めればいいか迷子になってしまいます。まずはこの形が「プログラムの顔」だと覚えておいてくださいね。
—
2. なぜPL/Iの数字は「クセ」が強いのか？
Javaで数値を扱うとき、皆さんは `int` や `double` を使いますよね。でも、PL/Iの世界には `FIXED DECIMAL` や `PICTURE` という、少し不思議な存在がいます。
FIXED DECIMAL（固定小数点）の正体
PL/Iの `DCL (DECLARE) VAR FIXED DECIMAL(5,2);` という宣言を見てみましょう。
これは「全体で5桁、そのうち小数部が2桁」という意味です。
Javaの `BigDecimal` に相当しますが、決定的な違いは「メモリ上の表現」です。PL/Iのこれらは、バイナリではなく、人間が読める「パック10進数」という形式でメモリに詰め込まれています。1バイトに2つの数字を押し込んでいるようなイメージですね。
PICTURE（ピクチャ）型の魔力
これが初心者泣かせの代表格です。
`DCL ACCOUNT_NO PIC ‘99999’;`
`DCL MONEY_VAL PIC ‘ZZZ,ZZ9.99’;`
これは単なる変数ではありません。「データの見た目（マスク）」を同時に定義しているのです。`Z` は「ゼロなら空白にする」という編集用文字です。つまり、PL/Iの変数は、値を持っているだけでなく、出力時にどう見えるかという「化粧」までを背負っているわけです。
—
3. Java移行時に発生する「精度と速度」のジレンマ
さて、ここからが本題です。PL/IからJavaへ移行する際、最もトラブルになりやすいのが、この「FIXED DECIMAL」の変換です。
課題1：精度の解釈
PL/Iの `FIXED DECIMAL` は、内部計算において「厳密な10進数演算」を行います。対してJavaの `double` や `float` で受けてしまうと、浮動小数点特有の「0.1 + 0.2 が 0.30000000000000004 になる」という現象が起き、金融計算では致命的なバグになります。
解決策：
Java側では必ず `java.math.BigDecimal` を使用してください。ただし、`BigDecimal` はオブジェクトであるため、大量の計算をループ内で回すと、PL/I時代には考えられなかった「GC（ガベージコレクション）によるパフォーマンス低下」に見舞われることがあります。
課題2：PICTURE型の「空白」問題
PL/Iの `PIC ‘ZZZ9’` をJavaに持っていくとき、単純な数値型にすると「空白をどう扱うか」で躓きます。
PL/Iでは「空白＝ゼロ」として自動的に変換してくれることが多いのですが、Javaでこれを再現するには、変換用のユーティリティクラスを自作し、厳格なバリデーションを挟むのが定石です。
—
4. 現場のアーキテクトからのアドバイス
PL/IのコードをJavaに書き換える際、最もやってはいけないのは「一対一の直訳」です。
1. データ構造を再定義する： PL/Iの「見た目（PIC）」と「値（FIXED）」が混ざった構造を、Javaでは「値（BigDecimal）」と「フォーマッタ（String）」に明確に分離しましょう。
2. パフォーマンスを恐れない： 現代のJVMは非常に強力です。まずは「正しさ」を最優先にし、ボトルネックが見つかってからプリミティブな型への最適化を検討する、という手順で進めるのが、失敗しないメインフレーム移行の鉄則です。
—
まとめ：怖がる必要はありません
PL/Iのデータ宣言は、一見すると呪文のように見えるかもしれません。しかし、それは「データがどうあるべきか」を非常に厳密に管理しようとした、当時の先人たちの知恵の結晶です。
「FIXED DECIMALはBigDecimalへ」「PICはフォーマッタクラスへ」。この原則さえ押さえれば、移行は決して恐ろしいものではありません。
もし現場で「この変数は何のためにあるんだ？」と迷ったら、いつでも教えてくださいね。その変数の向こう側にある、当時の業務ロジックの物語を一緒に読み解いていきましょう。
次回の記事では、メインフレームの「構造体（STRUCTURE）」とJavaの「POJO（DTO）」のマッピングについて深掘りしていこうと思います。それでは、また！
