SQL$MOD (VX/SQL$MOD) – Rdb SQL module language on OpenVMS x86

SQL$MOD (VX/SQL$MOD) compiles Oracle Rdb SQL module language on OpenVMS x86. Your .SQLMOD modules keep their procedures, their parameter lists and their calling sequence, so the COBOL, FORTRAN, Pascal or C programs that call them do not change. Each module becomes a C module built with VSI C and linked with the same runtime as SQL$PRE (VX/SQL$PRE), and the database underneath becomes PostgreSQL, Microsoft SQL Server, MySQL, MariaDB or SQLite, with Oracle reached through SQL Relay.

Oracle is not porting Rdb to OpenVMS x86. SQL module language is where many Rdb applications keep all of their SQL, so the module is the contract between the application and the database, and SQL$MOD keeps that contract: the same procedures, parameters and order. Sector7's SQLMOD toolset converted IKEA's 600 Rdb SQLMOD files to PostgreSQL, and 422 of those modules, with their converted output, form the regression corpus SQL$MOD is checked against. SQL$MOD runs on Linux as well as on OpenVMS x86.

Your modules, unchanged

In SQL module language the SQL lives in a separate module: each database operation is a named PROCEDURE with a typed parameter list, and the host program calls it as an ordinary external routine. SQL$MOD reads the module in Rdb's own SQL module language syntax:

MODULE ACCT_INQUIRY_MOD
DIALECT SQL92
LANGUAGE PASCAL
AUTHORIZATION BANK_USER
ALIAS RDB$DBHANDLE
PARAMETER COLONS

DECLARE ALIAS FOR FILENAME banking_accounts

PROCEDURE INSERT_ACCOUNT
    (SQLCODE,
     :P_ACCOUNT_ID  CHAR(5),
     :P_LAST_NAME   CHAR(14),
     :P_FIRST_NAME  CHAR(10),
     :P_BALANCE     INTEGER);
    INSERT INTO ACCOUNTS (ACCOUNT_ID, LAST_NAME, FIRST_NAME, BALANCE)
    VALUES (:P_ACCOUNT_ID, :P_LAST_NAME, :P_FIRST_NAME, :P_BALANCE);

The module header is read as Rdb writes it: DIALECT (SQLV40, SQL89, SQL92, MIA), LANGUAGE, AUTHORIZATION, ALIAS, PARAMETER COLONS and DECLARE ALIAS FOR FILENAME.
The reserved status parameters keep their place in the parameter list: SQLCODE, SQLSTATE, SQLCA, SQLDA and SQLDA2.
The procedure names and the parameter order stay the same, so callers link to the new module with no change to their CALL statements.

On OpenVMS x86

SQL$MOD runs natively on OpenVMS x86. Each .SQLMOD file becomes a C header and a C module that runs on the SQL$PRE runtime, compiled in one step with VSI C: no Pro*C and no second precompiler. The module links with the same runtime as your embedded-SQL programs, so an application that mixes SQL module language and embedded SQL moves as one.

What a procedure becomes

int INSERT_ACCOUNT(
    int  *_sqlcode,
    char *_P_ACCOUNT_ID, char *_P_LAST_NAME,
    char *_P_FIRST_NAME, int *_P_BALANCE)
{
    /* INSERT INTO ACCOUNTS (...) VALUES ($1, $2, $3, $4) */
    ...
}

The SQLCODE status becomes an output parameter, and each host variable a reference parameter, just as the calling programs already pass them.
Rdb :name placeholders become positional parameters, bound by type, size and indicator.
The generated C is readable and kept for audit, and the SQL$MOD test suite builds each module in both output flavours and checks the values it returns against a live database, so the two builds cross-check each other.

What the procedures can contain

Rdb SQL module language	Handled
Single-statement procedures: `SELECT ... INTO`, `INSERT`, `UPDATE`, `DELETE`	yes
Multi-statement procedures and compound `BEGIN [ATOMIC] ... END` blocks, `FOR ... DO` loops	yes
Static cursors: `DECLARE`, `OPEN [USING]`, `FETCH ... INTO`, `CLOSE`, `WHERE CURRENT OF`	yes
`SET TRANSACTION`, `COMMIT` and `ROLLBACK`	yes
Dynamic SQL: `PREPARE`, `DESCRIBE`, `OPEN` / `FETCH ... USING DESCRIPTOR`	yes
Indicator variables, including `INDICATOR ARRAY OF n`	yes
`RECORD ... END RECORD` parameters, from the dictionary or inline	yes

Dictionary records and OpenVMS data types

Record parameters can come straight from the dictionary. A RECORD parameter becomes a C structure with the canonical record layout, bound field by field, so SELECT ... INTO :record fills every column. Domain-typed parameters resolve through VX/CDD to real C types.

Dates can stay quadwords. A module passes the OpenVMS quadword as a BIGINT through Sector7's S7_CONVERT_INT64_TO_DATE and S7_CONVERT_DATE_TO_INT64 functions, and it round-trips through a SQL TIMESTAMP column. The database stores normal timestamps that every other tool can read.

Rdb status handling preserved

SQL$MOD maps database errors to the Rdb SQLCODE values, so a caller that tests the SQLCODE status parameter or the procedure's return value behaves as it did under Rdb: 100 for no data, -803 for a duplicate key, -913 for a deadlock.

Proven at scale

IKEA's store systems kept their SQL in Rdb SQL module language. Sector7 converted IKEA's 600 SQLMOD files to PostgreSQL, and 422 of those modules, with their converted output, are now the regression corpus SQL$MOD is checked against.

Performance

SQL$MOD modules run on the same runtime as SQL$PRE, including native server-side cursors on PostgreSQL. In the embedded-SQL benchmark of that runtime on OpenVMS x86, the median complete 57,344-query cycle took 9.9 seconds against PostgreSQL, where native Oracle Rdb on Itanium took 373 seconds. The workloads and the charts are on the SQL$PRE page.

The same tool on Linux

SQL$MOD also runs natively on Linux, where the module can be emitted either as direct C or as embedded SQL for the PostgreSQL ECPG toolchain, from the same .SQLMOD source. The calling programs see the same procedures either way.

On this page

Your modules, unchanged

On OpenVMS x86

What a procedure becomes

What the procedures can contain

Dictionary records and OpenVMS data types

Rdb status handling preserved

Proven at scale

Performance

The same tool on Linux

Related tools

Frequently Asked Questions

Curious about how Sector7 can facilitate your application migration? Explore our FAQs for expert insights.

Free Code Assessment

Do the programs that call my SQL modules change?

No. SQL$MOD keeps each procedure's name, parameter list and parameter order, including the reserved SQLCODE, SQLSTATE and SQLCA status parameters, so the programs that call the module keep their CALL statements as they are.

Does SQL$MOD run on OpenVMS x86?

Yes, natively. Each .SQLMOD file becomes a C module compiled with VSI C and linked with the same runtime as SQL$PRE (VX/SQL$PRE). No Pro*C and no second precompiler is needed.

What can my procedures contain?

Single and multi-statement procedures, compound BEGIN ... END blocks and FOR loops, static cursors including WHERE CURRENT OF, transaction control, dynamic SQL with descriptors, indicator variables and indicator arrays, and record parameters.

How are dictionary records and domains handled?

RECORD parameters become C structures with the canonical record layout and are bound field by field. Domain-typed parameters resolve through VX/CDD to real C types.

What happens to OpenVMS quadword dates?

The application can keep its OpenVMS quadword dates. Passed as BIGINT through Sector7's S7_CONVERT_INT64_TO_DATE and S7_CONVERT_DATE_TO_INT64 functions, they round-trip through SQL TIMESTAMP columns, so the database holds standard timestamps that any other tool can read.

Has it been used on a real application?

Yes. Sector7's SQLMOD toolset converted IKEA's 600 Rdb SQLMOD files to PostgreSQL, and SQL$MOD is regression-tested against 422 of those modules and their converted output. The case study is on this site.

Related Boot Camp talks

Transform Your Legacy Software Today!

Get In Touch

Unlock the potential of your legacy software with our expert migration services.