PL/IからJavaへ：メモリ管理の「決定論」と「非決定論」の狭間で
メインフレームの心臓部で鼓動を刻むPL/I。この言語の美しさは、ハードウェアを直接的に叩く「制御の緻密さ」にあります。しかし、いま多くの現場で進められているPL/IからJavaへのマイグレーションは、単なる言語の置き換えではありません。それは「メモリを支配する」という特権を手放し、ガベージコレクション（GC）という「緩やかな不確実性」に身を委ねる、アーキテクチャ上のパラダイムシフトなのです。
今回は、PL/Iの動的メモリ操作とポインタの世界を、Javaへいかに「安全に」翻訳するか。その深淵に触れていきます。
—
1. ポインタとベース変数の「死」をどう設計するか
PL/Iにおいて、`BASED`変数はメモリ管理の要です。`ALLOCATE`で領域を確保し、`POINTER`でその先頭アドレスを操作する。この明示的なメモリ管理は、効率的であると同時に、アベンド（ABEND：S0C4など）の温床でもありました。
PL/Iにおける動的確保の典型例
/i
/ データ構造の定義 /
DCL 1 MY_RECORD BASED(P_RECORD),
2 FIELD_A CHAR(10),
2 FIELD_B FIXED BIN(31);
DCL P_RECORD POINTER;
/ 明示的な領域確保 /
ALLOCATE MY_RECORD;
/ ポインタを操作して値をセット /
P_RECORD->FIELD_A = ‘TEST’;
Javaへ移行する際、この`BASED`構造体は「クラス」と「参照」へ変換されますが、ここで最大の罠が待っています。PL/Iではメモリが物理的に連続していることが保証されていましたが、Javaのオブジェクトはヒープ上に散らばります。
アーキテクトの知見：
ポインタを模倣するために `java.nio.ByteBuffer` を使用する手もありますが、それは「GCの恩恵を捨てる」ことと同義です。素直にPOJO（Plain Old Java Object）へ分解し、メモリ管理をJVMに委ねるべきです。ただし、CICS等のオンライン処理でメモリ断片化を恐れて頻繁な`FREE`を行っていたようなケースでは、Java側でオブジェクトのライフサイクルを制御しないと、GCが頻発し、レスポンスが劇的に劣化する（STW：Stop-The-Worldの増加）という「レガシーの亡霊」に取り憑かれます。
—
2. パックデシマル（COMP-3）の罠：符号反転の教訓
PL/IからJavaへの移行で、最も多くの現場で涙を流すのが、`FIXED DEC(N, M)`（パックデシマル）の処理です。メインフレームでは、パックデシマルの末尾ニブル（4ビット）が符号（Cは正、Dは負）を表します。
Javaの`BigDecimal`は便利ですが、バイナリデータとしてやり取りする際の「内部符号」の扱いは自前でハンドリングしなければなりません。
// アーキテクトの視点：パックデシマル変換の注意点
// PL/Iの内部符号(0x0C, 0x0D)を正しく評価しないと、
// マイグレーション直後に「金額がマイナスになる」「数値が化ける」バグが頻発する
public BigDecimal convertComp3(byte[] rawData) {
// 実際の実務では、末尾バイトの符号判定を丁寧に行う必要がある
// ここを適当に済ませると、バッチ処理の突合で致命的な不一致を生む
}
特にDB2の埋め込みSQLで取得した値をJavaのDTOにマッピングする際、PL/Iのコンパイラが暗黙的に行っていた「自動変換」が消滅します。この「コンパイラが隠していた詳細」を、Java側で明示的に定義することが、信頼性を担保する唯一の道です。
—
3. アベンド解析の勘所：ダンプが語る「真実」
かつて我々は、`SYSUDUMP`や`CEEDUMP`を読み解くことで、プログラムの死因を特定してきました。ポインタがNULLを指しているのか、境界外アクセス（S0C4）なのか。
Javaに移行すると、スタックトレースという強力な武器が手に入ります。しかし、基幹システムでは「なぜその変数がその値になったのか」という追跡の難易度が上がります。PL/I時代には、ストレージダンプを見れば「その瞬間のメモリ状態」が全て公開されていましたが、Javaではオブジェクトの動的な状態を追いかけるために、高度なロギング設計や、場合によってはAPM（Application Performance Management）ツールの導入が不可欠です。
現場の教訓：
「PL/Iならダンプを見れば一発だったのに」という声はよく聞きます。しかし、Java移行は「デバッグの難易度を上げる」のではなく、「開発の抽象度を上げる」行為です。アベンドを解析するのではなく、例外を設計するフェーズへシフトしてください。
—
結びに：レガシーの魂をコードに残す
PL/Iのコードには、何十年もの業務ロジックと、ハードウェアをねじ伏せてきた先人の知恵が詰まっています。Javaへの移行は、その「魂」を新しい言語という容れ物に移し替える儀式です。
メモリ管理の自動化は、我々の自由を奪うものではなく、ビジネスロジックの純粋な表現を可能にするためのステップです。ポインタ操作の快感は忘れても構いません。しかし、メインフレームエンジニアが培った「リソースに対する執着」と「データの整合性に対する厳格さ」だけは、Javaのコードにも色濃く残してください。
それが、我々メインフレーム・アーキテクトが次世代のシステムに遺せる、最大のレガシーなのです。
