On Tuesday, 10/30/2007 at 07:16 EDT, [EMAIL PROTECTED] wrote: > Thanks Robert But we already went down this route as I explained we know > it was a hardware hit to a brocade device. That really wasnt my question > we were told within a few minutes the chip'ds came back VM stayed up. But > zLinux crashed on the VM system. Those of course involved with the chip'd > taking the errors. Im just trying to find out is this normal, there are no > time out values for zLinux to wait before going down hard or if it cant > get to Root lets say once it dies? Sounds that way but wanting to see if > there is anything we can do to prevent this other then the obvious make > sure we dont take hardware hits ;)
To answer your question, an interface control check is a permanent I/O error (hence the HCPERP notifications and an EREP record was likely created). The channel subsystem has already tried all available paths to get to the device. There's nothing the guest can do to fix it. This is exactly the the kind of thing that Linux-HA and/or Tivoli System Automation for Linux [I think] can address using z/VM's HYPERSWAP command, if you have a z/OS GDPS solution. The I/O error would be trapped by the monitoring [Linux] guest and the failing volume replaced by a mirrored volume. (GDPS manages the mirroring.) Of course, if the primary and secondary volumes are coming through the same FICON switch then it won't help as much (protecting you only from port failures). Alan Altmark z/VM Development IBM Endicott
