Many disagreements (interspersed):
>There is a very hidden, subtle, but quite exorbitant price paid for PR/SM:
Define exhorbitant.
>- Memory for each instance of z/OS replicated,
Memory is relatively cheap compared to the total cost of the processor.
>- Performance: wasted CPU cycles especially for handshaking between LPARs
>doing shared I/O,
I've been involved in MDF & PR/SM since the mid-1980's.
Back then, MDF was expensive -- 5% of the processor per domain.
PR/SM -- 3090-base -- 7%
-- 3090-E -- 5-6%
-- 3090-S -- 5ish%
-- 3090-J -- 4-5%
-- ES/9000 -- 4-5%
-- 9672 -- 3-4%
-- z/Box -- 2-3%
These are from memory following IBM guidelines on the number of logical vs
physical ratios.
I was responsible for the measurements, and they were done by me, for many
different environments that I managed.
I only suffered twice from I/O elongation, and both were on the older
(non-CMOS) technology.
TPI & EMIF addressed a lot of the I/O issues. DCM & (HIPER)PAV addressed a lot
more. With sub-5ms response, it's almost impossible to discern any effects due
to PR/SM.
>- Software licensing fees
> - Inflexibility of fitting workloads into fixed partitions,
Again, define inflexibility.
With variable weights, CPUs, and other dynamism in the picture, surely there
is great flexibility.
Would you want to go back to the old monoliths with the (implied) wasted
capacity.
Also, by isolating specific workloads to smaller partitions, I have helped many
companies save licensing costs.
> - complexity: After splitting everything up we bring it all back together
> again with Parallel Sysplex, CDSes, CFRM policies: List, Cache, and Lock
> structures, all kinds of plexes: JESPLEX, VTAMPLEX, IMSPLEX, VSAM RLS,
> CICSPLEX, SHARED DB2, all designed to circumvent the artificial barriers we
> never needed to erect in the first place.
That has nothing to do with PR/SM. SYSPLEX complexity is for redundancy in case
of failure of hardware, systems, or sub-systems.
The first SYSPLEX, I was involved in, was four monolithic (ie: non-partitioned)
processors.
We went to PR/SM, on one new box, to replace two boxes, about a year later.
The reasons for PR/SM, in that case were:
1. Less power.
2. Less cooling.
3. Flexibility. The two images peaked at different times, so we could get away
with less capacity than that required by two footprints.
4. Of course, software costs. One less MVS licence.
>despite:
>- all efforts of IBM to encourage this with "sub-capacity pricing"
Sub-Capacity Licences DO save money.
>- the diminishing need to carve up memory now that paging, Expanded Storage,
>are history with 64 bit memory.
One agreement.
>True, there is a place for PR/SM for things like CFCC, AIX, LINUX.
>But just needlessly replicating z/OS because it is "free" and easy to do is
>not the answer.
Why not? There is more to it than your simple dismissal.
There are isolation issues.
And, even in the 21st century, virtual storage issues, still.
That is to name just two.
-
Too busy driving to stop for gas!
----------------------------------------------------------------------
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
