ゾンビ勘定科目を呼び覚ますな：PL/Iの `CR` / `DB` PICTURE編集文字が隠し持つ「符号の罠」とマイグレーションの処方箋
メインフレームの基幹系バッチ処理において、長年動き続けているレガシーコードのメンテナンスほど、エンジニアの知性と胆力が試される場面はない。JavaやC#といったモダン言語に慣れ親しんだ若い世代のアーキテクトが、PL/Iのソースコードを初めて覗いたとき、最も奇異に映るものの一つがPICTURE句によるデータ定義、そしてその中でも会計帳票の出力で多用される `CR` と `DB` という編集文字だろう。
「なぜ、数値データを出力するだけなのに、わざわざ文字リテラルに近い `CR` や `DB` を挟む必要があるのか？」
「マイグレーション時に、この挙動をそのままJavaの `DecimalFormat` に移植したら、なぜか本番で金額が反転して夜間バッチがアベンド（ABEND）したのか？」
今回は、PL/Iにおける `CR`（Credit）と `DB`（Debit）の会計処理における挙動、そのコンパイラ内部での符号判定メカニズム、そしてオープン系へのマイグレーションやDB2連携時におけるエッジケース対策について、システムアーキテクトの視点から徹底的に解剖しよう。
—
1. `CR` と `DB` 編集文字の言語仕様とコンパイラ挙動の核心
PL/IのPICTURE句における `CR` と `DB` は、単なる文字のオマケではない。これらは「条件付きサフィックス編集文字」として機能し、対象となる数値変数の正負（符号）に応じて、出力文字列の末尾を動的に切り替える特殊なプレースホルダーである。
- `CR` (Credit): 値が「負（Negative）」の場合にのみ `”CR”` が出力され、「正またはゼロ（Positive or Zero）」の場合は空白（2バイト分のスペース）が出力される。
- `DB` (Debit): 値が「負（Negative）」の場合にのみ `”DB”` が出力され、「正またはゼロ」の場合は空白が出力される。
(※会計上の「借方(Debit)」と「貸方(Credit)」の厳密な意味とは異なり、単に負数を視覚的に強調するための表示上のコンベンションとして用いられることが多い)
ここで重要となるのは、PL/Iコンパイラがこの編集を行う際、ベースとなる数値変数の「内部符号（Sign）」をどのように解釈しているかという点である。
パックデシマル（COMP-3）とゾーンデシマルにおける符号の罠
基幹系で扱われる金額項目の多くは、パックデシマル（`FIXED DECIMAL`）として定義されている。パックデシマルの最下位バイトのニブル（下位4ビット）には、IBMメインフレームのアーキテクチャ（S/370アーキテクチャ以降）に根ざした符号ビットが格納されている。
- 正の値: `C`, `F`, `A` など（通常は `C`）
- 負の値: `D`, `B` など（通常は `D`）
- 符号なし（Unsigned）: `F`
もし、外部ファイル（例えばVANから受信した電文や、他系から渡されたフラットファイル）の定義ミスや、マイグレーション時のコンバータのバグによって、符号なしのゾーン形式や、意図しない符号ニブルを持つデータが `CR`/`DB` 付きのPICTURE変数にMOVEされた場合、コンパイラはそれを「正」と判定してしまう。
結果として、マイナス金額であるにもかかわらず、金額の後ろに `CR` が付かずに空白でスルーされ、帳票上は黒字（プラス）として印刷されるという、会計監査上もっとも恐ろしい「サイレント・データ破損」を引き起こすのである。
—
2. 実践的コード例：PL/Iにおける `CR` / `DB` の実装と動的メモリ操作
以下のPL/Iコードは、バッチ処理において数値データを画面やプリンタ、あるいはCSV等へ出力する際の典型的な定義と、ポインタを用いた動的ストレージ操作のサンプルである。
1
—————————————————————-
- 勘定科目残高のフォーマット変換処理サンフ゜ル
—————————————————————-
ACCOUNT_PRINT_PROG: PROC OPTIONS(MAIN);
DCL 1 W_ACCOUNT_RECORD,
5 W_ACCT_ID CHAR(4),
- CHAR(1),
/ 内部計算用の符号付きパックデシマル金額 (11桁, 小数2桁) /
5 W_RAW_BALANCE FIXED DEC(11,2) INIT(-1234567.89);
/ 出力用のPICTURE編集変数 /
DCL W_EDIT_CR_BALANCE PIC ‘ZZZ,ZZZ,ZZ9.99 CR’;
DCL W_EDIT_DB_BALANCE PIC ‘ZZZ,ZZZ,ZZ9.99 DB’;
/ ポインタおよびベース変数を用いた動的メモリ操作の例 /
DCL P_WORK_AREA POINTER;
DCL 1 DYNAMIC_AREA BASED(P_WORK_AREA),
5 D_AMOUNT FIXED DEC(11,2),
5 D_FORMATTED PIC ‘ZZZ,ZZZ,ZZ9.99 CR’;
/ ストレージの動的獲得 (GETMAIN相当) /
ALLOCATE DYNAMIC_AREA;
P_WORK_AREA = ADDR(DYNAMIC_AREA);
/ 負の値を設定して挙動を確認 /
D_AMOUNT = -987654.32;
/ MOVE時に自動的に符号が評価され、CRが付与される /
D_FORMATTED = D_AMOUNT;
DISPLAY(‘— 編集結果出力テスト —‘);
DISPLAY(‘RAW VALUE (NEGATIVE): ‘ || D_AMOUNT);
DISPLAY(‘CR FORMATTED : [‘ || D_FORMATTED || ‘]’);
/ 正の値に変更して再評価 /
D_AMOUNT = 54321.09;
D_FORMATTED = D_AMOUNT;
DISPLAY(‘RAW VALUE (POSITIVE): ‘ || D_AMOUNT);
DISPLAY(‘CR FORMATTED(POS) : [‘ || D_FORMATTED || ‘]’);
/ 後始末 /
FREE DYNAMIC_AREA;
RETURN;
END ACCOUNT_PRINT_PROG;
このコードを実行すると、`D_AMOUNT` が負のときは `D_FORMATTED` の末尾に `CR` が入り、正のときは空白が入る。一見して何ということはない処理に見えるが、この「自動編集」の裏側で、PL/Iランタイムは厳密な符号ビットの検査を行っている。
—
3. 埋め込みSQL（DB2）およびCICSオンライン処理におけるエッジケース
この `CR` / `DB` 編集文字の挙動が、最も牙をむくのはDB2からのデータ取得時や、CICSの通信域（COMMAREA）を介したデータ受け渡しの現場である。
① DB2（SQL）とのデータ型ミスマッチ
DB2のテーブル定義で `DECIMAL(13,2)` として定義されているカラムからデータを取得し、PL/I側で `PIC ‘ZZZ,ZZZ,ZZ9.99 CR’` の変数に直接宿す（あるいはホスト変数経由でバインドする）場合、データが `NULL` である場合のエッジケースに直面する。
PL/Iには標準でJavaの `Optional` のようなスマートなNULL表現がないため、DB2のインジケータ変数（INDICATOR VARIABLE）を必ず併用しなければならない。
もしインジケータ変数をチェックせずに `NULL` 値を持つカラムを直接 `CR` 付きのピクチャ変数にMOVEしようものなら、PL/Iランタイムでデータ例外（S0C7アベンドの前兆、あるいはコンパイルエラー・実行時例外）を引き起こすか、意図しないゼロサプレス（またはゴミデータの表示）が発生する。
② CICSオンライン画面（BMSマップ）での入力逆変換の罠
オンライン画面（3270端末等）からユーザーが金額を入力し、画面上のフィールドに `123,456.78 CR` と手入力されたとする。
これをCICSのアプリケーションプログラム側で数値変数（`FIXED DEC`）に逆変換（エディット解除）しようとする際、PL/Iの `ASSIGN` 文や `MOVE` 文は、入力文字列の中に `CR` や `DB` が含まれていると、それを正しくパースして符号を復元できるケースと、コンパイラオプションの指定によってはエラー（CONVERSIONアベンド：ASRA/S0C7など）になるケースがある。
特に、レガシーなオンライン画面でユーザーがスペースや誤った文字を入力した場合、`CR` 判定ロジックが崩壊し、マイナス金額がプラスとしてDBにUPDATEされてしまうという深刻なデータ汚染インシデントに繋がった事例を、筆者は幾度となく現場で目撃してきた。
—
4. オープン系（Java / C#）へのマイグレーションにおける設計指針
メインフレームからJavaやC#へのマイグレーションプロジェクトにおいて、この `CR` / `DB` の振る舞いをどう再現するかは、移行設計のキモである。
モダン言語には、標準でPL/Iの `CR`/`DB` のような「負数の場合に特定の文字列サフィックスを付与する」組み込みの数値フォーマッタは存在しない（Javaの `DecimalFormat` はマイナス記号 `-` や親括弧 `()` の表現には強いが、`CR`/`DB` を直接指定するパターンはサポート外であることが多い）。
移行時のアーキテクチャ設計アプローチ
1. 共通ユーティリティ（カスタムフォーマッタ）の作成
Java側で、数値の符号を判定し、負数であれば末尾に `” CR”` または `” DB”` を結合し、正数であれば空白パディングを行うラッパーメソッド（またはカスタム `NumberFormat`）を必ず実装すること。
2. データベース層（DB2 / PostgreSQL / Oracle）での処理の排除
SQL側で無理に `CR`/`DB` 形式の文字列に変換しようとせず、データベース内ではあくまで純粋な数値（`NUMERIC` / `DECIMAL`）として保持し、プレゼンテーション層（画面出力やCSV生成バッチ）の直前でフォーマット変換を行うアーキテクチャを厳守する。
3. テストケースの網羅性
マイグレーション検証においては、「ゼロ」「正の数」「負の数」「NULL」「パディングのスペース数（右側の空白が削られていないか）」の5パターンを網羅したテストスイートを必ず用意すること。特に、COBOLやPL/I特有の「右側空白の切り詰め（Trimming）」挙動の違いにより、帳票のレイアウト崩れが発生しやすいため注意が必要だ。
—
5. まとめ
PL/Iの `CR` および `DB` 編集文字は、単なる「表示の装飾」ではない。それは、メインフレームが何十年にもわたって守り抜いてきた、ハードウェアレベルの符号表現と会計データの厳密な整合性を結ぶ、細いけれども極めて強靭な糸である。
レガシーシステムのブラックボックスを紐解くとき、こうした一見些細に見える言語仕様の妙が、システム全体の信頼性を支えていることに気づかされる。マイグレーションを成功させるカギは、新しい言語の文法を覚えることではなく、レガシーコードが背負ってきた「歴史と仕様の理由」を完璧に理解し、モダンなアーキテクチャへと昇華させることにあるのだ。
