Question:I am on OS/390 R3 and tried goal mode for the first time today. I discovered that WLM and a few other system address spaces are running in my discretionary started task service class! What happened? Answer: You probably have WLM and the other system spaces in your IEAICSxx parmlib member assigning them explicitly to a PGN for compatibility mode. Prior to OS/390 V2.4, this causes their HIPRI attribute to be lost. So when you switched to goal mode, WLM assigned the normal started task default which in your case was a service class with a discretionary goal. To restore the HIPRI attribute, you need to remove these started tasks from the ICS and re-IPL. Then when you switch to goal mode, these system address spaces will be assigned the proper default which is the SYSTEM service class.
This problem is fixed in OS/390 R4. In R4, the HIPRI attribute is remembered, even if you assign the started task to a PGN. Then when you switch to goal mode, HIPRI tasks get the SYSTEM default. In fact, V2.4 goes a step further for the WLM address space -- even if you put in a classification rule for WLM and attempt to assign it to a service class, it is still forced into SYSTEM.
For those who love detail, below is an explanation of how started tasks are assigned service classes and PGNs.
Default Performance Controls for Started Tasks
The dispatching priority and service class (or performance group) defaults for an address space created with the ASCRE macro depends on the ASCRE attributes and on whether the address space is privileged. Privileged for the purposes of this discussion means marked as privileged or as a system task in the Program Properties Table.
In both goal mode and compatibility mode, you can override these defaults by explicitly classifying the address space through the classification rules in the service definition (goal mode) or through the ICS (compat mode). The exception is the WLM address space in goal mode, which is always assigned to SYSTEM. Unless you have a specific reason to change the controls for system address spaces, you should allow them to default.
The table below describes the defaults:
Privileged
Not Privileged
ASCRE Attribute:
HIPRI
Goal:
SC = 'SYSTEM'
DP = x'FF'
Compat:
PGN = 0< br>DP = x'FF'
Goal:
SC = 'SYSTEM'
DP = x'FF'
Compat:
PGN = de fault for STC
DP = x'FF'
ASCRE Attribute:
NONURG
Goal:
SC = 'SYSSTC'
DP = x'FE'
Compat:
PGN = 0< br>DP = PVLDP Value
Goal:
SC = default for STC
DP = Managed to SC Goal
Compat:
PGN = default for STC
DP = value from PGN
Key:
DP = dispatching priority
PGN = performance group number
SC = service class name
STC = started task subsystem type
Question:What is the overhead of goal mode over compatibility mode? Answer: There is rampant misinformation circulating on the overhead of goal mode. The direct additional CPU processing in goal mode is typically around 0.5 to 2%. The exact cost for your environment will depend on multiple factors such as number of address spaces, amount of I/O, and volume of CICS and IMS transactions to sample. Some users, in fact, have seen a reduction in CPU time in goal mode because of better systems management over what they had specified in compatibility mode.
The one area to watch out for, though, is the MAXTASKS setting for your CICS regions. If MAXTASKS is set arbitrarily high, you incur unnecessary sampling overhead because a sampling control block is created for each potential task. Therefore, limit MAXTASKS to your high water mark plus a buffer. APAR OW32140 (still open, due to close by end of Nov. 98) will reduce the overhead of sampling the CICS regions if you are using velocity goals for the CICS regions and not managing the CICS transactions to response time goals.
"Adaptive algorithms for managing a distributed data process workload," an article from the IBM Systems Journal, Vol. 36, No. 2, 1997
A description of the concepts, rationale, and techniques behind WLM's algorithms.
