PL/Iの深淵：INDEX関数とハードウェア最適化、そしてレガシー移行の「罠」
メインフレームの現場で長く生きていると、現代の高級言語がいかに「ブラックボックス」に頼っているかを痛感させられます。PL/Iは、その言語仕様自体がハードウェアの挙動を直接的に反映するよう設計されており、特に文字列操作における`INDEX`組み込み関数の挙動は、その典型例と言えるでしょう。
今日は、単なる文法解説ではなく、この関数がなぜ最強であり、移行時にどこで足をすくわれるのか、アーキテクトの視点で紐解きます。
1. 予約語なき自由と、コンパイラの「忖度」
PL/IにJavaのような「予約語」が存在しないことは有名です。`IF = THEN + ELSE;` と書けば、コンパイラは文脈からこれらを識別子か演算子かを判断します。これは柔軟性の裏返しですが、マイグレーション時に静的解析ツールを混乱させる元凶でもあります。
`INDEX(STRING, SEARCH_STR)` を叩く際、PL/Iコンパイラは単なるループを生成しません。最適化オプション（`OPTIMIZE(3)`など）を付与すれば、コンパイラはプロセッサのTRT（Translate and Test）命令やCLC（Compare Logical Character）命令を駆使した、極めて効率的なコードを生成します。
実践的コード：INDEXの活用とエッジケースの罠
1
/ INDEX関数を使用した高速検索の基本 /
DCL SRC_STR CHAR(256) VAR INIT(‘IBM_MAINFRAME_SYSTEM_ARCHITECT’);
DCL TGT_STR CHAR(10) VAR INIT(‘SYSTEM’);
DCL POS FIXED BIN(15);
/ 空文字列や一致なしの挙動を正しく制御する /
POS = INDEX(SRC_STR, TGT_STR);
IF POS = 0 THEN
/ 一致しない場合の戻り値は0。これは厳格に管理すべき仕様 /
PUT SKIP LIST(‘検索文字列が見つかりませんでした’);
ELSE
PUT SKIP LIST(‘ヒット位置:’ || TRIM(CHAR(POS)));
ここで重要なのは、「検索対象が空文字列（”）の場合、戻り値は1である」というPL/Iの仕様です。C#の`IndexOf`とは挙動が異なるため、移行先でこの判定ロジックを直書きしていると、バッチの先頭処理で予期せぬ挙動を引き起こします。
2. メモリ操作とポインタ：ダンプを読み解く力
基幹システムのトラブルシューティングにおいて、`INDEX`関数が返すオフセットをポインタ演算に流用するケースは多々あります。`BASED`変数を使用して動的にメモリを切り出す際、`ADDR`関数と`OFFSET`の加算ミスが原因で発生する`S0C4`（保護例外）は、メインフレームアーキテクトの登竜門です。
特に、`CICS`環境下で`GETMAIN`した領域を解放し忘れたまま、`INDEX`で得たポインタを再利用しようとすると、メモリリークだけでなく、別トランザクションの領域を破壊する「サイレント・コラプション」を招きます。
アベンド（ABEND）解析の要諦
もし`INDEX`の結果をオフセットとして使用し、アベンドが発生した場合は、ダンプの`PSW`（プログラムステータスワード）だけでなく、レジスタに格納されたアドレス値が、`DCL`で定義したデータ構造の範囲内か否かを即座に突き止める必要があります。パックデシマル（`PIC S9(7)V99 COMP-3`）の符号反転（`X’0C’`が`X’0D’`に化けるなど）が混入していると、計算結果が狂い、それがそのまま`INDEX`の検索対象文字列を破壊する、という地獄のようなデバッグを経験した方も多いでしょう。
3. マイグレーションにおける最適化の落とし穴
JavaやC#への移行において、「PL/Iの`INDEX`をどう置き換えるか」は非常に重要な設計課題です。
- パフォーマンスの断絶: EBCDIC環境のTRT命令は、文字比較において極めて強力です。移行先のUnicode環境（UTF-8/UTF-16）では、文字コード変換コストが無視できません。
- DB2埋め込みSQLとの相性: `INDEX`の結果を使って`SUBSTR`で切り出し、それをDB2の`WHERE`句にバインドする際、PL/I側で`TRIM`を忘れると、固定長空白（`X’40’`）が検索条件に含まれ、インデックスが使用されずに全表スキャン（Tablespace Scan）が発生します。
最後に：レガシーの知見を未来へ
PL/Iのコードを読み解くことは、現代の抽象化された言語では決して学べない「ハードウェアがどう動いているか」を理解することに他なりません。
マイグレーションを担当する若手エンジニアの皆さんに伝えたいのは、「コンパイラが吐き出す機械語をイメージせよ」ということです。`INDEX`一つとっても、それが単なる関数呼び出しではなく、CPUの特定のレジスタを操作する命令列に展開されるという感覚を持てば、移行後のパフォーマンス劣化も予見可能になります。
私たちの仕事は、単なるコードの翻訳ではなく、メインフレームが40年間守り抜いてきた「信頼性」という設計思想を、いかに現代の分散環境へ移植するかにあるのです。
—
追記：もし皆さんの現場で、特定のコンパイラオプション（`NOSIZE`など）に依存した危ういコードが動いているならば、今のうちにカバレッジを高めた単体テストでその挙動を「ドキュメント化」しておくことを強く推奨します。仕様書に書かれていない挙動こそが、移行プロジェクト最大の資産であり、最大のリスクなのですから。
