予約語なき世界の流儀：PL/I動的SQLとポインタ操作の深淵
基幹システムの現場で長年メインフレームと向き合ってきた者にとって、PL/Iという言語の懐の深さは時として畏怖の念を抱かせる。CやJavaのように厳格な「予約語（Reserved Words）」の概念を持たず、文脈によって識別子がその意味を決定するこの言語は、コンパイラ泣かせであると同時に、極限まで最適化されたコードを書くための強力な武器でもあった。
今回は、このPL/Iの特異な構文的自由度を背景に据えつつ、現場のテックリードやマイグレーション設計者が最も頭を悩ませる「DB2埋め込みSQLにおける動的SQLの構築とPREPARE/EXECUTEの極意」について、アーキテクトの視点から徹底的に掘り下げていこう。
静的SQLが全盛の基幹バッチにおいて、動的SQLは「諸刃の剣」だ。しかし、条件分岐が複雑怪奇に絡み合うレガシーシステムの共通部品や、Java/C#への移行過渡期におけるリバースエンジニアリングの文脈において、動的SQLの内部挙動を完全に掌握しているか否かは、システムの生死を分ける境界線となる。
—
1. 予約語を持たないPL/Iの構文規則と、動的SQL文字列構築の罠
PL/Iの仕様書を開くと、驚くべき事実に出会う。そう、PL/Iには「厳密な意味での予約語」が存在しない。`IF`や`READ`といったキーワードであっても、文脈が許せば変数名として定義できてしまう（もちろん、そんなコードを書けばコードレビューで私に赤ペンを入れられること確実だが）。
この「コンテキスト依存の構文解析」は、動的SQL文を文字列として組み立てる際に強力な柔軟性をもたらすが、同時に恐ろしい副作用を生む。
1
DCL SQL_STMT CHAR(1000) VARYING;
DCL SELECT CHAR(10) INIT(‘EMPLOYEE’); / ← これすら文法上はエラーにならない場合がある /
動的SQLを組み立てる際、開発者はSQL文を格納する文字型変数（ベース変数）に対し、文字列結合を繰り返してクエリを生成する。ここで注意すべきは、PL/Iの文字型操作（特にVARYING文字列）におけるパディングと長さ制御の挙動だ。
1
/ 動的SQL構築の典型例と落とし穴 /
DCL DYN_SQL CHAR(2048) VARYING;
DCL W_DEPT CHAR(3) INIT(‘A00’);
/ 文字列の連結時に意図しないブランクが混入するリスク /
DYN_SQL = ‘SELECT EMPNO, EMPNAME FROM ‘;
DYN_SQL = DYN_SQL || SELECT; / 変数名の衝突に注意 /
DYN_SQL = DYN_SQL || ‘ WHERE DEPTNO = ”’ || W_DEPT || ””;
C#やJavaの `StringBuilder` のような洗練されたクラスがないPL/Iでは、文字列長（`LENGTH`関数）の管理を誤ると、DB2プリコンパイラやランタイム（DSNHIAPI等）が予期せぬ構文エラー（SQLCODE -104など）を返す。特に、ホスト変数やパラメータマーカー（`?`）を動的に埋め込む際、文字列の切り詰めやトレーリングブランクの扱いは、コンパイラオプション（`RULES(NOLAXICAL)`など）の指定によって挙動が変わるため、マイグレーション時の隠れた地雷となる。
—
2. プレースホルダとパラメータマーカー：ポインタを用いたデータバインドの極意
動的SQLの真骨頂は、`PREPARE`された文に対して `EXECUTE` を行う際、パラメータマーカー（`?`）を通じて安全かつ高速にデータをバインドすることにある。しかし、静的SQLのようにホスト変数を直接記述できない動的SQLでは、SQLDA（SQL Descriptor Area）を自前で制御するか、適切なポインタ操作が必要となる。
ここで、ベース変数とポインタを駆使した高度なメモリ操作のコード例を見てみよう。
1
/ ================================================================ /
/ 動的SQL PREPARE / EXECUTE 実装サンプル /
/ ================================================================ /
TEST_DYN: PROC OPTIONS(MAIN);
DCL DYN_SQL CHAR(512) VARYING;
DCL W_SALARY DEC FIXED(7,2);
DCL P_SALARY POINTER;
/ DB2コミュニケーションエリア /
EXEC SQL INCLUDE SQLCA;
/ 1. 動的SQL文字列の構築 /
DYN_SQL = ‘UPDATE EMP SET SALARY = ? WHERE JOB = ”MANAGER”’;
/ 2. SQL文のプレパレーション /
EXEC SQL PREPARE S1 FROM :DYN_SQL;
IF SQLCODE ¬= 0 THEN DO;
/ エラーハンドリング（後述のダンプ解析へ続く） /
SIGNAL ERROR;
END;
/ 3. パラメータ値の設定（ポインタを介した間接参照の例） /
W_SALARY = 750000.00;
P_SALARY = ADDR(W_SALARY);
/ 4. EXECUTE USINGによるバインド実行 /
/ 注: 実際のSQLDAを用いた動的SQLでは領域割振りとポインタ設定が必須 /
EXEC SQL EXECUTE S1 USING :W_SALARY;
IF SQLCODE = 0 THEN
DISPLAY(‘DYNAMIC SQL EXECUTE SUCCESS.’);
ELSE
DISPLAY(‘SQL ERROR CODE: ‘ || TO_CHAR(SQLCODE));
END TEST_DYN;
パックデシマルの内部符号反転バグとエッジケース
上記のコードで `DEC FIXED(7,2)`（パックデシマル：ゾーン10進数/パック10進数）を使用している点に注目してほしい。メインフレーム移行時、JavaやC#などのオープン系言語へロジックを移植する際、このパックデシマルの扱いで必ずと言っていいほどトラぶるのが「内部符号（Sign Nybble）の反転バグ」だ。
IBMメインフレームのハードウェアは、パックデシマルの最下位バイトの右側4ビット（ニブル）に符号（`C`, `D`, `F` 等）を格納する。COBOLやPL/IからDB2へデータを渡す際、この符号領域が不正な値（例えば、不正な文字データが混入して符号ニブルが `F` 以外になるなど）になっていると、DB2のサブシステム側でアベンド（S0C7等のデータ例外、あるいはDB2側のマイナスコード）を引き起こす。
動的SQLでパラメータマーカーを使用する場合、DB2は実行時にデータ型と長さを推論するため、ホスト変数のピクチャ句や属性が正確に一致していないと、暗黙の型変換に伴うオーバーヘッド、最悪の場合はS0C4（ストレージ保護例外）やS0C7（データ例外）といった致命的なアベンドへと直結する。
—
3. アベンド（ABEND）発生時のダンプ解析とアーキテクチャの知見
万が一、動的SQLの実行時やその後のフェッチ処理においてシステムが異常終了（ABEND）した場合、私たちシステムアーキテクトはJCLのSYSUDUMPやCEEDUMPを紐解くことになる。
PL/Iプログラムにおける動的SQLのデバッグで最も厄介なのは、コンパイラによる最適化（`OPTIMIZE(2)` や `OPT(FULL)`）がコードの実行順序を並び替えたり、変数をレジスタ内に完全にキャッシュしてしまったりする点だ。ダンプ上のストレージを覗いても、該当のホスト変数が意図したアドレスに存在せず、レジスタ（R3やR4など）の中に埋もれていることは日常茶飯事である。
アーキテクトが実践すべき対策
1. コンパイラの制御 (`NOOPTIMIZE` / `TEST`)
トラブルシューティングのフェーズでは、該当モジュールだけでもコンパイラオプションを `OPTIMIZE(0)` かつ `TEST(SYM)` に落とし込み、変数のシンボル情報とメモリ上の実アドレスを完全に一致させる。
2. SQLCAとWHENEVERの適切な配置
動的SQLを使用する場合、`EXEC SQL WHENEVER SQLERROR` のスコープ管理を誤ると、予期せぬエラー時に制御がどこに飛んだか分からなくなる。原則として動的SQLの直後には、必ず手動での `SQLCODE` チェックを記述し、エラー時は独自のログ出力ルーチンへ分岐させるべきである。
3. マイグレーション時の設計思想
Java（Spring JDBC / MyBatis等）やC#（Entity Framework等）へのマイグレーションを行う際、PL/Iの動的SQL（特に文字列結合によるSQL構築）をそのまま直訳してオープン系に持ち込むのは悪手中の悪手である。動的SQLはSQLインジェクション脆弱性の温床であり、オープン系へ移行する絶好の機会に、パラメータ化クエリ（Prepared Statement）への完全リファクタリングを行うべきだ。
—
結びに代えて
PL/Iの柔軟な構文とDB2の動的SQLの組み合わせは、レガシーシステムのダイナミクスを支えるロマンに満ちている。しかし、その背後にはハードウェアのデータ表現（パックデシマル）、コンパイラの最適化の闇、そしてメモリ管理の厳密なルールが複雑に絡み合っている。
「なぜ動くのか」ではなく「どうしてこの挙動になるのか」をコンパイラレベル、さらにはOS・サブシステムレベルで理解し尽くすこと――それこそが、真のレガシー移行スペシャリスト、そしてメインフレームアーキテクトに求められる絶対的な資質である。次の改修や移行プロジェクトでは、ぜひこの深淵なるレイヤーにまで意識を巡らせてコードに向き合ってほしい。
