You are currently on IBM Systems Media’s archival website. Click here to view our new website.

MAINFRAME > Tips & Techniques > Application Development

Lessons Learned on Workload Manager

When I started at this shop, I was gung ho about converting to transaction goals, but after looking at response time, I realized that it wouldn’t make sense to do the conversion. I have mentioned this on various discussion forums and have been pilloried regarding this unconventional approach.


I implemented Workload Manager (WLM) goal mode in January 1999 and it was a very successful project that I’m proud to have on my résumé. But, all things considered, there are choices I made then that I wouldn’t today. This article re-examines how I would either implement or review parameters in the WLM.

Service Definition Co-Efficients (SDCs)

Prior to goal mode, IBM had always recommended that the four co-efficients be:

  • CPU (TCB time): 10
  • SRB (SRB time): 10
  • IOC (EXCPs): 5
  • MSO (Main storage) 3

With the introduction of large storage allocations on modern mainframes and 64-bit addressability any value for MSO would overshadow all else and make it the main determinate of the size of transaction period. This would penalize any address space in a memory-rich environment with no paging, and even more so with 64-bit, since expanded storage never counted in the MSO calculation and, since converted to real/central, it does. This may seem like an old topic, but there are still many shops that have a non-zero value for MSO.

With the introduction of resource classes, IBM has recommended (along with many renowned experts) that the co-efficients be changed to:

  • CPU (TCB time): 1.0
  • SRB (SRB Time): 1.0
  • IOC (EXCPs): 0.5
  • MSO (Main Storage) 0.0

This is due to resource classes only using unnormalized CPU service for their definitions. Of course, changing the SDCs would mean that all service class periods depending on service units would also need to be modified. This can be done using RMF data reporting on service classes.

Resource Classes

I’ve never seen a reason for using resource classes to cap a workload; I’d use one to guarantee a minimum service to one, such as for a test batch. The amount to define for the minimum, as always, depends on the workload requirements and what service level you wish to assure. This sounds like a bit of a cop out, but performance is always in the eye of the analyst and can’t be decreed by anybody outside of your own organization.

There have been arguments that the resource class definitions have to be changed as processors are upgraded. I don’t totally agree with that. Since resource classes only use unnormalized CPU (trusted computing base) service, you can just guarantee a minimum CPU consumption that doesn’t change as the processor is upgraded. This is a method of enforcing an almost fixed test resource usage even as the processing environment gets larger. Of course, this is a minimum, so if the resource is available more will be used.

With z/OS* 1.8, and later, resource groups can be defined as percentages of a processor. I don’t agree with this definition because there can be many processors in a Parallel Sysplex*, with differing capacities. So, how do you reconcile the resource class within a Parallel Sysplex with varying sizings, unless the workload is restricted to a single processor? At least with service units, resource minimums can be controlled. Also, as your processor capacity increases, the amount reserved for these workloads will go up. In my opinion, this defeats the purpose of this, if you are intending to keep the resource usage down at peak times.

Ted MacNeil is a capacity/performance analyst with more than 25 years in the IBM mainframe environment. Ted can be reached at tedmacneil@alumni.uwaterloo.ca.



Advertisement

Advertisement

2019 Solutions Edition

A Comprehensive Online Buyer's Guide to Solutions, Services and Education.

A Beginner's Guide to the REXX Programming Language on z/OS

Reading and Writing Files in the REXX programming language on z/OS.

MAINFRAME > TIPS & TECHNIQUES > APPLICATION DEVELOPMENT

Application Management is Important to the Entire Process

MAINFRAME > TIPS & TECHNIQUES > APPLICATION DEVELOPMENT

Application Testing: Giving Users What They Need

IBM Systems Magazine Subscribe Box Read Now Link Subscribe Now Link iPad App Google Play Store
Mainframe News Sign Up Today! Past News Letters