On 10/23/2015 1:33 PM, Justin Dearing wrote:
Ok, I'll try that next time I'm in front of the computer. Do I have to do
anything to maintain the journal? Does it just grow with every insert or
update?
When one creates the journal (CRTJRN) one can specify that the system
manage cleaning up the receivers via the MNGRCV(*SYSTEM) DLTRCV(*YES)
parameters.
The following may not apply to OP, but I'll put it here for the archives.
I don't want to be 'that guy', because I believe in journalling, RI and
commitment control.
But.
Retrofitting an existing application with RI (constraints) can be touchy
because of how existing programs access those tables. Imagine this
scenario. Invoicing program goes through the order details and writes
detail records, summing up the total amount as it goes. When all the
detail records are written, the program writes the header, containing
the total amount among other things. This program has been running in
production for 10 years.
Now come along and add the RI constraint that the detail depends upon
the header. It's a perfectly reasonable rule, and the programs that you
are working on abide by it. But not Old Faithful - it inserts rows in
the wrong order, and the next time it runs, it will throw a hard error.
Why?
Because RI violations are exposed to programs using native access as I/O
errors, and virtually no RPG programmer codes database I/O with traps
for I/O errors.
So before adding RI to an existing table, some analysis will be needed
to ensure that existing code won't innocently break those RI rules.
midrange.com
