George, I don't know that I would say that running QA in a different LPAR than DEV is "best practices", I certainly run them in the same LPAR here, and at nearly every site I have ever worked at. In small shops I typically run a production LPAR, a non-production LPAR (DEV, QA, etc), and a "Sysprog Sandbox" LPAR. As others have said, if you run everything in one LPAR, you are not going to have any process for installing and testing new OS and/or ISP software before going production. This also allows you to control CPU/memory usage at a high level, and prevent non-prod workloads from stealing these resources from production. Larger shops may very well not use LPAR in this way, since they may be able to justify separate CECs for non-production work. As others have mentioned, the point of "isolation" may be more about memory isolation than the points you are making re: SYSRES, PROCLIB, PARMLIB, etc. If the LPARs are for different clients, then I can certainly understand the need for separate LPARs, since an APF authorized program could easily spy into another address space in the same LPAR, but doing that across LPARs is a whole 'nother ball o' wax. All in all, I think your arguments for VM over LPAR are way off-base. Most sites have little or no need for the added capabilities in VM, LPAR does the job very well, and at a significantly lower level of effort and complexity - even if you ignore the addition costs of VM (memory, storage, overhead, and of course acquisition/maintenance). I certainly have no desire to spend time on VM if I don't need the functionality, I simply don't have the time. I have worked on VM before, and rather like it, but if the tool doesn't fit I have no desire to use it.
>>> George Henke <gahe...@gmail.com> 2/23/2010 10:56 AM >>> 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.) < shmuel+ibm-m...@patriot.net <shmuel%2bibm-m...@patriot.net>> wrote: > In <b53f38421002191505j1b5fece8q2535a56965763...@mail.gmail.com>, on > 02/19/2010 > at 06:05 PM, George Henke <gahe...@gmail.com> 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 lists...@bama.ua.edu 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 lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html CONFIDENTIALITY/EMAIL NOTICE: The material in this transmission contains confidential and privileged information intended only for the addressee. If you are not the intended recipient, please be advised that you have received this material in error and that any forwarding, copying, printing, distribution, use or disclosure of the material is strictly prohibited. If you have received this material in error, please (i) do not read it, (ii) reply to the sender that you received the message in error, and (iii) erase or destroy the material. Emails are not secure and can be intercepted, amended, lost or destroyed, or contain viruses. You are deemed to have accepted these risks if you communicate with us by email. Thank you. ---------------------------------------------------------------------- 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
