I’ve been blogging about DB2 for z/OS for quite some time, beginning with my time as an independent DB2 consultant (http://catterallconsulting.blogspot.com/), and continuing with a blog I started when I rejoined IBM in 2010 (“Robert’s DB2 blog”). I am going to continue to post to “Robert’s DB2 blog,” but I’ve seen a need to let DB2 for z/OS people know about tools that can boost their productivity, extend their capabilities, and enable them to more effectively utilize mainframe DB2 technology to their employers’ advantage. I’ve decided to address that need with a new blog, and this is it. I hope that you’ll check in periodically to find information on IBM DB2 for z/OS tools that will make you better at what you do.
In this initial entry, I want to tell you about a new tool that enables dynamic and fine-grained management of a DB2 for z/OS client-server workload (i.e., a workload that involves the use of DRDA and DB2’s Distributed Data Facility): IBM InfoSphere Optim Configuration Manager V2.1 (the product’s full name is a bit of a mouthful, so I’ll refer to it hereafter as OCM). How can this be a new product, you ask, if it’s Version 2.1? Well, this is one of those happy stories in which a DB2 for z/OS-using organization came to IBM with a need, and IBM developed a tool to address the customer’s requirement. That was OCM Version 1.1. It was determined that the tool would be of value to the broader DB2 for z/OS user community, and OCM was enhanced and packaged accordingly. That’s Version 2.1, made available in the fourth quarter of last year (note that OCM can also be used with DB2 for Linux, UNIX, and Windows).
Why do I want to use this inaugural entry in my “DB2 for z/OS: Beyond the Engine” blog to shine a light on OCM? For two interrelated reasons: 1) at many mainframe DB2 sites, client-server is the fastest growing component of the overall DB2 for z/OS workload, and at more than a few sites it’s already the largest workload component -- bigger than batch-DB2, bigger than CICS-DB2 (this in terms of mainframe server CPU time associated with SQL statement execution -- refer to an entry on my DB2 blog, and check this out yourself for your environment); and 2) for plenty of DB2 for z/OS people, the level of control they have over the client-server workload is not what they want it to be. OCM changes that story.
First, consider workload management. There are still people out there in DB2 land who believe that there’s no such thing as fine-grained management of a client-server DB2 for z/OS workload -- they think that all DB2 DDF work runs at the same priority in the system. Of course, it’s been years since that was true. You can slice and dice a client-server DB2 workload based on a variety of identifiers, and assign priorities -- via service classes -- in a z/OS WLM policy accordingly (there’s a very good write-up on this in an IBM “red book” on DB2 for z/OS distributed functions). All well and good, but chances are the WLM set-up you have for your client-server DB2 applications assumes that these applications are behaving as they should. Suppose an application starts misbehaving in a way that causes it to hog mainframe DB2 server resources, to the detriment (performance-wise) of other DB2-accessing apps? Using OCM, you could create a rule that would dynamically re-map the misbehaving application to a different WLM service class to which a lower priority has been assigned. How could you do that? There are several scenarios, but one would involve changing the authorization ID associated with the rogue application, if auth ID is used to map an app to a WLM service class. How is that done? Easy: OCM allows you to have what are called managed clients (those being machines on which a piece of code called the Optim Data Tools Runtime Client has been installed), and for such a client an OCM administrator can override application-provided information such as the DB2 authorization ID (more on this override capability to come). After the application’s performance-degrading problem has been resolved, it can be dynamically switched back to it’s original WLM service class -- and these WLM-related adjustments require nothing in the way of client-side code changes.
If you’re running DB2 for z/OS in data sharing mode on a Parallel Sysplex mainframe cluster, OCM gives you even more options for minimizing the adverse impact of a misbehaving client-server application. Suppose the aforementioned reclassification (from a WLM perspective) of the problematic app is not sufficiently minimizing its negative impact on the performance of other DB2 applications? No problem: you can use OCM to dynamically isolate the resource-hogging application to a particular member (or subset of members) in the data sharing group (this OCM capability leverages the location alias functionality of DB2 for z/OS, about which I blogged a few weeks ago). After the problem has been resolved, you use OCM to re-enable the spreading of the application’s transactions across all members (or a larger subset of members) of the data sharing group -- and again, this shrinking and growing of the application’s DB2-side execution space, if you will, can be accomplished with no need for changes on the client end of things.
And the OCM application scenarios go on: Would it be handy to be able to easily redirect connection requests from a particular application server to a different DB2 for z/OS server (perhaps one that’s just been migrated to DB2 10, in order to see how the application behaves when accessing a DB2 10 system)? You can do that with OCM. Remember my mention of OCM’s ability to override application-provided identifying information (information that’s crucial in terms of mapping to WLM service classes, and important for DB2-side application monitoring)? Would it be nice to have a means of correcting such identifying information if it’s incorrectly specified on the client side? Check. Got a DB2 client-server app that’s using too many connections to a DB2 for z/OS server? Would you like to be able, from a central control point, to reduce the number of transports from that application to DB2 at the DB2 client (e.g., IBM Data Server Driver Package or DB2 Connect) data source level? Very do-able with OCM. Want something that can automatically track changes made to DB2 client and server configuration settings? With OCM, you got it.
Bottom line: OCM puts you in control of your DB2 for z/OS client-server workload in ways you weren’t before. And, we’re talking about control at a pretty fine-grained level, if you want it (e.g., by application identifier, authorization ID, client IP address, JDBC data source name, etc.) -- you aren’t limited to overly large-scope knobs and levers.
Something else to keep in mind: OCM is a pretty new tool. In this initial version, the focus is on Java applications. Expect support to be extended to other client types over time -- keep your eye on this space.
Want to know more? Check out the OCM Information Center on the Web. Want to see this thing? Watch a video of OCM being put through its paces.
