現場で泣かないための「ON CONVERSION」活用術：不正データへの防御壁を構築する
メインフレームのバッチ処理において、最も頭を悩ませるのが「外部からの不正データ」だ。特にレガシーシステムの移行や、異種システム間でのデータ連携では、数値項目に空白や制御文字が紛れ込むことなど日常茶飯事である。
「なぜかバッチがU0000やS0C7で落ちる」。調査の結果、データ変換エラーだった……。そんな経験はないだろうか。今回は、PL/Iにおいて最も信頼できる防御壁の一つ、`ON CONVERSION`条件の制御について解説する。
—
なぜ `ON CONVERSION` なのか？
PL/Iの強力な機能の一つに、実行時の例外を捕捉する「ONユニット」がある。`CONVERSION`条件は、文字列から数値（固定小数点や浮動小数点）への変換が失敗した瞬間に発火する。
これを適切に実装しておけば、不正なレコードに遭遇しても、ジョブを異常終了させることなく「異常値としてログに退避する」あるいは「デフォルト値に置き換えて処理を続行する」という、柔軟なリカバリが可能になる。
—
実践的なコード例：安全なデータ変換の仕組み
以下のコードは、VSAMファイルや順次ファイルから読み込んだ文字列データを数値変換する際、エラーをハンドリングする標準的なパターンの抜粋だ。
1
TEST_CONV: PROCEDURE OPTIONS(MAIN);
/ 文字列から数値への変換時に発生するエラーを捕捉する /
ON CONVERSION BEGIN;
/ エラー箇所の値をログに出力し、リカバリ処理へ /
PUT SKIP LIST(‘警告: 不正なデータが検出されました。値: ‘ || ONCHAR());
/ 不正な値の代わりに0を代入して、処理を強引に継続させる /
/ ONCHAR() を使って発生源を特定することも可能 /
CONV_VAL = 0;
RETRY; / エラー箇所から処理を再開させる魔法のキーワード /
END;
DCL INPUT_DATA CHAR(10) INIT(‘123A5’); / 変換失敗を誘発するデータ /
DCL CONV_VAL FIXED DEC(5,0);
/ 変換を実行：ここでエラーが発生するとONユニットへ飛ぶ /
CONV_VAL = INPUT_DATA;
PUT SKIP LIST(‘変換後の値: ‘ || CONV_VAL);
END TEST_CONV;
—
エンジニアが押さえておくべき「3つの鉄則」
1. `RETRY` の使い方には細心の注意を
`RETRY`文は、エラーが発生した箇所を再実行する。しかし、もしエラーを解消するロジック（代入など）を書き忘れると、無限ループに陥る可能性がある。必ず`ONCHAR()`や`ONSUBCODE()`を駆使して、エラー箇所を正常化してから`RETRY`させるのが鉄則だ。
2. スコープ（有効範囲）を意識する
`ON`ユニットは、その手続きがアクティブな間ずっと有効だ。特定のブロックだけで有効にしたい場合は、`BEGIN`ブロック内で定義し、終了時に`REVERT`をかけるのがスマートだ。グローバルに定義しすぎると、意図しない場所でのエラーまで拾ってしまう。
3. ログ出力は「後始末」の生命線
`PUT SKIP LIST`は手軽だが、大規模バッチではSYSOUTが溢れる原因になる。実務では、エラー発生時の入力レコード内容やキー項目を、診断用ファイルやDB2のログテーブルに書き出す処理を実装しよう。後から「あの時何が起きたのか」を追跡できるかどうかが、保守担当者の評価を分ける。
—
アーキテクトからのアドバイス
最近のマイグレーション現場では、COBOLからPL/Iへ、あるいはその逆と、コードが混在するケースも多い。しかし、PL/Iのこのような「例外捕捉の柔軟性」は、COBOLの`ON SIZE ERROR`などと比較しても非常に強力だ。
もし、貴方の担当するバッチ処理が「データ異常で即死」するような設計になっているなら、それはPL/Iのポテンシャルを殺しているに等しい。`ON CONVERSION`を使って、堅牢で止まらないシステムを構築してほしい。
プログラミングは芸術だが、メインフレームの保守は「いかにして止まらないか」という科学だ。次の改修の際には、ぜひこのコードを仕込んでおいてくれ。君の深夜の呼び出しが、一件でも減ることを願っている。
