zPerformance Why WLM Controls Are Not Enough For DDF

[Anuj Dhawan]

For once this isn’t a blog post that discusses a podcast episode or a screencast. It is one where I feel a little exposed, but only a little.1
I just updated my “Even More Fun With DDF” presentation - after a whole two months. You’d think there’d be little new to say after only two months, but you’d be wrong. Quite apart from some other additions, there is a whole new thought2 to share. And I’m interested in opinions on it.
I think it’s a quite important thought: WLM Controls Are Not Enough For DDF.
Let me explain.
Traditional DDF Control Mechanisms
As you probably know, you classify DDF work below the DB2 address spaces and based on multiple potential qualifiers. Each transaction is a single commit3. Which is often just a small part of the requestor’s conversation with DB2. And WLM doesn’t know about the whole conversation, just the (independent enclave) transaction.
You can use period aging - so as a transaction accumulates service it can fall into periods 2, 3, and maybe 44. You would expect each successive period to have a looser goal and a lower importance.
You can also use Resource Groups - but I consider that a pretty blunt instrument.
Where Does This Fall Short?
It falls short in two main areas:

• Non-Performance Controls
• Short Transactions

Non-Performance Controls
It might be stating the obvious but this is important: WLM does not control access to DB2.
So, you have to set up Security in DB2 and your security manager (such as RACF). You not only have to decide who can access a given DB2 and from where but also what they can do.
This is not a performance issue as such, but it’s the first clue that DB2 and Security people need to be involved in discussions about how to manage DDF work.
Short Transactions
A very short transaction is difficult to manage in any case. A bunch of all-the-same short transactions doubly so. There’s no period aging to be had there, for one.
This is the new area for me: I’m seeing in several recent cases bursts of short transactions from the same source. Two examples come to mind:

• SAP Batch. Which is really a bulk insertion of short DDF transactions.
• Java Batch. Likewise, quite often.

One thing these have in common is that they are generally5 detectable. The Unit Of Work ID6 is a constant for the “batch job”.
But this doesn’t really help control them. For that you really need gating mechanisms in DB2 / DDF and maybe outboard of that. And that’s really the new point.
To be fair, for SAP Batch, you generally see a Correlation ID of xyzBTCnnn where xyz is a kind of application code and nnn is a three-digit number. So you could classify it in a separate Service Class from e.g. SAP Dialog transactions (xyzDIAnnn).
Two Parting Thoughts
Another thing that occurred to me is this: Control of DDF is important not just for System purposes but to protect other DDF from rogue7 DDF.
Consider DB2 logical resources such as DBATs, which are a subsystem-level resource. If rogue DDF work came in and used them all at once it could crowd out Production DDF. And there’s plenty of that around that matters. So you definitely want to protect Production DDF. Probably with DDF Profiles, but with other DB2 mechanisms as available. And this is where I chicken out and defer to people like Rob Catterall - and posts such as this.
And one final thought: Slowing down DDF work might not be all that helpful, particularly if it holds locks that other work needs. But then this is true of other work, like lower-priority batch jobs. So WLM controls might have an unfortunate effect.

• It’ll be obvious where in this post that manifests itself, and I don’t think it detracts from my main argument. It’s possible My Considered Opinion? is helpful here. ↩
• So this whole post is about a single slide. Yeah, so?  ↩
• Or abort. ↩
• 4 periods is a bit excessive, in my opinion, but I have seen it. ↩
• Unless obfuscated by their source, somehow. ↩
• Minus the Commit Count portion. ↩
• Or “Feral” DDF if you prefer (as I do). ↩

Source: https://www.ibm.com/developerworks/comm ... DF?lang=en