PL/Iの「自由」が招く罠：GET/PUT EDITと帳票制御の深淵
多くのモダン言語エンジニアがPL/Iのコードを初めて見たとき、その「予約語の欠如」に驚愕し、次にその「自由奔放な記述」に戦慄する。`IF`が変数名に使えてしまうという事実は、現代のコンパイラ設計からは狂気のように見えるかもしれない。しかし、この「文脈によって意味が決まる」柔軟性こそが、数十年稼働し続ける基幹システムの心臓部を支えてきた強靭さの源泉でもある。
今日は、帳票出力やストリームファイル操作の要である`GET/PUT EDIT`、そしてその背後にある「地獄のダンプ解析」までを俯瞰して語ろう。
1. STREAM I/Oの制御：COLUMN, LINE, SKIPの物理的意味
帳票出力における`PUT EDIT`は、単なる文字列出力ではない。JCLで定義されたDCB（データ制御ブロック）の物理的な制約を、コンパイラがどのようにメモリ上のバッファへマッピングするかを理解する必要がある。
1
/ 帳票出力の典型的な制御例 /
PUT FILE(REPORT) EDIT (
‘CUSTOMER-ID:’, CUST_ID,
‘BALANCE:’, BALANCE
) (
SKIP(1), / 改行 /
COLUMN(10), A, / 指定カラムへの移動 /
F(10), / 数値のフォーマット /
COLUMN(30), A,
P’ZZZ,ZZ9.99′ / パックデシマルの編集 /
);
ここで注意すべきは、`SKIP`や`PAGE`が暗黙的に実行するバッファフラッシュだ。マイグレーションにおいて、この物理行制御をJavaの`PrintWriter`等に置き換える際、単なる改行コードの挿入と勘違いしてはいけない。メインフレームの帳票は、制御文字（ASA制御コードなど）が論理レコードの先頭に付与される構造である。この「制御コード」を見落とした結果、移行先で帳票が真っ白になったり、文字化けしたりする事故を私は幾度となく見てきた。
2. 「予約語がない」ことの代償：バグの温床
PL/Iには、いわゆる「予約語」が存在しない。以下を見てほしい。
1
/ 狂気のコード例 /
DCL IF FIXED BIN(15) INIT(10);
DCL THEN FIXED BIN(15) INIT(20);
IF = THEN + 5; / これは文法的に完璧に正しい /
この仕様は、動的メモリ操作やポインタ演算と組み合わさると、デバッグを地獄へ引きずり込む。特に、既存コードを改修する際、うっかりシステム変数を上書きするような命名をしてしまうと、コンパイラは警告すら出さずに正常終了する。マイグレーション時の静的解析ツールがこの「動的命名」を正しく解釈できない場合、ロジックの継承は高確率で失敗する。
3. パックデシマルと内部符号の呪い
JavaやC#への移行で最も厄介なのが、`PIC S9(n) COMP-3`、すなわちパックデシマル型の符号反転だ。
メインフレームの内部表現では、正の数は `C`、負の数は `D`（あるいは `F`）が最下位ニブルに格納される。このビット列をそのままJavaの`long`にキャストしようとすれば、符号が化けるのは当然だ。
解決のヒント：
ポインタを用いてメモリをダンプし、`X’0D’`や`X’0C’`を明示的に判定するユーティリティを必ず噛ませること。ABEND（S0C7など）が発生した場合、まずは該当するデータ領域が「有効なパック形式であるか」をダンプの16進数で確認せよ。`0-9`以外の値が混入している場合、それは入力ファイルか、あるいは前段の計算ロジックによるメモリ破壊の兆候だ。
4. ABEND（S0C7/S0C4）の深層心理
基幹システムのアーキテクトとして、我々はコンパイラを信じてはならない。特に`DCL`で宣言した変数が初期化されていない場合、それはメモリ上の「ゴミ」を拾い、演算を行う。
- S0C7 (Data Exception): 演算対象が数値形式ではない。前述のパックデシマルの符号破壊か、未初期化変数が原因。
- S0C4 (Protection Exception): ポインタ演算の失敗。`ADDR(VAR)`で取得したアドレスに対し、領域外アクセスを行っている。
特に、`DCL P PTR;`を用いた動的割り当てにおいて、`ALLOCATE`後に`FREE`を忘れる、あるいは`FREE`したポインタを再参照する「ダングリングポインタ」は、バッチ処理の終盤で突然発生する。これらは再現性が低く、稼働後の運用で最も胃を痛める要因となる。
最後に：移行設計への助言
レガシー移行において、PL/IをJavaに書き換えることは「言語の翻訳」ではない。「アーキテクチャの再構築」である。
PL/Iの`STREAM I/O`が暗黙的に行っていたバッファリングや、DB2への埋め込みSQLにおけるカーソル管理の挙動は、現代の疎結合なマイクロサービスアーキテクチャでは再現が難しい。コードを一行一行翻訳するのではなく、そのコードが「メインフレームのどの物理リソースを守ろうとしているのか」という意図を汲み取ってほしい。
我々アーキテクトに求められているのは、単なるコードの置換ではない。数十年前の設計思想が抱えていた「制約の美学」を、現代の技術でいかに高潔に再実装するか。その一点に尽きる。
次の改修で、もし`S0C7`のダンプに直面したら、画面を閉じずに、まずはその変数の定義と、それがメモリのどの位置に配置されているかを追ってみてほしい。真実の多くは、コンパイラの最適化リストの行間、そしてメモリの深淵に眠っているのだから。
