Thread Terms value doesn't match the All Trans Count value .
Article ID: 135318
Updated On:
Products
Issue/Introduction
Go to the System History( HSLIST) display and selected one intervals(R/HSTCSA) .
For the selected interval display the Accounting by Connection display. When looking at both displays the Thread Terms value doesn't match the All Trans Count value on the Accounting by Connection display. Here is one example for this particular case:
For 7/22/2019 14:30 to 15:00 interval, Thread Terms at 15:00 were 352517 and the All Trans Count value is 524446 in Accounting by Connection. Is thread reuse the cause of the differences between these counts? What else might impact these numbers?
Environment
Release :
Component : CA Insight Database Performance Monitor for DB for z/OS
Resolution
The "Thread Terminates" counter (Q3STTERM) comes from IFCID 1, while the "Transaction Count" (QWACPCNT369) comes from IFCID 369.
These counters have different meanings, they are updated at different times but yes, they could contain similar values. IFCID 369 counter is updated when an accounting record is produced (the actual values come from IFCID 3), while IFCID 1 count is updated when a thread is terminated.
Note, that there might be multiple IFCIDs 3 produced during thread life-time.
Here are the descriptions for these fields from IBM:
IFCID 369: QWACPCNT369 - THIS VALUE IS CALCULATED ONLY IF ACCOUNTING CLASS 1 IS ACTIVE.
- FOR A NON-ROLLUP RECORD FOR A PARENT AGENT, THIS VALUE IS THE NUMBER OF PARALLEL CHILD AGENTS THAT WERE CREATED.
- FOR A NON-ROLLUP RECORD FOR A CHILD AGENT, THIS VALUE IS 0.
- FOR A PARALLEL QUERY ROLLUP RECORD, THIS VALUE IS THE NUMBER OF PARALLEL CHILD AGENTS THAT WERE INCLUDED IN THE RECORD. - FOR AN AUTONOMOUS PROCEDURE ROLLUP RECORD, THIS VALUE IS THE NUMBER OF AUTONOMOUS PROCEDURES THAT WERE ROLLED INTO THE RECORD.
- FOR A DDF OR RRSAF ROLLUP RECORD, THIS VALUE IS THE NUMBER OF ACCOUNTING INTERVALS THAT WERE INCLUDED IN THE RECORD FOR THE CORRESPONDING END USER.
IFCID 001: Q3STTERM - SUCCESSFUL TERMINATE THREAD REQUESTS. NUMBER OF TIMES THREADS ARE TERMINATED. THIS COUNT DOES NOT AGREE WITH THE CREATE THREAD COUNT BECAUSE EACH LEVEL OF A THREAD'S ACCESS (IDENTIFY, SIGNON, AND CREATE THREAD) MUST BE TERMINATED.
- SIGNON - The number of signons that identified a new user of an existing thread for IMS and CICS. This field is valid only for CICS and IMS (not valid for TSO, CAF, or UTILITY). The initial signon does not perform an authorization check because the thread does not exist yet, but a resignon can.
- CREATE THREAD - The number of successful create thread requests. It does not include DBATs.
- IDENTIFY - The number of successful connections to DB2 from an allied address space (TSO, BATCH, CICS, IMS, CAF, or UTILITY).
Here is a couple examples:
1) Normal/standard case: Thread created, zero or several commits, thread de-alocated (Accounting record generated). In this case thread terminates counter should be equal to transaction count.
2) For IMS AND CICS threads could be reused. Thread created , signon, commit, new transaction signon (Accounting record generated), commit, new transaction signon (Accounting record generated), ... , thread de-alocated (Accounting record generated). In this case transaction counts will be greater than thread terminates counter.
3) When the connection goes inactive for distributed thread. Acquire DBAT, connection inactive on a Commit (Accounting record generated), acquire DBAT, connection inactive on a Commit (Accounting record generated).... In this case we could see a several transaction with no thread terminates.
4) For BATCH connection. Identify, Create Thread, Thread Terminate. In this case we could see one transaction with two thread terminates(each level of a thread's access (IDENTIFY, SIGNON, AND CREATE THREAD) must be terminated).
"Is thread reuse the cause of the differences between these counts?", Yes the thread reuse might be the cause of differences between the counters.
Feedback
