It looks like you might be on to something:
GATEWAY
; Address Hop Name Size Mask
Subnet Value
; ------------- --------------- ---------------- ----- --------------
----------------
192.168.193 = QDIO0 1500 0.0.252.0
0.0.193.0
DTCPRS007E ERROR ENCOUNTERED IN READING ZVMV5R11 TCPIP *:
DTCPRS052E LINE 233: SUBNET MASK NOT COMPATIBLE WITH NETWORK ADDRESS
Different variations, even to the point of defining it as just a single
class C network (192.168.193) failed also.
Well, back to the "level 3 guy".
Tom Duerbusch
THD Consulting
>>> [EMAIL PROTECTED] 10/14/05 5:08 AM >>>
Tom, the 192.168.192.x address is per default a class c address and you
use
it as a subnetted class b address. I had such a situation at a customer
site
several years ago. OS390 2.9 did not accept this address and subnet
mask,
because of violating standards. I have never tried, if z/OS is more
"tolerant" to the standard. You might get in trouble with more
restrictive
ip stacks. Of course, windows ip stack is not a problem, because
complying
to standards is not a primary domain of windows. ;-)
Franz Josef Pohlen
----- Original Message -----
From: "Tom Duerbusch" <[EMAIL PROTECTED]>
To: <[email protected]>
Sent: Thursday, October 13, 2005 9:34 PM
Subject: Subnet mask problem
> Well, my requests to the networking group for some networking
changes,
> ended up being sent to a "level 3 guru". At least I could find some
> common terms with networking, but this guy is speaking gibberish<G>.
>
>
> I wasn't paying attention to the IP addresses I've now been assigned,
so
> I let this one slip thru. They gave me 192.168.192/22. Huh?
>
> I get the impression that the mainframe now own:
>
> 192.168.192.x
> 192.168.193.x
> 192.168.194.x
> 192.168.195.x
>
> So, a thousand addresses should be sufficient<G>. Actually, I made
so
> many requests that they may be confused. So I'm accepting them and
> trying to do things in a piece meal fashion.
>
> Anyway, in z/VM 5.1, I need a subnet mask and subnet value for this.
It
> doesn't seem simple. This VM image will have 192.168.193.3. My
initial
> guess is a subnet mask of 0.0.255.0 and a subnet value of 0.0.3.0
but
> that didn't work in my first test. (At this point I don't know if
the
> "level 3 guy" made the changes correctly or if I didn't make the
changes
> right. (Right now, this is on the unused IFL side, so I have time
for
> testing.) Eventually, I'll put in VM's vswitch for support of the
Linux
> images.
>
> Background:
>
> They are not going to be routed.
> They are part of a virtual lan assigned to the mainframe.
> They are "seg 3". I don't know if that is a term, or a label, like
> "third segment" or what.
>
> What I wanted:
>
> We have 2 OSA card, each with 2 GBE ports.
> We have a 390 engine and an IFL.
> I see a 390 lpar plus multiple IFL lpars (all running under z/VM
images).
> A linux image may be IPL'ed in any of the lpars (so a LPAR can be
taken
> down for maintenance).
> I wanted all IP addresses to be available on any of the 4 GBE
fibers.
>
> So I think that is the virtual LAN that networking setup. Hence
they
> don't need to do routing. I think that is good.
>
> Eventually, we will be plugging in the 3 100mb ethernet connections
from
> the IBM DS6800 dasd subsystem as the DS6800 calls home over the
> Internet. Perhaps even the 3 100 mb ethernet connections from the
z/890
> (perhaps not on this one as the call home function is still over dial
up
> phone).
>
> Also I have two OSA-ICC cards. Each card has two ports of 1000
Base-T
> copper connections. One port on each card is configured as ICC.
The
> other port on each card is another OSA port, not used at this point.
>
> Boy, a single LPAR with a single IBM 3172 ethernet connection, was
much
> simpler<G>. But there are many reasons for going to the more
> complicated setup.
>
> Thanks
>
> Tom Duerbusch
> THD Consulting
>
>
