× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



Thanks for the link. I may also have been thinking about the "dirty bit" on
a memory page.



-----Original Message-----
From: rpg400-l-bounces@xxxxxxxxxxxx [mailto:rpg400-l-bounces@xxxxxxxxxxxx]
On Behalf Of Charles Wilt
Sent: Saturday, January 25, 2014 5:46 PM
To: RPG programming on the IBM i (AS/400 and iSeries)
Subject: Re: Possible timing issue with IO

Roger,

You're remembering...but the "dirty bit" is in the DB.

The problem here is that RPG does it's own buffering, so the DB doesn't yet
know the record has been added. FEOD(N) forces RPG to flush it's buffers to
the DB.

http://www-01.ibm.com/support/docview.wss?uid=nas8N1018493

Charles


On Fri, Jan 24, 2014 at 5:18 PM, Roger Harman
<roger_harman@xxxxxxxxxxx>wrote:

I always thought there was a "dirty bit" set when a record is
added/changed to avoid such an issue.

Am I recalling something about this incorrectly? (Obviously so, it
would
seem)



-----Original Message-----
From: rpg400-l-bounces@xxxxxxxxxxxx
[mailto:rpg400-l-bounces@xxxxxxxxxxxx]
On Behalf Of Vernon Hamberg
Sent: Friday, January 24, 2014 2:04 PM
To: RPG programming on the IBM i (AS/400 and iSeries)
Subject: Re: Possible timing issue with IO

Thanks much - this confirms what we are seeing.

Ah the pain of needing immediate visibility!!

Vern

On 1/24/2014 3:52 PM, Jon Paris wrote:
The difference between FEOD and FEOF(N) is that in the former case
your
program is suspended until the data makes it all the way onto the
physical disk (or at least the drive's cache I guess). When you use
the (N) extender you are telling the OS that you are happy to rely on
the content of its buffers and don't actually need the data to be forced
to the actual disk.
The speed differences are significant. You'll barely notice FEOD(N)
but you will notice FEOD.


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

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





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


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


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



As an Amazon Associate we earn from qualifying purchases.

This thread ...

Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.