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



Perhaps the coworker's field into which he is receiving the socket data is
declared as a 32767A field. He can increase it to 65535A to get some immediate
feedback to see if that's his problem.
Another idea is to create a user space, get a pointer to that users space, and
pass the pointer to the user space to the recv() function.

If he's getting the data in packets/chunks and just filling up a 32k field with
the data he's receiving (typically in a loop until recv() returns zero bytes),
then he could, as suggested, declare a larger, 64k field for his "buffer". 

-Bob Cozzi
www.i5PodCast.com
Ask your manager to watch i5 TV



-----Original Message-----
From: rpg400-l-bounces@xxxxxxxxxxxx [mailto:rpg400-l-bounces@xxxxxxxxxxxx] On
Behalf Of Rick.Chevalier@xxxxxxxxxxxxxxx
Sent: Tuesday, March 13, 2007 1:34 PM
To: rpg400-l@xxxxxxxxxxxx
Subject: Garbage characters received by socket


There haven't been any takers on the midrange-l list so I'm cross posting here.

We have an application that monitors a socket for application information in an
XML format.  At varying places in the transmission we receive a string of '@'.
The program parsing the XML will ignore them and viewing the received XML via a
browser doesn't have any trouble.

The issue is that we sometimes don't receive the entire XML string.  A co-worker
is responsible for this process and tells me that there is a 32k buffer
restriction.  He thinks the '@' string sometimes pushes the data beyond the
buffer size and we lose it.

We believe the information is being sent from a windows box.

Does this sound right?  Has anyone else encountered this type of behavior using
sockets in the iSeries?

Rick Chevalier
AmeriCredit ITS
817-525-7178



Privileged and Confidential.  This e-mail, and any attachments there to, is
intended only for use by the addressee(s) named herein and may contain
privileged or confidential information.  If you have received this e-mail in
error, please notify me immediately by a return e-mail and delete this e-mail.
You are hereby notified that any dissemination, distribution or copying of this
e-mail and/or any attachments thereto, is strictly prohibited.

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.