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?
The issues in migrating from VMS are:
Syntactic Differences: where VMS Fortran simply uses a different syntax from standard Fortran for the same
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.
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.
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
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.
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
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
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
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
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
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
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
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