🚨 Oracle not porting Rdb to x86 and EOL on Itanium 12/2027 🚨
Technical Capabilities
Having trouble finding what you need?
Get in touch with us, so we can answer your specific questions directly.
Get In Touch

VX/SQL-COBOL - COBOL with embedded Rdb/SQL to PostgreSQL or Oracle

Description:

VX/SQL-COBOL (part of Sector7's Vx/SQLCC toolset) is a post-processor for COBOL applications containing embedded Oracle Rdb SQL. It enables legacy COBOL applications to run against PostgreSQL or Oracle on x86 OpenVMS, Itanium, and Linux — without rewriting the COBOL source code.

Vx/SQLCC supports two operational modes: in situ execution, where embedded SQL runs within COBOL as a single compile step, and one-time SQL extraction, where SQL is separated into external C/C++ modules for long-term maintainability. Both modes include automatic conversion of OpenVMS-specific data types including PACKED DECIMAL and QUADWORD datetime.

The Problem — Why COBOL Embedded SQL Is Stuck

Oracle Rdb End of Life on OpenVMS

Oracle has announced that Oracle Rdb will not be ported to x86 OpenVMS, with end-of-life scheduled for December 2027 across all platforms. The classic Oracle client — which provided embedded SQL support for COBOL — will also not be ported to x86 OpenVMS. This leaves PostgreSQL as the only global enterprise database client available on both x86 OpenVMS and Itanium OpenVMS.

PostgreSQL Only Handles SQL in C and C++

The PostgreSQL ECPG preprocessor processes embedded SQL in C and C++ only. It cannot handle embedded SQL in COBOL or FORTRAN. For any COBOL application with embedded Rdb SQL, there is currently no standard migration path to PostgreSQL without manual rewriting of the entire application.

• Organisations with millions of lines of COBOL containing embedded Rdb SQL have no supported database path on x86 OpenVMS without the Sector7 converter.

There is no COBOL preprocessor available for ECPG. Vx/SQLCC is the only production-ready solution.

Unsupported Legacy Data Types

PostgreSQL does not natively support the data types used extensively in OpenVMS COBOL applications:

PACKED DECIMAL — used for compact numeric storage in COBOL

QUADWORD datetime — the OpenVMS/Rdb date and time format

The classic Oracle client also does not support these formats, which means both migration paths — to Oracle and to PostgreSQL — require data type conversion. Vx/SQLCC handles this automatically.

Rdb Record-Oriented Access

Oracle Rdb applications frequently rely on record-based cursor access patterns that are not directly compatible with PostgreSQL's relational model. Without specialist handling, migration causes significant performance degradation. Vx/SQLCC includes proprietary technology specifically designed to preserve performance.

How Vx/SQLCC Works for COBOL

Two Operational Modes

In situ (single compile step)
Embedded SQL remains within the COBOL source. Vx/SQLCC processes the source as part of the compile step, running the SQL against PostgreSQL with minimal disruption to application structure. The fastest migration path.

One-time SQL extraction
Embedded SQL is extracted from COBOL into external C/C++ modules. All host variable bindings are generated automatically, including full data type conversion logic. Future SQL changes are maintained in the external C/C++ module — separating database access from COBOL logic for long-term maintainability.

Automatic Data Type Conversion

Both modes include transparent handling of OpenVMS legacy data types:

PACKED DECIMAL → ANSI NUMERIC on input; ANSI NUMERIC → PACKED DECIMAL on output

QUADWORD datetime → SQL datetime on input; SQL datetime → QUADWORD on output

These conversions are fully automated — no manual intervention required in the COBOL source.

Host Variable Bindings and Return Codes

Host variable bindings are preserved across the COBOL/C boundary. Parameter passing linkage is generated automatically.

Return codes are automatically converted to Rdb-compatible equivalents, ensuring existing COBOL error-handling logic continues to function.

Rdb Cursor Fetch Optimisation

Vx/SQLCC incorporates Sector7's proprietary technology for accelerating legacy Rdb cursor fetch loops when running against PostgreSQL. Applications relying on record-based access patterns achieve equal or better performance compared to native Rdb — without changes to the COBOL source.

File Generation — One-Time Extraction Mode

Output Files

For the one-time extraction mode, Vx/SQLCC reads the COBOL source containing embedded SQL and generates the following files:

Input File Vx/SQLCC Output Files Description
Filename.COB
(COBOL with embedded SQL)
Filename.h C header containing all generated procedure declarations for extracted SQL calls.
Filename.pc / Filename.pgc SQL module with extracted SQL calls and full host variable bindings. (.pc for Oracle Pro*C; .pgc for PostgreSQL ECPG)
Filename.CPY COBOL copybook with procedure definitions for calling the extracted SQL module from COBOL.
Filename.COB (updated) COBOL source with embedded SQL replaced by calls to the generated procedures. Original program structure preserved.

Compilation and Linking Process

1. Updated .COB and .CPY are compiled by the COBOL compiler, generating an object file (.o).

2. The .pc / .pgc SQL module is processed by the Oracle Pro*C precompiler or ECPG preprocessor, generating a C source file (.c).

3. The C file is compiled using GNU C, generating a second object file (.o).

4. Both object files are linked to create the final executable, which interacts with Oracle or PostgreSQL directly.

Platform Support

OpenVMS x86 — PostgreSQL

Full Vx/SQLCC support on x86 OpenVMS. Both in situ and one-time extraction modes are available. PostgreSQL is the only available enterprise database client; Vx/SQLCC bridges the COBOL embedded SQL gap that no other tool addresses.

OpenVMS Itanium — Oracle Client

On Itanium OpenVMS, the Oracle client 11g (connecting to Oracle 19c) remains available. Vx/SQLCC supports this path, including all data type conversion and cursor fetch optimisation capabilities.

Linux — PostgreSQL or Oracle

Vx/SQLCC is not limited to OpenVMS. On Linux it enables legacy COBOL applications to run with PostgreSQL using Fujitsu NetCOBOL or OpenCOBOL / GnuCOBOL — environments where no COBOL ECPG preprocessor exists. For Oracle on Linux, Vx/SQLCC can generate C/C++ modules as an alternative to the Oracle COBOL preprocessor.

SQLMOD and CDD Conversion

Vx/SQLCC also processes Oracle Rdb SQLMOD files:

• Converts Rdb SQLMOD procedures to C/C++ with proprietary record-access optimisation

• Supports single-use mode (SQL maintained in C/C++) and multiple-use mode (SQL maintained in SQLMOD)

• Auto-generates test harnesses for all procedures in a SQLMOD

CDD conversion: Converts CDD to COBOL copybooks and C include files with automatic schema conversion — QUADWORD → TIMESTAMP and PACKED DECIMAL → NUMERIC. Note: CDD will not be ported to x86 OpenVMS; VSI provides VDD as a drop-in replacement, which integrates with the Vx/SQLCC workflow.

Key Benefits of Vx/SQLCC for COBOL

1. No COBOL Rewrite Required

• Existing COBOL applications run against PostgreSQL or Oracle without source rewriting.

• Choice of in situ (minimal disruption) or extraction (long-term maintainability) — both preserve original application logic.

2. Automatic Data Type Conversion

• PACKED DECIMAL and QUADWORD datetime handled transparently on both input and output.

• No manual conversion code required in COBOL or C.

3. Performance Preserved

• Sector7's proprietary cursor fetch optimisation ensures legacy record-based access patterns perform as well or better under PostgreSQL as under native Rdb.

4. Dual Database Target

• Oracle Pro*C output (.pc) for organisations on Oracle on Linux or OpenVMS Itanium.

• PostgreSQL ECPG output (.pgc) for organisations migrating to open-source PostgreSQL.

5. Cross-Platform

• Runs on x86 OpenVMS, Itanium OpenVMS, and Linux.

• Linux support covers Fujitsu NetCOBOL and OpenCOBOL/GnuCOBOL environments.

Conclusion

With Oracle Rdb reaching end-of-life and the classic Oracle client not being ported to x86 OpenVMS, organisations running COBOL applications with embedded SQL face a hard deadline with no standard migration path. Vx/SQLCC is the solution — automating SQL conversion, handling data type translation, preserving performance, and working across OpenVMS x86, Itanium, and Linux.

For organisations planning an Oracle Rdb migration or moving to OpenVMS x86, Vx/SQLCC provides the missing link between legacy COBOL applications and modern PostgreSQL or Oracle infrastructure. Talk to Sector7 to discuss your migration requirements.

Frequently Asked Questions

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

Does VX/SQL-COBOL require rewriting existing COBOL applications?

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.

What is the difference between in situ mode and one-time SQL extraction in Vx/SQLCC?

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.

Why can't I use PostgreSQL ECPG directly with my COBOL embedded SQL?

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.

How does Vx/SQLCC handle PACKED DECIMAL and QUADWORD datetime?

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.

Which COBOL compilers does Vx/SQLCC support on Linux?

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.

Does Vx/SQLCC work on OpenVMS x86, Itanium, and Linux?

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.

What happens to the COBOL source code after Vx/SQLCC processes it?

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.

Can Vx/SQLCC also convert Oracle Rdb SQLMOD files, not just embedded SQL?

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.

Transform Your Legacy Software Today!

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