メインフレームの現場から：PL/I数値編集（PIC ‘9’と’Z’）の「罠」を読み解く
諸君、お疲れ様。今日もどこかのバッチジョブがABENDしていないことを祈るよ。
さて、今回はPL/Iの数値編集、特に`PICTURE`句を使ったデータ変換について語ろう。特に基幹システムの帳票出力やVSAMへの書き出しにおいて、この「ゼロ抑制（Z）」と「数値埋め込み（9）」の挙動を甘く見ていると、深夜の呼び出しを食らう羽目になる。
若手から「出力したファイルの結果が期待と違う」と相談を受けるたびに思うのだが、この仕様はただの「見た目の整形」と侮ってはいけない。PL/Iのコンパイラがどのようにメモリ上のバイナリ値を解釈し、文字ストリームへ変換しているか。その裏側にある「暗黙の規約」を叩き込んでおこう。
—
1. PIC ‘9’ と ‘Z’ の決定的な違い
まずは基本の復習だが、現場ではここが曖昧なまま書かれているコードが散見される。
- `PIC ‘9’` (数値埋め込み): 指定した桁数を強制的に数字で埋める。ゼロであれば’0’として出力される。
- `PIC ‘Z’` (ゼロ抑制): 数値がゼロの場合、あるいは先行するゼロをスペース（空白）に置き換える。
最も重要なのは、「Zはあくまで先行するゼロをスペースに変えるだけ」という点だ。全ての桁がゼロの場合、`PIC ‘ZZZ’`と指定すれば出力は全角スペースではなく、3桁の空白になる。これが帳票のレイアウト崩れを引き起こす典型的な原因だ。
—
2. 実践的コード：数値編集の挙動を確認する
VSAMから読み込んだ数値を、外部ファイル（または帳票出力用データ）へ渡す際の典型的なコード例だ。`ON FIXEDOVERFLOW` を適切に配置するのも忘れずに。
1
TEST_EDIT: PROCEDURE OPTIONS(MAIN);
/ VSAM等から読み込む固定小数点数 /
DCL RAW_VALUE FIXED BIN(15) INIT(0);
/ 編集用変数：9はゼロを表示、Zはゼロを抑制 /
DCL ED_NINE CHAR(5) PIC ‘99999’;
DCL ED_ZERO CHAR(5) PIC ‘ZZZZ9’; / 最後の9は0を表示させるための定石 /
/ 例外処理のフック /
ON FIXEDOVERFLOW BEGIN;
PUT SKIP LIST(‘警告: 桁あふれが発生しました。データを確認してください。’);
END;
RAW_VALUE = 0;
ED_NINE = RAW_VALUE;
ED_ZERO = RAW_VALUE;
/ 結果の確認 /
/ ED_NINE は ‘00000’ となる /
/ ED_ZERO は ‘ 0’ となる (末尾の9でゼロを保護) /
PUT SKIP LIST(‘NINE:’ || ED_NINE);
PUT SKIP LIST(‘ZERO:’ || ED_ZERO);
END TEST_EDIT;
—
3. 現場で嵌まる「桁あふれ」と例外処理
PL/Iの最も恐ろしいところは、`PIC`句で指定した桁数を超えた数値を代入したときだ。
例えば `DCL VAL PIC ‘999’` に対して `1234` を代入しようとすれば、上位桁は切り捨てられ、最悪の場合、プログラムの制御フローが予期せぬ方向へ向かう。
ここがプロの勘所
1. ONユニットの活用: `ON FIXEDOVERFLOW` や `ON CONVERSION` は、ただのデバッグ用ではない。本番環境で予期せぬデータが流れてきた際の「最後の砦」だ。ここでダンプを出力するか、エラーログをVSAMのログファイルに書き出す処理を仕込んでおかないと、原因特定に数日を費やすことになる。
2. サブルーチン化: 数値編集が頻発するシステムであれば、編集ロジックを共通モジュール（PROCEDURE）に切り出せ。インラインで毎回`PUT EDIT`や代入を書くのは、保守性を著しく下げる。
3. BUILTIN関数の活用: `TRIM`や`SUBSTR`を組み合わせるよりも、`PIC`句を適切に定義して代入する方が、PL/Iのコンパイラは最も効率的なマシンコードを生成する。最適化レベルを上げたいなら、型変換のオーバーヘッドを意識した設計を心がけるべきだ。
—
最後に：なぜ今さらPL/Iなのか
最近のモダンな言語に慣れたエンジニアは、「なぜこれほど厳格に桁数を管理するのか」と疑問に思うかもしれない。だが、メインフレームのデータは数十年積み重ねられた資産だ。1バイトのズレが、後続の複雑なバッチ処理すべてを汚染する。
`PIC ‘Z’` を使うときは、「もし値がゼロなら、どう表示されるのが業務的に正しいか？」を常に考えること。そして、`PIC ‘9’` を使うときは、「本当にその桁数で収まるのか？」という疑念を常に持つこと。
この「疑い深さ」こそが、システムアーキテクトとしての最初の資質だ。
さて、次の改修作業に戻るとしようか。また何か詰まったら、いつでも聞きに来るといい。
