It seems to me understanding when an installation’s utilities run is important.
Why is this?
It’s because utilities can make systems behave differently from how they usually do. And some of these behaviours can represent a challenge.
It’s often also valuable to reduce the utility window.
What Is A Utility?
There is no formal definition of a utility – and there are plenty of uses of utility programs that you might not think of as part of a utility window. For example, a database unload for further processing. But, then again, you might consider that part of maintenance. (Usually this is faster than an application program.)
Another example might be a VSAM REPRO out. Usually this is to back the dataset up – but not always.
(To my mind REORGs are unambiguously maintenance- but someone probably has a use case where it isn’t, particularly if you can unload as part of the REORG.)
Behavioural Differences
In a utility window a number of things commonly happen:
- Coupling facilities get busier – driven by structures such as LOCK1 and Group Buffer Pools.
- zIIPs get busier – as many utilities use zIIPs.
- Memory usage goes up – generally driven by sorting.
The above, of course, is not an exhaustive list.
You might mitigate some of these by slowing down executions but it’s worthwhile considering that many installations limit or even exclude application processing. So there’s a trade off between application availability and resource consumption.
Obviously utility windows need careful planning – in terms of scheduling and phasing.
And discussions around all this are ones I’d like to have with customers. Which is why detection is important to me.
What I wouldn’t claim the right to do is to try to influence a customer’s utility strategy.
You’ll notice this post doesn’t talk about when utility executions happen in actual customers. That’s deliberate – as I want to get more experience of timing and utility window contents.
Detecting Utility Windows
In this post I am limiting myself to Db2 utilities and IDCAMS, though the “SMF 30” method is more general.
Using SMF 30
SMF 30 records address space activity. Subtypes 2 and 3 are interval records. Subtype 4 is written when steps end. All have program name.
I’m using interval records – as that makes it easier to summarise by the hour. (I could go down to whatever the SMF 30 interval is but hour granularity generally suffices.)
I can – and do – summarise by hour by day by system. I also roll up the days and sometimes groups of systems.
As SMF 30 has program name it’s easy to pick out records with eg “DSNUTILB” or “IDCAMS”.
If I use the Usage Data Section I could relate “DSNUTILB” to a specific Db2 subsystem. I don’t do that today but perhaps I might one day.
In any case I consider this method light weight- which is a good thing
Using Db2 Accounting Trace
This method only applies to online utilities – namely those that interact with a Db2 subsystem.
It’s also heavier weight than the SMF 30 method – as it requires the installation to have turned on Db2 Accounting Trace. While the records that relate to Db2 utilities aren’t all that expensive or numerous all the other records that would be cut in the same timeframe make this expensive.
In particular, records with a field QWHCATYP of value QWHCUTIL denote a utility execution. (The field and this value are defined in member DSNDQWHC of the Db2 macro library SDSNMACS.)
I’m not sure this adds value over the SMF 30 method but it is certainly valid.
One extension of this is to query the Db2 Catalog. Until recently I would’ve recommended querying SYSIBM.SYSCOPY but recently additional tables have appeared. (I used to query these – once JOBNAME was added for me – to help with utility execution tuning. I haven’t had the opportunity to do that for a long time.)
Making Of
I started writing this on a plane to Stockholm, to present “Drawers, Of Course” and “Parallel Sysplex Performance Topics” to a group of Swedish customers. I continued writing it on the way back.
I’m also nearing the end of writing code to detect utility windows from customer data. Writing this helps clarify my thoughts about what the code should do. Of course, the next few times I deploy the code in customer situations will help refine it. I’m looking forward to that.
This code, by the way, extends existing code that detects eg Catalog and DFSMShsm spikes in EXCPs and CPU. It seems a natural fit.
Right now it recognises a very limited number of utility programs. I intend to – with more experience – to add additional programs; The code is written in a way that facilitates that. (I’m thinking IMS and DSN1COPY, as well as third party utilities.)
But anyway, here’s what the output looks like right now:

It does show particular times of day have high activity, especially for DSNUTILB.




