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



I have seen this problem before. The solution that I use is that I have the
requesting machine (in this case the PC) send an acknowledgement of some
sort to indicate that it has received all of the data before the AS/400
closes the socket. Or you can have the AS/400 leave the socket open until it
has been closed by the PC (or until a certain timeout limit has been
reached).

Albert York                          

        -----Original Message-----
        From:   Chris Bipes [SMTP:chris.bipes@xxxxxxxxxxxxxxx]
        Sent:   Monday, September 08, 2003 10:01 AM
        To:     'Midrange Systems Technical Discussion'
        Subject:        RE: Socket program problem

        Look at your TCP Buffers Sizes one the individual machines.  Also
look at
        the network configurations.  Are there routers / fire walls between
the
        AS400 and the PC on some on the networks?  Can you see any patters
in the
        network layout or TCP Buffer sizes?  It sounds like the packets are
arriving
        out of sequence and the close is arriving before all the data is
processed
        by the PC.   Is this UDP or TCP connection?


        -----Original Message-----
        From: John Allen

        It is a socket program that allows data to be transferred from the
iSeries
        (Server) to the PC (Client).  

        The PC User can request a database file, the PC Client sends a
request to
        the iSeries, the iSeries creates the file and sends the records back
to the
        PC in (XML format) The PC reads the XML data and displays the data
on the
        PC. Each XML record sent to the PC has a CRLF appended to the end of
the
        record by the iSeries program (but I do not see anywhere in the PC
program
        that checks for the CRLF so I am not sure why it does it). 

        The application works well on most of our locations (each location
has their
        own iSeries), but there are a couple of locations where it does not
work. At
        the locations where it does not work - if the user requests a small
file (4
        or 5) records it works fine, if the user requests the same file but
it has
        16+ records then the PC client does not receive all the data and the
PC
        program gets error -10053 WSAECONNABORTED when trying to get the
next bit of
        data.  Each XML record transmitted from the iSeries to the PC is
aprox 350
        bytes in length.  I added a trace file to the iSeries program and it
always
        sends the complete file. When I debug the PC program I see that each
time it
        receives data it receives a different number of bytes (not sure why
this is)
        but it works ok until it eventually tries to get the next bit of
data and
        receives the error mentioned above.

        I know this is not enough information for someone to give me an
answer as to
        what the problem is, my question is where do I start looking for the
        problem? Not knowing where to look, I added a delay in the iSeries
program
        that sends the data to the Socket to wait one minute before ending
and
        closing the socket (I thought maybe it was closing the socket before
the PC
        had finished reading the data) but like I said I am new at this and
was just
        guessing. 

        When I request the exact same file (as one of the locations that is
        failing), the application works fine no matter how many records. 

        Each remote location has there own iSeries and only one user is
using the
        application at a time.
        _______________________________________________
        This is the Midrange Systems Technical Discussion (MIDRANGE-L)
mailing list
        To post a message email: MIDRANGE-L@xxxxxxxxxxxx
        To subscribe, unsubscribe, or change list options,
        visit: http://lists.midrange.com/mailman/listinfo/midrange-l
        or email: MIDRANGE-L-request@xxxxxxxxxxxx
        Before posting, please take a moment to review the archives
        at http://archive.midrange.com/midrange-l.

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.