Migrating Fortran from VMS

top_left_banner SimCon logo

Migrating/Porting Fortran from VMS

You have half a million lines of VMS Fortran which has to go to Linux, Unix or Windows. A trial compilation on the new host was disastrous. What are the problems, and how can you deal with them?

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 fpt. The VMS system libraries, and many of the language extensions are handled by Sector7's VMS emulation libraries. These libraries provide a very complete emulation of VMS under Linux or Unix.

Assessing Your Code

The list of potential problems shown below is alarming. But all of the language issues can be dealt with by fpt and all of the VMS library routines can be supplied by Sector7. To assess the code, build an fpt project as described here (Contact SimCon to arrange a temporary licence for this for which there is no charge).

The important decisions are:

Do you need the Sector7 libraries? Use the command show missing sub-programs. If you see large numbers of routines with names which begin, for example, SYS$, LIB$ or SMG$ then you almost certainly do.
Do you need fpt? Use the command check arguments. Check the list of diagnostics at the end of the listing file for warnings related to the language issues described below. If you need the Sector7 libraries, or if you have large numbers of real mis-matched arguments or other language issues you probably need fpt.
Do you want to carry out the migration or would you like Sector7 and SimCon to do it for you? Sector7 and SimCon have worked together on VMS migrations for almost 20 years. We have successfully migrated many million lines of code. We can carry out the migration or we can advise and support your own migration project.

Issues in VMS Fortran Migration

Syntactic Differences

These are cases where VMS simply uses a different syntax for a construct which is supported in standard Fortran. The problem is that the code will simply not compile on the new host. All known issues are fixed automatically by fpt. The important cases include:

Source Code Layout: VMS Fortran is written in fixed format and sometimes the line length is extended to 132 characters. This is not a problem: most modern compilers allow this. However, VMS Fortran also accepts a fixed format in which a continuation line was written as 0 to 4 spaces followed by a tab character and a numeric continuation character. Some modern compilers (e.g. ifort, CVF and HP-UX) accept this. Some (e.g. gfortran and FTN95) do not and will simply issue an error message. Also, under VMS, tab characters always count as 1 column wide. Under other compilers the tab character may count as the number of columns to the next tab stop. This moves code into the comment field at the end of the fixed format line. The treatment of tab format code and tabs under VMS is shown here. fpt converts the code to standard fixed or free format.
$ Characters in Variable Names: Most modern compilers allow $ characters in variable names as an extension, but some do not. fpt edits user-written symbols automatically to replace them. The fpt command is edit symbol names.
File Names in INCLUDE Statements: VMS file names are not case sensitive. Unix and Linus file names are. Also, VMS file names may contains logical names and device and directory specifications in VMS format. fpt recognises logical names. It can systematically change the upper and lower case spelling of file names, it can ignore directory specifications or edit them on-the-fly to conform to the file syntax of the new host. The facilities are described here.
VMS PARAMETER Statements Without Parentheses: VMS Fortran PARAMETER statements may be written without parentheses. The data type of the parameter is then determined by the data type of the parameter value, not by the current IMPLICIT rules or by prior data type declarations. A large number of INCLUDE files are provided under VMS to define constants used in the system libraries, and all of the PARAMETER statements in these files are written in this format. The format is also common in user-written legacy VMS code. These parameter statements are not usually supported by Linux, Unix or Windows compilers and must be converted as shown here.
VMS-specific Intrinsic Functions: VMS supports many non-standard intrinsic function names which are type-specific and kind-specific versions of the standard intrinsic functions in modern Fortran. These may be translated automatically by fpt. See change intrinsic in the fpt reference manual.
The BYTE data type: VMS uses the keyword BYTE for declaration of 8-bit integers. Some compilers (e.g. FTN95) require INTEGER(KIND=1) or INTEGER*1 instead. fpt makes the change automatically. See change byte to integer*1 in the fpt reference manual.
Octal and Hex Number Formats: VMS supports octal and hexadecimal number formats which are not supported in standard Fortran. fpt makes the conversions automatically. The issue is described here.

There are other, less common syntactic problems, for example, direct access record specifications of the form READ(iunit'irec) or $ used instead of * for label formal arguments. All known cases are translated by fpt.

Features which are Not Supported by the New Host

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. The changes are shown here
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's VXRMS library. The translations are described here.
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, as shown here.

Semantic Differences - Statements which Compile Differently

These are are constructs which compile under VMS but compile with a different meaning on the new host. They are faux amis. They compile. They look correct, but they don't behave as you might expect. They cause the worst kind of error - an unpredictable failure ar tun-time.

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 as described here.
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 as described here.
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. fpt re-programs the construct as described here.
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 as described here.

The VMS System Libraries

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 Inc. has developed a very complete emulation of these libraries for Linux and Unix. Sector7's 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. The issue is described here.