× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



Thanks Bob. I will change this procedure as you suggest.  It was code I got off 
the web so hey, free code...I guess I got my money's worth out of it.

Bob Cozzi <cozzi@xxxxxxxxx> wrote: Dave,
The RtvNetAds procedure is NOT returning the correct value to you.
It looks like somebody tried to write an API wrapper, rather than actually write
a good one.
Other than the obvious use of "B" fields in the call to the API, the resulting
API address that it is returning is in position 878 NOT 877 as you're trying to
retrieve it from.
877 is the "offset" not the "position". %SUBST uses positions not offsets. So
you have to add 1.  Not to sound like a broken record, but if you had RPG xTools
you could have "just called..." and got the IP address correctly. For now, just
adjust the offset to a position and see if that fixes things.


-Bob Cozzi
www.RPGxTools.com
RPG xTools - Enjoy programming again.

-----Original Message-----
From: rpg400-l-bounces@xxxxxxxxxxxx [mailto:rpg400-l-bounces@xxxxxxxxxxxx] On
Behalf Of Dave Johnson
Sent: Sunday, February 05, 2006 7:35 PM
To: RPG programming on the AS400 / iSeries
Subject: Re: SOCKET Connect() connects but shouldn't.

Scott, thank you for helping me try to understand this.  I've posted the program
code on midrange.com here: http://code.midrange.com/index.php?id=86383b016d

That's my entire program. I realize it's full of a lot of extraneous procedures
that are not even used here, but I just copied your copy books in so I wouldn't
miss anything.  The shotgun approach. 

I changed the socket(xxxx   call to use literals instead of the constants, even
though I'm sure the constants were fine. BUt just to be sure you know.

If it makes any difference at all... I am connected to my iseries over a two-way
satellite using a satellite modem.  I don't know why that would matter but maybe
direcway does some weird stuff there. 

I wish I had a dial up account somewhere so I could test this that way and see
if I get the same results. That'd tell me for sure that's its something on my
modem or network or connection that's causing the problem if the dial up worked.


Thanks,

Dave Johnson

Scott Klement  wrote: > c                   eval
sock = socket(AF_INET: SOCK_STREAM:
> c                                           IPPROTO_IP)
> c                   if        sock < 0
> c                   callp     die('socket(): ' + %str(strerror(errno)))
> c                   return
> c                   endif

Can you please verify that you are, in fact, passing SOCK_STREAM for the 
2nd parameter (like you posted here).  If so, can you please verify that 
SOCK_STREAM is a constant, and it's value is 1.

If you passed SOCK_DGRAM, or set the value of SOCK_STREAM to 2, it would 
exhibit the exact behavior that you're describing, because when you issue 
a connect() on a UDP socket, all it does is set the "destination" address 
on future datagrams, it doesn't actually send anything at the time you run 
it, thus it would succeed but no connection would be made.

So please make absolutely sure that AF_INET=2, SOCK_STREAM=1 and 
IPPROTO_IP=0 in your definitions.


The only other thing is that you're calling a prototype called addrCvtr(), 
and I don't know what that does.  I've never heard of that before.  This 
API is not a standard sockets API (unless you've renamed it!) and can't be 
found by searching the Information Center's API finder.

I took your code, but changed addrCvtr() to inet_addr() and ran it, and it 
worked just fine for me.  (It gave me a -1 on the connect() call).

So, again, please:

a) Verify that AF_INET, SOCK_STREAM and IPPROTO_IP are set to the correct 
values.

b) Tell us what addrCvtr() is.

As an Amazon Associate we earn from qualifying purchases.

This thread ...

Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.