z/OS System Monitoring Facility (SMF)
At Longpela Expertise, we have a bit of a crush on z/OS SMF records. So, this month we're going to indulge this crush, and talk all about SMF.
In our first technical article, we show some of the things we can quickly find out using SMF type 30 records.
In our second technical article we take a look at some of the issues you can face when using SMF type 30 records.
Finally, in our opinion article David Stephens argues that SMF data should be available (and advertised) to all z/OS technical groups.
We hope you enjoy this issue.
technical: Ten Things I Can Find Out From SMF30
SMF type 30 records hold a bounty of information about address spaces: including started tasks, TSO sessions and batch jobs. Whenever I start working on an unfamiliar z/OS system, one of the first things I want to see are the SMF type 30 records: regardless of the goals of the project. So, let me tell you 10 things I can find out from these records.
technical: Five Issues With SMF30
In our partner article, we talk about how SMF 30 records are brilliant for finding out information about a z/OS system.
However, there are a few interesting issues when working with SMF30 records that can trap the unwary. Let's look at five of them.
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.