Home

TUNING
   Letter
Table of Contents
Download Sample
CPU Chart
Subscribe

Articles

Videos

Cheryl's List

Software 

WLM GOAL MODE USING
A QUICKSTART SERVICE POLICY 

You've been running in SP 5 WLM compatibility mode for a while and you want to move to goal mode soon. But where to start? Here's an easy method of getting there - a "Quickstart" Service Policy. It's a simple, generalized service policy that will work in most installations as a starting point. Our "Quickstart" service policy provides a standard set of service classes and goals that you can easily use or modify for your initial policy. 

Once in goal mode, you'll have access to WLM's superior resource management and a wealth of measurement data that makes tuning a real breeze!

INTRODUCTION

The migration to Workload Manager (WLM) goal mode in MVS SP 5 and OS/390 may seem intimidating at first, but it can be quite simple. In this paper, I'll introduce a simple service policy I've designed that can be used by most installations. It should ease your migration to goal mode.

Some installations have used this "Quickstart" policy with little modification and began running in goal mode within a week or so. I think you'll find it an easy way to start your own migration.

This paper assumes you have a basic knowledge of WLM. If you're not familiar with service policies, service classes, and goals (response, velocity, and discretionary), please refer to the bibliography at the end.

KEEP IT SIMPLE

For years, the people maintaining IPS and ICS members have found that simplicity has its rewards. Not only is there the ease in making changes to your IPS/ICS parameters, but there is also the simplicity when reporting or explaining the system, and the reduction in system overhead to process the resulting data. Sites with only a couple of dozen performance groups take much less time and space to process their data than sites with several hundred groups.

The same reasons to keep things simple hold true when defining a service policy, only more so. The performance is considerably better and WLM is much more effective with a simple definition containing a few service class periods than with a definition with hundreds of periods. A simple service definition is also easier for you to maintain. While you should try to keep the total number of service class periods to a minimum for simplicity, you should know that there is little effect on performance if you choose to add several service classes with a discretionary goal or report classes.

Therefore, I have applied a single rule-of-thumb in providing these recommendations: "Use the minimum number of service definitions, policies, workloads, resource groups, service classes, service class periods, and classification rules that you can get away with." In other words, start small and add only when you need to.

You could begin with my "quickstart" service definition and add to it as you find a need. Start with a single service definition and service policy. A single policy may work just fine around the clock. Define a simple set of workloads and service classes and only use multiple period service classes when you have a specific requirement, such as with TSO.

Workloads and service classes for my "quickstart" service policy are shown in Figure 1. The importance (the "Imp" column) is set by each installation based on the workload priorities. The corresponding classification rules are shown in Figure 2, and the classification groups are in Figure 3. 

This is a very easy service definition to implement, and it only contains twenty service classes. Most current performance groups should easily fall into one of these classes.

The SYSTEM, SYSSTC, and SYSOTHER service classes are standard service classes defined by WLM. You may indirectly assign any work to SYSSTC and SYSOTHER, but not SYSTEM.

WLM GOAL MODE USING A QUICKSTART SERVICE POLICY

To be able to use this quickstart policy, you'll need to make some initial assignments. The quickstart policy is described below by subsystem, and describes the purpose of each service class and any initial decisions you might need to make. 

With service classes using response time goals, I've recommended starting with percentile response time goals. Percentile goals are much better to use since they're easier to achieve and provide a more accurate picture of what the user is experiencing. A single long job or transaction won't affect a percentile response time but can greatly affect an average response time. You may prefer to start with average response time goals since you can obtain average response times directly from your RMF, CMF, or SMF data. After you've been running in goal mode for a short period of time, you'll be able to determine percentile response time goals to use instead of averages. 

STARTED TASKS (STC) 

I defined four service classes for started tasks (ONLPRD, ONLTST, STCMD, and STCLO). The system automatically defines two (SYSTEM and SYSSTC). 

• SYSTEM will be automatically assigned by WLM to system address spaces such as master scheduler and CONSOLE. These address spaces will run at dispatch priority 255. You can't assign any address spaces to SYSTEM, although you can prevent some of the system address spaces from being assigned to SYSTEM by assigning them to other service classes. I would be hesitant to do this unless you're very sure of what you're doing. 
• SYSSTC is the default service class assigned by WLM to any started task that isn't otherwise assigned by you. It runs at dispatch priority 253, so you really shouldn't allow low-importance started tasks to fall into this service class. (Note that APAR OW19265 changes the DP to 254.) You can assign any high-importance tasks here such as VTAM, JESx, VLF, LLA, RMF/CMF, monitors, auto ops packages, the OMVS kernel, APPC and ASCH. I've designated a transaction name group (TNG) in Figure 3 to be used for these called STCHI. In STCHI group, you can place all of your high importance started tasks. There isn't a velocity goal associated with SYSSTC, but rather what the workload manager terms a "system goal." 

 

 
 
 

Transaction name groups (TNG) and transaction class groups (TCG) are used to easily create lists of names or classes that are to be assigned to the same service classes. I normally use the service class name as the group name for simplicity. Classification groups are assigned in the WLM ISPF dialog. 

Since you can't directly assign work to SYSSTC using classification rules, you need to code the rules for STCs in a special manner. SYSSTC can only be obtained as the DEFAULT for the STC subsystem. To assign classification groups to SYSSTC, use the following technique in the WLM ISPF screen for assigning service classes: 

TYPE VALUE SVC CLASS
DEFAULTS _______
TNG STCHI _______
TNG STCMD STCMD
TN * STCLO

STCLO is discussed later.

This technique is described in the WLM Planning manual described in the bibliography. 
 

• ONLPRD is a single service class for your production CICS, IMS, DB2, and other online regions. This service class can be used even if your online systems are running as batch jobs. This is set with a velocity goal above batch. For the quickstart policy you can use a transaction name group called ONLPRD that would contain the started task names of your CICS, IMS, DB2, ADABAS, ROSCOE, IDMS, and WYLBUR address spaces. I'd recommend, however, that you place the test online regions in ONLTST (described below). The reason for this is that test online systems tend to get into loops and you don't want looping jobs that run in high velocity service classes. CICS V4 and IMS V5 regions can be assigned to ONLPRD for initialization. After the subsystems are initialized, the regions will actually be managed according to the CICS or IMS subsystem goals (described later). 

 

 
 
 

If you're not running in a constrained environment, you can assign all of these address spaces to the same service class with a velocity goal. If you're running in a constrained environment, you may want to monitor your primary online systems during peak intervals and determine the velocity that they now receive. If there are varying velocities (e.g. 20%, 40%, and 60%), then set up different service classes for each velocity. You might end up with ONLHI, ONLMD, and ONLLO service classes. In a constrained system you might want your IMS control region and CICS TOR (terminal owning region) running with a higher velocity goal than the IMS message processing regions or the CICS AORs (application owning regions). 
 

• ONLTST is a service class that can be used for test online address spaces. It would have a discretionary or low velocity goal. As I mentioned before, I would tend to keep the online test regions in a separate service class from production since the transactions in the test regions have a tendency to go into loops. I defined a separate service class in order to assign them to the ONLINE workload. If you don't need to summarize these test regions with the production regions, you could simply assign the regions to STCLO as described below. 

• STCMD should be used for relatively high-importance started tasks that should be run below your online regions. I provided a STCMD transaction name group that can be used to contain all of the STC names in this service class. This service class will be unique between installations, but might include such products as your scheduling products, printer management products, and high importance operations jobs.

• STCLO is the service class used for all other started tasks and should be assigned a discretionary goal. See STCHI for the technique in assigning this. It will contain all started tasks not assigned to any of the other service classes. You may implement this scheme only to find a few address spaces that aren't performing as well under goal mode. If so, you can move them and later define them in one of the other started task classification groups. As mentioned above, you could also include any online test regions in this service class. 
BATCH JOBS 

The quickstart policy has five service classes defined for batch jobs, divided between test and production because most installations tend to manage their batch work in those two categories. 
 

• PRDBATHI - You may not need to assign anything to this service class initially. It's meant for high importance production batch jobs to help them complete on time, and isn't needed if you can easily meet your production deadlines (i.e. an unconstrained system at night). It can also be used for operators who need to increase the importance and velocity of a job with the RESET command. 

 

 
 
 

In a constrained system, you could identify critical path jobs and give them a unique jobclass or accounting code in order to assign them to this service class. I defined a TCG (Transaction Class Group) of PRDBATHI for use with unique jobclasses, but you could easily change it to a TNG (Transaction Name Group). The PRDBATHI service class can run with a velocity goal, while other production batch runs as discretionary. 
 

• PRDBATLO is for all of the other production batch jobs and would be assigned a discretionary goal. In an unconstrained environment, where the nighttime batch easily completes before morning, this will be all that's needed. 

 

 
 
 

PRDBATLO is the default service class for all batch jobs in this Quickstart policy. 

In a constrained environment where the critical batch jobs might not complete before morning, you can assign the majority of jobs to PRDBATLO and the jobs on the critical path to PRDBATHI. Most of the jobs (PRDBATLO) would run as discretionary while the critical jobs would run with a low velocity. If WLM needed to steal some resources, it would look at the jobs in PRDBATLO first. 

Some sites may need to define a medium importance and velocity service class, PRDBATMD, as discussed later. PRDBATLO is also the service class I've used as a default in the quickstart policy. Depending on your installation, you may want to use test batch as the default class instead of production batch. 

One more consideration for production batch is to determine if there's a need to run production batch during the day while test batch is running. In that case, you may want to define only test batch with a discretionary goal and define production batch with a low velocity goal so that production is always preferred to test. 
 

• TSTBATHI is the service class used for short turnaround batch job classes. For most installations the turnaround time from job submission to execution completion is between 10 and 20 minutes. Since most installations set up a separate jobclass for these short jobs, I've included a classification group for transaction classes called TSTBATHI where you can define the job classes. You need to have a rate of at least ten completions in a twenty minute period to be able to use response time goals. You can determine the rate of completions by looking at any RMF workload activity report at the ENDED field, which provides the number of transactions (or jobs) that ended during the interval. Divide that number by the number of minutes in the interval to determine if you have enough activity to use a response time goal. If you don't have this volume of activity, you'll need to change the goal to a velocity goal. 

 

 
 
 

You can determine the current average response time by looking at RMF, CMF, or SMF data for these jobs. In an RMF Workload Activity report, for example, the ACTUAL (or TOTAL for RMF releases prior to V5) response time is the average response time from job submission to termination. I've defined this with a percentile response time goal, but you could start with average and change it after you've collected more response data. 
 

• TSTBATMD can be used for longer test batch jobs, typically with a twenty to thirty minute turnaround. If you have several of these jobs (at least ten completing every twenty minutes so that WLM can obtain adequate sampling) you can use a percentile response time goal. If the activity is lighter than that, you'll need to change the goal of this service class to a velocity goal. 

• TSTBATLO would be used for the remainder of the test batch jobs. This service class uses a discretionary goal and contains all jobs not assigned to the other test batch service classes. You may prefer to use this service class as the default for the JES subsystem instead of PRDBATLO which I used. 

 

 
 
 

It's possible that your installation doesn't use jobclasses to differentiate test jobs since you use multiple periods to determine short, medium, and long. In that case, you can simply define one service class, such as TSTBAT, containing three periods with different goals for each period (similar to the three classes I've just described). 
 

TSO 

The quickstart policy defines a single TSO service class, TSOPRD, with three periods. It's set up using percentile response time goals, but you could start by using average response times corresponding to the current response times you see reported by performance group period. 

The response time goal on third period assumes that the activity is high enough (ten transactions every twenty minutes). Use a velocity goal for third period if the rate is low. 

TSOPRD is the default service class for all TSO users in this Quickstart policy. 

ASCH 

The majority of installations aren't running APPC/MVS workloads but soon will since OpenEdition MVS uses APPC/MVS for its implementation. There are several started tasks that can be assigned to service classes. The APPC and ASCH (scheduler) started tasks (you can change the name, of course) intercept and manage all of the APPC/MVS work. Therefore, these tasks should be run in the SYSSTC service class. 

The transaction programs (TPs) are the applications that process the requests coming from APPC/MVS clients. The characteristics of these programs will determine the actual goals. Many are long-lived started tasks with little resource usage and others are short-lived tasks with very high resource usage. You can monitor each one and place them in appropriate service classes, such as STCMD or STCLO. Because of their nature, the TPs are best managed with velocity goals. 

The APPC and ASCH address spaces are assigned in the STC subsystem, but the actual APPC/MVS TPs are assigned in the ASCH subsystem. 

The quickstart policy has a single service class, ASCH, defined with two periods: a percentile response for short transactions and a velocity goal for longer work. If the volume of ASCH transactions is not high enough, at least 10 transactions in twenty minutes, you can use a single period with a velocity goal. 

OMVS 

OpenEdition MVS (OMVS) transactions will be new to most installations. The Kernel for UNIX is similar to the master scheduler for MVS so the started task for the OMVS Kernel should be run at a very high priority. You can assign it to the SYSSTC service class. OMVS daemons are long-living started tasks that perform continuous or periodic system-wide functions such as network control. These started tasks should be assigned to STCMD in the STC subsystem. 

Actual OMVS transactions, the forked children, are classified in the OMVS subsystem. (Don't you just love UNIX terminology?) Due to the characteristics of OMVS transactions, some of which have short response times and high resource usage and others which have long response times and low resource usage, a service class similar to ASCH is the best place to start. 

CICS V4 and IMS V5 

These subsystems provide additional WLM support to allow you to assign response goals by transaction, subsystem, transaction class, or userid. If you install either of these versions while still running in compatibility mode, turn on collection of average response times. This will give you better data to let you set response time goals when you migrate to goal mode. The sample service classes that I've shown in the quickstart policy can be used as a starting point. Caution: you may see overhead (5%-10%) while collecting this data.

An important item to keep in mind is that there are two possible users of the transaction response time data. WLM will look at the goals and the actual response times of the transactions being processed by an address space. If goals aren't being met, WLM can respond by finding additional resources for the address space. But WLM can't really divide its resources among the transactions -- it only manages address spaces. If you have short transactions with high importance and long transactions with low importance in the same address space, WLM can't help the high importance transactions without giving a free ride to the low importance transactions. 

That's where other products come into play. For example, CICSPlex/SM can route transactions to multiple address spaces. If it sees a transaction that needs a short response time, it can route the transaction to the address space that's providing short response times. If it sees a transaction that doesn't have an aggressive response time goal, CICSPlex/SM can route the transaction to an address space that isn't providing wonderful response time. 

Thus, it will do you little good to separate your transactions into multiple service classes if you'll end up letting WLM manage a single address space. You could still define a single service class for your most important transactions and set a response goal for them. If they don't make their goal, WLM can try to find more resources for the address space to help the short transactions. Other transactions in that address space will see some benefit as well. 
 

• ONLPRDHI is a service class for the transactions that should be completed in the shortest response time. Percentile response times are the best type to use, so 80% completed in .5 seconds would be a reasonable starting point for short online transactions. I've indicated that you might use a transaction name group, ONLPRDHI, to allow easy classification by transaction names. You may have them divided by classes, userids, or even subsystem instances (e.g. VTAM applid), so change the group to correspond to your classification. 

• ONLPRDMD would be the service class for the majority of the transactions, if not all the rest. 80% within 3 or 4 seconds should handle the majority of online transactions. If the majority of transactions fall into this service class, assign this as the default for the subsystem. Then simply assign any high or low transactions to the other two classes. 

• ONLPRDLO would contain the transactions which don't need to get wonderful service, and it's the default for the CICS subsystem. You can also use it for all the transactions from a specific subsystem instance (such as a test or development region). You could set this up with a very attainable goal, such as 50% complete within 10 seconds. By assigning low importance and long-running transactions to a separate service class like this, you're eliminating them from the service class that is trying to meet a response goal. Since WLM doesn't really manage transactions, but manages address spaces instead, this low response time goal will allow these long running transactions to live in regions that are really being managed to provide response times for more important and shorter transactions. It essentially eliminates them from consideration. You can't use velocity goals with the CICS or IMS subsystems. 
MODIFICATIONS TO THE QUICKSTART POLICY 

There are several modifications that you'll want to make to the quickstart policy either initially or after you've collected data under goal mode. 

Initial Definitions 

1. Determine the batch job classes for production and test and set up the transaction class groups as defined in the quickstart policy. Also determine the started task names and online transaction names for the transaction name groups as described above. 
2. If you run test batch as multi-period in a single jobclass rather than different jobclasses, then set up a single test batch service class with multiple periods to use instead of TSTBATHI, TSTBATMD, and TSTBATLO. 
3. If you run TSO with more than three periods, then change the quickstart policy to match the current number of periods. Use your current average response time from RMF or CMF to set response goals for each period if you've been collecting the data or have already set response objectives. 
4. If you've been running CICS V4 or IMS V5 in compatibility mode, use the average response times you collected from the performance groups in compatibility mode to set average response time goals for the service classes in goal mode.
5. You may want to add a "HOT" service class for use by the operators. The quickstart policy provides several service classes that the operator can reset jobs to, but you may want to be able to identify the occurrence of these resets. In that case, create a "HOT" service class with a high velocity (60% or 70%). Some sites may even choose to have a "HOTTSO" and a "HOTBAT" service class. You should use only a velocity goal on these service classes since the number of job or transaction completions will be quite small. 
6. If you're running many online systems in a constrained system, then consider setting up multiple service classes instead of assigning them all to ONLPRD. You could set up three service classes, for example, with velocities of 30%, 40%, and 50% depending on the velocities that are seen during compatibility mode. Use a minimum number of velocities. That is, if four performance groups currently have measured velocities of 46%, 49%, 52%, and 54%, assign them all to a single velocity goal of 50%. 
7. Set the service definition coefficients (SDCs) by selecting option 8, Service Definition Coefficients, from the WLM Definition Menu. If you don't currently have a reporting system that uses service units, you can use my recommendations: 
CPU=1.0, SRB=1.0, IOC=0.1, MSO=0.0.
If you've been using other SDCs prior to going to goal mode, you may have to alter your duration values when setting multi-period service classes. This is because the duration is the sum of all service units (CPU, SRB, IOC, and MSO) and if you change the coefficients, you'll change the rate at which jobs accumulate service units. Another combination that will keep the same relationship between CPU and I/O is:
CPU=1.0, SRB=1.0, IOC=0.5, MSO=0.0 
OTHER MODIFICATIONS

Here's a list of some other changes you might want to make to the quickstart policy as you need them. 

1. First, you should make sure that you've set the current response times accurately. Compare the response times after moving to goal mode to those during compatibility mode. Be sure you understand any differences. If some workloads are getting poorer service in goal mode than compatibility mode, perhaps it's because another workload was given too good a goal. Make goal adjustments before attempting other changes, but review the following modifications in case they could help solve a problem. 
2. After you've been collecting response times for a short time (a day to a week) in goal mode, you can change any average response time goals you might have set to percentile response time goals. The RMF/CMF reports will show you what percentiles are currently being met. Percentile response goals allow you a greater possibility of meeting your goals consistently because a single long-running transaction (job in loop, etc.) will simply fall into the percent of jobs that don't complete within the goal. On the flip side, however, if you're missing the goal for percentile responses, you're probably severely constrained (or have set the goals wrong). 
3. Some installations will have a need for a medium velocity production batch because they have some "hogs" that they want to run lower than all other batch. In that case, you'd define PRDBATMD as the default for the production jobclasses, and specifically assign those jobs to the PRDBATLO service class. In order to keep the PRDBATMD slightly above the PRDBATLO service class, you can set a low velocity goal of 5% to PRDBATMD and leave PRDBATLO as discretionary. When WLM needs to steal resources, it will look at the discretionary work first. 
4. If you have problems with quickly starting your online system in the middle of the day after an unscheduled down, consider this suggestion from Gary Hall of Washington Systems Center. He suggests defining a two period service class for these regions with the first period long enough to complete initialization and set with a very high velocity goal. Second period would then run at the normal velocity for your online region. 
5. DB2 is a very resource intensive subsystem and some installations will want to keep DB2 in its own service class. It will need to be set up in a service class with a velocity goal. Remember that much of the DB2 activity is reflected in the caller's address space (CPU time and paging). In SP 5.2 and DB2 V4 (with the Distributed Data Facility, DDF), users can set response goals for distributed DB2 transactions. 
SUMMARY 

I've just described a service policy that can get you started into goal mode. Just remember the original concept of "keep it simple," and you'll find your migration will be easy and produce a very usable service policy.

BIBLIOGRAPHY 

Basics: 

IBM, "MVS/ESA Planning: Workload Management," GC28-1493. 

C. Watson, "WLM Goal Mode," Cheryl Watson's TUNING Letter, March/April 1995. 

P. Enrico and E. Berkel, "Effective Use of MVS WLM Controls," Cheryl Watson's TUNING Letter, March/ April 1995 and CMG Trans. 87, 21-38 (1995). 

For further reading: 

C. Watson, "WLM Classification," "A Quickstart Policy," and "WLM Measurements," Cheryl Watson's TUNING Letter, May/June 1995. 

C. Watson, "How to Set Velocities," Cheryl Watson's TUNING Letter, 1996, #3. 

IBM, "WLM Performance Studies," GG24-4352.