CICS® collects statistics on the data written to each journal and log
stream; this data can be used to analyze the activity of a single region.
However, because general log streams can be shared across multiple MVS™ images, it can
be more useful to examine the statistics generated by MVS.
The MVS system logger writes SMF Type 88 records containing statistics for
each connected log stream. MVS supplies in SYS1.SAMPLIB a sample reporting program,
IXGRPT1, that you can use as supplied, or modify to meet your requirements.
Alternatively, you could use some other SMF reporting program. For information
about the SMF Type 88 records and the sample reporting program, see the z/OS MVS System Management Facilities (SMF) manual.
The main items that should be monitored routinely are:
- For coupling facility log streams, the number of "structure full"
events
- For DASD-only log streams, the number of "staging data set full"
events.
If these events occur frequently, this indicates that the logger cannot
write data to secondary storage quickly enough to keep up with incoming data,
which causes CICS to wait before it can write more data. Consider the following solutions
to resolve such problems:
- Increase the size of primary storage (that is, the size of the coupling
facility structure or, for a DASD-only log stream, the size of the staging
data set), in order to smooth out spikes in logger load.
- Reduce the data written to the log stream by not merging so many journals
or forward recovery logs onto the same stream.
- Reduce the HIGHOFFLOAD threshold percentage, the point at which the system
logger begins offloading data from primary storage to offload data sets.
- Review the size of the offload data sets. These should be large enough
to avoid too many "DASD shifts"--that is, new data set allocations.
Aim for no more than one DASD shift per hour. You can monitor the number of
DASD shifts using the SMF88EDS record.
- Examine device I/O statistics for possible contention on the I/O subsystem
used for offload data sets.
- Use faster DASD devices
For CICS system logs, the best performance is achieved when CICS can delete
log tail data that is no longer needed before it is written to secondary storage
by the MVS system logger. To monitor that this is being achieved, your reporting
program should examine the numbers in the SMF88SIB and SMF88SAB SMF Type 88
records. These values indicate:
- SMF88SIB
- Data deleted from primary storage without first being written to DASD
offload data sets. For a system log stream, this value should be high in relation
to the value of SMF88SAB. For a general log stream, this value should normally
be zero.
- SMF88SAB
- Data deleted from primary storage after being
written to DASD offload data sets. For a system log stream, this value should
be low in relation to the value of SMF88SIB. For a general log stream, this
value should normally be high.
Note:
In any SMF interval, the total number of bytes deleted from
primary storage (SMF88SIB plus SMF88SAB) may not match the total number of
bytes written to secondary storage, because data is only written to offload
data sets and then deleted from primary storage when the HIGHOFFLOAD threshold
limit is reached.
If the SMF88SAB record frequently contains high values for a CICS system log:
- Check that RETPD=dddd is not specified on the MVS definition of the logstream. (For information
about the MVS RETPD parameter, see the CICS Transaction Server for z/OS® Installation Guide.)
- Check that no long-running transactions are making recoverable updates
without syncpointing.
- Consider increasing the size of primary storage.
- Consider increasing the HIGHOFFLOAD threshold value.
- Consider reducing the value of the the AKPFREQ system initialization parameter.
[[ Contents Previous Page | Next Page Index ]]