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



The remote locations are in different states, so I can't have the working
and non-working locations swap PC's But I could have them try another PC at
the same location.

I could have them try their PC and access the iSeries at my location to see
if it makes a difference?

I will try these two.



-----Original Message-----
From: midrange-l-bounces@xxxxxxxxxxxx
[mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of York, Albert
Sent: Thursday, September 11, 2003 11:43 AM
To: 'Midrange Systems Technical Discussion'
Subject: RE: Socket program problem

Does the problem happen regardless of which PC you use? Have you tried using
a PC from a location that works correctly? 

Albert York                          


        -----Original Message-----
        From:   John Allen [SMTP:jallen@xxxxxxxxxxx]
        Sent:   Thursday, September 11, 2003 9:14 AM
        To:     'Midrange Systems Technical Discussion'
        Subject:        RE: Socket program problem

        Well,  I have tried everything I can think of and what you guys
suggested
        and still losing the connection before all data is received by the
PC
        client.

        I am going to explain what is happening in a bit more detail in the
hopes I
        am doing something wrong.

        The iSeries is acting as the Server and it sits and waits for the PC
Clients
        to connect.
        The PC sends a request for a file to the iSeries and then waits for
a
        response back (Event message).
        The iSeries builds the file and sends it back to the PC one record
at a time
        (in XML format) The building of the file and sending all of the
records in
        XML format takes about 2 seconds.
        While the iSeries is sending the records, the PC client starts
receiving the
        records in groups (number of records it receives with each receive
varies
        from 1-5 records at a time) Before the PC receives all the records
it
        receives a 10053  WSAECONNABORTED and transmission is terminated.

        I read somewhere that after sending data I should wait for an ack
before
        proceeding. Does this mean when the iSeries send a single record it
should
        wait til the PC receives it and the PC send an ack back to the
iSeries, then
        the iSeries should send another record etc. etc. ?

        In this application when the iSeries receives a request (ie PC wants
file x)
        The iSeries spawns off a separate job that builds the file and send
the data
        to the PC. 
        The iSeries never acknowledges to the PC that it got the request. It
just
        builds the file and starts sending records to the PC. When the
iSeries
        program (spawned program) is done sending the records it ends. 
        The PC (client) starts receiving the records and when done receiving
the
        records it displays them. 

        At all 10 remote locations, if the file requested is small (about 10
        records) all 10 locations work fine, they receive all data just
fine.

        But when the file requested is larger (about 20 or so records)
        Two of our 10 remote locations never receive all the data They both
        consistently get the 10053  WSAECONNABORTED before all records are
received.

        We were going to re-write the application tonight and write it so
that
        whenever the PC or the iSeries sends data (even after each
individual( they
        are going to wait until the other side ack that they received the
data and
        is waiting for the next

        Is this a waste of my time? The programmers here are just guessing
at what
        it could be, but we are out of ideas except for this rewrite.

        New program would
        1) iSeries waiting for request
        2) PC send req to iSeries for file X, then waits for ack from
iSeries
        3) iSeries receives request for file x, sends ack to the PC that the
request
        was received and spawns Job A to build the file and transmit to PC
        4) PC get ack from iseries and waits for data
        5) iSeries Job A build file and sends record 1 (with X'FF' at end of
record)
        then waits for ack from PC that the record was received
        PC receives record 1 and knows it is complete because of x'FF' and
send ack
        to the iSeries
        6) iSeries receives ack from PC and the two go back and forth til
all
        records are sent and received.

        Is there any chance this might fix my problem?

        John   

        -----Original Message-----
        From: midrange-l-bounces@xxxxxxxxxxxx
        [mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of Scott Klement
        Sent: Monday, September 08, 2003 5:06 PM
        To: Midrange Systems Technical Discussion
        Subject: RE: Socket program problem



        On Mon, 8 Sep 2003, John Allen wrote:
        >
        > Would it be abnormal for a PC program to take 2 minutes to read
10,000
        > bytes

        Depends on the speed of the connection and how busy the line is, I
guess.
        10000 bytes in 2 minutes is what?  666bps?  About half the speed of
a 1200
        baud modem!  If the line is VERY busy, I guess that's possible.
Seems
        unlikely, though.

        I'd say it's more likely that something is wrong with their setup.
Either
        the PC program is poorly written, or theres a problem with the
networking
        between the iSeries and the PC that's causing it to drop packets.

        >
        > of data? It takes the iSeries .05 (5 hundredths of a second) to
send the
        > data.
        >

        How could the iSeries take 0.05 seconds if the PC takes 2 minutes?
Are
        you just talking about the time it takes to put the data into the
buffer?
        (The time it takes for the send() or write() API to complete?)

        > I will set it to 240 and see if it makes a difference
        > I should be able to see if the amount of data received on the PC
at least
        > increase from 16 records currently being read before it ends.

        Worth a try.

        >
        > I will also add a X'FF' at the end of the transmission and change
the
        Client
        > to look for it to stop receiving data.
        >

        If that helps, it'd probably imply that something was written
incorrectly
        in the application.

        > When I said that the PC is waiting for an acknowledgment that data
was
        ready
        > to be retrieved I was talking about Windows Event Message. I did
not
        realize
        > it would receive one for each part of the transmission. So that
must not
        be
        > the problem.

        Well, again, it could be if the PC program isn't completely reading
all
        data from the socket's buffer each time.

        >
        > I believe (correct me if I am wrong) that the Event message
carries with
        it
        > the number of bytes to be read from the buffer.
        >

        No, there's no byte count associated with the message.  (At least
not if,
        as I surmise, he's using the WSAAsyncSelect() API with FD_READ)
        If you think about it, it wouldn't make sense to give a number of
bytes
        since windows event messages are queued, and the potential exists
for a
        lot of new data to be added to the buffer between the time the
message
        is added to the queue and the time that recv() is called.

        The way I use that API is to use a non-blocking socket to read the
data,
        and simply read the socket until I get a WSAEWOULDBLOCK error
indicating
        that I've retrieved everything.

        Good Luck!
        _______________________________________________
        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 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.