Defining resource groups

A resource group is an amount of processor capacity. It is optional. Unless you have some special need to limit or protect processor capacity for a group of work, you should skip defining resource groups and let workload management manage all of the processor resource to meet performance goals. You use a resource group to:
Note: Start of changeThe sysplex capacity values of the resource groups apply to general purpose processors only and not to specialty processors. WLM manages resource groups based on their consumption of general purpose processor capacity.End of change

You can specify a minimum and maximum amount of capacity to a resource group. You can assign only one resource group to a service class. You can assign multiple service classes to the same resource group. You can define up to 32 resource groups per service definition.

Keep in mind your service class goals when you assign a service class to a resource group. Given the combination of the goals, the importance level, and the resource capacity, some goals may not be achievable when capacity is restricted.

If work in a resource group is consuming more resources than the specified maximum capacity, the system caps the associated work accordingly to slow down the rate of resource consumption. The system may use several mechanisms to slow down the rate of resource consumption, including swapping the address spaces, changing its dispatching priority, and capping the amount of service that can be consumed. Reporting information reflects that the service class may not be achieving its goals because of the resource group capping.

By setting a minimum processing capacity, you create an overriding mechanism to circumvent the normal rules of importance. If the work in a resource group is not meeting its goals, then workload management will attempt to provide the defined minimum amount of CPU resource to that resource group.

Name
Eight characters that identify the name of the resource group. Each resource group must be unique within a service definition.
Description
Up to 32 characters that describe the resource group.
Resource Group Type
Resource groups allow to define a guaranteed maximum and minimum CPU consumption for work on the sysplex and on each individual member of the sysplex. This allows to:
  • Prioritize work on a system-level basis
  • Control the minimum and maximum resource consumption
The following types of resource groups are valid:
Resource Group Type 1
Start of changeThe capacity is specified in unweighted CPU service units per second, the value must be between 0 and 99999999. Only the service units used on general purpose processors controls the management of the resource group.

Minimum and maximum capacity applies sysplex-wide, that is, WLM ensures that the limits are met within the sysplex.

The table in CPU capacity table shows the service units per second by CPU model.

End of change
Resource Group Type 2
Start of changeThe capacity is specified as a percentage of the LPAR share in the general purpose processor pool, the value must be between 0 and 99, and the sum of all minimum LPAR share percentages for all resource groups of this type should not exceed 99.

Minimum and maximum capacity has a system scope, that is, WLM ensures that the limits are met on each system within the sysplex. Refer to Calculating an LPAR share — Example 1 for a scenario showing how to calculate an LPAR share when using resource group type 2.

End of change
Resource Group Type 3
The capacity is specified as a number of general purpose processors (CPs), a number of 100 represents the capacity of 1 CP. The number should be between 0 and 999999.

Minimum and maximum capacity has a system scope, that is WLM ensures that the limits are met on each system within the sysplex.

Capacity
Identifies the amount of available capacity you want workload management to allocate to the resource group. Capacity includes cycles in both TCB and SRB mode. The table in CPU capacity table shows the service units per second by CPU model. Resource group minimum can equal resource group maximum.
Maximum
Start of changeCPU service that this resource group may use. Maximum specified for this resource group applies to all service classes in that resource group combined. Maximum is enforced. There is no default maximum value. If specified, Maximum must be greater than 0.End of change
Minimum
CPU service that should be available for this resource group when work in the group is missing its goals. The default is 0. If a resource group is not meeting its minimum capacity and work in that resource group is missing its goal, workload management will attempt to give CPU resource to that work, even if the action causes more important work (outside the resource group) to miss its goal. If there is discretionary work in a resource group that is not meeting its minimum capacity, WLM will attempt to give the discretionary work more CPU resource if that action does not cause other work to miss its goal.

The minimum capacity setting has no effect when work in a resource group is meeting its goals.

Note: Start of change
  1. You cannot assign a resource group to service classes representing transaction-oriented work, such as CICS® or IMS™ transactions. The ISPF application notifies you with an error message if you attempt to define one. If you want to assign a minimum or a maximum capacity to CICS or IMS work, you can do so by assigning a resource group to their regions. For example, suppose you have three service classes representing your CICS works: CICSTRN, CICSAORS, and CICSTORS. CICSTRN represents all of your online CICS transactions, and has one period with a short response time goal. CICSAORS and CICSTORS represent all of your CICS AORs and TORs, respectively, that process the online transactions. To assign a maximum capacity to your CICSTRN work, define a resource group, and assign it to the regions. So you assign the resource group to the CICSAORS and CICSTORS service classes.
  2. Resource group capping is implemented by marking the work units that belong to resource group non-dispatchable for some time slices and dispatchable for the remaining time slices (awake slices). Depending on the configuration, it may not be possible to enforce very low resource group limits. The granularity to which a resource group limit can be managed depends on how much service the work can consume in a system or across the Sysplex, respectively, during one awake time slice. Beginning with z/OS V2.1 the granularity of awake slices is 1/256 of the time.
  3. While resource groups are managed based on the general purpose processor service the dispatchability attribute is also honored by zAAP and zIIP processors.
End of change