A DB2 subsystem went into a suspended state and didn't process any work resulting in active work being delayed with no new work intake. During that suspension period of 1+ hour , IDB2's application exception enabled for long running DDF/CICS threads successfully tripped as defined. However, the External IQL exception request defined to identify a Long running DDF/CICS thread didn't trip a single time for the entire suspension window. Why did the exceptions behave differently?
Release : 20.0
Component : SYSVIEW Performance Management Option for DB2 for z/OS
The Exception processor and the IQL processor are separate components of Sysview for Db2 (IDB2), and work differently.
While the Exception System monitors DB2 directly by scanning the DB2 address spaces, the IQL processor
collects data given to us by DB2. If DB2 were somehow not functioning normally IQL processing would be impacted for DB2 needs to be functioning to provide trace records to the IQL processor.
The Application exception (via the Exception system) gets the data no matter the state of DB2. The IQL exception (via the IQL Processor) is reliant on receiving the data from DB2. The IQL written with an output destination of EXCP will send the data to the exception system, but it still needs to receive the data from DB2 first. In this case, The IQL exception was not receiving any data from DB2 to send to the Exception processor for output.
If the problem reoccurs or can be simulated, go the the Sysview for Db2 (IDB2) UI command screen and issue the IFI command. If the counters are getting higher (paying specific attention to IFCID 148 on that display) then take a console dump of the data collector to provide to Sysview for Db2 support for analysis. If the counters are not increasing then DB2 isn't responding and data is not being provided to the IQL processor.