This chapter stresses Workload Manager (WLM) enhancements that complement or interact with JES2 or JES3 classical batch jobs handling. Among other things, it also speaks that from OS/390 V2R4 on, initiator can now be managed by WLM and no longer by the job entry subsystem (whether JES2 or JES3).

Indeed, WLM introduced in 1994, for handling workloads in parallel sysplex environments, was enhanced in 1997 (OS/390 V2R4) for managing resources “a la JES3”, at the sysplex scale.

Indeed, through this enhancement, WLM started to take the role traditionally assigned to the global system in a JES3 configuration.

Do you need to add a classification rule to WLM to assign the correct WLM service class to all the JES2 address spaces? JES2 itself is in the PPT with a systask set so it will not need attention, other than perhaps having a rule to classify it as a high importance STC. The other spaces, such as JESXCF, FSS, CI, and network must be looked at for your system.

WLM manages initiators based on the goals specified in their service class period. In z/OSV1R8, IBM further enhanced this functionality by extending the scope of batch management to be able to optimize the distribution of the batch workload across a sysplex. This functionality is called improved batch initiator balancing.

JES2 attempts to use approximately the same percentage of active WLM-managed initiators in each service class on each system. JES2 does not try to use the same number of initiators on each system; the number used is in proportion to the number started on each system. If WLM has started 20 initiators on system A and 10 on system B, and 15 jobs are submitted, 10 will run on system A and 5 on system B.

This balancing only comes into effect when there are idle initiators; most commonly when other jobs have finished but the initiator is still active. If there are no free initiators, jobs run wherever another job finishes, or WLM starts new initiators.

Initiator balancing does not necessarily keep the number of initiators the same, or keep all systems equally busy. It does stop one system from always selecting the work when there are free initiators elsewhere, which gives WLM a better picture of the workload when it is deciding whether to start or stop initiators.

GROUP initialization statements combined with MAINPROC, SELECT, and CLASS statements are used to determine the algorithms used for job selection. The more common scheduling functions are discussed here. See z/OS JES3 Initialization and Tuning Guide, SA22-7549 for more information.

The GROUP statement defines attributes that JES3 uses for initiator management. Each job class group is defined as containing either WLM-managed or JES3-managed initiators. For JES3-managed initiators, the GROUP initialization statement determines how many initiators to create and when (they can be started at IPL time, manually, or dynamically.). For groups that use WLM-managed initiators, that function is controlled by WLM.

The installation can have JES3 or Workload Manager (WLM) or both manage initiators for batch jobs. JES3 or WLM control of initiators is at the job class group level. To specify whether JES3 or WLM manages initiators for a job class group, the installation uses the MODE parameter on the GROUP initialization statement. If MODE=JES is specified or defaulted, the initiators are managed by JES3. If MODE=WLM is specified, the initiators are managed by WLM. The MODE parameter can also be changed dynamically using the *MODIFY,G command. A group must be either WLM managed or JES3 managed; it cannot be WLM managed on one system and JES3 managed on another.

There are a number of reasons why you might choose WLM initiator management over JES3 initiator management: Fewer and simpler externals exist.

Less externals are needed in JES3 to control WLM-managed initiators and to perform workload balancing. When the service administrator defines the performance goals and classification rules in the WLM policy, the system takes over the job of starting and stopping initiators.

With JES3 initiator management, it is the installation’s responsibility to determine the number of initiators to be started on each system, the correct mix of jobs, and so on. The externals do not reflect an actual performance goal, such as a one-hour turn around time for jobs in class X. How do you translate a one-hour turn around time into initialization statements?

With WLM initiator management, initiators are managed by WLM according to the service classes and performance goals specified in the WLM policy. The performance goals are typically expressed in terms that are found in service level agreements (for example, a one-hour turn around time).

The system adapts to changing conditions and how well the work is meeting its performance goals. The current JES3 initiator management puts the responsibility on the system programmer/operator to manage the work. Workload balancing algorithms used by JES3 are difficult to define and static in nature; they require an operator command and sometimes a JES3 hot start to change. But even if they can be changed easily, why should human intervention be required? An operating system can better perform these tasks.

WLM decides when to start initiators and how many to start based on performance goals and the importance of batch work regarding other work.

A WLM scheduling environment is a grouping of resource elements, each element having a specified required state, into a single named entity to be used in making scheduling decisions. The scheduling environment is either available (that is, all the resource elements are in the required state) or unavailable (that is, one or more of the resource elements are not in the required state) on an MVS image. When a scheduling environment is associated with a unit of work, it signifies the requirement for an execution environment providing ALL of the services/conditions needed for successful execution.

WLM scheduling environment is a kind of generalization of JES3 setup. In a JES3 complex, jobs using a WLM scheduling environment (SCHENV = on the job card) only run on systems where that scheduling environment is available.

The same is true for a MAS JES2 configuration for which it has been also a totally new function made available since 1997, starting with OS/390 V2R4.

If the job class of a batch job is used to assign its WLM service class, changes in the job class name that might result from the migration from JES3 to JES2 will need to be taken into account in the classification rules.

For virtual servers that run z/OS, you can map service classes from a Unified Resource Manager performance policy to z/OS WLM service classes to achieve end-to-end goal-based performance management for multitier applications. Through classification rules for the IBM defined EWLM subsystem type, z/OS WLM administrators can assign work requests that originate from virtual servers in an ensemble workload to service classes and report classes on z/OS.

The EWLM subsystem work requests include DB2 distributed data facility (DDF) requests that originate from an ensemble, through virtual servers (or hosts) that are classified within a Unified Resource Manager performance policy. Unified Resource Manager performance policies have service classes that specify either discretionary or velocity performance goals that the Unified Resource Manager uses to manage virtual servers in the ensemble workload. When you correlate these IBM zEnterprise® service classes to WLM service classes, you enable z/OS WLM to manage the work differently than it does for local z/OS work:

The configuration tasks necessary for mapping zEnterprise service classes to WLM service classes are described in z/OS JES3 Initialization and Tuning Guide, SA22-7549. Another relevant reference is z/OS MVS planning: Workload Management, SA22-7602.

To address WLM, your group can include ensemble workload administrators, performance management administrators, and z/OS WLM administrators.