現場の知恵：PICTURE句による数値編集の「作法」とゼロサプレスの落とし穴
メインフレームのバッチ改修において、帳票出力やファイル連携のデータ変換は避けて通れない道です。特にPL/Iの`PICTURE`属性による数値編集は、COBOLの`PICTURE`句と似て非なる部分が多く、ここを理解せずに適当にコーディングすると、後々「数値が消えた」「桁がずれた」といった夜間バッチの障害に直結します。
今日は、ベテランなら誰もが一度は通る「`9`と`Z`の使い分け」と、その裏側にあるデータ変換の作法について、現場の視点から紐解いていきましょう。
—
1. PICTURE属性の基本：`9`と`Z`の役割を整理する
数値データを文字列として出力するための`PICTURE`属性。この指定一つで、数値の内部表現（パック10進数や2進数）が、人間が読みやすい「編集形式」へと変換されます。
- `9` (Digit)： 数値をそのまま表示します。0であれば’0’が出力されます。
- `Z` (Zero-suppress)： 数値の先行ゼロを空白（スペース）に置き換えます。
現場でよく見るのは、金額フィールドのゼロサプレスですね。`PIC ‘999999’`だと`000123`と出力される場所を、`PIC ‘ZZZZZ9’`と指定することで、` 123`と綺麗に整形できるわけです。
ここで注意すべきは、`Z`は必ず左から順に評価されるという点です。途中に`9`を挟むと、そこから先はゼロサプレスが解除される仕様になっています。この「桁の制御」を甘く見ると、帳票の列が綺麗に揃わず、ユーザーからのクレーム案件に繋がります。
—
2. 実践コード：VSAM読み込みから編集出力まで
実際にバッチプログラムでよく使われる、VSAMから読み取った数値を編集して出力するロジックを見てみましょう。
/i
/——————————————————————–/
/ サンプル: VSAMレコードの金額項目をゼロサプレスして出力する例 /
/——————————————————————–/
CONVERT_PROC: PROCEDURE OPTIONS(MAIN);
/ VSAM入力データ定義 (内部数値形式) /
DCL 1 INPUT_REC,
5 CUST_ID CHAR(5),
5 TRAN_AMOUNT FIXED DEC(9, 0);
/ 編集後の出力バッファ /
DCL 1 OUTPUT_REC,
5 O_CUST_ID CHAR(5),
5 O_AMOUNT_ED PICTURE ‘ZZZ,ZZZ,ZZ9’; / 3桁カンマ編集とゼロサプレス /
/ 異常系制御用ONユニット /
ON ENDFILE(SYSIN) BEGIN;
PUT SKIP LIST(‘ END OF FILE ‘);
END;
/ 処理開始 /
GET FILE(SYSIN) INTO(INPUT_REC);
/
- ここがポイント：
- 内部数値形式(FIXED DEC)からPICTURE属性への代入は
- PL/Iコンパイラが自動的に編集処理を行う。
- 複雑な変換関数を使わずとも、宣言時にPICTUREを定義するだけでいい。
/
O_CUST_ID = CUST_ID;
O_AMOUNT_ED = TRAN_AMOUNT;
PUT SKIP EDIT(O_CUST_ID, O_AMOUNT_ED) (A, A);
END CONVERT_PROC;
—
3. 実務で知っておくべき「落とし穴」
現場の保守作業で私が後輩によく注意するのは、以下の2点です。
① ON CONVERSION ユニットの存在
もし、数値データが壊れていたり、非数値文字が入っている状態で`PICTURE`属性の変数に代入しようとすると、プログラムは`CONVERSION`条件を発生させて異常終了します。
バッチが突然死するのを防ぐため、重要なデータ変換を行う際は必ず`ON CONVERSION`ユニットを定義し、エラー時のログ出力を実装しておくのが「メインフレームエンジニアの嗜み」です。
② Zと9の混在による桁位置のズレ
`PIC ‘ZZZ9’`と`PIC ‘9999’`を比較した際、後者は必ず4文字を埋めますが、前者は数値が0の場合、全てスペースになります。
特に固定長ファイル（FB）への出力時にこの仕様を失念すると、後続のプログラムで「カラム位置の読み込みミス」が発生し、帳票が崩壊します。ファイル定義（Copybook）との整合性は、修正前に必ず確認してください。
—
最後に：効率的な改修のために
PL/Iは柔軟な言語ですが、その分、プログラマの意図が明確にコードに現れます。`PICTURE`句を「ただの見た目の指定」と捉えるのではなく、「データがどう変換され、どの型にキャストされるか」を意識してください。
もし現場で「値が消えた！」と焦る事態になったら、まずはデバッガでその変数のPICTURE属性と、代入元のデータ型を再確認すること。案外、`PIC`指定の桁数が足りておらず、オーバーフローして値が切り捨てられている、なんてことはよくある話です。
地味な機能かもしれませんが、こういった基本を徹底して積み重ねることが、安定した基幹システムを維持する唯一の道だと私は信じています。また何かあれば、いつでも相談してください。
