Given the code shown, I'd suspect the program(s) that are adding
to/updating filea. If filea is journaled it might be worth examining
the journal entries.
On 8/19/2015 7:51 PM, Glenn Gundermann wrote:
I have a puzzling situation. The only thing I can think of is if buffering
of data might cause this problem. If I delete a record, can I re-read the
data if the delete is not forced to disk?
Here is my situation. Basically, I have a never-ending program that could
run for a week or more.
FHRITTRGDTAUF E K DISK USROPN
FHRITINTFC O E DISK USROPN
// Prototypes go here
// Set SQL options.
CloSqlCsr = *ENDMOD,
Commit = *NONE,
DatFmt = *ISO,
Naming = *SYS;
dow entryData <> END;
ReceiveDataQ('HRITTRGDTQ': '*LIBL': entryLength: entryData: WAITTIME); //
QRCVDTAQ api; wait = -1 = forever
*inlr = *On;
P ProcessData B
D ProcessData PI
setll *loval fileA;
dow not %eof(fileA);
// some calcs;
Today, we had 10 rows of extra data in fileB. The extra data is a copy of
5 previous rows made two times and shows a timestamp 3 minutes later than
the original data.
There is no MONITOR, *PSSR, or error handling program and no error messages
in the joblog.
If the delete didn’t work, I would expect an error.
I haven’t noticed this before and I am unable to recreate this problem at
fileA has a primary key that is the identity column.
Thank you for your time.
Work: (416) 675-9200 ext. 89224
Cell: (416) 317-3144
This mailing list archive is Copyright 1997-2019 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