>One other advantage of having the separate LPARs is that by using the >LPAR weights I can give preference to the total production LPAR over >what is running is development or the sysprog sandbox. In the instances >where the total CEC is near its max (month end processing), I would >prefer that development and the sandbox start feeling the pinch before >production does.
If your goal is to give preference to production work when the system is maxed out, I submit that you're better off having dev/test/prod all in the same system. We have multiple LPARs here: sys prog sandbox, a "legacy" two-way plex that has dev/test/prod all together in two LPARs (across two boxes) and one with 4 LPARs--two of which are supposedly dev/test and two of which are supposedly production. When a box gets maxed out, the "dev-test" LPARs continue to process work--consuming their share. On the "legacy" plex, dev/test work on the maxed out processor basically comes to a halt as WLM works to protect the production workload--as it probably rightly should. Is your dev/test work really more important than your production work? I agree that there are specific situations where it may be, e.g. some production batch that really doesn't need to be done "right now" but you have a developer sitting on their hands waiting on a compile. If you have dev/test in a separate LPAR on the machine, you probably aren't going to set the weight to zero to force dev/test to give up all their cycles, but WLM can come pretty close to that for work in the same LPAR. Having been in development, I understand the need for keeping some development moving, and separate dev/test LPARs are good for that. And I understand the warm fuzzy feeling one gets from deploying z/OS to dev/test first. But in my experience, new z/OS releases rarely cause application problems and in a production sysplex you can roll the OS to just one LPAR at a time, further reducing the risk. And as was previously pointed out, dev/test should have their own instances of WAS, DB2, CICS, etc. so new versions of the things that are more likely to cause problems should be rolled out to dev/test first. One final point: at least here, testing happens on the production LPAR even in that 4 way plex with the 2 dev/test LPARs. Why? Because those are the larger LPARs and so a long time ago the "system test" environment was put there so they could have the resources to run larger tests. That did cause us a problem yesterday in one of the few ways that dev/test still can impact production: a series of looping test jobs filled the spool. So even if you have separate dev/test LPARs, people will find a way to cause you trouble in production. ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
