NOTICE: 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

Summary

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.

1. Introduction

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 strongly encouraged.

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

	Arithmetic IF
	DO loops with real indices
	Assigned GOTO and assigned formats
	Branching to an END IF statement
	Alternate RETURN
	PAUSE statement
	H edit descriptor

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 standard.]

(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 results.]

(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 standard.]

(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 standard-compliant alternatives.]

(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 comment.]

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.
  
• 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 systems.
  
• 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 process.
  
• 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

• 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.
  

• 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).

*+SX_FITLIN

        SUBROUTINE
SX_FITLIN(X,Y,SIGMAY,NPTS,MODE,A,SIGMAA,B,SIGMAB,R)
        INTEGER NPTS, MODE
        REAL X(NPTS), Y(NPTS), SIGMAY(NPTS)	
        REAL A, SIGMAA, B, SIGMAB, R			 
C 
C	Description: 
C	Fits straight line Y = A + B*X by least squares.  
C 
C	Arguments: 
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 
C	Origin: 
C	Algorithm LINFIT by  Bevington, but adapted to 	
C							
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	...
C	Allyn Tennant   (1992 Sep 14), improved comments.  
*- Version 2.3.2

5. Conclusion

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.

References

"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 Press.

Proceed to the next article

Return to the previous article

Select another article