Steve Samson is probably the preeminent practicioner of MVS performance tuning. He has a couple of books to his credit, he has taught classes and is a regular presenter at SHARE. And I suppose that Candle Corporation pays him for some reason or other. I always treat anything Steve has to say with appropriate reverence; he is probably right.
For three years or more he has been haranguing everyone he meets at SHARE meetings. "Are you in Goal Mode yet? And if not, then why not?" This admittedly extravagantly titled session was the latest in his effort to convert the masses. He really believes in this stuff.
"Goal mode" is the fully operational mode of the Workload Manager, which itself is a component of the System Resource Manager. Prior to a few years ago, SRM made all the paging and swapping and dispatching decisions for your jobs, based on a complex set of formulae that you specified at IPL time. In my shop, we used it to specify a hierarchy of jobs in order of importance: system tasks, IDMS, TSO, and batch. We also used it to dedicate a portion of real memory to IDMS in order to help its performance along.
When you put your system in goal mode, the Workload Manager measures the performance of your system and adjusts the SRM parameters - about once every ten seconds. Rather than specify the actual SRM parameters, we now classify all our work into several groups, and then tell the Workload Manager the performance goals for each group. It's up to Workload Manager to meet these goals in any way it chooses.
(Since we implemented goal mode a month ago, I've seen a couple of positive aspects. I don't have to specify storage isolation for IDMSDC anymore; Workload Manager does this for me, on the fly, as conditions warrant. And nobody has complained to me about erratic TSO response time in the last month, either. I'm impressed...)
So why don't more people go to goal mode? Mostly because they don't have to. What they have, works... for now. And most systems programming folks aren't exactly looking for things to do.
Steve says "Goal mode drives CPU harder than you would dare to." And while the Workload Manager is primarily concerned with CPU utilization today, eventually the storage subsystems will learn to talk to the Workload Manager. The storage subsystems will start to manage their own internal request queues according to the importance of the workload. The "DEFINE EXTENT" command already contains a parameter that specifies the priority of the request.
Workload Manager goals are more flexible than simply specifying dispatching priorities, as we have done in the past. In the old SRM parameters there is no way to say "Make TSO response time as good as you can - until IMS hurts." But Workload Manager knows which of your workloads are more important. In goal mode, you can say:
Goal mode is easier to write parameters for. There is no need (and indeed no way) to code specifications for storage isolation, dispatching priority, or multiprogramming levels. These are all off limits.
Many installations are leery about giving up their control over dedicated memory; they're afraid that online response times will suffer for it. Steve guffaws. SRM starting doing working set management way back in version 4 of MVS, and does a good job of evaluating the costs and benefits of doing a swap. This is six years of proven code!
Some of the reports out of RMF have been obsoleted. The Workload report now contains a "performance index" - a simple indicator of whether your goals are being met or not. In a sysplex with many processors being dispatched work, Workload Manager will assign work based on each system's current performance index; busy systems with a "bad" performance index will not be assigned new work.
Workload Manager introduces the concept of "velocity". It is a measure of how rapidly you are using resources of the system, and can be applied to batch jobs or other systems where response times are not appropriate. We have velocity goals associated with things like IDMSDC, the fax processes and LANRES. Workload Manager also has a construct called "discretionary" work. This is work which has no specific goal other than to get it done when you can. Workload Manager runs best when it has lots of discretionary work that it can push around, and most of the batch workload at Duda is defined this way.
Steve did caution that discretionary work is the "canary" of the system. When it dies, you need more resources, pure and simple.