PL/Iの「短絡評価」を甘く見るな――基幹システムの性能を左右するIF文の深淵
夜中のバッチ処理で、突如として発生する原因不明の「データ例外（S0C7）」や、終わらないループ。その原因を紐解くと、多くの場合、若手が何気なく書いたIF文の条件式に行き着くことがある。
PL/Iという言語は、C言語やJavaのように「予約語」という厳格な壁がほとんど存在しない。自由奔放な言語に見えるが、その分、コンパイラの裏側で行われる評価順序の最適化や、短絡評価の挙動を理解していないと、大規模な基幹システムでは致命的なパフォーマンス劣化や論理バグを招くことになる。
今回は、PL/Iにおける条件式の評価順序と、その最適化が実行速度に与える影響について、現場の視点から深掘りしていこう。
—
短絡評価（Short-circuit evaluation）の真実
PL/Iの論理演算において、最も重要なのが「短絡評価」だ。
例えば、`IF A & B THEN` と記述した場合、Aが偽であれば、コンパイラはBを評価することなくブロックを抜ける。これは性能向上のためというよりは、「無効なデータに対する参照エラーを回避する」ために極めて重要だ。
特にVSAMファイルからの読み込み時、レコードが存在しない（またはNULLである）可能性がある場合に、この特性を利用しない手はない。
実践コード：安全かつ高速な条件判定
/1
/ VSAMから読み込んだデータが有効か判定する例 /
/ 冗長なネストを避け、評価順序を制御することで性能を確保する /
IF RECORD_PTR ^= NULL() & RECORD_PTR->DATA_LEN > 0 THEN
DO;
/
ここで短絡評価が威力を発揮する。
RECORD_PTRがNULLの場合、右辺のDATA_LEN参照は行われない。
もし短絡評価がなければ、ここでS0C4が発生し即座に異常終了だ。
/
CALL PROCESS_RECORD(RECORD_PTR);
END;
ELSE
DO;
/ 無効なデータに対するエラーハンドリング /
CALL LOG_INVALID_RECORD();
END;
—
コンパイラによる分岐予測と最適化の罠
現代のメインフレーム（z/Architecture）のパイプライン処理は非常に強力だが、コンパイラ任せの最適化には限界がある。
特に、「頻繁に真となる条件」と「滅多に真とならない条件」が混在する複雑なIF文において、評価順序を入れ替えるだけでCPU時間を数ミリ秒単位で節約できることがある。これは大規模バッチにおいて、数百万件のレコードを処理する際には無視できない差となって現れる。
パフォーマンスを最適化するコツ
1. 評価コストの低い順に並べる:
ビット演算や定数比較を先頭に。関数呼び出しや複雑な計算（BUILTIN関数など）は、他の条件が真であった場合にのみ実行されるよう、論理積の右側に配置する。
2. ONユニットとの兼ね合い:
`ON CONVERSION` などのONユニットが制御フローに絡む場合、条件判定でこけるとフローが飛ぶ。評価順序を意識しないと、予期せぬONユニットの発火を招くため注意が必要だ。
—
実務現場での教訓：なぜ「読めるコード」が最強なのか
コードの最適化は重要だが、それ以上に重要なのは「誰が見ても評価順序が自明であること」だ。
/1
/ 悪い例：条件式が複雑すぎて、短絡評価に頼っているのか不明瞭 /
IF (A = 1 | B = 2) & (C = 3 | D = 4) THEN …
/ 良い例：論理を分解し、評価順序を意図的に制御する /
IF A = 1 | B = 2 THEN
IF C = 3 | D = 4 THEN
DO;
/ 処理内容 /
END;
メインフレームの保守開発において、最もコストがかかるのは「動くコードを書くこと」ではない。「既存のコードを読み解き、変更した際に副作用を出さないこと」だ。
コンパイラの最適化に頼り切ったテクニカルな記述よりも、あえて論理を分割し、「どの条件が評価されたら、どの関数が呼ばれるのか」を誰の目にも明らかにする。これこそが、数十年稼働し続けるシステムを守る、ベテランの流儀だ。
—
最後に
PL/Iは、その柔軟性ゆえに「書き方一つで化ける言語」だ。
コンパイラの最適化オプション（`OPTIMIZE(3)`など）に依存する前に、まず我々エンジニアが「論理の最適化」をコードに刻み込む。それが、ダウンタイムを許されない基幹システムを支える我々の矜持である。
もし、貴方の担当しているバッチ処理が重いと感じたら、一度コンパイラのリストを見てみるといい。IF文の並び順一つで、機械語レベルでの分岐がどう変化しているか。そこには、コンピュータと対話する面白さが詰まっているはずだ。
