Let's face it, even by IBM's admission, PR/SM is little more than VM in microcode.
So why put VM in microcode in the first place and limit us to only 60 LPARs. Why not just give us VM "as is" and let us decide how many instances of z/OS under z/VM we would like to run as well as the mix with z/LINUX, AIX, etc? And then lock us in to this configuration with "sub-capacity pricing". Maybe because it will sell more hardware? "How many LPARs does it take to screw in a light bulb?", to paraphrase the old sysprog question. None, it is a hardware problem. "Don't fence me in" 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. Thank you, Ken, great hearing from you again. We are a small shop here and my client is looking at $6 million in additional software charges just to add a new QA LPAR and, quite frankly, if it were my money, for that price, I would find some way to run QA in the DEV LPAR. Hijacking the DR LPAR, however tempting, will not save anything either because the incremental software costs are not incurred until there is a "real" disaster. Centralize "whatever" and you minimize cost (TCO) and maximize control, albeit at the cost of flexibility; Management 101. After all is not MVS a far more robost operating system than VM which, by the admission of its own authors, is really little more than a hypervisor developed, of yore, to test different versions of MVS? Why would we NOT use MVS instead of VM, alias PR/SM, to do multitasking and manage workloads? Why look to a hypervisor to do the job that MVS was designed to do and far more capable of doing? Just because it is nice and neat, has the appearance of being separated, and is someone else's money? Someday management will grant bonuses to sysprogs for a percentage of the $ they will save the company by finding more cost-efficient ways of attaining their goals. Actually, Pratt and Whitney, already does this. As for SOX and customer demands for their own LPARs, there needs to be a risk assessment first. Where's the risk? Controls are designed for risk. No risk, no need for a control. Playing up risk is one of the oldest tricks in the saleman's book.. I can almost hear Robert Preston now . . . "Ohhhhhhhh, There's trouble, trouble, I say, right here, in River City". On Wed, Feb 17, 2010 at 4:17 PM, Shmuel Metz (Seymour J.) < shmuel+ibm-m...@patriot.net <shmuel%2bibm-m...@patriot.net>> wrote: > In <b53f38421002170726k4585f228k9c4048891605b...@mail.gmail.com>, on > 02/17/2010 > at 10:26 AM, George Henke <gahe...@gmail.com> said: > > >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? > > Do you freeze DEV when doing QA on a new release of the operating system? > If not, then you need both. > > >Can't MVS (z/OS) handle it? > > Handle what? Multiple release and service levels? Separation of DASD? > > >Why replicate the z/OS operating system a gazillion times when z/OS > >already has everything needed. > > Needed for what? > > >I know single point of failure at all that jazz, but then what do we > >have a DR box for anyway? > > Hint; what does the D stand for? > > >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? > > That's a question that only you can answer. It's not my dog. > > >But that cannot be achieved with a single instance of z/OS, a software > >sandbox, and a DR box? > > If you never install service or upgrade. > > >Don't we already logically separate DEV, TEST, UAT, and PROD in separate > >CICSes, DB2s, etc. > > To some extent. > > >These are hard questions like, "Is the emperor really wearing > >anything?". > > No, they are loaded questions like "Have you stopped beating your wife?" > > -- > 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
