Job scheduling and WLM
This chapter describes the possible integration and exploitation of the WorkLoad Manager (WLM) component of z/OS®. Today, schedulers process different types of work with different completion and resource requirements. Every scheduler aims at making the best use of its resources, at maintaining the highest possible throughput, and at achieving the best possible system response. WLM makes this possible.
With WLM, you define performance goals and assign a business importance to each goal. You define the goals for work in business terms and the system decides the amount of resources, such as CPU and storage, it should provide to meet these goals. WLM constantly monitors the system and adapts processing to meet the goals.
You can also tell WLM which are the resources a job needs to run and WLM will run it on a system where these resources are available.
- Service Policy
- A named set of performance goals (eight characters long) that workload management uses as a guideline to match resources to work. When activated, a service policy is merged with the service definition and applies to all the Sysplex.
- Service Class
- A named group of work (eight characters long), within a workload,
with similar performance characteristics:
- Performance goals
- Resource requirements
- Business importance
- Resource Group
- A named amount of processor capacity (eight characters long) across the Sysplex. It can be associated to a service class in the service class definition.
- Classification Rules
- Define how to assign an incoming work to service classes and report classes.
- Application Environment
- A named group of application functions (32 characters long) that execute in server address space and can be requested by a client.
- Scheduling Environment
- A named list of resource names (16 characters long) along with
their required states. You can specify up to 999 unique scheduling
environments in a service definition, according to the following convention:
- Alphanumeric and the special characters @, $, #, and _ are allowed.
- Underscore (_) must be imbedded
The scheduling environment can be defined in the job card of a JCL (SCHENV=SE_name) so that, at submit time, WLM has a list of the systems where the job can run (a system where the scheduling environment is active), and pick one according to the active service policy.
When no system with an active scheduling environment is available, the job is not started and is placed on the WLM hold queue: it will be started as soon as the scheduling environment becomes active on a system within the Sysplex. If the scheduling environment does not exist at all, the job fails with JCL error
- Workload
- A collection of service classes. It is used for reporting purposes.
- Report Classes
- A group of work used for reporting.
HCL Workload Automation for Z is able to submit large quantities of work into z/OS® systems. The work is submitted only after a number of predetermined conditions are met, but the scheduler does not know the state of the system (in terms of load and capacity, but also in terms of resource availability) when the work is submitted.
- Running your workload as efficiently as possible, in order to complete all work according to your time requirements.
- Monitoring the workload constantly to detect any possible problems and fix them immediately.
- Service Class
- After the jobs are defined as critical to WLM (at the AD and CP operation levels), HCL Workload Automation for Z uses customizable criteria (either as a controller initial parameter or within the operation definition) to check if these jobs are running late: if they are, the scheduler moves them to the predefined WLM high performance service class.
- Scheduling Environment
- Integration is accomplished by:
- Associating a scheduling environment to the operations (via HCL Workload Automation for Z ISPF panels or programming interfaces). At submission time, the JCLs are tailored by adding the SCHENV=SE_name statement in the JOB cards. A pre-existing SCHENV keyword in the JOB card is taken into account depending on the OPCOPTS SECHECK parameter.
- Monitoring the scheduling environment as follows:
- If the associated scheduling environment is not available, the job is not submitted and is assigned the waiting for scheduling environment extended status.
- As the scheduling environment becomes available, an exit activated by one of the trackers forwards an event to the scheduler which then submits the job again.