Using Velocity Goals

Q: When migrating from MVS 4.3 to OS/390 R3, how do I measure current velocities to set my goals?
A: First migrate, gather velocity data in compatibility mode, set your goals, then switch to goal mode.

Q: I have some work with very low activity and a high velocity goal. It is not achieving its goal even though there is CPU available. Why?
A: Work that goes into and out of wait accumulates CPU wait samples because it isn't necessarily dispatched immediately. This effect is due to the reduced preemption in the MVS dispatcher in MVS 3.1 and later. The delay samples drive down the calculated velocity.

For more information on velocity, see Velocity Goals: What You Don't Know Can Hurt You

Q: I've heard that achieved velocities can change with processor speed and multiprocessing level. How do I select a single, sysplex-wide velocity goal for a service class if I have a mixed-hardware sysplex?
A: It's a fact of life with velocity goals that the same work can achieve different velocities on systems of different speeds and different numbers of CPs. The dilemma then is how to select a single velocity goal in a sysplex with mixed machines. Some helpful hints:

• Use response time goals whenever possible.
• For work that requires velocity goals, don't try to be too precise in selecting a number. Small differences in velocity goals have little noticeable effect. For example, pick velocities that represent "slow", "medium", and "fast". These might be 20%, 50%, and 80%, respectively. The higher velocity goals are more sensitive to processor differences, so when selecting a fast velocity goal, select one that is attainable on the smaller processors.
• Revisit velocity goals after a processor change.
• For more information on velocity, see Velocity Goals: What You Don't Know Can Hurt You