メインフレーム技術指南：PL/I数値編集の「ゼロ抑制」という深淵
諸君、今日もメインフレームのバッチ処理と格闘しているか？
PL/Iという言語は、COBOLのように「とりあえず書けば動く」というものではない。コンパイラの解釈やデータ型の挙動を深く理解していないと、いざ本番稼働した瞬間に、帳票の数値が化けたり、予期せぬアライメントでレコードレイアウトが崩壊したりする。
今日は、保守現場で意外と「仕様をあやふやにしている」エンジニアが多い、PIC（ピクチャ）句による数値編集、特に`’9’`と`’Z’`の挙動について、現場の知見を交えて叩き込んでおく。
—
1. なぜ今さら数値編集なのか？
「数値なんて内部形式（BINやDEC）で持っていればいいじゃないか」と思うかもしれない。だが、基幹システムの出口は常に人間が読むための帳票や、外部システムへ渡す固定長テキストファイルだ。
ここで`PIC ‘9’`と`’Z’`の使い分けを誤ると、銀行の残高表示が`00000123`のように間抜けな形になったり、逆に桁溢れを起こしてシステム異常（`SOC7`の遠因）を招くことになる。
2. PIC ‘9’ と ‘Z’ の決定的な違い
まずは基本を整理しよう。
- `PIC ‘9’`（数字指定）: その桁に必ず数字を表示する。ゼロであっても容赦なく`0`を出力する。
- `PIC ‘Z’`（先行ゼロ抑制）: その桁がゼロであれば、空白（スペース）に置き換える。ただし、「ゼロでない数字」が出現した以降の桁は、たとえゼロであっても`0`として表示されるという特性がある。
実践コード：数値編集の挙動確認
以下に、実務でよくある数値編集のサンプルを記述する。`PUT EDIT`やレコードへの転記時にこれらを意識しているか確認してくれ。
/i
MAIN_PROC: PROCEDURE OPTIONS(MAIN);
/ 内部データは固定小数点パック十進数 /
DCL W_NUM_ZERO FIXED DEC(7) INIT(0);
DCL W_NUM_SMALL FIXED DEC(7) INIT(123);
DCL W_NUM_LARGE FIXED DEC(7) INIT(1234567);
/ 編集用ピクチャ変数 /
DCL P_9999999 PIC ‘9999999’; / ゼロ埋め強制 /
DCL P_ZZZZZZ9 PIC ‘ZZZZZZ9’; / 先行ゼロ抑制（少なくとも1桁は残る） /
DCL P_ZZZZZZZ PIC ‘ZZZZZZZ’; / 全ゼロなら空白 /
/ ゼロの出力結果 /
P_9999999 = W_NUM_ZERO;
P_ZZZZZZ9 = W_NUM_ZERO;
P_ZZZZZZZ = W_NUM_ZERO;
PUT SKIP LIST(‘— 値が 0 の場合 —‘);
PUT SKIP EDIT(‘PIC 9:’, P_9999999) (A, A); / 出力: 0000000 /
PUT SKIP EDIT(‘PIC Z (末尾9):’, P_ZZZZZZ9) (A, A); / 出力: 0 /
PUT SKIP EDIT(‘PIC Z (全Z):’, P_ZZZZZZZ) (A, A); / 出力: /
/ 値がある場合の出力結果 /
P_9999999 = W_NUM_SMALL;
P_ZZZZZZ9 = W_NUM_SMALL;
PUT SKIP(2) LIST(‘— 値が 123 の場合 —‘);
PUT SKIP EDIT(‘PIC 9:’, P_9999999) (A, A); / 出力: 0000123 /
PUT SKIP EDIT(‘PIC Z:’, P_ZZZZZZ9) (A, A); / 出力: 123 /
END MAIN_PROC;
—
3. 現場でハマる「落とし穴」
その1：VSAMレコードへの直接転記
VSAMのデータセットに書き出す際、レコード定義（Structure）のPIC句を誤ると、本来数値であるべき領域に空白（`X’40’`）が入り込む。後続の処理でその値を`FIXED BIN`等に演算転記しようとすると、コンバージョンエラー（ONCODE 700番台）でプログラムが落ちる。
「出力用変数」と「演算用変数」は明確に分けること。面倒でもこの一手間が、深夜の呼び出しを防ぐ。
その2：ONCODEによる制御
数値編集に関連して、データ型変換でエラーが出た場合は`ONCONVERSION`ユニットを適切に定義しておく必要がある。
/i
ON CONVERSION BEGIN;
PUT SKIP LIST(‘数値変換エラー発生：データを確認せよ’);
/ 必要に応じてログを出してGOTO等でハンドリング /
END;
これを書かないと、システムは即座に異常終了（ABEND）だ。レガシーな環境であればあるほど、エラーの「拾い方」がそのエンジニアの器量を決める。
—
最後に：ベテランからの助言
PL/Iは非常に強力だが、同時に「コンパイラに任せすぎると足元をすくわれる」言語でもある。`PIC`句の`Z`や`9`は、単なる見た目の問題ではない。それは「データがどうあるべきか」という設計思想そのものなんだ。
特に大規模マイグレーションや保守改修では、既存コードの`PIC`定義を安易に変更してはならない。画面レイアウトや帳票フォーマットが1バイトずれるだけで、現場のユーザーから「表示がおかしい」と烈火のごとく怒られるのがメインフレームの世界だ。
もし今、君が担当しているコードで`PIC`句の挙動に確信が持てない箇所があるなら、小さなテストプログラムを組んでダンプを取ることを恐れるな。それが一番の近道だ。
また何か壁にぶつかったら相談してくれ。健闘を祈る。
