メインフレームの「常識」がJavaの「非常識」になる瞬間
おい、ちょっといいか。今進めているオープン系移行プロジェクト、Javaへのリプレイスでまたあの「文字化けとパディングの呪い」にハマりかけているチームがあるようだな。
PL/IからJavaへのマイグレーションにおいて、最も多くのエンジニアが泥沼にハマるポイントはどこだと思う？最新のフレームワークの使い方か？いや、違う。もっと足元、「文字列データ型とメモリ上のバイナリ表現のギャップ」だ。
特に、PL/Iが誇る強力かつ厄介なデータ型である固定長文字列（CHARACTER(n)）を、Javaの`String`や`byte[]`にどうマッピングするか。ここを甘く見ていると、本番稼働した瞬間にバッチ処理が全滅するか、VSAMファイルのキー不一致で夜間運用が崩壊する。
今日は、ベテランの私が、メインフレームの鉄の掟とJavaの現実がどこで衝突し、どうやってそれを美しく調停すべきか、実務に直結するノウハウを叩き込んでやろう。
—
1. PL/I固定長文字列（CHARACTER）の冷酷な現実
まずは敵を知ることから始めよう。PL/Iの `CHAR(n)` は、Javaの `String` とは根本的に生き様が違う。
PL/Iで以下のように定義された変数を想像してくれ。
1
DCL WK-EMP-NAME CHAR(10) INIT(‘TANAKA’);
メインフレームのメモリ上（あるいはVSAMのレコード上）、この `WK-EMP-NAME` がどう格納されているか知っているか？
答えはこうだ：`’TANAKA ‘`（後ろに半角スペースが4つ強制パディングされる）。
PL/Iの固定長文字列は、宣言された長さに満たない場合、自動的に右側に空白（EBCDICコードの `X’40’`）がパディングされる。しかも、PL/Iの文字列操作（SUBSTRや比較演算）は、この末尾ブランクをよしなに考慮して動いてくれる。
さらに恐ろしいのは、PL/Iには「Javaの `String` のような不変（イミュータブル）オブジェクトの概念」はなく、純粋な連続したメモリ領域へのマッピングである点だ。これらをレコード入出力（READ/WRITE）やVSAMアクセスでそのままJava側に引き渡そうとすると、途端に辻褄が合わなくなる。
—
2. 実践コード：PL/I側でのパディング制御とBUILTIN関数
まずは、現場で私たちが日々書いている、文字列とパディングを厳密に制御するPL/Iのコード例を見てみよう。大文字記述、適切なインデント、そして組み込み関数（BUILTIN）を駆使した実戦的なスタイルだ。
1
/————————————————-/
/ 顧客マスタレコード構築およびパディング制御サブルーチン /
/————————————————-/
CUST_REC_PROC: PROC OPTIONS(MAIN);
Dcl 1 IN-REC,
5 EMP_ID Char(5), / 社員ID /
5 EMP_NAME Char(20), / 社員名（固定長） /
5 DEPT_CODE Char(3); / 部署コード /
Dcl OUT_BUFFER Char(100); / 出力用バッファ /
Dcl WORK_NAME Char(20);
/ 1. データの初期化と右側ブランク埋めの確認 /
EMP_ID = ‘A1234’; / 満たない分は自動パディング /
WORK_NAME = ‘YAMADA TARO’;
/ TRIM系組み込み関数で前後処理を明確化 /
/ 冗長なスペースを除去して再格納（厳密な制御） /
EMP_NAME = TRIM(WORK_NAME);
DEPT_CODE = ‘999’;
/ 2. レコード全体の結合（PL/Iでは暗黙の連結が行われる） /
OUT_BUFFER = EMP_ID || EMP_NAME || DEPT_CODE;
/ 3. 組み込み関数を用いた長さの検証 /
/ LENGTHは「宣言上の長さ」、CURRENTSIZEやHLEEN系に注意 /
DISPLAY(‘EMP_NAMEの長さ（宣言）: ‘ || LENGTH(EMP_NAME));
DISPLAY(‘有効文字数（TRAILING処理）: ‘ || LENGTH(TRIM(EMP_NAME, TRAILING)));
/ 4. VSAM/ファイル出力想定のダンプ確認 /
DISPLAY(‘OUT_BUFFER (HEX): ‘ || HEX(OUT_BUFFER));
END CUST_REC_PROC;
このコードのポイントは、`TRIM` や `HEX` といったBUILTIN関数を使い、メモリ上の実体がどうなっているかを常に意識している点だ。メインフレームエンジニアなら、`HEX` で `40` が並んでいるのを見ただけで飯が食えるはずだ。
—
3. Javaリプレイスにおける「パディングとエンコーディング」の罠
さて、これをJavaに移行する際、何が起きるか。ここからが本番だ。
罠その1：Javaの `String` は自動トリムしてくれない
Javaにこのレコードを `byte[]` として読み込み、そのまま `new String(bytes, “Cp1035” 等)` でStringに変換すると、末尾の空白（`’ ‘`）がそのまま文字列の一部として残る。
データベース（PostgreSQLやOracleなど）にそのまま突っ込むと、`”YAMADA TARO”` のつもりが `”YAMADA TARO “` になり、完全一致検索でヒットしないという、移行期によくある「笑えないバグ」が完成する。
罠その2：EBCDIC（CP930等）とUTF-8の文字コード差異
メインフレームはEBCDIC、オープン系Javaは基本UTF-8またはSJIS（Cp932等）だ。
単なるバイト列の切り出しにおいて、漢字（全角文字）が含まれる場合、EBCDICのシフトアウト（SO）・シフトイン（SI）制御文字を考慮せずにJava側で `substring` をやると、文字化けどころか例外（`IndexOutOfBoundsException`）の嵐になる。
—
4. 解決策：Java側での正しいマッピングと設計指針
この課題をクリアするため、移行プロジェクトのアーキテクトとして、チームに以下のコーディング規約を徹底させなさい。
1. Java側では「ドメインモデル」でパディングを剥ぎ取る
Javaのエンティティクラス（DTO）にマッピングする際、セッターまたは専用のパーサークラスで必ず `String#stripTrailing()`（Java 11以降）を適用し、PL/I特有の右側パディングを除去する。
2. 固定長バイナリの保持には `byte[]` を活用する
ファイルレイアウトやVSAMのキー構造体をそのまま維持する必要があるバッチの中間層では、`String` に即変換せず、`byte[]` のままオフセットを指定して切り出すユーティリティ（Apache Commons Langや独自バイト操作クラス）を使う。
3. 文字コード変換（Charset）の明示
IBM製メインフレームから吐き出されたデータであれば、文字コードはIBM漢字ホストコード（Cp930など）だ。Java側で読み込む際は、必ず `Charset.forName(“IBM-930”)`（またはベンダー提供のEBCDICコンバータ）を明示すること。システムデフォルトに頼るな。
—
ONユニットと例外制御の教訓をJavaへ
最後に、PL/Iの堅牢なエラーハンドリング（ONユニット）の精神を忘れてはいけない。PL/Iではデータ変換エラー（CONVERSIONなど）が発生した際、ONユニットでトラップして安全にデフォルト値を設定できた。
Javaに移行しても、パディングや文字コード変換で予期せぬバイト列に遭遇したときは、単に `RuntimeException` でバッチを異常終了させるのではなく、「どのレコードの何バイト目でパディング異常やコード変換エラーが起きたか」をログに詳細に出力するカスタム例外ハンドラを必ず挟むこと。
メインフレームの厳格なデータ制御の思想を理解した上でJavaに挑めば、恐れるものなど何もない。さあ、手を動かしてコードの隅々まで見直してこい！
