I have read through several responses to this, and I agree with all of them. Performance wise, having less LPARs is probably better. Our shop is small and we have only on CEC with three LPARs (production, development, and sysprog sandbox). One purpose for the three is to be able to test new releases of the software without affecting production. Of course software like the operating system, CICS, and DB2 start in the sysprog sandbox. Once the system programmers are satisified it would move to the development LPAR and then to production. New releases of application code start in the development LPAR.
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. Tom Kelman Enterprise Capacity Planner Commerce Bank of Kansas City (816) 760-7632 > -----Original Message----- > From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On > Behalf Of George Henke > Sent: Wednesday, February 17, 2010 9:27 AM > To: IBM-MAIN@bama.ua.edu > Subject: LPARs: More or Less? > > 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 ***************************************************************************** If you wish to communicate securely with Commerce Bank and its affiliates, you must log into your account under Online Services at http://www.commercebank.com or use the Commerce Bank Secure Email Message Center at https://securemail.commercebank.com NOTICE: This electronic mail message and any attached files are confidential. The information is exclusively for the use of the individual or entity intended as the recipient. If you are not the intended recipient, any use, copying, printing, reviewing, retention, disclosure, distribution or forwarding of the message or any attached file is not authorized and is strictly prohibited. If you have received this electronic mail message in error, please advise the sender by reply electronic mail immediately and permanently delete the original transmission, any attachments and any copies of this message from your computer system. ***************************************************************************** ---------------------------------------------------------------------- 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
