導入
メインフレームのPL/I開発において、構造体（STRUCTURE）の宣言はプログラムのメモリ効率やI/Oパフォーマンスを左右する重要事項です。特に「UNALIGNED」と「ALIGNED」の混在は、電文処理やファイルI/Oの高速化に欠かせないテクニックですが、一括リセットや上位レベルでの属性指定を誤解すると、予期せぬデータ破壊やパフォーマンス低下を招きます。本稿では、この属性オーバーライドルールと、現代的なシステム移行時の注意点を解説します。
基礎知識
メインフレームにおいて、ALIGNEDはデータ境界をCPUのアクセス効率が良い位置に配置する属性であり、UNALIGNEDは境界を無視して詰めて配置する属性です。
通常、電文などの外部インターフェース定義では、メモリを節約するために全体をUNALIGNEDで宣言します。しかし、演算に使用する特定の数値項目だけをALIGNEDにすることで、CPUのロード/ストア効率を向上させる「精密なチューニング」が可能になります。ここで重要なのは、下位レベルの指定が上位レベルの属性を上書きするというルールです。
実装/解決策
構造体の宣言時、最上位階層（レベル1）で属性を指定すると、その配下の全メンバに属性が継承されます。しかし、特定のメンバに対して個別に属性を付与することで、その箇所だけレイアウトを変更可能です。
重要なのは、コンパイラは各メンバの属性に基づいて自動的にパディング（隙間）を挿入するという点です。この仕組みを理解し、特にバイナリデータとして外部へ出力する際は、パディングによってオフセットがずれないよう、レイアウトを厳密に設計する必要があります。
サンプルプログラム
以下のコードは、全体をUNALIGNED（パディングなし）としつつ、特定の数値項目のみALIGNED（境界調整あり）にする実装例です。
/ 構造体の定義例 /
DCL 1 REC_STRUCTURE UNALIGNED,
/ 1バイトのキャラクタ項目（パディングなし） /
2 CHAR_ITEM CHAR(1),
/ 4バイトの数値項目。ALIGNED指定により、必要に応じてパディングが挿入される /
2 NUM_ITEM FIXED BIN(31) ALIGNED;
/ 処理ロジック /
/
注意：この宣言により、NUM_ITEMの前には
必要に応じてCPUの境界合わせのためのパディングが挿入されます。
バイナリダンプを確認すると、オフセットが想定と異なる場合があります。
/
応用・注意点
現場で最も注意すべきは、「現代言語（JavaやC#等）への移行時」です。
現代の言語にはPL/Iのような柔軟なパディング制御が標準搭載されていないケースが多く、バイナリシリアライザを自作する際には、各メンバ間の物理的なオフセットを開発者が自ら計算し、管理する必要があります。
特に、以下の点に注意してください。
1. パディングの自動挿入を過信しない：外部システムとバイナリ連携する際は、各項目のオフセットを「1バイト単位」で設計書に明記してください。
2. 属性一括リセットの副作用：上位階層で属性を変更した際、配下の全メンバのオフセットが芋づる式に変わる可能性があります。修正後は必ずアセンブラレベルのダンプを確認し、レイアウトの妥当性を検証してください。
この「精密なチューニング」は強力な武器ですが、設計が複雑化するリスクと表裏一体であることを忘れないでください。
コメント