メインフレームの残滓とJavaの理想：PL/I構造体の「完全再現」という幻想を破壊する
長年、z/OSの冷たい空調の中でIBMメインフレームと対峙してきた諸君なら、一度は「PL/Iの構造体をそのままJavaのPOJOに写せばいい」という安易な設計方針が、地獄の扉を開くトリガーになることを経験したことがあるはずだ。
PL/Iのレベル構造体は、単なる階層データではない。それはコンパイラが計算した「オフセット」の地獄であり、アライメントの美学である。今回は、PL/IからJavaへのマイグレーションにおいて、メモリレイアウトの再現性がなぜこれほどまでに困難であり、かつ重要なのか、その深淵に迫る。
—
1. 構造体の「メモリレイアウト」という呪縛
PL/Iの構造体は、宣言順序とアライメントのルールによって、メモリ上の配置が決定される。特に`ALIGNED`と`UNALIGNED`の混在は、移行における最大の落とし穴だ。
/i
/ レベル構造体の典型例 /
DECLARE 1 RECORD_STRUC,
2 FIELD_A FIXED BIN(31), / 4バイト /
2 FIELD_B CHAR(3), / 3バイト /
2 FIELD_C FIXED DEC(7,2); / パックデシマル(4バイト) /
この構造体をJavaの`class`にマッピングする際、単にフィールドを並べるだけでは不十分だ。PL/Iコンパイラは、`FIXED BIN`を境界調整するために暗黙のパディング（隙間）を挿入することがある。Java側でこれを再現するには、`ByteBuffer`を用いたバイナリ操作か、あるいはJNI経由での構造体アクセスが必要になるが、現代のJavaの標準的なオブジェクト配置では到底及ばない。
もし君がマイグレーションのリードなら、「クラスのフィールド配置とメモリ上のオフセットを一致させる」ことに固執してはならない。 代わりに、バイナリ転送用のDTO層を設け、そこからビジネスロジック用のドメインオブジェクトへ変換する「二段構え」の設計を強く推奨する。
—
2. パックデシマル（COMP-3）の亡霊を飼いならす
PL/IからJavaへ移行する際、最も「アベンド（ABEND）」を誘発するのは、`FIXED DEC(N,P)`すなわちパックデシマルの符号ビットの解釈だ。
PL/Iの内部表現において、最後のニブル（4ビット）は符号を表す。`0xC`は正、`0xD`は負、`0xF`は符号なし（unsigned）として扱われることが多い。Javaの`BigDecimal`への変換時、この符号反転を考慮しないコードを書くと、テスト環境ではパスしても、本番データの負数で突然の数値計算不一致が発生する。
現場での教訓:
- ダンプ解析の常識: ABEND S0C7が発生した際、ダンプリストの16進数ダンプを直視せよ。`0C`や`0D`という値が見えたら、それはパックデシマルの符号だ。
- Java側の実装: `BigDecimal`に変換する前に、必ず符号ビットの正規化を行うユーティリティクラスを噛ませるべきだ。これをサボると、保守フェーズで地獄を見る。
—
3. ポインタと動的メモリ操作の闇
PL/Iの`BASED`変数と`ADDR`関数を用いた動的メモリ操作は、C言語のポインタとは異なり、コンパイラによる境界チェックが厳格に働く。これをJavaの参照渡しにそのまま変換しようとすると、メモリの断片化や参照の生存期間（GC）の違いで詰む。
特に、CICSオンライン処理で`GETMAIN`によって確保されたストレージを、複数のモジュール間で受け渡すようなコードは、Javaのスタック/ヒープ構造とは根本的に相性が悪い。
// Javaにおけるメモリマッピングの回避策（イメージ）
public class DataBufferConverter {
public void mapToLegacy(ByteBuffer buffer, MyDataModel model) {
// オフセットを明示的に指定して配置する。
// パディングを考慮し、スキップ量をハードコードではなく定数で管理する。
buffer.putInt(model.fieldA);
buffer.put(model.fieldB.getBytes(StandardCharsets.EBCDIC));
// パックデシマルの符号処理はここで行う
buffer.put(packDecimal(model.fieldC));
}
}
—
4. 最後に：スペシャリストとしての視点
マイグレーションは「機能のコピー」ではない。「アーキテクチャの翻訳」である。
PL/Iの構造体が持つ「密なメモリ配置」は、メインフレームの限られたメモリリソースを最大限に活用するための先人たちの知恵だった。Javaという、ヒープを潤沢に使いガベージコレクションに依存する言語に移行する以上、その「密」を維持しようと足掻くのは賢明ではない。
もし、基幹システムの移行プロジェクトを率いているのであれば、以下の3点を常にチームに問いかけてほしい。
1. 「このデータ構造は、Java側のメモリ管理と共存できるか？」
2. 「パックデシマルの符号変換において、エッジケース（負のゼロや無効な符号）をテストケースに入れているか？」
3. 「埋め込みSQL（DB2）のホスト変数をマッピングする際、型変換のオーバーヘッドを計算に入れているか？」
PL/Iのコンパイラ挙動を熟知している諸君なら、Javaの「柔軟さ」の中に、メインフレームが持つ「堅牢さ」をどう組み込むべきか、その答えが見えているはずだ。コードの行数を減らすことよりも、ダンプを読まなくて済むような「解釈の余地がないコード」を書くこと。それこそが、真のシステムアーキテクトの仕事である。
