Peace, Shmuel, nol contende. Intelligent people can disagree and still be friends.
This whole brainstorming exercise started when 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." My knee-jerk reaction, of course, was, "Because everyone is doing it and it is 'best practices'". But it immediately became apparent how ridiculous that logic or lack thereof was. And the more I tried to find a justification, a good reason, for not defying this "best practice", the more I could not find one. And when I could not, 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. *Con:* Those efficiencies quickly disappear and are more than offset by the additional CP overhead incurred by the cross LPAR handshaking that must occur for shared I/O. Please see Cheryl Watson's newsletters on this. She points this out and elaborates on it. *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? Indeed, one of the vital functions "system symbolics" performs is to allow for this sharing, particularly in PARMLIB. True there are times when there should be a "chinese wall" built around certain sensitive workloads and then LPAR is certainly needed. But these is more often the exception, than the rule. *Pro:* The complexity of knowing both z/VM and z/OS makes it too hard to find people who know both. *Con:* Having installed both in total more than a dozen times myself, the latest being z/VM 5.4 last November, and having known and worked with sooooooo many others far more knowledgeable than I, not to mention the competition at interview time for both these skill sets, this is simply not true. *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. But is this necessarilly something we should be encouraged to be doing, ie proliferating z/OS otherwise needlessly, carving up memory, just to take advantage of a favorable pricing algorithm. Are we being led down the primrose path? I like to think that, as a general rule, a software solution will always beat a hardware solution operationally, economically, and financially. 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. It is all somewhat reminiscent of the old MFT days when everything ran in partitions. There were all kinds of inefficiencies introduced when we ran things in fixed partitions then. Certain jobs could not start because they needed a certain amount of memory, devices or system datasets were not available in certain partitions. When MVT came along it removed those constraints and voila, suddenly the floodgates of the CPU and system were open for work and it has remained that way through SVS, MVS, until PR/SM came along. And now we seem to be back into the old MFT partition mode once again all in the name of "best practices". As Marie Antoinette said as she stood before a statute of liberty erected by the guillotine, "Liberty what crimes are committed in thy name" (Mary Baker Eddy) As I said at the start, this is just brainstorming and I do not know the answer, but I do know we can do better than just "LPARs for the sake of LPARs". On Mon, Feb 22, 2010 at 7:32 PM, Shmuel Metz (Seymour J.) < [email protected] <shmuel%[email protected]>> wrote: > In <[email protected]>, on > 02/19/2010 > at 06:05 PM, George Henke <[email protected]> said: > > >No, you get to ask how many CICSes or DB2s or whatever do I need all > >running under the same or fewer or 1 z/OS virtual machine. > > How does that differ depending on PR/SM versus z/VM? > > >Precisely the point. You know of any lightly loaded boxes lately? > > Yes. > > >What isolation? > > Isolation of DASD. Isolation of service being tested. Isolation of program > products with wonky licenses. > > >Unless you want an administrative nightmare or have an army of system > >programmers, you will follow IBM's strong recommendation to share > >everything as much as possible: SHARED PARMLIB, SHARED MASTERCAT, > >SHARED PROCLIB, SHARED JESPOOL. > > That's my preference for everything but DR; auditors, legal and management > don't always agree. > > >After setting all that up, blow away just one "system symbolic" and see > >how much isolation you really have. > > I've seen plenty of shared failure modes, but not that one. Perhaps > there's something about your shop that makes it more likely, but elsewhere > it's rare. I'd be a lot more worried about losing the shared master > catalog, which is also rare. > > >Show me 1 shop running a SFW sandbox, Combined DEV/QA, PROD, DR LPAR > >configuration who will pay less by splitting QA into a separate LPAR. > > First show me where I said that they would in the specific case. You > raised a general objection against the use of PR/SM, and I addressed it as > a general issue. > > >How about counting and comparing the instruction path length of each. > > Why would I do that when it has nothing to do with my question? Path > length is not robustness. > > >True. But it does not predate SVS, VS1, MVT, MFT, and OS Rel 17 from > >which (except for VS1) MVS evolved. > > It certainly predates OS/VS1 and OS/VS2 SVS. I don't recall the exact date > for OS/360 Release 17, but Release 14 was out in 1968, so CP/67 was out > first. Virtual Machine Facility/370 was just the next version of CP/67. > > >Furthermore, a duck is still a duck no matter what you do to it, > > Claiming that doesn't make it true. > > >but no matter what you do to it, it still just a > >hypervisor as one of the links included by some of the creators of > >PR/SM in the trail notes pointing out that PR/SM is now officially > >referred to as the "LPAR Hypervisor". > > The fact that PR/SM doesn't offer most of the VM facilities doesn't mean > that z/VM doesn't. > > >After sharing everything, > > One of the reasons for isolation is that you are not always allowed to > share. > > >as previously noted, > > All that you noted was that it was possible to configure shared resources > with a single point of failure, not that the failure was likely. > > >If you seriously believe z/VM is larger, more robust with more > >functionality than z/OS, then you really need to take a another look. > > If you seriously believe that you are accurately reflecting either what I > believe or what I have written, then you need to take another look. I > never claimed that z/VM was larger or more robust; I simply asked you to > provide data to justify your claim that MVS was more robust. I neither > mentioned size nor took a position on robustness. As to functionality, > each has something that the other is missing. > > -- > Shmuel (Seymour J.) Metz, SysProg and JOAT > ISO position; see <http://patriot.net/~shmuel/resume/brief.html> > We don't care. We don't have to care, we're Congress. > (S877: The Shut up and Eat Your spam act of 2003) > > ---------------------------------------------------------------------- > 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 > -- George Henke (C) 845 401 5614 ---------------------------------------------------------------------- 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
