Posted with Don Deese's permission at the request of Mark Zelden with thanks to Dave Thorn for following this topic up with Don as part of a discussion at a recent Philly CMG meeting.
Chapter 1.7: Discretionary Goal Management A problem existed when using discretionary goals prior to OS/390 Version 2 Release 6: on systems in which 100% of the CPU was used by service class periods with performance goals, service class periods assigned a discretionary goal might never receive CPU service. This situation existed even though the service class periods with performance goals might be significantly over achieving their goals, since the Workload Manager would never allow discretionary work to have a CPU dispatching priority equal to or higher than work with performance goals. >From one perspective, this algorithm is proper; discretionary work is defined as work that has no performance goal. However, most sites want the discretionary work eventually to be processed, even though it has no performance goal. Consequently, many sites removed the discretionary goal from work and assigned a performance goal to the work. However, there are significant advantages to assigning a discretionary goal to work: work with a discretionary goal executes with the Mean-Time-To-Wait (MTTW) algorithm. . Work assigned to a Mean-Time-To-Wait group competes within the Mean-Time-To-Wait group for access to the processor. Address spaces are assigned dispatching priority within the MTTW group, based upon their execution characteristics. Address spaces that execute a significant number of CPU instructions between I/O operations are considered heavy CPU users. These heavy users receive a lower dispatching priority within the MTTW group than do address spaces requiring less CPU processing between I/O operations. . The philosophy behind assigning work to Mean-Time-To-Wait groups is to attempt to use as much of the overall computer system as possible. Dispatching relatively light CPU users ahead of relatively heavy CPU users ensures that the I/O complex will be used simultaneously with the CPU processor. Since both CPU and I/O are active simultaneously, more overall work will be accomplished by the computer system. This philosophy assumes, of course, that overall throughput is a major goal, rather than the turnaround of specific heavy CPU users. This philosophy is explicitly applicable to service class periods assigned a discretionary goal. IBM addressed this problem in OS/390 Version 2 Release 6, by implementing the discretionary goal management algorithms. With discretionary goal management, the Workload Manager identifies service class periods that have been assigned a performance goal and that are candidates for participation in discretionary goal management. Service class periods can participate in discretionary goal management if either of the following conditions applies: . The service class period has a response goal greater than one minute. This condition does not apply to subsystem transaction service classes (e.g., CICS or IMS transaction service classes), since these service class periods do not include address spaces. . The service class period has an execution velocity goal less than or equal to 30%. The Workload Manager identifies candidate service class periods meeting either of the above conditions, that have significantly overachieved their performance goal. If discretionary work exists in the system, the Workload Manager may apply internal resource capping to the service class periods that are over achieving their performance goal. The internal resource capping operates similarly to the normal Resource Group capping described in Chapter 1.6 of this section, in that the Workload Manager will cap the address spaces for one or more cap slices. This capping restricts the amount of CPU service that can be used by address spaces in the capped service class period. The Workload Manager may apply internal resource capping when the Performance Index is less than 0.7, and stops internal resource capping when the Performance Index is greater than or equal to 0.81. If a candidate service class period with a performance goal has multiple periods, later periods are selected for capping before earlier periods (that is, capping would potentially be applied to Period 2 before capping would be considered for Period 1). The effect of the discretionary goal management algorithm is to allow discretionary work to receive CPU cycles when work with a performance goal would otherwise significantly over achieve its performance goal. </SNIP> There are two important points in the above snip: (1) internal resource capping also applies to transactions that have greater than one minute response goal, and (2) internal resource capping will be applied only if there is discretionary work ready to run. Regards, Don ****** Don Deese, Computer Management Sciences, Inc. Voice: (703) 922-7027 Fax: (703) 922-7305 http://www.cpexpert.com ****** ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
