Alan, Great info.
Thanks. Jim P. On 8/19/10 9:04 AM, "Alan Altmark" <[email protected]> wrote: > On Thursday, 08/19/2010 at 03:52 EDT, Ronald van der Laan > <[email protected]> wrote: > >> I've not seen an answer to your question. >> But you need to list all the first OSA addresses in the SET VSWITCH > command. >> so: >> SET VSWITCH name RDEV prim_osa C000 CONNECT >> If you use: >> SET VSWITCH name RDEV C000 CONNECT >> Then you effectively drop your primary OSA connection and switch to your > backup >> one. > > Sorry, I didn't see this before. You cannot change the active RDEV on a > connected VSWITCH. > > In Jim's case, he wanted to use the *secondary* for something else. To do > that > SET VSWITCH name RDEV prim_osa > > You will see the secondary OSA detached from the controller, and it is > then available for use. Only use the DETACH command if the VSWITCH > becomes unresponsive (in which case you get a snapdump of the system first > to go with your PMR). Likewise, never ATTACH an OSA to a VSWITCH > controller. > > If you want to use the *primary* for some other purpose, then you will > disrupt the VSWITCH: > SET VSWITCH name DISCONNECT > SET VSWITCH name RDEV C000 > SET VSWITCH name CONNECT > > To add the former primary OSA back: > SET VSWITCH name RDEV C000 prim_osa > > Of course, prim_osa is now the backup! You could use the disconnect > three-step to get it back as the primary, but that's an itch that need not > be scratched. (Who cares which one is the backup? It's not like you > would use one fast, one slow!) > > If you want to add and delete OSAs on the fly with no disruption, then you > engage link aggregation and define a port group. > > Alan Altmark > z/VM Development > IBM Endicott
