メインフレームの「心臓部」を操る：PL/IにおけるVSAM直接アクセスと例外処理の極意
諸君、今日もバッチジョブのログと格闘しているか？
PL/Iという言語は、一見すると古臭い「化石」のように思えるかもしれない。だが、金融機関や公共システムの根幹を支えるVSAM（Virtual Storage Access Method）を、これほどまでにエレガントかつ強力に制御できる言語は他にない。
今日は、若手が現場で一番苦労するであろう「KEYED属性による直接アクセス」と、そこで発生する「ON条件のハンドリング」について、実務の勘所を伝授する。
—
1. KEYED属性の真実：直接アクセスの作法
VSAMのKSDS（Key Sequenced Data Set）を扱う際、シーケンシャルな読み込みではなく、特定のキーを指定してレコードをピンポイントで取得する。この時、ファイル宣言に必ず付けなければならないのが `KEYED` 属性だ。
これを忘れると、コンパイラはコンパイル時に冷酷なメッセージを突きつけてくるか、実行時にランタイムエラーでジョブをABEND（異常終了）させる。
1
/ VSAMファイル定義の例 /
DCL MST-FILE FILE RECORD INPUT KEYED
ENV(VSAM ORGANIZATION(INDEXED));
ここで重要なのは、`KEY`（キー値）を格納する変数の型だ。ファイル定義時のキー長と一致していることは大前提だが、もし型が不一致だと、メインフレームのメモリ上のバイナリ表現で予期せぬズレが生じ、ファイルが見つからないという「幻のレコード」現象に陥る。現場でデバッグに数日溶かす若手の典型的なパターンだ。
—
2. 「ON条件」こそがPL/Iの真骨頂
バッチプログラムを書く際、`READ` が成功することを前提にするのは素人だ。キーが存在しない、あるいは物理的なI/Oエラーが発生した際、どう振る舞うか。ここで登場するのが `ON` ユニットである。
多くの初心者が `IF` 文でエラーチェックをしようとするが、PL/Iには強力な割り込み処理機構がある。
1
/ キーが見つからなかった場合のハンドリング /
ON KEY(MST-FILE) BEGIN;
PUT SKIP LIST(‘警告: 指定されたキーのレコードは存在しません’);
/ ここでフラグを立てて処理を継続させるのが定石 /
GOTO END_OF_PROCESS;
END;
`ON KEY` を使うことで、メインのロジックから「エラーチェックのノイズ」を分離できる。これにより、コードの可読性が格段に向上する。ただし、`ON` ユニットのスコープ（有効範囲）には十分に注意せよ。うっかりブロックの外側に漏れ出た `ON` ユニットが、意図しない場所で悪さをするのは、現場では「よくある地雷」だ。
—
3. 実践：VSAM直接アクセス・コーディング例
以下に、実務で頻出する「キー指定読み込みと更新」の基本構造を示す。
1
PROCESS_MAIN: PROC OPTIONS(MAIN);
/ ファイルとキーの宣言 /
DCL MST-FILE FILE RECORD UPDATE KEYED ENV(VSAM);
DCL MST-REC CHAR(100);
DCL KEY-VAL CHAR(8) INIT(‘A1002003’); / 検索対象キー /
/ ON条件の定義：必ず処理の最初で定義する /
ON KEY(MST-FILE) BEGIN;
PUT SKIP LIST(‘KEY ERROR発生: ‘ || KEY-VAL);
/ 適切なエラーリカバリ処理を記述 /
END;
OPEN FILE(MST-FILE);
/ KEY指定によるダイレクトアクセス /
READ FILE(MST-FILE) INTO(MST-REC) KEY(KEY-VAL);
/ レコード更新処理 /
SUBSTR(MST-REC, 50, 10) = ‘UPDATED’;
REWRITE FILE(MST-REC) FROM(MST-REC);
CLOSE FILE(MST-FILE);
END_OF_PROCESS:
RETURN;
END PROCESS_MAIN;
4. ベテランからのアドバイス：デバッグのコツ
1. BUILTIN関数の活用: `ONKEY()` や `ONCODE()` を使え。エラー発生時に何が起きたのか、エラーコードをログに出力するだけで、調査時間は劇的に短縮される。
2. CLOSEの徹底: メインフレームのシステムリソースは有限だ。特に更新モードでファイルを開いた場合、異常終了時にファイルが「排他制御」されたままになり、後続ジョブが止まる。`ON ERROR` ユニット内でファイルを確実にクローズする設計を心がけること。
3. 大文字記述の美学: 現代のIDEは小文字も解釈するが、メインフレームの古いユーティリティやダンプ出力は依然として大文字だ。ソースコードを統一することで、保守時の検索効率が確実に上がる。
PL/Iは決して「古い」のではない。「完成されている」のだ。VSAMの構造を深く理解し、この言語の柔軟な例外処理を使いこなせれば、君はどんな複雑なバッチ改修でも恐れることはない。
次回の改修案件が来たとき、このコードの美しさを思い出してくれ。健闘を祈る。
