「なぜSUBSTRの重複で化けるのか？」――PL/Iのメモリ管理とポインタ演算の深淵
現場の諸君、今日もVSAMのレコードレイアウトと格闘しているか？
PL/Iという言語は、C言語のような「ポインタ万能主義」と、COBOLのような「堅牢なビジネスロジック」の狭間に存在する、非常にユニークな立ち位置にある。特に、今回テーマにする`SUBSTR`関数は、一見すると単なる文字列切り出しの便利なツールに見えるが、その裏側ではコンパイラが「メモリの安全」と「パフォーマンス」の血みどろの駆け引きを行っている。
今日は、なぜ`SUBSTR`のターゲットとソースが重複した際に予期せぬ挙動（あるいはパフォーマンスの低下）が起きるのか、その内部構造を紐解いていこう。
1. 予約語なき自由と、それに伴う「自己責任」の代償
まず大前提だが、PL/Iには「厳密な予約語」が存在しない。これは非常に強力だが、裏を返せば「`IF`という変数を作ることすら物理的には可能（推奨はしないが）」という、言語設計上の猛烈な柔軟性を意味している。
この設計思想は`SUBSTR`の処理にも如実に表れている。`SUBSTR`は単なる組み込み関数ではなく、代入の左辺値にもなれる「擬似変数（Pseudovariable）」としての顔を持つ。
/i
/ ソースとターゲットが重複する場合の典型的な例 /
DCL STR_VAL CHAR(20) INIT(‘ABCDEFGHIJ’);
/ STR_VALの先頭3文字に、STR_VALの4文字目から3文字をコピーする /
/ 実務では、データの左詰め処理などで頻発するパターンだ /
SUBSTR(STR_VAL, 1, 3) = SUBSTR(STR_VAL, 4, 3);
このとき、コンパイラはどう動くか。もし単純にメモリアドレスを左から順にコピーすると、コピー先が未処理のコピー元を上書きしてしまい、データが破壊される。これを防ぐために、コンパイラは「一時領域（Temporary Storage）」を密かに確保するのだ。
2. 内部的な一時領域確保とパフォーマンスの罠
`SUBSTR(A, 1, 3) = SUBSTR(A, 4, 3)` のようなステートメントに遭遇したとき、PL/Iコンパイラは以下の内部処理を走らせる。
1. 重複判定: ターゲットのメモリ領域とソースのメモリ領域が重なっているかを静的・あるいは動的に判定する。
2. 一時領域の確保: 重なりがあると判断された場合、スタック領域（あるいはコンパイラが管理するワークエリア）に一時的なバッファを確保する。
3. 転送処理: 一旦バッファにソースを退避させ、そこからターゲットへコピーする。
ここで注意が必要なのは、この「一時領域の確保」がバッチ処理のループ内で何百万回も発生する場合だ。
メインフレームの基幹バッチで、数百万件のVSAMレコードを処理する際、この「隠れた一時領域確保」がオーバーヘッドとなり、CPU時間を押し上げる要因になる。デバッグ時のダンプやトレースで、なぜか処理が重いと感じたときは、この「内部的なコピーによるメモリ消費」を疑うべきだ。
3. 実践的なコーディング・ベストプラクティス
では、現場でどう書くのが正解か。安全かつ高速に書くための鉄則を紹介する。
/i
PROC OPTIONS(MAIN);
DCL WS_RECORD CHAR(100) BASED(P_RECORD);
DCL P_RECORD POINTER;
DCL WORK_BUF CHAR(100);
/ VSAMからの読み込みを想定 /
/ READ FILE(VSAM_FILE) INTO(WS_RECORD); /
/ [推奨]: 重複を避けるためにワーク変数経由にする /
/ これによりコンパイラは一時領域を確保せず、直接メモリ転送ができる /
WORK_BUF = SUBSTR(WS_RECORD, 5, 10);
SUBSTR(WS_RECORD, 1, 10) = WORK_BUF;
/ ONユニットによるエラーハンドリングは必須 /
ON CONVERSION BEGIN;
PUT SKIP LIST(‘データ変換エラーが発生しました。入力データを確認せよ’);
SIGNAL FINISH;
END;
END;
なぜワーク変数を使うべきなのか？
1. コンパイラの最適化を阻害しない: ワーク変数を使うことで、コンパイラは「ここには重複がない」と確信でき、インライン展開や効率的な機械語生成を優先できる。
2. 保守性の向上: 誰が見ても「どこからどこへデータを移しているか」が明確になる。複雑なポインタ演算（`ADDR(X) + OFFSET`など）を隠蔽するのは、後から解析する担当者への優しさだ。
最後に：メインフレームエンジニアの矜持
PL/Iのコードを美しく保つことは、単なる自己満足ではない。それは、数十年前に書かれたコードが今もなお、銀行の勘定系や保険の契約管理を支えているという「責任」そのものだ。
`SUBSTR`の内部挙動を知ることは、メモリの配置を知ること。メモリを知ることは、システム全体の挙動を制御できるということだ。エラーが起きたとき、「仕様です」とマニュアルを引用して逃げるのではなく、「コンパイラが裏でこう動いているから、こう修正すべきだ」と断言できるエンジニアを目指してほしい。
次回は、`ON CONVERSION`ユニットと`SIGNAL`ステートメントを用いた、堅牢なエラーハンドリング戦略について深掘りしよう。それでは、今夜のバッチジョブが正常終了することを祈っている。
