× 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.



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

As an Amazon Associate we earn from qualifying purchases.

This thread ...

Follow-Ups:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

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.