Use the following questions as a basis for your own checklist when carrying
out a review of performance data. Many of these questions can be answered
by performance reporting packages such as CICS® Performance Analyzer or Tivoli® Decision Support for z/OS®.
Some of the questions are not strictly to do with performance. For instance,
if the transaction statistics show a high frequency of transaction abends with usage
of the abnormal condition program, this could perhaps indicate signon errors
and, therefore, a lack of terminal operator training. This, in itself, is
not a performance problem, but is an example of the additional information
that can be provided by monitoring.
- What are the characteristics of your transaction workload?
- Has the frequency of use of each transaction identifier altered?
- Does the mix vary from one time of the day to another?
- Should statistics be requested more frequently during the day to verify
this?
A different approach must be taken:
- In systems where all messages are channeled through the same initial task
and program (for user security routines, initial editing or formatting, statistical
analysis, and so on)
- For conversational transactions, where a long series of message pairs
is reflected by a single transaction
- In transactions where the amount of work done relies heavily on the input
data.
In these cases, you have to identify the function by program
or data set usage, with appropriate reference to the CICS program statistics,
file statistics, or other statistics. In addition, you may be able to put
user tags into the monitoring data (for example, a user character field in
the case of the CICS monitoring facility), which can be used as a basis
for analysis by products such as CICS Performance Analyzer for z/OS, or Tivoli Decision
Support for z/OS.
The questions asked above should be directed at the appropriate
set of statistics.
- What is the usage of the telecommunication lines?
- Do the CICS terminal statistics indicate any increase in the number of messages
on the terminals on each of the lines?
- Does the average message length on the CICS performance class monitor reports vary
for any transaction type? This can easily happen with an application where
the number of lines or fields output depends on the input data.
- Is the number of terminal errors acceptable? If you are using a terminal
error program or node error program, does this indicate any line problems?
If not, this may be a pointer to terminal operator difficulties in using
the system.
- What is the DASD usage?
- Is the number of requests to file control increasing? Remember that CICS records the number of logical requests made. The number of physical
I/Os depends on the configuration of indexes, and on the data records per
control interval and the buffer allocations.
- Is intrapartition transient data usage increasing? Transient data involves
a number of I/Os depending on the queue mix. You should at least review the
number of requests made to see how it compares with previous runs.
- Is auxiliary temporary storage usage increasing? Temporary storage uses
control interval access, but writes the control interval out only at syncpoint
or when the buffer is full.
- What is the virtual storage usage?
- How large are the dynamic storage areas?
- Is the number of GETMAIN requests consistent with the number and types
of tasks?
- Is the short-on-storage (SOS) condition being reached often?
- Have any incidents been reported of tasks being purged after deadlock
timeout interval (DTIMOUT) expiry?
- How much program loading activity is there?
- From the monitor report data, is the use of dynamic storage by task type
as expected?
- Is storage usage similar at each execution of CICS?
- Are there any incident reports showing that the first invocation of a
function takes a lot longer than subsequent ones? This may arise when programs
are loaded that then have to open data sets, particularly in IMS/ESA®, for example.
Can this be reconciled with application design?
- What is the processor usage?
- Is the processor usage as measured by the monitor report consistent with
previous observations?
- Are batch jobs that are planned to run, able to run successfully?
- Is there any increase in usage of functions running at a higher priority
than CICS? Include in this MVS™ readers and writers, MVS JES, and VTAM® if running above CICS, and overall
I/O, because of the lower-priority regions.
- What is the coupling facility usage?
- What is the average storage usage?
- What is the ISC link utilization?
- Do any figures indicate design, coding, or operational errors?
- Are any of the resources mentioned above heavily used? If so, was this
expected at design time? If not, can the heavy use be explained in terms
of heavier use of transactions?
- Is the heavy usage associated with a particular application? If so, is
there evidence of planned growth or peak periods?
- Are browse transactions issuing more than the expected number of requests?
In other words, is the count of browse requests issued by a transaction greater
than what you expected users to cause?
- Is the CICS CSAC transaction (provided by the DFHACP abnormal condition program)
being used frequently? Is this because invalid transaction identifiers are
being entered? For example, errors are signaled if transaction identifiers
are entered in lowercase on IBM® 3270 terminals but automatic translation
of input to uppercase has not been specified.
A high use of the DFHACP
program without a corresponding count of CSAC may indicate that transactions
are being entered without proper operator signon. This may, in turn, indicate
that some terminal operators need more training in using the system.
In addition to the above, you should regularly review certain items in
the CICS statistics, such as:
- Times the MAXTASK limit reached (transaction manager statistics)
- Peak tasks (transaction class statistics)
- Times cushion released (storage manager statistics)
- Storage violations (storage manager statistics)
- Maximum RPLs posted (VTAM statistics)
- Short-on-storage count (storage manager statistics)
- Wait on string total (file control statistics)
- Use of DFHSHUNT log streams.
- Times aux. storage exhausted (temporary storage statistics)
- Buffer waits (temporary storage statistics)
- Times string wait occurred (temporary storage statistics)
- Times NOSPACE occurred (transient data global statistics)
- Intrapartition buffer waits (transient data global statistics)
- Intrapartition string waits (transient data global statistics)
- Times the MAXOPENTCBS limit reached (dispatcher statistics)
- Times the MAXSOCKETS limit reached (TCP/IP statistics)
- Pool thread waits (DB2® connection statistics)
You should also satisfy yourself that large numbers of dumps are not being
produced.
Furthermore, you should review the effects of and reasons for system outages
and their duration. If there is a series of outages, you may be able to detect
a common cause of them.
[[ Contents Previous Page | Next Page Index ]]