現場で泣かないためのPL/I：RETURNS属性と「暗黙の型変換」の深淵
若手エンジニア諸君、お疲れ様。今日も今日とてJCLの海を泳ぎ、ABENDコードと格闘していることだろう。
PL/Iという言語は、CやJavaに慣れた現代のエンジニアから見れば、時に「古臭い怪物」に見えるかもしれない。しかし、この言語が持つ柔軟性と、IBMメインフレームという堅牢な環境との親和性は、今なお基幹システムの心臓部を支え続けている。
今日は、そんなPL/Iの基本でありながら、放置すると致命的なバグの温床となる「RETURNS属性による戻り値の定義」と「暗黙の型変換」について、現場の視点から深掘りしていこう。
—
なぜRETURNS属性を「省略」してはならないのか
PL/Iの`PROCEDURE`は、値を返す関数として設計できる。このとき、最も重要なのが`RETURNS`属性だ。
/i
/ 関数の定義 /
GET_VAL: PROCEDURE(P_INPUT) RETURNS(FIXED BIN(31));
DCL P_INPUT FIXED BIN(15);
/ ここで何らかの演算を行う /
RETURN(P_INPUT 100);
END GET_VAL;
ここで重要なのは、「呼び出し元(Caller)と呼び出し先(Callee)の定義が一致していない場合、コンパイラは文句を言わずに、メモリ上のビットパターンを強引に変換しようとする」という点だ。
例えば、`RETURNS(FIXED BIN(31))`と定義した関数を、`DCL VAL FIXED DEC(5,0);`で受け取ろうとしたらどうなるか。PL/Iは気を利かせて型変換を行ってくれるが、このとき「桁落ち」や「符号の不一致」が起きても、実行時エラーにならないことが多い。深夜のバッチ処理で、計算結果が突然謎の数値に化ける――その原因の多くは、この「暗黙の型変換」にある。
—
実践：VSAMアクセスとRETURNSを組み合わせる
現場でよくあるのは、VSAMファイルから特定のコードを取得し、それを加工して返す関数だ。以下に、現場で使える実装パターンを提示する。
/i
/ ———————————————————– /
/ 関数名: GET_CUST_LEVEL /
/ 目的: VSAMから顧客ランクを取得し、FIXED BIN(15)で返す /
/ ———————————————————– /
GET_CUST_LEVEL: PROCEDURE(IN_CUST_ID) RETURNS(FIXED BIN(15));
DCL IN_CUST_ID CHAR(10);
DCL WK_LEVEL FIXED BIN(15);
/ VSAM読み込み用の構造体などは省略 /
/ 読み込み失敗時はONユニットで制御フローを切り替えるのが定石 /
ON ENDFILE(CUST_FILE) BEGIN;
WK_LEVEL = -1; / 不明な場合は-1を返す /
END;
/ 実際の実務ではここにREADステートメントが入る /
/ WK_LEVEL = CUST_REC.LEVEL; /
RETURN(WK_LEVEL);
END GET_CUST_LEVEL;
デバッグとトラブルシューティングの極意
このコードを呼び出す側では、必ず以下のルールを守ってほしい。
1. DCLでの明示: 戻り値を受け取る変数は、必ず`RETURNS`で指定された型と完全に一致させること。
2. BUILTIN関数の活用: 型が曖昧な場合は、`FIXEDBIN()`や`CHAR()`といった変換用組み込み関数を明示的に挟む。これにより、後続の保守者がコードを読んだ際に「意図した変換」か「意図しない変換」かが一目で分かる。
3. ONユニットの活用: 関数の戻り値がエラーコード（例：-1や0）を返す設計になっているなら、呼び出し元では必ず戻り値のチェックを行い、異常時には`SIGNAL ERROR;`等で適切に後続処理をストップさせること。
最後に：メインフレームエンジニアの矜持
PL/Iのコンパイラは非常に優秀だが、それは「プログラマが意図を正しく記述していること」を前提としている。型変換をコンパイラ任せにするのは、時限爆弾を自ら埋め込むようなものだ。
「とりあえず動く」コードから、「メンテナンスしやすく、堅牢な」コードへ。関数定義一つひとつの`RETURNS`属性に、君の意図を込めてほしい。それが、長年このシステムを守り続けてきた先輩たちに対する、最大の敬意になるはずだ。
次は、`OPTIONS(MAIN)`とパラメータ受け渡し時の`BYADDR`/`BYVALUE`の罠について話そうか。また現場で会おう。
コメント