Attunity Change Data Capture (CDC) for RMS

[Jan-Erik Soderholm]

Hi.

We have an production environment where the data is
split between a number of RMS indexed files (the older
parts) and an Rdb database (mostly later subsystems).

Now, there is of course no problems to "use" the RMS
data from the normal applications, but ad-hoq queries
and "joins" with the Rdb data is another matter.

I have done a few replications (nighly or hourly), using
say Python, but it would be nice to have a online copy
in Rdb.

As far as I can see, "CDC for RMS" can do this, right?

I have searched the Attunity web but can only find
a 2 page datasheet. Does anyne know if there something
like a "user manual" available so that one can get a
feeling about the work involved to setup a replication
from RMS files to Rdb tables (on the same box).

I did talked (he was just boarding a plane) with the
swedish Attunity representative, and I got the impression
that one needed a Windows server box for the replication.
I want of course a 100%v VMS solution, in particular
since the source and target are on the same system.

Would it be possible to only use the "CDC Capture" part
and then add a Rdb update routine myself?

And is anyone here using "CDC for RMS" specificaly
for replication to Rdb? And if so, do you care to
share your thoughts about it?

Jan-Erik.

[abrsvc]

Hi.

Wouldn't it be simpler to write a simple utility to read the indexed files and place the data into the database directly? It seems using the capture would require more overhead. Better yet, have the applications write to both the RMS files and RDB?

The application environment I support now uses an external deamon to write to RDB keeping the RMS access within the app. Messages are sent via mailbox to the deamon for insertion into RDB.

Dan

[Jan-Erik Soderholm]

Post by abrsvc

Hi.

Wouldn't it be simpler to write a simple utility to read the indexed
files and place the data into the database directly? It seems using the
capture would require more overhead. Better yet, have the applications
write to both the RMS files and RDB?
The application environment I support now uses an external deamon to
write to RDB keeping the RMS access within the app. Messages are sent
via mailbox to the deamon for insertion into RDB.
Dan

The point with "CDC for RMS" is of course that it doesn't involve
any changes to the applications. The RMS accesses are not very
well isolated, so it would be quite a job to add extra code
everyware the RMS files are updated.

The long term solution I would prefer, would be to fully
migrate all data to Rdb, of course. That would be a still
larger job.

Anyway, let's see if someone are using this tool... :-)

Jan-Erik.

[V***@SendSpamHere.ORG]

Post by Jan-Erik Soderholm

Post by abrsvc

Hi.

Wouldn't it be simpler to write a simple utility to read the indexed
files and place the data into the database directly? It seems using the
capture would require more overhead. Better yet, have the applications
write to both the RMS files and RDB?
The application environment I support now uses an external deamon to
write to RDB keeping the RMS access within the app. Messages are sent
via mailbox to the deamon for insertion into RDB.
Dan

The point with "CDC for RMS" is of course that it doesn't involve
any changes to the applications. The RMS accesses are not very
well isolated, so it would be quite a job to add extra code
everyware the RMS files are updated.

Very true. Nothing on your system would know that RMS CDC is in there and
capturing updates to your selected RMS files.

Post by Jan-Erik Soderholm
The long term solution I would prefer, would be to fully
migrate all data to Rdb, of course. That would be a still
larger job.
Anyway, let's see if someone are using this tool... :-)

I'm not at liberty to disclose any customer names but there are several very
large installations using RMS CDC; whether their use is to perform the tasks
you are seeking to accomplish is completely unknown.

[Jan-Erik Soderholm]

Post by V***@SendSpamHere.ORG

Post by Jan-Erik Soderholm

Post by abrsvc

Hi.

Wouldn't it be simpler to write a simple utility to read the indexed
files and place the data into the database directly? It seems using the
capture would require more overhead. Better yet, have the applications
write to both the RMS files and RDB?
The application environment I support now uses an external deamon to
write to RDB keeping the RMS access within the app. Messages are sent
via mailbox to the deamon for insertion into RDB.
Dan

The point with "CDC for RMS" is of course that it doesn't involve
any changes to the applications. The RMS accesses are not very
well isolated, so it would be quite a job to add extra code
everyware the RMS files are updated.

Very true. Nothing on your system would know that RMS CDC is in there and
capturing updates to your selected RMS files.

Post by Jan-Erik Soderholm
The long term solution I would prefer, would be to fully
migrate all data to Rdb, of course. That would be a still
larger job.
Anyway, let's see if someone are using this tool... :-)

I'm not at liberty to disclose any customer names but there are several very
large installations using RMS CDC; whether their use is to perform the tasks
you are seeking to accomplish is completely unknown.

OK, fine. I have also contacted the Attunity representative
in Sweden.

According to him there was no "programming" involved for
replicationg RMS data to Rdb. Only configuration. Well,
that is what I'd like to verify in the documentation. :-)

Jan-Erik.

[V***@SendSpamHere.ORG]

Post by Jan-Erik Soderholm

Post by V***@SendSpamHere.ORG

Post by Jan-Erik Soderholm

Post by abrsvc

Hi.

Wouldn't it be simpler to write a simple utility to read the indexed
files and place the data into the database directly? It seems using the
capture would require more overhead. Better yet, have the applications
write to both the RMS files and RDB?
The application environment I support now uses an external deamon to
write to RDB keeping the RMS access within the app. Messages are sent
via mailbox to the deamon for insertion into RDB.
Dan

The point with "CDC for RMS" is of course that it doesn't involve
any changes to the applications. The RMS accesses are not very
well isolated, so it would be quite a job to add extra code
everyware the RMS files are updated.

Very true. Nothing on your system would know that RMS CDC is in there and
capturing updates to your selected RMS files.

Post by Jan-Erik Soderholm
The long term solution I would prefer, would be to fully
migrate all data to Rdb, of course. That would be a still
larger job.
Anyway, let's see if someone are using this tool... :-)

I'm not at liberty to disclose any customer names but there are several very
large installations using RMS CDC; whether their use is to perform the tasks
you are seeking to accomplish is completely unknown.

OK, fine. I have also contacted the Attunity representative
in Sweden.
According to him there was no "programming" involved for
replicationg RMS data to Rdb. Only configuration. Well,
that is what I'd like to verify in the documentation. :-)

Well, there's no programming involved if you use their "canned" solutions.

RMS CDC will capture all updates to RMS files you have interest in having
up-to-the-second updates for. Of Attunity's tools, these updates are then
exported to Linux or Weenzoze for further processing. RMS CDC captures a
file(s) $OPEN or $CREATE for file name and other VMS access information,
and then captures the record data that may be modified by RMS access, such
as a $PUT or an $UPDATE or a $DELETE. With the $UPDATE and $DELETE, the
"before image" can optionally be extracted. For $UPDATE, this is the data
in the record prior to applying the update; for $DELETE, it is the data in
the record being expunged.

There are a number of applications once having this data can provide. Hein
discusses a number of them with me but Attunity, AFAIK, is not interested
in persuing them. One is being to convert/optimize RMS files on the fly.

So, there my be some programming, if you can wrestle the RMS CDC component
from Attunity, but it would be external to your RMS applications. Those
applications would still continue to run without being touched.

[Jan-Erik Soderholm]

Post by V***@SendSpamHere.ORG

Post by Jan-Erik Soderholm

Post by V***@SendSpamHere.ORG

Post by Jan-Erik Soderholm

Post by abrsvc

Hi.

Wouldn't it be simpler to write a simple utility to read the indexed
files and place the data into the database directly? It seems using the
capture would require more overhead. Better yet, have the applications
write to both the RMS files and RDB?
The application environment I support now uses an external deamon to
write to RDB keeping the RMS access within the app. Messages are sent
via mailbox to the deamon for insertion into RDB.
Dan

The point with "CDC for RMS" is of course that it doesn't involve
any changes to the applications. The RMS accesses are not very
well isolated, so it would be quite a job to add extra code
everyware the RMS files are updated.

Very true. Nothing on your system would know that RMS CDC is in there and
capturing updates to your selected RMS files.

Post by Jan-Erik Soderholm
The long term solution I would prefer, would be to fully
migrate all data to Rdb, of course. That would be a still
larger job.
Anyway, let's see if someone are using this tool... :-)

I'm not at liberty to disclose any customer names but there are several very
large installations using RMS CDC; whether their use is to perform the tasks
you are seeking to accomplish is completely unknown.

OK, fine. I have also contacted the Attunity representative
in Sweden.
According to him there was no "programming" involved for
replicationg RMS data to Rdb. Only configuration. Well,
that is what I'd like to verify in the documentation. :-)

Well, there's no programming involved if you use their "canned" solutions.
RMS CDC will capture all updates to RMS files you have interest in having
up-to-the-second updates for. Of Attunity's tools, these updates are then
exported to Linux or Weenzoze for further processing. RMS CDC captures a
file(s) $OPEN or $CREATE for file name and other VMS access information,
and then captures the record data that may be modified by RMS access, such
as a $PUT or an $UPDATE or a $DELETE. With the $UPDATE and $DELETE, the
"before image" can optionally be extracted. For $UPDATE, this is the data
in the record prior to applying the update; for $DELETE, it is the data in
the record being expunged.
There are a number of applications once having this data can provide. Hein
discusses a number of them with me but Attunity, AFAIK, is not interested
in persuing them. One is being to convert/optimize RMS files on the fly.
So, there my be some programming, if you can wrestle the RMS CDC component
from Attunity, but it would be external to your RMS applications. Those
applications would still continue to run without being touched.

OK, thanks for the details.

I'll wait for the Attunity representative to come back.
Late Friday afternoon over here, so nothing will happen
today anyway...

About the $OPEN/PUT and so on. The actual RMS interface
is written in Fortran (called from our Cobol apps) and
uses code like:

READ (FILNR,300,KEY=KEYVAL,KEYID=KEYREF,IOSTAT=IRET)IRECL,BUFFER

(keyed read)

or

REWRITE(FILNR,200,IOSTAT=IRET) BUFFER

(rewrite current record)

I guess these uses the $-services...

Opening of the files are handled by a Macro routine
(called from the Fortran code through USEROPEN=xxx)
using $OPEN in the Macro code...

Regards,
Jan-Erik.

[V***@SendSpamHere.ORG]

Post by Jan-Erik Soderholm

Post by V***@SendSpamHere.ORG

Post by Jan-Erik Soderholm

Post by V***@SendSpamHere.ORG

Post by Jan-Erik Soderholm

Post by abrsvc

Hi.

Wouldn't it be simpler to write a simple utility to read the indexed
files and place the data into the database directly? It seems using the
capture would require more overhead. Better yet, have the applications
write to both the RMS files and RDB?
The application environment I support now uses an external deamon to
write to RDB keeping the RMS access within the app. Messages are sent
via mailbox to the deamon for insertion into RDB.
Dan

The point with "CDC for RMS" is of course that it doesn't involve
any changes to the applications. The RMS accesses are not very
well isolated, so it would be quite a job to add extra code
everyware the RMS files are updated.

Very true. Nothing on your system would know that RMS CDC is in there and
capturing updates to your selected RMS files.

Post by Jan-Erik Soderholm
The long term solution I would prefer, would be to fully
migrate all data to Rdb, of course. That would be a still
larger job.
Anyway, let's see if someone are using this tool... :-)

I'm not at liberty to disclose any customer names but there are several very
large installations using RMS CDC; whether their use is to perform the tasks
you are seeking to accomplish is completely unknown.

OK, fine. I have also contacted the Attunity representative
in Sweden.
According to him there was no "programming" involved for
replicationg RMS data to Rdb. Only configuration. Well,
that is what I'd like to verify in the documentation. :-)

Well, there's no programming involved if you use their "canned" solutions.
RMS CDC will capture all updates to RMS files you have interest in having
up-to-the-second updates for. Of Attunity's tools, these updates are then
exported to Linux or Weenzoze for further processing. RMS CDC captures a
file(s) $OPEN or $CREATE for file name and other VMS access information,
and then captures the record data that may be modified by RMS access, such
as a $PUT or an $UPDATE or a $DELETE. With the $UPDATE and $DELETE, the
"before image" can optionally be extracted. For $UPDATE, this is the data
in the record prior to applying the update; for $DELETE, it is the data in
the record being expunged.
There are a number of applications once having this data can provide. Hein
discusses a number of them with me but Attunity, AFAIK, is not interested
in persuing them. One is being to convert/optimize RMS files on the fly.
So, there my be some programming, if you can wrestle the RMS CDC component
from Attunity, but it would be external to your RMS applications. Those
applications would still continue to run without being touched.

OK, thanks for the details.
I'll wait for the Attunity representative to come back.
Late Friday afternoon over here, so nothing will happen
today anyway...
About the $OPEN/PUT and so on. The actual RMS interface
is written in Fortran (called from our Cobol apps) and
READ (FILNR,300,KEY=KEYVAL,KEYID=KEYREF,IOSTAT=IRET)IRECL,BUFFER
(keyed read)
or
REWRITE(FILNR,200,IOSTAT=IRET) BUFFER
(rewrite current record)
I guess these uses the $-services...
Opening of the files are handled by a Macro routine
(called from the Fortran code through USEROPEN=xxx)
using $OPEN in the Macro code...
Regards,
Jan-Erik.

Yup. If you're doing most any file access via any one of the supported
OpenVMS lingos (Basic, C, C++, Cobol, Fortran, Pascal,...) their support
RTLs invoke the RMS file services. The only thing that will not be able
to be captured would be raw $QIO IO$_WRITEVBLK I/Os. I doubt that there
are many doing that with ISAM files and, perhaps, relative files too.

[Doc Trins O'Grace]

I believe that IBM's Cognos PowerHouse gets in the way. Something in PowerHouse on OpenVMS does not tolerate RMS journaling... and mores the pity!

[V***@SendSpamHere.ORG]

Post by Doc Trins O'Grace
I believe that IBM's Cognos PowerHouse gets in the way.
Something in PowerHouse on OpenVMS does not tolerate RMS journaling...
and mores the pity!

Huh? Who has mentioned anything in this thread about RMS Journaling or IBM's
Cognos Powerhouse??? Neither have anything to do with Attunity's RMS CDC.

[Doc Trins O'Grace]

Post by V***@SendSpamHere.ORG
Huh? Who has mentioned anything in this thread about RMS Journaling or IBM's
Cognos Powerhouse??? Neither have anything to do with Attunity's RMS CDC.

Hi, Vaxman... ...that was me. I assumed that the Attunity data replication was built on RMS journaling. Your correction of me was helpful... I am now revisiting the CDC product as a consequence. Thank you!

[V***@SendSpamHere.ORG]

Post by Doc Trins O'Grace

Post by V***@SendSpamHere.ORG
Huh? Who has mentioned anything in this thread about RMS Journaling or IBM's
Cognos Powerhouse??? Neither have anything to do with Attunity's RMS CDC.

Hi, Vaxman... ...that was me. I assumed that the Attunity data replication
was built on RMS journaling. Your correction of me was helpful... I am now
revisiting the CDC product as a consequence. Thank you!

RMS Journaling is not used nor needed for RMS CDC. In fact, RMS Journaling
was the reason that I was contracted to develope RMS CDC; it didn't provide
what was needed by Attunity.

RMS CDC is integrated into executive mode (where RMS does its voodoo) with
RMS. It is completely transparent to any applications as well as to VMS.

[David Froble]

Post by V***@SendSpamHere.ORG
Yup. If you're doing most any file access via any one of the supported
OpenVMS lingos (Basic, C, C++, Cobol, Fortran, Pascal,...) their support
RTLs invoke the RMS file services. The only thing that will not be able
to be captured would be raw $QIO IO$_WRITEVBLK I/Os. I doubt that there
are many doing that with ISAM files and, perhaps, relative files too.

If you're using RMS files from any of the languages, including
assembler, I don't see any valid reason to step outside the RMS
routines. I do see lots of chances for things ending poorly. By
keeping strictly to use of the RMS routines, then things such as your
work for Attunity avoids missing some operations.

[V***@SendSpamHere.ORG]

Post by David Froble

Post by V***@SendSpamHere.ORG
Yup. If you're doing most any file access via any one of the supported
OpenVMS lingos (Basic, C, C++, Cobol, Fortran, Pascal,...) their support
RTLs invoke the RMS file services. The only thing that will not be able
to be captured would be raw $QIO IO$_WRITEVBLK I/Os. I doubt that there
are many doing that with ISAM files and, perhaps, relative files too.

If you're using RMS files from any of the languages, including
assembler, I don't see any valid reason to step outside the RMS
routines. I do see lots of chances for things ending poorly. By

Nor do I but I'm not the one with the application(s) doing the file access
needing to be captured.

Post by David Froble
keeping strictly to use of the RMS routines, then things such as your
work for Attunity avoids missing some operations.

The work I did for Attunity misses no operations. If they modify the file,
then they are captured.

[V***@SendSpamHere.ORG]

Post by abrsvc

Hi.

Wouldn't it be simpler to write a simple utility to read the indexed files and place the data into the database directly? It seems using the capture would require more overhead. Better yet, have the applications write to both the RMS files and RDB?

RMS CDC is incredibly efficient and it would capture the RMS updates in real
time.

Post by abrsvc
The application environment I support now uses an external deamon to write to RDB keeping the RMS access within the app. Messages are sent via mailbox to the deamon for insertion into RDB.

How "in-sync" does that keep your databases (Rdb<=>RMS)?

[abrsvc]

Post by V***@SendSpamHere.ORG
How "in-sync" does that keep your databases (Rdb<=>RMS)?

The database is used primarily for auditing, so there is no back-from-RDB pathway. This is simply a write to the database operation. The database is usually within a very small fraction of a second, up to date. Even during a busy transaction load, the farthest behind I have ever seen it was about 1/2 second.

Dan

[Jan-Erik Soderholm]

Post by abrsvc

Post by V***@SendSpamHere.ORG
How "in-sync" does that keep your databases (Rdb<=>RMS)?

The database is used primarily for auditing, so there is no
back-from-RDB pathway. This is simply a write to the database
operation. The database is usually within a very small fraction of a
second, up to date. Even during a busy transaction load, the farthest
behind I have ever seen it was about 1/2 second.
Dan

That is well within our requirements. But, it still need
changes to the application code.

If possible, I'd probably be happy with the "CDC capture"
part and then fix a "Rdb write" part in-house.

We'll see. Currently collecting information... :-)

Jan-Erik.

[V***@SendSpamHere.ORG]

Post by Jan-Erik Soderholm
Hi.
We have an production environment where the data is
split between a number of RMS indexed files (the older
parts) and an Rdb database (mostly later subsystems).
Now, there is of course no problems to "use" the RMS
data from the normal applications, but ad-hoq queries
and "joins" with the Rdb data is another matter.
I have done a few replications (nighly or hourly), using
say Python, but it would be nice to have a online copy
in Rdb.
As far as I can see, "CDC for RMS" can do this, right?

It could or can.

Post by Jan-Erik Soderholm
I have searched the Attunity web but can only find
a 2 page datasheet. Does anyne know if there something
like a "user manual" available so that one can get a
feeling about the work involved to setup a replication
from RMS files to Rdb tables (on the same box).

I'll forward your query (this post) to Hein. Knowning him, however, he may
see this before I email it to him.

Post by Jan-Erik Soderholm
I did talked (he was just boarding a plane) with the
swedish Attunity representative, and I got the impression
that one needed a Windows server box for the replication.
I want of course a 100%v VMS solution, in particular
since the source and target are on the same system.
Would it be possible to only use the "CDC Capture" part
and then add a Rdb update routine myself?

Anything is possible. ;) The question to ask of Attunity is whether they
will sell RMS CDC without all of the periphery that they now provide with
it. You may not need all of the off-box processing which their other bits
perform. I do technology; not sales and or marketing.

Post by Jan-Erik Soderholm
And is anyone here using "CDC for RMS" specificaly
for replication to Rdb? And if so, do you care to
share your thoughts about it?

I can't say that I'm doing that but I can most certainly answer any of your
questions about CDC specifics; especially, the capture component of the RMS
data because I developed it.

[Jan-Erik Soderholm]

Post by V***@SendSpamHere.ORG

Post by Jan-Erik Soderholm
Hi.
We have an production environment where the data is
split between a number of RMS indexed files (the older
parts) and an Rdb database (mostly later subsystems).
Now, there is of course no problems to "use" the RMS
data from the normal applications, but ad-hoq queries
and "joins" with the Rdb data is another matter.
I have done a few replications (nighly or hourly), using
say Python, but it would be nice to have a online copy
in Rdb.
As far as I can see, "CDC for RMS" can do this, right?

It could or can.

Post by Jan-Erik Soderholm
I have searched the Attunity web but can only find
a 2 page datasheet. Does anyne know if there something
like a "user manual" available so that one can get a
feeling about the work involved to setup a replication
from RMS files to Rdb tables (on the same box).

I'll forward your query (this post) to Hein. Knowning him, however, he may
see this before I email it to him.

Post by Jan-Erik Soderholm
I did talked (he was just boarding a plane) with the
swedish Attunity representative, and I got the impression
that one needed a Windows server box for the replication.
I want of course a 100%v VMS solution, in particular
since the source and target are on the same system.
Would it be possible to only use the "CDC Capture" part
and then add a Rdb update routine myself?

Anything is possible. ;) The question to ask of Attunity is whether they
will sell RMS CDC without all of the periphery that they now provide with
it. You may not need all of the off-box processing which their other bits
perform. I do technology; not sales and or marketing.

Post by Jan-Erik Soderholm
And is anyone here using "CDC for RMS" specificaly
for replication to Rdb? And if so, do you care to
share your thoughts about it?

I can't say that I'm doing that but I can most certainly answer any of your
questions about CDC specifics; especially, the capture component of the RMS
data because I developed it.

Thanks for your input!

OK, I didn't asked but I got the feeling that this was
the stuff you have been talkning about here. :-)

It would be nice of the Capture part had some documented
API or similar. It would be possible to write the Rdb part
in-house, I guess.

I am of course totaly uninterested in a solution involving
some "external" server (that we can't manage within our group)
and the RMS files and Rdb database is on the same physical
server anyway...

So currently I need either some "better" documentation
then the 2-page datasheet, or someone to ask. :-)

Thanks.
Jan-Erik.

[Hein RMS van den Heuvel]

Post by Jan-Erik Soderholm
Now, there is of course no problems to "use" the RMS
data from the normal applications, but ad-hoq queries
and "joins" with the Rdb data is another matter.

FYI: The Attunity AIS infrastructure with its 'CONNECT' drivers will happily execute a heterogenous query joining data from RDB and RMS, staying on OpenVMS all the time.

Post by Jan-Erik Soderholm
As far as I can see, "CDC for RMS" can do this, right?
I have searched the Attunity web but can only find
a 2 page datasheet.

The product delivers the RMS data broken down to columns into tables a 'staging area' on a middle tier, Windows or Linux not OpenVMS.

The missing link (I'll have to fix that!) is that this can also be used as a source datafeed to the Attunity REPLICATE product, which offers 'one-click' replaction (full-load + cdc) for RMS to any other DB, including RDB (through ODBC or OCI).

I have presented this in public a few times notably in Sweden last year (you were there!) and last week at the Boot Camp. I can get you slides.

Post by Jan-Erik Soderholm
Does anyne know if there something like a "user manual" available so that one > from RMS files to Rdb tables (on the same box).

There is the Replicate Usermanual, which I can make available,
But it is not offering that, not on the same on the same box.
There is a rather elaborate general purpose infrastructure in play which is available on Linux and Windows but not on OpenVMS.

Post by Jan-Erik Soderholm
I did talked (he was just boarding a plane) with the
swedish Attunity representative, and I got the impression
that one needed a Windows server box for the replication.

Largely correct. Linux is fine also

Post by Jan-Erik Soderholm
I want of course a 100%v VMS solution, in particular
since the source and target are on the same system.

I can appreciate that, but it makes no businesses sense for Attunity to port the infrastructure to OpenVMS.

Post by Jan-Erik Soderholm
Would it be possible to only use the "CDC Capture" part
and then add a Rdb update routine myself?

Anything is possible, for the right price.
At this point you would have to buy the (windows, linux) solution with the Logger and use only a small but critical part: The RMS-Logger.

That's will get the changes as raw records into a log file.
I have tools to consume those log files, but no 'solution'.
The tools could be adapted fairly easily to create per-file change table which can be consumed by a fairly generic(odbc?) tool to apply them to RDB, or with a bit more work the log file reader could push directly to RDB, but now you have field conversions to content with.

Post by Jan-Erik Soderholm
And is anyone here using "CDC for RMS" specificaly
for replication to Rdb?

Not to RDB. Yes to SQLserver.
Several, but we want more!

Jan> The point with "CDC for RMS" is of course that it doesn't involve
Jan> any changes to the applications. The RMS accesses are not very
Jan> well isolated, so it would be quite a job to add extra code
Jan> everyware the RMS files are updated.

Exactly. No application code changes.
Also ALL RMS record changes would be captured, not just the application as such.
DCL, Datatrieve, rogue programs, all.


Jan> It would be nice of the Capture part had some documented
Jan> API or similar. It would be possible to write the Rdb part
Jan> in-house, I guess.

It's a product / solution, not just a bunch of subroutines.

We can work with you (Professional Services) to create something more close to what you want but it is unlikely to be cost effective.
It may well be far more economical, and easier to manage long term, to accept that additional server (Does not have to be dedicated). Yes the data would travel off the box, and back into it. But if it allows you to buy a solution rather than create one, this may be a reasonable compromise.

Cheers,
Hein.

[Jan-Erik Soderholm]

Hein RMS van den Heuvel wrote 2014-10-10 17:38:

[A lot of good info about CDC for RMS, not quoted
here again...]

Thanks a lot for your input. I understand that the
main market is to migrate data *of* VMS. :-)

I can easily write a "loader" that makes a one-time
copy of a RMS file into an Rdb table. It is the online
update that is the "problem".

Ah, well. You can't have it all. :-)

Regards,
Jan-Erik.

[Arabella]

Hello dear,
thanks for your response to the mail which i sent to you,
please contact me through my email (***@hotmail.com) so that i will tell you more about my self i hope we can move from here OK.
Arabella