More Mobile

(Originally posted 2018-06-25.)

This post follows on from something I mentioned in When Reality Bytes. Some things I get to immediately; Others take a little time. This is one of the latter.

A more systematic, better, way for classifying work as Mobile was introduced with APARs OA47072 for WLM and OA48466 for RMF in December 2015.

Some months ago I mapped the SMF record improvements OA48466 brought. But I had no data to test the mapping with. Very recently, however, I had the opportunity to develop reporting to go with it. (A recent engagement had a strong Mobile component.) Often a few records are enough to test mappings with. But to begin to develop reporting takes “real world” data. Such is the process.

Mobile Work Classification With OA48466

As I mentioned in When Reality Bytes a new WLM construct was introduced: Reporting Attribute. To classify work as Mobile you simply scroll to the right (enough times) and type in MOBILE in the Reporting Attribute field.¹

Of course, planning and getting to that stage takes some doing. But it’s a lot better than previous schemes involving detailed transaction (SMF 110 CICS Monitor Trace, for instance) reporting. Or dedicated Mobile regions or even LPARs.²

And ensuring your application folks, or whoever, identify to you a workload as Mobile, remains an organisational challenge.

System-Level Reporting

So, suppose you’ve successfully implemented the new style of Mobile reporting. What do you see at the system level?

In SMF 70 you immediately get a useful new field: SMF70LACM. If you spotted this field before you’ll’ve noted the rather opaque description of the field. But now the description has been clarified.

It’s the long term Mobile MSUs³. The words “long term” are also used in the description of field SMF70LAC – the headline MSUs consumed by the LPAR. But what does “long term” mean? It means “rolling four hour average” – and is therefore a smoothed value relative to the RMF interval. SMF70LACM is analogous to SMF70LAC – but for Mobile.

My reporting for this field is graphical. It’s not difficult to plot Mobile and headline as series on the same time-of-day graph. In my code, this includes lines for Category A and B MSUs, as outlined below. The graph in its entirety, and the series included, depend on non-zero values in the relevant fields. For me this is the first indication that e.g. Mobile is in play in the LPAR.

Workload-Level Reporting

At the workload level this APAR produces a lot of useful detail. Here the numbers are service units, rather than MSUs. Obviously, you can divide by the interval to get SUs/second.

I choose to report on this using a shift-level average. This is because I don’t want to create and arbitrarily large number of graphs.

Because the data is available for both service classes and report classes I tabulate both. In at least the data I have the correlation between the two is interesting.

For each type – headline, Mobile, Category A, and Category B – you get GCP, zIIP and zIIP-on-GCP service units.⁴

Category A / B

Both the system-level and workload-level numbers for Mobile have analogues for the mysterious “Category A” and “Category B” cases. I’ve not seen actual cases where these have been used. But my reporting includes them smartly⁵ – so I would readily detect their presence.

Category A and Category B behave identically to Mobile. Tenant Resource Groups are quite different- both in setup and RMF.

Conclusion

This might be stating the obvious but you only get the new fields if you’re using the new method of classifying work as Mobile. These new fields are beneficial as they enable you to track Mobile usage, including which service classes are using it.

Because I already know the customer whose data I’m testing with well, there aren’t astonishing insights this time round. For future engagements I expect to find this data a useful introduction to their Mobile setup.

And continuing the “More Mobile” theme, this post was composed in a very Mobile way – on an iPhone using the very excellent Drafts 5 app. 🙂