RE: Triggers Vs. Journalling

Remote journaling works great.  It takes some programming to get up and
running.  Once you have the journal working for one file, you can simply add
additional files with no programming.  Gives you near real time mirroring
too.  Trigger can work great too.  Especially if you need the write on the
remote file before you return to the application.  I would use a DDM file
though and not transfer a batch.  But if communications is down, the DDM
will fail and so will the application.

So the question is, do you want REAL time of NEAR real time?

I would go with the journaling as long as the file updates are one way.  Now
if you need to modify the file on more than one system, well we do that here
and I must say, journaling does not work, nor does any mirroring package
that I can afford.

Chris Bipes

-----Original Message-----

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?