Some Things You Might Not Know About VSAM SMF Type 64 Records

(Originally posted 2012-09-24.)

This was originally going to be a different post about VSAM’s SMF 64 record, based on a customer situation. But it’s morphed into something else: A round up of "recent" enhancements to the SMF 64 record.

"Recent" is a nice euphemism: Some of these enhancements are 15 years old. 🙂 But let’s start the story at (or at any rate nearer to) the beginning…

Back in the early 1990’s I’d written the kernel of what would become SG24-2557 "Parallel Sysplex Batch Performance". Subsequently a few chums and I started putting together what would become "PMIO" – some tooling around which the Batch Window Tuning offering of the same name was built.

Other people in the team built the VSAM pieces – mostly out of DFSORT steps with assembler E15 and E35 exits, but also SLR as the database and REXX for reporting. Essentially the code marries up SMF 30-4 (step-end), 62 (VSAM OPEN) and 64 (VSAM CLOSE) records.

And it came to pass that I inherited all this code…

I’d not been closely involved with the code before so there was the usual re-engineering effort: Understanding the code, working on the comments and a little reformatting. It’s good code but quite fragile. So the "getting to know you" piece is essential. It’s the same as for any code adoption.

So what has all this got to do with "new" stuff in SMF 64?

If it ain’t broke don’t fix it" applies here – especially given what I said about fragility. So adding stuff that would give additional insight was what drove me to open up the code…

The first thing I added was new with z/OS Release 12: CA (Control Area) Reclaim. There are two fields in support of this line item: They tell me if you’re using CA Reclaim for a VSAM data set and if you’re getting benefit. (Thanks to Scott Drummond for reminding me of this – in the context of my customer’s problem.)

It’s not embarrassing that I’ve only just added this. But here’s one that IS: 🙂 In 1997 in OS/390 Release 4 DFSMS introduced System-Managed Buffering (SMB). This enables you to, for example, enable VSAM LSR (Local Shared Resources) and control it.

(LSR is a big deal as it allows you to change the VSAM buffering scheme to a better one than high-level languages tend to support. Previously one might’ve used the Batch LSR Subsystem to do this.)

So SMF 64 has lots of information on SMB, such as whether the JCL specifies what SMB’s buffering approach will be, whether it leaves it to SMB and what that approach will be (ACCBIAS). And now, only 15 years late, I capture this information: It rounds out what one can say about a VSAM data set’s performance rather nicely.

As for the customer situation: It turns out I mixed up CI (Control Interval) and CA (Control Area) split statistics (I do know the difference) and, wrongly concluded CA splits was a real issue. What I really had was a program-driven load (not a utility) which was causing a huge number of Index CI (write) I/Os. I think the simplest fix for this is to use SMB to turn on LSR buffering with Deferred Write.

It turns out this client is using neither SMB nor CA Reclaim. But if you get to send me your data I will now spot how you’re using these – assuming it’s relevant to the overall story. And we’ll see how well it’s working for you.