Detecting Obsolete Catalog Attributes with IBM Health Checker for z/OS

You can use the CATALOG_IMBED_REPLICATE check running in the IBM® Health Checker for z/OS® framework to detect instances of the obsolete IMBED and REPLICATE attributes for user and master catalogs. No supported releases of z/OS honor either the IMBED or REPLICATE attributes for new catalogs, they are obsoleted by newer, cached DASD devices. These attributes were obsoleted because they waste DASD space and degrade performance, in some cases causing unplanned outages. In addition, servicing catalogs with these attributes is very difficult.

If the check finds instances of IMBED or REPLICATE attributes, the system issues exception message IGGHC104E and generates a report in message IGGHC106I in the message buffer to describe the check’s findings. IBM suggests that you use the EXPORT/IMPORT command to remove the attributes:

Use the EXPORT command to create a back up and later to recover.
Use the IMPORT command for the exported copies.

Ideally, you should do this during system down time, when the catalogs cannot be accessed by any users.

This check is shipped as active and, by default, runs once a day. However, once you have identified all the catalogs you need to redefine without IMBED and REPLICATE attributes, IBM suggests that you turn the check off as soon as possible. This is recommended because:

Users can no longer define catalogs with the obsolete IMBED or REPLICATE attributes. That means that once you have identified any existing catalogs that were defined with IMBED and REPLICATE and redefined them, it is no longer useful to run this check.
Leaving the check on after you have identified and/or redefined any catalogs defined with IMBED or REPLICATE attributes, the check can cause a performance issue. the check does a sequential search of the active Master Catalog, which means it reads all the records in the master catalog. This I/O to the master catalog to read all the records can impact performance.

You can turn the check off temporarily using F HZSPROC command or permanently using the HZSPRMxx parmlib member.

Note that catalog requests that result in sequential processing of a master catalog will not add or update records in VLF. Catalog requests that kick off direct processing of a master catalog however, will add or update records in VLF.

Related information:

To see a full description of the check, see CATALOG_IMBED_REPLICATE in IBM Health Checker for z/OS User's Guide.
To set up and start using IBM Health Checker for z/OS, see Setting up IBM Health Checker for z/OS in IBM Health Checker for z/OS User's Guide.
Once the IBM Health Checker for z/OS is up and running, an exit routine automatically adds the check to the system and the check will run once every 24 hours or at another interval you specify.
To modify check attributes, such as the interval or severity for the check, do one of the following:
- Make temporary, dynamic changes using either SDSF or the F hzsproc,UPDATE command.
- Make permanent changes for the check in an HZSPRMxx parmlib member.
See Managing checks in IBM Health Checker for z/OS User's Guide.
To use the EXPORT and IMPORT commands, see z/OS DFSMS Access Method Services Commands for information on the EXPORT and IMPORT commands.