An VMS / OpenVMS Fortran code may contain many tens of years of software investment. If this investment is to be preserved the code must be converted to run on modern hardware under modern compilers. VX/FPT and Sector7's system service library, VX/RT, make this conversion. The authors of VMS / OpenVMS Fortran made many extensions to Fortran 77 and these extensions provided important facilities which were missing from the language at that time. Some of these extensions were incorporated into Fortran 90. Some do not conflict with Fortran 90 and are supported by modern compilers. But some are incompatible with modern Fortran and either do not compile at all, or generate errors at run-time. VX/RT re-engineers the code to translate these features to modern Fortran. Examples are described in the panels which follow. VMS / OpenVMS Fortran also accessed extensive support libraries for system tasks such as inter-process communication and form and screen handling. Sector7 has developed more than 900 VMS / OpenVMS system service calls (VX/RT API's) for Linux/Windows.

VX/Fortran automatically converts the names and directories used in INCLUDE statements in the code to Linux and Windows format. The file names written in OPEN and INQUIRE statements are wrapped in calls to VX/RT routines which change the file name and directory formats at run-time. File names in sub-program arguments may optionally be handled in the same way. VMS Fortran supports ISAM (Indexed Sequential Access Method) files. Additional keywords are added to the OPEN, READ, WRITE and INQUIRE statements to specify the file organization, the access keys and the links to be followed. However, ISAM files are not supported by any modern Fortran system. Sector7's VX/RT library provides subroutines and functions which support ISAM files. VX/FPT automatically converts all OPEN, READ, WRITE and INQUIRE statements for ISAM files to calls to these routines.

VMS Fortran may contain embedded SQL database code supported by Oracle Pro*Fortran™ The code is pre-processed by the Oracle's PROFOR pre-processor before compilation by the VMS Fortran compiler. However, the PROFOR pre-processor is no longer supported by Oracle and is not compatible with modern Fortran. In particular, it generates illegal code when Fortran 90 modules are present. If PROFOR is used for the migrated code, the code is trapped in an obsolete style and the advances in Fortran programming made in Fortran 90 and later are not available. Sector7's pf2pc pre-processor copies the embedded SQL code into new C routines, and inserts calls to the C routines into the Fortran. VX/Fortran may then be used to complete the migration

VX/Fortran supports the creation of acceptance tests, and of a testing environment which may be used to identify defects. Q.A. Analysis: VX/Fortran analyses the source code and identifies many classes of programming error likely to cause problems in migration. Record/Replay: VX/Fortran captures, and then replays from file, all keystrokes, file I/O and data at chosen sub-program interfaces. A long testing session may then be replayed by a single command. Run-time Trace: The result of every computation in a run is captured to file. The run is then repeated on the migration host, comparing every value computed with that in the file. Coverage Analysis: VX/VX/Fortran measures how often each executable statement is visited during a test procedure. Entry/Exit Monitor: The entry to and exit from every routine is logged to shared memory which is available to an independent program. It is therefore available even if the main process crashes.

VMS Fortran is written in fixed format. The first 5 printing columns are reserved for the statement label. Column 6 (Or the column after a tab character) is the continuation line marker, and the remainder of the line up to column 72 (or optionally column 132) contains the code. This is now considered to be archaic. Modern Fortran is usually written in free format, where no columns are reserved for specific uses. Similarly, VMS Fortran used the Fortran 77 dot-delimited relational operators, .EQ., .NE., .GT., .GE. etc. Modern practice is to use symbolic operators, ==, /=, >, >= etc.

The conversion to a modern style in these, and in many other respects may be made automatically by VX/FPT. This is partly an issue in staff training, retention and morale. It may be difficult to motivate staff to spend time on code and coding practices which they perceive to be obsolete.

The documentation is available on-line. The Tutorial Guide provides an introduction for the user's first use of Fortran on his or her own programs. The Reference Manual contains the installation procedures, and a detailed description of all VX/Fortran commands. The User's Guide describes how VX/Fortran may be used to achieve specific objectives, such as QA auditing and migration of code between platforms.

File names in OPEN and INQUIRE statements: VMS:

Migrated code:

OPEN of an Indexed Sequential (ISAM) file: VMS:

Migrated code (Note the conversion to free format):

READ of an Indexed Sequential (ISAM) file: VMS:

System library call with missing arguments: VMS:

Migrated code:

Unsafe execution order

(The array la has bounds (1:3) ): VMS:

Migrated code (The original crashes under ifort when i == 1) :

Testing - Tracing execution - VMS:

Migrated code:

VX/Fortran carries out in-line expansion of subroutines and functions, and unwinds DO loops, to optimise code for speed of execution. The effects of the optimisations depend on the host architecture. There are trade-offs between processor speed, memory speed and instruction cache size. Run times are typically improved by 20% to 40%, and by as much as a factor of two or more on high performance processors inhibited by memory speed.

Sub-program calls may interfere seriously with compiler optimisations. For example:

In this example 'ALPH' is an array and the indices, 'I1', 'I2', 'I3' and 'CELL' are variables in a COMMON block. The compiler must generate code to re compute the indexed address within 'ALPH' in case the COMMON block variables are modified during the call to the function 'INTERP1'. When 'INTERP1' is expanded in-line the memory address of the array element can be saved in a register for re use.

VX/Fortran comments the changes that it makes in the expanded code, so that it remains readable for debugging. The linear interpolation function, 'INTERP1' called in the example above is:

REAL*4 FUNCTION INTERP1(INPUT,BP,FUNTAB)
REAL*4 INPUT
REAL*4 BP(*)
REAL*4 FUNTAB(*)
I=1
DO WHILE (BP(I) .LT. INPUT)
  I=I+1
ENDDO
INTERP1=FUNTAB(I-1)+(FUNTAB(I)-FUNTAB(I-1))*
  1 (INPUT-BP(I-1))/(BP(I)-BP(I-1))
RETURN
END

VX/Fortran expands the call to read:

R=R0+ALPH(I1,I2,I3,CELL)

C
C  FR=INTERP1(TYRESPEED,TYREVBP,TYREFRICT)
C
I=1
DO WHILE (TYREVBP(I) .LT. TYRESPEED)
  I=I+1
ENDDO
INTERP1_VAL=TYREFRICT(I-1)+(TYREFRICT(I)- 
    TYREFRICT(I-1))*
1 (TYRESPEED-TYREVBP(I-1))/(TYREVBP(I)-TYREVBP(I-1))
C  RETURN INTERP1
C
FR=INTERP1_VAL
C
ALPH(I1,I2,I3,CELL)=FR*T0

Note that the modified code is marked by bars across the text, and the original statement, the assignment of 'FR', remains in place but is commented-out. The formal arguments in the function have been replaced by the actual arguments to the call.

In this example, there was no variable named 'I' in the scope of the expanded statement, so the name of the variable 'I' in the function was retained. Variables are renamed if name clashes occur. Declarations of variables used in the expansion are inserted in the routines which require them, and they are moved to COMMON blocks if they have a SAVE attribute or are SAVED by default.

In-line expansion may be carried out quickly and easily, and it is recommended that users maintain code in unexpanded form. VX/Fortran may therefore be used to resolve a common conflict in the maintenance of large programs. It is good practice to encapsulate small, frequently used operations, such as accesses to data structures, in subroutines or functions. Maintenance changes are then made in only one place. However, a large number of sub-program calls slow down program execution.

With VX/Fortran, users may choose to encapsulate primitive operations and to expand the calls in-line before the release of production code.

In-line expansion and loop unwinding are controlled by the VX/Fortran commands Expand inline and Unwind marked loops. The commands Inline and Unwind are written in the code to mark candidate routines and loops for expansion.

VX/Fortran identifies errors and inconsistencies in Fortran code (Please see Quality Assurance ). It may be used to correct some classes of error automatically. The most important corrections are to sub-program arguments. Consider the function call:

The function BOUND is a limiter, which is used to keep the input to ACOS within the range zero to one. It is coded as:

FUNCTION BOUND( LOW, INPUT, HIGH )
    REAL LOW,INPUT,HIGH
    BOUND = MIN ( HIGH, MAX ( LOW, INPUT ) )
RETURN
END
            

The problem is that all three arguments to BOUND should be real, but BOUND has been called with the arguments integer 0, real HDOT/V and integer 1. The integer value of zero is unlikely to cause a problem. Most systems treat integer zero as equivalent to real zero. The integer 1 will usually cause an error.

The VX/Fortran command to correct problems like this is " Correct inconsistent arguments ". VX/Fortran checks all arguments in the entire program. Corrections are made by re-writing the arguments or by inserting calls to intrinsic functions (e.g. REAL(), DBLE(), INT() etc.). Inconsistent arguments which cannot be corrected are marked by diagnostics.

ALPHA = ACOS ( BOUND ( 0, HDOT / V, 1 ) )

The call above is re-written as:

ALPHA = ACOS ( BOUND ( 0.0, HDOT / V, 1.0 ) )

A large Fortran program has many authors and a lifetime of many years. Code is inherited from other projects. Differences in style, in management and in the available programming tools lead to the creation of a dusty deck. The indentations may no longer represent the control structures; to find all the assignments of 'THETA' you may need to search for

VX/Fortran makes maintenance of such code manageable.

VX/Fortran automatically reformats source code to a consistent set of standards requested by the user. It deals with indentations, adds or removes spaces before and after tokens, checks line lengths, allows specifications of upper or lower case keywords and variables. It changes the format of real numbers, handles continuation lines, deals with the renumbering of statement labels and with many other issues to make life easier for the Fortran programmer. It also contains a language sensitive editor which allows Fortran identifiers to be renamed systematically. Each user works in his or her own coding style, and the code is reformatted to a company standard before release.

The same reformatting features may also be used to make code unmaintainable - to protect source code by removing the comments and encrypting the variable names, making it unintelligible to others. This has proved useful in situations where sensitive code is handed over to third parties in a compilable form (Please see Security ).