--------------------------------<snip>-----------------------------------
Regardless of how many CPs an LPAR may allow there may be an operating
system restriction to a smaller number.
It happens that at this point in time z/OS (1.11) is a bit ahead of the
LPAR limit so that it can support what is allowed within the LPAR.
I don't know about other operating systems.
As to whether customers are actually trying an 80-way z/OS, I can say only
that our testing has tried it..
--------------------------------<unsnip>-----------------------------------
Peter, I can't help but ask: how bad was the overhead incurred in
managing an 80-way z/OS?
In my experience, there was an overhead increment that had to be figured
into the "mix" when adding "engines" to a z/OS image. Are there now
microcode assists to help reduce that overhead? Beyond a certain point,
the increment seemed to remain the same, but it was still what I would
characterize as "significant". And trying to use all those additional
"engines" produced a rather unexpected shock when the I/O load suffered
a great deal of pain.
We once went from a 9672-R53 to a 9672-R83 and had to rebalance all our
I/O load, moving volumes, etc. on our RAMAC-III's to realize a
significant performance benefit from the 3 extra engines. The additional
CPU lead to much longer I/O queues and overall I/O response time
skyrocketed. (Yes, I know, RAMAC-III had its own considerations; we
spent a lot of time studying the architecture and learning how to tune
the drawers' usage patterns when we first installed them. Not to mention
channel loading.)
The vast majority of our production workload was based on CICS and a
hierarchical database using IDMS.
Rick
----------------------------------------------------------------------
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
