Contact us Heritage collections Image license terms
HOME ACL Associates Technology Literature Applications Society Software revisited
Further reading □ Introduction □ A. System overview □ B. Program execution □ C. Filestore □ D. GEORGE commands □ E. Introduction to Multiple On-line Programming (MOP) □ F. Input of background jobs □ G. Editing files □ I. Budgeting, scheduling and accounting □ J. Monitoring files □ L. FORTRAN □ M. ALGOL □ N. Assemblers PLASYD, PLAN □ P. Consolidator □ Q. Libraries □ R. Data storage □ Sections S-Z unavailable □ S. Large program organisation □ T. User utilities □ V. Graphics packages □ W. Other packages □ X. Efficient use of the 1906A □ Y. 1906A hardware □ Z. Peripheral equipment □ List of reference manuals □ Index
ACD C&A INF CCD CISD Archives Contact us Heritage archives Image license terms

Search

   
⟶ ACL ⟶ Literature ⟶ ICL 1906A manuals ⟶ 1906A Reference Manual
⟶ ACL ⟶ Literature ⟶ ICL 1906A manuals ⟶ 1906A Reference Manual
ACL ACD C&A INF CCD CISD Archives
Further reading ⇓

□ Introduction □ A. System overview □ B. Program execution □ C. Filestore □ D. GEORGE commands □ E. Introduction to Multiple On-line Programming (MOP) □ F. Input of background jobs □ G. Editing files □ I. Budgeting, scheduling and accounting □ J. Monitoring files □ L. FORTRAN □ M. ALGOL □ N. Assemblers PLASYD, PLAN □ P. Consolidator □ Q. Libraries □ R. Data storage
Sections S-Z unavailable
□ S. Large program organisation □ T. User utilities □ V. Graphics packages □ W. Other packages □ X. Efficient use of the 1906A □ Y. 1906A hardware □ Z. Peripheral equipment □ List of reference manuals □ Index

L. FORTRAN

L.1 EXTENDED FORTRAN DIALECT

L.1.1 INTRODUCTION

The aim of this part of the manual is to aid the competent FORTRAN programmer in converting or writing programs for the 1906A. The topics covered should be the ones that a user will most frequently wish to reference. This chapter deals with the enhancements found in the ICL Extended FORTRAN language. Subsequent chapters cover compiler system statements, the ACL compilers, library functions, program debugging and error messages. A basic knowledge of the FORTRAN language is assumed.

L.1.2 ENHANCEMENT TO ANSI

The FORTRAN dialect on the 1906A includes all the facilities of 1900 FORTRAN with one or two additions. The 1906A dialect includes a number of enhancements to ANSI FORTRAN. The user is warned that making use of these could lead to machine dependence.

L.1.2.1 Basic Elements

The FORTRAN character set consists of:

Letters	A to Z
Digits	0 to 9
Symbols	$ + - * / & = ( ) , . ' space

A legal FORTRAN name may be up to 32 characters long (6 only in ANSI FORTRAN).

L.1.2.2 Constants

  1. Text constants may be defined by enclosing them in primes. TEXT may be kept in storage reserved for any of the usual types of variables and arrays. The assignment may be done in one of the following ways:
    1. A TEXT value in a DATA or type specification statement.
    2. Specifying a TEXT constant as an actual argument of a subroutine or function call.
    3. By use of an A format descriptor in conjunction with a READ statement.
    The manipulation of TEXT constants should be carried out by means of the character routines supplied in the FORTRAN library (L.4.3).
  2. A subscript may be any arithmetic expression as long as the final type of the expression is INTEGER.
  3. Up to 7 dimensions to an array are allows (3 in ANSI FORTRAN(.

L.1.2.3 Storage

  1. In addition to the predefined FORTRAN naming rules, the IMPLICIT statement allows the user to declare that names beginning with specified letters have a different implied type. For example: 
          IMPLICIT INTEGER (A-H,O),COMPLEX(P,Q),LOGICAL(L)
    This indicates that, unless mentioned in a type specification statement, all names beginning with A-H and O will be of type INTEGER, those beginning with P and Q will be of type COMPLEX, while those beginning with L will be of type LOGICAL.
  2. Assignment of initial values to variables and arrays may be done using a type specification statement of the form: 
          INTEGER J/1/B(2,4)/1,0,1,3*0,1,0/
    This statement will initialise J as INTEGER and assign it to the value 1. The array B has 2 dimensions and is of type INTEGER. The elements B(1,1), B(2,1), B(1,2), B(2,2), B(1,3), B(2,3), B(1,4), B(2,4) will be assigned the values 1,0,1,0,0,0,1,0.
  3. An array name by itself in an EQUIVALENCE statement has the same effect as specifying the first element of that array. For example, the following statements have the same result: 
          EQUIVALENCE (B,ARRAY)
      EQUIVALENCE (B,ARRAY(1,1,1))
  4. Named COMMON blocks can differ in size in different segments. If used in this way the following rules apply:
    1. The position of an item is defined in terms of the number of words of storage counted from the beginning of the block to the start of the item.
    2. If two items used in different segments occupy the same position and are of the same type, assigning a value to one of them defines the other as having the same value.
    3. If rule (b) is not satisfied and an item is assigned a value in one segment, an item occupying one or more of the same words of storage in another segment will become undefined. For example, suppose COMP is defined as COMPLEX and the COMMON statements in two segments are: 
            COMMON //A,T/AREA/X,Y,Z,ICOUNT
      COMMON //A,T/AREA/X,Y,COMP
      This is valid in 1906A FORTRAN. However, in the second segment, if a value is assigned to COMP, both Z and ICOUNT will become undefined. Care should be taken when using COMMON in this way, especially when using COMPRESS mode in INTEGER or LOGICAL declarations (L.2.3.2).
  5. An array may be completely or partially initialised in a DATA statement by specifying the first element of that array and a TEXT constant whose character count exceeds the number that can be held in a single element, but not more than can be held in the complete array. For example: 
          DATA A(1)/14HEND OF RESULTS/
      DATA A(1)/'END OF RESULTS'/
    In both cases the two variables A(1) and A(2) would contain: 
    END OF R
ESULTS

L.1.2.4 Expressions and Functions

  1. Consecutive exponentiations are evaluated from RIGHT to LEFT. For example: 
    A**B**C ≡  a(bc)
(A**B)**C ≡ (ab)c
    It is worth noting that the exponent operates only on the arithmetic element proceeding it. For example: 
    -A**B ≡  -(ab) ≢ (-a)b
    Unlike some other machines (for example, 360/195), no warnings are given at compilation or run time when expressions thought to be real are actually integer by mistake (and vice versa).
  2. INTEGER type bases may be raised to REAL or DOUBLE PRECISION exponents. The results of such exponentiations are of type REAL and DOUBLE PRECISION respectively. For example: 
          X = J**2.73629
      RES = J**EXPO
  3. Mixed-mode arithmetic is allowed. However, there are some restrictions of mixtures of type. Below are two tables showing these restrictions and also the type results of permitted mixed-mode arithmetic.
  4. Relational operators may be used to combine elements of expressions of type INTEGER, REAL or DOUBLE PRECISION but not COMPLEX.
Arithmetic expressions of the type: A+B, A-B, A*B, A/B
TYPE OF A TYPE OF B
INTEGER REAL COMPLEX DOUBLE PRECISION
INTEGER INTEGER REAL COMPLEX DOUBLE PRECISION
REAL REAL REAL COMPLEX DOUBLE PRECISION
COMPLEX COMPLEX COMPLEX COMPLEX PROHIBITED
DOUBLE PRECISION DOUBLE PRECISION DOUBLE PRECISION PROHIBITED DOUBLE PRECISION
Arithmetic expressions of the type: A+**B
TYPE OF A TYPE OF B
INTEGER REAL COMPLEX DOUBLE PRECISION
INTEGER INTEGER REAL PROHIBITED DOUBLE PRECISION
REAL REAL REAL PROHIBITED DOUBLE PRECISION
COMPLEX COMPLEX PROHIBITED PROHIBITED PROHIBITED
DOUBLE PRECISION DOUBLE PRECISION DOUBLE PRECISION PROHIBITED DOUBLE PRECISION

L.1.2.5 Assignment Statements

  1. The assignment of REAL or INTEGER values to COMPLEX variables or array elements (or vice versa) is allowed. In REAL to COMPLEX, the REAL value is assigned to the real part and the imaginary part is zeroised. In the case of INTEGER to COMPLEX, the INTEGER part is floated first, then as per REAL to COMPLEX. In the case of COMPLEX to REAL, the real part is assigned and the imaginary part omitted; with COMPLEX to INTEGER, the real part is fixed (that is, truncated and converted to integer) and then assigned (the imaginary part again being omitted).
  2. Multiple assignment statements are permitted. They take the form: 
    identifier1, identifier2,......identifierN = expression
    All variables and array elements within a multiple assignment statement should be of the same type; if not, the effects are unpredictable.

L.1.2.6 Control Statements

  1. In a computed GOTO, if the tested value is out of range control passes to the next executable statement. Also, if the selected label of a computed GOTO is zero, then again control passes to the next executable statement. The tested value is unchanged.
  2. An assigned GOTO does not necessarily need a label list. For example: 
          ASSIGN 57 TO MEANS
      GOTO MEANS,(92,3,9999,57,2)
    This will result in a transfer of control to Statement 57. The GOTO could have been written: 
    GOTO MEANS
    This would have the same effect.
  3. The three parameters of a DO statement may be any arithmetic expression whose result is of type INTEGER and should be greater than zero at run time.
  4. The transfer of control rules for DO loops are less restrictive. Any transfer of control from inside to outside a DO loop are allowed without the control variable becoming undefined. Transfers of control back into a loop may only be made if there has been a transfer out previously and both the control variable and parameters have remained unchanged. For example: 
          DO 25 J=1,100
      IF (A(J) .GT. 50)GOTO 50
 25   CONTINUE
 50   ...........
      GOTO 25
    The statement labelled 50 must not alter J.
  5. Additions to the PAUSE and STOP instructions are defined having the form: 
          PAUSE CHARS 
      PAUSE 'MESSAGE' 
      STOP  CHARS 
      STOP  'MESSAGE'
    CHARS is a string of one to five alphanumeric characters while MESSAGE is a string of up to 40 alphanumeric characters (the special characters $ ] ↑ ← are not allowed). If an apostrophe is to be included in MESSAGE it must be represented by 2 apostrophes. The destination of the specified string or message is always the monitoring file (Part J).

L.1.2.7 Program Statements

  1. 1906A FORTRAN allows multiple entry points to subroutine and function segments by way of the ENTRY statement which takes one of the following forms: 
          ENTRY name (darg1,darg2,...,dargn)
      ENTRY name
    The parameter name is the identifier of the entry point. The name must not be the name of any other segment, another entry point name, any standard function, any common block or the name of any other item used in the same segment (except that function names and the names of entry points to a function segment can be used as variables within the function segment). For further clarification see example below.
  2. 1906A FORTRAN also allows multiple return points from subroutine segments. This alternative to the normal RETURN statement takes the form: 
          RETURN i
    The argument i is an integer constant or variable. This form returns control to a labelled statement in the calling segment. The dummy argument list of any SUBROUTINE statement or ENTRY statement, from which control may pass to that RETURN, must include one or more dummy label arguments (this is the symbol asterisk). The actual argument must take the form: 
    &LABEL
    LABEL is the label of an executable statement in the calling segment. When the RETURN statement is executed, control is passed to the statement in the calling segment whose label is given as the actual argument corresponding to the i th asterisk in the dummy argument list. If the value of i is out of range, control is returned to the statement following the CALL statement in the calling segment. Below is an example of multiple entry and return in a subroutine segment: 
          SUBROUTINE ADD (I,J,*,*) 
      DIMENSION I(10) 
C
      J = 0
      DO 20 K = 1,10 
      J = J + I(K) 
  20  CONTINUE
      ENTRY ADDENT(J,*,*) 
      IF (J.EQ.0) RETURN 
      IF (J.GT.50) RETURN 1 
      RETURN 2 
      END
    If J is zero, control is returned to the statement following the CALL statement, if non-zero control is passed to some other return point. If entered at ENTRY point ADDENT, the subprogram would simply test the range of a value. The normal subroutine CALL would be of the following form: 
          DIMENSION IARRAY(10)
      CALL ADD (IARRAY,N,&I4,&99)
C  If, however, the segment were to be used simply to test the range of N, 
C  the CALL statement would be:
      CALL ADDENT(N,&21,&99)
      .........
 21   .........
      .........
 99   .........
  3. Dummy argument transfer can be specified to be either transfer by location or transfer by value. Dummy arguments which are arrays, functions or subroutines are always transfer by location, that is, an address is passed to the referenced segment. All other dummy arguments are assigned using transfer by value. However, a notation is provided so that a transfer by location can be forced. This is done by surrounding the argument by solidi, like this: 
          SUBROUTINE MULT(X,/P/,Y,ARRAY,/D/,/F/)
    This implies that arguments P, D and F will be transfer by location and that X and Y will be transfer by value. The dummy argument ARRAY will always be a transfer by location. The corresponding actual arguments in the CALL statement are not surrounded by solidi: 
          CALL MULT(A,B,C,D,E,F)
  4. TEXT constants may be used as actual arguments. A TEXT constant used as an actual argument must not be assigned a value in the referenced segment, and if it is used as an actual argument corresponding to a dummy array, it must fill all the array elements, that is, 4 characters per element for COMPRESS INTEGER and COMPRESS LOGICAL, 8 characters per element for INTEGER, REAL and LOGICAL, 16 characters per element for other types. The use of TEXT constants as actual arguments is the only exception to the rule that actual arguments must correspond to dummy arguments in type.

L.1.2.8 Format Specification

  1. The T descriptor specifies the character position in a record at which the next data field is to begin. It takes the form: 
    Tn
    where n is an integer, less than 4096, giving the character position. In the case of lineprinter output, the actual character position is (n-1) as the carriage control character is not printed. If there is more than one T descriptor per format then the n's need not be monotonic. For example: 
          FORMAT(T20,F6.3,I4,T1,I2,T50,F14.7)
  2. TEXT descriptors of the form 'STRING' may appear wherever Hollerith constants are permissible. Therefore, the following are equivalent: 
          6HSTRING and 'STRING'
  3. The format code G is a general conversion code that transfers all type values. The form is: 
    Gw.c
    where w denotes the width in characters of the field and c gives the number of significant figures; c may be omitted for INTEGER and LOGICAL. The G code may be used for free-format input.
  4. The format code L will accept, for LOGICAL input, optional spaces followed by .T, optionally followed by any other characters (.F is accepted in the same way).
  5. A format descriptor with both field length and fractional length zero is of free-format input. The input data is scanned, skipping spaces and end of record characters until a numeric field is found. The numeric field is read until a space or end of record is found. Spaces may not, therefore, appear within a field, except after D or E of an exponent field.
  6. The octal format On has parameter n which specifies the number of octal digits to be printed.

L.1.2.9 Input/Output

  1. The use of the following is allowed in 1906A FORTRAN: 
          READ(6,300,END=LABEL1,ERR=LABEL2)LIST
    The clause END=LABEL1 is for use with serial files. LABEL1 is a statement label in the same segment as the READ statement. Control is passed to this statement if an attempt is made to read a further record after the last record on a serial file. ERR=LABEL2 may appear in any READ statement. Control passes to LABEL2 if a hardware error occurs in data transfers. LABEL2 must be in the same segment as the READ statement. Clause ordering is not important if both clauses appear in a READ statement.
  2. NAMELIST may be used for formatted serial input/output. The NAMELIST statement specifies for each NAMELIST name a list of variables and array names. Thus on execution of a READ or WRITE statement referencing a NAMELIST name, the data items so specified are transferred. The NAMELIST statement has the form: 
          NAMELIST/NLNAME/a1,a2,a3,....... ,an
    where NLNAME is a NAMELIST name and a1, a2, etc, are variables or array names forming the list for NLNAME.
  3. Direct access record input/output is allowed and the appropriate forms of the statements are: 
    Formatted
      READ(K'r,L,ERR=LABEL1)LIST 
      WRITE(K'r,L)LIST
    where ERR=LABEL1 and LIST are optional. 
    Unformatted
      READ(K'r,ERR=LABEL1)LIST 
      WRITE(K'r)LIST
    ERR=LABEL1 is optional. However, LIST must appear in the WRITE statement. K is an integer giving the number of the input/output channel. The 'r is optional and identifies the record in the direct access file at which input/output is to start. Any direct access file of type DIRECT (L.2.3.3) used in a program must be previously defined in a DEFINE FILE statement.

L.1.3 RESTRICTIONS ON ICL EXTENDED FORTRAN

  1. The main program segment must start with an identification statement. The segment identifier statement for a master segment takes one of the forms: 
          MASTER 
      MASTER name
    The name is any valid FORTRAN identifier. The naming rules are the same as those for BLOCK DATA, SUBROUTINE, FUNCTION and ENTRY names.
  2. The following rules must be adhered to when structuring a FORTRAN program:
    1. Each segment must begin with a segment identifier statement and end with an END line.
    2. Not more than one IMPLICIT statement may be used in a segment; if present, it must occur immediately after the segment identifier statement.
    3. The specification statements (type specification, DIMENSION, COMMON, EQUIVALENCE, EXTERNAL and DEFINE FILE statements) must precede any statement function definitions and all executable statements.
    4. FORMAT, NAMELIST and DATA statements may occur anywhere in the segment, provided that they do not precede an IMPLICIT statement.
    5. ENTRY statements may occur anywhere in the segment except that they must not precede an IMPLICIT statement and must not occur within the range of a DO loop.
    6. Statement function definitions must precede all executable statements.
    7. A statement function definition may only reference another statement function if the referenced statement function definition precedes the referencing definition.
    8. At least one executable statement must appear in every segment other than BLOCK DATA segments.
    9. Statement function definitions, executable statements, NAMELIST statements, DEFINE FILE statements and ENTRY statements must not appear in block data segments.
  3. A FORTRAN program may contain more than one BLOCK DATA segment but any named COMMON block can be referred to in only one BLOCK DATA segment. Also, items in the blank COMMON block cannot be given initial values in a BLOCK DATA segment.
  4. Space characters in exponents in data records are not treated as zero on input.

L.2 COMPILER SYSTEM STATEMENTS

L.2.1 INTRODUCTION

All FORTRAN programs to be compiled must be preceded by a program description. However, simple compilations may be carried out using a default program description supplied by the TASK system (Part B). For example, this limits the input and output channels that can be used. This default program description is as follows:

      PROGRAM(FORT) 
      INPUT 1,5 = CR0 
      OUTPUT 2,6 = LP0 
      END

FORT is the name of the program; input streams 1 and 5 are card reader channels connected to CR0 and output streams 2 and 6 are connected to LP0. Diagnostic facilities (L.5.2) and listing modes are at the levels assumed by default. Compiler runs other than simple compilations require system statements to be included which fall into the following categories:

  1. Initial statements
  2. Program description statements
  3. Intersegment statements
  4. Terminator

L.2.2 INITIAL STATEMENTS

L.2.2.1 LIST, SHORTLIST, ERRORLIST and NOLIST

The default at ACL is SHORTLIST. No FORTRAN source statements are listed except MASTER, SUBROUTINE, FUNCTION and BLOCK DATA statements. In all other respects the listing is similar to LIST. Error messages, warnings and comments have a slightly different format. A description of the format of a LIST listing is given in L.3.2.3.

ERRORLIST will only list the appropriate error message; comments and warnings are not listed. The NOLIST statement gives no listing - not even error messages.

The listing statements mentioned above may also be used as intersegment statements. After the statement has been encountered, subsequent segments are listed in the mode specified until either the next listing statement is encountered or the end of program is reached.

L.2.2.2 LISTALLERRORS

A complete list of all error messages within the compilers may be obtained by supplying as the first and only statement:

      LISTALLERRORS

This statement must start at or beyond column 7.

L.2.2.3 SENDTO(NONE)

This statement prevents the compiler producing semicompiled output. A program description should be supplied beginning with a SEGMENTS or OVERLAY SEGMENTS statement and preceded by the statement:

      SENDTO(NONE)

No COMP or BIN parameter should be given in the call to the TASK macro.

L.2.2.4 DUMPON and ADD DUMP

If the TASK macro contains a BIN parameter either DUMPON or ADD DUMP (exofile name) must be provided. The DUMPON statement specifies that the binary dump is to be made on the file specified in the BIN parameter, overwriting the previous contents, if any. The ADD DUMP Statement specifies that the binary dump is to be added to an existing dump on the specified exofile. The exofile name should be the same as that given in the BIN parameter.

L.2.2.5 LIBRARY and SEMICOMPILED

It is possible to include previously semicompiled segments from source segments in FORTRAN and other languages or segments from standard libraries at consolidation time (the FORTRAN library is automatically included). The files containing the segments to be inserted are specified by means of the SEMI or LIB parameter in the TASK command.

The LIBRARY statement is used when only those segments specifically required by the program are to be incorporated; that is, the consolidator is to accept segments selectively. The SEMICOMPILED statement is used when all the semicompiled segments specified in the subfile are to be consolidated; that is, the consolidation is to accept the segments inclusively.

The use of LIBRARY and SEMICOMPILED is not recommended. Instead, use should be made of the TASK LINK parameter.

L.2.3 PROGRAM DESCRIPTION STATEMENTS

A program description is introduced by one of the following statements

      PROGRAM(name) 
      OVERLAY PROGRAM(name)
      SEGMENTS(name) 
      OVERLAY SEGMENTS(name)

The parameter name is a four-letter program identifier. The PROGRAM statement is used to introduce a non-overlaid program which is to be compiled and consolidated. If a program is not complete or if consolidation is not required, the program description should be introduced by a SEGMENTS statement. The OVERLAY statements are described in L.3.3.2.

L.2.3.1 COMPACT, EXTENDED and EXTENDED DATA

Programs produced at ACL are in extended mode, unless specified otherwise. The program will normally be sparse (the normal reason for a dense program is when the program is being developed at ACL for use on another machine) and in most cases it should not be necessary to specify a mode, but the following are examples of when it will be necessary:

  1. A program compiled for execution in an environment where 32K words of core or less are available must be compiled in COMPACT mode.
  2. If segments or library routines are to be incorporated which will run only in a mode other than EXTENDED, then the program must be compiled in the appropriate mode.

The overall size of a COMPACT program must not exceed 32K; an EXTENDED DATA program may exceed this limit provided that the program instruction area lies within the first 32K words. In the case of overlay programs, these restrictions apply to the sum of the permanent unit and the largest overlay unit that may occupy each overlay area.

The statement, EXTENDED DATA, will produce an extended data program, and the COMPACT statement will produce a compact program. At ACL, both compact and extended data programs are always dense.

L.2.3.2 COMPRESS INTEGER and LOGICAL

This statement may be written anywhere in the program description as follows:

      COMPRESS INTEGER AND LOGICAL

If present, one word of core store is assigned to INTEGER and LOGICAL scalars or array elements instead of the usual 2 words. The range of the INTEGER quantities is not affected. The user is recommended to use this statement only when store is short or when some segments in a program are written in another language and these segments require compressed FORTRAN INTEGER quantities. In COMMON, EQUIVALENCE and DATA statements, extra care is necessary if COMPRESS mode is used. For example, if the following COMMON statements appear in two different segments:

      COMMON/MAT/A,B(100),I(10,10),C 
      COMMON/MAT/ING,BB(100),J(10,10),CC

If both segments are compiled without COMPRESS mode, ING and A will occupy the same storage. However, in COMPRESS mode not only will A and ING not occupy the same storage but also the following scalars and arrays will not correspond.

L.2.3.3 INPUT, OUTPUT, USE and CREATE

All input and output stream numbers used by a program must be associated with an actual input or output channel. For simple programs, the default program description may be used.

Input/output statements within a source program refer to their related peripheral units by integer stream numbers. When the program is compiled these stream numbers are associated with 1906A system names of the peripheral units by channel description statements, of which there are 4 types:

INPUT K=Z     (input only)
OUTPUT K=Z    (output only)
USE K=Z       (input and output)
CREATE K=Z    (input and output)

where K is a source program stream number in the range 1 to 4095, although stream 0 may be used for TRACE purposes (L.6.2); K may also be a list of stream numbers separated by commas. Z gives details of the peripheral to be associated with K. The same Z must not appear in more than one channel description statement and each K may appear once only.

The parameter Z consists of a 2-letter code defining the peripheral name, followed by a logical unit number chosen by the user. The logical unit number must be in the range 0 to 15 and must not contain leading zeros. The peripherals available are:

Paper Tape reader      TR
Paper Tape punch       TP
Card Reader            CR
Card Punch             CP
Lineprinter            LP
Magnetic Tape          MT
Disc                   DA

The format of a channel description statement for a disc file is as follows:

hk = DAn/q(f)/b

where

h   is one of INPUT,OUTPUT,USE or CREATE (not USE for CR or CP)
k   is a program stream number
n   is the logical unit number
q   is the record-type qualifier (FORMATTED, UNFORMATTED or DIRECT)
f   is the filename or dummy filename
b   is the size in words of the buffer associated with the file, 
     which must be the same as the bucket size defined in the CREATE 
     command (D.7.7).

The format of the channel description statement for magnetic tape is: 

hk = MTn/q(f)/b

where h,k,n,f, are as previously defined and q is the qualifier defining the format of the record (FORMATTED, UNFORMATTED or DUMP) and b is the block size on the magnetic tape.

In both disc and magnetic tape usage, USE will use the named file or scratch file for both input and output, CREATE will create a named file or rename an existing file or obtain a scratch file, and use it for output followed by input if required. Below are some examples:

INPUT 3 = CR0                  (Stream 3 associated with card reader 0)
OUTPUT 4 = LP7                 (Stream 4 associated with lineprinter 7)
CREATE 3 = DA3/DIRECT(FILEONE) (Stream 3 associated with direct access file 
                                 FILEONE to be allocated DA3)
USE 2 = MT3/1024               (Stream 3 associated with direct access file 
                                FILEONE to be allocated DA3) (Stream 2 is 
                                associated with a scratch tape opened on MT3
                                for input/output of 1024 word block-size records).

L.2.3.4 OMIT

For a program under test, some segments may not be required, or even need to be present when the program is run. Segments may be omitted at the consolidation phase by using:

      OMIT seg1,seg2,......,segN

The list of names following OMIT define the segments not to be consolidated. The program will be terminated if a call to a missing segment is encountered at run time. Currently, this does not work.

L.2.3.5 ABNORMAL FUNCTIONS

The optimizing compilers distinguish between normal and abnormal functions. A function is abnormal if either of the following apply:

  1. Directly or indirectly the function does any of the following before returning control to the referencing segment:
    1. alters any of its arguments
    2. alters any COMMON item
    3. performs any input or output
    4. executes a PAUSE statement
  2. Separate references with identical arguments may give different results.

If a program contains a function that does any of the above then the statement:

      ABNORMAL FUNCTIONS

must appear in the program description.

L.2.3.6 END

The program description must finish with an END line, identical in format to a source program END line.

L.2.4 INTERSEGMENT STATEMENTS

Certain statements may appear between source segments if it is required to change the original specifications during compilation. For example, the modes of listing (L.2.2.1) or of tracing in error diagnosis (L.5) may be changed by insertion of the required compiling system statement.

L.2.5 TERMINATOR

The end of input to the compilers must be indicated by the terminator statement:

      FINISH

If the specified source input is exhausted and no FINISH statement is found, one will be assumed and a message output to that effect on the source listing.

L.3 THE FORTRAN COMPILER

L.3.1 INTRODUCTION

There are two stages prior to execution of a program. The FORTRAN main program and any subroutines are not compiled directly into machine code but into a semicompiled state. The semicompiled code is a common intermediate language, thus allowing multi-language programming. The semicompiled then enters the consolidator. The consolidator links the generated segments of semicompiled code to form a binary object program for execution. The consolidator also searches the standard FORTRAN Library (L.4). If any routines are found that satisfy the cues (external references) produced by the compiler, then these are incorporated in the object program. Unsatisfied cues produce an error message but do not prevent execution of the object program.

It is possible to request that library files, other than the FORTRAN Library, are included (Part Q) and also to request the consolidator to include all the semicompiled segments from a given file into the object program, regardless of whether these have cues referring to them. The precise actions of the compilers and consolidator are determined by compiler system statements (L.2) and by options of TASK (Part B).

L.3.2 THE COMPILERS

There are two compilers in use at ACL which are modified versions of the ICL compilers XFIH and XFEH. XFEH is an optimising compiler while XFIH is intended for use when programs are under development; it contains extensive facilities for program testing. XFEH is intended for recompilation of tested programs prior to operational running; it compiles more slowly and contains fewer testing facilities. However, the object code will run faster than that produced by the standard compiler.

L.3.2.1 General Optimising Compiler Considerations

It is worth noting that the use of an optimising compiler may give rise to side effects causing object programs compiled by XFEH to behave differently to those compiled under XFIH. In the extreme case a program which works after using XFIH may fail when compiled by XFEH. Below are some points that should be borne in mind when programming for the optimising compilers.

  1. Order of evaluation of expressions: The order of evaluation of expressions in segments may be different from that when XFIH is used. In some cases overflow may occur or different results may be obtained. Therefore, if the order of evaluation is critical, parentheses should be used to define the order.
  2. DO loops: An expression in a DO loop that is unchanged in value during the execution of that DO loop is removed from the loop and evaluated once only. This streamlining of the object code can have its drawbacks. For example: 
          DO  150 I = 1,100
      IF(D .EQ. 0.0)GOTO 120
      A(I) = C/D
      GOTO 150 
 120  A(I) = 0.0 
 150  CONTINUE
      ........
    In this particular loop the expression C/D is unchanged in value and will be evaluated before the loop is entered. However, if D is zero, a failure will occur, even though the program checks for that condition, as the expression C/D will be computed, or, at least, attempted to be computed before checking whether D is zero.

    If the parameters of a DO loop or implied DO loop are variables there is a limit to the number of iterations that will be performed. If COMPACT mode (L.2.3.1) is specified in the program description segment, the limit is 32768 iterations; otherwise it is 222 iterations.

  3. Subroutine and function segments: The following two rules should be adhered to when writing subroutine and function segments:
    1. On entry to a subroutine segment there must be no reference to a dummy argument that is not in the argument list of the particular subprogram statement.
    2. If a subroutine reference causes a dummy argument in the argument list to become associated with another dummy argument in the same list or with any COMMON item, then neither dummy argument nor COMMON item must be changed in value in the referenced segment. For example: 
            FUNCTION RESULT(X,Y,Z) 
      COMMON W
      .........
      Consider in the referencing segment: 
            COMMON W
      ............
      C = RESULT(A,W,A)
      Then W,X,Y and Z must not be changed in value during the execution of function RESULT.
  4. Abnormal functions: The optimising compiler assumes, by default, that all functions, both intrinsic and external, are normal. (For definition of an abnormal function see L.2.3.5) if this is not so, as in the case of the library function, ICOMP, an ABNORMAL FUNCTIONS statement must be present in the program description segment. This means that all external functions will be treated as abnormal and intrinsic functions treated as normal. The ABNORMAL FUNCTIONS statement is ignored by XFIH.
  5. Overflow: Differing results may occur on calls to subroutine OVERFL (L.4.5.6) since the computation causing overflow may have been taken outside a DO loop, or the computed expression value may have been saved from a previous computation.
  6. Error trap segments: If an ERROR TRAP subprogram (L.5.2.3) is in use, it may be entered at different times as in the case of OVERFL. This could mean that COMMON variables would have different values on entry to that segment. Neither an error trap segment nor a segment used by it may change the values of COMMON variables.

L.3.2.2 ACL FORTRAN Compilers

The FORTRAN compilers in use at ACL are modified versions of the compilers supplied by ICL. The modifications either improve the efficiency of the compiler, or provide additional facilities.

Users are advised that these compilers are much more efficient when compiling from filestore files of type GRAPHIC or disc exofiles than they are when compiling from filestore files of type NORMAL or ALLCHAR (that is, paper tape files).

To use the optimising compiler XFEH, the parameter OPT is supplied in the call to TASK. For example:

TASK FORTRAN,*CR FRED,OPT

L.3.2.3 Listing Format

  1. A heading is listed at the start of every segment. This is similar to: 
    FORTRAN COMPILATION BY XFEH MK 1E/2 DATE,..........
  2. The default listing mode is SHORTLIST. A full listing can be obtained by specifying LIST in the program description segment (L.2.2.1).
  3. If there are no errors, warnings or comments in a segment, then the following statement appears: 
    END OF SEGMENT, LENGTH a,NAME b,TIME c,MILL d MSEX
    The parameters have the following meaning:
    1. is the length of the segment in words
    2. is the name of the segment
    3. is the time of day
    4. is the mill time in milli-seconds used since the start of compilation. Hence the mill time for compiling any one segment can be calculated.
  4. There are 2 columns of line numbers. The left-hand column contains FORTRAN line numbers, and these are the line numbers used in error messages. Note that not all lines listed will have an associated number; in particular, * INCLUDE statements (L.3.2.6), commands for the file editor and lines of a disc subfile are omitted. The right hand column contains the file line numbers and counts upwards from zero for card input (or graphic file type *INCLUDE input), or from one for disc input. These line numbers are the ones to use for editing the source files using the GEORGE EDITOR (Part G) or XMED (for information on the disc file editor XMED see Part T).

    When the input type of a line is different from that of the preceding line, then an indication of the type of the new line, namely CARDS, DISC or *INCL. respectively is given in columns 14-19 of the listing. The file line number count for card input is preserved when the input type changes to disc or *INCLUDE and is restored when input reverts to card type. Similarly, the line count for a disc subfile is preserved when the input changes the *INCLUDE file or subfile. Lines of FORTRAN inserted from cards into a disc file by the EDITOR are listed as being of type CARDS and are given the appropriate card file line numbers.

  5. There are a number of extra error messages. A complete listing of the error messages for the compiler may be obtained by performing a compilation run in which the source file contains only the program description statement: 
          LISTALLERRORS

L.3.2.4 Disc Input

It is possible to read the source for either compiler from an exofile using the READFROM statement. This has the format:

      READFROM (xx,filename.subfilename,csn/EDIT)

The parameters have the following meaning:

  1. xx: this is either DA or ED. If anything else is used, the READFROM statement will halt: 
    HALTED : EF
    This corresponds to end of file.
  2. filename: this is the name of the exofile. It must be a standard composite file in XMED format. The directory in the file must not be fragmented. The filename used is significant and must be a localname, The filename, together with the preceding comma, may be omitted from READFROM statements other than the first. In this case, the previously-used filename is assumed. If filename is omitted, the parameter csn should also be omitted.
  3. subfilename: this is the name of the subfile whose contents are to be compiled. The subfile must be a simple data one and must not be fragmented. It should be in the format produced by the AMED disc editor. If the READFROM statement included a filename parameter then the subfilename and preceding full stop can be omitted. In this case, the first subfile in the disc file will be used.
  4. csn: this is the octal serial number of the disc cartridge containing the exofile. If given, the compiler will issue an ONLINE command to on-line the disc file. If it is omitted, the preceding comma should also be omitted.
  5. EDIT: if present (with the preceding/), this indicates that the subfile is to be edited before compilation. Note that the contents of the exofile are not altered. The compiler edits the source as it is read and compiles the edited source. The editor commands must be on cards and should immediately follow the READFROM statement. Full details of the editor commands are given in the next section.

    If a subfile is being edited and the compiler comes to the end of the subfile without completing the edit, the compilation will be abandoned.

L.3.2.5 Editor Commands

These editor commands have the same format as those for the XMED editor. Consequently, if an experimental set of edit commands is successful, the same deck of cards may be input to XMED to perform a permanent edit to the exofile.

The editor commands all start in column 1 and have the following formats:

****

This terminates the edit.

*ALTER m

This compiles lines up to but not including line m where the lines in the subfile are numbered from 1 and not 0 as in GEORGE filestore files. The lines following the *ALTER command up to the next editor command are inserted at this point in the subfile. It is possible to insert a *INCLUDE line.

*ALTER m,n

This compiles lines up to but not including line m. The next n lines are omitted. The lines following the *ALTER command are then inserted in the subfile.

*ALTER m-n

This compiles lines up to but not including line m . Lines from m up to and including line n are omitted. The lines following the *ALTER command are then inserted in the subfile.

The other XMED commands are not available. In particular *IN, *OUT and the run terminator //// should be omitted.

If lines are to be inserted at the beginning of the subfile, the first card to follow the READFROM statement must be:

*ALTER 1

L.3.2.6 The INCLUDE Command

In a large FORTRAN program, there is often the need to include the same set of COMMON declarations in a number of different segments. It is possible to put these COMMON statements in a separate file or disc subfile and include them at the appropriate point in the routine by using the *INCLUDE statement. For example:

      SUBROUTINE CHAS(I)
      *INCLUDE(FRED)
      ...............
      END

The disc subfile FRED contains a set of FORTRAN statements to be inserted in the program. These may be any FORTRAN statements and are not restricted to COMMON statements. The *INCLUDE facility may use either disc subfiles or GRAPHIC filestore files. A *INCLUDE statement may be supplied either from card or disc source, or may be edited into a disc subfile. It is possible to nest *INCLUDE statements. However, users may run into difficulties with MAXSIZE if nesting is taken to any considerable depth.

If the LIST option is used, the depth of nesting is indicated in the compiler listing.

The two possible systems are:

  1. Disc System 
    *INCLUDE(subfilename,LIST)
    The statement must start in column 1 and must not have spaces within the *INCLUDE part. The parameter subfilename defines the subfile containing the lines to be included. The exofile containing the subfile is defined by a MACROFILE program description statement which must precede the first *INCLUDE statement.

    Normally the listing of the *INCLUDE file will be a SHORTLIST mode. However, if the listing level for the compilation is LIST and the parameter LIST (with the preceding comma) is supplied in the *INCLUDE statement, then the listing level will be LIST for the included statements.

    The name of the exofile is specified by the program description statement:

    MACROFILE (filename, csn)

    The parameter filename is the name of the exofile. It must be a standard composite file in XMED format. The directory in the file must not be fragmented. The subfiles in the file must be simple data subfiles and should not be fragmented. The filename used is significant and should be a localname. The parameter csn is the octal serial number containing the disc exofile. If this parameter, together with the preceding comma is given, the compiler will issue an ONLINE command to on-line the exofile.

    This statement may be used either as an initial statement (coming before the PROGRAM or SEGMENTS line of the program description) or as an intersegment statement. The exofile to be used in the *INCLUDE statements may be changed between segments by supplying another MACROFILE statement.

  2. GRAPHIC File System 
    *INCLUDE (*CR,filename,LIST)
    The contents of the file whose name is given by the anyfilename parameter is compiled at this point in the program. The specified file must be a GRAPHIC file. The MACROFILE statement has no effect for this type of *INCLUDE statement. The parameter LIST is the same as for the disc system.

L.3.2.7 Symbol Table Listing

It is possible to obtain a symbol table listing by supplying the program description statement:

      SYMBOLTABLE

This is an intersegment statement, and only applies to the next segment, to be compiled. Thus a SYMBOLTABLE statement must be supplied for every segment for which a symbol table listing is required. The individual items are listed in an arbitrary order. Each item is listed in a 60-column field with two fields to the line. The contents and format of the field depend on the type of the item although each format is similar. The basic format of the columns is:

1-16: Name of item (the name of the blank common block is %).

17-18: Blank

19: D for dummy variable

20: For dummy scalars, L defines access by location while V defines access by value. C defines that the item is in COMMON.

21: For dummy arrays, N indicates that it has variable dimensions. For non-dummy variables, E indicates it has been equivalenced. For function and subroutine names, E indicates that item appears in an EXTERNAL statement.

22: P indicates that item is pre-set (appears in a DATA statement). An array will be marked as pre-set if at least one element is pre-set. For function names, N indicates a NORMAL function while A indicates an abnormal function.

23-25: Blank

26: Length of scalar or array element in 1900 words

27-28: Blank

29-32: Type of variable where:

INT.   = integer
REAL   = real
D.P.   = double precision real
COMP   = complex
LOG.   = logical

33: Blank

34-36: AR. for an array

37: Blank

39-60: Relative address of scalar or first element of array

For certain special identifiers, the form of the item is given near the end of the field. For example:

  1. Function names have FUNCTION in columns 34-41.
  2. Subroutine names have SUBROUTINE in columns 21-30.
  3. Common block names have COMMON BLOCK LENGTH xxxx in column 19 onwards where xxxx is the length of the common block in 1900 words.
  4. ENTRY names have ROUTINE ENTRY POINT starting in column 29.
  5. Statement functions have STATEMENT FUNCTION starting in column 34.

L.3.3 MISCELLANEOUS COMPILER DETAILS

Below are the syntactic details of some compiler features to be found at ACL. They include the FORTIDY macro and overlay details.

L.3.3.1 The FORTIDY Macro

The FORTIDY macro generates symbol table listings for a FORTRAN program or set of segments. The program source is listed in a tidied format, with suspected syntax errors flagged. The parameters required to drive the macro are all optional, except for the source file parameter, and may be given in any order. These parameters are:

  1. *CR sourcefile or *CR/ATLAS/sourcefile or *CR/EBCDIC/sourcefile: This parameter identifies the file from which the source is to be read, and the card code used in that file. The default card code is the standard 1900 card code.
  2. *LP filename: This parameter causes output to be appended to the specified file, which will not be listed by the macro. The default action is to send output to a workfile, which is listed on the lineprinter.
  3. *CP newfile or *CP/ATLAS/newfile or *CP/EBCDIC/newfile: If this parameter is included, a new file will be created and will contain a tidied version of the source program in the required card code.
  4. JT jobtime: This parameter may be used to specify the jobtime required by the macro. If it is omitted, no JOBTIME command will be issued.
  5. EJ actiononmf: The parameters of the ENDJOB command at the end of the macro may be specified by this parameter. The default action is to ENDJOB NONE if the macro was called from a MOP terminal, and to EX if it was called from a background job.

L.3.3.2 Overlay Structure

Under the paged environment of GEORGE 4 it should not be necessary to use overlaying, but for those who must, because of lower data problems in FORTRAN (Part S), here is a brief specification. When an overlaid program is run, only part of it is in core store at a particular time. To use the overlay system, the user must divide the program into units; one unit which is not to be overlaid and a number of overlay units. The permanent unit should contain the MASTER segment, various subroutines that are inserted into a FORTRAN program by the compiler and not referred to explicitly by the user (for example, the input and output subroutines), and any other segments the user may choose. Each overlay unit of the program must be assigned to an overlay area of core store. There may be several overlay areas and each one may have several overlay units assigned to it. At any one time an overlay area may contain only one of the units assigned to it. A program to be overlaid is written and segments are called by CALL statements or function references exactly as if the complete program was in core. The usage and restrictions applicable to the overlay system are set out below:

  1. Program description statements for overlay programs: A program description must be submitted with the source program. This section describes the OVERLAY PROGRAM and OVERLAY SEGMENTS statements, (one of which must be used to introduce the program description) and the other program description statements which may be used with overlay programs.
    1. The OVERLAY PROGRAM and OVERLAY SEGMENTS statement: The OVERLAY PROGRAM statement must be used in place of a PROGRAM statement and this has the form: 
      OVERLAY PROGRAM (name)
      The parameter name is the program name. The OVERLAY SEGMENTS statement must be used instead of a SEGMENTS statement in order to introduce segments to be compiled which may later be included in an overlay program. It has the form: 
      OVERLAY SEGMENTS (name)
      The parameter name is the program name.
    2. The OVERLAY statement: This statement is used to define the structure of an overlay program. As this information is not required until the complete program is compiled, the statement should only be used in a program description introduced by the OVERLAY PROGRAM statement. The statement takes the form: 
      OVERLAY(a,u) seg1,seg2,seg3,......,segn

      a is the overlay area number and 1≤a≤255

      u is the overlay unit number and 1≤u≤1023

      seg1,seg2 etc are the names of the segments to be included in the unit u of area a.

      The same unit numbers may be used for units in different areas. No continuation lines are permitted. However, if the same area and unit numbers appear in more than one statement, then the unit will comprise all the segments named in all such statements. For example:

      OVERLAY(3,7) SUB1,SUB2,FUNC7 
OVERLAY(3,7) SUB3,SUB4

      This will have the same effect as: 

      OVERLAY(3,7)SUB 1,SUB2,FUNC7,SUB3,SUB4

      Any segments that are not assigned to an overlay unit will be assigned to the permanent unit. The permanent unit is not explicitly specified by the user.

    3. The DEPTH OF OVERLAY statement: This statement should only appear in the program description headed by the OVERLAY PROGRAM statement.

      A record is kept of the unit and area numbers of overlaid segments so that when a return is made to a referencing segment, the correct unit is brought into core. This situation becomes complex if the segment calls are nested. Therefore the space reserved by the compiler to contain this list of records must be sufficient to contain the maximum number of segment entries required; this is done by the DEPTH OF OVERLAY statement. It takes the form:

      DEPTH OF OVERLAY n

      where n is an integer constant of the maximum number of entries required in the list.

      If the DEPTH OF OVERLAY statement is omitted from a program description, the space required is estimated from the total number of units in the program. It is, therefore, obligatory only to use the statement in highly segmented programs. On the other hand if the number of records in the list will be considerably less than the number of units, some core store can be saved if the appropriate depth of overlay is specified. Below are two examples of the use of this statement:

      1. A program contains 40 overlay units and one overlay area. All calls to overlay units are made from the permanent unit and no overlay unit calls another overlay unit. An overlay unit may call standard functions in the permanent unit. The user may save the space of 38 entries in the list of records by using: 
        DEPTH OF OVERLAY 2
      2. A program contains 2 overlay units. A segment in the permanent unit calls segment 1 of unit A which calls segment 1 of unit B, which in turn calls segment 2 of unit A, and so on to a depth of 20 calls. Segments in units A and B reference standard functions held in the permanent unit. In order to reserve enough store to hold the list of records, the user must include: 
        DEPTH OF OVERLAY 22
  2. Overlay restrictions The following restrictions apply to overlay programs:
    1. A CALL or function reference must not bring down another unit to overwrite the referencing unit, either directly or indirectly via nested overlays. However, there is one exception: a CALL with no arguments may bring down a unit to overwrite itself. In this case, a RETURN may not be made unless the calling segment also has no arguments.
    2. No EXTERNAL referenced subroutine or function may appear in an overlay unit.
    3. No segment name may appear in two OVERLAY statements.
    4. DAO and MTO (L.2.3.3) must not be used in an overlay program.
    5. It is worth noting that non-common variables, array elements and arrays will be overlaid if assigned values in DATA statements and will be reset to the specified values each time the overlay unit is brought in.

L.3.3.3 Hardware Extended Precision

The ACL 1906A has facilities to allow DOUBLE PRECISION calculations to be performed by hardware; this is referred to as hardware extended precision (HEP).

To use this facility the compilers produce special object code which cannot be executed on machines without this facility. A special FORTRAN Library package, SRF8 (L.4) is used for HEP.

L.4 LIBRARY FUNCTIONS

L.4.1 INTRODUCTION

SRF8, System Routines FORTRAN 8, is a set of extended precision subroutines, functions and system routines. It is the hardware extended precision version of SRF4. At ACL the 1906A has HEP with 22-bit address mode and extended branch mode. SRF8 consists of 7 sections:

  1. Mathematical routines
  2. Character routines
  3. Direct access backing store package
  4. FORTRAN dump and restart package
  5. System routines
  6. Service routines
  7. Logical and shifting functions.

Details of the routines are given in the following sections. Arguments to routines have their implicit types unless specified. Routine arguments are given as z1, z2 etc.

L.4.2 MATHEMATICAL ROUTINES

L.4.2.1 Intrinsic Functions

Intrinsic function Definition Number of
Arguments		 Symbolic
name		 Types of
Arguments(s) Function
Absolute value |z| 1 ABS REAL REAL
1 IABS INTEGER INTEGER
1 DABS DOUBLE DOUBLE
Truncation sign of z times largest integer ≤ |z| 1 AINT REAL REAL
1 INT REAL INTEGER
1 IDINT DOUBLE INTEGER
Nearest integer sign of z times nearest integer (.5 is rounded up) 1 NINT REAL INTEGER
1 ANINT REAL REAL
Remaindering (modulo) z1 (mod z2) 2 AMOD REAL REAL
2 MOD INTEGER INTEGER
Choosing largest value Max(z1,z2,...) ≥2 AMAX0 INTEGER REAL
≥2 AMAX1 REAL REAL
≥2 MAX0 INTEGER INTEGER
≥2 MAX1 REAL INTEGER
≥2 DMAX1 DOUBLE DOUBLE
Choosing smallest value Min(z1,z2,...) ≥2 AMIN0 INTEGER REAL
≥2 AMIN1 REAL REAL
≥2 MIN0 INTEGER INTEGER
≥2 MIN1 REAL INTEGER
≥2 DMIN1 DOUBLE DOUBLE
Float Conversion from integer to real 1 FLOAT INTEGER REAL
Fix Conversion from real to integer 1 IFIX REAL INTEGER
Transfer sign Sign of z2 times |z1| 2 SIGN REAL REAL
2 ISIGN INTEGER INTEGER
2 DSIGN DOUBLE DOUBLE
Positive difference z1-Min(z1,z2) 2 DIM REAL REAL
2 IDIM INTEGER INTEGER
Obtain most significant part of double precision argument 1 SNGL DOUBLE REAL
Obtain real part of complex argument 1 REAL COMPLEX REAL
Obtain imaginary part of complex argument 1 AIMAG COMPLEX REAL
Express single precisionargument in double precision form 1 DBLE REAL DOUBLE
Express two real arguments in complex form z1 + i z2 2 CMPLX REAL COMPLEX
Obtain conjugate of a complex argument 1 COMJG COMPLEX COMPLEX

L.4.2.2 External Functions

Intrinsic function Definition Number of
Arguments		 Symbolic
name		 Types of
Arguments(s) Function
Exponential ez 1 EXP REAL REAL
1 DEXP DOUBLE DOUBLE
1 CEXP COMPLEX COMPLEX
Exponential to base 10 10z 1 EXP10 REAL REAL
Natural logarithm loge(z) 1 ALOG REAL REAL
1 DLOG DOUBLE DOUBLE
1 CLOG COMPLEX COMPLEX
Common logarithm log10(z) 1 ALOG10 REAL REAL
1 DLOG10 DOUBLE DOUBLE
Base 2 logarithm log2(z) 1 ALOG2 REAL REAL
Trigonometric sine (radians) sin(z) 1 SIN REAL REAL
1 DSIN DOUBLE DOUBLE
1 CSIN COMPLEX COMPLEX
Trigonometric cosine (radians) cos(z) 1 COS REAL REAL
1 DCOS DOUBLE DOUBLE
1 CCOS COMPLEX COMPLEX
Trigonometric tangent (radians) tan(z) 1 TAN REAL REAL
Trigonometric cotangent (radians) cot(z) 1 COT REAL REAL
Hyperbolic sine sinh(z) 1 SINH REAL REAL
Hyperbolic cosine cosh(z) 1 COSH REAL REAL
Hyperbolic tangent tanh(z) 1 TANH REAL REAL
Hyperbolic cotangent coth(z) 1 COTH REAL REAL
Square root z½ 1 SQRT REAL REAL
1 DSQRT DOUBLE DOUBLE
1 CSQRT COMPLEX COMPLEX
Arcsine (radians) sin-1(z) 1 ASIN REAL REAL
Arc-cosine (radians) cos-1(z) 1 ACOS REAL REAL
Arctangent (radians) tan-1(z) 1 ATAN REAL REAL
1 DTAN DOUBLE DOUBLE
range is -π to π tan-1(z1/z2) 2 ATAN2 REAL REAL
2 DATAN2 DOUBLE DOUBLE
Arc-cotangent (radians) cot-1(z) 1 ACOT REAL REAL
Inverse hyperbolic sine sinh-1(z) 1 ASINH REAL REAL
Inverse hyperbolic cosine cosh-1(z) 1 ACOSH REAL REAL
Inverse hyperbolic tangent tanh-1(z) 1 ATANH REAL REAL
Inverse hyperbolic cotangent coth-1(z) 1 ACOTH REAL REAL
Remaindering (modulo) z1(mod z2) 2 DMOD DOUBLE DOUBLE
Modulus 1 CABS COMPLEX COMPLEX

L.4.3 CHARACTER ROUTINES

L.4.3.1 Introductions

The FORTRAN language does not define character variables as distinct from other variable types (for example, REAL, INTEGER, COMPLEX and LOGICAL) although TEXT constants are permitted and characters may be read in at object time or initialised in the FORTRAN program. If, however it is attempted to manipulate characters using arithmetic statements, or to compare characters using the arithmetic or logical IF statements, overflow may be set.

It should be noted that if use were made in the source program of the internal form of 1900 characters in order to manipulate them arithmetically, the program would be particularly difficult to modify for compilation and running on other machines (and vice versa).

The following subroutines and functions have been provided in the 1900 FORTRAN libraries to facilitate character manipulation and comparison. These avoid setting of overflow and ensure that for re-compilation under any given FORTRAN system, re-programming is reduced to providing alternatives for these routines.

L.4.3.2 COMP

SUBROUTINE COMP(I,A,J,B,K)

This routine compares two character strings for equality. The character strings are contained in the scalars A and B. The first argument I defines the number of characters to be compared. If the characters in A and B are numbered from 1 upwards (the most significant character is numbered 1), comparison starts with the Jth character of A and the Kth character of B. The routine returns in I the number of characters for which identity exists before the first non-identical pair is found. Negative or zero values of I, J or K set overflow and return. An example is:

      I = 4
      A = 'ABCDEFGH'
      CALL COMP(I,A,2,'PPPBCGHJ',4)

This would compare the four characters BCDE of the first string with the four characters BCGH of the second string. Only the first two characters are the same so the routine returns the value 2 in I. There is no reason why the strings to be compared should not cross word boundaries. However, this is probably only useful when the strings are stored in consecutive array elements.

L.4.3.3 COMP8

SUBROUTINE COMP8(A,B,I)

This routine compares the two 8-character strings in A and B for equality. The argument I is set to 1 if the strings are identical, otherwise it is set to 2. A and B can be of any type provided they are two 1900 24-bit words in length.

L.4.3.4 COPY8

SUBROUTINE  COPY8(A,B)

The 8 characters in B are copied into A.

L.4.3.5 COPY

SUBROUTINE COPY(I,A,J,B,K)

The arguments are similar to COMP. The routine copies I characters from B into A. Copying starts from the Kth character of B and the Jth character of A. Negative or zero values of I, J or K set overflow and return. Consider the following example:

      I=11
      B(1) = 'ABCDEFGH'
      B(2) = 'IJKLMNPQ'
      A(1) = 'RRRRRRRR'
      A(2) = 'SSSSSSSS'
      CALL COPY (9,A(1),3,B(1),5)

The final values of A(1) and A(2) will be:

      A(1) = 'RREFGHIJ' 
      A(2) = 'KLMSSSSS'

L.4.3.6 ICOMP

INTEGER FUNCTION ICOMP(I,A,J,B,K)

This function is used to indicate the alphabetical order of two character strings. The arguments are similar to COMP. The function compares I characters of A and B starting at the Jth character of A and the Kth character of B. On return, the value of I is set to the number of characters that are identical before the first non-identical pair. The value of the function is returned as zero if the two strings are the same. If the strings are different, the value of the function returned is +1 or -1 depending on whether the higher valued character of the non-identical pair is in A or B respectively. For example:

      I = 5
      J =  ICOMP(I,'ABCDEFGH',1,'ABCDZFGH',1)

This function call would set I to 4 and J to -1 as Z has a larger value than E.

In making the comparison, a space character is taken as having the value zero. If the internal value of space is to be used, the value of I should be -N on input where N is the number of characters to be compared. The internal code value of space is 16 so that, as long as alphabetic strings are being compared (the alphabet has internal code values 33 to 58), both modes are equivalent. The correct mode must be specified if the strings contain digits (internal code values 0 to 9). For example:

      J = ICOMP(I,'ABCD XXX',1,'ABCD3XXX',1)

If I is set to 5 on input then J will be set to -1 as the internal code of the digit 3 is greater than zero. However, if I had the value -5 on input, J would be set to +1.

The user should note that this function is abnormal as it returns a value in one of its arguments. If a routine using ICOMP is to be compiled by XFEH, an ABNORMAL declaration (L.2.3.5) must be included.

L.4.4 DIRECT ACCESS BACKING STORE PACKAGE

This is a set of routines which access disc files directly (not serially). Whole or partial arrays may be transferred to and from store. Users are recommended to use the direct access READ and WRITE statements with numbered records in preference to this package.

L.4.5 SERVICE ROUTINES

L.4.5.1 Introduction

A number of subroutine and function segments are provided in the FORTRAN libraries to carry out miscellaneous services. These include interrogation of the computer clock, setting and interrogation of switches, testing and resetting of overflow and access to the date. Some of these are listed below. (Further information can be found in Chapter 5 of TP 4314.)

L.4.5.2 DATE

SUBROUTINE DATE(A)

The scalar A is of any type but must be at least two words in length. The first two words of A contain 8 characters in the form dd/mm/yy (dd is the day, mm is the month and yy is the last two digits of the year).

L.4.5.3 DEFBUF

SUBROUTINE DEFBUF(N,I,A)

The arguments are:

N : an integer channel number
I : the maximum length of the record in characters
A : an array name or array element of any type.

The subroutine is used to specify an array for use as a buffer which will be associated with a specified channel number, so that READ and WRITE statements referring to that channel will cause transfers of records to and from the array instead of to and from a peripheral device. DEFBUF is used in conjunction with a special form of program description I/O statement:

      USE N = /ARRAY

where N is the channel number used in DEFBUF. INPUT or OUTPUT can be used in place of USE. This program description statement must be provided if DEFBUF is used.

L.4.5.4 FMOVE

SUBROUTINE FMOVE(A,B,J)

A,B are array names or array elements of any type while J is the number of 48-bit words transferred from A (in column order) to B. If A is COMPLEX or DOUBLE PRECISION, J must be twice the number of elements to be transferred while if A is COMPRESS INTEGER, J must be half the number of elements to be transferred. A reduction in execution time by at least a factor of 12, compared with the equivalent DO loop, can be expected for REAL arrays. Both A and B can be the same array. This can be useful for clearing arrays:

      A(1)=0.0
      CALL FMOVE(A(1),A(2),100)

L.4.5.5 ITIME

SUBROUTINE ITIME(I)

The argument is an integer variable or array element (but not a constant or expression). The subroutine interrogates the hardware clock. The time of day in seconds since midnight is given in I as a binary integer.

L.4.5.6 OVERFL

SUBROUTINE OVERFL(I)

The argument I is an integer variable or array element. The overflow indicator is tested and then cleared. I is set to 1 if overflow is set in the calling segment and to 2 if overflow is not set.

L.4.5.7 RLEASE

SUBROUTINE RLEASE(N)

The argument N is an integer expression representing the channel number.

The peripheral associated with that channel number in the program description is released, unless it has already been released, in which case the subroutine has no effect. In the case of a disc file that has been extended, on execution of RLEASE the following message will be output to the monitoring file:

CHANNEL N NOW M BUCKETS

M is the new size of the file in buckets.

Any further READ or WRITE to-this channel will cause the program to fail unless remedial action has been taken at GEORGE level.

L.4.5.8 SSWTCH, SWOFF and SWON

SUBROUTINE SSWTCH(I,J)

This routine tests the state of a sense switch. The argument I is the number of the sense switch (an expression of type INTEGER having a value in the range 0 to 8 inclusive). The argument J is the result and is an integer variable or array element. It is set to 1 if the switch is on and 2 if it is off.

SUBROUTINE SWOFF(I) SUBROUTINE SWON(I)

These routines switch off or switch on a sense switch. I is the number of the sense switch and must be of type INTEGER and be in the range 0-8 inclusive. In the above routines, I determines which bit in word 30 of the program or switch is being referred to. Bit 0 is used to control trace output; bits 1-8 may be used for any purpose chosen by the programmer; bits 9-23 are reserved for the FORTRAN system. Switch 9 turns off overflow checks.

L.4.5.9 TIME

SUBROUTINE TIME(A)

A is a variable or array element of any type, but must be at least two 1900 words in length.

The time is returned in text form in A. The first two words of A are set to the 8 characters hh/mm/ss where hh,mm,ss are hours, minutes and seconds since midnight, respectively.

L.4.6 LOGICAL AND SHIFTING FUNCTIONS

L.4.6.1 Introduction

Several functions to perform logical operations and shifting functions on COMPRESSed integers are available in the standard FORTRAN library, SRF8. They are called in the same way as any other SRF8 routine, for example, MOD, ABS, etc. No special parameters or instructions are required. For the logical routines, each function lines up the two words, specified as arguments, so that corresponding bit positions are paired. The appropriate logical operation is then performed on each pair of bits. No special significance is given to the sign bit. For shifting functions, the word defined by the first argument is shifted by the number of bits specified by the second argument(J). Left shifts occur for 0<J<24 while right shifts occur for -24<J<0. No checks are made on the validity of J; the user should note that |J|<24 may change the nature of the shift.

L.4.6.2 IAND

LOGICAL FUNCTION IAND(I,J)

The function IAND performs a logical product (AND) of the arguments I and J. When an AND is performed on two bits, the result is one if both bits are one, otherwise it is zero. For example:

1 and 1 gives	1
1 and 0 gives	0
0 and 1 gives	0
0 and 0 gives	0

This operation is frequently used for masking off certain parts of a word.

L.4.6.3 IOR

LOGICAL FUNCTION IOR(I,J)

IOR performs a logical inclusive or (OR) of the arguments I,J. When an OR is performed on two bits, the result is one if either or both bits are one. It is zero if both bits are zero. For example:

1	or 1	gives	1
1	or 0	gives	1
0	or 1	gives	1
0	or 0	gives	0

This operation can be used to change particular bits in a given word leaving the others unchanged, and also to construct words from characters.

L.4.6.4 IER

LOGICAL FUNCTION IER(I,J)

IER performs a logical exclusive or (ER) of the arguments I,J. This is sometimes called non-equivalence. When an ER is performed on two bits, the result is only one if the two bits being operated on are different. For example:

1	or	1	gives	0
1	or	0	gives	1
0	or	1	gives	1
0	or	0	gives	0

The instruction is used mainly to invert the state of bits being used as switches.

L.4.6.5 INOT

LOGICAL FUNCTION  INOT(I)

The argument I is complemented on a bit by bit basis so that every 1 becomes 0 and every 0 becomes 1. This is done by an ER of the argument with -1.

L.4.6.6 ISLL

LOGICAL  FUNCTION  ISLL(I,J)

The function ISLL performs a logical left shift of I by J bits (J>0); excess bits are lost. A right shift takes place for J<0.

L.4.6.7 ISLC

LOGICAL FUNCTION ISLC(I,J)

The function ISLC performs a circular left shift of I by J bits (J>0); excess bits re-appear at the other end of the word. Right shifts take place when J<0.

L.4.6.8 ISLA

INTEGER FUNCTION ISLA(I,J)

The function ISLA performs an arithmetic left shift of I by J bits (J>0). However, unlike the previous functions, ISLA gives significance to the sign bit. It will change the state of the overflow register if there is a change in the state of the sign bit of the accumulator at any time during the operation. It can be used to multiply by powers of two, the ISLA function being faster than the multiply instruction.

The right shift (J<0) not only shifts the contents of the first argument by J places but also:

  1. fills the spaces created at the left-hand end with whatever was in the sign bit,
  2. adds in at the right-hand end the value of the last bit to drop off.

This means that integer divisions are rounded to the nearest whole number unlike FORTRAN divisions which truncate the result at the decimal point. For example:

I = 7 and J = 2
M = I/J        gives M = 3
M = ISLA(I,-J) gives M = 2

L.4.7 ADDITIONS TO THE RUN-TIME I/O PACKAGE

There are some important additions to the FORTRAN run-time I/O package. The modified routines are held in the standard package and are called from SUBGROUPSRF8. The main differences are described below.

  1. Card reader, card punch and lineprinter channels will cope with records up to and including 2000 characters in length - the maximum normal record length in a GEORGE file. This is the default.
  2. A specific length for a lineprinter channel (for example LP0/96) is specified in the program description will override the default.
  3. In any case, the default for any of these types (LP,CP,CR) can be changed by calling the library routine RESETLENGTH. It has two arguments, the channel type (3=CR, 4=CP, 2=LP), and the new default size. The default size must be between 80 and 2000, and does not include the PFCC for lineprinter channels.
  4. End of file will be detected on card reader channels if an attempt is made to read beyond the end of a GEORGE file. This is in addition to the usual facility to recognise a card beginning **** as end of file.
  5. The choice of **** for end of file can be altered by calling the library routine RESETEOF with a text argument of 4 characters. For example: 
          CALL RESETEOF(4H////)
    If a text of four spaces is given, only the true end of the GEORGE file will be detected. Use of this routine also affects the characters punched on a card punch channel for a FORTRAN ENDFILE statement, and at the end of the program.
  6. One channel of types CR and CP can be designated as special by calling the routine RESETCHAN. For example: 
          CALL RESETCHAN(14)
    This reserves CR14 and CP14 for special use. An attempt to read from the special card reader channel will cause the next (initially 1st) parameter of the last ENTER, LOADENTER or RESUME command to be read. An attempt to write to the special card punch channel will cause the record to be obeyed as a GEORGE command (see the example program below for examples of this facility).
  7. Channels CR7, CP7 and LP7 are treated like any other channels and are not double buffered.
  8. These facilities all apply to card reader and punch channels specifying card code conversion. An option to use an arbitrary conversion table can be made available if requested.
FORTRAN COMPILATION BY #XFIH MK 1C  DATE 15/03/74   TIME 11/44/58
0000                 LIST
0001                 PROGRAM (XMPL)
0002                 INPUT 5 = CR0
0003                 OUTPUT 6 = LP0
0004                 INPUT 115 = CR15
0005                 OUTPUT 215 = CP15
0006                 OUTPUT 7 = CP0/ATLAS
0007                 END
                     
0008                 MASTER COPY
0009           C     
0010           C     THIS ROUTINE COPIES A FILE (INCLUDING ANY **** CARDS)
0011           C     CONVERTING THEM FROM 1900 CODE TO ATLAS CODE.
0012           C     IT USES CR15 TO READ THE FILENAMES (%A AND %B ON THE
0013           C     ENTER COMMAND), AND CP15 TO ACTUALLY ASSIGN THE FILES.
0014           C     
0015                 INTEGER A(3),B(500)
0016           C     
0017                 CALL  RESETEOF(4H    )
0018                 CALL RESETCHAN(15)
0019                 READ(115)A
0020                 WRITE(215,100)A
0021                 READ(115)A
0022                 WRITE(215,101)A
0023            100  FORMAT('ASSIGN *CR0,',3A4)
0024            101  FORMAT('ASSIGN *CP0,',3A4)
0025           C     
0026               1 READ(5,200,END=9)B
0027                 WRITE(7,200)B 
0028                 GOTO   1
0029            200  FORMAT(500A4)
0030           C     
COMMENT 178 IS THIS LARGE  A REPEAT  COUNT  INTENDED AT ABOUT  COL   15,   LINE 0029?
0031               9 PAUSE   'OK'
0032                 STOP
                     END
END OF  SEGMENT, LENGTH  51,  NAME  COPY  =  COMMENTS

L.5 PROGRAM TESTING

L.5.1 COMPILATION ERROR DIAGNOSTICS

During compilation various checks are made and diagnostic messages may be output on the listing. All the compilers produce self-explanatory messages in words, but due to the nature of the compilers some errors not detected by XFIH may be found by XFEH. There are three types of diagnostic messages, as follows:

  1. ERRORS: The program contains a mistake that the compiler cannot rectify. No more semicompiled program is output but compilation usually continues so that any further errors may be detected.
  2. WARNINGS: The program contains something that is not strictly accurate but will not prevent compilation from continuing; for example, redundant characters may be present at the end of a source statement.
  3. COMMENTS: A comment will be given when a source statement is permissible but probably contains something that is unintentional; for example, a label may have been attached to a specification statement. Compilation.will continue.

L.5.1.1 Format of Diagnostic Messages

Each ERROR, WARNING and COMMENT detected during compilation will cause an explanatory message containing the following information to be printed:

  1. ERROR, WARNING or COMMENT
  2. The error, warning or comment number
  3. The reason for the message
  4. The line number of the source program to which the message refers
  5. The column number, when applicable. This indicates that the message refers to something at or before the column specified.

The line and column numbers are not always given, and the line number may not always be correct, particularly if the statement contains continuation or comment lines.

The format of diagnostic messages differs slightly depending on the mode of listing and on the compiler used; in full list mode, errors may be reported following the source statements in error, but some will be listed at the end of the segment. The messages will not necessarily appear in the same order as the source lines in which they occur and a column number will not always be given. Where a statement extends to more than one line, errors reported against the first line not containing a column number may refer to errors in a continuation line. Where an error cannot be attributed to a particular source line, the compilers will give no line number.

L.5.1.2 Other Messages

If any diagnostic messages occur during compilation, this fact will be reported at the end of the listing to enable errors in large compilations to be found easily. For example, consider the message:

END OF SEGMENT SOLVE, LENGTH 1724 - WARNINGS

If this is printed at the end of the segment listing, it indicates that one or more warnings and possibly comments have occurred in the segment. This message will be printed in SHORTLIST and LIST modes only.

At the end of compilation, the total numbers of errors, warnings and comments will be given individually, for example:

END OF COMPILATION - 12 ERRORS, 2 WARNINGS

An upper limit is imposed on the number of diagnostic messages that can be given and if this limit is reached one of the following messages will be output:

Situation                                Resulting Message
Too many errors, warnings and comments   ETC
in any one statement
Too many comments in any one segment     FURTHER COMMENTS SUPPRESSED IN THIS SEGMENT
Too many errors and warnings in any      FURTHER ERRORS SUPPRESSED IN THIS SEGMENT
one segment
Too many errors, warnings and comments    TOO MANY ERRORS, WARNINGS AND COMMENTS
in the program                            -LISTING SUPPRESSED-COMPILATION ABANDONED

L.5.1.3 Spurious Errors

The occurrence of one error may lead the compiler to produce further spurious errors later in the program. Consider the following sequence:

      COMMON /ABLE/ J,K;A(10)
      ..................
      READ (1,2) M,A,K 
      .........
      WRITE (2,A)

An error will be reported because of the semicolon in the COMMON statement. As a result the compiler will not register A as an array and will treat it as a variable in the READ statement; then in the WRITE statement an error will be reported because in this context A must be a FORMAT label or an array name. The reasons for such spurious errors are not always easy to find. If the cause of certain error messages cannot be ascertain then obvious errors should be corrected and the program recompiled; any spurious errors will then disappear.

L.5.1.4 Missing Segments

If some segments of a program are not present when consolidation is carried out, a loadable program is still produced but the following message will be printed:

SEGMENTS MISSING

An incomplete program should only be run if it is known that the missing segments will not be entered during that run. Any attempt to enter a missing segment will cause execution error 104 to be reported. The program cannot be continued even if an error trap routine is present.

The message DISPLAY MO is output to the monitoring file and may be tested for in the job description by a command of the form:

IF DISPLAY (MO) ,......

L.5.2 OBJECT PROGRAM ERROR DIAGNOSTICS

The discovery of the causes of run-time error conditions can be an expensive process, involving wastage of machine time and programming effort. For this reason it has become standard practice to incorporate monitoring routines into programs; these routines carry out tests during execution and output details of any error conditions that occur. All compiled FORTRAN programs contain monitoring routines and are said to be traced. The necessary routines are incorporated by the compilers and no extra programming is required.

The advantages of tracing are obtained at the cost of increased running time and core store requirements. The amount by which these two factors are increased is determined by the level of tracing used, that is, by the comprehensiveness of the tests carried out by the monitoring routines. The higher the level of tracing the longer will be the execution time and the greater will be the core store occupied.

The complete set of program testing facilities described in this section is available for use with XFIH. It is envisaged that this compiler will be used for program development since its wide range of diagnostic facilities will considerably ease the task of program testing and debugging. Fully tested programs should then be recompiled by XFEH prior to operational running, as this compiler employs special compiling techniques to produce faster object code.

Whichever compiler is used, the level of tracing that should be incorporated into a program is determined by the relative importance of two conflicting requirements; run-time efficiency and ease of error finding. During the early stages of the development of a program, ease of error finding will be the most important factor and a high level of tracing is suitable. When the program has been fully tested and proved, a lower trace level may be used with a corresponding increase in run-time efficiency. To provide for this variation three levels of tracing are available: 0, 1 and 2, being low, medium and high levels respectively.

L.5.2.1 Trace Level Specification

The level of tracing to be incorporated by the compiler is specified using the TRACE statement. The statement may be used either as a program description statement or as an intersegment statement and takes the form:

      TRACE n

The parameter n is the highest level of tracing required. If the TRACE statement is omitted, XFIH automatically incorporates TRACE 1 facilities, while XFEH assumes that TRACE 0 is required; these are also the levels of tracing provided by the default program descriptions.

L.5.2.2 Trace Output Channel

Trace information will normally be output on the first output channel specified in the program description; if the default program description is used, this will be channel 2, connected to LP0. The user should ensure that the channel used will accept formatted output. The trace output channel may be used for output of other information as well as trace output; if channel number 0 is used in WRITE statements, information will be output on the trace output channel whatever its channel number.

For example, a program description might consist of:

      PROGRAM (JIM5)
      INPUT 9 = TR0 
      OUTPUT 3 = LP0 
      OUTPUT 5 = TP1 
      END

In this case the trace information will be output on the lineprinter, which is also used by the program as unit 3.

L.5.2.3 Trace Level 1

Trace level 1 is automatically incorporated by XFIH if no TRACE statement is given, or if the default program description is used. If XFEH is used, the following statement must be present:

      TRACE 1

The effects of tracing at level 1 are described below:

  1. Normal error action: The occurrence of a detectable error causes the message: 
    EXECUTION ERROR n PROGRAM TERMINATED
    This is output on the trace output device where n is an error number; a full list of error numbers is given in L.6.2. The next part of the output is headed: 
    TRACE 1 POST MORTEM
    This consists of the names of the segments through which control has passed. In this context, a segment name may be the name of a FORTRAN source segment (or the name of an entry point in a FORTRAN source segment) or the name of a basic external function. The segment names are truncated to 8 characters. The order of segment names in the post mortem is such that the last segment entered is listed last. Following the post mortem, the following heading is printed: 
    SEGMENT HISTORY
    This is followed by the names of all the segments that have been entered but not yet left; thus the list shows the depth reached by the program. The last segment entered appears at the top of the list.

    After printing the segment history, the program releases its peripherals and halts, sending the following message to the monitoring file:

    HALTED: EE
  2. Overflow: Overflow may occur if the result of an arithmetic expression or the result of evaluating part of an arithmetic expression is out of range, or if the program attempts to carry out some mathematically undefined action such as division by zero. Overflow may also occur during the evaluation of a logical expression that compares two arithmetic expressions if the difference between the two is out of range; this is most likely to occur during the evaluation of logical IF statements.

    If overflow occurs, an overflow indicator is set and the program continues. A test on the state of this overflow indicator is made prior to an entry to or exit from every compiled subroutine or function segment and every basic external function. If the overflow indicator is found to be set, execution error 50 is reported.

    The library subroutine OVERFL is provided in the FORTRAN compiler libraries to enable the user to check the state of overflow in his program (L.4.5.6).

    Note: The point in the program at which overflow is detected may differ depending on which compiler is used. This subject is discussed more fully in L.3.2.1

    3. .
  3. The error trap facility: The user may augment the standard trace facilities by providing a subroutine to be entered whenever an error is discovered by the trace routines. Such a subroutine is called an error trap. An error trap may be written to output specialized information chosen by the user rather than by the system, or in certain cases it could contain coding to carry out some remedial action enabling the program to continue.

    An error trap is set up by a call to the library subroutine FTRAP. The single argument of FTRAP must be the name of a subroutine which is the user's error trap routine, and this name must therefore be declared in an EXTERNAL statement. Thus, if the error trap routine is called PMORTM, the calling segment would contain the following statements: 

          EXTERNAL PMORTM
      CALL FTRAP   (PMORTM)

    The subroutine FTRAP need only be called once in a program and will normally be called at the beginning.

    The error trap subroutine itself must be preceded by the intersegment statement:

          ERROR TRAP

    The subroutine must be written with one dummy argument of type INTEGER. When an error is detected, the subroutine will be entered with this argument set equal to the error number as listed in L.6.2 with the exception of error 0 which is dealt with below. Thus, the subroutine PMORTM might be written as follows:

          SUBROUTINE  PMORTM(ERRNO) 
      INTEGER ERRNO
      COMMON /ABCD/ARRY(10),X,Y,Z 
      WRITE(0,101)ERRNO,ARRY,X,Y,Z
 101  FORMAT(1H  ,6HERROR,I3/1H,,10E10.4/1H   ,3E10.4) 
      STOP
      END

    This subroutine outputs the error number, followed by the current value of an array and three variables, on the trace output channel (L.5.2.2).

    If the error results from an unacceptable character in a numeric input field (that is, error 0 'x' as listed in L.6.2) then the argument of the error trap subroutine is not set to the error number, but is set to the negated internal representation of the offending character x; hence, if the argument is negative, it should be made positive and its text value will then be 4H000x. The example above could be expanded to take care of this as follows:

          SUBROUTINE PMORTM(ERRNO)
      INTEGER ERRNO
      COMMON  /ABCD/ARRY(10),X,Y,Z
      IF(ERRNO.GT.0)GOTO  5
      ERRNO=-ERRNO
      WRITE(0,100)ERRNO,ARRY,X,Y,Z
      STOP 
 5    WRITE (0,101) ERRNO, ARRY, X,Y,Z
 100  FORMAT(1H ,7HERROR'    ,A4,1H'/1H ,10E10.4/1H ,3E10.4)
 101  FORMAT(1H ,6HERROR ,I3/1H ,10E10.4/1H ,3E10.4) 
      STOP 
      END

    If the programmer requires the program to continue after entry to the error trap routine, the routine should contain a RETURN statement instead of a STOP statement. For non-fatal errors, control will then return to the point in the program at which the error was detected and the operation that caused the error will have a meaningless result. For fatal errors it is not possible for the program to continue, and if a RETURN statement is executed the program will output the standard post mortem information and halt. The list of error numbers given in L.6 shows which errors are fatal and which non-fatal.

    The user may set up a different error trap at any point in the program by calling FTRAP with a different argument. Alternatively, the standard error procedure may be reinstated by calling the subroutine PRESET. This subroutine is called by the statement:

          CALL PRESET

    Its effect is to cancel any previous call to FTRAP. Beware of the use of ERROR TRAP with XFEH (L.3.2.1).

L.5.2.4 Trace Level 0

Tracing at level 0 is incorporated automatically by XFEH if no trace level is specified or if the default program description is used.

The limited facilities provided form a subset of trace level 1 facilities. On detection of an error, the standard error message is output giving the error number. However, no POST MORTEM or SEGMENT HISTORY lists follow. There is no user error trap facility and no test is made on the state of the overflow register. The detection of an error always causes the program to be terminated.

Trace level 0 will be incorporated by the compilers if the following statement is present in the program description or as an intersegment statement:

      TRACE 0

If TRACE 0 is specified as an intersegment statement, succeeding segments will be compiled at that level until another TRACE statement is encountered.

Segments generated for inclusion in non-FORTRAN programs should be traced at level 0.

  1. Mixed error detection levels: During development of a program, it may be convenient to run parts of it at different trace levels. The highest level of tracing used must be specified in the program description and the levels of tracing to be incorporated in the individual segments should be determined using TRACE as an intersegment statement; each segment will be compiled at the level set by the preceding TRACE statement.
  2. Suppression of trace output: Output of trace information may be suppressed during the running of a program by switching off switch 0 by a call to the library subroutine SWOFF. The normal error information will still be output if an error occurs while switch 0 is switched off. Switch 0 can be switched on again by a call to the library subroutine SWON or by use of the GEORGE command ON. SWOFF and SWON are described in L.4.5.8.
  3. User-defined errors: It may be required to obtain the standard post mortem or error action as a result of an error detected by the user's program. The library subroutine FERROR is available for this purpose.

    The subroutine is called by a statement of the form: 

          CALL  FERROR(N)

    where N is an integer variable or constant in the range 900<N<999.

    This statement may be written anywhere in a program and will cause the standard error action (depending on the level of tracing incorporated) to take place, execution error N being reported. If a user error trap routine is present then control will pass to it as for a standard execution error.

    If N takes the special value 999, no execution error will be reported; instead, the standard post mortem information will be output, all peripherals will be released and the program will halt with the message HALTED EE. This facility will be useful in an error trap routine.

    If N is outside the permitted range, execution error 47 will be reported.

    For example, if a variable named POS should never take a negative value at any point during execution of a program, the following statement could be included:

          IF(POS .LT. 0.0)CALL FERROR(918)

    This would cause execution error 918 to be reported if the statement were executed when POS was negative, and standard error action would ensue.

L.5.3 FOOTPRINT ROUTINES

This package is a FORTRAN source tracing suite and consists of three separate programs FORP, FORI and FORA, which together can be used to provide static and dynamic analyses of the usage of statement types in a FORTRAN program.

FORP is a preprocessor which inserts extra lines into the FORTRAN source, so that when the program is subsequently compiled and run, counts are kept of the number of times each executable statement is performed. These counts are then output at the end of the run on to either cards or paper tape.

FORI reads these counts and the preprocessed FORTRAN source, and produces as output the original source program, with most of the inserted lines removed, and with the execution frequency counts inserted in the identification fields (columns 74-80) of all executable statements. This output is referred to as the program with its 'program profile1. It may be output to the lineprinter and optionally to either cards or magnetic tape.

FORA reads a FORTRAN source program and prints out a list of all statement types used in the program, at segment and program level, giving for each one a static frequency count (ie the number of times it occurs in the source). If the input source has a program profile, FORA will also give dynamic frequency counts (ie the number of times each executable statement, type was executed during the running of the program).

Figure L.1 shows the various stages it is necessary to go through in order to obtain a static and dynamic analysis of a FORTRAN source program.

For further information concerning FOOTPRINT, users are advised to contact the Program Advisory Office at ACL.

Figure L.1:
FORP FORTRAN Source Parameters Optional Listing Preprocessed Source Compile and Run Execution Frequency Counts FORI Optional Listing Parameters Source with Program Profile Option FORA Parameters Static and Dynamic Anaylsis

L.6 ERROR DIAGNOSTICS

L.6.1 COMPILATION ERRORS

The complete list of compilation error messages can be found by supplying as the first and only statement of a program description, the statement:

      LISTALLERRORS

This should start at or beyond column 7.

L.6.2 EXECUTION ERRORS

The following table gives the interpretation of run-time error numbers. Those marked with an asterisk (*) are fatal. Errors not marked with an asterisk may be trapped and the program may be continued (L.5.2.3).

Error
number		 Interpretation
0'x' Incorrect character x has been found in an input field,
*01 Array subscript error. The generated address of an array element is outside the bounds of the array. This check is made only when the program is compiled in TRACE 2 mode. Alternatively, when the subroutine FMOVE is being used, the number of elements to be transferred exceeds the size of the array specified by the second argument. (This check cannot be made if an array element is specified by the second argument.)
*02 The TRACE steering list has incorrect format or is too long.
*03 The overlay depth has been exceeded.
*04 Reserved.
*05 Less than two arguments have been supplied for one of the library functions available for determining the maximum or minimum value of a number of items.
06 Reserved.
*07 Not enough arguments have been supplied for the subroutine called. This error is detected only when the object program is an overlay program.
*08 This error can only occur in mixed language programs. Too many arguments have been specified for a PLAN segment.
09 Dimension of an adjustable dummy array is not positive.
*10 Incorrect format specifications, for example, field separator missing, character out of place, or unrecognized character found.
*11 E format descriptor is associated with a non-REAL and non-COMPLEX item.
*12 I format descriptor is associated with a non-INTEGER item.
13 Reserved.
*14 L format descriptor is associated with a non-LOGICAL item.
*15 D format descriptor is associated with a non-DOUBLE PRECISION item, or F format descriptor is associated with a non-REAL, non-COMPLEX and non-DOUBLE PRECISION item.
*16 Zero or undefined field width when using the A, L, H or X codes.
*17 Data for logical item does not start with T, F, .T or .F.
*18 Format statement does not satisfy the input/output list.
19 Reserved.
*20 Channel number used in the program has not been associated with a peripheral in the program description,
*21 A formatted input record is too short.
*22 An unformatted input record is too short.
*23 Illegal operation attempted, for example read from card punch, or write to an input magnetic tape; or an attempt has been made to read or write: (1) serially to a direct access file (2) unformatted to a file described as formatted (3) formatted to a file described as unformatted
24-26 Reserved.
*27 An attempt has been made to use RENAME with an input file.
*28 An attempt has been made to use FILE or RENAME but a dummy file name has not been given in the program description statement.
*29 An attempt has been made to use FILE when the file is already open.
*30 Illegal sequence of operations on a serial file, for example read or write after ENDFILE.
*31 No filename specified for input device.
*32 Input file has incorrect format, for example no start-of-data sentinel found when opening input magnetic tape.
33 Reserved.
*34 End-of-tape mark detected when writing to magnetic tape
*35 Unformatted magnetic tape file misread or in wrong format. Data block count in trailer wrong.
*36 An attempt has been made to write a formatted record longer than the maximum permitted block or bucket size.
*37 Block size on input file exceeds buffer size specified in the program description.
38 Reserved.
*39 An attempt has been made to read a formatted record longer than the available buffer, or the bucket size in an unformatted file exceeds the buffer size.
40 Reserved.
*41 Failure of integrity code check on opening a direct access file.
*42 Purge date not exceeded on opening an output direct access file.
*43 System control area full when either: (1) Opening a direct access scratch file (2) Extending a direct access file (3) Renaming a direct access file.
*44 No space available either: (1) Opening a direct access scratch file (2) Extending a direct access file (3) Renaming a direct access file.
45 Reserved.
*46 Specified file not opened as an output file when renaming direct access file.
*47 Argument outside permitted range in FERROR.
48 Reserved.
49 Reserved.
50 The overflow register has been set in executing some previous statement (the immediately preceding statement if in trace level 2).
51 Reserved.
52 Reserved.
53 Result of EXP is out of range.
44 Result of DEXP is out of range.
55 Non-positive argument of ALOG.
56 Non-positive argument of DLOG.
57 Negative argument of SQRT.
58 Negative argument of DSQRT.
59 Both arguments of ATAN2 are zero.
60 Both arguments of DATAN2 are zero.
61 Second argument of ISIGN is zero.
62 Second argument of SIGN is zero.
63 Second argument of DSIGN is zero.
64 Second argument of MOD is zero.
65 Second argument of AMOD is zero.
66 Second argument of DMOD is zero.
67 Argument of ACOSH is not in the range x≥0.0
68 Argument of ATANH is not in the range -1.0<x<1.0.
69 Argument of ACOTH is not in the range x>1.0 or x<1.0.
70 Argument of ASIN is not in the range -1.0≤x≤1.0.
71 Argument of ACOS is not in the range -1.0≤x≤1.0.
72 Result of TAN is out of range.
73 Result of CABS is out of range.
74 Modulus of result of CSIN is out of range.
75 Modulus of result of CCOS is out of range.
76 Argument of NINT is out of range.
77 Result of IFIX is out of range.
78 Result of INT is out of range.
79 Depth of nesting exceeds capacity of the TRACE list.
*80 Error in the information block used by GENAH.
81 The array specified as the third argument of DEFBUF is not large enough to contain the number of characters specified in the second argument.
82 Semicompiled segments generated by XFAM/2C or earlier versions or by XFAP/1 or XFAC/1 have been included in programs compiled by the GEORGE compilers.
83 Illegal use of the subroutine FMOVE.
84 The number of elements transferred by the subroutine FMOVE is less than zero.
*85 A channel number in a DEFINE FILE statement does not refer to a direct access file.
*86 File not large enough (even with extension) to hold all the records defined in the DEFINE FILE statement.
*87 Record length in the DEFINE FILE statement is larger than the minimum of the buffer and bucket size.
*88 Relative position of a record is not a positive integer or exceeds the number of records in the data set.
*89 Formatted record too long.
*90 No previous DEFINE FILE statement.
*91 Disc file opened outside the system.
*92 DEFINE FILE statement does not correspond with previously created file.
*93 Core used has increased between dumps to a direct access file.
*94 Attempt to make more than 99 dumps to a file.
*95 The dump file is not named PROGRAM xxxx.
*96 The dump file on disc is too small to hold one dump.
*97 The file is not specified as a DUMP file.
*98 Misuse of monitor channel (for example BACKSPACE on Channel 0).
99 Reserved.
*100 The object program has reached an END statement.
101 There is insufficient room for this dump on the magnetic tape.
102 Dummy array exceeds limit of actual array (TRACE 2 only).
*103 Illegal array header, for example attempt to use a dummy array which has not appeared in a previously referenced entry
*104 Attempt to reference a missing segment, or a dummy segment which has not appeared in a previously referenced entry.
105 Attempt to read beyond end of data on a card input channel.
106 Attempt to read beyond end of data on a paper tape input channel.
*107 End-of-file encountered on magnetic tape input.
*108 End-of-file encountered on input from a serial disc file.
*109 Error in transfer on card input channel.
*110 Error in transfer on paper tape input channel.
*111 Error in transfer on magnetic tape input.
*112 Error in transfer on input from a serial disc file.
*113 Error in transfer on input from a direct access file.
*114 A call, with arguments, to an overlay segment has caused the calling segment to be overwritten.
115-120 Reserved.
*121 Attempt to write more than one record or to write too long a record in a single WRITE statement to a DEFBUF array.
122 Reserved.
123 Name in input data is not in current NAMELIST.
124 Error in &END field in NAMELIST input data.
125 Incorrect number of subscripts in array element in NAMELIST input data.
126 Error in array subscript in NAMELIST input data.
127 Attempt to read more data than can be held in an array in NAMELIST input.
128 Empty field in NAMELIST input data.
129 Missing = in NAMELIST input data.
130 Misplaced * in NAMELIST input data.
131 Complex constant expected in NAMELIST input data.
132 Complex constant incorrectly terminated in NAMELIST input data.
133 Input field size too large in NAMELIST input data.
134 End of record found when reading a text constant in NAMELIST input.
135-144 Reserved.
145 Incorrect format of text in NAMELIST data.
146 Name expected in NAMELIST data.
*147 Reserved.
*148 Reserved.
149 Reserved.
150-160 Reserved for FLAIR.
161-199 Reserved.
Error numbers 500 to 515 refer to direct access files used by the Direct Access backing store package.
*500 Insufficient space for reading from or writing to a. file (that is K specified incorrectly).
*501 Failure of integrity code check when opening a file
*502 Purge date not exceeded on an output file.
*503 Logical bucket number out of range (that is program corrupted).
*504 System control area full.
*505 No space available for extending a file or opening a scratch file.
*506 File does not have one block buckets.
*507 Attempt to write to a file opened by INFILE.
*508 Undeclared channel number used.
*509 More than 8 channel numbers declared.
*510 Incorrect format of parameters in opening procedure.
*511 Elements specified in GETPART or PUTPART are not within bounds or are incorrectly related.
*512 Channel number is outside the range 0≤k≤15.
*513 Not enough space available for scratch file (or file extension).
*514 Channel number already in use.
*515 Unit number already in use.

Error numbers 700 to 899 are reserved for use by ICL software which interfaces with the FORTRAN compilers. Error numbers 900 to 998 and *999 are available to the user for use with the subroutine FERROR.

L.7 SPECIMEN FORTRAN PROGRAM

C     TEST PROGRAM......RANDOM
C.............................
C
C     PROGRAM DESCRIPTION SEGMENT
C
      LIBRARY(RANDOM)
      LIST
      PROGRAM(EXMP)
      COMPRESS INTEGER AND LOGICAL
      ABNORMAL FUNCTIONS
      OUTPUT 1 = LP0
      INPUT 5 = CR0
      INPUT 6 = CR1
      INPUT 2 = CR2
      OUTPUT 7 = LP7
      CREATE 3 = MT3/FORMATTED
      USE 4 = DA4/FORMATTED
      END
C
      MASTER MANUAL
C..................
      COMMON  /COORDS/X(5000),Y(5000),2(5000) 
      NAMELIST  /LIST1/A,B,C,/LIST2/I,JJ,KARRAY 
      NAMELIST  /LIST3/X,Y,Z 
      DIMENSION  C(1000),KARRAY(500)
C
      READ(5,100)A,B,C
      READ(2,LIST3) 
      IF(A) 60,60,20 
   20 READ(6,LIST2)
      COUNT = B 
      LI   =  I
      ..........
      WRITE(3,LIST1) 
      WRITE(3,LIST2)
      ..........
      DO 50 KK =   1,5000
      RANDOMNUMBER=COUNT+103.0*G05ABF(0.0,1.0)
      X(KK) =X(KK)+RANDOMNUMBER*LZ
  50  CONTINUE
      WRITE(4,LIST3)
      .............
      IF(I.LE.100)GOTO  80 
 100  FORMAT(3F6.0)
 60   CALL SUBA(X,Y,Z)
      WRITE(7,LIST3)
      STOP'PROGRAM TERMINATED AT POS.1'
 80   CALL SUBENT(Y,Z)
      WRITE(7,LIST3)
      ................
      STOP'PROGRAM TERMINATED AT POS.2' 
      END
C
C
      SUBROUTINE  SUBA(X,Y,Z)
C     .......................
      DIMENSION X(5000),Y(5000),Z(5000)
      DO   10  J=I,5000 
      X(J)=X(J)/2.0
   10 CONTINUE
      ENTRY SUBENT(Y,Z)
      DO 20 K=1,5000
      Y(K)=Y(K)/2.0
      Z(K)=Z(K)/2.0
  20  CONTINUE 
      RETURN 
      END 
      FINISH

The TASK call to run this program would be as below:

TASK FORTRAN,*CRprogfilename,LIB(26,NAGLIBF),#CRdatafilename1,-
#CR1datafilename2,#CR2datafilename3,#LP7anyfilename,-
#MT3,#DA4(10,1)(SCRATCH)

For a description of TASK and its parameters see Part B. In this example, both the magnetic tape and disc area are used as scratch media - that is, the data is lost on completion of the program.

⇑ Top of page
© Chilton Computing and UKRI Science and Technology Facilities Council webmaster@chilton-computing.org.uk
Our thanks to UKRI Science and Technology Facilities Council for hosting this site