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