This section describes where to find information to set a velocity goal, and what kind of work is appropriate for velocity goals. Velocity goals define the acceptable amount of delay for work when work is ready to run. Velocity goals are intended for subsystems which use address spaces or enclaves to represent individual work requests. Velocity goals are not supported for work in the IMS™ and CICS® subsystem work environments because velocity data is accounted to the region, not to the individual transaction. Velocity is a goal to consider for long-running jobs.
For a service class with multiple periods, you cannot switch from a velocity goal in one period to a response time goal in a later period. See Subsystem support for goal types and multiple periods for a list of subsystems for which you can specify multiple periods.
Velocity goals are more sensitive to configuration
changes than response time goals and should be monitored and adjusted
when required after configuration changes. These configuration changes
include:- Change to the physical configuration, such as a new processor type.
- Changes to the capacity that is available to a system.
- Changes to the logical configuration, such as significant changes to the number of online processors, or implementation of HiperDispatch, or implementation of multi-threading
