Alan,
That is certainly a possibility. Another listserv member mentioned that
yesterday in a direct email to me.
This VM system was formerly configured as PRIROUTER until our z/OS network
administrator had a temporary requirement to define a hipersockets
connection to another z/OS system; at that point, I had to change my
VSWITCH definitions to NONROUTER because the z/OS systems are IPLd first
and I also changed my TCPIP DEVICE definitions to SECROUTER.
Those changes did happen since our last test.
In converting the TCPIP definition to standard OSA, I would have retained
the SECROUTER option, which I understand would have allowed me to assume
PRIROUTER status had another PRIROUTER system not been active.
There was some confusion about whether any z/OS systems were sharing the
OSA port with VM during the test; I heard two different answers to the
question.
So, it seems plausible that SETing the VSWITCH definition to specify
PRIROUTER might have corrected this problem. Its too bad VSWITCH doesn't
support a SECROUTER option similar to TCPIP itself.
Thanks for the suggestion.
Dennis
"Alan Altmark"
<[EMAIL PROTECTED]
ibm.com> To
Sent by: "The IBM [email protected]
z/VM Operating cc
System"
<[EMAIL PROTECTED] Subject
ARK.EDU> Re: Disaster Recovery VSWITCH
Networking Issues
10/26/2006 10:01
PM
Please respond to
"The IBM z/VM
Operating System"
<[EMAIL PROTECTED]
ARK.EDU>
On Thursday, 10/26/2006 at 03:33 EST, Dennis Schaffer
<[EMAIL PROTECTED]> wrote:
> Can anyone suggest specific documentation I should gather in the event
this
> problem occurs during our next DR test?
As a guess, the VSWITCH is defaulting to NONROUTER. If you're going to
attach a virtual router to the VSWITCH, then you must have PRIROUTER.
Remember, the Guest LAN IP addresses are not known to the OSA; only those
on the VSWITCH are registered.
Alan Altmark
z/VM Development
IBM Endicott
