符号（S）という名の魔物：PL/I PICTURE編集文字と内部表現の深淵
メインフレームの現場で「なぜかDB2の数値項目と突き合わせが合わない」「オンラインで突如としてデータ例外（S0C7）が発生する」というトラブルに直面したとき、多くのエンジニアはまずEXEC SQLの型変換を疑う。だが、その根源的な原因は、PL/Iの`PICTURE`句における符号`S`の扱いと、その裏側に隠れた内部表現の変換ルールを読み違えていることにあることが多い。
今日は、PL/Iという言語の「予約語を持たない」という自由奔放な仕様が、いかにして現代のマイグレーションプロジェクトに牙を剥くか、その深層を紐解いていこう。
—
PICTURE ‘S’ の本質：単なる表示用フォーマットではない
PL/Iにおいて`DCL VAR PIC ‘S9(7)V99’`と宣言したとき、これは単なるエディタ上の表示形式を定義しているのではない。コンパイラに対し、「この変数は符号付きパック十進数（COMP-3）としてメモリ上に展開せよ」という強烈な指示を送っているのだ。
1
/ 符号付きパック十進数としての定義 /
DCL WORK_AMT PIC ‘S9(7)V99’ COMP-3;
/ コンパイラはこの定義を見て、符号部を最下位ニブルに配置する /
ここで重要なのは、`S`を省略した場合の挙動だ。もし`PIC ‘9(7)V99’`と書けば、コンパイラは符号なしとして扱い、負の値を代入しようものなら、その瞬間にハードウェア例外が待ち構えている。
ゾーン十進数からパック十進数への「変換ルール」と罠
現場で最も恐ろしいのは、外部ファイル（EBCDIC）から取り込んだゾーン十進数（DISPLAY形式）を、内部でパック十進数に変換する際に発生する「符号の解釈」だ。
- ゾーン十進数: 1バイトごとに16進数のゾーン部と数値部を持つ。
- パック十進数: 2桁を1バイトに詰め込み、末尾のニブルに符号（C=正, D=負, F=符号なし）を格納する。
JavaやC#へ移行する際、この「D」という符号（負）を正しくハンドリングできていないシステムは山ほどある。PL/Iのコンパイラは、最適化オプション（`OPTIMIZE(3)`など）を効かせると、算術演算の効率化のために符号の展開を極限まで省略する。このとき、ダンプ上で`0C`や`0D`が予期せぬ位置に出現し、解析を阻害するのだ。
—
ABEND（S0C7）の真犯人を特定する
`DATA EXCEPTION`、いわゆる`S0C7`が発生したとき、ダンプリストを眺めて溜息をつく前に、まずは以下の点を確認せよ。
1. ベース変数とポインタによる不正アクセス:
`BASED`変数を使用して構造体をマッピングしている場合、ポインタが指し示す先が物理的にずれているのではないか。特に`ALIGN`属性の有無により、コンパイラが自動挿入するパディングバイトが、構造体全体のオフセットを狂わせることがある。
2. パックデシマルの内部符号反転:
外部システムが送信してきたデータに、正規の`D`（負）ではなく、独自拡張された符号が含まれている場合、PL/Iの算術命令は即座に停止する。
1
/ ポインタを用いた動的メモリ操作の例 /
DCL PTR_DATA PTR;
DCL 1 STRUCT_MAP BASED(PTR_DATA),
2 AMT_VAL PIC ‘S9(7)V99’ COMP-3;
/ アドレス計算が1バイトでもズレれば、S0C7は免れない /
IF PTR_DATA -> AMT_VAL < 0 THEN
/ ここでデバッグ用の処理を挟むのが定石 /
PUT SKIP LIST('負の値が検出されました');
---
マイグレーション設計における「鉄則」
もし君が今、このPL/IシステムをJavaやC#へ移行しようとしているなら、以下の防衛策を設計書に盛り込むことを強く推奨する。
- 符号の正規化処理: 入力段階でEBCDICのゾーン/パック表現を、ターゲット言語の`BigDecimal`や`Decimal`型へ変換する際、必ず符号ビットの変換テーブルを介在させること。
- ダンプ解析の自動化: 汎用機のダンプを読み解く能力は、マイグレーションの後半戦で最強の武器になる。どの変数がどのバイト位置にあり、どのビットが異常値（例えば`F`以外の符号）を示しているか、即座に特定できるツールを用意せよ。
- CICSオンライン処理のエッジケース: CICS環境下では、共有ストレージ上のデータが非同期に書き換わる可能性がある。`VOLATILE`属性や、適切な`ENQ/DEQ`を忘れてはならない。
結びに代えて
PL/Iという言語は、コンパイラが「何を考えているか」を理解できれば、これほどまでに強力な味方はいない。予約語がないからこそ、開発者の意図をダイレクトに機械語に変換できるのだ。
「レガシー」という言葉に隠された技術的負債を紐解くことは、単なるコードの書き換えではない。それは、数十年前に設計されたハードウェアの制約と、それを克服するために先人たちが編み出した知恵を、現代のアーキテクチャへと昇華させる作業に他ならない。
符号ひとつに泣かされる日々を、ぜひ「システムの深淵を覗き込む特権」として楽しんでほしい。次の現場でも、その厳しい眼差しでコードの裏側を見抜いてくれ。
