About this 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.

Putting these two together you come to the conclusion it might technically be possible to get more WLM information into Accounting Trace. That, of course, doesn't mean it's going to happen. I have to stress that before going any further. But it's worthwhile thinking about what's needed and how useful that would be to customers.

What Should Be Added?

Uncontroversially, I think, QWACWLME should be filled in with Service Class for all work types. I say "uncontroversially" because - if it can be done cheaply - it's just using space that's already in the record. I don't know if it can be done cheaply, though.

More controversially because, taken together, they represent 18 additional bytes in each 101 record are:

WLM Workload

WLM Report Class

WLM Service Class Period

I think I could live without Workload but it seems a shame to exclude it.

As Willie points out Performance Index (PI) is also in the DISPLAY THREAD command but I think we can get that from RMF Workload Activity Report (SMF 72) and that's probably a better place to get it from.

But the key question is "how useful and important would this extra information be to you?"

Let me outline three areas of use I can immediately see...

Understanding Not Accounted For Time

This time bucket is what you get when you subtract all the time buckets we know about from the headline response time. The two most important causes for this are CPU Queuing and Paging Delay.

If we calculate this time for a record and we know the (behaviour of) the WLM Service Class it's in we can understand this time better. A bugbear of doing DB2 performance is just this: understanding whether work is subject to queuing or not. (For Paging Delay as a cause of Not Accounted For Time we could do much the same thing.)

Understanding The WLM Aspects Of DB2 Work

It would be useful to be able to break down the work coming into a DB2 subsystem by Service Class, Goal and Importance, wouldn't it? In particular it would be nice to see the hierarchy of goals and importances, and to be able to relate the works' WLM attributes to those of address spaces such as DIST and DBM1. (In the former case discovering that the TCB's in the DIST address space were subject to pre-emption by the DDF work would be a blow.)

Correlating Service Class And Report Class For DDF Work

For non-enclave work I use the Report Class and Service Class in Type 30 to establish how these relate to each other (and what kind of work has which RC and which SC). I can't do it for DDF work because there's no usable Type 30 (i.e. with this kind of information in). If the 101 record had these both in you could extend the method.

Over To You

What do you think? I've listed three categories of value that immediately spring to mind (and that's with the disbenefit of jetlag so maybe not that articulately expressed). But I'd really like to know if this would be of value to you - and to modify the proposal if you think you'd like something slightly different.

There's no guarantee this will get done - and it's a bit of an attempt at a "Social Requirements Gathering" process. But it's worth debating in public, I think.

Quarantine this entry

Thanks to Willie Favero for creating a poll on the subject, a
technique I might in future use myself: <div>&nbsp;</div>
<div>&nbsp;</div>
https://www.ibm.com/developerworks/mydeveloperworks/blogs/db2handbook/entry/polldaddy_test?lang=en_us

I would very much like to at least have the WLM service class on
every 101 record. The report class and workload would be
interesting as well. My primary use of this information would be to
do root cause analysis on large not-accounted for times and the
side affects of that time such as increase lock, latch, page latch,
and global contention that often increases with not accounted for
time. <div>&nbsp;</div>
I would also be interested in using this information to correlate
with RMF data to understand what portion of each service class cpu
consumption was due to DB2 workloads.