As other posters have mentioned, and as I'll echo and agree, it's perfectly normal for CPU-bound batch to drive your z/OS system to 100% CPU utilization for some period of time. As long as you are meeting your service level agreements (SLAs), no problem. The system is doing exactly what it's supposed to do: allocate resources to execute your batch according to the service goals you've set while concurrently running other programs (such as online transactions) according to their service goals. Many, many customers are "batch peak" customers -- it's thoroughly common.
If you'd like to reduce your CPU consumption and thus (probably) lengthen the amount of time your CPU-bound batch job(s) take to run, you can do that -- if your business users find that arrangement acceptable. One way is to define a "softcap" either on an individual LPAR basis or across a group of LPARs. Note that a "softcap" allows the CPU utilization to spike above the cap but will definitively cap the 4 hour rolling average (4HRA). But there's absolutely nothing inherently wrong with 100% CPU utilization in z/OS. Often that's a good thing, actually, especially if you're meeting all your SLAs (including elapsed batch execution time) with just a "little bit" of margin to spare. In that perfect case it means you're getting your money's worth -- you've got exactly the right amount of capacity to meet the SLAs for the workloads you need to run. I don't recommend trying to second guess z/OS. Configure z/OS -- particularly WLM -- with the service goals you need according to your SLAs, and let z/OS figure out how to get there. Throw the batch jobs into the mix when they're ready to run, not later. Then control the overall utilization if you wish, particularly with one or more softcaps. If the critical online transactions go quiet when your call center loses power (for example), z/OS will run more batch (for example) at that moment in time -- and that's a very good thing. Let z/OS be z/OS and do its job(s) which it does very, very well. -------------------------------------------------------------------------------------------------------- Timothy Sipples IT Architect Executive, zEnterprise Industry Solutions, AP/GCG/MEA E-Mail: [email protected] ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
