Hi Chris; I think we've finally gotten a set of ROUTES definitions that are working. I performed an FTP to the server after settting these up according to your examples, and it worked.
I'll keep monitoring things for a while. Thanks for your assistance and patience on this issue. Hopefully some others on this list learned a few things. I know I did. On Tue, 24 Oct 2006 21:52:59 +0200, Chris Mason <[EMAIL PROTECTED]> wrote: >Matthew > >Thanks for the response. > >There's a bit more detail in the NETSTAT GATE output than in the GATEWAY >statement you showed us before and there is a possibly crucial difference in >the hipersockets IQDIO1 entry which has managed to acquire a "1" in the >third octet where you reported a "0" before. > >In your 11:04 pm post of Tues, Oct 17 2006, corrected in your 11:19 pm post. >you provided the following: > >GATEWAY > 10.0.0.0 = Z990CH41LNK1 1492 0.255.248.0 0.2.8.0 > 192.0.0.0 = IQDIO1 8192 0.255.255.0 0.0.0.0 > DEFAULTNET 10.2.8.2 Z990CH41LNK1 1492 0 > >But the NETSTAT GATE (and NETSTAT ROUTE) indicates the following: > >GATEWAY > 10.0.0.0 = Z990CH41LNK1 1492 0.255.248.0 0.2.8.0 > 10.2.12.103 = Z990CH41LNK1 1492 HOST > 192.0.1.0 = IQDIO1 8192 0.255.255.0 0.0.0.0 > 192.0.1.68 = IQDIO1 8192 HOST > DEFAULTNET 10.2.8.2 Z990CH41LNK1 1492 0 > >The "LOOPBACK" entry appears because of the following taken from the z/OS >V1R8.0 Communications Server IP Configuration Reference manual - which >appears, because of revision lines, first explicitly to be mentioned only in >this level of the manual: > ><quote> > >1.2.29 HOME > >... > >The default LOOPBACK address of 127.0.0.1 is internally defined by the >TCP/IP stack. If you try to define this LOOPBACK address, it is flagged as a >duplicate entry. You can use a link_name value of LOOPBACK in the HOME list >to define additional LOOPBACK addresses. No DEVICE or LINK statement is >needed for LOOPBACK, and it cannot be started or stopped (LOOPBACK is always >active). > >... > ></quote> > >The "host" entry for 10.2.12.103 is not necessary since it is included in >the address range specified by your network 10.2.8.0/mask 255.255.248.0 >entry. > >Also the "host" entry for 192.0.1.68 is not necessary since it is included >in the address range specified by your network 192.0.1.0/mask 255.255.255.0 >entry. > >Once this is converted to a BEGINROUTES/ENDROUTES block, we should have the >following: > > BEGINROUTES > ROUTE 10.2.8.0/21 = Z990CH41LNK1 MTU 1492 > ROUTE 10.2.12.103/32 = Z990CH41LNK1 MTU 1492 > ROUTE 192.0.1.0/24 = IQDIO1 MTU 8192 > ROUTE 192.0.1.68/32 = IQDIO1 MTU 8192 > ROUTE DEFAULT 10.2.8.2 Z990CH41LNK1 MTU 1492 > ENDROUTES > >As I mentioned above, the entries with "/32" are not necessary. > >I'm wondering whether these "/32" entries are present in order to support >some mechanism which requires host entries to be present in the routing >table. Thus they may have been added dynamically. > >If this BEGINROUTES/ENDROUTES block still does not work - with or without >the "/32" entries, please post the results of the PING tests I described in >an earlier post starting with router 10.2.8.2. > >As for the hipersockets interface, a PING to any and all of the partner >hipersockets interfaces is the only PING test you need. When reading up on >hipersockets, I noticed a claim that the hipersockets connections formed a >sort-of virtual LAN. I'd be interested in whether a PING command such as >192.0.1.255 managed to elicit a response from each of the hipersockets >partner interfaces. I suspect it won't as hipersockets connections probably >don't mimic a LAN in all respects. > >Chris Mason > ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
