How monitoring and statistics data turn performance symptoms into evidence
When something slows down in a CICS environment, the conversation often starts with a phrase every systems programmer (sysprog) has heard before:
“CICS feels stuck.”
The problem with that sentence is not that it’s wrong. The problem is that it’s not yet a diagnosis.
CICS may be consuming CPU, waiting on files, being throttled by transaction classes, waiting on Db2 or MQ, being blocked by ENQs, or simply processing more workload than usual. From the outside, much of this looks the same at first. Response times go up.
The business starts asking questions. Operations looks at the region. And somewhere in between, the search for the real cause begins.
“Poor response time is only a symptom. SMF 110 helps identify where time is actually being spent.”
That is where SMF record type 110 becomes interesting. It is one of the most important data sources if you want not only to run CICS, but to really understand it. CICS writes different SMF 110 subtypes, including records for monitoring and statistics. Especially relevant are SMF 110 subtype 1 for CICS monitoring and SMF 110 subtype 2 for CICS statistics.
Why SMF 110 Matters
Perhaps you’re wondering why SMF 110 matters. In essence, SMF 110 provides the monitoring and statistics data that help turn performance symptoms into evidence. Rather than relying on assumptions, systems programmers can use SMF 110 records to understand where time is being spent, which resources are involved, and how workloads behave over time.
SMF 110 helps answer questions such as:
- Which transactions consume the most CPU?
- Where are response-time delays occurring?
- Are waits caused by CICS, Db2, MQ, files, or something else?
- Which resources are under the greatest load?
- Has workload behavior changed over time?
Without SMF 110, troubleshooting often relies on assumptions. With it, performance analysis becomes evidence-based.
From Gut Feelings to Facts
The real value of SMF 110 is that it turns gut feeling into measurable facts.
Poor response time is only a symptom. It becomes useful only when it can be broken down. How much time was actually spent on CPU? How long was the task dispatched? How much time was lost in wait states? Were there file I/O waits, RMI components, ENQ delays, or delays caused by MXT or transaction classes?
SMF 110 turns gut feeling into measurable facts.
These are exactly the kinds of questions that separate reaction from analysis. SMF 110 helps treat CICS performance not as one big black box, but as a combination of CPU, dispatching, wait time, resource usage, and transaction behavior.
That is especially valuable for systems programmers. They do not only need to know that a region is running. They need to understand how it is running. They need to see whether a problem comes from the application, the region, a connected subsystem, or a configuration setting that suddenly matters under load.
SMF 110 at a Glance
| Record Type | Purpose |
|---|---|
| SMF 110 Subtype 1 | Transaction and task monitoring |
| SMF 110 Subtype 2 | Region and resource statistics |
| DFH$MOLS | Analyze monitoring data |
| DFHSTUP | Analyze statistics data |
Don't miss these other great articles
Monitoring and Statistics: Two Views of the Same Reality
With SMF 110, one distinction is particularly useful: knowing the difference in Monitoring Data, also known as subtype one, and Statistics Data, or subtype two.
Monitoring Data (Subtype 1) — Transactions and Tasks
Monitoring data, especially SMF 110 subtype 1, provides the transaction and task view. It shows what individual transactions are doing, which resources they are using, and where time is being spent or lost.
This includes information about:
- Response time
- CPU consumption
- Dispatching
- Suspend times
- Resource usage
- Other transaction-related metrics
Statistics Data (Subtype 2) — Region and Resources
Statistics data, especially SMF 110 subtype 2, provide the region and resource view. This is more about the big picture:
- Usage
- Trends
- Utilization
- Resource behavior
- Operational state
Together, they create a useful combination. Monitoring explains what individual transactions did. Statistics show how the region behaved overall.
Two Views of CICS Performance
| Monitoring (Subtype 1) | Statistics (Subtype 2) |
|---|---|
| Individual transactions | Entire region |
| Response times | Utilization trends |
| CPU per task | Resource activity |
| Wait analysis | Capacity analysis |
| “What happened?” | “What’s happening overall?” |
In practice, that combination matters. A single slow transaction may point to an application issue. Many slow transactions at the same time may indicate a regional or systemic problem. And a slowly growing trend over days or weeks may not be an incident at all, but rather a capacity issue.
SMF 110 Makes CICS More Transparent
CICS remains a high-performance, stable, and business-critical transaction engine in many organizations. At the same time, CICS can be difficult for newer teams to understand. Many environments have grown over the years and include:
- 3270 transactions
- Batch integrations
- IPIC connections
- Web services
- Db2
- MQ
- VSAM
- External programs
- Modern API access
None of these components operate in isolation. SMF 110 can help structure that complexity. Not because the record automatically provides all the answers, but because it enables fact-based questions.
Specifically, SMF 110 supports questions such as:
- Which transactions consume the most CPU?
- Which transactions have the longest response times?
- Which wait times occur repeatedly?
- Which resources are used most heavily?
- Which region behaves differently from comparable regions?
- Did behavior change after a release, a parameter change, or a workload shift?
That is transparency in the best sense: CICS does not magically become simple, but the conversation becomes fact-based.
It Does Not Always Have to Start with the Big Tool
When people think about SMF data, they often think about professional reporting, monitoring, or observability solutions. These tools absolutely have their place, especially in larger environments, historical analysis, visualization, automation, and SLA-driven operations.
But the starting point does not always have to be big.
IBM already provides tools and examples with CICS that allow first-level analysis.
DFHSTUP
DFHSTUP processes CICS statistics records, meaning SMF 110 subtype 2. This allows statistics data to be analyzed without immediately building a larger tooling landscape.
Questions it can help answer include:
- Which statistics records were written?
- What does workload activity look like over a given interval?
- How has resource usage changed over time?
DFH$MOLS
For monitoring data, there is also DFH$MOLS. This sample monitoring data print program processes CICS monitoring data from SMF and can serve as an example or starting point for custom analysis.
Questions it can help answer include:
- Which monitoring records stand out?
- Which transactions should be examined more closely?
- What data is actually available?
This is not a replacement for a mature performance and observability platform. But it is a very good starting point. For smaller analyses, initial plausibility checks, or focused questions, a pragmatic evaluation is sometimes enough.
With z/OS utilities, JCL, DFSORT, REXX, or simple post-processing, organizations can often validate or eliminate performance hypotheses before more sophisticated analysis becomes necessary.
Transparency does not begin with the perfect tool. It begins with the willingness to use the data that is already there.
Commercial Tools for Deeper Analysis
Organizations that require broader visibility often use dedicated tooling.
- IBM CICS Performance Analyzer for z/OS for reporting and historical analysis
- IBM Z OMEGAMON for CICS for operational monitoring
- IBM Z Common Data Provider to stream SMF data into analytics platforms
- IBM Z Operational Log and Data Analytics for centralized operational analysis
- IBM Z IntelliMagic Vision for health insights, trend analysis, and anomaly detection
These tools help transform raw SMF data into dashboards, reports, alerts, and long-term performance insights.
The Important Point: Data Quality and Context
With all the enthusiasm around analysis and visualization, one point should not be overlooked: SMF 110 is powerful, and it is not trivial.
CICS monitoring records require dictionary information to correctly interpret the fields they contain. This dictionary information describes which fields exist in the performance data records and how they should be read.
That is more than a technical footnote.
Anyone who processes SMF 110 incorrectly can draw the wrong conclusions.
Anyone who processes SMF 110 incorrectly can draw the wrong conclusions. Anyone who does not understand intervals properly may compare data that should not be compared. Anyone who looks only at averages may miss outliers. Anyone who looks only at individual transactions may miss regional bottlenecks.
That is why working with SMF 110 should always bring three things together:
- Clean data collection
- Correct technical interpretation
- Meaningful presentation
Only then does SMF 110 offer true transparency.
Why This Matters More Today
CICS has not disappeared. In many organizations, CICS remains the platform where business-critical transactions are processed reliably.
What has changed is the expectation of transparency.
In the past, it was often enough to review reports the next day or drill down when something went wrong. Today, CICS transactions are more often part of hybrid flows. They are connected to APIs, digital channels, customer portals, mobile applications, and distributed process chains. When performance issues appear there, nobody expects a purely technical explanation two days later.
That does not mean the mainframe has to give up its operational philosophy. Rather, it means that its data has to become easier to use. SMF 110 is one of the most important sources for that.
SMF 110 Is the Foundation of CICS Observability
Anyone who wants to understand CICS performance cannot ignore SMF 110.
The record does not simply show that something happened. It helps explain what happened, where time was spent, which resources were involved, and how system behavior changed over time.
Whether teams use DFHSTUP, DFH$MOLS, OMEGAMON, CICS Performance Analyzer, or a broader observability platform, the goal remains the same: turn assumptions into evidence.
Performance problems rarely begin with a lack of data. More often than not, they begin with a lack of visibility.CICS is often not opaque because there is no data. It appears opaque when that data is not used.
SMF 110 remains one of the most powerful tools available for changing that.









0 Comments