For more information about dispatcher statistics, see topic Dispatcher domain statistics.
The "Accum CPU time/TCB" is the amount of CPU time consumed by each CICS® TCB since the last time statistics were reset. Totaling the values of "Accum time in MVS™ wait" and "Accum time dispatched" gives you the approximate
time since the last time CICS statistics were reset. The ratio of the "Accum CPU
time /TCB" to this time shows the percentage usage of each CICS TCB. The "Accum CPU time/TCB" does not include uncaptured time, thus even a totally
busy CICS TCB would be noticeably less than 100% busy from this calculation.
If a CICS region is more than 70% busy by this method, you are approaching
that region’s capacity. The 70% calculation can only be very approximate,
however, depending on such factors as the workload in operation, the mix of
activity within the workload, and which release of CICS you are currently using. Alternatively,
you can calculate if your system is approaching capacity by using RMF™ to obtain a definititve
measurement, or you can use RMF with your monitoring system. For more
information, see the z/OS Resource Measurement Facility Performance Management Guide, SC33-7992.
Note:
"Accum time dispatched" is NOT a measurement of CPU time
because MVS can run higher priority work, for example, all I/O activity and higher
priority regions, without CICS being aware.
Modes of TCB are as follows:
- QR
- There is always one quasi-reentrant mode TCB. It is used to run quasi-reentrant CICS code and non-threadsafe application code.
- FO
- There is always one file-owning TCB. It is used for opening and closing
user data sets.
- RO
- There is always one resource-owning TCB. It is used for opening and
closing CICS data sets, loading programs, issuing RACF® calls, etc.
- CO
- The optional concurrent mode TCB is used for processes which can safely
run in parallel with other CICS activity such as VSAM requests. The SIT
keyword SUBTSKS has been defined to have numeric values (0 and 1) to specify
whether there is to be a CO TCB.
- D2
- The D2 mode TCB is used to terminate DB2® protected threads. Protected threads are
terminated in the normal purge cycle, or when a user issues the DSNC DISCONNECT plan-name command, which causes the protected threads
for a plan to be terminated immediately. Mode D2 is only used in CICS Transaction Server for z/OS®, Version 2 Release 2 or
later, when CICS is connected to DB2 Version 6 or later.
- SZ
- The single optional SZ mode TCB is used by the FEPI interface.
- RP
- The single optional RP mode TCB is used to make ONC/RPC calls.
- J8
- A J8 mode TCB is used to run a JVM in CICS key.
- J9
- A J9 mode TCB is used to run a JVM in user key.
- JM
- JM mode TCBs are used by the JVM that initializes the shared class cache.
There is one JM TCB for each shared class cache, including the current shared
class cache, any shared class cache that is being started or reloaded, and
any old shared class caches in the region that are waiting for worker JVMs
that are dependent on them to be phased out.
- L8
- A task has an L8 mode TCB for its sole use
when it
invokes a program that has been enabled with the OPENAPI option and is defined
with EXECKEY=CICS, or
when it invokes a task-related user exit program
that has been enabled with the OPENAPI option. This includes the CICS DB2 adaptor, when CICS connects to DB2 Version 6 or later.
L9 
A task has an L9 mode TCB for its sole use when it invokes a program
that has been enabled with the OPENAPI option, and is defined with EXECKEY=USER.
X8 
A task has an X8 mode TCB for its sole use when it invokes a C or C++
program that has been compiler with the XPLINK compiler option, and is defined
with EXECKEY=CICS.
X9 
A task has an X9 mode TCB for its sole use when it invokes a C or C++
program that has been compiler with the XPLINK compiler option, and is defined
with EXECKEY=USER.
- SO
- The SO mode TCB is used to make calls to the sockets interface of TCP/IP.
- SL
- The SL mode TCB is used to wait for activity on a set of listening sockets.
- S8
A task uses an S8 TCB if it needs to use the system Secure
Sockets Layer. The TCB is only used for the duration of the SSL negotiation.
When the negotiation is complete, the TCB is released back into the SSL pool
to be reused.
SP
The SP mode TCB is used for socket pthread owning tasks. It manages
the SSL pool of S8 TCBs and owns the Language Environment® enclave that contains the SSL cache.
The Dispatcher TCB Pool statistics for the JVM TCB pool show the number
of requests in a given interval that had to wait for a free J8 or J9 TCB (in
the statistics field Total Attaches delayed by Max TCB Pool Limit). The total
wait time is shown in the statistics field 'Total Max TCB Pool Limit delay
time'.
If the interval includes the time when the JVMs were initialized, it is
likely that the waits occurred while the JVMs were starting. You can verify
this by comparing the statistics to those for an interval later in the day,
when the JVMs have been initialised and have reached a steady state.
The statistics field 'Peak attaches delayed by Max TCB Pool limit' shows
the peak number of concurrent requests to run a JVM program that could not
be satisfied because no JVM was available. Again, you can expect this field
to be high while the JVMs are starting.
The statistics for mismatch waits show the numbers of requests that waited
because there was no TCB available matching the request, but there was at
least one non-matching free TCB. For the JVM pool, this shows the requests
that waited for a TCB of the correct mode (J8 or J9) and JVM profile. "How CICS allocates JVMs to applications" in Java™ Applications in CICS explains how CICS manages mismatch waits.
The JVM Pool statistics provide further information about activity in the
JVM pool. See Interpreting JVM statistics for more information about these statistics.
[[ Contents Previous Page | Next Page Index ]]