You should plan for the following broad levels of monitoring activity:
- Dynamic (online) monitoring.
- Daily monitoring.
- Periodic (weekly and monthly) monitoring.
- Keeping sample reports as historical data. You can also keep historical
data in a database such as the Tivoli® Decision Support database.
Dynamic monitoring, is "on-the-spot" monitoring that you can, and
should, carry out at all times. This type of monitoring generally includes
the following:
- Observing the system’s operation continuously to discover any serious
short-term deviation from performance objectives.
Use the CEMT transaction
(CEMT INQ|SET MONITOR), together with end-user feedback. You can also use the Resource Measurement
Facility (RMF™) to collect information about processor, channel, coupling facility,
and I/O device usage.
- Obtaining status information. Together with status information obtained
by using the CEMT transaction, you can get status information on system processing
during online execution. This information could include the queue levels,
active regions, active terminals, and the number and type of conversational
transactions. You could get this information with the aid of an automated
program invoked by the master terminal operator. At prearranged times in
the production cycle (such as before scheduling a message, at shutdown of
part of the network, or at peak loading), the program could capture the transaction
processing status and measurements of system resource levels.
- The System Management product, CICSPlex® SM, can accumulate information produced
by the CICS® monitoring facility to assist in dynamic monitoring activities.
The data can then be immediately viewed online, giving instant feedback on
the performance of the transactions. To allow CICSPlex SM to collect CICS monitoring
information, CICS monitoring must be active using CEMT SET MONITOR ON.
The overall objective here is to measure and record key system parameters
daily. The daily monitoring data usually consists of counts of events and
gross level timings. In some cases, the timings are averaged for the entire CICS system.
- Record both the daily average and the peak period (usually one hour) average
of, for example, messages, tasks, processor usage, I/O events, and storage
used. Compare these against your major performance objectives and look for
adverse trends.
- List the CICS-provided statistics at the end of every CICS run. You should
date and time-stamp the data that is provided, and file it for later review.
For example, in an installation that has settled down, you might review daily
data at the end of the week; generally, you can carry out reviews less frequently
than collection, for any one type of monitoring data. If you know there is
a problem, you might increase the frequency; for example, reviewing daily
data immediately it becomes available.
You should be familiar with all
the facilities in CICS for providing statistics at times other than at shutdown.
The main facilities, using the CEMT transaction, are invocation from a terminal
(with or without reset of the counters) and automatic time-initiated requests.
- File an informal note of any incidents reported during the run. These
may include a shutdown of CICS that causes a gap in the statistics, a complaint from
your end users of poor response times, a terminal going out of service, or
any other item of significance. This makes it useful when reconciling disparities
in detailed performance figures that may be discovered later.
- Print the system console log for the period when CICS was active,
and file a copy of the console log in case it becomes necessary to review
the CICS system performance in the light of the concurrent batch activity.
- Run one of the performance analysis tools described in Performance measurement tools: Overview for
at least part of the day if there is any variation in load from day to day.
File the summaries of the reports produced by the tools you use.
- Transcribe onto a graph any items identified as being consistently heavily
used in the post-development review phase (described in Gathering data for performance objectives).
- Collect CICS statistics, monitoring data, and RMF data into the Tivoli Decision Support database.
Here, the objective is to periodically collect detailed statistics on the
operation of your system for comparison with your system-oriented objectives
and workload profiles.
- Run the CICS monitoring facility with performance class active, and process it.
It may not be necessary to do this every day, but it is important to do it
regularly and to keep the sorted summary output as well as the detailed reports.
Whether you do this on the same day of the week depends on the nature of the
system load. If there is an identifiable heavy day of the week, this is the
one that you should monitor. (Bear in mind, however, that the use of the
monitoring facility causes additional load, particularly with performance
class active.)
If the load is apparently the same each day, run the CICS monitoring facility daily for a period sufficient to confirm this.
If there really is little difference from day to day in the CICS load, check
the concurrent batch loads in the same way from the logs. This helps you
identify any obscure problems because of peak volumes or unusual transaction
mixes on specific days of the week. The first few weeks’ output from
the CICS statistics also give guidance for this.
It may not be necessary
to review the detailed monitor report output every time, but you should always
keep this output in case the summary data is insufficient to answer questions
raised by the statistics or by user comments. Label the CICS monitoring
facility output tape (or a dump of the DASD data set) and keep it for an agreed
period in case further investigations are required.
- Run RMF, because this shows I/O usage, channel usage,
and so on. File the summary reports and archive the output tapes for some
agreed period.
- Review the CICS statistics, and any incident reports.
- Review the graph of critical parameters. If any of the items is approaching
a critical level, check the performance analysis and RMF outputs for more detail and follow any
previously agreed procedures (for example, notify your management).
- Tabulate or produce a graph of values as a summary for future reference.
- Produce weekly Tivoli Decision Support or CICS Performance Analyzer reports.
- Run RMF.
- Review the RMF and performance analysis listings. If there is any indication of
excessive resource usage, follow any previously agreed procedures (for example,
notify your management), and do further monitoring.
- Date- and time-stamp the RMF output and keep it for use in case performance
problems start to arise. You can also use the output in making estimates,
when detailed knowledge of component usage may be important. These aids provide
detailed data on the usage of resources within the system, including processor
usage, use of DASD, and paging rates.
- Produce monthly Tivoli Decision Support reports showing long-term trends.
When performance is acceptable, you should establish procedures to monitor
system performance measurements and anticipate performance constraints before
they become response-time problems. Exception-reporting procedures are a
key to an effective monitoring approach.
In a complex production system there is usually too much performance data
for it to be comprehensively reviewed every day. Key components of performance
degradation can be identified with experience, and those components are the
ones to monitor most closely. You should identify trends of usage and other
factors (such as batch schedules) to aid in this process.
Consistency of monitoring is also important. Just because performance
is good for six months after a system is tuned is no guarantee that it will
be good in the seventh month.
[[ Contents Previous Page | Next Page Index ]]