CICS recovery: performance considerations

Some types of recoverable resources, when they are accessed for update, cause logging. Do not define more resources as recoverable than you need for application programming requirements, because the extra logging incurs extra I/O and processor overheads. If the resource in question does not require recovery, these overheads are unproductive.

Limitations

Specifying recovery increases processor time, real and virtual storage, and I/O requirements. It also increases task waits arising from enqueues on recoverable resources and system log I/O, and increases restart time.

Recommendation

Do not specify recovery if you do not need it. If the overhead is acceptable, logging can be useful for auditing, or if a data set has to be rebuilt.

For information on specific recoverable resources, see Tuning the use of CICS temporary storage (TS), and Optimizing the performance of the CICS transient data (TD) facility.

How implemented

See the CICS® Recovery and Restart Guide for information on each resource to be specified as recoverable.

How monitored

CICS auxiliary trace shows task wait time due to enqueues. RMF™ shows overall processor usage. CICS monitoring data shows task wait time due to journaling.

Related tasks
CICS facilities: performance considerations
Tuning the use of CICS temporary storage (TS)
Using temporary storage data sharing to improve performance
Optimizing the performance of the CICS transient data (TD) facility
Using Global ENQ/DEQ to improve performance
CICS monitoring facility: performance considerations
CICS trace: performance considerations
CICS security: performance considerations
CICS storage protection facilities: performance considerations
CICS business transaction services: performance considerations
[[ Contents Previous Page | Next Page Index ]]