VSAMをどう持っていくか — KSDS/ESDS/RRDSとRDBMS化の判断

ホスト移行でCOBOLの変換と並ぶ難所がVSAMです。自動変換ツールはVSAMをリレーショナルなテーブルに落とし込んでくれますが、「機械的にテーブル化する」ことと「正しいデータモデルにする」ことは別。KSDS/ESDS/RRDSの性格を押さえたうえで、持ち方を判断する必要があります。

01VSAMの3種を思い出す

• KSDS（キー順） — 主キーでアクセスする、最もDB的なVSAM。代替インデックス（AIX）を持つこともある。移行の主役
• ESDS（エントリ順） — 書いた順に並ぶ。RBA（相対バイトアドレス）でアクセス。ログ的・追記的な使われ方
• RRDS（相対レコード番号） — レコード番号で直接アクセス。固定長・スロット的な使われ方

この3種は、RDBMSに移すときの自然な形が違います。ひとくくりに「テーブル化」で済ませると、後段の性能やロジックで無理が出ます。

02機械的テーブル化 vs 正しいデータモデル

自動変換は、VSAMのレコードレイアウト（COBOLのコピー句）を読んで、対応するテーブルを生成できます。しかしCOBOLのレコードには、RDBMSの設計思想と相容れない構造が普通に含まれます。

• REDEFINES — 同じ領域を複数の意味で使う。1カラムに落とすか、意味ごとに分けるか
• OCCURS（配列） — 1レコードに繰り返し項目。子テーブルに正規化するか、そのまま持つか
• フラグ・区分コードの束 — 1レコードに何十もの区分。正規化の誘惑と、既存ロジック互換のトレードオフ

03代替インデックスとキー設計の再現

KSDSの代替インデックス（AIX）や、PATH経由のアクセスは、COBOLプログラムが前提にしている検索経路です。RDBMS化するとき、これらはセカンダリインデックスとして再現しますが、注意点があります。

• VSAMのキーは「バイト列」で、EBCDICの照合順序に依存する。RDBMSのインデックス順とズレると、順次読み（START〜READ NEXT）の結果順が変わる（照合順序の罠と同根）
• 重複許可の代替キー、ユニーク制約の有無をレイアウトから正確に写す
• キー長・部分キーでのアクセスをアプリがしている場合の再現

04ファイルアクセスの意味論をどう保つか

COBOLは READ / WRITE / REWRITE / START / DELETE といったファイル操作でVSAMを触ります。Blu Age等の変換では、これらのファイル操作の意味論（ファイルステータス、EOF、重複キーエラーの戻り）を、DB操作の上で再現します。ここで「だいたい同じ」だと、エラー時の分岐でゲンとシンの挙動が食い違う。ファイルステータスコードでの分岐を多用するプログラムは、変換後の挙動を重点的に検証してください。

05CICSファイル制御からの脱却

オンライン（CICS）配下のVSAMは、CICSのファイル制御・排他・ジャーナルと一体で動いています。Web化（Angular等）に伴い、この排他制御やトランザクション境界を、移行先のDBトランザクションで再設計することになります。バッチとオンラインが同じVSAMを共有していた場合の同時実行制御は、特に丁寧な設計が要る領域です。

—まとめ

VSAM移行は「テーブル化できる」で油断すると、照合順序・ファイルステータス・排他制御で足をすくわれます。KSDS/ESDS/RRDSの性格を踏まえ、「構造を保つか正規化するか」を移行のゴールから判断し、代替インデックスとアクセス意味論を正確に写す。COBOLerの方なら、START〜READ NEXTの順序やファイルステータス分岐が命だと知っているはず。そこを設計の主役に据えてください。