ca.portal.admin

Re: IDMS Data Replication Via TCP/IP

Discussion created by ca.portal.admin on Nov 6, 2008
A couple of, ahem, not unbiased comments:

- the code required in support of this is not insubstantial, it may
require maintenance when and if CA changes the TCP/IP interface

- replication over TCP/IP is not going to be recoverable in the same way
as real time replication over MQ or offloaded journal based replication
using ftp

- if the code is embedded in an application, there is risk of the
application failing when an outboard component is unavailable

- if the code is independent of the application, say in an exit, then CV
performance and stability are issues

- a means will be needed to replicate during database recovery, perhaps
some means of reading the journal

A third party replication tool might address these issues at a
reasonable cost.

Jim Phillips
ISP
(800) 295-7608 x223

Date: Thu, 6 Nov 2008 11:35:35 -0500> From:
Harold.Govan@REEDELSEVIER.COM> Subject: IDMS Data Replication Via
TCP/IP> To: IDMSVENDOR-L@LISTSERV.IUASSN.COM> > Hi Everyone:> > I have a
question for folks using IDMS TCP/IP under R16.0.> > We are currently
using IDMS TCP/IP to support web-based apps coming in> from WebSphere.
We are contemplating doing selective data replication> to ORACLE and MS
SQL Server databases using TCP/IP enhancements to> existing IDMS-DC
applications.> > Has anyone out there done this type of replication
without the benefit> of a third-part product ? If so, I would appreciate
any information> you could share regarding your experiences.> > TIA> > >
Hal Govan> Senior Database Administrator> Reed Elsevier - Technology
Services> harold.govan@reedelsevier.com
<mailTo:harold.govan@lexisnexis.com>=20> Phone: (937) 865-7820
_________________________________________________________________
"
IDMS Public Discussion Forum
IDMS-L@LISTSERV.IUASSN.COM
SMTP
IDMS-L@LISTSERV.IUASSN.COM
IDMS-L@LISTSERV.IUASSN.COM
SMTP








Normal

Normal
Re: IDMS Data Replication Via TCP/IP
"I understand your points Jim and don't totally disagree.

Unfortunately, the one overriding issue you seem to minimize is $$$.

We already have many of the pieces and parts necessary to do the failure
management side of the problem. We also have some practical experience
with TCP/IP based on a year and a half working with in-bound
transactions.

We also do real-time replication to our D-R site and transmit copies of
journal extract files at every offload for the recoverability issue.

Having said this, I also acknowledge this will be a greater challenge
than our previous applications and wondered if others out there have had
success doing this type of processing and could share their insights.
=20

Hal Govan
Senior Database Administrator
Reed Elsevier - Technology Services
harold.govan@reedelsevier.com
Phone: (937) 865-7820

Outcomes