Caching of history file $$INDEX data

The default value for the PARM parameter in the Fault Analyzer IDIS subsystem startup JCL is UPDINDEX (see Starting the IDIS subsystem). When the default value is used, the IDIS subsystem manages the $$INDEX member access of all PDSE history files:

  • That are used on the MVS image where the IDIS subsystem is running.
  • To which the IDIS subsystem has UPDATE access.

For details about the $$INDEX member, see Special members in the history file data set. PDS-format history files are not managed in the IDIS subsystem because their enqueue and parallel update limitations prevent any effective caching of their $$INDEX members.

After the $$INDEX member from a history file is read, the information is kept in the IDIS subsystem address space during periods of high activity. This approach provides fast access for any requesters of this data, since no I/O is required. Real-time analysis, interactive and batch reanalysis, and the Fault Analyzer ISPF interface, use the cached IDIS subsystem data.

Each time the cache is accessed for read or write, the time limit for in-storage retention is reset. The reset ensures that a history file that is highly active continues to provide fast cache access. This approach is beneficial to environments, such as CICS®, where multiple abends might occur in rapid succession, and often all need to update the same history file.

The time limit for the IDIS subsystem in-storage retention is set to 5 minutes. The $$INDEX member is written back to the history file and the IDIS subsystem relinquishes control of it when:

  • The time limit expires.
  • A request for update of the same history file is pending from another MVS image in the same sysplex.
Tip: Make the setting of the IDIS subsystem option PARM='UPDINDEX' or PARM='NOUPDINDEX' the same for all IDIS subsystems in the sysplex. For details about sysplex sharing of history files, see Sharing of history files across a sysplex.

The UPDINDEX option can be used to ensure that certain low-priority jobs do not cause excessive delays in the Fault Analyzer execution due to serialization of the history file $$INDEX member. These jobs are the jobs that share history files with performance sensitive jobs or execution environments, such as IMS and CICS®, in a CPU constrained environment.

If you use the UPDINDEX option, ensure that the IDIS subsystem has UPDATE access through normal security server data set profiles to all history files that it is expected to handle. XFACILIT access is not sufficient.

If the IDIS subsystem is called for a history file to which it does not have UPDATE access, or if it fails to update a history file for any other reason, then no further attempt is made to manage the $$INDEX member of that history file until one of the following steps is performed:
Note: For maximum Fault Analyzer performance, consider the DeferredReport option. For details, see DeferredReport.