「またS0C7か」と溜息をつく前に―PL/Iにおけるデータ例外の深層とダンプ解析の極意
メインフレームの世界に長く身を置いていると、深夜のバッチ処理で鳴り響くアラートの主役が、いつも「S0C7（データ例外）」であることに気づかされます。特にPL/I環境において、パック十進数（COMP-3）の不正は、プログラムの構造やデータフローを理解していないと、迷宮入りしやすい厄介な相手です。
今日は、なぜPL/IでS0C7が発生するのか、そしてダンプを前にしたとき、プロとしてどう立ち回るべきか、実務的な知見を共有しましょう。
—
1. なぜPL/IでS0C7が起きるのか？
S0C7の正体は、CPUが算術演算命令（PACK, UNPACK, AP, SPなど）を実行しようとした際、対象のデータが正しいパック十進数形式（末尾のニブルが符号として有効か等）になっていないときに発生するハードウェア割り込みです。
PL/Iの場合、特に以下のケースで頻発します。
- 初期化漏れ: `DCL`した変数が自動変数（`AUTOMATIC`）であり、ゴミが入った状態で演算に使われた。
- 定義の不整合: ファイルから読み込んだデータが、期待した型（例えば`PIC S9(7) COMP-3`）と異なる、あるいは空白（SPACE）が入っている。
- 境界違反: 配列の添字計算ミスや、構造体のマッピングが想定とズレている。
—
2. 実践：ダンプから戦犯を特定する手順
夜間のバッチでABENDが発生したら、まずは「SYSMDUMP」を開きます。IDEの便利なデバッガも良いですが、ダンプを読めるスキルはあなたのエンジニアとしての価値を確実に高めます。
ステップ1：命令アドレスの特定
ダンプの冒頭で「SYSTEM COMPLETION CODE=0C7」を確認し、続いて`PSW`（プログラムステータスワード）を見ます。この末尾の数バイトが、次に実行されるはずだった命令のアドレスです。
ステップ2：逆アセンブルの確認
コンパイルリストの`OFFSET`と`PSW`のアドレスを突き合わせます。ここで「どのソース行の、どの演算命令で死んだか」を特定します。もし`AP`（Add Packed）命令なら、オペランド1か2のどちらかが不正な形式になっています。
ステップ3：レジスタとストレージの紐付け
PL/Iのコンパイルリストには、変数のアドレスを管理する「ベースレジスタ」の情報が記載されています。レジスタの値から、該当するストレージ上の実データを確認してください。多くの場合、そこに`X’40404040’`（スペース）や、初期化されていない`X’00’`の羅列が見つかるはずです。
—
3. PL/Iによる防御的プログラミング
後輩からよく聞かれるのは、「どうすれば防げるのか？」という問いです。答えはシンプル。「暗黙の期待を捨てること」に尽きます。
以下のコード例は、ファイル入力時にデータチェックを行う際の標準的なパターンです。
1
/ ファイル入出力とデータ妥当性チェックのサンプル /
EXAMPLE_PROC: PROCEDURE OPTIONS(MAIN);
/ 構造体の定義：実務ではCopybookから展開することが多い /
DCL 1 INPUT_REC,
5 CUST_ID PIC ‘9(5)’,
5 CUST_AMT PIC ‘S9(7)V99’ COMP-3;
/ ONユニットによる例外制御 /
ON CONVERSION BEGIN;
PUT SKIP LIST(‘データ変換エラー発生’);
PUT SKIP LIST(‘不正な値:’, DATAFIELD);
SIGNAL FINISH;
END;
/ 読み込み処理 /
READ FILE(INPUT_FILE) INTO(INPUT_REC);
/ 演算前の防御的確認 /
/ VERIFY関数で数値以外の文字が含まれていないかチェック /
IF VERIFY(INPUT_REC.CUST_ID, ‘0123456789’) ^= 0 THEN DO;
/ ここでエラーログを吐いて処理をスキップさせるのが堅牢 /
PUT SKIP LIST(‘ID形式不正:’, INPUT_REC.CUST_ID);
END;
ELSE DO;
/ 正しいと確信が持ててから演算を行う /
TOTAL_AMT = TOTAL_AMT + CUST_AMT;
END;
END EXAMPLE_PROC;
—
4. ベテランからのアドバイス：ONユニットと「逃げ道」
PL/Iの強力な武器である`ON CONVERSION`ユニットは、S0C7を未然に防ぐための強力なセーフティネットです。しかし、これを乱用してエラーを握りつぶすのは厳禁です。
- ログの重要性: `ON`ユニット内では、必ずエラーが起きたフィールド名と中身をログに出力してください。
- データクレンジング: そもそも入力データが汚いのであれば、プログラムを直す前に、データハンドリングの入り口でチェックするユーティリティを挟むのが、長期的には最も工数を削減します。
まとめ
S0C7は、プログラムが「自分は正しいと思い込んでいるデータ」と「現実のデータ」の間に乖離があることを教えてくれるシグナルです。ダンプ解析を恐れず、レジスタの先にある実データと対話してください。
「なぜ動かないのか」ではなく、「なぜそのデータがそこにあるのか」。この問いかけができるようになったとき、あなたは一人前のメインフレーム・システムアーキテクトに一歩近づいています。
次回のバッチ改修でも、この視点を忘れずに挑んでみてください。健闘を祈ります。
