Tivoli Workload Scheduler and Workload Manager Service Classes
MartinPacker 11000094DH Visits (3300)
I don't think I've mentioned this before in this blog but Tivoli Workload Scheduler (TWS) has a nice "WLM Integration" feature. With it TWS can change the Service Class a job runs in - before submission.
The main purpose of this is to elevate Critical Path work.
We wrote about this in the Redbook mentioned in Touring The Upcoming Batch Optimization On z/OS Redbook, and so some of you will have seen me begin to discuss the area in the presentation.
This week Dean Harrison (a friend who is a renowned expert on TWS) and I presented together on "TWS and WLM". It's all about this linkage. He talked about how you goad TWS into changing the WLM Service Class for a job. Very sensibly he didn't say "a better Service Class" but rather "a different Service Class". I was watching for him to trip up but he didn't.
(He also did a nice job of handling the whole fraught question of what a Critical Path actually is. I think we all know the score here.)
But back to the "different Service Class" thing: We all know that it doesn't matter what you call a Service Class, it's what the goal is that counts. In my portion of the presentation I did the "now you've got a Service Class now what?" piece. So I talked, for instance, about whether response time goals were usable with Production Batch or whether you should stick to velocity goals. (On that one I think only if the batch looks like a large number of independent really heavy transactions should you use response time goals.)
So, my role was in the vein of the cliche "what you don't know can hurt you" for Batch Operations folks. My message to them was "understand what the service classes you're steering work towards actually mean".
But let's stand it on its head: From the Performance Analyst's perspective the cliche still applies: How do you know what the batch is that shows up in PRDBATHI vs PRDBATMD? You don't unless you take an interest in how the jobs got into either of those classes. So my message to "us" is "understand how work came to be in each Service Class and what expectations the Batch Operations folks have of it".
The "can hurt you" in the cliche is interesting: You could - whether a Batch Operations person or a Performance Analyst hide behind "separation of concerns". I wouldn't recommend it though: Presumably installations take a dim view of such things. Another cliche on offer is "hang together or hang separately". I encourage both camps to work together. (Just as I encourage eg CICS and Performance people to.)
Best of all is if you can be skilled in both TWS and WLM. A tall order, I know. But that might earn you a leading role in the (proposed in the Redbook) Batch Design Authority.