奈落の淵を覗く：PL/IとDB2インジケータ変数が織りなす「NULL」の深淵
メインフレームの心臓部で動くPL/Iプログラムにおいて、DB2との対話は避けられない宿命だ。だが、多くの若手エンジニアやJava/C#出身の移行担当者が、この「NULL判定」という単純に見える作業で足元をすくわれる。今日は、コンパイラの裏側からABENDの深淵までを覗く、少しマニアックな話をしよう。
1. なぜ「NULL」は我々を苦しめるのか
SQLで値を取得する際、そのカラムがNULL許容であれば、インジケータ変数は必須だ。しかし、PL/Iでこれを扱う際の定石を誤ると、実行時に制御不能な事態を招く。
1
DCL IV_SALARY BIN FIXED(15); / インジケータ変数 /
DCL WS_SALARY DEC FIXED(9,0); / ベース変数 /
/ DB2からのフェッチ処理 /
EXEC SQL FETCH C1 INTO :WS_SALARY :IV_SALARY;
IF IV_SALARY < 0 THEN DO; / ここがNULL判定の正攻法 / WS_SALARY = 0; / NULLの場合は0として扱う業務ロジック / END; ここで重要なのは、`IV_SALARY` が負の値（通常は-1）を取るという事実だ。もしインジケータ変数を渡し忘れると、DB2はSQLCODE -305を返してくる。このエラーに遭遇したとき、多くのエンジニアは焦ってSQLのロジックばかりを見るが、実はプログラムのデータ定義が「暗黙の型変換」を引き起こしていないか確認すべきだ。
2. ABENDの現場：ダンプ解析とパックデシマルの罠
システムがS0C7（データ例外）で落ちたとき、真っ先に疑うのはパックデシマル（`DEC FIXED`）の内部符号だ。特に、Java/C#への移行を検討する際、最も頭を抱えるのがこの「符号の解釈」である。
PL/Iのパックデシマルは、最下位ニブルに符号（C, D, Fなど）を持つ。DB2から取得した値が不正な形式であれば、計算処理に入った瞬間にABENDする。ダンプを解析する際は、該当変数のストレージを `DUMP` オプション付きで出力し、16進数で符号を確認してほしい。
移行設計の教訓：
Java側へロジックを移植する際、PL/Iの `DEC FIXED` が持つ「符号あり演算の挙動」を単なる `BigDecimal` で置き換えると、負のゼロ（-0）の扱いでテストが通らなくなることがある。PL/Iは `+0` と `-0` を別個に扱うケースがあることを、設計書に明記すべきだ。
3. 動的メモリ操作とポインタの恐怖
大規模なバッチ処理では、`ALLOCATE` を用いた動的メモリ管理が多用される。特にインジケータ変数を動的に生成するようなトリッキーな実装をしている場合、ポインタの参照先が破壊されると、それは「原因不明のメモリ破壊」として現れる。
1
DCL P_PTR POINTER;
DCL 1 T_DATA BASED(P_PTR),
3 COL_VAL DEC FIXED(9,0),
3 COL_IND BIN FIXED(15);
ALLOCATE T_DATA;
/
ここでポインタ操作を行う際は、必ず境界整列(Alignment)を確認せよ。
コンパイラオプションで UNALIGNED を多用すると、
ポインタ計算時に予期せぬオフセットが生じ、
DB2の埋め込みSQLが誤ったアドレスを参照するリスクがある。
/
4. コンパイラ最適化とエッジケース対策
コンパイラ最適化（`OPTIMIZE(3)`など）を効かせると、デバッガの挙動が怪しくなることがある。特にインジケータ変数のチェックを「最適化によって省略」されるようなコードを書いてはならない。
CICSオンライン処理のエッジケースとして、「インジケータ変数の未初期化によるゴミ値」がある。PL/Iの自動変数は初期化されない。`FETCH` に失敗した際、インジケータ変数がたまたま負の値を持っていたら？ プログラムはNULLと誤認し、不正な業務ロジックを実行する。
アーキテクトからの助言：
- 全てのインジケータ変数は、FETCH直前にゼロクリアするのが鉄則だ。
- 埋め込みSQLの前には必ず `EXEC SQL WHENEVER SQLERROR GO TO …` を配置し、保守性の高いエラーハンドリングを構築せよ。
最後に：移行担当者へのエール
PL/IからJava/C#への移行は、単なるコードの書き換えではない。それは、30年かけて蓄積された「メインフレームの堅牢性」という知恵を、近代的な環境へ翻訳する作業だ。
インジケータ変数のNULL判定ひとつをとっても、そこには「値が存在しない」という事実をいかに安全にプログラムへ伝えるかという哲学がある。表面的な構文の変換に囚われず、その裏側にあるデータ構造の真実を見抜いてほしい。
コードは嘘をつかない。たとえそれが、30年前に書かれたレガシーなPL/Iであっても。
