On Monday, 04/24/2006 at 12:39 EST, Brian Nielsen <[EMAIL PROTECTED]> wrote: > There are several more iterations of Stop Lan and Start Lan, but it is > always on the backup OSA addresses, never on the primary OSA addresses. > > So the question is: why didn't it ever try to restart on the primary OSA > when the backup OSA received the Stop Lan? If both OSA cards were the > same it might not matter that much, but the primary is a Gig-OSA and the > backup is a Fast-OSA.
There is no permanent association of "primary" and "backup" in the VSWITCH. There is just a list of available OSAs. The VSWITCH starts with the first one and fails over until it finds a working one. Whichever one is active is the "primary". The others are "backups". (You can see that in QUERY VSWITCH.) So, I'm not 100% sure I'm reading your post correctly, but I would have expected identical behavior vis a vis the decision to fail over, without regard to which OSA was active and which were backups. A StopLAN on the currently active OSA should have caused a failover. If none of the backups worked (i.e. all OSAs unplugged at the same time), I would have expected CP to come back to the OSA that is currently 'active' and sit and wait for StartLAN on the active OSA or one of the backups. At that point, whichever one comes up first would become the active OSA. Of course, with the abend in the controller, bizzare things were obviously going on. The Support Center definitely needs to look at it. FWIW, if you want it to go back to the first OSA in the list, set up some system automation to do a SET VSWITCH DISCONNECT followed by a SET VSWITCH CONNECT when you get an adapter-initiated StartLAN on the desired device (as seen on the controller's console). CP will go back to the beginning of the OSA list and start looking for a working device. Alan Altmark z/VM Development IBM Endicott
