Scott Chapman wrote: >>Or use WLM and change their job priority so they are in 'Siberia work >>priority'. (absolute low priority, so low, it is freezing)
>Discretionary work that's running on a system with available capacity will >run. And if in doing so, it's holding locks in DB2 or pushing useful data out >of the buffer pools, that might be unfortunate. Or say it's running at 6am, it >might drive up the R4H enough that the production LPAR hits it's defined or >group capacity limit at 8am when it normally wouldn't. >If you want to keep a workload from consuming anything (or nearly so) in such >a situation you'll have to use a resource group in WLM. >Note that running the work on another LPAR on the machine may also not keep it >from impacting the R4H in an undesirable manner as well. But there you also >have the option of setting a defined capacity on the non-production LPAR. And >that LPAR can have both a defined capacity limit as well as be part of a >capacity group for the entire CEC. Thanks. I believe the OP will find your comments very useful. About DB2 locks, we have several DB2 subsystems, so our development teams can use one of them to do their testing without impacting the bread-and-butter DB2 systems and the locks. It helps a lot if your developers and programmers are well-behaved. [1] Besides various measures (including jobclasses in RACF which we plan to use at z/OS 2.1.), we have in RACF accounting details so they are billed for resource usage. Groete / Greetings Elardus Engelbrecht [1] - They know for example that playing with or testing DB2 datasets, they may or may not impact scheduled FTP or ad-hoc jobs... ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
