Three Early SMF 89 Results

(Originally posted 2018-10-31.)

Recently I wrote code to “flatten” SMF 89 records – in REXX.¹ Now I want to share with you some of the insights I’ve acquired from early experiments with the data.²

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:

• Ability to pull into Excel – which suggests CSV format
• Ease of processing with DFSORT or ICETOOL

These two aims are not mutually incompatible, it turns out. So here’s how you do it:

• Pad all your fields so they are fixed width. This makes it easier for DFSORT to find the fields – as fixed width supports fixed positions.
• Wrap character stings in double quotes.
• Splice fields in a row with commas.

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 right() and left() functions being your friend.

By the way what I’ve just said doesn’t just apply to SMF; It’s relevant to any tabular data.

Three Insights

Here are three things I (and you) can see – without much difficulty – from SMF 89.³

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.⁴

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
=====================

ASYS 
    DBG1
    DBR1
    DBS1
    DSN
BSYS
    DSNF
    DSNH
    DSNJ
CSYS
    DBG2
    DBP2
    DBR2
    DBS2
DSYS
    (none)

MQ - All at V8 R0.0
===================

ASYS
    EDIP
    ODSP
    ODSH

This might not be pretty – and before it hits Production it will be much prettier – but it gives useful insight:

• All the DB2 subsystems are V11 and all the MQ queue managers are V8.
• MQ only runs on ASYS.
• DSYS had neither DB2 nor MQ.
• You might be able to spot a meaningful naming convention – but this is not the technique for discovering Data- or Queue-sharing groups.

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:

• MQ01
• MQ01CHIN
• MQ01BATC
• MQ01RRSB
• MQ01CICS

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.)

• There is a fairly regular daily pattern.
• RRSB is more pronounced on Tuesday, 9th October.
• Early on Wednesday, 10th October Batch is much more pronounced.
• Later the same day CHIN becomes much bigger.

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.

Conclusion

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.