Prevention is better than cure - VSAM

Prevention is better than cure
You can take a number of actions to prevent VSAM problems. Here we provide some recommendations.

Back up your VSAM data sets

  • Back up all your critical data by using methods such as:
    SMS management class with ABARS for backups, to allow restore of your data in the case of a hardware error and/or application error, and for use in disaster recovery.
    Remote copy for disaster recovery.

Here, we discuss some backup issues you need to consider

IDCAMS export and import
First, we explain some of the unique characteristics of the EXPORT and IMPORT commands:

  • The EXPORT command either exports a cluster or an alternate index or creates a backup copy of an integrated catalog facility catalog.
  • Exporting means to store the cluster or AIX data in other media in a non-processable format, together with catalog information about the data set. An empty candidate volume cannot be exported. Access Method Services acknowledge and preserve the SMS classes during EXPORT.

    This is an example in which a key-sequenced cluster, ZZZ.EXAMPLE.KSDS1, is exported from a user catalog, HHHUCAT1. The cluster is copied to a portable file, TAPE2, and its catalog entries are modified to prevent the cluster's data records from being updated, added to, or erased.

    Exporting KSDS

    Exporting KSDS

  • IMPORT is the opposite operation to EXPORT. Here, you reload the cluster or AIX data and recatalog its catalog information in an active catalog.
  • This is an example in which a key-sequenced cluster, BCN.EXAMPLE.KSDS1, that was previously EXPORTed, is IMPORTed. The OUTFILE and its associated DD statement are provided to allocate the data set. The original copy of BCN.EXAMPLE.KSDS1 is replaced with the imported copy, TAPE2. Access Method Services finds and deletes the duplicate name, BCN.EXAMPLE. KSDS1, in the catalog VCBUCAT1.

    A duplicate name exists because TEMPORARY was specified when the cluster was exported. Access Method Services then redefines BCN.EXAMPLE.KSDS1, using the catalog information from the portable file TAPE2.

IMPORT of KSDS cluster

IMPORT of KSDS cluster

Backup while open considerations
Backup-while-open (BWO) allows DFSMSdss logical dump for an IMS or a CICS/VSAM data set while open-for-update. BWO works with Concurrent Copy (in 9390), or Snapshot (in RVAs), or Flashcopy (in ESS). The VSAM data set must be SMS managed.

The DFSMSdss BWO function does not apply to: Catalogs, VVDSs, LDSs, physical dump, and restore.

When you define the cluster with IDCAMS, you must declare it as a BWO. The options are:
_ TYPECICS
Use the TYPECICS parameter to specify BWO in a CICS environment. For RLS processing, this activates BWO processing for CICS. For non-RLS processing, CICS determines whether to use this specification or the specification in the CICS control data named FCT.

_ TYPEIMS
If you want to use BWO processing in an IMS environment, use the TYPEIMS parameter.

_ NO
Use this parameter when BWO does not apply to the cluster.

To have BWO with total security and integrity, the following products are modified:

  • DFSMSdfp, where catalog services have been changed to prevent unauthorized alterations of BWO indicators. DFSMSdfp does not allow deletion of a data set that DFSMSdss dumps as a BWO data set.
  • DFSMSdss enqueue serialization has been changed to prevent data integrity exposures when performing defrag, dump, or restore operations.
  • DFSMShsm, used for incremental backups and aggregate backups of a data set, invokes DFSMSdss to perform BWO.

In the catalog the following fields are referring to BWO:

  • BWO: Data set is enabled for backup-while-open.
  • BWO STATUS: Indicates the status of the data set. Status can be:
    Data set is enabled for backup-while-open.
    Control interval or control area split is in progress.
    Data set has been restored and is down level. It might need to be updated with forward recovery logs.
  • BWO TIMESTAMP: A CICS timestamp that indicates the time from whichforward recovery logs have to be applied to a restored copy of the data set.

Space constraint relief
Before we start explaining more complicated recovery situations, let us address a common abend situation prior to DFSMS/MVS 1.4.

Users occasionally encounter data set allocation or extension failures (the X37 type of abends), because there is not enough space available on a volume to satisfy the request. Incidentally, VSAM does not externalize an X37 abend. You recognize the out-of-space condition by the message IEC070I 203-204, where 203 is the reason code. You find the explanation in the message IEC161I, return code 203, when no secondary space allocation quantity was specified. Return code 204 is issued when a new extend was attempted, but the maximum number of extents was reached.

SMS alleviates this out-of-space situation to some extent by performing volume selection, checking all candidate volumes before failing an allocation.

With DFSMS/MVS 1.4, you can also use the Space Constraint Relief and Reduce Space Up To (%) attributes in the data class to request that an allocation be retried if it fails due to space constraints. SMS retries the allocation by combining any of the following:

  • Spreading the requested quantity over multiple volumes
  • Allocating a percentage of the requested quantity
  • Using more than 5 extents

Space Constraint Relief specifies whether or not to retry an allocation that was unsuccessful due to space constraints on the volume. Note that allocation is attempted on all candidate volumes before it is retried. This attribute applies only to system-managed data sets, and is limited to new data set allocations, and while extending the data set on new volumes.

Out-of-space conditions are now further reduced for new volume processing of SMS-managed data sets. VSAM and non-VSAM data sets can now acquire up to 123 extents instead of just 5 extents on a volume. Multivolume VSAM data sets can now have a maximum of 255 extents across volumes for each component, but no more than 123 extents per volume.

Two new parameters, Space Constraint Relief and Reduce Space Up To (%), are added to the SMS data class definition for this support.

Reduce Space Up to (%) specifies the amount by which you want to reduce the requested space quantity when the allocation is retried. You must specify Y for the Space Constraint Relief attribute. Valid values are 0 to 99.

If you specify Y for Space Constraint Relief, SMS begins the retry process. This is a one or two-step process, depending on the volume count you specified. For JCL allocations, SMS determines the volume count by taking the maximum of the unit, volume, or volser count. If these are not specified, SMS picks up a volume count from the data class. If there is no data class, SMS defaults the volume count to one:

_ If the volume count is one (one-step process):
SMS retries the allocation after reducing the requested space quantity based on the Reduce Space Up To attribute. SMS simultaneously removes the 5-extent limit, so that SMS can use as many extents as the data set type allows

_ If the volume count is greater than one (two-step process):
First, SMS uses a best-fit volume selection method to spread the primary quantity over more than one volume (up to the volume count). If this fails, SMS continues with the best fit method after reducing the primary quantity and removing the 5-extent limit.

If you request Space Constraint Relief but do not specify a percentage value (either 0 or blank), SMS does not reduce the requested space quantity. This implies your application cannot tolerate a reduction in the space to be allocated, so you want to remove the 5-extent limit, thereby allowing SMS to use more than 5 extents.

For extends to new volumes, Space Constraint Relief is strictly a one-step process. If regular volume selection has failed to allocate space, SMS reduces space or removes the 5-extent limit, but does not try the best-fit method.

The number of extents vary depending on data set type, as follows:

  • Non-VSAM, non-extended format data sets, up to 16 extents on the volume
  • Non-VSAM, extended format data sets, up to 123 extents
  • PDSE, up to 123 extents on the volume
  • VSAM data sets, up to 255 extents per component but only up to 123 extents per volume per component

When you request Space Constraint Relief in one or more data classes, you might notice any of the following:

  • Very large allocations might succeed if a sufficiently large volume count is specified in the data class or through JCL.
  • Existing data sets might end up with less space than initially requested on extents.
  • The space allocated for new data sets might be less than requested.
  • The number of extents used during initial allocation might result in fewer extents being subsequently available. For example, if the primary space allocation uses 10 extents when allocating a physical sequential data set, then only 6 extents are left for allocation of the secondary quantity.
  • You might observe fewer X37 abends.

Keep your system at current maintenance levels
Keep your system at a current maintenance level. Apply PTF selective service in your operating system, especially the ones associated with VSAM. To find fixes associated with broken VSAM data sets, use the search word 'dsbreaker' in either retain or through ibmlink (askq).

Use Resource Recovery Management Services (RRMS)
RRMS is an z/OS component that allows you to coordinate resource recovery.


All rights reserved © 2018 Wisdom IT Services India Pvt. Ltd DMCA.com Protection Status

VSAM Topics