Rdb to Oracle & PostgreSQL: Seamless Database Migration

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.

No. VX/SQL-COBOL (part of Sector7’s Vx/SQLCC toolset) is designed specifically to avoid COBOL rewrites. It processes COBOL source containing embedded SQL and produces either an in situ solution — where SQL runs from within COBOL in a single compile step — or a one-time extraction where SQL is moved to external C/C++ modules with all host variable bindings generated automatically.

Either way, the original COBOL program structure and business logic remain intact. No manual rewriting of SQL calls or host variable handling is required.

RDML (Rdb Data Manipulation Language) is the verb-keyed, record-at-a-time language Oracle/DEC Rdb embeds in host programs. VX/RDML is Sector7’s source-to-source converter that parses RDML in COBOL, BASIC, FORTRAN, C, and Pascal and rewrites it into standard EXEC SQL for PostgreSQL or Oracle.

See the VX/RDML technical page for the full verb grammar and SQL mapping reference.

In situ mode processes the embedded SQL as part of the COBOL compile step. The SQL remains within the COBOL source and runs against PostgreSQL or Oracle with minimal changes to the application. This is the fastest migration path with the least disruption to the existing codebase.

One-time SQL extraction permanently separates the SQL from COBOL. The SQL is extracted into external C/C++ modules (.pc for Oracle Pro*C, .pgc for PostgreSQL ECPG), with all host variable bindings generated automatically. Future SQL changes are maintained in those C/C++ modules rather than in the COBOL source. This approach suits long-term maintainability where SQL development continues independently of the COBOL codebase.

Both modes are part of Sector7’s Rdb to Oracle/PostgreSQL toolset bundle. Contact us to discuss which mode fits your migration goals.

VX/RDML uses a shared RDML parser across five host languages. A small slicer per language finds RDML regions in the source; the same lexer, AST, expression engine, and SQL emitter run for all of them.

Supported hosts include COBOL (.rco, .cob, .cbl), Pascal (.rpa, .pas), FORTRAN, DEC/VAX BASIC, and C. Only host-variable declarations and the EXEC SQL wrapper differ per language.

PostgreSQL’s ECPG preprocessor processes embedded SQL in C and C++ only — it has no support for COBOL or FORTRAN. There is no COBOL preprocessor available for ECPG, which means any COBOL application with embedded Oracle Rdb SQL has no standard path to PostgreSQL without either a full manual rewrite or Sector7’s Vx/SQLCC.

Vx/SQLCC bridges this gap by automating the conversion: it generates ECPG-compatible C/C++ modules from the COBOL source, with all host variable bindings, data type conversions, and return code mappings handled automatically. The COBOL application calls the generated modules and continues to function without modification. See the VX/SQLMOD page for how the same approach applies to Rdb SQLMOD files.

No. VX/RDML converts RDML regions only. Surrounding COBOL, Pascal, FORTRAN, BASIC, or C logic is passed through unchanged. RDML statements such as FOR, STORE, GET, and START_TRANSACTION are translated to equivalent EXEC SQL (cursors, DML, transactions) while the host program structure stays intact.

For broader migration planning, see OpenVMS to Linux and UNIX migration services.

Both data types are converted automatically — no manual intervention is required in the COBOL source or in any generated C code.

PACKED DECIMAL is converted to ANSI NUMERIC when passing data into the database, and converted back from ANSI NUMERIC to PACKED DECIMAL when data is returned to the COBOL program. QUADWORD datetime (the OpenVMS date and time format) is similarly converted to SQL datetime on input and back to QUADWORD on output.

Neither PostgreSQL nor the classic Oracle client natively supports PACKED DECIMAL or QUADWORD datetime, making automatic conversion a prerequisite for any successful migration. The same conversions apply to FORTRAN applications — see the VX/ESQL-FORTRAN tool page for details.

Yes. VX/RDML emits dialect-appropriate SQL — for example CONNECT / LIMIT / RETURNING ctid for PostgreSQL, and Oracle-specific forms such as ROWID and FETCH FIRST n ROWS ONLY where required.

Organisations leaving Oracle Rdb can also review the Rdb to Oracle/PostgreSQL toolset bundle and related tools such as VX/SQL-COBOL for embedded SQL in COBOL.

On Linux, Vx/SQLCC works with Fujitsu NetCOBOL and OpenCOBOL / GnuCOBOL. These are the recommended COBOL compilers for migrated applications running against PostgreSQL on Linux, where no COBOL preprocessor for ECPG exists — making the Sector7 converter the required bridging tool.

For Oracle on Linux, the Oracle COBOL preprocessor is an option, though Vx/SQLCC can alternatively generate C/C++ modules that interact directly with Oracle Pro*C, regardless of the COBOL compiler in use. Contact us to discuss which compiler and database target combination is right for your environment.

An RDML FOR … END_FOR over a record selection expression (RSE) becomes a synthesised cursor: DECLARE CURSOR, OPEN, repeated FETCH, and CLOSE. GET items inside the loop are folded into the cursor’s FETCH INTO list.

STORE maps to INSERT, MODIFY to UPDATE … WHERE CURRENT OF, and ERASE to DELETE … WHERE CURRENT OF. Transaction verbs (START_TRANSACTION, COMMIT, ROLLBACK) map to standard SQL transaction statements.

Yes. Vx/SQLCC operates across all three platforms. On x86 OpenVMS, it runs against PostgreSQL — the only enterprise database client available on that platform, since Oracle Rdb will not be ported to x86 and is end-of-life in December 2027. On Itanium OpenVMS, it supports the Oracle client 11g connecting to Oracle 19c. On Linux, it enables legacy COBOL applications to run with PostgreSQL using Fujitsu NetCOBOL or OpenCOBOL/GnuCOBOL.

Both in situ and one-time extraction modes are available on all supported platforms. Organisations migrating away from Oracle Rdb can explore the complete Rdb to Oracle/PostgreSQL toolset bundle for the full picture of available tools.

Some RDML features are recognised but preserved as comments with warnings — for example segmented-string FOR loops, INVOKE of external Rdb modules, BATCH_UPDATE transactions, and some WAIT/NOWAIT semantics. VX/RDML writes details to a .rdml.warnings.txt sidecar file.

With --strict, the converter exits non-zero when unsupported constructs are encountered. Contact Sector7 to review a representative source sample before production migration.

In in situ mode, the COBOL source is minimally modified. SQL statements are handled by Vx/SQLCC as part of the compile step, and the original COBOL file structure, control flow, and business logic are preserved without permanent changes to the source.

In one-time extraction mode, the COBOL source is updated to replace embedded SQL statements with calls to the generated external procedures. The original program logic remains intact. A COBOL copybook (.CPY) is also generated, containing the procedure definitions for calling the external SQL module. This approach is compatible with Sector7’s zero code freeze methodology, allowing active COBOL development to continue throughout the migration.

Yes. Vx/SQLCC’s capabilities extend beyond embedded SQL in COBOL and FORTRAN to include Oracle Rdb SQLMOD file conversion. SQLMOD procedures are converted to C/C++ modules incorporating Sector7’s proprietary record-access optimisation, which preserves the performance characteristics of legacy Rdb cursor fetch loops when running against PostgreSQL.

Two modes are supported: single-use (SQL maintained in the generated C/C++ module going forward) and multiple-use (SQL maintained in SQLMOD and converted on each build). Vx/SQLCC also auto-generates test harnesses for all procedures in a SQLMOD, supporting regression testing after migration. For more detail, see the VX/SQLMOD tool page.