現場で差がつくPL/I：VSAM KEYEDアクセスの深淵と「予約語なき世界」の罠
ようこそ、メインフレームの深淵へ。
大規模バッチの改修で、数万ステップの既存ソースと格闘している君たちなら、一度はこう思ったことがあるはずだ。「なぜPL/Iには、これほど自由奔放な構文が許されているのか」と。
C言語やJavaのような言語に慣れた若手エンジニアから見れば、PL/Iの「予約語が存在しない（文脈によって解釈が変わる）」という仕様は、悪夢のように映るだろう。だが、この自由度こそが、半世紀にわたり基幹システムを支え続けてきたPL/Iの強靭さの源泉でもある。
今日は、VSAM（KSDS/RRDS）アクセスにおける `KEYED` ファイル操作と、現場で必ずと言っていいほど遭遇する「検索失敗時の制御」について、実務の勘所を伝授する。
—
1. 予約語なき言語、PL/Iの美学と危険性
PL/Iには、厳密な意味での「予約語」がない。`IF` や `THEN` といったキーワードでさえ、変数名として使用可能だ。コンパイラは、その位置と文脈で「これは命令か、それともデータか」を判断している。
例えば、`DECLARE IF FIXED BIN(15);` と書けば、`IF` は変数になる。これは柔軟だが、メンテナンス時には致命的な罠になることもある。バッチ改修時に変数名を定義する際は、後続のエンジニアへの敬意を込めて、極力予約語と被るような名前は避け、`WK_` や `FLG_` といったプリフィックスを付けるのが、我々ベテランの嗜みだ。
—
2. KEYEDアクセス：GENKEYとKEYTOの現場的運用
VSAMファイル（特にKSDS）を扱う際、単なる `READ` ではなく `KEYED` アクセスを行うことは、パフォーマンスとロジックの簡潔化において必須のスキルだ。
KEYTOとGENKEYの使い分け
- KEYTO: 読み込んだレコードのキーを格納先にコピーする。範囲検索を行いたい際、次のキーが何であるかを特定するのに重宝する。
- GENKEY: 汎用キー（Generic Key）検索だ。例えば「先頭4桁が ‘1234’ であるレコード」を総なめしたい場合、すべてのキーをフル入力する必要はない。`GENKEY` オプションを指定すれば、指定した長さまでの前方一致検索が容易になる。
—
3. 実践コード：安全なKEYEDアクセスとONユニット
現場で最も恐ろしいのは、検索失敗時（キーが存在しない場合）のハンドリング漏れだ。`ON KEY` 条件を制する者が、バッチの堅牢性を制する。
1
/ VSAMファイル定義：KSDSを想定 /
DCL VSAM_FILE FILE RECORD KEYED ENV(VSAM);
DCL WK_KEY CHAR(10);
DCL WK_REC CHAR(100);
/ 検索失敗時の制御をONユニットで定義 /
ON KEY(VSAM_FILE) BEGIN;
PUT SKIP LIST(‘警告：対象キーが見つかりません。キー値:’ || WK_KEY);
/ ここでフラグを立てるか、リターン処理を記述 /
GO TO KEY_NOT_FOUND_RTN;
END;
/ — メイン処理 — /
WK_KEY = ‘A001’;
READ FILE(VSAM_FILE) INTO(WK_REC) KEY(WK_KEY);
/ ここに後続の処理が続く /
…
KEY_NOT_FOUND_RTN:
/ エラー後のクリーンアップ処理 /
このコードのポイント
1. ON KEYの局所化: この `ON` ユニットは、このスコープ内でのみ有効だ。特定の検索に対してのみ有効にしたい場合は、`BEGIN` ブロックで囲むのが定石である。
2. BUILTIN関数の活用: ファイルの状態を知りたいときは `STATUS(VSAM_FILE)` を活用せよ。`ON` ユニット内でどの理由でエラーになったか（キーなしなのか、ハードウェアエラーなのか）を判定するのに必須だ。
—
4. トラブルシューティングの極意
もし君が担当するバッチが「なぜか特定のキーで異常終了する」という事態に陥ったら、まずは以下の3点を確認してほしい。
1. キーの長さ: `KEY` で指定した変数と、VSAM定義上のキー長は完全に一致しているか？ 埋め込みスペースが混入していないか。
2. BUFFERの整合性: `READ` の直後に別のIO処理を挟んでいないか？ PL/IのIO制御は、バッファの状態に依存する部分がある。
3. コンパイラオプション: `CHECK` や `STRINGRANGE` を有効にしてコンパイルしたか？ 開発環境でこれらをオフにしている現場が多いが、不可解なメモリ破壊の犯人を突き止めるには、これらをオンにして走らせるのが一番の近道だ。
—
最後に：レガシーは「負債」ではない
「PL/Iは古い」と嘆く前に、考えてみてほしい。これほどまでに厳密なメモリ管理と、柔軟なファイルアクセス、そして堅牢な例外処理（ONユニット）が、数十年前にすでに完成していたことを。
君たちが今書いているコードは、あと20年後も誰かに読まれる可能性がある。予約語を持たない自由な言語だからこそ、コードは「誰が読んでも同じ挙動であると確信できる」ほど、明快でなければならない。
何かに行き詰まったら、いつでも戻ってくるといい。メインフレームの深淵は、常に君たちの挑戦を待っている。
