This is usually very misunderstood. It's really the number of service class PERIODS WITH velocity or response GOALS (i.e. with an importance level). The reason is because WLM on each system will wake up every ten seconds (that's an eternity in a z14!) to see if goals are being missed. It starts with importance=1 periods and works its way down. If there are too many periods, the ones at a lower importance level will never get adjusted and you might have some less important periods exceeding their goals while more important periods are missing their goals. I was able to include both my own recommendations and other IBM recommendations when I was on an IBM residency working for Frank Kyne and writing a really neat Redbook called System z Mean Time to Recovery Best Practices - SG24-7816 - http://www.redbooks.ibm.com/redbooks/pdfs/sg247816.pdf. I consider it one of the most useful Redbooks I own. It contains best practices for reducing start up and shut down of z/OS and each of the major subsystems. I especially like the section that explains the IPL process.
As an example, here are recommendations from section 5.2 of the Redbook: General WLM recommendations: 1. Keep your WLM policy as simple as possible. Service classes with only a single period are usually better than two periods, and two periods are almost always better than three periods. Of course there are exceptions to every recommendation, but this provides a good place to start. 2. Use response time goals, especially percentile response time goals, when you can. Only use velocity goals when transactions goals are not supported, or for test subsystems. Specifically, you should use percentile response time goals for DB2, CICS, IMS, and WebSphere. 3. Remember to review and possibly adjust velocity goals after any hardware upgrade. 4. If you have a very large number of classification rules, consider their sequence carefully. The rules are applied serially, starting with the first one, until a match is found. 5. Do not have too many service class periods with non-discretionary goals. A good guideline is to have less than 30 non-discretionary service class periods that are active on any one system. [Cheryl note: ON ANY ONE SYSTEM! If a service class is active on SYSA and not on SYSB, you don't need to count that on SYSB.] 6. Any service class with velocity goals should have multiple address spaces assigned to it so that it can collect meaningful statistics. If you need more granularity for reporting reasons, assign the address spaces to report classes. 7. If you have not reviewed your WLM policy in several years, take the time to do it now. Several enhancements to WLM have been made that can simplify your policy, or improve response time for transactions. Cheers! Cheryl ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
