RLS enhancements - VSAM

What follows is a list of RLS enhancements. The majority of them are introduced in z/OS DFSMS 1.3.

RLS/KSDS extended addressability
When VSAM RLS support was announced with DFSMS/MVS V1R3, it did not support VSAM KSDS extended addressability (EA) format. In other words VSAM RLS component retained the 4 GB architectural limit for the component size imposed by using the 4-byte field for the relative byte address (RBA) addressing mechanism. DFSMS/MVS V1R4 removed this restriction by supporting RLS EA for VSAM KSDSs, and therefore VSAM RLS now supports VSAM KSDSs up to the current multivolume limit of 59 DASD volumes.

As in VSAM non-RLS extended addressability, a VSAM RLS extended addressability KSDS must have its data class defined with:
Data Set Name Type =EXT
If Ext =P or R
Extended Addressability =Y

VSAM RLS CF structure duplexing and rebuild
VSAM RLS goes to lost locks state when the CF lock structure is lost and a system is also lost — a disruptive condition.

This process consists of the lock structure rebuild with all of the active VSAM RLS instances with the steps of allocating a new structure instance, propagating the lock data to the new structure, and switching over to using the new structure instance.

Currently, z/OS supports four types of lock structure rebuild processes. They are

  • User-managed rebuild
  • User-managed duplexing rebuild
  • System-managed rebuild
  • System-managed duplexing rebuild

User-managed rebuild
This enhancement to the current user-managed rebuild process will minimize the possibility of running out of record table space. Prior to this enhancement, if record space is exhausted, either an 0F4 abend or a record management error will occur. This enhancement adds a new validation check function during the user-managed rebuild process for the lock structure. When rebuild tries to change a lock structure and the size of the record table is greater than 50%, this new function will determine if the new table has enough space for all existing record table entries, plus enough empty space for future locking processes (120%). If the answer is no, then the rebuild request is rejected and a new IGW457I message will be displayed.

System-managed duplexing rebuild
This support is available from z/OS V1R4 DFSMS. The VSAM RLS duplexing support only applies to the lock structure and not the cache structures.

What is it?
This facility is a hardware-assisted mechanism for VSAM RLS duplexing CF lock structure data, and provides a robust recovery mechanism for failure scenarios such as a loss of a CF, or loss of connectivity to a single CF.

  • Provides quick recovery from RLS lock structure failure
  • Reduces lost lock conditions
  • Minimizes running out of record table space
  • Eliminates 0F4 abends

How to set it up?
To use the new VSAM RLS system-managed duplexing function the following tasks are required:
Review CF configuration
Evaluate the CF configuration (storage, links, processor capacity) and make any necessary configuration changes to accommodate the new VSAM RLS lock structure instances resulting from system-managed duplexing.

Migrate to z/OS V1 R4 or later
All systems in the sysplex that use this function will need to be upgraded to this level that supports System-managed duplexing.

Install hardware CFCC level 12 or later
CF Duplexing requires CFCC Level 12 for implementation on IBM ~ zSeries servers. For G5/G6 Servers and the stand alone CF 9672-R06, CF Duplexing function requires CFCC Level 11.

Format the CFRM couple data set
Format this as system-managed, duplexing-capable, and bring that CFRM couple data set into use in the sysplex, to enable CFRM for system-managed duplexing.

Modify the CFRM policy
Modify this to control the sizing, placement (through the CF preference list) and the DUPLEX parameter indication for the VSAM RLS lock structure, which is duplexed via system-managed duplexing, and activating this CFRM policy.

RLS CF caching enhancements
This support is available in z/OS V1 R3.

What is it?
There are two RLS caching enhancements, respectively:

  • Dynamic cache reassignment
  • For the CF structure rebuild process to work, extra space in a CF must be reserved, if not it fails. Then all I/O requests for those VSAM spheres fail.
  • DFSMS dynamic cache reassignment allows the customer to better utilize the CF resources.
  • If the rebuild fails, SMSVSAM Dynamic cache reassignment code examines each VSAM sphere that is assigned to the failing cache. Those spheres that are assigned to a storage class that point to 'cache set' where there are more than one cache structure names are reassigned. The same algorithm used in the original allocation of the sphere is used. For the VSAM sphere that were able to be reassigned, all requests continue to work. For the VSAM spheres in which the reassignment failed, those requests are failed with a reason code “cache not available”.
  • Data CIs larger than 4KB in cache structure. The initial version of SMSVSAM support did not cache RLS data CI that was greater than 4 KB, for performance reasons. However, since 9672 G4 machines, due to the faster CF links and CF CPU, there are performance gains in keeping larger than 4 KB data CIs in the CF cache structure. With this support you can cache all, some, or none of the VSAM RLS data in the CF cache structures defined to SMSVSAM — through the RLSCFCACHE keyword. The VSAM index< structure is ALWAYS cached. The directory entry for a CF data entry also is always cached, regardless of what option is specified.

How to set it up?
Here are the steps to take.

Migrate to z/OS V1 R3 or later
You must be at this level or higher.

Update SYS1.PARMLIB member IGDSMSxx
There are two new keywords in IGDSMSxx. They are:

  • RLS_DynamicCfCacheReassign(YES|NO).
    This keyword controls, at the sysplex level, whether RLS dynamic cache reassignment is active or not.
    This specifies the method that VSAM RLS should use to determine the size of the data that is placed in the CF cache structure. You can use the RLS_MAXCFFEATURELEVEL keyword to limit the connect level when the sysplex has a mixed level of releases and maintenance. If you do not specify a value, or if you specify Z, then only VSAM RLS data that has a Control Interval (CI) value of 4K or less is placed in the CF cache structure. If you specify A, caching proceeds using the RLSCFCACHE keyword characteristics that are specified in the SMS data class that is defined for the VSAM sphere.

    RLS_MAXCFFEATURELEVEL is a sysplex wide value. The first system activated in the sysplex will set the value; all other systems will use the value set by the first system. Default: Z.

    – RLS_MaxCfFeatureLevel(A) indicates that VSAM RLS caching uses the characteristics specified in the SMS DATACLASS defined for the VSAM sphere.
    – RLS_MaxCfFeatueLevel(B) indicates that DynamicCfCacheReassignment is installed. This feature is active if the RLS_DynamicCfCacheReassign(YES) is specified in the active SMS parmlib member.
    – RLS_MaxCfFeatureLevel(AB) indicates that both features may be activated.

    Update data class
    The new caching characteristics are defined in the DATACLASS SMS construct. A new field is added to the ISMF DATACLASS construct called RLSCFCACHE.

    The values are NONE, UPDATESONLY, and ALL(default).

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

VSAM Topics