HP OpenVMS Systems Documentation

Content starts here

HP Fortran for OpenVMS
Language Reference Manual


Previous Contents Index

15.5.3.2 Array Association

A nonpointer array occupies a sequence of contiguous storage sequences, one for each array element, in array element order.

Two or more arrays are associated when each one is associated with the same storage location. They are partially associated when part of the storage associated with one array is the same as part or all of the storage associated with another array.

If arrays with different data types are associated (or partially associated) with the same storage location, and the value of one array is defined (for example, by assignment), the value of the other array becomes undefined. This happens because an element of an array is considered defined only if the storage associated with it contains data of the same type as the array name.

An array element, array section, or whole array is defined by a DATA statement before program execution. (The array properties must be declared in a previous specification statement.) During program execution, array elements and sections are defined by an assignment or input statement, and entire arrays are defined by input statements.

For More Information:


Appendix A
Deleted and Obsolescent Language Features

This appendix describes deleted and obsolescent language features.

Fortran 90 identified certain FORTRAN 77 features to be obsolescent. Fortran 95 deleted some of these features, and identified a few more language features to be obsolescent. Features considered obsolescent might be removed from future revisions of the Fortran Standard.

You can specify a compiler option to have these features flagged.

Note

HP Fortran fully supports features deleted from Fortran 95.

A.1 Deleted Language Features in Fortran 95

Some language features, considered redundant in FORTRAN 77, are not included in Fortran 95. However, they are still fully supported by HP Fortran:

  • ASSIGN and assigned GO TO statements
  • Assigned FORMAT specifier
  • Branching to an END IF statement from outside its IF block
  • H edit descriptor
  • PAUSE statement
  • Real and double precision DO control variables and DO loop control expressions

For suggested methods to achieve the functionality of these features, see Section A.3.

A.2 Obsolescent Language Features in Fortran 95

Some language features considered redundant in Fortran 90 are identified as obsolescent in Fortran 95.

Other methods are suggested to achieve the functionality of the following obsolescent features:

  • Alternate returns
    To replace this functionality, it is recommended that you use an integer variable to return a value to the calling program, and let the calling program use a CASE construct to test the value and perform operations (see Section 7.4).
  • Arithmetic IF
    To replace this functionality, it is recommended that you use an IF statement or construct (see Section 7.8).
  • Assumed-length character functions
    To replace this functionality, it is recommended that you use one of the following:
    • An automatic character-length function, where the length of the function result is declared in a specification expression
    • A subroutine whose arguments correspond to the function result and the function arguments

    Dummy arguments of a function can still have assumed character length; this feature is not obsolescent.
  • CHARACTER*(*) form of CHARACTER declaration
    To replace this functionality, it is recommended that you use the Fortran 90 forms of specifying a length selector in CHARACTER declarations (see Section 5.1.2).
  • Computed GO TO statement
    To replace this functionality, it is recommended that you use a CASE construct (see Section 7.4).

  • DATA statements among executable statements
    This functionality has been included since FORTRAN 66, but is considered to be a potential source of errors.
  • Fixed source form
    Newer methods of entering data have made this source form obsolescent and error-prone.
    The recommended method for coding is to use free source form (see Section 2.3.1).
  • Shared DO termination and termination on a statement other than END DO or CONTINUE
    To replace this functionality, it is recommended that you use an END DO statement (see Section 7.6.1) or a CONTINUE statement (see Section 7.5).
  • Statement functions
    To replace this functionality, it is recommended that you use an internal function (see Section 8.7).

A.3 Obsolescent Language Features in Fortran 90

Fortran 90 did not delete any of the features in FORTRAN 77, but some FORTRAN 77 features were identified as obsolescent.

Other methods are suggested to achieve the functionality of the following obsolescent features:

  • Alternate return (labels in an argument list)
    To replace this functionality, it is recommended that you use an integer variable to return a value to the calling program, and let the calling program test the value and perform operations, using a computed GO TO statement (see Section 7.2.2) or CASE construct (see Section 7.4).
  • Arithmetic IF
    To replace this functionality, it is recommended that you use an IF statement or construct (see Section 7.8).

  • ASSIGN and assigned GO TO statements
    These statements are usually used to simulate internal procedures (see Section 8.7), which can now be coded directly.
  • Assigned FORMAT specifier (label of a FORMAT statement assigned to an integer variable)
    To replace this functionality, it is recommended that you use character expressions to define format specifications (see Section 11.2).
  • Branching to an END IF statement from outside its IF block
    To replace this functionality, it is recommended that you branch to the statement following the END IF statement (see Section 7.8.1).
  • H edit descriptor
    To replace this functionality, it is recommended that you use the character constant edit descriptor (see Section 11.5).
  • PAUSE statement
    To replace this functionality, it is recommended that you use a READ statement that awaits input data (see Section 10.3).
  • Real and double precision DO control variables and DO loop control expressions
    To replace this functionality, it is recommended that you use integer DO variables and expressions (see Section 7.6).
  • Shared DO termination and termination on a statement other than END DO or CONTINUE
    To replace this functionality, it is recommended that you use an END DO statement (see Section 7.6.1) or a CONTINUE statement (see Section 7.5).


Appendix B
Additional Language Features

This appendix describes additional language features provided by HP Fortran to facilitate compatibility with older versions of Fortran.

Note

These language features are particularly useful in porting older Fortran programs to Fortran 95/90. However, you should avoid using them in new programs, especially new programs for which portability to other Fortran 95/90 implementations is important.

B.1 DEFINE FILE Statement

The DEFINE FILE statement establishes the size and structure of files with relative organization and associates them with a logical unit number. The DEFINE FILE statement is comparable to the OPEN statement. In situations where you can use the OPEN statement, OPEN is the preferable mechanism for creating and opening files.

The DEFINE FILE statement takes the following form:


  • DEFINE FILE u(m, n, U, asv) [,u(m, n, U, asv)]...

u

Is a scalar integer constant or variable that specifies the logical unit number.

m

Is a scalar integer constant or variable that specifies the number of records in the file.

n

Is a scalar integer constant or variable that specifies the length of each record in 16-bit words (2 bytes).

U

Specifies that the file is unformatted (binary); this is the only acceptable entry in this position.

asv

Is a scalar integer variable, called the associated variable of the file. At the end of each direct access I/O operation, the record number of the next higher numbered record in the file is assigned to asv. The asv must not be a dummy argument.

Rules and Behavior

The DEFINE FILE statement specifies that a file containing m fixed-length records, each composed of n 16-bit words, exists (or will exist) on the specified logical unit. The records in the file are numbered sequentially from 1 through m.

A DEFINE FILE statement does not itself open a file. However, the statement must be executed before the first direct access I/O statement referring to the specified file. The file is opened when the I/O statement is executed.

If this I/O statement is a WRITE statement, a direct access sequential file is opened, or created if necessary.

If the I/O statement is a READ or FIND statement, an existing file is opened, unless the specified file does not exist. If a file does not exist, an error occurs.

The DEFINE FILE statement establishes the variable asv as the associated variable of a file. At the end of each direct access I/O operation, the Fortran I/O system places in asv the record number of the record immediately following the one just read or written.

The associated variable always points to the next sequential record in the file (unless the associated variable is redefined by an assignment, input, or FIND statement). So, direct access I/O statements can perform sequential processing on the file by using the associated variable of the file as the record number specifier.

Examples

In the following example, the DEFINE FILE statement specifies that the logical unit 3 is to be connected to a file of 1000 fixed-length records; each record is 48 16-bit words long. The records are numbered sequentially from 1 through 1000 and are unformatted. After each direct access I/O operation on this file, the integer variable NREC will contain the record number of the record immediately following the record just processed.


DEFINE FILE 3(1000,48,U,NREC)

B.2 ENCODE and DECODE Statements

The ENCODE and DECODE statements translate data and transfer it between variables or arrays in internal storage. The ENCODE statement translates data from internal (binary) form to character form; the DECODE statement translates data from character to internal form. These statements are comparable to using internal files in formatted sequential WRITE and READ statements, respectively.

The ENCODE and DECODE statements take the following forms:


  • ENCODE (c,f,b [,IOSTAT=i-var] [,ERR=label]) [io-list]
  • DECODE (c,f,b [,IOSTAT=i-var] [,ERR=label]) [io-list]

c

Is a scalar integer expression. In the ENCODE statement, c is the number of characters (in bytes) to be translated to character form. In the DECODE statement, c is the number of characters to be translated to internal form.

f

Is a format identifier. An error occurs if more than one record is specified.

b

Is a scalar or array reference. If b is an array reference, its elements are processed in the order of subscript progression.

In the ENCODE statement, b receives the characters after translation to external form. If less than c characters are received, the remaining character positions are filled with blank characters. In the DECODE statement, b contains the characters to be translated to internal form.

i-var

Is a scalar integer variable that is defined as a positive integer if an error occurs and as zero if no error occurs (see Section 10.2.1.7).

label

Is the label of an executable statement that receives control if an error occurs.

io-list

Is an I/O list (see Section 10.2.2).

In the ENCODE statement, the list contains the data to be translated to character form. In the DECODE statement, the list receives the data after translation to internal form.

The interaction between the format specifier and the I/O list is the same as for a formatted I/O statement.

Rules and Behavior

The number of characters that the ENCODE or DECODE statement can translate depends on the data type of b. For example, an INTEGER (2) array can contain two characters per element, so that the maximum number of characters is twice the number of elements in that array.

The maximum number of characters a character variable or character array element can contain is the length of the character variable or character array element.

The maximum number of characters a character array can contain is the length of each element multiplied by the number of elements.

Examples

In the following example, the DECODE statement translates the 12 characters in A to integer form (as specified by the FORMAT statement):


     DIMENSION K(3)
     CHARACTER*12 A,B
     DATA A/'123456789012'/
     DECODE(12,100,A) K
100  FORMAT(3I4)
     ENCODE(12,100,B) K(3), K(2), K(1)

The 12 characters are stored in array K:


K(1) = 1234
K(2) = 5678
K(3) = 9012

The ENCODE statement translates the values K(3), K(2), and K(1) to character form and stores the characters in the character variable B:


B = '901256781234'

For More Information:

B.3 FIND Statement

The FIND statement positions a direct access file at a particular record and sets the associated variable of the file to that record number. It is comparable to a direct access READ statement with no I/O list, and it can open an existing file. No data transfer takes place.

The FIND statement takes one of the following forms:


  • FIND ([UNIT=]io-unit, REC=r [,ERR=label] [,IOSTAT=i-var])
  • FIND (io-unit'rec [,ERR=label] [,IOSTAT=i-var])

io-unit

Is a logical unit number. It must refer to a relative organization file (see Section 10.2.1.1).

r

Is the direct access record number. It cannot be less than one or greater than the number of records defined for the file (see Section 10.2.1.4).

label

Is the label of the executable statement that receives control if an error occurs.

i-var

Is a scalar integer variable that is defined as a positive integer if an error occurs, and as zero if no error occurs (see Section 10.2.1.7).

Examples

In the following example, the FIND statement positions logical unit 1 at the first record in the file. The file's associated variable is set to one:


FIND(1, REC=1)

In the following example, the FIND statement positions the file at the record identified by the content of INDX. The file's associated variable is set to the value of INDX:


FIND(4, REC=INDX)

For More Information:

On direct access READ statements, see Section 10.3.2.

B.4 FORTRAN-66 Interpretation of the EXTERNAL Statement

If you specify the compiler option indicating FORTRAN-66 semantics, the EXTERNAL statement is interpreted in a way that was specified by the FORTRAN IV (FORTRAN-66) standard. This interpretation became incompatible with FORTRAN 77 and later revisions of the Fortran standard.

The FORTRAN-66 interpretation of the EXTERNAL statement combines the functionality of the INTRINSIC statement ( Section 5.11) with that of the EXTERNAL statement ( Section 5.8).

This lets you use subprograms as arguments to other subprograms. The subprograms to be used as arguments can be either user-supplied functions or Fortran 95/90 library functions.

The FORTRAN-66 EXTERNAL statement takes the following form:


  • EXTERNAL [*]v [,[*]v]...

*

Specifies that a user-supplied function is to be used instead of a Fortran 95/90 library function having the same name.

v

Is the name of a subprogram or the name of a dummy argument associated with the name of a subprogram.

Rules and Behavior

The FORTRAN-66 EXTERNAL statement declares that each name in its list is an external function name. Such a name can then be used as an actual argument to a subprogram, which then can use the corresponding dummy argument in a function reference or CALL statement.

However, when used as an argument, a complete function reference represents a value, not a subprogram name; for example, SQRT(B) in CALL SUBR(A, SQRT(B), C). It is not, therefore, defined in an EXTERNAL statement (as would be the incomplete reference SQRT).

Examples

Example B-1 demonstrates the FORTRAN-66 EXTERNAL statement.

Example B-1 Using the F66 EXTERNAL Statement

Main Program                        Subprograms

EXTERNAL SIN, COS, *TAN, SINDEG     SUBROUTINE TRIG(X,F,Y)
   .                                Y = F(X)
   .                                RETURN
   .                                END
CALL TRIG(ANGLE, SIN, SINE)
   .
   .                                FUNCTION TAN(X)
   .                                TAN = SIN(X)/COS(X)
CALL TRIG(ANGLE, COS, COSINE)       RETURN
   .                                END
   .
   .
CALL TRIG(ANGLE, TAN, TANGNT)       FUNCTION SINDEG(X)
   .                                SINDEG = SIN(X*3.1459/180)
   .                                RETURN
   .                                END
CALL TRIG(ANGLED, SINDEG, SINE)

The CALL statements pass the name of a function to the subroutine TRIG. The function reference F(X) subsequently invokes the function in the second statement of TRIG. Depending on which CALL statement invoked TRIG, the second statement is equivalent to one of the following:


Y = SIN(X)
Y = COS(X)
Y = TAN(X)
Y = SINDEG(X)

The functions SIN and COS are examples of trigonometric functions supplied in the Fortran 95/90 library. The function TAN is also supplied in the library, but the asterisk (*) in the EXTERNAL statement specifies that the user-supplied function be used, instead of the library function. The function SINDEG is also a user-supplied function. Because no library function has the same name, no asterisk is required.

For More Information:

On Fortran 95/90 intrinsic functions, see Chapter 9.

B.5 Alternative Syntax for the PARAMETER Statement

The PARAMETER statement discussed here is similar to the one discussed in Section 5.14; they both assign a name to a constant. However, this PARAMETER statement differs from the other one in the following ways:

  • Its list is not bounded with parentheses.
  • The form of the constant, rather than implicit or explicit typing of the name, determines the data type of the variable.

This PARAMETER statement takes the following form:


  • PARAMETER c = expr [,c = expr]...

c

Is the name of the constant.

expr

Is an initialization expression. It can be of any data type.

Rules and Behavior

Each name c becomes a constant and is defined as the value of expression expr. Once a name is defined as a constant, it can appear in any position in which a constant is allowed. The effect is the same as if the constant were written there instead of the name.

The name of a constant cannot appear as part of another constant, except as the real or imaginary part of a complex constant. For example:


PARAMETER I=3
PARAMETER M=I.25        ! Not allowed
PARAMETER N=(1.703, I)  ! Allowed

The name used in the PARAMETER statement identifies only the name's corresponding constant in that program unit. Such a name can be defined only once in PARAMETER statements within the same program unit.

The name of a constant assumes the data type of its corresponding constant expression. The data type of a parameter constant cannot be specified in a type declaration statement. Nor does the initial letter of the constant's name implicitly affect its data type.

Examples

The following are valid examples of this form of the PARAMETER statement:


PARAMETER  PI=3.1415927, DPI=3.141592653589793238D0
PARAMETER  PIOV2=PI/2, DPIOV2=DPI/2
PARAMETER  FLAG=.TRUE., LONGNAME='A STRING OF 25 CHARACTERS'

For More Information:

On compile-time constant expressions, see Section 5.14.


Previous Next Contents Index