文字コードとCOMP-3の地獄 — EBCDIC・JEF・パック10進をAWSでどう扱うか

ホスト移行で「動いた、でもデータがおかしい」の震源地は、たいてい文字コードと数値表現です。EBCDIC、富士通のJEF、パック10進（COMP-3）——メインフレームの物理表現は、そのままではAWS上のJavaやRDBMSと相容れません。ここは自動変換ツールが最も苦戦し、人の知識が要る領域です。

01EBCDIC→UTF-8 — 単なるコード変換では済まない

EBCDICからUTF-8への変換は、1バイトの読み替えに見えて、いくつも罠があります。まず前提として、変換テーブルが正しくても、照合順序が変わるため後続のソートやキー比較に影響します（現新比較で詳述）。加えて、EBCDICには複数のコードページがあり、どの版で作られたデータかを取り違えると、記号（円記号・シャープ・角括弧など）が化けます。

02富士通JEFの二重系 — シフトコードという時限爆弾

富士通GS系のJEFは、日本語（2バイト）と英数カナ（1バイト）を混在させるためにシフトコード（シフトイン／シフトアウト）でモードを切り替える方式を使います。COBOLの項目定義とデータ中のシフトコードが噛み合っていないと、変換後に日本語と英数の境界がずれて盛大に化けます。

• シフトコードの有無・位置を正しく解釈できる変換であること
• 1バイト系と2バイト系が混在する項目（NAME項目など）のレイアウト解釈
• 固定長レコードでシフトコードが桁を消費している場合の桁数計算

03外字（がいじ）の欠落

長年運用された基幹系には、人名・地名のためにユーザー定義文字（外字）が登録されています。メインフレームの外字領域と、移行先Unicodeの対応は自明ではなく、マッピングを用意しないと外字は「・」や空白に化けて消えます。人名の1文字が消えることの業務的重大性は、金融・自治体系では説明不要でしょう。外字の棚卸しとマッピング表の作成は、文字コード移行の独立タスクとして計画に載せてください。

04COMP-3（パック10進）— 符号ニブルという伏兵

数値表現の主役、パック10進（COMP-3）。1バイトに2桁を詰め、最後の4ビット（ニブル）に符号を持ちます。符号ニブルはC（優先的な正）・D（優先的な負）・F（符号なし＝正）が基本ですが、仕様上は A・C・E・F が正、B・D が負として有効で、現場のデータには C/D 以外のこれら代替符号コードが紛れていることがあり、扱いを取り違えると符号や値がずれます（特に B を無効値扱いすると負データの符号を落とします）。

• ゾーン10進（表示用数字）との往復での符号の持ち方（SIGN LEADING/TRAILING、SEPARATE有無）
• COMP（バイナリ）とCOMP-3の混同、桁あふれ
• 変換先（JavaのBigDecimal等）での精度・丸めの一致（1円ズレの話）

05REDEFINESとバイナリ項目の相性の悪さ

COMP-3やCOMPのバイナリ項目にREDEFINESを重ね、同じ領域を数値としても文字としても解釈するようなコードは、メインフレームの物理表現に密着しているため、変換で最も壊れやすい部分です。「このバイト列を、ある時は金額、ある時は制御情報として読む」ような技巧は、Java/RDBMSの世界に素直には落ちません。REDEFINESとバイナリの組み合わせは、変換後に個別検証が要る要注意箇所として洗い出しておいてください。

—まとめ

文字コードと数値表現は、ホスト移行で自動化が最も効きにくく、日本固有（JEF・外字）と物理表現依存（COMP-3・REDEFINES）の知識が要る領域です。ここを「ツールがやってくれる」で片付けた移行は、現新比較で日本語と金額が合わずに立ち往生します。EBCDIC・JEFのコードページ確定、外字マッピング、COMP-3の符号検証——この地味な仕込みが、移行の成否を静かに決めます。COBOLerの方には釈迦に説法かもしれませんが、だからこそ計画に必ず織り込んでください。