EBCDICの深淵：PL/I `TRANSLATE`関数とレガシー移行における「見えない境界線」
IBMメインフレームの現場で何十年と生き抜いてきた諸君なら、一度は`TRANSLATE`関数の挙動に救われ、あるいはその巧妙な罠に翻弄された経験があるはずだ。
現代のJavaやC#のエンジニアが`String.replace`を呼ぶ感覚でこの関数を扱うと、必ず痛い目を見る。なぜなら、PL/Iの`TRANSLATE`は単なる文字列置換ではなく、EBCDICという巨大なコード体系そのものを操作する低レイヤーの「変換エンジン」だからだ。
1. TRANSLATE関数の真髄と変換テーブルの設計
`TRANSLATE`関数は、指定されたソース文字列を変換テーブルに基づいてバイト単位でマッピングする。構文は単純だが、その裏にあるのはコンパイラが生成するインラインの変換命令、あるいは最適化されたライブラリルーチンだ。
1
/ 変換テーブルの定義例: 小文字を大文字へ、かつ特定の制御文字をスペースへ /
DCL TRAN_TABLE CHAR(256) INIT((64) ‘ ‘, / 0x00-0x3Fをスペースに /
‘ABC…XYZ’, / 変換定義をここに記述 /
…);
DCL TARGET_DATA CHAR(80) VAR;
DCL RESULT_DATA CHAR(80) VAR;
/ 変換の実行 /
RESULT_DATA = TRANSLATE(TARGET_DATA, TRAN_TABLE, ‘00010203…’X);
ここで重要なのは、変換テーブルは必ず256バイトである必要はないという点だ。第3引数の「元の文字セット」を明示することで、変換対象を特定範囲に絞り込める。マイグレーション時に「なぜJava側で同様の変換をすると結果が異なるのか」と問われたら、まずは両環境のコードページ（CCSID）を確認すべきだ。EBCDICの特定コードポイントが、Unicode変換時にどう解釈されているか。ここが移行の最大の泥沼となる。
2. ポインタを用いた動的メモリ操作とABENDの回避
我々アーキテクトがPL/Iで最も恐れるのは、データ長を超えた`TRANSLATE`や、無効なポインタ参照による`0C4 ABEND`だ。特にCICSオンライン環境では、ストレージ保護が厳格である。
1
DCL P_DATA PTR;
DCL BASED_DATA CHAR(32767) BASED(P_DATA);
/ ポインタ経由で動的に割り当てた領域を操作する際の定石 /
/ 領域外参照を防ぐため、常にLENGTHを検証すること /
IF STG_LEN > 0 THEN
BASED_DATA = TRANSLATE(BASED_DATA, TABLE, SOURCE);
`BASED`変数を使う際、コンパイラはポインタの妥当性をいちいちチェックしてくれない。最適化オプション(`OPTIMIZE(3)`)を有効にしている場合、コンパイラは「この変数は境界内にあるはずだ」という前提でコードを再配置するため、境界チェックが甘くなることがある。デバッグ時には`TEST`オプションを付与し、`CEEHDLR`でエラーハンドリングを仕込んでおくのが、信頼性を担保する唯一の道だ。
3. マルチバイト文字（DBCS）という名の時限爆弾
これが最も厄介だ。`TRANSLATE`関数は、文字通り「バイト単位」の変換を行う。もしデータの中に`SO`（Shift-Out: 0x0E）や`SI`（Shift-In: 0x0F）が含まれるDBCSデータが混在している場合、`TRANSLATE`は容赦なくバイトを置き換える。
結果として、SO/SIのペアが破壊され、後続のプログラムが誤った位置でマルチバイト文字を解釈し、データが化ける（あるいは致命的なABENDを誘発する）。
- 対策: 変換前に`VERIFY`関数でSO/SIの整合性を確認し、DBCSが含まれる領域を保護するガードロジックを必ず挟むこと。これを怠ることは、基幹システムの保守担当者として「時限爆弾を埋め込む」のと同義である。
4. マイグレーションに向けた警鐘
Java/C#への移行を進める際、多くが「ロジックの書き換え」に終始する。しかし、アーキテクトの視点で見れば、それは不十分だ。
- パックデシマル（COMP-3）の内部符号: PL/Iから書き出されたバイナリデータは、符号ビットがEBCDIC特有の処理を受けていることが多い。これを素直にJavaの`BigDecimal`に読み込ませると、符号が反転したり、予期せぬ数値化エラーが発生する。変換テーブルを通す前に、必ずバイナリ構造の正規化が必要だ。
- 埋め込みSQL: DB2のホスト変数として`TRANSLATE`後のデータを使う場合、CCSIDの整合性がDB2のバインド時にも影響する。移行先プラットフォームで「データの意味（セマンティクス）」が保持されているか、単なる「バイト列の移動」になっていないかを検証せよ。
結びに代えて
PL/Iは、ハードウェアの挙動を直接制御できる、極めて野心的で強力な言語だ。`TRANSLATE`関数一つとっても、それを「文字列変換の道具」と見るか、「EBCDICというコード体系を操るインターフェース」と見るかで、設計の深さが変わる。
移行先がクラウドであろうと、オンプレのJava環境であろうと、我々が守るべきは「データが持つ正確性」そのものだ。レガシーコードを解読する際は、単に構文を追うのではなく、そのコードがどのようなハードウェア制約下で、どのようなメモリレイアウトを想定していたのかを想像してほしい。
それが、真のシステムアーキテクトの在り方である。
