Addressing OLTP Solutions with CICS: The Transaction Server ... - Ibm

3.4.11 Operations
plan to cope with this situation. This is where CICS SM can play a significant
role. By having multiple configurations reflecting the different applications or
resources as required at different times of the day or week, changes can easily
be introduced. The changes are made by working with the CICS SM GUI rather
having to issue CICS commands or log on to the CICS system directly.
You want to minimize the amount of forced downtime for maintenance or
housekeeping procedures. Adopting the approach we discuss in 8.5.1.1,
“Combining Resources” on page 121 can help avoid such outages.
Consider how the operations staff will run the new systems on a day-to-day
basis. The only performance recommendation here is to ensure that the staff
has clear guidance and effective tools with which to manage the system because
a system or application that is down has zero performance.
Again CICS SM can play a major role in improving the ease with which the CICS
for AIX regions and their resources are operated. By having all necessary
configurations defined, the operations staff can simply ensure that the relevant
configuration is active at the required time by working with the CICS SM GUI.
The single point of control (SPOC) becomes a reality and a benefit. The single
system image (SSI) allows operations staff to determine the state of any CICS
resource without having to access the actual machine. As well as providing a
more effective means of managing the environment, CICS SM also provides a
more efficient means.
3.4.12 CICS Testing and Evaluation
46 CICS for AIX as the Transaction Server
Testing should be a key element in the introduction of a new system or
application. We recommend taking the time to develop test tools. The tools do
not have to be very complex. Consider using an ECI- or EPI-based application.
The use of a multithreaded client will allow more users to be simulated for a
given amount of machine resource.
Testing is often not given the focus that it deserves. It is, however, the last
opportunity to check the integrity and function before the actual users start using
the system. Problems discovered in a production environment are far more
difficult to resolve where there is greatly increased pressure for the service to
made available. Volume testing will enable you to gain confidence that the
system can cope with the expected levels of work. It will also enable you to
stress the system to see what happens if, for example, 110% of the expected
volume of work is placed in the system.
When you have the ability to drive work through the system, it is wise to
introduce some way to evaluate user and system performance, such as
measuring user response times, or CPU usage, to give you confidence that the
system is performing as expected. User and system performance evaluation can
indicate that the system is not tuned properly—perhaps the database buffers
were not set correctly and twice the expected level of I/O is taking place, or
perhaps a trace was left on after debugging some application problems.