Temporary storage control
The CICS® temporary storage control facility provides the application programmer with the ability to store data in temporary storage queues, either in main storage, in auxiliary storage on a direct-access storage device, or in a temporary storage data sharing pool. Data stored in a temporary storage queue is known as temporary data.
For an overview of the different temporary storage locations and the features available for temporary storage queues in each location, see Main temporary storage: Monitoring and tuning.
- Write data to a temporary storage queue (WRITEQ TS command).
- Update data in a temporary storage queue (WRITEQ TS REWRITE command).
- Read data from a temporary storage queue (READQ TS command).
- Read the next data from a temporary storage queue (READQ TS NEXT command).
- Delete a temporary storage queue (DELETEQ TS command).
Exception conditions that occur during execution of a temporary storage control command are handled as described in Dealing with exception conditions.
If you use these commands, you could create inter-transaction affinities that adversely affect your ability to perform dynamic transaction routing.
To help you identify potential problems with programs that issue these commands, you can use the scanner and collector components of the CICS Interdependency Analyzer. See CICS Interdependency Analyzer for z/OS for more information about this utility and Affinity for more information about transaction affinity.
Java and C++
The application programming interface described here is the CICS API, which is not used in Java™ programs. For information about Java programs using the JCICS classes to access temporary storage services, see Java programming using JCICS and the JCICS Javadoc documentation. For information about C++ programs using the CICS C++ classes, see Using the CICS C++ OO foundation classes.
Typical uses of temporary storage control
A temporary storage queue that has only one record can be treated as a single unit of data that can be accessed using its symbolic name. Using temporary storage control in this way provides a typical scratch-pad capability. This type of storage should be accessed using the READQ TS command with the ITEM option; not doing so can cause the ITEMERR condition to be raised.
In general, temporary storage queues of more than one record should be used only when direct access or repeated access to records is necessary; transient data control provides facilities for efficient handling of sequential data sets.
- Terminal paging
- A task could retrieve a large main record from a direct-access data set, format it into several screen images (using BMS), store the screen images temporarily in auxiliary storage, and then ask the terminal operator which “page� (screen image) is wanted. The application programmer can provide a program (as a generalized routine or unique to a single application) to advance page by page, advance or back up a relative number of pages, and so on.
- A suspend data set
- Suppose a data collection task is in progress at a terminal. The
task reads one or more units of input and then allows the terminal
operator to interrupt the process by some coded input. If not interrupted,
the task repeats the data collection process. If interrupted, the
task writes its incomplete data to temporary storage and terminates.
The terminal is now free to process a different transaction (perhaps
a high-priority inquiry). When the terminal is available to continue
data collection, the operator initiates the task in a
resume
mode, causing the task to recall its suspended data from temporary storage and continue as though it had not been interrupted. - Preprinted forms
- An application program can accept data to be written as output on a preprinted form. This data can be stored in temporary storage as it arrives. When all the data has been stored, it can first be validated and then transmitted in the order required by the format of the preprinted form.