Re: Possible timing issue with IO

You need FEOD(N) to be sure of catching anything written by the program Vern.

There may also be an impact from different blocking in the two programs that update the file - but using FEOD should fix it. For sure use the (N) extender. FEOD without it is a performance pig.

On 2014-01-24, at 4:16 PM, Vernon Hamberg <vhamberg@xxxxxxxxxxxxxxx> wrote:

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

Jon Paris

www.partner400.com
www.SystemiDeveloper.com