PL/Iの「RETURNS」が語る、堅牢なシステム設計の深淵
基幹システムという名の広大なジャングルを歩む我々にとって、PL/Iは単なる古い言語ではない。それは、CPUサイクルを極限まで削り出し、メモリの1バイトにすら魂を込めるための「エンジニアリングの芸術」だ。
特に、`PROCEDURE`の`RETURNS`属性。これほど単純に見えて、実はコンパイラの最適化戦略や、Java/C#への移行時に最も「地雷」を踏みやすい箇所はない。今日は、この`RETURNS`を軸に、単なる構文解説を超えた「アーキテクトの視点」から深掘りしていこう。
—
1. RETURNS属性の静的定義とコンパイラの「解釈」
PL/Iにおいて`PROCEDURE`が値を返す際、`RETURNS`属性は単なる型宣言ではない。それはコンパイラに対する「メモリレイアウトの指針」だ。
/i
/ 戻り値としてFIXED BIN(31)を期待する関数定義 /
CALC_ACCOUNT_BALANCE: PROCEDURE(P_ACCT_ID) RETURNS(FIXED BIN(31));
DCL P_ACCT_ID CHAR(10);
DCL W_BALANCE FIXED BIN(31) INIT(0);
/ 何らかのDB2検索処理 /
/ … /
RETURN(W_BALANCE);
END CALC_ACCOUNT_BALANCE;
ここで重要なのは、呼び出し元（Calling Module）がこのPROCEDUREをどう認識しているかだ。PL/Iはコンパイル単位が独立している場合、`DECLARE`での外部定義を怠ると、戻り値をデフォルトの`FLOAT BINARY`（あるいはコンパイラオプション次第で`FIXED DECIMAL`）と誤認する。この「型不一致」こそが、本番環境でのS0C7アベンドや、意味不明な演算結果を生む元凶となる。
2. 暗黙的変換が招く「パックデシマル」の悪夢
基幹システム移行において最も恐ろしいのは、`FIXED DECIMAL`（パックデシマル）の暗黙的変換だ。
もし戻り値として`FIXED DEC(5,0)`を返し、呼び出し元が`FIXED BIN(15)`で受け取ろうとした場合、コンパイラは内部的に変換ルーチンを挿入する。しかし、この際に桁溢れや符号の扱いが微妙にずれることがある。特に、DB2の`DECIMAL`型とPL/Iの`PIC`変数が混在する環境では、パックデシマルの内部符号（C/D/F等）が正しく認識されず、予期せぬ値に化けるケースがある。
教訓: 外部モジュールとのインターフェースにおいては、`RETURNS`の値は常に精密に型を指定し、呼び出し元でも`DECLARE EXTERNAL`を用いて厳格に型を一致させること。
3. ポインタと動的メモリ操作の危険な関係
アーキテクトとして、`RETURNS`に`POINTER`を返す設計を推奨することは滅多にない。だが、CICS環境でのデータ移動量を減らすために、あえて領域へのポインタを返す実装を目にすることもある。
/i
GET_BUFFER_PTR: PROCEDURE RETURNS(POINTER);
DCL P_AREA POINTER;
/ 動的メモリ確保 (CICSならGETMAIN) /
/ … 領域の割り当て … /
RETURN(P_AREA);
END GET_BUFFER_PTR;
この実装の落とし穴は、`RETURNS`で返されたポインタが指す領域のライフサイクル管理だ。呼び出し元がそのメモリをいつ解放すべきか、あるいは解放してはいけないのかという規約が曖昧だと、オンライン処理のメモリリークを誘発する。ダンプ解析を行う際、`RETURNS`されたアドレスが既に開放済み（Freed）の領域を指しているのを見つけるのは、まさに地獄のような作業だ。
4. マイグレーション現場での「最適化」という名の落とし穴
JavaやC#へ移行する際、PL/Iの`RETURNS`は、メソッドの戻り値としてシンプルに変換できると思われがちだ。しかし、PL/Iの`OPTIONS(REENTRANT)`やコンパイラ最適化（`OPTIMIZE(3)`など）による「レジスタ渡し」の挙動を無視してはならない。
- レジスタ渡し: 小さな値は汎用レジスタへ直接セットされる。
- スタック渡し: 大きな構造体などは、呼び出し元が確保した領域へのポインタを暗黙的に渡す。
この差異を理解せずに、自動変換ツールに頼り切ったマイグレーションを行うと、テスト環境では動くが、高負荷時にのみ発生する不可解なメモリ破壊が頻発する。
アーキテクトからの提言
PL/Iの`RETURNS`を扱う際は、常に以下の3点をチェックリストに入れてほしい。
1. INCLUDEファイルによる型定義の一元管理: `DECLARE`の記述漏れは死を意味する。ヘッダーファイルで型を固定し、全モジュールで共有せよ。
2. 型変換を明示的に行う: `RETURNS`の戻り値を受け取る側で、`FIXED BIN`から`PIC`への代入を行う際は、コンパイラのデフォルト変換に頼らず、`CAST`的な意味合いを持つ変換処理を意識せよ。
3. コンパイラオプションの統一: `DEFAULT(FIXEDBIN(31))`等の設定が全モジュールで統一されているか、ビルドJCLを再確認すること。
PL/Iのコードは、時代遅れの遺物ではない。適切に設計されたPL/Iプログラムは、今のJavaのフレームワークよりも遥かに速く、そして堅牢に動く。我々アーキテクトの仕事は、その堅牢さを現代の言語環境へ正確に翻訳し、あるいはレガシーの中でそれを守り抜くことにある。
次回のダンプ解析で迷ったら、まずはスタックトレースを追いかけ、`RETURNS`の戻り値がレジスタにどう格納されたか、その「1ビットの真実」に立ち返ってみてほしい。そこには必ず、答えがある。
