Coupling Facility Structure Activity section
This section of the Coupling Facility Activity report has detail for each active structure in the coupling facility, including activity data for each system connected to the structure during the reporting interval.
The following table explains the field headings in the Structure Activity section.
|STRUCTURE NAME||The name given to the structure by the coupling facility policy specification in the Function Couple Data Set. It is up to 16 characters and is unique within a sysplex.|
|TYPE||Indicates whether the structure is a list, lock, or cache structure. If it is a lock structure, then the contention counts are included in the report.|
|STATUS||Indicates status of the structure at the end of the interval. For the description of possible values refer to Table 1.|
|SYSTEM NAME||The system name for the system connected to the structure (from IEASYSxx Parmlib member,
The name is preceded by an '*' if the data for this system is incomplete for this interval, for example because the gatherer has been stopped.
| # REQ TOTAL
# REQ AVG/SEC
|The sum of all requests (internal and external) that utilize the subchannel. Specifically:
This field offers a quick way of determining which systems are generating the most activity for a given structure, and indicates where to focus tuning or load balancing efforts.
|REQUESTS||The requests are shown in four categories described hereafter: SYNC, ASYNC, CHNGD, and SUPPR.|
|SYNC||Total number of hardware operations that started and completed synchronously to the coupling facility on behalf of connectors to the structure.|
|ASYNC||Total number of hardware operations that started and completed asynchronously to the coupling
facility on behalf of connectors to the structure.
The service time is the time for all ASYNC requests (ASYNC and CHNGD).
|CHNGD||Total number of hardware operations that changed from synchronous to asynchronous because the
operation could not be serviced as synchronous operation. This field reports only those operations
which were changed due to a subchannel busy condition and can be used as an indicator of a shortage
of subchannel resources.
Conversions caused by heuristic sync/async algorithms used to optimize the coupling efficiency of workloads using the CF are not included.
|SUPPR||Number of requests whose execution was suppressed by the coupling facility in order to avoid a potential serialization deadlock condition across a duplexed pair of structures. This field does not apply to asynchronously duplexed structures.|
| # REQ
% OF ALL
(valid for SYNC, ASYNC, CHNGD, and SUPPR)
|The number of requests for this structure, and the percentage this represents of all requests for this structure from any system.|
|SERVICE TIME - AVG||The average time in microseconds required to satisfy a coupling facility request for this structure.|
|SERVICE TIME - STD_DEV||The standard deviation of service time for this structure.
Even though the average time looks acceptable, the standard deviation could be high, indicating that there is a wide fluctuation in service times for requests. In this case, analyze the coupling facility configuration for possible path or coupling facility bottlenecks in the Subchannel Activity section.
|DELAYED REQUESTS||These columns list possible contention reasons for requests sent to the coupling facility.|
|REASON||The reason for a delayed request can be either a subchannel contention (NO SCH), dump
serialization (DUMP) or CF monopolization avoidance (MONOP).
For synchronous duplexed requests, also peer subchannel wait time (PR WT) and waiting-for-peer-completion time (PR CMP) is reported. A duplexed request requires two subchannels. PR WT is the time (in microseconds) between the moment when the request was sent to the other duplexed structure instance and when it is sent to this one. PR CMP is the time (in microseconds) between the moment when this structure responded to z/OS and when the other structure instance responded. Both subchannels are busy until the responses from both structure instances are processed by z/OS.
If the coupling facility tasks receive excessive requests for the same structure, the coupling facility indicates this situation to the operating system so that cross-system extended services (XES) stops sending requests to the coupling facility for the specific structure. This feature is called CF monopolization avoidance. If a system does not have valid CF monopolization avoidance data, MONOP values are displayed in the report as N/A, and total MONOP values are unavailable for the structure.
| # REQ
% of REQ
|The total number and the percentage of requests delayed in the interval.|
|AVG TIME - /DEL||The average delay time in microseconds over all delayed requests.|
|AVG TIME - STD_DEV||The standard deviation to the average delay time.|
|AVG TIME - /ALL||The average delay time in microseconds over all requests, whether delayed or not.|
|EXTERNAL REQUEST CONTENTIONS||These values are available for all serialized list structures.|
|REQ TOTAL||The number of requests against this structure.|
|REQ DEFERRED||The number of requests running into a lock contention|
|EXTERNAL REQUEST CONTENTIONS||These values are available for all lock structures.|
|REQ||Total requests issued for the lock structure|
|REQ DEFERRED||Subset of the above field indicating the number of requests that were unable to complete within the request issuer's thread. That is, any request that needed additional processing to complete.|
|-CONT||A subset of the REQ DEFERRED field. It
presents the number of requests delayed due to contention on a lock.
A lock is held by an EXCLUSIVE request, and another request is made for the same lock with EXCLUSIVE or SHARE specified. If this number is high it could indicate an impact to the end user of the application or subsystem owning the lock structure. Refer to that application's traces or reports for more detail on what locks caused the heavy contention.
|-FALSE CONT||A subset of the CONT field showing the number of requests that experience "hash contention".
This occurs because a hashing algorithm is used to map a lock request to a lock table entry. When
more than one lock request maps to the same entry, there is the potential for contention delay. You
may need to increase the size of the lock table.
Note: It is possible for an application to have unusual lock reference patterns that cause storage contention regardless of the size of the lock structure.
|TOTAL||This row of data gives totals (or overall averages and percentages) for all the systems connected to the structure,|
|DATA ACCESS||This information is shown for cache structures.|
|READS||The number of occurrences the coupling facility returned data on a read request by any
connector (read hit).
Directory only caches will always have a zero value reported since there are no data to be returned.
|WRITES||The number of occurrences data has been written to the cache structure.
Directory only caches will always have a zero value reported since there are no data writes possible.
|CASTOUTS||The number of times CASTOUT processing occurs.
This is the process of writing changed cache data to permanent storage.
This counter is of interest for store-in cache structures (for example, Db2 global buffer pool structures) in determining the volume of changed data being removed from the structure.
|XI'S||The number of times a data item residing in a local buffer pool was marked invalid by the
XI's count values are seen for directory, store-in and store-thru caches. This count reflects the amount of data sharing among the users of the cache and the amount of write or update activity against the data bases.