Writing to Arrival Sequence file - not working properly

Hello all...

I'm wondering if anyone has ever run into this problem before.

While writing to a file with no index defined, so it is in arrival
sequence, after a number of records are written, it appears that the
program then begins writing to the beginning of the file, as if the
relative record # has been adjusted.


Ex: Normal record write

Record 1
Record 2
Record 3
Record 4
Record 5
Record 6


New flow:

Record 5
Record 6
Record 1
Record 2
Record 3
Record 4


No changes to the program or file have been made within the last three
years. There have been no recent PTF changes or OS updates. The
procedure has been working without issue for a number of years but the
last attempt to run it now reveals this situation. I've verified in debug
the point at which the process starts to jump ship but there are no error
messages or even warning messages.

Any idea what this might be?

Have a good day.


Blake Moorcroft
Analyst/Programmer - Corporate
Farrow
2001 Huron Church Road, PO Box 333, Windsor, Ontario N9A 2L6
Bus: 519-966-3003 ext. 566
blake.moorcroft@xxxxxxxxxx




From: Jeff Young <jyoung0950@xxxxxxxxx>
To: "RPG programming on the IBM i (AS/400 and iSeries)"
<rpg400-l@xxxxxxxxxxxx>
Date: 09/21/2015 10:35 AM
Subject: Re: Question on socket non block read
Sent by: "RPG400-L" <rpg400-l-bounces@xxxxxxxxxxxx>



Scott,
Going back to the article, I see where you initially set the socket to non
blocked.
When I attempt to implement this logic, I receive an error with the fcntl
function:
Flags = FCntl(Sock
: F_GetFL);
Flags = %BitOr(Flags : O_NONBLOCK);
FCntl(Sock
: F_SETFL
RNF7416: The types of the right and left hand side do not match in the
EVAL
operation.
: Flags);

My prototype is:
D fcntl PR 10I 0 ExtProc('fcntl')
D SocketDesc 10I 0 Value
D Command 10I 0 Value
D Arg 10I 0 Value Options(*NOPASS)

The definition for F_GETFL is:
D F_GETFL C CONST(6)

V6R1M0.

Any idea why this is causing a problem?

TIA.


Jeff Young
Sr. Programmer Analyst

On Sun, Sep 20, 2015 at 1:20 AM, Scott Klement <rpg400-l@xxxxxxxxxxxxxxxx>
wrote:

Jeff,

Yes, I understand all of that.

The reason it works when you have data in the socket is because the

recv()

API will return the data instead of waiting for more.

A blocking socket will sit and wait for more data. A non-blocking

socket

never sits and waits for more data.

This is NOT done within the nbrecv() routine... it must be done by you
before you call nbrecv. The article explains how to put the socket into
non-blocking mode. If you haven't put it into nonblocking mode. You

will

have the problem that you are reporting.

I understand what you are saying about moving the select before the recv
-- personally, i think this is a poor solution. In my experience, your
application will be more robust with the recv() first and using a
non-blocking socket.

-SK

On 9/18/2015 1:09 PM, Jeff Young wrote:

Scott,
I was using the nbrecv procedure from the article
http://iprodeveloper.com/rpg-programming/timeouts-sockets.
I copied the code from there and was using that version.
As long as the socket contained data, there was no problem.
As soon as there was no data available, the recv() function just hung

up.

I changed my procedure to move the recv() after the select() and now it

is

working fine.

--
This is the RPG programming on the IBM i (AS/400 and iSeries) (RPG400-L)
mailing list
To post a message email: RPG400-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/rpg400-l
or email: RPG400-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/rpg400-l.