RE: Triggers Vs. Journalling

Thanks Tom...good points. No sense reinventing the wheel, especially if
I can use IBM's wheel and get support when things go sideways.

On Tue, 22 Jun 2004 15:43:36 -0400, "Tom Liotta" <qsrvbas@xxxxxxxxxxxx>
said:
> Michael:
> 
> I would tend to go with remote journaling first. You can get a long way
> towards the goal of replicating changes to the remote system before
> needing any programming at all, and all of that effort is based in
> IBM-supported functions. Only at the point of actually pulling entries
> off the journal and writing to the files does it become your code. By
> that time, the entries are already on the remote system, or perhaps,
> they're "queued" for sending.
> 
> If a trigger program is used (or three trigger programs), it seems you'll
> potentially be applying records to remote files _before_ they're actually
> applied on the source system. And without writing some kind of
> store-and-forward process which remote journaling can do for you and
> which significantly complicates your code, you risk major blocks simply
> because the trigger might not be able to complete properly. If a
> connection is down at the time the trigger fires, how do you want the
> trigger to respond?
> 
> In general, any trigger mechanism ought to be capable of handling
> situations that remote journaling can handle. To that end, a good study
> of what remote journaling can do seems a good start in designing any
> trigger process for this. Naturally, remote journaling was designed to
> handle needs of different IBM customers, so you can ignore aspects that
> make no useful sense for you. Still, it seems worthwhile as a design
> guideline.
> 
> Whenever possible, I like to place the burden on IBM as long as they
> supply a feature that's appropriate. Remote journaling seems appropriate
> here.
> 
> Tom Liotta
> 
> midrange-l-request@xxxxxxxxxxxx wrote:
> 
> >  10. Triggers Vs. Journalling (michaelr_41)
> >
> >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?
> 
> -- 
> Tom Liotta
> The PowerTech Group, Inc.
> 19426 68th Avenue South
> Kent, WA 98032
> Phone  253-872-7788 x313
> Fax    253-872-7904
> http://www.powertech.com
> 
> 
> __________________________________________________________________
> Switch to the New Netscape Internet Service.
> As low as $9.95 a month -- Sign up today at
> http://isp.netscape.com/register
> 
> Netscape. Just the Net You Need. 
> 
> New! Netscape Toolbar for Internet Explorer
> Search from anywhere on the Web and block those annoying pop-ups.
> Download now at http://channels.netscape.com/ns/search/install.jsp
> --
> This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing
> list
> To post a message email: MIDRANGE-L@xxxxxxxxxxxx
> To subscribe, unsubscribe, or change list options,
> visit: http://lists.midrange.com/mailman/listinfo/midrange-l
> or email: MIDRANGE-L-request@xxxxxxxxxxxx
> Before posting, please take a moment to review the archives
> at http://archive.midrange.com/midrange-l.
> 
-- 
  
  michaelr_41@xxxxxxxxxxxxxx