Spotlight: Catalog Basics – Understanding CAS Caching

By Tony Brown


Understanding, Implementing, and Assessing Cache Options for the Catalog Address Space

The Catalog Address Space (CAS) provides a centralized facility for the coordination of catalog service requests on a single system image.  As part of this process, CAS also provides coordination of updates for shared Basic Catalog Structures (BCS) for multiple system images in a SYSPLEX.  The Catalog Address Space is started during system initialization.  Successful initialization of CAS is necessary for the continuation of the IPL process.  To facilitate start-up of other systems, successful entry look-up relies on proper Catalog Address Space operation.

During startup of the Catalog Address Space, internal tables are created based on the contents of the master catalog.  Tables for user catalogs, their location, and related aliases provide improved performance when resolving data set name alias-match look-up.  To ensure the integrity of entry look-up, master catalog updates are immediately updated in the CAS tables.

 

Factors affecting CAS Performance

The Catalog Address Space, developed in the late 1980’s, solves a number of issues that confronted IBM regarding the integrity and availability of system catalogs.  In addition to centralizing catalog access functions, CAS also provides virtual storage constraint relief, the ability to monitor ICF activity, and strategic functions to improve entry processing for both look-up and update.  Catalog recoverability is the highest priority when considering changes for your ICF environment, but performance can be enhanced without compromising recoverability and reliability.  There are three primary considerations that affect the performance of the Integrated Catalog Facility (ICF) in the Catalog Address Space:

This paper will explore CAS cache options and provide information to assist with evaluating cache effectiveness and identify potential actions available to improve the benefits of cache functionality.

 

Considerations for Caching the Master Catalog

It is important to note the unique processing requirements for the master catalog.  As the master catalog is seldom updated and used frequently for lookup and identification of related user catalogs, usage concerns differ from those for user catalogs.  As recommended by IBM, the master catalog should contain only those entries for user catalogs, user catalog aliases, and system data sets.  As the contents of those types of entries are not likely to be updated regularly, entry look-up becomes the primary request type for master catalogs.

During system initialization, entries for system data sets are retrieved from the master catalog and stored in the selected cache for the master catalog.  User catalog aliases are also retrieved during initialization and stored in dedicated alias tables that are not included as part of the master catalog cache.

 

Understanding Cache Options

The objective of the CAS caching facilities is to minimize the amount of I/O activity required to satisfy catalog service requests.  I/O’s are expensive when compared to the access of data already found in memory, so a proper caching strategy can eliminate a significant percentage of I/O activity.  The configuration of the ICF environment provides flexibility, so IBM offers caching options to accommodate the varied nature of catalog implementation.

One can spend many cycles trying to optimize I/O, but I/O elimination is the most effective cure for improving performance.

This “white paper” addresses the cache options managed by the Catalog Address Space; catalogs operating under Record Level Sharing (RLS) are not cached by CAS.

 

In-Storage Catalog (ISC)

The in-storage catalog cache is maintained within Catalog Address Space main storage.  ISC is the default cache strategy and will be used automatically once CAS opens a BCS, unless instructed otherwise.  In-storage catalog cache processing provides a fixed amount of storage to each catalog as it is opened.  When the space allocated to a single BCS is exhausted, the “least recently used” record is removed to accommodate new record requirements.

Be aware that ISC has some limitations that tend to dilute its effectiveness based on catalog configuration and the type of activity for a specific catalog.  Because ISC uses fixed amounts of storage to cache records for each BCS, catalogs with higher levels of activity receive no preferential treatment.  ISC is at its best when the primary activity is for look-up; when updates from sharing systems are detected, the entire ISC cache for the target BCS is invalidated.  Invalidation of a catalog’s cache in and of itself is not costly, but the “hit ratio” will suffer as new records must be read into cache for ongoing requests.

When performing planned maintenance for one or more catalogs, it’s beneficial to remove a catalog from ISC cache to eliminate the impact of cache invalidation.  This can be accomplished by issuing the MODIFY CATALOG,NOISC(bcs.name) console command on all sharing systems.  Once maintenance efforts are completed, you can return a catalog to ISC cache by issuing the MODIFY CATALOG,ISC(bcs.name) command.

If you are unsure if catalogs are currently cached using ISC, the MODIFY CATALOG,ALLOCATED or MODIFY CATALOG,ALLOCATED(catvol) commands will display BCS status information under the FLAGS heading.

It is also important to note that master catalogs are not subject to limitations on the amount of storage they occupy when cached using ISC.  All eligible records are cached in ISC as they are read from the master catalog.

 

Catalog Data Space Cache (CDSC) Managed by the Virtual Lookaside Facility (VLF)

The Catalog Data Space Cache is created and managed by the z/OS Virtual Lookaside Facility (VLF).  Unlike ISC, using CDSC requires some additional steps to implement data space creation.  PARMLIB member COFVLFxx must be updated to include DATA CLASS(IGGCAS) and identify the catalogs eligible for CDSC caching.  Optionally, the MAXVIRT parameter in COFVLFxx allows you to update the maximum amount of virtual storage VLF should use for the IGGCAS Class.

The CDSC operates on a more granular level when managing updates from sharing systems.  As noted previously, the ISC caching strategy invalidates its entire cache for a catalog when the catalog is updated from a sharing system, even if the updated record is not resident in the ISC cache.  The CDSC caching strategy provides the ability to identify records that are updated by sharing systems.  Records cached in the CDSC cache are removed from CDSC when updated by a sharing system on a “record by record” basis.  Although the CDSC caching strategy is more sophisticated in its recognition of specific record updates, it is still possible that the entire CDSC cache for a catalog might be reset to “empty” when the number of updates is too pervasive to track and process.

 

Shared Catalogs and Catalog Address Space Cache

Before discussing cache processing for shared catalogs, let’s review the requirements for properly sharing catalog access from multiple z/OS systems.  Any catalog residing on a shared device can be “connected” to another system’s master catalog.  To ensure that catalogs residing on shared devices are protected by sharing protocols, ensure that the catalog’s attributes indicate SHAREOPTIONS(3,4).  If a catalog on a shared device has attributes of SHAREOPTIONS(3,3), the Catalog Address Space on each sharing system is unaware that it should process the catalog as shared; control intervals could unintentionally be overwritten and the index component may become out-of-sync with its corresponding data component.  As a general rule, never define a BCS to a shared DASD volume without ensuring that the SHAREOPTIONS are specified as (3,4).

Defining a BCS with SHAREOPTIONS(3,4) causes the creation of a sharing sub-cell that becomes a part of the BCS data component VVR.  This structure is necessary for the proper recognition and tracking of updates to the catalog across systems.  The sharing sub-cell allows CDSC to track individual record updates.  If activity on SYSB results in the removal or update of a BCS data set entry in a specific catalog cached in the catalog data space cache on SYSA, the record or records representing the data set entry will simply be removed from the CDSC for SYSA.  Other records cached in the CDSC for SYSA will remain unaffected.

Although a catalog cannot be cached by both CDSC and ISC concurrently on the same system, Catalog Address Space cache is system-centric.  There are no requirements to cache a specific catalog using the same type of cache on multiple systems that share access to the catalog.

 

Continue reading… 

 

 

 

 

 

 


Tony Brown has worked in the MVS and z/OS industry for over 30 years and has extensive expertise with ICF catalogs and VSAM.  He has been involved with the development of many storage management products, including nearly 14 years serving as one of the developers of T-REX.  Tony is currently a Software Developer 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.