opinion: Why All Mainframe Technical Groups Need SMF

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

LongEx Quarterly is a quarterly eZine produced by Longpela Expertise. It provides Mainframe articles for management and technical experts. It is published every November, February, May and August.

The opinions in this article are solely those of the author, and do not necessarily represent the opinions of any other person or organisation. All trademarks, trade names, service marks and logos referenced in these articles belong to their respective companies.

Although Longpela Expertise may be paid by organisations reprinting our articles, all articles are independent. Longpela Expertise has not been paid money by any vendor or company to write any articles appearing in our e-zine.