Hi Allen
I'm starting to see where you are coming from with this. Obviously,
historically, there have been multiple ways of coding these entries.
And I have been able to get away with my way for a couple decades (not
bad, huh?) But it may be time to pay the piper on this one.
It didn't last quite long enough. As within 18 months, the VM stack
won't have any routing functions as everything would have (or should
have been) converted to vswitch. Vswitch seems to be a much
cleaner/easier solution. Good stuff.
So, in the latest post towards Miguel:
1. I do need a HOME statement for each interface, 30 some odd HOME
statements....right?
2. The IP statement on the HOME statement:
a. Cannot duplicate any other IP address in the network
b. Must be in the same subnet as the IP address for the host
(Linux27)
c. Each link, will have its own subnet which contains the IP
address of the link and the IP address of the host.
d. I can't have sequential IP addresses (incremented by 1) for my
Linux hosts.
e. The subnet address associates the IP address on the link with
the IP address for the guest.
3. My GATEWAY statement seems to be correct
On a tangent, vswitch.
I am using sequential IP addresses for my Linux machines on the
vswitch. And they are working, even under z/VM 5.2. Am I going to be
facing future problems here. Would it be advisable to start using
addresses on different .252 subnets? I do believe that vswitch is a
switch and the VM stack was a router and they may be more dis-similar
than similar. But in the areas where they are similar....
On a side note for those people that wrote the TCP/IP Planning and
Customization manual. All the references and examples are "big shop"
environments. Multiple real adapters (TR1, ETH1, FDDI1, SNA1, etc).
Not really much for guest machines running under VM (CTCA, IUCV). True
an adapter (real or virtual) is an adapter. And now the manual may be
written more for real adapters as vswitch replaces CTCA and IUCV.
Anyway, assuming the above interpretation of what you said is correct,
it is time to dig thru the manual to see what I didn't read over and see
what else I didn't read <G>.
Thanks
Tom Duerbusch
THD Consulting
