Part 4 – VSAM Volume Data Set

By Blair Svihra


An ICF catalog is comprised of two entities:

  • the Basic Catalog Structure (BCS) and
  • the VSAM Volume Data Set (VVDS).

Up until DFP 3, the VVDS was strictly used as a repository for describing the VSAM data sets physically residing on the volume with the VVDS.  Variable length records residing in the VVDS, not the BCS, contain the critical information describing each VSAM entity such as extent information, high allocated/high used Relative Byte Address (RBA), Access Method Data Statistics Block (AMDSB) information and data set attributes.

With the advent of system managed storage (SMS) in DFP 3, class information (data class, management class and storage class) for each system-managed storage VSAM and nonVSAM data set is duplicated in the BCS and VVDS.  No class information resides in the Volume Table of Contents (VTOC).

The VVDS name, by convention, is a special reserved name – SYS1.VVDS.Vvolser.  The volser in the VVDS name must match the volser in the unit control block (UCB) of the device on which it resides.  There is only one VVDS per volume.  It is a high activity data set and should be allocated near the VTOC if possible.  The VVDS can be created explicitly by an IDCAMS DEFINE CLUSTER –

 

//jobname   JOB    …
//stepname EXEC PGM=IDCAMS
//SYSPRINT  DD     SYSOUT=*
//SYSIN         DD     *
   DEFINE CLUSTER(NAME(SYS1.VVDS.VZZZZZZ) –
       VOLUMES(ZZZZZZ) NONINDEXED CYLINDERS(3 1)) –
       CATALOG(ICFCAT.UCAT)

 

If a VVDS does not exist on a volume, a VVDS is dynamically created when the first VSAM data set or SMS managed nonVSAM data set is defined on a volume.  The control interval size of the VVDS is always 4K.  There are no tuning parameters.  The default space allocation during an implicit define on a system prior to DFP 3 was TRK 3,2.  The default space allocation is currently TRK 10,10.  This default value can be changed via a Catalog Address Space (CAS) modify or via IGGCATxx parmlib member.

Additional records describing nonVSAM data sets are contained in the VVDS if the volume is SMS managed.  With the addition of these extra records, there is a good possibility that the VVDS may go into secondary extents, causing fragmentation and poor performance.  The same amount of planning should go into sizing of the VVDS as is usually done with the VTOC.  Both are easy to allocate but are not easily expanded.  It is advisable to explicitly define and position the VVDS on a volume.  The default values for an implicitly defined VVDS should not be used if the volume will be on system managed storage or if a large number of clusters will reside on the volume.  The explicit define previously listed will suffice for most instances.

The VVDS is a special entry sequenced data set (ESDS).  In a normal ESDS, records can be added but not physically deleted.  They can be logically marked by the user as deleted but will physically remain unless replaced by another record of the exact same size by a user program.  All insertions take place at the end of the file.  Altering the size of the record in an ESDS can be accomplished by marking the current record as deleted and inserting the modified record at the end of the data set.  The term flexibility is not generally associated with an ESDS, which is essentially a sequential data set, but with the added ability of random record selection by direct access through RBA specification.

In the VVDS, on the other hand, records can be physically added, expanded and removed anywhere that available free space exists in a control interval (CI).  VVDS processing is under the control of the VVDS Manager – IGG0CLE0 or IGG0CLHV.  All processing done by the VVDS Manager is on the CI level.

When a record is added to the VVDS, a CI with enough available free space to contain the record is located.  The entire CI is then read into storage.  The record to be inserted is moved after the last record in the CI and the CI control information is updated.  A record definition field (RDF) describing the length of the record inserted is added.  The control interval definition field (CIDF) is updated with the new available free space left in the CI and the offset to the beginning of available free space in the CI.

When a record is removed from the VVDS, all records in the CI following the deleted record are moved back toward the beginning of the CI, overlaying the space occupied by the deleted record.  The deleted records corresponding RDF is removed, and the CIDF is updated with the new available space information in the control interval.

When a record is expanded, the CI’s CIDF is checked to determine whether sufficient available free space exists in the current CI containing the record to be enlarged.  If sufficient space exists, the expanded record replaces the existing record.  Any records following the original record are moved further down in the CI and directly follow the updated record.  The corresponding CIDF is updated accordingly.  If sufficient free space is not available in the CI containing the record to be expanded, another CI with enough space to contain the updated record will be located.  The original record will be removed from its current CI, and the updated record will be added to the new CI. Although the VVDS is defined as an ESDS, the flexibility of the VVDS Manager allows for efficient use of internal free space.

 

VVDS Records

Five distinct records exist in the VVDS –

  • VSAM Volume Control Record (VVCR)
  • VSAM Volume Record (VVR)
  • NonVSAM Volume Record (NVR)
  • VVCR Catalog Name Record (VVCN)
  • VVCR Space Map Extension Record (VVCM)

 

The VVDS will always contain one VVCR and at least one VVR (the VVDS self-describing VVR).  NVR records will only exist in the VVDS on system managed storage volumes.  The VVR is always the first record in the VVDS.  It is located at RBA 0 and occupies the entire CI.  It contains the names of up to 36 BCSs having data set components residing on the volume.  Each catalog name slot has the following format –

+0 (44)   Catalog name

+44 (4)   RBA of the BCS data component

+48 (4)   RBA of the BCS index component

+52 (4)   RBA of the BCS sequence set

 

The RBA values are zero if the catalog does not physically reside on the volume.  If the catalog does reside on the volume, the RBA pointers to the data, index and sequence set (if the BCS was defined with IMBED) are CI pointers, not direct RBA values.  They point to the control interval in which the record resides.  By pointing to the CI, the VVDS Manager can add and delete other records in the same control interval without having to update the RBA values in the VVCR for the catalog records (if they should change position within the CI).  The catalog names will remain in the VVCR even after the last VSAM entity is removed from the volume.  The catalog names can be removed via IDCAMS if desired.  RBA values in the VVCR may point to additional VVCM and/or VVCN extension records.

The VVCR also contains an internal space map detailing each control interval in the VVDS.  The space map is comprised of two-byte entries which describe the available free space in each CI (matches the CIDF+2(2) of its corresponding VVDS CI).  When locating a CI in the VVDS to add a new record, the VVDS Manager scans the space map in the VVCR (or VVCM extension record) to locate the first CI with sufficient free space to contain a new record.  When one is located, a direct read for the CI is done and processing continues.  The use of a space map is much more efficient than reading the VVDS sequentially to locate the first CI with available free space.  Whenever a CI is updated, the resulting free space value in the CI’s CIDF is updated in the appropriate space map.

The number of control intervals in the VVDS is also kept in the VVCR.  This value indicates the number of space map entries used in the VVCR and any VVCM extension records.  The first two entries in the VVCR space map are always set to zero to indicate that no other records can reside in the control intervals containing the VVCR (RBA 0) and the self-describing VVR (RBA 4096).

 

VVR and NVR records

VVRs and NVRs are comprised of cells and subcells.  VVRs describe the VSAM components that physically reside on a volume, while NVRs describe the system managed storage nonVSAM data sets on a volume.  These records can appear anywhere in the VVDS beginning at RBA 8192.

 

A VSAM data set component will have a primary VVR in the VVDS on the volume which contains the first extent of the data set.  A primary VVR will only appear on the first volume of the data set.  Secondary VVRs are used to describe the component when they exist on additional volumes.  The volume information cell (X’23’) in the secondary VVR will only describe the extents on that volume.

 

A secondary VVR will appear on all volumes containing the data component if the data set is indexed and the IMBED option was specified at DEFINE time.  The secondary VVR, in this case, will describe the extents of the sequence set on the primary volume and any secondary volumes on which the data set resides.  Candidate volumes do not contain secondary VVRs; “Q” type VVRs will be inserted when data expands to those volumes.

 

Duplication of extent information exists in the volume information cell (X’23’) and the VTOC.  Should a discrepancy exist between the two, the VVDS extents take precedence over the VTOC extents when accessing the data set.  Since the VVDS is a modified ESDS structure (as opposed to a keyed or indexed structure), duplicate VVRs can exist in the VVDS.  This error condition may occur due to incomplete delete and defines, system failures and so on.  If the VTOC and VVDS extents describing VSAM data sets residing on the volume do not match, volume free space integrity is compromised.

As a performance enhancement, BCS catalog entries for VSAM data sets (and system managed storage nonVSAM data sets) contain RBA pointers to quickly locate their corresponding VVR or NVR records in the VVDS.  This eliminates the need to sequentially search the VVDS for a specific record when accessing a VSAM data set.  These VVR pointers in the BCS are not direct RBA pointers to the physical location of the VVR, but they instead point to the control interval in which the VVR is located.  Again, this allows the VVDS Manager to add, modify and delete any record in a CI without updating RBA pointers in the BCS for other VVRs (if their location should be changed within the CI).  If the RBA value in the BCS is incorrect, the VVDS Manager incurs the overhead of reading the VVDS sequentially to find the desired VVR.  After locating the desired VVR, the VVDS updates the BCS catalog entry with the correct CI RBA value so the overhead of the sequential search is not repeated on future accesses of the data set.

NVR records, unlike VVR records, do not contain extent information.  Only class and backup information, and a catalog name are contained in the NVR record.  An NVR will only appear on the primary volume for a multivolume system managed nonVSAM data set.  No NVR record exists for the VTOCIX on a system managed storage volume.

The VVDS self-describing record always resides at RBA 4096.  This VVR describes the VVDS itself.  No other records can exist in this CI.  The self-describing VVR contains the only reference in the VVDS to the volser on which the VVDS resides.  Relabeling the device does not change the Format 1/8 DSCB or the self-describing VVR.

 

VVCR Extension Records

The VVCN records lifts the 36 catalog limitation imposed on a VVDS.  Without this extension record, the VVCR could only reference a finite number of catalog names.  Each VVCN can reference an additional 72 catalogs.  The first VVCN record is chained off the VVCR by RBA (VVCR+8(4)).  An entire CI is dedicated to this record.  VVCN records can be chained together if additional catalog name slots are needed.

 

The presence of VVCN records in a VVDS may complicate catalog or volume recovery.  The more catalogs that point to a specific volume needing recovery, the more time consuming and intricate the synchronization processes becomes.  Limiting the number of catalogs residing on a volume, or that allowed to allocate VSAM on a specific volume, should be explored – either through specific installation standards or third party VSAM pooling packages.  There is currently no facility available through IBM to restrict or limit catalog access to specific volumes; however, there is a simple way to maintain a volume as nonVSAM.  Allocation of the VVDS as a nonVSAM data set will successfully prohibit any VSAM data set from being defined on a volume.

 

//jobname   JOB    …
//stepname EXEC PGM=IEFBR14
//SYSPRINT  DD     SYSOUT=*
//DDN1         DD     DSN=SYS1.VVDS.Vvolser,DISP=(NEW,KEEP),
//    UNIT=SYSALLDA,VOL=SER=volser,SPACE=(TRK,(0))

 

The VVCM record removes the VVDS size limitations which exist by having a finite number of two byte space map entries describing available free space in each VVDS CI.  Since 2048 bytes of the VVCR are allocated to the space map, the maximum useful size of a VVDS is 1024 CIs.  On a 3380 device, the VVCR can map a VVDS with a size just over six cylinders (or 100 tracks).  If a VVDS expands later, a VVCM extension record will automatically be created by the VVDS Manager and chained off the VVCR by RBA (VVCR+12(4)).  Each VVCM record can reference an additional 2036 CIs.  An entire CI is dedicated to this record.

The VVDS is an important part of the ICF catalog environment in terms of structure, performance and recoverability.  Its internal design provides an efficient and flexible organization that will easily lend itself to future enhancements.

 


Blair Svihra has been in the z/OS industry for over 30 years, having extensive expertise with ICF catalogs. He was the original author of VSAM Mechanic (Catalog Solution) and has contributed to many other products, including T-REX and Universal Data Manager (UDM).  Blair is currently a Sr. Product Development executive with Dino-Software Corp.

 

About Dino-Software

Dino-Software Corporation develops enterprise-wide solutions for the management, analysis, protection, and repair of complex z/OS mainframe environments.  Dino-Software has long been acknowledged for its superiority in ICF catalog management and technical support, helping organizations ensure their business-critical assets remain online and recoverable in a disaster.  Learn more about Dino-Software and its z/OS mainframe storage solutions at https://dino-software.com.


 

Click Here To Read More DINO Tech-Talk Articles