Evaluating Catalog Data Space Cache Performance

In order to evaluate the catalog data space cache, use the MODIFY CATALOG,REPORT,CACHE command. You can use the command to evaluate the cache performance for a specified catalog, or for all catalogs that are currently being cached. The numbers shown in this report are in decimal. If a 'K' appears after the number, it means that the number has been divided by 1024. Following is an example of the output for a catalog cache statistic report:

IEC359I CATALOG CACHE REPORT
*CAS******************************************************************
*   HIT% -RECORDS- -SEARCHES --FOUND-- -DELETES- -SHR UPD- --PURGE-- *
*                                                                    *
* SYS1.MVSRES.MASTCAT                            (ISC)               *
*    42%    1,578       679       291        13         0         3  *
* SYS1.PROD.UCAT                                 (VLF)               *
*    37%    2,304     1,014       372        27        42         0  *
*                                                                    *
*CAS******************************************************************

The report on SYS1.MVSRES.MASTCAT, currently using ISC caching, shows that 42% of the records requested from this catalog were already in storage. Therefore, no I/O operation was necessary. SYS1.PROD.UCAT is currently being cached through the VLF function, and shows similar statistics. Twenty percent is the break-even point for catalog caching. If the hit percentage is lower than 20, then the processor storage and cycles needed to maintain the data space are not worth the I/O operations saved. This figure is a rough estimate. If central processing unit (CPU) utilization and processor storage are not limiting factors, a lower hit ratio is tolerated.

When you evaluate the cache performance for a catalog, you need to consider how long the catalog has been using the cache. If the cache has only been available for a catalog for an hour, the hit ratio will likely be low. However, if the catalog has been using the cache for a week, expect a good hit ratio. The hit ratio is an indication of cache usage while the cache is available. The values do not accumulate between performing IPLs, stopping and starting VLF, or restarting the catalog address space.

To obtain a good comparative analysis of how different catalogs are using the cache, produce periodic reports during an active session (between IPLs). This shows you which catalogs are getting good hit ratios quickly, and those which are either reaching the break-even point slowly or not at all. If you want to reset the statistics for a catalog, you can use the MODIFY CATALOG,CLOSE command to close that catalog. When it is next referenced, a new cache structure will be built.

Note: The MODIFY CATALOG,CLOSE command does not clear the PURGE statistic.

To calculate the hit ratio, divide the number of hits by the number of searches of the data space. The Catalog Cache Report example also lists the number of catalog records in the cache and the number of deleted or updated records in the cache. Note that for catalogs using VLF, the count of records in the cache might not be accurate due to VLF trimming. The number that is shown represents the number of records that the catalog has added to VLF, not the number that might actually be in the VLF cache.

Hit ratio results are relative to a particular installation, workload, or reference pattern. It is possible (but not guaranteed) to increase hit ratios by dedicating more storage space to a VLF-managed catalog. For more information on how to dedicate more storage space to a VLF-managed catalog, refer to z/OS MVS Initialization and Tuning Reference.

The master catalog will always be searched for data set names that do not have an alias to a user catalog. For example, non-existent data set names and SMS-managed temporary data sets are not cataloged so all searches for them would show up as a "miss" of the master catalog cache. This may cause the hit ratio for the master catalog cache to appear lower than expected.

The PURGE count displays the number of times a particular catalog cache has been purged and is reset at an IPL (Initial Program Load). Catalog purges commonly occur for two reasons:

ISC-cached catalog purges occur when a change is made from an external system and is recognized by the current system.
The number of changes within a system exceeds the maximum that can be recorded between two catalog access events. The specific number of changes that can be recorded is an internal value and varies based on several conditions, all of which are outside of the user's control.

Catalog management allows for record level granularity updates to the VLF cache in a cross system sharing environment. Record updates for a catalog using ISC caching cause the entire ISC cache to be purged when a change is made from another system. Nonzero values under the PURGE column for a catalog using ISC caching indicate this is happening for that catalog. Deletes or updates to a shared catalog on one system cause a corresponding deletion of records in the VLF cache on the other systems. Catalog management accomplishes this by using a list of entries in the catalog that describes VVR.

Records might not be found in the cache of the corresponding system because they were never accessed on that system. The cache is a caching system where records are not added to the cache until they are accessed. The catalog caching report shows a value for sharing (SHR UPD). This sharing number reflects how many records that were found and deleted from the VLF cache because they were updated or deleted on a shared system. The deleted number given in the catalog data space report reflects:

The total count of records updated or deleted on the current system AND
Those records updated or deleted on the shared system that are found in the current system's cache.

If more updates or deletions occur in a given time than can be processed by the sharing system, the entire VLF cache on the sharing system is invalidated. This is shown in the MODIFY CATALOG,REPORT,CACHE output under the heading PURGE. This number should always be small, otherwise this indicates that more updates are occurring than can be processed by the sharing system. If the purged number grows dramatically over a short period of time, the catalog is probably not a good candidate for caching.

The numbers shown for record counts, records, searches, hits, deletes, and sharing might not have a one-to-one correlation to the catalog functions being performed. This is because catalog management maintains other records, such as truename records, that can be cached and will add to the statistics.

If a catalog is not using the catalog data space cache to your satisfaction, you can temporarily make it ineligible for CDSC by using MODIFY CATALOG,NOVLF. Alternatively, after closing or deallocating the catalog, you can use the ALLOCATE,NOVLF subparameter to allocate the catalog to CAS without the use of VLF.

To make the catalog permanently ineligible for future data space cache use, modify the COFVLFxx member of SYS1.PARMLIB, and stop and restart VLF.