Guaranteed?
Journal and Commit. Without the connection at the commit... it's like it
never happened.
Jeff Wurst wrote:
That would seem to be a possibility. Unfortunately I can't get this to
happen in testing. My test programs continue to write records until the
program finishes, even when I unplug my network cable or close the
client access session. And if I kill the job via WRKUSRJOB or WRKACTJOB
then I still don't seem to be loosing any records.
Is there another way to drop my connection in a way that the iSeries
would know about and then drop the job without evening writing the
blocked records to disk?
Thanks!
Jeff
-----Original Message-----
From: rpg400-l-bounces@xxxxxxxxxxxx
[
mailto:rpg400-l-bounces@xxxxxxxxxxxx] On Behalf Of R Bruce Hoffman
Sent: Monday, July 09, 2007 3:52 PM
To: RPG programming on the AS400 / iSeries
Subject: Re: I need ideas on what could cause some records to not be
written
IIRC output only files are blocked.... updated in blocks of records. So,
if you are writing say, 3 or 4 records, and the link drops... poof! you
are SOL....
and, again, IIRC, changing from output only to input-output ( update),
could have an impact. And with RPG III, IIRC, you need some LR NLR READ
statements to prevent the compiler from changing your request back to
output only.
Jeff Wurst wrote:
I'm trying to resolve a difficult problem. We have an OPM RPG III
callable program that writes a set of records. The program is reading
from one file in a loop and writing records to another. We have some
users that are reporting that in rare cases (like a fraction of 1%)
only
a few of the records are being written. This callable program is
called
by another program when the user presses a key on a screen. A bunch of
other updates happen at the same time. In each reported case the users
were working on a wireless connection that was possibly unstable. The
program was running interactively.
Questions:
1) If a wireless connection gets dropped in mid-update won't the job
continue to run at least until the iSeries needs to display another
screen? Certainly the wireless connection looks like more than a
coincidence but we're having trouble fitting it in. If the problem is
caused by an unstable connection then why isn't it sometimes failing
on
some of the other updates?
2) We've looked at record locks and determined that the program isn't
reading any records for update until after the loop that writes the
missing records is completed. Therefore record locks don't appear to
be
an issue. We don't use any commitment control. Is it possible for a
user
to set some kind of configuration on the iSeries that would cause
written records to be un-written if the program went into a LCKW
status
after the write operations and then was terminated by a bad
connection?
Does anyone have any other thoughts on what might cause a program to
execute half a loop and then end suddenly?
Thanks for any ideas you may have.
Jeff
--
"Suppose you were an idiot...
And suppose you were a member of Congress...
But I repeat myself."
- Mark Twain
===========================================================
R Bruce Hoffman
midrange.com
