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
