Skip to content
CA Vantage™ Storage Resource Manager - 14.0
Documentation powered by DocOps

Reference Data Sets

Last update December 5, 2018

Activity (Message) Log Data Set

The Activity Log data set stores messages issued by the system itself, as well as any messages rerouted from CA Disk.

In order not to lose messages when the subsystem is canceled, or because of other hang situations in the z/OS system, the messages are also written to an unblocked journal data set in parallel with the ordinary logging. The journal will be emptied when the logging is done. At startup, the journal is read and, if anything is found, it is put to the log and the journal is cleared again.

The following system parameters control the Activity Log, which is internally written to disk as a logged object:

Note: The Message data set must remain with the same attributes assigned by Vantage (unblocked, zero secondary allocation, specific number of blocks). If any attributes are changed by SMS, the results are unpredictable. For example, if partial release =IMMED_YES is assigned in management class, abend D37 can occur.

PDS Directory Statistics

When maintenance is delivered for a VPnnnnnn member of CCTUPARM, it is detected at system startup, and this is indicated by recording the current date within the directory information for the member. Normally this is done only once. If the directory statistics are deleted from this product library, it will be detected and updated once again. Whenever this happens, the following messages will be given:

VKG0001I VPnnnnnn members in CCTUPARM require directory statistics.

VKG0001I Directory statistics are being created now.

VKG0001I Directory update 1 in process, MBR=VPnnnnnn, DSN=data.set.name

VKG0001I Directory update 2 in process, MBR=VPnnnnnn, DSN=data.set.name

VKG0001I     2 directory update(s) successful out of  2 attempted.

If the startup task cannot update CCTUPARM, the following messages are given:

VAN0999E Error getting/updating VPnnnnnn members: ABEND INTERCEPTED

VAN0999E Shutting down. Access or update of CCTUPARM members failed.

VAN0999E Correct the condition and restart.

Similarly, CA Vantage SRM maintains special information within the directories for members in the script and external filter libraries. This is done when you create the script or external filter. If this information is accidentally lost, it detects and rebuilds it automatically. Since your external filter library may contain hundreds or thousands of members, messages are also issued when they require directory updates. The following are given:

VKG0001I Members in the External Filter Library require special userdata

VKG0001I in the directory.

VKG0001I Special userdata is being created now and may take a few minutes.

VKG0001I A progress status message will be given every 200 updates.

VKG0001I Directory update   1 in process, MBR=name001, DSN=your.extfltds

VKG0001I Directory update 200 in process, MBR=name200, DSN=your.extfltds

VKG0001I Directory update 400 in process, MBR=name400, DSN=your.extfltds

VKG0001I   421 directory update(s) successful out of 421 attempted.

Under normal operating conditions, this recovery process is not needed and the messages will not be seen. It is only if someone updates this library without using the client interface that auto-recovery is invoked and the above messages will be seen.

Profile Data Sets

When a user logs on for the first time, the system automatically creates a user profile data set.

System parameter PROFPFXU controls the format of the data set name created for each user profile, either:

DSN=logon ID.VANTAGE.PROFILE (this is the default format)

Or

DSN=ca.vant.PROFILE.logon ID

Note: To find and modify values affecting the profile data sets, see descriptions of the PROF xxxx system parameters in System Parameters.

Queue File Data Set

The Queue File is needed only if the Auto Restore Manager (ARM) is implemented, or the Allocation Option component is used. The Queue File serves as the communication point between CA Vantage SRM and CA Disk, or CA Vantage SRM and CA Allocate. The Receiver Subtask stores all requests to CA Vantage SRM in the Queue File. The Dispatcher Subtask processes all requests for the system on which it is running. Only one Queue File can be in use at one time.

The Queue File is a BDAM data set. BDAM stands for Basic Direct Access Method and uses READ, WRITE, CHECK. The file is created as if sequential but can be accessed sequentially or randomly. Records in the Queue File are 256 bytes in length. The first two records are reserved for a bit map and are used to determine what records are available and which are in use. The size of the bit map controls the size of the Queue File.

The QUEUE parameter of the VKGPARMS member in the PARMLIB data set must contain the data set name of the Queue File, if the default name of %%DSNPFX%%.QUEUE is not used.

Recall/Restore Log VSAM KSDS Maintenance

Note: To find out how to maintain the Recall/Restore Log VSAM KSDS, see RSTLGMNT Utility - Maintain the Recall/Restore Log or Hardware Error Log.

VSAM Idle Space Calculations

Idle space within a VSAM cluster is a complex subject. The most common case is that of allocated but unused Control Areas (CAs) at the end of the data set, that is, at the end of the data component.

VSAM always allocates space on CA boundaries. The total number of bytes within the number of CAs allocated is the high-allocated RBA. When a record is written into a CA for the first time, the entire CA is formatted with binary zeros and the logical records are inserted. VSAM records the last byte within the newly formatted CA as the high used RBA within the data set. The difference in these two values represents the idle bytes at the end of the data set. This applies to unused CAs at the end of the data set. These idle bytes can be divided by the high-allocated RBA to determine the percent idle.

For ESDS data sets, the above calculation accurately estimates the idle space. Missing is the amount of idle space within the last CA that actually contains data. For example, if one 80-byte record is written into a 1-cylinder CA, based on the above calculation the entire cylinder appears used. In reality, that CA is almost idle.

Another type of idle space is dead space within each Control Interval (CI) due to a bad match between the CI size and the actual lengths of the records, for example, a CI size of 2048 used with fixed-length records of 1050 bytes. Because only one record fits per CI, the remainder of the CI is dead or idle space. The above RBA calculation does not account for this type of idle space.

For KSDS data sets, the above considerations apply to the data component. However, there are additional possibilities for idle space:

  • The amount of internally distributed free space within each CI, CA, or both when a cluster is loaded (because of the free space percentage parameters) whether or not this free space has been used by subsequent updates.
  • A KSDS may have unreferencable data CIs within a CA because of insufficient key compression for a given combination of index CI size with its data CA and CI sizes.

The simple calculation of idle space based upon RBA values does not include these more complex cases. Idle space within the index component becomes very complicated because of such issues as imbedded and replicated indexes.

For RRDS data sets, the RBA calculations provide the same degree of accuracy as for ESDS data sets, except that they do not account for free slots that may exist within the RRDS.

For LDS data sets, the RBA calculations provide the idle space at the end of the data set. Whether or not there is more idle space within the used space is unknown. Only the LDS application can make that determination.

The amount of idle space within a VSAM data set as calculated from its high allocated and high used RBA values is always a low estimate.

VSAM - RBA Values Maintained

VSAM maintains all the specifics regarding a VSAM allocation within the VVDSs on the volumes on which the data set resides. For each component, it records the high allocated and high used RBAs within the D-cell of the primary VVR, which is written in the VVDS of the first or only data volume. D-cell RBA values are printed under Allocation information in a LISTCAT.

The primary VVR also has a V-cell for volume information, that is, a HARBA and HURBA for that volume as well as a low and high RBA for each extent. V-cell RBA values are printed under Volume information in a LISTCAT. For a single volume data set, the HARBA and HURBA in the D-cell and the V-cell are the same.

For data components spread across multiple volumes (multivolume data sets), VSAM writes a secondary VVR in the VVDS of the second and third volumes, and so on, whenever data is actually written to the volume. This secondary VVR consists of only the Q-type header cell and the V-cell needed to describe the contents of that volume. In other words, there is an HARBA and HURBA for the volume, and a low and high RBA for each extent on the volume. However, there is no primary VVR with D-cell information on the second or third volumes, and so on. When more space is used at the end of a multivolume data set, the D-cell RBA values on both the first volume (which describe the entire component) and the V-cell RBAs on the last used volume are updated.

VSAM - Key Range Data Sets

VSAM KSDS data sets that specify key ranges create slightly different VTOC and VVDS entries. In the VTOC, a key range qualifier is appended to the dsname of each data extent to receive a specified range of keys, whether on a single or on multiple volumes. For example, if three key ranges are defined for cluster VSAM.KEYED, which specifies VSAM.KEYED.DATA as the data component name:

  • The VTOC will contain the following names:
    • VSAM.KEYED.DATA.A001 for the first key range
    • VSAM.KEYED.DATA.A002 for the second key range
    • VSAM.KEYED.DATA.A003 for the third key range
  • The VVDS will contain:
    • Primary VVR for VSAM.KEYED.DATA
      Z-type header cell containing A001 KRQ (KeyRangeQualifier)
      V-cell containing the high and low key for the A001 extent
    • Secondary VVR for VSAM.KEYED.DATA
      Q-type header cell containing A002 KRQ (KeyRangeQualifier)
      V-cell containing the high and low key for the A002 extent
    • Secondary VVR for VSAM.KEYED.DATA
      Q-type header cell containing A003 KRQ (KeyRangeQualifier)
      V-cell containing the high and low key for the A003 extent

VSAM Idle Space - RBA Values

When the CA Vantage SRM VVDS reader processes a VVDS, it saves the primary and secondary VVR information in a control block called CFMAP (catalog field map).

Every primary VVR consists of the following:

  • Z-type header cell
  • D-cell (data set-info)
  • A-cell (AMDSB info)
  • V-cell (volume info)
  • Optionally, an S-cell/subcell (SMS info)

Every secondary VVR consists of the following:

  • Q-type header cell
  • V-cell (volume info)
  • Component name (with the appended KRQ, if present)
  • KRQ value by itself
  • The HARBA and HURBA for the volume
  • The XSRBA (lowest extents starting RBA value) for the volume

The CFMAP consists of the following:

  • All the Z, D, A, and S fields
  • Some of the V fields
    • All the general descriptor fields
    • The first extent description (out of 123 possible)

To build the DTOC DSAB, the DTOC reader matches the VTOC entry with its CFMAP entry. The HARBA, HURBA, and XSRBA for the volume are retrieved, and are sufficient for computing the idle space on that volume.

For a single volume data set, the XSRBA (starting RBA of the lowest extent) is always zero. Therefore:

PercentIdle = (HARBA - HURBA)x100

                     HARBA

For a multivolume segment, the XSRBA (starting RBA of the lowest extent on that volume) is not zero but the byte number of the next byte after all the bytes contained on the prior volume. On these volumes, the percent idle must be computed as follows (this represents the more general expression of the above):

PercentIdle = (HARBA - HURBA)x100

                  HARBA-XSRBA

VSAM Idle Space - Special Cases

Because of the complexity of determining idle space within index components and components of catalogs themselves, this product uses the D-cell RBA values (those that apply to the component) to arrive at its idle space estimate for a component marked as either an index or part of a catalog.

Because the VVDS entries do not accurately reflect the status of page and swap data sets, the product always indicates them as completely used (zero idle).

VSAM Idle Space - Product Differences

CA Disk reports in which the components parameter is specified show the idle space as zero because they are based solely on VTOC information, not on catalog information. When the components parameter is not specified, the CA Disk reports obtain the information from the catalog and combine the index and data component space on each volume into a single cluster entry, which is the resulting total for the data set.

CA Vantage SRM and CA Disk use the same RBA values, but CA Disk reports calculate percentage used and round it to the nearest percent. CA Vantage SRM calculates percentage idle and rounds it down, so that the number of tracks idle, computed with the percent value, is always smaller than or equal to the exact value, never greater than the exact value produced by the percent value being rounded to the nearest percent.

VSAM RLS Usage in CA Vantage SRM

CA Vantage SRM uses several VSAM data sets which are intended to be shared using RLS processing. Non-RLS processing can be used, but the ability to share access to the data sets is much more restricted (per IBM's definitions). These data sets are the:

  • Restore Log (identified by system parameters RSTLOG and RSTLGLST)
  • Hardware Error Log (identified by system parameter HWMLOG)
  • HACC Volumes Data Set (identified by system parameter HACCDSN)
  • MPM (identified by system parameters MPMDEVDA, MPMDEVDH, MPMDEVDS and MPMVOLDS)

CA Vantage SRM prevents integrity exposure by checking the VSAM specification at open time as follows:

  • If SHAREOPTIONS (1,3), (2,3) or (3,3) and LOG(NONE) and a non-blank SC is specified, CA Vantage SRM opens the VSAM data set in RLS mode. If it fails, the message VAN1531E including the VSAM Open RC and Reason Code is issued.
  • If SHAREOPTIONS (1,3) or (2,3) and LOG different from NONE, CA Vantage SRM opens the VSAM data set in non-RLS mode. If it fails, the message VAN1531E including the VSAM Open RC and Reason Code is issued.
  • If the data set is not defined as indicated in the two cases above, CA Vantage SRM will issue the error message VAN1532E indicating that the data set could not be opened because of inappropriate definitions.

Subsequently, if you get the VAN1531E or VAN1532E error message for Open, you need to redefine or run the appropriate IDCAMS alter commands below to correct the data set definitions. The data set name to alter can be found in the error message itself.

  • If you intend to share the data set between multiple systems, you need to define it as RLS.
  • To define a data set for RLS usage, use SHAREOPTIONS(3 3) LOG(NONE) and STORCLAS(smsrls).
  • To alter a data set for RLS usage, use:

      ALTER   CA.VANT.DATASET LOG(NONE) STORCLAS(smsrls)

      ALTER   CA.VANT.DATASET.DATA  SHAREOPTIONS(3 3)

      ALTER   CA.VANT.DATASET.INDEX SHAREOPTIONS(3 3)

    Where smsrls is an SMS storage class name that supports RLS.

  • To define a data set for non-RLS usage, use SHAREOPTIONS (2 3) and no LOG parameter specified.
  • To alter a data set for non-RLS usage, use:

      ALTER   CA.VANT.DATASET.DATA  SHAREOPTIONS(2 3)

      ALTER   CA.VANT.DATASET.INDEX SHAREOPTIONS(2 3)

    Notice that the LOG cannot be NONE for a non-RLS data set used by CA Vantage SRM, and you cannot alter the LOG to "null", so if the original LOG value is NONE, you can alter the LOG value to (UNDO) as follows:

      ALTER   CA.VANT.DATASET LOG(UNDO)

      ALTER   CA.VANT.DATASET.DATA  SHAREOPTIONS(2 3)

      ALTER   CA.VANT.DATASET.INDEX SHAREOPTIONS(2 3)

  • To find the log value, use TSO command:

      listc entry('CA.VANT.DATASET') all

Was this helpful?

Please log in to post comments.