It would seem that the upgrade/downgrade/CUoD microcode change merely sets
the limit on the maximum number of physical processors that can be placed
in-service concurrently, but will not remove from service physical
processors that happen to be in-service at the time the microcode change is
installed. Perhaps the number of active LPs in an LPAR is only checked
against this limit value at LP activation time (either IPL or "config"
command).
Tom
--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
This is a PRIVATE message. If you are not the intended recipient, please
delete without copying and kindly advise us by e-mail of the mistake in
delivery. NOTE: Regardless of content, this e-mail shall not operate to
bind CSC to any order or other contract unless pursuant to explicit written
agreement or government initiative expressly permitting the use of e-mail
for such purpose.
--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Hal Merritt
<[EMAIL PROTECTED]
RY.COM> To
Sent by: IBM [email protected]
Mainframe cc
Discussion List
<[EMAIL PROTECTED] Subject
.EDU> Re: Concurrent Upgrade Puzzlement.
09/13/2007 01:09
PM
Please respond to
IBM Mainframe
Discussion List
<[EMAIL PROTECTED]
.EDU>
I don't understand this state either :-)
That's why I'm asking this august group.
What I'm hearing is the possibility of interesting hole in IBM code.
That is, you are not permitted to define more logical processors than
there are CP's. But you are permitted to remove CP's without first
putting offline.
At point in time of definition, there were four CP's and four LP's were
defined.
Now one CP quietly goes away. We are not -defining- anything, so that
rule is unbroken. But we did seemingly end up with four LP's running on
3 CP's.
Performance has been as expected. I have no indication of any problem
being caused by the 4/3 situation.
Here is a clue: none of the other LPAR's had all four CP's defined. One
had three and the others only one each. So, the one with all four
defined still shows all four. The other LPARS show CP 3 as 'N' as
expected.
My knee jerk would be to configure CP 3 offline, which is something I
guess I should have done before the upgrade. But, again, I'm worried
that something is broken and I might break it worse. And, I've never had
to do anything like this before. Backing down from a capacity on demand
upgrade does include a deactivate/reactivate sequence, but that is
spelled out in the instructions.
One here is worried that we are actually still using the fourth CP, but
at full speed. When we next POR or IPL, we could take an unexpected
performance hit.
-----Original Message-----
From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On
Behalf Of Ted MacNEIL
Sent: Wednesday, September 12, 2007 5:47 PM
To: [email protected]
Subject: Re: Concurrent Upgrade Puzzlement.
>No manual configuration or profile changes were made. Only the hardware
microcode.
Then, I really don't understand what kind of state you're in.
..snip..
----------------------------------------------------------------------
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
