RDB$PRE (VX/RDML) – Rdb RDML to embedded SQL on OpenVMS x86

RDB$PRE (VX/RDML) takes Rdb programs written with DEC Rdb's record-at-a-time statements in COBOL, BASIC, FORTRAN, Pascal and C, including COBOL written with the &RDB& statements of the RDBPRE preprocessor, and moves them to OpenVMS x86 without a rewrite. It works two ways. As the RDML precompile step in your build, it turns RDML straight into plain COBOL that calls the database runtime, with no other precompiler, so the RDML source you maintain today builds on x86. Or as a one-time converter, it rewrites the RDML into standard embedded SQL that SQL$PRE (VX/SQL$PRE) then compiles.

RDML expertise is now rare, while far more people know embedded SQL. RDB$PRE gets an application off RDML without leaving OpenVMS: the screens, the dictionary records and the program logic stay as they are, only the database statements change, and the result runs on x86 against PostgreSQL, Microsoft SQL Server, MySQL or MariaDB through the VX/SQL$PRE runtime. The converted programs can even be compiled and tested first on your existing Itanium system, against the live Rdb database.

Get off RDML without leaving Rdb, or OpenVMS

What stays	How
The database	A converted program can still attach to the same Rdb database. No data move and no schema change until you choose, and the original RDML image stays as the fallback.
OpenVMS	Screens, COPY records, dialogues and business logic do not move. Only the database statements are rewritten.
Your host variables	Your host variables keep their names. A GET fetches straight into them wherever it can, and other values travel through typed bridge variables, with indicator variables for NULLs.
Your dictionary records	CDD records are read through the same dictionary protocol the VSI compilers use, from VX/CDD or CDDSHR. Library-call output keeps each COPY as written; embedded-SQL output keeps it too, or brings the same record in with `EXEC SQL INCLUDE FROM DICTIONARY` when SQL reads into it.
Your skills	The result is ordinary embedded SQL, or ordinary COBOL CALLs: far more people know embedded SQL than RDML.

Five host languages, one RDML grammar

RDML uses the same verbs in every host language, and RDB$PRE reads them the same way: a front end per language finds the RDML in the host source and writes the host code around it, and a shared parser and SQL generator handle the RDML itself. The host language is picked from the file name, or named on the command line.

Host language	Source file types
COBOL, including `&RDB&` statements for RDBPRE	`.RCO`, `.COB`, `.CBL`, `.SCO`
BASIC (DEC BASIC, VAX BASIC)	`.RBA`, `.BAS`
FORTRAN	`.FOR`, `.F`, `.F77`, `.F90`
Pascal	`.RPA`, `.PAS`
C	`.RC`, `.C`, `.SC`

A stream becomes a cursor

The conversion is mechanical and readable. An RDML stream in the original source:

&RDB& START_STREAM CUST_STR USING
&RDB&     C IN CUSTOMERS WITH C.LAST_NAME = CIQ_IN_LAST_NAME
&RDB&     SORTED BY C.CUSTOMER_ID
&RDB&   FETCH CUST_STR
&RDB&       GET
&RDB&           CUSTOMER_ID   = C.CUSTOMER_ID;
&RDB&           CU_LAST_NAME  = C.LAST_NAME;
&RDB&           ...
&RDB&       END_GET
&RDB& END_STREAM CUST_STR

becomes standard embedded SQL:

EXEC SQL DECLARE RDML_S_CUST_STR CURSOR FOR
  SELECT COALESCE(C.CUSTOMER_ID, 0), ...
  FROM AVERTZ_DB.CUSTOMERS AS C
  WHERE (C.LAST_NAME = :RDML-I2-LAST_NAME)
  ORDER BY C.CUSTOMER_ID ASC
END-EXEC.
EXEC SQL OPEN RDML_S_CUST_STR END-EXEC
EXEC SQL FETCH RDML_S_CUST_STR INTO :CUSTOMER_ID, :CU_LAST_NAME,
  :CU_FIRST_NAME, :CU_CITY, :CU_PHONE_NO END-EXEC
EXEC SQL CLOSE RDML_S_CUST_STR END-EXEC

The FETCH reads straight into the program's own dictionary fields.

RDML statements and the SQL they become

RDML	Embedded SQL
`DATABASE pers = FILENAME 'PERSONNEL'`	`CONNECT TO 'PERSONNEL' AS pers` for PostgreSQL; `DECLARE ALIAS FILENAME 'PERSONNEL'` for Rdb
`START_TRANSACTION READ_WRITE`	`SET TRANSACTION READ WRITE`
`START_TRANSACTION ... RESERVING rel FOR EXCLUSIVE WRITE`	`SET TRANSACTION` plus the matching table lock
`FOR e IN EMPLOYEES WITH ... GET ... END_GET END_FOR`	A cursor: `DECLARE`, `OPEN`, `FETCH ... INTO` in a loop, `CLOSE`
`STORE c IN COLLEGES USING ... END_STORE`	`INSERT INTO COLLEGES ... VALUES ...`
`MODIFY e USING ... END_MODIFY`	`UPDATE ... WHERE CURRENT OF`
`ERASE e`	`DELETE ... WHERE CURRENT OF`
`CROSS`, `NOT ANY`, `STARTING WITH`, `MISSING`	`JOIN`, `NOT EXISTS`, `LIKE`, `IS NULL`
`RDB$DB_KEY`	The target database's row id
`COMMIT`, `ROLLBACK`, `FINISH`	`COMMIT`, `ROLLBACK`, `DISCONNECT`

RDB$PRE takes the table and column definitions from an RMU/EXTRACT of the database and from the dictionary. It never needs to read the live database.

Two paths to OpenVMS x86

Path A: convert once to embedded SQL, then SQL$PRE

RDB$PRE rewrites the RDML into ordinary embedded SQL. The result can be tested on your existing OpenVMS system: it compiles and runs there against the live Rdb database, before anything else changes. On x86, SQL$PRE precompiles the same .SCO, and the program reaches PostgreSQL through the SQL$PRE runtime. No Rdb is needed on x86.

CUSTINQ_T86.RCO          (original RDML)
    ->  VXRDML --mode=execsql --targetdb=rdb --schema=AVERTZ_DB=CUSTINQ_SCHEMA.SQL
    ->  CUSTINQ_RDML.SCO     (ordinary embedded SQL)
    ->  SQL$PRE /COBOL
    ->  COBOL compile, link VXSQL_PGSQL_RUNTIME_SHR
    ->  CUSTINQ_RDML.EXE

Path B: library calls, no precompiler at all

RDB$PRE rewrites the RDML directly into plain COBOL that calls the database runtime. The COBOL compiler is the only compiler in the build.

CUSTINQ_T86.RCO
    ->  VXRDML --mode=libcall --targetdb=postgres --schema=AVERTZ_DB=CUSTINQ_SCHEMA.SQL
    ->  CUSTINQ_LIBCALL.COB  (plain COBOL)
    ->  COBOL compile, link VXSQL_PGSQL_RUNTIME_SHR
    ->  CUSTINQ_LIBCALL.EXE

    CALL "S7RdbConnect" USING ...
    CALL "S7Exec" USING ...
    CALL "S7CursorFetchOne" USING ...
    CALL "S7Disconnect" USING ...

No EXEC SQL remains. The database is chosen only by which runtime is linked, so the same source reaches PostgreSQL, Microsoft SQL Server, MySQL or MariaDB with no change.

One program, three builds, on OpenVMS x86

Sector7's demonstration for VSI's OpenVMS Boot Camp builds a customer-inquiry program from the AVERTZ application three ways on OpenVMS x86, each reaching PostgreSQL through the VX/SQL$PRE runtime:

Program	Route
`CUSTSQL_T86`	Pure embedded SQL through SQL$PRE
`CUSTINQ_RDML`	RDML rewritten to embedded SQL by RDB$PRE, then SQL$PRE
`CUSTINQ_LIBCALL`	RDML rewritten to library calls by RDB$PRE: no precompiler

The first two use the precompiler. The third needs none: the COBOL compiler and a link against the VX/SQL$PRE PostgreSQL runtime are its whole build.

The same tool off OpenVMS

RDB$PRE also runs off OpenVMS, with the same options. In Sector7's testing its output there was byte-identical to the native OpenVMS x86 converter's, so conversion work can run wherever suits the project, including for applications that later move off OpenVMS.

VSI Boot Camp presentation

The Boot Camp session on moving RDML and Rdb SQL to PostgreSQL on OpenVMS x86: the two-step route, both paths, and the three example programs, in 13 slides.

Download the presentation (PDF, 13 slides)

On this page

Get off RDML without leaving Rdb, or OpenVMS

Five host languages, one RDML grammar

A stream becomes a cursor

RDML statements and the SQL they become

Two paths to OpenVMS x86

Path A: convert once to embedded SQL, then SQL$PRE

Path B: library calls, no precompiler at all

One program, three builds, on OpenVMS x86

The same tool off OpenVMS

VSI Boot Camp presentation

Related tools

Frequently Asked Questions

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

Free Code Assessment

Do I have to rewrite my RDML programs?

Not the programs. RDB$PRE rewrites only the RDML statements. Screens, dictionary records, host variable names and business logic stay as they are, and the conversion is mechanical and readable: a stream becomes a cursor, STORE becomes INSERT, MODIFY becomes UPDATE ... WHERE CURRENT OF. RDB$PRE prints its diagnostics with file name and line number, and with --strict any warning stops the build.

What are the two ways to use RDB$PRE?

As the precompile step in your build, in library-call mode: RDML goes in, plain COBOL that calls the database runtime comes out, and the COBOL compiler is the only compiler needed. Or as a one-time converter to standard embedded SQL, which SQL$PRE (VX/SQL$PRE) then precompiles on x86.

Which host languages are supported?

COBOL, BASIC, FORTRAN, Pascal and C, picked from the file extension or named on the command line.

Can I convert and test before moving to x86?

Yes. The embedded-SQL output compiles and runs on your existing OpenVMS system against the live Rdb database, so the converted programs can be tested there first, with the original RDML image as the fallback.

Which databases can the converted programs use on OpenVMS x86?

PostgreSQL, Microsoft SQL Server, MySQL and MariaDB. In library-call mode the database is chosen only by which runtime is linked, so the same source reaches each of them with no change; embedded-SQL output reaches them through SQL$PRE.

Does RDB$PRE need access to the Rdb database?

No. It takes the table and column definitions from an RMU/EXTRACT of the database and from the dictionary, through the same CDD protocol the VSI compilers use.

Transform Your Legacy Software Today!

Get In Touch

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