Re: Possible timing issue with IO

[Vernon Hamberg <vhamberg@xxxxxxxxxxxxxxx>]

hi Eric

That seems the likely suspect. If things are not out of the buffer, then 
DB management knows nothing about them, and the logicals won't be 
maintained, right?

Have you used the N extender on FEOD? Reference says that unwritten from 
a block get writ to database, although not necessarily to disk. So 
things should be available, I'd think.

Index maintenance is a part of this, maybe, although a request for a 
record know to DB should just make the program wait until maintenance is 
done, as I recall.

Thanks much!
Vern

On 1/24/2014 3:19 PM, DeLong, Eric wrote:
> Vernon,
>
> I'd suspect that you have data written to buffer that has not been flushed to disk yet.  You could try issuing a FEOD to the file before exiting.
>
> -Eric DeLong
>
> -----Original Message-----
> From: rpg400-l-bounces@xxxxxxxxxxxx [mailto:rpg400-l-bounces@xxxxxxxxxxxx] On Behalf Of Vernon Hamberg
> Sent: Friday, January 24, 2014 3:17 PM
> To: RPG programming on the IBM i / System i
> Subject: Possible timing issue with IO
>
> Y'all
>
> I haven't had to deal with quirky IO issues in a long time, so here goes
> with my problem - hope someone has seen this behavior.
>
> I have a program that reads through a file (let's call it VHFILE) from a
> certain position and is checking for duplicates of a type - not
> important - I'm using a state machine to handle this.
>
> When this program is called on its own, it finds the duplicates.
>
> When it is called from a program that just wrote to the file in
> question, it rarely finds anything - but it does sometimes catch 1 or 2
> instances of the problem.
>
> It seems that this new program doesn't see the data that was just written.
>
> VHFILE has 3 logicals - and VHFILE is quite large - one of what we call
> our big files.
>
> VHFILE - arrival - 51million
> VHFILEA - 51million entries - 1.5GB
> VHFILEB - 51million entries - 1.8GB
> VHFILEC - 10million entries (S/O) - 420MB
>
> OK, here's more info on the call stack -
>
> 1. CLPGMA - OPM
>        calls
>        2. CLPGMB - OPM with simple OVRDBF on file in question
>             calls
>             3. RPGPGMA - ILE - *CALLER - uses VHFILEA as UF A (update +
> add) and has deletes and writes
>                  calls (after all writes are done - the number varies, )
>                  4. CLPGMC - ILE - *DFTACTGRP
>                       calls
>                       5. RPGPGMB - ILE - QILE - uses VHFILEC as UF
> (update only) and has only deletes
>
> There is no need of sharing ODPs.
>
> I recognize the "flaky" activation group structure, but I don't think it
> should matter - in fact, it might help, to isolate opening VHFILEC from
> the open of VHFILEA.
>
> No commitment control in place - there is iTera for replication or whatever.
>
> So -
>
> 1. Is FEOD a way to overcome this?
> 2. And is the N extender useful? RPG Reference says it can perform
> better - unwritten records in a block are written to the database,
> although not necessarily to disk (non-volatile storage).
>
> Or some other idea.
> Thanks
> Vern