This manual micro-managment is exactly what we do, by REXX, though. The problem is that batch gets unlimited resources as long as the lpar is not capped and chases your lpar into capping. So we try to avoid capping during online periods (07:00 - 19:00) by assigning batch jobs dynamically (by REXX) different service classes (discretionary, light brake, heavy brake), dependent on the 4h-average values of our production lpar group (2 lpars). This works pretty well for us.
- - Werner Kuehnel Spezialist in der Abteilung Betrieb/Support IMD-Gesellschaft für Informatik und Datenverarbeitung mbH Augustaanlage 66 68165 Mannheim Tel: +49.621.457-4885, Fax: -4046 E-Mail: [email protected] IMD-Gesellschaft für Informatik und Datenverarbeitung mbH Sitz Mannheim, Amtsgericht Mannheim HRB 7460 Geschäftsführer: Norbert Koch Von: "Joel C. Ewing" <[email protected]> An: [email protected] Datum: 19.02.2013 20:03 Betreff: Re: Low priority workload Gesendet von: IBM Mainframe Discussion List <[email protected]> It would admittedly be an unusual case where manual micro-management might do a better job than WLM, but just be aware that on a tight system, decisions to run lower-priority work that seem reasonable at the time could contribute to LPAR capping during the following four hours and adversely affect later high priority work. There could be times when humans with better knowledge of future workloads than WLM might be able to take preemptive action to delay or avoid LPAR capping to improve response to future high priority workloads. -- Joel C. Ewing, Bentonville, AR [email protected] ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
