Symptoms
Timeout events such as Abend522
or application specific errors.
How to investigate
- Issue the command F CATALOG,LIST wait 30 seconds to a minute and
reissue the command. The list of active tasks should have changed.
Any tasks waiting over 5 seconds should be investigated. The output
from the command will give the requesting address space name, type
of request, how long the request has been waiting and in some cases
the reason the request is waiting.
- Issue D GRS,C to identify any contention on a particular catalog
(SYSIGGV2) or volume (SYSZVVDS)
- Issue F CATALOG,TAKEDUMP during time of slow performance to obtain
a dump in case support must be engaged
Recovery actions
- Cancel non-critical jobs that are involved in the contention
- F CATALOG,RESTART. This will be followed by an IEC363D if the
F CATALOG,TAKEDUMP was not used to obtain a dump prior, answer ‘y’
to IEC363D and ‘n’ to the following IEC364D query to obtain a dump.
Otherwise, reply ‘n’ to IEC363D to proceed with the restart. For
more information, see "Restarting the Catalog Address Space" in DFSMS Managing Catalogs.
Actions to avoid recurrence
- Review "Diagnosing a Catalog Performance Problem" in DFSMS
Managing Catalogs for possible solutions and best practices
- Investigate any jobs or users that may be issuing generic requests
such as locates for *. These processes may hold a shared SYSIGGV2
ENQ for a longer time than typical locate requests.
- If performance is concerning a particular catalog, research whether
certain aliases directed to that catalog can be split off into a separate
catalog as this may reduce contention during peak periods
- If performance is concerning a particular volume, research whether
there are other volume processing is occurring at that time such as
defragmentation jobs or back-up processing.