|
I could use a X'FF' rather then multiple characters I did add a file output to the iSeries so that as soon as it did a write it also writes the transmission data to a physical file as well (also included the byte count) This all looks OK. -----Original Message----- From: midrange-l-bounces@xxxxxxxxxxxx [mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of York, Albert Sent: Monday, September 08, 2003 3:11 PM To: 'Midrange Systems Technical Discussion' Subject: RE: Socket program problem I was think more along the lines of a single end-of-transmission (EOT) character. Anything that is not valid data (such as X'00' or X'FF') would do. However, when I read your earlier email I missed the part about the 1 minute delay before closing. That should be enough time for the data to make it to your PC. You might want to double check the program on the AS/400 to make sure it is the latest version. You could also try putting the AS/400 program in debug to make sure it is sending everything correctly. Albert York -----Original Message----- From: John Allen [SMTP:jallen@xxxxxxxxxxx] Sent: Monday, September 08, 2003 12:58 PM To: 'Midrange Systems Technical Discussion' Subject: RE: Socket program problem I thought about this, because it is the way I expected the program to be written. But then I found that I could send 2,000 bytes of data from the iSeries and the PC receives it in pieces. PC might receive the first 1990 bytes then the next receive would get the 10 bytes. If I end the transmission with "NO MORE DATA" The last receive on the PC might be "MORE DATA" (the "NO" might be included in the first receive the PC did. If I use this method I guess I would have to buffer all the received data on the PC and keep checking for NO MORE DATA then once it is received process the buffered data? Or am I confused? -----Original Message----- From: midrange-l-bounces@xxxxxxxxxxxx [mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of York, Albert Sent: Monday, September 08, 2003 12:30 PM To: 'Midrange Systems Technical Discussion' Subject: RE: Socket program problem 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. _______________________________________________ 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. _______________________________________________ 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. _______________________________________________ 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 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.
midrange.com
