On Thursday, 02/25/2010 at 01:39 EST, "Wiggins, Mark" <[email protected]> wrote:
> 1) Because of the way the SVC performs it?s upgrade, usually, one I/O > group is taken down while being upgraded, then there is a 30 minute delay, then > the second I/O group is taken down, activity is resumed to the first I/O group, > then the upgrade is preformed on the second I/O group. Question 1 is, can it be > as simple as varying of the CHPID attached to the first I/O Group, wait for it > to complete the SVC node upgrade, and then during the 30 minute wait time, vary > that CHPID back on and vary off the second CHPID in order to ?quiesce the I/O? > as mentioned above? It sounds plausible to us. Give it a try and let us know. :-) > 2) Second part to this question is, in the past we?ve lost one of our > paths connected to the SVC. We were able to vary on the CHPID, PATH and > Devices, etc., but couldn?t figure out how to get the SVC and z/VM to initiate > any kind of a handshake. The only way that we could get the path to reestablish > activity was to IPL. Does anyone know of a command that can be issued either > from VM or from the SVC to let the other one know that it?s there again. I > would liken it to something like a ?ping?, just something that says ?hey, I?m > here now, talk to me?. Please apply the PTF for VM64679 and its pre-reqs; it isn't on an RSU. It significantly improves error recovery with SVC. If you still have a problem after that, open a PMR. Alan Altmark z/VM Development IBM Endicott
