Usually a transaction or application execution is considered as
one thread for which one physical accounting records (IFCID 3) is
created by Db2. In case of SQL query parallelism there is one or
more additional physical record (IFCID 3) per each parallel thread
execution. (you are right SYSPLEX query || is dead, but we still
support older DB2 versions). In order to see the complete execution
counts we accumulate all parallel thread info into the originating
parent record for the REPORT, means you will see the complete
execution counts of your application w/o having to accumulate the
parallel thread execution by yourself. That is why we talk
about logical accounting record which can consist of several
physical (parallel) records.
The other case is if a ACCUMAC roll-up contains a number RRSAF
or DDF thread executions. In order to calculate the correct average
times and counters per rolled-up thread we have to count the real
number of rolled-up thread execution data.
That is #OCCURRENCES is the number of originating threads (w/o
counting the physical parallel thread because they are already
accumulated by OM DB2 into the originating thread) and the
number of rolled-up RSAF and DDF threads.
With this #OCCURRENCES we/you will have a divisor to get the
average values application/transaction execution. The REPORT
is always an aggregated view of several application execution Ordered
by the criteria you defined in your command language.
If you want to see the exact single execution values per
accounting records (IFCID3 ) you have to run the TRACE report or
even the RECTRACE report.
"number of accounting
There exist several connection types to DB2 (e.g. DDF, CICS)
which may allow to keep the connection alive, but DB2 would cut an
accounting records (IFCID 3) in certain situations, e.g. with
Please refer to the DB2 manual “Managing
Performance” (e.g. V11 SC19-4060), here an
You get an accounting trace record each time that a thread
is pooled rather than once for the entire time that you are
connected. When a pooled thread becomes active, the accounting
fields for that thread are re-initialized. As a result, the
accounting record contains information about active threads only,
which makes it easier to study how distributed applications are
performing. If a pooled mode thread remains active because of
sections that are specified with the KEEPDYNAMIC(YES) bind option,
an accounting record is still written.
Exception: If you employ account
record accumulation, an accounting trace is not produced each time
that a thread becomes pooled. Accounting records can be rolled up
by concatenated combinations of the following values:
– User ID
– End transaction name
– User workstation name
You can use the accounting trace to ensure that your
parallel queries are meeting their response time goals. DB2 rolls
task accounting into an accounting record for the originating task.
OMEGAMON also summarizes all
accounting records generated for a parallel query and
presents them as one logical accounting record.
When CICS implements thread reuse, a change in the
authorization ID or the transaction code initiates the sign-on
process. This process terminates the accounting interval and
creates the accounting record.
TXIDSO=NO eliminates the sign-on process when only the
transaction code changes.
When a thread is reused without initiating sign-on, several
transactions are accumulated into the same accounting record. The
accumulated transactions can make it difficult to analyze a
occurrence and correlate DB2 accounting with CICS
accounting. However, applications that use ACCOUNTREC(UOW) or
ACCOUNTREC(TASK) in the DBENTRY RDO definition initiate a partial
which creates an accounting record for each transaction. You
can use this data to tune your programs and to determine DB2