【現場の鉄則】PL/Iの「SUBSTR」は単なる切り出し関数にあらず ― 左辺値としての破壊的威力と、その代償
メインフレームの保守現場で、若手エンジニアから「SUBSTR関数でなぜか値が化ける」という相談を受けるたびに、私は決まってこう答える。「PL/IのSUBSTRは、単なる文字列操作の道具じゃない。メモリの特定領域を直接叩く『外科手術用のメス』だと思え」と。
今日は、多くのエンジニアが「読み取り専用」と誤解しがちな、SUBSTR関数の左辺値利用（Pseudo-variable）について、その内部動作と実務上のリスクを深掘りしていく。
—
1. SUBSTR関数：切り出しだけではない「代入」の仕組み
一般的な言語では、文字列の特定位置を書き換えるには一時的なバッファを作るか、文字列結合を繰り返す必要がある。しかし、PL/Iは古くからメモリ直結型の設計思想を持っており、`SUBSTR(target, start, length) = source;` という記述が言語仕様として許されている。
これは、コンパイラが `target` 変数のベースアドレスに `start` 分のオフセットを足し、`length` 分の長さをターゲットとしてメモリを直接上書きする命令を生成することを意味する。つまり、一時的な中間領域を介さない、極めて高速かつ直接的なメモリ操作だ。
/i
/ — コード例：SUBSTRを左辺値として使用するケース — /
DCL WORK_AREA CHAR(20) INIT(‘IBM-MAINFRAME-SYSTEM’);
/ 6バイト目から始まる’MAINFRAME’を’Z-SERIES’で上書きする /
/ 期待値: ‘IBM-Z-SERIES-SYSTEM’ /
SUBSTR(WORK_AREA, 6, 9) = ‘Z-SERIES ‘;
/
- ポイント:
- WORK_AREAの中身が直接書き換わる。
- 転送元の文字列が短い場合、残りは空白で埋められる仕様。
- C言語のstrncpyのような「NULL終端」を気にする必要はない。
/
—
2. なぜ「境界外アクセス」が起きるのか？
ここからが現場のトラブルシューティングの本題だ。SUBSTRを左辺値として使う際、最も恐ろしいのは「指定した範囲が、元の変数の領域を超えてしまうケース」である。
例えば、`DCL STR CHAR(10);` に対して `SUBSTR(STR, 5, 10) = ‘1234567890’;` と記述した場合、PL/Iコンパイラは（最適化オプションにもよるが）警告を出すか、最悪の場合、メモリ上の隣接領域を容赦なく破壊する。これがバッチ処理における「原因不明のデータ化け」の正体であることが非常に多い。
現場での回避策：ONユニットによるガード
メインフレームの堅牢なコードを書きたいのであれば、こうした境界違反を検知するための`ON条件`を適切に配置すべきだ。
/i
/ — 堅牢なコードのための例外制御 — /
ON ERROR BEGIN;
PUT SKIP LIST(‘警告：メモリ領域外への書き込みが発生しました’);
/ ここでログを出力し、異常終了ではなくダンプを取る等の処理へ /
CALL ABEND_ROUTINE;
END;
/
- 修正案: 範囲チェックを必ず入れること
- 長さ計算を動的に行う場合は、必ず変数の宣言長(STG)と比較するロジックを挟むのが鉄則だ。
/
IF (START + LEN – 1) <= LENGTH(TARGET_VAR) THEN
SUBSTR(TARGET_VAR, START, LEN) = DATA_SOURCE;
ELSE
SIGNAL ERROR;
---
3. VSAMレコード処理における実務的注意点
基幹システムのバッチでは、VSAMのレコードエリアを `BASED` 変数（定義体）でマッピングして操作することが多い。このとき、レコードのフィールドをSUBSTRで書き換えるのは非常に強力だが、一つだけ注意が必要だ。
「構造体の配置とメモリ境界」だ。
PL/Iの `ALIGNED` 属性やコンパイラのパディング（詰め物）を意識せず、レコードのオフセットを勘で指定してSUBSTRで上書きすると、パディング領域を書き換えてしまい、後続のプログラムやファイル書き出し時に予期せぬゴミデータが混入することがある。
- 鉄則： VSAMレコードを操作する際は、可能な限り `SUBSTR` でのオフセット指定ではなく、`DEFINED` 属性を使ってフィールドを構造体として定義し、名前でアクセスせよ。どうしてもSUBSTRを使う必要がある場合のみ、それは「例外的な処理」として明確なコメントを残すこと。
—
まとめ：アーキテクトからの助言
`SUBSTR` の左辺値利用は、PL/Iの歴史が産んだ「諸刃の剣」だ。
1. 高速である: 文字列操作のオーバーヘッドが最小限。
2. 危険である: メモリ破壊の温床になり得る。
3. 可読性: 乱用すると、どこでどの変数が変わっているのか追跡不能になる。
もし君が今、レガシーコードの改修を担当しているなら、既存コードのSUBSTRを触る前に必ずその変数の定義範囲を確認してほしい。「なぜそこを直接書き換える必要があるのか？」という問いを常に持ち、もしそれが安全でないなら、迷わず定数や新しいワークエリアへの退避を検討すべきだ。
メインフレームのシステムは、こうした「一見地味だが、一つ間違えればシステム全体を沈める」ような細かい仕様の積み重ねで動いている。その細部にこそ、エンジニアとしての矜持を持って向き合ってもらいたい。
