This Legacy journal article was published in Volume 3, May 1993, and has not been
updated since publication. Please use the search facility above to find regularly-updated information about
this topic elsewhere on the HEASARC site.
OGIP Fortran Standards
GSFC ASCA GOF
This article contains the current philosophy regarding use of Fortran in Office
for Guest Investigator Programs (OGIP) programs. For some libraries created
for widespread use, sometimes beyond the confines of X-ray astronomy, we will
enforce strict conformance to the Fortran 77 standard. For others, we take a
more pragmatic approach and allow certain widespread extensions. These
extensions are listed, together with some explanations. Also listed are the
recommended format for prolog comments.
We at the OGIP are collecting, developing and distributing Fortran programs for
use on a variety of platforms; the use of Fortran rather than, e.g., C, is a
fact of life at OGIP, and will not be discussed in this article.
Recently we felt the need for an explicit statement of a group-wide policy
regarding the programming practices. Particularly contentious was the issue of
ANSI FORTRAN 77 standard, which is widely regarded as too restrictive in many
respects. In addition, there is an area which is not covered by language
standards and show Operating System dependent behaviors; we have attempted to
establish a guideline for OGIP programmers in this regard. Also discussed was
a uniform style of prolog comments for program modules.
In the rest of this section, some general issues are discussed.
1.1. Portability Requirements
Portability is naturally a major concern for any software that are intended for
widespread use. This suggests strict conformance to the existing standard as a
possible course of action: FORTRAN 77 (ANSI X3.9-1978) is the last standard
that is currently widely supported (see section 1.2 for comments on Fortran
90). On the other hand, there are many extensions to FORTRAN 77 that make
software more useful, easier to write or easier to maintain. Moreover, we
often make use of, or modify, existing codes that do not conform to the FORTRAN
77 standard either by choice or by necessity; in many such cases, rewriting the
existing code is not a viable option, at least not in the short term.
Commonly used extensions are available, not surprisingly, on platforms that are
popular among X-ray astronomers. We have therefore decided to relax the
portability requirements for some of our software; these can use extensions
that are available on VMS VAXes and unix workstations (sometimes via the
Fortran to C converter/compiler, f2c). Software written to this standard may
not run on IBM mainframes, PCs and Crays, for example, without some work; we
judge the impact of this restriction is not particularly severe. For other
software, we may still demand a strict conformance to the FORTRAN 77 standards.
In either case, all system dependent (i.e., non-portable) part of the code must
be carefully isolated into a small set of subroutines.
Many compilers which allow extensions have a built-in switch that turn off, or
issue warnings about, all the compiler-specific extensions. There are also
utility programs that can perform a similar function. Use of these are
1.2. Fortran 90
Fortran 90 (ISO 1539:1991 and X3.198-1992) is the new international standard of
the language, containing many advanced features. All the widely supported
extensions are in the new standard. It is backward compatible although certain
features of the language are marked "obsolescent"; these may be deleted in the
next standard after Fortran 90, an added incentive for programmers not to use
them (only those features widely regarded as bad are in this list).
Obsolescent FORTRAN 77 Features
DO loops with real indices
Assigned GOTO and assigned formats
Branching to an END IF statement
H edit descriptor
In the mean time, those obsolescent features should not be used in OGIP
There are already some Fortran 90 compilers in market, and major vendors
(including DEC and Sun) have publicly stated their intention to support this
language in the near future. It is likely that, once supporting compilers
become widely available, new OGIP Fortran software will use the capabilities of
the new standard, making this document (among others) obsolescent.
2. ANSI Standard FORTRAN 77 and OGIP Extensions
2.1. General Portability Requirement
We do allow a very limited number of extensions even for programs that are
meant to be generally portable. A prominent example that meets this
requirement is the FITSIO package.
(i) Both upper and lower case letters can be used. However, the programmer
must assume that the compiler is not case sensitive, and enforce this with a
compiler switch if necessary.
[According to the standard, only upper case letters are allowed. However, this
is rarely enforced by compilers and leads to hard-to-read codes.]
(ii) END DOs are allowed.
[This is recognized by all major compilers, is in the new standard, and
conversion to old style DO loops can be done automatically.]
(iii) DO WHILE loops are allowed.
[This feature is also present in most compilers and in Fortran 90.]
(iv) INCLUDE statements are allowed.
[INCLUDEs are useful for keeping common blocks and parameters in one central
location, and are recognized by all major compilers. Note, however, that any
directory specification can lead to awkward non-portability problems.]
(v) Data type INTEGER*2 is allowed when it is essential.
2.2. Reduced Portability Requirement
For many OGIP Fortran products, we allow the following extensions in addition
to those listed in section 2.1. These features are common to VMS Fortran, Sun
Fortran, DEC Fortran and f2c.
(vi) Variable, module and common block names up to 31 character long,
including underscores, are allowed.
[Most unix and VMS workstations support such extensions, although this may make
programs unportable to certain machines. This also is the Fortran 90
(vii) IMPLICIT NONE is allowed.
[This is now accepted by all major compilers (some old versions of Sun compiler
did not) and is in the Fortran 90 standard. It is relatively easy to remove
this, once the development is completed.]
2.3. Examples of disallowed extensions
We have found some wide-spread extensions to be more detrimental to portability
than others. Some prominent examples follow.
(i) Lines longer than 72 characters
[Many compilers do have options to extend lines, but not all; if they do, they
either rely on non-standard instruction within the code (VMS Fortran) or a
compiler switch, both of which are less than ideal for portability. Improperly
recognized long lines can lead to cryptic error messages and unexpected
(ii) Use of TABs in places of SPACEs, except as a part of a character string
[Most compilers do accept TABs, but this practice can lead to problems,
particularly in combination with the 72-character rule of the Fortran
(iii) Structures and other non-standard data types
[Except for INTEGER*2, non-standard data types can curtail portability, yet
sometimes they are unavoidable.]
(iv) String concatenation requiring dynamic memory allocation
[There are certain restrictions on operations that can be performed on dummy
character string arguments declared as CHARACTER*(*). There usually are
(v) Common block with numeric variables and character strings
[Some compilers do not allow this. There may be a penalty in performance with
compilers that do allow it.]
(vi) Free-format read in internal I/O
[Works with most compilers.]
(vii) Inline comments
[Statements followed by "!" and comments are highly useful and are therefore
supported in Fortran 90; however, not all compilers recognize this form of
3. VAX/VMS/DCL vs. Sun/unix/c-shell
In addition to the difference among Fortran compilers, features of the
operating systems and command languages play a major role in determining which
program is portable and which is not. This section summarizes some of the
differences between VAX/VMS/DCL and Sun/unix/c-shell that Fortran programmers
should be aware of.
3.1. File systems
- unix file names are case-sensitive; VMS ones are not.
- Device and directory specification syntax is rather different.
- unix has few rules about file names; unix programmers often use file names
with multiple "." in them, which would prevent the program from running under
- VMS has the concept of file version numbers; unix does not.
- Under VMS, OPEN with "STATUS='NEW'" will create a new version if file with
the given name already exists; it leads to a crash under unix.
- Under VMS, OPEN with "STATUS='OLD'" will result in an error if the named file
does not exist; under unix, an empty file will be created by this command,
although any subsequent "READ" command is likely to result in an error.
- VMS has a vigorous system of file attributes; you cannot use direct access on
sequential access files or vice versa. There is no such restrictions on unix
- Under unix, Fortran unformatted files are usually implemented by adding
4-byte integers before and after a record representing the number of bytes in
it. Thus, even though you can mix direct and sequential access under unix,
that could lead to errors (or very unix dependent code).
- Under VMS, the easiest way to allow simultaneous access to a file by multiple
processes is to open it with a "READONLY" keyword (otherwise, the first process
that opens the file will lock it). This is a non-standard keyword. Under
unix, this is not the case but the onus is on the programmer to avoid nasty
results due to one process reading a file while it is being modified by another
- Fortran standard does not specify where the pointer should be when an
existing file is opened. In many systems including VAXes and Sun workstations,
it is at the beginning of the file. The non-standard keyword "ACCESS='APPEND'"
works on both these systems to put the pointer at the end of the file, but
there is no standard-conforming way to achieve this.
- Fortran carriage control is not implemented on unix systems, although a
subset of this feature can be used by opening the file (or even the terminal)
with a "FORM='PRINT'" qualifier. On VMS, Fortran carriage control is the
default, which can be overridden with a "CARRIAGECONTROL='LIST'" qualifier.
Both these qualifiers are non-standard.
- Fortran standard specifies that you can open 64 files from a program at any
given time; unix includes the standard input, output and error in this
calculation thus 61 other files can be opened by default. On the Sun
workstations, it is possible to extend this to 256 total files, however. On
VMS, there is a separate limit imposed by the process quota; this can be
changed only with a SYSTEM privilege.
- Under VMS, file names can be specified using logical names; no comparable
method exists under unix/c-shell, although environment variables can be
expanded using a system call.
- "Using tape files on a SunOS or unix systems is awkward because,
historically, unix development was oriented toward small data sets residing on
fast disks. Magnetic tape was used by early unix systems for archival storage
storage and moving data between different machines. Unfortunately, many
FORTRAN programs are intended to use large data sets from magnetic tape." --
from Sun Fortran User's Manual. Sun provides a Fortran tape I/O package,
which, by their own admission, offers only a partial solution and the manual
actually discourages its use. It would also be non-standard.
Thus any use of files will make programs OS-specific. The XANLIB library
contains various low-level routines that enables application programs to be
written in a portable way, which OGIP programmers are encouraged to use.
Isolation of all such OS-dependent calls is a good programming practice
regardless of specific libraries used.
3.2. Data representations
3.3. Other issues
- Byte order: On VAXes and 80x86 chips, the least significant byte comes first.
On SPARC, 680x0 and IBM mainframes, the most significant byte comes first.
MIPS chips can be configured either way.
- Internal representation of characters, logicals, integers and reals vary from
system to system.
- IEEE arithmetic, which is becoming more widespread, can behave in a
counter-intuitive (for a Fortran programmer) way, concealing where division by
0, for example, occurred within a program.
4. Prolog Comments
- Under unix, a backslash "\" has a special meaning, which even applies to
character strings within a Fortran program. Use of backslashes should be
avoided, if at all possible.
- Under VMS, each process has a set of "quotas", limits on various system
resources that the process can use; try "SHOW PROCESS/QUOTAS" for details.
This can cause incompatibility problems among VMS machines that are configured
differently. Under unix, these limits are typically hard-wired or
non-existent; excessive use of system resources under unix typically hangs up
the machine rather than stopping the program with an error condition.
- Under VMS, there is a limit on the size of a line that can be written out
free-format. This is 128 characters by default.
The following example of prolog comments is provided to encourage a uniform
style of comment and to allow automatic extraction ("*+" and "*-" marks the
beginning and end of prolog).
INTEGER NPTS, MODE
REAL X(NPTS), Y(NPTS), SIGMAY(NPTS)
REAL A, SIGMAA, B, SIGMAB, R
C Fits straight line Y = A + B*X by least squares.
C NPTS (i) : No. of data pts in X,Y,SIGMAY, must be >2.
C X(NPTS) (i) : Array of independent variables
C Y(NPTS) (i) : Array of dependent variables
C SIGMAY(NPTS) (i) : Array of Std Errors on Y (only used if MODE=1)
C MODE (i) : Data weighting mode.....
C -1 for WEIGHT = 1/ABS(Y) i.e. Poission errors
C 0 for WEIGHT = 0.0 i.e. all points same weight.
C 1 for WEIGHT = 1/SIGMAY**2 i.e. user-supplied errors.
C A (io): Intercept on X=0 line
C SIGMAA (o): Std error in A assuming Gaussian error distribution.
C B (o): Slope of line
C SIGMAB (o): Std error in B assuming Gaussian error distribution.
C R (o): Correlation coeff between X and Y
C Algorithm LINFIT by Bevington, but adapted to
C Authors/Modification History:
C Ian M George (1989 April 28), original version
C Allyn F Tennant (1992 Aug 01), minor bugs corrected
C Nick White (1992 Sept 03), MODE=-1 added to handle
C Allyn Tennant (1992 Sep 14), improved comments.
*- Version 2.3.2
This is part of our on-going effort to make things easier for ourselves. We
welcome comments, particularly from people who routinely use computers other
than VAXes, DECstations and Sun workstations.
"Starlink Application Programming Standard" by P.T. Wallace, 1992, Starlink
General Paper SGP 16.10.
"Fortran 90 Explained" by M. Metcalf, M. & J. Reid, 1990, Oxford University
Proceed to the next article
Return to the previous article
Select another article
HEASARC Home |
Last modified: Monday, 19-Jun-2006 11:40:52 EDT