VTOCフォーマット②
VTOCフォーマット②
VTOCのDSCBレコードについては、歴史的な経緯もあり、MVS、MSP、VOS3の3つのOSでは基本的な部分で互換がある。しかしながら、インデックスVTOC（索引付きVTOC）については必ずしも互換とはいかない。3つのOSとも考え方においては同じであるが、具体的な実装となると異なってくる。
MSP
MVSとMSPではインデックスVTOCの索引データセットについては基本的な構造において互換となっている。索引データセットの名前の付け方も同じである。外部仕様（API）も内部構造も基本的にMVSと互換と言ってよいが、実際には1980年代後半の頃（MVS/XAからMVS/ESAの初期）のMVSのインデックスVTOCとの互換となっている。
索引データセットと索引レコード
VIRと呼ばれる2048バイトの固定長レコードの集合である点はMVSと同じである（※MVSではEAVボリュームでは8192バイトに拡張されているが、同容量程度のDASDボリュームであれば同じ2048バイトのVIRレコードが使われる）。
VIRにはMVS同様に、VIXM、VPSM、VMDSおよびVIERがあり、それぞれの並び順も同様となっている。ただし現在のz/OSでは、MVS独自にフィールドが追加されコントロールの方法もエンハンスされているので、まったくの互換にはなっていない。一言で言えば、MSPのインデックスVTOCは昔のMVSと同じであるが、MVSと同じようにはエンハンスされていないので内部の細かい部分では異なってきている。例えば、MVSでは従来空フィールドであった部分に、SMS関連フラグやラージ・デバイス関連のフラグやポインターなどが追加されている。
ただし、よほどのソフトウェアでない限り索引データセットのVIRを直接参照したり、書き換えたり、することはほとんどない。
CVAFマクロ
VTOCのDSCBレコードやボリューム内の空きスペース情報を得るためのCVAFマクロについても、互換サービスとなっている。DSCBそのものをアクセスするためのCVAFDIRとCVAFSEQに関しては同じ機能とインターフェースを持つが、部分修飾名指定のデータセット名に一致するDSCBをリストアップするCVAFFILTマクロは提供されていない。必要ならば同様の機能をプログラム側に独自に実装する必要がある。また、ボリューム内の空きスペース情報にアクセスするためのCVAFDSMマクロも基本的に互換であるが、ラージ・デバイスで必要となる4バイト相対トラックアドレスのインターフェースはMSPのCVAFにはない。
VOS3
VOS3にもVTOC索引の機能がある。しかし同じなのは、DSCBの他に索引データセットを持ってデータセット毎のDSCBの位置やボリューム内の空きスペースの管理を行う、という考え方だけである。考え方が同じなので、索引データセットも似たような構成をもっているが、レコードの構造やフィールド名や意味まで同じようなことはない。また、APIにも互換はない。そもそもVOS3では索引付きVTOCとは呼ばずに論理VTOCという呼び方となり、呼び方からしてMVSとは異なる独自のものなのだ、と主張しているように思える。
VOS3もMSP同様にVTOC索引を使用するかどうかはユーザーの任意であるが、H-6588-9型ディスク装置を使用する場合は論理VTOCが必須となる。
- SYS1.LVTOC.Vxxxxxx
- LVCBレコード
- BMAPレコード
- DMAPレコード
- TMAPレコード
- JRNLレコード
- INDXレコード
索引データセット
VOS3の論理VTOCでは、VTOC索引データセットを論理VTOC索引部と呼んでいる。データセット属性はMVSと同じで、2048バイトの固定長レコードの順次データセットである。外見上のDSORGはPSではなくDAU（直接編成）となっているが、ランダムアクセスする順次データセットという意味では同じである。DSNもMVSの「SYS1.VTOCIX.Vxxxxxx」のVTOCIXがLVTOCに変わっているだけで、Vxxxxxxのxxxxxxが、索引データセットの格納ボリューム名である点も同じある。
索引レコード
VOS3のLVTOCデータセット（論理VTOC索引部）は、6種類のレコードによって構成される。各々のレコードの役割はMVS側の各VIRレコードに相当するが、その内容に互換はない。
LVTOCデータセットの先頭に位置し、後続のBMAPからINDXの各レコードのレコード数などが管理されている。
LVTOCデータセット内の未使用レコードを管理するためのビットマップ情報が格納されている。
VTOC内の未使用DSCBを管理するためのビットマップ情報が格納されている。MVSのVTOC索引データセットにおけるVMDSレコードに相当する。
VOLUME内の空きスペースを管理するためのビットマップ情報が格納されている。MVSのVTOC索引データセットにおけるVPSMレコードに相当する。
LVTOCデータセットに対する更新要求のジャーナルレコード。MVSのVTOC索引データセットでは、先頭のVIXMレコードで管理される。
VTOC内のDSCB1を検索するための索引情報が格納されている。MVSのVTOC索引データセットにおけるVIERレコードに相当する。
索引はレベルによる階層管理がされているが、その構造はMVSとは異なる独自のものとなっている。また、MVSではキーとなるDSNは圧縮されずにそのまま格納されるが、VOS3ではDSNの先頭からの重複部分が削除された形で格納され、同様の名前を持つDSNについてはある種の圧縮が行われるようになっている。
LVTOCデータセット内では、上記のレコードがLVCB、BMAP、DMAP、TMAP、JRNL、INDXの順に並んでいて、BMAPからINDXの各レコードは複数レコードで構成される場合がある（レコード種類ごとに連続して配置されているようである）。INDX以外のレコードは、ボリュームをイニシャライズしない限りはレコード数が増減しないと考えられる。INDXレコードは作成されるデータセットが増えれば、それに対応して増加して行く。
なお、BMAP、DMAP、TMAPの各レコードのビットマップ領域は2000バイト分あり16000のスペースを管理できる。DMAPであれば1つのレコードで16000個のDSCBが、TMAPであれば1つのレコードで16000個のトラックが管理できる。
VTOCアクセスAPI
VOS3では、MVSにおけるCVAF互換または相当するAPIサービスは提供されていない。従来通りOBTAINマクロによってDSCBをDSN（OBTAIN SEARCH）あるいはCCHHR（OBTAIN SEEK）によって読み込むことになる。ただし、論理VTOCを持つボリュームの空きスペース情報を得るには、従来のOBTAIN SEEKによってDSCB5のチェインをたどりながら読み込む方法は使えない（空きスペースはFormat-5 DSCBレコードではなくLVTOCデータセットで管理されるため）。代わりにOBTAIN XSEEKを使って、仮想のFormat-5 DSCBレコードを読み込むことができる。OBTAIN XSEEKは、LVTOCデータセットのTMAPレコードから、Format-5 DSCBレコードをシミュレートする機能を持つVOS3独自のAPIである。