>From a pure performance standpoint fewer is probably better (less overhead).
WLM balancing should be possible if you want to mix DEV, UAT, PROD on the same LPAR but there is always the possibility of a DEV or UAT task impacting PROD in any number of ways that might not have as large an impact on separate LPARs (depending on setup of course). Perhaps the largest reason for separate LPARS is phased implementation of software (system & program products) that might be more cumbersome or even impossible in a shared LPAR environment. The assumption is that only limited testing can be performed in a sandbox LPAR and to get a larger workload and more variability you need to implement in a DEV and/or UAT environment. >From a DR perspective it may be easier to control if you only have to worry about your PROD LPAR (assuming you don't need to have DEV and UAT at DR) although I imagine that in a 'true' disaster you would probably have to have all environments if your main site is out of commission for long enough. Ken Porowski VP Mainframe Administration CIT Group -----Original Message----- George Henke Here is what I thought was a dumb question until someone posed it to me yesterday. Why have a separate QA LPAR and not just leave QA in the DEV LPAR? The more I tried to come up with a good reason, the more I could not find one. Then I started to take the logic to its extreme and ask myself, "Why do we have LPARs at all? Can't MVS (z/OS) handle it? Why replicate the z/OS operating system a gazillion times when z/OS already has everything needed. I know single point of failure at all that jazz, but then what do we have a DR box for anyway? If it were really my money I was playing with, would I have sooooooo many LPARs just for neatness or so-called integrity, control, apple pie, and motherhood? I know RAS, Reliablity, Available, Serviceability. But that cannot be achieved with a single instance of z/OS, a software sandbox, and a DR box? Don't we already logically separate DEV, TEST, UAT, and PROD in separate CICSes, DB2s, etc. Why then do we need to separate them physically in their own LPARs, incur the addition cross LPARpay hire licensing fees (not counting sub-capacity licensing) only to bring them all back again logically with SHARED PARMLIB, SYSRES, MASTERCAT, JESPOOL. Is this just IBM's and ISVs way of making more money? These are hard questions like, "Is the emperor really wearing anything?". Are fewer LPARs necessarilly a bad thing? After all there is L ---------------------------------------------------------------------- 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
