How collection data is saved

The data collection process stores interdependency and affinity data in a data space, thus avoiding the overhead of writing the data to a VSAM data set. However, at some point this data must be externalized to VSAM data sets. Externalization is known as "saving" the collected data.

The save process occurs in these circumstances: The threshold is based on the number of record updates occurring in the data space.

The CINB transaction is called to perform the save process.

New records in the data space

To determine when new records are stored in the data space, see Number of interdependency records per workload and Number of affinity records per workload

Updated records in the data space

A record is updated when Maintain usage counts is set to Y on the General Options panel, and CICS IA detects a command that is already stored in the data space being issued. Note that changing Maintain usage counts from N to Y has a minimal effect on CICS IA performance.

Saving records to a VSAM data set

The cost of saving a single record to a local CICS IA VSAM data set is 47 microseconds.

Example for interdependency data collection

  • A workload runs in a single CICS region, and consists of 10 transactions, each of which invokes a single program.
  • Each of the 10 programs reads from its unique TD queue, and issues an FC WRITE to a common file.
  • Assuming that interdependency data collection is running for just TD and FC data, the total number of records in the data space is 20, consisting of 10 transaction IDs, each with 2 records (one for a TD queue read and one for an FC WRITE).
  • The total CPU time to save these records to a local VSAM file is 940 microseconds (20*47).
Note that normal production workloads result in many more records than in this example.

For most resources, the resource names are explicitly defined (for example, files defined by RDO or tables defined by DB2®), and are therefore relatively few in number. However, with TS queues, for example, programs can dynamically create a queue name. Potentially, there might be a large number of records in the data space because each unique queue name causes a new record to be created.

Improving the performance of DB2 catalog tables

During the installation process for CICS IA, run member hlq.SCIUSQL.OUT(CIUIBM1) to define indexes on the SYSIBM.SYSPACKSTMT and SYSIBM.SYSSTMT tables. This improves the performance of retrieving the information from the catalog tables.
Following the creation of these DB2 indexes, and before running the hlq.SCIUSMP2.OUT(CIUDBNB) member to rebind the packages and plans, you might need to run the RUNSTATS DB2 utility to ensure that these indexes are used in the new DB2 plan. The required RUNSTATS parameters are:
RUNSTATS TABLESPACE DSNDB06.SYSPKAGE TABLE(ALL) INDEX(ALL)
RUNSTATS TABLESPACE DSNDB06.SYSPLAN  TABLE(ALL) INDEX(ALL)