PL/Iの深淵：VERIFY関数と「予約語なき言語」が突きつける保守の現場
メインフレームの現場で何十年と生き抜いてきたPL/Iという言語は、JavaやC#のモダンな言語仕様に慣れたエンジニアから見れば、どこか「野生的」で、かつ「底知れない」存在に映るはずです。特に、PL/Iには明確な「予約語」が存在しません。`IF`という変数名すら許容するこの言語仕様は、コンパイラがいかにして文脈を読み解いているのか、というアーキテクチャの真髄を私たちに問いかけます。
今回は、そんなPL/Iの特性を理解した上で、入力値検証の要である`VERIFY`関数について、基幹システムの現場で遭遇する「落とし穴」を交えて深掘りします。
—
VERIFY関数の本質：内部ループと戻り値の「意味」
`VERIFY(string, reference)` は、`string`の中に`reference`セットに含まれない文字が最初に現れる位置を返します。0が返れば、すべてが許可された文字セット内に収まっていることを意味します。
1
/ 許可文字セット：数字のみを許容する場合の検証 /
DCL INPUT_FIELD CHAR(10) INIT(‘1234A67890’);
DCL ALLOWED_CHARS CHAR(10) INIT(‘0123456789’);
DCL POS FIXED BIN(15);
POS = VERIFY(INPUT_FIELD, ALLOWED_CHARS);
IF POS > 0 THEN
/ ここでアベンドを回避するためのエラーハンドリングを行う /
PUT SKIP LIST(‘不正な文字を検知。位置：’, POS);
この処理を単なる「関数呼び出し」と捉えてはなりません。コンパイラは、`reference`の長さと`string`の長さを天秤にかけ、最適化オプション（`OPTIMIZE(3)`など）が有効であれば、CPUのベクトル命令（SIMD的な挙動）を駆使して極限まで高速化されたマシンコードを生成します。
しかし、マイグレーション時にこの挙動をC#やJavaで再現する際、文字列のエンコーディングの違いや、ホスト側（EBCDIC）特有の文字コード順序（Collation Sequence）を考慮せず単純な`Regex`等に置換すると、バッチ処理全体の整合性が崩壊します。特に、パックデシマル（`PIC S9(7) COMP-3`）が混在する入力バッファを扱う場合、`VERIFY`の戻り値と、その後に続く`UNPK`命令でのオーバーフロー（S0C7アベンド）の因果関係を正確にトレースしなければなりません。
—
アベンド解析の現場から：ポインタ操作とデータ破損
基幹システムにおいて最も恐ろしいのは、意図しないメモリ領域への書き込みです。PL/Iはベース変数とポインタ（`BASED`, `POINTER`）を用いることで、物理メモリを直接叩くような動的操作が可能です。
1
/ ポインタを用いた動的なバッファ操作例 /
DCL P POINTER;
DCL BUFFER CHAR(100) BASED(P);
/ アドレスを動的に割り当てた領域をVERIFYでチェック /
P = GET_ADDRESS_FROM_CICS_COMMAREA();
IF VERIFY(BUFFER, ‘0123456789’) ^= 0 THEN
/ 異常検知時のダンプ取得ロジック /
CALL ABEND_PROCEDURE;
もし`VERIFY`が返すインデックスが境界値を超えている場合、それはメモリの破損を意味します。ダンプ解析の際、`CEE3207S`（データ例外）が発生しているなら、`VERIFY`でチェックしきれなかった非数値データが、後続の演算命令に渡っている可能性が高い。特にCICS環境では、COMMAREAの領域を跨いでデータを参照していないか、`BASED`変数の定義長と実際の転送長が一致しているか、`OFFSET`演算の結果を厳密にチェックする必要があります。
—
移行設計への提言：なぜ「そのまま」移植してはいけないのか
レガシーマイグレーションの現場で私が最も注意を促すのは、「PL/Iの柔軟性を、現代言語の堅牢性でどうラップするか」という点です。
1. 予約語のない仕様への対策: PL/Iは`IF`を変数名にできますが、当然、可読性は最悪です。移行先のJavaでこれと同等の挙動を求めようとせず、まずは静的解析ツールで「意味のある変数名」に置換するリファクタリングを先行させることが、保守コストを劇的に下げる唯一の道です。
2. パックデシマルの内部符号反転: `VERIFY`で検証したあとに`PIC S9`に変換する際、EBCDICの符号ビット（`C`や`D`、`F`）が期待通りかを確認してください。特にDB2からFETCHした値がNULLか否かの判定が、`VERIFY`のロジックと衝突して誤作動するケースは枚挙に暇がありません。
3. コンパイラ最適化の副作用: `OPTIMIZE(3)`を適用したPL/Iコードは、レジスタの再利用が非常にアグレッシブです。移行先でも同様の並列処理を行う場合、スレッドセーフな設計になっているかを、単なるロジック変換ではなく、メモリアクセスの排他制御レベルから再定義する必要があります。
結びに代えて
PL/Iは、汎用機の時代が作り上げた「妥協なき道具」です。`VERIFY`関数ひとつとっても、そこにはハードウェアを叩くための哲学が詰まっています。
マイグレーションという名の「言語の翻訳」を行う際、単なる構文変換に終始すれば、基幹システムの心臓部はいつか停止します。コードの向こう側にある「マシンが何をしようとしているのか」を想像し、設計に落とし込むこと。それが、真のシステムアーキテクトに求められる姿勢ではないでしょうか。
次回の記事では、`ON-UNIT`ハンドリングによる動的な例外制御と、CICS環境下でのトランザクション整合性について、さらに深淵な領域へ足を踏み入れたいと思います。
