Cheryl Watson gave this update on her well known WLM quickstart policy. It was well worth attending, even though I thought I'd heard it all before.
I had listened to her give her spiel at another SHARE two years ago, and have since studied it pretty thoroughly. Heck, we even implemented it a month or two ago, with some minor changes. I went to this session expecting to have her repeat most of the details, but wanted to make sure I had not forgotten anything major.
And she surprised me by not reviewing the quickstart policy at all. It's in Steve Samson's book, and it's on IBM's web site, and the basics are in the handout for this session, so... go investigate it yourself, she concluded. This session was billed as an update, and it was indeed an update. Tailor made for me. I was loving it.
She made this observation: Workload Manager more aggressively pages, typically from CSTOR to ESTOR. You should have six to ten - "I've seen 20" - page datasets, and they should all be the same size. They should reside on dedicated volumes if possible. With Iceberg this is indeed possible, and we already have six paging volumes.
(Steve Samson further recommends that you never have more than 30-35% of your slots allocated in any page dataset. This significantly reduces the opportunity for block paging.)
Cheryl pointed out some misconceptions concerning velocity goals for long running jobs with intermittent response time requirements. I've got to review some of what I did for the fax PCs; my specifications may be bogus.
She has new recommendations for new workloads that are coming on in OS/390: APPC/ASCH, web server, Unix processes and so on.
Cheryl encourages people to define as few periods and service classes as necessary. She even wants people to consider two period TSO; she rarely sees a need for three performance periods, and she's seen hundreds of data centers.
TSO response time, as reported by RMF can be very bad, because Unix transactions that start under TSO execute elsewhere, and the TSO transaction remains in period 1. The moral of the story is to use percentiles. Response time averages can be artificially out of line.
Cheryl Watson recommds sticking in ten dummy service classes in your workload definition, with no workloads associated with them. Later you can assign workloads to them with the RESET operator command. This is good for experimentation and reduces the need to do policy changes, which are disruptive to some extent.
Rules-of-thumb: you should be envious of people with six millisecond response time on DASD. Many people work hard for 20-30 millisecond times. Cheryl wants you to be cautious in implementing I/O priority management (which is optional in release 1.3, but not in 2.4).
Velocities can vary widely on different hardware platforms (example: Skyline vs CMOS machines). You must review your goals after a hardware upgrade. Dang, I was hoping to avoid this.
Recommended CSTOR to ESTOR ratio: 3:1 or 4:1, but only after you've preallocated the ESTOR required by your subsystems.