On Tue, 23 Feb 2010 10:56:19 -0500, George Henke wrote: >... my client, who is relatively >small, questioned a very specific thing, basically: "Why would I NOT keep >QA in the same LPAR with DEV. Why create a new LPAR just for QA and incur >$6 million of additional software costs."
Good question. Your experience with this seems to differ from others who have responded. Do you really expect to incur this additional software cost? Have you analyzed the reasons for it? >My knee-jerk reaction, of course, was, "Because everyone is doing it and it >is 'best practices'". "best practices"? Says who? >I started questioning the merits of having LPARs at >all and opened the question here with the hope that someone could. > >And so far there does not appear to be any. > >To summarize, thus far it has been argued: > >*Pro:* z/VM in microcode is more efficient. To pick a nit, there is no microcode on a z9 or z10. There is millicode, which is quite unlike microcode. PR/SM is likely more efficient than z/VM because it doesn't do nearly as much. If you had a z/VM that supported only V=R guests and dedicated devices it might be just as efficient as PR/SM. >*Pro:* You can isolate workloads better and give customers and clients >better isolation and security. There may also be requirements mandated by >law. >*Con:* But that isolation is seriously compromised when after creating a >separate LPAR, it is all tied back together with shared SYSRES, SYSCAT, >PARMLIB, PROCLIB, JESPOOL for support, when "best practices" call for >sharing everything at the system level as much as possible? If you share everything then you are not isolating anything. Sharing PARMLIBs, PROCLIBs, SYSRES, SPOOL and master catalog between LPARs does not make you any more vulnerable than running a single LPAR Again with the "best practices"? I don't think anyone has used the phrase in this thread except for you. I don't like the term. It seems to me that people like to use it to claim that their way is the best. >*Pro:* With LPARs it is possible to take advantage of IBM's "sub-capacity >pricing" algorithm and save millions. >*Con:* Yes, indeed. IBM's "sub-capacity pricing" algorithm encourages it. You started by saying that a new LPAR was going to cost you $6 million. In your case, will it save you money or cost more? >I like to think that, as a general rule, a software solution will always >beat a hardware solution operationally, economically, and financially. Is that based upon intuition or analysis? I do agree that a single well-defined WLM environment will perform better than multiple ones. >But with PR/SM the trend seems to be in the other direction. > >Such a policy might favor IBM and ISVs, and with IBM's "sub-capacity >pricing" algorithm, it might even favor us in the short-run, but in the >long-run it is making us more dependent on and constrained by the hardware, >not less, and so is sub-optimal. I don't follow your logic. How does using PR/SM make you more dependent on z/Architecture to run z/OS? -- Tom Marchant ---------------------------------------------------------------------- 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
