はじめに：PL/Iとハードウェアの密接な関係
メインフレームの現場で長年生き抜いてきたシニアアーキテクトなら、「PL/Iは古臭い言語だ」という偏見がいかに的外れであるかを知っている。C言語やJavaが抽象化のレイヤーを重ねてハードウェアから遠ざかる一方で、PL/IはIBM System/360の時代から、ハードウェアの金属音さえ聞こえてきそうなほど、プロセッサのアーキテクチャとタイトに結びついてきた。
特に数値演算、そして今回焦点を当てる平方根計算（`SQRT`関数）の挙動は、コンパイラの最適化とIBM Zのハードウェア（FPU：浮動小数点演算ユニット）がどのように協調動作しているかを理解する上で最高の題材だ。
モダン言語へのマイグレーション（JavaやC#へのリライト）を控えたプロジェクトにおいて、レガシーコードの数学関数が「なぜそのように振る舞うべきなのか」を解体できなければ、移行後の本番稼働で必ず痛い目を見る。今回は、`SQRT`関数の背後にあるFPUのハードウェア命令、例外処理、そして実務で遭遇するエッジケースの深淵へと案内しよう。
—
1. 識別子の「自由度」と予約語なき世界：SQRT関数を守るもの
PL/Iの最もユニーク、かつC言語に慣れたモダンプログラマを絶句させる仕様として、「PL/Iには予約語が存在しない」という事実がある。
1
/ すべて有効な変数宣言の例 /
DECLARE SQRT FLOAT(53);
DECLARE IF FIXED(5);
DECLARE THEN CHARACTER(10);
コンパイラは、コンテキスト（文脈）だけで `SQRT` が組み込み関数なのか、それともプログラマが定義した倍精度浮動小数点の変数なのかを完璧に判別する。この柔軟性は強力だが、移行設計の文脈では「魔改造されたレガシーコード」を生み出す温床となる。
もし前任者が `DECLARE SQRT FLOAT;` なんぞと変数定義しようものなら、コード内のどこで本来の組み込み関数が呼ばれ、どこで変数が参照されているのか、静的解析ツールを泣かせる原因になる。マイグレーション前のソースコードアセスメントでは、まずこの「名前空間のオーバーロード」を検出することが、第一歩となる。
—
2. ハードウェア直結：SQRT関数とFPU（浮動小数点演算ユニット）の挙動
PL/Iで `Y = SQRT(X);` と記述した時、バックエンドのIBM Enterprise PL/Iコンパイラはこれをどのように機械語に翻訳しているか。
最適化オプション（例えば `OPT(2)` または `OPT(3)`）が有効な場合、コンパイラはこれをインライン展開し、IBM Zアーキテクチャの浮動小数点演算命令（例：`SQRT` または `SQRTF` などのハードウェア命令）に直接変換する。関数呼び出しのオーバヘッド（スタックフレームの構築など）は完全に排除され、CPUのパイプラインに直接命令が流し込まれる。
しかし、ここに基幹システム特有の罠がある。「負の数」が渡された場合の挙動だ。
数学的に実数域での平方根は存在しない。FPUに負の数が渡された際、ハードウェアは「浮動小数点無効演算例外（Floating-Point Invalid Operation Exception）」を発生させる。
バッチ処理におけるアベンドと例外ハンドリング
もしPL/I側で何の対策もしていない状態で、入力ファイル（あるいはDB2の列）のデータ化けによってマイナス値が `SQRT` に飛び込むと、プログラムは容赦なく ASRA (S0C7) または ASRB (S0C4)、あるいはより正確には S0CF（浮動小数点例外） などのシステムABENDを引き起こしてジョブストリーム（JCL）を異常終了させる。
これを防ぐためには、`ON条件（ON-condition）` を用いた明示的な例外トラップが不可欠である。
1
/ 浮動小数点例外（CONDITION: ERROR または ZERODIVIDE/CONVERSION等）の捕捉 /
ON ERROR
BEGIN;
PUT SKIP LIST(‘ 致命的エラー: 数学関数演算または浮動小数点例外が発生しました ‘);
/ エラーログの出力や、退避コードへの分岐処理 /
GOTO ERROR_ROUTINE;
END;
/ 安全なSQRT演算のラッパー的実装例 /
CALCULATE_SQRT: PROC(P_INPUT) RETURNS(FLOAT(53));
DECLARE P_INPUT FLOAT(53);
DECLARE V_RESULT FLOAT(53);
/ 事前ガード条件：ハードウェア例外を回避するためのビジネスロジック /
IF P_INPUT < 0.0 THEN
DO;
PUT SKIP LIST('警告: 負の値に対するSQRT呼び出しを検知しました。処理をスキップします。');
RETURN(0.0E0);
END;
V_RESULT = SQRT(P_INPUT);
RETURN(V_RESULT);
END CALCULATE_SQRT;
実務の現場では、コンパイラオプション `TRAP(ON)`（デフォルト）が機能していることが前提となるが、パフォーマンスチューニングの一環で `TRAP(OFF)` が誤設定されているレガシーモジュールに出くわすことがある。これが原因で、例外発生時にハードウェアトラップが正しく言語ランタイムに拾われず、即座にジョブがクラッシュするトラブルが後を絶たない。
---
3. レガシー移行（Java / C#）におけるエッジケース対策
PL/IからJava（OpenJDK）やC#（.NET）へマイグレーションする際、この `SQRT` 関数の挙動差異で最も頭を悩ませるのが、「IEEE 754規格の厳密な解釈」と「データ型の暗黙的変換」である。
① パックデシマル（COMP-3）から浮動小数点への変換バグ
メインフレームでは、金額や数量は `DECIMAL FIXED`（パックデシマル）で保持されていることが多く、これを浮動小数点演算に渡す際には暗黙的、あるいは明示的な型変換（CAST）が行われる。
ここで、レガシー特有の「内部符号反転バグ」や「ゾーン不良（S0C7の温床）」が存在する場合、Javaの `Double.valueOf()` や C#の `double.Parse()` にそのまま持ち込むと、メインフレーム上ではなぜか許容されていた（あるいは無視されていた）微小な数値誤差や例外が、モダン環境では `NumberFormatException` や `ArithmeticException` として爆発する。
移行設計では、単に `Math.sqrt()` に置き換えるだけでなく、「入力値の正当性検証（バリデーション）」をJava/C#側に手厚く移植する必要がある。
// Javaへの移行時における安全なSQRTラッパーの例
public class LegacyMathUtils {
public static double computeSqrt(BigDecimal inputDecimal) {
if (inputDecimal == null) {
throw new IllegalArgumentException(“入力値がヌルです。”);
}
double val = inputDecimal.doubleValue();
// メインフレームのFPU例外を防ぐためのガード節
if (val < 0.0) {
// レガシーシステムの仕様に合わせたフォールバック処理
System.err.println("警告: 負の数に対する平方根計算が要求されました。");
return 0.0;
}
return Math.sqrt(val);
}
}
② 埋め込みSQL（DB2）やCICSオンライン処理のエッジケース
CICSの画面から受け取った文字列を `PIC S9(9)V99 COMP-3` で受け取り、それを浮動小数点に変換して `SQRT` を掛け、結果を再びDB2の `DECIMAL` 型カラムに格納するバッチプログラムを考えてほしい。
オンライン（CICS）の応答速度を極限まで高めるため、かつては最適化レベルを上げ、ポインタ操作やベース変数（Based Variables）を使ってストレージ上のバイナリを直接リード・ライトしているコードを見かける。
1
/ ポインタとベース変数を用いたストレージ直接操作の例 /
DECLARE 1 DATA_AREA BASED(PTR_DATA),
3 RAW_VAL FIXED BIN(31),
3 CALC_VAL FLOAT(53);
/ 領域のアドレスをセットして直接演算 /
PTR_DATA = ADDR(CICS_COMMAREA_BUFFER);
CALC_VAL = SQRT(FLOAT(RAW_VAL));
このようなコードをJavaに移行する場合、`ByteBuffer` や構造体のアンマーシャリング処理を正確に再現しなければ、バイナリレイアウトのズレによる数値化け（あるいは端数処理の不一致）を引き起こす。特に、IBMメインフレームのビッグエンディアンと、x86/x64アーキテクチャのエンディアンの違いによるバイトオーダーの逆転には、アーキテクトとして細心の注意を払うべきだ。
—
4. ダンプ解析の現場から：S0CFと浮動小数点レジスタ
本番稼働中のバッチジョブが夜間帯に突如としてアベンドし、SYSUDUMPが出力されたとする。スペシャリストがIPCS（Interactive Problem Control System）を用いてダンプを覗くとき、見るべきポイントは決まっている。
1. PSW（Program Status Word）の確認: 命令アドレス（Instruction Address）を特定し、どのモジュールのどの機械語命令で例外が起きたかを突き止める。
2. 浮動小数点レジスタ（FPR: Floating-Point Registers）のダンプ: FPR 0, 2, 4, 6 などの値を検証し、例外発生時にどのような汚染されたデータ（NaNやInfinity、あるいは不正な負数）が演算器に投入されたかをリバースエンジニアリングする。
PL/Iコンパイラが吐き出したアセンブラリスト（`LIST`オプション付きでコンパイルしたもの）と照合し、「あぁ、ここで最適化された `SQRT` 命令が、先行するDB2のホスト変数からのフェッチミス（あるいはヌルインジケータの未チェック）によって不正なビットパターンを掴まされたのだな」と即座に原因を特定できること。これこそが、レガシーシステムを支えるアーキテクトに求められる真のスキルである。
—
おわりに：レガシーの知見を未来のアーキテクチャへ
PL/Iの `SQRT` 関数とFPUの連携、そして例外処理のメカニズムは、単なる古い言語仕様の話ではない。「ハードウェアの特性を極限まで引き出し、予期せぬ例外からシステムをどう守るか」という、システムアーキテクチャの本質が詰まっている。
マイグレーションプロジェクトにおいて、「とりあえずJavaの `Math.sqrt` に置き換えれば動くだろう」という安易なアプローチは、本番環境での偶発的な停止事故を誘発する。レガシーコードが何十年もの間、どのようなハードウェアの制約と例外処理の歴史的背景の上で動いてきたのかを解体し、モダンなプラットフォームへとその堅牢性を継承していくこと。それこそが、我々テックリードに課された使命である。
