Modernize Your Legacy Code: COBOL, FORTRAN, PASCAL, BASIC, C

VX/COBOL translates OpenVMS COBOL to ANSI COBOL automatically, with no manual code changes. What is more important is that there are no fixes required, post-translation.

The translation is done on Linux at compile time and is automatic. The time depends on the size and complexity of the application, so we give you an estimate for your own code as part of the assessment process.

Immediately after the translation is performed, the translated code is compiled on Linux using Fujitsu NetCOBOL or Micro Focus COBOL. These Linux-based compilers are really fast. Testing then follows a test plan agreed with you: see the value of testing in a migration project.

VX/COBOL is a comprehensive solution designed to migrate OpenVMS COBOL applications to modern, flexible Linux-based systems. It is a source-to-source translator: it reads VMS and OpenVMS COBOL and emits standard ANSI COBOL, which Fujitsu NetCOBOL or Micro Focus COBOL then builds on x86 Linux. Your valuable, time-tested business logic is retained without rewriting code from scratch, and the original program logic and structure are preserved.

To discover how we can help you, please contact us.

No. VX/COBOL is a source-to-source translator that does the conversion automatically, so teams do not rewrite their COBOL by hand. It reads OpenVMS COBOL and emits standard ANSI COBOL that Fujitsu NetCOBOL or Micro Focus then compiles on Linux.

VX/COBOL emits standard COBOL, so the translated application is built, debugged and profiled with the ordinary Fujitsu NetCOBOL or Micro Focus COBOL toolchains on Linux. Testing is how we confirm functional equivalence: we validate the OpenVMS baseline, then run the same test plan against the migrated application before it goes live.

To learn more about our testing methodologies, read the value of testing in a migration project or contact us.

No. Embedded Rdb SQL in COBOL is handled by SQL$PRE – COBOL, our replacement for the Rdb embedded-SQL precompiler. The COBOL does not change; underneath, the database becomes PostgreSQL (or another supported database), with Oracle reached through SQL Relay. At the end of the transformation, the COBOL application on Linux accesses PostgreSQL/Oracle instead of Rdb.

VX/PASCAL is an automated transpiler that converts OpenVMS Pascal to ANSI-compliant C++ for execution on Linux. It carries VMS-specific extensions, CDD data structures, and RMS file handling across to Linux, so the translated program behaves the same as it did on OpenVMS. To explore VX/PASCAL for your migration, contact us.

VX/PASCAL automates migration in four steps: source code analysis, transpile to C++, compile with GNU C++, and validate with automated testing to ensure identical behavior.

VX/PASCAL is driven by a setup table read from a customer setup file, so output can be tuned to house conventions without editing source. Variable naming, code formatting (braces, indentation and line breaks), VMS logical-name translation, POSIX error-code mapping and inherited system-file handling are all controllable, and runtime checks (case, array bounds, nil pointers, allocation and file state) can be enabled together for a validation build.

VX/PASCAL translates OpenVMS and VAX Pascal to ANSI C++ automatically, with zero code freeze: teams keep developing in Pascal while each release is migrated. Any construct the translator cannot fully represent is named with a numbered diagnostic rather than dropped. Contact us to discuss your requirements.

VX/FORTRAN is an automated migration tool that translates OpenVMS FORTRAN to ANSI-compliant FORTRAN (Intel Fortran) for execution on Linux. It extends Fortran Partner (FPT) with VMS-specific features, standards adherence, and performance optimizations.

It is designed for scientific and engineering FORTRAN estates, so decades of software investment move forward intact. To learn more about how VX/FORTRAN can modernize your legacy systems, contact our migration experts.

The migration follows four automated steps: source code analysis to identify VMS-specific extensions and dependencies, transpilation to ANSI-standard Fortran, compilation with Intel Fortran optimization, and validation through automated testing to verify identical execution behavior.

Yes, VX/FORTRAN supports zero code freeze, allowing you to continue development on VMS while migrating to Linux. This parallel approach ensures business continuity throughout the modernization process.

Organizations like Amprion GmbH have successfully used this approach for large-scale FORTRAN migrations involving millions of lines of code.

VX/FORTRAN performs advanced optimizations including loop unrolling, inline expansion, and memory access optimizations.

VX/FORTRAN automatically converts Pro*Fortran SQL statements to external C functions, ensuring seamless database integration on the target Linux platform without manual intervention.

Before any rewrite, VX/FORTRAN's source code analysis identifies VMS-specific extensions and RMS file dependencies and reports missing sub-programs and mismatched arguments. After translation, the Intel FORTRAN compiler builds the emitted source and automated test cases confirm identical execution behaviour. For detailed information about our testing methodologies and quality assurance processes, read about testing in a migration project or contact our team.

VX/C is Sector7's automated tool that converts VMS/OpenVMS C source code into portable, POSIX-compliant ANSI C. It identifies, flags, and corrects VMS-specific issues to ensure your code runs seamlessly on Linux environments.

The tool provides fully automated source code conversion, works with existing Makefiles and build systems, and handles VMS-specific syntax and dependencies. For organizations looking to modernize their legacy systems, contact us to discuss your migration requirements.

VX/C identifies and resolves 14 categories of VMS-specific issues including addressing constants, variant struct/union usage, missing function arguments, VMS-specific compiler calls, and POSIX type incompatibilities.

VX/C automatically handles VMS-specific include file references, logical name includes, and case sensitivity issues in include paths, ensuring proper POSIX compliance in the migrated code.

VX/C functions like a C compiler, parsing source files and generating formatted reports, fix scripts, and POSIX-compliant source code through a simple command-line interface.

Yes, VX/C automatically corrects missing function arguments, undefined return types, and inconsistent function naming cases. It converts VMS-specific function calls to their POSIX-compliant equivalents and fixes typecasting issues on assignment operations.

VX/C is an automated source-to-source translator that reduces manual effort and gives consistent code output across large codebases. Every machine-applied edit is annotated inline with a /*S7-nnn*/ comment, so each change stays traceable and reviewable, and it works with existing Makefiles and build systems and fits continuous-integration workflows.

The result is portable, POSIX-compliant ANSI C that compiles cleanly off OpenVMS on Linux and macOS. To learn more about how VX/C can accelerate your migration project, contact our migration experts.

VX/BASIC is a full-featured OpenVMS BASIC to ANSI C transpiler that enables legacy BASIC applications to run natively on Linux. It converts VMS BASIC syntax to working C code (the graphics command family is the one documented exclusion) while maintaining the original structure, variable names, and comments for easy maintenance.

For organizations ready to modernize their legacy systems, contact us to discuss your specific migration requirements.

VX/BASIC programs that call OpenVMS system routines are backed by the VX/RT runtime libraries, which replicate over 900 OpenVMS system service and run-time calls, including RMS file handling and other system services.

VX/BASIC maintains the original BASIC source code structure while generating readable ANSI C code, allowing developers to continue working with familiar BASIC syntax. The transpiled C code retains the original program flow and variable names, making debugging and maintenance much easier than completely rewritten applications.

VX/BASIC converts VMS BASIC to ANSI C that keeps VAX BASIC semantics, with the graphics command family the one documented exclusion. Organizations retain their valuable software investments while moving to modern, portable infrastructure.

The generated ANSI C is built with the host's own toolchain, so it can be maintained, built and debugged with standard modern tools.

Ready to explore migration options for your BASIC applications? Contact us to discuss your specific requirements.

VX/C takes OpenVMS/VAX-C and DEC C source and produces portable, POSIX-compliant ANSI C. It identifies, flags, and corrects VMS-specific issues so the generated code targets Linux and other POSIX/UNIX platforms such as macOS.

VX/C works like a C compiler. You run the vxcpp command with a list of switches (for example --include=, --vms-api=lower, --output=) and one or more C source files. It also reads mapping files (--hmapfile=, --vararg_file=) so common option sets and header remaps do not have to be retyped on every run.

VX/C covers 14 feature-coded categories, including addressing constants and strings, variant struct and union usage, union-to-union assignment, several #include problems (text-library includes, logical-name references, case sensitivity), missing function arguments, type mismatches, inconsistent function-naming cases, VMS-specific compiler calls such as vax$errno, incompatible POSIX type usage, undefined return types, and left-hand-side typecasting.

Both. It rewrites the source into POSIX-compliant ANSI C and marks every edit inline with a traceable /*S7-nnn*/ annotation (for example /*S7-041*/ where it padded a system-service call's arguments), and it writes diagnostics for anything it cannot handle to standard error.

Every transformation is tagged in the output with a /*S7-nnn*/ comment that identifies the rule applied, so a reviewer can diff the migrated source against the original and see exactly what the tool did and why. The annotations can be suppressed with --no-s7-tags when they are no longer needed.

It addresses #include directives that pull from a text library without delimiters, #include references via VMS logical names, and case-sensitivity differences in #include paths. It also remaps VMS header names to their POSIX equivalents (for example stat.h to sys/stat.h, in.h to netinet/in.h) using a built-in table plus any user-supplied maps.

Yes. It works with existing Makefiles and build systems and supports continuous-integration workflows. It is typically driven by a batch script that runs vxcpp over a source tree, using --copy= for directory-tree mode, and then compiles the transformed output.

VX/C produces code for Linux and other POSIX/UNIX platforms such as macOS. It ships target personalities that load the correct predefined macros for each host (GCC on Linux, Apple LLVM/clang on macOS). There is no Windows target.

It translates VMS and OpenVMS BASIC into ANSI C source and then compiles that C. C is used as an intermediate language, which is what gives the output long-term portability and lets it build, run, and be debugged directly on modern systems with standard tools.

VX/BASIC converts OpenVMS BASIC into C that compiles and runs on Linux and Windows, while still allowing the application to be maintained in its original OpenVMS BASIC form and re-translated on each release.

All VMS and OpenVMS BASIC data types are supported. Integer types map to fixed-width C types (BYTE to int8_t, WORD to int16_t, LONG to int32_t, QUAD to int64_t), SINGLE and DOUBLE map to float and double, DECIMAL maps to a packed decimal type, and STRING maps to a VMS string descriptor. GFLOAT and HFLOAT are converted to double.

Yes. VX/BASIC keeps both dynamic and fixed-length string handling and uses VMS string descriptors for STRING data, so migrated code stays compatible with VMS BASIC string memory management.

VX/BASIC preserves VMS error codes and the ON ERROR handling model, so programs behave the same as they did on OpenVMS, including RMS errors such as the file-not-found condition. Return-value checks on system routines are backed by the VX/RT runtime libraries, and ERR, ERL, ERT$, RMSSTATUS, and VMSSTATUS are all available for introspection.

VX/BASIC fully translates RECORD and MAP declarations into C. A RECORD becomes a typedef'd struct, a VARIANT becomes a union with one struct per CASE, and several MAP declarations that name the same storage become parallel structs bound to one backing block, preserving the exact VAX BASIC byte layout.

All VMS BASIC statements except the graphics family are supported, including IF...THEN, FOR...NEXT, WHILE, SELECT CASE, GOTO, and ON ERROR GOTO. Terminal I/O such as PRINT, INPUT, and LINPUT is covered, and RMS file I/O supports sequential, relative, indexed, and virtual organizations.

The one documented exclusion is the graphics command family, which is recognised but not translated. GFLOAT and HFLOAT are converted to double rather than preserved exactly (HFLOAT loses precision), and a few OpenVMS-specific options such as OPTION ANGLE are out of scope. Everything else in the core language is supported.

VX/COBOL automatically converts VMS and OpenVMS COBOL to ANSI-compliant COBOL so the application runs on x86 Linux with no manual code changes. The converted code targets the Fujitsu NetCOBOL and Micro Focus COBOL compilers, and the original COBOL logic and structure are preserved.

VMS and OpenVMS can initialize a pointer by reference, which ANSI COBOL does not allow. VX/COBOL changes the initialization to a null value and generates a MOVE FUNCTION ADDR statement in an init section, so the pointer is set up correctly in the PROCEDURE DIVISION without any manual editing.

VX/COBOL replaces GIVING with RETURNING, converts each OMITTED argument to BY VALUE 0, and for known item-list system services renames the callee to its COB$ runtime counterpart. All of this is automatic, so the calling code does not need manual editing.

Yes. VX/COBOL is built for continuous integration: you keep developing in VMS and OpenVMS COBOL, and each release is migrated to Linux automatically, so there is no code freeze and full functionality is preserved across the estate.

VX/COBOL routes file operations through VX/RMS, so RMS file handling carries over to Linux. Programs keep their VMS file organizations, access modes, record formats, and locking behaviour, and per-file RMS status is preserved for the status special registers.

Yes. As part of targeting Linux, VX/COBOL adjusts for 32-bit and 64-bit architecture differences, widening descriptors and converting stored pointers where needed, so the migrated application behaves correctly on x86 Linux.

VX/COBOL drops the OpenVMS APPLY LOCK-HOLDING clause from I-O-CONTROL and instead adds LOCK MODE IS AUTOMATIC to the affected file's SELECT in FILE-CONTROL, so record-locking behavior carries over without manual rework.

It translates OpenVMS and VAX FORTRAN into ANSI-compliant FORTRAN (Intel FORTRAN) that runs on x86 Linux and Windows. It is built on the Fortran Partner (fpt) transpiler and adds VMS-specific handling, standards adherence, and performance optimizations, so decades of FORTRAN investment move forward without manual code modifications.

Source code analysis identifies VMS-specific extensions, RMS file dependencies, and embedded Pro*FORTRAN SQL. Transpilation converts VMS extensions to ANSI-standard FORTRAN. Optimization tunes the emitted source with inline expansion and loop unrolling for Intel FORTRAN. Finally, compile and validate builds the source and runs automated test cases to confirm identical execution behaviour.

VMS file specifications are translated to host paths at run time, so standard OPEN statements keep working. Keyed and indexed (ISAM) files, along with the REWRITE, DELETE, and UNLOCK record operations, are routed to the VX/RMS runtime, which replaces obsolete ISAM handling with modern FORTRAN record I/O while preserving key structure and record locking.

VX/FORTRAN automatically converts Pro*FORTRAN SQL statements into external C functions, so database access keeps working on the target platform without hand-rewriting the embedded SQL.

VX/FORTRAN applies optimizations during migration: inline expansion of subroutines and statement functions to remove call overhead, loop unrolling, and memory-access optimizations. The gain depends on the application.

Advanced static analysis flags syntax, logical, and performance issues before migration. A representative report shows missing subroutine declarations (which would stop compilation), inconsistent argument types (which could cause runtime crashes), and unsafe integer-to-real conversions (which could lose precision). It also flags keywords used as variable names and uninitialised variables.

Yes. VX/FORTRAN supports zero code freeze. You continue development on OpenVMS while each release is migrated to Linux and Windows in parallel, so the migration does not stall ongoing work.

No. The migration is fully automated, with no manual code changes. VX/FORTRAN rewrites VMS extensions to standard FORTRAN, and the analysis stage reports missing sub-programs and mismatched arguments before any rewrite.

It is an automated source-to-source translator that converts OpenVMS and VAX Pascal into ANSI-compliant C++, which then compiles, links, and runs on x86 Linux and Windows. It targets readable, maintainable C++ rather than opaque machine-generated output.

It supports VMS-specific extensions, including VMS stack operations, string descriptors, CDD data structures, and RMS file handling: the constructs a generic Pascal compiler would not understand, so it preserves compatibility with the original application.

Linux and Windows do not natively carry the VMS notion of an optional argument being present or absent. VX/PASCAL preserves the PRESENT and not-present semantics in the emitted C++ and its runtime, so optional-argument handling behaves as it did on OpenVMS.

No. VX/PASCAL is built for continuous migration: you can keep developing in OpenVMS Pascal while each release is migrated, with source kept synchronized between the Pascal and C++ versions and builds carried across through converted MMS and command files.

VARYING and packed string types become runtime string class templates that keep VMS length and padding semantics, and VMS string routines such as STR$CONCAT and STR$COPY are handled through the STR$ runtime and C++ operator overloading.

Through the VX/RMS runtime, the generated code supports indexed, relative, sequential, and block files, plus keyed access, RFA access, and record locking, so file behavior carries over without a data conversion step.

It integrates with VX/CDD to retain Common Data Dictionary record definitions during conversion, so CDD-defined data types and references carry through into the translated C++.

The migration process ends with an execute-and-validate step that runs automated test cases to confirm identical behavior between the original VMS Pascal and the translated C++, and any construct the translator cannot represent is named with a numbered diagnostic rather than dropped.