Matthew It worries me that you are testing with FTP which really isn't the place to start when you have problems. Much better is to use PING and, possibly, take a peek at the ARP tables.
Let's start from first principles: There is a LAN, L, which is associated with the IP address range defined by the IP address 10.2.8.0 and subnet mask - as expressed in all implementations of IP except the old TCP/IP for VM product (which was used for TCP/IP for MVS which became the IP component of Communications Server) - 255.255.248.0 or 21 contiguous bits. We know of two interfaces connected to LAN L. One is one of the ports on your OSA feature which must have an address in the range 10.2.8.1 to 10.2.15.254. The other is a router, R, interface with address 10.2.8.2. There may be other interfaces connected to LAN L. The ROUTE statement ROUTE 10.2.8.0/21 = Z990CH41LNK1 MTU 1492 by itself should allow communication with all interfaces connected to LAN L. Thus, for example, PING 10.2.8.2 should be successful. This is the first test to try. Whether it is successful or not, a display of the ARP table on your system or the router should show MAC addresses associated with the relevant IP addresses. You should, of course, now be able successfully to PING any other interface on LAN L. One "trick" you might use is to issue the PING command PING 10.2.15.255 This should prompt a response from each of the interfaces connected to LAN L. Adding the ROUTE statement ROUTE DEFAULT 10.2.8.2 Z990CH41LNK1 MTU 1492 to the ROUTE statement above should now allow communication with all interfaces which can be reached through the router R. One typical IP address to try at this stage is that of your name server - assuming it is not connected to LAN L. I hope it is clear that any PING commands up until now should use IP addresses rather than names! Only now, assuming your FTP partner is reached by means of router R, should you attempt your FTP test. Please report back your findings from these tests. You'll notice I have not mentioned the other route(s) via "hypersockets". I haven't worked with this so the only guidance I have on this is your existing GATEWAY entry. If your FTP partner is accessed via "hypersockets", let me know - let all of us know - and I/we will try to sort out what might be the problem there. Chris Mason ----- Original Message ----- From: "Matthew Stitt" <[EMAIL PROTECTED]> Newsgroups: bit.listserv.ibm-main To: <IBM-MAIN@BAMA.UA.EDU> Sent: Wednesday, 18 October, 2006 6:51 PM Subject: Re: I love TCPIP (not!) > Thanks, Chris. > > I made the changes you suggested, and the FTP still failed. I wish I knew > what in the GATEWAY statements causes it to work, and what in the ROUTES > causes it to fail. > > I know that GATEWAY is out-moded, so that is why I am switching to ROUTES. > > I really appreciate your assistance and patience. > > On Wed, 18 Oct 2006 02:00:29 +0200, Chris Mason <[EMAIL PROTECTED]> wrote: > > >Matthew > > > >Here's your GATEWAY statement converted to a BEGINROUTES/ENDROUTES block: > > > >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 > > > >to > > > > BEGINROUTES > >; Where is the gateway? > > ROUTE 10.2.8.0/21 = Z990CH41LNK1 MTU 1492 > >; The internal hypersockets routes > > ROUTE 192.0.0.0/24 = IQDIO1 MTU 8192 > >; All other traffic defaults here > > ROUTE DEFAULT 10.2.8.2 Z990CH41LNK1 MTU 1492 > > ENDROUTES > > > >Note that the number of contiguous bits in the mask is 8 for the first octet > >(byte), 8 for the second octet and 5 for the third octet. the third octet is > >5 because 248 = 128(1)+64(2)+32(3)+16(4)+8(5). > > > >In fact your GATEWAY entry for the hypersockets routes is incorrect. 192 is > >a class C network, the first in the class C range in fact. Thus the subnet > >mask field can be specified as 0 and there will be no subnet value field. > > > >As this is strictly an "incorrect entry in a GATEWAY statement" I would > >expect the following note from 1.2.27, "GATEWAY" in z/OS V1R8.0 > >Communications Server IP Configuration Reference to apply: > > > ><quote> > > > >1. When an incorrect entry in a GATEWAY statement is encountered, it is > >discarded along with the remaining entries in the GATEWAY statement. All > >routes defined before the incorrect entry are added to the IP Route Table. > >Subsequent GATEWAY statements in the same profile data set, or VARY > >TCPIP,,OBEYFILE command data set, are processed. > > > ></quote> > > > >Thus I would expect the hypersockets route not to be processed and the > >DEFAULT route not to be processed. > > > >However, you say this GATEWAY statement works so maybe the fact that the > >mask is strictly not necessary is ignored, the mask implied by the class of > >the network, 255.255.255.0, is "OR"ed with the subnet mask value, > >0.255.255.0, and the end result is as required. Syntactically, if not > >logically in terms of the IP class rules, the statement is correct. > > > >Incidentally, your original post said that the IP addresses of your > >hypersockets pseudo-LAN., as it appears to be, are 192.10.1.xxx. This isn't > >what you are now saying. If 192.10.1.xxx is correct, the internal > >hypersockets routes ROUTE statement would be as follows: > > > > ROUTE 192.10.1.0/24 = IQDIO1 MTU 8192 > > > >Please post again if you need more help. > > > >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
