In order to report a catalog performance problem when running DFSMS with z/OS® V1R7 or higher, you must do the following:

1. Collect the following information:
   1. What information indicated an increase in CPU usage?
   2. Was this increase noticeable immediately after upgrading to a new release of z/OS?
   3. What release level was used as base for comparison?
   4. What are the PUT/RSU levels of the base used for comparison?
   5. Were any changes made in the catalog environment, such as:
      • Any new shared catalogs, or old catalogs that are now shared?
      • VLF or ISC changed catalogs?

        Note that SMF record type 41, subtype 3 gives details on VLF hit ratios and trimming for each VLF class. Based on this information, you may want to increase the MAXVIRT value in the COFVLFxx parmlib member for the IGGCAS VLF CLASS. Refer to VLF documentation in z/OS MVS Programming: Authorized Assembler Services Guide and z/OS MVS Initialization and Tuning Reference.

      • STRNO changes to catalogs?
      • CATMAX or TASKMAX changes?
      • Any other relevant changes to the system environment?
   6. Have there been any increases in workload on the system, such as new applications, the addition of more TSO users, or increased batch workloads?
   7. Have you noticed any increases in CPU consumption for other system address spaces, such as GRS, SMS, MASTER, or JES?
   8. Are there specific time frames of increased Catalog CPU usage?
   9. Are there specific jobs or users affected by the problem?
   10. What type of serialization product are you using. For example, is GRS your serialization product?
   11. Is the problem affecting overall system performance?
   12. Do you have any DASD UCBs specified as LOCANY=YES in HCD? If so, when were the UCBs put above the line?
   If the answers to these questions point to an overall increase in CAS CPU consumption (as opposed to specific users or jobs) then proceed to step 3. Otherwise, refer to Possible causes and solutions for catalog performance problems.
2. Collect comparison data of CAS CPU consumption between the base (previous) release and new DFSMS release. This information should represent total weekly or monthly CPU consumption for CAS broken down by TCB and SRB. If you are using RMF™, this is easiest if the Catalog address space is in a report performance group. You can use OEM applications that provide similar information so that a comparison can be made between the previous release and the current release.
3. Collect comparison data of CAS storage size between the base or previous release and new release of DFSMS.
4. Collect comparison data of CAS I/O rates between the base or previous release and new release of DFSMS.
5. If OMEGAMON® is available, then do an INSPECT of CAS drilling down on a few of the active TCBs to a CSECT level and the offsets within those CSECTs that are consuming CPU. Other OEM applications provide a similar capability. The important point is to get to the CSECT level of load modules. For example, you might find CSECT IGG0CLF5 in load module IGG0CLX0.