MVS and DASD: improving performance

Tuning CICS® for virtual storage under MVS™ depends on the following main elements:

Because tuning is a top-down activity, you should already have made a vigorous effort to tune MVS before tuning CICS. Your main effort to reduce virtual storage constraint and to get relief should be concentrated on reducing the life of the various individual transactions; in other words, shortening task life.

The installation of a faster processor can cause the current instructions to be executed faster and, therefore, reduce task life (internal response time), because more transactions can be processed in the same period of time. Installing faster DASD can reduce the time spent waiting for I/O completion, and this shorter wait time for paging operations, data set index retrieval, or data set buffer retrieval can also reduce task life in the processor.

Additional real storage, if page-ins are frequently occurring (if there are more than 5 to 10 page-ins per second, CICS performance is affected), can reduce waits for the paging subsystem.

MVS provides storage isolation for an MVS performance group, which allows you to reserve a specific range of real storage for the CICS address space and to control the page-rates for that address space based on the task control block (TCB) time absorbed by the CICS address space during execution.

You can isolate CICS data on DASD drives, strings, and channels to minimize the I/O contention suffered by CICS from other DASD activity in the system. Few CICS online systems generate enough I/O activity to affect the performance of CICS seriously if DASD is isolated in this manner.

So far (except when describing storage isolation and DASD sharing), we have concentrated on CICS systems that run a stand-alone single CICS address space. The sizes of all MVS address spaces are defined by the common requirements of the largest subsystem. If you want to combine the workload from two or more processors onto an MVS image, you must be aware of the virtual storage requirements of each of the subsystems that are to execute on the single-image ESA processor. (For an overall description of ESA virtual storage, see Appendix F. MVS and CICS virtual storage.) Review the virtual storage effects of combining the following kinds of workload on a single-image MVS system:

  1. CICS and a large number (100 or more) of TSO users
  2. CICS and a large IMS™ system
  3. CICS and 5000 to 7500 VTAM LUs.

By its nature, CICS requires a large private region that may not be available when the large system’s common requirements of these other subsystems are satisfied. If, after tuning the operating system, VTAM, VSAM, and CICS, you find that your address space requirements still exceed that available, you can split CICS using one of three options:

  1. Multiregion option (MRO)
  2. Intersystem communication (ISC)
  3. Multiple independent address spaces.

Adding large new applications or making major increases in the size of your VTAM network places large demands on virtual storage, and you must analyze them before implementing them in a production system. Careful analysis and system specification can avoid performance problems arising from the addition of new applications in a virtual-storage-constrained environment. If you have not made the necessary preparations, you usually become aware of problems associated with severe stress only after you have attempted to implement the large application or major change in your production system. Some of these symptoms are:

The rest of this section covers the following techniques that you can use to improve the performance of CICS under MVS:

Related tasks
Reducing MVS common system area requirements
Splitting online systems to improve availability
Making CICS nonswappable
Increasing the CICS region size
Using job initiators
Tuning the region exit interval (ICV)
Using LLA (MVS library lookaside)
DASD tuning

Related reference
MVS system data sets used by CICS
Setting up the MVS environment for CICS
[[ Contents Previous Page | Next Page Index ]]