How Sysview for Db2 reports on lock contention IFCID 1017

Products

• SYSVIEW Performance Management Option for DB2 for z/OS

Issue/Introduction

How does the Sysview Performance Management Option for Db2 for z/OS (IDB2) gather the information used to report on lock contention?

IDB2 creates IFCID 1017 records internally and IFCID 1017 is not an IBM IFCID.
How does Sysview for Db2 gather the 1017 record information? Control block sampling or via the IBM Db2 IFI interface?
How much overhead is involved when Sysview for Db2 gathers the IFCID 1017 information?

Resolution

The IFCID 1017, is a "pseudo-IFCID" that IDB2 creates based on data it finds when scanning the IRLM control blocks. These control blocks are
found in the IRLM address space. The control blocks are undocumented and do not have proper names, so there is no way to really describe
them much, other than to say that every lock holder and waiter will exist on a chain in the IRLM address space, and that is the source that
is used to populate the IRLMCONT request. It has been expectation that IBM would eventually create their own IFI record that would provide
the same info via an IFI READS call, but that still has not happened.

For the overhead, there is virtually no overhead to this process. The IRLMCONT request only executes code when somebody goes to the screen and hits (enter).
If an modified IRLMCONT version that executes every "n" seconds, it will execute regularly, of course. The overhead is still very low, but there is one caveat
that should be considered: if the IDB2 data collector does not execute at as high a dispatching priority as IRLM, and there is always a chance that IRLM control
block chains may be altered while IDB2 is looking at them. This generally results in an program check. This situation is expected, and recover from the ABEND
and retry the scan from the beginning. The overhead of the program check/recovery/retry is more significant, but still pretty low (as long as it is not happening too frequently).
So some care should be taken that the modified request is not executed more often than necessary.