× 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.



What is happening is the program is dumping in the middle of the night when doing a send() and the work buffer is returning an abnormal number which in turn is dumping on length or start position is out of range for the string operation
len = Send(sock:%addr(wrkbuf):wrkbuflen:0)
 
"Len" is coming back as 16,777,216 so maybe is something prior to the send is making the wrkbuflen wrong. We are suspecting something going on at machine backup/down time in the middle of the night.
 
thnx all I shall investigate further.

Bill
(All in favour of saving gas, raise your right foot!)



----- Original Message ----
From: Scott Klement <rpg400-l@xxxxxxxxxxxxxxxx>
To: RPG programming on the AS400 / iSeries <rpg400-l@xxxxxxxxxxxx>
Sent: Wednesday, August 27, 2008 12:23:22 PM
Subject: Re: send() api

If everything is working properly, that would mean that you sent
16,777,216 bytes -- but I'd be shocked if that's really the case.  It
would either mean that you have a network that's faster than your CPU
speed, or that you have your TCP send buffer set large enough to hold 16
MB of data -- which AFIAK is not allowed.  (And even if it were, it
would be seriously sub-optimal.)

More likely, your prototype for send() is wrong.

Or, perhaps you're corrupting memory.

Bill Wragg wrote:
I the sockets programming, we are getting a return value on the
send() api of 16,777,216. we are not sure what this is trying to tell
us.

Can anybody clue me in on what this means? TCPIP down? No
communication with client ?


As an Amazon Associate we earn from qualifying purchases.

This thread ...

Follow-Ups:

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.