メインフレームの深淵：PL/IにおけるALIGNとUNALIGNEDがシステム性能に与える真実
メインフレームの現場で長く生き残っていると、「なぜこのプログラムは計算速度が遅いのか」「なぜ移行先のJavaで数値精度がずれるのか」という問いに直面する。その答えの多くは、現代の言語仕様からは隠蔽されてしまった、メモリレイアウトの設計思想に帰結する。
PL/Iが誇る強力なデータ制御能力、特に`ALIGN`と`UNALIGNED`属性は、単なるストレージの節約術ではない。これはハードウェアのバスアクセス効率と、CICSやDB2といったミドルウェアとのインターフェース品質を左右する、システムアーキテクトの腕の見せ所だ。
1. ALIGN vs UNALIGNED：境界調整の物理学
PL/Iのコンパイラは、デフォルトで変数を「境界調整（Alignment）」する。これは、4バイトや8バイトの境界にデータを配置することで、CPUが単一の命令サイクルでデータをロードできるようにする機構だ。
/i
/ デフォルトではALIGN属性が付与される /
DCL 1 WORK_AREA,
2 FIELD_A FIXED BIN(31), / 4バイト境界に配置される /
2 FIELD_B CHAR(1); / 続くフィールドも境界調整の影響を受ける /
/ UNALIGNEDはメモリを詰め込む。バッファ通信やファイル出力で多用される /
DCL 1 PACKED_RECORD UNALIGNED,
2 ID CHAR(8),
2 AMOUNT FIXED DEC(7, 2); / 境界を無視して連続配置 /
なぜこれが重要なのか
`ALIGN`はCPUのロード時間を最適化するが、構造体全体ではパディング（隙間）が多くなり、メモリを浪費する。一方、`UNALIGNED`はストレージを節約し、外部システムとの通信用コピーブックとレイアウトを一致させるために不可欠だ。
しかし、注意が必要だ。`UNALIGNED`のデータを、`ALIGN`を前提としたサブルーチンや、特定のインライン・アセンブラルーチンへポインタ経由で渡すと、S0C4（保護例外）やS0C7（データ例外）の引き金になる。CPUが奇数アドレスから境界調整を要する命令を実行しようとした瞬間、システムは無慈悲にアベンドする。
2. 実務の罠：パックデシマルの符号反転とDB2連携
基幹システムのマイグレーションにおいて、最も「血」を流すのが`FIXED DEC`（パックデシマル）の扱いだ。
PL/Iの`FIXED DEC`は、内部的にニブル（4ビット）単位で数値を保持する。メインフレームのIBM z/Architectureでは、符号（S）は末尾の4ビットに格納される。Java等へ移行する際、この構造をそのままバイト配列として読み込むと、符号ビットの解釈違いで数値が反転したり、予期せぬ値に化けたりする。
特にDB2の埋め込みSQL（EXEC SQL）を使用している場合、ホスト変数の定義には注意を払わねばならない。
/i
/ DB2連携時の正しいホスト変数定義 /
DCL :HV_AMOUNT FIXED DEC(15, 2);
/
- 陥りやすい罠：
- ポインタを用いて領域を動的に確保し、外部からデータを流し込む際、
- 構造体がUNALIGNEDであると、DB2が期待するデータ境界からズレが生じ、
- SQLCODE -802（算術例外）や、データ変換エラーを引き起こす。
/
3. ダンプ解析から読み解く最適化の勘所
もしあなたが、実行中のバッチが突然アベンドした際、ダンプリストの「OFFSET」だけを見て満足しているなら、それはアーキテクトとしては未熟だ。
PL/Iのダンプ解析で見るべきは、「スタック上の引数渡しが期待する境界と、実際のデータ配置の不一致」である。特に、`OPTIONS(MAIN)`で定義されたエントリーポイントから呼び出されるサブルーチン間で、異なるコンパイルオプション（例えば片方がデフォルト、もう片方が`UNALIGNED`）が混在している場合、引数のポインタが指し示す先の値が、期待したバイト数だけずれていることがある。
トラブルシューティングの鉄則
1. コンパイラ・リスティングの確認: `MAP`オプションを付与して出力し、各変数がどのオフセットに配置されているかを視覚的に確認せよ。
2. ポインタのアドレスチェック: `ADDR(var)`を使って、期待する境界（4バイト境界ならアドレスの下位2ビットが0）にあるかを確認するデバッグコードを一時的に仕込む。
3. CICSの通信エリア(DFHCOMMAREA): これを扱う際は必ず`UNALIGNED`を明示せよ。さもなくば、COBOLで書かれた別のプログラムとの間でデータの断絶が起きる。
結論：技術の「詰め」がシステムの「寿命」を決める
現代のクラウドネイティブな開発環境では、メモリ境界やポインタを意識する必要はない。しかし、メインフレームという過酷な環境で、数百万行のコードを24時間365日止めずに動かし続けるためには、この「泥臭いメモリ制御」の理解が不可欠だ。
`ALIGN`と`UNALIGNED`は、単なるキーワードではない。それは、ハードウェアの能力を極限まで引き出すための「設計図」そのものなのだ。これからマイグレーションを担う諸君には、単なる構文変換に終始せず、データが物理的にどう配置され、CPUがどう処理しているのか、その裏側の「息遣い」を感じ取れるエンジニアであってほしい。
それが、レガシーを「負債」ではなく「資産」として次世代へ継承するための、唯一の道である。
