現場で泣かないためのPL/I：DIM関数と動的配列の「深い」関係
若手から「配列のサイズを動的に判定したいのですが、DIM関数でうまく値が取れません」という相談をよく受ける。メインフレームのバッチ改修で、汎用的なサブルーチンを設計しようとすると必ず突き当たる壁だ。
今日は、PL/Iにおける`DIM`（および`HBOUND`、`LBOUND`）ビルトイン関数、特に「アスタリスク（）指定された引数」をどう扱うか、実務的な視点で深掘りしよう。
1. なぜ「DIM関数」で躓くのか
まず基本を押さえておこう。`DIM(X, 1)`は配列`X`の第1次元の要素数を返す。だが、ここには落とし穴がある。もしその配列が、プロシージャの引数として`() CHARACTER(10)`のように「境界が不定」で渡されている場合、コンパイラはコンパイル時にサイズを確定できない。
これがなぜ重要か？ それは、`DIM`関数は実行時に記述子（Descriptor）を参照して値を算出しているからだ。このメカニズムを理解していないと、VSAMファイルから読み込んだ可変長レコードの処理や、動的メモリ確保（`ALLOCATE`文）を行う際に、とんでもないバグを埋め込むことになる。
2. 実践コード：アスタリスク指定引数の扱い方
以下のサンプルコードを見てほしい。大規模なバッチ処理で、多様なサイズを持つ配列を一つのサブルーチンで受け取りたい場合の定石だ。
/i
/——————————————————————-/
/ サブルーチン：配列の内容をダンプし、サイズを判定する /
/——————————————————————-/
SUB_PROCESS: PROCEDURE(P_ARRAY);
/ 引数の配列は境界を()で受け取り、記述子情報を保持させる /
DCL P_ARRAY() CHAR(10) BASED;
DCL I BIN FIXED(31);
DCL CURRENT_DIM BIN FIXED(31);
/ DIMビルトイン関数で現在の要素数を動的に取得 /
CURRENT_DIM = DIM(P_ARRAY, 1);
PUT SKIP LIST(‘配列の要素数は: ‘ || TRIM(CHAR(CURRENT_DIM)));
DO I = LBOUND(P_ARRAY, 1) TO HBOUND(P_ARRAY, 1);
/ 境界チェックを厳密に行うのがメインフレーム流 /
PUT SKIP LIST(‘INDEX ‘ || I || ‘ : ‘ || P_ARRAY(I));
END;
END SUB_PROCESS;
3. トラブルシューティングの勘所
現場でよくある失敗ケースと、その回避策を伝授する。
- 境界オーバーフローとONユニット:
`DIM`で取得した値を使ってループを回す際、もし配列の添字が1から始まると決めつけてコードを書くと、`LBOUND`が0や負の値をとる配列が渡された瞬間に`SUBSCRRG`（添字範囲外エラー）が発生する。必ず`LBOUND`と`HBOUND`をセットで使い、`ON SUBSCRRG`ユニットで異常系をハンドリングする癖をつけておけ。
- VSAMレコードとの相性:
`READ`文でVSAMから構造体を読み込む際、その構造体の中に配列が含まれていると、`DIM`は「定義された最大サイズ」を返す。動的に入力されたレコードの有効データ数と混同してはならない。有効データ数は必ず別途カウンターを持たせること。
- 最適化の影響:
稀にコンパイラの最適化オプション（`OPT(3)`など）によって、ループ内の`DIM`評価がループ不変式とみなされ、期待した動作をしないことがある。どうしても動的に評価させたい場合は、`VOLATILE`属性を検討するのも一つの手だが、まずはコード構造を見直すのが先決だ。
4. 最後に：なぜ「今」PL/Iなのか
今、レガシー移行のプロジェクトで多くのエンジニアが苦労しているのは、言語仕様の表面的な暗記ではなく、「メモリ配置」と「記述子」という、プログラムの裏側にある「作法」を理解していないことにある。
PL/Iは、高級言語でありながら、アセンブラに近い柔軟性を併せ持つ言語だ。`DIM`関数一つとっても、それが単なる数字の取得ではなく、コンパイラが生成した隠れた記述子へのアクセスであることを理解すれば、デバッグのスピードは劇的に変わる。
「動かない」と悩む時間は、システムアーキテクチャの根幹を学ぶチャンスだ。次回の改修では、ぜひ`DIM`関数の戻り値がどこから来ているのか、コンパイラのリスト出力を眺めながら、その奥深さを堪能してみてほしい。
—
現場のエンジニア諸君、今日もメインフレームの安定稼働を支える良いコードを。何かあれば、またいつでも聞いてくれ。
