← Back to Blog

Runtime Evidence as the Right Starting Point – SMF, CICS, and Job Logs

The mainframe generates more runtime evidence than almost any other platform. Here is how to use it as the foundation for AI analysis.

One of the things that surprises developers coming from modern platforms when they first work with mainframe is how much the system records about itself.

Every program execution. Every dataset access. Every transaction. Every job step. Every operator message. Every performance interval. The mainframe captures it all, in structured records, with timestamps, resource consumption figures, and outcome codes.

This is not an accident. It is the product of sixty years of operational discipline in environments where downtime is measured in millions of dollars per hour and audit trails are legally required.

For AI analysis, this runtime evidence is more valuable than source code. It tells you what actually happened, not what the code says should happen. And on a system where the gap between those two things can be thirty years wide, that distinction matters enormously.

SMF records – the mainframe's operational history

SMF stands for System Management Facilities. It is z/OS's built-in instrumentation system, writing structured records to datasets that capture operational data across the entire system.

TYPE 30 – JOB/STEP/TASK ACCOUNTING. The most widely used SMF record type. Written at the end of every job step, it contains: the job name, step name, program executed, start and end times, CPU time consumed, I/O counts per dataset, return code, and system completion code if the step abended. From TYPE 30 records you can reconstruct exactly what ran, when, for how long, with what resources, and with what outcome. Across months of history, this tells you which programs are production-active and which have not executed in years.

TYPE 14/15 – DATASET ACCESS. Written when datasets are opened and closed. Contains the dataset name, volume, access type (input/output/update), and the job that accessed it. This is the raw material for dataset lineage analysis – understanding which jobs produce which datasets that which programs consume.

TYPE 42 – VSAM DATASET ACTIVITY. Detailed VSAM access statistics – records read, written, updated, deleted. For understanding how VSAM files are actually used versus how the code suggests they should be used.

TYPE 70-79 – RMF PERFORMANCE DATA. Written at configurable intervals by the Resource Measurement Facility. Contains CPU utilisation, paging rates, I/O rates, DASD response times, and other system-level metrics. The foundation for performance analysis and capacity planning.

TYPE 110 – CICS TRANSACTION DATA. Written by CICS for each completed transaction. Contains the transaction ID, terminal ID, response time, CPU time, DB2 calls made, file accesses, and outcome. The most detailed picture available of what CICS is actually doing.

CICS journals – online transaction evidence

CICS transaction journal. The complete record of every transaction that ran through a CICS region – what ran, when, how long it took, what it accessed. In a high-volume bank, this can be hundreds of millions of records per day, but it is the definitive answer to "which programs handle which transactions in production."

CICS exception data. Every CICS abend, every transaction that exceeded thresholds, every resource constraint that was hit. This is the starting point for diagnosing production problems – not the source code, but the system's own record of what went wrong.

CICS statistics. Interval statistics on CICS resource usage – program storage, file activity, DB2 thread usage, temporary storage. Used for capacity planning and identifying resource bottlenecks.

Job scheduler logs – dependency evidence

Modern mainframe shops use job schedulers to manage batch execution. These schedulers maintain logs of what ran, when, in what sequence, and what dependencies were satisfied before each job started.

This log data is critical for AI analysis because it contains the dependency graph that JCL alone does not provide. JCL tells you what a job does. The scheduler log tells you what must have completed successfully before this job ran, and what this job's completion enables downstream.

From scheduler logs you can reconstruct:

• The complete batch execution sequence for any business day
• Which jobs are on the critical path
• Which jobs have the most downstream dependencies
• Where failures cascade – which jobs fail when a specific predecessor fails

What runtime evidence answers that source code cannot

Which code is actually live. A large mainframe codebase typically contains programs that have not executed in years. Some were replaced by new programs and never deleted. Some are test programs that were never cleaned up. SMF TYPE 30 records can tell you – if a program does not appear in TYPE 30 data over a twelve-month period, it has not executed in production. That is the most reliable way to identify dead code.

Which code paths are critical. A program may have fifty different execution paths. In production, forty-five of them execute thousands of times per day. Five execute once a month at month-end. Two have never executed in the eighteen months of history available. This information changes how you approach analysis, modernisation, and testing.

What typically precedes a failure. When an abend occurs, the most useful diagnostic question is not "what does the code do" but "what was happening before this failed." SMF and CICS data provide the answer – what ran before this job, what datasets were written, what transactions preceded this one, what resource pressure existed at the time of failure.

Dataset lineage. Which jobs produce which datasets that which programs consume is the execution graph made concrete. SMF TYPE 14/15 records provide the raw data. From this you can answer: if this dataset is corrupted, which downstream jobs and transactions are affected? If this job fails, what data is missing from which systems?

Practical guidance – what to collect

For any AI analysis project on mainframe, collect this runtime evidence before touching source code:

With this data, AI analysis has something real to work with. Without it, any AI tool is reading source files and making inferences about a system it cannot observe.

Also in this series: Why Generic AI Tools Fail on Mainframe · Why Mainframe is Different · What AI Can and Cannot Do with COBOL