境界調整の美学と罠：PL/IにおけるALIGNとUNALIGNEDの深淵
メインフレームのアーキテクチャに長く身を置いていると、現代の高級言語がいかに「メモリの物理的な姿」から乖離しているかを痛感する。PL/Iは、その設計思想においてハードウェアの構造と極めて親密だ。特に`ALIGN`と`UNALIGNED`の扱いは、単なるストレージの節約術を超え、CPUのメモリアクセスサイクルを支配する「職人の領域」である。
今回は、この属性が基幹システムの安定性と性能にどう直結するのか、そしてマイグレーション時に我々を待ち受ける地雷原について語ろう。
1. ALIGN vs UNALIGNED：速度か、密度か
IBM Zアーキテクチャにおいて、命令がメモリ上のデータをフェッチする際、データが「境界（Boundary）」に揃っていることは極めて重要だ。
- ALIGN（デフォルト）: データをハードウェアのワード境界に合わせる。アクセスは高速だが、メモリ上に「隙間（パディング）」が生じる。
- UNALIGNED: データを詰め込む。メモリ消費は最小化されるが、CPUが非境界データを読み出す際、内部で余分なサイクルを消費し、最悪の場合は性能劣化を招く。
大規模バッチの勘定系処理などで、数百万件のレコードをメモリ上に展開する場合、この数バイトの差が「メモリ不足（S0C4やS0C5の遠因）」を招くか、あるいは「CPU時間の超過」を招くかの二択となる。
1
/ 構造体によるストレージレイアウトの比較 /
DCL 1 SAMPLE_DATA ALIGNED,
2 ID FIXED BIN(31), / 4バイト境界に配置 /
2 VALUE FIXED DEC(7,2); / 境界調整のためパディングが発生 /
DCL 1 COMPACT_DATA UNALIGNED,
2 ID FIXED BIN(31),
2 VALUE FIXED DEC(7,2); / 詰め込まれるためパディングなし /
2. 実務の現場で遭遇する「地雷」
パックデシマルの符号反転バグ
`UNALIGNED`属性で定義した構造体を、そのままDB2のテーブルやVSAMファイルへ書き出す際、あるいは外部システムとのインターフェースで用いる際、最も恐ろしいのはパックデシマル（`FIXED DEC`）の内部表現だ。
特に、`UNALIGNED`構造体内でパックデシマルが予期せぬ境界に配置されると、`COMPARE LOGICAL`命令などで符号（Sign）ビットが意図せず書き換わるケースがある。これは、コンパイラが境界調整のために挿入するバイト列が、既存のデータと重なるようなポインタ操作を行った場合に顕著だ。
ポインタ操作とアベンドの解析
ポインタ変数を使い、`BASED`変数で領域をマッピングする際、`ALIGN`を意識しないコーディングは、`S0C7`（データ例外）よりも厄介な`S0C4`（保護例外）を引き起こす。特に、CICS環境下でのポインタ操作は致命的だ。
1
/ ポインタを用いた動的メモリ操作の例 /
DCL P_REC POINTER;
DCL MY_REC BASED(P_REC) ALIGNED;
/ 領域の確保時にALIGNを考慮しないと、後続のアクセスで
境界違反が発生し、S0C4でダウンするリスクがある /
ALLOCATE MY_REC;
/ 読み取り専用のバッファをマップする際は特に注意が必要 /
/ 外部から渡されたアドレスにUNALIGNED構造体を被せると
CPUが非境界アクセスを強いられ、性能が数割落ちることもある /
3. マイグレーションへの提言：Java/C#への架け橋
今、PL/IからJava等へコードを書き換える際、多くの若手エンジニアが「同じ変数型なら挙動も同じ」と誤解している。しかし、JavaのメモリレイアウトはJVMが抽象化しており、PL/Iのような「物理的な詰め込み」を明示的に制御することはできない。
もし、貴殿が移行設計を担うのであれば、以下の点を確認してほしい。
1. データ構造の等価性: `UNALIGNED`で設計されたVSAMレコードは、Java側でそのままバイナリ読み込みするとオフセットがずれる。これを補完する設計（`ByteBuffer`での明示的パディング処理など）が不可欠だ。
2. パックデシマルの扱い: Javaには標準でパックデシマルがない。`BigDecimal`への変換ロジックを挟む際、符号処理がPL/Iのハードウェア実装と一致しているか、単体テストで徹底的に検証すること。
3. コンパイラオプションの再確認: 既存のPL/Iソースが`LIMITS(FIXEDBIN(31))`なのか、`ALIGN`がデフォルトで付与されているかを確認せよ。古いコードほど、コンパイラのデフォルト設定に依存した「暗黙の仕様」が潜んでいる。
結びに代えて
システムアーキテクトにとって、コードは単なるロジックの羅列ではない。それはCPUとメモリの間で行われる、極めて物理的で官能的な対話だ。`ALIGN`や`UNALIGNED`というたった一つの属性に拘泥することは、決して古臭いこだわりではない。それは、基幹システムという巨大な獣を、最短かつ最も効率的に走らせるための「調律」なのである。
次回のブログでは、`OFFSET`変数を用いた動的記憶管理の極意と、それによるメモリリークの温床について深掘りしていく予定だ。現場のエンジニア諸氏には、ぜひ一度自身のコンパイルリストの「STORAGE MAP」を眺め直す時間を取ってみてほしい。そこには、君たちがこれまで見て見ぬふりをしてきた、ハードウェアとの会話が記録されているはずだ。
