CICS / WebSphere

The CICS Data Sharing Servers

6 Pages

CICS has been continually enhanced since its inception more than 35 years ago. Support for many new features has been added, including Web access, SOAP support, Java applications, etc. 

With CICS Transaction Server, support was added for temporary storage data sharing, a new type of data sharing predicated upon a new form of server provided with CICS. The shared temporary storage server runs as a separate address space to CICS. It provides access to a named pool of shared temporary storage queues, whose data is held in a coupling facility. For each z/ OS image in the sysplex environment, one shared temporary storage server is required for each pool defined in the coupling facility accessed from that z/ OS image. The pool access occurs via cross-memory calls from CICS to the shared temporary storage server for the named pool. 

CICS Transaction Server V1.3 provides support for additional forms of data sharing servers. This release provided a coupling facility data table server and named counter server, besides the shared temporary storage server. 

This article describes the use of data sharing servers in CICS, including issues relating to the servers, the programming options available to exploit them, and their diagnostic capabilities. 

An Overview of CICS Temporary Storage  

The temporary storage facility lets application programs hold data created by one transaction for later use by the same transaction or a different transaction. Temporary storage is a scratchpad facility that user applications and CICS itself can use to obtain state data (e.g., the FROM data associated with interval control EXEC CICS START requests). The data is saved in temporary storage queues identified by one-to 16-character symbolic names. Before the introduction of temporary storage data sharing, temporary storage data could traditionally be held in two places: 

  • Main temporary storage was typically used if small amounts of data were to be stored, the data was needed for only short periods of time, and/or the data didn’t need to be recoverable.
  • Auxiliary temporary storage was typically used if large volumes of data were to be stored, the data was needed for extended periods of time, and/or the data was to be maintained from one CICS run to the next. Auxiliary temporary storage queue data is held on the CICS-managed VSAM Entry-Sequenced Data Set (ESDS) DFHTEMP. It can be defined as a recoverable CICS resource. 

Both destinations limit the use of the temporary storage facility to one CICS system, making it impossible to share temporary storage queue data between different CICS systems. Main temporary storage resides in memory in a particular CICS system’s address space; auxiliary temporary storage resides in a DFHTEMP data set that a particular CICS system owns. To allow data access by multiple CICS systems, temporary storage requests could traditionally be function shipped from multiple Application Owning Regions (AORs) to dedicated Queue Owning Regions (QORs). 

Temporary Storage Data Sharing  

CICS Transaction Server V1.1 introduced shared temporary storage using a coupling facility. Temporary storage was further enhanced in CICS Transaction Server V1.3 to allow the definition of TSMODELs through CICS RDO and to support queue names of up to 16 characters. 

Temporary storage data sharing lets CICS applications access non-recoverable temporary storage queues from multiple CICS systems running on any z/OS image in a parallel sysplex environment. CICS stores a set of temporary storage queues to be shared across the parallel sysplex in a TS pool. Each TS pool corresponds to a coupling facility DFHXQLS list structure defined in the Coupling Facility Resource Manager (CFRM) policy. 

6 Pages