CICS temporary storage: overview

You can set up temporary storage for a CICS® region in three locations: main storage, auxiliary storage, or shared temporary storage pools in a z/OS® coupling facility.

Main storage
Main temporary storage is in 64-bit (above-the-bar) storage in the CICS region. You use the TSMAINLIMIT system initialization parameter to specify the amount of storage that is available to temporary storage queues.

You can use local main storage in the CICS region where the applications run, or you can function ship temporary storage requests to a remote queue-owning region (QOR).

Auxiliary storage
Auxiliary temporary storage is in a nonindexed VSAM data set named DFHTEMP. You define the available space and any additional extents when you set up this data set. Some 31-bit (above-the-line) storage is used in the CICS region for VSAM buffers to make control intervals available from the VSAM data set. You use the TS system initialization parameter to set the number of buffers. Like main temporary storage, auxiliary temporary storage can be associated with the local CICS region or a remote queue-owning region.
Shared temporary storage pools in a z/OS coupling facility
Shared temporary storage pools (TS pools) are in a z/OS coupling facility managed by a temporary storage data sharing server (TS server). Each pool corresponds to a list structure in the coupling facility. You specify the size of each temporary storage pool using the coupling facility resource manager (CFRM) policy definition utility in z/OS. Shared temporary storage pools do not use any storage in the CICS region, and applications access them directly from the local CICS region.

When applications use the WRITEQ TS and READQ TS commands to access temporary storage queues, the requests are processed by the CICS temporary storage domain, which creates temporary storage queues in the appropriate storage location and places the data in them. Any task can retrieve the data using the symbolic name of the temporary storage queue. The CICS temporary storage domain can process multiple requests concurrently, but it serializes requests made for the same temporary storage queue, and the queue is locked for the duration of each request.

You use TSMODEL resource definitions to set up models that CICS uses to create temporary storage queues. Each model specifies the following attributes for temporary storage queues with names that match the model:
  • The location of the temporary storage where the queue must be stored
  • Whether the temporary storage is associated with the local CICS region or a remote CICS region, such as a queue-owning region
  • Whether the queue is deleted automatically by CICS, if it remains unused for a period of time and is not deleted by an application
  • Whether the queue is recoverable

Table 1 summarizes the storage usage and the features that you can select for temporary storage queues in each location.

Table 1. Features of temporary storage locations
Temporary storage location Storage type Automatic queue deletion Recovery
Main storage 64-bit storage in CICS region Available Not available
Auxiliary storage VSAM data set, plus 31-bit storage in CICS region for buffers Available for non-recoverable queues Available
Shared temporary storage pool z/OS coupling facility Available CICS recovery is not available, but the queues are persistent (they are not affected by a CICS restart)
CICS also creates some temporary storage queues for its own use. These queues can be in main temporary storage or auxiliary temporary storage. For example, CICS uses temporary storage for the following purposes:
  • Basic mapping support (BMS) paging and routing
  • Caching of messages
  • Interval control
  • The CICS execution diagnostic facility (EDF)
  • Local queueing for MRO, ISC, and IPIC while the target system is unavailable

When you view the temporary storage queues in your CICS system, queues with names that start with these characters are CICS queues: **, $$, X'FA' through X'FF', CEBR, and DF.