Three Early SMF 89 Results
MartinPacker 11000094DH Visits (2350)
There are three things I’d like to share with you that you might not realise you can get from SMF Type 89. But first a design standard I didn’t mention before.
CSV Files That Are Sortable
When processing data it’s useful to create a series of tables. And so it is with SMF. There are two things I’m aiming for:
These two aims are not mutually incompatible, it turns out. So here’s how you do it:
If you do those things you can process the data with a wide variety of methods - whether on z/OS or elsewhere. When I’m flattening SMF 89 I follow these rules; It’s not difficult in REXX, with
By the way what I’ve just said doesn’t just apply to SMF; It’s relevant to any tabular data.
Here are three things I (and you) can see - without much difficulty - from SMF 89.3
zNALC Or Not zNALC?
When examining software economics, for example, it’s important to know if an LPAR is operating under zNALC rules. zNALC is a successor to NALC.
With NALC you had to have the LPAR follow a strict (IBM-specified) naming convention. With zNALC you don’t. Operationally it’s much easier.
In SMF 89 there is a flag for whether the LPAR is zNALC or not. Maybe this one isn’t particularly useful if it’s your systems we’re talking about. For consultants and people like me it’s a different matter, of course. But the standard homily applies: “Systems should be self documenting.” In this case they are.
Actually, in my test data sets, this is a little hard to verify - as none of them contain data from zNALC LPARs. With each new set of customer data I’ll run a query until I find a zNALC LPAR. Then I’ll incorporate the test into my formal code. I quite like the idea of being able to test things.
MQ Queue Managers And DB2 Subsystems
Believe it or not, you can list the MQ and DB2 subsystems by LPAR - using only SMF 89 Subtype 1 data. You don’t need to use SMF 30 - which I have been using up until now just for this purpose.4
The key here is to look for Usage Data Sections with Product Name “DB2” or “MQM MVS/ESA”. The Product Qualifier field yields then name, perhaps slightly encoded. Decoding turns out to be easy - as you’ll see in a minute.
The Product Version field tells you what release the subsystem is running at.
Here is an example:
DB2 - All at 11.01.00 ====
This might not be pretty - and before it hits Production it will be much prettier - but it gives useful insight:
If you were a SAP installation, for example, you might be glad of a report based on SMF 89 rather than SMF 30.
MQ Queue Manager CPU By Time Of Day
This is a more surprising result: For MQ you can see the CPU in MQ by time of day. The following graph is from a real customer. I teased it on Twitter the other day. Or rather a simplified version of it.
The graph is for a single MQ queue manager across a seven-day period.
I mentioned decoding the Product Qualifier field above. For queue manager MQ01 this field takes values including:
These enable me to plot a graph such as the one above, using the TCB time in the Usage Data Section. I’ve omitted a series “Other”. In this data Other contains zero TCB time. I calculate Other by summing up all the MQ-related TCB time where the Product Qualifier begins with “MQ01” but isn’t in this list. (I can figure out what it is and create another series for it, obviously.)
So, to what the graph shows. (Or rather what I think it shows - and you might form your own view.)
CHIN, by the way, is MQ traffic to and from outside the z/OS LPAR. We don’t get from this data (or SMF 30) PUT and GET rates. Nor is why CHIN is unmatched by some other connection explained. But this is enough to alert you to the fact something happens, and to talk to the MQ experts in the installation.
I think these three insights are useful, if not a little surprising. It encourages me to work further with the SMF 89 data. Maybe it encourages you, too, to look at this record. And they weren’t hard to get. There’a more to come, I suspect.