枯れた技術の深淵：PL/Iにおける`ON CONVERSION`と「予測不可能なデータ」との対話
メインフレームの現場で、夜中の3時に呼び出される理由の8割は、COBOLやPL/Iで処理しきれない「ゴミデータ」の混入だ。DB2から抽出したはずのパックデシマル（COMP-3）項目に、なぜかEBCDICの半角スペースや不明なビットパターンが紛れ込む。
多くの開発者は、この瞬間にシステムが`S0C7`（データ例外）で沈没するのを指をくわえて眺めることになる。だが、PL/Iを扱う我々アーキテクトにとって、`ON CONVERSION`は単なるエラーハンドリングではない。これは、レガシーシステムが絶命するのを防ぐための「最後の防波堤」だ。
ON CONVERSION：アベンドを回避し、システムの矜持を保つ
PL/Iの`ON CONVERSION`は、数値型への変換失敗を検知して制御を奪い取る。単に「止める」のではなく、「何とかして処理を継続する」ためのトリガーとして使うのがプロの流儀だ。
以下に、現場でそのまま使える、堅牢なエラー捕捉パターンの実例を示す。
/i
/ — 数値変換エラーの捕捉とリカバリ — /
EXAMPLE_PROC: PROCEDURE OPTIONS(MAIN);
DCL INPUT_VAL CHAR(10) INIT(‘123A5’); / 不正データが混入したと想定 /
DCL TARGET_NUM FIXED DEC(5,0);
DCL ERROR_FLAG BIT(1) INIT(‘0’B);
/ オン・ユニットの設定：変換エラー発生時に制御を移す /
ON CONVERSION BEGIN;
PUT SKIP LIST(‘警告: 不正な数値変換を検出しました。ログを出力して0で補完します。’);
ERROR_FLAG = ‘1’B;
/ 変換対象を強制的に’0’に置き換えて処理を続行させる /
CONV_DATA = ‘0’;
END;
/ 実際に数値変換が発生する箇所 /
TARGET_NUM = INPUT_VAL;
IF ERROR_FLAG THEN
CALL LOG_ERROR_TO_DB2(INPUT_VAL); / 不正な値を別テーブルへ退避 /
ELSE
CALL PROCESS_BUSINESS_LOGIC(TARGET_NUM);
END EXAMPLE_PROC;
なぜコンパイラ最適化と「ポインタ」が重要なのか
マイグレーション先のJavaやC#では、データ型変換は例外スロー（`NumberFormatException`）が標準だが、PL/Iでは「動的メモリ操作」が可能だ。もし`ON CONVERSION`で拾えないような、より低レイヤーの破壊的なデータ破損に遭遇した場合、私は`ADDR()`関数とポインタを用いて、当該領域を直接バイナリ解析する。
特に、パックデシマルの内部符号反転バグは厄介だ。本来`0x0C`（正）であるべき末尾のニブルが`0x0F`や`0x00`で入ってくる場合、標準的な代入文ではどうしようもない。このようなケースでは、構造体（`BASED`変数）にポインタをキャストし、メモリ上のビットパターンを直接操作して正規化する。この設計思想が、Javaへの移行時にも「単なる自動変換」を超えた、堅牢なデータ正規化層を設計する際の指針となる。
マイグレーションの最前線で語るべき「教訓」
私たちがレガシーからオープンシステムへ移行する際、最も犯しやすいミスは「エラーを例外としてスローすること」だ。
1. アベンドを恐れるな、制御せよ：`ON CONVERSION`で捕捉したなら、単にログを出すだけでなく、そのデータが「なぜ不正になったのか」のメタデータ（ジョブ名、タイムスタンプ、ソーステーブル名）をDB2の例外テーブルに書き出すまでをセットにする。
2. CICS環境での注意：CICSオンライン処理において`ON CONVERSION`を広域で設定すると、タスク全体のパフォーマンスに影響を及ぼす。プログラムのスコープを限定し、`REVERT`文で適切にハンドラを解放することを忘れてはならない。
3. コンパイラオプションの罠：`LIMITS(FIXEDDEC(15,5))`のような最適化設定を行っている場合、境界値チェックが緩和されることがある。移行前には、現行機のコンパイラオプションと、新しい環境でのデータ型の挙動をバイトレベルで比較検証すること。
結びに代えて
PL/Iは、もはや「古い言語」ではない。システムがどれだけ巨大化しようと、データの整合性を守るための厳しい制約を、コンパイラレベルで強制できる数少ない言語だ。
もし今、あなたの現場で「原因不明のS0C7」が頻発しているなら、それはシステムが「もうこれ以上、不整合なデータを受け入れられない」と叫んでいる証拠だ。`ON CONVERSION`を導入し、不正データを「捨てる」のではなく「飼い慣らす」設計に切り替える。それこそが、次の10年を支えるシステムアーキテクトが取るべき唯一の道である。
次は、埋め込みSQLにおけるホスト変数の境界を超えたメモリ破壊について深掘りしよう。メインフレームの深淵は、まだまだ尽きない。
