Chapter 17 Key Takeaways

The Core Principle

MAXT is a symptom, not a cause. When a CICS region hits MAXT, the instinct to raise MXT is almost always wrong. The right question is not "what should MXT be?" but "why are tasks accumulating?" The answer is in the wait-time breakdown — dispatcher congestion, DB2 delays, MRO latency, storage pressure. Fix the root cause, and the MAXT disappears. Raise MXT without diagnosis, and you convert a MAXT event into an SOS event.

Task Management and Dispatching (Section 17.2)

  1. The QR TCB is cooperative, not preemptive. A task running on the QR TCB runs until it voluntarily yields by issuing a CICS command. A CPU-bound loop with no CICS commands monopolizes the QR TCB and starves every other task in the region. This is the single most destructive application-level bug in CICS.

  2. THREADSAFE is the most impactful optimization in modern CICS. Converting high-volume programs from QUASIRENT to THREADSAFE moves DB2 calls from the QR TCB to L8 open TCBs. The QR TCB is freed to dispatch other tasks. CNB achieved a 40% reduction in QR TCB busy time; SecureFirst went from 82% to 31%. If you do only one thing from this chapter, convert your top 10 programs to THREADSAFE.

  3. Task priority only matters when there is queuing. In a healthy region with idle QR time, every ready task is dispatched immediately. Priority becomes critical when the region is saturated — it determines which transactions are protected and which are sacrificed.

  4. CMDT gates DB2 thread consumption. Without CMDT, every concurrent task could hold a DB2 thread, overwhelming DB2. Size CMDT using peak (not average) TPS to account for traffic bursts.

Storage Architecture (Section 17.3)

  1. EUDSA is the critical storage domain. Each task gets its own copy of working storage in EUDSA. A high-volume program with large working storage can consume hundreds of megabytes. Reducing working storage in the top 10 programs is often more effective than increasing EDSALIM.

  2. Size EDSALIM to measured peak plus 30% headroom. Not more, not less. Excessive EDSALIM masks storage leaks and increases working set size. Insufficient EDSALIM causes SOS during predictable peak periods.

  3. SOS is worse than MAXT. MAXT stops new tasks from starting. SOS degrades all tasks — running, ready, and waiting — because CICS enters storage compression mode and may begin purging tasks. SOS is a Severity 1 event.

  4. MXT must not exceed the storage-bounded limit. Calculate both the task-based MXT and the storage-bounded MXT. Use the task-based value, but ensure the storage-bounded value exceeds it by a comfortable margin. If they are close, you are one spike away from SOS.

Transaction Classes (Section 17.4)

  1. TRANCLASS prevents workload starvation. Without transaction classes, any workload can consume all available tasks. With transaction classes, critical transactions are protected even during bulk workload surges.

  2. TRANCLASS waits are often healthy. A TRANCLASS wait for a bulk class means the class limit is protecting higher-priority work — exactly as designed. Only investigate if the throttled class is missing its SLA.

  3. Dynamic TRANCLASS adjustment is your throttle during incidents. Reducing a TRANCLASS MAXACTIVE in real time can protect a region without recycling or raising MXT. Keep a throttle playbook for each incident type.

Performance Monitoring (Section 17.5)

  1. SMF 110 Type 1 records are the gold standard for CICS performance analysis. The wait-time breakdown in each record immediately identifies whether a problem is in CICS (dispatcher), DB2, VSAM, or MRO. Collect them continuously.

  2. Combine top-down and bottom-up monitoring. CMF/SMF 110 provides the aggregate view (what is slow). Self-aware transaction instrumentation provides the individual view (why it is slow). Neither alone is sufficient.

  3. CEDF and auxiliary trace are deep-dive tools, not continuous monitors. Use them when SMF 110 points you to a specific transaction or component. Always filter auxiliary trace — unfiltered trace generates gigabytes per hour.

  4. Trend analysis prevents incidents. A gradual increase in QR TCB busy, a slow creep in EUDSA, a rising TRANCLASS wait count — these are leading indicators. Catch them in weekly trend reviews, and you fix problems before they become incidents.

Diagnosing Production Problems (Section 17.6)

  1. The wait-time breakdown is the first diagnostic step. For any response time degradation, the first question is: where is the time going? Dispatcher, DB2, file I/O, or MRO? The answer determines the entire diagnostic path.

  2. Storage leaks manifest as gradually rising EUDSA with stable task counts. If EUDSA grows while task count does not, a program is allocating storage without freeing it. Identify the program through storage attribution in CICS statistics.

  3. Post-deployment performance regression has a specific checklist. Compare working storage size, THREADSAFE attribute, DB2 call count, and program load success between old and new versions. The developer's "small change" may have large performance implications.

Capacity Planning (Section 17.7)

  1. The bottleneck sequence is predictable. In most CICS environments: CMDT exhausts first, then MXT, then EUDSA, then QR TCB, then CPU. Knowing the sequence tells you what to monitor and what to plan for.

  2. Plan horizontal scaling 6 months before you need it. A new AOR takes weeks to deploy through change management. If your capacity projections show MXT saturation in 3 years, plan the new AOR for Year 2.

  3. Include failure scenarios in capacity plans. If one AOR fails and its load shifts to the surviving AOR, the surviving AOR must have enough MXT headroom to absorb the load. This connects capacity planning to high availability — they are the same discipline.

  4. WLM misconfiguration is invisible from inside CICS. A region in the wrong WLM service class has normal CICS metrics but slow response times. Always check WLM service class assignment when CICS-level diagnostics show no anomalies.

The Big Picture

CICS performance tuning is not a collection of parameter changes. It is a discipline that requires understanding the entire system — from the z/OS dispatcher through the CICS dispatcher through the DB2 thread pool through the VSAM buffer pool through the network to the end user. Every parameter exists for a reason, every default is wrong for your workload, and every change has consequences that ripple through the system.

The practitioners who excel at CICS performance work share three traits: they measure before they tune, they understand the full stack from hardware to application code, and they never accept "just raise the limit" as an answer.