メインフレームの深淵：FIXED BINARYの「境界整列」が運命を分けるとき
基幹システムのコードを読み解いていると、たまに溜息が出るようなコードに出会う。「なぜわざわざ `FIXED BINARY(15)` を多用したのか？」と。当時のメモリ制約や、あるいは特定のレジスタ操作を意識した先人の苦悩が透けて見える瞬間だ。
今日は、PL/Iにおける `FIXED BINARY(15)`（ハーフワード）と `FIXED BINARY(31)`（フルワード）の境界整列（アライメント）が、現代のz/Architectureにおいてどのような物理的意味を持ち、それがなぜマイグレーション時の「性能劣化」や「不可解なアベンド」の引き金になるのかを紐解いていきたい。
—
1. なぜ「境界整列」が神聖視されるのか
我々が扱うIBMメインフレームのCPUは、メモリ上のデータを読み込む際、そのデータが「自身のサイズに応じた境界」に配置されていることを強く好む。
- FIXED BINARY(15): 2バイト境界（偶数番地）に配置されるべき。
- FIXED BINARY(31): 4バイト境界（4の倍数の番地）に配置されるべき。
もし、`ALIGNED` 属性を忘れて `UNALIGNED` になっていたり、構造体内でうっかり奇数番地に配置されたりするとどうなるか。CPUは、たった一つの値を読み込むために、わざわざ2回メモリをアクセスし、ビットシフトして連結するという「余計な儀式」を強いられる。
これが数百万件のレコードを処理する深夜バッチにおいて、どれほどの遅延を招くか。現代のJava等へのマイグレーションにおいて、メモリレイアウトの差異を無視して「単に値を置き換える」だけの設計をすると、性能要件を満たせずプロジェクトが炎上する主因となる。
—
2. 構造体設計における最適化の実例
以下のコードを見てほしい。構造体を宣言する際、`ALIGNED` を明示するかしないかで、コンパイラの生成する機械語は劇的に変わる。
/i
/ 不適切な構造体定義の例：パディングが考慮されていない /
DCL 1 BAD_STRUCT UNALIGNED,
2 FIELD_A FIXED BINARY(15), / 2バイト /
2 FIELD_B FIXED BINARY(31); / 4バイトだが、ここが奇数位置から始まる可能性がある /
/ 推奨される構造体定義の例：アライメントを意識する /
DCL 1 GOOD_STRUCT ALIGNED,
2 FIELD_A FIXED BINARY(15),
2 FILLER CHAR(2), / 明示的なパディングで境界を調整 /
2 FIELD_B FIXED BINARY(31);
`ALIGNED` を指定すると、コンパイラは自動的にパディングを挿入し、実行効率を最適化する。逆に `UNALIGNED` は、メモリ消費を最小限に抑えたいCICSの通信領域（COMMAREA）などで使うのが定石だ。この使い分けを理解していないと、DB2のホスト変数として渡す際に「データの食い違い」という地獄を見ることになる。
—
3. ダンプ解析：S0C6/S0C7の裏側にある真実
オンライン処理で「S0C6（仕様例外）」が発生したとき、真っ先に疑うべきは境界整列ミスだ。
特に、`BASED` 変数を使用してポインタ経由で構造体をマップする際、ポインタが奇数番地を指した状態で `FIXED BINARY(31)` にアクセスすると、ハードウェアは容赦なくアベンドを叩きつけてくる。
/i
DCL P PTR;
DCL MY_DATA BASED(P) FIXED BINARY(31);
/ Pが奇数番地を指していると、この時点でS0C6が飛ぶ /
MY_DATA = 100;
この手のバグは、マイグレーション先のJavaで `ByteBuffer` を操作する際にも形を変えて現れる。ポインタという概念がない言語へ移す際、メモリのアライメントをどう模倣するか。ここがアーキテクトの腕の見せ所だ。
—
4. パックデシマル（FIXED DECIMAL）の罠
最後に一つだけ、現場でよくある罠に触れておこう。`FIXED BINARY` と混在させて計算を行う際、パックデシマル（`FIXED DECIMAL`）の内部表現に注意が必要だ。
特に古いシステムで見かける「符号反転バグ」は、パックデシマルの末尾ニブル（符号部分）が `X’0C’`（正）から `X’0D’`（負）へ意図せず変化することで起きる。これを `FIXED BINARY` へ変換しようとして `CONVERSION` エラーでアベンドするのは、基幹系開発における「登竜門」のようなものだ。
対策：
`CHECK` オプションを使用して、計算の境界で値が異常値になっていないかを逐次監視すること。また、DB2へ値を渡す際は `DECIMAL` 型を厳密にキャストし、メインフレームのハードウェア演算が期待する形式と、DB2の内部表現が合致しているか確認を怠らないこと。
—
結びに代えて
PL/Iは古い言語ではない。それは、CPUの挙動を直接制御する「裸のアーキテクチャ」を、人間が理解可能な形で記述するための高度な抽象化ツールだ。
マイグレーションを単なる「コードの翻訳」と考えているチームは、必ず失敗する。我々が向き合っているのは、バイト境界の先にある「計算の整合性」そのものなのだから。次にメインフレームのダンプを見るときは、レジスタの値だけでなく、その背後にあるメモリマップという広大な宇宙を想像してほしい。
それが、真のシステムアーキテクトというものだ。
