PL/IのRETURNS属性：戻り値の「型」が引き起こす基幹システムの静かなる崩壊
現代のJavaやC#のモダンな開発現場から見れば、PL/Iの`RETURNS`属性など、単なる関数の戻り値定義に過ぎないと思うかもしれない。しかし、IBMメインフレームの深い闇を覗いてきた我々にとって、この属性は単なる記法ではなく、プロセッサのレジスタ操作とメモリ上のバイナリ表現を直接制御する「契約」そのものだ。
今回は、`RETURNS`属性を用いた関数型プロシージャの設計と、それが引き起こすかもしれない「沈黙のデータ破壊」について、アーキテクトの視点から紐解いていこう。
1. RETURNS属性の「厳格さ」とコンパイラの甘い罠
PL/Iにおいて`RETURNS`を指定する際、呼び出し側と定義側で属性の不一致が起きたとき、コンパイラは時として「親切すぎる」エラー修正を行う。これがバグの温床だ。
特に`FIXED DECIMAL`（パックデシマル）を返す際、呼び出し側の宣言で精度(`PRECISION`)を明示的に省略すると、コンパイラはデフォルト値を適用する。このとき、内部の符号ビット（`x’C’`や`x’D’`）が期待する変換ルールと微妙にズレることで、CICSのトランザクションが突然`0C7`（データ例外）を吐くことがある。
実践：堅牢な関数定義の作法
1
/ 戻り値の精度を呼び出し元と完全に一致させること。これが鉄則だ。 /
CALC_TOTAL_AMOUNT: PROCEDURE(P_AMT, P_RATE)
RETURNS(FIXED DECIMAL(15,2));
DCL P_AMT FIXED DECIMAL(11,2) PARM;
DCL P_RATE FIXED DECIMAL(5,4) PARM;
DCL W_RESULT FIXED DECIMAL(15,2);
W_RESULT = P_AMT P_RATE;
/ 戻り値を返す際、メモリ上のパックデシマル形式が崩れていないか注意が必要 /
RETURN(W_RESULT);
END CALC_TOTAL_AMOUNT;
2. ポインタ操作との危険な邂逅
`RETURNS`でポインタ(`POINTER`)を返す設計は、大規模なバッチ処理の共通ルーチンで頻繁に見かける。動的に確保したメモリ領域へのアドレスを戻り値とする場合、PL/Iの`BASED`変数との組み合わせには細心の注意が必要だ。
もし呼び出し側で受け取る変数の属性に`ALIGNED`が漏れていたらどうなるか。メインフレームのアーキテクチャでは、境界調整（アライメント）が物理メモリへのアクセス速度に直結する。最悪の場合、ポインタが指し示すべきデータ構造のオフセットが2バイトずれる。これにより、DB2のホスト変数に不正な値が渡り、SQLの実行結果が予期せぬものになる――まさに、夢に出てくるような悪夢だ。
3. アベンド（ABEND）解析とデータ整合性の境界
マイグレーション時に最も苦しめられるのが、「現行機では動いていた」という事実だ。これは、旧世代のコンパイラが「あやふやな型変換を良しとしていた」ことに起因する。
アベンド発生時のチェックリスト
1. ダンプ解析の第一歩: `SYSUDUMP`を出力し、戻り値を受け取る直前のレジスタ(`GR`)を確認せよ。パックデシマルの符号ビットが`0C`や`0D`の範囲外（例：`0F`など）になっていないか。
2. コンパイラオプションの最適化: `OPTIMIZE(3)`を適用している場合、レジスタの再利用が激しく、変数のスコープを逸脱したメモリ参照が起きる可能性がある。デバッグ時は`OPTIMIZE(0)`で挙動を再確認するのが賢明だ。
3. 埋め込みSQLの罠: `RETURNS`で受け取った値がそのままDB2の`DECIMAL`カラムに格納される場合、その中間の型変換で「桁落ち」が発生していないか。
4. アーキテクトからの提言：マイグレーションを見据えた設計
今後、JavaやC#へ移行する予定があるなら、PL/Iの「曖昧さ」を徹底的に排除した記述に修正しておくべきだ。
- `DECLARE`の明示: すべての戻り値に対し、`FIXED BIN(31)`や`FIXED DEC(15,2)`といった具体的な精度を必ず指定する。
- `RETURNS`の型安全: `RETURNS`するデータ構造は、できる限り`STRUCTURE`（構造体）として定義し、マップを明確にする。
- CICS/DB2のエッジケース: `RETURNS`を使うプロシージャ内での`EXEC CICS`発行は、スタックの整合性を崩す可能性があるため避ける。関数はあくまで「計算」に徹し、外部リソースへのアクセスは呼び出し側の責任で完結させるべきだ。
最後に
PL/Iのコードを読んでいると、まるで先人たちの息遣いを感じるような瞬間がある。かつてのエンジニアは、限られたメモリとCPUパワーの中で、いかにして計算誤差を出し、いかにしてアベンドを回避するかという「美学」をコードに刻んでいた。
あなたが今、そのコードを現代的な言語に書き換えようとしているなら、単に構文を変換するのではなく、その「データがどのようなバイナリとしてメモリを流れているか」という本質を読み解いてほしい。技術の移り変わりは激しいが、データが正しく処理されなければならないという基幹システムの鉄則だけは、メインフレームの時代から何一つ変わっていないのだから。
