RE: Triggers Vs. Journalling

["Dan Bale" <dbale@xxxxxxxxxxxxx>]

> -----Original Message-----
> From: midrange-l-bounces@xxxxxxxxxxxx / michaelr_41@xxxxxxxxxxxxxx
>
> I'd appreciate opinions (especially if they're based on fact <smile>)
> regarding remote database synchronization. I have a situation where I
> need to keep some files updated on a remote iSeries system in the
> unlikely event the main iSeries crashes. I can't go the package route
> now due to cost constraints. Since there are only three files (but large
> ones with a lot of records), I was thinking I could trigger the files on
> the main system and write add/change/delete records to a file. I could
> then transfer the file to the remote system (every x minutes) and apply
> those changes to the corresponding remote file. I could do the same
> thing with journalling.
>
> Thoughts?

It depends.  <g>

In my limited experience in using triggers & journaling to essentially do
what you're attempting to do, I have found that journaling is the "better"
way to go, primarily for assuring that one doesn't bring an application to a
halt because of a problem with a trigger program.  Also, depending on
exactly what the trigger program does and the system it's running on, there
may be a performance tax.

If you go the journaling route, you can have a batch program that does a
"never-ending" RCVJRNE to process adds/changes/deletes almost
instantaneously.

Also, others may have more experience with this, but I believe that you
could have the journal set up on your remote system and just set it and
forget it (no third party software required).  Check out the *RMTJRN
commands.

HTH,
db