CONNX For DBMS ?

[Ofery]

Hello all,

We are considering to use CONNX to mirror our VMS-DBMS on a Windows-SQL.

I wonder if someone can share his/her experience regarding using CONNX with DBMS ?

Regards /Ofer

CONNX:

"The CONNX Codasyl DBMS Module provides secure, realtime, read/write, SQL access to Codasyl DBMS data-bases running on VAX and Alpha OpenVMS platforms, with connectivity through TCP/IP or Pathworks"

[Brad McCusker]

Typically, CONNX is used to provide a “relational-like” front end to DBMS, but not to “mirror”  (make/maintain a relational copy) --  and because you don’t’ have a relational “mirror” database, you are still accessing the DBMS database.  Creating a true “mirror” within CONNX would be challenging.

Would it work better for you to actually replicate your DBMS database to a relational database (SQL Server, Oracle or Rdb)?  This way, you would be accessing a real relational database that would be a copy (mirror) and you can take advantage of all power and features of relational databases.

If a copy or mirror is really what you want, our firm has a product called SCI TranSSend, that allows you to create relational databases from a  DBMS database backup and then continually keep the relational database up-to-date using only the after image journals (AIJs).  This is extremely efficient – and because there is no DML access to the production database, there is no impact on your production DBMS environment.

With CONNX:

• The queries still run against the production DBMS database – thus impact the performance/locking on your production system/database.
• You can’t create indexes needed for reporting to improve performance.
• You can’t create views that can simplify the queries to the end users.
• Tools are limited to the types of connections supported by CONNEX.

With SCI TranSSend:

• Queries run against a native relational database
• You can create indexes, triggers, views, stored procedures, etc. to support your business requirements.
• You can use all of the tools/access methods supported by the native relational database (Oracle, SQL Server, Rdb…)

If our TranSSend product might be of interest, please contact me at mccusker@sciinc.com.  We will be happy to tell you more about SCI TranSSend and even arrange a demonstration if interested.

Brad McCusker

Software Concepts International

www.sciinc.com

[Ofery]

Hello,

The SCI TranSSend sounds interesting !

What I really need is to keep an up-to-date SQL from the production DBMS all day. Means when a user update the DBMS, the SQL will be updated immediately or after few seconds.

Will SCI TranSSend work both ways (from DBMS to SQL & from SQL to DBMS) ?

Will SCI TranSSend support RMS files as well (from VMS to Windows) ?

How SCI TranSSend handles other than English data (like Hebrew) from DBMS to SQL ?

Regards /Ofer

[Hoff]

Any reason not to use ODBC or JDBC for remote access, and remote access into the database?  It's feasible to perform distributed transactions, after all.

FWIW, most of this question does look to be a question of interfacing Oracle DBMS and Microsoft SQL Server environments, which — Brad's expertise aside — really isn't the most common topic here in the HP OpenVMS forum.  Put another way, you might want to try the Oracle discussion forums, as they've almost certainly encountered similar questions over there.

Microsoft also has some related materials.

[Hein van den Heuvel]

Solid  reply Brad. Thanks.

Ofer> Will SCI TranSSend support RMS files as well (from VMS to Windows) ?

Hi Ofer, Not tranSSend, but Connx can and Attunity also.

Connx uses a repeating data level file scan, looking for changes in bucket CRC values to detect changes after the fact.

The Attuniry RMS-Logger product uses an intercept to record changes to a change log.

Those changes can be presented in basic change tables, for an (SSIS? Java?) application  to pick up and process.

With the help of the Attunity Replicate product they can be applied to just about any target DB desider (SQLserver, Oracle, MySQL, Vertica, PDW, Netezza,...) to keep an target DB in sync in near real time without programming.

Regards,

Hein van den Heuvel

(Yes, I work for Attunity and helped implement the RMS-Logger)