November 21, 2016
This week, I am continuing this series on significance (the quality of being worthy of attention or importance). For this post, I want to focus on a component of z/OS called Workload Manager (WLM). It handles the varied and diverse work that runs in a z/OS system giving the individual jobs, started tasks and time sharing option (TSO) users the system priority desired by the business that’s running the software. The desired priority is expressed as definitions in the WLM policies. WLM policy is capable of implementing the diverse needs of insurance, banking, manufacturing and companies in many other industries both big and small. This flexibility makes WLM a truly significant component of z/OS.
Why Is a Workload Manager Needed?
One of the enormous strengths of the IBM z platform and the z/OS server is the ability to run multiple workloads at the same time within one z/OS image or across multiple z/OS images. Typically, workloads have different characteristics like real-time versus batch and competing resource needs like intensive CPU use versus substantial I/O. WLM is needed because these requirements must be managed in order to make the best use of the finite computing resources of a z/OS installation, maintain the highest possible throughput and achieve the best possible system responsiveness.
How Does It Work?
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 how much resource (e.g., CPU or storage) should be given to it to meet the goal. WLM constantly monitors the system and adapts processing to meet the goals. This is a simple explanation of a very complex task.
If you work with z/OS, you know about broad categories of work like batch, started tasks, TSO and online applications running as part of CICS and IMS address spaces. What aren’t so obvious are the workload variances within each of these broad categories. What variances? Within batch work there is usually production and test. Within production batch work there can be high and medium priority work. Within test batch, which can be defined as lower in priority than production, there can be high and low priority work. There can be a lot of granularity depending on the company’s actual workload bearing in mind that many of these workloads have evolved over decades.
To complete this example, you have to examine started tasks, TSO and online applications, even at the transaction level, to see how granular the demands are that can be placed on WLM. Fortunately, there are useful documents that help explain the possibilities like the Washington Systems Center's (WSC) sample service definition
download, which is intended to give examples of various WLM constructs.
This sample service definitions contains many service class periods. The number of service class periods that the WSC recommends customers to have active on a z/OS image is about 30 and this sample has over 60. The WSC defined so many for completeness to allow you to see examples of how to classify various work. Clearly you will not need to have this many service classes defined in your policy.
Here is a overview of the sample—
Find Out More
||batch, database and online workloads
||high priority batch and low priority SAP
||named LIMITRG to control quiesced non swappable work
||named WLMPOL containing goals related by service class
||JES class a production jobs and JES class z test jobs
||DB2 and IWEB
||RACCTRCV for account receivables and RCICSDEF for default CICS work
||MQ Series workflow EXE server
||DB_REORGSE for reorganization of DB timeframe and ONLINEPRODSE for production online timeframe
||DB2_PROD and PRIME_SHIFT
It’s difficult to understand WLM in such a short post but you can certainly get the big picture from exposure to some of the main ideas. Here are some ways to find out more
about this fascinating component of z/OS.
Posted November 21, 2016 | Permalink