The FORTRAN and C on that system have been doing the job for thirty years. The problem is everything underneath: hardware nobody makes, data that only that system can read, and a shrinking number of people who know how either works.
OpenVMS modernization is not a cloud exercise, and it rarely starts with a rewrite. It is a sequence of low-risk moves that take the hardware risk off the table first, open up the data second, and leave decisions about the code until you have the time and information to make them well. The plant keeps running throughout, and the system stays supported the whole way: Salem supports OpenVMS and the older operating systems around it as they run today, not only after they have been modernized.
This article covers VAX, Alpha, and Itanium (HPE Integrity) systems running OpenVMS. For Windows-era applications built on VB6, C++, Classic ASP, and ADO, see our companion article on Windows legacy application modernization.
“The VMS system” is usually several things that grew together over decades. Before choosing a path, it helps to name the parts, because each one constrains the options differently.
| Platform | Era | Status today |
|---|---|---|
| VAX | 1977 to late 1990s | Orphaned by its vendors. No vendor-supported hardware or OS, and VSI does not support VAX. The last Oracle Rdb release for VAX was 7.0. Salem still supports VAX/VMS systems, on original hardware or under vtVAX emulation. |
| Alpha | 1992 to mid-2000s | Hardware long out of production. OpenVMS itself is still supported on Alpha by VMS Software Inc. (VSI). Oracle Rdb runs on Alpha, with Oracle’s extended support. Salem can still support it. ending December 2027. |
| Itanium (HPE Integrity) | 2003 to 2021 | Intel stopped shipping Itanium in 2021, and HPE’s support for Integrity servers ended at the end of 2025. Salem can still supports OpenVMS on Integrity. |
| x86-64 | 2022 onward | VSI OpenVMS V9.2 and later run natively on x86-64 servers and hypervisors. This is the go-forward platform for OpenVMS itself. |
The OS is not the end-of-life problem on Alpha and Itanium; the hardware is. On VAX, both are. Either way, an end-of-life label from a vendor does not have to mean an unsupported system: Salem provides OpenVMS support for VAX, Alpha, and Itanium systems, from VAX/VMS 5.x through OpenVMS 8.x, including versions that VSI’s support does not cover.
In Salem’s assessments of production OpenVMS systems, the same languages or tools come up again and again:
| Language or tool | What you will find | Why it matters for modernization |
|---|---|---|
| FORTRAN | VAX FORTRAN (FORTRAN 77 with DEC extensions) on VAX; DEC, Compaq, and HP Fortran (Fortran 90/95 compilers that also accept the older dialect) on Alpha and Itanium. Often the bulk of the process logic, sometimes hundreds of thousands of lines. | DEC extensions such as STRUCTURE/RECORD, %VAL/%REF, and direct system-service calls tie code to VMS. |
| Fortran with embedded database access | Source files that a precompiler turns into plain Fortran: embedded SQL (.SFO, Oracle Rdb SQL precompiler) and RDML (.RFO, Rdb’s older data-manipulation language). | The database logic is woven into the application. Any database change touches these files, and both precompilers are Rdb-only. |
| C | VAX C on older systems, then DEC C, Compaq C (V6.x), and HP C (V7.x) on Alpha and Itanium. Common for interfaces, utilities, and network code. | Mostly portable, but older VAX C code relies on behavior later compilers flag. Socket code often links against the TCP/IP stack’s own libraries. |
| MACRO-32 | VAX assembly language. On Alpha and Itanium it is compiled rather than assembled, so it still runs. | Usually small but critical: device drivers, system-service wrappers, timing code. Some MACRO-32 is generated by other compilers rather than written by hand. |
| CRISP/32 | A compiled process-control logic language with its own runtime, still found driving plant logic on Alpha. | The logic depends on a third-party runtime license. Moving off CRISP means re-expressing the logic, not recompiling it. |
| SQL module language | Rdb’s way of keeping SQL in separate modules that host-language code calls. | Cleaner to migrate than embedded SQL, but still Rdb’s SQL dialect. |
| DCL | The VMS command language. It runs batch jobs, start-up, builds, menus, and much of the operational glue. | Often the least documented and most underestimated part of the system. Thousands of command procedures are common. |
| Screen and report tools | FMS and DECforms screen forms, SmartStar, DATATRIEVE, FOCUS. | A compiled form library may be the only record of an operator screen, and the source may be gone. |
| Others | COBOL, BASIC, Pascal, BLISS, PL/I, Ada, DEC C++. | Less common in plant systems, but each one needs a compiler or a translation path. |
RMS (Record Management Services) is the file system’s own record layer. Sequential, relative, and indexed files are how a great deal of VMS application data is stored, especially in FORTRAN, COBOL, and BASIC systems. An RMS indexed file behaves like a keyed table, but it has no schema. The record layout lives in the programs that read it, sometimes in an FDL file, sometimes in a Common Data Dictionary (CDD) definition, and sometimes nowhere at all.
Fields are often stored in binary or packed formats, and some records change layout depending on a type code. Nothing outside VMS can read that data correctly without knowing all of this.
Oracle Rdb is a full relational database. DEC originally developed it, and Oracle has owned it since 1994. It is not Oracle Database: the SQL dialect, storage model, and tools are different, and moving between them is a port, not an upgrade.
Rdb 7.4 runs on OpenVMS Alpha and Integrity, but its future is now fixed. In 2026, Oracle confirmed it will not port Rdb to OpenVMS x86-64. Premier Support for Rdb 7.4 ended in December 2025, and Extended Support ends in December 2027, after which there will be no new patches. The CDD repository and Oracle CODASYL DBMS are on the same path. VAX systems are frozen at Rdb 7.0. Rdb is often reached from applications through embedded SQL, RDML, or SQL modules, and from outside through Oracle’s SQL/Services, ODBC, and JDBC interfaces.
Many estates have both: Rdb for the core production records, RMS files for configuration, queues, and anything written before the database existed.
Spare parts for VAX and Alpha systems come from a shrinking secondary market. Disk drives, tape drives, power supplies, and console terminals fail on their own schedule, and when one goes, recovery depends on finding a matching part. A line can be down for days. With HPE’s Integrity support now over, Itanium sites face the same problem a generation later.
OpenVMS system management, DCL, FORTRAN process logic, RMS file design, and Rdb administration are scarce skills. When the last person who understands a batch stream or a record layout leaves, the knowledge leaves too. Salem’s OpenVMS system managers and developers can take over day-to-day support, so the system is not left without anyone who knows it. Salem’s work on retiring expertise covers this in practical terms.
MES, ERP, quality, and analytics systems all want production data, and most OpenVMS data is only readable from OpenVMS. RMS files have no external interface at all without middleware. Opening up that data is often worth as much as the hardware fix. See legacy data access.
CISA lists unsupported or end-of-life software among its bad practices for critical infrastructure. A VAX running a decades-old OS version, reachable over DECnet or old TCP/IP stacks, is hard to defend in an audit. Moving to supported platforms, putting the operating system under an active support agreement, and segmenting the network closes that gap.
These paths are not alternatives so much as a sequence. Most programs use two or three of them, in roughly this order. For Oracle Rdb sites, Salem runs them as the Controlled Runway: a fixed-fee Risk Assessment, then three phases (Stabilize, Understand, Migrate), each scoped and engaged separately, with long-term support running underneath the whole time.
Before changing anything, get the current system under control: verified backups that have been restored, an inventory of hardware and licenses, spare parts on the shelf, and the DCL procedures, batch queues, and start-up sequence written down. This is cheap and buys time for everything else. If there is no one left in-house to do it, this is where a legacy OS support agreement with Salem usually starts.
High-fidelity emulators such as vtVAX and vtAlpha recreate VAX or Alpha hardware in software on modern x86-64 servers. The existing OpenVMS installation, applications, RMS files, and Rdb databases move over as disk images and run as they did, with no source changes and no recompiling. Operators see the same screens. For VAX and Alpha systems, this is usually the lowest-risk first step, because it takes hardware failure off the table quickly: the cutover itself is usually measured in days. Native Oracle Rdb comes across unchanged, so nobody is forced to replace the database just to get off old hardware. This is Phase 1 of the Controlled Runway. See OpenVMS virtualization, VAX emulation, and Alpha emulation.
Where “unchanged” stops being true. Emulators reproduce the CPU, memory, disks, network, and serial ports. They do not reproduce custom I/O cards. A system that talks to plant equipment through Q-bus or Unibus cards, TURBOchannel or PCI data-acquisition boards, GPIB, or DR11-type parallel interfaces needs a plan for that interface, usually a replacement over Ethernet or serial. Discovery should find these early.
Itanium systems can use this step too, by a different route. There is no Itanium emulator, but OpenVMS and most of its layered products, Oracle Rdb included, also exist for Alpha. Salem can move an Itanium workload onto vtAlpha with minimal changes: the application is rebuilt for Alpha, then runs on emulated Alpha hardware on a modern server. It is not the zero-change move that VAX and Alpha sites get, but it takes Itanium hardware out of the picture without porting the database.
Emulators run on Bare Metal or under common hypervisors, so the emulated system can sit in your existing virtual infrastructure with its backups and monitoring. Salem supports the emulated system afterward, the guest OS included, under its long-term support services.
VSI’s native x86-64 release lets OpenVMS applications run on standard Intel and AMD servers without emulation. VSI provides compilers for the main OpenVMS languages, including C, C++, Fortran, COBOL, BASIC, Pascal, BLISS, and MACRO-32. Alpha and Itanium code generally recompiles with modest changes. VAX code usually needs an intermediate port, because VAX-specific assumptions (data alignment, MACRO-32 code, data formats) have to be dealt with first.
This is one of the main paths for Itanium systems. Integrity sites are choosing between recompiling on x86-64 OpenVMS, moving the workload onto vtAlpha (see step 2), or moving the application off VMS entirely. Salem pairs an x86-64 port with application porting and revalidation: source-code review, a compiler and build-system rebuild, then unit, integration, performance, stress, and user-acceptance testing to prove the ported system behaves identically.
For Rdb applications on VAX or Alpha, a direct move to OpenVMS x86-64 is rarely the right first step. Because Rdb cannot come along, it forces the database to be replaced at the same moment as the platform, in one high-stakes event with no chance to prove the new environment in parallel. Stabilizing under emulation first, then migrating in stages, avoids that.
Two things decide how easy the port is:
Layered products. Every product the application depends on (database, forms, process-control runtime, TCP/IP stack, job scheduler) has to exist on x86-64 too. Oracle Rdb is the big one: Oracle has cancelled Rdb for x86-64, so an Rdb application can only make this move if its database moves too. That usually means native Oracle Database on Windows or Linux, reached over the network. Another database that runs on OpenVMS x86-64 (Mimer, for example, offers Rdb compatibility features), SQL Server, or PostgreSQL can also fit, and the assessment weighs those on evidence.
Data formats. Numeric and binary data stored by older systems do not always mean the same thing on newer platforms or in a new database. Every data move needs a validation step that compares values, not just row counts.
You can make OpenVMS data available to the rest of the plant without touching the application. Rdb can be reached over ODBC and JDBC. RMS files can be exposed through third-party SQL connectors once their record layouts are defined. Data can also be replicated on a schedule to SQL Server or another modern database for reporting and integration. This often delivers the integration benefits people want from modernization, years before any code changes.
The same work helps the system get understood while it runs: dependencies between programs, databases, DCL procedures, and outside systems are mapped, resulting in a risk register and a target plan for migration. This is Phase 2 of the Controlled Runway.
For Rdb sites, this is no longer optional, only a question of timing. With no x86-64 release and no patches after December 2027, every Rdb database will eventually need a new home. Emulation keeps Rdb running on vtAlpha in the meantime. It does not change the support dates, but it does take the hardware deadline away, so the move can be planned rather than rushed.
This is Phase 3 of the Controlled Runway, done incrementally, in parallel, and reversibly. When the database itself has to move, two very different jobs are involved: RMS to SQL. First, recover the schema: every record layout, key, and variant from source code, FDL, and CDD. Then convert the binary and packed fields and load the data into relational tables. The hard part is finding the layouts, not moving the bytes.
Rdb to native Oracle Database on Windows or Linux, which is the natural destination for most Rdb sites, or to an alternative such as SQL Server, PostgreSQL, or an OpenVMS-native database where the assessment shows a better fit. Translate the schema, convert the Rdb SQL dialect, stored procedures, and triggers, and repoint every precompiled SFO, RFO, and SQL module. Here is a case study on how Salem helped a customer migrate to a modern database.
Either way, run the old and new databases in parallel and compare them before anything depends on the new one. Every step should be reversible until the new side is proven.
Once the hardware risk is gone and the data is accessible, some parts of the application may be worth rewriting: an operator interface moved off FMS forms, a reporting layer taken over by modern tools, a module nobody can maintain. Rewrite pieces, not the whole system, and only where the long-term cost of keeping the old code clearly outweighs the risk of replacing it.
| VAX | Alpha | Itanium | |
|---|---|---|---|
| Emulate | Yes (vtVAX). Usual first step. | Yes (vtAlpha). Usual first step. | Via vtAlpha, with minimal changes. There is no Itanium emulator, so the application is rebuilt for Alpha. |
| Port to x86-64 OpenVMS | Possible, but usually via an intermediate port. Rdb stuck at 7.0. | Yes, subject to layered products. Rdb applications must also migrate the database, so Rdb sites usually stabilize under emulation first. | Main path, subject to layered products. Rdb applications must also migrate the database, so Rdb sites may stabilize on vtAlpha first. |
| Open up data | Yes | Yes | Yes |
| Migrate data or rebuild | Yes, after stabilizing under emulation | Yes, after stabilizing under emulation | Yes, after stabilizing on vtAlpha or as the primary path |
Most OpenVMS programs that run into trouble do so because the system turned out to be bigger or stranger than anyone thought. Salem starts every engagement with a read-only, fixed-scope, fixed-fee Risk Assessment. It answers three questions:
The answers fit in a sentence, for example, “two applications, about 700,000 lines, 400 tables, 98% of the code with matching source,” and they decide which paths are realistic. The same assessment flags hazards such as missing source, third-party runtimes, cluster members holding part of the system, and custom I/O cards.
There is no commitment beyond it: each later phase is scoped and funded only if the evidence justifies it. Request an assessment.
Avoid a single, all-at-once cutover. It concentrates every risk (undocumented dependencies, data that will not reconcile, downtime) into one event you cannot price in advance. Whichever path you take, the transition should follow the same pattern instead. Build the new environment alongside production, run it in shadow mode against live inputs, and compare outputs until operators and process engineers trust it. Then cut over to a rehearsed plan with a tested way back. Train system managers on the new environment and treat knowledge transfer as a deliverable, so you do not replace one single point of failure with another.
Yes, from two directions. VMS Software Inc. (VSI) develops and supports current OpenVMS releases on Alpha, Integrity (Itanium), and x86-64. VAX has no vendor support left, and many plants run older OpenVMS versions that Salem can cover.
Salem supports legacy operating systems, OpenVMS included. That covers VAX/VMS 5.x and OpenVMS 6.x through 8.x, on original hardware or under vtVAX and vtAlpha emulation, along with Tru64 UNIX, IBM AIX, and Oracle Solaris. Support comes in three lines: Remote System Administration, where Salem runs the system on your behalf; Remote System Monitoring, with proactive health checks, alerts, and reporting; and OS telephone support. Every line is available with business-hours or 24×7 coverage and a 1-, 2-, or 4-hour response time. You do not have to modernize to be supported. See Support Services.
The aging part of most systems is the hardware, not the OS.
Usually, yes. Emulation keeps it exactly as it is, and FORTRAN recompiles on OpenVMS x86-64. Rewriting working process logic is rarely the best first move.
A focused VAX or Alpha emulation project often takes weeks, with on-site cutover measured in days. Custom I/O interfaces, clusters, and the amount of parallel validation needed are what stretch it.
Oracle will not port Rdb to OpenVMS x86-64, and Extended Support for Rdb 7.4 ends in December 2027. After that, Rdb stays on Sustaining Support with no new patches. Rdb will keep running, on real hardware or under emulation, but every Rdb site now needs a database migration plan.
The deadline is real, but the response does not have to be rushed: stabilize on modern hardware first, then migrate on your own timeline. You do not have to leave Oracle; for most sites the natural destination is native Oracle Database on x86, running on Windows or Linux. Start with an inventory of where Rdb is used, including embedded SQL, RDML, SQL modules, and CDD definitions, because that decides how large the job is.
This is the hardest combination. HPE’s Integrity hardware support has ended, there is no Itanium emulator, and Rdb will never run on x86-64, so you cannot simply port to x86-64 and keep the database. You do have a way to stabilize first, though. Because Rdb runs on Alpha, Salem can move the workload onto vtAlpha with minimal changes, rebuilding the application for Alpha while keeping Rdb.
That removes the Itanium hardware risk and gives you the same controlled runway VAX and Alpha sites get. From there, migrate the database in stages, typically to native Oracle Database on Windows or Linux, running old and new in parallel. Rdb’s support dates still apply on vtAlpha, so plan the database migration with December 2027 in view.
Salem Automation, based in Winston-Salem, North Carolina, works in exactly these environments: VAX, Alpha, and Itanium systems running FORTRAN, C, MACRO-32, and DCL, with data in RMS and Oracle Rdb. First, Salem supports the legacy operating systems themselves, OpenVMS and VAX/VMS included, for as long as you run them.
For Oracle Rdb sites, that work is packaged as the Controlled Runway: a fixed-fee Risk Assessment, then Stabilize, Understand, and Migrate, each engaged separately. Services also include vtVAX, vtAlpha, and vtSparc emulation, data access, selective rebuilds, structured knowledge transfer, and long-term support (hosting, disaster recovery, system and database administration, and legacy development in C/C++, Fortran, COBOL, and Pascal).
The constant is continuity: production keeps running while the platform underneath it changes. Learn more about our legacy application modernization services.
