Alan,
But since the Shark supports CUIR (Control Unit Initiated
Reconfiguration), shouldn't VM be able to get through this kind of
Shark microcode upgrade without operator assistance?
We went through a Shark microcode upgrade a while ago when we were
running z/VM 4.3 and z/OS 1.4 in separate LPARs on a 9672 with Shark
DASD. We had a similar channel setup - one CHPID per Shark host
bay. MVS got through the upgrade with no operator intervention, but
VM needed some help. If I remember correctly VM responded fine as
each CHPID was being taken offline by the control unit, but needed us
to do something when they came back online. Also if I remember
correctly z/VM 4.4 was supposed to have an improvement over 4.3 in
CUIR support?
Mark Bodenstein ([EMAIL PROTECTED])
Cornell University
At 06:40 PM 1/24/2006, you wrote:
On Tuesday, 01/24/2006 at 05:00 PST, Randy Dray <[EMAIL PROTECTED]>
wrote:
> Last night we had IBM upgrade the code on our 800ESS
> Shark.
>
>
> The statement was this would not be a service
> impacting upgrade.
>
> all the CHPIDs upgrade fine for our open systems stuff
> but when we got to all my VM CHPIDs VM crashed.
You probably interrupted
> I am looking for a way to vary offline the CHPIDs that
> that we need to upgrade.
>
>
> CHPID 14, is host bay 1
> CHPID 15, is host bay 2
> CHPID 16, is host bay 3
> CHPID 17, is host bay 4
>
> IBM said that he thought the operating system zVM 4.4
> should have been smart enough to switch over due to
> the multiple paths into the system.
IBM? There is a bit of confusion. The I/O subsystem will select an
available path automatically, but once chosen, a failure in the chpid will
result in an I/O error. Depending on what part of CP was performing the
I/O, it may be critical (i.e. paging). So you can't yank the cables
(physically or logically) *VM is using* out from under VM without warning.
First you must quiesce CP I/O to the affected path (chpid). This is done
by VARY OFFLINE PATH nn FROM ALL. If you don't do that, then CP will
start I/O operations on any available chpid. CP just removes the chpid
from the Logical Path Mask (LPM), but leaves the chpid in place. The LPM
is what tells the channel subsystem what chpids it can use to start an I/O
operation.
Then perform your host bay update, then VARY ONLINE PATH nn TO ALL. Then
proceed to the next chpid and the next bay update.
(*Some* device errors will cause the channel subsystem to retry the I/O on
its own.)
> QUESTION: Can I issue a Vary OFFLINE CHPID nn Force,
> then will it automatically switch over to another
> chpid. When all the maintanance is done, Vary ONLINE
> CHPID NN to get it back.
This is evil. You will deconfigure (but not remove) the chpid from the
LPAR, effectively killing any I/O in flight. That can result in the same
abend you got before.
Taking the chpid offline is not necessary unless directed to by device
service instructions. The only device I know of that gets benefit from
taking the chpid offline is the OSA. When all OSA chpids go offline, the
device reIMLs itself. I mean, it doesn't *hurt* to take the chpid
offline, but it typically doesn't help you, either.
Alan Altmark
z/VM Development
IBM Endicott
