Re: Record should be there, but isn't.

[Charles Wilt <charles.wilt@xxxxxxxxx>]

James,

If I'm reading that right, it sounds as if another process is writing
out the record correct?

In that case, does the other process have the file specified as
output-only?  If so, then my guess would be that the RPG program in
the other process is buffering the writes.  So the DB doesn't see that
record till other process closes...

If the customer can change the other process, see if they can add a
FEOD(n) to it.  I wouldn't do it after every record, but do it before
the process goes back to it's wait state.

If the code can't be changed, one external way to force RPG to not
buffer the writes, would be to create a unique index over some set of
fields in the file.

HTH,
Charles

On Thu, Oct 21, 2010 at 10:59 PM,  <jamesl@xxxxxxxxxxxxxxxxx> wrote:
> I'm having a weird (and embarrassing, since it's happening on a customer
> box where it worked just fine in a test environment) problem in which I'm
> attempting to chain to a record that should be there, yet somehow isn't.
>
> I've got debugging code in the program, that logs the record ID and the
> time in which access was attempted, if the RPG CHAIN statement fails. And
> the program that writes the record I'm trying to read puts several
> timestamps in the record itself. In every case in which I've been able to
> find the record myself, the timestamps on the record have been either the
> same second as the CHAIN, or a second or two earlier.
>
> I'm thinking about double-checking that I really AM attempting to chain to
> the record, but assuming I am, can anybody think of a reason why this
> would happen, and yet wouldn't throw exceptions (as I might expect with a
> lock collision)?
>
> --
> JHHL
> --
> 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.