Hi: The considerations for CI/CA splits varies with either on-line or batch processing. Here is some information from the CICS TS Performance Guide and VSAM Demystified manuals that may be useful. Free space provides a tool for deferring splits to occur. >From CICS TS 4.1 Performance Guide >From Pg 29 related to information in LISTCAT Whether and how often control interval (CI) or control area (CA) splits occur (splits should occur very rarely, especially in CA). >From Pg 112 related to reducing I/O operations Minimize CI/CA splits by: – Allocating ample free space (free space can be altered by key range during load) – Timely reorganizations of disk storage. >From Pg 124 related to CICS VSAM tuning considerations File control requests for NSR files are done asynchronously, however, and still cause the CICS main task or subtask to stop during a split.
>From Pg 152 related to specifying free space Other VSAM definition parameters Free space parameters need to be selected with care, and can help reduce the number of CI and CA splits. Where records are inserted all over a VSAM data set, it is appropriate to include free space in each CI. Where the inserts are clumped, free space in each CA is required. If all the inserts take place at just a few positions in the file, VSAM should be allowed to split the CA, and it is not necessary to specify any free space at all. >From Pg 160 related to the TCB subtasking (CO TCB) Effects of permitting VSAM subtasking The objective of subtasks is to increase the maximum throughput of a single CICS system on multiprocessors. However, the intertask communication increases total processor utilization. When I/O is done on subtasks, any extended response time which would cause the CICS region to stop, such as CI/CA splitting in NSR pools, causes only the additional TCB to stop. This may allow more throughput in a region that has very many CA splits in its file, but has to be assessed cautiously with regard to the extra overhead associated with using the subtask. ---------------------------------------------------------------------------- ----------------------------------------------------------------------- >From VSAM Demystified: >From Pg 124 related to I/Os associated with a CA split I/Os associated with CA splits These I/Os should be avoided. CA splits generate many I/O operations. CA splits occur in a KSDS or VRRDS along inclusions and increase the logical record size during an update. CA splits may be minimized by the use of CA free space. Refer to “Splits” on page 15. However, a CI splits is not a real performance problem because it needs less than five I/Os. >From Pg 57 related to Free Space Too little free space can result in an excessive number of CI and CA splits (depending on the key pattern of the records to be inserted), with consequences such as: The CA splits are resource consuming, due to the overhead (during the split), since approximately half of the CIs from the CA are moved to the end of the data set. CI and CA splits may also affect the sequential processing because the DASD controller, to better use the cache, only detects 3390/3380 tracks physical sequence. Splits make the logical sequence different from the physical sequence. >From Pg 131 related to lowering connect time Less free space in the CIs: The existence of a significant amount of free space in a CI, may increase the I/O connect time. This free space may be caused by an excess in the definition of the data set, or by CI and CA splits. Remember that any CI with a logical record is moved to storage in a sequential read. This is not true with totally free CIs, where no I/O operations are executed towards them. Pg 208 related to CA splits may increase free space CI/CA splits causing free space increase After CI and or CA splits the free space per CI (excluding the totally freed) tends to increase. In sequential read processing there is some impact on performance because more free bytes are moved to storage. Refer to 2.7.4, “I/O service time (connect) for VSAM data sets” on page 129. Regards, Gene ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
