現新比較で泣かないために — ホスト移行の等価性検証を設計する

ホスト移行の受け入れテストは、機能テストではなく現新比較（等価性検証）が主役です。旧（ゲン）と新（シン）を並走させ、出力が同じであることを証明する。ところが「正しく変換したはずなのに一致しない」が必ず起きます。その大半は不具合ではなく、プラットフォームが変わったことによる当然の差です。差の正体を知り、突合を設計しましょう。

01なぜ「一致しない」のか — 差は不具合とは限らない

完璧に変換できても出力が一致しないことがあります。理由は、メインフレームとAWS（Java等）で、文字の順序・数値の表現・端数の扱いが本質的に違うからです。これらを「不具合」として1件ずつ潰そうとすると、永遠に終わりません。「正当な差」と「本物の不具合」を最初に切り分ける設計が、現新比較の成否を分けます。

02罠① EBCDIC照合順序の逆転 — ソート結果が変わる

COBOLerが最初に唸るのがこれです。EBCDICとASCII/Unicodeでは文字コードの並び順が違います。EBCDICでは概ね「英小文字 → 英大文字 → 数字」の順ですが、ASCIIでは「数字 → 英大文字 → 英小文字」。つまり同じデータをソートしても、ゲンとシンで並び順が変わるのです。

英数字混在のキーでソートした帳票やファイルは、変換が正しくてもレコードの順序が食い違い、単純な行単位diffは全滅します。これは不具合ではなく、照合順序の仕様差です。

03罠② 数値・丸めの差 — 1円のズレは1円では済まない

COBOLの固定小数点演算と、移行先（JavaのBigDecimal等）の演算は、丸めや中間桁の扱いが完全一致するとは限りません。COBOLのROUNDED、切り捨て、COMPUTE文の中間結果の桁——これらの再現が甘いと、合計金額が1円ずれる。そして金額の1円は、監査上は「1円」では済まされません。

• パック10進（COMP-3）の符号ニブル（C/D/F）の扱い、ゾーン10進との往復
• 除算・利息計算・按分での丸め方向と丸め桁
• 中間結果の桁あふれ・切り捨てのタイミング

数値系は、変換ツール任せにせず、代表的な計算ロジックについてゲン・シンで意図的に境界値を通して一致を確認する専用テストを組むのが安全です。詳細はCOMP-3の記事で。

04罠③ 空白・LOW-VALUE・初期値・日付

• スペース vs LOW-VALUE（x00） — 未設定領域の表現が、EBCDICの空白とバイナリゼロで食い違い、diffに出る
• パディング — 固定長レコードの右詰め・左詰め・埋め文字の差
• 日付 — 2桁年・独自の日付表現・システム日付の取得タイミングがゲンとシンでずれると、日付項目が全件不一致に見える

05突合の設計 — 全件か、サンプルか

現新比較の設計判断は「どこまで突き合わせるか」です。

• 出力ファイル・帳票の全件突合 — 最も確実。ただし照合順序と正当な差の正規化を先に済ませること
• 項目単位の比較 — 行単位diffが照合順序で崩れる場合、キーで結合して項目ごとに比較する仕組みを用意すると、本物の差だけが浮く
• サンプル＋境界値 — 全件が非現実的な規模なら、代表データ＋境界値（最大桁、符号、ゼロ、月末、うるう年）を厚く

—まとめ

現新比較は、ホスト移行で最も工数を過小評価される工程です。EBCDIC照合順序の逆転、数値の丸め差、空白と日付——「正しく変換したのに一致しない」の大半は正当な差で、それを不具合と切り分ける設計こそが本体です。変換ツールの選定より、この突合基盤の設計に時間を割いてください。COBOLerの方なら、ここで挙げた罠はどれも「あった、それ」だと思います。だからこそ、最初から織り込んで計画してください。