Change Data capture with RMS on OpenVMS

[Jon Pinkley]

Journaling would be better if you want to be able to track every change, but for resynchronizing, I don't see a big disadvantage to the CONNX CDC method, other than the need to scan every record for the sync. If the database is large, and only a very small number of records are changed between sync points, then the overhead will be higher than journaling.

But an advantage is that it doesn't have to journal every change. It just detects when the values are different than they were at the last "sync point".

Another advantage is that it detects differences, not the fact that the record has been updated. If someone is changing a flag field but the flag is returned to its original value before the next sync point, the data doesn't need to be copied.

Jon

[Richard J Maher]

Hi Vincent,

In the words of Mark Bradley (an ex-Rdb engineer) "The best way to replicated data is not at all!". Just curious what you're using the CDC for.

My version? Many moons ago I tried putting an RMS-like exec-mode lock on the record(s) I was "watching" hoping to get a blocking-AST when someone touched the record. (A slight problem is that COBOL doesn't honour the i-o-control clauses that tell it to wait for RMS locks (apply lock-wait 255?) and just returns an error from the read/write/delete etc and never triggers the BLAST :-(

Journal-mining seems to be the most feature rich - but there's that code-change again.

Cheers Richard Maher

[Hein van den Heuvel]

A little over 2 years ago, I wrote:

>> An other transparent alternative could be trhough SSI (System Service Intercept)... a major undertaking.

Well, this has now been under undertaken, by Attunity. They now offer an RMS-CDC product in their STREAMS offering. Let me assure you that it was indeed a significant task. But is seems worht while!

In the end SSI was not the right solution because or is process specific and more or less 'voluntarily'.

To do this properly one has to intercept all RMS calls, whether direct, through a Language RTL, Datatrieve, or even DCL.

See also:

http://forums13.itrc.hp.com/service/forums/questionanswer.do?threadId=1452391

Regards,
Hein

[Brian Schenkenberger]

Hi Vincent,

Since I am the party responsible for Attunity's RMS-CDC, I thought I'd expound Hein's comment and explain a bit about the RMS-CDC since others may use this forum as a resource when looking for such a solution.

Hein said: "To do this properly one has to intercept all RMS calls, whether direct, through a Language RTL, Datatrieve, or even DCL."

The Attunity solution does, indeed, intercept the SYS$rms services. This insures that anything writing to a file -- whether it be a direct invocation of an $RMS service or via one of the layer/language support RTLs -- will see the change data. Only a $QIO will not be captured but then, the product *IS* called RMS-CDC.

The system service interception was the simple part (proprietry). There are a great many things going on in the bowels of RMS that needed to be considered -- it's not just a copy of data being passed to the $RMS service. This was a project that consumed about 8 extremely intense months of my life -- 25 hours a day, 8 days a week. The before image was exceptionally onerous. Thus, real-time RMS-CDC is not something that is going to be easily replicated by any other provider.

If you're really looking for a "real-time" RMS-CDC solution, contact Attunity and get a demo of RMS-CDC.