汎用機の「深淵」を覗く：ON CONVERSIONで制御するデータ不整合の処方箋
メインフレームの現場で、夜中のバッチ処理中に突然発生する「S0C7」や「CONVERSION条件」。これらは単なるエラーではなく、システムからの「データ構造とロジックの乖離」を告げる悲鳴です。
現代のJavaやC#のアプリケーションでは、`try-catch`による例外処理は日常茶飯事ですが、PL/Iにおける`ON CONVERSION`は、それらとは一線を画す「動的な割り込み処理」としての重みがあります。今回は、この強力かつ危険な武器を、基幹システムのアーキテクトとしてどう使いこなすべきか、その要諦を語ります。
—
1. CONVERSION条件の本質：なぜ「アベンド」ではなく「介入」か
PL/Iのコンパイラは、算術演算や代入において、ソースデータがターゲットのデータ形式（特にパックデシマルや固定小数点）に適合しないと判断した瞬間に`CONVERSION`条件を発行します。
多くのエンジニアがこれを「防ぐべきエラー」と考えますが、データクレンジングが不十分なレガシー環境では、これを「システムを止めないための安全弁」として活用することが重要です。
基本的な実装パターン
1
/ 異常データ混入時にアベンドを回避し、ログを残して0に補正する例 /
MAIN_PROC: PROCEDURE OPTIONS(MAIN);
DCL WS_WORK_NUM DEC FIXED(7,0);
DCL INPUT_CHAR CHAR(7) INIT(‘123A567’); / 意図的な不正データ /
/ ONユニットの定義：CONVERSIONが発生した瞬間にここへ飛ぶ /
ON CONVERSION BEGIN;
/ コンパイルオプションでDEBUGを指定すれば、より詳細なダンプが得られる /
PUT SKIP LIST(‘警告: 数値変換エラー発生。不正データ検知。’);
/ ここでデータの内容をダンプし、処理を続行させるか判断 /
WS_WORK_NUM = 0; / 0で埋めて強制的に後続処理へ /
/ RESCANにより、変換後の値で処理をやり直す /
RESCAN;
END;
WS_WORK_NUM = INPUT_CHAR; / ここでCONVERSION条件が発生 /
PUT SKIP LIST(‘結果値: ‘, WS_WORK_NUM);
END MAIN_PROC;
—
2. アーキテクトが知るべき「舞台裏」の挙動
パックデシマルの罠と内部表現
しばしば遭遇する「パックデシマルの符号不整合」は、EBCDICコード体系と内部のニブル（4ビット）表現の齟齬に起因します。特に、他システムからファイル転送されたデータで、下位4ビットが正しく`0xC`や`0xD`になっていない場合、コンパイラは即座に音を上げます。
ここで重要なのは、`ON CONVERSION`内でポインタ（POINTER）と`ADDR`関数を用い、メモリ上の生データ（Hex）を直接覗くことです。単に数値を代入するだけでは、なぜその値が不正なのかという「犯人（供給元システム）」を特定できません。
パフォーマンスへの影響
`ON CONVERSION`は、発生のたびにスタックを生成し、ランタイム環境で例外処理をハンドリングします。高頻度で発生するような設計は、メインフレームであってもCPUリソースを著しく消費します。これは「異常系のフロー」であって「正常系のロジック」ではありません。移行先のJava等で`NumberFormatException`を多発させるのが悪手であるのと同様です。
—
3. マイグレーションを見据えた設計指針
JavaやC#への移行を想定する場合、この`ON CONVERSION`の挙動をどうマッピングするかが最大の課題です。
- バリデーションの境界線を定義せよ:
PL/Iでは「動的変換」で逃げていた部分も、Javaでは`Input Validator`で厳格に弾く必要があります。移行設計では、`ON CONVERSION`の発生箇所をすべてリストアップし、「データ修正を上流に持っていく」のか、「新システムでも同様の補正ロジックを実装する」のかを明確にしてください。
- CICS/DB2との親和性:
CICS環境下での`ON CONVERSION`は、トランザクションのロールバックを引き起こす可能性があります。特にDB2の埋め込みSQLで、不正なデータ型のホスト変数を渡した場合、PL/Iのコンパイラがチェックする前に、DB2側でSQLエラー（-301等）が発生することもあります。層（Layer）ごとのエラー責任分界点を意識してください。
—
最後に：職人としての矜持
メインフレームのコードは、時に無骨で、時に冷酷です。しかし、`ON CONVERSION`を適切に配置し、万が一の際にもログを出し、処理を継続させるという設計思想には、ビジネスを止めないという汎用機ならではの「執念」が宿っています。
最新のモダン言語へ移行する際にも、この「異常系をどうハンドリングするか」という哲学だけは捨てないでください。技術は変わっても、システムが守るべき信頼性の本質は変わりません。
読者の皆さんが直面しているコードが、単なる古い資産ではなく、長年ビジネスを支えてきた「誇りある防壁」であることを理解し、慎重かつ大胆に紐解いていくことを期待しています。
