I have to disagree. I often hear this, but there's no "resources" to give. Other than MPL adjustments, almost all of the major WLM decisions are simply a matter of setting dispatching priorities. There can never be a situation of where a lower priority [lower DP] unit of work can pre-empt a higher DP unit of work.
In addition, higher importance levels always have precedence in terms of having their goals honored, well above lower importance level work, so again, there can be no instance of where lower importance [lower priority] work can cause a higher importance level to miss its goals, except in the case of resource groups. In addition, WLM "predicts" the expected outcomes every 10 seconds, so there is no need to "know" future workload. Having excess available resources only ensures that those units at lower priorities have access. High DP work isn't subject to resource availability unless there are an excessive number of competitors at the same or higher levels. If all the processing power is used by high DP work, then there is nothing that can be done except incur delays, since [by definition] everything is either at the same priority or importance levels and no decisions can be made [likely result in "No donor found" or "No Net Value"] If I read your comment correctly, you're referring to only one specific instance where circumstances conspire to cap the CPU resource [which has nothing to do with your WLM policy]. In that situation your objective is simply to keep the workload below utilization thresholds so that peaks can exceed the cap and gain the extra CPU resources. It's not a question of micromanagement then, it's simply a matter of not running work if you know that heavier loads are coming that need to exceed the soft-cap. Adam >WLM bases its management on current resources and workload. It has no >way of "knowing" that giving available resources to lower priority work >now when resources may be plentiful may result in raising the rolling >4-hour MSU average to the point that in the future the LPAR may become >capped at a time of peak load of high priority workload, denying that >later high-priority workload the ability to use any CP resources above >the MSU cap to handle short-term peaks. ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
