メインフレームの心臓部を蝕む「境界アライメント」の罠
こんにちは。長年、金融や流通の基幹系システムでIBMメインフレームのアーキテクチャと向き合ってきた私にとって、PL/Iという言語は、ハードウェアの物理制約とプログラミングの抽象化を最も美しく（そして時には残酷に）結びつける魔力を持った言語です。
現代のオープン系言語（JavaやC#など）に慣れ親しんだエンジニアが、マイグレーションプロジェクトなどでPL/Iの構造体や`FIXED BINARY`の定義を眺めると、しばしば首をかしげます。「なぜ、こんな無駄な隙間（パディング）が空いているのか」「なぜ、メモリアドレスの奇数・偶数にこれほど神経を使う必要があるのか」と。
結論から言いましょう。メインフレームのプロセッサ（z/Architecture）にとって、メモリアライメントは単なる「スタイルの問題」ではありません。それは、CPUサイクルの無駄を省き、システム全体のスループットを極限まで高めるための生死に関わるハードウェア制約なのです。
今回は、`FIXED BINARY(15)` と `FIXED BINARY(31)` がメモリ上でどのように配置され、アライメントの不一致がパフォーマンス低下や、最悪の場合は致命的なアベンド（S0C4やS0C7など）を引き起こすメカニズムについて、コンパイラの挙動からダンプ解析、そしてDB2やCICSのエッジケースに至るまで、現場の知見を総動員して解説します。
—
1. ハーフワードとフルワード：メモリ配置の物理原則
z/Architectureにおいて、データ型に応じたメモリアライメント（境界調整）のルールは厳格です。
- `FIXED BINARY(15)`（2バイト / ハーフワード）: 2の倍数のメモリアドレス（偶数アドレス）に配置される必要があります。
- `FIXED BINARY(31)`（4バイト / フルワード）: 4の倍数のメモリアドレスに配置される必要があります。
もし、CPUが奇数アドレスから2バイトや4バイトのデータを読み込もうとすると、ハードウェア例外（プログラムチェック）が発生するか、あるいはプロセッサ内部で複数回のメモリアクセスサイクルが発生して性能が著しく劣化します。
PL/Iコンパイラは、このハードウェアの要求を満たすために、構造体（`STRUCTURE`）のメンバ間に自動的にパディング（空白領域）を挿入します。
構造体パディングのメカニズム
言葉で説明するよりも、実際のコードとメモリ上の配置を見ていただきましょう。以下のPL/I構造体を定義したとします。
1
DCL 1 例文構造体 BASED,
2 区分コード FIXED BIN(15), / 2バイト整数 /
2 連番 FIXED BIN(31), / 4バイト整数 /
2 ステータス CHAR(1); / 1バイト文字 /
一見すると、合計サイズは `2 + 4 + 1 = 7バイト` に見えますよね。しかし、PL/Iコンパイラがメモリ上にこれをどう配置するか、その内部計算を見てみましょう。
1. `区分コード` は `FIXED BIN(15)` なので、2バイト境界に配置されます（オフセット 0）。
2. 次の `連番` は `FIXED BIN(31)` なので、4バイト境界に配置されなければなりません。
3. しかし、現在のオフセットは 2 です。4の倍数にするために、コンパイラは自動的に 2バイトのパディング（隙間） を挿入します。これにより、`連番` はオフセット 4 から始まります。
4. `連番`（4バイト）がオフセット 4〜7 を占有します。
5. 最後の `ステータス`（CHAR(1)）はオフセット 8 に配置されます。
6. さらに、構造体全体のサイズは、最も厳しいアライメント要件（この場合はフルワードの4バイト）の倍数に切り上げられるというルールがあります。そのため、末尾にもパディングが入り、全体のサイズは 12バイト になります。
7バイトのデータを持つはずの構造体が、メモリ上では12バイトに膨れ上がる――これが、レガシー移行時にデータレイアウトの不一致（いわゆる「構造体ズレ」）を引き起こす最大の原因です。
—
2. コンパイラオプション（ALIGNED vs UNALIGNED）の選択とリスク
PL/Iには、このアライメント動作を制御するための強力なコンパイラオプション、あるいは属性として `ALIGNED` と `UNALIGNED` が存在します。
- `ALIGNED`（デフォルト）: ハードウェアの境界規則に厳密に従います。パフォーマンスは最高ですが、前述の通りパディングが発生します。
- `UNALIGNED`: パディングを極力排除し、データが連続して配置されるように詰めます。
1
/ UNALIGNEDを指定した構造体 /
DCL 1 圧縮構造体 BASED,
2 区分コード FIXED BIN(15) UNALIGNED,
2 連番 FIXED BIN(31) UNALIGNED,
2 ステータス CHAR(1);
この場合、パディングは最小限に抑えられ、データサイズは理論値に近づきます。しかし、ここに大きな罠があります。
パフォーマンスとマイグレーションのジレンマ
`UNALIGNED` なデータをCPUが処理する場合、アライメント境界を跨ぐ可能性（クロスカウンターアクセス）が生じるため、ハードウェアレベルでエミュレーションや追加のメモリアクセスが発生し、CPU使用率が跳ね上がります。バッチ処理で何百万件もこの構造体をループ処理する場合、処理時間が数倍に膨れ上がることも珍しくありません。
また、JavaやC#へのマイグレーションを行う際、Java側で `ByteBuffer` や構造体マッピング（JNA等）を行う場合、PL/I側が `ALIGNED` なのか `UNALIGNED` なのかを正確に把握していないと、バイナリデータの読み込み時に値が綺麗にシフトせず、大惨事になります。
—
3. ベース変数とポインタによる動的メモリ操作のエッジケース
基幹システムでは、可変長レコードやストレージ直読み込みのために、`BASED` 変数とポインタを駆使した動的メモリ操作が日常茶飯事に行われます。
1
Dcl Ptr_RawData POINTER;
Dcl 1 Map_Record BASED(Ptr_RawData),
3 Header_ID FIXED BIN(15),
3 Data_Body FIXED BIN(31);
/ 外部から取得したストレージのアドレスをポインタにセット /
Ptr_RawData = Get_Storage_Address();
ここで恐ろしいのは、`Get_Storage_Address()` が返すアドレスが、もし奇数アドレスであったり、4の倍数でなかったりした場合です。この状態で `Map_Record` を参照しようとすると、システムは容赦なく S0C4（Protection Exception / Addressing Exception） や S0C1（Operation Exception） のアベンドを吐いてクラッシュします。
特に、CICSの通信領域（COMMAREA）や、ファイルから読み込んだアンブラインドなバイナリデータをそのままポインタでキャストして読み込む際は、アライメント違反によるサイレント破壊や突発性アベンドに細心の注意を払う必要があります。
—
4. ダンプ解析の現場から：S0C4アベンドの真相
夜間バッチが突然 `SYSTEM COMPLETENESS CODE = 0C4` で異常終了したとします。SYSUDUMPやCEEDUMPをひも解くと、PSW（Program Status Word）の指すアドレスと、レジスタの値が睨めっこ状態になります。
アベンドの直接の原因が「ロード命令（LやLHなど）でのアドレス例外」である場合、多くは以下のいずれかです。
1. ポインタ変数が初期化されておらず（ヌルポインタ）、不正なアドレス（例: `00000004` など）を参照した。
2. `UNALIGNED` 指定を忘れた、あるいは外部インターフェースのレイアウト変更により、期待したオフセット位置からズレたアドレスのデータを `ALIGNED` としてロードしようとした。
メインフレームのアーキテクチャでは、アドレスレジスタの偶数・奇数チェックはハードウェアレベルで行われます。PL/Iのランタイム（Language Environment – LE）は優秀ですが、ポインタの生のアドレス操作におけるミスまでは防いでくれません。ダンプ上のレジスタ値と、コンパイルリストのオフセットマップを突き合わせ、「今、何バイト目のメモリを読み込もうとしてクラッシュしたのか」を特定するスキルは、シニアアーキテクトにとって必須の技量です。
—
5. 埋め込みSQL（DB2）およびCICSオンラインにおける実務的注意点
最後に、実務で頻発するDB2やCICSとの連携におけるエッジケースに触れておきましょう。
DB2ホスト変数とアライメント
COBOLやPL/IからDB2を叩く際、ホスト変数を定義します。
1
DCL HV_EMP_ID FIXED BIN(31);
DB2のプリコンパイラは、生成されるC言語等のコードや内部制御構造において、フルワード境界を前提としています。もしホスト変数の定義で不適切なストレージ割当やアライメント崩れが発生していると、SQLの実行時にSQLCODE -180や、予期せぬマイナーコードを返されることがあります。特に、大規模な構造体をそのままホスト変数構造体（`HOST-STRUCTURE`）としてDB2に渡す場合は、必ず `ALIGNED` で統一し、パディングの存在を意識したレイアウト設計が不可欠です。
CICSにおけるCOMMAREAのパディング
CICSのタスク間でデータを引き渡す `COMMAREA` は、単なるバイト列（CHARの連続）として扱われます。ここに `FIXED BIN` を混在させる場合、送信側と受信側（あるいはPL/IプログラムとCOBOLプログラムの間）で `ALIGNED` / `UNALIGNED` の解釈が異なると、データのズレが発生します。
鉄則: CICSのCOMMAREAや外部ファイルI/Oでやり取りする構造体は、アライメント依存のパディングによる予期せぬズレを防ぐため、可能な限り `UNALIGNED` を明示するか、あるいはすべて基本データ型（文字型や明確にサイズが保証された領域）に分解して扱う設計にすべきです。
—
結びに代えて
PL/Iの `FIXED BINARY` とアライメントの挙動は、一見すると過去の遺物のような面倒な制約に見えるかもしれません。しかし、その裏側には「ハードウェアの性能を1滴残らず絞り出す」という、メインフレームの歴史が積み上げてきた合理的な思想が宿っています。
これからレガシーシステムをJavaや最新のクラウド環境へ移行（モダナイゼーション）するにあたり、現行のPL/Iプログラムがなぜこのようなメモリ配置になっているのかを理解していないと、データ移行フェーズや結合テストで「原因不明の文字化け」「数値の化け」「理由の分からないパフォーマンス劣化」という名のモンスターに足元をすくわれることになります。
コードの表面をなぞるだけでなく、コンパイラの裏側でメモリがどう呼吸しているか――そこまで見通すことのできるアーキテクトであり続けたいものです。
