汎用機の深淵へ：PL/I `KEYED` 属性とVSAM制御の「危うい」作法
長年、メインフレームの心臓部で稼働し続けてきたPL/Iプログラム。昨今のマイグレーション案件において、JavaやC#への移行を検討する際、多くのアーキテクトが「なぜこれほどまでに堅牢なのか」あるいは「なぜこれほどまでに闇が深いのか」と頭を抱えるのが、VSAMの `KEYED` アクセス制御です。
今日は、単なるマニュアルの焼き直しではなく、コンパイラの裏側までを知り尽くした現場の視点から、`KEYED` 属性を伴う直接アクセス制御の勘所を紐解いていきます。
—
1. KEYED属性の背後に潜む「暗黙の規約」
PL/Iにおける `KEYED` 属性は、単なるファイルのオープンオプションではありません。これはOS（z/OS）のデータ管理機能であるDFSMSと、アプリケーション層を直結させる「論理的な橋渡し」です。
1
DCL VSAM_FILE FILE RECORD KEYED ENV(VSAM);
DCL KEY_VAR CHAR(10);
/ キーによる直接読み込みの定石 /
READ FILE(VSAM_FILE) INTO(REC_BUFFER) KEY(KEY_VAR);
このコード、一見シンプルですが、移行設計においては以下の点に注意が必要です。
- KEYLENGTHの暗黙的な解釈: JCLの `DCB` パラメータとプログラム側の `DCL` が乖離していると、実行時に `KEY condition` が発生します。特に、可変長レコード（VB）を扱う際の「キー位置のオフセット」は、マイグレーション時の再定義において最もバグを誘発しやすい箇所です。
- 例外処理の哲学: `ON KEY(VSAM_FILE) BEGIN; … END;` を安易に使うのは推奨しません。例外を拾いすぎて、本来検知すべき論理エラーを隠蔽してしまうからです。実務では、`READ` 直後の `ONCODE()` を検査するアプローチを強く推奨します。
—
2. アベンド（ABEND）を呼び込む「パックデシマル」の罠
VSAMのキーとしてパックデシマル（`DECIMAL FIXED(n,0)`）を使用している場合、移行時に地獄を見ることになります。
1
DCL KEY_PACKED FIXED DEC(7,0);
/ 内部表現: 0x12345C (正) / 0x12345D (負) /
JavaやC#に移行する際、この「内部符号（CやD）」の処理を適切にエミュレートし損ねると、キーが一致せず、バッチ処理が全滅します。特に `BINARY(31)` との混在演算では、コンパイラによる最適化で符号が反転することがあります。移行ツールに頼り切るのではなく、ダンプ解析を通じて、バイナリレベルでの一致を厳密に検証してください。
—
3. ポインタとBASE変数による動的メモリ操作
高負荷なバッチ処理で、動的にレコード構造を変えたい場合、`BASED` 属性と `ADDR` 関数を駆使することがあります。
1
DCL REC_PTR PTR;
DCL REC_BUFFER CHAR(256) BASED(REC_PTR);
/ 構造体の動的割り当てとマッピング /
ALLOCATE REC_STRUCT SET(REC_PTR);
READ FILE(VSAM_FILE) INTO(REC_BUFFER) KEY(KEY_VAR);
ここで重要なのは、`FREE` を忘れたことによるメモリリークではありません。「ポインタが指し示す先のアライメント」です。メインフレーム特有の境界調整（Boundaries）を無視してポインタ演算を行うと、稀に `S0C4` アベンドが発生します。これは最新のハードウェア（z16等）でも変わらない、計算機科学の原点です。
—
4. マイグレーション設計への提言
Javaへの移行を担当するテックリードの方々へ。VSAMの `KEYED` 読み込みを単純な `SELECT FROM TABLE WHERE KEY = ?` に置き換えるだけで済むと考えてはいけません。
- エッジケースの再現: CICSオンライン処理における `ENQ/DEQ`（排他制御）は、RDBMSのトランザクション分離レベルとは挙動が異なります。
- ダンプ解析の知見: `CEEDUMP` を読み解く力は、新言語のスタックトレースを読む力とは別物です。`OFFSET` からソースの行を特定するスキルを、移行先言語でも再現できる環境（デバッガの作り込み）を構築すべきです。
最後に
PL/Iは「時代遅れの言語」ではありません。ハードウェアの限界性能を引き出すために磨き上げられた、至高の道具です。もしあなたが今、レガシー移行の重責を担っているなら、コードを変換することに固執しないでください。「そのコードがなぜその形を成しているのか」というビジネスロジックの背景にある「設計の意図」を読み解くこと。それこそが、メインフレームアーキテクトに求められる、最後にして最大の仕事です。
我々には、数十年分の蓄積がある。それを次世代のシステムにどう昇華させるか。その議論こそが、真の技術者の仕事ではないでしょうか。
