PL/Iの深淵：ON ENDFILEが導く制御の罠と、次世代移行への技術的遺産
汎用機の世界では、コードは単なる「論理の記述」ではない。それは、数十年稼働し続けることを前提とした、堅牢な機械の設計図そのものだ。
PL/I（Programming Language One）という言語は、その設計思想において極めて野心的だ。科学技術計算から事務処理、さらにはシステム制御までを網羅しようとしたその複雑さは、現代の言語にはない特有の「深み」を生んでいる。今回は、バッチ処理の生命線である`ON ENDFILE`の制御と、それが現代のマイグレーションプロジェクトにおいてどのような地雷原となり得るか、実務的な視点で紐解いていく。
—
1. ON ENDFILE：宣言的制御の美学と現実
PL/Iの`ON`ユニットは、当時のコンパイラ技術からすれば魔法のような例外処理機構だった。`ON ENDFILE(ファイル名)`は、ファイル終了を「割り込み」として捉え、制御を強制的に移す。
1
/ 順次ファイル読み込みの典型的なパターン /
ON ENDFILE(INPUT_FILE) BEGIN;
/ フラグを立てて読み込みループを終了させる /
EOF_FLG = ‘1’B;
GOTO LOOP_EXIT;
END;
READ FILE(INPUT_FILE) INTO(REC_BUF);
DO WHILE (EOF_FLG = ‘0’B);
/ 処理ロジック /
…
READ FILE(INPUT_FILE) INTO(REC_BUF);
END;
LOOP_EXIT:
/ 後処理 /
このコードにおいて、`GOTO`を「悪」と断ずる現代のプログラマーもいるだろう。だが、PL/Iの文脈において、`ON`ユニット内からの`GOTO`は、スタックを巻き戻して正常な制御フローに復帰させるための、極めて実用的な「緊急脱出」なのだ。
移行の現場で直面する「アベンドの悪夢」
JavaやC#へマイグレーションする際、この「例外による制御フローの強制遷移」をどのようにマッピングするかが最大の課題となる。単純に`try-catch`で囲めば済む話ではない。特にCICSオンライン処理において、この`ON`ユニットの有効範囲（SCOPE）を読み違えると、意図しないタイミングで前のトランザクションの終了処理が走り、深刻なデータ不整合を引き起こす。
—
2. 禁断の果実：ポインタと動的メモリ操作
PL/Iが強力なのは、アセンブラに近いメモリ操作を許容しているからだ。`BASED`変数と`ADDR`関数、そして`POINTER`の組み合わせは、パフォーマンスの最適化には寄与するが、同時に「パックデシマル（COMP-3）の内部符号」を破壊するリスクを孕んでいる。
1
DCL P POINTER;
DCL MY_REC CHAR(100) BASED(P);
/ 特定のオフセットに直接アクセス /
P = ADDR(BUFFER) + 20;
このポインタ操作をC#の`unsafe`コードやJavaの`ByteBuffer`で書き換える際、注意すべきは「符号反転」だ。汎用機特有のパックデシマルにおいて、負の数の内部表現（例えば`0x0D`が`0x0C`に変わるケースなど）を正しくハンドリングできなければ、マイグレーション後の計算結果は必ず狂う。私たちはこれを「ビットレベルの言語変換」と呼び、単なるソースコードの翻訳ではなく、メモリレイアウトの再現と位置づけている。
—
3. コンパイラオプションと最適化の深層
IBMコンパイラの`OPTIMIZE(3)`を適用した際、驚くべき挙動を示すことがある。最適化によって一部の未使用変数が削除され、ダンプ解析時に変数の値が参照できなくなる現象だ。
基幹システムでは、ABEND時に生成されるSYSUDUMPが唯一の「黒箱」である。最適化レベルを上げすぎてデバッグ情報を削ぎ落とした結果、本番障害時に原因が特定できず、現場が阿鼻叫喚になる光景を何度も見てきた。
- 教訓: 移行設計においては、あえて最適化レベルを下げたデバッグビルド環境を保持し、パフォーマンス要件と保守性のバランスをトレードオフとして明確に文書化しておくこと。これが、システムアーキテクトとしての責任ある態度だ。
—
4. 最後に：レガシーは「負債」ではなく「知恵」だ
PL/Iのコードを眺めていると、当時の先人たちが限られたCPUサイクルとメモリ容量の中で、どれほど知恵を絞って信頼性を担保してきたかが伝わってくる。`ON ENDFILE`一つとっても、そこにはエラーハンドリングの哲学が宿っている。
もし、貴方が今、この古き良き言語からオープン系への移行を担っているのなら、ただコードを変換する作業者になってはいけない。「なぜ、この例外処理が必要だったのか」「なぜ、このポインタ操作でなければならなかったのか」という、当時の制約と要求を読み解く考古学者になれ。
技術は常に進化するが、システムに求められる「止まらない信頼性」という本質は、メインフレームの時代から何も変わっていない。その本質を理解してこそ、初めて真のアーキテクトと呼べるのではないだろうか。
また次の機会には、DB2の埋め込みSQLにおけるカーソル制御と、それに付随する`SQLCODE`の巧妙なハンドリングについて掘り下げていこうと思う。現場の「戦い」は、まだ終わらない。
