CICS / WebSphere

Setting the Interval Control Values in CICS

2 Pages

CICS has three Interval Control Values (ICVs) specified in the System Initialization Table (SIT), via overrides or through the use of CEMT command, that can be used to set a new value. Setting these parameters correctly can help reduce system CPU overhead and improve resource usage. This especially applies to installations with many CICS regions. This article explores these parameters and offers recommendations on what values to use. The three parameters we’ll focus on are:

  • ICV is used to specify the maximum time CICS is to wait when there’s no work to do. (There’s no ready task to dispatch within CICS.time is given in milliseconds (ms); the default is 1,000 ms or 1 second.
  • ICV for Runaway Tasks (ICVR) is used to specify the maximum time that’s allotted to a task before the task has to return control to CICS or else be cancelled with a cancel code of AICA. The time is given in ms; the default time is 5,000 ms or 5 seconds.
  • ICV for Terminal Scan Delay (ICVTSD) is used to specify the time that’s to elapse before CICS deals with some terminal I/O activity. The time is given in ms; the default is 500 ms or half a second.

Let’s address the ICV parameter first. When CICS has no transaction ready to dispatch or work to do, CICS enters a wait state based on an Event Control Block (ECB) list that includes the ICV timer. Any interrupt that posts an ECB completion wakes CICS, even if the ICV timer ECB hasn’t completed. Traditional recommendations specify that the ICV can be used to protect the working set of the CICS region. Periods of low terminal or transaction activity can represent a problem for CICS if the system is under pressure for real storage. Setting the ICV to a low value such as 1,000 ms will wake up CICS more often to protect part of the nucleus. However, waking up CICS this often to find nothing to dispatch and to be placed into a wait state again can be a waste of CPU resources.

CICS requires considerable real storage to run. During normal execution, many CICS management programs, control blocks, and tables must be accessed, in addition to the user program and storage areas. So, waking CICS often as a result of a low ICV protects only a small portion of the total CICS code and its areas. In addition, due to increased real storage availability on modern processors, the need to protect a small amount of CICS storage may not be an effective trade-off against CPU cycles and comes at the expense of lower-priority regions. This is especially true with a period of low-transaction activity.

ICV, like other SIT parameters, tends to be “inherited,” meaning it was defined many years ago and is never adjusted. The conditions under which these parameters were set many years ago have changed. Faster CPUs, improved I/O devices, and more real storage availability are among the changes that have occurred. Yet, the original specification for these SIT parameters remains the same. In addition, the number of CICS regions has grown significantly. It’s not unusual to see a programmer test CICS, a model office or quality assurance CICS, and a production system combination in many installations. Often, an application can set up these types of CICS regions, resulting in even more CICS systems in a CPU complex. It’s not unusual to see more than 100 CICS systems in a z/OS or OS/390 installation. So having all these CICS systems, especially test and model office or quality CICS systems, with a low ICV amount may be questionable.

As an example, we changed the CICS statistics collection period from three hours to 10 minutes so we could get the information and quickly reset the statistics. We ran two tests, one with an ICV=1,000 (1 second) and one with an ICV=10,000 (10 seconds).

Figure 1 shows the results of the first test with an ICV of 1 second. The average length of the ICV interval for this test was 828 ms and the TCB CPU time was 1.9677 seconds. The figures include the transaction to capture the data in both examples.

Figure 2 reflects the second test when the ICV was set to 10 seconds. The results were an average ICV of 2,861 ms and the TCB CPU time was .9674 seconds. As in the first benchmark, the figures also include the transaction overhead used to capture the information. Increasing the ICV to 10 seconds represented a savings of one CPU second, or just more than 50 percent CPU overhead. The one-second difference over the measurement period of 10 minutes represented around .2 percent overhead of the overall CICS CPU used on this processor. This savings would represent a 1 percent CPU savings for every five CICS systems that have a low ICV value such as 1,000 ms on this system. A lower ICV value requires more CPU overhead.

As with all benchmarks, your mileage may vary. The number of instructions that are executed in CICS to handle an ICV interrupt would be about the same for each occurrence. So, the amount of CPU seconds saved would depend on the processor speed and the total number of CICS systems that would have a low timer value. However, the percent of extra CPU cycles required to handle a low ICV vs. a high ICV should be about the same. The same will apply for the ICVTSD benchmark.

Setting the ICV to a value between 5 to 10 seconds should reflect lower CPU overhead and would result in a positive factor for lower-priority regions. During normal prime-time execution, the system would probably respond to other interrupts (e.g., VSAM I/O) rather than to the ICV timer value, especially in busy systems.

2 Pages