お疲れ様です。今日も元気にオンラインのログや夜間バッチのABEND（アベンド）解析に追われていることと思います。
メインフレームの現場において、COBOL全盛の世の中であっても、金融・証券・公共といった極めて高い信頼性が求められる基幹システムでは、今なおPL/Iがその深遠なる表現力と圧倒的な処理能力を武器に現役で稼働しています。
さて、後輩の皆さんから「先輩、なんでこの数値項目の定義はわざわざ `FIXED BINARY` にしてるんですか？ `PIC S9(4)` じゃダメなんですか？」という質問をよく受けます。
画面や帳票の入出力ならまだしも、VSAM（KSDS/ESDS）のキー項目や、CICSとの通信領域（COMMAREA）、あるいは他システム連携のバイナリインターフェースにおいて、このデータ型の内部表現を誤ると、夜間バッチで突如として「S0C7（データ例外）」や、もっと厄介な「サイレント・データ破損（原因不明の数値化け）」を引き起こします。
今回は、PL/Iにおける `FIXED BINARY(15)` と `FIXED BINARY(31)` の内部表現 に焦点を当て、2バイトおよび4バイト整数としての格納形式、符号ビットの扱い、そして実務で直面するVSAMアクセスやデバッグの勘所を、ベテランの視点から徹底的に解説しましょう。
—
1. PL/Iの「予約語を持たない」美学と識別子の罠
本題に入る前に、PL/Iという言語のユニークな思想について少し触れておきます。
C言語やCOBOLとは異なり、PL/Iには厳密な意味での「予約語（Reserved Words）」が存在しません。
どういうことか？ `IF` や `THEN`、さらには今回解説する `FIXED` や `BINARY` さえも、すべて「文脈依存のキーワード」です。極端な話、以下のようなコードを書くことも理論上は可能です。
1
DECLARE FIXED FIXED BINARY(15);
（※変数名に `FIXED` を使っています。コンパイラは前後の文脈から変数名か属性キーワードかを判別しますが、こんな悪趣味なコードを書いたら、コードレビューで私に赤ペンを何本折られるか分かりません。絶対にやめましょう）
この「予約語がない」という仕様は、言語の拡張性を爆発的に高めた一方で、うっかりキーワードと同じ名前を変数に使ってしまった際に、コンパイラがとんでもない解釈をしてエラーメッセージの迷宮に迷い込む原因になります。識別子（変数名）の命名にあたっては、言語仕様のコンテキストを常に意識するプロフェッショナルなセンスが求められます。
—
2. `FIXED BINARY(15)` と `FIXED BINARY(31)` の内部表現
それでは本題です。整数データを扱う際、私たちは通常以下のいずれかを選択します。
- `FIXED BINARY(15)` : 2バイト（16ビット）整数
- `FIXED BINARY(31)` : 4バイト（32ビット）整数
ここで「あれ？ 15桁や31桁の数字が入るわけじゃないの？」と勘違いする若手が後を絶ちません。PL/Iの `BINARY` 属性における括弧内の数値は、「精度（Precision）」すなわち符号を除いた有効ビット数を表します。
2バイト整数：`FIXED BINARY(15)` の世界
- 格納サイズ: 2バイト（半ワード / Halfword）
- ビット配分: 最上位1ビットが符号（Sign Bit）、残りの15ビットが数値データ。
- 表現可能範囲: $-32,768$ から $+32,767$ まで（$2^{15} – 1$）
メインフレームのアーキテクチャ（S/390やz/Architecture）において、これはIBM汎用機の基本命令である `LH`（Load Halfword）や `STH`（Store Halfword）の直撃を受けるサイズです。CICSの領域長や、小規模なループカウンタ、フラグ的な数値コードによく使われます。
4バイト整数：`FIXED BINARY(31)` の世界
- 格納サイズ: 4バイト（フルワード / Fullword）
- ビット配分: 最上位1ビットが符号、残りの31ビットが数値データ。
- 表現可能範囲: $-2,147,483,648$ から $+2,147,483,647$ まで（$2^{31} – 1$）
こちらはフルワード命令（`L`, `ST`, `A`, `M` など）の領域です。件数カウンタや金額（円単位の整数保持）、あるいは大規模なシーケンス番号にはこちらを選択します。
符号ビットの扱いと「2の補数」
IBMメインフレームは、すべての負数を「2の補数（Two’s Complement）」で表現します。
例えば、`FIXED BINARY(15)` で `-1` を表現する場合、16ビットすべてが `1`（`X’FFFF’`）になります。
もし、外部から受信した汚れたデータや、C言語などの他言語で作られたバイナリファイル（Big-Endian形式）を読み込んだ際、符号ビットの解釈を誤ると、プラスであるはずのデータがマイナスに化けたり、逆に巨大な数値として暴走したりします。ここがレガシー移行時の最大の地雷原です。
—
3. 実践：VSAMレコード入出力とBUILTIN関数の活用
百聞は一見にしかず。実際のメインフレーム開発を想定したPL/Iのサンプルコードを見てみましょう。
このプログラムは、VSAM（KSDS）ファイルからバイナリデータを読み込み、社内ニッチな口座残高やトランザクション件数を `FIXED BINARY` で安全に処理しつつ、内部のビット表現を検証するものです。
1
//
/ ﾌﾟﾛｸﾞﾗﾑ名: ﾋﾞｰｴｽｴﾑｻﾝﾌﾟﾙ (VSAMとFIXED BINARYの検証) /
/ 概要: VSAM(KSDS)からのレコード読み込みと2/4ﾊﾞｲﾄ整数の制御 /
//
BINPR01: PROC OPTIONS(MAIN);
/ — ﾌｧｲﾙ定義 (VSAM KSDS) — /
DECLARE VSMFILE FILE RECORD
ENVIRONMENT(KEYED
BUFOFFSET(0)
VSAM);
/ — ﾚｺｰﾄﾞ構造体定義 — /
DECLARE 1 VSAM_RECORD,
5 ACCT_ID CHAR(8), / 口座ID (ｷｰ項目) /
5 TXN_COUNT FIXED BIN(15), / 本日の取引回数(2ﾊﾞｲﾄ) /
5 ACCT_BALANCE FIXED BIN(31), / 口座残高(4ﾊﾞｲﾄ) /
5 FILLER CHAR(10); / 予備領域 /
/ — ﾜｰｷﾝｸﾞｾﾞｯﾄ — /
DECLARE W_EOF_FLG CHAR(1) INIT(‘OFF’);
DECLARE W_HEX_VAL CHAR(20);
DECLARE RET_CODE FIXED BIN(31) INIT(0);
/ — ONﾕﾆｯﾄによる異常系 (ﾌｧｲﾙ終了条件) の制御 — /
ON ENDFILE(VSMFILE) W_EOF_FLG = ‘ON’;
/ — ﾌｧｲﾙのｵｰﾌﾟﾝ (更新用入力) — /
OPEN FILE(VSMFILE) INPUT;
DISPLAY(‘ ﾊﾞｯﾁ処理開始: BINPR01 ‘);
/ — ﾒｲﾝﾙｰﾌﾟ — /
READ FILE(VSMFILE) INTO(VSAM_RECORD);
DO WHILE (W_EOF_FLG = ‘OFF’);
/ ｻﾃﾞｨｽﾌｧｲｸﾞなﾃﾞｰﾀ検証: 符号付き整数の健全性ﾁｪｯｸ /
IF TXN_COUNT < 0 THEN
BEGIN;
DISPLAY('【警告】取引回数にﾏｲﾅｽ値が検出されました。ｷｰ: ' || ACCT_ID);
/ ここで適切な異常処理やﾛｸﾞ出力を行う /
END;
/ ﾃﾞﾊﾞｯｸﾞ用途: 内部ﾊﾞｲﾅﾘをﾋｷﾞｽ (HEX) で確認する (BUILTIN関数活用) /
/ UNSPEC組込み関数により、変数の生のﾋﾞｯﾄ列を文字列に変換 /
W_HEX_VAL = UNSPEC(ACCT_BALANCE);
/ 実務のﾎﾟｲﾝﾄ: FIXED BIN(31)の値を画面や帳票に出力するため、 /
/ ﾃﾞｰﾄﾞ (編集) ﾊﾟﾀｰﾝを使用して文字型に明示的変換する /
DISPLAY('口座: ' || ACCT_ID ||
' / 取引回数(BIN15): ' || EDIT(TXN_COUNT, 'ZZZ9') ||
' / 残高(BIN31): ' || EDIT(ACCT_BALANCE, '---,---,--9') );
/ 次のﾚｺｰﾄﾞ読み込み /
READ FILE(VSMFILE) INTO(VSAM_RECORD);
END;
/ --- ﾌｧｲﾙのｸﾛｰｽ --- /
CLOSE FILE(VSMFILE);
DISPLAY(' ﾊﾞｯﾁ処理正常終了: BINPR01 ‘);
RETURN;
END BINPR01;
—
4. 現場のシニアが教える「デバッグとコーディング標準」のコツ
上記のコードと、長年の保守経験から得た知見をもとに、実務で絶対に押さえておくべきポイントをいくつか伝授します。
1. `UNSPEC` と `HEX` 組み込み関数の使い分け
プログラムが意図しない数値（例えば、先ほど述べた符号ビットの反転や、パディングのゴミデータ）でクラッシュしたとき、シニアエンジニアはまずタンプ（Dump）やトレーシングで変数の生データを確認します。
PL/Iには `UNSPEC` という強力な組み込み関数があります。これは変数の型を無視して、メモリ上の物理的なビットパターンをそのまま露出させます。
VSAMの再構築や、オープン系システムとのEDI連携で「数値がおかしい」と感じたら、迷わず `UNSPEC(対象変数)` を出力するデバッグルーチンを挟んでください。原因が一発で特定できます。
2. 暗黙のデータ型変換（Mixed-Mode Arithmetic）に殺されるな
PL/Iは非常に「親切」な言語です。`FIXED BIN(15)` と `FIXED BIN(31)` を演算させる際、コンパイラが勝手に型を拡張（Promotion）してくれます。
しかし、この「自動型変換」を過信していると、予期せぬパフォーマンス低下や、最悪の場合、桁あふれ（Overflow）による `ON SIZE` 条件の発生を招きます。
算術演算を行う際は、あらかじめ変数宣言を統一するか、`BINARY` の精度を明示的にそろえるコーディング標準をチーム内で徹底してください。
3. ONユニットによる例外制御
サンプルコードでも入れている `ON ENDFILE` や、数値演算エラーを捕捉する `ON SIZE`、`ON CONVERSION` などのONユニットは、PL/Iの真骨頂です。
COBOLの `INVALID KEY` や `DECLARATIVES` に相当しますが、より洗練されたスコープ制御が可能です。特にバイナリデータを扱うバッチでは、外部からの不正データ流入による `S0C7` アベンドを未然に防ぐために、適切な `ON CONVERSION` ルーチンをグローバルまたはブロック単位で仕込んでおくことが、プロのシステムアーキテクトとしての最低限のたしなみです。
—
おわりに
今回は `FIXED BINARY(15)` と `FIXED BINARY(31)` の内部表現という、一見地味ながらメインフレーム開発の根幹をなすテーマについて解説しました。
たった2バイト、4バイトの違いですが、このメモリ上のバイナリ表現と符号ビットの挙動を完全に手に入れたとき、あなたは単なる「コードが書けるプログラマ」から、ハードウェアの息吹までを感じ取れる「真のメインフレーム・アーキテクト」へと一歩近づきます。
レガシーシステムのブラックボックスを恐れず、論理と仕様の裏付けを持って、今日も誇りあるコードを書き上げていきましょう。質問や現場でのハマりどころがあれば、いつでも声をかけてください。
