予約語なき言語の深淵：PL/Iにおける文字変換の最適化とアーキテクチャの死角
汎用機（Mainframe）の現場で30年、幾多のシステム移行を渡り歩いてきたが、PL/Iほど誤解されている言語はない。「古臭い」「可読性が低い」と揶揄されることもあるが、それはこの言語が持つ「コンパイラに対する極めて直接的な命令権」を理解していない者の戯言に過ぎない。
今日は、PL/Iの「予約語を持たない」という極めて特異な仕様が、いかにして文字変換のパフォーマンスに寄与し、あるいはマイグレーション時に我々を地獄へ叩き込むか、その深層に触れていきたい。
—
1. TRANSLATE関数の裏側：EBCDICと変換テーブルの最適化
`TRANSLATE`関数は、PL/Iプログラマにとって最も身近な武器だが、その内部挙動を意識している者は少ない。
/i
/ 文字変換の基本例 /
DCL TARGET_STR CHAR(80) VAR;
DCL SOURCE_STR CHAR(80) VAR;
DCL (TBL_IN, TBL_OUT) CHAR(256) INIT(…);
/ TRANSLATEの実行 /
TARGET_STR = TRANSLATE(SOURCE_STR, TBL_OUT, TBL_IN);
この一行がコンパイルされるとき、コンパイラは内部的に「変換テーブルを参照するループ」を展開する。EBCDIC環境において、この処理はCPUのL1キャッシュと非常に相性が良い。だが、変換対象が巨大なバッチ処理の一部である場合、この関数を愚直にループ内で回すのは悪手だ。
アーキテクトの視点：なぜ「予約語がない」ことが重要なのか
PL/Iには厳密な意味での「予約語」が存在しない。`IF`や`THEN`でさえ、変数名として宣言できてしまう。これはコンパイラが「文脈」を解析してコードを生成していることを意味する。
`TRANSLATE`関数を使用する際、第2・第3引数を静的な定数として渡すか、あるいは`BASED`変数を用いてメモリアドレスを直接参照させるかで、生成されるマシン語の効率は劇的に変わる。
—
2. マイグレーションの罠：パックデシマルと内部符号
JavaやC#への移行を検討する際、最もエンジニアが苦しむのが`PIC S9(n) COMP-3`の処理だ。特に、EBCDIC特有の「内部符号（サイン）」の扱いは、移行先の環境（ASCII/UTF-8）と致命的な差異を生む。
/i
/ パックデシマルの符号反転バグの典型的なケース /
DCL WORK_AMT PIC S9(7)V99 COMP-3;
/
- この変数がCICSの通信域（COMMAREA）を経由して
- 他システムに渡される際、符号ビットが規格外の値をとると
- Java側のBigDecimal変換で即座にNumberFormatExceptionを誘発する。
/
移行設計において、PL/Iのバイナリダンプを解析する際、`ABEND S0C7`（データ例外）に遭遇したら、まず疑うべきは「変換の過程で符号が0x0C/0x0D以外の値を保持していないか」だ。PL/Iはこれを黙認して計算を進めようとするが、Javaは許さない。この「PL/Iの寛容さ」こそが、移行時の不整合の温床となる。
—
3. 動的メモリ操作とポインタの活用：極限のパフォーマンス
大規模バッチにおいて、膨大なレコードを処理する際、`ALLOCATE`による動的メモリ操作は避けて通れない。しかし、ここでのポインタ操作を誤ると、再帰的なメモリリークや、最悪の場合はアドレス空間を跨いだ破壊を引き起こす。
/i
/ ポインタを用いた効率的なデータアクセス /
DCL DATA_PTR POINTER;
DCL DATA_AREA CHAR(1024) BASED(DATA_PTR);
/ 領域確保の最適化：一度のGET STORAGEで複数レコードを管理する /
ALLOCATE DATA_AREA;
/
- ここでポインタをずらす（オフセット計算）ことで、
- 配列を再定義せずにメモリ上のストリームを走査できる。
- マイグレーション時には、この「ポインタ演算」を
- JavaのByteBufferやUnsafeクラスでどう等価実装するかが腕の見せ所だ。
/
—
結びに：レガシーを「遺産」にするために
PL/Iが現代のJavaやC#と根本的に異なるのは、「ハードウェアが何を見ているか」をプログラマが記述できる点にある。マイグレーションプロジェクトにおいて、単に言語を置き換えるだけでは、元のPL/Iが持っていた「計算資源を極限まで絞り出す」という設計思想までは移植できない。
もし君が、いま正に「PL/IからJavaへの移行」の真っ只中にいるなら、ソースコードを一行ずつ読み解くのではなく、「コンパイラがこのコードを見て、どのようなマシン語を出力しているか」を想像してみてほしい。
その先にこそ、真の「移行成功」と、システムアーキテクトとしての昇華があるはずだ。
—
追伸：もし特定のABENDコードや、DB2埋め込みSQLのデッドロック問題に頭を抱えているなら、また次の機会に「CICS/DB2間のコミット論理」について深く掘り下げよう。この世界には、マニュアルには載っていない「呼吸」のような挙動が確かに存在する。
