Planning Workgroups

To use the Workload Manager effectively, you need to know who uses your system now, how they use it, and how to translate this information into an effective workgroup configuration. In this section, you'll find questions and suggestions to help you gather this data.

To evaluate current system use

Knowledge of the current system workload is essential to the effective use of the Workload Manager. As system manager, you should be familiar with the demands of all your users and clearly understand the relative priorities of these demands.

The questions below can help you gain a more complete understanding of who uses the system and what their needs are. Consider these questions as a guideline only. Other questions, more pertinent to your particular situation, will arise while you are gathering information.

What kinds of on-line users need the system? Begin by categorizing users by job title or function, for example, data entry clerks, customer service representatives, system analysts, or programmers.
What system needs does each group of users have? For example, do some of the users interact directly with customers and therefore require fast response time?
Do you have a Service Level Agreement (SLA) with a specific department or division within your company that you must meet?
Is there an identifiable pattern of system use over time for each group? For example, at the end of each quarter, do your financial analysts place a heavy demand on the system to prepare fiscal reports? Or is there a peak demand for database access between 9 o'clock and noon and again between 2 and 5 o'clock?
How and when are batch jobs submitted on your system and do any of them require a guaranteed turnaround time? For example, does your Marketing staff run a report every morning that must be on the CEO's desk by 10 a.m.?

To partition the system workload into workgroups

Once you understand who is using the system and what their needs are, you can determine how to group the users effectively. For example, you might create separate groups for data entry clerks, all batch jobs updating a certain database, one particular batch job, application developers using editing programs, or special servers. It is these logical groupings that you translate into workgroups.

Suppose you wanted to begin by creating three user-defined workgroups, one for a server, one for data entry clerks who log orders for retail products, and one for programmers who are editing their application files. The workgroup membership criteria might look like this:

Table 2-1 A Set of Sample Workgroups

Description	Workgroup Name	Membership Criteria
Server workgroup	Server	`MEMB_PROGRAM=(SERV.APPL.DEV)`
Order entry workgroup	Retail_online	`MEMB_LOGON=(@.ORDERS)`
Program editing workgroup	Prog_Develop	`MEMB_PROGRAM=(EDITOR.PUB.SYS, QEDIT.@.@, HPEDIT.@.@)` and `MEMB_LOGON=(@.TEST, "TST,@.DEV")`

Once you decide what workgroups you want, the next step is to determine the appropriate workgroup order and what kind of access to the CPU each workgroup will have (explained next). It is important to understand, however, that the first workgroup configuration you devise is unlikely to be the last. Developing workgroups with the appropriate membership criteria and scheduling characteristics is an iterative process. You should anticipate continual monitoring of the existing workgroup configuration, evaluation of system performance, and at least some ongoing modification.

To understand the importance of workgroup order

The workgroups on your system are maintained in an ordered list, which is identical to the order in which workgroups are listed in any indirect file used by the NEWWG command. You determine workgroup order by:

Creating and/or editing the indirect file.
Adding new workgroups to the current configuration.
Removing a workgroup from the current configuration.

When the Workload Manager assigns a process to a workgroup, it uses a “first-fit algorithm”. That is, the Workload Manager searches the list of workgroups on your system and places the process into the first workgroup in which it fits. It does not seek a “best fit”.

Both the membership criteria that you do specify, and those that you don't specify, affect the placement of processes in a workgroup. That's because if you omit a category, the Workload Manager treats it as a match when it is determining membership. (For example, to allow a process with any logon potentially to become a member of a workgroup, don't specify MEMB_LOGON= when you create the workgroup.) In general, to capture a broader population of processes, specify fewer membership criteria.

In light of these factors, it is important that you order workgroups so that those with the most specific membership criteria appear first and those with more general membership criteria follow. The five system-defined workgroups, which only specify a single criterion, MEMB_QUEUE, always appear last in the list of workgroups.

How workgroup membership is determined: an example

Listed below are the names and membership criteria for three user-defined workgroups and the five default system-defined workgroups. (These are not intended to be realistic or complete workgroup specifications, since the point of this example is to understand workgroup membership.)

   

   WORKGROUP=Program_Development

   ;MEMB_PROGRAM=(EDITOR.PUB.SYS, QEDIT.@.@, HPEDIT.@.@)

   ;MEMB_LOGON=(@.TEST, "NM@,@.MYTEST")



   WORKGROUP=Payroll_Online

   ;MEMB_PROGRAM=(PAYROLL.@.PRAPP)

   ;MEMB_QUEUE=(CS)



   WORKGROUP=Payroll_Batch

   ;MEMB_PROGRAM=(PAYROLL.@.PRAPP)

   ;MEMB_QUEUE=(DS,ES)



   WORKGROUP=AS_Default

   ;MEMB_QUEUE=(AS)



   WORKGROUP=BS_Default

   ;MEMB_QUEUE=(BS)



   WORKGROUP=CS_Default

   ;MEMB_QUEUE=(CS)



   WORKGROUP=DS_Default

   ;MEMB_QUEUE=(DS)



   WORKGROUP=ES_Default

   ;MEMB_QUEUE=(ES)

Based on the preceding membership specifications, processes are assigned to the workgroups as shown in the following table.

Process Attributes				Resulting Workgroup
PIN	Logon	Queue	Program File	Resulting Workgroup
100	CMTEST, CHUCK.TEST	CS	EDITOR.PUB.SYS	Program_Development
200	NMTEST, DOUG.MYTEST	CS	EDITOR.PUB.MYTEST	CS_Default
300	NMTEST, SLC.TEST	BS	EDITOR.PUB.SYS	Program_Development
400	CMTEST, DOUG.MYTEST	BS	HPEDIT.PUB.SYS	BS_Default
500	NMTEST, SLC.MYTEST	BS	QEDIT.PUB.SYS	Program_Development
600	SUSAN, SLC.PRAPP	CS	PAYROLL.PUB.PRAPP	Payroll_Online
700	JREPORT, GREG.MYTEST	DS	PAYROLL.RPT.PRAPP	Payroll_Batch

To help you understand this example, consider why process 100 is assigned to the Program_Development workgroup and process 200 to the CS_Default workgroup. Both processes have the same queue attribute, and both meet the logon requirement for Program_Development. The critical difference is that process 200 is executing EDITOR from the MYTEST account, whereas the Program_Development workgroup requires that EDITOR come from PUB.SYS.

To find the workgroup for which Process 200 does qualify, proceed down the ordered list. Process 200 fails to match the program criterion for Payroll_Online and the queue criterion for Payroll_Batch, AS_Default, and BS_Default. The first workgroup in which Process 200 does fit is CS_Default, and, as a result, that is its destination.

To establish workgroup scheduling characteristics

The workgroup membership criteria determine which processes are grouped together in a particular workgroup, while the scheduling characteristics control the CPU access of those processes. You use your knowledge of the needs and relative priorities of these workgroups to establish the scheduling characteristics.

When you first create workgroups, consider setting only the required scheduling characteristics of base and limit priority, allowing all other values to assume their defaults. Then, monitor system performance and make the necessary adjustments, using the following list of guidelines to help you.

Give higher base and limit priorities to more important workgroups.
Assign overlapping priority ranges to workgroups that have similar needs.
Adjust quantum bounds to provide the proper rate of priority decay.
To allow workgroups with long-running transactions to compete with shorter transactions, do one of the following: set the boost property to OSCILLATE, increase the timeslice value, or increase the minimum CPU percentage of the workgroup.

If you need to review the function and use of any of the traditional scheduling parameters, read the next section. It explains each of them in detail, as well as describing the new CPU percentage bounds.

An Overview of Scheduling Characteristics

With Release 5.0, the MPE/iX Dispatcher remains priority-driven, dispatching processes to the CPU(s) based on their priority. The MPE/iX Scheduler controls process priorities in accordance with the scheduling parameters established by the system manager. The scheduling characteristics include those characteristics associated with traditional scheduling subqueues, as well as new CPU percentage bounds that are available for user-defined workgroups.

Base and Limit Priorities

The base and limit priorities determine the range of priorities available to processes within the workgroup. If no user-defined workgroups have CPU percentage minimums, the CPU will be allocated to processes based on their priorities. For example, processes in a workgroup with base=152 and limit=160 will run before processes in a workgroup with base=170 and limit=180. (Note, however, that the priorities you assign to workgroups can overlap, so that processes within the workgroups compete with each other for the CPU.)

For base and limit, priority is inversely related to the integer value: a higher-priority process has a lower number. Processes in the CS_Default, DS_Default, and ES_Default system-defined workgroups, and all processes in any user-defined workgroups, begin execution at the base priority and decay toward the limit priority. At some point, depending upon the boost property set for the workgroup, any process that is not yet complete is boosted back to the base priority to continue execution.

In traditional MPE/iX parlance, the CS, DS, and ES scheduling subqueues were known as “circular scheduling queues” because their process' priority circulated within the bounds of the established base and limit values for the subqueue. For example, a process in the CS subqueue will start at the base priority of 152 and decay towards the limit of 200. This behavior has not changed for the three system-defined workgroups which corresponding to the CS, DS, and ES subqueues.




	NOTE: The introduction of workgroups dictated a simplification of the preemption algorithm. Because the assumption that a higher subqueue indicates a more important process is no longer valid, the dependency on scheduling queue attribute was eliminated. The algorithm continues to compare priorities, only considering preemption if the priority of the potential preemptor exceeds the priority of the running process by the preemption threshold. If system and boosted processes are able to pass these priority checks, they can preempt the running process (if it is preemptable).

Quantum Bounds

The minimum and maximum quantum values bound the calculation of the workgroup quantum, which determines the rate of priority decay of processes within the workgroup. The quantum represents the average transaction time of processes within that workgroup. The consumption of CPU by a process is compared against the quantum to determine the amount of priority decay. Small quantum values mean most transactions are short, and process priorities will decay quickly. Larger quantum values indicate longer transaction times, and process priorities will decay more slowly.




	NOTE: All three system-defined workgroups that have decayable processes, the CS_Default, DS_Default and ES_Default workgroups, now perform a dynamic quantum calculation using a similar decay algorithm. The algorithm bases priority decay on the quantum divided by a constant, applying smaller amounts of priority decay for smaller amounts of CPU consumption. The default values for the minimum and maximum quantum for the DS_Default and ES_Default workgroups have remained the same to ensure that the quantum will not vary unless you choose to change the bounds. The traditional DS and ES subqueues did not provide this flexibility and had a fixed quantum value.

Boost Property

While the quantum controls the rate of priority decay, the boost property determines the behavior of the process once its priority has decayed to the limit of the workgroup. The default value of DECAY indicates that the process will decay to the limit and remain there until it completes its transaction. The value OSCILLATE indicates that if the process priority decays to the limit of the workgroup, its priority is reset to the base priority (the process oscillates between the base and limit priorities).

Timeslice

The timeslice is used to ensure that one process does not monopolize the CPU for long periods of time. When a process is launched, the Dispatcher guarantees that it will not run for more than its timeslice value (even if it is CPU-bound). The Dispatcher will actually take the CPU away from the process if it is still running after the timeslice interval has passed (provided that the process can be interrupted).




	NOTE: Before Release 5.0 of MPE/iX, CS subqueue processes were able to preempt DS or ES subqueue processes since they had a higher subqueue, and thus the timeslice values for the DS and ES subqueue were set high. These default values have now been reduced so that processes in these workgroups cannot monopolize the CPU for long periods of time. The timeslice value remains tuneable, however, and the system manager can adjust it to a higher value if it is appropriate to the environment.

CPU Percentage Bounds

User-defined workgroups also allow the specification of minimum and maximum CPU percentage bounds. The minimum percentage serves as a guarantee. Processes in a workgroup with minimum CPU percentage equal to 20% will be guaranteed 20% of the CPU(s), provided they have enough demand to use the 20%. If the processes demand more than 20%, they can receive more, providing it does not violate the minimum values for other workgroups. Thus, the minimum is a true minimum and can be exceeded. It is not a target amount.

The maximum percentage serves to restrict the CPU consumption of a workgroup. Processes in a workgroup with a maximum CPU percentage equal to 50% will never receive more than 50% of the CPU. If no other workgroups require CPU, the system will idle rather than allow the workgroup to exceed its maximum.

The sum of all CPU minimums should not exceed the amount necessary to provide sufficient "leftover" CPU for the system processes. As an alternative to guaranteeing a minimum to workgroups, the system manager might choose to set a maximum CPU percentage on a workgroup that tends to starve other workgroups. The maximum will constrain the workgroup to run within the allocated amount of CPU.