VX/FORTRAN - OpenVMS FORTRAN to ANSI FORTRAN

VX/FORTRAN is a source-to-source migration tool that rewrites OpenVMS and VAX FORTRAN into ANSI-compliant FORTRAN (Intel FORTRAN), so existing applications compile and run on x86 Linux and Windows with no manual code changes. It is built on the Fortran Partner (fpt) transpiler and adds the VMS-specific handling, standards adherence, and performance optimizations a real OpenVMS estate depends on, so decades of scientific and engineering FORTRAN move forward intact.

The migration is fully automated. VMS language extensions are rewritten to standard FORTRAN, semantic differences are re-programmed so behaviour is preserved, and file and record access is carried by the VX/RMS runtime, so RMS and ISAM I/O, VMS system services, and embedded Pro*FORTRAN SQL keep working on the target platform. Teams keep developing on OpenVMS while each release is migrated to Linux and Windows, so there is no code freeze during a long project.

<div class="s7-tech-embed" data-vxfortrand-body-embed="1" data-technical-mega-embed="1" lang="en"><h2 id="architecture">Translation model and pipeline</h2><p> VX/FORTRAN is a compile-time source-to-source translator, not a runtime emulator. It reads OpenVMS and VAX FORTRAN and writes ANSI-standard FORTRAN, which the Intel FORTRAN compiler (ifort or ifx) then builds into a native Linux or Windows executable. The rewriting is done by the Fortran Partner (fpt) transpiler, which works on a typed model of the whole program rather than doing text substitution, so it can distinguish a VMS extension from a semantic difference and apply the correct change to each. </p><p> Two things ship together: the fpt transpiler that rewrites the source, and the VX/RMS runtime library the rewritten program links against for VMS file, record, and system behaviour. Source that used VMS filespecs, ISAM files, or VMS system services keeps working because those constructs are routed to the runtime rather than being left to the target compiler. </p><div class="callout"><strong>Compile-time, not runtime.</strong> VX/FORTRAN emits ordinary ANSI FORTRAN, so the output is standard source the Intel toolchain builds, debugs, and profiles. The VX/RMS runtime supplies the file and record access and the OpenVMS system-service behaviour the emitted code depends on. </div><h6>Pipeline</h6><style>.s7-tech-embed .process-flow {margin: 1.5rem 0;padding: 16px;border: 1px solid var(--s7t-border);border-radius: 10px;background: rgba(255, 255, 255, 0.01);}.s7-tech-embed .process-endpoint {display: grid;grid-template-columns: 72px minmax(0, 1fr);gap: 14px;align-items: center;padding: 14px 16px;border-radius: 8px;background: var(--s7t-surface);color: var(--s7t-text);}.s7-tech-embed .process-output {border: 1px solid var(--s7t-note-bd);background: var(--s7t-note-bg);}.s7-tech-embed .process-label,.s7-tech-embed .process-number {font-family: var(--s7t-mono);color: var(--s7t-accent);font-size: 0.76em;font-weight: 700;letter-spacing: 0.08em;text-transform: uppercase;}.s7-tech-embed .process-endpoint div,.s7-tech-embed .process-stage {min-width: 0;}.s7-tech-embed .process-endpoint strong,.s7-tech-embed .process-endpoint span:last-child,.s7-tech-embed .process-stage strong,.s7-tech-embed .process-stage span:last-child {display: block;}.s7-tech-embed .process-endpoint strong,.s7-tech-embed .process-stage strong {margin-bottom: 4px;color: var(--s7t-text);}.s7-tech-embed .process-endpoint span:last-child,.s7-tech-embed .process-stage span:last-child {color: var(--s7t-muted);font-size: 0.9em;line-height: 1.45;}.s7-tech-embed .process-stages {display: grid;grid-template-columns: repeat(3, minmax(0, 1fr));gap: 10px;margin: 10px 0;}.s7-tech-embed .process-stage {padding: 15px;border-top: 3px solid var(--s7t-accent);border-radius: 6px;background: var(--s7t-surface2);color: var(--s7t-text);}.s7-tech-embed .process-stage .process-number {margin-bottom: 10px;}@media (max-width: 800px) {.s7-tech-embed .process-stages {grid-template-columns: 1fr;}.s7-tech-embed .process-endpoint {grid-template-columns: 1fr;gap: 5px;}}</style><div class="process-flow" aria-label="VX/FORTRAN translation pipeline"><div class="process-endpoint"><span class="process-label">Input</span><div><strong>OpenVMS or VAX FORTRAN</strong><span><code>.for</code> or <code>.f</code> source</span></div></div><div class="process-stages" role="list" aria-label="Translation stages"><div class="process-stage" role="listitem"><span class="process-number">01</span><strong>Static analysis</strong><span>Analyses the complete program and identifies VMS-specific dependencies.</span></div><div class="process-stage" role="listitem"><span class="process-number">02</span><strong>Transpile</strong><span>Rewrites VMS extensions and semantic differences into standard FORTRAN.</span></div><div class="process-stage" role="listitem"><span class="process-number">03</span><strong>Optimise</strong><span>Applies source-level optimisations to the translated program.</span></div><div class="process-stage" role="listitem"><span class="process-number">04</span><strong>Emit</strong><span>Writes ANSI or Intel FORTRAN source as <code>.f90</code>.</span></div><div class="process-stage" role="listitem"><span class="process-number">05</span><strong>Intel compiler</strong><span><code>ifort</code> or <code>ifx</code> compiles and links the source against the VX/RMS runtime.</span></div></div><div class="process-endpoint process-output"><span class="process-label">Output</span><div><strong>x86 Linux or Windows binary</strong><span>Native executable linked against the VX/RMS runtime</span></div></div></div><h6>What runs the migration</h6><div class="table-wrapper"><table><thead><tr><th>Stage</th><th>Role</th></tr></thead><tbody><tr><td>Source code analysis</td><td>Identifies VMS-specific extensions, RMS file dependencies, and embedded Pro*FORTRAN SQL, and reports missing sub-programs and mismatched arguments before any rewrite.</td></tr><tr><td>Transpile</td><td>fpt rewrites VMS spelling, language extensions, and semantic differences into standard FORTRAN.</td></tr><tr><td>Optimise</td><td>Applies inline expansion, loop unrolling, and memory-access optimisations while emitting the ANSI source.</td></tr><tr><td>Compile and validate</td><td>The Intel FORTRAN compiler builds the emitted source, and automated test cases confirm identical execution behaviour.</td></tr></tbody></table></div><h2 id="dialect-coverage">Source dialect coverage</h2><p> VX/FORTRAN parses the full OpenVMS and VAX FORTRAN surface into a typed model, so it understands the extensions a real estate uses rather than passing them through as text. The table groups the VMS-specific constructs it recognises and shows how each one is carried onto the target platform: some are rewritten inline to standard FORTRAN, others are routed to the VX/RMS runtime, and the remainder are recognised and preserved for the target compiler. </p><div class="table-wrapper"><table><thead><tr><th>VMS construct</th><th>How it is migrated</th></tr></thead><tbody><tr><td><code>STRUCTURE</code> / <code>RECORD</code> / <code>UNION</code> / <code>MAP</code> aggregates, <code>BYTE</code> type</td><td>Rewritten to standard derived types and equivalence layouts.</td></tr><tr><td>Argument-passing built-ins <code>%REF</code>, <code>%VAL</code>, <code>%LOC</code>, <code>%DESCR</code></td><td>Call sites rewritten to the host calling convention.</td></tr><tr><td>Hollerith literals (<code>5HHELLO</code>) in DATA and FORMAT</td><td>Rewritten to character constants.</td></tr><tr><td>Legacy BOZ literals (<code>'FF'X</code>, <code>'377'O</code>, <code>'101'B</code>)</td><td>Rewritten to standard hexadecimal, octal, and binary constants.</td></tr><tr><td>Legacy I/O statements (<code>ACCEPT</code>, <code>TYPE</code>, <code>ENCODE</code>, <code>DECODE</code>, <code>DEFINE FILE</code>)</td><td>Rewritten to standard READ, PRINT, and internal-file I/O.</td></tr><tr><td>Record I/O statements (<code>REWRITE</code>, <code>DELETE</code>, <code>UNLOCK</code>, <code>FIND</code>)</td><td>Routed to the VX/RMS runtime for keyed and relative files.</td></tr><tr><td>Specification extensions (<code>AUTOMATIC</code>, <code>STATIC</code>, <code>VIRTUAL</code>, Cray-style integer <code>POINTER</code>, <code>IMPLICIT UNDEFINED</code>)</td><td>Mapped to standard storage and pointer declarations.</td></tr><tr><td>Variable and run-time <code>FORMAT</code> expressions</td><td>Rewritten to run-time format strings.</td></tr><tr><td>DEC-style <code>INCLUDE</code> with logical names, <code>DICTIONARY 'record'</code> (CDD)</td><td>Logical names resolved; CDD records extracted and inlined as FORTRAN.</td></tr><tr><td>VAX intrinsics (<code>IARGCOUNT</code>, <code>SIZEOF</code>)</td><td>Mapped to standard intrinsics and argument-count handling.</td></tr><tr><td><code>cDEC$</code> / <code>!DEC$</code> compiler directives</td><td>Recognised and preserved, including conditional-compilation blocks.</td></tr></tbody></table></div><div class="callout"><strong>Named gaps, not silent ones.</strong> Any construct the translator cannot fully represent is counted and named in the analysis report rather than dropped, so the migration is auditable and nothing disappears without a trace. </div><h6>Compiler directives</h6><p> VMS compiler directives written as <code>cDEC$</code>, <code>*DEC$</code>, or <code>!DEC$</code> in fixed or free form are recognised and carried through the migration, including <code>ATTRIBUTES</code>, <code>ALIAS</code>, <code>IVDEP</code>, <code>UNROLL</code>, <code>PSECT</code>, and the <code>!DEC$ IF</code> / <code>ELSEIF</code> / <code>ELSE</code> / <code>ENDIF</code> conditional-compilation construct. Source form switches such as <code>FREEFORM</code> and <code>FIXEDFORM</code> are honoured so mixed-form estates parse correctly. </p><h2 id="transformations">Three classes of change</h2><p> Moving OpenVMS FORTRAN to a standard compiler is not one problem but three, and VX/FORTRAN treats each differently. Syntactic differences are spelling changes rewritten inline; language extensions have no standard equivalent and are routed to the runtime; semantic differences keep the same syntax but mean something different on the host, so the construct is re-programmed to preserve the original behaviour. </p><div class="table-wrapper"><table><thead><tr><th>Class</th><th>What it is</th><th>How VX/FORTRAN handles it</th></tr></thead><tbody><tr><td>Syntactic differences</td><td>VMS spelling that a standard compiler rejects</td><td>Rewritten inline to the standard spelling.</td></tr><tr><td>Language extensions</td><td>VMS features with no standard equivalent (VMS filespecs, ISAM files, variable FORMAT)</td><td>Rewritten to calls into the VX/RMS emulation library.</td></tr><tr><td>Semantic differences</td><td>Same syntax, different meaning on the host compiler</td><td>The construct is re-programmed so behaviour matches OpenVMS.</td></tr></tbody></table></div><h6>Semantic differences the migration re-programs</h6><p> These are the subtle cases where code compiles cleanly on both platforms but would behave differently if left unchanged. VX/FORTRAN detects each one and rewrites it so the migrated program produces the same results as the original. </p><div class="table-wrapper"><table><thead><tr><th>VMS behaviour</th><th>Why it differs on the host</th></tr></thead><tbody><tr><td>Integer used as a LOGICAL</td><td>VMS tests the least-significant bit; other compilers may test the whole value. The compound test is re-programmed to VMS semantics.</td></tr><tr><td>Left-to-right <code>.OR.</code> / <code>.AND.</code> evaluation</td><td>The standard permits reordering, so a short-circuiting compound <code>IF</code> is re-programmed to force VMS ordering.</td></tr><tr><td><code>CALL</code> used to invoke a FUNCTION</td><td>Mismatched call and return conventions corrupt the stack on the host, so the call site is corrected.</td></tr><tr><td>Mismatched 4-byte and 8-byte REAL arguments</td><td>VAX F, D, G, and H floats share leading bits; IEEE-754 does not, so mismatched REAL arguments are corrected.</td></tr><tr><td>Real-number and FORMAT edge cases</td><td>Differences in real formatting and FORMAT interpretation are detected and corrected.</td></tr></tbody></table></div><div class="callout"><strong>Detected before it becomes a runtime bug.</strong> Static analysis flags syntax, logical, and performance issues before migration, so the classes above are resolved at translation time rather than surfacing as wrong results after cutover. </div><h2 id="examples">Before and after</h2><p> These worked examples show VX/FORTRAN rewriting real OpenVMS FORTRAN constructs into standard FORTRAN. The identifiers use a banking demo estate; the syntax is exactly the kind of change the migration applies. </p><h6>Legacy I/O statements</h6><p>VMS terminal I/O statements become their standard equivalents:</p> <pre><span class="kw">TYPE</span> 100, ACCOUNT_ID, BALANCE <span class="kw">ACCEPT</span> 200, NEW_BALANCE</pre> <p>becomes:</p> <pre><span class="kw">PRINT</span> 100, ACCOUNT_ID, BALANCE <span class="kw">READ</span> (*, 200) NEW_BALANCE</pre> <h6>Hollerith and BOZ literals</h6> <pre><span class="kw">WRITE</span> (6, 100) 5HDEBIT, AMOUNT MASK = <span class="str">'FF'</span>X</pre> <p>becomes:</p> <pre><span class="kw">WRITE</span> (6, 100) <span class="str">'DEBIT'</span>, AMOUNT MASK = <span class="kw">Z</span><span class="str">'FF'</span></pre> <p> The Hollerith count-and-string form is rewritten to a character constant, and the VMS <code>'FF'X</code> hexadecimal literal becomes the standard <code>Z'FF'</code> form. </p><h6>VMS file specifications</h6><p>A file opened with a VMS filespec keeps standard OPEN syntax; the runtime translates the specification at run time:</p> <pre><span class="kw">OPEN</span> (<span class="kw">UNIT</span>=11, <span class="kw">FILE</span>=<span class="str">'DISK$DATA:[BANKING]ACCOUNTS.DAT;3'</span>, & <span class="kw">STATUS</span>=<span class="str">'OLD'</span>)</pre> <p> The device, directory, and version-numbered VMS filespec is resolved to a host path by the VX/RMS runtime when the file is opened, so the OPEN statement itself does not need editing and logical names still resolve. </p><h6>Keyed (ISAM) files</h6><p>Indexed and keyed files, which a standard compiler cannot open directly, are routed to the VX/RMS runtime:</p> <pre><span class="kw">OPEN</span> (<span class="kw">UNIT</span>=12, <span class="kw">FILE</span>=<span class="str">'STATEMENTS.DAT'</span>, & <span class="kw">ORGANIZATION</span>=<span class="str">'INDEXED'</span>, <span class="kw">ACCESS</span>=<span class="str">'KEYED'</span>, & <span class="kw">STATUS</span>=<span class="str">'OLD'</span>) <span class="cmt">! ... later ...</span> <span class="kw">REWRITE</span> (<span class="kw">UNIT</span>=12) STATEMENT_REC</pre> <p> The keyed OPEN and the <code>REWRITE</code>, <code>DELETE</code>, and <code>UNLOCK</code> record operations are served by the VX/RMS runtime, which replaces obsolete ISAM handling with modern FORTRAN record I/O while preserving key structure and record locking. </p><h2 id="runtime">Runtime, files, and system libraries</h2><p> The emitted ANSI FORTRAN links against Sector7 runtime libraries that supply the OpenVMS behaviour the source relied on. File and record access, VMS system services, numeric formats, and embedded SQL all resolve against these libraries rather than being left to the target compiler, so the migrated program behaves as it did on OpenVMS. </p><div class="table-wrapper"><table><thead><tr><th>Area</th><th>What the runtime provides</th></tr></thead><tbody><tr><td>File and record I/O</td><td>VMS filespec translation, sequential, relative, and indexed (ISAM) files, and the OPEN, READ, WRITE, REWRITE, DELETE, and UNLOCK record operations, served by <a href="/technical/vx-rms-sys-routines-for-rms">VX/RMS</a>.</td></tr><tr><td>Numeric formats</td><td>VAX F, D, G, and H floating-point data converted to IEEE-754 so numeric results carry over unchanged.</td></tr><tr><td>FORTRAN support routines</td><td>The OpenVMS FORTRAN run-time support entry points delivered by <a href="/technical/api-for-fortran-support-routines">FOR$</a> inside <a href="/technical/vx-rt-apis">VX/RT</a>.</td></tr><tr><td>System services and libraries</td><td>OpenVMS <code>SYS$</code>, <code>LIB$</code>, and <code>SMG$</code> services provided by the <a href="/technical/api-sys-interface-routines">SYS$</a> emulation libraries in VX/RT, so system-service calls link and run without source changes.</td></tr><tr><td>Embedded SQL</td><td>Pro*FORTRAN SQL converted to external C functions on the <a href="/technical/vx-sql-fortran-with-embedded-sql-to-pro-c">VX/SQL-FORTRAN</a> path, so database access keeps working on the target platform.</td></tr></tbody></table></div><h6>File and record access</h6><p> File operations route through <a href="/technical/vx-rms-sys-routines-for-rms">VX/RMS</a>, so sequential, relative, and indexed files behave exactly as they did under OpenVMS RMS. VMS file specifications are translated to host paths at run time, keyed and relative record access is preserved, and record locking carries over, so the migrated program reads and writes the same data files without a data conversion step. </p><h6>System services and DCL</h6><p> Applications that call OpenVMS system services keep working because those calls resolve against the VX/RT emulation libraries rather than the VMS executive. Argument passing that used <code>%VAL</code>, <code>%REF</code>, <code>%LOC</code>, or <code>%DESCR</code> is rewritten to the host convention at translation time, and command-procedure and event-flag behaviour is available through <a href="/technical/vx-dcl-vms-dcl">VX/DCL</a>, so no source changes are needed to reach the services the application depends on. </p><h2 id="compatibility">Compilers, targets, and optimisation</h2><p> VX/FORTRAN produces ANSI-compliant FORTRAN for the Intel compiler on Linux and Windows and preserves the OpenVMS behaviours applications depend on. The matrix summarises what is supported, and the subsections cover the optimisation and code-quality work the migration does along the way. </p><div class="table-wrapper"><table><thead><tr><th>Capability</th><th>Support</th></tr></thead><tbody><tr><td>Target compiler: Intel FORTRAN (ifort / ifx)</td><td><span class="ac-live">live</span></td></tr><tr><td>Target platforms: x86 Linux and Windows</td><td><span class="ac-live">live</span></td></tr><tr><td>OpenVMS RMS and ISAM file handling through VX/RMS</td><td><span class="ac-live">live</span></td></tr><tr><td>OpenVMS system services and run-time libraries via VX/RT</td><td><span class="ac-live">live</span></td></tr><tr><td>VAX F / D / G / H floating-point to IEEE-754 conversion</td><td><span class="ac-live">live</span></td></tr><tr><td>Embedded Pro*FORTRAN SQL to external C functions</td><td><span class="ac-live">live</span></td></tr><tr><td>Source-code security and obfuscation</td><td><span class="ac-live">live</span></td></tr></tbody></table></div><h6>Code optimisation</h6><p> While emitting the ANSI source, VX/FORTRAN applies optimisations that the original VMS build did not: subroutines and statement functions are expanded inline to remove call overhead, loops are unrolled, and memory-access patterns are tuned. Together these reduce function-call and memory latency, and execution time can improve by up to 40 percent over the legacy VMS build. </p><h6>Code-quality analysis</h6><p> Static analysis runs before migration and reports the systematic defects that accumulate in long-lived FORTRAN. A representative analysis report looks like this: </p><div class="table-wrapper"><table><thead><tr><th>Diagnostic</th><th>Count</th><th>Impact</th></tr></thead><tbody><tr><td>Missing subroutine declarations</td><td>12</td><td>Prevents compilation errors.</td></tr><tr><td>Inconsistent argument types</td><td>8</td><td>Fixes potential runtime crashes.</td></tr><tr><td>Unsafe integer-to-real conversion</td><td>15</td><td>Prevents loss of precision.</td></tr></tbody></table></div><p> The analysis also flags keywords and intrinsics used as variable names, inconsistent name usage, and uninitialised variables, so defects are corrected during migration rather than carried onto the new platform. </p><h6>Continuous migration without a code freeze</h6><p> Because conversion is fully automated, a team keeps developing in OpenVMS FORTRAN while each release is migrated to Linux and Windows on demand. There is no code freeze during a long project, and functionality is preserved across the estate. </p><h6>How this differs from an emulator or a rewrite</h6><p> VX/FORTRAN is neither a hand rewrite nor a runtime emulator. It is a compile-time translator that emits ANSI-compliant FORTRAN, so the result is standard source the Intel toolchain builds and developers can read, debug, and maintain with mainstream tools. Every change is recorded, and any construct the translator cannot represent is named rather than dropped, so the migration is auditable rather than a black box. </p><h2 id="quick-reference">Quick reference</h2><h6>Pipeline</h6><p><code>analyse → transpile → optimise → emit</code>, then build the emitted ANSI FORTRAN with the Intel compiler and link the VX/RMS and VX/RT runtimes.</p> <pre><span class="cmt">1. Migrate: OpenVMS FORTRAN in, ANSI / Intel FORTRAN out (plus an analysis report)</span> account.for -> account.f90 + account.log <span class="cmt">2. Compile the emitted source with Intel FORTRAN</span> ifx -O2 account.f90 -o account <span class="cmt">! links VX/RMS + VX/RT</span></pre> <h6>Signature transforms to remember</h6><div class="table-wrapper"><table><thead><tr><th>OpenVMS FORTRAN</th><th>ANSI FORTRAN</th></tr></thead><tbody><tr><td><code>TYPE</code> / <code>ACCEPT</code></td><td><code>PRINT</code> / <code>READ</code></td></tr><tr><td><code>5HHELLO</code> (Hollerith)</td><td><code>'HELLO'</code> (character constant)</td></tr><tr><td><code>'FF'X</code> / <code>'377'O</code> / <code>'101'B</code></td><td><code>Z'FF'</code> / <code>O'377'</code> / <code>B'101'</code></td></tr><tr><td>VMS filespec in OPEN</td><td>Translated to a host path by VX/RMS</td></tr><tr><td><code>ACCESS='KEYED'</code> / ISAM files</td><td>Routed to the VX/RMS runtime</td></tr><tr><td><code>%VAL</code> / <code>%REF</code> / <code>%LOC</code> / <code>%DESCR</code></td><td>Host calling convention</td></tr><tr><td>Integer used as LOGICAL</td><td>Re-programmed to VMS LSB semantics</td></tr><tr><td>Pro*FORTRAN embedded SQL</td><td>External C functions</td></tr></tbody></table></div><h6>What migrates</h6><div class="kw-grid"><div>VMS extensions</div><div>Semantic differences</div><div>RMS / ISAM I/O</div><div>VAX float to IEEE</div><div>SYS$ / LIB$ / SMG$</div><div>Pro*FORTRAN SQL</div><div>DEC$ directives</div><div>CDD dictionary records</div></div></div>

On this page

Frequently Asked Questions

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

Free Code Assessment

Our OpenVMS application makes use of multiple System Services. How do you support that?

Sector7 has an extensive library of these services running on Linux to perform the same functions as on OpenVMS. our language conversion tools will adapt the arguments in the procedure API to work with this library. For instance, VX/COBOL or VX/FORTRAN etc will transform the argument passed BY DESCRIPTOR to a method that will work on Linux.

When the code is compiled on Linux, the compiled objects are linked with the Sector7 library of system services and the program executes on Linux just as it does on OpenVMS, making full use of the various system services.

The critical point here is that there is no need to touch the original source code, the Sector7 tools do all the work.

What is VX/FORTRAN and how does it help with OpenVMS migration?

VX/FORTRAN is a powerful 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.

The tool is specifically designed for aerospace, defense, and high-tech industries to ensure complete, error-free Fortran migration while preserving decades of software investment. To learn more about how VX/FORTRAN can modernize your legacy systems, contact our migration experts.

Does VX/FORTRAN require manual code modifications during migration?

No, VX/FORTRAN provides 100% automated migration without requiring manual code modifications.

What types of VMS-specific features does VX/FORTRAN handle?

VX/FORTRAN handles VMS-specific extensions, RMS file dependencies, Pro*Fortran SQL statements, and seamless ISAM support through VX/RMS integration.

How does the VX/FORTRAN migration workflow operate?

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.

Can I continue development during the migration process?

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.

Does VX/FORTRAN provide code optimization capabilities?

VX/FORTRAN performs advanced optimizations including loop unrolling, inline expansion, and memory access optimizations that can speed up execution time by up to 40%.

How does VX/FORTRAN handle embedded SQL conversion?

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

What quality assurance and testing capabilities does VX/FORTRAN provide?

VX/FORTRAN includes comprehensive testing tools that support record/replay execution, trace logs, and QA compliance. The tool automatically detects and fixes errors, improving code quality and maintainability by identifying issues like missing subroutine declarations, inconsistent argument types, and unsafe conversions.

Companies like BNY Mellon have leveraged similar automated migration capabilities for critical financial systems. For detailed information about our testing methodologies and quality assurance processes, contact our team.

How does VX/FPT assist in migrating Fortran code from VMS systems?

When migrating Fortran code from VMS systems, VX/FPT addresses several challenges:

Syntactic Differences: Automatically converts VMS-specific syntax to standard Fortran.
Language Extensions: Handles VMS-specific language features not supported by modern compilers.
Semantic Differences: Identifies and corrects statements that behave differently under VMS compared to modern systems.
System Libraries: Works in conjunction with Sector7's VMS emulation libraries to emulate VMS system library routines under Linux or Unix

What types of systematic Fortran errors does VX/FPT detect and correct?

VX/FPT is designed to identify and address various classes of systematic errors, including:

Use of Fortran keywords or intrinsic function names as variable names.
Inconsistent use of names, such as different values for the same parameter name or different COMMON block addresses for the same name.
Uninitialized variables.
Mismatched arguments in subroutine or function calls.

Can VX/FPT modernize legacy Fortran code?

VX/FPT can analyze, re-engineer, and migrate legacy Fortran programs. The approach includes

Identifying and correcting systematic errors in the code.
Generating documentation reports.
Re-engineering code for migration, optimization, and standardization.
Instrumenting code for regression testing and coverage analysis.

‍

How can I assess whether I need VX or Sector7's VX/RT libraries for my Fortran migration project?

All OpenVMS FORTRAN applications use OpeVMS specific APIs and command line functions, it is very unlikely that your FORTRAN application uses no OpenVMS capabilities or libraries.

Determine the need for Sector7's libraries: Use the command show missing sub-programs. If you see routines with names like SYS$, LIB$, or SMG$, you likely require these libraries.
Determine if you need DCL or any other OpenVMS utilities.
Assess the necessity of VX/FPT: Use the command check arguments and review the diagnostics for warnings related to language issues. A significant number of mismatched arguments or other issues indicate that fpt would be beneficial.
Easiest: Sector7 will scan your application and create an index of all OpenVMS specific library calls (APIs)

Semantic Differences - Fortran Statements which compile differently

Real Number Format: The real number format used under VMS is designed so that an 8-byte real value and the corresponding 4-byte real number have the same, or almost the same bit patterns in the first 4 bytes. The consequence is that a sub-program which expects a 4-byte real argument may be passed the corresponding 8-byte argument (Or vice versa) with no error except for a very small change in precision. Usually the code will run correctly. When the code is migrated and uses IEEE real numbers, the 4 and 8-byte representations have different numbers of exponent bits. Therefore, when the 8-byte bit pattern is read as a 4-byte real number (Or vice versa) a significant error occurs. fpt detects and corrects mis-matched real arguments .
‍
Integers Used as Logicals: VMS Fortran allows integer variables (Or expressions) to be used as if they were logicals, for example, in IF statements. Some compilers will reject this use. Others accept it, but may not convert the integer to a logical in the same way as VMS. VMS uses the least significant bit to determine the logical value of an integer. Other compilers may use the sign bit, or treat any non-zero value as logical true. fpt re-programs the usage.
‍
The order of Logical Tests: When VMS Fortran processes a compound IF statement, for example,
IF ((i .LE. 0) .OR. (a(i) .EQ. 0))
The sub-expressions in the logical expression are evaluated in turn from left to right. Thus, in this case, if the array a has bounds (1:10) and i has the value 0, VMS never evaluates a(0). This behaviour is not required by the Fortran standard. Other compilers may evaluate the sub-expressions in parallel or in a different order and the program then crashes with an array reference out-of-bounds. VX/FPT re-programs the construct.
‍
CALL Statements used to call Functions: VMS allows functions to be invoked by CALL statements. Under Linux, Unix or Windows the address of the function return value may be placed on the system stack, which then becomes corrupt. The program crashes when the unused value is eventually un-stacked, sometimes at a point which is remote from the original error. fpt re-programs the usage.

Which Fortran features are not supported by the new host compiler?

These are language constructs which are supported by VMS for which there are no simple syntactic translations to modern Fortran. The code must be re-structured. Usually, sub-programs must be called to supply the missing features.

Again, the VMS code will simply not compile or run without modification. The important issues are:

VMS File Names in OPEN and INQUIRE: VMS file names may contain device directory and version specifications. When these are specified in I/O statements they must be translated at run-time on the new host. This is done by calling sub-programs in Sector7's VXRMS library.
ISAM Files: Indexed Sequential Access Method files are files which contain linkage pointers from fields within their records to related records. Under VMS the OPEN, READ, WRITE and INQUIRE keywords are extended to support them. These extension are not supported under Linux, Unix or Windows. fpt handles ISAM files by replacing the OPEN, CLOSE, INQUIRE, READ and WRITE statements by calls to sub-programs in Sector7' VXRMS library.
Variables and Expressions in FORMAT Statements: Under VMS, variables and run-time expressions may be written inside FORMAT statements or in embedded format strings. The variables or expressions are written within < > delimiters. This construct is translated to standard Fortran using run-time format strings.

The VMS System Libraries - Fortran

The VMS system libraries contain many hundreds of routines which handle issues such as inter-process communication and timing, logical name handling and specialised text and form manipulation. Sector7 . has developed a very complete emulation of these libraries for Linux and Unix. libraries also provide support for the language features in VMS Fortran which are not supported by modern compilers, in particular for ISAM files.

It is important to understand how complex this emulation needs to be. The system must maintain tables which support VMS file names, including file version handling and logical name translations, and these tables must be visible to all programs which use the emulations. Similarly, VMS event flags and mailboxes must be emulated and shared in the same way as under VMS. The system must also contain a complete emulation of DCL.

The VMS system libraries are shared by all of the computer languages supported under VMS: they are not specific to Fortran. In consequence, the arguments to the library routines are sometimes passed in ways which differ from the usual Fortran defaults. Under VMS, the argument passing protocols may be specified by the pseudo-intrinsics %REF, %VAL, %LOC and %DESCR. These, and other attributes of the call-sites must be modified systematically by fpt to conform to the requirements of the target compiler.

What are the Problems?

The issues in migrating from VMS are:

Syntactic Differences: where VMS Fortran simply uses a different syntax from standard Fortran for the same construct.
Language Extensions: where VMS Fortran supports facilities which are not supported at all by modern compilers.
Semantic Differences: where a VMS Fortran statement has the same syntax as a standard Fortran statement, but compiles with a different meaning.
The VMS System Libraries: The system library routines used in a program must be emulated. Often the call-sites must be modified to change the way in which the arguments are passed.

The syntactic and semantic differences are all handled automatically by VX/FPT. The VMS system libraries, and many of the language extensions are handled by VMS emulation libraries. These libraries provide a very complete emulation of VMS under Linux or Unix.

What does VX/FORTRAN convert, and what does it produce?

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.

What are the stages of the VX/FORTRAN migration workflow?

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.

How does VX/FORTRAN migrate VMS file handling?

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.

What happens to embedded Pro*FORTRAN SQL during migration?

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.

How much faster is the migrated code, and where does the speed come from?

Execution time can improve by up to 40 percent. The gains come from optimizations applied during migration: inline expansion of subroutines and statement functions to remove call overhead, loop unrolling, and memory-access optimizations.

What kinds of code-quality problems does the static analysis catch?

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

Can we keep developing on OpenVMS while the migration is underway?

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.

Does VX/FORTRAN require manual code changes, and can it protect our source?

Migration is 100 percent automated with no manual remediation required. For sites that need it, VX/FORTRAN can also apply security and obfuscation to protect the source code while ensuring it remains compilable.

Transform Your Legacy Software Today!

Get In Touch

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