CICS / WebSphere

Shared Data Tables & CICS TS

5 Pages

A Shared Data Table (SDT) is simply a VSAM Key Sequenced Data Set (KSDS) that has been loaded into virtual storage and accessed as a table— reducing physical I/O and improving response time. The feature for using SDTs has been available in CICS TS since CICS/ESA 3.3, but SDT use has been somewhat limited in many installations for several reasons:

  • The amount of real storage required to support data sets defined as SDTs
  • The recommendation that SDTs be used for data sets that reflect a high read-to-write activity ratio or for read only
  • Several restrictions, when data tables were initially announced, that required programming changes
  • The original design of the data table, which called for using CICS region storage.

For these reasons, many installations limited use of SDTs to small- or intermediate-size, read-only data sets. The recommended read-to-write ratio Rule of Thumb (ROT) for data sets that require output operations has been around 90 percent; that is, the data set receives 90 percent of its activity doing read operations. However, with the availability of more real storage on processors today, users should re-evaluate the use of SDTs to obtain better performance and response times.

This article offers tuning recommendations for SDTs, including insight on the break-even point for a data set in terms of its read-to-write ratio.

VIRTUAL STORAGE: A CONCERN?

We haven’t mentioned virtual storage as a concern in a CICS TS address space when using SDTs. The reason is because SDTs are placed into data spaces that have their own virtual storage, independent of the CICS TS address space. The CICS TS address space contains only control blocks that identify where the information is kept in the data spaces. Small control blocks also are placed into the z/OS Extended Common Storage Areas (ECSA) used when the SDT is shared by more than one CICS region. However, virtual storage may be an issue in the data spaces themselves. CICS TS can generate up to 100 data spaces, each up to 2GB. The total capacity available for data tables is 200GB.

The actual number depends on several factors, including the total number of data sets declared as data tables and the installation System Management Facility (SMF) Exit, IEFUSI, which can be used to limit both the total number of data spaces CICS TS can support and the maximum size allowed for each data space. So, check with your operating system staff to see what, if any, limitations have been placed on CICS TS regarding the use of data spaces. Also, the default values for the parameters in IEFUSI may not suit your needs. The allocated data spaces are retained until CICS TS is shut down regardless of whether the file is closed and the space is no longer used.

The names CICS TS assigns to the data spaces are DFHDT001 to DFHDT100. CICS TS initially creates three data spaces when the first data table is opened. DFHDT003 is used to store the actual data. Should this data space fill up, CICS TS will allocate the next data space available, if any. In this case, it would be DFHDT004. The first data space, DFHDT001, is used to store table entry descriptors while DFHDT002 is used to store the index nodes.

Space allocations in a data space occur in 16MB units for the data component and are allocated to individual tables in increments of 128KB. So, each 16MB allocation can hold up to 128 extensions of 128KB increments. If additional space is required, another 16MB piece is acquired, if available. If not, then another data space is acquired, if available. If not, then a “no more space available condition” is raised. Data for the table in the 128KB is stored in page-aligned frames that can accommodate the maximum record length. The process continues until there are no data spaces available or the index node or table entry descriptor data spaces are full.

DATA PAGE FRAMES

The concept of data page frames can be loosely equated to a VSAM Control Interval (CI). Data with similar keys are stored in the frames. However, in contrast to VSAM, records aren’t necessarily stored in ascending sequence in the frame. The reason is that records are located by indirect means using record descriptors. For this reason, records can’t be moved to consolidate free space because it would affect the table entry descriptors used to access the records and would limit concurrent access to records.

5 Pages