Fortran_Extended_4_Users_Guide_60499700A_Dec77 Fortran Extended 4 Users Guide 60499700A Dec77

Fortran_Extended_4_Users_Guide_60499700A_Dec77 Fortran_Extended_4_Users_Guide_60499700A_Dec77

User Manual: Pdf Fortran_Extended_4_Users_Guide_60499700A_Dec77

Open the PDF directly: View PDF .
Page Count: 112

Download
Open PDF In Browser	View PDF

60499700

CONTRPL DATA
CORPORATION

T.
FORTRAN EXTENDED VERSION 4
USER'S GUIDE

0^\

r

0$>,

CDC® OPERATING SYSTEMS:
NOS 1
NOS/BE 1
SCOPE 2

REVISION RECORD
DESCRIPTION

REVISION
A

Original release.

12/30/77

- *

,^\

Publication No.
60499700

REVISION LETTERS I, O. Q AND X ARE NOT USED

Address comments concerning
this manual to:
C O N T R O L D ATA C O R P O R AT I O N

Publications and Graphics Division
© 197?

Control Data Corporation
Printed in the United States of America

215 MOFFETT PARK DRIVE
SUNNYVALE, CALIFORNIA 94086

or use Comment Sheet in the
back of this manual
^^ls\

0£\

LIST OF EFFECTIVE PAGES

,#SN

New features, as well as changes, deletions, and additions to information in this manual are indicated by bars in the
margins or by a dot near the page number if the entire page is affected. A bar by the page number indicates pagina
tion rather than content has changed.

Page

0m\

Cover
Title page
ii
iii/iv
v/vi
vii tliru ix
1-1 thru 1-4
2-1 thru 2-13
3-1 thru 3-12
4-1 thru 4-17
5-1 thru 5-12
6-1 thru 6-18
7-1 thru 7-11
A-l thru A-3
B-l, B-2
Index-1 thru -3
Cmt. Sheet
Reply envelope
Cover

60499700 A

Revision

Page

Revision

Page

Revision

A
A
A
A
A
A
A
A
A
A
A
A
A
A
A

iii/iv

/^\

/*^\

0%\

r/S!%

PREFACE

0^\

This user's guide provides helpful information for the user of
CDC FORTRAN Extended. FORTRAN Extended is sup
ported by the following operating systems:

S o m e t o p i c s o f i n t e r e s t t o t h e F O RT R A N E x t e n d e d
programmer are discussed in other user's guides. These
include the following:

NOS 1 for the CONTROL DATA® CYBER 170 Models
171, 172, 173, 174, 175; CYBER 70 Models 71, 72, 73,
74; and 6000 Series Computer Systems

9 Interactive program creation and execution. For
NOS/BE, this topic is covered in the INTERCOM Guide
for FORTRAN Extended Users. For NOS users, parallel
material is included in the NOS Time-Sharing User's
Guide and the NOS Text Editor Reference ManuaK

NOS/BE 1 for the CDC® CYBER 170 Series; CYBER 70
Models 71, 72, 73, 74; and 6000 Series Computer
Systems

/0fe\

SCOPE 2 for the CONTROL DATA CYBER 170 Model
176, CYBER 70 Model 76, and 7600 Computer Systems
This user's guide is written primarily for the FORTRAN
programmer who is unfamiliar with CDC operating systems.
It is a supplement to the FORTRAN Extended Version 4
Reference Manual, with minimal duplication of information.
This guide concentrates on the interfaces between
FORTRAN Extended and other software products, as well as
on programming, debugging, and optimization techniques of
particular interest to the FORTRAN Extended programmer.

e Input/output implementation. This topic, with partic
ular emphasis on the advanced input/output capabilities
available through the CYBER Record Manager interface
routines, is covered in the CYBER Record Manager
Version 1 Guide for Users of FORTRAN Extended
Version 4. SCOPE 2 users can find parallel information
in the SCOPE 2 User's Guide.
9 Debugging facility. The C$ DEBUG capability included
with the FORTRAN Extended compiler is described in
the FORTRAN Extended DEBUG User's Guide.
In addition, user's guides exist for SCOPE 2 and NOS/BE;
these guides are recommended for programmers new to
these systems.

Publication

Publication Number

NOS 1 Operating System Reference Manual, Volume 1

60435300

NOS/BE 1 Operating System Reference Manual

60493800

SCOPE 2 Reference Manual

60342600

NOS/BE 1 User's Guide

60494000

SCOPE 2 User's Guide

60372600

FORTRAN Extended Version 4 Reference Manual

60497800

CYBER Loader Version 1 Reference Manual

60429800

SCOPE 2 Loader Reference Manual

60454780

FORTRAN Extended DEBUG User's Guide

60498000

INTERCOM Interactive Guide for
Users of FORTRAN Extended

60495000

CYBER Record Manager Version 1 Guide for
Users of FORTRAN Extended Version 4

60495900

FORTRAN Common Library Mathematical Routines

60498200

UPDATE Reference Manual

60449900

CYBER Common Utilities Reference Manual

60495600

/SjPN

CDC manuals can be ordered from Control Data Literature and Distribution Services,
8001 East Bloomington Freeway, Minneapolis, MN 55420
This product is intended for use only as described in this document.
Control Data cannot be responsible for the proper functioning of
undescribed features or parameters.

60499700 A

v/vi

^

^

*

CONTENTS

1.

PROGRAMMING TECHNIQUES

Top-Down Programming
Coding Style

SAMPLE PROGRAMS
A C C TA B
NEWTON
GAUSS
OTOD
LINK
CORCO

3.

0U^S

OPTIMIZATION

1-1
1-1
1-3
2-1
2-1
2-1
2-1
2-6
2-6
2-8
3-1

Compiler Optimization
Machine-Independent Optimizations
Invariant Code Motion
Common Subexpression Elimination
Dead Definition Elimination
Constant Evaluation
Test Replacement
Machine-Dependent Optimization
Strength Reduction
Special Casing of Subscripts
Functional Unit Scheduling
Register Assignment
Optimization Example
Source Code Optimization
Helping the Compiler Optimize
Loop Restructuring
Miscellaneous Optimizations
Programming for Greater Accuracy
Sum Small to Large
Avoid Ill-Conditioning

3-1
3-2
3-2
3-4
3-4
3-5
3-5
3-6
3-6
3-6
3-7
3-7

4.

4-1

DEBUGGING

3-8
3-9

3-9
3-9
3-10
3-11
3-11
3-11

Desk Checking
Compilation
Diagnostic Scan
Cross-Reference Map
Execution Time Debugging
DMPX and Load Map
Debugging Facility

4-1
4-1
4-1
4-4
4-4
4-7
4-7

5.

5-1

BATCH EXECUTION

Sample Job Decks
Job Processing Control Statements
Job Statement
ACCOUNT Control Statement
RESOURC Control Statement
EXIT Control Statement
REWIND Control Statement
RETURN Control Statement
UNLOAD Control Statement

60499700 A

5-1
5-1
5-1
5-1
5-2
5-2
5-4
5-4
5-5

Copy and Skip Operations
COPY Control Statement
COPYBF and COPYCF Control
Statements
COPYBR Control Statement
NOS/BE and SCOPE 2 Skip
Operations
NOS Skip Operations
Permanent File Usage
NOS/BE and SCOPE 2 Permanent Files
REQUEST Control Statement
CATALOG Control Statement
ATTACH Control Statement
ALTER and EXTEND Control
Statements
PURGE Control Statement
NOS Permanent Files
SAVE Control Statement
GET Control Statement
REPLACE Control Statement
DEFINE Control Statement
ATTACH Control Statement
PURGE Control Statement
Magnetic Tape Processing

LIBRARY FILES

5-5
5-5
5-6
5-6
5-6
5-7
5-7
5-7
5-8
5-8
5-8
5-8
5-8
5-9
5-9

5-9
5-9
5-9
5-10
5-10
5-10

6-1

User Libraries
NOS/BE and SCOPE 2 User Libraries
Directives in General
NOS/BE and SCOPE 2 Sample User
Library Creation
NOS/BE and SCOPE 2 Sample User
Library Modification
NOS/BE EDITLIB Control Statement
and Directives
SCOPE 2 LIBEDT Control Statement
and Directives
NOS User Libraries
Sample User Library Creation
Sample User Library Re-creation
LIBGEN Control Statement
LIBEDIT Control Statement and
Directives
GTR Control Statement
COPYL Control Statement
UPDATE Source File Maintenance
UPDATE Directives
UPDATE Control Statement
Creation Run
Decks
Sample Creation Run
Correction Run
Sample Correction Runs
UPDATE Listing

6-2
6-2
6-3

7 . L O A D I N G F O RT R A N P R O G R A M S

7-1

Basic Loading
Name Call Statement
EXECUTE Control Statement

7-1
7-2
7-2

6-3
6-4
6-4
6-4
6-6
6-6
6-6
6-8
6-8
6-8
6-10
6-12
6-12
6-13
6-13
6-13
6-14
6-15
6-15
6-16

>*^ls

/S5\

SLOAD Control Statement
LOAD Control Statement
NOGO Control Statement
LIBRARY Control Statement
LDSET Control Statement
Library Search Order
Field Length Control

7-2
7-3
7-3
7-4
7-4
7-4
7-5

Basic Load Examples
Segment Loading
Segmented Program Structure
Building a Segmented Program
Segment
Directives
Loading and Executing a Segmented
Program

7-5
7-6
7-6
7-7
7-8

7-10

APPENDIXES
Standard Character Set

A-l

Glossary

B-l

INDEX
FIGURES
1-1 Top-Down Programming Example
1-2 Coding Style Example
2 - 1 P r o g r a m A C C TA B
2-2 Second Degree Interpolation
2-3 Sample Input Deck
2 - 4 A C C TA B O u t p u t
2-5 Program NEWTON
2-6 Input to NEWTON
2-7 Output from NEWTON
2-8 Program GAUSS
2-9 Input to GAUSS
2-10 Output from GAUSS
2-11 Program OTOD
2-12 Arrays OCT and IA in Program OTOD
2-13 Program LINK
2-14 Record Format for INFIL
2-15 Record Format for NEWFIL
2-16 Program CORCO
2-17 Input Records for CORCO
2-18 Records on File PROBS
2-19 Formula for Correlation Coefficient
2-20 Printed Output from CORCO
3-1 Intermediate Language Example
3-2 Basic Block Example
3-3 Invariant Code Motion Example
3-4 Invariant Code (Example 1)
3-5 Invariant Code (Example 2)
3-6 Invariant Code (Example 3)
3-7 Variable Dead on Exit
3-8 Test Replacement Generated Code
3-9 FORTRAN Subprogram and Generated
Object Code
4-1 Program ACCTAB Before Debugging
4-2 Example after Desk Checking,
with Diagnostics
4-3 Cross-Reference Map
4-4 Example with Compilation Errors Corrected
4-5 Test Data for ACCTAB
4-6 Dayfile Showing Loader Errors and
Mode 1 Errors
4-7 Load Map
4-8 DMPX
4-9 Object Listing (Partial)
4-10 Dayfile Showing Mode 2 Error
4-11 Sequence of Debug Statements
4-12 Debug Output Showing Array Contents
4-13 Example with Zero Value Test
4-14 Dayfile Showing Mode 2 Error
4-15 Debug Output and Printed Output
4-16 Example with Duplicate Point Test
4-17 Output from Figure 4-16
4-18 Final ACCTAB Source Listing
4-19 Output from Figure 4-18
5-1 Compilation and Execution

1-2
1-4
2-2
2-3
2-3
2-3
2-4
2-4
2-4
2-5
2-6
2-6
2-7
2-8
2-9
2-10
2-10
2-11
2-12
2-12
2-13
2-13
3-2
3-2
3-3
3-3
3-3
3-3
3-5
3-6

5-2
5-3

3-8
4-2

5-23

4-3
4-5
4-6
4-7
4-8
4-9
4-11
4-12
4-12
4-12
4-12
4-13
4-14
4-14
4-15
4-16
4-16
4-16
5-2

5-4
5-5
5-6
5-7
5-8
5-9
5-10
5-11
5-12
5-13
5-14
5-15
5-16
5-17
5-18
5-19
5-20
5-21
5-22

5-24
5-25
5-26
5-27
5-28
5-29
5-30
5-31
5-32
6-1
6-2
6-3
6-4
6-5
6-6
6-1
6-8

E x e c u t i o n w i t h D a t a o n M a g n e t i c Ta p e 5 - 3
Execution of Binary Program with
Two Sets of Data Cards
5-4
Job Statement Format
5-4
ACCOUNT Control Statement Format
5-4
RESOURC Control Statement Format
5-4
5-4
EXIT Control Statement Format
5-5
REWIND Control Statement Format
5-5
RETURN Control Statement Format
5-5
UNLOAD Control Statement Format
COPY Control Statement Format
5-5
COPYBF and COPYCF Control Statement
5-6
Formats
5-6
COPYBF Example
5-6
COPYBR Control Statement Format
SKIPF and SKIPB Control Statement
5-6
Formats (NOS/BE, SCOPE 2)
SKIPB and SKIPF Examples (NOS/BE,
SCOPE 2)
5-7
SKIPF, SKIPBF, SKIPR, and BKSP Control
5-7
Statement Formats (NOS)
REQUEST Control Statement Format for
Permanent Files (NOS/BE, SCOPE 2)
5-8
CATALOG Control Statement Format
5-8
(NOS/BE, SCOPE 2)
ATTACH Control Statement Format
5-8
(NOS/BE, SCOPE 2)
EXTEND and ALTER Control Statement
Formats (NOS/BE, SCOPE 2)
5-8
PURGE Control Statement Format for
Attached Files (NOS/BE, SCOPE 2)
5-8
PURGE Control Statement Format for
Unattached Files (NOS/BE, SCOPE 2)
5-8
SAVE Control Statement Format (NOS)
5-9
GET Control Statement Format (NOS)
5-9
REPLACE Control Statement Format (NOS)
5-9
DEFINE Control Statement Format (NOS)
5-9
ATTACH Control Statement Format (NOS) 5-10
PURGE Control Statement Format (NOS) 5-10
LABEL Control Statement Format (NOS) 5-11
LABEL Control Statement Format (NOS/BE) 5-12
REQUEST Control Statement Format for
Ta p e s
(SCOPE
2)
5-12
NOS/BE and SCOPE 2 User Library Creation 6-2
Sample User Library Creation (NOS/BE,
SCOPE
2)
6-3
Output from Sample User Library Creation 6-5
NOS/BE and SCOPE 2 User Library
M o d i fi c a t i o n
6-6
Sample User Library Modification
(NOS/BE,
SCOPE
2)
6-6
Typical
LISTLIB
Output
6-7
EDITLIB Control Statement Format 6-8
LIBEDT Control Statement Format 6-8

/■**%

s*v&\

,*SS\

A^&K

A^&\

/^S\

A^S

60499700 A
y*SS?V

0s*
0^/|Sv

6-9
6-10
6-11
6-12
6-13

/ig#r^

v

0^\

y^^\

/Sfcv

v

6-14
6-15
6-16
6-17
6-18
6-19
6-20
6-21
6-22
6-23
6-24
6-25
6-26
6-27
6-28

NOS User Library Creation
Sample User Library Creation (NOS)
Listing of NOS User Library
COPYL Use in Re-creating a
User Library (NOS)
GTR and LIBEDIT Use in Re-creating a
User Library (NOS)
LIBGEN Control Statement Format
LIBEDIT Control Statement Format
GTR Control Statement Format
COPYL Control Statement Format
UPDATE Program Library Creation Run
UPDATE Program Library Correction Run
UPDATE Control Statement Format
Input Stream Cards
Sample Program Library Creation
Listing of Card Identifiers
Using a Routine on a Program Library
Sample Use of Program Library
Sample Correction Run Creating a
New Program Library
Listing from Corrected Deck
Typical UPDATE Output Listing

6-8
6-8
6-9
6-10
6-10
6-10
6-11
6-11
6-11
6-12
6-12
6-14
6-14
6-14 •
6-15
6-15
6-16
6-16
6-17
6-18

7-1
7-2
7-3
7-4
7-5
7-6
7-7
7-8
7-9
7-10
7-11
7-12
7-13
7-14
7-15
7-16
7-17
7-18
7-19
7-20
7-21
7-22
7-23
7-24

Name Call Statement Format 7-2
Alternate File Name Examples 7-3
EXECUTE Control Statement Format 7-3
SLOAD Control Statement Format 7-3
LOAD Control Statement Format 7-3
NOGO Control Statement Format 7-3
LIBRARY Control Statement Format 7-4
LDSET Control Statement Format 7-4
REDUCE Control Statement Format 7-5
RFL Control Statement Format 7-5
Basic
Load
7-5
Sample
Tree
Structure
7-6
Segmented Program with Three Levels 7-7
SEGLOAD Control Statement Format 7-8
TREE
Directive
Format
7-8
TREE
Directive
Examples
7-8
INCLUDE
Directive
Format
7-8
INCLUDE
Directive
Example
7-9
LEVEL
Directive
Format
7-9
GLOBAL
Directive
Format
7-9
END
Directive
Format
7-9
Segment Directives Example 1 7-10
Segment Directives Example 2 7-10
CALL-RETURN
C o n fl i c t
7 - 11

TABLES
3-1 Array Subscript Formulas
5-1 EXIT Processing
6-1 Utility Support

60499700 A

3-1
5-5
6-1

6-2
6-3
6-4
6-5

EDITLIB Directives
LIBEDT Directives
LIBEDIT Directives
UPDATE Directives

6-7
6-9
6-11
6-13

/^In

0®&\

/^Slg

PROGRAMMING TECHNIQUES

This section outlines some procedures designed to simplify
and safeguard the production of FORTRAN Extended pro
grams, as well as some techniques to improve their
a c c u r a c y. A l t h o u g h t h e p r o c e s s o f p r o g r a m m i n g i s
essentially the same, regardless of the language in which the
program is written, FORTRAN presents specific difficulties
and specific opportunities.

Nevertheless, the advantages of modularity must be weighed
against their effect on optimization (see section 2). Subpro
gram calls are more expensive to execute than simple
branches. Therefore, they should be kept to a minimum in
frequently-executed loops. In any particular application, a
balance must be struck between the decreased programmer
time brought about by modularity, and the decreased
execution time brought about by limiting subprogram calls.

TOP-DOWN PROGRAMMI NG

The number of steps between problem definition and final
coding depends on the size and complexity of the applica
tion, but at least four steps are always necessary. These
steps can be summarized as follows:
1. The problem to be solved is defined as precisely as
possible (in English).

In recent years, the attempt to reduce the cost of computer
systems has focused increasingly on the cost of software
development and maintenance. The consensus is that these
processes should be better controlled and more standardized
than they have been in the past. The following criteria are
those generally agreed upon for software, regardless of its
function:
0jB\

# It should be reliable. This requires extensive (and well
planned) testing before the software is used for its
intended purpose.
* It should be easy to read. This simplifies the process of
maintenance, which is frequently done by different
people than those who originally developed the soft
ware. This goal is achieved by avoiding convoluted
algorithms and implementation-dependent tricks, and by
providing ample and useful documentation. Very large
programs usually require external documentation, in
addition to the comments in the code itself.
0 It should be modular. This is partly for the purpose of
increased readability, and partly so that useful modules
can be written once, to be used by many programs.

<|PK

Several principal methods have been developed to achieve
these goals. The method that has attracted the most
interest, and that is advocated here, is top-down pro
gramming. This is more than just the advice to design first
and code later, which has always been followed by good
programmers. The key component of top-down programming
is the formalization of the successive steps between the
original requirements of an application and the final coded
version of the program. The idea is to hold in check the
tendency, when beginning to write a program, to write
FORTRAN sta t e m e n t s i m m e d i a t e l y. I n t o p - d o w n p r o
gramming, FORTRAN is not used until the very last step earlier steps are written in English or in a more informal
pseudo-FORTRAN. (It is important to note that all steps
must actually be written, or the purpose of top-down
programming is defeated.)
Another important component of top-down programming is
modularity. Modularity means limiting the size of program
units, and ensuring that each performs a well-defined
function. A good rule of thumb is that each program unit
should be about one page long. This ensures that the purpose
and logic of each module are readily comprehensible. When
the purpose of each module is well-defined, it is frequently
possible to use the same subprogram in more than one
program (as explained under User Libraries, in section 6).
The division of a program into modules should not be
arbitrary, but should follow as much as possible the
separation of functions between program units.

60499700 A

2. An algorithm covering only major steps of the program
is written, in English and, where appropriate, in
mathematical notation. The major modules of the
program are also defined.
3. For each module defined in step 2, the algorithm is
broken down into lower level steps, written in a higherlevel language than FORTRAN. This step is repeated
until the program is in a form of pseudo-FORTRAN.
4. The program is coded in FORTRAN. If step 3 was done
properly, this process can take place practically lineby-line.
To illustrate this procedure, we will follow the various steps
for a simple example. The example is not ideal; because it
is so small, it uses no subprograms, and therefore does not
illustrate the development of separate modules. The
example is program NEWTON, which is explained more fully,
with input and output, in section 2.
The origin of the program is an application that needs to
find the roots of a polynomial equation (presumably part of a
larger application). After considering various methods, the
programmer decides on Newton's method. The stages of
program development are then written down as shown in
figure 1-1.
Step 1 defines the problem as precisely as possible. In this
case, the reader of the description is assumed to be familiar
with Newton's method, so little description is necessary.
Step 2 presents the algorithm to be used. At this stage, the
order in which major steps are to be executed is determined.
In order to describe the algorithm, some of the data
structures to be used might be defined. In a program longer
than NEWTON, the algorithm would probably not be detailed
enough to include any mathematical formulas.
In step 3, the algorithm is made more detailed and, for the
first time, the program logic is defined. The language used
in this step is very casual; it is a mixture of ALGOL,
English, and FORTRAN. A more standardized language
could be developed; the main point is to defer actual
FORTRAN statements as long as possible. By the last
iteration of step 3, each module should be written in a sort
of pseudo-FORTRAN, with the statements appearing in their
fi n a l o r d e r. N o n - e x e c u t a b l e s t a t e m e n t s a r e g e n e r a l l y
omitted in step 3, as are most statement labels. Input/output statements are only sketched in.

1-1

Step 1. Problem definition. Find the roots of a given equation using Newton's method.
Step 2. Algorithm specification
Given:
F(x) The function
F'(x) Its derivative
Xq An initial approximation
e The convergence criterion
max Maximum number of iterations (in case of failure of convergence).
Algorithm:

 ♦ 2.0/(X-1.0>*«2
REAO •. XO. EPS. ITMAX
IF (DERIV(XO) .FQ. 6.0) GO TO 300
DO 100 1=1.ITMAX
ITS = I
XI = XO - F(X0)/DFRIV(X0)
V = F(X1)
PRINT ». *X.Y #♦ vO. Y
IF (APS(XI - XO) .LE. EPS) GO TO 200
XO = Xl
100
CONTINUE
WRITE (5.20) ITMAX
STOP
200 WRITE 
DIME NSI0NB( 10,10
COMMON/XYZ/C(10,10)
CONTROLLING ROUTINE FOR THE PROGRAM
REA0(5,2>1,J,K
FCRPATC2X3IM
IF(EOF(5))10G,2G0
CO30QH-l«I
B=C(M,K)»»2*I»K
CAILWHATSIS(B,C»M>
STOP
STOP
END

A^$\

After:
PROGRAM NAOA (INPUT, OUTPUT, TAPE5-INPUT)
C
C

c

c
c

c
c
c
c
c

PROGRAM NADA COMPUTES THE LOWEST VALUE CF N (GREATER THAN
2) FOR WHICH X**N ♦ V»»N = Z*»N. MOST OF THE WORK IS DONE
IN THE SUBPROGRAM WHATSIS; THE MAIN PROGRAM PERFORMS HOUSEKEEPING CHORES.

a&^\

AUTHOR* A. ALLIVER, CDC 1977

c
DIMENSION 8(10,10)
COFMON /XYZ/ C(10,10).
REAO (5,2) I, J, K
IF (EOF(5).NE.0.C) STOP
DO 10G M=1,I
B(J,M> = C(M,K>»»2 ♦ I»K
100
CONTINUE
CALL WHATSIS (B, C, M)
STOP
2 FORMAT (2X, 314)
END

Figure 1-2. Coding Style Example

1-4

60499700 A

SAMPLE PROGRAMS

The programs in this section are intended to illustrate the
programming practices discussed in section 1 through appli
cation of some commonly used mathematical procedures and
basic algorithms. The programs are typical of smaller
special-purpose FORTRAN programs, rather than larger,
more complex applications.

NEWTON

ACCTAB

is applied to generate successive approximations to the
equation f(x) = 0, where x. is the current approximation, x. .
is the new approximation, and f*(x) represents the derivative
of f(x). The test for convergence is:

Program ACCTAB (figure 2-1) computes acceleration as a
function of mass and force. It reads two sets of data cards.
The first set is read in line 9 and contains three numbers per
card, representing time, force and mass. These values are
used to generate a table of time versus acceleration.
Acceleration is calculated in line 15 by the statement:
ACC (N) = F/AMASS
where ACC(N) is acceleration, F is force, and AMASS is
mass. The variable AMASS is tested for a zero or negative
value. The counter N is incremented each time a card is
read. If N exceeds the maximum allowable table size, a
message is printed and execution terminates. The variable
NTIMES contains the total number of time values in the
table. When the first set of cards has been read, the table is
printed.
The program then reads the second set of cards, which
contains selected time values, one per card. A table search
is performed for the time values immediately above and
below the input value. In lines 30 and 31, each time value is
tested for validity. If a time is outside the table bounds, a
message is printed and the next card is read. In lines 46
through 55, a second degree interpolation is performed for
the acceleration value. This is accomplished by the formula:
A m y ( =T - T
1 ) ( T- T 2 ) A 0
ACCX
(T0-T1)(T0-T2)

(T-T0)(T-T2)A1
" (T1-T0XT1-T2)
(T-T0)(T-T1)A2
+ (T2-T0XT2-T1)
where T is the input time, AO, Al, and A2 are tabular
acceleration values corresponding to the time points TO, Tl,
and T2, and TO < T £ Tl. A diagram of interpolation is shown
in figure 2-2.
Since, for a given input time, two tabular points beyond that
time are required for interpolation, special processing is
included in lines 31 through 33 for times falling between
TIME(N-l) and TIME(N), where TIME(N) is the last point in
the table. After the interpolation has been performed, time
and acceleration are printed, the next card is read, and so
on, until all input times have been processed. A sample
input deck is shown in figure 2-3; the output is shown in
figure 2-4.
Statements in the program test for table overflow (line 12),
for an invalid value for AMASS (line 13), and for a zero
divisor in the formula (line 49). The development of this
program is explained in section 4.

60499700 A

0m*.

Program NEWTON (figure 2-5) finds the roots of a poly
nomial equation by Newton's method. The iterative formula

x.l +. l= x. - if(x.)/f'(x.)
ii

xi-l' < eps
where eps is a constant indicating the desired degree of
accuracy.
In the example, the equation to be solved and its derivative
are
f(x) = sin(x) - (x+l)/(x-l)
f(x) = cos(x) + 2/(x-l)2
The equation and its derivative are provided in the form of
statement functions (lines 13 and 17); these can be easily
replaced to apply the procedure to other functions. A data
card is read containing the following information:
XO

Initial approximation to f(x) = 0 (real)

EPS Convergence criterion (real)
ITMAX Maximum number of iterations (integer);
ensures that the program terminates even
when the function fails to converge.
The DO-loop applies the iteration formula to calculate a
new approximation XI (line 23) and tests for convergence
(line 26). If convergence has not occurred, the new
approximation XI becomes the current approximation XO
and the iteration is continued until either the process
converges or the maximum number of iterations is reached.
In either case, an appropriate message is printed and
processing terminates. Sample input for the program is
shown in figure 2-6, and the output generated from that
input is shown in figure 2-7.
Line 20 tests for a zero value for the derivative; otherwise
the division in line 23 produces an infinite value and the
program aborts.

GAUSS
Program GAUSS (figure 2-8) solves a linear system of N
equations in N unknowns by the Gauss-Seidel method. The
system is of the form:
+ a. x = b.
In n 1

21xl + a22x2 +

,2nxn!sb2

nl*l * dn2*2

nn

n

n

2-1

PR0GRA1 ACCTAB (INPUT,OUTPUT ,TAPE«»=INPUT>
DIMENSION TIME(10), ACC(IC)
*SAO THE, MASS, FORCE, ANO COMPUTE ACCELERATION TABLE
N * C
IER » 3
130 REAO (%,*) T, AMASS, F

IF 

<^V

N = N r 1
IF (T .'LT. TIME(l) .OR. T .GT. TINECNTIMES) ) GO TO 800
IF (T .LE. TIME(NTIHES-D) GO TO 195
IT = NTIMES - 1
GO TO 220
.SEARCH ACCELERATION TABLE
195 LIH * HTINES - 1
OO 200 I * 2,LIM
IT s I
IF if .LF. TIMEUTH GO TO 220
233 CONTINUE
GO TO 95C
DO SECOND DEGREE INTERPOLATION

223 DI = TIMECIT-1) - TIME(IT)
02 = TIME(IT-l) - TIME(IT*1)
03 = TIMEIITI - TIME
1 - 01»I3*ACCCIT)/(01*03)
2 ♦ Ql*a2»ACC(IT*l)/(D2»03)
P R I N T 2 5 , T, A C C X
GO TO 190
SOD PRINT », * TOO MUCH OATA. MAX NO. OF TIMES IS 10*
STOP
730 PRINT •;, ^INVALID VALUE FOR AMASS *, N
I*R * t

GO TO 100
930 PRINT •, * BAD TIME, VftLUE IS*, T
65

7C

SO TO
353 PRINT
30 TO
933 PRINT
STOP

190
*, * INTERPOLATION PROBLEMS, TABLE ERROR*
190
»;, t END ACCTAB*

1 3 F O R M AT ( * 1 * , 2 < * T I M E A C C E L * ) )
15 FORMAT (2(5XF7.2,2XF8.5))
2 5 F O R M AT < * T I M E = * , F 7 . 2 , * A C C E L E R AT I O N = * , F 8 . 5 )
END

Figure 2-1. Program ACCTAB
^k^!»

2-2

60499700 A

/SiP^v

/fSN
Figure 2-2. Second Degree Interpolation
Mass
100.
100.
100.
100.
100.
100.

(Time
0.
1.
2.
3.
4.
5.
7/8/9
0.
0.5
3.6
4.9
6.0
6/7/8/9

0m\
0§^S

time: a::sl
ccc lc.aecce

Force)
1000.
1010.
1020.
1030.
1040.
1050.
(Selected Times)

Figure 2-4. ACCTAB Output
and the notation x (k) indicates the (k+i)st iteration of the
solution vector for x X o , • . . , x .

Figure 2-3. Sample Input Deck

v «2

T h e a l g o r i t h m b e g i n s w i t h a n i n i ti a l guess a t t h e
v a l u e o f t h e s o l u t i o n v e c t o r X(0)
(X(0)= (x^O),
x?(0), .. ., x (0))) and substitutes that vector into the right
hand side of the relation to generate a vector X(l), which
should be a better approximation to the solution. It then
substitutes X(l) into the equation to yield X(2). Continuing
in this manner, it generates successive approximations until
it achieves the desired degree of accuracy. The criterion
for convergence is

This can be rewritten as:
x1 = -(a12x2 + a13X3 + ... + alnxn)/a11
x2 = -(a21x1 + a23x3 + ... + a2nxn)/a22

n

nl

1

TIME
TIME
TIME
TIME
BAO
ENO

2.CC 13.2CCaO
U.ZO l(.,4C0u0
O . G C A 3 C t LT P 4 T i n \
= . S l A C : r. L s R AT I O M
= 3.
- xl
l
i
< E

T^kTITf

for a prescribed E. In others words, when the difference
between successive values of x. is sufficiently small, the
process is considered to have converged. If this criterion is
not satisfied after a prescribed number of iterations, the
process is assumed not to converge and the iteration is
discontinued.

bj- = -aijA»ii (for i=l,n; j=l,n)
b.. = 0 (for i = j)
yp&j^v

c. = b./a.. (for i=l,n)

60499700 A

Input to the program is from data cards. Sample input is
shown in figure 2-9. The first card specifies the number of
equations and unknowns (N), the maximum number of iter
ations (MAXIT), and the convergence criterion (EPS).
Succeeding cards specify the elements of the coefficient

2-3

PROGRAH NEKTON (INPUT, OUTPUT, TAPE5«0UTPUT)
<*
*

5

c

PROGRAM JNEMTON* FINOS THE ROOTS OF THE EQUATION OEFINEO IN THE
FUNCTION STATEMENT BY NEHTON*S METHOO. THE FOLLOHIMG VALUES ARE
INPUT

-J

c

X 9 . I N I T I A L A P P R O X I M AT I O N
EPS CONVERGENCE CRITERION
I I'M AX MAXIMUM NUMBER OF ITERATIONS

c
10

0ztf®§\

fx
rt

EQUATION TO BE SOLVED

rf
*
15

rf

rf
rf
20

25

30

35

40

FIX) = SIN(X) - **2
REAO *, XO, EPS, ITNAX
IF (DE*|V(X0» .EQ. 0.0) GO TO 300
DO 100 1*1,ITMAX
ITS * I!
XI = XB - F(XQ)/OERIV(X0)
Y » FCC1)
PRINT •;, *x,v a, X0V V
IF CAQSKX1 - X0) .LE, EPS) GO TO 200
XO s XI
100
CONTINUE
HRITE (5,20) ITMAX
STOP
290 MRITE 15,10) ITS, XO
STOP
300 W R I T E < 5 , 3 0 ) X 0
STOP
ia FORMAT (* METHOO HAS CONVERGEO IN *,I3,* ITERATIONS*,//* X = *,
LE12.4)
29 FORMAT <* METHOO HAS NOT CONVERGED IN *,I3 ,* ITERATIONS*//
1,* EXECUTION TERMINATED*)
30 FORMAT <1X,E12.4, * IS INVALIO VALUE FOR X0«)
ENO

Figure 2-5. Program NEWTON

0.0 ,0001 10
Figure 2-6. Input to NEWTON
matrix: each card contains the value of the element and
two integers indicating the position of the element within
the matrix. Zero elements need not be included.

X,Y 0. .1728053032033
X,Y -.3333333333333 • 01 S76*»99«»5L7376
X,Y -,«»16815892«*31 .00Q0113375%253679
X,Y -.42035645358^2 3. t 977975822'88E-U
METHOO HAS CONVERGED IN h ITERATIONS
X =

^*^\

-.4204E*00

Figure 2-7. Output from NEWTON
The program begins by reading the input deck and scanning
for errors (lines 42-48). If an error is encountered, the card
number is printed along with an appropriate message and
processing terminates after the entire deck is scanned.
Once the matrix has been read and stored in array A, the
program applies the Gauss-Seidel scheme to generate the
solution values. The solution values are stored in array X.
An initial approximation for each value of X is required to
initiate the process. For the sake of simplicity, the values
of X are initially set to 0.
Three nested DO-loops control the iterative process
(lines 56-72). Each pass through the outer loop constitutes

2-4

one iteration. The variable MAXIT is used as the upper
limit, allowing the process to terminate if convergence does
not occur within the specified number of iterations. Each
pass through the middle loop yields a new approximation
XNEW for a particular element of the solution vector. The
inner loop sums the rows of the matrix.
^2£5N-'

The variable CNV is initially set to 0. After an approxima
tion to a particular x has been calculated, CNV is set to
the difference between the new approximation and the
previous approximation, if the difference is greater than the
current contents of CNV. Thus, CNV always contains the
maximum of the differences between the new and previous
values of the solution vector.

60499700 A
■^^v

PROGRAH GAUSS P(4I • NE. 0 . 0 ) GO TO 900
I F (N . G T. 5 0 ) G 0 TO 910
RFAO < '♦.»» I t J i ELEMNT
I F (EC - ( 4 ) ) 3 3 3 , 350
NCARO = NCARD ♦
I F ( I .=LT. 1 .OR . I • GT. N GO TO 360
I F ( J . L T . 1 .OR • J . G T. N fi ) G O TO 3 6 0
A ( l , J » = ELEMNT
GO TO 200
IERR =
ORINT »., *ERROR ON CARD *, NCARO
GO TO 200
I F ( I ? RR .1* E . 0 ) GO 'TO 650
BEGIN ITERATION

55

6C
♦
' 09

65
509

DO 600 ITS=1,MAXIT
CNV = 0.0
DO 500 1=1,N
SUI = 0.0
DO 400 J=1,N
IF (J .NE. I) SUM = SUM ♦ A(I,J)*X(J)
CONTINUE
XNEW = (A(I,N+1) - SUM)/A(I,I)
TEMP = ABS(X(I) - XNEW)/XNEW
CN/ = AMAX1 (CNV,TEMP)
XU) = XNEW
CONTINUE
TEST F:rR CONVERGENCE

Figure 2-8. Program GAUSS (Sheet 1 of 2)

60499700 A

0m\

2-5

70
630
650
75
739
33
80
930
910
85

IF ONV .LE. EPS) GO TO 700
CONTINUE
PRINT », ^PROCESS HAS NOT CONVERGED IN *,MAXIT,* ITERATIONS*
PRINT *, *EXECUTION TERMINATED*
STOP
PRINT »:, *PROCESS HAS CONVERGED IN *,ITS,* ITERATIONS*
PRINT *, *SOLUTION VALUES ARE*
PRINT 30, (X(I),I=1,N>
FORMAT (1X,8E12.4)
STOP
PRINT *, *INSUFFICIENT INPUT OATA, CANNOT CONTINUE*
STOP
PRINT », *N * *,N,* IS TOO LARGE: MUST BE .LE. 50*
STOP
ENO

/*^\

Figure 2-8. Program GAUSS (Sheet 2 of 2)

3
1
1
1
1
2
2
2
2
3
3
3
3

50 .0001
1 10.
2 1.
3 1.
4 24.
1 1.
2 10.
3 1.
4 24.
1 1.
2 1.
3 10.
4 24.

containing 3742B in columns 10-14. Then the array OCT
would contain the values shown in figure 2-12. After the
number is decoded, the contents of array IA would be as
shown in the same figure.
For each character, the DO-loop does the following:
Lines 24, 25 Tests for blank or B; the B must be at the
end of the string.
Line 28 Tests for sign; + or - is the last character
processed
Line 29 Tests for non-octal digit

Figure 2-9. Input to GAUSS
At the completion of each iteration, CNV is compared with
the convergence criterion EPS; if convergence has occurred,
the solution values are printed and processing terminates. If
convergence does not occur within the specified number of
iterations, an appropriate message is printed and processing
terminates. Figure 2-10 shows the output produced from
execution with the input shown in figure 2-9.

PROCESS HAS CONVERGED IN 5 ITERATIONS
SOLUTION VALUES ARE
.2000E«-01 .2000E+01 .2000E+01

Line 30 Tests for too many digits
Line 31 Converts display coded octal digit to
internal format by subtracting 1R0 (33B)
Line 32 Sums place value of digit to form decimal
number
When all digits of an octal number have been processed, the
decimal number is signed and printed. In the above example,
the procedure for converting to decimal is
3x83 + 7x82 + 4x8 + 2 = 2018 10

Figure 2-10. Output from GAUSS

OTOD
Program OTOD (figure 2-11) reads display coded octal
numbers and converts them to decimal numbers. Input is
from cards containing a single octal number, with up to 20
digits, appearing anywhere within the first 30 columns; the B
suffix is optional. Octal digits are positive integers written
in base 8 notation; therefore, they can only contain the
digits 1 to 7.
The octal numbers are read according to 3R10 format
specification. This produces a right-justified, zero-filled
string 30 characters long contained in array OCT. The
DECODE statement strips off each display coded octal digit
and stores it in array IA in reverse order. The format
specification produces an array of right-justified, zeropadded characters. For example, suppose a card is read

so that 2018 is printed.
A test for end of file is included after the READ statement;
when all input cards have been read, a message is printed
and processing terminates.

LINK
Program LINK (figure 2-13) assumes that a previously
executed scientific program has calculated temperatures for
regions of a grid at specified time intervals and that the
results have been written to a file called INFIL. For each
time point there is a record containing the time value, the
region numbers, and the region temperatures. Regions and
temperatures are packed into single words, with a region
number in the lower half of a word and the temperature in
the upper half. The record format and some sample records
are shown in figure 2-14.

/SisSV--

,i*3!|i

2-6

60499700 A

Program LINK reads the entire input file, reformats the
data, and writes a new file called NEWFIL. In NEWFIL,
there is one record for each region. Each record contains
the region number, the time points, and the temperature at
each time point, as shown in figure 2-15. Time values and
associated temperatures are packed into a single word, with
a temperature in the upper half of a word and the time in
the lower half.
An array in ECS (Extended Core Storage) or LCM (Large
Core Memory) is allocated for data read from the input file
(line 8). The LEVEL statement defines the type of memory

allocated for the array. Since data assigned to level 3 cannot
be referenced in expressions, the MOVLEV subroutine is used
to transfer the data to and from central memory.
The first record is buffered in and the length is obtained
from the LENGTH subroutine (lines 20-23). The loop
(lines 26-34) does the following: the time value, from the
first word of the record, is stored in a separate array and
the record is moved from the input buffer to ECS with the
MOVLEV subroutine. The variable I, used as a pointer to the
next available location in the ECS array, is incremented by
the record length. If the value of I exceeds the array

PROGRA"! OTOO (INPUT,TAPE4=INPUT,OUTPUT)
r\
Irf

n

rf
5

PROGRAM *OTO0* REAOS OCTAL NUM9ERS CONTAINING UP TO 20 OIGITS
AND CONVERTS THEM TO DECIMAL. INPUT IS ON CARDS? THE NUMBER MAY BE
ANYWHERE WITHIN THE FIRST 3C COLUMNS, AND THE B SUFFIX IS OPTIONAL

rf
rf
rf

INTEGER OCTC3), OEC
DIMENSION IA(33)

rf
i:

PPINT 5 0

rf

RFAO AND OECOOE DISPLAY CODED OCTAL NUMBER

rf

iijPx

130 R FAT 1 4 , 1 0 ) O C T
IF (E0*(4) .NE. 0) GO TO 30C
J s C
OFC = 3
DECODE (3C,l5,OCT) (IA ( 30-H-l) ,1 = 1, 30)

15

2;

rf
rf

CONVERT DISPLAY TO INTERNAL, THEN TO DECIMAL

r,
u

25
153
33

35

4£

45

50

55

%*

223

OO 200 I=lt3U
IOIG = IA(I)
IP(IDIG .EQ. 1R ) GO TO 2CC
IF (IDIG .NE. 1R9) GO TO 150
I F ( J . E Q . 0 ) G O TO 2 0 0
GO TD 850
IF (IDIG .EQ. 1R«- .OR. IDIG .EQ. 1R-) GO TO 250
I F ( I D I G . LT. 1 R 0 . O R . I O I G . G T. 1 R 7 ) G O T O 7 0 0
I F ( J . G T. 1 9 ) G O T O 7 5 0
IOIG = IOIG - 1R0
OEC = DEC «• IOIG*8»»J
J = J f 1
CONTINUE

253 I F ( J . E Q . 0 ) G O TO 7 G 0
IF (IOIG .EQ. 1R-) OEC = -DEC
PRINT 20, (OCT(I),I=l,3), OEC
SO TO 100
730 P R I N T 3 0 , ( O C T ( I ) , I = l , 3 l
GO TO 100
753 PRINT 30
sn TO 100
933 PRINT *0
STOP
35fl PPINT 7C
GO TO 100
13 FORMAT (3R1C)
15 FORMAT (30R1)
23 F O R M AT ( 3 ( 1 X A 1 0 ) , 1 X 1 2 0 )
33 FORMAT (3(1XA10), * IS NOT AN OCTAL NUMBER*)
♦
3 FORMAT (* END OTOD*)
33 F O R M AT ( * 1 O C TA L * , 2 0 X , * O E C I M A L * )
30 FORMAT (* INPUT NUMBER HAS MORE THAN 20 DISITS*)
73 FORMAT (3(1XA10), * CONTAINS B OUT OF SEQUENCE*)
ENO

Figure 2-11. Program OTOD

60499700 A
j$s^

2-7

boundary, a warning message is printed; no more data is read
but processing continues on the incomplete array. The next
record is read and the record counter NTIMES is incre
mented; if NTIMES exceeds its limit, a warning message is
printed and the incomplete array is processed. Records are
read and stored in this manner until either the end-of-file is
reached or the ECS array is full.

When the entire file, or as much of it as possible, has been
read and stored in ECS, lines 38 through 48 construct the
output records and write the output file NEWFIL. Each pass
through the outer DO-loop constructs a single output record;
each pass through the inner DO-loop stores a single word in
the output record. On the first pass through the inner loop,
the first input record is transferred to central memory via
MOVLEV; its time value is packed with the temperature
value of the first region and stored in the output buffer OUT
to form the second word of the output record. On the
second pass, the second input record is moved to central
memory, and the time value is packed with the temperature,
value for the first region to form the third word of the first
output record. When all times and temperatures for the
region have been stored in the output buffer (inner loop
completed), the region number is stored in the first word of
the output buffer and the new record is written. Then,
under control of the outer loop, the subsequent records are
constructed and written in a like manner, until the entire
array has been processed.

The program reads the two files and, for each test,
calculates the probability that a student will answer each
question correctly, calculates a correlation coefficient,
calculates a new probability for each question, and writes a
new file. The output file record contains the test number,
number of students, and the probability that a student will
answer each question correctly. The output record format,
along with some sample records, is shown in figure 2-18.

The program begins by reading a record from each file.
Since data from the first file is needed immediately, the
input operation on unit 5 must be complete before proc
essing can continue; unit 5 is tested immediately after the
BUFFER IN. However, data from the second file is not
needed until later in the program; therefore, processing can
continue while the input operation on unit 6 is in progress.
Since execution of the UNIT function loops until input is
complete, it should not be executed until just before the
data is needed.

^n®£\

When the first BUFFER IN has completed, the loop
(lines 22-24) calculates the probability that a student will
answer a question correctly.
P=

No. of correct answers
No. of students
. ' ^ ^ 1

After this calculation, data from the second file is needed.
Unit 6 is tested; when the input operation has completed,
the record from the second file is processed in the same
manner as the record from the first file.

CORCO
Program CORCO (figure 2-16) assumes that a series of
standardized tests has been given to two groups of students,
and that the results have been stored in two corresponding
files. For each test there is a record containing the test
number, the number of students who took the test, and the
number of students who correctly answered each question on
the test. The record format, along with some sample
records from both files, is shown in figure 2-17.

OCT:
OCT(1)
OCT(2)
OCT(3)

55555555555555555536
42373502555555555555
55555555555555555555

IA(1)
IA(2)

blanks
blanks

IA(17)
IA(18)
IA(19)
IA(20)
IA(21)
IA(22)

00000000000000000002
00000000000000000035
00000000000000000037
00000000000000000042
00000000000000000036
blanks

IA:

Lines 37 through 46 calculate the correlation coefficient for
corresponding records of the two files. The formula is
shown in figure 2-19. In the figure, X and Y are the
probabilities for the first and second testings, respectively,
and N is the number of students who took the test. The
correlation coefficient has a value between -1 and 1. A
negative coefficient indicates unreliable data. The test
number and coefficient are printed. An example of the
printed output is shown in figure 2-20.

When every question on a test was correctly answered by the
same number of students, the divisor in the formula became
zero, and the correlation coefficient infinite. Therefore,
the LEGVAR function is used to check this possibility
(line 47).

«*^§\

')
NTIMES = NTIMES ♦ 1
IF (NTI«MES .GT. ^C) GO TO 9GC
I r ( U M T C I I 11 0 , 2 C 0 , 3 C C

3:

35

ALL OATA IS IN lCS. MOVE TO SCM, REFORMAT, ANO WRITE NEW FILE

2:o mtimpc = NTIMES - 1
U~

253
U5
3j3

OO 7ufl 1=2,LENREC
II = 1
OO 25C J=l,NTIMES
CALL MOVLEV (ECSBLKdl), INBUF(l), I)
II = II * LENREC
OUTPUFU + l) = (INPUF(I) .ANC. MASKU) .OR. TIME(J)
COMTINUE
OU"3UF(l) = INBUF(I> .AND. MASKL
SUFFER OUT (5,0) lOUTBUF(l), OUTBUF(NTIMES*l))
IF (JNIT(5)) 30C, 8CQ, 80C
CONTINUE

«r

5.

55

POINT *, *END LINK*
313 PFINT
STOP
9 i ? PRINT
PPINT
SO TO
END

♦, * OISK I/O ERROR*
♦, *INPUT FILE EXCEFOS PROGRAM LIMITS.*
*, *EXECUTION CONTINUING ?»UT SOME DATA MAY BE LOST*
2CC

Figure 2-13. Program LINK

0S&\

0^*,
60499700 A

2-9

A. Record Format
wordl
time

word

2

temp/region 1

word3

wordN

temp/region2

temp/regionN

B. Sample Actual Records
1.0 ~1726620C0CQCQ00C000i
0000006
2.0 17?643ul-00OC00QD0O01
0000006
3.0 17236QOCCC0GO00a00Gl
0000006
4.0 l72554C3COOLC0C:0O0t
0000006
5.0 17?662CCC0CC0aCJOOGl
0000006
6.C 17266C^:02CGj00uG0w1
0000006
7.0 1726610LCCCC00C:0C-C1
0000006
8.0 17264Q430C0CQGQO00IH
0000006
9.0 17'2040CC00CCC0Ce30Cl
00000G6
1D.0 1726614QC0OGCOL'JCa01
00000&6

^500000000000005

1726500000Q&0

264540000000000005

1726460000000

7257000000000000005

1726414000OC0

1725540000000000C

J.72554Q00Q000QGQ00G5

1725540000000

172661000000COOCQ

172656QQOOOQGG000005

172655OGOO000

172652000000000QC

172460G0OQCOGOC00005

1725660C0000Q

172640000000000GI

17245200000000000005

1725660000000

1723640C0000G00C

17255500000000000005

17264000G00G3

1724620000CCOOC

1725740G0GCOCOO0QOG5

1724500C0OO0C

17264640000000'

17265400000000000005

6053037777000

1726670000000000CQG2
1726440000000000030
1724F60CC000C00000

-^^•\

z''^.

Figure 2-14. Record Format for INFIL

A. Record Format
wordl

word2

word3

wordM

region #

temp/time 1

temp/time2

temp/timeM

B. Sample Actual Records
1 1726620QCC172C4Ctu£C
26CC0CC
2 17266?C&:-iJ172G4CC0eC
26CC0CI
3 17267U0GCC172C4CCCLC
26C00Ct
4 17274.4CGL172C4CCuC0
2€CCCCC
5 17265'30GCCl72C''tCeCCC
26CQCGC

6 1 7 2 b 5 r. 0 G 0 Q 1 7 2 C 4 i ; & f j e i
26C0CCC

172643400017214GC

c20CG01r£25i;COOO

1726(04000172

172644u(,C0l72140vi

6610000172250CG0O

172*6520000172

l7264440U0172mtC

6(0000017225000(10

1726404000172

1 7 2 6 4 5 a 0 L fl l 7 2 l M C b

65700001722500000

1724760000172

1726454GC017214CC

65600001722500000

1724600000172

1726**6J0C0172140

6550G0017225GOCOO

17.25660000172

• ^ s

Figure 2-15. Record Format for NEWFIL
,/sffjtisv

2-10

60499700 A

PROGRAM CORCO (OUTPUTiTESTA,TESTB»PROBS,
1 TAPE5=TESTA,TAPE6=TESTB,TAPE7=PROBS)

c

INTEGER TESTN1, TESTN2, TOTST
D I M E N S I O N I B U FA ( 1 5 0 ) , I B U F B ( 1 5 0 ) , O U T B U F ( 1 5 0 > , X ( 1 5 0 ) , Y ( 1 5 0 ) ,
1 IOUT(2»
E O U I VA L E N C E ( I O U T ( l ) , O U T B U F ( D )

5
r \

READ INPUT FILES CONTAINING TEST RESULTS
IJ

w

RFWINO 5
REWIND 6
N=1G
133 BUFFER IN (5,0) (IBUFA(l) ,IBUFA (Nf 2) )
3UFFEP IN (6,0) (IBUFB(l),IBUF9(N»2))
I F ( U N I T ( 5 ) ) 11 0 , 9 3 0 , 8 0 0

ir>

2:

**•

CALCULATE PROBABILITIES FOR FIRST TESTING
113 T F S T N 1 = I B U FA ( l )
N S T 1 - I 9 U FA ( 2 )
OO 120 1=1,N
X ( I ) = F L O AT ( I B U FA ( I f r 2 ) ) / N S T l
120
CONTINUE

?ri

CALCULATE PROBABILITIES FOR SECONO TESTING

c

IF (UNIT(6)) 130,900,800
130 T F S T N 2 = I B U F B ( l )
NST2 = IBUFB<2)
OO 140 1=1,N
Y ( I > = F L O AT ( I B U F B ( I * 2 ) ) / N S T 2
143
CONTINUE

3:

f*

3*

CALCULATE CORRELATION COEFFICIENT

»*

SUMX r SUMY = SUMXY = SUMXSO = SUMYSQ = 0.0
OO 150 1=1,N
SUMX s SUMX «■ X(I)
SUMY = SUMY * Y(I)
SUMXr = SUMXY ♦ X(I)*Y(I)
SUMXSO = SUMXSO ♦ X(I)**2
SUMYSO = SUMYSQ f Y(I)**2
150
CONTINUE
R = (M»SUMXY - SUMX*SUMY)/
1 (SORT(N*SUMXSQ - SUMX<^2>*EORT(N*SUMYSQ - SUMY»»2))
I F ( L F S VA R ( R ) . N E . 0 ) G O TO 1 0 0 0
PRINT 14, TFSTN1, R
14 F O R M AT ( * T E S T N O . = * , I 3 , * C O R R E L AT I O N C O E F F I C I E N T = * , F 5 . 2 )
TOTST = NSTl f NST2

u:

45

?:

CALCULATE NEW PROBABILITIES AND WRITE OUTPUT FILE
C
5?

6;

OO 150 1=1,N
O U T R J F ( I * 2 ) = ( X ( I ) * N S T 1 *■ i ( I ) * N S T 2 ) / T O T S T
150
CONTINUE
IOUT(l) = TESTN1
I OUT (2) = TOTST
BUFFER OUT (7,0) (OUTBUF(l),OUT«UF(N*2))
IF (UNIT(7)) 100, 800, 80C

a;o

65

P R I N T * , * FATA L I / O E R R O R *
STOP
930 PRINT ♦, *ENO CORCO*
STOP
u j o P R I N T • " , * I N VA L I D C O E F F I C I E N T *
GO TO 100
ENO

Figure 2-16. Program CORCO

0$S
60499700 A

2-11

A. Record Format
wordl

word2

word3

word4

test no.

no. of students

#Q1

#Q2

B. Sample Actual Records
T E S TA
t IjC
2 ICC
3 ICC
4 ICC
5 ICC
o 13 G
7 IOC
3 ICC
9 10 0
10 ICC

99
65
93
65
93
74
99
71
21
94

93
76
64
66
97
75
98
72
23
66

97
95
97
26
9U
7*.
95
73
25
59

96
95
54
98
93
78
93
74
27
73

95
*8
65
94
65
79
89
75
29
*1-

94
31
71

93
97
93
35
87
93
78
77
33
98

92
35
17
68
87
56
71
73
35
63

91
98
92
68
5'+
65
63
79
37
12

90
47
89
73
34
93
54
80
39
58

TEST B
1 ICC
2 IOC
'S IOC
4 IOC
5 1GC
6 ICC
7 IOC
9 13G
9 IOC
10 IOC

69
63
99
99
98
94
44
75
75
96

89
31

73
79
69
69
73
85
83
75
75
65

43
77
11
11
91
73
55
75
31
32

53
75
79
80
47
48
96
75
75
21

93
68
73
71
21
69
22
72
85
98
93
&5
94
95
75 * 75
22
75
54 . 65

98
69
31
34
66
24
96
75
12
87

99
67
59
65
79
47
91
75
75
65

88
65
41
47
58
93
25
75
16
32

61
94
77
75
42
94

°5

65
HI
84
76
31
25

Figure 2-17. Input Records for CORCO

A.

B.
1
2
3
4
5
6
7
' 109

Record Format
wordl

word2

word3

word4

test no.

no. of students

P(Q1)

P(Q2)

Sample Actual Records
2C0
200
20Q
200
2QG
20C
20C
200
200

.84
.74
.99
.32
.93
.84
.72
,.43
.96

.94
.79
.33
.35
.79
.85
.83
.33
.31

.38
.87
.93
.59
.36

.81
.92
.50
.62

72
86
38
. 55
4 95
78
74
29
55

.77
.72
.82
.87
.56
.64
.93
.52
.36

.96
.52
.46
.59
.75
.90
.89
.27
.40

.81
• 84
.81
.79
.93
.79
.87
.54
.82

.95
.52
.24
.51
.77
.40
.84
.24
.75

.95
.8 3.76
.67
.67
• 56
.77
• 56
.39

.89
• 56
.65
.63
.71
• 96
• 40
.28
.45

Figure 2-18. Records on File PROBS

2-12

60499700 A

j0Ss..

N
N
N
N 2 XjYj - 2 Xj 2 Yj
i=1 i=1 i=1

R=

/
N
„
N
"
/
Vn 2 X:2 - ( 2 X:)2 Vn 2 Y:^ - ( 2 Y:
i=1

i=1

i=1

i=1

Figure 2-19. Formula for Correlation Coefficient

TEST KO.
aoRRELATION
TEST NO,
CORRELATION
TEST KO.
CORRELATION
TFST NO.
:oRRELArroN
TEST NO.
CORRELATION
TEST KO.
CORRELATION
TEST NO.
CORRELATION
INVALID (^EFFICIENT
TEST KO.
CORRELATION
TEST KO.
IC CORRELATION
END CCRCO

COEFFICIENT
COEFFICIENT
COEFFICIENT
COFFrjciENT
COEFFICIENT
COEFFICIENT
COEFFICIENT

-.45

COEFFICIENT
COEFFICIENT

-.35

.24
.64

-.42
• 27

.59
.12

.26

Figure 2-20. Printed Output from CORCO

0^\

y$SN

60499700 A

2-13

0**s

1

ry

* >

/P^v

OPTIMIZATION

The purpose of optimizing a program is to reduce the cost of
executing it. This cost is literally a cost in money, whether
the cost is charged to the individual user or shared among all
the users. Because the cost of a job results from the use of
several kinds of system resources, the cost can be reduced
by reducing the use of one or more of these resources.
These resources include central processor time, central
memory field length, and the various resources used in
input/output operations.
Frequently, however, a reduced expenditure of one resource
requires an increased expenditure of another. For instance,
the amount of memory required by a program can be
reduced by using segmentation or overlays (section 7), but
more- central processor time is then required. Conversely,
some optimization techniques, such as loop unrolling
(described in this section), decrease central processor time
at the expense of field length. Only the requirements of a
particular application can determine whether specific
optimizations are worthwhile.
A resource cost that is frequently overlooked when optimi
zation is considered is programmer time. As discussed in
section 1, program development, debugging, and mainten
ance frequently contribute more to the overall cost of a
program than the computer resources required to execute it.
Therefore, a programmer should be very cautious about
optimizing a program in such a way as to make it less
comprehensible or maintainable. Unless a program is to be
executed repeatedly, or to use a lot of resources, not much
time should be spent on user optimization.
This section describes both the optimizations that the
compiler performs for the user as well as those the user can
embody in the source code. Most of these optimizations
decrease central processor time (not always at the expense
of field length), but some decrease field length, input/output
time, or real time (throughput).
It should be kept in mind that the best way to optimize code
is to use efficient algorithms. The higher the level at which
a program is optimized, the better the results.
Array subscript computation is discussed frequently in this
section; therefore, the formulas for one-, two-, and threedimensional arrays are shown in table 3-1 for convenient
reference. These formulas do not apply to double precision
or complex arrays.

Because it is reasonable to assume that any programmer
interested in optimal program execution will compile the
program under OPT=2 or UO (unsafe optimization), the
optimizations performed by the compiler in those modes are
discussed first.

COMPILER OPTIMIZATION
When OPT=2 is specified on the FTN control statement, the
compiler optimizes the user code extensively in the process
of generating object code. When the UO option is also
specified, all the OPT=2 optimizations are performed, as
well as some additional ones that could cause incorrect
results. (The additional optimizations performed when UO is
specified are identified below.)
OPT=2 mode is a global optimizer; that is, it analyzes the
structure of an entire program unit during the optimization
process. A brief description of the procedure followed by
this optimizer will help to clarify the specific optimizations
described here in more detail.
In optimizing mode, several passes are made over the source
code. In the first pass, the syntax of statements is analyzed,
a symbol table is constructed, and the statements are
translated into an intermediate language similar to assembly
language. Typically, several instructions in this inter
mediate language are required for each executable
FORTRAN statement. At this stage, no register assignment
has taken place; rather, an indefinite number of registers
(R1,R2, . .. ,Rn) are used as needed. An example of a
FORTRAN statement and its translation into intermediate
language is shown in figure 3-1. The intermediate language
used in this example is similar to that used by the compiler,
but is different in format.
Local optimizations are performed before global optimi
zation begins. (Local optimizations are also performed when
OPT=0 or 1 is specified.) The local optimizations include
constant evaluation and elimination of redundant subex
pressions.
Global optimization begins by grouping sequences of inter
mediate language instructions into units called basic blocks.
A basic block is a sequence of instructions with one entry
and one point of exit. It has the property that if one
instruction in a block is executed, all the instructions are
executed. This grouping simplifies the process of analyzing
the flow of control in the program. In figure 3-2, each
section of code between comment lines constitutes a basic
block.

TABLE 3-1. ARRAY SUBSCRIPT FORMULAS
Number of
Dimensions
0$S\
V

60499700 A

Declaration

Reference

Formula for Offset
from First Element

1

A(I)

A(L) =

L-l

2

A(I,J)

A(L,M)=

L-l + I*(M-1)

3

A(I,J,K)

A(L,M,N)=

L-l + I*(M-1 + J*(N-D)

3-1

The next stage is to construct a directed graph in which the
basic blocks are nodes, and the lines connecting the nodes
indicate a conditional or unconditional transfer between
blocks. The optimizer constructs a table indicating which
variables are used and defined in each block.
The optimizer then identifies all the loops in the program
unit (IF loops as well as DO loops). The loops are
categorized according to how deeply they are nested. (An
unnested loop is in the same category as the innermost loop
of a nest.) Then, beginning with the innermost loops and
proceeding outward, optimizations are performed for each
loop. These optimizations include movement of invariant
code outside the loop, strength reduction, elimination of
dead variable definitions, and register assignment.
After all loops have been optimized, object code is gener
ated. As a result of optimization, the order in which
operations are performed can be different than the order in
which those operations were specified in the source code.
The result, however, is always identical.
FORTRAN Statement:
Q = X + Y/Z
Intermediate Language Equivalent:
LOAD Y—* R1
LOAD Z—*R2

Users with a knowledge of COMPASS are encouraged to
examine the object listing produced from an OPT=2 compila
tion to get an idea of the types of source code manipulation
that take place. The listing can be compared with one
produced by an OPT=0 compilation.

^^v

The compiler-produced optimizations discussed in this
section are divided into machine-independent optimizations
and machine-dependent optimizations. Machine-independent
optimizations are those that would produce more efficient
code on any machine. Primarily, they consist of the
elimination of unnecessary operations. Optimizations in this
category include common subexpression squeezing, elimina
tion of dead variable definitions, invariant code motion, and
compilation time evaluation of constants. Machinedependent optimizations are those that take into account
the specific features of the systems on which FORTRAN
Extended programs run. They include replacing expensive
operations with cheaper ones and taking advantage of the
functional units present on some models.

MACHINE-INDEPENDENT
OPTIMIZATIONS
As stated above, machine-independent optimizations are
those that result in the elimination of operations. In some
cases, the operations are completely removed from the
source code; this saves space as well as time. In other
cases, operations are moved out of loops so that they are
executed less frequently; this does not necessarily save any
space.

DIVIDE R1 / R2-*R3
LOAD X—*R4

Invariant Code Motion

ADD R3 + R4—»R5

If a sequence of instructions appears in a loop, and the result
of execution of the instructions does not depend on any
variable whose value changes within the loop, the instruc
tions are called invariant. If the instructions remain in the
loop, they are redundantly executed as many times as the
loop is executed; therefore, the optimizer removes such
sequences from loops whenever possible.

STORE R5—*Q
Figure 3-1. Intermediate Language Example

For example, in the sequence:

c
X = Y
DO 120 1=1,N
A(l) = B(l)
120 CONTINUE
GO TO (100,200,300) J
C
100 Z= Q
GO TO 500
C
200 PRINT \ X
GO TO 500
C
300 N = N + 1
A{1) = 0
RETURN
C

Figure 3-2. Basic Block Example

3-2

DO 100 I=1,N
K(I) = J/L+I**2
100 CONTINUE
neither J nor L can change in value during execution of the
loop and, therefore, J/L is invariant and can be safely
removed from the loop. J/L is then calculated only once,
rather than repeatedly. After optimization, the loop is
equivalent to the following:
Rl = J/L
DO 100 I=1,N
K(I) = Rl+I**2
100 CONTINUE
(In this example of
follow, variables of
rather than memory
strictly speaking be

code after optimization, and those that
the form Rn indicate machine registers
locations; thus, the examples should not
read as FORTRAN statements.)

Invariant code can extend for several statements, as shown
in figure 3-3. This example also shows that IF loops that are
essentially the same as DO loops are optimized in the same
way.

60499700 A

^ s \

Invariant code can also include code that is invisible in
FORTRAN. For example, in the sequence:
DIMENSION B(10,10,10)
DO 10 I=1,N
B(I,7,K) =1
10 CONTINUE
The relative location of the element of array B is calculated
by the formula (see table 3-1):

1-1 + 10 x (6 + 10 x (K-l))
Without optimization, this entire calculation would be
performed once for each execution of the loop. After
optimization, however, the invariant part of the calculation
is performed before entering the loop. This invariant part
consists of the following subexpression which, in fact, is
most of the calculation:

-1 + 10 x (6 + 10 x (K-l))
The optimizer only moves code out of a loop when it is
certain that the code is actually invariant. There are
circumstances in which execution of a sequence of instruc
tions proves it to be invariant but the determination cannot
be made at compilation time. These circumstances include
the following:
/fl^V

• When a call is made to a subprogram within the loop,
and the code that is being considered for invariancy
uses the value of a variable that is either in common or
is an actual parameter to the subprogram. For
example, in figure 3-4, neither X**2 nor Y/Z can be
moved out of the loop, because the subroutine MYSUB
might change the value of X or Z. However, if the call
to MYSUB were:
CALL MYSUB (Q,R,Z+2)

« When a conditional branch within the loop introduces
the possibility that the code might never be executed.
For example, in figure 3-5, the expression K+M can be
moved out of the loop so that it is executed only once,
but the store into J must be left in the loop.
0 When the value of an expression ultimately depends on a
variable that is capable of changing value in successive
iterations of the loop. For example, in figure 3-6, the
division L/Nl cannot be moved out of the loop because
the value of L ultimately depends on that of I, which
changes each time the loop is executed.
Taking the limitations of the optimizer into account, the
user concerned with optimal performance can write loops so
as to maximize the amount of optimization that can take
place. Above all, loop structure should be kept simple and
straightforward. Common should not be used for storage of
strictly local variables. Finally, expressions should be
written in such a way as to make invariant subexpressions
easier to recognize. For example:
DO 100 I=1,N
A(I) = (1. + X) + B(I)
100 CONTINUE
COMMON X
DO 100 I = 1,N
A(l) = X**2
B(l) = Y/Z
CALL MYSUB (Q,R,Z)
100 CONTINUE
Figure 3-4. Invariant Code (Example 1)

then Y/Z could be moved out of the loop, since the
compiler assumes that the call to MYSUB does not
change the value of Z.

LOGICAL L
DO 100 I = 1,N
IF (L) GO TO 110

Before optimization:
= P(l) + S/Q

100
Y

= X/Z +

I

=1+1

IF0.LT.12) GO TO 100

J = K+M
110

A(l) = B(l) + C(l)

100

CONTINUE

Figure 3-5. Invariant Code (Example 2)

After optimization:

DO 100 l=1,N

R1 = S/Q
Y
100

= X/Z +

K = J*...

= PO) + R1

L = K+...

=1+1

M = L/N1 + N2*N3

IF0.LT.12) GO TO 100

Figure 3-3. Invariant Code Motion Example

60499700 A

J = l+...

100

CONTINUE

Figure 3-6. Invariant Code (Example 3)

3-3

/*^^1

is preferable to
DO 100 I=1,N
A(I) = 1. + B(I) + X
100 CONTINUE
because 1. + X is recognized as an invariant expression only
in the first case.
Common sense must be used to decide when rewriting loops
interferes with the readability of code.
Whenever it is not clear whether the compiler can move
invariant code, the user can move it. Moving code
sometimes requires the creation of temporary variables to
hold subexpressions; these variables should only be used
locally, so that the optimizer does not generate unnecessary
stores into them (as explained under Dead Definition
Elimination). An exception to the effectiveness of this
technique is that the program should not perform its own
subscript calculation for a multidimensional array. For
example, the sequence:
DIMENSION B(10,10,10)
DO 10 I=1,N
B(I,7,K) = 1
10 CONTINUE
should not be rewritten as:
DIMENSION B(10,10,10)
ITEMP = -1 + 10*(6 + 10*(K-1))
DO 10 I =1,N
B(I+ITEMP) = I
10 CONTINUE
even though the results are the same, because the rewritten
version inhibits certain special-case optimizations the
optimizer performs on array subscripts. (The expression in
the rewritten version is not recognized as a subscript.)

the expression is usually
Since the operators are
compiler might reorder the
be used to ensure the
expressions:

evaluated from left to right.
associative, however, the
operations. Parentheses can
desired grouping of sub

(A*B)/C
0 The expressions must be in the same sequence of code,
otherwise it is not feasible to allocate a register to save
the result. The further apart two occurrences of the
same expression are, the less likely it is that they will
be matched. Furthermore, no code can occur between
occurrences of the same expression that might cause it
to change in value. For example, in the sequence:
X = A(2)/B(2) - Q
A(I) = 4.5
Z = A(2)/B(2) + 13.4
A(2)/B(2) cannot be matched as a common subexpression
because of the possibility that I will be equal to 2 at
execution time, changing the value of the expression.
In this example, if the user is sure that I will not be
equal to 2, the assignment to A(I) should be placed after
the assignment to Z.
Keeping these restrictions in mind, the user can write
expressions so as to maximize the chance that identical
expressions are recognized by the optimizer. For example:
AA = X*A/Y
BB = X*B/Y
is not likely to result in subexpression elimination, but
AA = A*(X/Y)
BB = B*(X/Y)
will do so.

Common Subexpression Elimination
A common subexpression is an expression that occurs more
than once in the source code. In completely unoptimized
code, the expression is evaluated each time it occurs.
Instead, the optimizer tries to save the result of the
expression in a register whenever possible and to use that
result instead of reevaluating the expression.
For example, in the following sequence of code:
X = A*B*C
S(A*B) = (A*B)/C
all three occurrences of A*B are matched; A*B is evaluated
only once, and the result is used three times. This procedure
can take place only when all of the following conditions are
true:
0 The expressions can be recognized as the same
expression. The compiler reorders each expression into
a canonical order, and then compares expressions termby-term. Only expressions that match exactly are used.
For example, A+B, A+B+C, C+D, and so forth, are
recognized as subexpressions of A+B+C+D, but A+C is
not recognized. B+A can be matched with A+B,
however, because they are rearranged into the same
order. When a subexpression contains more than one
operator of equal precedence, as in:
A*B/C

3-4

Dead Definition Elimination
As explained above, the optimizer divides a program unit
into basic blocks as part of its analysis. In the process, it
keeps track of the uses and definitions of each variable
within the block. By investigating which combinations of
blocks can be branched to from a given block, the optimizer
determines whether the value of a variable is needed after
the block is executed. If the value is needed, the variable is
referred to as live on exit, otherwise it is referred to as
dead on exit. If a variable is dead on exit from a block, the
last store into the variable can be eliminated, since the
value of the variable will not be needed again in the
program.
For example, in the program unit shown in figure 3-7, the
store into X in the line labeled 100 is eliminated, because
there is path through the program in which X could be
referenced subsequently.
Locally (that is, within a basic block), other stores of a
variable can also be eliminated. For example, in the
sequence:
X=Y+Z
A=X+B
X = X/R

60499700 A

all three of these statements must be executed whenever
the first one is executed. Therefore, it is not necessary to
store X after the first statement because it is almost
immediately redefined. A dead definition is eliminated only
if the optimizer can be certain that it is really dead. For
instance, the logic of the program might be such that it is
impossible to decide for certain where the last usage of the
variable is. In this case, no stores can be deleted (except
locally). Also, the ability of the optimizer to eliminate
stores even locally is limited by the availability of registers.
For example, in the sequence:
X = Y+Z
A(I+J,J+K,K+I) =(B(M,N) +
1C(N,L)) ** (D(L,M)/E**X)/F
X = Q/R/S/T

The user can help the optimizer by grouping constant
subexpressions within an expression. For example, it is
better to write:

X = Y * (3.14159265358979 / 2.)
than:

X = 3.14159265358979 * Y / 2.
because the constant subexpression is recognized in the first
case but not the second.

Test Replacement
it is impossible to keep the value of X in a register
throughout the execution of the second statement, so X
must be stored and then subsequently loaded.
There is not much the user can do to help the optimizer
eliminate dead definitions. Of course, many dead definitions
result from incorrect or redundant code. For example, if
the last statement to be executed in a program unit is a
store into a local variable, the statement is superfluous and
should be eliminated by the programmer. The best advice is
to keep program logic simple and avoid unnecessary use of
common blocks and equivalence classes.

Constant Evaluation
At all optimization levels, the compiler attempts to
evaluate as many constant subexpressions as possible. The
reason for this is that programs are usually executed many
more times than they are compiled. For example:

X = 3.5 + 4.**2
The compiler evaluates the expression and replaces it with
the constant 19.5. Some constant subexpressions serve no
useful purpose and should be evaluated by the programmer,
not the compiler. Others are justified, however, when they
make programs more readable. This is particularly true
when one of the components of the expression is a standard
constant, such as pi or e. Because the expression is
evaluated at compile time at minimal expense, it is better
to leave such expressions unevaluated.
SUBROUTINE A (M,V, I)
DIMENSION V(M)
READ \ X
GO TO (100,200) I
100 X = X/2.
IF (M .GT. 20) GO TO 250
STOP
200 PRINT \ X
RETURN
250 V(M) = 25.6
RETURN
END

Figure 3-7. Variable Dead on Exit

60499700 A

Test replacement consists of replacing, in a loop, all or some
occurrences of a variable with a function of a related
variable. The control variable is especially likely to be
eliminated. A variable can be eliminated if it satisfies the
following conditions:
9 it is not in common or a formal parameter
0 Its value is not required outside the loop
0 At least one of its appearances in the loop is in the
form of a linear function (expecially as an array
subscript); for example:
DO 100 I = 1,N
A(2,I) = 33.2
100 CONTINUE
Test replacement of I can take place in this loop, but
not in the following case:
DO 110 I=1,N
X = SQRT(FLOAT(I))
100 CONTINUE
In test replacement, the increment and test portions of the
loop code are rewritten so that a linear function of the
control variable is incremented and tested, rather than the
control variable itself; for example:
DO 100 1=1,10
A(I) = 2.5
100 CONTINUE
In this loop, test replacement causes the address of the
successive elements of the array A to be used for testing
and incrementing, rather than the variable I. Because the
distinction is easier to see in COMPASS code, the object
code generated for this loop under OPT=0 and OPT=2 is
shown in figure 3-8. It should be noted that the variable I,
for all intents and purposes, does not exist in the second
version.
When the control variable has more than one use within a
loop, test replacement can still take place, but the control
variable is not necessarily eliminated. However, at least
one increment instruction per loop iteration is eliminated.

3-5

("'SSx

^^S

MACHINE-DEPENDENT
OPTIMIZATION
As stated above, machine-dependent optimizations are those
that take advantage of the peculiar features of the systems
on which FORTRAN Extended programs can be run. They
fall into three main categories:
* Those that replace slower operations by faster oper
ations. In FORTRAN, the relative speeds of operations
can be ranked as follows (slowest first):
** Exponentiation
/
*

Some types of strength reduction are local optimizations.
For example, any exponentiation by a small integer constant
(less than about 12) is replaced by a series of multiplica
tions. Exponentiation by larger integers results in a call to a
Common Library routine, which also uses multiplication for
exponentiation by any integer up to about 100.
Another example is multiplication by 2, which can be
replaced by addition of the variable to itself; thus:
J = 2*1
becomes:
J = 1+1

Division
Multiplication

+ - Addition and subtraction
* Those that reorder instructions so as to use simulta
neously as many functional units as possible. These
optimizations are only carried out on systems with
functional units; that is, the 6600, 6700, CYBER 70
Models 74 and 76, and CYBER 170 Models 175 and 176
Computer Systems.
% Those that schedule register usage so as to minimize
stores and loads. These apply to all computer systems.

When OPT=2 is specified, strength reduction also takes place
in other situations. For example, if a subscript expression is
of the form:

^

n*I + m
where n and m are unsigned integer constants, and I is a
variable that varies only linearly in the loop (such as the
control variable), then the multiplication can be replaced by
an addition. For example, in the loop:
DO 120 1=1, 100
B(4*I + 3) = 2.5
100 CONTINUE
the loop is rewritten as follows:

Strength Reduction
Strength reduction is one instance of the replacement of
expensive operations by cheaper operations. Specifically,
strength reduction replaces exponentiation by multiplica
tion, and multiplication by addition.

Rl = 3
DO 120 1=1, 100
Rl = Rl + 4
B(R1) = 2.5
120 CONTINUE
so that the multiplication is replaced by an addition.

Under OPT=0:

)AA

SX7
SA7
BSS

IB

Special Casing of Subscripts

09

SA5
SA4
BX7
SA7

co*.

In a multidimensional array, subscript computation requires
one or more multiply instructions. The formula for this
computation is shown in table 3-1. If any of the declared
dimensions (except the last dimension, which is not used in a
multiply) is a power of 2, the multiplication can be replaced
with a shift instruction, which executes more quickly. This
is possible because, subscript dimensions are positive
numbers less than 2 -1. (Shifts cannot replace multiplica
tions of other integer variables because the results might
overflow 48 bits, leading to invalid results.)

SA5
SX7
SXO
SA7
MI

X5
X4*A-1B
X5f IB
X7-13B
A5
X0, )AA

^^v

In the following example:
DIMENSION A(2,4,7)

Under OPT=2:
A(I,J,K) = 452.3

)AA

SAl
SB6
SB7

CON.
A+11B

BSS
BX7
SA7
SB7
GE

OB
XI
B7
B7f IB
B6,B7,)AA

the subscript calculation is:
I - 1 + 2 * (J-l + 4*(K-D)

Figure 3-8. Test Replacement Generated Code

After optimization, both multiplications are performed by
shifts instead of multiply instructions.
The replacement of multiplication
when the array dimension is a
powers of 2. In this case, the
shifted twice, and the two results

by a shift also takes place
sum or difference of two
number to be multiplied is
are added or subtracted.

^^iv

3-6

60499700 A

0^>

In the following example:
DIMENSION A(6,12,3)

0j^\
A(I,J,K) = 452.3
the formula for the subscript is:

1-1 + 6*(J-1 + 12*(K-1))
or
I + 6*J + 72*K - 79

"r

Both multiplications are performed using shift and add
instructions.
Another type of special casing takes place when the first
subscript expression of a subscript is a constant. In this case,
the constant is added to the base address of array, saving
one addition each time the subscript is calculated. For
example, in the following case:
DIMENSION A (10,10,10)
DO 100 I=1,N
A (4, J, I) = I
100 CONTINUE
the address of the array element in the assignment state
ment is calculated as follows:
Address = Base address + (3 + 10 * (J - 1 + 10 * (I - 1)))
where the base address is the address of the first element in
the array. Since the constant part of the calculation only
needs to be performed once, 3 is added to the base address
at compile time, effectively transforming the calculation to
the following form:
Address = Biased base address +
(10 * (J - 1 + 10 * (I - 1)))
The same principle can be applied to the case where the two
leftmost subscript expressions, or all three, are constants.

Functional Unit Scheduling
The central processor in several of the computer systems on
which FORTRAN Extended programs run has multiple
functional units. The optimizer takes advantage of this
feature whenever possible by scheduling instructions so as to
use units simultaneously. This optimization is performed
only when the program is compiled on a system with
functional units; the compiler assumes that the program is
to be executed on the same system on which it was
compiled. However, performance is not degraded if the
program is executed on a different system.
An important special case of functional unit scheduling is
array element prefetching. Prefetching takes place when
the elements of an array are used successively in a loop.
With prefetching, loading of the next element to be used
overlaps usage of the current element. For example:
DO 100 I=1,N
A(I) = B(I) + C(I)
100 CONTINUE
Without prefetching, both B(I) and C(I) would have to be
loaded before being added, so either the floating add unit or
the increment unit (which is responsible for loads and stores)

60499700 A

would be idle while the other unit was in use. With
prefetching, B(I+1) and C(I+1) are fetched at the same time
as B(I) and C(I) are added.
The potential danger with prefetching is that the last
iteration of a loop might attempt to load a nonexistent array
element. In the example, B(N+1) and C(N+1) are loaded (but
not used) even if the arrays only have N elements. If the
array is stored near the end of the user's field length, this
attempt might result in an address out-of-range (an arith
metic mode 1 error). Thus, a program that executes
correctly without prefetching might abort with prefetching.
For this reason, prefetching is not performed for compila
tions under OPT=2 unless there is no danger of exceeding
field length. However, when the UO (unsafe optimization)
option is specified in addition to OPT=2, the compiler can
prefetch for any array, without regard for the possibility of
exceeding field length. Therefore, UO should not be used
unless the user is sure that field length is not exceeded.
In the example above, field length is not exceeded because
the increment between prefetched elements is only one
word, and at least one word is guaranteed at the end of the
field length.

Register Assignment
As one of the last stages of code generation, the optimizer
decides which register to use for each variable and
temporary quantity in every sequence of code. As part of
the process, an attempt is made to minimize the number of
loads and stores required. Whenever a program uses more
quantities than there are registers, some of the quantities
not immediately in use must be stored and subsequently
loaded. To avoid this, the optimizer analyzes the register
usage of a sequence of code and decides whether to put each
quantity in an A, B, or X register.
For some quantities, no alternative is available. The value
of most variable or array elements must be in an X register
(which is 60 bits long), and the address of an operand to be
loaded or stored must be in an A register. However, any
quantity known to be less than or equal to 18 bits long can
be kept in either a B register (which is 18 bits long) or an X
register. These quantities include DO-loop control vari
ables, limits, and increments, and any quantity used in array
subscript calculation.
In the following example:
DO 100 I=J,K,L
A(I) = B(M,N,I)
100 CONTINUE
I, J, K, L, M, and N can all be legally placed in B registers,
because none of these quantities are allowed to exceed
18 bits.
U s u a l l y, r e g i s t e r a s s i g n m e n t c o n s i s t s o f r e a l l o c a t i n g
quantities from X registers to B registers, since X registers
are usually scarcer than B registers, but occasionally the
reverse is true. A special case of register assignment is
retention of B registers across calls to basic external
functions (library routines), which takes place only when the
UO option is specified. Normally, all registers are saved
whenever an external reference occurs, because it is
impossible to determine at compile time what registers are
used by the referenced function. However, when the UO
option is specified, the compiler assumes that certain
B registers are not used by basic external functions, and
does not bother to save those registers when such functions
are referenced. When the UO option is specified, the user

3-7

should ensure that functions with
external functions are not loaded
the functions are referred to in
type statements that override the

the same names as basic
at execution time, unless
EXTERNAL statements or
default type.

simple program unit and the code that would be generated
for it when compiled with each of the following two control
statements:
FTN,OPT=0,ER=0,OL.
FTN,OPT=2,UO,OL.

OPTIMIZATION EXAMPLE

Only the object code generated for the executable state
ments is shown; a full listing of the object code would also
include code to allocate data blocks and common blocks, and

A somewhat more complex example can serve to illustrate
how various optimizations are combined. Figure 3-9 shows a

Source Code:

1

5

SUBROUTINE O
INTEGER A, B* C
COMMON A(10,10) • B(]0t 10) » C(10« 10)
1)0 100 I=2»10
A { I ♦ 1 . 1 - 1 J = B C l * i » I ♦1) > C ( I -■1 , 1 - 1 )
100 CONTINUE
RETURN
FNO

Under OPT=0:
00000? CORE.

717000000?

SX7
SA7

5 1 7 0 0 0 0 0 1 2 D ATA .
00000^ CODE.
000001 CODE.
000004 CODE.
000005 CODE.
000006 CODE.

) AA
515000001?
D ATA .
7100000013
4P705
524700014*
//
5P37000262
//
36614
5*67777753
//

SA5
SXO
DX7

SA4
SA3
1X6
SA6

13B
X0»X5
X7 + 8
X7+C-26B
X3 + X4
X7+A-24B

5 1 5 0 0 0 0 0 1 2 D ATA .

CODE.

SA5
SX7
SXO
SA7
MI

I
X5+1B
X7-13B
AS
X0,)AA

S TA R T.

EQ

EXIT.

SA2
SAl
SB5
SB6
SB7

B+268
C
13B

BSS
1X7
SA2
SAl
SA7
SB6
GE

0B

EO

E X I T.

000007 CODE.

7?75000001

000010 CODE.

54750

7207777764
0330000003
000011 CODE.

BSS

2B
I
0B

0400000001

LIME

LIME

LIME

LIME

Under OPT=2:

00000? CODE.
000001 CODE.
000004 CODE.
000005 CODE.
000005 CODE.

5120000172
5 11 0 0 0 0 3 1 0
6150000013
6160000002
617000013?

//
//
//
//

AA
36712
54225

54U5
000006 CODE.
000007 CODE.

66665

56760

0676000005 CODE.
0400000001

S TA R T.

«

LIME

A + 2B
A+132B
LIME

X1+X2
A2 + B5
A1+B5
B6
B6 + B5
B7,B6,)AA
LIME

Figure 3-9. FORTRAN Subprogram and Generated Object Code

3-8

60499700 A

to establish communication between program units. The
COMPASS instructions shown are not explained; they should
be self-evident to anyone familiar with COMPASS. The
code generated under OPT=2 shows the following features:
0 Test replacement (the registers B6 and B7 hold linear
functions of the control variable, which does not exist
within the loop)

/|Ks

% Strength reduction (the multiplications that would
normally be used in the subscript calculation have all
been replaced by additions)
0 Common subexpression elimination (not well shown in
this example, because the expressions 1+1 and 1-1 have
disappeared completely) "
4 Register assignment (use of B registers to hold array
subscripts)
0 Prefetching (of elements of B and C)
The object code under OPT=2 is two words shorter than the
object code under OPT=0. More significantly, the loop itself
is reduced from six words to two words.

SOURCE CODE OPTIMIZATION

0SS

/$sfe\

A program compiled under OPT=2 almost always runs faster
than a program compiled under OPT=0, OPT=l, or time
sharing (TS) mode. The amount of improvement depends
primarily on the number of loops in the program, because
that is where most of the optimization under OPT=2 takes
place.
In addition to the optimizations performed by the compiler,
the user can rewrite the source code in such a way as to
improve its performance, especially for cases that the
compiler is incapable of optimizing, time should be devoted
only to optimizing loops, especially innermost loops; optimi
zations in straight-line code are not likely to be fruitful.
Source code optimization should not be done at the expense
of other desirable features; some optimizations decrease
execution time while increasing field length. (This is rarely
true for compiler optimizations.) Also, many optimizations
decrease the comprehensibility or ease of maintenance of a
program. The added cost in programmer time often exceeds
the savings in execution time.
With these cautions in mind, the user can decide which of
the source code optimizations described here is worthwhile
in any given application.

HELPING THE COMPI LER OPTIMIZE
/p^\

Probably the most important source code optimizations are
those intended to maximize the optimizations the compiler
can perform. Many of these have already been discussed in
the context of the compiler optimizations, so only a
summary is necessary here.
A primary consideration is to avoid unnecessary use of
common blocks and equivalence classes. With variables in
common, every subroutine call or function reference
requires the compiler to store the variable before the
reference, because it cannot be determined at compile time
whether the variable is used in the referenced subprogram.
In particular, the practice sometimes encountered of
allocating local scratch variables in unused portions of

60499700 A

common blocks to save space is very detrimental, and can
actually cause space to be wasted. For example, in the
following sequence:
COMMON I,A(1000),B(1000)
DO 100 I = 1,1000
A(I) = 4*B(I)
CALL SUB1 (C,D)
100 CONTINUE
CALL SUB2
END
I is in common, therefore its value must be stored before
each call to SUB1 or SUB2. These two stores, 30 bits each,
occupy the same amount of space as the variable. If I were
not in common, the stores could be eliminated, saving the
same amount of space and considerably speeding execution.
Equivalence classes inhibit optimization in somewhat less
obvious ways. The following example is typical:
DIMENSION X(100)
EQUIVALENCE (X(1),W)
W=Y
PRINT *,X(I)
STOP
END
Without the EQUIVALENCE statement, the assignment
statement could be eliminated because the value of W is not
used again in the program. However, because W is
equivalenced to X(l), and the PRINT statement might
reference X(l), the assignment statement cannot be
eliminated.
These cautions are not meant to discourage legitimate uses
of common blocks and equivalence classes. In particular,
when variables are needed by more than one program unit, it
is faster to pass them through common than as parameters,
because the code for setting up and using the parameter list
is eliminated.
Another major way to help the compiler optimize is to keep
program logic straightforward and simple, and to keep
program units short. Of course, this also improves program
readability and modularity. But the advantage to the
optimizer is that it is more likely to correctly identify loops
and monitor the usage of variables in different portions of
the program.
It has already been mentioned that the optimizer recognizes
IF loops as well as DO loops. The user should keep in mind
that the more closely the IF loop resembles a DO loop, the
more different kinds of optimizations are performed. (The
implication of this is that a DO loop should be used
whenever possible.) For example, the IF loop in the
following sequence of code:

1=1
100 A(I) = B(I) + C(I)
1=1+1
IF (I.LE.12) GO TO 100
generates code essentially identical to that generated by the
following DO loop:
DO 100 1=1,12
A(I) = B(I) + C(I)
100 CONTINUE

3-9

and all the same optimizations are performed. However, if
the loop is changed to the following algebraically identical
form:

1=1
100 A(I) = B(I) + C(I)
1 = 1+1
F(I+5.LE.17) GO TO 100
some of the optimizations the compiler performed in the
first case cannot be performed in the second (for example,
test replacement).

LOOP RESTRUCTURING
When the user is rewriting a program to optimize the source
code, special attention should be paid to the loops, because
that is where most of the execution time is spent in a
typical FORTRAN program. Frequently, the users can take
advantage of their knowledge of the peculiarities of their,
own programs to rewrite loops in such a way as to reduce
the total number of operations performed at execution time.
One of the best known methods of restructuring is called
loop unrolling. The idea is to reduce the overhead resulting
from incrementing and testing the loop control variable by
reducing the number of times the loop is executed. For
example, the following loop:
DO 100 1=1,10000
X(I) = Z(I)**2
100 CONTINUE
can be replaced by this loop:
DO 100 1=1,9999,2
X(I) = Z(I)**2
X(I+1) = Z(I+1)**2
100 CONTINUE
In the second case, only half as many increment, test, and
branch instructions are executed.
One disadvantage of loop unrolling is that it makes programs
m o r e d i f fi c u l t t o u n d e r s t a n d . C a r r i e d t o i t s l o g i c a l
conclusion, loops would be completely eliminated, and
replaced with long sequences of assignment statements.
Clearly the user who is this concerned with optimization
would be better off coding in COMPASS in the first place.
A more technical limitation of unrolling arises in the case
when it is not known at compile time just how often the loop
will be executed. For example, if the DO statement is:

DO 100 1=1,3
unrolling does not produce the correct results unless J is an
even number (assuming that each assignment statement is
unrolled into two statements).
Another way to reduce the overhead associated with loops is
to combine them. For example, in the sequence:
DO 100 I=1,K
A(I) = B(I) + C(I)
100 CONTINUE
DO 110 J=1,K
E(J) = F(J) + G(J)
100 CONTINUE

3-10

the two loops can be combined into one, thus reducing by
half the overhead associated with the loop:
DO 100 I=1,K
A(I) = B(I) + C(I)
E(I) = F(I) + G(I)
100 CONTINUE
Combining loops is usually worthwhile; however, its useful
ness as an optimizing tool is limited by the requirement that
both original loops must be executed the same number of
times.

MISCELLANEOUS OPTIMIZATIONS
The following is a list of miscellaneous techniques for
optimization which might be found helpful under particular
circumstances. They are discussed very briefly.
1. Avoid mixing modes in an expression. Each conversion
from one mode to another requires extra instructions.
An exception is exponentiation; integers as exponents
are usually quicker than real numbers, whatever the
base. When a choice among modes is possible for an
expression, the choice should be made according to the
f o l l o w i n g h i e r a r c h y ( f r o m m o s t e f fi c i e n t t o l e a s t
efficient):
Integer
Real

A^m^s

r^S\

Double Precision
Double precision is especially inefficient, and should be
avoided whenever possible. A single precision floating
point number has 48 significant bits, which is more than
enough for most purposes.
2. If a program is only going to be relocated once (see
section 7), but executed many times, the DATA state
ment is preferable to assignment statements for initial
ization of variables, especially large arrays.
3. The forms of conditional branch, from slowest to
fastest, are as follows:
Computed GO TO
IF statement
Assigned GO TO
Unfortunately, the assigned GO TO makes following the
flow of control in a program more difficult, and also
impedes the detection of logic errors^ during debugging;
it must be used with caution. When more than four or
five branches can be taken from a given point, the
c o m p u t e d G O T O i s m o r e e f fi c i e n t t h a n t h e I F
statement.
4. More efficient code is generated if one branch of an
arithmetic IF or two-branch logical IF immediately
follows the IF statement. In this case, the path for this
statement falls through instead of branching.
5. References to basic external functions should be consol
idated whenever possible. For example:
A = ALOG(C) + ALOG(D)
is not as efficient as:
A = ALOG(C*D)

60499700 A

y*W-X

/fpSv

6. If the executable statements in a function subprogram
can be consolidated into a single assignment statement,
a statement function is more efficient. Because the
code for a statement function is expanded inline during
compilation, the overhead associated with passing
parameters, saving registers, and branching to and from
the function is saved for each function reference.
7. Expressions should be factored whenever possible to
reduce the number of operations required for evalu
ation. For example:
X = A*C + B*C + A*D + B*D
should be replaced by:

AVOID ILL-CONDITIONING
Because of the inherent properties of certain mathematical
functions, precision is increasingly lost as the function
approaches a certain value. In an effort to counteract this
effect, programmers often use the double precision versions
of the functions. However, this technique is drastically less
efficient and often produces results that are less accurate.
In many cases, better and faster results can be achieved by
rewriting the referencing expressions and avoiding the
double precision functions.
The problem arises for values of the argument for which the
derivative of the function is very large. More precisely,
when the following function:
nfv\ - x f'(x)

X = (A + B) * (C + D)
The first version requires four multiplications and three
additions; the second requires only one multiplication
and two additions.
/pp^\

For example, in the expression:

SQRT(1.-X**2)

PROGRAMMING FOR GREATER
ACCURACY
0$S

is very large, which is usually true when the derivative is
very large.

The remainder of this section presents some miscellaneous
ideas designed to improve the accuracy and efficiency of
mathematical programs coded in FORTRAN Extended.

when the value of X is very close to 1., the result of the
expression tends not to be very accurate. Therefore, X is
frequently declared double precision, and the expression
rewritten as:
SNGL(DSQRT(1. - X**2))
However, noting that:

/$PN

SUM SMALL TO LARGE
It is better to sum from small to large than from large to
small. That is, when a group of numbers is to be added
together, if the numbers vary widely in magnitude, a more
accurate result is achieved if the smallest numbers are
added first, and then the largest, rather than the other way
around.
This can best be explained by an illustration. For the sake
of simplicity, assume that the computer can only maintain
four decimal digits of accuracy. When two numbers are
added, only the four most significant digits of the result are
kept, and the remainder is truncated. If the following series
of numbers is to be added:

.00001234
.00005678
.00003121
.41610000
.21320000
the true result is .62940033. If the numbers are added in
pairs from largest to smallest, and all but four significant
digits of each result discarded, the result is .6293. If they
are added from smallest to largest, the result is .6294, which
is more accurate.

"C

The expression can be rewritten with greater accuracy as:
SQRT((1.+SNGL(X)) * SNGL(l.-X))
The amplification of relative error when the value of a
function nears a certain value is a particular problem with
trigonometric functions. With the tangent function, the
function g(x) defined above has the value:
9 sin(x) cos(x)
g increases without limit as x approaches any multiple of
ir/2 radians. When the value of x might be in this range,
programmers frequently declare x double precision and
compute the function as follows:
SNGL(DTAN(X))
However, greater accuracy and efficiency can be achieved
by declaring x double precision and using the addition
formula for tangents (since a double precision number is the
sum of its upper and lower parts). The formula is as follows
(where x is the upper word of the double precision number,
and x. is the lower word):
tan(x ) + tan(x.)
u r 1 - tan(x ) tan(x.)

tan (x + x.) =,—r—?—r-r—7—x

The explanation of this phenomenon is that, when adding
from smallest to largest, because of carrying, the cumula
tive total of the small numbers often has one or more
significant digits within the range of the larger numbers.
Adding from largest to smallest, however, the total becomes
very large immediately, and smaller numbers are ignored
completely.

60499700 A
/ ^ N

1 - X2 = (1 - X) (1 + X)

Furthermore, for any number x less than 10 , tan (x.) is
approximately the same as x.. Therefore the formula can be
rewritten as:
tan(xu) + Xj
tan(x u + Vx.)1 =i—z—7—^—
- tan(x ) x.

3-11

or, in FORTRAN:
DOUBLE PRECISION X

An even better example is the exponentiation function EXP.
In this case, the larger the value of x, the larger the
function g(x) defined above. The addition formula in this
case is as follows:

XU = SNGL(X)
XL = X - XU
RESULT = (TAN(XU) + XL) / (1. - TAN(XU) * XL)
using no double precision arithmetic.
Similar substitutions can be made for sine and cosine, using
the addition formulas and the information that sin(x.) is
approximately x., while cos(x.) is approximately 1.0.

exp(xu + Xj) = exp(xu) + Xj exp(xu)
or, in FORTRAN:
DOUBLE PRECISION X

>*S8>\

RESULT = EXP(SNGL(X)) + (X - SNGL(X)) *
1(EXP(SNGL(X)))

-/*^\

3-12

60499700 A

DEBUGGING

Debugging can be difficult and time consuming, particularly
where lengthly programs and intricate logic are involved.
FORTRAN Extended and the operating systems that support
it offer the programmer several features that can aid in the
debugging process. By becoming familiar with these
features, the amount of time involved in debugging programs
can be substantially reduced.
JpN
The debugging process actually begins when the program is
initially coded; a program that is well documented and has
logic that is easy to follow is easier to debug than one that
is not. (Refer to section 1 for a discussion of good
programming practices.)
Debugging a FORTRAN program involves three steps, which
can be summarized as follows:

0^S

Desk checking The program is checked for obvious
keypunch and logic errors. A simple
test case can be followed through the
program by hand to test the logic.
Compilation The program is compiled using a fast
compilation mode. Errors detected
by the compiler are identified and
corrected.
Execution The program is executed using test
cases designed to thoroughly test all
aspects of the program. If possible,
output should be compared with a
known standard to ensure cor
rectness.
In this section, these steps are illustrated by means of a
sample program which is debugged using some of the
features of FORTRAN Extended. Although the typical
FORTRAN program is much longer than the sample
program, portions of many longer programs often can be
coded and debugged separately and the intermediate results
checked. The program illustrated is program ACCTAB,
which is discussed in section 2 in its final version. It is
shown in figure 4-1, complete with bugs, as it might appear
after initial coding.

DESK CHECKING
The programmer should examine a program for the more
obvious errors before attempting to compile and execute it.
Regardless of how carefully a program is desk checked,
however, it might not run or even compile without errors on
the first attempt. Because of this the programmer should
not spend a lot of time desk checking; instead, the computer
should be allowed to do as much of the debugging as
possible. Even with a program as small as the sample
program (figure 4-1), it is unlikely that desk checking would
reveal all the bugs.

^0SS

An examination of the sample program ACCTAB reveals
some obvious blunders. The character . appearing in line
13 is a mispunch; the programmer intended to type a / .
The compiler would have detected this particular error. On
the other hand, if the character * had been punched instead
of the character . , the statement would have been

60499700 A

syntactically correct and the error not quite as obvious. In
line 20, a left parenthesis should be a right parenthesis. The
error in line 41 is obvious; the statement was punched
starting in column 1 instead of in column 7. The compiler
would have detected both of these errors.
In addition to checking for syntax errors, the programmer
should examine the program for logic errors and ensure that
no steps have been left out. Informative comments are
helpful in verifying program logic. The comments included
in ACCTAB indicate that all the necessary steps are present
and in the correct logical sequence and that the flow of the
program is essentially correct. Or is it? After interpolating
and printing time and acceleration, the program is supposed
to branch back and read the next statement; but the branch
in line 48 goes back to the beginning of the program where
the data for the table is read. The correct branch is to the
statement labeled 190.
Although closer inspection of the program might reveal
additional bugs, this illustration continues with an attempt
to compile ACCTAB.

COMPILATION
The FORTRAN Extended compiler provides useful debugging
information, particularly the diagnostic messages and the
cross-reference map.
The following control statement is used for the first attempt
at compilation of ACCTAB:
FTN,Q,R=3.
On the FTN control statement, the Q parameter specifies
quick mode: the compiler performs a full syntactic scan of
the source code but does not produce object code. The
program cannot be executed in the absence of object code,
but compilation errors would undoubtedly prevent execution
anyway and Q mode compilation is substantially faster than
normal compilation. For debugging purposes, compilation
speed is more important than optimization of object code.
When the program has been completely debugged and
checked out, it will be recompiled to produce optimized
object code. The R=3 parameter produces a long crossreference map. By default, the compiler produces a list of
informative and fatal diagnostics.

DIAGNOSTIC SCAN
The source listing and diagnostic messages issued during
compilation of ACCTAB are shown in figure 4-2. Informa
tion provided in the diagnostic messages includes the line
number where the error occurred, the severity of the error,
and a brief description of the problem. In figure 4-2, two
different codes appear in the severity column.
Severity I indicates that the message is informative; the
compiler can produce executable object code, although the
results from executing the code might not be correct. As a
matter of good programming practice, the programmer
should try to eliminate the causes of informative diagnostics
from the program. Severity code FE indicates that the error
is fatal and the program cannot execute.

4-1

.-*^%v

In figure 4-2, the first error in ACCTAB occurs in line 12,
where times are being stored in the array TIME. In line 12
the array subscript is missing. The corrected line reads:
TIME(N) = T
Because the severity code
warning message. It would
from executing; however,
effects upon the results of

is I, this error produced only a
not have prevented the program
it would have had catastrophic
the execution.

1

The next error is in line 18; it also has generated an
informative message. The executable statement just before
line 18 is an unconditional branch to statement label 100.
Because the statement at line 18 has no label, there is no
logical path to that statement. The correct branch is
specified in line 9, but the label has been omitted from
line 18. The corrected statement reads:
150 NTIMES = N

PROGRAH ACCTAB CINPUT,OUTPUT,TAPE4*INPUT)
C

5

10

DIMENSION TIHE(IO), ACC(IC)
C
C....REA0 TIME, MASS, FORCE, ANO COMPUTE ACCELERATION TABLE
C
N s 0
1 0 0 R E A D ( 4 , * ) T, A M A S S , F
I F ( E O F ( 4 ) . N E . 0 ) G O TO 1 5 0
N = N ♦ 1
IF CN .GT. 10 ) GO TO 600
TINE = T
ACCCN) * F.AMASS
GO TO 100

15

20

25

30

C . . . P R I N T A C C E L E R AT I O N TA B L E
C
NTIMES t H
PRINT IC
PRINT 15, (TIHE(I),ACC (K,1=1,NTIMES)
C
C....REAO A CARO CONTAINING A TIME VALUE
C
190 REAO (4 *) T
IF CE0FC4) .NE 0) GO TO 900
N a N ♦ 1
C
C....SEARCH ACCELERATION TABLE
C
DO 200 I t 2,NTIMES
IT = I
IF (T .LE. TINECIT)) GO TO 220
200 CONTINUE
GO TO 650

35

40

45

50

55

60

C....DO SECOND OEGREE INTERPOLATION
C
2 2 0 D I - T I M E C I T- 1 ) - T I K E ( I T )
D 2 = T I M E C I T- 1 ) - T I M E U T + 1 )
03 = TIME(IT) - TIHECIT*1>
Q l * T - T I M E C I T- 11
Q2 = T - TIME(IT)
Q3 = T - TIMECIT*1)
A C C X = Q 2 * a 3 * A C C C I T- l ) / C D I * D 2 >
1 - Qi*Q3»ACCCIT)/CDi»D3)
2 ♦ Q1*Q2»ACCCIT*1)/CD2»03)
P R I N T 2 5 , T, A C C X
GO TO 190
C
600 PRINT *, =TOO MUCH OATA. HAX NO. OF TIMES IS*
STOP
850 PRINT ♦, * INTERPOLATION PROBLEMS, TABLE ERROR*
GO TO 190
900 PRINT ♦, * ENO ACCTAB*
STOP
C
10
F O R M AT
(*1*,2(*
TIME
ACCEL*))

■■N
^

15 FORMAT C2C5XF7.2,2XF0.5)>
2 5 F O R M AT C * T I M E = * * F 7 . 2 , * A C C E L E R AT I O N * * , F 8 . 5 )
END

Figure 4-1. Program ACCTAB Before Debugging

4-2

60499700 A

PROGRAM ACCTAB < INPUT, OUTPUT, TAPE4=INPUT)
C
DIMENSION TIHF(lu), ACC(IC)
C
C....REAO TIME, MASS, FORoE, AND COMPUTE ACCELERATION TABLE
C
N = C
IC-j READ (<♦,♦) T, AMASS, F
IF (E0F(4) .NE. u) GO TO 150
N = N «• 1
I F ( N . G T. l i - ) G O T U 6 0 3

IC

TIME = T

ACC(N> = F/AMASS
GO TO 10C
C
C . . . P R I N T A C C E L E R AT I O N TA B L E

15

r-

tt

NTIMES = N
PRINT IC
PRINT 15, CTIMECI),AGC(I),1=1,NTIMES)
C-

C....REAQ A CARD CONTAINING A TIME VALUE
19. READ U ♦) T
IF CECFU) .NE a) GO TO 9 J \i
N = N ♦ 1

25

C
C....SEARCH ACCELERATION TABLE
C
3C

OO 2CC I = 2,NTIMES
IT = I

IF (T .LE. TINECIT)) GO TO 22u
2CC CONTINUE
GO TO i53
35

C
L....00 SECOND OEGRtE INTERPOLATION
C
iiu

01 - TIHECIT-1I - TIME(IT)
D 2 = T I M E ( I T- i ) - T I M E C I T + 1 )

C3 = TIMECIT) - TIMECITtl)
Ci = T - TIMECIT-1)

i2 = T - TIKECIT)
G3 = T - TIMECIT + 1)
ACCX = Q2»Q3*ACuCIT-l> /C0I*02)
1 - C1*U3*ACCCIT*/C01»03)
2 ♦ Gl*Q2»ACCCITH)/ Cu2*03>
P R I N T 2 5 , T, A C C X

U5

GO TO 19C
C

S5

C

P. SErfEPITY
12
19
24
25
25
35
5C
60

I
I
FE
FE
FE
FE
FE
FF

6.0 PRINT ♦, =TOO MULH U*TA. MAX NO. OF TIMES IS*
STOP
8CC PRINT ♦, f- INTERPOLATION PROBLEMS, TABLE ERROR*
GO TO 19C
90C PRINT *, * ENO ACCTAB*
STOP
I C F O R M AT ( * i * , 2 ( * T I M E A C C E L * ) )
15 FORMAT CwM5AE7.2,2xFi.5))
25 FORMAT C* TIME = *,F7.2,* ACCELERATION = *,F8.5)
ENO

DETAILS
TIME
NEC
TOOMUChD

DIAGNOSIS OF PR03LEM
ARRAY NAME OPtRANu NOT SUBSCRIPTED, FIRST ELEMENT HILL BE USLU.
THERE IS NO PATH TO THIS STATEMENT.
SYNTAX ERROR IN INPUT/OUTPUT STATEMENT.
INVALID USE OF A CHARACTER STRING.
UNMATCHED PARENThESIS.
UNRECOGNIZED STATEMENT.
SYMBOLIC NAHE HAS TOO MANY CHARACTERS.
UNDEFINED STATEMENT LA8ELCS), SEE LIST BELOW.

UNDEFINEO LAPELS
15 C
Figure 4-2. Example after Desk Checking, with Diagnostics
60499700 A

4-3

The error in line 24 is a fatal error: a comma is missing
from the READ statement. The corrected statement reads:
190 READ (4,*) T
The statement at line 25 has generated two fatal diag
nostics. Neither states explicitly what the problem is. It
often happens that error messages appear to have little
relation to the errors that caused them. In such cases, it is
sometimes necessary for the programmer to use some
imagination in determining the cause of the diagnostic. In
the example, it is easily seen that a period is missing from
the .NE. operator. This is clear from reading the FORTRAN
statement but not from reading the error message.
In line 38, the character = was mispunched as the - char
acter. The compiler could not recognize the statement and
generated a fatal error. The corrected line reads:

220 DI = TIME(I-l) - TIME(I)
If the statement had been mispunched with two equal signs
instead of two minus signs as follows:
220 DI = TIME(I-l) = TIME(I)
it would have been interpreted as a multiple replacement
statement, and no diagnostic would have been generated.
The message referring to line 50 appears to have little
relation to the actual error. The opening & of the character
string was mispunched as an =. Once again, the message
gives little clue as to what is wrong with the statement;
however, it does indicate that something is wrong. If the
programmer is unable to determine the specific error from
the text of the message, the statement should be checked
for syntax errors.
The last message refers to a list of undefined labels. A
statement appearing in this list has been referenced in a
GO TO or other branching statement, but does not appear as
a statement label anywhere in the program. In locating the
cause of this error, the programmer can make use of the
cross-reference map.

CROSS-REFERENCE AAAP
The cross-reference map (figure 4-3) is a list of all symbols
used in the program, with the properties of each symbol and
the references to each symbol listed by source line number.
It can be used to detect errors that do not show up as
compilation errors. A typical listing is that for the
variable ACC; the map shows that it is located at address
12„ relative to the starting address of the program; is of
type real; is an array; is referenced once in line 3, twice in
line 20, and three times in line 44; and appears to the left of
an = in line 13.
For debugging purposes, it is useful to look at the column
under the heading SN. A stray name flag appears under SN
if the symbol appears only once in the program. Such
symbols are likely to be keypunch errors, misspellings, and
the like. In figure 4-3, the variables DI and DI both have
stray name flags. Also, they are both undefined; that is,
they do not appear to the left of an = , in a common block,
in an argument list, in an input statement, in an ASSIGN
statement or in a DATA statement. Both variables are
referenced in line 44. Apparently DI is a misspelling of DI.
The attempt to define DI, in line 38, failed because that
statement contained an error.

4-4

The EXTERNALS section of the reference map lists names
of functions and subroutines called from the program. The
programmer should check this section to make sure all
function and subroutine references are correct. The
e x t e r n a l n a m e s a p p e a r i n g i n A C C TA B a r e E O F ( t h e
FORTRAN function that tests for end-of-file) and TINE.
TINE is referenced in line 32 and appears to be a misspelling
of the array TIME. An error message has not been
generated, because the compiler has no way of knowing what
functions and subroutines will be loaded at execution time.
This error is left uncorrected to illustrate its effect on
further attempts to execute ACCTAB.
The last section of the cross-reference map lists each label
used in the program, the line numbers in which the label is
referenced, and the line where the label is defined.
Statement label 150 is referenced in line 9 of ACCTAB, but
does not appear as a statement label. This error, as
previously noted, is corrected by inserting the label in
line 18. This section of the map is also useful in locating
duplicate labels: a statement label defined in more than one
line generates a fatal error.
The corrected source listing is shown in figure 4-4.

EXECUTION TIME DEBUGGING
Errors detected during the execution of a program can cause
abnormal termination or produce incorrect results. The
standard dump (DMPX), load map, and the FORTRAN
Extended debugging facility can help the programmer
determine the causes of execution-time errors.
With all I and FE compilation errors presumably cor
rected, ACCTAB is ready for another compilation attempt.
This time it is anticipated that the program will compile
without errors and produce executable object code. Because
the program is still in the testing phase, a compilation mode
resulting in quick compilation but unoptimized object code is
used; the input data is included in the deck.
The program is then compiled with the following control
statement:
FTN,R=3,OPT=0.
When OPT=0 is specified in the control statement, the ER
option is implied. When this option is specified and an
execution-time error is detected, the approximate line
number in the source program where the error occurred is
printed in the dayfile. When OPT=l or OPT=2 is specified,
the default is ER=0. The T option is also implied when
OPT=0 is specified; this option produces a full error
traceback when an execution-time error is detected.
An important consideration in execution-time debugging is
the use of test data. The programmer should design one or
more test cases that completely test the program, including
all options and all possible paths through the logic. It is
frequently a good idea to include data that tests the limits
of acceptable values. The programmer should determine
what data causes execution errors or incorrect results, and
then either correct the program or include program state
ments to check for invalid data.
Once satisfactory test data has been selected, the results
must still be verified. Verification can be performed by
comparing the results to a known standard, or, if none is
available, by comparing to hand calculations.

^

V

60499700 A
^^?\

,

0$$S

■o

cm

(Jl 'J ID Ul -J

c-i o a 
o ui uj

to cn a

t* tn z z z TO

u. u. u.
ul ui u>
□ a o

U- U.
UJ u«

ezt a

■XH
r

a.
co

O O Ul Ul Ul 0 xH
■rH  u. u.
Ul Ul Ul
O Q O

j-

-t

_»

j-

or

S

OJ

(Vi

OJ

CVJ

M

OJ

C> J"
IVJ OJ

IO tr to

U
n

a

a

a

(At/)(/)C/)tOC/)(A{/1f/l(/tt/)t/>(/)UJt/)uJ
U . U . U - U . b . U . U . U . l L U . < : U . Z U . l L l L U . | j . Z U . Z
U i U I L J I U t i t l L l l i l U I U J U j H U J H U J U J U J U J I i i H U J H

o f a r i v a f a . ' Q f c v t v o f a r b . Q f u . a fi ' K Q r o f t v u . a f u .
ui
ui
ui
ui
o
o
a
a

UJ

m
Ul

tn tn ta
liJQ
z tr i \ l
<>
"
t- -x ul
M UJ OC

_ j
-VI
Qi

Ul

Ul

u.
Ul
oc

■O._>JTHJ*N)W

rl«

Ul

_J N. V3 O1 CO

u. u.

X
■

a a
z z

■t

za za
* *

Ul
Z ^

o: a.
Ul
Q .

J

J

J

kSI
J J J

-

I

J

Ui ul
J3
U U

t— ) !A bt A

Ul Ul

ac
oc

a


j j

Ul tr .3 r- -X o>

ac

&. ac ui
j:
u.

-.
">
II
a
"**:

o
z
UJ
!*

CO

in
x tn
o o xx
rA tn tn az f* ■,, tM to tiu< N N J j O I U > i i ; « J

tf»

<■• ^ -o N a\
viJ Vk> vO VL' Ul

Ul
uj O CL
a uj Ui >• -J
O X UJ l~ <
z: i-i a.' uj
Z u. Qi

-J
«*
ui
a

f-

f-

f-

Z Z Z
i^illu.

u.

Ui
a

i- 3 JMQ.i-a u, z
UJZ3«t(/)OH
j: t-i o i— -J u t-

O O Cl O U U O (..I
Z ' H H N ' H H r l W W v D O O I J '
UJ -J H J O
I—
f>>
J

U U
J"

U U
_i

ll

.J

Li

o z

H4 
Q l = T - T I M E ( I T- I )
Q2 = T - TIMECIT)
03 = T - TIMECIT + i)
A C C X = Q 2 » Q 3 * A C C ( I T- 1 ) / ( D 1 * D 2 )
1 - Ql»a3*ACC(IT)/(Ol*03)
2 ♦ 01*Q2*ACC(IT+1)/(D2*D3)
P R I N T 2 5 , T, A C C X
GO TO 190
C
6CC PRINT *, * TOO MUCH OATA. MAX NO. OF TIMES IS IC*
STOP
85C PRINT *, r INTERPOLATION PROBLEMS, TABLE ERROR*
GO TO 190
90Q PRINT *, * END ACCTAB?
STOP
C
IS
F O R M AT
(*l*,2l*
TIME
ACCEL*))
1 5 F O R M AT ( 2 ( 5 X F 7 . 2 , 2 X F t t . 5 ) )
2 5 F O R M AT i t T I M t =■ * , F 7 . 2 , * A C C E L E R AT I O N = * , F 8 . 5 )
ENO

/^^V

Figure 4-4. Example with Compilation Errors Corrected

j*SE^V

4-6

60499700 A

The data shown in figure 4-5 is used to check out ACCTAB.
The first data card results in a zero acceleration value; the
second card introduces a zero into the acceleration calcula
tion; the fifth card is a duplicate of the fourth. The second
set of data consists of selected times for which the table
search is performed. The first time corresponds to the
lower limit of the table; the second time corresponds to a
discrete point in the table; the third time causes the
duplicate point to be used in an interpolation; the fourth
time is below the lower limit of the table; the fifth and sixth
times require interpolation to be performed; the seventh
time corresponds to the last point in the table; and the last
time exceeds the upper limit of the table.

case, the jump is to entry point TINE. This instruction
occurs at relative address 4222. To locate this instruction in
the dump, the relative address of the instruction must be
added to the first word address (FWA) of the program:

DMPX AND LOAD MAP

This is a return jump to address 404333, an illegal address
generated by the loader when it was unable to locate the
nonexistent entry point. Because the address is outside the
program's field length, a mode 1 diagnostic was issued.

The dayfile from the first test with data is shown in
figure 4-6. This time, ACCTAB compiles without errors, is
loaded and executed, but terminates with errors. A nonfatal
loader error was detected. Because the error was nonfatal,
the program went into execution and subsequently termi
nated with an arithmetic mode 1 error. Mode 1 errors are
generated when the computer detects an address outside the
field length reserved for the program. The computer tried
to reference address 404334g, which is outside the field
length of ACCTAB. The load map (figure 4-7) shows that
ACCTAB was loaded at address 111„ with a last word
address (LWA) of 20447. The error summary on the map
states that ACCTAB references a function or subroutine
called TINE, which could not be found by the loader. As
previously noted, the EXTERNALS section of the crossreference map indicates that TINE is referenced in line 32,
where TINE is a misspelling of the array TIME. A dayfile
message also specifies line 32 as the location of the
arithmetic mode error. This message results from the ER
option.

0SS

More information can be obtained from the object listing
and the DMPX listing (figure 4-8). A DMPX listing is
produced automatically when a program terminates abnor
mally. The DMPX consists of the contents of the hardware
registers, the exchange package, the first 100„ words of the
program field length, and 200g words of memory centered on
the instruction the central processor was executing when the
error was detected.
The machine instructions associated with line 32 of the
source listing are shown in figure 4-9. This listing was
generated through the OL (object listing) control statement
option. FORTRAN Extended generates an RJT (return jump)
instruction to branch to an external entry point. In this
0. 10 0. 0.
1. G. 10CC.
2 . 1 0 0 . icia.
3 . 1 0 0 . 13 2C.
3. 10G. 1G2S.
4. 103. 103C.
5. 100. 1G4J.
0.
1.
-1.
2.5
3.5
4.5
5.
5.5

Figure 4-5. Test Data for ACCTAB

60499700 A

4222
111
4333
The instruction appearing at this address in the DMPX
listing is:
0100404333

Program debugging continues with a correction of the
misspelling, and rerunning of ACCTAB. The dayfile (fig
ure 4-10) reveals that a mode 2 error was detected during
execution. To determine the cause of this error, the
FORTRAN debugging facility is used.

DEBUGGI NG FACI Ll TY
FORTRAN Extended provides a debugging facility to
monitor the execution of a program. (Refer to the
FORTRAN Extended Reference Manual for a detailed
description of the facility.) The debugging facility consists
of statements that are included in the source input file and
processed by the compiler. The statements can be inter
spersed with the FORTRAN source statements, or they can
be included separately as an external deck. This allows
debugging of portions of a program, or of individual
subroutines, as well as the entire source file. In debug
mode, programs execute regardless of compilation errors (up
to a limit of 100 errors), but execution terminates when a
fatal error is detected. Hence, the debug facility is useful
in locating both compilation and execution-time errors.
Debug output is written by default to a file named DEBUG.
By equivalencing DEBUG to OUTPUT, the output can be
interspersed with program output.
Because ACCTAB is being run and debugged for the first
time, and no debugged program units are included in the
source file, an external debug deck is used; the debug
statements apply to the entire program. Debug statements
are included to provide information about the arrays ACC
and TIME. The job deck is shown in figure 4-11.
The D parameter on the FTN control statement implies
debug mode. The debug deck performs the following:
Checks bounds for arrays TIME and ACC; prints a
message if array bounds are exceeded
Prints a message each time the value of an element of
T or ACC changes
The NOGO statement suppresses partial execution if compi
lation errors are detected.
The dayfile in figure 4-10 states that an infinite value is
used near line 44 of the source listing. This is an arithmetic
mode 2 error. Infinite operands are usually generated by
dividing a nonzero number by zero, or by an addition,
subtraction, multiplication whose result is greater than

4-7

322
10 . Line 38 is the first line of the interpolation scheme.
One of the variables used in the equation contains an infinite
value (a value of 37770 ... 0fi); however, it is not clear
which variable contains the infinite value.
The debug file (figure 4-12) reveals that the second value
stored into the array ACC was infinite, indicated by R. It is
likely that this value, when used in the interpolation
calculation, caused the program to terminate with a mode 2
error. Referring to line 13 of figure 4-4, where values are
stored into array ACC, one might suspect that a division by
zero occurred here. This is verified by recalling that the
second data card contains a zero, which is subsequently
stored into the variable AMASS. Notice that the program
terminates only when the infinite value is used, not when it
is generated. If the program were executed on a CYBER 70
Model 76 or 7000 series computer, the mode error would
occur when the infinite value was generated. Figure 4-13
shows that coding has been inserted to test variable AMASS
for a zero or negative value and to print a message if zero is
detected.
For the next debugging step the data card containing the
zero value is removed from the deck and ACCTAB is run
again. The dayfile is shown in figure 4-14. An infinite value
has again been used, near line 47. To determine the source
of this infinite value, the following debug statement is used:
C$ STORES (D1,D2,D3,Q1,Q2,Q3)
This statement produces a printout of the intermediate
values used in the interpolation scheme. These values can
be useful in tracing the progress of the program. The
resulting debug output, interspersed with program output, is
shown in figure 4-15.

1 6 . 1 6 . 15.
16 . 1 6 . 15.
1 6 .. 1 6 . 15.
16 .16. 22.
16 .16. 25.
16 . 1 6 ., 2 5 .
16 , 1 6 ,. 3 1 .
16 . 1 6 . 32.
16 . 1 6 ,, 3 2 .
16 . 1 6 ., 3 2 .
16 . 1 6 . 3 2 .
16 .16. 32.
16 . 1 6 ., 3 2 .
16 . 1 6 . 3 2 .
1 6 .. 1 6 . 33.
16 . 1 6 . 3 3 .
1 6 . 1 6 ., 3 3 .
16 . 1 6 .. 3 3 .
16 . 1 6 ., 3 3 .
16 . 1 6 ., 3 3 .
1 6 . 1 6 ,. 3 3 .
16 . 1 6 ., 3 3 .
16 .16, 33.

The debug file reveals that the last value stored in variable
D3 was zero. D3 is calculated in line 43. If the two
consecutive times used in the calculation are equal, the
result is zero. Recall that a duplicate time point was
included in the data for the acceleration table. A debug
statement to print out values of the array TIME could be
used to verify that the duplicate point caused the error. The
coding to test for duplicate points is indicated in fig
ure 4-16.
The output from the next run is shown in figure 4-17. Some
of the acceleration values are correct, but accelerations
corresponding to points outside the table limits are not
printed. Also, the input time corresponding to the upper
limit of the table does not appear.
An examination of the dayfile reveals that this run termi
nated with a mode 2 error. Although the program processed
some input times correctly, it cannot process extreme
values. This illustrates the importance of test data that
includes such values. In figure 4-18, statements have been
inserted in ACCTAB to process times that fall outside the
table limits or coincide with the end points.

/^\

The output from the next run is shown in figure 4-19. The
table has been generated correctly and hand calculations
verify that the interpolations are correct. The two points
falling outside the limits of the table, whose values are -1.
and 5.5, have been detected. The program can now be
considered debugged. Of course, there are numerous
improvements that can be made to ACCTAB, and it is
possible that future use will reveal more bugs.
The program should now be recompiled with the following
control statement to produce optimized object code.
FTN,OPT=2.

FTST2 U * F* OM
/C6
IP
O O C 0 0 5 7 6 r f 0 * D S - FILE INPUT
, OC 0 4
FTST2,T5,P4.
FTN, P = 3,OPT = 0,() L .
. 4 1 6 Z * SECONDS COMPILATION TIME
LGO.
N O N - F ATA . LOAOER EfRRORS - SEE MAP
MODE

ER*0R

JOB R E P R I E V E D
U N S AT I S F I E D E (T IN ACSTAB NEAR LINE

32

. 0 2 7 3 P SECONDS EXECUTION TIME
(PREVIOUS ER*0* C0NDIM0M RESET)
ERROR MODE =01 , ftOORES'S S404334
OP 0 0 0 3 5 6 9 6 W O R O S - FILE OUTPUT , DC 40
MS
7168 WO^DS (
250 88 MAX USED)

CP4
1.136
CP3
.171
10
1.190
CM
40.043
SS
pp
6.954
EJ END OF J03 t

SEC.
SEC.
SEC.
KWS.
SEC.
u6

1 . 1 8 5 ADJ.
. 1 7 1 ADJ.
1 . 1 9 C ADJ.
2 . 4 4 3 AOJ.
4.991
D A T E l fl / 2 4 / 7 7

/■*s^V

Figure 4-6. Dayfile Showing Loader Errors and Mode 1 Errors

4-8

<*'^»k

60499700 A

UJ

•

V)
hZ
r i

>»
or

o

or

to

UJ

Ul o

—
» xc

a

M Ul 4
fZf- O

•
to
.

o
or

r l

Z

xH

.

1- V a.
* X fi O

a.
o

U t
|x-

m a cn

uz
a j

>
»

 O fi I H M

t—
-1
(/J o

1t— t—

to

u.

Ul

J C

t-l
f fi

•o.

-1

l-l

▶
-

a.

a a U l 3 Ul
za a
. z a. i- o. a 
.

QC

0,

z f- tn -if

I-O
OZ
Ul •X Ml OC UH
o f - - J az oc um za uh a r z o
Ui -1
O M

▶-» or u. or o

IA

N.
J
CVJ

*ft

1• 1-

Ul u.
•h a t- a iCC 1- Ul  -I tn -i tn

II
1-

xH

O _J
K H

_*

a
u > u.
M o

i—

ta

a - l

1-

-i t-t in
«t
1o 1oc za u»
or

Ul

Ul

_l
O . 4
2d
M
•» m or t-

Ul U l

to

z • or
• 
• i- U. I- II
za za tn
■J U |t u- O >mi-»

O IH CJ l - O H Q
f - U l I H ui or ui z
XX —1 U . 1 - X 1 - U l
U l tn a
J
o
Ul
NI - I O
UJ O Ul X
UH

-1

u.
z r

or co z
O ft ft
U. _l -I

A ^ l \
Ul

oc

•X
..1

fi

ca

X

*
•

tx.
XX

1
"1

T ,

0$&\

-1
a i

tx
Ul

o

_1 tzx o o ra is
 vD v£> .0 >J3 >J3
X X
x x x x
4- 4- 4- J J f J " J - J " J - J " 4 - 4 - 4 4- J t & o r ■ * 4 -

«3
JJ

Jt

4-

•J3 vD
4-

O l

4^ 4" -J" J - J -

-t 4- 4 - 4- 4" 4- 4^

4-

4" 4 -

4-

ro io ro t o «o ro «o fo ro ro ro ro

ro ro ro ro ro ro ro

ro

ro ro

in to to to to to CO IO IO CO CO CO io to to to 00
to to to tn tn <.i to to to CO to to CO CO CO to CO
< t •X
< 

oc
UJ

m

■
Z
3-

»
•

Ul
-1

to to to
to to to
4 4 4
0-0.0.

OC
IA

>tn

to
tn
o
QC
tx

z z z
X z z z z z z
o o o o o o O O O o o
o c > tx
^j tn U O () () i.l
(X, N. h- *. t - t r r>- r>- N- r- n.

Z
l—

u.

N .
N .

Ul
i -

Ul

z

«r

fi
t |x-

f - N- N. IV
V. S . N . ^
<> C» -3
i-» O t.J
f\J t\l CM C
M CM CM CM CM 

■s.

u.

a l
_ l

Ul

at

—l

u.

- j

j^pN

Kl :.l J

•■»*.
^

Of

4"

O i

f -

C J

M

co

to

a
■a

a:

a.'

1
—
1
—
Ul

r
z

i-.

C J

N. N.
N . S . f>~ fs.
"^ X
«-j i^j C . 1 CJ
CM CM CM CM
>H "s, V .
(T> tr t r t r
t-> ir> ca c>

■X*

z

«t -X

oc ot
f- u0C QC

CM CO

V *v

CJ

Cl r3

S K S K
>s N . - V X V

z

i - u-

t

j

■',

• i ca eo c»

V.

CM CM CM CM
N. N» N» N.

CM

t l
Pvl

tr



'.» 13 Cl CJ

z
Z Z Z Z
i o >o 4 - •rH
u 0 o o x x in 4rH -O 0 J3

«
-■

CM
S.

tr

u>

C.I

, J

tn

o o

i-i
CO

or or or or 0C QC OC QC OC
o o o
O O O o tn
ta o o tn tn m tn tn
u.
u_
u.
u. u. u. u. u. u. u. u. u. u. u. u. u. u. u. u. u.
.
1
1
1
»
•
r
|
■
v
■
I
i i i i
_ l _ l - l _ l _ l - J - J - l _ l -j _i
_ i _J -J - i - J _ i _ i _ i
co to v) in ti to to co oo a in tn to to 00 to to co to tn


-1

N.
fx- fx.
N.

fx.
fx.

r-

tr rr tr tr cr tr tr

<* . »«* vt.3 I—I
s.

z z z z

Z

—
•

to

'.J est CJ

z z
o o o

CJ O

».
-*

UH
IA

>-

co

-1
CO

tn

>-

I A

- J _l
to OO

_(»

-h x »n Tt vo • J
•o
4- j- m in
* xH

CM

r t

O J Ti Ti

I O xi
TO • r i
CM

fX

u j
-J

u,

u.

to

f t

•*

to

t—
< l

QC

cn

Z

r.J

•I 

ll
a- ll
«V O
»- >-i

II
-1

J?

tn

-*

fO ^ .-1 4 4 v P • » i n in ro
. fl U N I in cm

tn x x

.*
^%
•u« c»
N.
vD

-H CM »o in vO 4* *-i <\j r j t " l , . t vO •H 

Ul
•X

oc

*

Ul

u.
co
z

»a

II

ll

II II

1
1-

ii
QC II
U i z ■J
Z C J Q - O » H 1—

> . V.
Z
Z

>
»

II z
or
h • or

xc •- to
ti
o
tn za >- I H h m i
o to u. Z 3 O U . 4 Z
»- or 1— O l KlrtO
z o a
U l -1 o UJ a za za a- tn
H * r _ j O u. u. u. t D r J O O t O V

> ii
0. Z II
k tn u

z z u t - i- or
f-Z
o ui U - u. u. U . H

CJ f/> u. • 3 4 0 O O - i
"X,

li

a.—
»

ii

Ql

O;

<_i

>.

. .

■»—
♦Z

•-O U l
b-l

ct or

ar in o
a 7-

CJ

Ul

-> z

"x. "x.

4-9

i**^V

UJ
CJ
4

u.
or
Ul
i-

to

z

UJ

Jj

or

vO X
•t 41

CJ Ci
X lQ

4-

J- -t

13 •-» O '-.'J
O \0 00
J" 4" 4-

vO
vO■£> .£»
4 J- 4 -4"

4"

4- 4-

4 4- J" 4- 4 4" 4-

ro

ro ro

ro ro ro ro ro ro ro

CO 00
CO CO
4
4

00
to
4

oo oo
oo tn
4 4

to co oo to oo co co
oo oo to tn tn in in

CJ (1

tn

CJ (1

a a
z or
o o
fx. |x.

a.
z
o

a. a.
z z
o o
fx. fxfx. fx.
V. V
U C3
CM CM
xx. V
tT> CT

fx.

r>.

■J.
Xx.

CM

CT>

CO

4
a.
z
o
tn

4 4
a o_
z z
o o
tn tn

4
a.
z
o
i-3

r» rs. r-. r>- f>» ix. rs.
n. n. r». rx. fx. N. n.

V
N. V xx, V ♦>, V
-a -, a t-i <3 i j r->
CM fO CM CM CM CM CM

V X xs. V *x. "x. V
rr to tr ttt n\ fj\ -t\

. . 4". 4.-

ro ro ro
CO 00
ro 00
4
4

a. a.
z z
o o

to

to
CO '0 CO t o

a.

a.

fx.
fxx«.
' J
CM

|xrs-

fx- fx. rx.
r- rx. f x .

CJ

Xs, x * .
t o 1 ->
CM CM

t r

4

4

O

O

a. 0 - a.
z z z z
o o o
0.

CJ o
fx. rx.
fx- tx.
X* V
i.J '1
CM CM
V x».
er (xi

M
to

O o
M M
CO CO

»
.-

3 -

y -

'A

00 00

_ l

- 1 -1
oo 00

to

l O T i rx. fx.
IX.
to
CM
4-

ro
ro

O

O

>.
CM

V

tr

CT»

o o o o o o o

O

C l CJ

•»

fx.
fxN»
r l

CM

i

Xs,

fa- 3- >- >• >- >» >oooo i/i to oo oo oo oo
II
I
I
I
I
I
I
-i-i —* —i —i —i —i —I
00 00 00 00 00 00 CO 00

aoo
I
—r
00

(C\Mj i nri lfitnq r txn. H4o" a )Wi x .| H
in4
x,Orl
•H

-I

4-

00 00
-1 -J
00 to

j

x*.

Xx,

t r t r CT

123

tn o

UH fi

00 oooo oo oo to cn co oo oo

>00
I
_i
00

to

tn mm

tn
to

Cl

o

13

4-

. . . . . . .

4 4 4
a. a a.
z z z
O O o
t x tn li

CJ

X X X X
4 - 4 - 4^

vO X
4- 4-

U i

Ol
•H
-1

to

09

00 00 CO
300 00

00

- 1 -1 - 1 _J
00 to ' A 00

>- >-

rOsDfx.fx.lx.CMfx.rl
4»0
ro
4"

ro

' 3

r>.
u>

c l

xH

>oo

■^*fy\

H
■
r l

Tt

l fi a } l fl W * ' 0 ( M l f t 4 t O I O r . i c . i f x . ' j i , 3 i O l f t \ C f O S o W H o S > D f > K
in ui
I V J ^I lOf tN^Sf iC) Jk iaat 'f Ji ^r l) M
r ll iCn \i lr lN\ JJ 0I l3^ ii O
f l NN Cr lyl (f V
t r)l li «V5J li ,nOv bD\ N
i iS
i . r x linx . 4*
.M
> 0^ (^ sM, M
HT
l fW
t Uj u3 i». O
N o r i r«j
ro. ro«ro
CM CM CM

0jCMinU>U,imk0vDi0v0<.0s0sDs0j)kDu0U3<3i-JO

^ ^ r l r l r l r l r l r l r l r l r l r l r l r l r l r l r l r l r l r l r l r l r l r l r l r l r l r l C M C M C M

OOZV

0*x,

O

N.

O

*x

"x,

X

*x.

u. - u.orz o• r ou. o ou -• z ar
i - aco
r a co
u - oto .oozzooorooooororoo
a z a a ^ - z o u - o o•oou.ou.
o x•ore?
io o z * z . c o t o u . « • • - j . o r o r •• O. r c•D* Z. .X r •- > '>3.U_.. C- .0_3.c>.o
• o r o• o t o
3: * h- 4 I- •
uiujzari— « <(/) u.

o or
>

O • O
O . O . U J U J 3 l - f t : j M U J i y O « U . M IQ} rr 33 B! 3 U
U lJUU) J3 3
U lI U
C0
C _n Jj 0W0 UU 5I 3L UJ IQC. LUUJl H
l - (0/ 0) 33 O
0
ooo.i-o.340_joi-uioovr>-arxooo.aa-J-io_iQruiojQrou)
.ooui
S S 0 \ S Q . I \ U M D S \ t r t W W O O O O \ K O S O M > ; s S N v » N U , 0 ;

Z " ^ .

4-10

60499700 A

ia ca ca *j IO o
uaoas
cj
joaoN
a
O O 13 O |A O
o « o «?
u
a
a
a
aoouin
cj
o
o
a

ri
iv
ro

«j
o
o
o

IA
XJ
H
CM
O

O rl
o r g
O O
0
0
o
o

O
O
O
4CM

0
n>
0
0
0

Ul
(M
O
CM
4-

q
N
o
O <0 0
Q U O
O O O
0
0
0

CM
IA
«M
tx.

0
0
0
0
0
0
0
0
0
J J- -J
0
0
0

r l
r l

O
O
O
vo
J

CJ
O
t a

ca cj ca
0 '-3 0
O 10 <3
O rl CM
(3 tA O

o o o o t n i A o o
( M o H o i A r o o ^
o o H U t M n a N i O
H l O a H a 4 < O o H
i D 4 o i n f l o J a i A n

CM
IA
CM

0 t» 0
IA tO O
u«
00
IM O O
CJ 0 0

o
i
f
N
r

 H r i a o
v U « 0 O C U | A ^ t A O | w r . l V O w C 0 a ) x U i O i n r O i 0 t A I A r O | 0 O x l > < 0 C 3 O I A l > O X V W « 0 X W O o

0
0
0
0

O
s
O
0
o

r».
r a
CM
j -

0
00
0
0
*

W o o i A a
l 0 O O O O t A
w a a i o o N
u \ i g « N ( i i
c a - T - J ' r o .
•
O
o
H
0

(3

n N n Q O o o o i A H N <
I O r l \ 0 O O C 9 O ^ O C M C M H
^ t n ^ o a o o A i a i n i M n
4 < T ^ 4 i o < o i s i i i - T o 4 «
j ' o o o < n - T < T - r - 3 ' o o o o o

a o o c a o o o o r l c j o o
O O O O O O O ^ O O O O O I
a o N o a H S ' r o o Q a
v 0 t 0 r O v 0 4 H r l 4 c 9 c 9 < 0 > 0
4 4 > 4 ^ 0 t A t A o ^ 4 4 4 a r

o o
A U
J N
c 3 C
x . t

o
I
j
M
A

t N 4 * ^ < i o o o o o a o H
H C M C M ^ ' t A O O O C » O r l 4 ' I
i n i i i u i K j a o o o o i i i N
^ ' t « « a « i < i i o i S i 0 o J ; o »
c a o o - * o - T < * ' - J * - T o o ~ * ' o

c a o o
I A O O I
n M A n
C M C M H
t A t A l

o o o o o t a
A O C M O O
H i A H o a
H ( M H 4 - H > 0
A I A I A 0 I A

ri
-r
ia
cm
ro
mi
10
n
a
jJ
Jro
ro
< f N N r l N H N j a a < ' H « l l > I H H N O I A a H O
C M 4 C M c 3 t A O i 3 C > K r 0 ' 4 4 m i » l t A U \ t A f x . l 3 I
4*J04000tIJ
J
J"
JJ"
J"
O O O O O O O O I A O O O O c a O o O C M O O O

o o
O O
o o
« 0 U
^ ' 4

o
O
o
l l
'

a o c
O O C
a l A
0 O H 4
4 ' ^ 0

o a a o o o o
A C > O O O O r )
f a i j o a o i A
i a i S i o i p o ^
J - * ~ - ? - 3 * o o

j c j o o o o o o
M O O O O O O O
H a o o o o c i
' H t 0 « 0 « 0 l 0 O r l
0 O t A ^ ^ ^ ^ 0 a

 - ( M H n i x . a j - l n j - c j o J , ( M O o n c a o o o o o o r i a o o o o
H H n r t N H H H N f ) r l H H H H H N r t H H H * H r t r t H * 0 0 * H H H H J ' 0 0
mi'oixuMJ«K
Hou>
oiAolAiAtAro<0
iniA'twiAwwaaojiuiAilxuaoa

o
a
o
u
")
vi
o
o
o
o
it
o
o 4 J- xT o 4
O » w> K> U> KJ
o io io ro r>o-r.j-.rvO
a
n
^
o
n
a^J;
J-o

ro
4o
4

o H H H tA
o o -_j o -j
aaao
T
o
oo
or-,

H
o
a
a

II il n ll ll II ll
—. T. —. #S ^k —. T.
ri CM IO 4 IA «0 N.
s* s* -t w w w stf
O
OO
OOO
o

H
O
O
0
O

H
xi
H
0
O

>0
IO
CM

»
.

0
O
O
0
«

m o l fl i O c i O O l f t t J O O l M V I M W o . J ' . l - O
4 - o 4 o O O O J - J > t A O 4 o ( M r l O
C U O l M l A O O O t M J - r « . O < M O 4 - l
^ J * 4 ' i O J ) ' 0 * . » * i f l . T 0 4 , *
o - T o o J ' ^ - ' o c j t A - J ' o o o

u
s
o
.
x

^ n > v o
n ^ H o
o o i fl
O t A O J
. O O O a

c
a
g
K
«

H
A
v
o

j r s . o o o
- Y o H o o o
O D K H i fl a
l t O H r l H «
a M n i A « i f t

N i o i A H a i u t U a r
n H M o a n ^ n ^ f
i x o n i A a g o a a
- C M - T ' r l ^ ' O O C
l A O r l o O O O O C 3

C M C M r l
o l A t A l A t
O - J * » J
j ' o c a o

o
o
i
H
i

^MnnooMft
r < r 0 r M O O r l O
A l A l A l A o o ' 0 t A
J ; * ^ v O i O - » J
o o o o - T J ' o r

o o o o o o o o o o c
o t A o o o C M o o o o
M O N i n n i v i t o o a
N H H H N H v O l P 4 H
A i i M A t t i | i t m » J ; 0

r l o
l A l
, * J
a o

J - M fl M o c j K l fl J ' N
r 0 C M C 3 O H O r l O
A l A t A o o l 0 ( A l A t A
? . t . » i O v O * * * *
o o o - a ' j - o o o o

j o o o o o a o o
a o o c M o c j c a
a r i Q a M v O o o
O T l N r l l S l | ) 4
i A C j a l l t i A ^ « o

o
o
a
<
i

o o
o o
H a
l a r
A c i

o
o
a
l
a

| i i ' i x r ) o r ) > v o N N H < i i N a o O N < v i T | i i <
^ ^ i M a W r i n a W N i o i d o o n o i P M U
o o o W K o i A i M D o N q a o o i l i i i i o M
n o O O O O J - ^ ' O . a ' J - J - O O O O O O J - ^ - O O
0 a O O C M O O O C M < 3 H a s 3 0 0 c 3 C M O r l O a

i
i
a
O
c

x a c i
o o Q
o a a
O O O
a ) l 3

* O O rl tU «J CM
rl O O -1 a «M o
Itt Itt o r) a 01 o
4oo
o
o4^
o
O tM O O O O O
o
o
o
o
oo
a
o cj o o o tn o
o o o O O U3 o
d O o o u N
o o o o o r.
o o o rx. o ix.
a a o n a s

a
o
o
a

oa
uvvtaiua
oa
o
a
o
o
o
oo
o
o
o
a
o
e a N N o o a

O
O
O
O
O

O
O
O
O
O

IA
IA
0
o
ca

H ix. 0
0 4 O
0
4
0
o
o
o
ca CM ca

I A r x . f x . o o o f x . c 0
r 0 r l 4 O N i n o O O r 0
C M c 9 ( M O 4 r x . | A U > O
4'^4tD4-t44;iS-tN4'i0
o o - r a > A o o j

O
O
O
O
O

O
O
O
O
O

o
rl
H
ro
ca

o
o
o
ca ca 0
o o g
00 ca
0 0 ca

o a a
o o m o
O l A o
O O N t
O O O . 4

O
O rl 0
O
O o
o
O
O O IA
O O O O
O O O CM

O O H H o a C3
o o o o o o o
a a •* •* o o o
O O M N O M O

O
O
O
O
O

I I | | I I I I I I 11 I I

O
O
O
O
O

0 0
o
o
O O
O O
O O

Q r
a o o
O < 0 .
0 C M
C M

O O O O
0 13 ca a
rl O O CJ
rl
OO
0
tA OO O

i
a
*
C
I

o t A K C M o o o o o O O ^ C M r l l A o 4 ' | x . l A
o r l O l M t f < O O T - I O r l C M < M H i n O r
^ v 0 t n o 4 ' N . a o 4 ' O I A l A t A I A r O C M r O I A ( M
44i0v0J'va44'r4J;o^44
a r i a ' T o i n J J a 4 c i c i a o 4 J a

o i A o e l l i a o a o
o u o o t n o c o c j o o
H r s . | n l O N . r l o 4 ' O H
S H i O r l H o H a H l
' m r 0 m i A H t A C M t A . 4
> C
H o
' I A
M 4
O O

H H - r o i i i j n n
H H o N N H i D n
o O O I A I A o l A t A
O 0 0 < 4 4 ' O 4 '
O a O O O O O O H

i
o
4
4
O

m t A o l A o 4 ' r x . | A t A ( A o c r
! O - T 4 O ( n m o H O < f 4 O U >
C M O C M r O C v i n i A ( v i r A I < 3 I M
4o^«o4'444o t A I A l 0 C J r l « 0 « 0 O o l A \ 0 O r l c a c a o
l l H i g 4 l ( « l l H N H H « « 4 H o O O O * 4 « H e O O
> m r 0 a . 4 ' O . » | A l A | A t A O < M o l A o O O O O < M O | A O O O

o
o
O
O
O

M H H a n N ^ o S O ' i ' O v 0 o ' ' ' o o o o o
o j ^ H i A e a l A N N i S d l A U i a o N N O
' O O N - f O o i n Q m r - . Q I A O O O U M A O O I A O
' H O O r l ^ O ^ o ^ ^ 0 C M ^ O 0 H r | O 0 ( M
O l A O O o o O C M O t A ^ O O r l r l O O I A x t

o
o
O
0
O

i D
i S
C 3
^ O
' O

a n a o
I A I A
o l A t A
O r l H
O r l r l

o
o
O
O
o

CJ o o o o o o o o o o o o o o t A o o o o o r o o i A i n o o o o o o t A t n o o o o o o
OOrOQCMQCMOOCMIAOO
(MO
tnSNaNO^NmNNNaooO|l)NNNOOOO
Q o o N o o a ^ i A O S i n o a O N N a K a i a o i l i n a < J o D o a ' ' n a a a o o a
OHHHHHHHHNHHHHonHHHHHHoOHHHHOOOOHHH
tXOJX
' 4 O O t A v O f x . c g i A t A i 0 f > . I A O v 0 h > H a > O I A c g i A ' O ( 0 ^ r O i 0 ( 0 O O O C 3 « I O i X ) > 0 o o O f 3

H M rl 4- IA \D tr
4 4 4 4 4 4 4
OO

O

OO

O

O

a W g O O N U t a
o o a a u i O > O o
O O O O O ^ N O t
O O O O O i 0 N - O
D U o a o a M i
O O O O O o h - O

H J
r l
CD
o H
o IA IA
O ^ O O

I M • a CM
O

o w m n ^ i M O s a
CM O U i
03 CD CQ 00 tO CD CD CD cj
u
0
o
o CJ 0
0
a
o
o
O N 1 4 J M H 4
O M J ' I O d l A H
IA
J-urlolAvOmci
CJ
a j - i n w o j - ^ J - o c a
C M o o r i o o o o o o
0 r»
o o o o o o o o o o o o r o
O
4

JiniOKO
4 4 4 0
O
o
0 0 0 0 0 0 0
0 0 0 0 in 0 0
□
(MinSOOJ
0
Cl
iDOOUOrl
It
hmnoooo
CJ
O iM O CJ CJ O O cj
X
0.
x.
O

a

rl
4 4

e

NM
4 4

'4JZUU«
u.
w
a:

u.

x

O

o

CD
O

O

ua

0

0
a

0
0
o o

u a i n Cl C l
0 0 0
o
o
o
o o o i m o o
i_>

o

13
O C J U
CJ
a o M

o

o

t a t t
CJ CJ
o u

O rl O
O H r l
O rl N.
CJ 0 #
O 13 IA

rl O O rl
i O J O O
CJ CJ a 0
O O 0 O
0 O O 13

. * O N - c 3 I A i
n4no400H04
( M C M C M O C M
* J ' i 0 i 0 * J u n ^ o o

0 0 •*
0
0 IA
0
0 O
ca ca O
0
0 O

0
O
CJ
O
O

o o i n o o u n o a o a o o a
o o N - c j o o o c j o r o o o o o c
o s s H u i ^ i f t O N o e H n
c a s N n s H j H i O o H i t H a H H H n H fi H N H H a
o K 4 o i o a i A 4 o s « i A o i A

4ro
(O
*
•3

cj cj 0 ca
0 O cj ca
0 ca r- O
cm 0 in 0
ia r. n. 0

rro
IA
0
c»

* CM
rl rl
O O
O -T
O CM

0
rl
rl
ro
0

0
O
O
O
O

0
0
(3
O
O

a
O
0
rl
O

C I H H H O
H IA Ix. N. cs
rl 0 ca 0 0
v O I A 4 - ■» *
U\ rl H rl IA
t.
».

O
4 -3* O .? 0 O
c a 0 tn *0 10 r. ca
ca cj c a c a 0 a r l
ca cj 0 0 0 C J 0
0
0 O O O O O

ca o N N 4 C
c j r . o i x . H
o o s o n u n
o r - O l 0 O
O r x - O O

O o H o i A r O o r o t A c O I O o o v 3 c 9 . 4 r ' ) C M C M H I A i n o o 4 ' H < M H t n i A O O - 4 r l
00««OHONOHHNNN04«oooHN04*OQOH
t A < 3 I A O C M 0 0 4 ' C M I A I A N - r o r x . l A I A t A I A t A r x . C M I M C I O t A H l A l x . l M C \ I O O t A H
v 0 4 v 0 J - O v 0 * - * J - 4 ' 4 r f 4 4 - 4 4 4 > 4 O J - J - a ) « 0 J - o J - o 4 ' - » > O i 0 4 o
4 a ' ' u o 4 c i u o j N o N o o o o o 4 a o 4 . r o a o ^ o o J 4 o o

<
C
o
r
O

O o r s . O O O v
a S N O N S
O O r w O O O C
O O S H H H i
^ j ' N v O o i a n

«
.

i o i n
3 r i C M r
o n i A
O O O r l
O O O r

d o i l t o n o o o o o s o o o o o
a o \ 0 o 4 o Q t A o o r o r . l M o o o o
i A i A O M a M A n K fi n i fl i fi a a a
00
i f i n o n i A i n i i i i J M A < r c j o 4 ' t

N n n N 4 4 N s K a n o
. r i i 0 C M r ^ i o r o o i A C M o i
« o » ) a a i A S i A K o i
. ^ r l O C 9 O O 4 - 4 . * 4 O
l O r l O O O o O I A O C M

0 O O O O O O O O O O > x , C
N N O O a N a N N O ' l A
J O O O I A O O C J O C J l A o
O H H H H r l H H H H H S
i O i a c i i A o i s o i O i o u i n

l
J
r
N
i

o o s o o o o o o
o r o r . C M o o o o
a j i A i A d a o o a
i t i s e o r i e e o O i fl o o
o o i A 4 o o 4 j ; o o

t i N a 4 r ^ n o a n a
A o o i o i n K U > d i « 0 o a (
n K K 4 n i A ' 4 Q O K
. * . * O O r l H . ^ ^ O O Q
O a C M 4 i 4 H r | 0 0 0

o j 4 n
o i A r « > t
J ; i o i
C 3 r l r l
0 ^ 4 - H

f O O o r O I A r l O O O O Q O l A n o
N O ^ ^ I A O O O B O O ^ U I O
O o c j ^ O O H O G a r l n O O o H O
H H H H O o H H H H O O Q O fl
n n i fl u i m j ^ c i c i i M A o o j ' ^ c i

D J a 4 a 4 o 4 o J a 4 o 4 o f c i 4 o J a j O ' J o J o J
M J ' J m i A l O \ O N S c > . ( J r l r l < M C t i n fi ) 4 ' J I M I M O l O l s N i a O H < 4
CMCMCMCMCMCMCMiMCMroroforororoiorororOfororo'Oiorod'a .r -J- .*• •!
4 J - U ' J . f J J ' . C 4 4 ' * » * . J J * 4 J J J * J J J J J 4 *
o o o o o o o o o o o o o o o u t a o o o o c j o e o o o o o

o o
n \ O
A 4
4 ' .
r | 0

n o
t 0 o
4 o
4 O
0 0

o
o
o
O
0

c 3 O O O
a o o D
O r l r l O
H H H O
o i A i n o

O
O
O
O
o

o 4 o j a ' o J o j
A I M r > S O C j n r l l \ I N
ro ro •» .x -j- j- j- .»
^ J . I 4 J * J J 4 4
o o o o o o o o o o

O H CM IO 4- (A <0 rx.
xx
X X X

>^%
60499700 A

4-11

LINE
Q04221 CODb.

61020.Gi.4&

C04222 CODC.

0l&L

SBO
SAl
RJT

5111QC4311 CODE.
QGUcJu
<£XT>
CC4CCC.4134

32

B2+4CB
[AP3
TINE,4C3

•'*^\

Figure 4-9. Object Listing (Partial)

/"^\
10 .32, 26.
10 . 3 2 . 2 7 .
10 . 3 2 ., 2 7 .
10 . 3 2 .. 3 1 .
10 . 3 2 ., 3 5 .
10 . 3 2 ., 3 6 .
10 . 3 2 . 4 1 .
10 . 3 2 . 4 1 .
10 . 3 2 ., 4 1 .
10 . 3 2 .. 4 1 .
10 . 3 2 ,, 4 1 .
IC .32. 41.
10 . 3 2 , 4 1 .
10 . 3 2 . 4 2 .
10 . 3 2 ., 4 2 .
10 . 3 2 . 4 2 .
10 . 3 2 ., 4 2 .
10 . 3 2 . 4 2 ,
10 . 3 2 . 4 2 .
I G . 3 2 .42.
10 . 3 2 . 4 2 .
10 . 3 2 . 4 2 .

FTST39 7 F*OM
/C6
IP
OC000512 »mDS - F I L E INPUT
, OC 0 4
FTST3,T5,P4.
FTN, D , R = 3 .
. 4 5 5 C ° 5 EDONOS SOMPILATIO*1 TIME
LGO.
KODE ER*0R
JOB REPRIEVEO
NEAR LINE 44
I N F I N I T E V 4 - J E IN ACCT'AB
. 0 5 1 Z ° 5 ECONOS EXECUTION TIME
(PREVIOUS ER*OR CONDITIO*1 RESET)
ERROR 1O0E =0 2.
aOORFSS = 004470
OP 00002830 WORDS - F I L E OUTPUT , OC 40
HS
3584 
DIMENSION TIME(IC), ACC(10)
UAD TIME, MASS, FORCE, AND COMPUTE ACCELERATION TABLE

IC

IF* = 3
N = C
1 0 3 R E A O ( 4 , » ) T, A M A S S , F
IF iE0-<4) .NE. 0) GO TO 150
N = N •• 1

IF (N .GT. 10 ) GO TO 600
15

I F ( A M I S S . L E . C . ) G O TO 7 0 C
TIME(M) = T
ACC(N) = F/AMASS

GO TO 100
*RINT ACCELERATION TABLE
15J NTIMES = N
PRINT 10

PRINT 15, (TIM£(I),ACC(I),1=1,NTIMES)
IF 

....READ A CARO CONTAINING A TIME VALUE
1 9 3 R FA O U , » ) T
I F ( E 0 ~ ( 4 ) , N E . C ) G O TO 9 0 C
N = N ♦• 1

3:
I....SEARCH ACCELERATION TABLE

35

OO 200 I * 2,NTIMES
IT = I
IF (T .LE. TIME(IT)) GO TO ?23
23 J COMTINUf
a" TO 350
:....30 SECOND OEGREE INTERPOLATION

45

220 DI
02
03
01
02
33

=
=
=
=
=
=

TIME(IT-I) - TIME(IT)
TIMElIT-1) - TIME
DIMENSION TIME(IO), ACS(IO)
iH
xj

C....REA0 THE, MASS, FORCE, ANO COMPUTE ACCELERATION TABLE
•s

N s C
IFR = 3
133 READ U,») T, AMASS, F
IF  T
IF (E0F(4) .NE. 0) GO TO 900
N = N f 1
—▶ IF (T .LT. TIME(l) .OR. T .GT. TIME(NTIMES)) GO TO 800
—▶ IF (T .LE. TIME(NTIMES-D) GO TO i95
—* IT = NTIMES - 1
—▶ GO TO 220
o

35

4C

45

>^^\

C....SEARCH ACCELERATION TABLE
C
195 LIM - NTIMES - 1
OO 2fl:0 I = 2,LIM
IT a I
IF 
2 ♦ Qi»a2»ACC(im>/(D2»D3>
P R I N T 2 5 , T, A C C X
GO TO 190

55

0SS

rs

60

65

530 PRINT
STOP
739 PRINT
IFR GO TO
▶ 330 P R I N T
■*
50 TO
353 PRINT
50 TO
933 P=TNT
STOP

*, * TOO MUCH DATA. MAX NO. OF TIMES IS 10*
•:, *INVALID VALUE FOR AMASS *, N
1
100
• » * B A O T I M E , VA L U E I S * , T
19C
*, * INTERPOLATION PROBLEMS, TABLE ERROR*
19C
»;, * END ACCTAB*

i :
13 F O R M A T
(*1*,2(*
TIME
ACCEL*))
15 F O R M AT ( 2 ( 5 X F 7 . 2 , 2 X F 8 . 5 ) )
25 F O R M AT ( * T I M E = * , F 7 . 2 , * A C C E L E R AT I O N = * , F 8 . 5 )
END

Figure 4-18. Final ACCTAB Source Listing (Sheet 2 of 2)

k

NOS Skip Operations
The SKIPF, SKIPBF, SKIPR, and BKSP control statements
(figure 5-17) skip partitions and sections.
SKIPF bypasses partitions in a forward direction; SKIPBF
bypasses partitions in a reverse direction. End-of-partition
boundaries are skipped until the specified number, n, have
been read. The file denoted by lfn is then positioned
immediately after the nth boundary (for SKIPF) or immedi
ately after the preceding boundary (for SKIPBF). SKIPF and
SKIPBF skip partitions on all files except those with W type
(FORTRAN unformatted) records. For these files, SKIPR
and BKSP should be used.>
SKIPR bypasses sections in a forward direction; BKSP
bypasses sections in a reverse direction. End-of-section
boundaries are skipped until the specified number, n, have
been read. The file denoted by lfn is then positioned
immediately after the nth boundary (for SKIPR) or immedi
ately after the preceding boundary (for BKSP). An end-ofpartition boundary is counted as an end-of-section.

2. Before the end of the first job using the file, the file
must be identified to the system as a permanent file.
The required control statement is CATALOG.
Using an existing permanent file requires these steps:
1. Subsequent jobs must obtain access to the file from the
system before use. The required control statement is
AT TA C H .
2. If changes to a file are to be made permanent, the
system must be notified. The required control state
ment is EXTEND or ALTER.
3. When the file is no longer needed as a permanent file, it
should be removed from the system catalog. The
required control statement is PURGE.
The following control statements and parameters are those
most frequently used under NOS/BE and SCOPE 2.
SKIPF,lfn,np,m.

PERMANENT Fl LE USAGE

SKIPFB,lfn,np,m.

If a mass storage file containing user data or programs is to
remain in existence between jobs, it must be made a
permanent file. Because permanent file concepts and
control statements differ substantially between NOS on the
one hand and NOS/BE and SCOPE 2 on the other, they are
described separately.

SKIPR,lfn,ns,lvl,m.
BKSP,lfn,ns,m.
lfn

Logical file name of the file to be repositioned

np

Number of partitions to be skipped

ns

Number of sections to be skipped

Ivl

Level number of sections; 17 indicates partitions,
all other values indicate sections, the default is 0

Creating a permanent file under NOS/BE or SCOPE 2
involves the following steps:

m

File mode:

1. The file must be assigned to a permanent file device
before it is written. The required control statement is
REQUEST.

Figure 5-17. SKIPF, SKIPBF, SKIPR, and BKSP
Control Statement Formats (NOS)

NOS/BE AND SCOPE 2
PERMANENT FILES

C for coded, B for binary (default)

SKIPF,FILE,3.

0m\

SKIPF,FILE,3,17
E
0
S

SKIPB,FILE,4.
. E
O
S

Figure 5-16. SKIPB and SKIPF Examples (NOS/BE, SCOPE 2)

0!&\
60499700 A

5-7

REQUEST Control Statement
The REQUEST control statement for permanent files (fig
ure 5-18) ensures that the file can be made permanent. This
control statement must appear before any other reference
to the file in the job in which it is created. It specifies that
the file is to be assigned automatically to a permanent file
device when it is first referenced. The REQUEST control
statement is not applicable to an existing permanent file.

REQUEST,lfn,*PF.
Figure 5-18. REQUEST Control Statement Format
for Permanent Files (NOS/BE, SCOPE 2)

CATALOG,lfn,pfn,ID=idname,RP=days.
l f n L o g i c a l fi l e n a m e

CATALOG Control Statement
The CATALOG control statement (figure 5-19) declares a
file to be permanent. The file must exist on a permanent
file device. A file should be cataloged as soon as possible
after creation, so as to be more secure in event of system
failure.

ATTACH Control Statement

y^S^k

pfn Permanent file name; if omitted, the lfn is used
as the pfn
idname Owner or creator of the file
days Number of calendar days the file is to be
retained in the system; the default is installa
tion-defined

The ATTACH control statement (figure 5-20) makes a
previously cataloged permanent file available as a local file
to the current job. The logical file name can be different
from job to job. A file should not be attached until just
before it is needed, since each attached permanent file
represents increased overhead for the operating system.
Similarly, the file should be returned by the RETURN
control statement as soon as it is no longer needed within a
job.

ATTACH,lfn,pfn,ID=idname.

ALTER and EXTEND Control Statements

idname Name of the owner or creator of the file used
when the file was cataloged

All files processed by FORTRAN Extended are sequential
files except those processed by the mass storage input/output routines (READMS, WRITMS) and some of those
processed by the CRM interface routines. (See the
FORTRAN Extended Reference Manual for descriptions of
both these kinds of files.) On a sequential file, information
can be added only at the end; existing records cannot be
modified. If the file is permanent, it cannot be changed
unless either the EXTEND or ALTER control statement
(figure 5-21) is used.
EXTEND is used when information has been added at end-ofinformation. It causes the current end-of-information to
become the permanent end-of-information, thus making the
added information part of the permanent file.
ALTER can be used to change the length of the file. It
specifies that the current file position is to become the
permanent end-of-information. Thus, the file can either be
shortened or (when information has been added) lengthened.
Although the functions of ALTER and EXTEND overlap,
each has its specialized uses. When all the information that
has been added to a file is to become part of the file, but
the current file position is not at end-of-information,
EXTEND must be used. If any of the information currently
in the file is not to be part of the permanent file, ALTER
must be used.

Figure 5-19. CATALOG Control Statement
Format (NOS/BE, SCOPE 2)

lfn Logical file name; if omitted, pfn is used as lfn

■^8§\

pfn Permanent file name under which the file was
cataloged

Figure 5-20. ATTACH Control Statement
Format (NOS/8E, SCOPE 2)
EXTEND.Ifn.
ALTERJfn.
lfn Logical file name of file to be extended
or altered.
Figure 5-21. EXTEND and ALTER Control
Statement Formats (NOS/BE, SCOPE 2)
PURGE.Ifn.
lfn Logical file name

^m\

Figure 5-22. PURGE Control Statement Format
for Attached Files (NOS/BE, SCOPE 2)

PURGE,lfn,pfn,ID=idname.
l f n L o g i c a l fi l e n a m e

PURGE Control Statement
The PURGE control statement removes permanent file
status, so that the file referenced disappears at the end of a
job. A permanent file can be purged whether or not it is
attached. If the file is attached, the format shown in
figure 5-22 is used. If it is not attached, the format shown
in figure 5-23 is used and the file is attached after being
purged.

5-8

pfn Permanent file name
idname Name of the owner or creator used when the
file was cataloged

'*^\

Figure 5-23. PURGE Control Statement Format
for Unattached Files (NOS/BE, SCOPE 2)

60499700 A
./f*e^v

/tfp^\

Because the file remains attached
altered and then recataloged. If the
used anymore, a RETURN control
PURGE to remove the file from the

to the job, it can be
file is not going to be
statement should follow
system.

NOS PERMANENT Fl LES

0^\

Two kinds of permanent files are used under NOS: direct
access files and indirect access files. With indirect access
files, the user attaches a local copy of the file; only the
local copy is read or written. If the local copy is altered, it
does not replace the permanent copy unless the system is so
instructed. With direct access files, all reads and writes are
performed directly on the only copy of the file. For most
applications, direct access files are not as convenient as
indirect access files, as they are less secure (because they
are written directly) and they might use more system
resources (because mass storage space is preallocated).
Direct access files are more efficient for very large files,
however.
Creating a permanent file in batch mode involves the
following steps:

0^s

REP LACE Control Statement
The REPLACE control statement (figure 5-26) destroys the
permanent copy of the file specified by pfn and replaces it
with the local file specified by lfn. If pfn does not exist, a
permanent copy of the local file is saved with the name pfn
(in this case, REPLACE is identical to SAVE). It is not
necessary for lfn to be a local copy of pfn; it could be a new
file, or a local copy of some other permanent file.

DEFINE Control Statement
The DEFINE control statement (figure 5-27) specifies that a
file is to be a direct access permanent file. It can occur
either before the first reference to the file (that is, the file
does not exist yet) or after the last reference. The latter
method is usually preferable, since it keeps system resources
free as long as possible. However, the first method is more
secure in the event of system failure. DEFINE is not
applicable to existing direct access files; ATTACH must be
used instead.

1. The USER or ACCOUNT control statement identifies
the owner of the file to the system.

SAVE,lfn=pfn.

2. The file is created like any other file.

lfn Logical file name of the local file to be made
permanent

3. After the file is created, it is saved as a permanent file.
The required control statement is SAVE (for indirect
access) or DEFINE (for direct access).

pfn Permanent file name; if the equals sign and the
pfn are omitted, the lfn is used as the pfn

Using an existing permanent file requires these steps:

Figure 5-24. SAVE Control Statement Format (NOS)

1. A job using an indirect access file must obtain a copy of
the file for use as a local file. The required control
statement is GET. For a direct access file, the only
copy is made available to the job through the ATTACH
control statement.

GET,lfn=pfn.

2. For indirect access files, if changes are made to the
local copy, and these changes are to become part of the
permanent copy, the local copy replaces the permanent
copy. The required control statement is REPLACE.

pfn Permanent file name

3. When the file is no longer needed as a permanent file, it
should be removed from the system. The required
control statement is PURGE for both types of files.

lfn Logical file name to be assigned to the local
copy of a permanent file; if lfn and the equals
sign are omitted, the pfn is used as the lfn

Figure 5-25. GET Control Statement Format (NOS)

REPLACE,lfn=pfn.
The following control statements and parameters are those
most frequently used for permanent files.

lfn

Logical file name of the local file to replace a
permanent file

SAVE Control Statement

pfn

Permanent file name of the file to be replaced

The SAVE control statement (figure
file to be permanent. A permanent
current contents of the local file,
rewound. Subsequent changes can be
but the changes are not permanent
control statement is used.

5-24) declares a local
copy is made of the
and the local file is
made to the local file,
unless the REPLACE

GET Control Statement
/$#£\

The GET control statement (figure 5-25) obtains a local
copy of a permanent file and assigns to it the logical file
name lfn. If a file named lfn is already assigned to the user,
it is returned even if errors occur in processing the GET
control statement. The local copy is always rewound.

60499700 A

Figure 5-26. REPLACE Control Statement Format (NOS)
DEFINErlfn=pfn.
lfn

Logical file name of file> to be made
access file.

pfn

Permanent file name to be assigned. If the
equals sign and pfn are omitted , the lfn is used
as the pfn.

direct

Figure 5-27. DEFINE Control Statement Format (NOS)

5-9

0^$$\

y;/^\

ATTACH Control Statement
The ATTACH control statement (figure 5-28) makes an
existing direct access permanent file available to a job.
Subsequent output operations write directly to the only copy
of the file.

ATTACH,lfn=pfn.
lfn Logical file name to be assigned to direct access
permanent file.
pfn Permanent file name. If lfn and the equals sign
are omitted, the pfn is used as the lfn.

Figure 5-28. ATTACH Control Statement Format (NOS)

PURGE Control Statement
The PURGE control statement (figure 5-29) removes a
permanent file from the system. It is applicable to both
direct and indirect access files. For indirect access files, no
local copy is made when PURGE is executed; if a local copy
exists, it is not destroyed by PURGE.

PURGE,pfn.
pfn Permanent file name of the file to be purged

When designing a tape application, a number of decisions
must be made about the characteristics of the tape. Among
the attributes that must be chosen are the following:
$ Tape drive used to read and write the tape (7-track or
9-track). Data is stored in 6-bit units on 7-track tapes,
and in 8-bit units on 9-track tapes (the remaining bit is
used for parity). On a 9-track tape, four 6-bit
characters in memory are converted to three 8-bit
characters on tape. For 9-track tapes, conversion mode
is according to either ASCII or EBCDIC codes.
e Tape density. Tapes can be written at 200, 556, or 800
bits per inch on a 7-track tape, or 800 or 1600 bits per
inch on a 9-track tape. 9-track tapes can be written at
6250 bits per inch under NOS/BE only.

MAGNETIC TAPE PROCESSING
The user finds it necessary to know about magnetic tape
processing in two different situations:
• When it is necessary to read an already existing tape.
The tape could have been written at the installation in
question, or sent there from somewhere else. In either
case, it is necessary to know the exact attribute
parameters with which the tape was created. If the
tape was written on a computer system not manu
factured by CDC, or was written by a different CDC
system such as one of the 3000 series, special proc
essing is required. This manual does not describe how
to process such tapes; the user is referred to the
appropriate operating system reference manual.
0 After deciding that a tape is the most economical way
to store data between jobs for a given application.
Tapes are cheaper than the equivalent amount of disk
space; however, disks are quicker in terms of real time.
When planning an application using tapes, the user
determines the type of tape processing before running
the first job that writes to the tape. Because all
processing is specified by the original user, tape
attribute parameters can be chosen strictly on the basis
of efficiency or expediency. The discussion that follows
assumes that this is the case.

■^^\

9 Tape format. For a new application, one of the formats
designed for use with CDC systems should be chosen,
because these formats are the most efficient on CDC
systems. Under NOS, I (the system default) and SI
formats are available. Under NOS/BE and SCOPE 2, SI
format (the system default) is available. To read
existing tapes, it might be necessary to specify one of
the S or L tape formats.
9 Label type. A tape can be either labeled or unlabeled.
Labeled tapes are strongly recommended. They provide
greater security against accidental overwriting, and
they are simpler to process because they can be
assigned without operator intervention. Labels are
either ANSI standard or user-defined. ANSI labels are
the system default and are preferred for new
applications.
Tapes are processed by the following steps:

Figure 5-29. PURGE Control Statement Format (NOS)

/Z&*§\

j ^ r ^ \

r^S\

1. A volume serial number (VSN) for the tape must be
determined. At many installations, tapes are blanklabeled before being made available to programmers. In
this case, a serial number is recorded on the tape that
agrees with the serial number on the visual sticker on
the tape. If the tape has not been blank-labeled, the
user selects an arbitrary volume serial number.
2. In the job that creates the tape, a LABEL control
statement (NOS and NOS/BE) or REQUEST control
statement (SCOPE 2) must appear before the control
statement that writes the tape (such as COPY or LGO).
This control statement specifies the attributes that are
to be permanently associated with the tape. At the end
of the job, or when a specific request is made, the tape
is logically unloaded and physically dismounted. The
procedure used to specify how long the tape is to be
retained depends on the installation; however, if the
expiration date field of the label is set, the tape cannot
be overwritten before that date without explicit
operator command. Before the tape can be written, a
write-enabling ring must be mounted; this is explicitly
requested through the LABEL or REQUEST control
statement.

•*c^\

^^?\

3. Any future job using the tape specifies the VSN on a
L A B E L c o n t r o l s t a t e m e n t ( N O S a n d N O S /B E ) o r
REQUEST control statement (SCOPE 2).
The formats of the LABEL control statement under NOS and
NOS/BE, and the REQUEST control statement (for tapes)
under SCOPE 2, are shown in figures 5-30 through 5-32.

/ t fi ^ N

5-10

60499700 A
yrtfi$£\

LABEL,lfn,D=den,CV=conv,PO=p,F=format,VSN=vsn,LB=lab,labwr.
lfn Logical file name of the tape file,
den Tape density; the default is an installation parameter. Implies whether tape is 7-track or 9-track.

LO
HI
HY
HD
PE

200 bpi (7-track)
556 bpi (7-track)
800 bpi (7-track)
800 bpi (9-track)
1600 bpi (9-track)

conv Conversion mode for 9-track tapes; the default is an installation parameter.
AS
EB

ASCII conversion
EBCDIC conversion

Processing option. See the NOS Reference Manual for options other than the following:
R Enforce ring out. If the tape is mounted with the write ring in, job processing is suspended until the
operator remounts the tape correctly. Recommended for tapes to be read.
W Enforce ring in. If the tape is mounted without the write ring in, job processing is suspended until
the operator remounts the tape correctly.
format Tape format:
/KsN

I N OS In te r n a l ( d e fa u l t)
SI NOS/BE internal
S Stranger
L Long stranger
vsn Volume serial number. See the discussion in text.
lab Indicates whether the tape is labeled.
KL NOS labeled (ANSI standard labels; default)
NS Nonstandard labels
KU Unlabeled

/SS\

labwr Indicates whether labels are to be written or read (checked).
R Existing labels are to be checked (default)
W Labels are to be written

Figure 5-30. LABEL Control Statement Format (NOS)

j

^

\

60499700 A

5-11

LABEL, If n,wr,ring,D=d,F=f,N=n,VSN=vsn.

REQUEST,lfn,den,con,VSN=vsn,lab. RING IN

lfn

Logical file name of the tape file.

lfn

Logical file name of the tape file.

wr

Indicates whether the label is'to be written or
read (checked). No default.

den

Tape densityr''the default is an installation
option. Also '-jtermines whether the tape
is 7-track or 9-track.

W Label to be written
R Label to be checked
ring

Indicates the presence or absence of a writeenabling ring; the default is an installation
option.
RING Write-enabling ring required
NOR ING Write-enabling ring prohibited

d

200 bpi (7-track)
556 bpi (7-track)
800 bpi (7-track)
800 bpi (9-track)
1600 bpi (9-track)
6250 bpi (9-track)

Tape format; the default is SI (system internal)
format.
S Stranger tape
L Long stranger tape

n

con

Tape density. Also indicates whether the tape
is 7-track or 9-track.
LO
HI
HY
HD
PE
GE

f

LO
HI
HY
HD
PE

200 bpi (7-track)
556 bpi (7-track)
800 bpi (7-track)
800 bpi (9-track)
1600 !)pi (9-track)

Conversion mode for 9-track tapes; the
default is an installation option.
US ASCII code
EB EBCDIC code

vsn

Volume serial number. See the discussion in
text.

lab

Indicates whether labels are to be written or
read (checked).
N New label to be written
E Existing label to be checked (default)

Figure 5-32. REQUEST Control Statement
Format for Tapes (SCOPE 2)

y^^v

Conversion mode for 9-track tapes; the default ;
is an installation option.
US ASCII code
EB EBCDIC code

vsn

Volume serial number. See the discussion in
text.

Figure 5-31. LABEL Control Statement Format (NOS/BE)

^^\

5-12

60499700 A

0i&<\

LIBRARY FILES

This section describes some efficient techniques when a
group of routines are frequently used together or called
from many other routines. The section describes how a user
library can be created using EDITLIB (NOS/BE), LIBEDT
(SCOPE 2) or LIBGEN (NOS). Maintenance and use of a user
library is also described. In addition, this section describes
how a source language program can be created or main
tained using the UPDATE utility. The COPYL and LIBEDIT
utilities that edit records on a file are also described.
Ta b l e 6 - 1 i n d i c a t e s t h e u t i l i t i e s t h a t o p e r a t e u n d e r
SCOPE 2, NOS/BE, and NOS. EDITLIB is discussed further
in the NOS/BE Reference Manual, LIBGEN, LIBEDIT, and
GTR are discussed in the NOS Reference Manual, LIBEDT is
discussed in the SCOPE 2 Reference Manual, and COPYL is
discussed in the CYBER Common Utilities Reference
Manual.

Alternative 2 eliminates the inconvenience of a physical
deck. Resubmission of the program for processing is
accomplished by a deck containing only control statements
and data. And, if the data is also on a permanent file, the
program can be executed from a terminal that does not
include a card reader.

In this section, the word library implies one of several
different types of file, depending on the context. In a
general sense, the word library refers to a collection of
records. When the word library is qualified by the word user
or program, however, it implies a particular type of file:

Alternative 3 is less useful if changes are to be introduced.
When a main program and the subprograms it calls are
stored as one file, a change in any routine requires a
recompilation of the entire source deck; that recompilation
requires the existence of those routines in source format. In
the absence of anticipated changes, alternative 3 stores the
program in less space than required by a source program.

A user library is a file in a format that can be used by
the loader to satisfy external references or name call
references. It must be created by a library-creating
utility, EDITLIB, LIBEDT, or LIBGEN for the NOS/BE,
SCOPE 2, and NOS operating systems, respectively. All
records on a user library must be binary modules.
A program library is a file in a format created or
maintained by the UPDATE utility. Information in a
program library consists of compressed images of punch
cards in Hollerith format.
This section uses the program GETACC to illustrate user
library and program library construction and maintenance.
Subroutines GENTAB and INTERP are part of a physical
card deck that also contains the main program GETACC. If
GETACC is to be executed only once with one set of data,
its existence as a card deck is reasonably efficient.
Considering execution of GETACC with many sets of data
over a period of time, however, leads to the need for
keeping GETACC and its subroutines in some form other
than punch cards containing source language programs.
Several alternatives can be chosen to provide for use of
program GETACC over an extended period. These include
the following when the program and its subroutines are kept
together:
1. Keeping the main program and its two subroutines as a
source language card deck

Both alternatives 1 and 2 are expensive in terms of machine
time, since a source language program must be compiled
each time it is executed. If the program is compiled before
it is stored, repetitive use of the program requires only
loading and execution time. As long as a program and its
subroutines will not be changed, use of a binary object
module (alternative 3) is efficient.

TABLE 6-1. UTILITY SUPPORT

Utility

Alternative 1 requires the continued existence of a physical
card deck. In this particular example, the GETACC deck is
small, but it is susceptible to the problems of all card decks:
mistreatment that results in card bending or warping, bulky
size, and possible card shuffling.

60499700 A

Applicable Operating
System
NOS

NOS/BE SCOPE 2

UPDATE Coded card file
maintenance
COPYL

Copy of a file
with replace
ment of selected
records

LIBGEN

User library
creation

LIBEDIT Modification of
sequential file
of binary
modules
GTR

2. Storing an image of the deck as a permanent file
3. Storing the compiled program and subroutines as a
permanent file

Function

Extraction of
records from
fi l e

-—

EDITLIB User library
creation and
modification
LIBEDT

User library
creation and
modification

6-1

->^\

When changes to a program are anticipated, other alterna
tives should be considered:
4. Separating the main program from its subprograms, and
separating the subprograms from each other in their
source language and compiled forms
5. Storing all the source language routines in one program
library and storing all the compiled routines in one user
library file
Alternative 4 saves compilation time, because only the
changed routine needs to be recompiled as a result of a
change in that routine. This alternative adds to the
programmer burden, however. When many separate routines
are involved, the programmer must keep track of separate
files or card decks, or keep track of many partitions in one
file for both the source language and binary forms of
routines. The contro l sta te me n ts n e e d e d to e xe cu te
GETACC would have to call for loading of three files by
name, such as:
LOAD, GETACCB.
LOAD, GENT ABB.
LOAD, INTERPB.
EXECUTE.
(See section 7.)
Alternative 5, storing source language programs in UPDATE
format and compiled programs in user library format,
eliminates several problems of the other alternatives. The
card deck can be eliminated once the initial UPDATE
program library is created; for instance, a change to one
routine calls only for recompilation of the changed routine.
All routines on the user library can be referenced by a single
control statement identifying the file on which the library
resides. Assuming GETACC and its subroutines exist on a
user library (MYLIB), GETACC can be executed by:
LIBRARY,MYLIB.
LIBLOAD, MYLIB, GETACC.
EXECUTE,GETACC.
With subroutines on a declared library, the programmer
references only the name of the main program to be
executed. The loader examines that program to determine
what subroutines are required, then searches the library for
those routines without further programmer references.

Because the procedures and control statements needed to
create and maintain a user library differ substantially
between NOS on the one hand and NOS/BE and SCOPE 2 on
the other, they are described separately here.
For FORTRAN programs, a user library can only contain one
main program, unless the main programs are compiled using
the SYSEDIT parameter on the FTN control statement (see
the FORTRAN Extended Reference Manual). This param
eter is necessary because otherwise, multiple references to
the same file name in different main programs cause
duplicate entry points.

NOS/BE AND SCOPE 2 USER LIBRARIES
The utility called to create a library differs between
NOS/BE and SCOPE 2, but the general procedure is the
same, as shown in figure 6-1. Under the NOS/BE operating
system, the utility EDITLIB is called; under the SCOPE 2
operating system, LIBEDT is called. Creating a user library
involves the following steps:
1. The routines to be made a part of the library must exist
in compiled form. They can be on one or more files
stored on tape, cards, or mass storage. They can be
routines in any language and need not all be FORTRAN
routines. The control statement that creates the proper
binary format for each routine is a compiler or
assembler call.
2. Detailed instructions, known as directives, must be
available to EDITLIB or LIBEDT at the time the utility
is called. The file containing the directives is identified
by the I parameter in the EDITLIB or LIBEDT control
statement.
3. The EDITLIB or LIBEDT utility is called to create a
user library.
4. The file on which the user library is created should be a
permanent file. The control statements that make a
file permanent are the REQUEST control statement
before the library is created, and the CATALOG control
statement after the file exists (described in section 5).
If the library is changed in a later run, the EXTEND
control statement (section 5) is then necessary, to make
the changes permanent.

This last alternative is described in detail in this section.
While the small routines GETACC, GENTAB, and INTERP
might be more easily handled in card deck format, the
principles they illustrate are essential for efficient handling
of source programs and frequently used routines.

USER LIBRARIES

Binary
Modules

A user library is a file of binary modules in a special format
constructed by a library-creating utility. In general, a
library file contains, in addition to the modules, a directory
and tables that can be used by the loader to quickly locate
any module. Some of the information in the tables includes
lists of entry points, lists of external references within a
module, and field length information. The specific format
of the library depends on the operating system it is
associated with and, in general, is not of concern to the
user.
A user library is similar to a system library that is
associated with the operating system. It differs from a
system library in that it is created and maintained by an
individual programmer and also must be explicitly refer
enced and attached by any job that uses the library.

(NOS/BE)
EDITLIB
or
LIBEDT
(SCOPE 2)

User
Library

■"^v
Directives

Figure 6-1. NOS/BE and SCOPE 2 User Library Creation
,^S^v

6-2

60499700 A

Directives in General
Directives are the supplementary control information for
E D I T L I B o r L I B E D T. T h e y i n d i c a t e t h e l i b r a r y t o b e
manipulated, the program on a sequential input file (or old
user library) to be made part of the library, and whether a
new library is to be created or an existing library is to be
modified. Directives must exist on a sequential file in the
form of punch cards or punch card images.
The format of a directive is similar to control statement
format. Directives can begin in any card column; they can
contain embedded blanks. Any parameters on the directive
must appear within a set of parentheses, however.
In both EDITLIB and LIBEDT directives, the proglist
parameter can reference a single program or a set of
programs; it can take any of the following formats:
name

Reference

a
single
by name.

program

name/name/. . ./name

Reference several programs
by name in any order.

name,1 +-r I name
lean ItSrs

Reference an inclusive
interval of programs to be
included in the directive
processing by the names of
the first and last programs
in the interval.

name, - name.

Reference an exclusive
interval of programs to be
omitted from the directive
processing by the names of
the first and last programs
in the interval.

0m\

51 +

/$0$\

Reference an inclusive
interval of programs to be
included in the directive
processing by the name of
t h e fi r s t p r o g r a m i n t h e
interval through end-ofpartition or end-of-informa
tion.

Any interval must be specified such that the beginning of
the interval occurs before the end of the interval when
LIBEDT or EDITLIB searches the file in a forward direction.
The search is end-around; that is, the search begins at the
current position of the specified file, continues until end-ofinformation, then resumes at beginning-of-information if
necessary. A search stops when the entire file has been
examined once and the specified programs have not been
found, or when the end of the specified interval occurs. The
programs that indicate the interval range are included in
that interval. Once the beginning of the interval is found,
searching continues only until end-of-information; an
interval cannot wrap around the end of a file.
Directives for EDITLIB and LIBEDT are shown separately
below, because they differ in some respects.

NOS/BE and SCOPE 2 Sample
User Library Creation
The sample job deck shown in figure 6-2 illustrates the
general structure of a job that creates a user library. This
example uses a program with main program GETACC and
subroutines GENTAB and INTERP.
The EDITLIB and LIBEDT control statements shown in
figure 6-2 indicate that the directives are part of the job
deck (I=INPUT). Directives in the example have these
functions:
The LIBRARY directive identifies the library to be
manipulated (MYLIB).
The NEW parameter on the LIBRARY directive
indicates a new library is to be created as opposed to a
modification of an existing library.
All directives between the LIBRARY directive and the
FINISH directive refer to the library named.
The ADD directive specifies that all programs on file
LGO are to be incorporated in the library (because *
appears as the proglist parameter). File LGO was
created by the FTN control statement, which has a
default B=LGO parameter for binary output.
The ENDRUN directive terminates directive execution.

name.

* + name, or * - name.

t"

Reference an exclusive
interval of programs to be
excluded from the directive
processing by the name of
t h e fi r s t p r o g r a m i n t h e
interval through end-ofpartition or end-of-informa
tion.
Reference an interval of
programs to be included (+)
or excluded (-) from the
directive processing with
the interval beginning at the
c u r r e n t fi l e p o s i t i o n a n d
extending through the
named program.
Reference an interval of
programs that consists of all
programs starting at the
p r e s e n t fi l e p o s i t i o n a n d
continuing through end-ofpartition or end-of-informa
tion.

60499700 A

job statement
ACCOUNT control statement (if required)
FTN.
REQUEST,MYLIB,#PF.
EDITLIB,USER,I=INPUT. NOS/BE
LIBEDT,I=INPUT,M=1. SCOPE 2
CATALOG,MYLIB,ID=MINE.

7/8/9
Routines GETACC, GENTAB, INTERP
7/8/9
LIBRARY(MYLIB,NEW)
REWIND(LGO)
ADD(\LGO)
FINISH.
ENDRUN.
6/7/8/9

Figure 6-2. Sample User Library
Creation (NOS/BE, SCOPE 2)

6-3

/*%-

The library name specified in the LIBRARY directive is the
same as the file name specified on the permanent file
control statements. In subsequent loader control statements
(described in section 7), the library is always identified by
the name of the file on which it resides.

The ADD and REPLACE directives identify the names of the
programs and the files on which they reside. The REWIND
directive is not required (since files are searched endaround), but it makes searching more efficient when the
program in question is known to be before the current file
position.

Output from EDITLIB and LIBEDT includes the user library
and a listing that shows operations performed and the
contents of the library. By default, the listing is written to
file OUTPUT. Figure 6-3 shows output from the deck in
figure 6-2 when EDITLIB is called. Information listed
includes:

After library operations are complete, the LISTLIB directive
lists the names of the programs on the library. LISTLIB
output is shown in figure 6-6.

1. A list of the directives as read from the directive file
and as interpreted by EDITLIB. (An error in directive
format might cause a different interpretation.)
2. Status information resulting from execution; in partic
ular, detailed information about each program added to
the library, such as:
a. Contents of the prefix table (a loader table).
b. Octal number of words in the routine excluding the
prefix table. Execution field length is zero for
relocatable programs, because the loader deter
mines length at load time.
c. Access level and field length, which refer to status
bits explained in the NOS/BE Reference Manual.
d. A list of all entry points in the program. Entry
points include the program unit names specified on
the PROGRAM and SUBROUTINE statements.
File names referenced in the PROGRAM statement
are entry points for the main program and external
references in any subprogram (such as GENTAB)
performing input/output on these files.
e. A list of external references within the program.
In program GENTAB, for example, external refer
ences shown refer to FORTRAN library routines
required to execute the READ and WRITE state
ments, as well as to the EOF function called by the
program, and the file names referenced in the
program (unless the program was compiled with the
SYSEDIT parameter).

NOS/BE and SCOPE 2 Sample
User Library Modification
An existing user library can be changed under NOS/BE or
SCOPE 2 using the EDITLIB or LIBEDT utility that originally
created the library (figure 6-4). A program on the library
can be deleted or replaced by another version of the
program, and new programs can be added.
Figure 6-5 shows a sample job deck that deletes program
GENTAB, adds program NEWTAB, and replaces program
GETACC with a new version. In this example, the new
version of GETACC is within the deck and is compiled and
written by default to file LGO. The new routine NEWTAB
was compiled in a previous job and stored as a permanent
file with the name NEWONE.
The existing user library was stored in figure 6-2 as a file
with the permanent file name MYLIB. In the present job, it
is attached with the logical file name MOD. Consequently,
the LIBRARY directive must identify the library as MOD,
not MYUB.

6-4

NOS/BE EDI TLIB Control Statement
and Directives
The EDITLIB control statement (figure 6-7) creates and
maintains a user library that the CYBER loader can use in
satisfying externals and name call references under NOS/BE.

^^^\ ■

In addition to the directives shown in table 6-2, other
directives exist for EDITLIB. They allow field length and
access status bits to be set in the directory of the library.
The ADD and REPLACE directives have additional param
eters for these same items. See the NOS/BE Reference
Manual for information about these other directives. The
directives shown in table 6-2 are sufficient for creating and
modifying a user library using sequential files with type REL
relocatable programs.

•^^\

The user library produced by EDITLIB execution is in random
format; consequently, the library cannot be copied by any of
the copy utilities without losing its integrity. If it is
necessary to copy the library to a tape for backup purposes,
the RANTOSEQ directive must be used. To restore the
library to mass storage in a format that can be used by the
loader, the SEQTORAN directive must be used.

<^^§\

SCOPE 2 LIBEDT Control Statement
and Directives
The LIBEDT control statement (figure 6-8) creates and
maintains a user library that the SCOPE 2 loader can use in
satisfying externals and name call references under
SCOPE 2.
Directives for LIBEDT are shown in table 6-3. Other
directives exist to allow a library to be copied to a
sequential file, rearrange a library, or otherwise update the
library and control other types of records in the file. See
the SCOPE 2 Reference Manual for information about these
other directives. Those directives shown in table 6-3 are
sufficient for creating and modifying a library using a
sequential file of type REL programs.
The column of table 6-3 entitled Required Position refers to
the location a directive must occupy in respect to a run. A
run is defined as a group of operations with a particular
library. (More than one library can be manipulated through
a single call to LIBEDT even though only one is shown in the
examples in this section.) A run begins with a LIBRARY
directive and ends with a FINISH directive. Thus, table 6-3
indicates that the ADD directive must appear between
LIBRARY and FINISH, but that the LISTLIB directive cannot
appear between LIBRARY and FINISH directives, and that it
does not matter whether ERROR appears between them or
not.
Under SCOPE 2, a library has a format recognizable by
SCOPE 2 Record Manager as FO=LB. A library file contains
a number of partitions, the first being a directory used by
the loader.

60499700 A

EOITLIB

VERSION

2.3

D AT E

07/26/77

TINE

11 . 3 6 . 3 ? .

••••»• LI9RARY(HYLI9,NEm
1 LIBRARY(FYLIB,NEM>
»»»•*• REWIND (LGO)
2 REWINO(LGO)
••*•»• AD0<»»LGOI
3 A0D(*,LGO>
*•••»•

FINISH.
»♦ FINISH.

•••••» ENDRUN*
9 ENORUN.

EDITLIB

VERSION

T I H E 11 . 3 6 . 3 S .

O AT E 0 7 / 2 6 / 7 7

2.3

PROCESSING DIRECTIVE NUHBER 1
PROCESSING OIRE3TIVE NUMBER 2
PROCESSING OIRECTIVE NUH9ER 3
FOLLCHlNG PROGRAH AOOEO ©
PRCGR*H NAHE
GETACC
SYSTEH NAHE NOS/BE 1.207/26/77
11 . 2 9 . 3 1 P R O C E S S O R N A M E
DEPENDENCIES HARDWARE I
INSTRUCTION 66 6X
THIS
A BRELOCATABLE
I P
R E F ITS
X TA
L E I N F O R M AT IPROGRAH.
ON
Q))-BINARY LENGTH = 210 AND EXECUTION FIELD LENGTH :
/rvlACCFSS LEVEL IS 0
^ I F I E L O L E N G T H H AY N O T B E I N C R E A S E O .
© / E(N T R Y P O I N G
T SE T A C C
EXTERNAL REFERENCES
EOF
OUTFI.

INPJTr
G E N TA B
O I N T R Y.

(EXTERNAL REFERENCES
EOF
(
TA P E * ?

INP*I.

t*,6

TAP£«f =

INPFI.
S T O P.

INTERP

OUTCI.

FOLLOWING PROGRAH AOOEO
PREFIX TABLE INFORMATION
PRCGR4H NAHE
INTERP
SYSTEH NAHE NOS/BE 1.207/26/77 11 . 2 9 . 3 1 P R O C E S S O R N A H E
DEPENDENCIES HAROWA3E I
INSTRUCTION 66 6X
THIS IS A RELOCATABLE PROGRAH.
9INARV LENGTH = 136 ANO EXECUTION FIELT LENGTH
ACCES? LEVEL IS 0
FIFLO LENGTH ««AY NOT BE INCREASEO.
ENTRY POINTS
INTERP
EXTERNAL REFERENCES
OUTFI.
OUf»UT=

452

( O C TA L ) .

OUTPUT!

FOLLCMIHG PROGRAH AOOEO
P R E F I X TA B L E I N F O R H AT I O N
PRCGRAH NAME
GENTAB
SYSTEM NAHE NOS/BE 1.207/26/7*
11 . 2 9 . 3 1 P R O C E S S O R N A M E
DEPENDENCIES HARDWARE I
INSTRUCTION 66 6X
THIS TS A RELOCATABLE PROGPA*.
BINARY LENGTH = 260 ANO EXECUTION FIELO LENGTH
ACCESS LEVEL IS 0
FIELO LENGTH HAY NOT BE INCPEASED.
ENTRY POINTS
GENTAB
©<

FTN

FTN

OUTCI.

If. 6

452

(OCTALI.

OUTFI.

FTN

OUTPUT:



The DECK directive specifies a deck name for the cards
that follow. UPDATE assigns a sequence number within
the deck for each card.
The cards of source language programs become text in
the program library.

"^V

Output from UPDATE includes the program library with
three decks and a listing that shows the results of execution.
The program library is saved as a permanent file with the
name PL2.
The call to the FORTRAN compiler is made in figure 6-22 in
order to provide a listing of the card identifiers assigned by
UPDATE. These identifiers must be known to the program
mer before cards can be added to or deleted from a program
library through a correction run. The listing can be made in
the same job that creates the library or in any subsequent
job. Part of the listing from the compiler call is shown in
figure 6-23. The text cards added to the program library
are also listed as part of the UPDATE output.
job statement
ACCOUNT control statement
REQUEST,NEWPL,*PF. NOS/BE, SCOPE 2
UPDATE,l=INPUT,N=NEWPL,C=COMPILE.
CATALOG,NEWPL,PL2,ID=MINE. NOS/BE, SCOPE 2
SAVE,NEWPL=PL2. NOS
FTN,I=COMPILE,R=0,TS. PW=72.
7/8/9
•DECK DGETACC
GETACC source program
•DECK DGENTAB
GENTAB source program
•DECK DINTERP
INTERP source program
6/7/8/9

,^^v

Art^vS.

A ^ \ „

Figure 6-22. Sample Program Library Creation

60499700 A

•^^\

CORRECTION RUN
A correction run is a run that uses an existing program
library rather than one that creates a program library.
During a correction run, new cards can be added and existing
cards can be deleted. Changes can be .made on the basis of
individual cards, a range of cards, or all the cards of a
particular correction set identifier. These changes become
part of a new program library. Any run that simply extracts
a deck from the existing program library and copies it to the
compile file, such as shown in figure 6-24, is also a
correction run.
Any correction run that makes a change to a program library
must begin with an IDENT directive that gives a name to all
the following changes. For the rest of the life of the
program library, any card that is added to the library is
identified by a card identifier that has the format:
ident.seqnum
where ident is the correction set identifier, and seqnum is a
number assigned by UPDATE.

Sample Correction Runs
The sample job decks in figures 6-25 and 6-26 illustrate
correction runs. The examples differ in that the first deck
uses an existing program library, but does not update the
entire program library as the second example does. Both
examples presume the existence of the program library
created in figure 6-22 and cataloged as a permanent file
with the name PL2.
/$p^>

The example in figure 6-25 illustrates a procedure useful
when changes are to be made to an existing routine. The
input stream contains directives that add a new card to the
deck DGETACC. In this particular example, the card added
is merely a comment for illustration purposes, but could
have easily been many cards that substantially change the

Figure 6-24. Using a Routine on a Program Library

Card Identifier
P R O G R A M G E TA C C ( I N P U T. TA P f 4 « I M P U T » O U T P U T )
OUFMSIHN
TIME(100)»
iT^IKU

c

N ■ C
NMAX » IOC

c
r

. . . G £ N TA « G P W E P 4 T E S T H t A C C E L E R AT I O N TA R L E
C A L L r » e N T J 5 « * < N K A X » T I * P # ATA < U N T I ^ S . I F R )
I c ( I C P . N ' F. 0 ) G O T O 9 0 0

r

c. . . . O F A 9

A C A O C C O N TA I N I N G A T T * f VA L U E

r

r

r.

c

13« PF4 0 (4t*| T
IF CeOF(4> .NE. 0) GO TO QCC
. . . T N T C R P I N T E R P O L AT E S F O R A C C E L F PAT I P *
C A L L I N T F B P ( N T I M E S * T H E * ATA « , T » A C C » I E R )
IF CTE9 .NE. 01 GH TO 100

0G«=TACC
OGFTACC
0 5 C TA C C
H G F TA C C
Q G F TA C C
OGFTACC
0 5 6 TA C C
OGFTACC
h G F TA C C
n G E TA C C
OGFTACC
0GFT6CC
DGETACC
OGFTACC
OGFTACC
O G f TA C C
OGFTACC
OGFTACC
O G F TA C C
OGFTACC
Correction
Set
I d e n t i fi e r

fl
IC
11
12
13
14
15
16
17
19
19
20
21
Sequence
Number

Figure 6-23. Listing of Card Identifiers
/(jjjpSV

60499700 A

6-15

program GETACC. In order to be sure that the new cards
did not introduce an error into a successfully running
routine, the entire routine is then extracted from the
program library and compiled. Once the program has
executed successfully, UPDATE should be run once more,
this time writing a new program library and making it a
permanent file.
A new program library can be written and preserved as a
permanent file each time UPDATE executes. If errors are
subsequently found, another correction run is needed to
change the newly inserted cards or to delete erroneous
cards. Each subsequent correction run must specify a unique
correction set identifier, and as a result, one fix might
ultimately appear in the program library with several
different correction sets as card identifiers. Consequently,
the technique of trial runs is often useful.
The UPDATE control statement of figure 6-25 contains only
a Q parameter, which instructs UPDATE to write only decks
identified on COMPILE directives to the compile file, in the
original format. When this parameter is used, no new
program library is generated when the N parameter is
omitted.
Directives in figure 6-25 have the following functions:
1. The IDENT directive provides a correction set identifier
name. All subsequent cards in the input stream, until a
PURGE directive or an IDENT directive appears, are
part of the set and are sequenced by UPDATE within
that set.
job statement
ACCOUNT control statement
NOS/BE, SCOPE 2
ATTACH,OLDPL,PL2,ID=MINE.
GET,OLDPL=PL2. NOS
UPDATE,Q.
FTM,B=0,I=COMPI LE.TS.
7/8/9
•IDENT TRYIT
•INSERT DGETACC.18
CCC. THIS IS NEW, INSERTED BY TRYIT .CCC
•DELETE DGETACC7,DGETACC9
•COMPILE DGETACC

6/7/8/9
Figure 6-25. Sample Use of Program Library

job statement
ACCOUNT control statement
ATTACH,OLDPL,PL2,ID=MINE. NOS/BE, SCOPE 2
GET,OLDPL=PL2. NOS
REQUEST,PL3,*PF. NOS/BE, SCOPE 2
UPDATE,F,N=PL3,C=0.
CATALOG,PL3,ID=MINE. NOS/BE, SCOPE 2
S AV E , P L 3 . N O S
PURGE,OLDPL.

7/8/9
•IDENT TRYIT
•INSERT DGETACC.18
CCC THIS IS NEW . . .
•DELETE DGETACC7,DGETACC9

6/7/8/9
Figure 6-26. Sample Correction Run Creating
a New Program Library

6-16

2. The INSERT directive identifies the location at which
following text cards are to be inserted; namely, after
the card identified as DGETACC.18.
3. The card that begins with C is not recognized by
UPDATE as one of its directives. Any card that is not
recognized as an UPDATE directive is treated as a text
card to be inserted.

>**SS\

4. The DELETE directive causes three comment cards to
be removed from the deck. When two card identifiers
are separated by a comma as shown in the figure, a
range of cards is indicated. Both cards specified, and
all those between, are deleted.
5. The COMPILE directive ensures that deck DGETACC is
written to the compile file and the new program library.
The FORTRAN compiler call tests whether the corrected
routine compiles correctly. Because execution is not
planned, B=0 is specified to suppress executable binary code.
The TS parameter calls for quick compilation with little
o p t i m i z a t i o n . T h e s o u r c e f o r c o m p i l a t i o n i s t h e fi l e
COMPILE, the default file name when a C parameter is not
specified on the UPDATE call. The compile file contains
only deck DGETACC (the main program GETACC), because
Q mode is specified on the UPDATE control statement. No
decks appear on the compile file in the absence of COMPILE
directives under Q mode.
The source listing produced by the FORTRAN compiler is
shown, in part, in figure 6-27. Notice that the deleted cards
do not appear on the compile file, although they still exist
on the program library and can be reactivated by a YANK
directive that references the correction set identifier. The
new card added appears with a card identifier corresponding
to the correction set identifier and sequence number in that
set.
In the second correction run example (figure 6-26), the
changes made to the existing program library are incorpo
rated into a new program library.
The UPDATE control statement, in the absence of a P
parameter, assumes the existing program library is on the
file OLDPL. The new program library is to be written to the
file PL3. Because the changes to the program library were
checked out in the previous example, there is no need for
the compile file and it is suppressed by the C=0 parameter.
The new program library, PL3, is made a permanent file
before the old program library is purged. If the CATALOG
or SAVE control statement fails for any reason, the old
program library is preserved.
The UPDATE mode is specified as F. As a result, all decks
on the old program library are written to the new program
library. If the Q mode was specified, only the deck
DGETACC would have been written to the new library.

^^\

<^3\

The PURGE control statement eliminates the previous
version of the program library.

UPDATE Listing
Figure 6-28 shows the output listing from figure 6-25.
Information printed includes the following:
1. Identification of the run as a creation run (CREATION
RUN) or correction run (OLDPL).
2. A copy of the input stream.

60499700 A

T

^

\

3. The full text of cards modified, with the card identi
fiers (3a) and an indication whether the card was
inserted (I), deleted (D), or added as a result of a YANK
directive (A).

4. A list of correction set identifiers. Notice that all deck
names are also considered to be correction set names.
The order of identifiers is significant when the YANK
or PURGE directives specify a range of identifiers,
because the range specified must be in the same
chronological order in which the identifiers were
inserted into the program library.

5. A list of decks already on the old program library, plus
any decks added in the current run. All program
libraries contain a deck YANK$$$ that is used inter
nally by UPDATE to track YANK operations.
6. A list of decks written to the new program library. The
UPDATE mode and COMPILE directives control the
decks written to the new program library.
7 . A l i s t o f d e c k s w r i t t e n t o t h e c o m p i l e fi l e . T h e
UPDATE mode and COMPILE directives control the
decks written to the new program library. The decks on
t h e c o m p i l e fi l e c a n b e c o m p i l e d b y F O RT R A N
Extended.

PROGRAM GETACC (INPUT, TAPE4=INPUT, OUTPUT)
D I M E N S I 3 N T I M E ( I O O ) , ATA B ( I Q O )

0&fe\

DGETACC
DGETACC
OGETACC
DGETACC

t

H = 0
NMAX = 10 0
3ALL GENTAB (NMAX, TIME, ATAB, NTIMES, IER)
I F < I E R . N E . 0 ) G O TO 9 0 0
t J

C....REA0 A CARO CONTAINING A TIME VALUE
100 READ (4,») T
I F ( F 0 F C 4 ) . N E . 0 > G O TO 9 0 0
C
3....INTERP INTERPOLATES FOR ACCELERATION
C C C . T H I S I S N E W, I N S E R T E D B Y T R Y I T . C C C
C
C A L L I N T E R P ( N T I M E S , T I M E , ATA B , T, A C C , I E R )
IF (IER .NE. 0) GO TO 100
W R I T E 1 5 , T, A C C

CARDS DELETED {iS£
OGETACC
DGETACC
OGETACC
DGETACC
OGETACC
DGETACC
DGETACC
DGETACC
CARD ADDED + TRYIT
DGETACC
DGETACC
DGETACC
OGETACC

10
11
12
13
14
15
16
17
18
19
20
21
22

Figure 6-27. Listing from Corrected Deck

0m\

60499700 A

6-17

o o o

/^a$\
0.

zn
tn

M
X

o o o

U U U
< < < l l-l-l-H

ui uj ui v
o to u> or

a

OO O H-

UJ
4
UJ
DC
U

UJ

z
o

/ ^ ^ k

u.
ec
Ul
tn

ec

z

4
Of
OD

z

oc
Ul
o
ec
o

4

o
o
ar
a

©
UJ

o

x
UJ
z

_ l

o
z
o
ac

U l
-J
00
4
f -

e

ae
o

*-

M

»4

oc

Ck!
UJ
-1
UJ

Oi

o
u

O

uj tr

VZ
U l

t f O
U I O

o

Ul

*r

\~

tn «t
z >-

M

tn

M UJ

Ul

O

• O

\

enx «

xH Ul N.
• Z • (>

o
o
u
o 

a

..
.

o
oo
oo
oo
o
UJ UJ U>

T~

Ul

is is id tn
O O O O

z
o
UJ

u
z

UJ

a
zn
o
o
c

ui
oc
o
tn

x
o

u.

tn
cn
iv
o

U

or
UJ
o
oc

trt

=>
_i
a

OC
I H

o

c

ztn

3

©

•-s
l-«
_J

tn
z

4 M 4 t-

Xu 11 ft Ut ex
OC OI o
»1UJ
1- Ul -J
Ktt
»hH
Z Ul O UJ CL
Ul IO • -J X
O Z U U I O
M M • O O
* » O * *

u
z

M

O
Ui
h-

4

r~ •

X

Ul

O
T
r^\

Logical file name of the file to become part
of the local library set.
Specifies the type of loader error for which a
job is to be aborted. The default is an installa
tion option. Must be one of the following:

LIBRARYtlfn-,, . . . ,lfnn)
lfn

Logical file name of a library-format file to
become part of the global library set. Maxi
mum number is 2 user and 2 system libraries,
1 user and 13 system libraries, or 0 user and
24 system libraries. If LIBRARY is specified
with no parameters, the global library set is
cleared.

Figure 7-7. LIBRARY Control Statement Format

7-4

ALL

Job is aborted for catastrophic, fatal,
and nonfatal errors

FATAL Job is aborted for catastrophic and
fatal errors
NONE Job is aborted only for catastrophic
errors

Figure 7-8. LDSET Control Statement Format

60499700 A

/WT^V

Within each library set, libraries are searched in the order
that they were defined.
If the loading of programs from libraries produces new
external references that must be satisfied from the library
set, these references are satisfied the next time the
appropriate entry point is encountered. If the end of all the
library sets is encountered, and unsatisfied references
remain, the search is begun again from the beginning. This
circular search continues until either all references have
been satisfied, or until the entire library set has been
searched once with no new satisfaction of references.

Fl ELD LENGTH CONTROL
The amount of memory needed to execute a job step is
normally calculated and requested by the loader. However,
the user can control this procedure by using the CM
parameter on the job statement, as well as the REDUCE and
RFL control statements.

0$*s

The format of the REDUCE control statement is shown in
figure 7-9; the format of the RFL control statement is
shown in figure 7-10. The effect of the CM parameter
depends on the operating system:
^ Under NOS/BE, the CM parameter establishes a maxi
mum field length available to the job, and assigns that
field length to the job initially. This parameter should
not in general be used, since it inhibits dynamic
adjustment of field length.
* Under SCOPE 2, the CM parameter can only be
overridden by a request from within a program; this can
occur during a FORTRAN compilation. Otherwise, its
action is the same as under NOS/BE.
0 Under NOS, the CM parameter can be overridden by the
MFL control statement (see the Loader Reference
Manual). Otherwise, it establishes a maximum value for
field length.
To inhibit reduce mode
REDUCE(-)

NOS

REDUCE(OFF)

NOS/BE INTERCOM

(CM parameter or RFL under NOS/BE batch,
SCOPE 2)

Under NOS/BE and SCOPE 2, all jobs begin in reduce mode
in the absence of the CM parameter. Under NOS, all jobs
begin in reduce mode regardless of the CM parameter. In
reduce mode, the loader sets the field length for every job
step before execution begins; therefore, only the amount of
memory actually needed is allocated. If a REDUCE(OFF)
control statement (NOS/BE INTERCOM), a REDUCE(-)
control statement (NOS), or an RFL control statement
(NOS/BE batch and SCOPE 2) is encountered, reduce mode is
turned off. In the case of an RFL control statement, the
field length specified becomes the execution field length
until another RFL control statement is encountered or
reduce mode is reestablished by a REDUCE control state
ment (NOS/BE batch, NOS, and SCOPE 2) or a REDUCE(ON)
control statement (NOS/BE INTERCOM). Under NOS,
REDUCE(-) must be preceded or followed by an RFL control
statement because otherwise the field length is reduced to

FORTRAN users are not usually required to manage their
own field length because the compiler tries to assure that
adequate field length is always available; however, under
some circumstances, compilation speed can be improved by
providing an RFL control statement prior to compilation.
This is particularly true when compiling with the TS option
or the OPT=2 option. Although both these compilation
modes control their own field length by requesting more
central memory when necessary, providing an initial value
greater than the default can reduce compilation time.

An RFL control statement does not improve execution time
of a compiled program, because execution field length is
calculated by the loader. Reduce mode should be reestab
lished before execution begins.

BASIC LOAD EXAMPLES
The control statements shown in figure 7-11 illustrate the
use of global and local library sets. The example applies to
NOS and NOS/BE; under SCOPE 2, there is no default
system library.

When the file LGOl is loaded, the library set is empty
except for the default system library, SYSLIB; therefore,
SYSLIB is the only library searched to satisfy externals for
LGOl.

To restore reduce mode
REDUCE.

NOS/BE batch, NOS, and
SCOPE 2

REDUCE(ON)

NOS/BE INTERCOM

LGOl.
LIBRARY(ALGOL)
Figure 7-9. REDUCE Control Statement Format

LDSET(LIB=USER/AX)
LG02.
LG03.

RFL(n)
Number of words of central memory field
length, in octal.

Figure 7-10. RFL Control Statement Format

60499700 A

LIBRARY.
LG04.

Figure 7-11. Basic Load

7-5

The LIBRARY(ALGOL) control statement specifies that the
global library set is to consist of ALGOL. The
LDSET(LIB=USER/AX) loader control statement specifies
that the current load sequence is to use local libraries
named USER and AX; thus, when the file LG02 is loaded,
the libraries ALGOL, USER, AX, and SYSLIB are searched
(in that order) to satisfy externals.
When LG03 is loaded, only ALGOL and SYSLIB are searched
to satisfy externals, because USER and AX were local to the
load sequence completed by LG02. The next LIBRARY
statement clears the global library set, so that the only
library searched to satisfy externals for LG04 is SYSLIB.
As another example, consider compilation of a program with
an OPT=2 parameter on the compiler call. Assume the
following message was listed in the output listing:
63000B CM USED
After the user made some minor modifications, the program
was recompiled and executed with the following control
statements:
RFL,63000.
FTN,OPT=2.
REDUCE.
LGO.
The RFL control statement eliminates the necessity for the
compiler to request additional field length. The REDUCE
control statement restores reduce mode so that no more
field length than necessary is used for execution of the
program.

SEGMENT LOADING
Segmentation allows the user to decrease the execution time
field length requirements of a program by dividing it into
smaller portions called segments, which are loaded and
unloaded as needed, rather than all being in memory at the
same time, as for a basic load. Segments (each of which
contains one or more program units) are grouped into
structures called trees, and the trees are grouped into one or
more levels. One particular segment, called the root
segment, stays in memory at all times.
Segments are built whenever a SEGLOAD control statement
is encountered. The building takes place according to the
segment directives provided by the user. The segmented
program is saved on a file and can be executed in the same
load sequence, or at a later time.
Execution of a segmented program always begins with the
root segment. A segmented FORTRAN program contains
one and only one main program, which must be in the root
segment. Whenever a subprogram is referenced, the
segment containing the subprogram is automatically loaded.
This segment might overwrite a previously loaded segment.
Compared to overlays, which is the other method of dividing
large programs into smaller units, segmentation provides
several advantages. The structures that can be created are
more varied; whereas overlays allow only one tree with at
most three levels of branching, segments can be grouped
into any number of independent levels, each containing any
number of trees. Furthermore, segments can be built from
previously compiled programs; with overlays, the structure
must be specified at the time the program is compiled.
Finally, loading of segments is automatic and takes place
whenever a program unit in a segment is referenced;
overlays must be loaded explicitly.

Segments have some disadvantages, however, especially for
the FORTRAN user. For one thing, segmented programs
cannot be put into libraries. Also, the treatment of labeled
common blocks requires the FORTRAN user to explicitly
specify the blocks used by the FORTRAN Common Library
(as explained below). However, neither of these disadvan
tages should be considered as a conclusive objection to the
use of segmentation.
One additional disadvantage applies both to segments and
overlays: the increase in execution time resulting from
moving programs into and out of memory during execution.
Whether this outweighs the savings in field length provided
by these two methods can only be decided based on a
specific application.

SEGMENTED PROGRAM STRUCTURE
A segmented program consists of one or more levels, each of
which contains one or more trees.
A tree consists of a root segment and zero or more branch
segments, each of which in turn can have zero or more
branches of its own. An example of a tree is shown in
figure 7-12; A is the root segment and B and C are its
branches. C in turn has one branch, D.
y^^v

Trees can be grouped into levels. The lowest level can only
contain one tree; the root segment of this tree is the root
segment of the whole program. An example of a segmented
program containing three levels is shown in figure 7-13. The
first level contains one tree, the second level contains two
trees (one of these trees contains only one segment), and the
third level contains one tree. Segment A is the root
segment of the whole structure.
If segment y is in the same tree as segment x and can be
reached from x by branching upward, x is called the ancestor
of y. For example, in figure 7-13, segments A and C are
ancestors of segment D. Neither B nor C is an ancestor of
the other.
The structure of a segmented program determines which
segments can be in memory at the same time. Such
segments are called compatible, and fall into two
categories:
.J"^^V

# Segments in different levels, which are always com
patible
0 Segments in the same level, which are compatible only
if they are in the same tree, and only if one of the
segments is an ancestor of the other segment. In
figure 7-13, C is compatible with D but not with B; E
and F are not compatible.
Any two segments have a nearest common ancestor,
determined as follows:
0 If the segments are in different trees, the root segment
of the whole structure is their nearest common
ancestor.

^v
Figure 7-12. Sample Tree Structure

>^\
7-6

60499700 A

/pss

0 If one of the segments is the ancestor of the other
segment in the same tree, it is the nearest common
ancestor of the two segments.

0O®\

0 If the segments are in the same tree, but neither is the
ancestor of the other, then the nearest common
ancestor is the highest segment from which both
segments can be reached by branching. Another way to
put this is that the nearest common ancestor is the root
of the smallest subtree containing both segments.
This process is repeated for more than two segments. For
example, in figure 7-13, segment A is the nearest common
ancestor of segments H and G, segment C is the nearest
common ancestor of segments C and D (note that a segment
can be its own ancestor), and segment H is the nearest
common ancestor of segments I and J.

BUI LDI NG A SEGMENTED PROGRAM
When a SEGLOAD control statement is encountered, the
loader creates a segmented program. All the control
statements in the same load sequence as the SEGLOAD
control statement are used in the segmentation process.
However, these statements take on a different meaning than
in a basic load.

0^\

Instead of causing loading, LOAD, SLOAD, and the name
call statement specify files (or programs on files, in the case
of SLOAD) from which relocatable program units and
common blocks are to be read during the creation of
segments. EXECUTE and the name call statement signal
the end of the load sequence and the execution of the
segmented program, but execution always begins at the main
entry point in the root segment. This entry point can come
from any file, not just the file specified in the name call
statement. NOGO terminates the load sequence and causes
the segmented program to be written to the file specified in
the SEGLOAD control statement; the program is not
executed. No file name can be specified in the NOGO
control statement in a segmented load.
Level 2

Level 1
/flSs.

Level 0

Figure 7-13. Segmented Program with Three Levels

60499700 A

For example, a load sequence consists of the following
control statements:
LOAD(ABC)
SLOAD(DEF,GHI,JKL,MNO)
SEGLOAD, B=PQR.
LDSET(LIB=MYLIB)
LGO.
All program units from the files ABC and LGO are included
in the segmented program, and the program units GHI, JKL,
and MNO from the file DEF are also included. External
references are satisifed from these files, from the global
library set, and from the local library MYLIB. After the
segmented program is built, the binaries are written to the
file PQR, the root segment is loaded, and execution begins
at the main entry point in the root segment.
To build a segmented program, the loader collects all the
information in the control statements in the load sequence
and in the segment directives, and then builds the program
based on that information. When building segments, the
loader reads program units from the load files and divides
them into fixed programs and movable programs. Fixed
programs are those explicitly assigned to segments by the
user through TREE and INCLUDE directives. Movable
programs are those encountered by the loader while either
loading other programs or satisfying external references.
External references are satisfied from load files and from
the global and local library sets. The loader then assigns
each movable program to the nearest common ancestor of
all the segments that reference the program.
When a program unit is present on a load file (unless the file
was specified by SLOAD), but is not referenced by any
segment, the loader includes it in the root segment.
Because such a program is not referenced in any standard
way by the FORTRAN program units (or else it would be
loaded to satisfy an external reference), its inclusion in the
segmented program is of no value, and is wasteful of field
length; therefore, the user should ensure that the load files
contain only program units that are actually used in the
segmented program.
The treatment of common blocks differs from that of
program units. Blank common is always loaded after the
highest address in the highest level of segmentation. The
location of a labeled common block depends on whether or
not the block is specified in a GLOBAL directive. If the
block is declared global, a single copy of the block is kept in
the specified segment. If the block is not declared global, a
separate copy is made for each segment that references the
block. In this case, data placed in the block by a program
unit in one segment cannot be accessed by a program unit in
a d i ff e r e n t s e g m e n t . T h e r e f o r e , a n y b l o c k u s e d f o r
communication between program units in different segments
should be declared global by the user. A global block can
only be preset from the segment containing it.
After all program units and common blocks have been
assigned to segments, the loader converts addresses into
absolute addresses. The space allocated for a non-global
common block is the same for each copy, and is the greatest
length declared for it by any program unit. The space
allocated for a level is the length of the longest tree in that
level. Blank common is allocated after all segments.
As the segmented program is built, it is written to a file
(either the file specified on the SEGLOAD control state
ment, or the file ABS if none was specified). If the
completion statement of the load sequence is EXECUTE or a
name call statement, the program is then executed,
beginning at the main entry point in the root segment. If
the completion statement is NOGO, execution does not take

7-7

place. In either case, the file is normally saved by the user
and executed again at a later time (since segmentation is
unlikely to be used for a program executed only once).

SEGMENT DI RECTI VES
The segment directives are found on the file indicated by
the I parameter on the SEGLOAD control statement
(figure 7-14). SEGLOAD directives have three fields: label,
verb, and specification. The label field begins in column 1
and ends with one or more blanks. The verb field begins
after the label field, and ends with one or more blanks. The
specification field begins after the verb field. The contents
of each of these fields depend on the directive.
The directives can be in any order except for LEVEL, TREE,
and END. END must be the last directive. If the
segmentation structure is to contain more than one level,
LEVEL directives are used to separate the levels. Between
each pair of LEVEL directives, TREE directives define the
trees that constitute the level. Within a particular level,
TREE directives can be in any order.
The format of the TREE directive is shown in figure 7-15.
The label field contains the tree name, which is not needed
if it is not referenced elsewhere in the directives. The
specification field contains an expression that defines the
root of the tree and its branching structure. This expression
consists of tree segment names, separated by the characters
- , ( and ). The character - indicates that the segment
or tree name to the left of the minus sign is the parent of
the expression to the right of the minus sign. This
expression is either another segment or tree name or a
subexpression enclosed in parentheses. The character ,
indicates that the segments, tree names, or subexpressions
separated by the comma are on the same level, branching
from a common parent. Examples of tree expressions are
shown in figure 7-16.

The INCLUDE directive (figure 7-17) forces inclusion of
object programs into a specific segment, thus overriding the
rules that place an object program into the nearest common
ancestor of all referencing segments. Using INCLUDE,
duplicate copies of a program unit can be placed in more
than one segment.
The INCLUDE directive can sometimes be used to decrease
the maximum field length required by a segmented program.
For example, in figure 7-13, suppose that both segments B
and E reference the subroutine SUBl. This subroutine would
normally be included in the root segment A. Because A is
always present in memory, this subroutine is always loaded,
even when neither B nor E is loaded. If the length of
segments C and D is greater than the length of B, the total
space allocated for level 0 is greater than the space actually
1. The expression A-(B,C) can be diagrammed as
follows:

V
2. The expression A-((B-(C,D)),E) can be dia
grammed as follows:

When one of the names in an expression is a
tree name, the entire tree is substituted in the
generated structure. For example, if the
following two TREE directives appear:

When writing a tree expression, it is always necessary to
ensure that the tree specified is a valid tree. For example,
the following pair of TREE directives does not generate a
valid tree:

F TREE B-(C,D)
T R E E A - ( F, E )
the resulting tree would appear as follows:

A TREE B-(C,D)

X/

TREE A-(E,F)
SEGLOADfMfn^BHfnj)
lfn .j Logical file name of file containing segment
directives. The default is INPUT.

Figure 7-16. TREE Directive Examples

Ifn2 Logical file name of the file to which a seg
mented program is to be written. The default
is ABS.

Figure 7-14. SEGLOAD Control Statement Format
Label

Verb

Specification

tname

TREE

exp

Label

Verb

Specification

segname

INCLUDE

program-],...,
programn

segname

Name of the segment in which program units
are to be included. If omitted, all program
units named in the directive are included in
the root segment.

program

Name of the program unit to be included
in the segment.

tname Optional tree name
exp

Tree expression. The format is described in
the text.
Figure 7-15. TREE Directive Format

7-8

Figure 7-17. INCLUDE Directive Format

60499700 A

/^%.

/*^\

needed at any time. By forcing copies of SUB1 into B and E,
the length of level 0 can be reduced. The directives to do
this are shown in figure 7-18.
The fixed programs contained in a segment are defined by
the TREE and INCLUDE directives. When a segment name
appears in a TREE directive, the loader searches for a
program unit with that name and includes it in the segment
with the same name. However, the INCLUDE directive
overrides the TREE directive. If a segment name appears in
an INCLUDE directive, the programs specified in the
INCLUDE directive are forced into the segment; so is the
program with the same name as the segment.
The primary value of INCLUDE for the FORTRAN user is to
h e l p a v o i d C A L L - R E T U R N c o n fl i c t s , s u c h a s t h o s e
described below. Care must be taken in using INCLUDE
that extra copies of common blocks are not created, unless
each such block is referenced only by program units in the
segment it is forced into; otherwise, each segment will use
the copy of the block contained in that segment, and
information stored in one segment will not be available to
other segments.
The LEVEL directive (figure 7-19) delimits levels within the
directive sequence. As each LEVEL directive is
encountered, a new level is begun. Thus, the trees included
in any given level are those defined by TREE directives
occurring between the LEVEL directives.
The GLOBAL directive (figure 7-20) ensures that only one
copy of a labeled common block is created. If a segment

0ffiS

Label

Verb

Specification

B

INCLUDE

SUB1

E

INCLUDE

SUB1

name is present in the label field, the block is kept in that
segment; otherwise, the block is kept in the root segment of
the whole structure. When a block is kept in a segment
other than the root, it is overwritten whenever an incom
patible segment is loaded unless the -SAVE parameter is
used. -SAVE specifies that the contents of the block are to
be written to a file whenever the segment is overwritten,
and restored when the segment is reloaded. -SAVE is
unnecessary for a block kept in the root segment. ECS
common blocks can be specified by the GLOBAL directive,
but because these blocks are never overwritten, -SAVE is
also unnecessary for them.
Global common blocks can be freely referenced or defined
by the owning segment, or by any segment that is known to
be in memory at the same time as the owning segment. In
particular, this includes all descendants of the owning
segment, because if a descendant is loaded, the ancestor is
automatically loaded. Other compatible segments can
reference the block whenever the user is sure that the
owning segment is already loaded, but such references do
not force loading of the owning segment, and no check is
made by the loader. If the owning segment is not loaded,
the results of a reference to the block are not valid.
The common blocks used by Record Manager and the
FORTRAN Common Library are treated the same by the
segment loader as user-declared common blocks; that is,
local copies are made for each segment declaring them
unless they are declared global. When multiple copies exist,
it is almost certain that input/output will not function
properly. To avoid this problem, the FORTRAN Common
Library common blocks (as a minimum) should be declared
global by the user. The names of these blocks are:

Q8.IO.
FCL.C.
STP.END

Figure 7-18. INCLUDE Directive Example
(The periods are a part of the names.)
Verb

Label

Specification

LEVEL

Declaration of these blocks as global is usually sufficient to
ensure correct operation of input/output. Under unusual
circumstances, however, it might be also necessary to
declare some Record Manager common blocks as global.

Figure 7-19. LEVEL Directive Format

Label

Verb

Specification

segname

GLOBAL

bname-] ,...,
bnamen-SAVE

segname

Name of the segment in which labeled
common blocks are to be included. If
omitted, all blocks named are included
in the root segment.

bname

Name of the labeled common block to
be included in the segment.

-SAVE

Optional parameter indicating that the
contents of common blocks are to be
saved whenever the block is not loaded.

Figure 7-20. GLOBAL Directive Format

60499700 A

0m\

The END directive (figure 7-21) is required as the last
segment directive. Examples of sequences of segment
d i r e c t i v e s a r e s h o w n i n fi g u r e s 7 - 2 2 a n d 7 - 2 3 . T h e
segmented program shown in figure 7-13 can be defined with
the segment directives shown in figure 7-22. In the segment
directives shown in figure 7-23, the user has placed all the
FORTRAN Common Library labeled common blocks in the
root segment to ensure correct communication between
segments. In addition, the function RANF has been included
in each segment in which it is called; this was done so that
the sequence of values produced by successive calls is the
same, regardless of the order in which the segments are
loaded.

Label

Verb

Specification

END

Figure 7-21. END Directive Format

7-9

LOADI NG AND EXECUTI NG A
SEGMENTED PROGRAM
A segmented program is brought into execution in one of
two ways. If an EXECUTE or name call statement
terminates the load sequence that creates the segmented
program, the program is loaded and executed after it is
created. The name call statement must not specify the file
containing the segmented program. At any other time, the
program is loaded and executed by a name call statement
specifying the name of the file containing the program. In
either case, any file name parameters on the name call or
EXECUTE control statement are passed to the program just
as for a basic load.
When execution begins, the resident segment control
program, which occupies approximately 1000fl words, is
loaded first, and then the root segment is loaded! Execution
begins with the main program, which must be unique and
must be in the root segment. When a segmented program is
built, all intersegment external references are replaced with
calls to the resident segment routines. During execution of
a call to an entry point, the segment resident routines regain
control and load the required segment unless it is already
loaded. Any ancestors of the segment (in the same tree) are
also loaded. Control is then returned to the specified entry
point.
Because of the way in which external references are
trapped, several restrictions are imposed on segmented
programs that do not apply to basic loads. One of these is
that subprogram names cannot be passed as actual
parameters.
A more complicated restriction results from the fact that
the CALL statement is implemented through the return
jump (RJ) instruction, as described in the COMPASS
Reference Manual. As part of its operation, the return jump
instruction stores, in the entry point of the routine being
called, a branch back to the calling routine. When the
RETURN control statement in the called routine is
executed, a branch takes place to the entry point of the
routine, which in turn causes a branch back to the calling
routine. In a segmented program, the branch that is stored
in the entry point is not trapped by the loader (since it does
not exist at load time) and, therefore, cannot result in
segment loading. This can lead to invalid results in cases
like the one illustrated in figure 7-24.
In this example, root segment A branches to two incom
patible segments, B and C. Bl, one of the subprograms in
segment B, calls Al, a subprogram in segment A. When the
Label

Verb

Specification

BRANCH

TREE

C-D

TREE

A-(B.BRANCH)

LEVEL
TREE
TREE

F-G

LEVEL
TREE

To summarize, if a routine in one segment calls a routine in
another segment, the calling segment must be loaded at the
time control is returned from the called segment. This
problem does not arise when the calling segment is either
the root segment or an ancestor of the called segment,
because the calling segment is then always loaded at the
same time as the called segment.

Figure 7-22. Segment Directives Example 1

/<<3^\

*^^\

There is no automatic way to avoid conflicts of this type.
Frequently, they can be avoided by careful planning when
the program is designed. In addition, the C$ CALLS and C$
FUNCS statements of the FORTRAN debugging facility can
be used to trace program flow while the program is being
debugged.

Label

FRUIT

CONIFER

Verb

Specification

GLOBAL

Q8.I0.,FCL.C.,STP.END

TREE

APPLE-(PLUM.LEMON)

TREE

ALDER-(FRUIT,CONIFER)

TREE

FIR-(PINE,SPRUCE)

LEVEL
TREE

MAPLE-OAK-(BIRCH,ASPEN)

PINE

INCLUDE

RANF

FIR

INCLUDE

RANF

OAK

INCLUDE

RANF

END
This tree can be diagrammed as follows:
BIRCH ASPEN
\
OAK1

1

.

MAPLE

/

Level

1

-RANF
/

' \\

'

\_

(PLUM LEMON PINE \ SPRUCE)
FRUIT
{
\/
\\/
>CONIFER
(
APPLE
FIR
)

aldefT"^ Level °
H-(U)

END

7-10

call is executed, the return jump stores into the entry point
of Al a branch back to Bl. However, Al calls Cl, a routine
in segment C, before returning; therefore, C is loaded,
overwriting B. When the RETURN control statement in Al
is executed, the branch that is stored in the entry point
attempts to return to Bl. Because the segment resident
routines are unaware of the existence of this branch,
segment B is not loaded, and a branch to some meaningless
address in segment C is executed instead.

\ (Q8.IO.

Nfclc.
(STP.END

Figure 7-23. Segment Directives Example 2

60499700 A

A*^\s-.

Segment directives:
rfgp^N

Label

Verb

Specification

TREE

A-(B,C)

Tree structure:
B
/P*>

V

C

Code in B1 (in B):
SUBROUTINE Bl
CALLA1

•

Code in A1 (in A):
(0$S
SUBROUTINE A1

•
CALLC1
•
•
RETURN

Figure 7-24. CALL-RETURN Conflict

60499700 A

7-11

~

.

STANDARD CHARACTER SET

Control Data operating systems offer the following vari
ations of a basic character set:

r

7/8/9 card. The specified mode remains in effect through
the end of the job unless it is reset by specification of the
alternate mode on a subsequent 7/8/9 card.

CDC 64-character set
CDC 63-character set
ASCII 64-character set
ASCII 63-character set
The set in use at a particular installation was specified when
the operating system was installed.
Depending on another installation option, the system
assumes an input deck has been punched either in 026 or in
029 mode (regardless of the character set in use). Under
NOS/BE, the alternate mode can be specified by a 26 or 29
punched in columns 79 and 80 of the job statement or any

Under NOS, the alternate mode can be specified by a 26 or
29 punched in columns 79 and 80 of any 6/7/9 card, as
described above for a 7/8/9 card. In addition, 026 mode can
be specified by a card with 5/7/9 multipunched in column 1,
and 029 mode can be specified by a card with 5/7/9
multipunched in column 1 and a 9 punched in column 2.
Graphic character representation appearing at a terminal or
printer depends on the installation character set and the
terminal type. Characters shown in the CDC Graphic
column of the standard character set table are applicable to
BCD terminals; ASCII graphics characters are applicable to
ASCII-CRT and ASCII-TTY terminals.

0S\

0^S

0m*.

/SN

60499700 A

A-l

o
o

cor-O'-coincNr-O'-rr
CDtor«.r-ininminininrr
o o o o o o o o o o o

ox
C N
o

co rr in up ro
« D f - c o c n CcM9 ^x 0- Pt n^ c f ?N 0 r?- 0 x?-

91

•ta
C O

<

i n
i-»

tn r r
XT

CO

co in in cn
o , - , - 0 0

CO

m r r co co rr rr

o

f » » TCO rT
xO

St
—

<

J=

0-

CD

o
c

CO
CO

CO

6

r» r - r r

CO

rr r r

- t -

CO

+
CO

Q



+

I*

tn

ii

ar
X

CO

CJ

ra
a

E
E
o
o

a
r"

o

o ina
Q
O

CO
i n

r-

O

in co

+*- cn co rr

m co

r-

CO

CO

CO

CO

CO

CO

CD

Is-

_
,

Is-

CN
Is-

CO
Is-

rr

Is-

i n
Is-

CD
Is-

r«.
Is-

sz

CD

Is-

00

CT)

+

i*

-~-

—

—

OT

ii

"S
"so

T5
O
0)

3-

X

"aJ

'x

a

1

ai
TJ

o3

c

V)

A ©

r v.

0

a>

0

(

—
« -"

>

0 LU >

C

"5
1

-a
c r^

^

^ C N C N C N C N C N C N C N C N C N . ^ -

*r
i n CO i - »
CN CN CM CN

C O

1s-

CN
CO

CO
CO

rr

CO

i n
CD

a
>
u .
CD

CO

rr

E Q
co

U

x
UJ

^

Q>

TJ

o

CO r r in co I s - O r - C N
0 ' - C N C O r r m c o r s - o « - ' - CN
O C O C O C O C O c O C O C D r - f - r r r r r r r r rr rr ^t in in cn

CO rr
CN CN

i n CO
CN CN

IsCN

CO

_
,

CO

CN
«-

•O

CN

CO

rr

i n

i n

CN

o

( N r - c N C O ' » i n t D r ^ o o q > ' 7

CN

CO

r r in co T °9 °? CN

^

j ^ c n c n c n c n c n c n c n c n c n ' ^ -

^

CO

rr

i n

C O

00

O)

6 6

O

x-

CN

CO

03

a

CU

CO

CO

i

i n
f

a>
r
a

Q

91
TJ

o

■-1
t -

c n r - t s t o x t x t x r ^ t n r - o i

CO

rr

i n

co r-

o

O «- CN CO
CN CM CN CN

T
in
CN CN

CO
CN

r»
CN CO

r -

co

CN
CO

CO CO

IsCO

i n
CO

_ o
O a
CO

c1_
QJ

la
QJ
N

■a

i n
CJ

'sz
a
CO
1_
O)
1

CO
CO
CO

0)
4-"

c

sn

za

CU

at
X
3
CO

■■

-

>
c
0

—

CN

CO

rr

0

i n

0
CD

>
QJ

u

u 'x
Q
O

"ro
f
X
cu

CD

aar
6

_
^
•-



xC

_1

Z O

a. a CC co

\- 3

>-

O

r-

CN

CO

rr

i n

$
■1-

cu

sn
OC
1—
t o

«

O O)
C CM
TJ

O)

rr

c

0

QJ

t t

cu

cu Q.

>

«5

S Z
t t

rr

0
CO

iz

O
O

CD

6 6 6 6 6

">
C
(0

.*2 c

CU

L. (J
•

E

OJ

0

c

•20) 111

ra

— *I

c

0

CO

T3

T3
O 6s-

CL)

or
<

A-2


£ CM
O

O
C■—■
£ £
"S
•
03 -s
.S2I
"q. a>

CO

"to
i t
s n
CZ

»2 ro
£
\p

03

++-

QJ
+->
°^ -zz
CO
03

SZ sz
\- r-

■t•4-

- 1 -

60499700 A

OCTAL-DECIMAL INTEGER CONVERSION TABLE
OcM totoo 20000 30000 40000 SOSOQ K080 70009
Otetail 40K I1S2 122IJ 1SJI4 20410 24578 28872
Otttl 80S0 to 0377
Oltiail COCO t 0255

S

Double precision 3-11

D parameter (FTN) 4-7
Dump 4-7

Card decks 6-1
C ATA L O G
NOS 6-6
NOS/BE, SCOPE 2 5-8
CM parameter 7-5
Coding style 1-3
Comments 1-3
Common blocks
effect on optimization 3-9
in segments 7-7
Common decks 6-13
Common library
common blocks 7-9
mathematical functions 3-11
Common subexpression elimination 3-4
Compilation errors 4-1
Compile file 6-12
Compile time evaluation 3-5
Conditional branches 3-10
Constant evaluation 3-5
Control statement 5-1
COPY 5-5
COPYBF 5-6
COPYBR 5-6
COPYCF 5-6
COPYL 6-8
Copy operations 5-5
CORCO 2-8
Correction run (UPDATE) 6-15
Correction set 6-12
Creation
program library 6-13
user library (NOS) 6-6
user library (NOS/BE, SCOPE 2) 6-3
Cross-reference map 4-4
C$ DEBUG 4-7
Data, testing 4-4
DATA statement 3-10
D a y fi l e 4 - 6
Dead definition elimination
DEBUG file 4-7

Debugging 4-1
Debugging facility 4-7
Decks
card 6-1
sample 5-1
U P D AT E 6 - 1 3
DEFINE 5-9
Density, tape 5-10
Desk checking 4-1
Diagnostics 4-1
Direct access files 5-9
Directives
EDITLIB 6-3
LIBEDIT 6-8
LIBEDT 6-3
segment 7-8
U P D AT E 6 - 1 2
DMPX 4-7
Documentation 1-3

3-4

EDITLIB
control statement 6-4
directives 6-4
End-of-partition 5-5
End-of-section 5-5
Equivalence classes, optimization 3-9
Errors
categories 4-2
compile time 4-1
execution time 4-4
EXECUTE 7-2
Execution errors 4-4
Execution of program 5-1
EXIT 5-2
Expression elimination 3-4
EXTEND 5-8
External references 7-1
Factoring 3-11
Fatal errors 5-3
Field length 7-5
File name call 7-2
Files
direct access 5-9
indirect access 5-9.
permanent 5-7
Functional unit scheduling 3-7
GAUSS 2-1
GET 5-9

Global

common blocks 7-9
library set 7-4
optimization 3-1
GTR 6-8

Ill-conditioning 3-11
Indirect access files 5-9
Infinite value 4-8
Invariant code motion 3-2

Index-1

Job decks, sample 5-1
LABEL 5-10
Labels 5-10
LDSET 7-4
Levels 7-6
LGO 7-2
LIBEDIT 6-8
LIBEDT
control statement 6-4
directives 6-4
LIBGEN
control statement 6-8
Libraries
program 6-12
search order 7-4
user 6-2
L I B R A RY 7 - 4
Library set
global 7-4
local 7-4
LINK 2-6
LOAD 7-3
Loader errors 4-7
Loading 7-1
Load map 4-7
Local library set 7-4
Local optimization 3-1
Loop restructuring 3-10
L tapes 5-10
Machine-dependent optimization - -6
Machine-independent optimization 3-2
Magnetic tapes 5-10
Map
load 4-7
reference 4-4
Mathematical programming 3-11
Memory 7-5
Messages, diagnostic 4-1
Mixed mode 3-10
Mode, mixed 3-10
Mode errors 4-7, 4-8
Modularity 1-1
Name call statement 7-2
New program library 6-12
NEWTON 2-1
NOGO 7-3
NOS
permanent files 5-9
skip operations 5-7
user libraries 6-•6
NOS/BE
permanent files 5-7
skip operations 5-6
user libraries 6-2
NUCLEUS 7-4
Object code
listing 4-7
optimization example 3-8
Old program library 6-12
Optimizations
example 3-8
global 3-1
local 3-1
machine-dependent 3-6
machine-independent 3-2
source code 3-9

OPT=2 3-1
OTOD 2-6
Overlays 7-1

Partition 5-5
Permanent files
NOS 5-9
NOS/BE, SCOPE 2 5-7
Prefetching 3-7
Program, segmented, see Segments
Program library 6-2
Programming techniques 1-1
PURGE
NOS 5-10
NOS/BE, SCOPE 2 5-8

"*>

Record manager
common blocks 7-9
W type records 5-5
REDUCE 7-5
Reduce mode 7-5
Reference map 4-4
References, external 7-1
Register assignment 3-7
Relocation 7-1
REPLACE 5-9
REQUEST
permanent files 5-8
tapes 5-10
RESOURC 5-2
RETURN 5-4
REWIND 5-4
RFL 7-5

>w^\

Satisfaction of references 7-1
SAVE 5-9
SCOPE 2
permanent files 5-7
skip opeations 5-6
user libraries 6-2
Search, library 7-4
Section 5-5
SEGLOAD 7-8
Segments
building 7-7
directives 7-8
executing 7-10
loading 7-10
structure 7-6
SI tapes 5-10
SKIPB 5-6
SKIPBF 5-7
SKIPF
NOS 5-7
NOS/BE, SCOPE 2 5-6
Skip operations
NOS 5-7
NOS/BE, SCOPE 2 5-6
SKIPR 5-7
SLOAD 7-2
Source code optimization 3-9
S tapes 5-10
Strength reduction 3-6
Subscripts, see Array Subscripts
Symbolic dump 4-7
Symbolic reference map 4-4
SYSLIB 7-4

■<*^\

■■V
^I—

^s^k

-*^\
Index-2

60499700 A
.AtA

00^*

Tapes 5-10
Testing 4-4
Test replacement 3-5
Top-down programming 1-1

User libraries
NOS 6-6
NOS/BE, SCOPE 2 6-2
User optimization 3-9
Utilities 6-1

Unformatted records 5-5
UNLOAD 5-5
Unsatisfied externals 7-1
UO option
prefetching 3-7
register assignment 3-7
UPDATE
control statement 6-13
directives 6-12
listing 6-16
USER 5-1

Volume serial number
VSN 5-10

Trees 7-6

5-10

W type records 5-5
6/7/8/9 card 5-1
7-track 5-10
7/8/9 card 5-1
9-track 5-10

0ms,

■^-0X\

60499700 A

Index-3

'^|V

/^%

I

f1*

COMMENT

I I

/2

SHEET

\ o i e S 5/ \ C O N T R p Lc o r p o r aDt iAoTnA

I TITLE: FORTRAN Extended Version 4 User's Guide
P U B L I C AT I O N N O . 6 0 4 9 9 7 0 0 R E V I S I O N A
V • This form is not intended to be used as an order blank. Control Data Corporation solicits your comments about this
manual with a view to improving its usefulness in later editions.
;^f

jpsK ' Applications for which you use this manual.

Do you find it adequate for your purpose?

What improvements to this manual do you recommend to better serve your purpose?
/$P*N

Jp*S

f

Note specific errors discovered (please include page number reference).
lJ j

Z |
_J

0^S

2I
°

X
H
7-\
i - '

*>!

General comments:

iaij0&\

FROM

NAME:

POSITION:

COMPANY
NAME:
ADDRESS:
NO POSTAGE STAMP NECESSARY IF MAILED IN U.S.A.
FOLD ON DOTTED LINES AND STAPLE

STAPLE

STAPLE

s^\

A*^\

('•OLD

F^?__|
FIRST CLASS
PERMIT NO. 8241
MINNEAPOLIS, MINN.

BUSINESS

R E P LY

MAIL

NO POSTAGE STAMP NECESSARY IF MAILED IN U.S.A.

POSTAGE WILL BE PAID BY

CONTROL DATA CORPORATION
Publications and Graphics Division
115 Moffett Park Drive
Sunnyvale, California 94086

FOLD

"^^^

^5^(*

STAPLE

STAPLE



File Type                       : PDF
File Type Extension             : pdf
MIME Type                       : application/pdf
PDF Version                     : 1.3
Linearized                      : No
Page Count                      : 112
Creator                         : ScanSnap Manager
Producer                        : Mac OS X 10.5.8 Quartz PDFContext
Create Date                     : 2009:10:23 02:45:13Z
Modify Date                     : 2009:10:23 02:45:13Z