CICS performance is about getting transactions to complete quickly and reliably under load. This page covers how response time is measured, how to diagnose poor response time using a layered approach, and how system and application tuning and monitoring (including CMF) help you improve it.
Imagine a bank with one teller. If every customer takes a long time at the window, the line grows and everyone waits—that’s slow response time. If the teller is fast but keeps leaving to get papers from the back (I/O), everyone still waits—that’s suspend time. Making the bank perform better means making the teller faster (less work per customer), giving them more help (more CPU), or reducing how often they have to leave (less I/O and waiting). CICS performance is the same: we measure how long each "customer" (transaction) takes and why it’s waiting, then we fix the bottlenecks.
Response time is the time from when a user or system sends a request until the response is complete. For CICS, that usually means from transaction start to return to the terminal (or API). Two main components are processor time (CPU used by the task) and suspend time (time the task was not running—waiting for I/O, DB2, locks, or other resources). High response time can be due to high CPU (pathlength or load), high suspend time (I/O or contention), or both. CMF (CICS Monitoring Facility) records both and breaks suspend time into categories so you can see whether file I/O, DB2, or lock waits dominate.
IBM recommends a hierarchical approach to finding the cause of poor response time. You start with system-wide issues, then narrow to load, then to specific transactions, then to specific terminals or users.
| Layer | Focus | Typical actions |
|---|---|---|
| Level 1 – All transactions | System-wide. | Reduce paging (working set or real storage), application errors, resource contention. |
| Level 2 – Medium/high load | Throughput and capacity. | Reduce pathlength, add CPU, reorganize datasets, reduce data transfer, buffers, CICS limits. |
| Level 3 – Specific transactions | Single transaction or group. | Redesign/tune application, data placement, enqueue logic. |
| Level 4 – Specific terminals | User or terminal. | Network load, operator behavior, terminal definitions. |
At Level 1, high paging or application errors can slow everything. Fix storage or address abends first. At Level 2, under medium or high load, look at pathlength, CPU capacity, dataset placement, buffer and limit settings. At Level 3, one or a few transactions are slow; tune those programs, their data access, and enqueue usage. At Level 4, a single terminal or user is slow; check network and terminal definitions and how the user is driving the transaction.
System tuning involves CICS system initialization parameters (SIT) and resource definitions. For example, interval control and timer settings can be adjusted to reduce CPU overhead without hurting response time. Storage and limit parameters (e.g. region size, task limits, file limits) affect how many tasks can run and how much they can do before contending. Buffer and pool sizes affect I/O efficiency. Reorganizing datasets and placing heavily used files on faster storage can reduce I/O wait. These changes apply to the whole CICS region or system.
Application tuning targets the code and data access patterns of transactions. Goals are to reduce pathlength (fewer instructions, fewer calls) and to reduce wait time (fewer or faster I/O and DB2 calls, shorter or fewer enqueues). Use CMF or Performance Analyzer to find transactions and programs that consume the most CPU or have the highest suspend time. Then optimize those programs: avoid unnecessary loops, reduce file and DB2 round-trips, use efficient data structures, and hold locks for the minimum time necessary. This work is more labor-intensive than system parameter changes but often yields large gains for specific workloads.
CICS Monitoring Facility (CMF) collects detailed performance data and writes it to SMF. Performance class records include transaction timing: processor time, elapsed time, and suspend time. Suspend time is broken down into wait types such as file I/O wait (FCIOWTT), DB2 connection and ready-queue wait (DB2CONWT, DB2RDYQW), and lock manager wait. By analyzing these fields you can see whether a transaction is slow because of CPU, file I/O, DB2, or locks. CICS Performance Analyzer and other tools read CMF SMF data and produce reports and trends for capacity planning and tuning.
1. What does high transaction suspend time usually indicate?
2. Where is CICS performance data typically written?
3. Application tuning for CICS usually targets: