How do I monitor CICS transaction response times?

CICS captures per-transaction performance data in SMF (System Management Facilities) Type 110 records — specifically subtype 1 (transaction data) and subtype 2 (performance class records). These records include elapsed time, CPU time, I/O counts, DB2 thread wait time, and CICS suspend time broken down by component. Tools like IBM CICS Performance Analyzer (CICS PA) or IBM Omegamon for CICS transform raw SMF 110 records into readable reports. At runtime, CEMT INQUIRE TASK shows active tasks and their elapsed time.

What are the most common causes of slow CICS transaction response times?

The main causes are: (1) DB2 thread wait — tasks waiting for a DB2 thread because THREADLIMIT in DB2ENTRY is too low; (2) Lock contention — tasks waiting for VSAM or DB2 locks held by other tasks; (3) CICS dispatcher wait — too many active tasks competing for the limited number of CICS TCBs; (4) Storage shortage — DSA running low, causing GETMAIN waits; (5) Expensive SQL — full table scans or missing indexes in DB2 queries; (6) File strings shortage — VSAM strings exhausted on a FILE definition.

What is the CICS Statistics transaction and what does it produce?

CICS collects statistics at configurable intervals (default every 30 minutes) and at CICS shutdown. These statistics cover DSA storage utilisation, task counts, transaction counts, program load counts, file access counts, DB2 thread allocations, TS queue statistics, and much more. CICS writes statistics to SMF Type 110 subtype 2 records. The CICS-supplied DFHSTUP batch program formats raw statistics records into readable reports. IBM CICS PA provides more sophisticated statistics analysis with trend reporting and threshold alerting.

How do I diagnose a CICS storage shortage (A2xx ABEND)?

First, identify which DSA sub-area is short using CEMT INQUIRE DSAS — look at the current size vs maximum size for CDSA, UDSA, ECDSA, and EUDSA. Then check if the shortage is caused by: too many concurrent tasks (reduce MAXTASKS or fix the workload peak), very large WORKING-STORAGE programs (recompile with DATA(31) to move storage above the 16 MB line), or SHARED GETMAIN memory leaks (audit application programs for GETMAIN SHARED without corresponding FREEMAIN). Short-term fix: increase the CICS DSA size parameters in the SIT. Long-term fix: address the root cause.

CICS Monitoring and Performance Tuning: Complete Guide for 2026

Introduction: Why CICS Performance Monitoring Is Critical

A CICS region serving 5,000 concurrent users must complete transactions in under 2 seconds to maintain acceptable service quality. When response times degrade, the cause could be anywhere: a new DB2 index was dropped, a runaway transaction is locking rows, the DSA is full, or a code change introduced an expensive SQL query. Without monitoring data, diagnosing performance problems is guesswork. With the right data, problems are solved in minutes.

This guide covers the full CICS monitoring toolkit — from real-time task management with CEMT to SMF Type 110 record analysis with CICS PA — and the most common performance problems and their solutions.

CICS Statistics: The Performance Baseline

CICS automatically collects statistics on resource usage at configurable intervals and at shutdown. These statistics are written to SMF (System Management Facilities) records as Type 110 subtype 2 records.

Key statistics categories:

Category	What It Tells You
Task manager statistics	Peak active tasks, task wait counts, MAXTASKS hits
Program manager statistics	Program loads, reloads, resident program storage used
DSA statistics	Peak storage usage per DSA sub-area
File control statistics	Read/write counts, NOTFND count, lock wait count
DB2 statistics	Thread allocations, peak active threads, thread waits
TS queue statistics	Queue count, peak item count, main vs auxiliary usage
TD queue statistics	Write count, ATI triggers fired

Format raw statistics with the DFHSTUP batch utility:

jcl

//DFHSTUP  EXEC PGM=DFHSTUP,REGION=0M
//STEPLIB  DD DSN=CICSTS56.CICS.SDFHLOAD,DISP=SHR
//DFHAUXT  DD DSN=your.SMF.DAILY.G0001V00,DISP=SHR
//DFHPRINT DD SYSOUT=*
//SYSIN    DD *
  DATE 20260421
  TIME 0000,2359
  TYPESTAT
/*

SMF Type 110 Records: Transaction-Level Data

For per-transaction performance data, CICS writes SMF Type 110 Subtype 1 records (performance class data). Each record covers one task and includes:

Elapsed time: Total time from task start to end
CPU time: CPU consumption by this task
Suspend time: Time the task spent waiting (for I/O, locks, DB2 threads)
DB2 wait time: Time waiting for a DB2 thread to become available
File I/O counts: Number of READ, WRITE, REWRITE, DELETE operations
ABEND code: Set if the task ABENDed
Terminal ID and transaction ID: Who ran what

CICS PA (Performance Analyzer) or IBM Omegamon for CICS DBMS are the standard tools for processing these records into transaction reports, pivot tables, and response time trend charts.

Using raw SMF data with a batch report program:

jcl

//CICSPARF EXEC PGM=DFHMNDUP,REGION=0M
//STEPLIB  DD DSN=CICSTS56.CICS.SDFHLOAD,DISP=SHR
//DFHAUXT  DD DSN=your.CICS.SMF.DAILY,DISP=SHR
//SYSPRINT DD SYSOUT=*
//SYSIN    DD *
  OUTDD(PERF,TYPE(110),SUBTYPE(1))
  SELECT TRAN(EMPI,ORDR,INVQ)
/*

Real-Time Monitoring with CEMT

CEMT provides real-time visibility into the running CICS region without any batch processing.

Task Monitoring

text

*── List all active tasks with elapsed time ──────────────────────
CEMT INQUIRE TASK ALL

*── Find tasks waiting for specific resources ────────────────────
CEMT INQUIRE TASK SUSPENDVALUE(FILE)

*── Drill into a specific task ───────────────────────────────────
CEMT INQUIRE TASK(00143)

Task display shows: task number, transaction ID, terminal ID, program, task state (RUNNING, SUSPENDED, DISPATCHED), elapsed time, and suspend reason.

DSA Storage Monitoring

text

*── Check DSA utilisation ────────────────────────────────────────
CEMT INQUIRE DSAS

*── Output shows:
*── CDSA  : Current=  2MB  Peak=  4MB  Max= 8MB   (50% peak)
*── UDSA  : Current= 12MB  Peak= 18MB  Max=20MB   (90% peak\!) <-- WARNING
*── ECDSA : Current= 45MB  Peak= 80MB  Max=200MB  (40% peak)
*── EUDSA : Current= 80MB  Peak=120MB  Max=512MB  (23% peak)

If UDSA peak is consistently above 80% of maximum, DSA tuning is needed.

DB2 Thread Monitoring

text

*── Check DB2 thread pool status ─────────────────────────────────
CEMT INQUIRE DB2ENTRY(EMPIENTR)

*── Shows: CURRENTACTIVE(12) THREADLIMIT(20) THREADWAIT(YES)
*── If CURRENTACTIVE frequently equals THREADLIMIT, increase limit

File Status Monitoring

text

*── Check all file statuses ──────────────────────────────────────
CEMT INQUIRE FILE ALL

*── Look for DISABLED or CLOSED files that should be open
*── STRINGS value shows current vs maximum concurrent access strings

Common Performance Problems and Solutions

Problem 1: High DB2 Thread Wait Time

Symptom: SMF 110 records show high DBTHR (DB2 thread wait) time. CEMT INQUIRE DB2ENTRY shows CURRENTACTIVE frequently at THREADLIMIT.

Diagnosis:

text

CEMT INQUIRE DB2ENTRY(EMPIENTR)
*── CURRENTACTIVE: 20  THREADLIMIT: 20  → Always at limit\!

Solution: Increase THREADLIMIT in the DB2ENTRY definition:

text

CEDA ALTER DB2ENTRY(EMPIENTR) GROUP(MYDB2) THREADLIMIT(40)
CEDA INSTALL DB2ENTRY(EMPIENTR) GROUP(MYDB2)

Also investigate the SQL being executed — long-running queries hold threads and reduce effective throughput.

Problem 2: VSAM File Strings Exhaustion

Symptom: File control statistics show high lock wait counts. Transactions are slow on FILE operations.

Solution: Increase the STRINGS parameter on the FILE definition:

text

CEDA ALTER FILE(EMPFILE) GROUP(MYAPP) STRINGS(10)
CEDA INSTALL FILE(EMPFILE) GROUP(MYAPP)

STRINGS controls how many concurrent VSAM operations can be active simultaneously. Too few strings cause serialisation.

Problem 3: MAXTASKS Reached — Task Queueing

Symptom: CICS statistics show MAXTASKS hits. New tasks are queued rather than started immediately. Response times rise linearly with load.

Diagnosis: Check SIT parameter MAXTASKS. Monitor with statistics — Task manager statistics show peak active tasks and MAXTASKS hit count.

Solution: Increase MAXTASKS in the SIT (requires CICS restart) or reduce the workload. Before increasing MAXTASKS, verify the z/OS region has sufficient virtual storage — more tasks means more storage.

Problem 4: Runaway Task (AICA ABEND)

Symptom: One transaction is consuming excessive CPU, driving up LPAR utilisation. CICS region appears to slow down for all users.

Diagnosis:

text

CEMT INQUIRE TASK ALL
*── Find tasks with very high elapsed time and RUNNING state
*── Task 00289: EMPI ELAPSED=00:45:23 STATE=RUNNING

Solution:

text

CEMT SET TASK(00289) FORCEPURGE

Then investigate the program code for infinite loops. Check CICS statistics for the AICA ABEND count — repeated AICA on the same transaction indicates a code defect.

Problem 5: Storage Shortage (A20D — EUDSA)

Symptom: A20D ABENDs appearing in CICS job log. Some tasks failing to start.

Diagnosis:

text

CEMT INQUIRE DSAS
*── EUDSA: Current=490MB Peak=510MB Max=512MB → FULL

Solutions:

Short-term: Increase EUDSA maximum in SIT (EDSASZE parameter), recycle CICS
Medium-term: Identify which programs have large WORKING-STORAGE — compile with DATA(31) if not already done
Long-term: Audit for GETMAIN SHARED leaks (programs allocating shared storage without FREEMAIN)

CICS Explorer and IBM Tools

IBM CICS Explorer

CICS Explorer is an Eclipse-based GUI tool for CICS administration and monitoring. Key capabilities:

Visual CSD management (define, install, alter resources without CEDA syntax)
Real-time task and resource monitoring dashboards
Bundle deployment for CICS TS 5.1+ application bundles
Integration with IBM z/OS Connect EE for API management

IBM CICS Performance Analyzer (CICS PA)

CICS PA processes SMF 110 records and produces formatted reports:

Transaction summary reports (average response time, CPU, I/O by TRANSID)
Exception reports (transactions exceeding thresholds)
Trend analysis (response time over time periods)
Resource utilisation reports (DSA, threads, files)

IBM Omegamon for CICS

Omegamon provides real-time dashboards, threshold alerting, and historical trending for CICS regions. It is the standard tool in large mainframe shops for continuous CICS monitoring, capacity planning, and SLA compliance reporting.

CICS Monitoring Best Practices Checklist

Track these metrics daily in production:

Peak EUDSA/UDSA utilisation (alert at 80%)
Peak DB2 thread utilisation per DB2ENTRY (alert at 80%)
Average transaction response time by TRANSID (alert on > 2-sigma deviation)
ABEND count by ABEND code (ASRA, AICA, AEY9 require immediate investigation)
MAXTASKS hit frequency (alert if non-zero)
File strings utilisation for high-volume files (alert at 80%)

Key Takeaways

CICS monitoring is a continuous discipline that combines real-time observation (CEMT), statistics collection (SMF 110 records), and trend analysis (CICS PA, Omegamon). The most common performance problems — DB2 thread exhaustion, VSAM string shortage, MAXTASKS queueing, and DSA storage pressure — all have clear diagnostic signatures and straightforward remediation steps. Build a monitoring baseline on day one of a production deployment: know your normal response times, thread utilisation, and storage headroom so that deviations are immediately visible.

For career preparation and interview readiness, complete the CICS journey with CICS Interview Questions. For the full course, visit the CICS Mastery Course.