RE: Replication Opinions

Michael,

How frequent are the changes? Are they single changes or do the changes get batched together?

DDM over TCP/IP has better performance and it can make the remote connection invisible to a program. Performance is great for sequential access but sucks with indexed access.

You've just mentioned using SQL. Why not put the SQL in the trigger(s) to update the remote file from the trigger? Could really hurt performance on the local file but would be simpler for the remote update connection.

I'm also curious why the remote isn't just a DDM file pointed back to the local file? (Or vice versa)

Paul

Principal Programmer Analyst
IT Supply Chain/Replenishment

-----Original Message-----
From: midrange-l-bounces@xxxxxxxxxxxx [mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of Michael Ryan
Sent: Friday, January 07, 2011 8:49 AM
To: Midrange Systems Technical Discussion
Subject: Re: Replication Opinions

Great replies folks...thanks very much. I need to replicate the
changes on a near real-time basis, so a once a day file transfer won't
work for me. I've written code in the past to handle updates with the
remote journaling, so I may resurrect that code and modify it to fit
the current needs. MQ is licensed to one of the systems but not the
other, so that's probably not going to help. The budget is probably
just person hours - no room for package software.

What are folks thoughts about the continuing use of DDM? I just seem
to shy away from it anymore. I know it's still viable in a TCP/IP
environment, but I find it's not my first thought when it comes to
remote file access. I'd rather have some SQL code embedded in my
program that processes a remote connect and accesses the data that
way. Of course, that's not a good option when needing to access both
remote data and local data.

Thanks...

- Michael

On Thu, Jan 6, 2011 at 4:53 PM, Morgan, Paul <Paul.Morgan@xxxxxxxxxxx> wrote:

Exactly. ÂIf the file is small and updates aren't that frequent why go through the rigmarole of journaling, triggers or data queues. ÂJust blow the file over to the remote system occasionally. Â*UPDADD works if someone is in the file instead of *REPLACE which requires a lock on the file. ÂCourse the file would also have to have keys and no record locks on the remote system. ÂThat's why it would work 'in some conditions'.

Paul

Principal Programmer Analyst
IT Supply Chain/Replenishment


-----Original Message-----
From: midrange-l-bounces@xxxxxxxxxxxx [mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of Charles Wilt
Sent: Thursday, January 06, 2011 4:09 PM
To: Midrange Systems Technical Discussion
Subject: Re: Replication Opinions

That solution would be equivalent to replacing the destination file every time.

*UPDADD doesn't "update" changed records only...it updates any
existing record in the destination from the source.

*RPLADD would have been a better name :)

Charles

On Thu, Jan 6, 2011 at 3:46 PM, Morgan, Paul <Paul.Morgan@xxxxxxxxxxx> wrote:

Michael,

There is a software package called Mimix that does that automatically but it could be overkill for just one file.

Maybe a repeated CPYF with *UPDADD run on the remote system from a DDM file would work in some conditions.

Paul

Principal Programmer Analyst
IT Supply Chain/Replenishment


-----Original Message-----
From: midrange-l-bounces@xxxxxxxxxxxx [mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of Michael Ryan
Sent: Thursday, January 06, 2011 2:55 PM
To: Midrange Systems Technical Discussion
Subject: Replication Opinions

Have a file that I need to replicate in near real time to another
system. What techniques do folks use? I'm thinking of triggers on the
from file, remote SQL connect, ACD as appropriate. I guess journaling
would be an option too. Opinions welcome. Thanks...
--
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.


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

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


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