PL/I算術演算における型プロモーションの罠：基幹システムを救う暗黙的変換の制御とアーキテクチャ設計
メインフレームの現場において、夜間バッチの終了間際に突如発生するS0C7アベンド。あるいは、JavaやC#へのマイグレーション検証フェーズで浮上する「なぜか本番データと移行後の出力結果が1円ズレる」という悪夢。
これらの原因の多くは、PL/Iという言語の懐の深さ、そして時に過剰なまでの親切心である「自動型プロモーション（暗黙的データ変換）」に端を発しています。
現代のオープン系言語に慣れ親しんだエンジニアから見れば、PL/Iは「コンパイル時にうまいことやってくれる言語」に見えるかもしれません。しかし、IBM Enterprise PL/Iコンパイラが裏で何を行っているのか、その算術演算の優先順位と内部表現のメカニズムを把握していなければ、基幹システムの信頼性は容易に揺らぎます。
今回は、テックリードやマイグレーションアーキテクトに向けて、PL/Iの型プロモーションの深淵と、それが引き起こすエッジケース、そして実務で身を護るための設計指針を解説します。
—
1. 予約語を持たない自由の代償：PL/Iの型プロモーションの基本原則
PL/Iの最大の特徴の一つは、「言語としての予約語を持たない（Contextual Keywords）」という設計思想にあります。`IF`や`READ`といったキーワードであっても、文脈によっては単なる変数名として定義できてしまうこの柔軟さは、構文解析器（パーサー）にとって驚異的な複雑さをもたらします。
データ制御と算術演算においても、この「何でも受け入れる」姿勢が貫かれています。異なるデータ型、例えば固定小数点（FIXED DECIMAL）、浮動小数点（FLOAT）、そしてバイナリ（FIXED BINARY）が混在する式を評価する場合、コンパイラは厳密な内部規則（Arithmetic Promotion Hierarchy）に従って型を昇格（プロモーション）させます。
算術演算の優先順位と型昇格の階層
PL/Iにおける算術型のランクは、概ね以下の順序で上位へと昇格します。
1. FIXED BINARY（固定小数点二進数）
2. FIXED DECIMAL（固定小数点十進数 / パック十進数 COMP-3）
3. FLOAT（浮動小数点数）
一見すると、「精度が落ちないように自動でやってくれるなら安全だ」と思われがちですが、ここに基幹システム特有の罠が潜んでいます。特に、金銭計算で多用される `FIXED DECIMAL` と、ループカウンタや内部計算で使われる `FIXED BINARY` が混在するとき、コンパイラは目に見えない一時領域（Workspace）を割り当て、暗黙的な型変換コードを生成します。
—
2. 実務の現場を襲うエッジケース：なぜ「1円のズレ」と「S0C7」が起きるのか
エッジケース①：パックデシマルの内部符号反転とS0C7アベンド
バッチ処理で外部から取り込んだファイルやDB2のホスト変数（`DECIMAL`）を、適切に初期化しないまま算術演算に巻き込んだ際、ゾーン/パック形式の整合性が崩れていてS0C7（データ例外）が発生した経験はないでしょうか。
PL/Iでは、異なる精度やスケールを持つ `FIXED DECIMAL` 同士の演算であっても、中間結果を保持するために一時的なコンパイラ生成のワークエリアが使われます。このとき、暗黙のプレシジョン拡張（桁あふれを防ぐための拡張）が行われますが、元のデータの有効桁数や符号ニブル（Zone/Sign半バイト）が不正である場合、プロモーションの過程でハードウェア例外がトリガーされます。
エッジケース②：埋め込みSQL（DB2）とCICSにおける予期せぬ型変換コスト
CICSのオンライン画面から渡ってきたテキストデータ（`CHAR`）や、DB2から取得したNull可の列をそのままPL/Iの算術変数に直結させた場合を考えてみます。
1
DCL WK_SALARY FIXED DEC(9,2);
DCL DB_SALARY DECIMAL(9,2); / DB2のホスト変数 /
/ 暗黙的変換が発生する危険な演算 /
WK_SALARY = DB_SALARY 1.05;
このコード、一見何の問題もないように見えます。しかし、リテラル `1.05` はデフォルトでどのような属性を持つでしょうか？
PL/Iの仕様では、浮動小数点リテラルや固定小数点リテラルの精度は、その記述方法によってコンパイラが決定します。`1.05` は `FIXED DEC(3,2)` として扱われますが、これがより高精度な変数や `FLOAT` と絡み合うと、意図しない精度の丸め（Truncation）や、逆に無駄なバイナリ変換によるCPUサイクルの消費（オーバーヘッド）を招きます。
—
3. ポインタとベース変数（BASED）を用いた動的メモリ操作における罠
システムアーキテクトとして特に警告したいのが、`BASED` ストレージクラスを使用した動的メモリ操作と型プロモーションの組み合わせです。
メインフレームのレガシーコードでは、可変長レコードやストレージの節約のために、ストレージ・エリア（バッファ）を複数の構造体で「重ねて定義（OVERLAY）」したり、ポインタで指し示したりする手法が頻繁に使われます。
1
DCL P_BUF POINTER;
DCL 1 REC_A BASED(P_BUF),
5 A_CODE FIXED BIN(15),
5 A_VAL FIXED DEC(7,2);
DCL 1 REC_B BASED(P_BUF),
5 B_CODE FIXED BIN(31),
5 B_VAL FIXED DEC(11,2);
同じメモリアドレス（`P_BUF`）を指しながら、型解釈を動的に切り替えるような設計において、算術演算を安易に行うと大惨事になります。
`FIXED BIN(15)` の領域をコンパイラが勝手に `FIXED DEC` にプロモーションして計算しようとした際、ストレージ上のバイナリ表現と十進数（パック）表現の不一致により、メモリ上の隣接領域を破壊するか、あるいはゴミデータをオペランドとした不正演算を引き起こします。
ポインタ操作を伴う領域では、「コンパイラの暗黙的変換に頼らない」ことが鉄則です。
—
4. アーキテクトが実践すべき「暗黙的変換の排除」と最適化プラクティス
パフォーマンスの最大化と、マイグレーション時の予期せぬ挙動差異を防ぐためには、コンパイラの「お節介」を断ち切り、データ型を完全に制御下におく必要があります。
対策1：明示的なビルトイン関数による型キャスト
演算を行う際は、コンパイラの自動プロモーションに委ねるのではなく、`BINARY()`、`DECIMAL()`、`FLOAT()` などのビルトイン関数を用いて、意図した型と精度（プレシジョン・スケール）へ明示的にキャストします。
1
/ 良い例：明示的にデータ型と精度を一致させて演算を制御する /
Dcl Total_Amt Fixed Dec(11,2) Init(0);
Dcl Unit_Price Fixed Dec(9,2);
Dcl Qty Fixed Bin(15);
/ Qtyを明示的にDecに変換し、中間精度のブレを防ぐ /
Total_Amt = Unit_Price Decimal(Qty, 5, 0);
対策2：コンパイラオプションの活用とチューニング
IBM Enterprise PL/Iコンパイラを使用する場合、最適化レベルやデータチェックに関するオプションを厳格に設定します。
- `RULES(NOVALLIST)` や `STGDEFN` などのサブオプション:
コンパイル時に意図しない暗黙のデータ変換や、不安全なストレージ参照が行われていないかを検出させます。
- `TRAP(ON)` / `ON-UNIT` の実装:
万が一のオーバーフローやデータ変換エラー（`CONVERSION` 条件）が発生した際、単なる強制終了（S0C7）ではなく、正確なダンプ情報を取得し、どの変数のプロモーションで破綻したかを特定できる体制を構築します。
—
5. マイグレーション（Java/C#等への移行）への視点
レガシーマイグレーションの現場において、PL/Iの暗黙的型プロモーションの挙動をJavaの `BigDecimal` や C#の `decimal` に正確に置き換える作業は、アーキテクトの腕の見せ所です。
PL/Iの `FIXED DECIMAL(p, q)` は、切り捨て（Truncation）の挙動や、オーバーフロー時の丸め処理（Rounds or Truncates）において、オープン系言語の標準ライブラリとは微妙に異なる挙動を示します。特に、負数の扱いやスケールが異なる変数間の代入における四捨五入のルールは、PL/I言語仕様の隅々まで読み解く必要があります。
「動いているから触らない」のではなく、「なぜこの型で定義され、なぜこの順序でプロモーションされているのか」をコードから読み解き、移行先でも同等の厳密性を担保すること。それこそが、基幹システムのモダナイゼーションを成功させる唯一の道です。
PL/Iのコードに向き合うときは、常にコンパイラと対話してください。コンパイラが裏で何を補正しているかを見抜けた瞬間、あなたは真のメインフレーム・アーキテクトの領域に到達しています。
