【実務・中級編】ON CONVERSION条件によるデータ変換エラーの捕捉 – PL/Iの基本構文とデータ制御実践ガイド

現場のエンジニアへ:PL/Iの「ON CONVERSION」で防ぐ、バッチ異常終了の深淵

夜間バッチが走り出し、オペレーターから「ABENDした」と連絡が入る。ログを見ると `S0C7` や「データ例外」の文字。メインフレームの現場では日常茶飯事の光景だが、その原因が「外部データが混入した数値フィールド」である場合、PL/Iの恩恵を最大限に活用できているかどうかで、復旧のスピードと品質は大きく変わる。

今日は、PL/Iの最大の武器の一つである「ON CONVERSION」条件について、現場でそのまま使える知見を語ろう。

1. 予約語なき言語、PL/Iの懐の深さと罠

まず大前提として、PL/Iには「予約語」という概念が存在しない。`IF`という変数名を使おうが、`DECLARE`という名前の配列を作ろうが、コンパイラはコンテキストで判別する。これは強力だが、裏を返せば「書き手の意図が明確でないと、後世の保守担当が地獄を見る」ことを意味する。

特にデータ変換。`CHARACTER`から`FIXED BINARY`への暗黙的な変換は、PL/Iの強力な機能だが、同時にバッチを落とす「時限爆弾」でもある。この爆弾を安全に処理するのが `ON CONVERSION` ユニットだ。

2. ON CONVERSIONによる防御的プログラミング

データ変換エラーが発生した際、デフォルトの動作は「即座にプログラムを中断(ABEND)」させることだ。しかし、これではバッチの堅牢性は語れない。

`ON CONVERSION` を定義しておくことで、エラー発生時に「何が起きたか」を捕捉し、必要であれば値を補正して処理を継続させることが可能になる。

実践的なサンプルコード

以下に、VSAMファイルから読み込んだデータが数値変換に失敗した際のハンドリング例を示す。

1
/ ——————————————————————- /
/ データ変換エラー捕捉のサンプル /
/ ——————————————————————- /
EXAMPLE_PROC: PROC OPTIONS(MAIN);

DCL WS_INPUT_CHAR CHAR(10) INIT(‘123A5’); / あえて数値でない値を入れる /
DCL WS_TARGET_NUM FIXED DEC(5,0);
DCL MSG_BUFFER CHAR(80) VAR;

/ ON CONVERSIONの定義 /
ON CONVERSION BEGIN;
/ ONSOURCE: エラーの原因となったデータそのもの /
/ ONCHAR: 変換を拒絶した不正な文字 /
MSG_BUFFER = ‘変換エラー検出: データ=’ || ONSOURCE ||
‘ 不正文字=’ || ONCHAR;

PUT SKIP LIST(MSG_BUFFER);

/ ここで値を強制的に0に置換して継続させる例 /
/ 実際にはログを出してABORTするか、スキップするかを判断する /
CONVERSION = ‘0’;
END;

/ 変換の実行 /
WS_TARGET_NUM = WS_INPUT_CHAR;

PUT SKIP LIST(‘処理完了: 値は ‘ || WS_TARGET_NUM);

END EXAMPLE_PROC;

3. ここがプロの勘所:ONCHAR と ONSOURCE を使いこなす

上記のコードで重要なのは、`ONSOURCE` と `ONCHAR` というビルトインファンクション(正確には擬似変数)の活用だ。

  • ONSOURCE: 変換しようとした文字列全体を保持している。デバッグ時に「どのレコードのどのフィールドでコケたか」を一目瞭然にするために必須だ。
  • ONCHAR: 文字列の中で、変換を妨げている「真犯人」の文字を特定できる。スペースが入っているのか、低位バイト(LOW-VALUES)が紛れ込んでいるのか。これを見るだけで、データソースの品質が即座に判明する。

実務上のアドバイス:

変換エラーを捕捉した際、単に `PUT` するだけでなく、VSAMのキー情報と共にエラーログを別ファイル(エラーリストファイル)へ書き出す仕組みを `ON` ユニット内に組み込むべきだ。そうすれば、バッチを止めることなく、後から「どのレコードが異常だったか」を完全にトレースできる。

4. 最後に:保守担当へのメッセージ

PL/Iは古い言語と言われるが、その仕様は現代の言語設計を先取りしている。特に、例外を構造化して処理する `ON` ユニットの仕組みは、他の言語における `try-catch` ブロックよりも柔軟で、システム全体の制御フローを破壊せずにエラー処理を注入できる。

「動けばいい」というコードではなく、「異常が発生した時に、いかに速やかに原因を特定し、業務インパクトを最小限に抑えるか」。それをコードに組み込むのが、我々システムアーキテクトの仕事だ。

次の改修時には、ぜひ `ON CONVERSION` を仕込んでみてほしい。夜間の呼び出し回数が減ることを保証しよう。


現場のエンジニア諸君、今日もメインフレームを止めず、正確に回し続けよう。何か詰まったら、またいつでも相談してくれ。

タイトルとURLをコピーしました