CICS Activity Monitoring

CICS activity monitoring is how you observe what CICS and your transactions are doing: how many transactions run, how long they take, which resources they use, and where bottlenecks or shortages occur. The CICS Monitoring Facility (CMF) collects this data and writes it to SMF 110 records for analysis. You can turn monitoring on or off dynamically and use CEMT or commands to control it. This page introduces CMF, the types of monitoring data (performance, transaction resource, exception, identity), SMF 110, and how monitoring is used for performance and capacity management.

Explain Like I'm Five: What Is Activity Monitoring?

Activity monitoring is like keeping a diary of what CICS does. Every time a transaction runs, CICS can write down: how long it took, how much work the processor did, and whether it had to wait for something (like a file or a queue). Later, people look at that diary (the SMF records) to see which transactions are slow, which resources are busy, and where the system might need more capacity. So monitoring does not change how your program runs; it just records what happened so you can improve things.

The CICS Monitoring Facility (CMF)

The CICS Monitoring Facility (CMF) is the component that gathers performance and activity data during online processing. It can be activated or deactivated while CICS is running, so you can enable it when you need data (e.g. for a performance test or capacity study) and turn it off to reduce overhead when you do not. CMF writes its data into SMF (System Management Facility) records, type 110. Those records are written to a dataset (or other target) that your site configures. Analysis tools and reporting products read SMF 110 to produce reports on transaction response times, resource usage, and exceptions.

CMF does not change how your application code runs; it only records metrics. There is some overhead when monitoring is on, so sites often enable it selectively (e.g. by transaction or time window) or for specific regions.

Classes of Monitoring Data

CMF collects data in several classes. Each class serves a different purpose and can be controlled separately in some configurations.

Performance class data gives you transaction-level metrics: processor time, elapsed time, and I/O wait. At least one performance record is produced per monitored transaction, so you can see how each transaction type is performing. Transaction resource class data adds detail about use of specific resources (e.g. distributed program link calls, file operations, temporary storage queues) per transaction. Exception class data records when transactions encounter resource shortages or waits—for example file string queuing or temporary storage full—so you can see what is constraining the system. Identity class data supports audit and security analysis by capturing identity propagation for eligible transactions. Performance and exception data are typically stored in SMF 110 subtype 1 records; CICS Statistics (system-level) uses subtype 2. Exact record layout and subtypes depend on the CICS version and configuration; see your CICS documentation.

SMF 110 Records

SMF (System Management Facility) is the z/OS facility for recording system and subsystem activity. CICS uses record type 110 for its monitoring data. Subtype 1 records usually hold CMF performance and exception class data: one or more records per transaction with timing and resource information. Subtype 2 is used for CICS Statistics, which provides system-level resource usage (e.g. overall CPU, storage, transaction counts). SMF 110 records are written to the SMF dataset or to a CICS-specific output according to your installation's setup. Reporting and analysis tools (e.g. IBM CICS Performance Analyzer, CA Mainframe, or custom programs) read these records to produce response-time reports, capacity reports, and exception reports.

Controlling Monitoring

You can turn CMF on or off and control which classes are collected in several ways. The CEMT (CICS Execution Monitor and Trace) transaction is often used by operators: CEMT I MONITOR (inquire) shows the current monitoring state, and CEMT S MONITOR (set) can change it. The CEMN transaction provides a menu-driven interface for monitoring control. From an application or from an EXEC CICS command, you can use INQUIRE MONITOR and SET MONITOR (syntax depends on your CICS version) to read or change monitoring settings. System initialization parameters can define the default state (e.g. monitoring on or off at startup) and which classes are active. Because monitoring has overhead, many sites enable it only when needed or for a subset of transactions or regions.

Using Monitoring Data

Monitoring data is used for performance analysis (which transactions are slow, where time is spent), capacity planning (how much load the system can handle, where resources are short), and troubleshooting (correlating slow or failed transactions with exception data). By reviewing SMF 110 (or reports built from it), you can identify transactions that need tuning, resources that need more capacity, or times of day when the system is under stress. Exception data helps you see when file or TS queuing, or other shortages, are affecting response times so you can add resources or change design.

Step-by-Step: Enabling Monitoring (Conceptual)

1. Confirm your site's CICS and SMF setup: where SMF 110 records are written and which CMF options are available.
2. Use CEMT I MONITOR (or equivalent) to see the current monitoring state. Use CEMT S MONITOR (or SET MONITOR) to turn on the monitoring classes you need (e.g. performance, exception).
3. Run the workload you want to measure. CMF will record data for monitored transactions.
4. After the test, use your analysis or reporting tool to process the SMF 110 dataset and review response times and exceptions. Turn off monitoring if it is no longer needed to reduce overhead.

Best Practices

• Enable monitoring when you need data for performance or capacity analysis; consider disabling it or limiting scope when overhead is a concern.
• Use exception class data to find resource shortages and waits that affect response time; address them with tuning or capacity.
• Correlate performance class data (response time, CPU) with exception data to see why transactions are slow.
• Keep SMF 110 data (or summarized reports) for trend analysis and capacity planning.

Test Your Knowledge