VX/CDD – Common Data Dictionary / Repository on OpenVMS x86

VX/CDD brings the OpenVMS Common Data Dictionary and CDD/Repository workflow to Linux. It preserves shared, language-independent field and record definitions so applications can continue to draw consistent declarations from one managed dictionary.

The product combines a compatible CDD$ callable interface, CDO, CDDL and DMU utilities, source ingestion, compiler-facing include expansion and multi-language extraction. Existing definitions and application integration points can be retained while the underlying repository moves to a modern, maintainable platform.

Architecture and components

VX/CDD provides a shared dictionary store with compatible management, extraction and application interfaces. Definitions enter through CDO, CDDL, SQL DDL or structured record sources, then become reusable fields and records that can be rendered for each target language.

OpenVMS capability	VX/CDD component	Purpose
CDD/Repository	VX/CDD dictionary	Stores repositories, directories, fields, records, members, variants and SQL definitions.
CDDSHR callable interface	`libvxcdd`	Provides the compatible `CDD$` session and element operations used by existing applications and tools.
Compiler dictionary expansion	`vxcddpp`	Expands dictionary references for supported source languages and can pass the expanded source to the selected compiler.
CDO, CDDL and DMU	Command utilities	Manage dictionary content, compile definitions, browse directories and extract records.
CDD extraction	`vxcdd` and extract APIs	Ingest definitions, list content and render reusable declarations for target languages.

Definition flow

Source definitionsCDO, CDDL, SQL DDL, or record sourcesManaged definitions enter through supported source formats.

Stored in

Shared storeVX/CDD dictionaryMaintains reusable fields, records, members, variants, and SQL definitions.

Branches to two consumer paths

Language extractionRenders native declarations for supported target languages.

Consumed byApplication builds

CDD$ session accessExposes compatible callable dictionary operations.

Consumed byExisting tools and code

One definition, many consumers. A field or record is maintained once and rendered in the native declaration form required by each supported language.

Dictionary model and source ingestion

The dictionary is organised as a hierarchy of repositories, directories and named definitions. Fully qualified names identify an element unambiguously when the same short name appears in more than one directory.

Dictionary object	Purpose
Repository	Top-level namespace for a dictionary.
Directory	Hierarchical grouping such as `CDD$TOP.BANKING.CUSTOMER`.
Field	One typed data element that can be reused across records.
Record	An ordered aggregate of members with a defined storage layout.
Member	A local, included, based-on, structured or variant element within a record.
Variant	An overlay of alternative record layouts selected by the application.
SQL source	Schema definitions retained for analysis and SQL dialect conversion.

Accepted source formats

Format	Typical use
CDO source	Define and manage fields, records and directories using the native CDD command language.
CDDL source	Compile CDD Data Definition Language files into the selected dictionary directory.
SQL DDL	Ingest domains, tables and columns for inventory and dialect conversion.
Structured record dumps	Load existing record definitions, including nested structures.

Directory ingestion follows dependency order so shared SQL domains and mapped CDDL sources are available before dependent CDO definitions are processed. Unsupported file types are reported rather than silently ignored.

Language extraction and compiler integration

VX/CDD renders one central definition into the declaration style expected by each target language. Applications can continue to use dictionary references in their source while the build process expands those references into native declarations.

Target	Rendering	Availability
CDD	Original CDO definition	Extraction and preprocessing
COBOL	Data definitions with levels and PIC clauses	Extraction and preprocessing
Fortran 90	Derived type declaration	Extraction and preprocessing
FORTRAN 77	DEC STRUCTURE and RECORD declarations	Extraction and preprocessing
C	`typedef struct` declaration	Extraction and preprocessing
C++	Compiler-facing dictionary include expansion	Preprocessing only
DECforms IFDL	FORM RECORD declaration	Extraction
VAX Pascal	TYPE and RECORD declaration	Extraction only
VAX BASIC	RECORD and END RECORD declaration	Extraction

Source-level dictionary references

The preprocessor recognises established dictionary include forms in COBOL, C, C++, Fortran and FORTRAN 77. It can write expanded source for review or invoke the configured compiler with the expanded source and original build options.

COBOL      COPY CUSTOMER-RECORD FROM DICTIONARY.
C          #pragma dictionary CDD$TOP.BANKING.CUSTOMER
Fortran    INCLUDE 'CDD$TOP.BANKING.CUSTOMER'

Existing source stays recognisable. Dictionary references remain part of the application source, while VX/CDD supplies the target platform declaration during the build.

CDO, CDDL and DMU utilities

VX/CDD includes familiar management tools for interactive use, scripted dictionary builds and operational access on Linux.

Utility	Role	Typical operations
`CDO`	Common Dictionary Operator	Define, inspect, copy, move, change, purge, verify and extract dictionary elements.
`CDDL`	CDD Data Definition Language compiler	Compile definition files into the active repository and directory.
`DMU`	Dictionary Management Utility	Create or delete dictionaries, list directories, set defaults and extract definitions.
`vxcdd`	Cross-platform dictionary tool	Ingest sources, inventory content, extract declarations and convert SQL schemas.

CDO command language

The CDO engine supports interactive commands and script files. Its top-level operations include DEFINE, SHOW, DELETE, SET, DIRECTORY, ENTER, COPY, CHANGE, MOVE, PURGE, EXTRACT and VERIFY.

DEFINE DIRECTORY BANKING.
SET DEFAULT BANKING

DEFINE FIELD CUSTOMER_ID
    DATATYPE IS UNSIGNED NUMERIC SIZE IS 10 DIGITS.

DEFINE FIELD CUSTOMER_NAME
    DATATYPE IS TEXT SIZE IS 40 CHARACTERS.

SQL schema conversion

Ingested SQL DDL can be analysed, retained and rendered for Oracle, PostgreSQL, SQLite, MySQL, MariaDB and SQL Server. This gives database migration teams a consistent inventory alongside application record definitions.

CDD$ callable interface

libvxcdd provides the CDD/Plus callable contract used by existing applications and utilities. The interface preserves the established routine names, packed OpenVMS descriptors, session lifecycle, metadata tags and condition values expected by compatible callers.

Session lifecycle

01CDD$ATTACHAcquire a user context.
02CDD$START_SESSIONBegin the dictionary session.
03CDD$SET_ANCHOR or CDD$SET_DEFAULTSelect the dictionary location.
04CDD$FETCH_START / CDD$FETCH_NEXTIterate matching dictionary content.
05CDD$GET_ELEMENTReturn the selected element metadata.
06CDD$END_SESSIONClose the dictionary session.
07CDD$DETACHRelease the user context.

Routine group	Purpose
`CDD$ATTACH`, `CDD$DETACH`	Acquire and release a user context.
`CDD$START_SESSION`, `CDD$END_SESSION`	Control dictionary sessions and transaction scope.
`CDD$SET_ANCHOR`, `CDD$TRANSLATE`	Select and resolve dictionary locations.
`CDD$DEFINE_ELEMENT`, `CDD$CHANGE_ELEMENT`	Create or update elements from compatible metadata buffers.
`CDD$FETCH_START`, `CDD$FETCH_NEXT`, `CDD$FETCH_END`	Iterate matching dictionary content.
`CDD$GET_ELEMENT`	Return an element as a CDDSHR-compatible metadata buffer.
`CDD$COPY_ELEMENTS`, `CDD$ERASE_ELEMENT`, `CDD$PURGE_ELEMENT`	Copy and manage element versions.
`CDD$VERIFY`, `CDD$VERSION`	Verify a dictionary and report interface version information.
`CDO$INTERPRET`	Execute a CDO command through the callable interface.

The documented callable surface contains 27 CDD$ routines and 2 CDO$ routines. Higher-level extraction entry points are also available for applications that need rendered text without manually traversing metadata buffers.

Compatibility is defined at the interface boundary. VX/CDD reproduces the byte layouts, tag ordering and condition handling consumed by established CDD clients.

Compatibility and validation

VX/CDD is designed around the OpenVMS CDD contract rather than a new, product-specific representation. Dictionary metadata, relationship tags, array bounds, variant structures, descriptors and status handling follow the established CDD model so existing consumers see familiar data.

Compatibility area	Coverage
CDD hierarchy	Repositories, directories, fields, records and qualified names
Record structures	Included fields, based-on members, arrays, nested structures and variants
CDD$ metadata	Compatible metadata buffers, entity tags, relationship tags and descriptors
Management tools	CDO, CDDL and DMU command workflows
Language extraction	CDD, COBOL, Fortran, C, FORTRAN 77, IFDL, Pascal and BASIC
C++ dictionary expansion	Available through the source preprocessor
Pascal dictionary expansion	Extraction is available; preprocessor expansion is not currently included

Validation approach

Representative dictionaries cover scalar datatypes, nested records, arrays and multi-arm variants. Extracted structures and callable-interface metadata are compared with OpenVMS CDD behaviour and compiler-produced declarations to verify both source meaning and storage layout.

No silent substitution. A compatibility mismatch is treated as an implementation issue to correct, not as a reason to change the calling application or redefine the OpenVMS contract.

Quick reference

Common command patterns

Task	Command pattern
Ingest a source directory	`vxcdd --cdd=cdd.db --adddir=./schema`
Extract one record as C	`vxcdd --cdd=cdd.db --extr=CUSTOMER_RECORD --lang=c`
List dictionary records	`vxcdd --cdd=cdd.db --list=records`
Expand and compile COBOL	`vxcddpp --cdd=cdd.db --compile customer.cob`
Run one CDO command	`CDO /EXECUTE="SHOW REPOSITORIES"`
Browse with DMU	`DMU DIRECTORY`

Supported SQL targets

Oracle

PostgreSQL

SQLite

MySQL

MariaDB

SQL Server

Dictionary location order

When no path is supplied, VX/CDD checks VX_CDD, then CDD_TOP, then the configured CDD setting, and finally ./cdd.db.

On this page

Architecture and components

Definition flow

Dictionary model and source ingestion

Accepted source formats

Language extraction and compiler integration

Source-level dictionary references

CDO, CDDL and DMU utilities

CDO command language

SQL schema conversion

CDD$ callable interface

Session lifecycle

Compatibility and validation

Validation approach

Quick reference

Common command patterns

Supported SQL targets

Dictionary location order

Frequently Asked Questions

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

Free Code Assessment

What is VX/CDD and how does it support OpenVMS modernization?

VX/CDD is Sector7's implementation of the OpenVMS Common Data Dictionary and CDD/Repository workflow for Linux. It stores shared, language-independent field and record definitions, then makes them available through familiar utilities, compatible callable interfaces, and language-specific extraction. This helps organisations modernise onto Linux while retaining established data definitions and application integration points.

Which programming languages does VX/CDD support?

VX/CDD can extract declarations for CDD, COBOL, Fortran 90, FORTRAN 77, C, DECforms IFDL, VAX Pascal, and VAX BASIC. It also supports compiler-facing dictionary expansion for C++. Pascal declarations are available through extraction, while Pascal dictionary expansion is not currently included.

Does VX/CDD include compatible APIs and management utilities?

Yes. VX/CDD provides a compatible CDD$ callable interface for applications and tools that access dictionary content programmatically. It also includes familiar CDO, CDDL, and DMU capabilities for defining, compiling, browsing, verifying, and extracting dictionary definitions on supported platforms.

Where can VX/CDD run?

VX/CDD is designed to provide the OpenVMS CDD/Repository workflow on Linux. Organisations can retain familiar dictionary concepts, application integration points, and build processes while moving supported workloads to a modern Linux environment.

How does VX/CDD support database modernization?

VX/CDD can ingest SQL DDL, retain schema definitions, and render ingested schemas for Oracle, PostgreSQL, SQLite, MySQL, MariaDB, and SQL Server. This gives database and application teams a consistent view of SQL definitions alongside shared record structures. VX/CDD does not convert SQLMOD application code; that capability is provided by SQL$MOD.

Which definition sources can VX/CDD bring into the dictionary?

VX/CDD can ingest CDO source, CDDL definitions, SQL DDL, and structured record dumps. These sources become reusable dictionary content that can be organised, inspected, and rendered for supported application languages. Dependency-aware directory ingestion also helps load shared definitions before records that depend on them.

Can VX/CDD preserve existing dictionary-based application workflows?

Yes. VX/CDD is designed to retain established CDD concepts such as repositories, directories, fields, records, qualified names, and language-specific declarations. Existing applications can continue to use familiar dictionary references and compatible interfaces, helping modernization teams preserve application structure instead of replacing the dictionary model.

What business benefits does VX/CDD provide during modernization?

VX/CDD keeps shared field and record definitions in one managed dictionary, helping teams avoid separate, inconsistent declarations across applications and languages. By preserving familiar dictionary workflows while supporting deployment on Linux, it can reduce migration risk, simplify ongoing maintenance, and let application and platform changes proceed in controlled stages.

Transform Your Legacy Software Today!

Get In Touch

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