>So instead of asking "How many z/OS LPAR's do I need?" you get to >ask "How >many z/OS virtual machines do I need?"; the question doesn't go away. 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. >Would you prefer paying the maximum price even if the box was lightly l>oaded? Precisely the point. You know of any lightly loaded boxes lately? >As Ken pointed out earlier in this trail, it is indeed possible to put >it all in one LPAR and configure WLM, in lieu of PR/SM, to manage the >weightings.
>That addresses the performance issue; it doesn't address the isolation >issue. What isolation? 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. After setting all that up, blow away just one "system symbolic" and see how much isolation you really have. >Centralize "whatever" and you minimize cost (TCO) and maximize control, >albeit at the cost of flexibility; Management 101. >No; the Devil is in the details. Some shops save money by having >multiple >LPAR's 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. >After all is not MVS a far more robost operating system than VM >Maybe. Do you have any relevant data? How about counting and comparing the instruction path length of each. >which, by the admission of its own authors, is really little more >than a hypervisor developed, of yore, to test different versions >of MVS? >No. It's considerably more these days, and it predates MVS. It's not >your >father's VM. True. But it does not predate SVS, VS1, MVT, MFT, and OS Rel 17 from which (except for VS1) MVS evolved. Furthermore, a duck is still a duck no matter what you do to it, no matter how you dress it up. z/VM is certainly larger, more robust, and more powerful, than ever, 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". >Why would we NOT use MVS instead of VM, alias PR/SM, to do multitasking >and manage workloads? >Isolation, whether due to software level or due to legal and licensing >issues. After sharing everything, as previously noted, all you really have is the illusion of isolation which might be good enough to fool lawyers and auditors, but if any of us thought for a moment these systems were really isolated, we would just be fooling ourselves. >Why look to a hypervisor to do the job that MVS was designed to do and >far more capable of doing? >Why is the Moon larger than the Earth? Your question has an >assumption >contrary to fact. 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. Regarding other previous comments as to the efficiencies realized from putting VM into microcode, the performance degradation from the "shoulder tapping" that LPARs must do when sharing CPs for I/O is quite significant as was pointed out by Cheryl Watson many moons (no pun intended) ;-) ago and far outweighs any gain that would be realized from the microcode implementation. On Fri, Feb 19, 2010 at 4:20 PM, Shmuel Metz (Seymour J.) < shmuel+ibm-m...@patriot.net <shmuel%2bibm-m...@patriot.net>> wrote: > In <b53f38421002190841p227674abx84936665dfa68...@mail.gmail.com>, on > 02/19/2010 > at 11:41 AM, George Henke <gahe...@gmail.com> said: > > >Let's face it, even by IBM's admission, PR/SM is little more than VM in > >microcode. > > So instead of asking "How many z/OS LPAR's do I need?" you get to ask "How > many z/OS virtual machines do I need?"; the question doesn't go away. > > >And then lock us in to this configuration with "sub-capacity pricing". > > Would you prefer paying the maximum price even if the box was lightly > loaded? > > >As Ken pointed out earlier in this trail, it is indeed possible to put > >it all in one LPAR and configure WLM, in lieu of PR/SM, to manage the > >weightings. > > That addresses the performance issue; it doesn't address the isolation > issue. > > >Centralize "whatever" and you minimize cost (TCO) and maximize control, > >albeit at the cost of flexibility; Management 101. > > No; the Devil is in the details. Some shops save money by having multiple > LPAR's. > > >After all is not MVS a far more robost operating system than VM > > Maybe. Do you have any relevant data? > > >which, by the admission of its own authors, is really little more > >than a hypervisor developed, of yore, to test different versions > >of MVS? > > No. It's considerably more these days, and it predates MVS. It's not your > father's VM. > > >Why would we NOT use MVS instead of VM, alias PR/SM, to do multitasking > >and manage workloads? > > Isolation, whether due to software level or due to legal and licensing > issues. > > >Why look to a hypervisor to do the job that MVS was designed to do and > >far more capable of doing? > > Why is the Moon larger than the Earth? Your question has an assumption > contrary to fact. > > > -- > 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
