George, I will give you the application developer's point of view. I can and have brought Dev/QA LPAR's to their knees with mistaken coding while developing new projects or updated programs. It isn't intentional, mind you, but mistakes happen. We are human.
Do you really want your production online LPAR being accidentally brought to its knees because of a developer mistake while testing new/updated code? I don't think my management would allow that, but YMMV. And QA with Development is also a problem for the same reason, but it goes both ways. When your QA analysts are running volume tests or clients are putting in a day's transactions to test out a major new update, the developers get short shrift of the CPU cycles (and there are never enough of those to go around anyway) and their project timetables are affected because they can't finish their programming work. Of course, the QA department doesn't want a developer mistake taking CPU cycles from them either because their project schedules are even shorter than are the developers'. In short, I would strongly advise you to keep PROD/QA/Dev LPAR's separated. I can't say though whether it's a good idea to have multiple Prod LPAR's or not. I'm not sure whether an Online LPAR and a Batch LPAR (or multiples thereof) are good or bad to consider, but I suppose it depends on the SLA's you have with your customers and what is important to them. Your sysprog sandbox of course should always stay separate so you can test PTF's and RSU's and new software versions. Just my USD$0.02, FWIW. Peter > -----Original Message----- > From: IBM Mainframe Discussion List [mailto:[email protected]] On > Behalf Of George Henke > Sent: Wednesday, February 17, 2010 10:27 AM > To: [email protected] > 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 This message and any attachments are intended only for the use of the addressee and may contain information that is privileged and confidential. If the reader of the message is not the intended recipient or an authorized representative of the intended recipient, you are hereby notified that any dissemination of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by e-mail and delete the message and any attachments from your system. ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
