Rdb to Oracle & PostgreSQL: Seamless Database Migration

PostgreSQL (the reference, most tested driver), MySQL/MariaDB, Microsoft SQL Server (via ODBC), any ODBC data source, Oracle (via the OCI client) and SQLite. The database is chosen at run time by configuration, so the same generated modules move between back ends without rebuilding.

On Linux, SQL$MOD can emit a module either as direct C, or as embedded SQL for the PostgreSQL ECPG toolchain. Both come from the same .SQLMOD source, and the calling programs see the same procedures either way.

The generated modules keep the SQLMOD procedure-call interface, so your Fortran, COBOL, C or C++ programs call the same procedures. For Fortran callers the toolset also generates an updated Fortran source file (Module.F) that calls the converted procedures, so that file is rebuilt.

A RECORD ... END RECORD parameter, optionally sourced from a CDD dictionary path, becomes a C struct and is bound field by field, so SELECT ... INTO :record populates every column. Domains resolve through CDD to C typedefs, and VMS CDD data-type definitions can be extracted into C headers.

VMS quadword date and time parameters are converted to and from SQL TIMESTAMP automatically. Dates are stored as normal timestamps in the target database, so other tools can read them, while your application keeps sending and receiving VMS quadwords with no application change.

Yes. SQL$MOD provides an Rdb-compatible SQLCA and maps Rdb SQLCODE and SQLSTATE, so procedures that inspect sqlca.sqlcode behave as they did under Rdb.

Oracle Rdb reaches end of life on Itanium in December 2027 and Oracle is not porting it to x86. SQL$MOD gives SQLMOD-based applications a supported path onto modern platforms and open back ends, while preserving the procedure interface so the application itself is largely unchanged.

The vxsql preprocessor rewrites each EXEC SQL block into ordinary COBOL CALL "S7..." statements and writes a binary .cbsql.map sidecar that captures host-variable types and null indicators. The result is still COBOL: it is compiled by your native COBOL compiler and linked against the VX/SQL$PRE runtime. It is not converted into C or C++.

PostgreSQL is the reference and most tested driver, alongside MySQL/MariaDB, Microsoft SQL Server (via ODBC or FreeTDS), Oracle (via the OCI client), SQLite, and any ODBC data source. Each build links one runtime library, so within a driver family a program repoints by changing its connection string. Moving to a different database engine means relinking against that engine's runtime library.

Both the PostgreSQL ECPG preprocessor and Oracle's Pro*C process embedded SQL in C and C++ only. Neither handles embedded SQL in COBOL. That is the gap SQL$PRE – COBOL fills: it is the COBOL-aware embedded-SQL preprocessor those tools do not provide.

No. Existing EXEC SQL blocks, CDD includes, and SQLCODE branches keep working. SQL$PRE – COBOL is a drop-in replacement for Rdb's SQL$PRE, so the migration does not require a hand rewrite of the COBOL source.

It provides a 136-byte Rdb-compatible SQLCA carrying Rdb SQLCODE and SQLSTATE values: 0 for success, 100 for no data, and Rdb negatives such as -803, -811, and -913. Code that branches on SQLCODE behaves as it did under Rdb. For example, a PostgreSQL duplicate key (SQLSTATE 23505) is reported to COBOL as Rdb SQLCODE -803.

PACKED DECIMAL and COMP-3 are converted to ANSI NUMERIC, and VMS QUADWORD date/time to SQL TIMESTAMP, transparently on input and output. There is no conversion code to add in the COBOL.

They are expanded into native COBOL record declarations through the genuine CDD$ compiler-protocol interface, using Sector7's portable dictionary library on any platform or VSI CDD/Repository on OpenVMS, with the same code path either way. Because CDD is not being ported to x86 OpenVMS, VSI's VDD is a drop-in replacement in the same workflow.

OpenVMS x86-64 (V9.2) with native VSI COBOL, Linux with Fujitsu NetCOBOL or GnuCOBOL, and macOS for development and CI. On every platform the vxsql preprocessor and the runtime are the same, so one code base covers all three.

SQL$PRE - FORTRAN is a single-pass embedded-SQL preprocessor for FORTRAN. It reads your source, rewrites each EXEC SQL ... END-EXEC block into ordinary FORTRAN calls to the portable libvxsql runtime, and emits one preprocessed FORTRAN source file.

The original SQL is preserved as !S7 comments in the output, so you still have a readable audit trail. It is a drop-in replacement for Oracle Rdb's SQL$PRE precompiler.

Oracle Rdb and its SQL$PRE precompiler are tied to a platform and database that many estates are moving away from. SQL$PRE - FORTRAN keeps your embedded SQL in FORTRAN while opening a path to modern platforms and open or commercial back ends.

You replace SQL$PRE with SQL$PRE – FORTRAN in the build, link against libvxsql-fortran, and run the same application logic against PostgreSQL, Oracle, SQL Server, MySQL/MariaDB, SQLite, or ODBC.

No. SQL$PRE - FORTRAN is designed so your FORTRAN source structure and application logic stay intact. You keep EXEC SQL blocks, host variables, and the same program flow.

The preprocessor emits ordinary FORTRAN that compiles with gfortran or ifx. There is no application rewrite and no intermediate language files to maintain.

The same preprocessed FORTRAN source can target PostgreSQL (the reference target), Oracle, SQL Server, MySQL/MariaDB, SQLite, or ODBC. You choose exactly one database driver at link time.

That means one codebase can be built for different back ends without rewriting embedded SQL, which simplifies testing and phased migration.

SQL$PRE - FORTRAN is available on x86 OpenVMS, x86 and ARM Linux, and macOS. The preprocessor and libvxsql runtime are built for these targets so Rdb-era FORTRAN can move with your platform strategy.

Build and link steps follow normal FORTRAN toolchain conventions on each platform, with libvxsql-fortran and your chosen database driver added at link time.

Replace the Rdb SQL$PRE step with the SQL$PRE – FORTRAN preprocessor. It takes your FORTRAN source with embedded SQL and produces a single preprocessed .f (or equivalent) file ready for your FORTRAN compiler.

Compile that output with gfortran or ifx, then link against libvxsql-fortran plus one database driver selected at link time. No separate header or include pipeline is required beyond your normal FORTRAN build.

Yes. Host variables, cursors, dynamic SQL (methods 1 through 4), NULL indicators, WHENEVER directives, and SQLCA-based error handling all carry through the preprocessor into calls to libvxsql.

Your existing Rdb-style embedded SQL patterns continue to work after migration, so operational code around fetches, prepares, and error branches does not need to be redesigned.

SQL$PRE - FORTRAN is part of the VX/SQL$PRE toolset alongside SQL$PRE – COBOL and SQL$MOD. All three share the same libvxsql runtime and the same set of link-time database drivers.

Mixed-language Rdb estates with FORTRAN, COBOL, and SQLMOD modules can migrate onto one database access layer, which reduces duplication and keeps SQL behavior consistent across languages.

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.

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.

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.

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 SQL$PRE – COBOL for embedded SQL in COBOL.

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.

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.