メインフレームの背骨、PL/I：PROCEDUREブロックの「作法」を再考する
諸君、お疲れ様。今日もバッチのログと睨めっこしているのか？
大規模なマイグレーションや、30年選手のレガシー改修を担当していると、PL/Iのコードがいかに「構造」という名の規律によって守られているか、改めて痛感することがあるだろう。
今回は、PL/Iの最小実行単位である `PROCEDURE` ブロック、そしてそれを囲う `END` ステートメントについて、現場の視点から深掘りしていこう。単なる構文の暗記ではなく、「なぜそう書くのか」というコンパイラの挙動と保守性を意識した話だ。
—
PROCEDUREの呼吸：ブロックの開始と終了
PL/Iにおいて、`PROCEDURE` は単なるコードの塊ではない。それはメモリ管理、自動変数の生存期間（スコープ）、そしてエラーハンドリング（ONユニット）の基点となる「閉鎖空間」だ。
特に `OPTIONS(MAIN)` を付与した主手続きは、JCLのEXECカードから呼び出される入り口だ。ここが正しく構成されていないと、異常終了時のダンプ解析で路頭に迷うことになる。
実践的なソースコード例
1
/ —————————————————————— /
/ プログラム名：BATCH001 /
/ 概要：VSAMマスタ更新バッチ /
/ —————————————————————— /
BATCH001: PROCEDURE OPTIONS(MAIN);
/ 宣言部：属性は明示的に記述する（DEFAULT設定に依存しないこと） /
DCL VSAM_FILE FILE RECORD SEQUENTIAL UPDATE ENV(VSAM);
DCL 1 REC_STRUC,
5 KEY_ID CHAR(8),
5 DATA_VAL FIXED BIN(31);
/ ONユニットによる例外制御（ブロック固有の生存期間を持つ） /
ON ENDFILE(VSAM_FILE) BEGIN;
PUT SKIP LIST(‘EOF REACHED: PROCESSING FINISHED’);
CLOSE FILE(VSAM_FILE);
STOP;
END;
/ 処理開始 /
OPEN FILE(VSAM_FILE);
DO FOREVER;
READ FILE(VSAM_FILE) INTO(REC_STRUC);
/ BUILTIN関数によるデータ検証 /
IF VERIFY(KEY_ID, ‘0123456789’) ^= 0 THEN DO;
PUT SKIP LIST(‘INVALID KEY FOUND: ‘ || KEY_ID);
ITERATE;
END;
/ 更新処理ロジックがここに続く /
END;
/ PROCEDUREの終了には必ずラベルを付ける習慣を /
END BATCH001;
—
現場で「泣かない」ための3つの鉄則
1. ENDステートメントには必ずラベルを付ける
上のコードを見て気づいたか？ `END BATCH001;` と記述している。
コンパイラは `END;` だけでも文法上は許容するが、数千行あるコードでブロックの入れ子が深くなったとき、どの `END` がどの `PROCEDURE` なのか判断できなくなる。特に `DO` グループや `BEGIN` ブロックが混在するコードでは、必ず `END ラベル名;` を徹底しろ。これは後輩にコードレビューを依頼する際の最低限の礼儀でもある。
2. ONユニットのスコープを理解する
`ON ENDFILE` のような例外処理は、それが定義されたブロックの終了とともに無効化される。もしメインのPROCEDUREの中で別のプロシージャを呼び出している場合、ONユニットがどこで有効で、どこで無効になるかを意識しないと、予期せぬ「ONCODE」の連鎖や、デバッグ不可能な無限ループに陥る。
3. BUILTIN関数を積極的に活用する
`SUBSTR` や `VERIFY`、`LENGTH` といったBUILTIN関数は、コンパイラが最適化された機械語を生成してくれる。自分で独自の比較ロジックを組むよりも、標準関数を使う方が圧倒的に安全で、かつ保守性も高い。特にVSAMのレコード処理においては、固定長・可変長の判定に `LENGTH` 関数を活用するのは基本中の基本だ。
—
コンパイラは嘘をつかない
PL/Iのコンパイラは、極めて厳格だ。手続きの開始と終了の不整合は、コンパイルエラーとして明確に弾かれる。しかし、論理的な「ブロックの切り方」が悪いと、実行時にメモリリークを起こしたり、予期せぬタイミングでファイルがクローズされたりと、不可解な挙動を引き起こす。
我々メインフレームエンジニアの使命は、単に動くコードを書くことではない。「10年後に担当する誰かが、このコードの構造をひと目で理解し、安全に改修できる」状態を保つことにある。
`PROCEDURE` は、そのプログラムの「顔」だ。美しく、かつ強固なブロック構造を意識して、今日も堅牢なシステムを作り上げよう。
何か行き詰まったら、いつでも聞いてくれ。マニュアルの行間を埋める知見を、また共有しよう。
コメント