魂を込めた例外処理：PL/IにおけるON CONVERSIONの深淵と実戦的アプローチ
メインフレームの現場で何十年と「枯れた」コードを保守し、時にはJavaへの移行という名の荒波に揉まれる皆さんに問いたい。「データ変換エラー（S0C7の予兆）を、単なるアベンドとして処理し終えていないか？」と。
特にPL/Iは、その柔軟な型変換ゆえに、境界値やゴミデータに対して極めてセンシティブだ。今回は、基幹システムの信頼性を担保する最後の砦、『ON CONVERSION』による異常捕捉と、それにまつわるアーキテクチャの急所を解き明かす。
—
1. なぜ「ON CONVERSION」なのか
DECIMALやFIXED BINへの変換時に、文字データが混入すればコンパイラは即座に例外を投げる。これを放置すれば、バッチ処理はS0C7の山となり、深夜の運用担当者が泣くことになる。
我々アーキテクトが目指すべきは、アベンドによる停止ではなく、「異常を検知し、安全にデフォルト値へフォールバックし、かつそのログを確実に残す」という自律的な例外処理だ。
1
/ 異常発生時の動的ハンドリング例 /
ON CONVERSION
BEGIN;
/ 変換に失敗した変数の名前を取得し、ログ出力する処理 /
PUT SKIP LIST(‘データ変換エラーが発生しました。デフォルト値 0 をセットします。’);
/ コンパイラの内部レジスタを操作し、変換結果を 0 に差し替える /
CONVERSION = 0;
END;
2. コンパイラ最適化と「見えないバグ」の正体
ここで注意が必要なのが、コンパイラオプション（`OPTIMIZE(3)`など）による影響だ。最適化を効かせると、コンパイラはコードの命令順序を激しく入れ替える。この際、`ON CONVERSION`のスコープが正しく制御フローに乗っているかを確認しなければならない。
特に、パックデシマル（FIXED DECIMAL）の内部符号反転は鬼門だ。EBCDIC環境において、数値の末尾が正当なゾーン符号（X’C’やX’D’）ではなく、ファイル転送時の不手際等でX’F’（符号なし）となっている場合、算術演算で即座にアベンドする。
実践的なエッジケース対策
CICSオンライン処理において、画面入力項目をそのままDB2のパックデシマル列に突っ込む際、この`ON CONVERSION`が命綱になる。
1
/ CICS環境下での安全な変換スキーム /
PROCEDURE OPTIONS(MAIN);
DCL INPUT_VAL CHAR(10) BASED(P_VAL);
DCL P_VAL POINTER;
DCL TARGET_NUM FIXED DEC(9,0);
/ ポインタを用いたメモリ直接参照時の注意点 /
/ 文字列の先頭から数値部分だけを切り出すような動的メモリ操作を行う際、 /
/ ON CONVERSION を適切に配置しないと、メモリ保護違反を誘発する /
BEGIN;
ON CONVERSION CALL LOG_ERROR_ROUTINE;
TARGET_NUM = INPUT_VAL; / ここで数値以外ならONユニットへ遷移 /
END;
LOG_ERROR_ROUTINE: PROC;
/ DB2へのダンプ記録や、CICSのTDQへの出力 /
END;
3. マイグレーションに向けたアーキテクチャの視点
JavaやC#への移行を検討している読者へ。現在のPL/Iの`ON CONVERSION`の挙動は、そのままJavaの`try-catch`に置き換えてはならない。
PL/Iの`ON`ユニットは、実行時のステートメント環境を継承する。一方で、Javaの例外処理はスタックトレースに基づく。移行設計においては、以下のポイントを遵守することをお勧めする。
1. データの「バリデーション」と「変換」の完全分離: 移行先の言語では、変換前に正規表現や数値チェックユーティリティを通すレイヤーを設けること。
2. ダンプ解析の再現性: メインフレームのSYSUDUMPやCEEDUMPは、変数の変遷を追う上で最高のリソースだ。移行後のシステムでも、例外発生時に変数の状態（特にポインタ先の内容）を確実にログ出力する設計を怠らないこと。
3. DB2埋め込みSQLの型不一致: PL/I側で許容されていた「数値の文字詰め」が、DB2側で厳格な型チェックを求められるケースがある。`ON CONVERSION`で防いでいたゴミデータが、移行先ではDB2のSQLエラー（SQLCODE -180等）として跳ね返ってくる。
最後に：アーキテクトとしての矜持
PL/Iのコードは、時に難解で冗長だ。しかし、その裏には「何があっても計算を止めない」という、先人たちの執念が刻まれている。
`ON CONVERSION`を使いこなすことは、単なるエラー回避ではない。システムに「回復力（レジリエンス）」を持たせることに他ならない。新技術への移行においても、この「何が起きてもシステムを破綻させない」という哲学だけは、決して枯らしてはならないのだ。
次回の記事では、`DECLARE`文におけるポインタ修飾の極意と、複雑な構造体（`BASED`変数）を効率的に扱うためのメモリ・アライメントについて深掘りする予定だ。現場の悩みがあれば、また語り合おう。
