メインフレームの深淵：多次元配列の「メモリ配置」と最適化の真実
現場の諸君、お疲れ様。今日も今日とて、数千万行におよぶレガシーソースコードの海に潜っていることだろう。
PL/Iという言語は、一見すると古臭い手続き型言語に見えるかもしれない。しかし、そのメモリ管理の精緻さと、最適化コンパイラの挙動を理解すれば、これほどバッチ処理のボトルネック解消に威力を発揮する武器はない。今回は、多くのエンジニアが「なんとなく」使いがちな多次元配列のストレージ配置と、それがパフォーマンスにどう直結するかについて、現場の視点から紐解いていく。
—
1. 多次元配列の「行優先（Row-Major）」という宿命
PL/Iにおいて、`DECLARE A(10, 20) FIXED BIN(31);` と定義した場合、メモリ上ではどう並ぶか。結論から言えば、「右側の添字が最も速く変化する」、いわゆる「行優先（Row-major）」順序で配置される。
これは、C言語などのモダンな言語と同じだが、メインフレームのバッチ処理において重要なのは、「アクセス順序がメモリ配置と一致しているか」だ。
/i
/ 多次元配列のアクセス効率を考慮したコーディング例 /
DECLARE ARR(100, 100) FIXED BIN(31);
DECLARE (I, J) FIXED BIN(15);
/ 悪い例：行優先順序に逆らってアクセスしている /
/ 内側のループでIを回すと、メモリを大きくジャンプするためキャッシュ効率が最悪 /
DO I = 1 TO 100;
DO J = 1 TO 100;
ARR(J, I) = 0;
END;
END;
/ 良い例：メモリの連続性を最大限に活かす /
DO I = 1 TO 100;
DO J = 1 TO 100;
ARR(I, J) = 0; / メモリを順次なぞるため、最適化が効きやすい /
END;
END;
もし君たちの保守しているバッチ処理で「CPU時間が異常に長い」という現象があれば、まずこのネスト順序を疑え。コンパイラは優秀だが、メモリの物理的な飛び越し（ページフォールトやキャッシュミス）を完全に隠蔽することはできない。
—
2. コンパイラによるオフセット計算の裏側
PL/Iのコンパイラは、`ARR(I, J)` のアドレスを算出する際、以下の論理式を内部的に組み立てている。
`BaseAddress + ( (I – LowerBound1) Extent2 + (J – LowerBound2) ) ElementSize`
ここで重要なのは、`Extent`（次元の大きさ）が定数であれば、コンパイラはこれらをシフト演算や加算の組み合わせへと極限まで最適化するということだ。逆に、`DIMENSION()` を使った引数引き渡し（可変長配列）の場合、この計算は「実行時の動的アドレス算出」になるため、わずかながらオーバーヘッドが生じる。
高頻度で呼ばれるサブルーチン内の配列アクセスであれば、できる限り次元のサイズを固定し、コンパイラに「定数」として計算させることが、秒単位の短縮に繋がる。
—
3. 実践：VSAM入出力とONユニットの制御
多次元配列を使う場面は、大抵の場合、VSAMファイルから読み込んだレコードの集計や、突き合わせ作業だろう。ここで注意すべきは、`ON ENDFILE` や `ON ERROR` のスコープと、配列の初期化タイミングだ。
/i
MAIN_PROC: PROCEDURE OPTIONS(MAIN);
/ VSAM読み込み用構造体と集計用配列 /
DCL 1 VSAM_REC,
5 KEY_ID CHAR(4),
5 DATA_VAL FIXED BIN(31);
DCL STAT_TBL(10, 100) FIXED BIN(31) INIT((1000)0); / 初期化は必須 /
ON ENDFILE(VSAM_FILE) BEGIN;
PUT SKIP LIST(‘全レコードの処理完了’);
GOTO FINISH;
END;
OPEN FILE(VSAM_FILE) INPUT;
DO WHILE(‘1’B);
READ FILE(VSAM_FILE) INTO(VSAM_REC);
/ ここでデータの妥当性チェックを行う /
IF DATA_VAL < 0 THEN SIGNAL ERROR;
/ インデックス計算を伴う配列更新 /
STAT_TBL(SUBSTR(KEY_ID,1,1), DATA_VAL/10) += 1;
END;
FINISH:
CLOSE FILE(VSAM_FILE);
END MAIN_PROC;
ここで重要なのは、`ON ERROR` ユニットがトリガーされた際、どこで `GOTO` するかだ。安易に `STOP` を呼ぶと、ファイルのクローズ処理がスキップされ、VSAMの不整合を招く恐れがある。必ずクローズ処理を通る制御フローを意識すること。
---
先輩エンジニアからの助言
最後に、バッチ改修時のトラブルシューティングの極意を授けよう。
1. 境界値チェックを怠るな: `DIMENSION` を超えたアクセスは、PL/Iでは即座に異常終了（ABEND）とは限らない。隣接する変数領域を破壊し、数ステップ後に全く関係のない場所でエラーが出る「サイレント・データ・コラプション」が最も恐ろしい。開発環境では `CHECK(SUBSCRIPTRANGE)` オプションを必ず有効にしてテストを行うこと。
2. BUILTIN関数の活用: `HBOUND` や `LBOUND` を使え。配列のサイズをマジックナンバーでハードコーディングするな。将来的な配列サイズの拡張があったとき、ソースの修正漏れで致命傷を負うのは君たちだ。
PL/Iは古い言語だが、その設計思想には「計算機資源をいかに効率的に使い切るか」というエンジニアの矜持が詰まっている。メモリの配置を意識し、コンパイラの挙動を予測できるようになれば、君はもう一人前のメインフレームアーキテクトだ。
現場で何か行き詰まったら、いつでもマニュアルの「言語参照」に戻ってこい。そこには、教科書以上の真実が書かれているはずだ。健闘を祈る。
