There are a lot of PTFs for CUIR on VM 4.4.0 and earlier; I don't know about ver 5. Most of the problems are CP abends. You need to check that you have all relevant maintenance on the system.
Regards, Richard Schuh -----Original Message----- From: VM/ESA and z/VM Discussions [mailto:[EMAIL PROTECTED] On Behalf Of Mark Bodenstein Sent: Wednesday, January 25, 2006 7:24 AM To: [email protected] Subject: Re: Varying CHPID offline 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
