おい、最近配属された若手が「画面や帳票に出力した数値の頭に余計なゼロが残るんです」って泣きついてきたんだよ。聞いてみれば、COBOLから流れてきた連中にありがちな勘違いや、PL/I特有のピクチャ仕様の罠に綺麗にハマっていた。
メインフレームの基幹システムを支える上で、金額や数量の数値編集（エディット）は避けて通れない基本中の基本だ。だが、「なんとなく動くから」と `PIC ‘99999’` や `PIC ‘ZZZZZ’` を適当に使っていると、オンライン画面のレイアウトが崩れたり、監査証跡の帳票で数字がズレたりして、夜間バッチの真っ最中に運用担当者から血の気の引くような内線が飛んでくることになる。
今回は、PL/Iにおける `PIC ‘9’` と `PIC ‘Z’` の本質的な差異、そしてレガシーシステムの現場で絶対に知っておくべきゼロサプレスの内部挙動について、実務で使えるコードを交えながら徹底的に叩き込んでやろう。
—
1. 予約語を持たないPL/Iと「文脈」の魔力
まず前提として、PL/IにはCOBOLのような厳格な「予約語（Reserved Words）」という概念が基本的に存在しない。`IF` や `READ` でさえ、コンテキスト（文脈）によってただの変数名として定義できてしまう自由度の高い言語だ。
だからこそ、データ定義におけるピクチャ句（PICTURE）の解釈は、コンパイラがソースコードの文脈を厳密に読み解いて処理している。この自由度の裏側で、数値編集文字の指定を一つ間違えると、コンパイルエラーにはならず、意図しないゴミデータを本番のVSAMファイルやシーケンシャルデータセット（QSAM）に書き込んでしまうという、最もタチの悪いサイレントエラーを引き起こす。
数値編集の基本を改めて整理しておこう。
—
2. `PIC ‘9’` と `PIC ‘Z’` の決定的な違い
数値データを文字として出力（編集）する際、最もよく使われるのが桁位置を指定する `9` と `Z` だ。それぞれの役割は明確に分かれている。
- `PIC ‘9’`（数字位置指定文字）:
- 対応する数値の桁にデータが存在すればその数字を表示し、値がゼロであってもそのまま ‘0’ を表示（保持）する。
- 先行ゼロ（Leading Zeros）を落としたくない固定長のコード類や、桁数が厳格に決まっている項目で使用する。
- `PIC ‘Z’`（ゼロサプレス文字）:
- 対応する数値がゼロ（かつそれより上位の桁もゼロ）の場合、その位置のゼロを空白（Space）に置換（ゼロサプレス）する。
- 金額や数量など、人間が視覚的に読みやすくするために「000123円」ではなく「 123円」と表示させたい場合に用いる。
現場でやりがちな「先行ゼロの罠」
例えば、内部形式が `FIXED BINARY` や `FIXED DECIMAL (5,0)` の変数に `00045` という値が入っているとする。これをそれぞれ以下のように定義した変数に代入して出力するとどうなるか。
DCL W-NUM-S FIXED DECIMAL(5) INIT(45);
DCL W-EDT-9 PIC ‘99999’ INIT((5)’ ‘);
DCL W-EDT-Z PIC ‘ZZZZZ’ INIT((5)’ ‘);
W-EDT-9 = W-NUM-S; // 結果: ‘00045’
W-EDT-Z = W-NUM-S; // 結果: ‘ 45’
この挙動の違い自体は基本だが、実務で問題になるのは「負数の場合」や「小数点以下の扱い」、そして「完全なゼロ（Zero Value）が入ってきたときの挙動」だ。
—
3. レコード入出力とVSAM/QSMアクセスにおける実務上の注意点
夜間バッチで動く帳票生成プログラムや、CICS画面へ渡すマップデータを構築する際、レコードレイアウト（コピーブックに相当する `%INCLUDE` メンバ）の定義ミスは致命傷になる。
特にVSAM（KSDSなど）から取得した数値データを画面やプリンタ出力用ワークにムーブする際、編集文字の定義を誤ると、意図しないブランクパディングやデータ落ちが発生する。
次の実用的なPL/Iサンプルコードを見てほしい。大文字ベースで記述し、現場の標準的なコーディングスタイルに合わせたものだ。
実践コード例：数値編集とゼロサプレスの挙動確認バッチ
/================================================================/
/ ﾌﾟﾛｸﾞﾗﾑID : EDTTST01 /
/ ﾃｰﾏ : PIC ‘9’と’Z’による数値編集とｾﾛｻﾌﾟﾚｽの検証 /
/================================================================/
EDTTST01: PROC OPTIONS(MAIN);
/ — 内部数値データ（演算用） — /
DCL 1 IN-DATA,
3 IN-AMT-ZERO FIXED DEC(7,0) INIT(0), / 完全ゼロ /
3 IN-AMT-SMALL FIXED DEC(7,0) INIT(125), / 小額データ /
3 IN-AMT-LARGE FIXED DEC(7,0) INIT(1234567);/ 高額データ /
/ — 編集済みデータ（出力用） — /
DCL 1 OUT-EDIT-AREA,
/ PIC ‘9’による編集（ゼロが残る） /
3 OUT-S9-ZERO PIC ‘9999999’,
3 OUT-S9-SMALL PIC ‘9999999’,
/ PIC ‘Z’によるゼロサプレス編集 /
3 OUT-SZ-ZERO PIC ‘ZZZZZZ9’, / 1桁は9を残すのが帳票の基本 /
3 OUT-SZ-SMALL PIC ‘ZZZZZZZ’, / 全てZにすると完全ゼロが全白ぬけになる /
3 OUT-SZ-LARGE PIC ‘ZZZZZZZ’;
/ — 処理開始 — /
PUT SKIP LIST(‘ ﾋﾟｸﾁｬ編集 ﾃｽﾄ開始 ‘);
/ 1. 編集処理の実行（代入による暗黙的編集） /
OUT-S9-ZERO = IN-AMT-ZERO;
OUT-S9-SMALL = IN-AMT-SMALL;
OUT-SZ-ZERO = IN-AMT-ZERO;
OUT-SZ-SMALL = IN-AMT-SMALL;
OUT-SZ-LARGE = IN-AMT-LARGE;
/ 2. 結果の出力（PUT LISTによる確認） /
PUT SKIP LIST(‘— PIC ”9” ｼﾘｰｽﾞ —‘);
PUT SKIP EDIT(‘ZERO (S9): [‘, OUT-S9-ZERO, ‘]’) (A, A, A);
PUT SKIP EDIT(‘SMALL (S9): [‘, OUT-S9-SMALL, ‘]’) (A, A, A);
PUT SKIP LIST(‘— PIC ”Z” ｼﾘｰｽﾞ —‘);
PUT SKIP EDIT(‘ZERO (SZ): [‘, OUT-SZ-ZERO, ‘]’) (A, A, A);
PUT SKIP EDIT(‘SMALL (SZ): [‘, OUT-SZ-SMALL, ‘]’) (A, A, A);
PUT SKIP EDIT(‘LARGE (SZ): [‘, OUT-SZ-LARGE, ‘]’) (A, A, A);
/ 3. 応用：BUILTIN関数を使った文字列操作の例 /
/ 編集後の項目から前置空白をトリムしてログ出力する場合の常套手段 /
PUT SKIP LIST(‘— ﾄﾘﾑ処理の活用 —‘);
PUT SKIP EDIT(‘TRIMMED SMALL: [‘, TRIM(OUT-SZ-SMALL, LEFT), ‘]’) (A, A, A);
PUT SKIP LIST(‘ ﾋﾟｸﾁｬ編集 ﾃｽﾄ終了 ‘);
END EDTTST01;
—
4. このコードから読み解くべき「現場の知見」
上記のコードをコンパイル・実行したとき、ベテランエンジニアならニヤリとするポイント、あるいは過去に障害を踏み抜いたからこそ分かる注意点がいくつかある。
① 完全ゼロ（`IN-AMT-ZERO`）を全て `PIC ‘Z’` にするとどうなるか？
コード内の `OUT-SZ-ZERO` は `PIC ‘ZZZZZZ9’` と、一の位にあえて `9` を残している。
もしこれをすべて `PIC ‘ZZZZZZZ’` にしてしまうと、値が `0` のとき、出力フィールドの全7桁が完全にスペース（空白）で埋まってしまう。
帳票のデザイン仕様書で「金額がゼロのときは ‘0’ を表示するのか、あるいはブランクにするのか」は極めて重要な仕様だ。「金額欄が完全に空白になっていて、データが抜けているのかゼロ円なのか分からない」というクレームをユーザーから受けたことがあるなら、この `9` の重要性が痛いほど分かるはずだ。
② 内部データとの型不一致によるパフォーマンス劣化
PL/Iでは、異なるデータ型の間での代入（例えば `FIXED DECIMAL` から `PICTURE` へのムーブ）はコンパイラが自動的にコードを生成してくれる。しかし、これが大規模な数百万件のVSAMバルク処理やQISAMのループ内で行われると、暗黙のコンバージョン（型変換）がCPUサイクルの無駄な消費（オーバーヘッド）につながる。
パフォーマンスチューニングの現場では、編集が必要な最終出力フェーズまで内部の数値型（`FIXED BINARY` や `FIXED DECIMAL`）を維持し、I/O直前のバッファリング層で一気にピクチャ項目へトランスファーするのが鉄則だ。
—
5. トラブルシューティングの現場から：ONユニットによる例外監視
もし、異常系データ（例えば、パックスペースにゴミが入っていたり、定義外の文字が混入していたりする不正データ）が原因で編集時にコンバージョンエラーが発生した場合、プログラムはそのまま異常終了（ABEND、IBMメインフレームなら `S0C7` などのデータ例外）を引き起こす。
これを安全に捕捉するために、PL/Iには強力な ONユニット（ON-conditions） が用意されている。数値編集時のオーバーフローや変換エラーに備えるには、以下のような例外処理をメインルーチンの手前に仕込んでおくのがプロのアーキテクトのやり方だ。
/ ﾃﾞｰﾀ変換ｴﾗｰ（CONVERSION）の捕捉 /
ON CONVERSION BEGIN;
PUT SKIP LIST(‘ 警告: 数値編集時にｺﾝﾊﾞｰｼﾞｮﾝｴﾗｰが発生しました ‘);
/ 不正データを強制的にゼロとみなして続行する場合の処理を記述 /
GOTO ERROR_RECOVERY_POINT;
END;
レガシーシステムの保守において、予期せぬデータパッチや電文の揺れに直面することは日常茶飯事だ。`PIC ‘9’` と `PIC ‘Z’` の挙動を正確に理解し、ゼロサプレスのメカニズムをコードレベルでコントロールできるようになっておけば、どんな古いメインフレームの改修案件が来ようとも、背中を預けられる信頼性の高いシステムを作り上げることができる。
さあ、理理整然とした美しいコードで、次のデプロイも完璧に乗り切ろうぜ。
