The underlying dataset over which TS is implemented is pointed to by DFHTEMP dd-name in the CICS startup. This is a VSAM ESDS file, set up by the system’s programmer.
All CICS instance wide TS queues use this one file and the application programmer need not be bothered about setting this file up.
No need to define TS queues to CICS, if you do not want them to be recoverable, or under syncpoint control.
Online CEDA does not support TS queue definitions. You have to code assembler macros and assemble and Link edit the definition into the CICS libraries. This is a system programmer / CICS administrator’s job.
QUEUE:
This is the name of Queue 1 to the 8-byte character-set
ITEM:
A halfword PIC S9(4) COMP field which specifies the item to be rewritten when REWRITE is specified.
NUMITEMS:
A binary half word field that CICS sets with the number of items (including this one just written) in the queue. Not valid if ITEM is coded
Notes on TSQ:
- Temporary storage queues remain intact until they are deleted by the originating task, by any other task, or by an initial or cold start; Before deletion, they can be accessed any number of times.
- Even after the originating task is terminated, temporary data can be accessed by other tasks through references to the symbolic name under which it is stored.
- Temporary data can be stored either in the main storage or in auxiliary storage. Generally, the main storage should be used if the data is needed for short periods of time; auxiliary storage should be used if the data is to be kept for long periods of time.
- Data stored in auxiliary storage is retained after CICS termination and can be recovered in a subsequent restart, but data in the main storage cannot be recovered.
- The temporary storage queues can be defined as local, remote, or shared.
References
Related Posts
Srinimf 