識別子の呪縛がない言語、PL/I：TRANSLATE関数とEBCDICの深層
メインフレームの現場で何十年も動き続けているPL/Iプログラムの保守や、Java/C#へのマイグレーション（レガシー移行）を任されたとき、多くのオープン系エンジニアが最初に驚愕するのが「この言語には厳密な予約語（Reserved Words）が存在しない」という事実だ。
`IF`や`DO`といった制御文字すら、文脈によっては単なる変数名として許容される。CやJavaのように「キーワードだから変数名に使えない」というコンパイルエラーに悩まされない反面、書き手とコンパイラの解釈がズレたときのカオスは、長年汎用機を触ってきたアーキテクトなら誰もが冷や汗をかいた経験があるはずだ。
今回は、この独特な構文自由度を持つPL/Iにおいて、基幹システムのデータ加工で多用される `TRANSLATE`関数と文字変換内部テーブル に焦点を当てる。単なる文字列置換の解説ではない。EBCDICコード体系のハードウェア特性、ポインタ操作を伴う動的メモリ管理、さらにはマイグレーション時の致命的な罠まで、システムアーキテクトの視点から徹底的に紐解いていこう。
—
1. TRANSLATE関数の基本とEBCDIC変換の効率性
`TRANSLATE`関数は、指定された文字列（第1引数）の中で、変換対象文字（第2引数）を対応する変換後文字（第3引数）に置換するための組み込み関数である。C言語の `tr` コマンドや、他言語の文字マッピング処理に似ているが、IBMメインフレーム（z/Architecture）上では、これが単なるソフトウェアのループ処理ではなく、ハードウェア命令（TR命令など）と直結して極めて高速に実行される点に強みがある。
しかし、変換テーブルの設計を誤ると、バッチ処理全体のスループットを大きく落としたり、予期せぬデータ化けを引き起こしたりする。特に、JIS漢字やシフトJISが混在する現代の基幹システムにおいて、EBCDIC（IBM漢字コードやCCS1027など）のコードポイントを正確に理解していないと、致命傷になる。
以下の実用的なPL/Iコードを見てほしい。大文字で統一された、現場のバッチ処理を想定した実装だ。
DCL 1 W_WORK_AREA,
5 W_TARGET_STR CHAR(100) INIT(‘00012345-ABC’), / 変換対象のベース変数 /
5 W_TRANS_TABLE CHAR(256) INIT(/ 256バイトの変換テーブル /);
/ 変換テーブルの初期化ロジックなどの後、TRANSLATEを実行 /
/ 第2引数の文字を、第3引数の位置に対応する文字へ一括置換する /
W_TARGET_STR = TRANSLATE(W_TARGET_STR,
‘ABCDEFGHIJKLMNOPQRSTUVWXYZ’, / 変換元文字群 /
‘abcdefghijklmnopqrstuvwxyz’); / 変換先文字群（小文字→大文字化の例） /
ここで注目すべきは、第3引数以降に渡される「変換テーブル（通常256バイト）」の存在だ。PL/Iでは、このテーブルを動的に構築し、ポインタを用いて高速に参照・書き換える手法がよく使われる。
—
2. ベース変数とポインタを用いた動的変換テーブルの操作
基幹システムの夜間バッチなどでは、外部から渡される電文レイアウトや変換ルールが動的に変わることがある。ハードコーディングされたテーブルではなく、メモリ上の動的領域にテーブルを展開し、ポインタで制御するアーキテクチャが求められる所以だ。
以下に、ポインタとBASEDストレージクラスを用いた高度なテーブル操作の例を示す。
/ 変換テーブルの構造体定義 /
Dcl 1 TBL_TEMPLATE Based(P_TBL),
5 TBL_ENTRY Char(1);
Dcl P_TBL Pointer;
Dcl W_256_AREA Char(256) Based(P_256);
Dcl P_256 Pointer;
Dcl W_I Fixed Bin(31);
Dcl W_BYTE_VAL Fixed Bin(31);
/ 領域の動的獲得（STORAGE関数とALLOCATE文） /
P_256 = Storage(W_256_AREA); / 実際にはALLOCATE等でヒープから取得 /
/ EBCDICの全コードポイント（0～255）に対するカスタム変換テーブルの動的構築 /
Do W_I = 1 To 256;
P_TBL = Addrel(P_256, W_I – 1); / ポインタ演算によるオフセット移動 /
/ 例：特定の制御文字や特殊文字をブランク（X’40’）に潰す処理 /
If W_I < 64 Then
TBL_ENTRY = X'40';
Else
/ 自作の対応ロジックに基づくバイト代入 /
TBL_ENTRY = Byte(W_I - 1);
End;
/ 構築した動的テーブルをTRANSLATE関数の第3引数（またはテーブル形式）として適用 /
/ ※PL/IのTRANSLATEは第2引数に256バイトのテーブル文字列を直接取ることも可能 /
このコードで使用している `ADDREL` やポインタ演算は、C言語のポインタ操作に匹敵する柔軟性を持つ反面、アドレス計算を誤れば瞬時に S0C4（Protection Exception） や S0C1（Operation Exception） といったアベンドを引き起こす。ダンプ解析の現場では、お馴染みの光景である。
—
3. コンパイラオプションによる最適化とアベンド（ABEND）解析
Enterprise PL/Iコンパイラを使用する際、文字変換処理のパフォーマンスを極限まで高めるためには、適切なコンパイラオプションの選定が不可欠だ。
- `OPTIMIZE(2)` または `OPTIMIZE(FULL)`: ループ内の不変式を外側に追い出し、`TRANSLATE` 処理で使われるインラインコード展開を促進する。
- `INLINE`: 小規模な変換ルーチンをサブルーチン呼び出しからインライン展開に切り替え、分岐命令（BALR/BSM）のオーバーヘッドを削る。
しかし、最適化を極限まで上げると、万が一アベンドが発生した際のCEEDUMP（Language Environmentのダンプ）解析が難解になる。
例えば、ポインタの指す先が不正になり `TRANSLATE` が参照外メモリを読みに行った場合、S0C4アベンドが発生する。ダンプリストのPSW（Program Status Word）とレジスタ（R14, R15など）を確認し、どのステートメントのどのデータ参照で例外が起きたのかを逆算するスキルは、メインフレームアーキテクトにとって必須の技量だ。
特に、EBCDIC環境下では、パックデシマル（COMP-3）の符号領域（下位4ビット）を誤って `TRANSLATE` の対象にしてしまい、内部符号が破壊されるバグが後を絶たない。
—
4. マイグレーション（Java/C#）におけるエッジケース対策
レガシーマイグレーションのプロジェクトにおいて、PL/Iの `TRANSLATE` 関数とEBCDICテーブル変換をJavaやC#に移植する際、最も多く踏む地雷が 「文字コード体系の差異（EBCDIC vs ASCII/UTF-8）」 である。
1. コードポイントの非対称性:
EBCDICのアルファベットや数字の並びは、ASCIIとは完全に異なっている（例：EBCDICの ‘A’ は `X’C1’`、ASCIIの ‘A’ は `X’41’`）。PL/Iの `TRANSLATE` でEBCDICのコードポイント前提で組まれていた256バイトの変換テーブルを、そのままJavaの `String.replace()` やバイト配列操作に移植すると、意図しない文字化けやデータ破損を起こす。
2. DB2埋め込みSQLやCICSオンラインとの連携:
CICS環境下で画面から受け取った3270データストリーム（EBCDIC）に対し、`TRANSLATE` で漢字変換前のカナ寄せや特殊文字のマスク処理を行っている場合、Javaのマイクロサービス側で同一のバイナリ互換性を担保する必要がある。マイグレーション時には、単なる構文変換ではなく、「文字コード変換のタイミングをどこで行うか（DB2手前か、画面入出力時か）」というアーキテクチャ全体の再設計が求められる。
—
5. 結びにかえて
PL/Iの識別子の自由度と、ポインタや文字変換テーブルを駆使した低水準なメモリ操作は、ハードウェアの性能を極限まで引き出すための洗練された仕組みである。
コードの古臭さに惑わされてその本質を見誤ると、マイグレーションの現場で痛い目を見る。TRANSLATE関数一つをとっても、それが裏でどのようなEBCDICのバイト操作を行い、コンパイラやハードウェアとどう連携しているのか。その深層を理解しているか否かが、システムアーキテクトとしての真価を問う試金石となるのだ。
