CICS temporary storage: Performance and tuning

CICS® temporary storage is intended for short-lived data. An application can write data to temporary storage as a series of numbered items in a temporary storage queue. CICS also creates some temporary storage queues for its own use. Temporary storage is heavily used in many CICS systems.

The ways in which you can tune the use of CICS temporary storage depend on the locations of the temporary storage available to the CICS region. Temporary storage can be main storage in the CICS region, auxiliary storage in a VSAM data set, or shared temporary storage pools in a z/OS® coupling facility. The temporary storage can be associated with the local CICS region or a remote queue-owning region (QOR). For an overview of the locations for temporary storage, see CICS temporary storage: overview.

For main temporary storage, you can monitor the use of storage and use the TSMAINLIMIT system initialization parameter to set a suitable limit. For more information about tuning main temporary storage, see Main temporary storage: monitoring and tuning.

For auxiliary temporary storage, you must balance several factors when you set up the VSAM data set and when you are tuning the use of CICS temporary storage. The following factors affect the performance of auxiliary temporary storage:
  • The control interval size for the data set
  • The number of VSAM buffers in the CICS region
  • The number of VSAM strings for I/O to the data set
For more information about tuning auxiliary temporary storage, see Auxiliary temporary storage: monitoring and tuning.
Consider setting up shared temporary storage pools to improve availability and support dynamic transaction routing. Shared temporary storage pools require temporary storage servers (typically one server in each z/OS image in the sysplex), but they have a number of advantages:
  • No storage is used in the CICS region for the shared temporary storage pools.
  • Shared temporary storage pools do not cause intertransaction affinities. Local temporary storage queues in main or auxiliary storage can cause intertransaction affinities, where affected transactions must run in the same region to access the queue. Intertransaction affinities can affect performance by limiting the scope for workload routing across AORs in a sysplex.
  • Compared to remote queue-owning regions, access to temporary storage queues in shared temporary storage pools in a coupling facility is quicker.
  • If you use more than one temporary storage server for each pool, availability is better than it is for a remote queue-owning region. If one temporary storage server or z/OS image fails, transactions can be dynamically routed to another application-owning region on a different z/OS image.