導入：なぜデータ宣言の「一致」が重要なのか
メインフレームでのバッチ処理において、構造体同士の代入（MOVE CORRESPONDINGや直接代入）は日常的な操作です。しかし、何気なく記述したプログラムが、実はパフォーマンスの「隠れたボトルネック」になっていることがあります。その原因の多くが、データ属性である「ALIGNED」の不一致です。この属性が一致していない場合、システムはメモリ上のデータを効率よく一度に転送できず、メンバ単位で一つずつ書き出すという非効率な動作を強いられます。本稿では、データ宣言の制約を理解し、実行速度を最大化するための原則を解説します。
基礎知識：ALIGNEDとは何か
ALIGNED属性とは、データ項目をメモリ上の境界（境界調整）に配置するようコンパイラに指示するものです。メインフレームのアーキテクチャでは、データが特定の境界（ハーフワードやフルワードなど）に配置されていると、CPUが一度の命令で読み書きできる確率が高まります。逆にUNALIGNED属性は、メモリを節約するために境界を無視して詰め込む指定です。これらが混在した状態で構造体代入を行うと、コンパイラは型が一致しないと判断し、ハードウェアによる高速なブロック移動（MVC命令など）を諦め、ソフトウェアレベルでの個別転記に切り替えてしまいます。
実装と解決策：属性の統一原則
大規模なデータを扱う構造体では、必ず「ALIGNED」属性を明示的、またはデフォルト設定として統一することが重要です。構造体の先頭から末尾まで、すべてのメンバが同じ境界規則に従っていることで、コンパイラはコンパイル時に効率的な「一括転記命令」を生成できるようになります。移行解析ツール等を使用し、代入処理が内部で個別の転記ループに分解されていないかをチェックすることが、性能チューニングの第一歩です。
サンプルプログラム：高速代入のための構造体定義例
以下は、ALIGNED属性を揃え、最適化を促進するためのPL/Iの構造体定義例です。
/ 構造体AとBでALIGNED属性を明示的に一致させる /
/ この定義により、コンパイラは一括転記命令を生成可能になる /
DCL 1 SOURCE_DATA ALIGNED,
2 ID FIXED BIN(31), / 4バイト境界に配置 /
2 VALUE FIXED BIN(31), / 連続する4バイト境界 /
2 FLAG CHAR(4); / 境界を意識したデータ配置 /
DCL 1 TARGET_DATA ALIGNED LIKE SOURCE_DATA;
/ 以下の代入は、内部的に効率的なブロック転記（MVC等）に最適化される /
TARGET_DATA = SOURCE_DATA;
/ 注意：以下のように一方がUNALIGNEDだと、性能が著しく低下する /
/ DCL 1 BAD_DATA UNALIGNED, … /
応用・注意点：現場で役立つ補足情報
現場での開発において陥りやすい罠は、COPY句でインクルードした構造体に、予期せずUNALIGNEDが混入することです。特に古いレガシー資産から流用したデータ定義には、メモリ節約重視のUNALIGNEDが指定されていることが多々あります。
1. 属性の継承を確認せよ：構造体の一部を変更する際は、上位の属性が下位にどう影響しているか（DEFAULT属性の設定）を必ず確認してください。
2. トレースの活用：どうしても性能が出ない箇所は、コンパイラが生成したリスト（生成コード）を確認し、代入部分が「MOVE」系の単一命令になっているか、あるいはサブルーチン呼び出しに変換されていないかを観察してください。
3. メモリとのトレードオフ：ALIGNEDはメモリ消費量が増える傾向にあります。しかし、現代のメインフレーム環境では、メモリ量よりもCPU時間（MIPS）の削減がコストに直結するため、基本的にはALIGNEDによる高速化を優先すべきです。
この「階層的一致の原則」を守るだけで、大規模バッチ処理の実行時間を大幅に短縮できる可能性があります。ぜひ次回のコーディング規約見直し時に役立ててください。
コメント