Rdb to Oracle & PostgreSQL: Seamless Database Migration
FAQ Categories
Preserve Your Rdb Investment
VX/SQLMOD automatically converts Rdb SQLMOD procedures and handles embedded SQL, ensuring your applications access modern databases without code changes.
VX/SQLMOD will convert Rdb SQLMODs to Oracle as SQLPCs or PostgreSQL as SQLPGCs.
Currently, VX/SQLMOD generates code with embedded SQL commands in C/C++. These databases do not have preprocessors for C/C++.
No, the SQLMOD API remains the same, so the application code does not have to change the calling sequence. On OpenVMS, the SQLMODs, SQLPCs, and SQLPGCs are completely interchangeable.
This is not an issue, the SQLPCs and SQLPGCs, will accept and return the dates as quadwords and will do the conversion between the formats automatically. Your OpenVMS application will continue to receive and send dates as quadwords. If you migrate your OpenVMS application to Linux using Sector7’s tools and libraries, the automatic conversion will still be done so your application logic does not need to change during the migration process.
A main goal of migrating from Rdb to Oracle or PostgreSQL is to have the application storage in a widely used environment, Oracle or PostgreSQL, that is accessible with a wide range of tools, applications and interfaces. If the dates were stored as quadwords in Oracle or PostgreSQL, the data could not be accessed by any other application, tool, utility or interface and the built-in date handling functions and methods in Oracle or PostgreSQL could not be used.
By doing on-the-fly conversions, the date fields are stored as regular dates in Oracle and PostgreSQL and accessible by every other tool or app, and your OpenVMS application still uses the familiar VMS quadword date, which is needed for the many system services.
Yes. Tinyints do not exist in Oracle and PostgreSQL. Also, since these RDBMS have data integrity built-in, you can’t just use a CHAR and put a number in it that can go from 0 to 255.
We have built-in a mechanism for automatic conversion from tinyints to smallints. We even have a mechanism to handle a CHAR if your OpenVMS hides a character in a tinyint.
We would need to look at each case, but generally speaking, as long as we know which data field may be “overloaded” with various types of data representation, that should not be a problem. We would simply treat the field as RAW (Oracle) or BYTE (PostgreSQL) in the database to not run afoul of the data integrity mechanisms and return the data back to the application to continue operating as before.
These types of large data retrievals are not uncommon in older applications, especially those that originally used RMS files to store the data. VX/SQLMOD inserts special procedures in the new SQLPCs and SQLPGCs, specifically designed for these retrievals by packaging multiple records and use of prefetching techniques in Oracle and PostgreSQL.
These techniques are hidden from the application, but tremendously speed up the retrieval of records in a OPEN CURSOR/FETCH scenario. These can be adjusted if necessary.
We have seen some very complex (hundreds of lines of code) procedures in sophisticated SQLMODs. The test harnesses that are automatically generated by VX/SQLMOD allow for easy testing of any SQLMOD procedures that have been translated into SQLPC or SQLPGC procedures, for use with Oracle or PostgreSQL. This individual testing can be performed at will and even provides timing information. The test harnesses can even use the existing SQLMODs, if performed on OpenVMS for comparison purposes.
In complex applications, it can oftentimes be difficult to test a specific procedure in an SQLMOD/SQLPC/SQLPGC, and the test harnesses are invaluable to for testing these procedures directly.
