×
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 your comments.
I really just wanted to confirm my belief that the journal sequence numbers
accurately depicted when the records were written to disk.
After a couple of quick tests, I believe they do - as Charles says above -
the RPG buffering is prior to the record being passed to the DB and hence
the journal entries being created.
Here was my test:
I have two files which have identical columns.
The first column is an INT which is defined as a Primary Key in FileA, but
not in FileB (which has no Primary Key)
The RPG program defines them both for OUTPUT only.
The RPG program writes to FileA then to FileB in a loop repeated 10 times,
so the write sequence is FileA, FileB, FileA, FileB, FileA, FileB ...
Compiling the program shows RNF7086 against BOTH files - RPG handles
blocking for the file. INFDS is updated only when blocks of data are
transferred.
When the RPG program opens FileA with the primary key - the joblog shows:
Message . . . . : Open of member FILA was changed to SEQONLY(*NO).
Cause . . . . . : Member FILEA file FILEA in library CRAIGTEMP was
opened with the SEQONLY(*YES) parameter specified in the program or on the
Override Database File (OVRDBF) command. However, the parameter has been
changed to SEQONLY(*NO) because of condition 1 shown below:
1 - The program opened member FILEA for output operations only and
SEQONLY(*YES) was specified with the default number of records.
SEQONLY(*YES) was changed to SEQONLY(*NO) to allow the program to handle
duplicate key, conversion mapping, key mapping, and select or omit errors,
or both select and omit errors at the time of the output operation.
Which demonstrates what I'd thought and Charles confirmed - the RPG program
opened the file with SEQONLY(*YES) because it was specified for OUTPUT
only, but then because there was a primary key - changed it to SEQONLY(*NO)
As I mentioned above, the sequence of writes in the program was:
For i = 1 to 10;
Write FileA;
Write FileB;
EndFor;
But the journal entries clearly show 10 writes to FileA, followed by 10
writes to FileB because FileB (the one without the primary key) was opened
and left as SEQONLY(*YES) and therefore the output was buffered.
So - all good.
Question asked and answered!
thanks and regards,
Craig
As an Amazon Associate we earn from qualifying purchases.
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.