longpelaexpertise.com.au/ezine/EveryoneNeedsSMF.php?ezinemode=printfriend

LongEx Mainframe Quarterly - August 2023

In one site, I used SMF type 30 records to show them how many of their jobs were abending or ending with non-zero return codes. In another, I used SMF type 110 records to show application teams why their CICS transactions were running slow. In a third, I used SMF type 72 records to show them service classes with poor performance: their WLM goals were wrong, or they had a problem.

I can't remember the last time I was engaged at a site, and didn't use SMF records. Looking at CPU capacity or usage: I use SMF. Performance issues: SMF. Resilience issues: SMF. Even finding out things about a new system: SMF.

I've hunted down the person who deleted a dataset, and identified CICS programs that weren't being used. I've looked at IBM MQ buffer performance, and helped DBAs look for CPU hungry SQL statements. I've identified workloads that don't match WLM workload selection routines, CICS transactions that need to use more syncpoints, and long-running batch jobs that are at risk of running during the online day. In every case, SMF.

But here's the thing. In many sites, I deal with local staff that don't understand SMF, or don't have access to SMF. For example, one application group wrote their own program to report on their CICS transaction response times: they didn't know about SMF Type 110 records.

Traditionally, systems programmers have been responsible for SMF records. But today, I often meet systems programmers that aren't familiar, or aren't comfortable with, SMF records and getting information from them. They can't quickly interrogate SMF records to get the answers they need.

I often see sites where groups outside of the systems programming group don't even know that SMF records exist. They don't know what they can do, and so don't know to ask their friendly systems programmers for help.

There are a lot of nice tools that can help. From sophisticated products like EPS Pivotor and IntelliMagic Vision, to more traditional tools like IBM CICS Performance Analyzer and Broadcom MICS. Even if you're not that familiar with z/OS, it's not over: SMF Explorer and Zowe are ready to help.

So, the whole point of this soapbox rant is to say two things:

• Every systems programmer should know about SMF records and have the tools and talent to get information from them.
• Every site should make SMF records available to appropriate groups. This may be standard reports generated, tools to interrogate SMF records, or simply advertising the services of systems programmers to help.

SMF records are amazing. They shouldn't be hidden away.

David Stephens