PL/Iの「編集」という魔術：PIC ‘9’と’Z’が隠蔽するデータ変換の深淵
メインフレームの現場で長く生きていると、若いJavaエンジニアから「なぜPL/Iの変数はこんなに複雑で、挙動が直感に反するのか」と問われることがある。彼らにとって、データ型とは明快なクラス構造を持つものだが、我々が扱うPL/Iの世界において、変数の型は単なる記憶領域の定義ではなく、コンパイラに対する「期待値の表明」であり、時には「暗黙的な変換のトリガー」に過ぎない。
今日は、その中でも特にバグの温床になりがちで、かつ移行時に最も設計者を悩ませる「編集付きPIC（Picture）句」の内部ロジックについて、腰を据えて語ろうと思う。
—
PIC ‘9’ と ‘Z’ の静かなる戦争：ゼロサプレスとは何か
PL/Iにおいて `DCL A PIC ‘999’;` と `DCL B PIC ‘ZZZ’;` を定義したとき、中身はどちらも文字型（CHARACTER）の衣を纏った数値である。しかし、この二つが数値データから変換される際、内部では全く異なる「編集処理（Edit）」が走る。
/1
DCL NUM FIXED DEC(3) INIT(12);
DCL OUT_9 PIC ‘999’;
DCL OUT_Z PIC ‘ZZZ’;
OUT_9 = NUM; / 結果: ‘012’ – 固定長としての数値表現 /
OUT_Z = NUM; / 結果: ‘ 12’ – 先頭の0をスペースに置換 /
この「Z（ゼロサプレス）」が曲者だ。コンパイラは実行時、数値の左端から順に「有効数字が現れるまではスペースを書き込む」というループを回す。この際、もし変数の長さが足りなければ、左側からデータが削られる（Trancation）わけだが、その挙動は`OPTIMIZE`オプションの設定によって、レジスタ操作の最適化具合が変わり、稀に意図せぬアベンドを引き起こすことがある。
移行の落とし穴：パックデシマル符号と文字変換の不整合
JavaやC#へ移行する際、最も恐ろしいのは「PIC句による自動変換が、暗黙のうちにパックデシマル（COMP-3）の符号を評価している」という事実だ。
例えば、`PIC ‘999’` に対して負の値を放り込んだ場合、PL/Iコンパイラは符号を無視して絶対値で埋めようと試みるが、DB2の埋め込みSQLでこの変数をそのまま渡すと、DB2側で「Invalid Data」としてSQLCODE -802（例外発生）を吐く。
特にCICSオンライン処理で、画面上の入力値を `PICTURE` 定義した変数に転送する際、パックデシマルの内部符号（通常、末尾のニブルが `C` なら正、`D` なら負）が想定外のビットパターンを持つと、コンパイラが生成した編集コードが暴走し、S0C7アベンドを誘発する。これを防ぐには、変換前に `CHECK` 条件による値の妥当性検証が不可欠だ。
実践的な防衛術：ポインタと基底変数による「メモリ直叩き」の回避
レガシーなコードベースでは、`BASED` 変数と `ADDR()` 関数を用いて、メモリの生データを強引に数値として読み解く手法が散見される。
/1
DCL RAW_DATA CHAR(4) BASED(P);
DCL NUM_VAL FIXED BIN(31) BASED(P);
/
- 注意: この手法はポインタPのアライメントに依存する。
- 境界整列（Alignment）を無視したアクセスは、性能劣化だけでなく
- 特定のメインフレームモデルでハードウェア例外を招く。
/
P = ADDR(STORAGE_AREA);
IF NUM_VAL < 0 THEN DO;
/ ここで符号反転の補正ロジックを噛ませる /
END;
現代的な移行プロジェクトにおいて、このような動的メモリ操作は「技術的負債の塊」だ。移行先がJavaであれば、`ByteBuffer` を駆使してビット演算で符号を再構築する必要があるが、PL/Iのコンパイラが裏でやっていた「文字データから数値への自動変換時に符号を判断する」という一連の処理を、完全に再現しなければならない。
結論：レガシーの神は「詳細」に宿る
システムアーキテクトとして言いたいのは、`PIC ‘Z’` 一つとっても、それが単なる表示上の装飾ではないということだ。それは、過去40年の基幹システムが積み上げてきた「データ整合性の作法」そのものなのだ。
- コンパイラ最適化の影響: `OPTIMIZE` を高めると、境界チェックが省略されることが多い。移行前には必ず `TEST` オプションでアベンド箇所を特定し、ロジックの脆さを洗い出しておくこと。
- ダンプ解析の極意: S0C7が発生した際、ダンプリストの `PSW`（プログラムステータスワード）だけでなく、変数の `STORAGE` ダンプを16進数で追え。`PIC ‘Z’` の左側に、意図しない `0x00` や `0x40`（スペース）がどのように配置されているかを見れば、バグの原因は一目瞭然だ。
PL/Iのコードを読み解くことは、コンピュータの歴史を読み解くことに等しい。表面的な文法ではなく、コンパイラが生成する「命令の連鎖」をイメージできるレベルまで解像度を高めてほしい。それが、レガシー移行を成功させる唯一の道だ。
