Re: econnrefused

hi scott..

here is the latest information i have..

there is no firewall..

the 820 is running r5v2 and the i5 is running r5v4

in the display connections DSPCNNL on the 820 there is the following

QDCCNNLANY *ISDN this ISDN CNNL is IBM supplied

this is missing on the i5
..
in addition on the i5 the command to create a connection CRTCNNL is missing..i dont know if this command simply does not exist in r5v4 or if there is a part of the os missing..

this is a question the system operator found and asked me..

the only response we get from ibm here is that it is an application problem and they are not interested..also they keep saying dont use sockets do it some other way..they sent us a model cl program to ftp files from one system to the other..they dont seem to understand that we are not working with files but with stream files within document folders..

i have believed all along that it is a configuration problem..the programs work perfectly on each of the systems individually and are taken from programs i used in the us that worked perfectly..but again it was basically within the same box up there..an as400 with a pc and pc application attached...

i dont know how this affects the issue but the telnet programs QTVDEVICE and QTVTELNET are active within the subsystem qsyswrk but in navigator i cannot find a TELNET entry..

another thing on the 820 as/400 netserver is not started but it is on the i5 these are under the system/network/servers/tcp/ip

on the i5 in this window dns is listed but it is turned off..dns is not listed in the window for the 820..

it has been many many years since i have done any configuration work so i am not sure what should exist and be active..

thanks

keith

message: 7 date: Fri, 07 Dec 2007 11:22:22 -0600 from: Scott Klement <midrange-l@xxxxxxxxxxxxxxxx> subject: Re: econnrefused Hi Keith, When you reply to a digest, PLEASE change the subject of the message back to match what you're replying to. Otherwise, it becomes VERY difficult to follow all of the messages in a conversation. Your test proves that the error is not in your code. Either there's a routing problem, or there's a firewall that's blocking your connection attempts. keith wrote:

> hi scott..
> > here are the results of the test you suggested..
> > on both systems the test of
> > TELNET RMTSYS('192.168.1.100') PORT(2000)
> > fails with unable to open connection and this is respective of the port used..dropping the port option it automatically tries to connect with port 23 and gets the same error..
> > however when > > TELNET 192.168.1.100 2000 or > > TELNET 192.168.1.100
> > is used a connection is made..is active and is useable..
> > i might add a caveat here..i am working in buenos aires and my command of spanish while quite functional is not totally fluent and i can have difficulty communicating what we need to do with the operators..
> > thanks
> > keith
> > > message: 3
> date: Thu, 06 Dec 2007 22:16:10 -0600
> from: Scott Klement <midrange-l@xxxxxxxxxxxxxxxx>
> subject: Re: econnrefused
> > Darn... I thought it might be the bind(), too... since it's inaddr_any, > that's not it. (You can verify that by using NETSTAT *CNN and choosing > option 5. If it shows "local internet address = *" then you've used > INADDR_ANY correctly.)
> > In a previous message to you, I suggested that it might be a firewall. > Have you looked into that?
> > If you type TELNET RMTSYS('192.168.1.100') PORT(2000) does it connect? > Or do you get a connection refused error? If you get a conn refused > error, then the error isn't in your client program.
> > You might also try doing a telnet from a WinXP PC that has a direct > network connection to the remote system. Open up a DOS prompt and type > 'telnet 192.168.1.100 2000' (without the quotes) and see if it connects. > If it does, then there's an error in the way the two iSeries are > communicating with each other. Either a firewall is blocking access, or > there's a routing problem of some kind. If the telnet from the WinXP > computer doesn't work, then there's an error in your server program.
> > At any rate, it's clear that the problem is NOT related to > gethostbyname() or inet_addr(), since you obviously have the right IP > address and port in your socket address structure.
> > >