はじめに：なぜ今、`FIXED BINARY`の「bit単位の境界」に立ち返るのか
基幹システムの現場で、夜間バッチの性能チューニングや、オープン系（JavaやC#）へのマイグレーション設計に携わっていると、避けて通れないのがデータ型の「サイズとアライメント」の壁です。
特にPL/Iの `FIXED BINARY (p)` は、一見すると単なる2進数固定小数点数ですが、その内部表現とストレージ占有量は、コンパイラの仕様（さらにはCPUのアーキテクチャ）と密接に結びついています。精度パラメータ `p` の値によって、変数がハーフワード（2バイト）になるか、フルワード（4バイト）になるか、あるいはダブルワード（8バイト）になるか。この境界を曖昧にしたままポインタ操作を行ったり、外部システム（DB2やCICS）とデータ構造を共有したりすると、突発的なS0C4アベンドや、原因究明に数日を要するサイレント・データ破損を引き起こします。
今回は、IBMメインフレームの深淵を知るシステムアーキテクトの視点から、`FIXED BINARY` の真の姿と、実務で踏みがちな地雷、そしてモダン言語への移行における設計の急所を徹底的に紐解いていきましょう。
—
1. `FIXED BINARY(p)` の内部表現とストレージ割り当ての鉄則
PL/Iにおける `FIXED BINARY(p)` の精度 `p`（ビット数、符号ビットを除く）は、コンパイラがどれだけのストレージを割り当てるかを決定する絶対的な基準です。ここにはIBM Enterprise PL/Iコンパイラが厳格に定めたルールが存在します。
精度 `p` とストレージ占有量の関係
| 精度 `p` の範囲 | 割り当てられるストレージ | バイト数 | 備考 |
| :— | :— | :— | :— |
| `1` ～ `15` | ハーフワード (Halfword) | 2 バイト | 16ビット境界にアライン |
| `16` ～ `31` | フルワード (Fullword) | 4 バイト | 32ビット境界にアライン |
| `32` ～ `63` | ダブルワード (Doubleword) | 8 バイト | 64ビット境界にアライン (`FIXED DEC` や `FLOAT` との混在時注意) |
ここで重要なのは、「宣言された桁数（見かけ上のサイズ）」ではなく、「`p` の値」がストレージを支配しているという点です。例えば、`DCL A FIXED BIN(15);` は2バイトですが、`DCL B FIXED BIN(16);` とたった1bit増やしただけで、内部的には4バイトのフルワードに跳ね上がります。
コンパイルオプションとアライメントの罠
デフォルトでは、コンパイラはパフォーマンスを最大化するため、半ワード変数は2バイト境界、フルワード変数は4バイト境界に境界調整（アライメント）を行います。構造体（`STRUCTURE`）の定義において、このアライメントの仕様を知らないと、意図しない「パディング（パディングバイト）」が自動挿入され、CICSの通信領域（COMMAREA）やDB2のホスト変数構造体のレイアウトがズレる原因になります。
1
DCL 1 01_MEMBER_REC,
02 M_ID FIXED BIN(15), / 2バイト + パディング2バイトが自動挿入される可能性あり /
02 M_SALARY FIXED BIN(31); / 4バイト /
もしパディングを排除して完全に連続した領域として扱いたい場合は、構造体宣言に `UNALIGNED` 属性を明示する必要があります。ただし、その代償として、アラインされていないデータへのアクセスはCPUのサイクル数を増加させ、極端な場合はハードウェア例外（S0C7やS0C4）を誘発するため、安易な `UNALIGNED` の多用は禁物です。
—
2. ベース変数とポインタを用いた動的メモリ操作のエッジケース
レガシーなPL/Iプログラムでは、ストレージ領域を節約するため、あるいは可変長レコードを効率的に処理するために、`BASED` 変数とポインタを駆使したコーディングが日常的に行われています。ここでも `FIXED BINARY` のサイズとアライメントの理解が勝負の分かれ目となります。
以下の実務的なコード例を見てください。ストリームから読み込んだ生バイナリデータを、ポインタを介して `FIXED BINARY` の構造体にマッピングする処理です。
1
/ —————————————————————- /
/ ベース変数とポインタによる動的領域マッピングの例 /
/ —————————————————————- /
GET_DATA_BLOCK: PROC OPTIONS(MAIN);
DCL RAW_BUFFER CHAR(1024) BASED(P_BUF);
DCL P_BUF POINTER;
/ マッピング用の構造体（完全なアライメント制御が必要） /
DCL 1 HEADER_MAP BASED(P_HDR),
02 RECORD_ID FIXED BIN(15), / 2バイト /
02 DATA_COUNT FIXED BIN(31); / 4バイト /
DCL SYSIN FILE STREAM INPUT;
DCL SYSPRINT FILE STREAM OUTPUT;
/ ワークエリアの動的割り当て /
ALLOCATE RAW_BUFFER;
/ 生データの読み込み（省略） /
/ … /
/ ヘッダ部のポインタを設定 /
P_HDR = P_BUF;
/ 【警告】もしP_BUFが4バイト境界にアラインされていない場合、 /
/ DATA_COUNT（FIXED BIN(31)）へのアクセスで /
/ ハードウェア例外（S0C4アベンド）が発生するリスクがある /
PUT SKIP EDIT (‘RECORD_ID = ‘, HEADER_MAP.RECORD_ID) (A, F(6));
PUT SKIP EDIT (‘DATA_COUNT = ‘, HEADER_MAP.DATA_COUNT)(A, F(10));
FREE RAW_BUFFER;
END GET_DATA_BLOCK;
アーキテクトの視点：S0C4アベンドの真相
System/390やz/Architectureプロセッサにおいて、4バイトのフルワードデータ（`FIXED BIN(31)` など）は、4の倍数のメモリアドレス（4バイト境界）に位置していなければなりません。もしポインタ演算や不適切なオフセット計算によって、奇数アドレスや2の倍数アドレス（但し4の倍数ではない）を指している状態でその変数を参照すると、ハードウェアが例外割込みを発生させ、お馴染みの `ABEND S0C4`（Protection Exception または Addressing Exception）へと直行します。
動的メモリを扱う際は、常に `ADDR()` ビルトイン関数とオフセットの偶数・4倍数性を意識した設計が不可欠です。
—
3. 埋め込みSQL（DB2）およびCICS通信における落とし穴
オンラインシステム（CICS）やデータベース（DB2）と連携する際、`FIXED BINARY` はオープン系のデータ型（SQLの `INTEGER` や `SMALLINT`）とダイレクトにマッピングされます。ここに潜む「型のミスマッチ」は、コンパイルエラーにならずに実行時エラーやデータ化けを引き起こすため、最も厄介です。
1. DB2ホスト変数としての定義ミス
DB2の `SMALLINT` は正確に2バイトの符号付き整数です。これをPL/I側で `FIXED BIN(31)`（4バイト）としてホスト変数に定義した場合、SQLのフェッチ時に予期せぬ領域オーバーランやデータ切り捨てが発生する可能性があります。逆に、DB2の `INTEGER`（4バイト）に対して `FIXED BIN(15)`（2バイト）を割り当てた場合も同様です。
- 鉄則: DB2の `SMALLINT` ＝ PL/Iの `FIXED BIN(15)`、DB2の `INTEGER` ＝ PL/Iの `FIXED BIN(31)` を厳守すること。
2. CICSのCOMMAREAとビッグエンディアンの呪縛
メインフレームはビッグエンディアン（上位バイトから格納）です。CICSの通信領域を通じてホスト間や他システムとバイナリデータをやり取りする場合、`FIXED BINARY` の実体がどのように並んでいるかが勝負になります。
オープン系（x86系CPU）へのマイグレーションを行う際、このエンディアンの違い（リトルエンディアンへの変換）を考慮漏れすると、数値が全く別の巨大な値に変貌する「符号反転・バイトスワップバグ」の温床となります。
—
4. マイグレーション設計（Java / C# への移行）における処方箋
レガシーPL/IシステムをJava（Spring Bootなど）やC#（.NET Core）へモダナイゼーションする際、`FIXED BINARY` の定義をそのままターゲット言語のプリミティブ型に置き換えるだけでは不十分です。
移行時のデータ型マッピング指針
- `FIXED BIN(15)`
- Java: `short` または `int`
- C# : `short` (`Int16`)
- 注意: Javaには無符号の概念が薄く、`short` は符号付き(-32768～32767)であるため、PL/I側でビット演算や無符号として使われていた場合は `int` への格上げとビットマスク処理が必要です。
- `FIXED BIN(31)`
- Java: `int`
- C# : `int` (`Int32`)
- 構造体のパディングとアライメントの再現
- Javaでバイナリファイルを直接読み込む構造体（いわゆるコボルやPL/Iのコピーブックを模したレイアウト）を再現する場合、Javavolutionやカスタムのバイナリパーサ、あるいは `ByteBuffer` を用いて明示的なオフセット管理を行う必要があります。C#であれば `[StructLayout(LayoutKind.Sequential, Pack = 1)]` 属性を用いて、メインフレームの `UNALIGNED` 相当のレイアウトを強制することが移行成功の必須条件となります。
—
おわりに：レガシーの構造を愛し、モダナイゼーションを制す
PL/Iの `FIXED BINARY` という一見地味なデータ型を深く掘り下げていくと、そこにはハードウェアの制約、コンパイラの最適化ロジック、そして何十年も動き続けてきた基幹システムの「知恵と執念」が詰まっていることが分かります。
単に「古い言語の仕様」として片付けるのではなく、その内部表現（ハーフワードかフルワードか、アライメントはどこか）の本質を完全に理解しているアーキテクトだけが、トラブルシューティングを瞬時に解決し、リスクのない完璧なマイグレーションを導くことができます。
レガシーのアーキテクチャに敬意を払いつつ、次世代のオープンな世界へその魂を継承する――それこそが、我々システムスペシャリストの使命です。
