メインフレームの深淵：PL/Iにおけるアライメント戦略と、その「見えない代償」
メインフレームの現場で長くPL/Iと向き合っていると、ふとした瞬間に「なぜこの構造体はこんなにメモリを食うのか？」という疑問に突き当たることがあります。特にJavaやC#といったマネージド言語から来たエンジニアが、マイグレーションの設計で最も躓くのが、このALIGNED属性とUNALIGNED属性の境界調整（Alignment）にまつわる挙動です。
これらは単なるメモリ効率の話ではありません。システムが処理する膨大なトランザクションのパフォーマンス、そして不可解なABENDを未然に防ぐための「基幹システムの作法」そのものなのです。
1. アライメントの正体：ハードウェアへの敬意
PL/Iのコンパイラは、デフォルトで`ALIGNED`属性を採用します。これは変数のアドレスを、そのデータ型が最も効率的にアクセスできる境界（ワード境界やダブルワード境界）に配置しようとする挙動です。
/i
DCL 1 SAMPLE_STRUCT ALIGNED,
2 FIELD_A FIXED BIN(31), / 4バイト境界に配置される /
2 FIELD_B CHAR(1); / ここに3バイトのパディングが自動挿入される /
この「パディング」こそが、メモリ効率を悪化させる犯人です。`FIELD_B`の後に続くデータが意図せず空き領域を埋めてしまい、巨大な配列を定義した瞬間にメモリが枯渇する――これがレガシー移行の設計段階で頻発する見積もりミスの一因となります。
一方で、`UNALIGNED`を指定すれば、パディングを極限まで削ぎ落とせます。しかし、CPUは「端数」にあるデータを取り出すために追加の命令サイクルを消費するため、演算速度は微量ながら低下します。この「メモリの節約 vs 演算の高速化」というトレードオフを、単なるマニュアルの知識ではなく、「対象のデータが億単位のレコードなのか、あるいはリアルタイム性の高いCICSオンライン画面なのか」というビジネスコンテキストで判断するのが、我々アーキテクトの腕の見せ所です。
2. 動的メモリ操作とポインタが引き起こす罠
構造体配列を`BASED`変数としてポインタで操作する際、アライメントの理解が甘いと、データ破壊の温床となります。特にDB2の埋め込みSQLやCICSの通信領域（COMMAREA）で発生するデータ不整合は、原因特定が困難です。
/i
/ 不適切なポインタ計算の例 /
DCL PTR_STRUCT POINTER;
DCL 1 BASED_STRUCT BASED(PTR_STRUCT) UNALIGNED,
2 DATA_VAL FIXED BIN(31);
/ ポインタを動的に進める際、アライメントを無視して加算すると… /
PTR_STRUCT = ADDR(BASE_ARRAY) + OFFSET;
もし`BASE_ARRAY`が`ALIGNED`で定義されている場合、単純なバイト演算でのポインタ加算は、次の構造体の開始位置をずらし、結果としてパックデシマル（FIXED DEC）の符号ビットが隣接データに侵食されるという致命的なバグを誘発します。これによる「パックデシマルの内部符号反転バグ」は、ダンプを取っても原因が即座には見抜けない、メインフレーム特有の悪夢です。
3. ダンプ解析：ABENDを読み解く「眼」
S0C7（データ例外）やS0C4（保護例外）が発生した際、コンパイラの最適化オプションを疑う前に、まずはマッピングを確認してください。
特に、コンパイラオプションの `AGGREGATE` や `MAP` を出力し、実際にコンパイラがどのようにパディングを配置したかを確認することをお勧めします。現場のコードでは、長い年月を経て継ぎ足された`REDEFINE`句が、アライメントを複雑怪奇にしているケースが少なくありません。
- 解決のヒント: 構造体のバイナリダンプを解析する際、16進数で境界を確認してください。もし`FIELD_A`の次のアドレスが4の倍数でなければ、そこには確実にコンパイラが「隠した」パディングが存在しています。
4. マイグレーションへの提言
JavaやC#への移行にあたっては、この「アライメントの非対称性」をアプリケーション層で吸収する必要があります。
1. データ構造の可視化: `UNALIGNED`なPL/I構造体を、そのままJavaの`ByteBuffer`や`Unsafe`クラスで扱おうとすると、境界調整の差異でデータが化けます。移行先では、パディングを明示的にフィールドとして定義する「DTO化」を推奨します。
2. 符号の扱い: パックデシマルの符号反転バグは、Javaの`BigDecimal`への変換ロジックで確実に捕捉・検証してください。
結びに
PL/Iは、ハードウェアの制約をプログラマが直に制御できる、極めて強力な言語です。`ALIGNED`と`UNALIGNED`の使い分けは、単なる仕様の選択ではなく、あなたのシステムが「どこまでハードウェアの性能を絞り出せるか」という意志の表れです。
もし今、あなたの管理するシステムが不可解な挙動を示しているなら、それはコンパイラが「見えないパディング」という名の警告を発しているのかもしれません。その警告を読み解くことが、次の10年も稼働し続ける基幹システムを作るための第一歩です。
