Re: Possible timing issue with IO

[Vernon Hamberg <vhamberg@xxxxxxxxxxxxxxx>]

Tried FEOD both with and without the N extender - it didn't help.

I also just tried USROPN with open/close around the writing subroutine. 
Didn't work.

The file in question is a logical file - is there a difference in how 
FEOD affects an LF vs a PF?

My next attempt is to use the PF as output-only - leave the LF for its 
use to check for and maybe delete under certain conditions. Then use 
USROPN on the PF.

This is most curious. The call to my cleanup program is within the 
program that is writing to this file. The cleanup uses a different LF 
(with S/O) to walk through what was just written, based on pair of 
numeric date/time fields.

Hmm, just had a thought - I have to be sure that my date/time is not too 
recent - that the upload date & time might not be earlier than the last 
run of my cleanup.

OK - having y'all for a blank wall is always helpful - will let you know 
what's up - because it seems the FEOD should have worked.

Vern

On 1/24/2014 3:48 PM, Jon Paris wrote:
> 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