Blogs

ACERCA DE ESTE BLOG

I'm a well-known mainframe performance guy, with almost 30 years of experience helping customers manage systems. I also dabble in lots of other technology. I've sought to widen the Performance role, incorporating aspects of infrastructural architecture.
I'm a world-famous podcaster and screencaster (albeit VERY thinly spread). :-)

Etiquetas

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

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.