メインフレームの美学：PL/Iピクチャ編集とゼロサプレスの深淵
ようこそ、メインフレーム開発の最前線へ。
保守開発の現場で、「なぜか帳票の数値が意図しない表示になる」「本番でデータ例外（S0C7）が起きた」というトラブルに頭を抱えたことはないだろうか？
特にPL/Iのピクチャ編集（PIC）は、一見するとCOBOLの編集ピクチャと似ているが、その背後にあるメモリ上のデータ表現とコンパイラの挙動は、驚くほどシビアで奥深い。今回は、レガシーシステムの屋台骨を支えるエンジニア諸君へ、PIC ‘9’ と ‘Z’ を使いこなすための勘所を授けよう。
—
1. PIC ‘9’ と ‘Z’ の決定的な違い
数値データの編集において、最も頻繁に遭遇するのがゼロサプレス（先行ゼロの非表示）だ。
- `PIC ‘9’`: 指定桁数分、数値をそのまま表示する。ゼロであれば当然 ‘0’ が出力される。
- `PIC ‘Z’`: 指定桁数分、数値を表示するが、その値が「ゼロ」であればスペースに置換する。
ここまでは教科書通りだが、実務でハマるポイントは「桁数」と「編集文字」が混在した時の挙動だ。例えば `PIC ‘ZZZ9’` と定義した場合、値が `0` であれば `0` と表示されるが、値が `10` であれば ` 10` となる。この「Z」はあくまで先行するゼロをスペースに変換するトリガーであり、最後を ‘9’ にすることで、値がゼロの場合でも最低1桁は残すという「帳票の作法」を強制できる。
—
2. 実践：VSAM入出力とピクチャ編集の実装例
バッチ処理でよくある「VSAMから読み込んだ数値を編集して帳票に出力する」というシナリオで、安全な実装コードを示そう。特に `ON CONVERSION` ユニットで例外を捕捉するテクニックは、本番障害を未然に防ぐ生命線だ。
/i
/ — サンプルプログラム: 数値編集とデータ例外のハンドリング — /
TEST_EDIT: PROCEDURE OPTIONS(MAIN);
DCL WS_RAW_DATA CHAR(5) INIT(‘00010’); / VSAMから読んだ未編集データ /
DCL WS_EDIT_OUT PIC ‘ZZZ9’; / ゼロサプレス用編集ピクチャ /
DCL WS_NUMERIC FIXED DEC(5,0); / 計算用データ /
/ コンバージョンエラー（数値不正）発生時の制御 /
ON CONVERSION BEGIN;
PUT SKIP LIST(‘警告: 数値変換エラーが発生しました。データをスキップします。’);
GO TO NEXT_RECORD;
END;
/ 1. 文字列から数値へ変換 /
WS_NUMERIC = WS_RAW_DATA;
/ 2. ピクチャ変数への代入による編集 /
WS_EDIT_OUT = WS_NUMERIC;
/ 3. 出力確認 /
PUT SKIP EDIT (‘編集結果:’, WS_EDIT_OUT) (A, A);
NEXT_RECORD:;
/ 次のレコード処理へ /
END TEST_EDIT;
—
3. なぜ「データ例外（S0C7）」は起きるのか？
現場で最も恐れられるS0C7（データ例外）。PL/Iにおいて、これがピクチャ編集絡みで発生する場合、原因は決まって「ピクチャ変数に数値として解釈できないデータが混入した時」だ。
例えば、`PIC ‘999’` として宣言した変数に、誤ってスペースやA～Fの文字（パック10進数以外のデータ）が入った状態で計算や代入を行うと、コンパイラは即座にプログラムを中断させる。
トラブルシューティングの鉄則：
1. 入力インターフェースを疑え: VSAMファイルやフラットファイルの定義体（コピーブック）が最新か確認すること。特に、外部システムから受け取ったデータに「スペース埋め」のゴミが入っていることは珍しくない。
2. `VALID` ビルトイン関数の活用: 疑わしいデータに対しては、`IF VALID(変数名) THEN …` を使い、代入前にチェックを行う癖をつけること。
3. `ON CONVERSION` を過信しない: 上記コードのようにエラーを捕捉して `GO TO` で抜けるのは緊急避難的措置だ。根本解決は、データ発生源でのバリデーション（入力チェック）にある。
—
4. ベテランからのアドバイス：保守の現場で生き残るために
PL/Iのコードを読む際、`PIC` 文定義を見るだけで、そのプログラマが「帳票の美しさ」を意識しているか、「データの整合性」を意識しているかが手に取るように分かる。
もし、貴君が担当する既存コードで、ゼロサプレスをプログラム内の `IF` 文でガチガチに制御している箇所を見つけたら、それはリファクタリングのチャンスだ。`PIC ‘Z’` を活用した定義へ書き換えるだけで、ソースコードの行数は劇的に減り、可読性は向上する。
だが忘れないでほしい。メインフレームの真の強さは、その「古臭い」と揶揄される厳格なデータ型定義にある。この厳しさを味方につけた時、貴君は単なるコーダーから、安定した基幹システムを支える真のシステムアーキテクトへと進化するはずだ。
明日からのバッチ改修、ピクチャ定義の1文字1文字に、魂を込めて修正してほしい。健闘を祈る。
