汎用機の深淵：PL/IにおけるCONVERSION条件と「見えない不正データ」との対峙
IBMメインフレームという極限環境において、PL/Iは単なるプログラミング言語ではない。それは、CPUサイクルを極限まで削り出し、データの整合性を物理的に保証するための「規律」そのものだ。
長年メインフレームの保守やマイグレーションに携わっていると、システムを崩壊させる犯人の多くは、外部インターフェースから紛れ込んだ「たった一箇所の不正な文字データ」であることを痛感させられる。特に、数値型への暗黙的な型変換に失敗した瞬間に発生する`CONVERSION`条件は、単なるエラーハンドリングの対象を超え、システムの信頼性を問う試金石となる。
今日は、この「CONVERSION」をいかに制御し、その裏側に隠れた動的なデータ構造とメモリ上のバグを炙り出すか、アーキテクトの視点から紐解いていきたい。
—
1. CONVERSION条件：その予期せぬアベンドを「制御」する
PL/Iの強力な型変換機能は、時に諸刃の剣となる。パックデシマル（FIXED DECIMAL）への代入時に、内部に数字以外のASCII/EBCDIC文字が混入していた場合、コンパイラが生成したコードは容赦なく`SOC7`（データ例外）をスローする。
これを防ぐための基本は、`ON CONVERSION`ブロックの活用だ。しかし、ただログを吐くだけでは不十分である。
/i
/ 不正データ検知の定石：ON-UNITによる捕捉 /
ON CONVERSION BEGIN;
/ 問題の発生箇所を特定するためのダンプや変数追跡 /
PUT SKIP LIST (‘ERROR: 非数値データが検出されました’);
PUT SKIP LIST (‘OFFSET: ‘, ONCHAR, ONSOURCE);
/
- ここでフラグを立てて処理をスキップするか、
- あるいはデフォルト値に置換して処理を継続させるか。
- ただし、安易な継続はデータ汚染を招くため慎重に行うこと。
/
GOTO RECOVERY_ROUTINE;
END;
ここで重要なのは、`ONSOURCE`擬似変数だ。何が原因で変換に失敗したのか、その「罪深き値」を動的に取得できるこの機能を使いこなせているかが、デバッグの質を分かつ。
—
2. 動的メモリとポインタ：見えないバグを追う
基幹システムの複雑なバッチ処理では、`BASED`変数とポインタを駆使してメモリを直接操作することがある。特に、CICSのCOMMAREA経由や、DB2のホスト変数として定義されていない領域を読み込む際、ポインタが指し示す先が予期せぬデータ構造体であることは珍しくない。
もし、ある領域を`FIXED BINARY`として読み込もうとして失敗した場合、それは単なるデータ型不一致ではなく、メモリアライメントや構造体のマッピングミスである可能性が高い。
/i
DCL BUFFER_PTR PTR;
DCL MY_STRUCT BASED(BUFFER_PTR) CHAR(100);
/ 不正データ混入の温床：構造体のオフセットズレ /
DCL 1 DATA_MAP BASED(BUFFER_PTR),
2 FIELD_A FIXED DEC(5,0),
2 FIELD_B CHAR(10);
/ POINTERによる動的制御：意図しないバイト列を強引にアクセスする際の注意点 /
/ 構造体のサイズと実際の受信バッファサイズが合致しているか確認せよ /
特に、マイグレーション先がJava等のオブジェクト指向言語である場合、この「ポインタによる強引な型変換」は最大の難所となる。Javaには存在しない「メモリレイアウトの厳密な定義」が、PL/Iの強みであり、同時に移行の際の爆弾となるのだ。
—
3. パックデシマルの符号反転：現場で陥る罠
IBMのハードウェアにおけるパックデシマルは、末尾のニブル（4ビット）が符号を表す。`0xC`は正、`0xD`は負だが、もしデータ転送の過程でこの符号が`0xF`（符号なし＝不正）になったり、あるいは他の文字コードで上書きされた場合、算術演算の瞬間に`CONVERSION`、あるいは`SOC7`が発生する。
私が過去に遭遇したトラブルでは、DB2からのフェッチ時に、ある特定の列がNULL値を許容していないにもかかわらず、バグにより不正なビットパターンが格納されていたケースがあった。
- 対策: DB2の`INDICATOR VARIABLE`を必ず使用すること。
- ダンプ解析: アベンドが発生した際のダンプを見て、当該変数がどのようなビット構成になっているか、Hexダンプで確認する癖をつけること。`DUMP`オプション付きのコンパイル結果は、メインフレームエンジニアにとっての「地図」である。
—
4. アーキテクトとしてのアドバイス
JavaやC#への移行を検討しているチームに対して、私はいつもこう言う。
「PL/Iの堅牢性は、コンパイラによる静的な型チェックと、ON-UNITによる動的な例外制御のハイブリッドによって成り立っている」と。
マイグレーション先にこの「PL/I的な厳密さ」を移植しなければ、システムは形を変えても、同様のデータ異常によって崩壊する。
1. コンパイラオプションの見直し: `CHECK(SUBSCR, SIZE)`を開発環境で常に有効にし、本番環境でも極力パフォーマンスを犠牲にしてでも有効にすることを検討せよ。
2. ストラクチャード・プログラミングの徹底: `GOTO`による制御フローを最小化し、`ON-UNIT`を適切に配置することで、例外パスを明確にすること。
3. データバリデーションの外部化: PL/Iに依存する前に、インターフェース層で正規表現やスキーマチェックを行い、不正データを「入り口」で遮断する設計が、結果として最も工数を削減する。
PL/Iのコードは、時代遅れではない。それは、データの海で溺れないための、最も洗練された「防波堤」なのだ。次回のデバッグ時には、ぜひ`ON CONVERSION`の向こう側に広がる広大なメインフレームの宇宙を覗いてみてほしい。
