What's In A Name?
MartinPacker 11000094DH Visits (11508)
This is the post I was going to write before the discussion that led to CICS VSAM Buffering arose. It's about getting more insight into how WLM is set up and performing than RMF Workload Activity Report data alone allows.
I recognise some of this can be done with the WLM policy in hand. But this is about an SMF-based approach. (The piece you can't do with SMF is discerning the WLM classification rules.) And the policy can't answer questions about how systems actually behave.
There are two distinct problems I've worked on solving (relatively) recently. I share the outline of my solution to each of these with you here.
The "What's In A Name?" in the title refers to the fact a Workload, Service Class or Report Class name is just a string of characters: Rhetorically it might be a "promise" but it's not a mechanistic guarantee. So - to me at least - it's worth knowing rather more.
Report And Service Class Relationships
SMF 72 Subtype 3 RMF Workload Activity Report data describes how Service Class Periods and Report Classes perform.
Type 30 Interval records (Subtypes 2 and 3) describe how address spaces perform.(Actually so do Subtypes 4 and 5, which are step-end and job-end records.) These records contain, amongst other things, WLM Workload, Service Class and Report Class names - for the address space. You can therefore use Type 30 to relate Workload and Service Class to Report Class. My code's done this for some time.
Type 30 does not apply to Service Classes that don't own address spaces. Two examples of this are DDF Transaction Service Classes and CICS Transaction Service Classes.
A related topic is which Service Classes are serving other Service Classes. For example CICS Region Services Classes and transaction Service Classes. Now this you can readily discern from SMF 72 alone. (And of course my code does that.)
What Work In A Service Class Is
(This piece relates equally to Report Classes.)
As I said, you can't tell much about what a WLM Service Class covers from Type 72. So, as well as the correlation described above, my code uses Type 30 to flesh out what a Service Class is for. The key to this is the Program Name. For example CICS regions have PGM=DFHSIP. So a Service Class with just PGM=DFHSIP address spaces is just a CICS Region Service Class. Simple enough. Some are more complicated than others - perhaps necessitating the 16-character program name field which, for Unix, includes the last portion of the Unix program name.
You can play other games, too: The job name for a DB2 address space can be decoded to glean the subsystem it belongs to. Certain System address spaces have mnemonic Procedure names. And so on.
From SMF 72 you can obtain the number of address spaces for a Service Class - 0 suggesting the Service Class doesn't own any (see above). 1 suggests this class (possibly a Report Class) is there to provide more granularity. You can also get the number of address spaces In and the number Out-And-Ready. This can help you form a picture of e.g. "low use" address spaces in the Service Class.
This post is about sharing some of my experience of trying to extend the value that can be got out of SMF - beyond the obvious. Some of this will probably appear in my I Know What You Did Last Summer presentation - which I'm still hoping to complete soon. This also, by the way, explains why I'm so keen to get Type 30 data from you when you're sending me RMF data. There really is a huge amount of value to be had.