1972 05_#40 05 #40

1972-05_#40 1972-05_%2340

User Manual: 1972-05_#40

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

Download1972-05_#40 1972-05 #40
Open PDF In BrowserView PDF
AFIPS
CONFERENCE
PROCEEDINGS

VOLUME 40

1972
SPRING JOINT
COMPUTER
CONFERENCE
May 16 - 18, 1972
Atlantic City, New Jersey

The ideas and opinions expressed herein are solely those of the authors and are not
necessarily representative of or endorsed by the 1972 Spring Joint Computer Conference Committee or the American Federation of Information Processing
Societies, Inc.

Library of Congress Catalog Card Number 55-44701
AFIPS PRESS
210 Summit Avenue
Montvale, New Jersey 07645

@1972 by the American Federation of Information Processing Societies, Inc.,
Montvale, New Jersey 07645. All rights reserved. This book, or parts thereof, may
not be reproduced in any form without permission of the publisher.

Printed in the United States of America

CONTENTS
IMPLEMENTATION OF PROGRAMMING LANGUAGE
PROCESSORS
1

R. M. McClure
T. E. Cheatham, Jr.
B. Wegbreit

An appraisal of compiler technology ............................ .
A laboratory for the study of automating programming ........... .

11

Segmentation and optimization of .programs from cyclic structure
analysis ................................................... .

23

J. Baer
R. Caughey

37
45
51

K. K. Curtis
R. B. Lazarus
M. S. Lynn

53
59
69
77

B. Jones
J. O. Hammond
R. W. Kleffman
G. A. Smith

FRONTIERS OF LARGE-SCALE SCIENTIFIC COMPUTATION
The interplay of computer science and large-scale scientific calculation.
Computer architecture and very large problems ........ ; ......... .
Scientific applications of computers in the 70's ................... .
THE COMPUTER AS SUPERTOY-PANEL SESSION
(No papers in this volume)
TRAINING COMMERCIAL PROGRAMMERS AND SYSTEMS
ANALYSTS
The functions and elements of a training system .................. .
Planning data processing education to meet job requirements ...... .
Modular training-A new emphasis ............................. .
Training techniques today-Tomorrow .......................... .
SOFTWARE DESIGN FOR THE MINI-COMPUTER
The future of mini-computer programming ...................... .

103

The current state of mini-computer software ..................... .
Real-time fault detection for small computers .................... .

111
119

D. Waks
A. B. Kronenberg
J.' Ossanna
J. R. Allen
S. S. Yau

TECHNIQUES FOR DEVELOPING LARGE PROGRAMMING
SYSTEMS
An organization for successful project management ............... .
Commercial data processing machines in government applications .. .
Programming language efficiency in real-time software systems ..... .

129
141
155

D. Smith
J. D. Aron
R. E. Merwin
J. O. Henriksen

163
181
187

B. Friedland
D. H. Jacobsen
D. G. Wilson

199

P. E. Valisalo
B. D. Sivazlian
J. F. Maillot

205
219
225
235

R. L. Graham
Z. Manna
D. Scott
J. D. Ullman

MATHEMATICAL OPTIMIZATION THEORY AND ALGORITHMS
A review of recursive filtering algorithms ........................ .
On computational methods for dynamic and static optimization .... .
Piecewise linear approximations of fewest line segments ........... .
Experimental results on a new computer method for generating optimal policy variables in (s,S) inventory control problem .......... .

NEW THEORETICAL FRONTIERS OF COMPUTER SCIENCE
Bounds on multiprocessing anomalies and packing algorithms ...... .
Computation of recursive programs-Theory vs practice .......... .
Mathematical concepts in programming language semantics ........ .
Applications of language theory to compiler design ............... .

THE ARPA NETWORK
The terminal IMP for the ARPA computer network ................ .

243

S. M. Ornstein
F. E. Heart
W. R. Crowther
H. K. Rising
S. B. Russell
A. Michel

Computer communication network design-Experience with theory
and practice ............................................... .

255

Function-oriented protocols for the ARPA computer network ...... .

271

McROSS-A multi-computer programming system ............... .

281

H. Frank
R. E. Kahn
L. Kleinrock
S. D. Crocker
J. Heafner
J. Metcalfe
J. Postel
R. H. Thomas
D. A. Henderson, Jr.

Extension of packet communication technology to a hand-held personal terminal .............................................. .

295

L. G. Roberts

An overview of programming languages for special application areas .. .
The future of specialized languages ............................. .

299
313

AMBUSH-A case history in language design ................ , .. ;.
The data-text system-An application language for the social
sciences ...... , ..................................... , ...... .

321

J. E. Sammet
F. B. Thompson
B. H. Dostert
S. Warshall

333

D. J. Armor

LSI-Implications for future design and architecture .............. .

343

The rationale for logic from semiconductor memory ............... .
SYMBOL hardware debugging facilities ......................... .
The Rice Research Computer-A tagged architecture ............. .

353
359
369

S. F. Dennis
M. G. Smith
W. H. Davidow
M. A. Calhoun
E. A. Feustel

PROGRAMMING LANGUAGES FOR SPECIALIZED
APPLICATION AREAS

NEW TRENDS IN THE ARCHITECTURE OF COMPUTER
SYSTEMS

COMPUTERS IN INSTRUCTION-SOME CONSIDERATIONS
A generative CAl tutor for computer science concepts ............. .
Preliminary thoughts about a UNIversal TEAching Machine ...... .

379
391

Mainline CAl, necessary but not oppressive ..................... .
Should the computer teach the student or vice versa? ............ .

399
407

E. Koffman
J. K. Clema
R. L. Didday
M. Wessler
C. V. Bunderson
A. W. Luehrmann

OPERATING SYSTEM DESIGN CONCEPTS
Performance evaluation-A structured approach ................. .
Protection-Principles and practice ............................. .

411

PRIME-An architecture for terminal oriented systems ........... .

431

417

S. Kimbleton
G. S. Graham
P. J. Denning
H. B. Baskin
B. R. Borgerson
R. Roberts

GRAPHIC TERMINALS-PRESENT AND NEXT STATES
Computer graphics terminals-A backward look .................. .
The future of computer graphics ............................... .

439
447

A versatile computer-driven display system for the classroom ...... .
GOLD-A graphical on-line design system ....................... .

453
461

C. Machover
R. H. Stotz
T. G. Hagan
J. W. Will hide
L. J. French
A. H. Teger

FORMAL ANALYSIS OF ALGORITHMS
Establishing lower bounds on algorithms-A survey .............. .
Analysis of combinatory algorithms-A sampler of current
methodology ............................................... .
On the complexity of proving and disproving functions ............ .
On the structure of Blum measure .............................. .

471

E. Reingold

483
493
503

W. D. Frazer
A. N. C. Kang
T. S. Chow

Management information systems, public policy, and social change ... .
Geographic information systems in the U.S.-An overview ......... .

507
511

A. Gottlieb
R. Amsterdam
E. Andersen
H. Lipton

UNIMATCH-A computer system for generalized record linkage
under conditions of uncertainty .............................. .
New directions in legal information processing ................... .

523
531

M. Jaro
R. T. Chien
P. B. Maggs
F. A. Stahl

HOMLIST-A computerized real estate information retrieval
system ..................................................... .

541

D. J. Simon
B. L. Bateman

Organization of a natural resources data bank system for government
and research ............................................... .
The command terminal-A computerized law enforcement tool. .... .

545
553

A. J. Surkan
D. M. Hudak

Experience gained in the development and use of TSS/360 ......... .
Multics-The first seven years ................................. .

559
571

Organization and features of the Michigan terminal system ........ .

585

R. E. Schwemm
F. J. Corbat6
C. T. Clingen
J. H. Saltzer
M. T. Alexander

THE COMPUTER IN GOVERNMENT-A TOOL FOR CHANGE

INTERACTIVE SYSTEMS

DATA COMMUNICATIONS-THE PAST FIVE YEARS AND
THE NEXT TEN YEARS
Data communications-The past five years ..................... .
Data communications in 1980-A capital market view ............ .

593
611

Allocation of copies of a file in an information network ............ .

617

P. Walker
R. E. LaBlanc
W. E. Himsworth
R. G. Casey

MANPOWER FOR COMPUTERS-HEYDAY OR CUTBACK
Production and utilization of computer manpower in U.S. higher
education .................................................. .
Sources of trained computer personnel-A quantitative survey ..... .

627
633

Employment of trained computer personnel-A quantitative survey ...

641

Sociological analysis of public attitudes toward computers and
information files ............................................ .

649

J. W. Hamblen
B. Gilchrist
R. E. Weber
B. Gilchrist
R. E. Weber
R. E. Anderson

MICROPROGRAMMING ENTERS A NEW ERA
Microprogrammed significance arithmetic-A perspective and feasibility study ................................................ .
Architectural considerations of a signal processor under microprogram
control .................................................... .
A building block approach to multiprocessing .................... .

675
685

The interpreter-A microprogrammable building block system ..... .

705

659

C. V. Ramamoorthy
M. Tsuchiya
Y.S. Wu
R. L. Davis
S. Zucker
C. M. Campbell
E. W. Reigel
U. Faber
D. Fisher

PERFORMANCE PREDICTION-MODELING AND
MEASUREMENT
Modeling, measurement and computer power .................... .

725

Experiments in page activity determination ...................... .
Validation of a trace-driven CDC 6400 simulation ................ .

739
749

Instrumentation for the evaluation of a time-sharing, page demand
system .................................................... .

759

J. Rodriguez- Rosell
J. Dupuy

767

L. Seligman

775

H. G. Rudenberg
J. T. Quatse
P. Gaulene
D. Dodge

G. Estrin
R. R. Muntz
R. Uzgalis
J. G. Williams
J. D. Noe
G. J. Nutt

LSI PERSPECTIVES-ARCHITECTURE AND COST OF SMALL
COMPUTERS
LSI and minicomputer system architecture-Implications for multiprocessor systems ........................................... .
Approaching the minicomputer on a silicon chip-Progress and
expectations for LSI circuits ................................. .
The external access network of a modular computer system ........ .

783

COMPUTER SIMULATION AS A DECISION MAKER'S TOOL
An over-the-shoulder look at discrete simulation languages ......... .
A specialized language for simulating computer systems ........... .

791
799

1. M. Kay
P. B. Dewan
C. E. Donaghey
J. B. Wyatt

Discrete computer simulation-Technology and applications-The
next ten years .............................................. .

815

J. N. Maguire

The emergence of the computer utility .......................... .

827

Installation management-The next ten years .................... .

833

R.
H.
D.
R.

THE DILEMMA OF INSTALLATION MANAGEMENT

PROGRAM DOCUMENTATION-PANEL SESSION
(No papers in this volume)
THE ROLE AND SCOPE OF COMPUTER SYSTEMS DESIGN
RESEARCH IN A UNIVERSITY SETTING-PANEL SESSION
(No papers in this volume)

S. Manna
Waldburger
R. Whitson
M. Rutledge

AN EVALUATION OF THE STATE OF COMPUTER SCIENCE
EDUCATION
841
847

S. Amarel
M. S. Lynn

849
857

P. J. Denning
p.1 C. Fischer

865
875
885
897

H. F. Cline
G. Sadowsky
T. L. Jones
R. C. Noel
T. Jackson

907

J. D. Schoeffler

915
925

H. E. Pike
O. Serlin

933
937

E. W. Dijkstra
P. J. Denning

Magnetic disks for bulk storage-Past and future ................ .

945

J. M. Harker
H. Chang

Ultra-large storage systems using flexible media,' past, present and
future ...... " .................................. " ......... .
New devices for sequential access memory ....................... .

957
969

W. A. Gross
F. H. Blecher

Two direct methods for reconstructing pictures from their projections-A comparative study ............... , ................. .
PRADIS-An advanced programming system for 3-D-display ...... .

971
985

MARS-Missouri Automated Radiology System ................. .

999

Sailing-An example of computer animation and iconic communication
Computer description and recognition of printed chinese characters ... .
Computer diagnosis of radiographs ............................. .

1005
1015
1027

G. T. Herman
J. Encarnacao
W. Giloi
J. L. Lehr
G. S. Lodwick
D. J. Manson
B. F. Nicholson
S. M. Zwarg
W. Stallings
S. J. Dwyer
C. A. Harlow
D. A. Ausherman
G. S. Lodwick

A set of goals and approaches for education in computer science ...... .
Computer science education-The need for interaction ............ .
Operating systems principles and undergraduate computer science
curricula .................................................. .
Theory of computing in computer science education .............. .
SCIENTIFIC COMPUTATION-THE SOCIAL SCIENCES
Social science computing-1967-1972 ............................ .
PotentiaJ future developments in social science computing ......... .
A computer model of simple forms of learning in infants ........... .
An information management system for social gaming ............. .
PROGRAMMING· FOR PROCESS CONTROL AND REAL TIl\IE
APPLICATIONS
The development of process control software ..................... .
Future trends in software development for real-time industrial
automation ................................................ .
Scheduling of time critical processes ............................ .
ACM PRIZE PAPERS IN PROGRAMMING LANGUAGES AND
SYSTEMS
A class of allocation strategies inducing bounded delays only ....... .
On modeling program behavior ................................. .
A SPECTRUM OF MEMORY STORAGE SYSTEMS, NOW AND
IN THE FUTURE

GRAPHIC SOFTWARE

COMPUTERS IN SECONDARY EDUCATION
The impact of computing on the teaching of mathematics ......... .
Computing in the high school-Past, present and future-And its
unreasonable effectiveness in the teaching of mathematics ....... .

1043

W. Koetke

1051

W. Stenberg

LSI PERSPECTIVES-DESIGN AUTOMATION: DESIGN AND
SIMULATION

1059
1065
1071
1079

H. W. vanBeek
J. J. Teets
N. B. Rabbat
M. A. Mehta
H. P. Messinger
W. B. Smith

Computer-aided drug dosage ................................... .

1093

Automated therapy for non-speaking autistic children ............. .

1101

L. B. Sheiner
B. Rosenberg
K. L. Melmon
D. C. Smith
M. C. Newey
K. M. Colby

Computer-aided design of MOS/LSI circuits ..................... .
The role of simulation in LSI design ............................ .
Implementation of a transient macro-model in large logic systems .. .
Functions for improving diagnostic resolution in an LSI environment ..

DEVELOPMENTS IN BIOMEDICAL COMPUTER TECHNOLOGY

An inferential processor for interacting with biomedical data using
restricted natural language .................................. .
An information processing approach to theory formation in biomedical
research ................................................... .
The clinical significance of simulation and modeling in leukemia
chemotherapy .............................................. .
Interactive graphics software for remote terminals and their use in
radiation treatment planning ................................ .
Automated information-handling in pharmacology research ........ .

1107

D. W. Isner

1125

H. Pople
G. Werner

1139

T. L. Lincoln

1145

K. H. Ryden
C. M. Newton
W. Raub

1157

THE IMPLEMENTATION GAP IN MANAGEMENT
INFORMATION SYSTEMS
Where do we stand in implementing information systems? ........ .
MIS technology-A view of the future .......................... .
Selective security capabilities in ASAP-A file management system ..

1167
1173
1181

A graphics and information retrieval supervisor for simulators ...... .
NASDAQ-A user driven, real-time transaction system ........... .

1187
1197

J. C. Emery
C. Kriebel
R. Conway
W. Maxwell
H. Morgan
J. L. Parker
N. Mills

1207
1211

H. G. Cragon
M. J. Flynn

LSI PERSPECTIVES-THE BOUNDARIES OF COMPUTER
PERFORMANCE
LSI perspectives-The last five years ........................... .
Towards more efficient computer organizations ................... .

An appraisal of compiler technology
by ROBERT M. McCLURE
Consultant

stood that we are mainly talking about so-called "production" compilers. By this we mean compilers for important languages that are intended for translating programs that are expected to be run extensively. l\Ioreover, we restrict our consideration to compilers for
medium and large scale general purpose computers. The
subject of compilers for minicomputers and special
purpose computers is deserving of considerable study on
its own. Also research compilers, "quick and dirty"
compilers, and pedagogic compilers will not be considered in this commentary. Finally, it is inevitable that
someone's favorite technique will be given a short straw.
For this we plead for tolerance.

INTRODUCTION
Although the last decade has seen the implementation
of a very large number of compilers for every conceivable language, the literature on compiler writing is still
unorganized. There are many papers on formal languages, syntactic analysis, graph theoretic register assignment, and similar topics to be sure. But, they are
not very useful in helping the newcomer to the field
decide how to design a compiler. Even the recent books
in the field are more encyclopedic in nature than instructive. The best single book available is Gries,! which has
a good bibliography for further study.
The few open descriptions of compilers that do exist
rarely are candid about the mistakes that were made.
This is, after all, human nature. lVloreover the nature of
scientific publishing is not conducive to papers of an
evaluative or subjective nature. The principal reason,
therefore, for writing this paper, is not to add to the basic
body of scientific knowledge, but rather to provide a
few value judgments on how compilers are being written and should be written. Since subjective statements
should always be prefaced with "It is my opinion that",
the indulgent reader will understand that this phrase
should be applied to the entire paper.
There is an enormous amount of material to be studied in connection with compiler design. lVlost of it is
very difficult to read. vVe refer to the listings of the compilers themselves and associated internal documentation. At present there is no alternative to obtaining a
comprehensive knowledge of the field. Even if one is
willing to put forward the effort, however, much of the
material is difficult to obtain. The desire of computer
manufacturers and software houses to protect their latest ideas interferes with a free flow of information. The
result of this is the growth of an oral tradition for passing information much like the wandering troubadours of
yore. Until this changes, there will be hardships worked
on those who would like to learn the trade.
In order to reduce this paper to manageable size and
to make generalizations more useful, let it be under-

SYNTACTIC ANALYSIS
In the area of syntactic analysis or parsing, the necessary solutions are clearly at hand. Parsers are now routinely constructed by graduate students as class projects. The literature on the subject is extensive, and new
techniques are revealed regularly. Almost all compilers
are written using only two of the many available methods however: recursive descent or precedence. Rarely
are either used in pure form. Compilers that use both
methods intermixed are common. Although both of
these methods have their roots in the very earliest compilers, they remain the mainstays of the business.

Recursive descent
The basic idea in recursive descent is that there is a
one-to-one correspondence between the syntactic units
in the formal description .of the language and routines
for their recognition. Each routine examines the input
text by either scanning for specified terminal tokens
(usually produced by a separate lexical analyzer) or by
calling other routines to recognize non-terminal syntactic units. Figure 1 is a flowchart of one such simple
recognizer. Because most practical languages are defined recursively, the recognizers must themselves be
1

Spring Joint Computer Conference, 1972

2

6p-<"'"""OiO">- Ep--< ""'0"'"'>-~-<""'""'"'>-F

T

ERROR

Figure I-Recognition routine

recursive. Upon exit from each procedure, either the
required syntactic unit has been recognized· and the
appropriate actions taken, or an error message has been
produced.
Recursive descent analyzers are usually written so
that it is never necessary to "back up" the input stream.
If an impasse is reached, an error indication is given,
perhaps a correction attempted, and the scan resumed
at some readily recognizable token, such as ";". The
knowledge of the context at the time an error is discovered allows more meaningful diagnostics to be generated than with any other technique.
The use of recursive descent usually requires the rearrangement of the formal syntax, since left recursions
must be removed. Although this is not difficult, it does
somewhat spoil the clarity of the approach. For peculiar
grammars, it is easier to use recursive descent than to
transform the grammar into a form suitable for precedence analysis. Although the methodology is basically
ad hoc, recursive descent is the most widely used
method of syntactic analysis.
Recursive descent has one further advantage for a
language with a large number of productions. Precedence methods seem to require table sizes proportional
to the square of the number of syntactic units, whereas
recursive descent recognizers are roughly proportional
to the grammar size.
Precedence analysis

The idea that operators have varying degrees of
"precedence" or "binding-power" is quite old, and has
been used in some of the earliest compilers. The formalization of precedence relations between operators actually started with Floyd2 in 1963. Now it is more
customary to define precedence relations between all
syntactic units. While very few producti0Ii compilers
have used a formal precedence parser yet, the modern
implementation of these techniques such as described
by lVlcKeeman,3 is clearly destined for wider use.
The fundamental attraction of precedence methods
lies in the automatic construction of analyzers from the
formal grammar for the language to be analyzed. Parsers

built in this way can be quickly changed to reflect
language changes simply by changing the tables without
modifying the underlying interpretation algorithm.
Furthermore, if the tables are constructed by formal
methods, the language accepted is exactly that specified and no other. This considerably simplifies the construction of bug-free parsers.
There are some drawbacks to parsers built wholly
around precedence methods. For example, many
languages in everyday use, such as COBOL and FORTRAN can simply not be made into precedence languages. Even PL/I can only be fit into the correct mold
with considerable difficulty. 1Vloreover, the tables required can be quite large.
A major problem with precedence parsing methods is
the problem of recovery from source program errors and
the issuance of good diagnostics for such errors. Several
approaches to solving this problem have been tried with
only modest success. Various techniques for reducing
the size of the tables required, such as the introduction
of precedence functions, serve only to complicate this
problem.
Nevertheless, there are several conditions that suggest strongly that a precedence parser of some variety
should be tried. If, for example, a parser must be produced in the shortest possible time. Precedence parsers
tend to be easy to debug. A further advantage is gained
if the language is being designed at the same time as the
compiler, since the language can be made into a precedence language. Finally, a precedence parser is often a
most suitable alternative when recursive procedure calls
required for recursive descent parsing are either impossible (as in FORTRAN) or expensive (as in PL/I).
Mixed strategies

A number of compilers use the technique of recursive
descent for analysis of the larger syntactic units such as
statements, and turn to precedence methods for parsing
expressions. In this case, simple operator precedence
analysis is customarily used. There is no conceptual or
practical difficulty in accomplishing this since the expression recognizer requires relatively small tables which
may easily be hand constructed. The number of calls on
procedures is minimized (normally a high overhead
item) and perhaps the best of both worlds is achieved.
The idea of mixing parsing techniques can be generalized. It appears (with no theoretical foundation as
yet) that a good partition is achieved when the subgrammar to be parsed with a precedence parser results
in a relatively dense precedence matrix, and the subgrammar to be parsed with a recursive descent parser
would result in a relatively sparse (for legitimate symbol pairs) precedence matrix.

Appraisal of Computer Technology

INTERNAL REPRESENTATION
Generation of code occurs simultaneously with syntactic analysis only in very small compilers and quick
and dirty compilers. In most compilers the results of
syntactic analysis are stored for later code generation.
A number of ways have been described for the internal
representation of the results of parsing, two of which
have attained really wide usage: tree structures (most
usually a form known as triples) and late operator
Polish notation. Figure 2 illustrates several forms of the
representation of a simple expression. Form (a) is a
binary tree, called triples when recorded in the tabular
form shown, since each line consists of an operator and
two operands. The result of each operator is known implicitly by the line number of the triple. Form (b) is a
tree form with variable sized nodes. Form (c) is the Polish form and is actually the string that results from traversing the terminal nodes of a parse tree in a prescribed
order.
The simpler compilers prefer the Polish representation since subsequent processing usually amounts to
simply a linear reading of the text. Fortunately the
order in which action is to be taken by the code genera-

A+ B + C * D

3

tor is very nearly that of tokens in the Polish string anyway. Since this is also the order of generating the Polish
string, the only advantage gained from deferred generation is that obtained by a full reading of all of the text,
including declarations, implicit as well as explicit. Although optimization can be implemented on internal
representations in Polish form, tree forms are much
easier to work with.
A further advantage of Polish strings is that they may
be easily written on and read from sequential data files,
are conceptually simple, and require a minimum of additional space for linkage information. If memory space
is at a premium or the simplest representation is preferred, Polish strings are recommended.
Complete representation of the source program in
tree form is now growing in popularity, and has appeared in quite a number of the more recent compilers.
It is especially prevalent in compilers for major languages for the larger machine in which optimization is
important. The ease with which the program can be
searched and/or rearranged is the primary motivation
for this selection. For building a generation system based
upon formal semantics, an internal tree representation
is a good choice. Not only does it appear that code generation can be formalized but also that optimization
strategies can be formalized utilizing the idea of transformation sets defined over trees.
SYlVIBOL TABLES AND DICTIONARIES

1

*

C D

2

+

B

3

+

A (2)

1

C

2
3

D

4

B

5
6

*2 (1)
+3 (3)

BINARY TREE

(B)

FULL TREE

(c)

POll SH STR I NG
Figure 2-Internal representations

A

(1)

Considerable effort has gone into devising symbol
table routines that have all of the desirable properties
of compactness of storage required, speed of access, and
simplicity of construction. The result is that almost all'
compilers use some variant of the hash link method.
In this method, the symbol to be looked up is first
hashed into a reasonably small range such as 31 to 512.
This hash index is then used to access the head of a list
of symbols with the same hash value. This is shown
schematically in Figure 3., This hash chain is frequently
ordered, say alphabetically, to reduce further the lookup time.
The dictionary information associated with each symbol may either be included directly with the external
representation or be contained in a separate table. Since
in a multiple pass compiler, the external representation
is not required after the lexical analysis is complete,
the separation of symbol table and dictionary has become customary.
It is becoming increasingly important to make provision for symbol tables and dictionaries to grow beyond the bounds of the available main memory. This
presents no unusual problems for hardware systems that

4

Spring Joint Computer Conference, 1972

tive size of these tables could only be statistically determined, unnecessary limitation in the size of programs
that could be compiled frequently occurred. During the
1960's however, dynamic allocation of storage came
into· widespread use. Although many techniques have
been invented, only two have proven extremely popular: movable, contiguous tables, and block allocation.

o

~

N-l
HASH
TABLE
(CHAIN HEADS)

Movable tables

~l
B EE

\

tc

" - - - - 1

SYMBOLS WITH'IDENTICA'-.HASH VALUES

~

~

Figure 3-Hash chain symbol table

support virtual memory, but does require careful attention if it must be strictly software supported. The
simplest and usual method is to divide the space required into pages and to address this space through an
availability table. This method is used in the IBM
PL/I compiler (F-Level) to allow the compilation of
very large programs on a relatively small machine. In
designing symbol table methods for use with software
virtual memory, a premium is placed on minimizing the
number of references to different blocks.
Compilers for block structured languages with immediate code generation usually allocate new dictionary
entries in stack fashion. That is, new entries are placed
in first position on the correct hash chain. Searching the
hash chain then automatically gives the correct instance
of the symbol searched for. At block closure, all the
chains are pruned until an enclosing block number is
found. The table is then shortened to the level that
existed at block entry. In this way, symbol table entries
that are no longer needed by the compilation are
constantly discarded. Although PL/I is block structured, this very simple approach is not available without refinement. In PL/I, declarations may at any point
be made in enclosing blocks. For examples, lables on
entry statements belong to the immediately enclosing
block, implicitly declared variables belong to the outermost block, and variables declared with the EXTERN AL attribute are scopeless.

The conceptual simplicity of having tables in consecutive memory locations is a major reason for adopting the idea of "floating" tables. The additional burden
of referencing all entries indirectly through a current
table base pointer is a small price to pay for this simplicity. First used in compilers by Digitek in a series of
minicomputer compilers and by IBM in a COBOL compiler for the IBlVl 7090 in the early 1960's, the basic
ideas have been widely adopted. Modern computer
architecture that makes both base addressing and indexing simultaneously available makes implementation
extremely simple.
Every table is allowed to grow (or shrink) independently. Before any table expands, a check is made to see
if there is available space. If not, space is made available

1

1

~XX

2

3

4

~.I
4

IXXX)(

5

5

TABLE MANAGEMENT

BEFORE
Early compilers had fixed size tables for storing information needed during compilation. Since the rela-

AFTER

Figure 4-Movable table storage allocation

Appraisal of Computer Technology

by actually copying the data items in the tables to be
moved into another location in memory. Although copying data in memory to reorganize storage seems inefficient at first, it turns out to be quite satisfactory in
practice since it occurs rarely. Figure 4 shows how tables
are rearranged to allow available space for all tables to
grow.
The interesting questions about this form of allocation revolve around deciding how much of the available
space to allocate to each table. Garwick suggests that
space be allocated in proportion to how much each table
has grown since the last allocation. CITRUS (the storage allocation package in the IBlVl COBOL compiler)
required specification of the desired increment of space.
Most common is dividing the remaining space proportional to the current size of each table (with some prescribed minimum). All methods will run out of space
only when there is absolutely no more. This may not be
desirable, though, since considerable time will be spent
trying to squeeze in the last item before overflow occurs.
lVlovable tables seem to work best for relatively small
memories, for machines in which internal speeds are fast
relative to 1-0 speeds, or for systems in which all available memory is allocated to the compiler at the start of
any compilation.
List structures are complicated by the necessity to
use relative links rather than absolute addresses and to
identify the table pointed to.

B lock allocation
Block allocation methods are the second most popular
storage management technique. In this case, tables are
not kept in contiguous locations, and information is
usually linked together. Each routine that may add data
to a table is responsible for requesting a block of suitable size (sometimes a system fixed size) for the purpose
at hand. Usually space is allocated in multiples of the
basic element size of the table at hand in order to avoid
calling the main allocator too often. Since OS/360 implements this form of allocation as a primitive in the
operating system, this form of allocation has been quite
widely used on that machine.
This technique does have the principal advantage
that since table segments are not moved after allocation, absolute pointers may be used in list structures.
It suffers from the drawback that storage fragmentation
can occur and may prevent usage of all available flemory.
Block allocation is suggested whenever memory is a
resource to be shared with other simultaneous users of
the machine in a multiprogramming environment. This
is because it is desirable to minimize the amount of

,,)

memory required at any given time, and most main
memory allocation algorithms supported by operating
systems do not guarantee that additional memory will
be allocated contiguously with previously allocated
memory.

IMPLEl\1:ENTATION TECHNIQUES
Early compilers were invariably written in assembly
language; most still are today. It was originally felt
that only assembly language could yield the efficiency
that was required in such a widely used program as a
compiler, and that the required operations were not well
supported by higher level languages. Although it has
now been generally recognized that very little of any
compiler needs to be "tightly coded" to achieve nearly
the same efficiency, the tradition of assembly coding is
dying a slow and painful death.
A second reason usually given for writing a compiler
in assembly language was to minimize the space that the
compiler required for its code. Factors of 1.5 to 3 have
been cited. With the growth of main memory sizes available, the almost universal availability of random access
secondary storage, and the common use of dynamic
loading techniques, the requirement for small code has
been considerably reduced in importance.
Advocates of coding in "higher level" languages have
not always been completely candid in their arguments
either. It is frequently stated that one of the main motives for using a higher level language is the gain in readability that occurs. Anyone who has tried to read a
compiler written in FORTRAN knows that this simply
is not the case. A much stronger case may be made for
PL/I or ALGOL. The fluidity of these languages plus
the natural benefits of block structuring generally result in code substantially more readable than assembly
code.
A major drawback to most higher level languages for
coding compilers is that the native data types manipulated in these languages are neither those required in
either lexical scanning, nor those required for table
management. Both of these are vitally important in
compiling, and result in the construction of subroutines,
frequently in assembly code, to support them. The linkage overhead in using these routines can be substantial.
By all odds, the most compelling reason for using a
higher level language is the conciseness with which code
can be written. The sheer laboriousness of assembly code
is a major obstacle to its use. One of the best measures of
the suitability of a language for a particular purpose is
the number of characters that must be written to achieve
the desired result. Since error rates in programming are
almost independent of the language being written, con-

6

Spring Joint Computer Conference, 1972

cise programs will have fewer bugs than verbose programs.

LDS (Load Stack), and is written as:
LDS
LDS

A

B

Pops
One approach that has gained a number of particularly ardent adherents is that of writing compilers in an
interpretive language. This idea seems also to have
originated in the early 1960's. Although the COBOL
compiler for the IBJVI 1410 was written in interpreted
code, the main source of the popularity was the series of
(mostly FORTRAN) compilers 'vrit~en by Digitek. A
number of syntax directed compilers of the same vintage
utilized an internal representation of a similar nature.
The increased suitability of current computer instruction sets for compiler writing has caused the technique
to largely fall from favor for large machine compilers in
recent years. The technique has much to recommend it
for some applications, though, and it is worthy of a few
comments.
Since there have been no published papers on the
Digitek POP system, which appears to be the most
highly developed system, we will include here a somewhat more complete description than for the other ideas
discussed in this paper.
The name POP derives from the Programmed OPerators on the SDS 910 for which the first Digitek FORTRAN compiler was written. These were a series of unassigned operation codes that caused a trap to a location distinct for each such op-code. This enabled the
user to define the meaning of each of these op-codes by
a subroutine. Subsequently, for other machines which
did not have such a feature, a completely interpretive
system was substituted.
The POP system consists of a set of operations that
resemble single address instructions. The single operand
in each POP is either a single data element (usually an
integer but perhaps a pointer into a table, etc.), a character, a string of characters (this is handled indirectly), a
table (movable), or a flag. Additional data types are
defined as needed. Tables are implemented as contiguous, movable tables as previously described. A pointer
is defined as having a table number part plus an offset
into a table. Pointers are used for forming linked structures and for referencing data in tables if other than the
last item is to be referenced. Tables are normally used
like stacks. One table is distinguished as the main stack
and is often used as an implicit second operand. Another
table is distinguished as the stack used to save return
addresses in procedure calls. Recursion is therefore quite
natural.
To illustrate how this system is used, we will define
several of the more common POP's. The first POP is

This sequence of two POP's is interpreted as follows:
the data item A, a single work item, perhaps an
mteger, is placed on the main stack, extending it by one
word in the process. Then the item B is added to the
stack, extending it once again. At the conclusion the
stack appears as in Figure 5. The end of stack it~m is
referred to as item 0 and the next item (A) is referred to
as item 1.
The POP STS (Store Stack) is simply the converse.
For instance:
STS
A
STS
B
~irst

stores the end item of the stack in cell A, and shortens
the stack. The second POP stores the new end item in
cell B and shortens it once again. The net effect of the
four POP's we executed is to exchange cells A and B.
Similarly, the stack may be loaded with the end item
on any table by MOF (Move Off) which has as an
operand a table number. The effect of this is to lengthen
the stack and to shorten the table specified as the
operand of the instruction by moving one word of data.
This operation is usually defined to set a global flag to
FALSE rather than to move an item if the table specified is empty. The companion operation is lVI0N (Move
On). Hence to move the contents of one table into
another, the four instruction loop suffices:
LA

MOF
BRT
lVION
BRU

TAB LEI
ALLDONE
TABLE2
LA

2
END OF STACK

A
B

Figure 5-Picture of end of stack

1

a

Appraisal of Computer Technology

The two new instructions above are BRT (Branch True)
and BRU (Branch Unconditional).
Character scanning is done with primitives of the
form
CRS
character
The POP CRS (Character Scan) has as its operand the
internal representation of a character. If the specified
character is the next in the character input stream, the
input scanning pointer is advanced and a global flag set
to TRUE. Otherwise the global flag is set to FALSE.
Similarly a complete string may be matched with SCN
(String Scan), as in
SCN

"BEGIN"

Subroutine calling is done with BRS (Branch and
Save) which stores the return address in a stack. The
natural implementation of recursion leads most POP
written compilers to be of the recursive descent variety.
For instance the sequence of code required to recognize
the syntax SU1VI :: = TERl\1 {+ TERl\/I }* is as simple
as
BRS
TERM
SUM
CRS
"+"
BRT
SUM
RET
The POP system is fleshed out with instructions for
packing and unpacking data words, creating instructions, setting and testing flags, and so on almost ad
infinitum. In theory, a POP compiler can be moved
from one machine to another simply by writing a new
interpreter for the next machine. In practice, this is not
feasible because the bulk of the work in writing a compiler is in designing the code generation strategy, which
must be rethought for any new machine in any event.
POP compilers are considerably more compact in
code than machine coded compilers, especially where
there is an addressability problem (such as in a minicomputer). Fortunately this is the place that compactness is needed most. POP written compilers are, however, slower than machine coded compilers not only because of the interpretive overhead, but also because of
the redundant work done in moving data through the
stack. This problem is masked in minicomputers since
their computing power is very high relative to input
output speeds of paper tape and teletypes.
The synopsis is that POPs are a fairly good way to
write very small compilers for minicomputers and a
poor way to write compilers for large machines.

7

at least some mention. The idea of using a TWS is very
appealing, but in practice the use of TWS has not proven
much of a boon. The reason is quite simple. To date,
TWS has done a good job of lexical scan, parsing, and
the dictionary parts of a compiler, but has made few
inroads into the most difficult parts, namely code generation and optimization. Even if the facilities provided
by a TWS are valuable, the penalty of forcing a user
into a prescribed mold has been too stiff for most production compiler writers to bear.
CODE GENERATION
Code generation has traditionally been one of the
most ad hoc (and bug-ridden) parts of any compiler.
There is some evidence, though, that this is changing
rather rapidly. Formally, the generation of code is the
attaching of semantics to specific syntactic structures.
In the case of immediate generation, of course, opportunities for substantially altering the source order
are minimal and conversion of the parse back into sequences of instructions proceeds strictly on a local basis.
The actual generation of code is accomplished either by
open sequences of code that construct the required instructions or by the equivalent of macro sequences
selected by combination of the operator and the associated operand types. In the latter case, the macros
are usually described in a format similar to the assembly
language of the target machine. Conditional features
similar to conditional features in macro assemblers are
used to improve on the quality of code generated. Provision is normally made to test the state of the target
machine as well as supplementary information about
the operands. The macros also update the state of the
target machine.
In multipass compilers, there is now a move to systematize code generation by formal tree transformations so that all data conversions, register loadings, and
the like, are explicitly recognized in the tree structure.
Most of the current work in formal semantics is along
this line. Information may be collected during tree
traversals which aids considerably in the production of
high quality code.
Whether the code is produced by conventional or
table driven techniques is far less important that the
organization of the generation as a sequence of transformations rather than as a complex series of decisions
based upon global data left as side effects of prior generation.

Translator writing systems

OPTIMIZATION

As an implementation technique, the use of one of
the many extant Translator Writing Systems deserves

One of the most important differences between production compilers and experimental compilers is that

8

Spring Joint Computer Conference, 1972

most production compilers try much harder to generate
high quality code even at the expense of considerably
slower compiling. This tradition dates from the very
first FORTRAN compiler. At that time, it was felt
necessary to compete with hand generated code in
quality in order to gain acceptance. Since that time
much effort has gone into finding ways to improve the
quality of code generated by compilers. Unfortunately,
the matter is too tightly bound up with the specifics of
the language at hand. FORTRAN, for example, is relatively easy to optimize. PL/I, on the other hand, is
almost impossible due to the significance of side-effects
in the language. If, of course, optimization information
is supplied by the programmer (which is rarely done),
the problem becomes more nearly like that of FORTRAN.
After carefully sifting through all of the forms of
optimization that have been used however, there are
only two areas Qf optimization that have sufficient payoff to warrant consideration, unless super-optimization
is being attempted. That is, there are only two issues in
addition to strictly local improvements in generated
sequences. These two areas are register assignment and
address calculation.

Optimal register assignment
Also dating back to the earliest compilers is the problem of optimal assignment of the registers available in
the machine. If a computer has only one register of a
given class, or a very large number, the problem is
minimal or does not exist. However, for common
machines with 3 to 16 registers in a register class, the
advantage to finding the correct data items to maintain
in registers can be substantial. This is particularly true
of values used for array accessing. Although there have
been numerous papers on this subject, the general problem is still unsolved. Even the most satisfactory approaches require an excessive amount of computation
to find an optimal solution.
The consequence of this dilemma, is that most compilers that do not do flow analysis usually simplify the
problem by merely keeping a simple record of register
contents. Loads and stores are then done on a strictly
local basis. This works quite satisfactorily for all except
the most demanding requirements.

A ddress calculation
One of the most important forms of non-trivial optimization and one that requires at least a modicum of
flow analysis is the calculation of subscripts within a

loop by repeated addition of some precalculated value
to an address rather than a full recalculation of the address. This is best shown by the simple loop:
DO

K = 2T099;

A(I, J, K) = A(I, J, K +1) + A(I,J, K - 1);
END;
The address calculations required can be drastically reduced with only two observations. First, all three array
addresses are related to each other with only a constant
difference. Second, consecutive executions of the loop
body require only that the address be adjusted by a
constant amount. The first of these simplifications is
called common subexpression elimination. The second
is called recursive address calculation. (It has nothing
to do with recursion in the programming sense. Here it
is really an iteration.)
Gear4 reports on a reasonably straightforward way of
accomplishing this by consecutive passes over the parsed
program in alternating directions. Although his technique is applicable without alteration only to explicit
loops in the program with no local branching to disturb
the movement of code, with more extensive flow analysis
this can be generally accomplished.
Although common subexpressions other than subscript expressions can be located and moved, the benefits are not impressive and there are perils. The necessity
of avoidance of altering the side effects of the evaluation
is often underestimated. For this reason, more general
common sub expression detection is not often done.
Since programs that do considerable accessing of
multidimensional arrays spend a large part of the time
in address calculation, locating common index expressions and calculating addresses recursively in loops is
recommended as one of the first targets in any compiler
intended to produce very high quality code.

SUMMARY
This has been intended as a brief overview of the way
in which production compilers are written at the present
time as seen by one of the practitioners of the art. The
word art is used here as little has been accomplished in
applying engineering techniques to compiler writing
outside of the areas of lexical and syntactic analysis.
The parts associated with declaration processing and
code generation and optimization are still very ad hoc.
The need for researchers to find better descriptive devices for generation strategies and the miscellaneous
problems surrounding the creation of real object programs is still great. The need for compiler writers to

Appraisal of Computer Technology

apply the best that is already known is perhaps even
greater.

REFERENCES
1 D GRIES
Compiler construction for digital computers
John Wiley 1971
2 R W FLOYD

Syntactic analysis and operator precedence
Journal of the ACM July 1963 p 316 Vol 10
3 W R McKEEMAN J J HORNING
DB WORTMAN
A compiler generator
Prentice Hall 1970
4 C W GEAR
High speed compilation of efficient object code
Communications of the ACM August 1965 P 483 Vol 8

9

A laboratory for the study of
automating programming*
by T. E. CHEATHAM, JR. and BEN WEGBREIT
Harvard University
Cambridge, Massachusetts

INTRODUCTION

Weare concerned with facilities at a "higher level":
translating specifications which contain much less commitment to particular data and algorithmic representations than is usual with higher level programming languages, and performing rather more drastic reorganization of representation, implied computational steps, and
even implied method of computation than is done with
traditional compilers. We imagine our end product to
be programs in a higher level language. On the other
hand, we must note that the line between the kind of
facility we will describe and a good compiler is very fine
indeed and we will suggest that certain kinds of transformations sometimes made by conventional compilers
might better be approached with the tools and techniques described here.
The purpose of this paper is to describe a facility
which we characterize as a laboratory for the study of
automating programming. We view the laboratory as a
pilot model of a facility for practical production programming. The time and expense invested in programming today and the lack of confidence that most programs today actually do what they are intended to do
in all cases is surely dramatic evidence of the value of
such a facility. The need is particularly acute when the
task to be accomplished is complex and the resulting
program is necessarily large. Such situations are precisely those encountered in many research areas of computer science as well as in many production systems software projects. Dealing with this kind of complexity,
which is to say producing efficient verifiably correct
program systems satisfying complex requirements is a
significant, decidedly non-trivial problem.
The second section of this paper contains a critical
discussion of a wide variety of work and research areas
which are related; the third section is devoted to a
broad general description of the laboratory; the fourth
section then briefly describes the ECL programming
system, the intended host for the laboratory; the fifth

We are concerned in this paper with facilities, tools, and
techniques for automating programming and thus we
had best commence with discussing what we mean by
programming. Given a precise specification of some task
to be accomplished or some abstract object to be constructed, programming is the activity of producing an
algorithm or procedure-a program-capable of performing the task or constructing a representation of the
object on some computing system. The initial specifications and the resulting program are both couched in
some (programming) language-perhaps the same
language. The process typically involves such activities
as: choosing efficient representations for data and algorithms, taking advantage of known or deduced constraints on data and algorithms to permit more efficient
computations, verifying (proving) that the task will be
accomplished or that the object constructed is, in fact,
the one desired, demonstrating that certain performance
criteria are met, and so on.
The kind of facility currently available which might
be characterized as contributing to automating programming is usually called a compiler. It typically translates an algorithm from some higher level (programming) language to a lower level ("machine") language,
attempting to utilize memory and instruction resources
effectively and, perhaps, reorganizing the computational
steps, as implied by the higher level language representation, to move invariant computations out of loops,
check most likely (or cheapest) arms of conditions first,
and so on.
Weare not here concerned with traditional compilers;
indeed, we will assume the existence of a good compiler.

* This work was supported in part by the Advanced Research
Projects Agency under contract F-19628-68-C-0379 and by the
U.S. Air Force Electronics Systems Division under contract
F19628-71-6-0173.
11

12

Spring Joint Computer Conference, 1972

section discusses, in general terms, a variety of program
au tomation techniques to be employed; the sixth section
describes the basic components of the initial laboratory ;
and the seventh section summarizes what we hope to
accomplish with the laboratory and mentions several
open problems.

RELATED WORK
There is a considerable body of work and a number of
current research areas which are related to programming automation. lVlost of this work does not, at present,
provide anything like a complete system; much of it
does provide components of a system for automating programming and is thus directly related to and sometimes
directly usable in the laboratory we will describe.
We have divided the work to be discussed into seven
different areas: automatic program synthesis, mechanical theorem proving, automatic program verification,
program proof techniques, higher level programming
languages, equivalence of program schemata, and system measurement techniques. In each case we are discussing the "vork of several people; the bibliography cites
the recent work we feel is most relevant.

A utomatic program synthesis
The basic idea here is to construct a program to produce certain specified outputs from some specified inputs, given predicates asserted true of the inputs and
the outputs as related to the inputs. The basic technique
is to (mechanically) prove the theorem that there exist
outputs satisfying the predicate and then to extract a
program from the proof for constructing the outputs.
It has been suggested that these techniques can also be
utilized to transform programs, for example to transform a recursive procedure into an equivalent iterative
procedure using the two stage process of first deducing a
predicate that characterizes the recursive procedure and
then synthesizing an equivalent iterative procedure
which computes the outputs satisfying the predicate
deduced.
We view the work in this area to date as primarily of
theoretical interest and contributing to better mechanical theorem proving and proof analysis techniques. It
is often more convenient to produce an (inefficient)
algorithm than it is to produce a predicate; the two
stage process proposed for "improvement" of programs
is awkward and, we believe, highly inefficient as compared with the direct transformation techniques to be
discussed below.

111echanical theorem proving
The heart of any system for automating programming will be a facility for mechanical theorem proving.
At the present time there are two basically different approaches to mechanical theorem proving and a realization of both these approaches provide important components of our laboratory. One approach is to construct
a theorem prover which will, given enough resources,
prove any true theorem in the first order predicate calculus with un interpreted constants; the other approach
is to provide a theorem prover which is subject to considerable control (i.e., allO\vs one to employ heuristics
to control the strategy of proof) and which utilizes interpretations of the constants wherever possible for
efficiency. l\Iechanical theorem provers of the first sort
are now usually based on the resolution principle. We
term those of the second sort "programmable theorem
provers".
Resolution theorelll provers

Robinson's 1965 paper introducing the resolution
principle has been followed by vigorous activity in
implementing mechanical theorem provers based on this
principle. lVluch of the activity has been concerned with
developing strategies for ordering consideration of
resolvents; at the present time the breadth-first, unitpreference, and set-of-support general strategies have
been studied and other variations are being considered.
It is clear that a powerful resolution-principle based
theorem prover will be an important component of the
laboratory.
Prograllllllable theorelll provers

In the PLANNER system, Hewitt provides a facility
for programmable theorem proving in the sense that one
can very easily utilize interpretations of the objects and
operations entering into a theorem to control the
strategy of proof, one can make the choice of technique
used in any particular instance data dependent, and can
very readily employ any general mechanical theorem
prover, effectively as a subroutine. The use of a small
subset of Hewitt's proposed facilities by Winograd
(called micro-planner by him; see [Winograd 71], [Sussman 70]) in his program for understanding natural language gives dramatic evidence of the effectiveness of
the approach. We thus include a programmable theorem
prover on the style of Hewitt's and Winograd's as the
basis for the theorem proving component of our laboratory.

Laboratory for Study of Automating Programming

A utomatic program verification

The work in this area is concerned with mechanization of what we term "flow chart induction". Given a
representation of some algorithm as a flow chart with assignments, conditional branching, and looping, one appends to the boxes of the flow chart predicates asserted
true of the variables at various points in the computation and, in particular, of the inputs and the outputs.
The procedure is then to attempt to mechanically demonstrate that the whole is consistent and thus that the
program is correct.
Again, we view this work as primarily of theoretical
interest. The theorem proving techniques utilized in
King's system (see [King]) are particularly interesting,
however, as they utilize interpretations of the integers
and operations over the integers; while not general,
they do provide rather more efficient methods for proofs
concerning integers than is presently possible with the
more general resolution-type proof methods which do
not employ interpretations.
Program proof techniques

A number of workers have been concerned with developing proof techniques which are adapted to obtaining proofs of various properties of programs. These include some new induction methods-structural induction and flow chart induction-simulation techniques,
and so on. This work provides a very important basis
for proving the equivalence of various programs.
Higher Level Programming Languages

A considerable amount of work in the development of
higher level programming languages has been concerned
with providing languages which are particularly appropriate for certain application areas in the sense that
they free the programmer from having to concern himself with the kind of detail which is not relevant to the
application area in which he works. For example, APL
permits a programmer to deal with arrays and array
operations and relieves him of concern with the details
of allocation, accessing, and indexing of the array elements. SNOBOL 4 directly supports algorithms which
require back tracking, providing the mechanics automati cally and permitting one to write theorem-proving,
non-deterministic parsing, and such like algorithms very
easily. SETL provides general finite sets as basic data
objects plus the usual array of mathematical operations
and predicates on sets; it thus permits one to utilize
quite succinct statements of a wide variety of mathe-

13

mati cal algorithms and to considerably ease the problem
of proving that the algorithms have certain properties.
EeL (which we discuss in some detail in a later section)
provides a complete programming system with facilities
which permit one to construct extended language facilities such as those provided in APL, SNOBOL 4, and
SETL, and to carefully provide for efficient data representation and machine algorithms to host these extended
language facilities.
Equivalence of program schemata

There has been considerable interest recently in
studying various program schemata and investigating
their relative power, developing techniques for proving
their equivalence, and so on. Most of the work to date
is interpretation independent and while, for example,
many transformations from recursive specification to
iterative specification of algorithms have been developed, it is clear that many practical transformations
cannot be done without employing interpretations.
The most common use of interpretation dependent
transformations is in "highly optimizing" compilers.
There, a very specific, usually ad hoc set of transformations is employed to gain efficiency. Often the transformations are too ad hoc-under certain conditions they
do not preserve functionality (i.e., don't work correctly).
System performance measurement techniques

It is a quite straightforward matter to arrange for
various probes, monitors, and the like to permit measurements of the performance of programs, presuming
that appropriate test input data sets are available, and
a considerable amount of work has been done in this
area. However, there are two further areas which are
now the subject of investigation which we feel may yield
important components for our laboratory. These are
mathematical analysis of algorithms and automatic
generation of probability distributions for interesting
system parameters.
Mathematical analysis of algorithms

Several people have been working recently in the
area of developing methodology and techniques for the
mathematical analysis of algorithms to obtain estimates
and/ or bounds on certain critical parameters and for
developing (and proving) optimal algorithms for certain
functions. We envision the manipulation facilities of the
laboratory as being readily adaptable to providing

14

Spring Joint Computer Conference, 1972

mechanical assistance in this activity, particularly in
the area of aiding in the inevitable symbolic algebraic
manipulation required in carrying out a mathematical
analysis.
AutoDlatic synthesis of probability
distribu tions

Some recent work by Nemeth (see [Nemeth]) may,
when it is developed further, provide an interesting and
valuable component of the laboratory. What he is trying
to do is to develop algorithms for mechanically generating probability distributions for various parameters
from a computational schema augmented by given
probability distributions for input variables and functions employed. Use of techniques like his should prove
far superior to actually carrying· out the computation
for sample data values. A mixture of mechanical generation of distributions and carrying out portions of a
computation might, in the earlier stages, provide a
practical tool.
All the above work is related and relevant to automating programming, but none, in our opinion, is adequate alone. The need .now is to integrate these facilities, techniques, and so on into a system-a laboratory
for the study of automating programming.
THE APPROACH TO BE TAKEN IN THE
LABORATORY
The goal of such a laboratory is a practical, running
system that will be a significant aid to the construction
of real-world programs. Automating programming entails transferring to the computer those facets of
programming which are not carried out efficiently by
humans. It is our contention that the activity most in
need of such transfer is the optimization (in a very broad
sense of the word) of programs. The orientation of the
laboratory and the principal task to which it will be put
is that of taking an existing program and improving
upon it.
That optimization is, indeed, a key problem requires
little defense. If "program" is taken in a sufficiently
broad sense, it is easy to produce some algorithm which
performs any stated task. Given just the right language,
program synthesis is seldom a significant issue. For
many problems, the most natural task description is
precisely a program in an appropriate notation. The use
of an extensible language makes straightforward the
definition of such notation. For other problems, it may
be that a predicate to be satisfied is a better task statement, but this too is in some sense a program. The line
between procedural and non-procedural languages is

fuzzy at best and it may be erased entirely by the use
of theorem-proving techniques to transform predicates
into programs (and conversely).
As we see the problem, the issue is not arriving at a
program, but arriving at a good one. In most cases,
programs obtained from theorem provers applied to
predicates, from a rough-cut program written as a task
description, or even from the hands of a good programmer leave much to be desired. Often, the initial program
is several orders of magnitude away from desired or
even acceptable behavior. The larger the program, the
more likely this is to be the case. The reasons are generally such defects as inefficient representation of data,
failure to exploit possible constraints, use of inefficient
or inappropriate control structures, redundant or partially redundant computations, inefficient search strategies, and failure to exploit features of the intended host
environment. Recognizing the occurrence of such defects
and remedying them is the primary goal of the laboratory.
ECL AS A BASIS FOR THE LABORATORY
The ECL programming system and the ELI language
have been designed to allow rapid construction of large
complex programs, perhaps followed by modification
and contraction of the programs to gain efficiency. The
facilities of ECL permit one to compose, execute, compile and debug programs interactively. The ELI language is an extensible language with facilities for extension on three axes: syntax, data, and operations.
The ELI language plays four roles in the laboratory:
(1) it is the language used to construct the various components of the system; (2) it and its extensions are the
language used to state algorithms which are to be
manipulated by the system; (3) it is the target language
for transformations (i.e., ELI programs are transformed
into better ELl programs); and (4) it is the host language for the theorems constituting the data base. *
The features of ELI and its host system, EeL, which
are particularly relevant to the laboratory are the following:
(a) Data types (called "modes" in ELl) can be programmer defined usi~g several basic data types
(e.g., integers, reals, characters, etc.) and, recursively, several mode valued functions (e.g.,
construction of homogeneous sequences, nonhomogeneous sequences, pointers, etc.).

* That is, the parts of a theorem (i.e., the conditions, antecedent,
consequent, and recommendation list as described in the following
section) are couched in an extension of ELl and "glued together"
as an ELl procedure by operators defined as extensions; of
course, the theorems are not "executed" in the usual sense.

Laboratory for Study of Automating Programming

(b) Procedures can be generic in the sense that a
given procedure (say that for +) can have a
number of different bodies or meanings and the
selection of a particular body or meaning to be
used is determined by the mode(s) of the argument(s) utilized in some call of the procedure.
Thus, for example, it is particularly straightforward to accommodate refinements in representation of some general data type (e.g., sets) without doing violence to algorithms defined on it by
associating a new mode with a refinement and
defining new versions of operators particularized
to that mode via the generic mechanism.
(c) The compile-time, load-time, run-time, and the
like kinds of restrictions employed in most systems are not present in EeL. In particular, the
EeL compiler is a program which can be called
at any time; it is given a program to be compiled
and a list of variables (free in that program)
whose values are to be taken as fixed. It then
converts the program to a form which takes advantage of whatever efficiencies it can from the
freezing of values. There is no distinction between compiled code and non-compiled (interpretive) code insofar as their discernible effect when
executed.
(d) EeL provides storage allocation and reclamation
mechanisms which are quite sensitive to spacej
time efficiencies. Thus, the so-called "data compiler" goes to some lengths to utilize memory
efficiently when allocating a component of a
complex data structure containing several
"pieces" .
The use of both "stack" and "heap" mechanisms
for allocation and freeing of space is also provided.
(e) EeL provides for multiple concurrent paths and
permits complete user control over the environment for each concurrent path. In addition to
permitting strategies such as employing, say, a
general resolution theorem prover to be applied
to some difficult theorem in parallel with other
undertakings, this feature makes it particularly
straightforward to set up and run some program
in an environment of ones choosing; for example,
to gather statistics on its behavior in some
simulated "real" environment.
(f) Error conditions (both system detected and
those defined by user programs) are generally
handled by setting interrupts and each interrupt
is, optionally, handled by a user defined procedure. This feature is very helpful in test execution and evaluation of subject programs and permits construction of elaborate control mecha-

15

nisms when appropriate, as might be the case in
controlling the behavior of the programmable
theorem prover.
There are two extensions of EeL which provide particularly convenient linguistic facilities for stating algorithms; these are an extension which permits one to
deal with sets and set operations* and an extension
which hosts non-deterministic programs.
OPERATION OF THE INITIAL LABORATORY
The laboratory, like EeL, is intended for interactive
use. A programmer approaches it with a problem
specification and a set of requirements on how the
program is to perform. He and the system together
undertake to produce a program which meets the
specifications and requirements. The intention is tha~
the laboratory be a practical tool for everyday use, i.e.,
that hard, real-world problems with realistic performance requirements be brought to and handled by the
laboratory.
The problem specification may be an existing program
written in ELI, possibly a long-standing production
program. In this case, the presumption is that its performance falls short of that required and that the concern is with automating its tuning. Alternatively, the
specification may be an ELI program written in a very
liberal extension and constructed solely as a concise
algorithmic statement of the problem task. There may
be little expectation that such a program will meet any
non-trivial performance requirements. Significant improvements may be needed even to reach the desired
order of magnitude. Finally, the problem specification
may be a set of predicates to be satisfied. Here the
laboratory begins by constructing an initial ELI program using as its target an extension set' designed for
this purpose. Again, such a program may be several
orders of magnitude removed from acceptable performance.
In very general terms, the laboratory is a manmachine system for transforming the initial program to
an equivalent one which meets the stated requirements.
The heart of the system is a set of transformations, actually theorems concerning the language, which preserve functionality while improving the program. Deciding whether an arbitrary transformation either preserves functionality or improves the program is, of
course, impossible, but decision procedures for the gen-

* This extension permits us to capture most of the facilities
proposed for the language SETL. See [Schwartz 70] for a particularly cogent argument for providing sets and set operations in a
higher-level programming language.

16

Spring Joint Computer Conference, 1972

eral case are not needed here. The laboratory will employ specific transformations which under appropriate
circumstances-i.e., when their enabling predicates
hold-maintain program equivalence. Constructing
these transformations and verifying that the validity of
the enabling predicates do insure functionality will be a
task assigned to humans who may, of course utilize the
facilities of the laboratory to prove the validity. While
the functionality of the transformations may be assured,
such is not the case for their effectiveness. To obtain a
sufficiently powerful set of transformations it is necessary to include many whose utility is conditional, e.g.,
those which are effective only under circumstances
which are difficult or impossible to verify analytically,
or those which optimize performance in one metric at
thB(perhaps unacceptable) expense of another. In general, the transformation set will include transformations
which are mutually exclusive (i.e., only one of some subset can be applied) and some which are inverses (i.e.,
applying two or more repeatedly will lead to a loop).
Hence, choice of which transformations to apply is
governed specifically by the performance requirements
demanded of the program and the disparity between
these and the program at each state of optimization.
Determining program performance is a crucial issue.
There are two basic approaches, both of which are used
in the laboratory. The first is analytic. The system derives closed-form expressions for program behavior
based entirely on a static inspection of program structure and interpretation of the program operations. Then
given a description of an input data set, e.g., as a set of
probability distributions for possible input valnes, the
system can describe the exact program behavior. W'henever such closed form expressions can be obtained, this
is clearly the best certification of program performance.
However, at present our analytical techniques are too
weak for any but the simplest programs. The second approach is that of actually running the program on
benchmark data sets, data sets provided by the programmer as part of his performance specifications. Between these two extremes lies the spectrum of simulation: those portions of the program which can be treated
analytically are replaced by simulation blocks and the
rest of the program is run as is. The large area of mixed
strategy is particularly powerful since it allows one to
use only partially representative benchmark data sets
yet extrapolate meaningful results from them by the
use of analytical techniques.
The utility of the laboratory will be governed principally by the specificity of admissible performance
specifications and the degree to which they can be met
on the intended machine. Performance specifications
include the obvious bounds on execution time and

space. Alternatively, they might be cast in the form:
as fast or as small as possible. This is, however, only a
rough cut. Few problems and fewer host machines are
entirely homogeneous. In real time situations, optimizing total execution time may be far less important then
attaining a certain minimum for particular sections.
Similarly, the total space occupied by a program and
its data is far less important than the distribution of this
space over several storage devices of various capacities
and access speeds. Also, the intended host machine may
be a multiprocessor or provide multiprocessing capabilities by means of special processors (e.g., graphics) or
remote processors (e.g., a network). Partitioning the
computation among the various processors so that the
computation load on each is beneath prescribed limits
is another task of the laboratory.
The possible transformations for obtaining the desired
performance vary considerably in scope, power, and effectiveness. A sketch of those which currently seem to
have the greatest payoff may give the flavor of what
may be accomplished.
The most straightforward are those for reducing the
space occupied by data. Any field containing literal
data restricted to N possible values requires, of course,
no more than [10g2N] bits. What may not be quite so
obvious is that with an appropriate programming language, simply changing declarations is all that is required to control the storage allocated, perform the coding and uncoding on data access, and handle the necessary conversions. ELI is such a language; hence, the
class of transformations is readily obtained. In the case
of sequences of literal data fields (e.g., character strings),
further compression can be obtained by block encoding.
Relations can be represented in a variety of ways and
changing from one to another often results in significant
economics. Sparcely populated arrays can be changed
to lists or hash tables in which the array indices are retrieval keys. Conversely, the space occupied by pointers
(e.g., in list structure) can be reduced if linked lists are
replaced by arrays in which relations are represented by
small integer array indices occupying only a few bits.
One candidate for optimization of both time and space
is sets and set operations. There are a number of particularly efficient representations for sets applicable
only under certain conditions (e.g., bit vectors when the
number of elements is fixed and relatively small or lists
in canonical set order when the generation of new sets is
carefully controlled) or efficient only when the set operations are circumscribed (e.g., hash tables when the
operations' are union and intersection but not set complement). When such a representation is possible, its
use will often produce dramatic improvement over
standard list structure techniques.

Laboratory for Study of Automating Programming

Transformations for optimizing time are often subtle
and require sophisticated techniques for manipulating
program structures. Perhaps the best understood sort is
the transformation of recursive to iterative programs.
Even restricting attention to uninterpreted schemas,
there are several interesting schema classes for which
the transformation can always be carried out. By adjoining additional transformations which exploit the
properties of specific common program operations, a
very powerful tool for eliminating program recursion
may be obtained.
Time can always be saved at the expense of space by
substituting the definition of a routine for a call on it.
Where recursion is absent or has been previously removed, it is possible to perform repeated back substitution until all calls have been eliminated. While too costly
in space to be employed everywhere, it is very effective
if performed on the most frequently executed portions
of the program. Aside from the obvious virtue of eliminating the expense of function call, it has the more significant virtue of allowing each back substituted defining instance to be optimized independently-in the
context of the text into which it is placed.
The principal class of time optimizations is the elimination of searches. A few such transformations are simple, e.g., the replacement of association lists by hashed
structures or balanced trees, and the substitution of arrays for lists which are frequently accessed by indexing.
Searching is, however, not confined to .lists. Structures
of all sorts-arrays, queues, strings, and so on-are
frequently searched for an element or set of elements
having some property. When the density of hits is small,
blind search is inefficient. An appropriate method is to
adj oin bookkeeping records to the given structure and
add bookkeeping code to the program so as to keep track
of what would be the result of searching. When the incremental costs of maintaining the necessary records is
small compared to the search cost, this often provides a
significant optimization. Determining what records
must be kept and how to keep them are non-trivial problems, but ones which appear open to solution at least
for many significant program classes.
A related class of program optimizations is based on
reordering computations in operations on compound
structures. Any operation on a compound object must
be defined in terms of primitive operations or its primitive components. Given a sequence of operations on
compound objects, it is usually possible to reorder the
underlying sequence of primitive operations to reduce
some computational resources. Galler and Perlis (see
[Galler 1970]) discuss in detail the problem of saving the
storage required for temporaries in matrix operations
and mention that a variation on their technique can be

17

used to minimize time. It appears possible to generalize
these results to arbitrary data structures. First, recursion is eliminated from function definitions. Then each
compound operator is replaced by its definition until
only primitive operators appear (i.e., the back substitution optimization mentioned above). Then, program
loops are merged to carry as many operations as possible
on each loop. Finally, dependency analysis is used to
find common sub-expressions and eliminated unnecessary temporaries. Any number of ad hoc, type dependent, transformations can be added to this basic
framework. The basic technique, that of unwinding
compound operations and then winding them up again
in a more optional fashion, is broadly applicable.
Several sets of transformations are concerned with
effective utilization of the particular host machine(s).
These are therefore specific to the environment, but no
less important than their general cousins. The most
important is that of partitioning the computation
among several processors. In so doing, the first step is
to take a conventional sequential program and transform it to a representation which exhibits all the potential parallelism so that sequencing is dictated only by
data dependency. The next step is to partition the transformed program among the available processors in such
fashion that (1) upper bounds on computational resources demanded of each machine are obeyed; (2)
communication between processors is carried out satisfactorily along the available data paths and (3) the entire configuration has the desired performance characteristics. Item (2) can be reduced to item (1) by treating each data path as a processor with its own (perhaps
small) computational bounds. Item (1) is, of course, the
heart of the matter. The work of Holt, Saint, and
Shapiro provides a very promising approach to this and
has already demonstrated some success in certain restricted applications (see [Shapiro 69]).
This set of program transformations is only representative. Others will be added in time as users of the
laboratory gain practical experience with and understanding of program transformation. However large
such a collection, it is only a beginning and its exact
composition is only a secondary issue. lVlore important
is the problem of determining which transformations to
use and where, given a program and a set of performance
specifications. The first step is to refine the performance measurements so as to determine precisely where
the specifications are not being met.· Correlating the
various measurements with program text is straightforward.
Given the program text augmented with resource
utilization statistics, the next task of the laboratory is
to find places in need of optimization, find one or more

18

Spring Joint Computer Conference, 1972

appropriate transformations, verify whether they are
applicable and apply them. In choosing places to concentrate attention the laboratory starts simply by looking
for the areas with the largest cost relative to that desired. Given these obvious starting places, the key problem is tracing back from these when necessary to the
causes, perhaps at some point far removed in the program. In this step, and in the choice of transformation
classes to be attempted, there will be the opportunity
for explicit guidance by the programmer. If no guidance
is given, the laboratory will doggedly pursue possible
hypotheses but the search may be cut dramatically by
human intervention.
Even with this assistance, the proposed transformations must be taken as tentative hypotheses to be explored. Few transformations always result in improvement. Many optimize one resource at the expense of
others, while some transformations are of use only for
certain regions of the data space. Hence, in general, it is
necessary to continually verify that the transformed
versions of the program are indeed improvements.
Again, program analysis coupled with performance
measurement tools will be employed.
In summary, the principal functions of the laboratory
are choosing areas of the program to be optimized, carrying out pattern matching to'determine the applicability
of various transformations, performing these transformations, and arranging for explicit· guidance by the
programmer in this process. The laboratory consists of
a set of components for carrying out these activities in
concert.
COMPONENTS OF THE INITIAL LABORATORY
As we noted previously the laboratory is, essentially, one particular extension of ECL and· that the
internal representation for programs and data employed
in ECL will be utilized for programs being manipulated
(synthesized, transformed, proved to have some property, and so on). Here we will describe the several components in the initial laboratory-the several ELI
programs and/or ECL extensions which together constitute the initial laboratory. Before launching into the
discussion, however, we want to note the influence of
the work of Hewitt and Winograd on ours; the basic
components of the laboratory have very much the flavor
of the linguistic-independent components of Winograd's
version of Hewitt's PLANNER system. Our discussion
of the components is quite brief as our intention in this
paper is to provide an overview of the laboratory and
the general approach being taken. A detailed discussion
of the current versions of the components is provided in
a paper by Spitzen (see [Spitzen 71]).

Control

There is a top-level control path* which provides the
interface between the user and the laboratory. It provides for input of the program to be manipulated and
the associated performance criteria, if any. It then arranges that the program to be manipulated is put into a
canonical form and sets up a parallel path which provides the manipulation strategy by calling for the appropriate theorem or theorems to be applied. The control path then provides for dialogue between the system
and the user so that the system can request information from the user (e.g., verification that certain constraints hold in general, test data, and the like).
Programmable theorem prover

A "theorem" in the sense this term is used in the system consists of a condition which governs the applicability of the theorem, an antecedent, a consequent,
and a recommendation list. Given some program structure, an instance of substructure matching the antecedent can be replaced by an equivalent substructure
corresponding to the consequence so long as the condition holds. The recommendation list is basically a list of
predicates which govern the use of other theorems to be
used in manipulating the structure to match the antecedent in applying this one and it is the careful use of
this "governor" which permits the theorem proving to
operate in a practicable time frame. Note that in a very
strong sense theorems are really programs effecting
transformations which, through the conditions and
recommendation lists (arbitrary ELI predicates), can
establish elaborate control and communication arrangements.
Data base

The theorems which constitute the basis for the transformations and manipulations performed by the system
are housed in a data base. There is a continually growing static component of the data base which includes
the "standard" theorems. In addition there may be a
collection of theorems appropriate to certain particular
investigations with which we will augment the data base
at appropriate times. There is also a dynamic component
which varies as a program is being manipulated. For example, If we commence dealing with the arm "p2~e2"

* ECL provides multiprogramming; "path" is the ECL terminology for a parallel path of control.
~

Laboratory for Study of Automating Programming

of the conditional expression

[pf=:::}el; p2=}e2; . . .; pn=}en]
Then we would add the theorem appropriate to "--, PI"
to the data base and arrange that it be removed when
we get to the stage of treating the conditional expression as a whole in "higher level" manipulation of the
program structure containing it.
The data base is quite large and, as various new
facilities are added to the system, the data base will
grow. Its size plus the fact that one wants to be able to
select appropriate theorems (i.e., in accordance with a
given recommendation list) from the data base efficiently, make it imperative that a certain amount of
structure be imposed on the data base. Initially this
structure basically amounts to a collection of "threads"
through the data base, implemented by a combination
of list structure, hash, and descriptor coding techniques.
It is anticipated that getting an efficient structuring of
the data base as it grows will pose a non-trivial research
problem which we anticipate being attacked with the
tools provided by the laboratory itself.

19

Measurement techniques
In addition to the usual facilities for inserting probes
to provide measures of utilization of various functions
and data elements provided in EeL and the usual
ability to obtain measurements by sampling driven by a
real-time clock there are two measurement components
in the system which are less usual. Precise delineation
of potential inefficiencies sometimes requires very exact
timing data. Unfortunately it is usually impossible to
get very fine-grained timing from most contemporary
machines. Hence, the laboratory includes a machine
language simulator for its host machine, i.e., a program
which executes machine code interpretively and gathers
statistics as requested. This permits programs to be
run unchanged while collecting very precise data on
the distribution of program execution time and storage
requirements. This data, combined with that obtained
by inserting measurement probes into the program
permits performance measurements to be made to any
level of detail. The second measurement component is
an implementation of the "probability distribution
computer" described by Nemeth.

Pattern Matcher
The process of applying some theorem to some program structure involves matching the parts of the
antecedent to acceptable corresponding parts of the
structure; in general, of course, this will involve calls on
other theorems to manipulate the structure into an
appropriate format and/or the verification that certain
conditions maintain. It is the pattern matcher which
administers this activity; it will make tentative partpart matches, reject matches or attempt them in new
ways when subsequent failure to match occurs, and
so on.

Backtracking mechanism
The pattern matcher operates as a non-deterministic
program in the sense that it makes provisional matches
which must be "unmatched" and rematched when
failure occurs to match some subsequent part of the
antecedent to the program structure being manipulated.
A backtracking mechanism must therefore be provided
so that the effects of computations and variable bindings
can be "undone." The method we use to accomplish
this is to alter the basic ELI evaluator so that, when
backtrackable code segments are executed, any change
to the environment is preceded by recording the appropriate modification to the environment which will undo
the change in the event backtracking is required.

GOALS OF THE LABORATORY
It must be stressed that the laboratory is intended
for practical use, for the attainment of useful results
which would be difficult to obtain without its assistance.
It is the deliberate intention that one be able to approach it with a non-trivial program and obtain with it
a significantly improved version. Such programs will
include applications programs, system programs such
as the ELI compiler, as well as modules of the laboratory itself.
It appears that this will be achievable even with the
simple approaches to be taken in the initial version of
the laboratory. The use of programmable theorem
provers and search techniques have made it possible to
quickly endow the laboratory with considerable expertise, if not deep insight. On large production pro" grams (which commonly are so complex that no one
really understands their exact behavior) the laboratory
may be expected to make significant improvements by
more or less· mechanical means. Such mechanical skill
is precisely what is required to complement the high
level programmer. Initially, the laboratory will serve
as a programmer's assistant, suggesting possible areas
of improvement and carrying out the transformations
he chooses, but leaving the creative work to him. Even
at this level the laboratory may serve better than the
average junior programmer. Further, the initiallabora-

20

Spring Joint Computer Conference, 1972

tory will serve as a basis for developing more sophisticated control over the choice of transformations to
be applied.
A topic which falls out as another application of this
work is the modification or adaptation of programs.
Given a program which does a certain job well, it is very
common that it must be modified to handle a related
task or work under changed conditions. Usually such
modifications are done by hand, seldom with entirely
satisfactory results. Hence, automation of the process is
attractive. One method which has been occasionally
proposed for performing this is to construct a system
which when fed the existing program, deduces how it
works, and then performs the specified modifications.
This requires the system to dig the meaning and purpose out of the existing program-an operation which
is difficult at best and perhaps impractically expensive.
A solution which shows greater promise is to use the
laboratory to combine man and machine. If programs
are developed using the laboratory, then for any
production program, there is an initial program from
which it was derived. Given a statement of the new task
to be accomplished, the programmer can make his
modifications to the relatively transparent and simple
initial program. This is still hand labor, but at a much
higher level. Applying the laboratory to the optimization of the modified program results in a production
program with the desired properties. This puts creative
work in adapting a program into the hands of the
programmer while freeing himJrom the drudge work.
It is anticipated that as the programmer gains
experience with the system, he will develop his own set
of optimization techniques. By making it convenient
for him to add to the data base these transformations
along with patterns for recognizing potential situations
for their applications, we allow a certain degree of
growth in the expertise of the laboratory. Given a clever
population of users, the laboratory should grow to some
considerable level of sophistication, at least in areas of
interest to that user population. This scenario has, of
course, its limitations. Merely expanding the data base
would, in time, cause the system. to flounder in a sea of
possible but irrelevant transformations. Hence growth
of the system must ultimately depend on significant
improvements in global strategies, local heuristics, and
theorem provers. In particular, the need for specialized
theorem provers will very likely arise.
At present, it is not clear how to proceed in these
directions, nor is this surprising. One of the purposes
of the laboratory is to gain expertise in program manipulation, determine the limitation of current techniques, and advance to the point where the real
problems can be seen clearly. The initial laboratory is
a first step, but a significant step, in this direction.

BIBLIOGRAPHY
E A ASHCROFT (1970)
M athematicallogic applied to the semantics of computer
programs
PhD Thesis Imperial College London
E A ASHCROFT Z MANNA (1970)
Formalization of properties oj parallel programs
Stanford Artificial Intelligence Project Memo AI-110 Stanford
University
R M BURSTALL (1970)
Formal description of program structure and semantics in
first-order logic
Machine Intelligence 5 (Eds Meltzer and Michie)
Edinburgh University Press, 79-98
R M BURST ALL (1969)
Proving properties of programs by structural1·nduction
Comp J 12 1 41-48
D C COOPER (1966)
The equivalence of certain computations
Computer Journal Vol 9 pp 45-52
R W FLOYD (1967)
Assigning meanings to programs
Proceedings of Symposia in Applied Mathematics American
Mathematical Society Vol 19 19-32
R W FLOYD (1967)
Non-deterministic algorithms
JACM Vol 14 No 4 (Oct.)
B A GALLER A J PERLIS (1970)
A view of programming languages
Chapter 4 Addison-Wesley
C GREEN (1969b)
The application of theorem proving to question-answering
systems
Ph D Thesis Stanford University Stanford California
C GREEN B RAPHAEL (1968)
The use of theorem-proving techm·ques in question-answering
system'S
Proc 23rd Nat Conf ACM Thompson Book Company
Washington DC
P J HAYES (1969)
A machine-oriented formulation of the extended junctional
calculus
Stanford Artificial Intelligence Project Memo 62 Also appeared
as Metamathematics Unit Report University of Edinburgh
Scotland
C HEWITT (1971)
Description and theoretical analysis of plannar
Ph D Thesis MIT January
C B JONES P LUCAS
Proving correctness of implementation techniques
Symposium on Semantics of Algorithmic Languages Lecture
Notes in Mathematics 188 New York
D M KAPLAN (1970)
Proving things about programs
Proc Princeton Conference on Information Science and System
D M KAPLAN (1967)
Correctness of a compiler for algol-like programs
Stanford Artificial Intelligence Memo No 48 Department of
Computer Science Stanford University
J KING (1969)
A program verifier
Ph D Thesis Carnegie-Mellon University Pittsburgh Pa
J KING R W FLOYD (1970)

Laboratory for Study of Automating Programming

Interpretation oriented theorem prover over integers
Second Annual ACM Symposium on Theory of Computing
Northampton Mass (May) pp 169-179
D C LUCKHAM N J NILSSON (1970)
Extracting information from resolution proof trees
Stanford Research Institute Artificial Intelligence Group
Technical Note 32
Z MANNA (1969)
The correctness of programs
J of Computer and Systems Sciences Vol 3 No 2 119-127
Z MANNA (1969)
The correctness of non-deterministic programs
Stanford Artificial Intelligence Project Memo AI-95 Stanford
University
Z MANNA J McCARTHY (1970)
Properties of programs and partial function logic
Machine Intelligence 5 (Eds Meltzer and Michie)
J McCARTHY (1963)
A basis for a mathematical theory of computation
Computer programming and formal systems
(Eds Braffort and Hirschberg) Amsterdam North Holland
pp 33-70
J McCARTHY J A PAINTER (1967)
Correctness of a compiler for arithmetic expressions
Mathematical Aspects of Computing Science Amer Math Soc
Providence Rhode Island pp 33-41
R MILNER
An algebraic definition of simulation between programs
Stanford Artificial Intelligence Memo AI-142
A NEMETH
Unpublished; to be included in his Ph D Thesis Harvard
University
J A PAINTER (1967)
SemanUc correctness of a compiler for an algol-like language
Stanford Artificial Intelligence Memo No 44 (March)
Department of Computer Science Stanford University
M S PATERSON (1967)
Equivalence problems in a model of computation
PhD Thesis Cambridge University
G ROBINSON L WOS
Paramodulation and theorem-proving in first-order theories
with equality
Machine Intelligence Vol IV Ed by D Michie

21

J ROBINSON (1966)
A review of automatic theorem proving
Annual Symposia in Applied Mathematics Vol XIX
J T SCHWARTZ (1970-71)
Abstract algorithms and a set-theoretic language for their
expression
Preliminary Draft First Part Courant Institute of
Mathematical Sciences NYU
J M SPITZEN (1971)
A tool for experiments in program optimization
(in preparation)
R M SHAPIRO H SAINT (1969)
The representation of algorithms
Rome Air Development Center Technical Report 69-313
Volume II September
H A SIMON (1963)
Experiments with a heuristic compiler
JACM (October 1963) 482-506
J SLAGLE (1967)
A utomatic theorem proving wUh renameable and semantic
resolution
JACM Vol 14 No 4 (October 1967) 687-697
J SLAGLE (1965)
Experiments with a deductive question-answering program
Comm ACM Vol 8 No 12 (December) 792-798
H R STRONG JR (1970)
Translating recursion equations into flow charts
Proceedings Second ACM Symposium on Theory of Computing
(May) pp 184-197
G J SUSSMAN T WINOGRAD (1970)
M icro-plannar reference manual
MIT AI Memo No 203 (July)
R J WALDINGER (1969)
Constructing programs automatically using theorem proving
PhD Thesis Carnegie-Mellon University (May 1969)
B WEGBREIT (1971)
The ECL programming system
Proc F JCC Vol 39
R WINOGRAD (1971)
Procedures as representative for data in a computer program for
understanding natural language
Project MAC MIT MAC-TR-:4 February

Segmentation and optimization of programs from
cyclic structure analysis
by JEAN-LOUP BAER and ROBERT CAUGHEY*
University of·Washington
Seattle, Washington

INTRODUCTION

Phase 1

Modelling of computer programs by directed graphs,
where the vertices represent the computational tasks
and the arcs show the flow of control, has been used for
optimization purposes,1,10 parallel processing evaluation,2,8 and segmentation. 7 ,9,13 All these studies are
mainly based on the fact that a high proportion of the
execution time of a program is spent in loops. Although
the cyclic structure of programs can be theoretically
complex, it has been observed that the nested ness is
seldom vBry deep.6 Thus if one wants to optimize
programs written in a high-level language, the detection
of cycles by the compiler and its use in an optimization
phase may yield a definite improvement in execution
time without having to pay too heavily for excess
compiling time. In this paper we show how a compiler
could make use of an efficient cycle detection algorithm12
to model the embeddedness of cycles by an acyclic
directed graph. The latter can then be used for packing
purposes in case of a paging or "cache" memory system
as well as for predicting t he expected number of executions of a given statement for optimization purposes.

Directed graph model-/nstruction Sequences

The basic model is a directed graph G (W, U) where
W is the set of vertices {WI, W2, .•• , wm } and U is the
set of ordered pairs (or arcs) Uk = (Wi, Wj). Vertices
represent computational tasks and arcs show the flow
of control. Methods to analyze a FORTRAN source
program and transform it into an equivalent-in terms
of control-directed graph are now \vell-known. We
shall follow Russell's approach lO and therefore we
assume the uniqueness of an initial vertex WI and
terminal vertex w: as well as connectedness of the graph.
Appendix I shows the vertices and arcs generated from
the analysis of the current source statement according
to its type. Figure 1 gives an example program (executable statements only) and its directed graph representation. Associated with each vertex Wi is a volume
attribute Vi which represents the amount of memory
words required for the machine code generated by the
translated statement.
Thus given a source program, the first part of the
modelling process yields G (W, U) which can also be
conveniently represented by an m Xm (where m = ! W !)
Boolean connectivity matrix C,9 and a volume vector

MODELLING OF FORTRAN PROGRAMS

V(!V!=m).

For clarity of exposition we present the modelling
process as a sequence of four phases. However, actions
of phases 1, 2, and some of 3 are performed concurrently.
The source program itself is scanned only once. The
four phases are now described both functionally and
in terms of the basic data structures. Detailed algorithms
can be found in Reference 4.

For reasons which will become apparent in Phase 3
we now define the / nstruction Sequences (LS.) of a
source program.
Let A be thEY class of all FORTRAN executable
source statement types which do not have the attribute
of implicit flow of control* and A its complement with
respect to the class of FORTRAN executable source
statements. Let Z = SI, S2, ... , Si, ... , Sn be the

* Present

* I.e., these statements which have as a unique immediate
successor the next statement in sequence.

address: System Services Department, Snohomish
County, Everett, Washington.

23

24

Spring Joint Computer Conference, 1972

Z' can also be represented by a directed graph
READ (5,5) K1,Il,I2,13
IF (K1) 10,20,300
10

STOP

20

K1=1

23

K1 : K1 + 1

25

Il=Il+1
IF (Il) 25,30,30

8

30

12 = 12 + 1
IF (12) 30,35,35

10

35

40

IF «Il+I2+I3) .LT. 15) GO TO 23

3900

:1(1) = (I*Il

15

3995

M(I)

~

+

K1)

4000

CONTINUE
IF (K1 - 15) 23,400,400

If!,

Identify DO-loops and their embeddedness

2*M(I)

IF ('1(1) .LT. 25) GO TO 3995

16

19

400

IF (K1 - 50) 300,300,10

20

300

DO 200 J = 1,10

In this phase we record the membership of statements
in DO-loops in the following way. Each DO-loop is
represented by an m-dimensional Boolean vector, say
d i for the ith DO-loop, such that dik = 1 if the statement
represented by vertex Wk is in the DO-loop and d ik = 0

DO 195 I = K1,50

21
22

195

N(I,J) = 2*I/3*J

23

200

CONTINUE

24

Phase 2

DO 4000 I - 1,50

13

14

17

mination of the LS.'s and their interconnections is
easy and not time consuming (Figure 2 displays these
new structures for the example program of Figure 1).
It follows the same algorithms as the one used for the
generation of branch instructions by the compiler.

IF (13) 35,40,40

11
12

13 = 13 + 1

H (I, Y) where I is the set of vertices Ii representing
the LS.'s and Yk= (Ii, I j ) is an arcE Y if the terminal
statement Sim of Ii can transfer explicitly to a statement
Sjp of I j • This directed graph can also be represented
by a Boolean connectivity matrix M.
Given Z the string of source statements, the deter-

END

Figure l-Modelof a FORTRAN program
(executable statements only)

11 = (1,2)

16 = (12)

12 = (3)

17

13 = (4,5,6,7)

18 = (17,18)

14 = (8,9)

19

15 = (10,11)

1

10

= (13,14,15,16)

=

(19)

=

(20,21,22,23,24)

(a) Instruction Sequences.

finite string of source statements which comprise a
program, in the order (on ascending index) in which
they are initially submitted to a translator. An instruction sequence I k is a non-empty substring of consecutive
elements of Z written as

2

3

4

1

1

a a a a

a a a

such that:
(i) SkjEA for 1:::;j~m-1 and SkI is called the
initial statement of I k
(ii) SkmEA and Skm is called the terminal statement
ofh
(iii) Ik is the substring of Z of maximum length
which contains Skm.
Z is partitioned into instruction sequences and can

1

a

10

5

0

a

6

0

7

0

8

9

0

a

1

a

0

1

10

0

a

1

1

0

a

0

0

a a

a

0

0

1

1

0

0

0

0

0

0

0

0

1

1

0

0

0

a

0

a

1

0

0

0

1

a

0

0

a a a

0

a a

1

1

a

0

a

1

a

1

a

0

0

1

a

0

0

a

1

a a

0

a a

0

0

1

0

a a

0

a

a

0

0

0

0

(c) Matrix M

(b) Graph H(I,Y)

now be rewritten as:
Figure 2-Alternate representations of the example
FORTRAN program

Segmentation and Optimization of Programs

otherwise. At the same time, we build a (partial)
embeddedness Boolean matrix E+ which is such that
eij+= 1 if DO-loop j is nested within DO-loop i.
The construction of the d/s and E+ is up to this point
straightforward and mainly requires the same techniques as those used generally in the compilation of
DO-loops, that is the maintenance of a stack of currently active DO-loops and their associated terminating
labels. Figure 3 shows the d/s and E+ after DO-loop
processing for the example of Figure 1.
Phase 3
Identify the remaining elementary cycles

A general algorithm to detect the elementary cycles
in a directed graph has been recently published. 12 It is
based on a path extension technique with each vertex
of the graph being a potential starting point for a cycle.
In our case, the searching time of the exhaustive
detection-a function of the number of vertices and
arcs in the graph-can be greatly reduced by the
following two observations.
(i) Ignore the feedback arcs of the DO-loops since
the corresponding cycles have already been
detected.

Ve rtex Number

11122222
78901234

123456789

0000000000011110000000
0000000000000000001110
0000000

00000000

000

0

1

0

25

TABLE I-List of Origin-Destination statements and I. S.'s
Origin-Destination

Origin-Destination

2,3
2,4
2,20
3,24

1~ 2
1,3
1, 10
2,10
3,3
3,4
4,4
4,5
6,3

7,6
7,8
9,8
9,10
11,10
11, 12
12,5
16, 15
18,5
18, 19
19,20
19, 3

7,7
8,3
8,9
9,10
9,2
5,5
5,6

(ii) In FORTRAN only a subclass X of statements
(X CA) can be origin statements of cycles. This
subclass X corresponds to statement types*:
GO TO K
GO TO L, (Kl' K 2, ••• , Kp)
GO TO (Kl' K 2 , • • • , Kp), L
IF (E) K 1, K 2 , K3
IF (B) S where S is a GO TO statement
Only statements of type belonging to X can be
starting points of cycles in G (W, U), and they are
necessarily terminal statements of 1.S. 'so Thus ,ve are
going to reduce our cycle search by looking first for
cycles in H (I, Y) and then transform these into cycles
of G (W, U). This phase is going to be processed in
three stages.

0

Stage 1. Reduce domain of search of elementary cycles
of I.S.'s
Partial Embeddedness matrix E+

Cycles

...."u

>.
u

1

1

2

3

4

0

0

0

0

0

0

1

0

0

0

0

0

Figure 3-Array D (cycle vertex membership) and matrix E+
(cycle embeddedness) after DO-loop processing of the example
program

A list of paired origin-destination statements, where
the origin statements are the terminal statements of the
1.S.'s and the destination statements are those referred
to by the labels K i, is built during the scanning of the
source program Z. The forward reference labelling
problem is dealt with in the same manner as the compiler must do for generating code. The corresponding
list of origin-destination LS.'s is also constructed (cf.
Table I for our example) .

* We restrict ourselves to the analysis of main programs or
subroutines, that is we do not include CALL statements as
statements which imply transfer of control.

26

Spring Joint Computer Conference, 1972

Figure 4 shows M* and the reduced set of LS. starting
vertices.

I. S. Number

1

,...

1

2

3

4

5

6

7

8

9

1
0

0

1

1

1

1

1

1

1

1

1

Stage 2. Find elementary cycles of I. S.' s
The algorithm already referred to 12 is used with the
short-cut of skipping those vertices which are not part
of the reduced set of possible starting points. Figur~ 5
lists these cycles.

2

0

0

0

0

0

0

0

0

0

1

3

0

1

1

1

1

1

1

1

1

1

4

0

1

1

1

1

1

1

1

1

1

5

0

1

1

1

1

1

1

1

1

1

6

0

1

1

1

1

1

1

1

1

1

7

0

1

1

1

1

1

1

1

1

1

8

0

1

1

1

1

1

1

1

1

1

Each cycle of LS.'s must be converted into cycles of
the original graph (G-cycles). It is of course possible
that a single LS. cycle may yield several G-cycles.
For example, the LS. :

9

0

1

0

0

0

0

0

0

0

1

Corresponding vertex number

10

0

0

0

0

0

0

0

0

0

0

Stage 3. Conversion of I.S. cycles to original graph
cycles (G-cycles)

QJ

§
z

.
.

U)

1-1

Starter I. S. Number

3
4

5
6

7
8
Figure 4-Matrix M* and domain of starter I.S.'s

The domain of· possible starter nodes for the cycle
detection algorithm could be further reduced as follows.
Let (h,I j ) be an origin-destination pair of LS.'s. They
will be part of a same cycle if and only if mk/ = mjk* = 1
in the reflexive transitive closure M* of the connectivity
matrix M. If these relations do not hold the origindestination pair can be deleted. However, it is debatable
. if the gain incurred by this deletiori surpasses the cost
of generating M*, a process of order greater than n 2•

10 A=B
20 C=D
IF (E) 10,20,30

1
2
3

which has one LS. cycle, namely itself, yields two
G-cycles {l, 2, 3} and {2, 3}.
The conversion algorithm may be summarized as
follows: Let Ci=I a, Ifj, ... , Iu be an LS. cycle. Recalling the definition of an LS. one can write I a = Sa,l,
Sa ,2, ••• , Sa ,mao All Sa ,ma are part of all G-cycles
generated by Ci. Let (Sa,ma, Sfj,j) be a paired origindestination statement leading from I a to 1(3. Now the
sets d i corresponding to G-cycles are obtained as
follows:
1. Initialization step. d i o= rJ> (the empty set).
2. Let a be the index of the first LS. in Ci and 13
the index of the next LS. in sequence (if there is
only one LS. 13 = a) .

C = (3)
1

C = (4)
4

C = (3,4,5,6)
2

C

C
3

=

(3,4,5,6,7,8)

s

= (5)

C = (7)
6

Figure 5-List of cycles of instruction sequences

Segmentation and Optimization of Programs

3. For each origin-destination pair (Sa.ma,
For each d ia do:

S~.j)

do:

dil = diaU {S~.j, ... , S~.m~}
4. a=~; ~='Y (set to index of next LS.). (If a=u,
~

is set to the index of the first LS.)

If a = index of the first LS. then stop; the d/s are the

last dk~ generated; else go to step 3. Figure 6 shows the
set of G-cycles generated in the Boolean notation
adopted in phase 2.

Phase 4
Complete and reduce the embeddedness matrix E+

We now want to complete E+ which was defined and
partially built during phase 2. If d i and d j are two
G-cycles in Boolean representation, then letJij=dindj.
Elements of E+ will now be defined by:

27

1

2

3

4

5

6

7

8

9

1

0

0

0

0

0

0

0

0

1

2

0

0

1

0

0

0

0

0

0

3

0

0

0

0

0

0

0

0

0

4

0

0

0

0

0

0

0

0

0

5

0

0

0

1

0

0

1

1

0

6

1

0

0

0

1

0

0

0

0

7

0

0

0

0

0

0

0

0

0

8

0

0

a

0

a

0

0

0

0

9

0

0

0

0

0

0

0

0

0

-IfJi1 = d i then eii+= 1, eii+=O (d i embedded indj)
-IfJii= dithen eii+=O, eii+= 1 (di embedded in d i )

-If Jij~di~dj then eji+ = eij+ = O.

Since the embeddedness of the DO-loops between
themselves have already been recorded, these tests are
done only for the pairs of cycles i, j where 1:::; i:::; n
(n number of cycles) , k p (if cycle does not fit entirely in a
page) go to step 16 (part C) .

B. [The cycle fits in (remainder of) page].

A. [Initialization].
1. If h=k (i.e., vector T completely traversed)
then end.
2. Let h be the index of the next (initially first)
cycle in vector T and dj be the Boolean representation of this cycle.
h=h+l;

Page
Number

j=T(h).

3. Let n be an index varying from 1 to m (the
number of vertices in G). Set n = O.

11. cp=cp+vdh ; Vq=Cp (This is part of the merging
process) .
12. n=n+1.
13. If djn = 0 go to step 15.
14. Vn = O. Merge Wn into Wq (for an explanation of
merging see below) .
15. If n=m go to step 1 (i.e., to part A) else go to
step 12.
C. [The cycle overflows a page].

4. If cp=O go to step 7.

16. cp=vn.

5. If CP+Vdh~P (i.e., if the current cycle will not
go over a page boundary) go to step 11.

17.
18.
19.
20.

6. Set cp = 0 (Start a new page) .

7. n=n+1.
8. If djn = 0 (i.e., vertex n does not belong to cycle
j) go to step 7.

n=n+1.
If djn = 0 go to step 22.
If Vq+vn>p go to step 21.
Merge Wn into Wq and Vn into Vq; cp=cp+v n;
Go to step 22.

21. q=n; cp=vn.
22. If n=m go to step 1 else go to step 17.

30

Spring Joint Computer Conference, 1972

TABLE III-Volume Vector for Example Program

Vertex 1 2

111
3 4 5 6 7 8 9 0 1 2

1 1 1 1 1 1 122 222
3 4 5 6 7 8 9 0 1 2 3 4

Volume 8 4 2 2 3 3 3 3 3 3 3 5 5

The merging process is defined by:
-To merge Wn into Wq replace qth row of C by the
logical sum of itself and the nth row of C, and
replace the qth column of C by the logical sum
of itself and the nth column of C. Set the nth
column and row of C to all O's.
-To merge Vn into Vq replace Vq by vq+v n in the
memory volume vector V and set Vn to O.
The remaining task is to assign those nodes which
are not members of cycles. It is done by following part
C above, after first initializing both q and n to 1.
Figure 8 shows the result of packing for p = 8 (a very
small page size only for illustration purpose) and the
volume vector of Table III. Although this algorithm
is crude-and we see below how to improve it-it is
worthwhile to compare its outcome with what would
have been obtained by usual compiling techniques.
Figure 9 shows how the code would be allocated in a
straightforward manner with vertices allowed to run
over pages.
As can be seen the total number of pages required for
the generated code is smaller in the usual compiler's
case (7 instead of 10). However, the goal of the packing
algorithm is to improve the residency of the pages, i.e.,
the locality of the code. In general the number of data
pages needed for efficient execution is much greater
than the number of code pages; the packing algorithm
thus helps in leaving more main memory space to data
during long bursts of execution. For example, loops
(W6, W7) (WIO, Wll) and (W22) occupy one page instead
of two. Moreover, as stated earlier, the packing algorithm can be improved. A first clean-up pass could
be implemented as follows:
If after the merging process, Cji = 1 (i.e., pages i and
j are connected) and Vi+Vj~P (the sum of their
memory volumes is less than a page), then merge
Wi into Wj and Vi into Vj.
In our example, pages 16 and 17 would be merged,
as well as pages 18 and 19, thus leading to a definite
improvement in the second part of the main cycle.
A more sophisticated clean-up pass would be first to
"squeeze" those elementary cycles which are leaves of
the forest, by allowing vertices to run over pages. (In

6 5 4 3 4 4 5 5 8 3

2

our example WI6 would be in pages 15 and 16.) Then the
clean-up pass defined above would be invoked. Figure
10 shows the results of the improved algorithm. The
main loop requires now only 8 pages; the number of
interpage transitions is diminished, and the locality of
the code is improved.
EXPECTED NUMBER OF EXECUTIONS OF
SOURCE STATEMENTS
The knowledge of the expected number of times a
given source statement is going to be executed can be
an important factor in the optimization of high-level
source programs. 6 ,IO It allows replacement of compilergenerated code by a tighter hand-coded version in the

Figure 9-Usual memory allocation by a compiler
(all pages have volume 8)

Segmentation and Optimization of Programs

event of an often-repeated statement. In the context
of the previous section, the traversal of the tree could
be monitored by the maximum expected number of
executions, instead of being directed by maximum
levels, thus leading to a better residency of pages of
code.
In this section we show how these numbers can be
estimated when i) the probabilities q/ of traversing
the arcs (Wi, Wj) corresponding to paired origindestination statements are known, and ii) when the
mean number of times the feedback arc of a DO-loop
is set up to be traversed is known. These parameters of
the source program will have to be "guessed" or instrumented. Io In the former case they represent a first pass
at the analysis of the program and only well-known
sections of it should be optimized. In the latter, they
correspond to an "a posteriori" optimization of a
production run. In both cases, we assume that we have a

31

Markovian process, i.e., the qJ stay invariant each
time Wi is reached.

Travel'sal of the directed graph
The method we outline is an outgrowth of studies
related to the prediction of performance of multiprocessors. 2 •8 Let fi be the expected number of executions of vertex Wi, Pi its probability of being reached
from the initial vertex WI when all feedback arcs of the
graph have been removed. In the case of a stochastic
cycle, i.e., one which is not a DO-loop, this feedback
arc is the one corresponding to the last paired origindestination statement encountered when transforming
the LS. cycles to G-cycles, and of probability not equal
to 1. After normalizing the probabilities of arcs incident
out of vertices which are origins of feedback arcs, one
computes the Pi as:
k

(1) pi=

L

pjq/ where

Wj

(j = 1, ... , k) are the

j=I

immediate predecessors of
all fi are set to 1.

Wi.

At initialization

The traversal of the directed graph represented by
the original embeddedness matrix E is performed aEl
follows.
1. Let dI , d2, ••• ,dk be the leaves of the graph.
Partition these leaves into classes El = {d1 },
E 2 = {d2 },

•••

,Ek = {d k }.

2. If two classes Ei and E j are such that there
exists diEEi and djEE j such that dindj~cp, let
Ei=EiUEJ and suppress E j •
3. Repeat step 2 until no suppression occurs.
4. Compute the fi (up to that point) of each
vertex member of a cycle belonging to one of the
Ei left after step 3, as explained belmv.
5. Suppress from E all the leaves and repeat steps
1 to 4 until all cycles have been treated.
Steps 1 to 3 are facilitated by the use of the tabular
representation of the graph. They involve mainly the
partition of cycles into classes with the equivalence
relation being "to have a common father with at least
one member of the class."

Computation of f/s corresponding to leaf cycles

Figure 10~Parking after "squeeze" and "clean-up" passes

Let Ek = {d il , d i2 , ••• , d ile } be a class as defined
above. We shall give expressions for the fi of vertex
members of d ij in supposing first that the cycles are at
their maximum depth of embedded ness.

32

Spring Joint Computer Conference, 1972

there exists no arc (Wi, wi') such that Wi Ed i1 - {wd
and W/~di1.
Let (N -1) be the mean number of times the DO-loop
has been set up for and p the probability of the feedback
arc of a stochastic cycle. For a DO-loop:

(a)

o
o
I

\

\

b

N

ii= L j Pr[wi( j) ]
i=1

and

/

But

Pr[w;(j)

J~

C)

p<*i(l-p,*)N-;,

Hence:

= N Pi*

L

(N-l)

i=1

j-1

N

Pi*i-1(1- p/) (N-1)-(i-1)

or
h=Npi*=ihPi*.

(b)

p

Figure ll-Regular Markov chain (sub case 1 of case 1)

Case 1. Ek has a unique member d i1 = {Wh' ... , Wi,
... , Wt} where (Wt, Wh) is the feedback arc.
Let Pi* be computed as in (1) in considering only
the subgraph corresponding to d i1 and Ph = 1. We note
Pr[wi( j)] as the probability of executing wd and j
times only.
Subcase 1. There is no branching out of d i1 , that is

For a stochastic cycle: the process can be considered
as a regular Markov chain as shown in Figure l1.a. by
introducing an extra arc of probability 1. Now if P is
the regular transition matrix, (Ilh' ... , IIi, ... , lIt, lIe)
the limiting probability vector, it is known that the
mean first passage time to return to a given state is
mii= l/Il i. In our case, mee= l/Il ee represents the mean
number of steps, and h = IIi/lIe.
If one is interested only in ih, ii, it, the graph is
equivalent to the one in Figure l1.b. whose transition
matrix is:

o

0

o

1

o

o

0

o

1

o

p

0

o

o

1-p

1

0

o

o

o

and since IIi = p/II h, then ii = P/ih. Now ih could be
computed by the ratio Ilh/ll e but directly one can see
that:

Sub case 2. There is some branching out of total

Segmentation and Optimization of Programs

33

probability l-Q where Q=Pt*. In the DO-loop case:
Pr[Wh(j)J=Qi- 1(I-Q) (j=I, ... ,N-l);
Pr[wh(N)J=QN.

Hence

p

G

1
p

Now
Pr[wi(k)] =

i:
i=k

,

Pr[wh( j) ] (j) p/ k (I-Pi*) i-k
k

t2

(k= 1, ... ,N)

and
N

Ji=

L: k Pr[wi(k) ]

k=l

i:

Pr[wh(k) ] t j

k=l

(~) Pi*i(1-Pi*)k- i

3=1)

Figure 13-Regular Markov chain (subcase 1 of case 2)

matrix
010

N

=p/

L: k Pr[wh(k)] •

k=l

(X-I)

k
~.

3=1

Pi*i-1 (1- p/) (k-1)-(j-1)

)-1

o

0 Q l-Q

p

0 0

I-p

100

0

which yields

N

=Pi*

0

L: k Pr[wh(k) ]=P/Jh.

1

k=l

In the stochastic case, the computation of Jh corresponds to the Markov chain of Figure 12 of transition

p

1

Figure 12-Regular Markov chain (subcase 2 of case 1)

Jh= l-Qp

Analysis similar to subcase 1 would yield Ji = Pi*jh.
In summary for this first case, the computation of the
Ji involve only the computation of the Pi* and of the
Jh as given above.

Case 2. Ek has more than one member.
Subcase 1. All cycles are stochastic.
Again we have recourse to the ::.vrarkov chain approach. Of interest are the Ji of the heads and tails of
the cycles. A typical example is shown in Figure 12 of
transition matrix;

o

1

0

0

0

o

0

1

0

0

p

0

0

I-p

0

o

p'

0

0

I-p'

1 0

0

0

o

34

Spring Joint Computer Conference, 1972

approach. To do so an N -folding of the structure must
be performed as shown in Figure 14.a. To obtain fh2
andft2 a reduction as in Figure 14.b. is performed giving
a transition matrix

(a)

p

I-p

0

0

p

0

I-p

0

p

o

o

I-p

1

o

o

o

which yields
1

fh1= - - (l-p)N'
(b)

1- (l-p)N
p(l-p)N

p

andft1=fh2,ft2= (l-p)fh2 as in subcase 1.

1

If for both cases 1 and 2, the cycles are not embedded
in any other cycle, the fi are multiplied by Ph the
probability of reaching the first head. If they are
embedded in other cycles, the fi computed at the next
level will be multiplied by those just obtained until all
cycles have been treated.

CONCLUSION
Figure 14-Subcase 2 of case 2

which yields
p

fh1=

1+ (l-p) (I-p')

,

1
fh2=ft1= (l-p) (I-p')

and
1

ft2= -1-p'

Subcase 2. One member of Ek is a DO-loop (there
can be no more than one due to the Syntax of
FORTRAN).
Consider again Figure 13 but suppose now that the
second cycle is a DO-loop. It could be possible by using
methods of renewal theory to determine the fi in this
case. However we can still use the Markov chain

In this paper we have presented a model of Fortran
source programs with particular emphasis on the cyclic
structure. Applications of the model to segmentation
and optimization have been introduced. Algorithms
needed to extract information from the high-level
language in order to build the model have been given.
A packing algorithm, whose goal is to reduce the
number of interpage transitions in a paging or cache
memory system, has been presented along with its
application to an example program. The cyclic structure
of the program has also been used to compute the
expected number of executions of each statement of the
source program.
The results of the packing algorithm, which is meant
to increase the locality of the generated code, could also
be used in paging mechanisms with anticipatory
control. The expected numbers of executions could
serve in the packing of data into pages, the data with
high correlation being allocated in the same pages. This
latter problem needs more investigation and it is in this

Segmentation and Optimization of Programs

direction that extensions of the model and new algorithms should prove useful.

REFERENCES
1 FE ALLEN
Program optimization
Ann Rev in Aut Prog 5: pp 239-302 1969
2 J L BAER
Graph models of computations in computer systems
PhD Dissert UCLA 1968
3 J L BAER
Matrice de connexion minimale d'une matrice de precedence
donnee
RIRO 16: pp 65-73 1969
4 R T CAUGHEY
Automatic segmentation of FORTRAN programs from cyclic
structure analysis
MS Thesis Univ of Washington 1971
5 F H DEARNLEY G B NEWELL
A utomatic segmentation of programs for a two-level store
computer
The Computer Journal 7 3 pp 185-187 May 1968
6 D E KNUTH
An empirical study of FORTRAN programs
C Sci Depart Report CS-186 Stanford Univ 1970
7 T C LOWE
Automatic segmentation of cyclic structures based on
connectivity and processor timing
Comm ACM 13 1 pp 3-9 Jan 1970

35

8 D F MARTIN G ESTRIN
Models of computational systems cyclic to acyclic graph
transformations
Trans IEEE EC-16 pp 70-79 Feb 1967
9 C V RAMAMOORTHY
The analytical design of a dynamic look-ahead and program
segmenting scheme for multiprogrammed computers
Proc ACM 21st Nat Conf Thompson Book Co pp 229-239
1966
10 E C RUSSELL G ESTRIN
Measurement based automatic analysis of FORTRAN
programs
Spring Joint Conf Proc 34 pp 723-732 1969
11 J M S SIMOES-PEREIRA

.

On the Boolean Matrix Equation M' = U Mi
i=l

Journal ACM 12 3 pp 376-382 July 1965
12 J C TIERNAN
An efficient search algorithm to find the elementary circuits
of a graph
Comm ACM 13 12 pp 722-726 Dec 1970
13 E W VERHOEF
A utomatic program segmentation based on Boolean
connectivity
Spring Joint Comp Conf Proc 38 pp 491-495 1971
14 B W KERNIGHAM
Optimal sequential partitions of graphs
Journal ACM 18 1 pp 34-40 Jan 1971
15 J KRAL
One way of estimating frequencies of jumps in programs
Comm ACM 11 7 pp 475-479 July 1968

36

Spring Joint Computer Conference, 1972

APPENDIX I
Vertices and arcs generated by the graph modeling process.
Notation: Wi current vertex number; Wi+! next (sequential) vertex number;
statement of label n; Wz terminal vertex.
STATEMENT
GOTOn
GO TO (nl,n2, ... ,nk),j
GO TO j, (nl,n2, ... ,nk)
IF (e) nl,n2,nS
IF (e) S
(a) If S is not a GO TO RETURN
or STOP
(b) If S is a GO TO RETURN or
STOP
DO n I = M1,M2,M3
CONTINUE
PAUSE
RETURN
STOP
READ (a,b,END = nl,ERR = n2)list
WRITE (a,b)list
ENDFILE
REWIND
REWIND
BACKSPACE
Arith. Stats.
END

Wn

vertex corresponding to source

VERTEX GENERATED

ARCS GENERATED
(Wi,W n )
(Wi,W nl),(Wi,W n2), ••• ,(Wi,Wnk)
(Wi,W nl),(Wi,W n2), ••• ,(Wi,Wnk)
(w i,Wnl), (w i,W n 2), (w i, wns)

Wi,Wi+1

(w i,W i+1), (w i, W i+2)

Wi

(Wi,Wi+l)

Wi

(W i,W i+I), (Wn, W i+l)

Wi

(Wi,Wi+l)

Wi

(Wi,Wi+l)

Wi

(Wi,W z )

Wi

(Wi,W z )

Wi

(W i, W i+1), (W i,Wnl), (W i,W n2)

Wi

(Wi,Wi+!)

Wi

(Wi,Wi+l)

Wi
Wi

(W i,W i+!)

Wi

(Wi,Wi+l)

Wi

(Wi,Wi+l)

Wz

The interplay of computer science and
large scale scientific calculations
by KENT K. CURTIS
National Science Foundation
Washington, D.C.

refer to the machines which have until now dominated
scientific calculation. Other designs which attempt to
reflect some additional measure of understandi.ng of
scientific calculations have been considered and some
are of substantial current interest. Pipe-line systems
and the ILLIAC IV, are among those which come to
mind, but none of them has yet had opportunity to
prove its value. Even they, however, are the result of
adding only one more global observation to the design
criteria, the observation that many scientific calculations have the common property that they involve
the redundant use of identical operation sequences on
ordered sets of data. Hence, their appearance and
history does not vitiate the force of the earlier observation. On the contrary, they extend its force to the near
future.
They do, however, raise several interesting points.
First, the principal ideas of architecture underlying
each of the machines which are now being physically
realized are approxi.mately ten years old. Still, these
machines are only now being delivered and experience
suggests that it will be some time yet until the systems
will have been stabilized sufficiently and used sufficiently to be able to make a definitive evaluation of
them from experience. This is a long gestation period.
It suggests that we should not expect breakthroughs
in large scale scientific computing due to new ideas in
machine architecture in a short time scale. The machines which are now coming to life may be substantial
contributors to scientific computing ten years from
now, if they prove out, but it is unlikely that machines
which are still on the drawing board will contribute
until later .
It also suggests that unless we believe we already
have discovered the only important concepts in machine
organization (which is possible but would be most
remarkable, if true) we should be very interested in
reducing the time span from idea to realization. Ideas
in machine organization spring from an environment

The history of computing has been characterized by
the statement that what the manufacturer makes, the
customer takes. To the extent that this is true, it is not
only an interesting and perceptive comment on history
but also a testimonial to the remarkable nature of the
sequential, stored program, electronic computer. If
that invention had not fit so well from the beginning
to a wide variety of interesting problems, the development of hardware and software systems could not have
proceeded as independently of scientific motivation
as it did. Of course, scientific requirements have influenced systems design, but the prominent parameters
such as speed or memory size could be understood
without detailed knowledge of scientific problems or
programs and the parameters which might depend
upon the structure of programs could be ignored.
It is fortunate that that was true. There were important problems to solve in physics, chemistry,
meteorology, etc. We could work on those without
delay and let systems design take care of itself, with
ad hoc software adjustments when things became
intolerable. Computers worked so well there was no
apparent need for guidance by scientists of system
design. Better design might make an incremental
difference but that increment was not sorely missed
and barely worth an incremental effort.
Meanwhile, computer development followed an
internal dynamic of its own. It was influenced by the
fact that scientific requirements provided a ready
market for computers which were big and fast, but
the general purpose computer was a useful paradigm
and rapid advancement of electronics technology kept
many problems at bay. Computer engineers and
businessmen could do their own thing in their own way,
with unusual freedom. The computers they built have
reflected principally their own genius in taking advantage of technological opportunity, and that, happily,
has been sufficient.
In making these comments, let me note that they

37

38

Spring Joint Computer Conference, 1972

of experience to meet a perceived need. They need
testing to evaluate them. If the need is really important
it will probably persist until an answer is found. But,
on the other hand, if the need is important we would
rather not wait ten years. This line of thought argues
for research in such areas as description languages
which can describe complex systems and be translated
to a design and fabrication process and it argues for
support by the scientific community for such research.
I would like to return to this point later.
Second, a "paper machine" has very little weight.
At an early stage in the development of the machine
which is becoming ILLIAC IV, I spent some time with
several people who were active in hydrodynamics and
meteorological research to see what basis for estimating
performance could be established from analyses of the
actual codes which were of interest in those fields. My
question was, to what extent does the parallelism which
is available in this design offer an effective improvement in performance, considering the detailed structure of the computing algorithms, data management,
and I/O processes that are used in these problems? I
thought I understood how to do that kind of analysis,
at least in part, including modifying the codes for
parallel processing, but I did not know the codes. I
hoped that someone who knew the codes could be
motivated to undertake some analysis. I. was impressed with the degree of interest in the machine and
the lack of interest in attempting any analysis. I found
a uniform response that if the machine existed, they
would try it because it seemed intuitively attractive.
No one was willing to attempt an analysis of his programs, however, with a view to justifying construction
of the machine or influencing its design. In all fairness,
they did not know how to do it and neither did I. The
problem is harder and more subtle than I thought. The
question remains open and, indeed, I still do not know
how to find an answer with assurance except by extended experience. Responsible people still hold an
honest difference of opinion. Fortunately, the continued development of that machine did not require
the active support and involvement of the scientific
community it was intended to serve. Technological
opportunity supported by intuition and some analysis
has been sufficient. The experience suggests, however,
that there exists only a weak coupling between the
community of natural scientists and the community
of computer engineers. It also affirms the need to test
new ideas in machine design by actual construction of
machines and evaluation in a user environment.
Another interesting point which these machines have
emphasized is that more than one schema may be
applied to the solution of most problems and different
computer architectures may favor different schema.

This seems obvious but it required the actual development of parallel and pipe-line machines to stimulate
such rethinking of problem formulation and algorithms.
N ow this offers a rich field of research for numerical
analysts and computer scientists, where results may
be of direct interest to scientists. I personally believe
that this is a profoundly significant development which
may portend the appearance of a new degree of influence by computers and computer science in our
conceptualization of the scientific problems we attempt
to solve. More immediately, however, it means that
definitive evaluation of new ideas in computer architecture can only be made after good algorithms for
those architectures are devised. Is this backwards?
Should not the analysis of algorithms influence design?
Is this not another example of weak coupling between
communities with allied interests? Fortunately, we are
beginning to make progress on the theory of algorithms
which offers hope of benefit to both scientific computing
and computer design.
Let us return, now, to the remarkable success of
sequential computers in large scale scientific computing.
If one considers the spectrum of activities which now
comprises large scale scientific calculation one can
observe a number of common features.
(1) The conceptual theory upon which the computations are based was firmly established before the
invention of computers. That theory had been
well verified using experiments and calculations
which could be and were conducted without
computers, providing a solid basis for faith
that large investments of effort and money in
computing would not be wasted.
High energy physics might be considered to
be one outstanding exception to this since conceptual theory in that field is being developed
during the age of computers. If one considers
the actual computing being done, however, the
distinction disappears. The large-scale computing
is in analysis of data from experiments which are
patterned in their design and analysis after
particle physics concepts that were well established before computers were applied. Orders
of magnitude less computation is used in theoretical investigation exploring the conceptual
understanding of high energy physics. No theory
commands sufficient faith to justify a larger
investment of time and money.
(2) The conceptual theories are all expressible in
well formed mathematical or statistical models.
(3) Based on the conceptual paradigms, it is possible
to visualize, without using computers, interesting
problems which can be solved with computers.

Interplay of Computer Science and Large Scale Scientific Calculations

(4) Such problems can be solved, to a sufficiently
good approximation to be interesting, using
sequential machines operating for reasonable
lengths of time.
(5) These problems enjoy a high national priority
giving them access to the large amounts of
money and effort which have been required for
their study.
If you think about it, this is an interesting set of
properties. It suggests the roles which have been played
in fact by scientific motivation, technological opportunity, and public support in determining the
course of development of large scale scientific computing. It provides a basis for understanding why
scientific progress and the development of computer
technology could be so vigorous, so symbiotic, and yet
so independent. It provides a rationale for the observation that scientific inquiry has adopted the technology
provided rather than leading or strongly cooperating
in its development. At the same time, it points to
certain limits, which have been observed by the course
of events, in fact, on the regions of success in scientific
computing. If one may have faith in continuity, it
suggests some features which can be expected of developments in the near future.
One interesting observation which derives from this
set of characteristics is that although computing has
profoundly changed the style and methodology of
research in some fields, although it has opened nmv
questions for serious consideration, there has been no
departure from already established concepts. Computing has not yet altered our paradigms of nature in
a fundamental way. This is not surprising-the time
constant for developing fundamental physical theory
is much longer than the history of computers-but it
indicates that we should not expect the short time
scales associated with the development of technology
to be reflected in any obvious way, if at all, in the rate
we revise our fundamental underst9,nding of nature. It
also invites the question of whether computing should
be expected to ever become an essential component of
conceptualization. Are there interesting phenomena
which cannot be described within the framework of
mathematical or statistical models? Are there important questions to be posed which do not yield to
analysis by sequential procedures? What would it
mean to include a program operating in time as an
essential element in our description of a model, as we
now include time-dependent equations? It is an interesting conjecture. Considerations of real-time systems are suggestive.
Before going on, let us examine some possible inferences which may be drawn from the preceding

39

characterization of large scale scientific computing.
Certainly it is true that national priorities have strongly
influenced the choice of fields of investigation and
hence the visible progress. These priorities are changing
and efforts in large scale computation in fields other
than the physical sciences will receive more encouragement. Fields which have the property that they can
take advantage of existing technology, have well
posed questions based on well formulated mathematical paradigms, and have a sufficiently large community of interested and talented scientists who are beginning to emerge as partners with the physical sciences
in large scale computing. The National Science Foundation is playing a role in this through its interest in
the applications of computers to research in the natural
sciences, in social sciences, and in applied research.
One harbinger of change is the establishment of the
Computer Research Center for Economics and lVlanagement Science by the National Bureau of Economic
Research, Inc. with NSF support. We intend to take
advantage of other opportunities as they arise.
If we note, again, that it has taken a decade to develop the new machines which are now appearing and
that it will be some time, yet, before they can be
adequately evaluated we may guess that the new fields
which will join the ranks of large scale scientific computing in the next decade can be discerned now. They
are not many. Few disciplines enjoy the advantages
which the physical sciences have of almost universally
accepted, well established paradigms which adapt well
to existing computer technology. Advances in theory
might accelerate the entry of one field or another in
unexpected ways but advances in technology are unlikely to do so within a ten year time frame. I, myself,
am not aware of many well formed problems embedded
in widely accepted theory which are only awaiting a
technological breakthrough to be solved. Even if they
exist, it will take time to translate new ideas in technology into effective research application. The ideas
must first be converted into actually realized tools, a
task that may take more than ten years itself if we accept prior experience as a guide. The application of these
tools must then be developed. Although there is overlap in these activities, a reasonable expectation would
be that in ten years time we will be able to guess some
still in the future impacts we do not now discern but
the fully active members of the large scale computing
fraternity which will then exist are already recognizable today as having accepted theories which are
describable by mathematical or statistical models
amenable to solution by sequential machines. The
potential new members are distinguished from the
present members primarily by the fact that they are
only now adopting the mathematical methodology of

40

Spring Joint Computer Conference, 1972

the physical sciences and by the fact they they do not
yet enjoy high national priority status. Technology
notwithstanding, ten years is a short time in .the development of human thought. Even quantum theory
took much longer to evolve.
Another feature which emerges from considering
this set of properties is the prevalence in successful
scientific computing of certain mathematical or statistical models. Not only were the conceptual theories
well established before computers entered the scene
but the models used to describe those concepts and the
approaches taken to solve them were also well established. For example, finite difference approximations
of partial differential equations. We have always
quickly exhausted the capacity of the machines we had
to solve those problems in that way but we have not
become frustrated because technology advanced rapidly
enough to keep the game interesting. We have made
substantial advances in discovering faster, more efficient algorithms for carrying out these processes and
in understanding convergence and stability but basically
we have worked, not only in the same conceptual but
also in the same procedural framework that was common with desk calculators. (l\10nte Carlo techniques
might be thought to be an exception. I think not. As
with many things, computers made those already established techniques more effective.)
Now a new line of thought is beginning to emerge.
I am aware of it in meteorology but it may be present
elsewhere. Computers have enabled us to undertake
"ab initio" calculations which could never be approached before. (Indeed, some chemists now believe
that their theory is so sound and their computing
techniques so accurate that they can place as much
faith in the results of a calculation of a possible molecule
as they can in an experiment. They have some substantial basis, as is evidenced by the story of the noble
gas compounds but it reflects an interesting shift in
attitude.) This ability has enabled us to undertake
prediction with an accuracy never before possible and
the long range weather forecasting which has become
part of our daily lives is an outstanding result. But,
perhaps we are beginning to push the limit of that
ability using standard techniques. The predictive
power of a given mathematical model rests ultimately
upon the completeness and accuracy of the physical
data we can provide even if the model is in principle
perfect and we have infinite computing power. At some
point, decreasing the size of the mesh or increasing the
number of layers in a three dimensional atmospheric
model multiplies the computational steps required
without yielding a commensurate increas3 in useful
results. It has been suggested that in atmospheric
circulation problems, computers may be bringing that

limit within sight. A couple of weeks may be a limit
beyond which the model diverges from reality because
of limitations in physics, not computing.
This observation is suggestive. The problem has been
recognized before and some computer scientists have
studied significance arithmetic schemes to provide
continuous knowledge of the significance of quantities
throughout a calculation. This work has not yet entered
into practical applicatjon but interest may revive in it
as we find ourselves pushing the limits of data accuracy
more frequently. If true, it will offer a rich field for
research relevant to computer users.
But the observation is also interesting in another
dimension. I t would be surprising if a conceptual
theory can find mathematical expression in only one
model or if that model can be solved in only one way.
It would also be surprising if we have already chosen
the best model for all situations. In atmospheric circulation, some of the questions one wants to raise may
be answerable from a turbulence model which is statistical in nature and leads to a different computational
problem. This could be a better way to obtain some
results than solving the general field equations.
This phenomena is not new. Scientists have always
reformulated models and changed approximations
when they were unable to make further progress with
one particular line of attack. Instead, the last twenty
years have been unusual. Computers have increased the
power of certain traditional lines of attack so much
that we are only now approaching their limits. As we
reach those limits, more attention may be paid once
again to alternatives and to the real significance of the
numbers we compute.
Finally, this set of characteristics of successful
scientific computing can be helpful in anticipating the
near term impact of new developments. They suggest
that the most likely effect of technology will be to
help scientists do better the things they already know
how to do, perhaps, even stronger, the things they are
already doing. Before discussing specifics here, however, it is necessary to make note of a new current
which is beginning to influence the computing environment. While scientists and computer manufacturers
each followed their own independent but mutually
reenforcing interests, a third community, the community of computer scientists, was gradually emerging.
This is the community whose imagination is captured
by the intrinsic interest of complexity, systems, arid
computers and it is largely populated by bright young
people who grew up with computers as a background.
To the extent that computers have broken tradition,
these people have the advantage of growing up with
fewer ties to the old traditions. This community is nQw
taking shape and beginning to find things to say which

Interplay of Computer Science and Large Scale Scientific Calculations

have relevance to both scientific calculation and
computer design.
Neither the computer manufacturers nor the computer users have had much interest in computer
science. They have been preoccupied with technology
and have strongly flavored the definition of the term
"computer science" with their own interests. For this
reason it may be necessary to define more precisely
what I mean. To some degree, one man's science may
be another man's technology and neither can live in
good health ",ithout the other. This is especially true
if one looks at the actual occupations of people who
call themselves scientists, the things they really do
with their time and energy. The term science, however,
has a commonly accepted meaning which involves the
discovery and formulation of generalizations or principles that can be expressed in models describing phenomena. Computing has focussed attention on
phenomena which are as old as man but which have
been taken for granted; phenomena concerning information, complexity, and the processes for organizing,
describing, and analyzing. Computer science is addressing itself to these phenomena. Its success will have
meaning for all who are concerned with computers.
The conduct of computer science research is also
interesting. There is reason to believe that it must be,
at least in part, essentially complex and involve the
concerted effort of research teams. Professor Jack
Schwartz, of New York University, has used an
analogy which I find fruitful. He notes that mathematics is a solitary occupation which can be compared
to diamond mining. One digs through large quantities
of dross but in the end one finds a jewel which is small,
beautiful, and can be easily admired by all who have
eyes to see. Computer science, on the other hand, is
comparable to coal mining. One handles comparable
or greater quantities of material but none of it can be
thrown away. Everything must be preserved for use
and the process is intrinsically complex. This does not
preclude generalization and the discovery of principles
but it does say something about the process of finding
them and about the description of them which gives
them meaning.
With this preamble, let us return to the consideration of new technology. There are several things which
come immediately to mind. They cannot really be
separated-each influences the others-but you can
construct your own feedback loops.
(1) Machine architecture
This has already been discussed. The new architectural ideas which may affect large scale scientific
computation within ten years are already being built

41

in hardware. The long lead times involved make it
almost certain that the impact of other ideas will not
be realized in that time frame. New contributions
inspired by the machines now being built will increase
rapidly as those machines actually become available,
however, and will influence their use. These will be
in the areas of problem formulation, analysis of algorithms, data management schemata, operating systems, languages, and file management. I hope these
machines will be available for computer science research. I think they cannot be properly evaluated
without it.
(2) Solid state memory

It appears likely that we will soon have memories
available which are comparable in cost to present core
memories but comparable in speed to logic. This will
change one of the parameters of machine design which
has been nearly constant throughout the history of
computers, the ratio of memory time to logic time,
from about 100: 1 to about 1: 1. It would be most
surprising if this does not have some effect. Programming would seem to gain a new degree of freedom. One
possible effect may be more effective specialization of
machine function without specialization of machine
design. Floating point arithmetic might be programmed
again, not wired, for example, to give greater flexibility
of word size and significance arithmetic may have a
better chance for effective implementation.
On the other hand, the forces influencing change
are numerous, subtle, and complex. It is very difficult
to forecast but fascinating to watch as events unfold.
The foregoing statements assume that it is easier to
program than to build machines. But one can also
imagine ways in which this same memory development,
with proper inspiration and motivation, might lead to
simplifying the fabrication process. Modular building
blocks for machines and systems of machines might
then become part of our standard repertoire.
(3) Algorithms
This is an area where computer science will give us
an undisputed benefit. Theoretical limits on the speed
of algorithms will provide measures against which
to compare performance and will inspire improvement.
Analysis and classification of algorithms will begin to
give formal structure to programs and guides to optimize design of both programs and machines. From this
area will come the indispensable tools for understanding
the information processes which are possible for us to
use in solving problems.

42

Spring Joint Computer Conference, 1972

The benefit will be felt, not only in increased performance on our present problems, which may be
significant or not, but in providing us with constructive
procedures for thinking about the information processes
appropriate for our problems. It may seem facetious to
suggest that the science of algorithms will usurp the
role of calculus and numerical analysis as the primary
tools for description and problem solving. It certainly
is premature. But I will be interested to see what our
attitude is about this at the end of this decade.
(4) Languages
In the short history of large scale scientific computing
we have relied primarily upon one language, FORTRAN, and have accepted its limitations in the interest
of pursuing the scientific problems at hand. Again, it
has been the case that other languages migh t provide
an incremental gain but that has not been worth an
incremental effort by scientists to learn, to use, or to
develop. Improvements have been made and will continue. Computer scientists are developing automatic
code optimization procedures which may help performance and, perhaps, debugging. Monitoring schemes
and performance measurement studies are making it
possible to do time analysis of programs to increase the
efficiency of codes. Factors of two, three, ten, or sometimes fifty improvement result. But with respect to
learning languages, the scientific community has been
conserva tive.
N ow we may be reaching another kind of limit.
Programming is a human effort involving a long chain
of people and events before a complete program can
be made to work satisfactorily. Programming time
and the irreducible error rate at each step of the process
places a practical limit on the growth of complexity of
programs, generally by making the cost or time required to achieve a certain degree of complexity greater
than we can, or want to invest. In spite of large programming investments and outstanding successes we
are all aware of these limitations, and have had the
experience of thinking of interesting programs which
we were unwilling or unable to write. More significantly,
some of the programs we have already constructed
are maximally complex for our resources. FORTRAN
is becoming a restraint that can be felt.
It is clear that this restraint can be relaxed since
this is an area in which computer science has made
progress since FORTRAN was developed. Iverson's
APL, for example, is indicative as is Schwartz' SETL.
In still another direction, Hearn's REDUCE is building
a record of accomplishment. Within a decade, scientists
will be multilingual and have greater freedom for
scientific research as a consequence.

Another problem in the general area of languages
which computer science is attacking is the problem of
transportability of programs from one computing environment to another. Gradually, the structure of
programs, compilers, and operating systems is becoming clear. We are learning how to isolate the essentially machine dependent portions of codes, and to
bootstrap a system with minimum reprogramming
effort. The benefits of this development are already
being felt in economy of programming effort when
changing machines. Ultimately, it may make an important contribution to scientific communication by
making it feasible to exchange codes.
(5) Communications
This may make the most significant change in our
daily working environment and seems to have large
momentum, with stimulation from many sources. The
National Bureau for Economics Research Center,
which I mentioned earlier, is being estabHshed with
remote operation in mind from its inception. So is the
CDC-7600 installation at Berkeley for high energy
physics. ILLIAC IV, at Ames, will soon follow and it
_ seems likely that other centers for specialized disciplines
with planned remote operation will soon appear.
The trend seems natural and inevitable. Research
computing involves not only a computing machine but
also a corpus of appropriate programs and an operating
policy favorable to the work. Finally, and perhaps most
importantly, it involves a group of scientists and support staff which can work well together and communicate freely to develop the research methodology.
The success of this organization for research has been
demonstrated in the national laboratories. It is not
surprising that it carries over to computing with communications providing the means.
At the same time, this mode of operation is a departure from the organization of research computing
which developed during the fifties and sixties when
each institution built the local, general purpose computing capability which would best satisfy its overall
staff requirements within the limits of its resources.
This change requires an adjustment by all parties
concerned and the transition will take time to accomplish. It will be interesting to see what changes in
our working environment and relationships result.
These are several technological changes that may
affect scientific computing in the near future. Others
should be included, also. The availability of large data
files, improvement in man-machine interaction, progress
in data representation (including the question of what
data should be stored and what should be reconstructed), and others will have a significant impact.

Interplay of Computer Science and Large Scale Scientific Calculations

Yet each of these seems likely to have effects which
are rather specific to particular fields of research, in
the near term, and little influence common to all fields.
Color graphics may be an exception.
One other project, which NSF is undertaking, should
also be mentioned. That is a cooperative effort among
several universities and national laboratories to analyze,
certify, and document standard subroutines. The
resulting library should give us greater basis for confidence in results and less trauma in carrying out
research programs involving computing.
Before closing, I would like to mention the problem
of publication. Scientific computing has labored under
a handicap because it has not been possible to publish
programs. A number of factors are relevant but I am
not sure of their causal ordering.
(1) Attitude

Programming has been considered necessary but
menial even though it has been the principal occupation of many scientists in terms of time and energy.
(2) Language

Mathematics has a language which is concise and
makes the intellectual content clear. Often, the best
description of a FORTRAN program is the program
itself which is neither concise nor clear.
(3) Utility

A mathematical analysis of a theory or experiment
can be universally understood, generalized, and used.

43

A program is typically obscure, specific, and almost
universally useless.
The belittling attitude toward programming, which
is another carry-over of tradition, has certainly inhibited any attempt to solve the problem but failure
to overcome the other hurdles does not encourage a
change in attitude. It is a classical example of an
impasse, one which natural scientists will not solve
within the framework of their own disciplines.
It may be that computer science will make an important contribution here by developing the basis for
describing and communicating programs in a really
useful and general way. If that results, the benefit to
science of improved communication may be great. It
is interesting, though, that the path to this accomplishment will have been through byways such as automata
theory, formal languages, perhaps set theory, the study
of algorithms, and the structure of machines which
have almost no discernible relevance to physical science.
We have seen that although progress in large scale
scientific computing has been surprisingly rapid, it
has also been bound by tradition. We have also seen
that there is a long time constant in developing and
absorbing technology. Both of these facts tend to
become obscured by the activity around us but together they will continue to shape the near term future.
At the same time, a new influence is emerging through
the development of computer science which may provide the means to relax the constraints of tradition and
expand both our conceptual and procedural horizons.
The time scale for fundamental change, if it occurs,
can be expected to be long but a decade may reveal
the strength of the trend. It will be interesting to watch.

Computer architectllre and very large prohlems*
by R. B. LAZARUS
University of California
Los Alamos, New Mexico

large problems, though important, command only
limited funds.
Let us start by considering the role of logic elements.
They differ in cost, speed, size, power dissipation,
sensitivity, and reliability. In many cases, there are
inherent trade-offs among these properties. Let us
imagine an omniscient computer designer who has in
mind all possible computer architectures-no, make
that all possible computer designs-and who has full
knowledge of all available logic elements. For all
possible designs implemented with all available types
of element, he wants to find that combination giving the
maximum speed, subject only to the restrictions that
speed-to-cost ratio be not much higher than what is
now available and that the computer have a mean time
to failure of many hours.
He would immediately realize that the problem is not
well defined. He would ask what kind of calculation he is
to maximize the speed of, and be told, "Large problems,
as defined above." Noting that such problems have
"large numbers of variables," he would fold into his
task the consideration of the various kinds of memories
available. He would then come up against the following
major architectural problem.
Define access time as the time which must elapse
between a decision to fetch an operand from a given
address and the arrival of that operand at the desired
function unit. Then, for all large-memory technologies
today, the access time is long compared to the achievable average instruction execution time. (In other
words, you can't win by rebuilding the IBM 704 with
modern components.) What can be done? There
appear to be only two things to do. First, one can try to
minimize the number of operand fetches required during
the solution of the given problem. Second, one can overlap the fetching of operands, both with each other and
with computation.
It is interesting to ask whether these two things are
in conflict with each other. For machines with internal

For the purposes of this paper, "very large problems"
are defined by two properties: (1) There is an effectively
unlimited amount of physics and of spatial detail
which it would be useful to include if practical; and (2)
the calculation must be completed in a limited number
of hours. The best example is perhaps the global weather
problem. We will obviously never put in all the energy
sources or all the topography and we must obviously
calculate faster than real time.
Such problems need big machines in the sense of
operating as rapidly as possible on large numbers of
variables which describe or pertain to a single region of
space. It is the aim of this paper to consider questions
of computer architecture in this context.
The questions of primary interest are (1) what
computer architecture is best for such problems today,
and (2) what architecture may be best ten years from
now. These questions will not, in fact, be answered.
The following comments may, however, indicate why
the first question is unanswerable and help others in a
search for the answer to the second.
To keep the problem within a reasonable scope, it will
be assumed as a boundary condition that the cost per
unit of arithmetic of the ideal computer for large
problems must not be substantially greater than the
cost per unit of arithmetic of, say, an IBM 360/195 or
a CDC 7600. This assumption is intended to exclude an
architecture which offers a factor of n in speed if the cost
is up by a factor of, say, 3n. This admittedly excludes
an interesting area; if, for example, it becomes necessary
to control Los Angeles air traffic by computer and the
best available computer is too slow by a factor of three,
then it would certainly be interesting to know whether
the necessary computer could be built for a cost up
by a factor of nine. Nonetheless, the restricted question
would appear to be of sufficient interest, since many

* This

work performed under the auspices of the U. S. Atomic
Energy Commission.

45

46

Spring Joint Computer Conference, 1972

addressable registers, good coders (and compilers)
exploit the first; by clever use of the registers, they try
to minimize the number of times a given operand is
fetched. For the upcoming vector machines, on the
other hand, good coders will try to exploit the second;
they will maximize overlap by favoring the vector
commands, which stream operands from memory as
fast as the memories and memory buses permit.
Is there, then, a conflict or not? There is a conflict
only so long as the restriction on gate count (which may
come from cost, size, power, or reliability) prevents us
from having the best of both worlds. Here is precisely
where the question gets so sticky. Are we discussing
today's practical problems, or are we looking for fundamentals? This matter will be touched on again below.
In passing, it might be noted that this problem of
long access time cannot be solved merely by development of a very fast memory, because transmission times
for address and data would still be long. It is no help
to postulate a general scaling down of the whole computer, so that all function units can be very close to the
memory, because this will scale down the instruction
execution time as well. A very restricted solution is
suggested in the Appendix, but just for fun, since it
certainly cannot be achieved within the next ten years.
The long access time should probably be accepted as a
fact of life.
At this point, our omniscient designer might note
that, while memory access times are inherently long, it is
relatively easy to achieve high bandwidth by a variety
of methods. He might then pause to consider the
methods appropriate to various architectures and note
advantages and disadvantages.
The first technique uses a memory word which is two
or more machine words in length. In all plausible situations, the number is a power of two and the machine
words have consecutive effective addresses. For a
given memory technology, this increases potential
bandwidth as long as the read time increases more
slowly than the size of the memory word. Whether or
not it increases realized bandwidth depends on the mean
number of useful machine words which are acquired
by a fetch of a memory word. The technique is obviously
appropriate for instruction fetching and for feeding
streams of consecutive operands to a vector machine.
With many independent memory boxes (see next
paragraph), the technique is· also quite powerful for
most "naturally occurring" codes, if the boxes have fast
registers to hold the last memory word fetched, or in the
presence of a "cache" memory as in the IBM 360/85
and 195.
The second technique uses interleaving of many

independent memory boxes. We may assume with no
loss of generality that the number of boxes is a power
of two and that they are interleaved on the low order
bits of the memory word addresses. This technique is
also obviously appropriate for feeding streams of
consecutive operands to a vector machine. Let us
examine the behavior of such a memory for a sequence
of fetches from random addresses; for simplicity, assume
there is only one machine word per memory word.
Suppose we have an infinite list of random addresses,
a clock, and the logic to pass one address per cycle
to the appropriate memory box. If the order in which
the fetches get accomplished is irrelevant (and if we
have sufficient logic), then our steady state will either
be one fetch per clock cycle or else all boxes working to
capacity, depending on whether the clock is relatively
slow or relatively fast compared to the memory cycle
time. In either event, that steady state will constitute
maximum available data rate.
If our list has precedence relations (as it certainly
must when we mix in stores as well as fetches), or if we
do not have facilities to queue up an arbitrarily ~ong
list, or if we do not have the logic to scan an arbitrarily
long list in one clock cycle, then we wHl have conflicts
and loss of data rate. It is probably not fruitful to
derive results for random addresses, since there is a
great deal of correlation in real cases.
It is worth noting that additional processors may be
able to share a memory "for free" whenever a single
processor leaves most boxes idle most of the time. Such
idleness could be because of a relatively slow clock cycle
or very many boxes, or it could be because of too many
precedence relations in the work of a single processor
(assuming that multiple processors have no, or at
least negligible, precedence relations among each other).
The third technique uses separate memories serving
separate processors. This is the technique of the
ILLIAC IV, where each memory-processor pair works
on a separate portion of the large problem. The potential
bandwidth is simply the product of the number of
such pairs and the bandwidth of an individual pair.
The realized bandwidth is less by the mean fraction of
processors doing useful work.
By this time, our designer, being merely omniscient
and not divine, has developed a headache. He returns
to his consideration of logic elements, having in mind
that there are several ways to get whatever bandwidth
he needs from memory. He takes a quick look at the
possibility of using the best of everything. He imagines
a design of eight super-processors with independent
instruction streams, where each super-processor consists
of 64 slave processors, each combining the arithmetic

Computer Architecture and Very Large Problems

capabilities of a '7600 with vector streaming capabilities.
Before bothering to add up the price, he sees that the
mean time between failures will be a few minutes.
Concluding, then, that he must compromise, that he
may use only a subset of the techniques which enhance
speed for certain kinds of work, he realizes that his
problem is still not well defined. He calls in a friend who
knows all about programming, numerical analysis, and
applied mathematics. He asks for guidance on the fundamental arithmetic and data flow requirements of the
large problems under consideration.
Unfortunately, his friend points out two difficulties.
First of all, there are trade-offs between the amounts of
arithmetic and the amounts of· data flow, at both the
programming and mathematical levels. Second, the
properties of any important computer which may come
into existence will themselves influence the development of mathematical techniques.
The second point is brushed aside, and a new problem, this time well defined, is stated as follows. For all
possible computer designs, implemented with all
available types of element and applied to today's large
problems with all well-known mathematical methods,
which combination of design, implementation, and
calculational method gives the fastest solution, subject
again to cost and reliability restrictions?
Perhaps these gentlemen are busy somewhere
solving this well defined problem. Unfortunately, they
have not been heard from, and the problem is too
difficult for ordinary mortals. What should be done?
What actually has been done in recent years is as
follows. Various designers have chosen some mediumsized area in the design-implementation space, looked
for a local optimum with respect to some set of pieces of
problems, and proceeded to create a computer. During
the creation time, mathematicians have made some
exploration of the calculational method (and programming technique) space by analysis and simulation.
After creation (if successful), programmers can be
expected to find quite rapidly the actual optimum with
respect to programming technique; over the years, the
mathematicians will also move us steadily toward the
optimum with respect to calculational method. In this
way, points are located empirically in the space of
interest, namely the design-implementation-method
space.
It is time now to look more specifically at the present
state of affairs. Consider the approximately 16 year
interval between the IBM 701 and the CDC 7600. A
typical large problem ran for about ten hours on the
701; a typical large problem runs for about ten hours
on the 7600. The ratio of work being done is perhaps

47

1000; the cost ratio is perhaps five, leaving an improvement factor of 200. Most of this factor, which amounts
to 40 percent per year, comes from raw component
speed. The rest comes from improved design (architecture, if you wish), including floating point arithmetic,
index register~, parallel input-output, sophisticated
arithmetic engines, and, finally, parallelism among
instruction decoding, addressing, data flow, and
arithmetic. Most of what came from improved design
was again due to improved component technology,
being obvious enough in principle but requiring large
component counts which, in turn, required cheap, small,
reliable components. For the large problems, not very
much at all, up through the 7600, came from what we
would now like to call really new architectural concepts,
like vector arithmetic, multi-processors, or parallel
processors.
The reason why architecture has apparently played
so small a role, to date, for large problems is precisely
that 40 percent per year is very big. If implementation
of a substantially new architecture requires a 50 percent
increase in cost and a two year delay, one is giving
away a factor of three to begin with. Furthermore, if
the architecture moves us away from the optimum in
method space (i.e., if new methods and/or reprogramming is required), one gives away a further factor;
it is generally considered that at least a factor of four
must be anticipated in order to motivate a substantial
change in method or program for a large problem.
To say this again in other words: As long as 40 percent
per year improvement keeps coining along "for free,"
the short term needs of the large problems under consideration here do not motivate a substantial architectural
change unless the anticipated speed improvement is
substantial. "Substantial" means a factor of four in
speed-to-cost over the competition after correcting
for delivery date at 40 percent per year, compounded.
There are, nonetheless, motivations. The first is the
need to shift onto a more rapidly rising curve, if there is
one, even if one takes an initial loss to do so. If routine
improvements will come at a greater rate with some new
architecture than with old architectures, then the short
term loss from making the transition will eventually be
overbalanced.
The second and more important motivation is the
need to explore the design-implementation space in
order to get ready for the time, which must come
sooner or later, when nothing approaching 40 percent
per year will be available in the implementation direction. The trouble is knowing where to explore, and
how much to spend on such exploration.
To begin with, it must be noted that the manufac-

48

Spring Joint Computer Conference, 1972

turers will continue to explore, through actual construction, architectures which look profitable. Although the
nature of the expanding computer market is such that
architectures will not look profitable if they are only
good for large problems of the type considered here,
some light will nonetheless be shed on our question
of the best machine for such problems. It will not be
shed optimally, but it will be shed, in some sense, for
free.
There is a key difference in the importance of time
between the commercial interest and the computer
science interest. In the fullness of time, it will make no
significant difference to computer science whether
something was achieved a year or two earlier or later.
But it can make quite a substantial difference to the
company which achieves it first.
All in all, this author sees no valid basis for criticizing
the nature of the action within the private sector. On
the other hand, it will be appropriate from time to time
for the Government to underwrite exploration of
important areas where the chance for profit is too far off
to attract private industry. Some comments may be in
order on how such exploration should take place. The
particular question of interest to this author is whether
the exploration should rely on simulation or on machine
construction.
Some years ago it was argued plausibly that the
effective speed, for real large problems, of a new
architecture could only be determined by implementing
that architecture in a real computer as big and fast as
anything else available. The argument was that only
then would the appropriate people be motivated to
optimize methods and programming. This may well
have been true some years ago, but it is probably not
true now. Two relevant things have increased in the
last few years, namely the ability to do simulation at
reasonable cost and the number of unemployed
scientists.

CONCLUSION
To find the best computer, one must explore the space
of computer design, componentry, mathematical
method, and, programming technique. For a given
computer design (or, at least, architecture), there has
been substantial progress from improved componentry.
This progress will continue for some time, but not
forever. There has also been substantial progress from
improved methods and programming techniques. This
progress will also continue for some time, quite possibly
forever.
On the other hand, one cannot say that, for a given

componentry, there has been or is about to be substantial progress from improved architecture. Part of the
reason is that the 40 percent per year of progress which
has been available without architectural change puts
a handicap on any development which requires more
time (because it is breaking new ground) between
choice of components and delivery. The rest of the
reason must be that no new architecture has
been invented which offers an order of magnitude
improvement.
Some day, the rate of increase of component speeds
must become small. At that time, architectural changes
which give small improvements in performance will be
profitable. In this area, it seems safe to assume that
exploration by industry will be adequate.
If, on the other hand, as seems likely, the practical
limit on gate count goes up by several orders of magnitude, substantial improvement will be available from
architectural changes, and only from architectural
changes.
It is on this basis of very large gate count that architectural exploration will be needed, in the opinion of the
author. If such exploration is to be carried out bel'ore
the large gate counts are actually available, it must of
course be done by simulation. The right time to begin
is probably about ten years before the results are
needed. Is that today? Was it, perhaps, a few years
ago?

APPENDIX
If a memory technology came about which could
give one function unit very fast access to all the words
in a large memory, if there were an architecture with a
crucial need for such very fast access from n function
units, if such access to a small (e.g., register) memory
were already in hand, and if the memory technology in
question were so cheap that one could afford n-fold
memory redundancy, then one might consider the
following.
Let each function unit have its own memory, and
let each memory start out with identical contents.
Define two types of storing, A and B. A Type A store
is the ordinary type, in which, logically, the old value
of some variable is instantly replaced by the new
value. A Type B store goes only to "empty" cell (i.e,
it replaces dead, or garbage, information) and the
information is not going to be refetchable for a long
time. Then require all problems to restrict Type A
stores to the small memory and make only Type B
stores to the large memory.
Many readers will lose interest at this point; there

Computer Architecture and Very Large Problems

are, nonetheless, many large problems which fit these
rules. What is proposed, obviously, is that Type B
stores be propagated from memory to memory at
leisure. The whole thing would likely be of interest only
if this propagation came from a natural diffusion
inherent in the physics of the memory. For example,

49

imagine that the binary storage element is a cell in a
long filament. The filament is stable with all its cells
zero or all its cells one. If any cell is changed, the
change propagates along the filament in both directions.
Each function unit gets at all the filaments at some
convenient station along their length.

Scientific applications of computers in the '70s
by M. STUART LYNN
Rice University
Houston, Texas

was required was another substantial injection of
federal or other support to achieve the necessary
breakthrough. In application after application a
similar pattern was followed: early promise with highly
simplified models indicated great things to come, only
to be followed in time with the limitations of reality,
as the complexities of highly nonlinear or otherwise
complex problems and indeterminate data circumscribed the bounds of possibility. The debris left behind in many of the goldfields became depressingly
familiar.
N ow we no longer attempt fifteen decimal places.
We talk instead of provoking lines of thought which
might not otherwise have occurred. This is probably a
healthy trend, although it is perhaps unfortunate that
we are still not learning from the past in some newer
application areas.

It is still fashionable to predict that what happens
in the future of computing will be a glorified extension
of what has happened in the past. Thus, the last decade has seen an explosion in all uses of computers
and therefore, so the fashion would dictate, this explosion must necessarily continue if the faith is not
to be shaken.
There is no doubt that exciting new ways of putting
computers to work will be found. This writer is in no
better position than anyone else to forecast what these
will be. It will, however, be the main thesis of this
discussion that the explosive rate of growth will not
continue, particularly in the area of scientific applications, but that the emphasis will be on making known
applications work, and work in a more meaningful
environment.

GOLDFIELDS
INDUSTRY TRENDS
The gold-rush of the sixties is over-this period was
characterized by taking a field of man's endeavor, any
field, multiplying it by three and attempting to automate it, independent of whether or not such automation could in any way be justified. Support was easily
available for anything and, as such practically every
field of man's interest was a candidate for computer
application. The fact that reality has fallen short of
promise has left a skeptical, if not nasty, taste in many
mouths. It is probably true, however, that we have
been left with a more realistic perspective as to the
meaningful uses of computers and, even more importantly, the limitations of such usage.
The gap between promise and reality is, for example,
evident in application areas dependent upon modelling
or simulation. Ten years ago it was customary to insist
that we were on the verge of modelling the world and
its component parts to fifteen decimal places; all that

In addition to the effects of left-over skepticism,
trends in the computer industry will also mitigate
against a continuation of the applications explosion.
It is certainly highly probable that the current computer overcapacity in this country, when combined
with the decreasing cost/performance curve of computer systems, will cause considerable pressure on the
industry to underwrite nmv applications as a means
of supporting continued expansion of the industry.
However:
• I t is likely that the most acceptable applications
will be those whose economic pay-off is readily
justifiable in the short-term, in view of past management experiences and of the current economic
climate. This would tend not to favor scientific
applications.

51

52

Spring Joint Computer Conference, 1972

• The effects of unbundling have already moved
the onus of applications research and development
more than ever on to the end-user. This will
continue. Whereas this has little impact on the
traditional user of computers, it reduces the prospects of important uses of computers materializing
among new user classes.
• The increasing pressure for rapid economic justification lessens the changes of serendipity yielding
new applications. The principal opportunities for
serendipity will continue to move back to the
universities; this is probably not a bad thing, except that universities are not always in the best
position to judge user needs over the long-term.

WHAT WILL HAPPEN?
This writer suggests that the following are likely to
be characteristic of scientific applications of the next
decade:
(1) The areas of application familiar today are
unlikely to change substantially. The relative
emphasis between areas is, however, likely to
change as a reflection of society's changing
priorities, as has already been observable over
the past three years. Thus, for example, as a
reflection of NASA's changing priorities, the
use of computers in support of this nation's
activities in space will shift toward the many
possibilities involved in applications relating to
the Earth Resources Program, a shift that has
already begun to take place. Again by way of
example, the ability to simulate ever more
complex molecules and chemical reactions will
have important applications in the petroleum,
chemical and pharmaceutical industries.
(2) Basis technological developments in support of
applications will not mature at anywhere near
the pace of the sixties. The emphasis will shift
toward making fuller use of existing technologies and in making them support each other.
Thus, for example, the concern of the sixties for
speed and compactness in algorithmic processes
will have diminished importance in the complex
environments of present and future operating
systems and as the cost of computing continues
to decrease. On the other hand, the unnatural

boundaries between such areas as numerical
analysis, mathematical programming, computational statistics, signal analysis, pattern recognition and control theory will continue to become
less well-defined.
(3) There will be more emphasis on total systems
implementation of known applications so that
they are economically (or otherwise) useful to
the end-user. This will include careful exploration of computing environments in order to
minimize overall costs and to maximize, inter
alia, user productivity and convenience. In this
context there will continue to be an increasing
emphasis upon reliable systems. Substantial
investment in research and development of
scientific computer applications will be closely
geared to their proven practicality and utility
in society as a whole.
(4) Basic methodologies already well understood
in established application areas will be brought
to bear upon newer areas. Examples of this are
to be found in the electric power industry and
in water estuarial modelling where only too
often the simulation techniques currently used
are primitive by comparison with what has
been developed in other application areas.
(5) The computer will continue to be brought to
bear, only with ever increasing emphasis, in
making the scientific research process itself
more efficient. Advances in the technology of
interfacing with computers will become sufficiently reliable and efficient that the use of such
technology will become widespread (many
scientists use computers today no differently
than they did ten years ago, in spite of the
changes that have taken place). The ability to
interact efficiently with large data bases, the
growth of extensible languages, the develop·ment of special processors configurable by the
user to meet his particular requirements, are
examples of technologies which will have an
impact upon ways in which scientists use computers.
This appraisal is not intended to be pessimistic.
Within the above confines, the opportunities for using
computers in exciting ways should be as great, if not
greater, than ever before. The challenge, however, is
one of turning more of the promises of the past decade
in to accepted reality.

The functions and elements of a training system
by B. A. JONES
Bankers Trust Company
New York, New York

"From a systems point of view, the design of an
operation which can successfully carry out the training
function becomes a problem of creating a system to
accomplish a given end result or objective. In the case
of training, this end result is to effect a group of planned
and predetermined behavior changes in the organization.' '1
The following are five basic functions that I feel are
essential for an effective training system that will allow
you to effect that group of predetermined behavior
changes:
I.
II.
III.
IV.
V.

3.
4.
5.
6.

Is this
Is this
Is this
Is this

an attitude problem?
due to a lack of resources?
due to a lack of reinforcement?
a procedures problem?

When this element of the training analysis has been
completed, the suggested solution to the initial request
or desired end result may be made. If the suggested
solution is to develop a training curriculum, the third
element in the training analysis, that of stating the
terminal behaviors, begins.
Once this has been accomplished, the design of the
training curriculum proceeds. It is at this point that
the cost of training, the length of training, the media,
the method of evaluation, may be determined.
The implementation and evaluation of the training
curriculum may end the analysis function. If the desired
end result was not obtained, it may be due to a bad
analysis or a poor design. Whichever is the case, a
reiteration through the process is essential. If the desired end result has been met, the final element is to
maintain the material. That is, if it is a one time only
curriculum, it is placed in a history file. If it is an ongoing curriculum, it is kept up-to-date.
When the suggested solution, the second element, is
not the design of a training curriculum, the Educational
Consulting function becomes crucial. Figure 2 illustrates
the elements of this function. It differs from the training analysis in that the training person acts only as an
advisor, i.e., he can suggest solutions but is not accountable for implementation or evaluation. Figure 3
lists some of the skills and knowledge necessary for
successfully performing the consultation function. The
questions asked during the follow-up emphasize the
advisory capacity of the consultant.
The third function of the training system, Training
System Support, is basically an administrative and
maintenance activity. However, the support is essential
for a training division if it is to effectively serve and

Training Analysis
Educational Consulting
Training System Support
Public Relations
Management

The elements of each of these functions become the
procedures necessary for the successful operation of the
entire training system. To better understand these five
basic functions it is necessary to look at their elements.
The training analysis function (Figure 1) and its
elements is the critical activity in determining training
requirements.
We begin the analysis by gathering valid data. That
is, in terms of performance, what is it you want the
trainee to do that he is not now doing, or what is it you
want him to do better? Determine whether these are
basic skills and knowledge he should possess or whether
they are supplemental skills and knowledge that will
upgrade his proficiency. This may determine the priority
of training.
The second element in the training analysis function
is to address performance standards by conducting a
deficiency analysis. At this point the following determinations must be made:
1. Is this a training problem?
2. Is this a feedback problem?

53

/

54

Spring Joint Computer Conference, 1972

Sell
Interview
Problem Solving
Advise
Help
Expertise in training
Communication
Analysis
Suggestions
Persuade
Confident
Confidentiality
Patience
Sensitivity
Follow-up
-did you decide?
-what did you decide?
-were you 'successful?
-may I help you?

Figure I-Training analysis function

assist its users. The elements of this function are
exhaustless, but three of these elements are vital.
Record keeping provides an historical reference for
each student and aids in defining what courses he
must yet complete in terms of his career development.
Record keeping is of great importance also in pre par-

Figure 3-Consultation skills and knowledges

Name,_ __

Course
Date__________ _

Title____________ Phone_________ _
Uptown
Department _________ Downtown
Division_________ _

OTHER
DEPARTMENT

r----

r- - ~

~

E. D. P.

PROBLEM
ECOGNITION
(Performanc
deficiency

I

N
TRA NI G

Supervisor's signature__________________ _
Current Responsibilities: _________________ _

-,-----It-----...,
PROBLEM
DEFINITION
The following information is helpful to the course instructors and
they would appreciate your cooperation in supplying it.

AL TERNATIVE
SOLUTIONS
(Recommended
solution if
advisable)

EXPERIENCE
Number of years/months in any Data Processing Function:
Programmer________ _
Systems Analyst_______
Other (please state) __________________ _

FOLLOW-UP

I

- _____ J

EDUCATION
Check highest Degree and indicate major:
High School______ --'-__ Undergraduate______ _
Graduate__________ Ph.D._________ _
Major__________ _

Figure 2-Consultation function

Figure 4-Systems analysis and design-Enrollment form

Functions and Elements of a Training 8ystem

ing a cost per student figure, developing and justifying
a yearly budget, and forecasting resources. Figure 4
illustrates such a form.
Equipment maintenance is necessary for an effective
and efficient training facility. It doesn't matter if the
facility has only a one person training staff, a conference
room, and an overhead projector, or is a large scale
multi-media facility with a full-time training staff.
Calvin R. Gould, put it this way:
A national meeting of professional communicators was ending its second day with a banquet
that featured a learned and distinguished
individual. Before the banquet, the speaker's
assistant set up a pair of 35mm projectors
and a screen. This person would be the projectionist and would work from a cued copy
of the speech. While this practice requires
that the speaker read his material, it is more
effective than asking for each slide, and if well
rehearsed, can be professionally done. The
audience quite properly expected a worthwhile
message from the speaker, a vice president
of a large manufacturing company. They
weren't to be denied. His initial remarks,
charging the audience with their responsibility
to world communications, proved he was going
to be a dynamic speaker. As the first slide
was projected the house lights went off right
on cue. Everything was working like clockwork, even the pause that followed the first
slide seemed effective and timely . . . except
it seemed to be longer than necessary .. ,
really too long. Finally the audience, the
projectionist, and the speaker all seemed to
realize simultaneously that the speaker's
lectern light went out with the house lights.
The fifteen minutes interruption required to
recover from this unfortunate situation was
enough to seriously damage the communications effectiveness of this presentation. I was
in the audience, and I have long forgotten
the message. 2
A schedule for the maintenance of equipment must
be established, fully documented and enforced. It should
include timetables for the changing of bulbs, the cleaning of equipment, periodic maintenance checks, etc.
Inventory control is important, since in the majority
of installations the training division has equipment that
can be borrowed by other departments. The unavailability of equipment can often lead to the cancellation
of a class. The availability of existing equipment should

DESCRIPTION

SLIDE PROJECTORS

QUANTITY
3

16MM PROJECTORS

55

CONDI- AVAILTION ABILITY
GOOD

YES

GOOD

NO

16MM CAMERA (BOLEX)

1

GOOD

NO

VIDEOCORDER (1/1 & 2")

3

GOOD

31" only

VIDEO CAMERA

1

SATISFACTORY

YES

T.V. MONITORS

5

GOOD

3 only

MARK IV

1

GOOD

NO

CASSETTE PLAYER

2

GOOD

YES

HEADPHONE SETS

4

GOOD

NO

3M FOIL MAKER

1

GOOD

YES

3M OVERHEAD PROJECTOR

1

SATISYES
FACTORY

PORTABLE SCREENS

GOOD

YES

6 FOOT MIC

GOOD

NO

GOOD

NO

GOOD

NO

NECK MIC

1

MARK V
35MM CAMERA
MP-3 CAMERA

1

REPAIR NO
GOOD

NO

Figure 5-Inventory and status report

be documented by an inventory and status report
form. Figure 5 illustrates the form used at Bankers
Trust.
The Public Relations function has two distinct elements. Within the organization, communication is with
users of data processing training. The promotion of
in-house courses and the selling of services are necessary
in order to establish and maintain credibility. The
external element is, on the one hand, to let the rest of

56

Spring Joint Computer Conference, 1972

FORECASTING

1
SET OBJECTIVES

1
ESTABLISH
PROGRAMS TO
MEET OBJ.

1
SCHEDULE
PROGRAMS

.1

WHAT'S TO DO

ALLOCATE
RESOURCES:
PEOPLE, MONEY,
TIME

1
GROUNDS RULES
HOW TO DO IT
PROCEDURAL
STANDARDS OF
REPETITIVE TYPE
WORK

SET
POLICIES

1
ESTABLISH
PROCEDURES

expert in management philosophy or management development, yet find it necessary to manage a training
system, I offer the following descriptions of the four
elements in the management function from Louis A.
Allen, president of Louis A. Allen Associates, Inc.
1. Planning
"Planning is the work a manager does to master
the future. Planning requires that a manager
think before acting. In the process of doing this,
he will map out beforehand what he expects to
accomplish, how he can best do it, and the limits
of cost and other factors that are significant.
The principles of planning stress the importance
of current decisions in limiting our potential
range of action in the future.
They point out that the further we project a
plan into the future, the more unstable and undependable it becomes. A key principle emphasizes the tendency of people to resist changes.
Resistance to change can be overcome primarily
by providing for participation and communication in the planning process. Plans are considered
in terms of the specific activities of forecasting,
establishing objectives, establishing programs,
scheduling programs, allocating resources, setting policies, and establishing procedures." 3
Figure 6 illustrates how our training staff at
Bankers Trust interprets this element.
II. Organizing
"Organizing is the work a manager does to arrange and relate the work to be performed so that
it can be carried out most effectively by people.
An organization is not people but the mechanism arranged to enable people to work most
effectively together. An organization chart is
helpful but the chart itself is not the work of

Figure 6-Management function planning sub-function
ADMINISTRATION
&

the world know what your organization is doing, and, on
the other, to make sure that you yourself are not re-inventing
the wheel.

The fifth function, that activity which permits the
combination of time, people, and money to efficiently
achieve the desired end result, is the Management function. It has four major elements: Planning, Organizing,
Leading, and Controlling. Within each element are
specific activities.
Since most data processing training staffs are not

SCHEDULING

Figure 7-E.D.P. training division

Functions and Elements of a Training System

organizing, for this is how one insures that the
most work is accomplished by the fewest people
at the least cost." 4
Figure 7 illustrates the organization of our training
division.
III. Leading
"Leading is the work a manager performs to get
people to take required action. Leading is the
energizing function that makes planning, control, and organizing possible. In studying what it
takes to lead, we find that there is no one best
management personality. The proper blend of
authoritarian and democratic leadership knowingly applied is best. The specific activities
within this function are decision making, communications motivating people, selecting people,
and the development of people. We are at the
present time within our element of control. A lot
of work has yet to be accomplished so that these
two elements of management will relate directly
to our responsibilities."s
IV. Controlling
"Controlling is the work a manager does to assess
and regulate work in progress and completed.
The control is the manager's means of checking
up.
While control by personal observation is often
necessary, the most desirable method is control
by exception. Here the principle of Least Cause
and the principle of Point of Control are important to ensure that the greatest amount of
control is applied where it will do the most good.
The significant activities inherent in good control
are establishing performance standards, performance measuring, performance evaluating,
and performance correcting." 6
It is apparent that, due to the sheer length of the
process, a training staff of more than one is desirable.
However, given that the training needs are clearly defined and not too abundant, and that time and money
are available, such a process can be implemented effectively by a minimal staff. To a great extent, this is
due to the increasing availability of vendor-supplied
training materials, and also to new, multi-media techniques for its presentation.
To properly select media that will meet training objectives, one must understand the advantages and disadvantages of each. The most commonly used (and
misused) media are the spoken and written word.
Several studies have indicated that we retain only 20
percent of what we hear. It has also been cited that the
average student possesses a reading level of eighth grade

57

or lower. Therefore, it is necessary for the trainer to
know his students' abilities and to adjust his communication methods accordingly.
The studies on learning further suggests that we retain 80 percent of what we see and as much as 95
percent of what we both hear and see. Thus, it appears
that a lecture supported with various media would
allow us to satisfy our objectives in the most efficient
and effective manner.
It has been my experience, being fortunate enough to
have access to a very sophisticated multi-media training facility, that the integration of various media into
our training system has accomplished several things:
1. This integration makes use of two or more senses
and
2. More easily establishes a relationship between
the unknown and the known.
3. Often, visuals can save teaching time because
they add to the student's ability to arouse and
retain interest in the subject.
4. Visuals tend to create a sense of involvement and
partici pation.
5. When color is used in visuals, the retention rate
is vastly increased.
There are certain obvious drawbacks when a training
facility is heavily involved with the use of audio/visuals.
I have stated earlier that the record keeping function is
essential in the smooth and effective operation of a
training facility; I would like to emphasize this importance when using audio/visual media. The hardware
required for the use of audio/visuals must be maintained as "Operational" at all times. It is most desirable
to have backup for each piece of equipment you are
using; the consequences are self-evident.
Staff resources must often be increased to support a
multi-media facility, e.g., for maintenance and ad.ministration. However, once standards and procedures are
developed for maintaining and scheduling equipment,
the advantages one can attain from the use of multimedia are considerable.
In summary, when selecting media for communicating to the Jearner, consider the following procedures:
1. Determine your training objectives first, then
determine the means whereby you can convey
them to the student.
2. Consider the physical constraints; how will they
affect the media you have selected? How many
students will you have at one time? Where will
they be trained?

58

Spring Joint Computer Conference, 1972

3. Determine as best you can the collective backgrounds and abilities of your students, and
which media will have the greatest appeal and
effectiveness for them.
4. Examine carefully the economics of the ideal
system, i.e., look carefully at the cost of
alternatives.

2 C R GOULD
Anatomy of a presentation
Audio-Visual Communications V June 1971 p 20
3 L A ALLEN
The management profession
New York McGraw-Hill 1964 p 109
4 Ibid p 173
5 Ibid p 246
6 Ibid p 324

SUMMARY
BIBLIOGRAPHY
A Training System (the process) is a methodology with
established functions, procedures, and activities one
can follow to effectively and efficiently achieve a desired result.
A properly evaluated multi-media system, when well
maintained, will improve the learner's ability to comprehend and retain the training supplied. This will allow
the training division to accomplish its objective, that
of giving the user of its services what he wants, when
and where he wants it.
REFERENCES
1 M W WARREN
Training for results
Reading Massachusetts Addison-Wesley 1969 p 15

L A ALLEN
The management profession
New York 1964
M M BROADWELL
The supervisor as an instructor
Massachusetts 1970
L BENNIGSON
The strategy of running temporary projects
Innovation Number twenty-four September 1971 pp 32-40
HARTMAN MATTHES PROEME
Management information systems handbook
New York 1968
o GLASER
The management of training
Massachusetts 1970
MWWARREN
Training for results
Massachusetts 1969

Planning data processing education
to meet job requirements
by JAMES O. HAMMOND
IBM Corporation
White Plains, New York

resource. If the data processing staff is selected and
trained to meet the requirements and needs of the
business of the parent company, then a data processing organization has gone a long way toward solving
efficiency problems not to mention personnel problems
and potential large cost savings that can be gained.
The staff human resource portion of a data processing
organization is the one addressed in this paper. More
specifically, ways of defining and structuring data
processing skills and job responsibilities are explained.
Approaches are included on ways of defining an education program to provide the knowledge and skills that
may not currently exist in the skills mix of the data
processing staff.
Keeping in mind that all the other key factors of
operating an efficient, productive data processing
organization have not been forgotten, concentrate
for a moment on how we might go about putting some
form and rationale to human resource selection and
training.
One of the most effective ways of relating data
processing skills requirements, and in turn DP education, to a data processing organization is to start with
the process being used to develop and implement data
processing products. Relating skill requirements to the
process is especially effective because the process is
normally a well established one with which most
company management are familiar both inside and
outside the DP organization. Since the DP process is
the mainstream around which the majority of all
other DP activities in a department revolve, it is most
likely a well defined and valid process. If the DP
department is just being organized or for some other
reason the process to be used is not well defined, then
first things should be first-the process should be
clearly resolved and defined.
The major steps of the DP process will vary from
one DP organization to another and, of course, from

The greatest single expenditure that a data processing
organization has today is for its human resource. This
has been dramatically illustrated in several well-known
studies. The cost of human resources continues to rise
in data processing. Computers and systems are becoming more -and more complex. It has become extremely difficult for programmers and analysts to
know all the essential things about a system. This is
especially true with the large, widespread teleprocessing networks. This complexity of sytems is forcing
more and more specialization in computer technology.
At the same time, small computer staffs find that although a few staff members may know all that is
required to support a system, it is frequently difficult
to identify job responsibilities in such a way that
maximum efficiency can be attained for the benefit of
the business.
Most data processing organizations have major
effects on their parent company's ability to meet the
needs of its business. It becomes of vital importance,
therefore, that the data processing or information
systems department, as they are frequently called,
be managed as efficiently as possible providing the
business support to its parent company in the most
optimum fashion. Obviously, the management of any
data processing department is an important key factor
in its success. In this day and age of national economic
lull and austerity moves in business to get more for
the dollar spent, it has become even more important
that management exercise its very best judgment at
all times to run the data processing department more
as a business and not just as a support function. In
other words, have as valid justification that the money
spent is worth what is being gained from the output.
There is another extremely important factor to
consider in maintaining a high efficiency level in a
data processing organization. This factor is the utilization of the staff employees or the bulk of the human
59

60

Step

Spring Joint Computer Conference, 1972

Example 1

I Study
II Design
III Develop
IV Install
V
VI
VII
VIII
IX
X

Example 2

Example 3

Example 4

Example 5

Concept
Definition
Develop
Acquisition
Operational

Evaluate
Concept
Definition
Develop
Operation

Determine Function
Develop System
Data Collection
Consider Alternatives
Select Solution
Formulate System
Review
Test
Install
Measure

Application Analysis
Design Synthesis
Feasibility Validation
System Design
Development & Test
Installation
Operation
Maintenance

Figure I-DP process steps

one company to another. This is expected and even
desired if the organization is being primarily tailored
to meet the needs of the parent company's business.
Figure 1 shows a selection of DP processes chosen
from the DP organization of several companies in the
United States. It can be seen, as was just mentioned,
that the steps in the processes do vary. It is interesting,
however, to notice that in spite of variations in the
steps of the process and that some of the steps are
called by different names with essentially the same
meaning, that there is a thread of commonality through
all the processes. There are some process steps that are
common to all data processing organizations regardless
of size, complexity, systems types, or structure. Three
of these common steps are design, install, and maintain.
It is important that the major steps of the process be
clearly defined in any given DP organization where the
human resources are being studied. Once this is done a
framework is established around which the human
resource requirements can be structured. The process

shown in Figure 2 has been selected for the purpose
of illustrating how we can go about relating the human
resource requirements to a DP process.
Considering the common thread through the proesses again-design, install, and maintain-these general terms can now be expanded into the selected
process.
Before we go further in skills requirements structuring, we must make sure that each step of the process
is defined well enough so that there is no miscommunication. I have attached the following definitions to each
step of this process. Keep in mind that there is no hing
fixed about the process and the associated definitions
that are being used in this example. Although, according
to surveys made, this is one of the more common
processes, the steps and definitions may be different
for various DP organizations.
So that we may continue our analysis, here are the
definitions that will be used.

Process Steps
APPLI CATI ON ANALYS I S

I.
II.
III.
IV.
V.
VI.
VII.
VIII.

DES I GN SYNTHES I S
FEASIBILITY VALIDATION I----Design
SYSTEM DESIGN

---1-

Applications Analysis
Design Synthesis
Feasibility Validation
System Design
Development and Testing
Installation
Operation
Maintenance

DEVELOPMENT &TESTING

Definitions
INSTALLATION
OPERATION
MAINTENANCE

-----'IJI-I------Install

Figure 2-The process

I. Applications Analysis
Maintain

This first step includes defining the problem,
analyzing and documenting the existing system,
describing the processing, defining output and
performance requirements, estimating the value
of what is required, and developing and present-

Planning Data Processing Education

ing the initial specifications to management
for their review and concurrence.

Basic

I ntermediate

61

Advance

APPLICATION ANALYSIS

II. Design Synthesis

Ski"s{~

This step includes establishing project planning
and control, checking and refining the systems
requirements and initial specifications, developing preliminary design alternatives and selecting
a solution that is most economically feasible
and best meets the requirements specified
(with supporting analysis from Feasibility
Validation). The system solution is then proposed to management where a decision must
be made whether to proceed into System Design
or consider alternative solutions.

III. Feasibility Validation

System
Support

Operations

APPLICATION ANALYSIS
DESIGN SYNTHESIS

DEVELOPMENT & TESTING

MAINTENANCE

Fi~ure

Skills{ ..
SYSTEM DESIGN

Ski"S{~
Skil S{

.•

Figure 4-Application development

IV. System Design

This step includes planning and designing the
details of the systems solution using the output
from Design Synthesis and the feasibility model,
selecting hardware and software, developing the
new procedures and test plan, and identifying
each program.

Here the process is completed and proved by
translating the system and program specifications into machine-readable code, testing and
debugging this code and documenting each
program module.

SYSTEM DESIGN

OPERATION

FEASIBILITY VALIDATION

V. Development and Testing

FEAS I BI LITY VALIDATION

I NSTALLATI ON

Ski"S{~

DEVELOPMENT & TEST I NG

This includes the processing testing the performance, technical feasibility and validity of
design alternatives or existing solutions by
creating prototypes, models or through simulation. Major cost and performance improvements can be made possible by the application
of standard solutions and generalized program
designs already available. Adaptations of existing systems or generalized programs may be
entirely adequate solutions; therefore, no further
design work would be required.

Application
Development

DES I GN SYNTHES I S

I
•

3-The process expanded

I

VI. Installation

This step includes converting data files, transactions, software and hardware used by the
existing system to meet the requirements of the
new system.

62

Spring Joint Computer Conference, 1972

TITLE:
SENIOR ASSOCIATE PROGRAMMER, DEVELOPMENT.
GENERAL CONCEPT:
AN ACTIVE MEMBER OF AN INTERNAL DATA PROCESSING SYSTEM APPLICATION TEAM, RESPONSIBLE FOR
DEFINING PROBLEMS, PROPOSING SOLUTIONS, DEVELOPING AND TESTING THOSE SOLUTIONS.
HE IS QUALIFIED TO SPECIALIZE IN THE AREA OF PROGRAM MODULE DEVELOPMENT.
SPECIFIC RESPONSIBILITIES:
(1) THE PRECISE DEFINITION OF PROGRAM MODULES (INPUT, TRANSFORMATION, AND OUTPUT) WHICH
WILL IMPLEMENT THE SYSTEM DESCRIBED IN SYSTEM DESIGN.
(2) THE DOCUMENTATION, FLOWCHARTING AND CODING OF THE MODULES SPECIFIED.
COMMUNICATES WITH:
TESTING SPECIALIST FOR RESULTS OF MODULE AND SYSTEM TESTS.
SYSTEM DESIGN SPECIALIST TO REQUEST MODIFICATION OF SYSTEM SPECIFICATIONS, IF THEY ARE FOUND
UNCLEAR.
MANAGER TO REPORT PROGRESS AND RECEIVE ASSIGNMENTS.
APPROPRIATE TOOLS, TECHNIQUES AND SKILLS:
ADVANCED PL/l
MODULAR PROGRAM DESIGN
PROGRAMMING TECHNIQUES
OPERATING SYSTEMS INTERFACE
PROMOTION POSSIBILITIES:
STAFF PROGRAMMER, DEVELOPMENT AND TESTING
SENIOR ASSOCIATE PROGRAMMER, SYSTEM DESIGN
Figure 5-Job description

VII. Operation

This step includes running the designed and
tested system (or application) on the computer.
VIII. Maintenance

This includes the maintenance of the software
systems programs and applications programs,
e.g., changes, extensions, and optimization.
There are specific skills, tools and techniques that
must be known and applied to accomplish each of the
steps in this process. If the organization is a large one, a
staff member might specialize in one or two of these
steps and be required to master a smaller number of
tools, but be able to apply these with considerable
expertise. A small DP organization would not have a
requirement for such extensive expertise; the staff
member may, therefore, be skilled enough to perform
several of the steps in the process to a much less level
of complexity.
At this point the DP organization functions and job
responsibilities can be related to the process that has
been described. The organization functions can be

identified as being three maIn segments of activity:
1. Application Development
2. System Support
3. Operations

Figure 3 shows how these organizational functions can
be related to the process. Notice the overlap among the
functions. For example, the system support function
overlaps the application development function in the
development and test step and installation step of the
process. In large installations where a high degree of
specialization may exist, these overlaps indicate the
points where responsibilities are passed from one
person or group to another. It is extremely crucial
that these key points of communication are identified
and the responsible staff members are made aware that
this "passing of the baton" so to speak, is an important
part of their responsibility. It is equally important
that they be adequately trained to carry out these
tasks with great efficiency.
Now take another cut at the same process from the
individual staff member point of view. For the purpose
of analyzing how this might be done, consider the applications development function alone for a minute. The
staff working within this function of a DP organization

Planning Data Processing Education

63

Responsibilities / Skills
(Be Able To:)
Application Analysis
Analyze existing system/applications
Document system
Define system requirements
Development and present initial specifications
Design Synthesis
Refine initial specification
Develop conceptual solutions-design alternatives
Identify and select known/existing solutions
Specify details of each design alternative
Estimate development, conversion, installation and operating
costs
Test and evaluate alternatives and select best solution
Present proposed system solution
Feasibility Validation
Create and test prototype systems
Construct and analyze or simulate models
Compare prototype or model to required systems performance

Technical Strength Definitions

o has no knowledge
1
2
3
4

understands capability and applicability
can use technique effectively
can maintain, modify and create new features
can synthesize and evaluate to reduce or eliminate analysis,
machine runs, development or tests based on his wide
knowledge of alternatives and depth of experience.

Systems Design
Development systems design work plan
Document system in detail
Design forms and reports
Finalize record and file requirements
Define data editing and validation rules
Select final hardware configuration and software
Document controls, audit trails, back-up procedure
Write new and revise old procedures
Plan system test and prepare test data
Prepare computer operations work flow
Document computer flow and identify each program
Development and Testing
Define program modules
Flowchart, code and document program modules
Design and implement program module tests
Implement system tests specification in system design
Figure 6-Programmer/analyst in application development environment

is made up for the most part of one of three types of
personnel: analysts, programmers, and managers. The
analysts are known as systems, application or program
in most cases. The analysts' job responsibilifes can
range across the analysis, synthesis, validation, and
design of DP systems and applications. Programmers
are generally of two primary types, applications
and systems. Applications programmers program
and test primarily business applications whereas system programmers program primarily control and
system applications. There are a wide range of job
responsibilities performed by programmers at all

levels of complexity. The managers referred to here are
technical managers. It is important to identify the job
responsibilities of higher management along with all
the other members of the organization but higher
managements' job responsibilities are broader, less
technical, and more administrative. For this reason they have been excluded in the sample being
used in this paper. The technical manager is one who
has direct supervision over a small staff of programmers or analysts and is able to understand technical
detail, at least within his assigned responsibilit·es.
There are numerous titles for programmers and

64

Spring Joint Computer Conference, 1972

RESPONSIBILITY (SKILLS)
(BE ABLE TO:)

BASIC

INTERMEDIATE

ADVANCED

APPLICATION ANALYSIS
ANALYZE EXISTING SYSTEM/APPLICATIONS
DOCUMENT SYSTEM
DEFINE SYSTEM REQUIREMENTS
DEVELOP & PRESENT INITIAL SPECIFICATIONS

DESIGN SYNTHESIS
REFINE INITIAL SPECIFICATION
DEVELOP CONCEPTUAL SOLUTIONS-DESIGN
ALTERNATIVES
IDENTIFY AND SELECT KNOWN/EXISTING SOLUTIONS
SPECIFY DETAILS OF EACH DESIGN ALTERNATIVE
ESTIMATE DEVELOPMENT,CONVERSION, INSTALLATION
AND OPERATION COSTS
TEST AND EVALUATE ALTERNATIVES AND SELECT
BEST SOLUTION
PRESENT PROPOSED SYSTEM SOLUTION
FEASIBILITY VALIDATION
CREATE AND TEST PROTOTYPE SYSTEMS
CONSTRUCT AND ANALYZE OR SIMULATE MODELS
COMPARE PROTOTYPE OR MODEL TO REQUIRED SYSTEMS
PERFORMANCE
SYSTEM DESIGN
DEVELOPMENT SYSTEM DESIGN WORK PLAN
DOCUMENT SYSTEM IN DETAIL
DESIGN FORMS AND REPORTS
FIN ALIZE RECORD AMD REQUIREMENTS
DEFINE DATA EDITING AND VALIDATION RULES
SELECT FINAL HARDWARE CONFIGURATION AND
SOFTWARE
DOCUMENT CONTROLS, AUDIT TRAILS BACK-UP
PROCEDURE
WRITE NEW AND REVISE OLD PROCEDURES
PLAN SYSTEM TEST AND PREPARE TEST DATA
PREPARE COMPUTER OPERATIONS WORK FLOW
DOCUMENT COMPUTER FLOW AND IDENTIFY EACH
PROGRAM

0
0
1
1
0

1
2
2
2
2

2
3
3
3
3

3
4
4
4
3

4
4
4
4
4

4
4
4
4
4

0

2

3

3

4

4

0
1
0
1

1
2
2
2

2
3
2
3

3
4
3
3

4
4
4
4

4
4
4
4

1

2

3

4

4

4

DEVELOPMENT AND TESTING
DEFINE PROGRAM MODULES
FLOWCHART, CODE AND DOCUMENT PROGRAM MODULES
DESIGN AND IMPLEMENT PROGRAM MODULE TESTS
IMPLEMENT SYSTEM TESTS SPECIFICATION IN SYSTEM
DESIGN
Figure 7-Programmer/analyst in application development environment responsibility (skills) matrix

analysts. It is best, of course, to define job levels using
the titles of a given DP organization. In Figure 4, the
levels-basic, intermediate, and advanced,-have been
used to relate job levels to the process. The bar graphs
under these levels give an indication of the approximate
average level required to perform the job responsibilities
in the corresponding process steps. For example, most
senior staff personnel have had experience and/or
training in development and testing before advancing

to more senior positions in either systems design,
feasibility validation, or design synthesis. This type
of structuring forms a rather neat array of potential
career paths.
Job levels, titles, and major responsibilities are
traditionally structured into a job description. Job
descriptions can range in form from the one sheet
summary shown in Figure 5 to very detailed descriptions. In all cases, it is worthwhile specifying the

Planning Data Processing Education

Basic

65

Advanced

In termediate

System Design

.-----------------------------------------------------------------------------------------------------------------------,
: Develop system design work plan
: Document system in detail
: Design forms and reports
: Finalize record and file requirements
: Define data editing and validation rules

0
0
1
1
0

1
2
2
2
2

2
3
3
3
3

3
4
4
4
3

4
4
4
4

.:i

4
4
4
4
4

0
0
1
0
1
1

2

3
2
3
2
3
3

3
3
4
3
3
4

4
4
4
4
4
4

4
4
4
4
4
4

:
:
:
:

J ______________________________________________________________________________________________________________________ _

Select final hardware configuration and software
Document controls, audit trails, back-up procedure
Write new and revise old procedures
Plan system test and prepare test data
Prepare computer operations work flow
Document computer flow and identify each program

1

2
2
2
2

Technical Strength Definitions

o has no knowledge
1
2
3
4

understands capability and applicability
can use technique effectively
can maintain, modify and create new features
can synthesize and evaluate to reduce or eliminate analysis, machine runs, development or tests based on his wide knowledge of alternatives and depth of experience.
Figure 8-Programmer/analysts-Responsibility matrix expanded

knowledge and skills required as well as promotion
possibilities. This information is valuable to management both in utilizing the employees best talents and
planning for his career advancement.
A further expansion is necessary of the knowledge
and skills required to do the jobs within each step of the
process. If some type of job analysis has not been performed on the data processing organization in question,
then now is the time. What the job involves, the complexity of the technical level, the associated responsibilities, and, last but not least, the knowledge and
skill level required to do the job all must be defined to
fulfill the requirements specifed in the steps of the
process. Much of this information can be structured
on the job description summary sheet that was just
described.
Job analysis should be done by professionals who have
had experience in making such analysis. This type of
study is usually performed for a fee by an outside
consultant. If the consultant is carefully chosen the
results will be well worth the money but be sure that he
has extensive data processing expertise on his staff to
participate in the analysis. Also make sure that his
analysis is going to be provided to you in a form that
fits your needs and is tailored to the process in your
organization.
There are many good approaches to job analysis
Most of them involve some type of general experience
questionnaire and the observation and interview of

selected employees doing their job. It is important to
make sure that the employees have a good underst' nding of what is being done and why job related questions
are being asked. Employees quickly become skeptical
and concerned when a lot of questions are asked about
their job and how it is performed. The cooperation
given by the staff in programs such as this will be
much better and with a more positive attitude if the
reasons are first clearly explained.
Under each of the process steps the major skills,
actions, and knowledge are identified that are important in accomplishing the step in the DP organization.
Try to refine these major items as much as possible so
they will be concise yet descriptive of the responsibility.
Sometimes it is difficult to express all the items purely
in the terms of skills. For this reason be practical and
realistic about the results by using a mixture of skills,
actions, and knowledge. This approach seems to render
a better level of definition.
Figure 6 shows how this expansion can be accomplished. Keep in mind that we are talking about the
application development function of the DP organization and the associated programmer and analyst staff.
For this reason the expansion shown is for the first five
steps of the process.
The technical strength definitions below show how
knowledge levels can be identified. Once again these
definitions should be prepared with the requirements of
the organization in mind. There must be an adequate

66

Spring Joint Computer Conference, 1972

range in the knowledge levels. With programmers and
analysts it is especially desirable to be able to identify
whether they can explain a concept and apply it as well.
Technical Strength Definitions

o
1
2
3
4

has no knowledge
understands capability and applicability
can use technique effectively
can maintain, modify and create new features
can synthesize and evaluate to reduce or
eliminate analysis, machine runs, development or tests based on his wide knowledge of
alternatives and depth of experience.

You will notice that these levels are primarily for
programmers and analysts so that we may continue
to expand our definition of the application development function.
All the data that is needed to put together a summary
skills matrix of a selected DP organization should now
be available. The data includes:
1. Definition of the steps in the DP process to meet
the needs of the business.
2. Definitions of job responsibilities to meet the
process requirements.
3. Association of these job responsibilities with
defined jobs.
4. Identification of the level and possibly the title
of each of the defined jobs.
5. List of the major relevant skills, actions, and
knowledge to meet the defined job responsibilities.
6. Define the strength levels of the skills and
knowledge requirements.
A summary skills matrix can now be constructed by
inserting the strength indicators required for each
defined activity of each process step. The strength
indicators are placed in the appropriate job title or
level column.
Figure 7 shows how the technical strength indicators
are added to the System Design step of the process.
The strength level definition and the job level to which
it is associated is determined primarily from the
data obtained as a result of the job analysis and survey
of the staff's skills.
When the summary skills matrix is constructed for
all members of the DP organization, it becomes an
invaluable management tool in planning and obtaining

the required skill mix. The skills matrix also acts as a
key index in planning tailored education for the staff.
This can lead to significant savings in education
expenses to a company.
Using the summary skills matrix and data from the
job analysis and knowledge surveys, a trained industrial
educator can determine what additional knowledge and
skills are needed to enhance that already possessed by
the staff. The identification of the missing skills and
knowledge is the foundation on which future training
Name:
Business System Design
Duration:
Five days
Audience:
Those with the responsibility for the detailed design of a
business system.
Prerequisites:
Experience in program development and testing or successful
completion of the development and testing curriculum.
Objectives:
Upon successful completion of this course, the student will be
able to:
Develop cost estimates and a work plan for scheduling and
controlling the work through the design phase.
Define the record content, file organization, storage requirements and access methods.
Define data editing and validation rules, controls and audit
trails.
Design the necessary forms and reports.
Complete the detailed documentation of the system, specifying
the input, output, processing and file requirements of each
program.
Prepare the systems test plan.
Topics *
Systems design cost estimating planning
and scheduling
Detailed record design, file organization
and access method specification
Editing, validation, controls and audit trails
Forms and reports design
Procedure writing
Systems test planning, test data and file
preparation
Program specification and documentation
Estimating programming development time
Case study

Total

Hours
2

4
2
2
2

4
4
2
8

30

* These topics teach to the 2 and 3 technical strength levels.
Figure 9-Course specification

Planning Data Processing Education

can be based. Much of this needed training can be
accomplished on the job or through self-study. Some
of it will require more formal classroom education.
In any case, the education will be tailored toward the
business needs and requirements since it is based on
a foundation geared toward that same goal.
Regardless of whether the training program required
is going to be developed in-house or contracted out to
an education company or computer manufacturing
company, it is good to have at least a general specification of the type of training needed.
Using the related job responsibilities boxed in on
Figure 8, a training specification can be written.
Job responsibilities that are related should be clustered
together so that eventually a series of topics or modules
can be defined to teach the relevant subjects. Related
topics, in turn, are normally grouped together to form
a course.
The course specification shown in Figure 9 is one
designed to teach to the 2 and 3 strength level on all the
job responsibilities boxed in Figure 8. Notice that the
course specification identifies the most pertinent facts

67

about the training needed. The audience, prerequisites
and a clear definition of the objectives are the most
important items. Individual topics that make up the
course and the approximate duration of each can be
included when they are needed. The purpose for using
a duration on each topic is to give some indication of the
depth that topic covers.
I said at the beginning of this paper that surveys show
that the greatest expenditure that a data processing
organization has is for its human resource. Actually it is
the knowledge that is being purchased. This statement
applies equally as well to most all human resource
requirements in industry. In Peter F. Drucker's
recent book, The Age of Discontinuity, he treats knowledge as one of the four discontinuities. Mr. Drucker
says, "Knowledge, during the last few decades, has
become the central capital, cost center and the crucial
resource of the economy."
Since knowledge is a very valuable and expensive
commodity it should be treated as such. Planned
education according to the needs of a business will
impart knowledge where and when it is required.

Modular training-A new emphasis
by ROGER

w.

KLEFFMAN

United Air Lines
Englewood, Colorado

basis, and to accomplish training on second or third
shift, or even on a part-time basis.
The balance of the paper presents the details relating
to this particular project. This includes principles of
course development, course descriptions, and the
required training sequence for positions on the project.
It should be stressed that no really new principles or
techniques are offered, only a new emphasis or applying
some old methods (and not so old, such as v:deo
modules) is advocated here.

INTRODUCTION
During 1970 and early 1971, United Air Lines and IBM
implemented a PARS-based (Programmed Airline
Reservations System) reservations system. This system
is written in Assembly Language Coding for the IBM
360/65. The software is special purpose, dedicated
to providing very fast response to remote airline reservations inquiries including: schedules and availability
between cities, passenger name data, and related
information. At the start of the project, there were
virtually no United personnel with PARS experience,
and the implementation phase included the development of a comprehensive training program. The
principle objectives of this program, over and above
that of preparing United programmers and operators
for participation in the project, included the capability
to be completely self-sufficient for PARS training at
United, the ability to administer training as personnel
became available to the project, and the desire to
maintain a minimal staff of professional trainers.
To achieve these objectives 12 special courses were
developed using the guidelines described as modular
training. These courses, developed by IBM for United,
were according to specific guidelines and standards.
The standards emphasize that courses should be
developed in short, self-contained parts, bring the
student into direct contact with source information
and use other media (e.g., video tapes, audjo tapes)
slides) to amplify material being presented to the
student. This assists the student in advancing at an
individual pace, and encourages self-sufficiency.
The basis for this paper is that an in-house training
program can be developed which is self-sufficient. The
need for outside training may exist for course development. However, generally development can be accomplished by line personnel with technical competance
designing training courses in accordance with welldefined 'standards and objectives. Once developed, it is
possible to administer the training on an "as needed"

MODULAR TRAINING
Modular training is the term used by United to
describe training in terms of courses divided into
specified units. A course is defined as: a set of objectives
that should be achieved by a target audience together
with training material, a time duration for the course,
and a plan for accomplishing the training. Training
courses are tutorial for programmers and operators on
this project in that training is viewed as the transfer
of information necessary for the student to carry out
job responsibilities in a defined area. This is in contrast
to training in a seminar environment by means of
exchange of ideas among participants. Under the
modular approach, the responsibilities for programming
and computer operator positions have been keyed to the
courses. Each position has an identified sequence of
training courses through which a student progresses
prior to full-time work assignment.
Under this modular training approach, each course is
admjnistered to a student by an advisor, an experienced
person with successful completion of the course or with
extensive experience within that area. The governing
elements of the course are a student guide and an
advisor's guide.
The student guide is a document which coordinates
the student's progression through training materjal.
It is designed to give the student the information
69

70

Spring Joint Computer Conference, 1972

REFERENCE 1

o

REFERENCE 2

REFERENCE 3

o
Figure I-Student guide

nec~ssary for a thorough understanding of the subject,
as Illustrated by Figure 1.
The intent of the student guide is to direct the
student through applicable training material in a given
order. This includes readings in references not cont~ined. in the guide itself (technical manuals, profesSIOnal J~urnals), or viewing video tapes (including local
productIOns keyed to specific elements of the project),
as well as utilizing the guide itself for tutorial material.
In particular the video tapes are a valuable means
for producing training material. Use of video tapes is
to deve' op standard, lecture-type modules and elimi~ates the requirement for an instructor to repeatedly
gIve the same stand up lectures. Video is also useful in
explaining standards and procedures, which can be
presented to the student as dictated by students responsibilities to the project. The advisor, however,
must always be available to answer questions or exchange dialogue with the student on the basis of the
information in the video tape.
By design the student guide cannot and does not
function alone as a self-sufficient course, such as in
p:ogrammed instruction. The advisor is a necessary and
VItal part of the course in modular training.
The format of the student guide includes:

A. Introductory Section
1. Course description and intended audience.
2. Course objectives.
3. Prerequisite
training
and/or
related
experience.
4. Recommended duration of the course.
5. Advisor/student relationship.

B. Reference Material
This section identifies all other manuals and
documents needed in the course.
C. Detailed Assignments
This section presents the series of steps which
lead the student through the material. It includes
reading assignments, identifies lectures, designates participation in workshops, and tests to
determine how well the student is learning and
applying the material. In courses involving
programming, actual coding experience is accomplished by assignments which are processed
on the computer.
A history log is maintained for each course containing
questions raised by students during the course. This
information is used to develop additional explanatory
material, quizzes, or more detailed references to aid the
student in acquiring a better understanding of the
subject.
COURSE ADVISOR
The second key element in modular training is the
Course Advisor. By design the course can be administered to a single person, to a formal class of students ,
or to several students who have started the course at
different times. Except for formal classes, the advisor
performs this roll on a part time basis. As a result, line
programmers can function as advisors as well as having
normal job responsibilities.
Under United's approach, only one person devotes a
full-time effort as the advisor for basic courses, and line
programmers act as advisors for advanced courses.
Each manager furnishes the advisor for advanced
courses for students who will receive assignments in
that manager's area. Only senior, experienced personnel
are used as advisors. This represents one of their job
responsibilities, and is a means of providing further
experience in the management aspects of dealing with
people.
The advisor has three primary responsibilities:
1. To serve as a point of reference for any questions
the student may have on the course material.
The advisor may not be able to answer every
question, and may have to get the answer from
another source. In any case, the response is on a
timely basis.
2. To administer quizzes and exams to the student
as required in the course sequence. The results
are always reviewed with the student to insure
complete understanding.

Modular Training

3. To emphasize the most pertinent parts of the
course relative to the student's work area, and to
evaluate the student's understanding of the
course. Here, the advisor's function is to tailor
the course to the student's needs. The advisor
takes the initiative in discussing the important
aspects of the course instead of passively waiting
for the student to ask questions. By probing the
student's thought process the advisor can fill in
any areas of weakness and correct misunderstanding. Normally, the advisor spends 7i to Y2
of the student's assigned course time, depending
on the advisor's familiarity with the course and
the extent of the student questions. For example,
if a student is training on a half-time basis, the
advisor can expect to spend VB to 7i of that time
in an advisory capacity. The advisor also provides up-to-date technical information on the
system, which minimizes the problems associated
with technical obsolescence of training material.
CAREER PATHS AND COURSE PROGRESSION
The U nited PARS project provides training for
programmers, data base personnel and computer
operator personnel. This section describes each job and
the training sequence required.
There are seven areas of programming responsibility:
1. Application Programmer
Develops programs in a real-time environment
which accomplish the airline reservations functions. These include display of airline schedules,
availability of seats inventory control, flight
information, and programmatic exchange of
information with other airline reservations
systems. Programming is done in ALC, the
assembly language used for coding on the IBM
360 series.
2. Schedule Change Programming
Includes an understanding of batch processing
as well as real-time programming, and has
significant impact on many system data records.
These include modifications to flight schedule
information and development of information
used to reaccommodate passengers. Programming in ALC under DOS and OS is included.
3. System Support Programmer
Has responsibility for the generation and
maintenance of systems, both OS and DOS,
PARS off-line support, together with file
maintenance and management reports. Programming languages include P LjI and FORTRAN.

71

4. Control Program Programmer
Has assignments in inputj output for disk and
tape, CPU scheduling, queue processing for input,
ready and deferred lists, interrupt handling and
on-line data collection.
5. Communications Programmer
Is involved with control and coordination of
communications between remote sites with
CRT terminals as well as with the other computer systems. There is heavy involvement
with hardware such as IBM 2703, WE201B
modems or equivalent, IBM 2948, and the IBM
2915 or equivalents.
6. Performance Evaluation Programmer
Analyzes the PARS system performance by
measuring and interpreting system characteristics including inputj output message size,
program core residency time and execution
time, file accesses and queueing. Simulates the
system by means of model(s) and predicts
system performance relative to proposed
modification.
7. Coverage Programmer
Has primary responsibility for the diagnosis
and immediate correction of on-line software
malfunctions, as well as monitoring on-line
system software integrity. Programming occupies a relatively sm9,ll amount of time.
Two Data Base jobs pertain to information records
in both the on-line and off-line systems. Programming
experience is not required for these jobs:
1. Data Base Specialist
Has the responsibility for the integrity of all
passenger information in the on-line system.
This can involve restructing parts of the data
base as a result of airline rescheduling as well as
corrections to erroneous on-line information.
2. Data Base Coordinator
Has responsibility for maintaining airline schedule information, pilot data information and
communications tables. These are processed in
the off-line system.
Computer Operations involves three tasks:
1. Data Control Clerk
Receives and monitors off-line processing jobs,
maintains tape and disk libraries, and JCL card
decks for off-line jobs.
2. Computer Equipment Operator
Operates all equipment in the off-line-system

72

Spring Joint Computer Conference, 1972

\ DATA
BASE

PROGRAMMER

\ OPERATIONS

1

b~ ~~,~

'I>{,.t(>4:{!z~ '" 8/j.A .AkJ(){(>~~4i.{J. (>O~~4 4 .e.:l'4l/j.t~~qt80
:Z-Oq

~~O~~~ ':4i; ~:Z-Oq&~:;;.tOq~(J~~..t!&.e :e 00 Oq.(>~O ~.(> 0 'l;e 0

.AkJ()~~(>:~-r4'~ (>{,~'I>~Ir..t~~Ir..t:r;O
~ ~

~~~
d

zH
zH
~
8

0
\0

(Y'l

d

zH
zH

«
I):;

8

fQ


D

R3

INTERNAL.~

SCHEDULE CHANGE-INPUT DATA
PREPARATION
OFF-LINE SCHEDULE CHANGE
ON-LINE SCHEDULE CHANGE
COMMUNICATIONS
'DATA COLLECTION
DATA BASE MANAGEMENT
SYSTEM OPERATOR TRAINING
TOTAL TRAINING DAYS
FOR REQUIRED COURSES

Rl
R2

Rl
R2

~./)

~

50

45

55

50

R8
Rq
RIO
Rl1
D

Rl
D

R~

80 10

3

R = Required
D = Desirable
Subscript indicates course sequence number
*Not required for all System Support Programmers
Figure 2-Career path training sequence

and assists in monitoring the on-line system
activities.
3. Console Operator
Has responsibility for operating the hardware
in the on-line system. Monitors and controls

system configuration, and applies corrective
action for hardware failures.
The training required for these positions is summarized in Figure 2. IBM/360 training is also shown

Modular Training

in presenting the training progressions. The total training days associated with the IBM/360 training and the
PARS training identify the time needed before an
individual is ready to accomplish productive work.
For example, a programmer with no 360 computer
background would require both IBM/360 and PARS
training. For applications programming, 40 training
days would be required. If the programmer already had
IBM/360 experience and no PARS experience, 25
training days would be required. The description of
PARS training courses is given in the Appendix. Both
the training results and the training duration are good
as evidenced by high comprehension rate and mininal
training period.

SUMMARY
As a part of the implementation of a PARS system,
United Air Lines has developed a comprehensive
training program using the modular method with
three objectives:
1. United is self-sufficient for PARS training
(N ote: PARS training requires IBM 360 knowledge as a prerequisite).
2. Training is administered as people are available.
3. Training is accomplished with a minimal
professional training staff.
Twelve courses were developed to achieve these
objectives for the different job responsibilities within
the project. More than sixty students were successfully
trained with this method.
An advisor is a key element in administering modular
training. The advisor is responsible for tailoring the
basic course to reflect the content of the student's
assigned area, and to monitor the student's progress.
Drawn from the line organization, the advisor is proficient in the assigned area and monitors the student's
progress by answering questions, administering quizzes,
and probing the student's understanding of the subiAp.t
matter.
Modular training with professionally competent
personnel acting as advisors eliminates the need for
formal classes, and training can be administered on an
"as availa;ble" basis, although a class can easily be
accommodated with this method. In addition, the
advisors have line responsibilities and thus the need
for a large, dedicated training staff is eliminated.
Currently, at United one person has full-time basic
training responsibility for the 70-80 project programming staff.

73

Advanced training advisors are furnished by the area
to which the student is assigned.
Generally only senior persons are advisors and
represent a part of the responsibilities of a senior
position. Being an advisor usually affords first exposure
to working with people in a management mode, which is
good experience if further advancement along supervisory lines is desired.
In particular, however, it was found that:
1. An advisor is indispensable to the program, and
cannot be passive. The advisor must actively
monitor and encourage the student's progress.
Experience has shown this method has favorable
results.
2. Prior to starting the training, there should be a
review meeting between the student, the assigned
manager and the advisor. The review will include
the sequence and duration of the courses for the
student, the approximate expected progress
(relative to whether the student will be in
training full-time or part-time), and the role and
responsibility of the advisor(s).
3. Practical problems, and quizzes which reflect the
course objectives are essential, especially for
programming courses. A simulation of the real
environment is necessary for coding and debugging problems. The course content must be
tutorial and serve as a transition into the work
environment.
4. Insofar as possible, training, especially the
advanced training, should be on a part-time
basis. This gives the student a better opportunity
to assimilate the many new concepts and
terminology as training exposes them. In fact,
terminology is a major factor on this project,
because the student is not only using EDP
terms, but also the special vocabularies associated with airlines and with the PARS system.
5. Update of course content caused by system
change is best accomplished by line personnel.
In this case they act as advisors but without
students, and have the responsibility for updating the applicable course content.
6. The student guide/advisor functions best in a
non-development environment. In a totally
developmental environment, scheduling is a
problem. Estimates of required program development time always seem to neglect factors which
were not expected to occur (sickness, machine
downtime, etc.) In either case, the line must be
staffed to accomplish both programming and
training requirements.

74

Spring Joint Computer Conference, 1972

Overall, modular training has worked reasonably well
for the United Airlines PARS project. The primary
objectives have been satisfied by a minimal professional
training staff and utilization of line personnel in the
training function. The advisory responsibility takes
time, however, and an advisor's schedule must include
time for training in addition to normal line responsibilities if modular training is to function properly.
This same method should also be able to work for
other projects. A student guide need not necessarily
be a reference unto itself, it may be a series of references
to other manuals, documents, video tape, et al. Video
tapes, in particular, afford the means of augumenting
course material and making it available for training
around the clock. There currently exists a dearth of
organized information and material which can be used
to construct a course. There is no prophet for rewriting a
document which can be used in its present format with
directions as to applicability. Both the student guide
and the advisor furnish this direction to the material
and provide tailoring specific to requirements.
APPENDIX A
Course descriptions

This Appendix presents a description of the 12
courses that were developed at United Air Lines.
These specific courses are applicable only to a relatively
small group of PARS users.
It should be noted that because the courses are
tutorial, quizzes form an important part of the course,
being geared to the course objectives. The student is
expected to achieve certain defined objectives, and the
quiz results represent, in part, how well the material
has been learned, as well as performance evaluation.
Training in PARS requires a knowledge of the IBM
360 hardware and Assembly Language Coding (ALC).
These are prerequisites for all the PARS Programming
Courses. Commercial video taped courses, augmented
by material particular to United's needs, satisfy these
requirements.
The PARS courses are divided into two sets; a basic
set which all programmers attend, and the advanced
courses, which are attended on an "as needed" basis.
The first three courses listed below are the members
of the basic set; all others belong to the advanced set
for programming except the operator course, which
is independent. Sixteen video tapes have been produced
by United to augment the basic PARS training. These
were produced based on an evaluation of the information in the history log, an invaluable tool for developing

training modules such as programming techniques,
project procedures, and the like. In addition, the video
modules are always available to the student on an
around the clock basis, thus helping to free training
from the prime shift dependency.
1. PARS System Description-3 days
This course presents the basic PARS hardware
and software descriptions, as well as concepts and
terminology associated with the airline industry
as well as PARS system. Emphasis is placed on
providing the fundamental information concepts
and terminology needed in other courses.

2. Applications Programs-5 days
This course presents the functions of all PARS
application program packages including programs within each package, and describes the
data records required by each program explaining
how these records are accessed and data is
manipulated. It relates airline reservations agent
actions and needs to the manipulation of the
applications programs and the data records.
3. Airlines Programmer Environment-17 days
This course is divided into three major areas
corresponding to the types of programmer activities in this real-time PARS environment:
1. Program Development
The availability and use of programmers tools
such as: entry control block, macros, and
conventions.
2. Program Maintenance
The PARS Program Library System, the
steps involved in entering programs, the
inputs necessary for program maintenance.
3. Program Testing
The concepts and procedures used in testing,
in generating test inputs and in interpreting
test results.

The course environment is designed to resemble,
as closely as possible, the expected environment
in the development group. The subjects discussed at length are those dealing directly with
the job of application programming.
Upon completion, the student is capable of productive assignment in applications programming
within the PARS environment.
4. ACP Fundamentals-5 days
This course introduces the programming t.echniques such as queuing, priorities, message
flows, and related items used by the Control
Program.

Modular Training

Upon completion the student is able to relate
the functions of the ACP program to his present
assignment.
S. ACP Internals-IS days
Airline Control Program Internals is concerned
with program listing level discussion, by topic,
of each of the functional units of the airline CPo
This includes communications, hardware input/
output, and services and facilities provided to
application programs.
Upon completion the student is prepared to
accept assignment in any functional area of the
Control Program. The student will lack only
what can be gained through experience.
6. Schedule Change Input Data Preparation-3
days
Editing and validation of modified schedule
information is the main objective of this course.
Upon completion the student is able to prepare
the input data required for Off-line Schedule
Change.
7. Off-Line Schedule Change-S days
Topics covered include concepts of off-line schedule change; off-line schedule change input and
processing, and a detailed analysis of the off-line
schedule change programs.
Upcn completion the student is able to communicate in the language of schedule change
with non-programmers and other PARS Application Programmers, use to use the appropriate
documents to extract the details of the schedule
change programs assigned as the student's responsibility.
8. On-Line Schedule Change-S days
This course presents the functions of all the
on-line schedule change programs, defines the
data records affected by the on-line schedule
change and describes how they are affected,

9.

10.

11.

12.

7S

explains the four logic phases of the on-line
schedule change, and relates the programs and
data records involved to each phase.
Communications-S days
This course presents PARS Communications in
general, and specifically as applied in United's
PARS System. This system exchanges communications with two other United Air Lines
On-line Computer Systems. In addition PARS
Communications is covered from the functional
level to a detailed program level which describes
the interrelationship of the programs, tables
and data records involved.
Data Collection-S days
This course describes the functions of the Data
Collection Programs and defines the facilities
provided by these programs, explaining how
system, file, program and message variables are
collected on-line, and reduced off-line. It identifies listing variables which are out of line from
data collection reports and determines from
these variables how system performance can
be improved.
Data Base Management-20 days
Data Base Management covers four major file
support functions and data base generation.
These include: Pool Directory Generatbn and
Maintenance, Recoup, Capture/Restore, Fixed
File Reorganization and System Test Compiler.
System Operator Training-S days
This course describes, in general terms, a typical
PARS hardware configuration and the PARS
software system. In addition performance of the
following operator tasks is explained: program
library maintenance and update, testing, system
load, all other off-line and on-line operator
activities, interpretation of error messages, and
use of functional messages appropriate to a
given job.

Computer training, present and future
by GORDON A. SMITH
Jet Propulsion Laboratory
Pasadena, California

INTRODUCTION

cassettes and a small workbook for those who want to
become familiar with data processing terms. One of the
major banks in Arizona has required its 132 branch
managers to review this course while traveling to and
from work. It is also an excellent device to augment
stand-up instruction for a new student. Several firms
today have canned video-taped courses along with
workbooks as a self-instructional means to replace the
very widespread utilization of PI or programmed instruction textbooks. To my way of thinking, there is
nothing more borjng, and less motivating, than sitting
down with a workbook, and saying I am going to learn
by myself and teach myself something, whether it is
data processing or any other area of interest.
Another firm, in addition to its video taped courses in
basic computer programming-COBOL, FORTRAN,
and so forth-has a considerable library of animated
motion picture films, along with associated workbooks
and other materials as a self-teaching means in support
of standardized automatic data processing (ADP)
curricula. Some of the films are excellent, and, in some
cases, we have utilized them to augment our classroom
course "Introduction to Computer Technology." A
firm in Illinois has developed a systems analysis course,
as well as courses in operating systems (OS) with a
thorough interaction between video tape, audio tapes,
and workbooks-none of the media being used for more
than 15 minutes at a time. There is a constant transfer
from one medium to another which provides not only
motivation but reinforcement. More of the physical
senses are used in the absorption of educational material. Of course, motion picture films are also used;
films themselves are a bit more cumbersome, but if
intermixed with other media, may become a viable
means of instructional transfer.
I believe that audio tapes, video tapes, motion picture films, and animated cartoons can effectively. be
used in a learning carrel. A carrel is nothing more than
an enlarged desk with various devices in it; one can

Before beginning this discussion, I would like to make
a few remarks concerning the Jet Propulsion Laboratory (JPL). The Jet Propulsion Laboratory is responsible to the National Aeronautics and Space Administration (NASA) for unmanned missions in deep space.
A worldwide tracking network encompasses Goldstone,
California; Madrid, Spain; Johannesburg, South Africa;
and Woomera and Tidbinbilla, Australia. In addition
to the deep space missions, there are a great number of
scientifically oriented projects throughout JPL. The
Laboratory has approximately 4,100 employees, as well
as some support contractor personnel.
All levels of personnel in JPL, as well as contractor
operations personnel, are involved with the educational
programs, starting with "Introduction to Computing"
through management training in the data processing
field.
Within almost every government organization, and
certainly within every NASA facility, a considerable
workload rests within the administrative and financial
operations. These are nonscientific endeavors which
hopefully will lead toward improved management information system controls. A commercial enterprise,
financial operations organization has a number of
similarities.
To begin with, I have prejudices against classrooms
of stand-up instruction only, or classrooms of videotaped lecturers only, or instruction in any single medium. Therefore, I will spend a few moments reviewing
some of the products of educational firms today leading
toward altmultimedia approach to the education and
training of commercial programmers, systems analysts,
or obviously, into some of the scientific fields.
Let me cite a few examples of ideas that have come
out of some commercial firms. For instance, there is one
firm in Ohio that has developed a course titled "ADP
Terminology." This course consists of 16 audio tape

77

78

Spring Joint Computer Conference, 1972

COMPUTER-ASSISTED INSTRUCTION

Figure I-JPL training carrel

instruct himself at his own speed, and hopefully, improve his motivation if he has a goal in mind (see
Figure 1). This type of self-instruction is extremely
worthwhile if it is also reinforced by a senior programmer or analyst. The multimedia approach will
create greater motivation.
For a moment, let's look at the benefits. In classroom
training, the teacher is usually - ")sponsible for maintaining a norm at the average class level. Very often
the faster student becomes quite bored because he is
ahead of the group, whereas the slower student is having a problem keeping up, and thus becomes rather discouraged. Most schools in the data processing field require the student to write, run, and debug test programs
on whatever type of equipment that school may possess.
There is a danger at times if the "school" has only the
equipment of one manufacturer and is not able to provide good classroom direction where students can effectively learn the differences between equipment of various manufacturers-either small-scale computers or
large-scaJe systems.
A list of the computer courses available at the Jet
Propulsion Laboratory, along with the computer selection procedure, is given in Appendix A; a set of computer-related job descriptions from the Computer
Education Directory published by Edutronics Systems
International, Inc., Los Angeles, Calif., is presented in
AppendixB.

Computer-assisted instruction, or CAl, is a relatively
new medium to augment the other media I have discussed; however, I am certain all of us will be influenced
by it over the next few years. I feel we are missing a
very worthwhile and cost-effective tool. Helen Lakin
at the University of Wisconsin noted there are 1,264
program descriptions in the publication Index to
Computer-Assisted Instruction. These descriptions are
from sources in the United States, Canada, Europe,
and Japan, representing elementary and secondary
school systems, colleges, and universities that have
complete CAl courses for credit. As an example, the
University of Southern California recently instituted a
complete course in Programming Language I by CAl
for three units of credit. Many universities are using
CAl as a self-teaching method very successfully for
both direct teaching and remedial education. In none
of these situations does it mean that there is not a
teacher available to answer questions or at least to
cover the highlights that may be misunderstood. In the
government area, certainly throughout the Department
of Defense, there are any number of programs that are
offshoots of simulation programs as well as specific
courses in CAL Many of the programs, however, are
tailormade to the particular command or to the
organization.
I t is extremely important that data processing organizations thoroughly evaluate available software
systems in today's market, whether they are proprietary or in the public domain. For the programmer or
systems analyst, where it can be shown to be costeffective, there is no better system than one with immediate feedback. From a motivational standpoint,
the one-to-one relationship without outside distraction
can be made a very viable and successful means of
instruction in this field. It seems strange that there are
not more schools or private firms teaching programming, systems analysis, or data processing management
on a computer terminal.
Briefly, from the principal title of the session, let's
consider the capability of the computer in CAL In
August 1970, a test project was instituted in the Communications Electronics School Battalion at the Marine
Corps Recruit Depot in San Diego, California. Twelve
terminals were connected by data link to a UNIVAC
1108 computer some 75 miles away. A stand-up class
was run concurrently with the CAl classes. Individuals
were psychologically matched, and each student proceeded through the course of instruction at his own
pace. Of considerable importance, the Marine instructors wrote their own courses for the computer after

Computer Training, Present and Future

only two weeks of instruction from the manufacturer. A
system of positive or negative reinforcement of learning
experience was presented to the student immediately.
The immediate benefits of the teaching experience were
the objectivity, data collection and reduction, and
standardization of instruction. Cathode ray tube terminals were employed. The results demonstrated substantially increased learning in the CAl class; and
subsequent to the test, far greater retention was
achieved. This demonstration has convinced Headquarters Marine Corps to initiate formal schools in
CAl at the Marine Corps Station at Twenty-Nine
Palms, California. Sixty terminals will be employed,
course time will be reduced by 20 percent, and instructor requirements by 75 percent of instructor manpower.
In the universities, there is a strong tendency to tie
CAl courses with other portions of the curricula. There
is a major tendency, of course, to deal primarily with
the fields of scientific uses of the computer, or, in other
words, its applications to physics, chemistry, biology,
genetics, etc., rather than to the straight business approaches; however, some universjties are improving
their curricula, from computer programming on into
the area of management information systems. There is
an excellent marriage between business management
and the tools the computer can provide.
GOVERNMENT USE OF COMPUTERS
The government was the first major user of computers, in the late 1940s and early 1950s. Commercial
data processing centers have become increasingly
widespread. Subsequent to unbundling, the government agencies developed their own schools and separate
series of grades within the Civil Service Commission
to handle the various levels of computer programmers
and systems analysts. One of the problems of government, as well as of all large business operations, is fre~
quently a lack of communication among similar services
and organizations. The Office of Management and
Budgets in Washington is examining improvements in
communication among similar elements of government,
where both can utilize the same software, hardware, or
systems approaches. Where there is coordination among
government entities, cost savings are very substantial.
Due to a low turnover, many large government entities
also realize that their management personnel, as well as
their programming personnel do not effectively utilize
the tools available today.
Many of the leading computer manufacturers emphasize more now than before the need for improved
management training) which, in a sense, goes beyond

79

the scope of this present paper. However, when speaking of education for computer programmers and systems
analysts, we must consider the people who are directing
the needs for this education and training. These needs
definitely stem, and should stem, from a better understanding by management of their own specific needs.
When management understands these needs and can
define them, then indeed they will do a much better
job in hiring personnel. This will establish the type of
training curricula these personnel should have had before being hired.
As a lesson from the government's interest in this
field, communicating between commercial firms possessing similar interests can assist industry in setting
standards or norms of personnel. In Appendix B are a
number of what I feel to be excellent definitions of
programmers and systems analysts. There is a need
throughout the United States today for an improvement in semantics of all facets of ADP terminology in
the entire field. Pers::mnel firms should seek for a common understanding, thus setting some type of definition
of various grades of programmers for the systems
analysts. In large industries, of course, these have been
indicated. However, they vary considerably from industry to industry. By an improvement in definition,
understanding, and attainment, the individuals in this
field should become more professional in their
community.
THE IMPORTANCE OF PRETESTS
Obviously, any paper may reflect the bias of the
individual writing that paper, who may promote those
things that are the most successful in improving his
responsibilities. Both with beginning programmers or
systems analysts, or with those who wish to enter this
field, I am a firm believer in computer pretests. Large
schools have pretests of one type or another. However,
when they are sel1ing courses, their pretests may not
be as restrictive as a pretest would be within my organization or within other organizations depending upon a
profit motive.
Pretests can aid in determining a person's ability to
absorb a particular instructional level. He takes the
test, analyzes the test himself, and, from the results, he
himself should be mature enough to state whether he
has the ability to go ahead as a computer programmer,
as a systems analyst, or in some other field of data
processing, or whether his capability in fact rests somewhere else, and not in the ADP field at all. Many of
the personnel with whom I have been associated who
have taken these pretests have suddenly decided they

80

Spring Joint Computer Conference, 1972

should not take FORTRAN or COBOL, but rather
should go back into a program we have titled "Introduction to Computers," or, in other words, the basic
groundwork-"What is a computer, what does it do,
how does it operate, how does it function, and what are
the various fields to which it could be applied?" The
next step (shown in Figure A-I) analyzes his particular
functional responsibilities, and, from there, determines
the type of course toward which he should direct himself: in other words, what computing system should he
be addressing? This last step is extremely important,
since a person who is completely educated in one type
of equipment, and then is thrown into another organization with an entirely different type of equipment,
normally has some problems adjusting. This can be
prevented if his training is directed toward the type of
equipment he is going to use in the first place. Within
an organization, a person's immediate supervisor is responsible for determining whether company time should
be devoted to such courses or whether the individual
would improve himself by taking courses outside of his
office hours.
FUTURE DEVELOPMENTS
Let's consider some probable areas where changes in
technology should considerably influence ADP education in the next decade. Increasing capability in the
multiprogramming aspects of large-scale computers will
permit a more economical approach toward computerassisted instruction. Initially, however, it should be
treated primarily as an augmentation or reinforcement
of courses rather than as the stand-alone desire of some
CAl enthusiasts. There will be an increasing need for
studies into the motivational aspects of all levels of
individuals, whether students are from grammar
schools or high schools, or are personnel in government
or industry.
According to the ETV Newsletter of July 26,1971, as
an example of the future development (and one that
I believe will be widespread some years from now),
the MITRE Corporation of Bedford, Massachusetts, is
conducting a feasibility study utilizing TVICAI
through cable TV distribution. In this instance, both
the voice and the stiH pictures are transmitted via
microwave and on cable TV to homes equipped with
special terminal and TV set combinations. The company is using its time-shared interactive computercontrolled information television (TICCIT) system to
display selective material on individual TV sets. Thus,
600 TV sets can receive separate information provided
by the computer at typical rate of one frame every 10

a

seconds. The viewer is then in a position to communicate back to the computer through a 12-button telephone. The overall software for the system is designed
under the sponsorship of the National Science Foundation, which can provide individualized educational
courses for home and school use. Over courses that
have a broad-scale interest in the future, therefore, it is
quite likely that up to 10,000 TV sets in one local area
could conceivably be tied into one major system with
a number of different programs being selectively
addressed.
Microcomputers of the future, costing as low as
$2 to $3 K with keyboard and tape cassette units and a
small TV light display, could be utilized by a number
of commercial and governmental operations where
specific instruction is required. * I believe the cassette
will playa large part in the future.
Along with educational programs, we consider the
terminal hardware development. Keyboards have
varied from the standard typewriter keyboard to colorcoded keys for some special studies. It is possible the
lightweight, touch-sensitive surfaces instead of keyboards may be utilized. Common phrases that could
have a general application to a number of educational
uses may be designed into either system.
Pictorial or handwritten input may be one area of
the future, as well as the very early development of
voice input (Culler Harrison, Inc., in Goleta, California, and the Bell Telephone Labs), and, lastly, one
I am certain a number of you have seen demonstrated,
the plasma array terminals developed by Dr. Donald
L. Bitzer of the University of Illinois in conjunction
with Owens Illinois Glass Co. As some of you may recall, the view plate which replaces the video tube consists of three layers of glass with gold wires and an
X/Y axis, imbedded in an electrolyte containing neon
gas. The dots of stimulated neon gas, 3600 per square
inch, may display pictures without computer regeneration, allowing both the computer and the user to modify
the display. A number of these terminals are presently
in manufacture by The Magnavox Co. for the University. I feel this type of approach ~rill contribute a
great deal to the ability of fairJy small computers having a capability to relate through educational systems
to a number of terminals.
The software field also has a major impact upon the
future of education and training to systems analysts
and programming personnel, in that language capa-

* F. W. Blackwell, The Probable State of Computer Technology by
1980, With Some Implications for Education, P-4693 R, The Rand
Corporation, Santa Monica, Calif., Sept. 1971.

Computer Training, Present and Future

bility should certainly be on higher level than it is at
present, including switchablemicroprograms, very
large memories, associative memories, and other variables at an economical cost which could contribute
considerably to a multi-user access. In a sense, with the
technological changes, both in hardware and software,
the aspect of the present programmer training should
change markedly from the existing languages and the
present direction. One of the interesting fallouts in
teaching FORTRAN to a group of high school students
on the West Coast recently resulted in improved ability
of the students in their other courses. Apparently
there is some relationship to the logical display of
FORTRAN which overlapped into an improved understanding by these students in other subjects within
their curricula.
Another aspect of the future is the multitude of
libraries of application programs available to all facets
of industry, government, and the educational community. With improved library maintenance and cross
correlation, hopefully, many users of the future will
be prevented from "reinventing the wheel" concept,
and will be forced to thoroughly review the application
programs available before they attempt to develop
training programs on their own. Therefore, extenE?ive
markets exist for personnel to improve the development of such a compendium. Along with these application programs, however, and one of the aspects that is
not as thoroughly covered today, is that of computer
costs associated with each application program. This
type of data will definitely have to be included in any
compendium of library programs (similar to COSMIC, *
which is operated today) .
In communications, I feel many of us have seen
limitations in our present telephone equipment; however, in the near future, firms similar to DATRAN,
whose microwave towers will be completely devoted to
data processing centers throughout the United States,
as well as improvements in our present communication
equipment and satellite interface, will aid considerably
in the more economical aspects of computing, as well as
the education and training in a CAl approach throughout major time-sharing networks.
In summary, there will be a considerable change in
programming languages, major changes in terminals
and hardware equipment, and a greater interest and
acceptance of computers.

81

RECOMMENDATIONS
For the educational, governmental, or business organization involved with its own educational development, it is essential to seek a multimedia mode of
educating personnel. Do not rely on self-instructional
manuals for the individual to develop an ability on his
own. Upon completion of internal or external schooling,
maintain an open view to periodic reinforcement of
whatever course the individual attends.
Whenever possible, seek or have developed pretests
to determine the level of investment your organization
would make with the individual. It is normally wiser
to allow management personnel the prerogative for selfcorrecting to determine their level of instruction. I feel
that senior and middle management are too often neglected in the general concepts of computer technology.
Be aware of the developments in the university and
governmental areas in education and training as they
may very often be obtained without cost to your organization. The NASA data bank (COSMIC) is an
example of this.
Lastly, in returning to the major subject of this
session, that of training of commercial programmers
and systems analysts, a thorough review of the commercial school, in addition to the very excellent training
offered by the major computer manufacturers, should
be made. University or high school evening classes very
often may be an economical advantage in this evaluation. Maintain an awareness of the development of
CAl as it is being used in grammar schools, secondary
schools, and universities. Most important of all, to the
prospective programmer or analyst, be aware of the
"state of the art" changes to prevent ccmplacency.
ACKNOWLEDGMENTS
This paper presents the results of one phase of research
carried out at the Jet Propulsion Laboratory, California Institute of Technology, under Contract No.
NAS 7-100, sponsored by the National Aeronautics and
Space Administration.
APPENDIX A-COMPUTER COURSES AT
THE JET PROPULSION LABORATORY,
CALIFORNIA INSTITUTE OF TECHNOLOGY
GENERAL INFORMATION

* The Computer Software Management and

Information Center
(COSMIC) is maintained for NASA by the University of Georgia
and provides a national data bank of software programs developed and debugged by government agencies and in the public
domain.

Definition of terms

Pretest. These are self-administered, self-graded tests
whose purpose is to help the individual determine that

82

Spring Joint Computer Conference, 1972

dance or upon the demonstration of proficiency in the
techniques or skills taught.
Survey
ARE YOU
A SCF

NO

The courses were developed in response to the major
needs expressed and measured through the Training
Needs Survey.

IBM COURSES

USER?

YES

SCFPROGRAM
LIBRARY

Schematic

A diagram of the courses available is shown
Figure A-l.

III

INTRODUCTION TO COMPUTERS
Figure A-I-JPL computer course selector

For Whom:

the course is correct and that the individual is neither
underpowered nor overpowered for the course material.
The pretest also provides a general feeling of course
content.

Prerequisites:
Description:

Time distribution charts

Objectives:

Each pie chart indicates the approximate distribution of the total time of the course required both in
and out of class. The symbol "I" refers to Instruction,
"P" refers to Participation, and "H" refers to
Homework.

Text Provided:
Pretest:
Time Distribution:

Certification

Certificates of completion are issued and recorded in
the personnel file. They are based either upon atten-

Those with little or no knowledge
of computers. Quota limited.
None.
Description and explanation of
computer purposes, parts and functions, computer languages, programming concepts, and the computers at JPL.
To gain a general understanding of
computer-related technology and
terminology.
Handouts.
Recommended.

Instruction: Lectures with audiovisuals.
Participation: Discussion.
Homework:
Simple
problem
assignments.

Computer Training, Present and Future

Schedule:

Four 2-hour sessions; 2 weeks. A
new class to be held each month
during the year.

Prerequisites:

"Programming
course.

Description:

Introduction to the elements of
FORTRAN and the methods of
writing programs in it. This course
includes several illustrative problem assignments.

Objectives:

To gain ability to write simple
programs in FORTRAN.

Text Provided:

FORTRAN
notes.

Pretest:

Recommended.

PROGRAMMING FUNDAMENTALS
For Whom:

Prerequisites:
Description:

Objec#ves:

Text Provided:
Pretest:
Time Distribution:

Those with no computer programming background who plan to take
other courses in computer languages. Quota limited.
None.
Introduction to computer programming, its logic, elements,
terminology, and procedures. Preview of FORTRAN, COBOL, and
X-BASIC.
To gain general awareness of computer programming concepts and
languages.
None.
Recommended.

83

Fundamentals"

IV

primer-class

Time Distribution:

Instruction: Video-taped lectures.
Participation: Discussion.
Homework: Problem assignments.
Schedule:

Schedule:

Instruction: Live and video-taped
lectures.
Participation: Discussion.
Homework : None.
Four 2-hour sessions; 2 weeks.
Classes to be held each month during the fiscal year.

Twelve 2-hour sessions; 6 weeks.
Classes to be given on a bimonthly
basis.

FORTRAN V
For Whom:

Scientific Computing
users. Quota limited.

Facility

Prerequisites:

FORTRAN Fundamentals and
"Beginning EXEC-8" courses and
experience using the UNIVAC

FORTRAN FUNDAMENTALS
For Whom:

Beginning FORTRAN programmers who will use the Scientific
Computing Facility. Quota limited.

1108.

84

Spring Joint Computer Conference, 1972

Review of FORTRAN Fundamentals. Explanation of more extensive capabilities of FORTRAN
for advanced programming technology.

Instructor:

Self-study program with group
discussion.

Text Provided:

1108 ANS COBOL-Programmers
Reference Manual.

Objectives:

To gain ability to write sophisticated programs in FORTRAN.

Pretest:

None.

Text Provided:

FORTRAN V Reference manual.

Pretest:

Recommended.

Description:

Time Distribution:

Time Distribution:

Instruction: Lectures.
Participation: Discussion.
Homework: Program assignments.
Schedule:

Instruction: Discussion leader and
films.
Participation : Self-study.
Homework: Simple problem assignments.
Schedule:

Ten 2-hour sessions; 3Y2 weeks.
Six to eight classes per fiscal year.

Four hours self-study approximately, plus 1-hour group discussion per week; 7 weeks. Four
classes per year scheduled.

BEGINNING COBOL
BEGINNING EXEC-8 CONTROL LANGUAGE
For Whom:

Prerequisites:

Those who will use the Administrative
Computing
Facilities.
Quota limited.
"Programming
Fundamentals"
and "Introduction to Computers"
courses or equivalent.

Description:

Introduction to the elements of
COBOL and methods of writing
programs.
Several illustrative
problem assignments are included.

Objectives:

To gain ability to write simple
programs in COBOL.

For Whom:

Beginning users of the Scientific
Computing Facility. Quota limited.

Prerequisites:

Ability to use X-BASIC, FORTRAN, or COBOL.

Description:

"Introduction to EXEC-8," the
Command Language of the
UNIVAC 1108 System. Preparation of run streams, compilation of
programs, assignment and manipulation of files.

Computer Training, Present and Future

85

Objectives:

To gain ability to prepare simple
jobs for running on the UNIVAC
1108.

Text Provided:

EXEC-8 OPERATING SYSTEMS-Programmers Reference
Manual.

Text Provided:

EXEC-8 Student Handbook.

Pretest:

Recommended.

Pretest:

None.

Time Distribution:

Time Distribution:

Instruction: Lecture.
Partici pation: Discussion.
Homework: Problem assignments.

Instruction: Lecture.
Participation: Discussion.
Homework: None.
Schedule:

Schedule:

Four 1Y2 hour sessions; 2 weeks;
classes to be held each month.

TEXT EDITOR FOR THE UNIVAC 1108
For Whom:

Scientific Computing Facility users
with access to conventional terminals. Quota limited.

Prerequisites:

"Beginning EXEC-8 Control Language" course and experience In
use of conversational terminals.

Description:

Explanation of features of the
UNIVAC 1108, Text Editor and its
use at· demand terminals, creating
and modifying data or files.

Objectives:

To gain ability to utilize more
powerful and convenient methods
of manipulating Source Files from
conversational terminals.

Text Provided:

Text Editor.

Pretest:

None.

EXEC-8 CONTROL LANGUAGE

For Whom:

Scientific
users.

Prerequisites:

Extensive experience with the SCF
computer system.

Description:

Explanation of the full capabilities
of the EXEC-8 Control Language,
system file formats, and programming debugging aids and methods.

Objectives:

Computing

Facility

To gain ability to prepare jobs for
the UNIVAC 1108, utilizing the
full capabilities of the system
available to higher level language
programmers.

Ten 2-hour sessions; 5 weeks; four
classes/year.

86

Spring Joint Computer Conference, 1972

5. Additional Courses: Additional courses are given
in integrated circuit design, computer-aided circuit analysis, integrated circuit application,
speed reading, telephone practice, computer
concepts, and techniques, utilizing audio/video
(animation) program, and \\'orkbooks on various subjects in the computer field in self-study
mode, self-study audio cassette/\vorkbook in
BASIC, FORTRAN, and a computer technology course put out by the AIAA discussing
computer technology media in the next decade.

Time Distribution:

APPENDIX B-COMPUTER-RELATED
OCCUPATIONAL DESCRIPTIOXS*©
OCCUPATIONAL DESCRIPTIONS

Schedule:

Instruction: Lecture.
Participation: Discussion.
Homework: None.
Five 2-hour sessions; 272 weeks;
two classes/year.

ADDITIONAL COVERAGE IN ADP
COURSE CAPABILITY
1. Systems Analysis and Design Course: This is a
30-hour course of self-study, utilizing textual,
audio, and video media (no single medium over
15 minutes at one specific period). It is an extensive, self-study program to develop skills in
systems work for data processing personnel
(DELTAK, Schiller Park, Illinois).
2. ADP Terminology: This is a course completely
in audio, on audio tapes for personnel who wish
to become familiar with data processing terminology. One of the recommendations for taking
this course is to utilize a tape unit in a car going
to and from work, listening and repeating the
words, as well as the explanation following. This
course was developed by a firm in Ohio, and is
being utilized throughout the United States
(DYNAPHONICS, Dayton, Ohio).
3. JPL/OS: The operating system for IBM's
360/75 computers. This program is completely
on video tape for self-instruction or reinforcement, primarily to be used by the computer
personnel having advanced knowledge of computer programs.
4. FORTRAN Fundamentals: In addition to the
classroom presentation, this course can also be
taken on a self-instructional basis by video tape.

The occupations described on the following pages are
considered to be the basic occupations most directly
concerned with electronic computing. These occupations, however, are still fluid.
Hiring requirements and qualifications for employment have not yet been fully standardized. As a consequence, a certain amount of overlap and duplication of
job duties and responsibilities will be noted among the
various occupational descriptions. The occupational
data, however, were assembled from many different
sources and are a reflection of the existing situation.
Since the data reflect the occupational situation as it
exists in varied localities and establishments, the descriptions must be considered as cOIp.posites of jobs,
and cannot be expected to coincide exactly with any
job in a specific organization. It will be necessary,
therefore, to adapt descriptions to fit individual jobs
before they can be used with complete accuracy.
The job descriptions are arranged in seniority order
of their main titles. The wording of the title that appears at the head of each description is a reflection of
common usage. Other titles, by which the job is known,
also appear at the head of each description in small
type. Between the main and alternate titles appears
the code number which identifies the job within the
present classification structure of the U.S. DICTIONARy OF OCCUPATIONAL TITLES.
The narrative portion of each job description is arranged as follows:
Occupational Definition-Thi~ provides a brief description of the duties involved in a particular occupa-

* © Edutronics Systems International, Inc., 1969 (Reprinted,
with permission, from Computer Education Directory, Edutronics
Systems International, Inc., Los Angeles, California, 1969.)

Computer Training, Present and Future

tion. It provides an understandjng of the tasks that are
performed, and the skills and knowledge that are necessary to the performance of those tasks.
Education, Training, and Experience-This section
provides an indication of the amount of education and
the level of training and experience usually required by
management for employment in the occupation. As
previously mentioned, the various occupations and the
qualifications are not standardized, and considerable
variation exists among employers as to required education, training, and experience. However, an attempt
was made to indicate the range of such hiring
requirements.
Special Characteristics-This section provides some
estimate of the worker trait requirements pertinent to
the specific occupations. I t has long been believed
that the ability of an individual to adjust to specific
types of work situations is as significant as the education and training qualifications he brings to the occupation. This seems particularly significant when dealing
with a group of relatively new occupations. Consequent]y, judgments have been in terms of a number of
components consisting of aptitudes, interests, temperaments, physical activities, and environmental conditions to which individual workers have to adjust.
A ptitudes-These are the specific capacities or abilities required of an individual in order to facilitate the
learning of some task or duty. This component is made
up of 11 specific aptitude factors, and is a modification
of the aptitudes contained in the General Aptitude
Test Battery developed in the U.S. Emp]oyment
Service. Those aptitudes were selected which seem to be
significant in the occupation and were identified in terms
of specific work situations. The factor of intel1igence,
however, was not rated because of the difficulty in
writing meaningful descriptive statements.
I nterests-This component is defined as a preference
for a particular type of work experience. It consists of
five pairs of bipolar factors, arranged so that a preference for one factor in a pair generally indicates a lack
of interest in the other factor in the pair. Those factors
were identified which seemed to be significant to the
job in question, and were identified in terms of specific
worker situations.
Temperaments-The temperament component consists of 12 factors defined in terms of specific work
situations that suggest different temperament trait requirements. Each work situation describes a type of
activity that demands a different adjustment on the
part of individual workers. Those temperament factors
were selected that appeared to be significant in the
occupation, and were identified in terms of specific
work duties.

87

Physical Activities and Environmental ConditionsThis refers to (a) the physical activities required to be
met by the worker; and (b) the physical surroundings
which make specific demands upon a worker's physical
capacities. There are six physical activities factors and
seven environmental conditions factors. Those factors
were selected that were significant in the occupation in
the sense that they met established criteria for successful performance.
MANAGER, DATA PROCESSING-(169.168),
DIRECTOR, DATA PROCESSING

Occupational definition
Directs and coordinates planning and production
activities of electronic data processing division. Consults with management to define boundaries and priorities of tentative projects, discusses equipment acquisitions, determines specific information requirements of
management, scientists, or engineers, and allocates
operating time of computer systems. Confers with department heads involved with proposed projects to
ensure cooperation and further defines nature of project.
Consults
with
SYSTEMS ENGINEER, ELECTRONIC DATA PROCESSING to define equipment needs. Reviews project feasibility studies. Establishes work standards. Assigns, schedules, and reviews
work. Interprets policies, purposes, and goals of organization to subordinates. Prepares progress reports to
inform management of project development and
deviation from predicted goals. Contracts with management specialists or technical personnel to solve problems. Revises computer operating schedule to introduce
new program testing and operating runs. Reviews
reports of computer and peripheral equipment production, malfunction, and maintenance to ascertain costs
and plan operating changes within his department.
Analyzes data requirements and flow to recommend
reorganization or departmental realignment within the
company. Participates in decisions concerning personnel
staffing and promotions within electronic data processing departments. Directs training of subordinates.
Prepares proposals and solicits purchases of analysis,
programming, and computer services from outside
firms.

Education, training, and experience
Two years of formal post-high school training in data
processing with courses in business. administration and

88

Spring Joint Computer Conference, 1972

accounting or engineering, or equivalent practical experience is necessary for small computer installations.
College graduation with major in one or more of the
above fields is preferred for large installations. Experience in systems analysis, programming, and computer
operations is desirable. In installations offering more
sophisticated services, such as operations research and
engineering simulation, a college mathematics major
coupled with experience listed above is desirable.
Special characteristics
Aptitudes:

Verbal ability to translate technical terminology into
terms understandable to management and department
heads.
Numerical ability to apply knowledge of linear or
differential equations in evaluating work of department,
preparing reports and proposals for management, and
selling services to outside users.
Spatial ability to read engineering drawings, charts,
and diagrams; to understand presentations, proposed
solutions, and progress reports of business or engineering problems.
Form perception to see pertinent detail in drawing
charts, diagrams, and other presentations.
Clerical perception to detect and avoid errors in
reading and preparing reports.
Interests:

An interest in scientific and technical subjects to cope
with wide range of technical and scientific problems
processed through computer.
A preference for business contacts with people in
directing activities of computer department and to sell
ideas or services.
Temperaments:

Must be able to direct, control, and plan the operations of the division, bringing together knowledge of
operations and information needs of departments, such
as accounting, purchasing, engineering, sales, and inventory control.
Required to deal with people such as management,
department heads, and manufacturers' representatives
to exchange information and ideas, discuss equipment
and their uses, elicit information from departments,
and to answer inquiries from department heads.
Ability to influence management and department
heads to enlist their support for acceptance, expansion,

and sophistication of computer systems; and ability to
sell excess computer time and services to outside clients.
Required to make judgmental decisions concerning
equipment needs, scope of assignments, allocation of
computer time, and organization of departments.
Required to make decisions based on factual data to
evaluate progress or success of computerized projects.
Physical Activities and Environment:

Work is sedentary.
Occasionally walks to various departments and
offices; stands during conferences and discussions with
management, department heads, and supervisor of
computer operations.
Talking and hearing required in conferences and during exchanges of information.
N ear visual acuity and accommodation required for
reading reports and charts.
Work is performed inside.
PROJECT DIRECTOR, BUSINESS DATA
PROCESSING (020.168), BUSINESS-SYSTEMS
COORDINATOR; LEAD ANALYST;
PROGRAM MANAGER; PROJECT
PLANNER; SENIOR SYSTEMS ANALYST,
BUSINESS
Occupational definition

Plans, directs, and reviews business electronic dataprocessing projects, coordinates planning, testing, and
operating phases to complete project with maximum
balance of planning and equipment time, man hours
and new equipment expenditures. Prepares project
feasibility and progress reports. Confers with department heads who provide input and use output data to
define content and format. Schedules and assigns duties
to OPERATIONS RESEARCH ANALYSTS based
on evaluation of their knowledge of specific disciplines.
Coordinates activities of workers performing successive
phases of problem analysis, solution outlining, solution
detailing, program coding, testing, and debugging
(error elimination). Reviews output data and related
reports, applying knowledge of systems, procedures,
methods, and data requirements of management and
other output users to ensure adherence to predetermined standards and devise techniques for improved
performance on similar future projects. Directs revision
of continuous control project to adapt it to new data
requirements or improve operations by using new
techniques or equipment.

Computer Training, Present and Future

Education, training, and experience

A bachelor's or master's degree in business administration, with extensive course content in accounting and
mathematics or statistics often is required. Employers
frequently waive academic training requirements for
currently employed workers with extensive systems
analysis, design and followup responsibility in electronic data processing, and supervisory experience in
tabulating-machine departments. Employers frequently
require a degree or equivalent experience either in industrial engineering, or the engineering discipline most
directly related to their manufacturing processes, when
expanding business data processing to an integrated
system that includes production forecasting, planning,
and control.
Background knowledge and experience usually include a minimum of one to three years' experience in
systems analysis and concurrent familiarization with
structure, work flow requirements, and standards of the
employing organization.
Current trend is toward greater mathematical sophistication than previously expected of workers at this
level. The need for advanced mathematics becomes
more urgent as computer applications become involved
not only with normal business data-processing, but also
with the involved problems of operations research.
Special characteristics
Aptitudes:
Verbal ability to elicit information and discuss project intentions, problems and progress, and to prepare
reports.
Numerical ability to analyze problems and develop
systems statements in form capable of being programmed. Mathematics varies from arithmetic and
algebra for simple, single-purpose systems design to
differential equations and mathematical statistics for
complex systems involving optimization, simulation, or
forecasting.
Spatial ability to develop, interpret, or integrate
operational workflow diagrams and charts.
Clerical perception to recognize pertinent detail and
avoid perceptual errors when working with verbal
material, which often is in highly contracted and
conventionalized form.

89

gar ding the potentialities, limitations, and alternative
methods of data processing, supervise analysts and
coordinate their activities.
A preference for activities that are technical in nature
to read and keep informed of computer development
and) new or more refined systems and procedures
techniques.
Temperaments:
Ability to perform a variety of duties involving frequent change, ranging from direct involvement in
problem analysis to coordination of subsequent work
processes until each project is operational.
Must be able to direct and plan an entire area of
work activity, assigning subordinates on the basis of
knowledge of individual specializations and abilities,
and control activities through personal contact and
reports.
Must be able to deal with people jn nonsupervisory
situations requiring considerable tact, to secure cooperation from management and all personnel affected
by project.
Required to make decisions on a judgmental basis
when supervising others and developing approaches to
problems on basis of past experience. Evaluates fixed
cost, time, manpower allocation, and output specifications to judge efficiency of project development and
operation.
Required to make decjsions based on factual data, as
in planning proposed system around capabilities and
limitations of a specific computer system.
Physical Activities and Environment:
Work is sedentary, with occasional standing and
walking required.
Occasionally lifts and carries books, charts, diagrams,
and other records seldom exceeding 10 pounds.
Talking and hearing to discuss problems and progress.
N ear visual acuity to work with reports, charts, and
diagrams and other printed or written records.
Work is performed inside.

SYSTEMS ANALYST, BUSINESS DATA
PROCESSING-(012.168) , COMMERCIALSYSTEMS ANALYST AND DESIGNER;
DATA-METHODS ANALYST; SYSTEMS
AND PROCEDURES ANALYST, BUSINESS
DATA PROCESSING

Interests:

A preference for prestige-type activities, and for
business contact with others to participate in conferences with management, advise and inform others re-

Occupational definition

Analyzes business problems, such as development of
integrated production, inventory control and cost

90

Spring Joint Computer Conference, 1972

analysis, to refine its formulation and convert it to
programmable form for application to electronic data
processing system. Confers with PROJECT DIRECTOR, BUSINESS DATA PROCESSING and department heads of units involved to ascertain specific output requirements, such as types of breakouts, degree of
data summarization, and format for management reports. Confers with personnel of operating units to devise plans for obtaining and standardizing input data.
Studies current, or develops new systems and procedures to devise workflow sequence. Analyzes alternative means of deriving input data to select most feasible
and economical method. Develops process flow charts
or diagrams in outlined and then in detailed form for
programming, indicating external verification points,
such as audit trial printouts. May work as member of
team, applying specialized knowledge to one phase of
project development. May coordinate activities of team
members. May direct preparation of programs.
Education, training, and experience

College graduation with courses in business administration and accounting usually is required for entrants
without prior experience in data processing. Some
employers, while requiring a college degree, do not require a specific major or course content. A successful
college record is regarded as proof of ability to reason
logically which is considered more important for successful performance than knowledge of techniques acquired in any specific area. Many employers waive the
formal education requirements for those workers employed in their establishments who have had several
years' manual and machine systems experience prior to
computer conversion. Business programmers without a
college degree can, through experience, acquire a background in business systems and procedures and may
thereby advance into systems analysis. Currently, the
trend is to require a knowledge of advanced mathematics because ofthe rapidly increasing sophistication
of business systems. Continuing education, through
specialized courses, self-study, and participation in
activities of professional associations, is the rule rather
than the exception in this occupation, as in all higher
level occupations related to the computer.
Special characteristics
Aptitudes:
Verbal ability to discuss problems and progress, prepare reports, and make annotations for graphic representations of work.
Numerical ability to select from alternatives to de-

velop optimum system, procedures and methods.
Mathematical investigation of such factors as variation
in volume of input data, and frequency of appearance of
exceptions to normal \vorkflow in processing is often
necessary. Level of mathematics varied from business
arithmetic and algebra to differential equations.
Spatial ability to visualize, prepare, and review twodimensional graphic representations of \vorkflow.
Form perception to identify nonverbal symbols on
records such as block diagrams and flow charts.
Clerical perception to avoid perceptual errors and
recognize pertinent detail in the recording and identifying of letters and numbers that often occur in abbreviated or acronymic combinations.
Interests:
A preference for activities that are technical and
analytical, and those that are abstract and creative in
nature to devise new or to modify standardized computer-oriented systems to meet the specific needs of an
organization.
Temperaments:
Ability to confer with personnel from other departments, develop flow charts, devise workflow sequence,
and prepare reports.
Required to deal with people in conference and
interview situations.
Required to make judgmental decisions to select
from alternatives when devising optimal system.
Required to make decisions on basis of factual data
to design system within machine capability.
Physical Activities and Environment:
Work is sedentary, with occasional standing and
walking. Occasional handling of source documents,
books, charts, and other records that seldom exceed
10 pounds.
Talking and hearing to discuss and confer with management and technical personnel.
N ear visual acuity to prepare and review workflow
charts and diagrams.
Work is performed inside.

OPERATIONS RESEARCH ANALYST(020.088), MANAGEMENT-OPERATIONS
ANALYST; OPERATIONS ANALYST
Occupational definition

Formulates mathematical model of management
problems by application of advanced mathematics and
research methods to provide quantitative basis for
planning, forecasting, and making decisions. Analyzes

Computer Training, Present and Future

problems in terms of management information requirements. Studies problem, such as selecting from competitive proposals a plan that affords maximum probability of profit or effectiveness in relation to cost or
risk. Prepares mathematical model of problem area in
form of one or several equations that relate constants
and variables, restrictions, alternatives, conflicting objectives, and their numerical parameters. Gathers,
relates, and identifies data with variables in model by
applying personal judgment and mathematical tests.
Specifies manipulative and computational methods to
be applied to formulations and refers to data processing
division for solving equations, programming, and
processing. Reviews operations and testing of model to
ensure adequacy or determine need for reformulation.
Prepares written, nontechnical reports to management,
indicating problem solution or range of possible alternatives in rank of desirability and probability of success
when there is no single solution. Writes followup reports,
evaluating effectiveness of research implementation.
May specialize in research and preparation of contract
proposals specifying the competence of an organization
to perform research, development, or production work.
May develop and apply time and cost networks, such as
Program Evaluation and Review Technique (PERT),
to plan and control large-scale business projects. May
work in areas associated with engineering, as when
analyzing and evaluating alternative physical systems,
such as production processes, in terms of effectiveness
and cost. May work alone or as member of a team.
Education, training, and experience

College degree with emphasis on advanced mathematics and statistics is usually the minimum educationa] requirement. A combination of advanced degrees
in mathematics and business administration is especially
desirable. A doctorate in mathematics is frequently
required. Specific training in operations research at the
graduate level is rapidly becoming a standardized requirement, as more schools offer courses in this interdisciplinary occupational area. Many workers have acquired the necessary background in mathematics
through education and experience in engineering and
the physical sciences, and knowledge of specialized
techniques through self-study and participation in
activities of professional organizations.
Special characteristics
Aptitudes:
Verbal ability to understand techn1cal languages of
various professional disciplines such as engineering and

91

accounting, to give oral reports and to prepare written
reports on results of research in lay terminology to
management.
Numerical ability to understand and work with such
mathematical specializations as game, queuing, and
probability theory, and statistical inference to prepare
formulations, specify manipulative methods and evaluate effectiveness.
Spatial ability to prepare and interpret charts, diagrams, graphs, and maps.
Clerical perception to recognize pertinent detail in
compilation and analysis of statistical data, and to
avoid perceptual errors in working with higher forms of
mathematics.
Interests:

A preference for activities that are technical in nature
to apply analytical, experimental, and quantitative
techniques in the solution of management problems
such as long-range forecasting, planning, and control.
Interests in devising mathematical equations, analyzing the methods used for their manipulation, and evaluating their practical effectiveness.
Temperaments:

Requires ability to perform a variety of tasks related
to the solution of various problems on all departmental
levels. This involves conversing in several professional
disciplines with personnel at all operating levels to
gather and relate data and opinions relevant to problem under study.
Must possess ability to make judgmental decisions
such as probability of continuity or change in conditions, and assign arbitrary weights and values to problem factors when conventional statistical methods are
not applicable.
Must possess ability to make decisions based on
verifiable data, such as tabular records of previous organizational experience.
Physical Activities and Environment:

Work is sedentary, and occasionally involves lifting
and carrying books, ledgers, and statistical tabulations
seldom exceeding 10 pounds.
Talking and hearing to discuss organization goals and
priorities with management and acquire data pertinent
to the problem from other organizational personnel.
N ear visual acuity to read and work with a variety
of data from many sources, and to refer to texts and
technical papers.
Work is performed inside.

92

Spring Joint Computer Conference, 1972

CHIEF PROGRAMMER, BUSINESS-(020.168) ,
COORDINATOR, COMPUTER
PROGRAMMING; LEAD PROGRAMMER
Occupational definition

Plans, schedules, and directs preparation of programs
to process business data by electronic data processing
equipment. Consults with managerial and systems
analysis personnel to clarify program intent, indicate
problems, suggest changes and determine extent of
automatic programming and coding techniques to use.
Assigns, coordinates, and reviews work of programming
personnel. Develops own programs and routines from
workflow charts or diagrams. Consolidates segments of
program into complete sequence of terms and symbols.
Breaks down program and input data for successive
computer passes, depending on such factors as computer
storage capacity and speed, extent of peripheral equipment, and intended use of output data. Analyzes test
runs on computer to correct or direct correction of
coded program and input data. Revises or directs revision of existing programs to increase operating efficiency or adapt to new requirements. Compiles documentation of program development and subsequent
revisions. Trains subordinates in programming and
program coding. Prescribes standards of terminology
and symbology to simplify interpretation of programs.
Collaborates with computer manufacturers and other
users to develop new programming methods. Prepares
records and reports.
Education, training, and experience

Graduation from a technical school or college with
training in business administration, computer programming, data processing mathematics, logic, and
statistics is the usual educational requirement. Usually,
a minimum of two years' experience in programming
for same or similar computer system, on broadscope
and complex projects is required. Experience should
indicate knowledge of organization structure and workflow, and also reflect proven ability to supervise others
and coordinate work activities of the group supervised
with that of other organizational units.
Special characteristics
Aptitudes:
Verbal ability to present oral and written reports and
recommendations and to read technical literature about
changes in techniques and equipment.

Numerical ability to program at level of linear and
Boolean algebra (logic) to minimize expensive programming and debugging time. Mathematics at level of
differential equations and probability theory frequently
required when an organization is developing or using
sophisticated, integrated management information and
forecasting systems.
Spatial ability to interpret systems statement, develop general and detailed computer flow charts, and
prepare block diagrams that indicate hardware
configuration.
Form perception to see pertinent detail in charts,
diagrams, and code sheets composed of symbols.
Clerical perception to refer to manuals and written
instructions and to review own work. This requires
accurate identification of numbers, letters, words, and
acronyms as well as ability to grasp general content.
Interests:

A preference for activities that are technical in nature
to apply mathematics and logic in converting proposed
business systems to computer-processable form.
Temperaments:

Ability to perform a variety of duties, covering problems from different but related areas of business activity
such as production and inventory control, and sales
analysis.
Must be able to direct, control, and plan development
of business data processing programs that will meet
current and future needs. This involves direction of
activities, such as program testing and revising, and
coordination of all phases of business programming
activities to meet schedules.
Required to deal with subordinates for purposes of
control and coordination, and with systems analysis
and management personnel to resolve questions of intent and programming difficulties.
Required to make judgmental decisions based on experience to assign personnel and select and apply
techniques that will produce least cost, fastest, or most
flexible programs.
Required to make decisions based on factual data to
evaluate adequacy of completed program by comparing
program, test and operating· runs with prescribed
standards of terminology, and time.
Physical Activities and Environment:

Work is sedentary. Lifts and carries source and output data, books, charts, and diagrams seldom exceeding
10 pounds.

Computer Training, Present and Future

Stands, walks, talks, and hears in instructiDnal and
conference situations.
N ear visual acuity to prepare, integrate, or modify
complex programs, using a variety of charts, diagrams,
and handbooks.
Work is performed inside.
PROGRAMMER, ENGINEERING AND
SCIENTIFIC-(020.188), PROGRAMMER,
TECHNICAL
Occupational definition

Converts scientific, engineering, and other technical
problem formulations to format processable by computer. Resolves symbolic formulations, prepares logical
flow charts and block diagrams, and encodes resolvent
equations for processing by applying knowledge of advanced mathematics, such as differential equations
and numerical analysis, and understanding of computer
capabilities and limitations. Confers with engineering
and other technical personnel to resolve problems of
intent, inaccuracy, or feasibility of computer processing.
Observes or operates computer during testing or processing runs to analyze and correct programming and
coding errors. Reviews results of computer runs with
interested technical personnel to determine necessity
for modifications and rerun. Develops new subroutines
for a specific area of application, or expands on applicability of current general programs, such as FORTRAN,
to simplify statement, programming, or coding of
future problems. May supervise other programming
personnel. May specialize in single area of application,
such as numerical control, to develop processors that
permit programming for contour-controlled machine
tools in source-oriented language.
Education, training, and experience

College degree with major in mathematics or engineering is usually the minimum educational requirement. A master's degree or doctorate in mathematics or
engineering is a common requirement where analysis or
programming is extremely complex or where work
duties involve basic research in mathematics or programming. From two to four years of on-the-job training, with gradually decreasing amounts of supervision
and with increasingly complex work assignments, are
regarded as necessary for the worker to become familiar
with at least one class of computer, programming language, and applications area. Short (one to four weeks)

93

training sessions are given by employers and computer
manufacturers to provide basic training and (later)
specialized training. Current trends toward simplification of programming languages and greater applicability
of generalized programs, and requirement of basic
computer orientation and programming courses for
college degree in physical sciences or engineering will
reduce on-the-job training time.
Special characteristics
Aptitudes:
Verbal ability to discuss problems and equipment
requirements with other technical personnel, to prepare
computer flow charts, written records, reports, and
recommendations and to read technical publications.
Numerical ability to interpret mathematical formulation, to select from alternative computational methods, to frame program within limitations of the computer to be used, prepare logical flow charts and diagrams, to convert program steps to coded computer
instructions, and to review work. Level of mathematics
may vary from arithmetic and algebra to advanced
differential equations in the course of writing a single
program, and may also include applications of numerical
analysis.
Spatial ability to prepare logical flow charts specifying sequences of operating instructions and flow of data
through computer system, to design input and output
forms, and to interpret detailed drawings, diagrams,
and other graphic data.
Form perception to see pertinent detail in charts,
diagrams, and drawings, and distinguish symbols in
subject matter areas such as physics and electrical
engineering.
Clerical perception to avoid perceptual errors in recording of alphanumeric and special symbologies.
Motor coordination to operate calculator or
computer.
Interests:
A preference for activities technical in nature to use
mathematics to reduce formulations to computerprocessable form.
Temperaments:
Required to make decisions on a judgmental basis,
using past experience and knowledge to select best
method of programming and coding a problem and
thereby avoiding costly, time-consuming analyses of
alternate techniques.
Required to make factual decisions, such as evalua-

94

Spring Joint Computer Conference, 1972

tion of program accuracy by computer acceptance,
presence of error messages or obvious output distortions.
Must be able to conform to accepted standards and
techniques in developing and testing programs, and in
writing instructions for digital-computer operator.
Physical Activities and Environment:
Work is sedentary, requiring occasional lifting and
carrying of source data, books, charts and diagrams
seldom exceeding 10 pounds.
Talking and hearing to confer and collaborate with
other technical personnel.
N ear visual acuity to prepare logical flow charts
from lengthy mathematical statements of problem, and
to convert program steps to coded computer
instructions.
Work is performed inside.

PROGRAMMER, BUSINESS-(020.188) ,
DIGITAL-COMPUTER PROGRAMMER
Occupational definition

Converts symbolic statement of business problems to
detailed logical flow charts for coding into computer
language. Analyzes all or part of workflow chart or
diagram representing business problem by applying
knowledge of computer capabilities, subject matter,
algebra, and symbolic logic to develop sequence of program steps. Confers with supervisor and representatives
of departments concerned with program, to resolve
questions of program intent, output requirements, input
data acquisition, extent of automatic programming and
coding use and modification, and inclusion of internal
checks and controls. Writes detailed, logical flow chart
in symbolic form to represent work order of data to be
processed by the computer system, and describe input,
output, arithmetic, and logical operations involved.
Converts detailed, logical flow chart to language processable by computer (PROGRAMMER, DETAIL).
Devises sample input data to provide test of program
adequacy. Prepares block diagrams to specify equipment configuration. Observes or operates computer to
test coded program, using actual or sample input data.
Corrects program error by such methods as altering
program steps and sequence. Prepares written instructions (run book) to guide operating personnel during
production runs. Analyzes} reviews, and rewrites programs to increase operating efficiency or adapt to new
requirements. Compiles documentation of program development and subsequent revisions.· May specialize in
writing programs for one make and type of computer.

Education, training, and experience

Minimum requirements are high school graduation
with six months to two years of technical training in
computer operations and in general principks of programming and coding, or equivalent job experience in
these areas. Current trend is to hire college graduates
for promotional potential with training in accounting,
business administration, and mathematics, and provide
them with a year of on-the-job training to qualify
them for programming. In installations concerned with
the application of the computer to more complex areas
such as market research and statistical forecasting, a
college degree in mathematics is preferred.
Special characteristics
Aptitudes:
Must possess verbal ability to understand and analyze oral or written statements concerning a variety of
business problems and to discuss them with others.
Must possess numerical ability to interpret workflow
charts, program problems, and understand machine
logic. Level of mathematics varies from arithmetic and
algebra for simple business data processing problems to
differential equations and mathematical statistics for
involved problems such as forecasting or optimization.
Must possess spatial ability to interpret diagrammatic representations of workflow, and to visualize flow
of data through computer system to prepare computer
block diagrams and logical flow charts.
Must possess form perception to see pertinent detail
in symbols when reading, interpreting, or preparing
charts, diagrams, and code sheets.
Clerical perception to detect errors in letters, words,
and numbers recorded on charts, diagrams, and code
sheets.
Interests:
An interest in activities technical in nature to effectively analyze problems, and to design logical flmv
charts and block diagrams.
An interest in activities that are carried out in relation
to processes, techniques, and machines to plan sequence
steps, to prepare instructions, and to test programs.
Temperaments:
Required to make judgmental decisions to plan
logical sequence of steps and prepare logical flow chart
for a project, keeping in mind capacities and limitations
of computer and integrated machine units.
Must be able to conform to accepted standards and

Computer Training, Present and Future

techniques in developing and testing programs, and
writing instructions for computer operators to follow.
Physical Activities and Environment:
Work is sedentary, requiring occasional lifting and
carrying of such items as source materials, run books,
and documentations seldom exceeding 10 pounds.
Talking and hearing to communicate with systems,
program coding, and operating personnel.
N ear visual acuity and accommodation required to
review statistical data and interpret charts and
diagrams.
Work is performed inside.

PROGRAMMER, DETAIL-(219.388),
JUNIOR PROGRAMMER; PROGRAM
CODER

95

Special characteristics
Aptitudes:
Verbal ability to recognize programming and coding
language consisting of abbreviated words, grouping of
numbers, symbols, or mnemonics.
Numerical ability to convert decimal numbers to
binary or other number systems.
Form perception to recognize and remember graphic
symbols (arrangement of lines and curves).
Clerical perception to select from handbooks codes
acceptable to computer, which involves accurate identification and recording of numbers, letters, and words.
Interests:
A preference for activities of a routine, concrete and
organized manner to code programs, using standardized
codes.

Occupational definition

Selects symbols from coding system peculiar to make
or model of digital computer and applies them to successive steps of completed program for conversion to
machine-processable instructions. Reads and interprets
sequence of alphabetic, numeric, or special characters
from handbook or memory for each program step to
translate it into machine language or pseudo (symbolic)
code that can be converted by computer processor into
machine instructions. Records symbols on worksheet
for transfer to punchcards or machine input tape.
Marks code sheet to indicate relationship of code to
program steps to simplify debugging of program. Confers with programming personnel to clarify intent
of program steps. Usually works as understudy to
PROGRAMMER, BUSINESS performing such additional tasks as converting flow charts and diagrams of
simple problems from rough to finished form, or making
minor changes in established programs to adapt them
to new requirements.

Temperaments:
Ability to perform repetitive tasks according to set
procedures, to refer to source books for symbologies and
select appropriate codes for each detailed step in program. Steps may number into the thousands.
Required to work to precise and established standards
of accuracy in recognition of steps of detailed program
and in selecting and recording codes. Any mistake can
introduce error into programs and either prevent
processing or distort output of program when processed.
Physical Activities and Environment:
Work is sedentary. Work sheets and code books seldome exceed five pounds.
Continuously handles pencils, work sheets, and code
books while interpreting program steps, finding representative coding, and posting codes to work sheets.
N ear visual acuity to select correct alphabetical,
numerical, or special symbols to convert detailed program to machine-processable form.
Work is performed inside.

Education, training, and experience

Must be high school graduate. Some training in programming, coding, and computer operations at technical school level is desirable. Experience in computer
operations is preferred, but six months of job experience,
most often in a clerical capacity, to become familiar
with company operations, workflow, standards, and
terminology is the minimum requirement. One to four
weeks classroom training in coding for specific computer is usually provided by employer or computer
manufacturer. Some employers favor college graduates
in order to enhance the worker's promotion potential.

SUPERVISOR, COMPUTER OPERATIONS(213.138), CHIEF CONSOLE OPERATOR;
SENIOR CONSOLE OPERATOR;
SUPERVISOR, DATA PROCESSING;
SUPERVISOR, ELECTRONIC DATA
PROCESSING
Occupational definition

Supervises and coordinates activities of workers who
operate electronic data processing machines. Assigns

96

Spring Joint Computer Conference, 1972

personnel and schedules workflow to facilitate production. Directs training or trains personnel in operation of
computers and peripheral and off-line auxiliary equipment. Works with programming personnel in testing
new and revised programs. Develops operating methods
to process data, such as devising wiring diagrams for
peripheral equipment control panels, and making minor
changes in canned (standardized) programs or routines
to modify output content or format. Directs insertion
of program instructions and input data into computer,
and observes operations. Aids operators in locating and
overcoming error conditions. Makes minor program
and input data revisions through computer console to
maintain operations. Notifies programming and maintenance personnel if unable to locate and correct cause
of error or failure. Revises operating schedule to adjust
for delays. Prepares or reviews records and reports of
production, operating, and down-time. Recommends
changes in programs, routines, and quality control
standards. Consults with MANAGER, ELECTRONIC
DATA PROCESSING about problems, such as including new program testing and operating runs in
schedule and arranging for preventive maintenance
time. Coordinates flow of work between shifts to assure
continuity. May supervise personnel engaged in keypunching, data typing, and tabulating.
Education, training, and experience

High school graduation is the minimum requirement.
Usually a minimum of one to three years' experience in
operating computers, peripheral, and off-line equipment
is required. A familiarization with programming and
coding techniques usually gained through experience in
computer operation or a course in programming are
additional prerequisites. However, a two-year post-high
school training course in electronic data processing
may reduce experience requirements. Training in business administration, mathematics, and accounting is
regarded as particularly desirable. Some employers require a college degree, particularly in large installations
where work duties are largely administrative, and also
in order to enhance the worker's promotion potential.
Experience in supervising personnel is desirable.
Special characteristics

Numerical ability to level of arithmetic and algebra
to cope with error or stoppage situations in computer
operations; to plan operating changes; and to prepare
variety of reports, often on a daily basis such as revision
of average time requirements for processing data or cost
allocations to departmental users.
Spatial and form perception to prepare wiring diagrams, wire control panels for peripheral machines, and
operate equipment.
Clerical perception to review records of production,
operating and down-time, and recognize pertinent detail
in computer printout dumps.
Interests:

A preference for business contact with others to confer with management, technical personnel, suppliers of
input data, and users of computer output, and to supervise and train subordinates.
A preference for activities that are technical in nature
to keep informed of new techniques for operation of
current machines.
Temperaments:
Ability to perform a variety of tasks subject to frequent change, such as training and assigning personnel,
accommodating changes in production schedules to
meet priority runs, maintaining records, and developing new operating procedures.
Must be able to direct, control, and plan the activities
of computer operators, satellite input-output computer
operators, on-line and off-line peripheral equipment
operators, and tape librarians.
Required to deal with people such as other departmental supervisors to resolve problems concerned with
the scheduling, adequacy, and accuracy of input data.
Required to make decisions on a judgmental basis to
set up work assignments that make maximum use of
workers' knowledge and ability, and most effective and
economical use of computers and peripheral equipment.
Required to make decisions on a factual basis when
developing schedules for processing programs, relating
such factors as date of program receipt, priorityassignment, estimated run time, and available computer time.
Compares output requirements against available equipment, and existing programs, routines, wiring diagrams,
and control panels to determine need for developing or
modifying operational methods, or altering operating
schedule.

Aptitudes:

Verbal ability to train and supervise subordinates,
confer with other supervisory and technical personnel,
and prepare records and oral or written reports.

Physical Activities and Environment:

Work is light, requiring frequent standing and walking and occasional lifting and handling of reels of tape,

Computer Training, Present and Future

decks of punchcards, and control panels weighing up to
20 pounds.
Talking and hearing to give oral instructions, assign
work, and train personnel. Confers with management
and others, discussing such items as budget requirements and staffing, machine capability, and production
problems.
N ear visual acuity to frequently analyze records, prepare reports, study program run books, and read
technical literature.
Work is performed inside.

COMPUTER OPERATOR-(213.382),
COMPUTER OPERATOR; CONSOLE
OPERATOR
Occupational definition

Monitors and controls electronic digital computer to
process business, scientific, engineering, or other data,
according to operating instructions. Sets control
switches on computer and peripheral equipment, such
as external memory, data communicating, synchronizing, input, and output recording or display devices, to
integrate and operate equipment according to program,
routines, subroutines, and data requirements specified
in written operating instructions. Selects and loads input and output units with materials, such as tapes or
punchcards and printout forms, for operating runs, or
oversees operators of peripheral equipment who perform these functions. Moves switches to clear system
and start operation of equipment. Observes machines
and control panel on computer console for error lights,
verification printouts and error messages, and machine
stoppage or faulty output. Types alternate commands
into computer console, according to predetermined instructions, to correct error or failure and resume operations. Notifies supervisor of errors or equipment stoppage. Clears unit at end of operating run and reviews
schedule to determine next assignment. Records operating and down-time. Wires control panels of peripheral
equipment. May control computer to provide input or
output service for another computer under instructions
from operator of that unit.
Education, training, and experience

A high school education meets the minimum educational requirements of some employers, but an increasing number of employers are demanding an additional

97

several months to two years of technical school training
in data processing. This training usually includes such
courses as data processing mathematics, accounting,
business practices, elementary programming, and operation of computers, peripheral equipment, and tabulating machines.
The employer or computer manufacturer usually
provides one to three weeks of formal instruction for
the specific computer system the worker will operate.
Length of subsequent on-the-job training and experience required to achieve adequate performance ranges
from a few months to one year because computer systems and equipment vary in complexity and need for
operator intervention. Except in small units, a minimum of three to six months prior experience in operation of peripheral equipment frequently is required.

Special characteristics
Aptitudes:

Verbal ability to comprehend technical language of
operating instructions and equipment manuals and to
explain clearly any operating problems and difficulties
in interpreting program intent.
Numerical ability at level of arithmetic to prepare
operating records, time computer runs, and adhere to
fixed operating schedule. While not always an operator
requirement, an understanding of data processing
mathematics (the number systems used, algebra and
logic) is almost essential to discuss operating difficulties
with programming personnel, and to progress from
routine production runs to the testing of new programs.
Spatial perception to wire control panels for peripheral equipment.
Form perception to identify flaws in input and output
materials.
Clerical perception to avoid perceptual errors in preparing operating records, and to recognize alphabetic,
numeric, and mnemonic symbols.
Motor coordination, to rapidly set up machines and
to move keys and switches to quickJy correct errors or
stoppages.
Interests:

A preference for working with machines and processes
to continuously operate and monitor the equipment
that comprises the computer system.
Interest in activities of concrete and organized
nature to operate machines according to specific and
detailed instructions.

98

Spring Joint Computer Conference, 1972

Temperaments:

Work situation requires ability to perform a variety
of work tasks subject to frequent change in the simultaneous operation of a console and a variety of peripheral equipment, the integration of which varies from
program to program, or even during a single operating
run, and which demands rapid transfer of attention
from one piece of equipment to another.
Accuracy required to operate system effectively and
minimize down-time and rescheduling of runs. Carelessness in following written and oral instructions can
cause extensive rebuilding of program or input data, or
even lead to irrecoverable loss of data.
Physical Activities and Environment:

Work is light. Lifts, carries, and positions tape reels,
punchcard decks, output forms, and control panels seldom exceeding 20 pounds.
Stands and walks frequently when loading and
monitoring machines.
Reaches for and fingers switches and keys on console
and peripheral machines. Wires control panels, loads
and removes input and output materials.
Talking and hearing to frequently exchange information concerning program and system requirements with
other workers and to receive or give instructions.
N ear visual acuity and .accommodation to follow
detailed operating log, monitor computer and peripheral
machines for signs of malfunction, and analyze console
messages or high-speed printer output for cause of
error or stoppage.
Color vision to distinguish between colored wires
when wiring control panels, to identify color-coded
cards or forms and to monitor colored display lights if
used.
Work is performed inside.
COMPUTER-PERIPHERAL-EQUIPMENT
OPERATOR-(213.382), ASSISTANT
CONSOLE OPERATOR; TAPE HANDLER
Occupational definition

Operates on-line or off-line peripheral machines,
according to instructions, to transfer data from one
form to another, print output, and read data into and
out of digital computer. Mounts and positions materials, such as reels of magnetic or paper tape onto
spindles, decks of cards in hoppers, bank checks in
magnetic ink reader-sorter, notices in optical scanner,
or output forms and carriage tape in printing devices.

Sets guides, keys, and switches according to oral instructions or run book to prepare equipment for operation. Selects specified wired control panels or wires
panels according to diagrams and inserts them into
machines. Presses switches to start off-line machines,
such as card-tape converters, or to interconnect on-line
equipment, such as tape or card computer input and
output devices, and high-speed printer or other output
recorder. Observes materials for creases, tears, or
printing defects and watches machines and error lights
to detect machine malfunction. Removes faulty materials and notifies supervisor of machine stoppage or
error. Unloads and labels card or tape input and output
and places them in storage or routes them to library.
Separates and sorts printed output forms, using decollator, to prepare them for distribution. May operate
tabulating machines, such as sorters and collators.
Education, training, and experience

High school graduate. Post-high school training in
operation of electronic or electromechanical data
processing equipment is desirable. Employers frequently
regard worker as understudy to computer operators
and apply same education and aptitude standards to
them.
Special characteristics
Aptitudes:

Verbal ability to read written instructions and handbooks and to communicate with supervisor about
operating functions.
Spatial ability to follow diagrams to wire control
panels, position and thread tapes onto spindles or position decks of cards1.n hoppers.
Clerical perception to identify and record, without
error, data such as dates, program numbers, departments, and routings on forms.
Motor coordination and finger and manual dexterity
to load and unload machines quickly and minimize
down-time, to thread ribbons of tape over guides and
through rollers, and to handle cards and tapes deftly
without bending, tearing, or otherwise damaging them.
Interests:

An interest in activities concerned with machines,
processes, and techniques to operate various machines.
Preference for activities of a routine and organized
nature to follow well-defined instructions for any of
several different machines.

Computer Training, Present and Future

Temperaments:
Worker must be adept at performing a variety of
tasks requiring frequent change to operate a number of
machines in varying combinations and sequences.
When operating peripheral equipment, must adhere
to established standards for accuracy, such as observing printer output forms for defects in alinement,
spacing, margin, and overprinting. Immediate response
to indication of error in operation of peripheral equipment is vital.
Physical Activities and Environment:

Work is light, involving frequent standing and walking when operating machines and lifting and carrying
tapes, cards, and forms not exceeding 20 pounds.
Reaches, handles, and fingers to mount tapes onto
spindles, position decks of cards in hoppers, and thread
tape through guides and rollers of peripheral units or
wire control panels.
N ear visual acuity to read labels on reels, to wire
plug boards from diagrams, to scan printout for error,
and to read operating instructions and handbooks.
Color vision to distinguish between various colors of
wires to ensure correct wiring of control panels.
Work is performed inside.
CODING CLERK-(219.388)
Occupational definition

Converts routine items of information obtained from
records and reports into codes for processing by datatyping or key-punch units, using predetermined coding
systems. Manually records alphabetic, alphanumeric,
or numeric codes in prescribed sequence on worksheet
or margin of source document for transfer to punchcards or machine input tape. May be designated according to trade name of computer system as CODING
CLERK, UNIVAC; IBM CODER.
Education, training, and experience

High school graduation usually is required. Training
of a day or two in a classroom situation or under the
direction of an experienced worker usually is provided
by the employer. Achievement of adequate speed, and
particularly the development of a high degree of accuracy, takes from one to three months. Achievement
of speed involves memorization of many of the codes.
Familiarization with standard business terminology and
abbreviations, and with special conventions used by
the employer can reduce the time necessary to achieve
adequate performance.

99

Special characteristics
Aptitudes:
Verbal ability to understand written and oral instructions, business terms, abbreviations, and mnemonic
contractions, and to explain difficulties to supervisor.
Clerical perception to scan and extract pertinent detail from source documents, and to avoid and detect
perceptual errors.
Interests:
A preference for activities of a routine, concrete,
organized nature to code according to a predetermined,
standardized system.
Temperaments:
Work activities are repetitive and short cycle in
nature. Converts each item into the equivalent code in
the allowable time cycle of a few seconds.
Must follow specific instructions to convert items to
their coded equivalents which are indexed in tables or
handbooks.
Physical Activities and Environment:
Work is sedentary. Reaches for, lifts, and handles
handbooks, papers, and forms seldom exceeding five
pounds.
N ear visual acuity to read and convert items to
codes.
Work is performed inside.

TAPE LIBRARIAN-(223.387)
Occupational definition

Classifies, catalogs, and maintains library of magnetic
or punched paper tape or decks of magnetic cards or
punchcards used for electronic data processing purposes. Classifies and catalogs material according to content purpose of program, routine or subroutine, and
date on which generated. Assigns code conforming with
standardized system. Prepares index cards for file
reference. Stores materials and records according to
classification and catalog number. Issues materials and
maintains charge-out records. Inspects returned tapes
or cards and notifies supervisor if worn or damaged.
May maintain files of program developmental records
and operating instructions (run books). May operate
key-punch to replace defective punchcards and produce
data cards to identify punchcard decks. May work in
computer room performing such tasks as loading and
removing printout forms, reels of tape, and decks of
cards from machines.

100

Spring Joint Computer Conference, 1972

Education, training, and experience

High school graduate, preferably with commercial
background. Three to six months experience as catalog
clerk, file clerk, mail clerk, or messenger with the company is desirable.
Special characteristics
Aptitudes:
Verbal ability to read information on labels describing contents of decks of cards and reels of tape and read
catalogs that contain standardized codes and
ab breviations.
Numerical ability to count, add, and subtract numbers to perform inventory functions.
Clerical perception to note pertinent detail on labels,
cards, or work schedules, and in code books to detect
error and avoid misinterpretation.

to machine and previously punched program card
around machine drum to control duplication and spacing of constant data. Loads machine with decks of
punchcards. Moves switches and depresses keys to
select automatic or manual duplication and spacing,
selects alphabetic or numeric punching, and transfers
cards through machine stations. Depresses keys to
transcribe new data in prescribed sequence from source
material into perforations on card. Inserts previously
punched card into card gage to verify registration of
punches. Observes machine to detect faulty feeding,
positioning, ejecting, duplicating, skipping, punching,
or other mechanical malfunctions and notifies supervisor. Removes jammed cards, using prying knife. May
tend machines that automatically sort, merge, or
match punchcards into specified groups. May keypunch numerical data only and be designated KEYPUNCH OPERATOR, NUMERIC.
Education, training, and experience

Interests:
A preference for working with things and objects,
following routine and organized patterns to classify,
catalog, store, and fill requests for cards and tapes.
Temperaments:
Follows specific instructions and established procedures to receive, store, issue, and purge materials.
Physical Activities and Environment:
Work is light, involving frequent standing and walking to carry reels of tapes or trays and drawers of cards
weighing less than 20 pounds between desk, handtruck,
file cabinets, and racks.
Reaches for and handles tapes and cards to store
them.
N ear visual acuity to read and assign identification
symbols and inspect materials for damage.
Work is performed inside.

KEY-PUNCH OPERATOR-(213.582),
CARD-PUNCH OPERATOR; PRINTINGCARD-PUNCH OPERATOR;
PRINTING-PUNCH OPERATOR

High school graduate preferred with demonstrated
proficiency in typing on standard or electric typewriter.
High school or business school training in key-punch
operation is desirable. Frequently, one week of training
is provided by employer or manufacturer of equipment.
Special. characteristics
Aptitudes:

Verbal ability to understand oral and written instructions, such as manufacturers' operating manuals,
and to Jearn operation of machine.
Clerical perception to perceive pertinent detail in
tabular material consisting of combinations of letters
and numbers, and avoid perceptual error in transferring
this data to punchcards.
Motor coordination to read work sheets and simultaneously operate keyboard of approximately 40 keys
to punch data on cards.
Finger dexterity to move switches on machine.
Interests:
Preference for organized and routine activities to
transfer data onto punchcards.

Occupational definition

Operates alphabetic and numeric key-punch machine, similar in operation to electric typewriter, to
transcribe data from source material onto punchcards
and to reproduce prepunched data. Attaches skip bar

Temperaments:
Must be able to perform repetitive duties of operating key-punch machine.
Ability to follow specific instructions and set procedures to transfer data onto punchcards.

Computer Training, Present and Future

Required to work to precise and established standards
of accuracy to key-punch data at high rate of speed.
Physical Activities and Environment:
Work is sedentary with infrequent lifting of decks of
cards when loading machine.

101

Reaches for and handles code sheets, business records,
and decks of cards; fingers switches and keys to operate
machine.
N ear visual acuity to read copy when key-punching.
Work is performed inside.

The future of minicomputer programming
by D. J. WAKS and A. B. KRONENBERG
A pplied Data Research, Inc.
Princeton, New Jersey

by typically providing little general-purpose software*
with their minis. Although manufacturers have recently attempted to provide reasonable program-creation software, the majority of available assemblers still
lack such de8irable features as macros, conditional
assembly, literals, and multiple location counters.
Program-execution software for most small computers is
often so weak that the user usually is left to write his
own disk handler, communications package, or real-time
executive. Even in cases where a manufacturer does
provide such software, it usually requires a configuration
that is uneconomically large.
The manufacturers' software planners seem to
exhibit the minicomputer syndrome more than many
of their customers. They continue to design separate,
single-application monitors apparently assuming that
the user will employ his mini only for real-time applications, file processing, communications, or report writing.
Thus, the user who wants a single monitor system to
support some combination or all of these must either
adapt a manufacturer-supplied monitor or build one
from scratch.
This lack of coherent manufacturer software support
has also been characterized by a lack of standardization
and conventions or standardization of poor or unworkable conventions in the software. This in turn has led
to a proliferation of software to dismay any ecologist.
For example, how many different assemblers now exist
for the DEC PDP-8 family? We were able to count a
baker's dozen in two minutes of trying; there must be
an equal number we didn't think of or don't know about.
Finally, this lack of standards and conventions has
resulted in incompatibility from one user to another.
Software modules created for one user's executive and
assembler can be neither assembled nor run at another
user's site. We have been involved in more than one

"Here is Edward Bear, coming downstairs now,
bump, bump, bump, on the back of his head,
behind Christopher Robin. It is, as far as he
knows, the only way of coming downstairs, but
sometimes he feels that there really is another
way, if only he could stop bumping for a moment
and think of it. And then he feels that perhaps
there isn't."

Beginning of Winnie-the-Pooh, A. A. Milne

INTRODUCTION
The minicomputer syndrome

The programming of minicomputers to date has
resembled Pooh Bear coming downstairs because
although we feel that there really is another way, we
rarely stop bumping. Programmers for small computers
have long exhibited what we call "the minicomputer
syndrome", which is a very low expectation of program
support and facilities on a minicomputer and a lack of
appreciation of the hardware and software tools one can
employ to attack and solve a programming problem.
l\iinicomputers came on the market when it was first
realized that small general-purpose stored-program
computers could be competitive with complex hardwired systems built from general-purpose logic modules.
Not at all surprisingly, the manufacturers of logic
m?~ules quickly became the leading developers of
mmIComputers. Since the programming process was
viewed as an unfortunately necessary step in making
the mini behave like the hard-wired system it was
replacing, very little general-purpose programming
support was provided with the minis. Thus the
. .
'
mmIComputer syndrome-the belief that primitive
computers require primitive programming support-was
born virtually at the same time as the mini itself.
Computer manufacturers have fostered this syndrome

* General-purpose

software can be classified as either programcreation software (text/file editors, language processors), or
program-execution software (monitors, device drivers, real-time
executives).

103

104

Spring Joint Computer Conference, 1972

project requiring that a program be manually transliterated from one dialect for a computer to another.
What is a minicomputer?

The paper is intended to describe programming for
minicomputers. What do we mean by "minicomputer"?
Let us begin by characterizing the small computer as
having:
(a) A short word and register length, always 18 bits
or less; a small computer, therefore cannot
perform single-precision floating-point arithmetic
through either the hardware or software.
(b) A main memory provided in modules of 8K words
or less (typically 4K words).
(c) An instruction set and, commonly, its addressing
mode which are restricted, usually having a
rather short operation code field in its machinelanguage structure.
One more characteristic is required to define what we
mean by a mini: if a machine passes the test for a small
computer, and you can't ordinarily buy it without an
ASR Teletype ®, it is a mini. If you can't ordinarily buy
it without a card reader, it isn't a mini, it's just a small
computer.
The virtual machine and the extensible machine

Let us digress for a moment and define some useful
concepts we will refer to throughout the remainder of
this paper. The concept of the "extended machine" was
first propounded by Holt and Turanski;1 we will use the
term "virtual machine" interchangeably with extended
machine. Here we are using the term "virtual" in its
dictionary2 sense: "Virtual, apparent, as contrasted
with actual or absolute." That is, the virtual or
extended machine is what the computer user, on some
level, sees and uses. Another way of saying this is to
describe it as the set of primitives with which he must
work. Watson 3 defines a "virtual processor" in a
timesharing system in a similar way. The "virtual
memory" concept in paged computers is a similar
derivation.
As it is, the computer user rarely sees or uses the
"actual or absolute" machine. To do so, he would have
to write all his code in machine language. Language
processors, executive systems, device drivers, et al., are
all extensions to the machine which substantially affect
®

Teletype, a registered trademark of the Teletype Corporation.

the user's view of the machine. For instance, a mInIcomputer with a disk operating system appears to be a
very different machine from one with only paper-tapeoriented software. A mini with a manufacturer-provided
real-time executive appears to be a very different
machine from one without it to the user with a data
acquisition and reduction problem. In this sense, then,
all available software and hardware options act as real
extensions to the "actual" machine.
When certain types of extensions are preplanned into
the computer hardware and software design, the
resultant machine is considered "extensible"-to the
extent that such extensions are planned. We characterize
these extensions as being expansions of primitives on
three distinct levels: the hardware or "firmware" level;
the system software level; and the applications software
level. On each level, the user can implement new
extensions, typically visible at the next higher level
(further away from the hardware) although sometimes
available at the same level.
The first and lowest level of extensibility is at the
hardware or firmware level. By hardware extensibility,
we mean the ability to add new operation codes,
typically for I/O but also for CPU purposes. Thus,
a supervisor call facility was added to a PDP-8 four
years ago to provide for user-supervisor communication
in a real-time system for TV control room automation.
This form of extensibility is designed-in, and encouraged, although only rarely used to augment CPU
primitives. By firmware extensibility, we mean extensions through modifications or additions to microcode
on those computers (such as all machines in the Interdata family) which have a two-level (micro and user)
programming structure. 6 This ability to modify or
augment the instruction repertoire of the machine is a
powerful way, albeit rarely exploited, to extend the
machine at the lowest level; the new primitives thus
created are fully comparable to the original instructions
of the actual machine.
The second level of extensibility is at the software level
through creation of system software. By system software,
we mean such obvious extensions as operating systems,
device drivers and interrupt handlers, and any programcreation software, especially language processors, which
can drastically change the primitives available to the
end user. Planned extensibility at this level implies such
hardware features as:
(a) A user mode/supervisor mode distinction, providing a trap of some kind against the execution
of .reserved instructions in user mode, and
providing some kind of "supervisor call" facility.
(b) An approach to I/O on the hardware level which

The Future of Minicomputer Programming

provides for substantial compatibility of the I/O
mechanisms from device to device, particularly
with respect to interrupts and status information.
(c) Some method for extended address mapping
which .provides for hardware protection and
relocation, thus relieving the mini user of his
worst problem-severe limitations on addressing.
The third and highest level of extensibility is on the
user software level. Planned extensibility provides the
end user with the capability of augmenting the apparent
set of primitives he uses in writing his programs. Such
long-used techniques as subroutines and macros both
constitute expansions of primitives, particularly when
used together, e.g., a macro used to generate a calling
sequence for a subroutine which performs some complex
function.
lVIany sophisticated programmers for minis, particularly those coming from a large-computer background,
habitually define large numbers of macros to provide
extended primitives comparable to those found in the
actual instruction set on large machines. In this way,
the experienced programmer of a minicomputer views
the problem of programming a mini as being no different
from that for a large computer, effectively countering
the purveyors of the "minicomputer syndrome" by
using the same techniques, approaches, and skills
developed for large computers. The manufacturer can
plan for extensibility on this level by providing the user
with macro features in the assembler and by providing
flexible hardware and software techniques for invoking
subroutines.
Let us close this introduction by noting that each
layer of extension, although providing a new set of
primitives to the next higher level, may also reduce the
original set of primitives available on that level. A set of
device drivers for I/O handling, once defined, usually
prevents the user from writing code to use a new I/O
device in a substantially different way from that
standardized by the drivers added as extensions; he also
loses, in the process, any capability of doing I/O
operations himself, since attempts to do so are trapped
by the hardware.
Additionally, a Basic system-editor, compiler, and
operating system combined-gives the Basic user a
different and more powerful set of primitives than he
has in assembly language, but deprives him of the
ability to perform operations in assembly language, even
though this might be far preferable for some aspects of a
given problem. Thus, the extended machine may look to
the user quite different from the original machine, with
some primitives added and others deleted, at the
extender's discretion.

105

The remainder of this paper is devoted to describing
many kinds of extensions which we see occurring now
and in the future. Since this paper is principally about
software, we will concentrate on extensions to the
second and third levels. However, we feel that current
hardware developments will encourage software-like
extensions at even the lowest level, and we will discuss
these implications also. Hopefully, viewing the minicomputer as more closely related to the large-scale
computer than the hard-wired controllers it was
originally designed to replace will lead to alleviating the
underlying symptoms of the minicomputer syndrome.
THE MINI AS A GENERAL-PURPOSE
COMPUTER
We will first discuss the minicomputer as it may be
viewed by the applications programmer in the future. To
do this, we will first examine a significant difference in
the evolution of larger computer software as opposed to
minicomputer software.
Both scales of computers developed from the same
base: machine-language programs loaded into memory
via manually produced media (cards or paper tape)
followed by console debugging with the user setting
switches and reading lights on the computer. In the
history of large computers, the first executive systems
were batch monitors, which were quite widely developed
by 1960. These batch monitors provided for submitting
"jobs" on decks of cards to the computer center where
they were eventually entered into the "job stream" and
run. All programming and debugging tools developed
for large computers during most of the 1960s were
oriented to batch operation; and today virtually all
operating systems for today's large computers are
optimized for batch processing. Nearly all commercial
programming, and most university programming, is
today done using batch monitors on computers including
the IBNI 360 and 370, the Univac 1108, and the CDC
6600 and 7600. Recently, a trend has started toward
providing some sort of support for interactive programming, debugging, and program execution. Except for
several large computers explicitly designed for interactive operation in time-shared applications (specifically the XDS 940 and the DECsystem-10, both
produced by companies previously known for minis),
the machines were originally designed for batch
operation and modified in both hardware and software
to support interactive operation. The IB::vr 360/67 is a
modification to the 360/65, the Honeywell (GE) 645 to
the 635, the Spectra 70/46 to the 70/45. These machines
seem to have been grudgingly provided by the manu-

106

Spring Joint Computer Conference, 1972

facturers to meet what they saw as a small, uneconomical, but prestigious market; none of them provide
nearly as good interactive operation as machines and
software designed to be interactive from the beginning.
In particular, a system like the DECsystem-l0 can
provide program interaction with the user on a
character-by-character basis through the user's teletypewriter; no machine based on a 2741-type terminal
can possibly do so, since the terminal and its supporting
computer-based interfaces are designed to operate
strictly on a half-duplex, line-at-a-time basis. But· the
trend would appear to be toward expanded interactive
and conversational uses of large computers, particularly
as management information systems make terminal
access to data bases desirable in real time.
l\1:inicomputer programming started in the same way
as the large computers. Paper tape was the primary I/O
medium, read in by an ASR-33 Teletype ®, with the
computer console used for all debugging. Since minicomputers cost so much less than large computers, there
was much less pressure to get away from consofe
debugging, particularly as it was recognized as being a
very cost-effective tool for a competent programmer.
When it became clear that it was possible to create
software tools to facilitate debugging, it was natural to
use the Teletype®, which was there anyway (recalling
our definition of a minicomputer), as the I/O device
around which to design the "monitor." The first
interactive programs for minicomputers, using the
"console teletypewriter" to provide interaction with the
user, were symbolic editors and debugging tools
(particularly DDT,7 a debugging system produced at
MIT for the PDP-I). Many other interactive systems
for minis are described in an earlier paper by one of the
authors.8 Interactive systems of all kinds are common
today on virtually all minicomputers. In addition to
symbolic editors and debugging ,systems, there are
full-scale Basic systems for one or several users on many
minis; several minis have Disk Operating Systems
designed for conversational control from the console
teletypewriter, single-user and multi-user interpretive
systems derived from JOSS ® running on one or more
terminals. etc.
N ow that minicomputer configurations often include
peripherals, such as mass storage on removable disk
packs, card readers, line printers, magnetic tapes,
formerly found only on large computers, we see a trend
toward the use of batch operating systems on minicomputers. Such systems, typically based on RPG
and/ or Fortran as higher-level languages, are closely

®

JOSS, a registered trademark of the RAND Corporation.

modeled after large-machine batch systems. The
resulting virtual machine thus looks almost, if not completely, like the virtual machines erected on larger-machine
bases. A user programming in Fortran or RPG, both
relatively standardized languages, cannot tell, when he
submits a deck and gets back his reports, whether it was
run on a large computer or on a mini (except, perhaps,
by the size of the bill!).
Thus, large computers and minis are becoming more
and more alike-at least from the point of view of the
applications programmer. The authors hope that the
significant advantages of interaction between the user
and the computer, so prominent in the development of
minicomputer software, will not be disregarded by the
mini manufacturers in their seemingly headlong rush to
"me-too" compatibility with larger computers and their
batch operating systems.

THE MINICOl\1:PUTER EXTENSION
SPECIALIST
Until now, the people who have played the largest
role in extending minicomputers have been the system
software designers and implementors and the hardware
engineers. We feel that the systems software designers
will have an increasing role as extension specialists in the
future by becoming knowledgeable in hardware
techniques.

Hardware/software extensibility

Already, the manufacturers of minis are providing
richer instruction sets and more designed-in extensibility in their newer computers. As an example, the
DEC PDP-II provides a rich instruction set, a novel
I/O structure, and virtually a complete elimination of
the addressing problem which once plagued most minis.
The Interdata System.s 70 and 80 provide substantial
encouragement for the user to employ microprogramming to extend the base machine, i.e., to produce
firmware. Almost all new minis provide modular
packaging, in which a hardware function, to add a new
primitive, can be easily wired on a single module and
plugged into the machine.
We see the continued growth of microprogrammed
processors, built around Read-Only Memories (ROM's),
as being in the vanguard of user-extensible machines.
The newest hardware facilities include Programmable
ROM's (PROM's) which can be written by the user on
his site; Erasable PROM's-·which can be manually

The Future of l\1:inicomputer Programming

erased after being written; and Writable RO~VI's (slow
write cycle compared to read, intended to be written
relatively infrequently), sometimes called "Read-:\Iostly
Memories" (or Rl\1:l\l's). All of these lead us to see a
trend toward making this form of extensibility available
by design, rather than by accident.
Thus, the extension specialist win be encouraged to
work on all levels of extensibility. He will be able to add
firmware in the form of lower level programming
(microprogramming) or as pre-wired primitives which
he can literally plug in as new functions (as on the
GRI-909 family). Writable ROM's promise additional
extensibility, even providing the systems programmer
with the ability to optimize the instruction set for each
application by loading a writable ROlVI from his system
initialization code. Thus, he might choose an instruction
set built around four-bit decimal numbers to run Cobol
or RPG programs, one featuring binary floating point oli
multiple-precision numbers for Fortran or Algol, one
with extensive byte manipulation for Snobol, and one
with primitive expression evaluation for PL/I.
Systems programmers will become more competent
at lower-level extension work, either by the firmware
being brought closer to the user in the form of writable
ROM's, or by the software designer being cross-trained
in hardware techniques. For many minicomputer
systems programmers, an oscilloscope is a familiar tool
in debugging complicated programs and systems. Every
sign indicates a growing encouragement for the systems
programmer to create his own desired environment
through extensibility. The DEC PDP-16 carries this to
its logical extreme by letting the user build his own
computer from a pre-determined set of modules using
software tools to aid the design and implementation
process.
Thus, we predict that the systems designer of the
future will increasingly be at home in both cultureshardware and software.
Programming automation systems

We also see a substantial growth and extension to
what we call "programming automation systems"techniques that provide the programmer with computer
aids in the programming process. 9 All programming
systems are designed to help the programmer through
the critical loop of program development, i.e., program
modification, language processing, debugging, and back
to modification. Thus, systems such as Basic and
JOSS ® provide for complete control over the critical
loop within the context of a single system with a single
language used to control all three functions. On

107

minicomputers, symbolic editors, language processors
and debugging aids are provided to "automate" these
three steps. For the systems programmer working on
logically complex and large programs, however, the
minicomputer does not really provide an optimum
environment. Unless it provides bulk storage and a line
printer, it is not well suited to editing and assembly.
Unless it has a console much better designed than most
mini consoles, it is also not particularly well suited to
debugging (and the newest consoles are even less useful
f or debugging). Thus, there seems to be a trend toward
the use of larger computers, particularly time-shared
systems, for supporting programming automation
systems designed to support smaller machines. A largemachine-based editor and assembler can do a lot to
facilitate the creation of programs, particularly since
the assembler does not have to be restricted in either the
features or the number of symbols which can be
accommodated. A good simulator, designed for debugging, can significantly improve the productivity of a
programmer by providing him with the necessary tools
to debug a program without the limitations of the
smaller machine. The authors have invested quite some
time over the last few years investigating this approach;10 several other organizations have also done so,
with some success. Several new computers, notably the
GRI-909 and the IB:\1 System 7, accentuate this trend;
they are only supported by larger host computers; the
actual machines are configured only to run programs,
not to create them.
For years, systems programmers for small machines
have felt, like Pooh Bear, that there must be a better
way than assembly language to write programs for
small machines. The so-called "implementation languages" have been in use for some time on larger
computers; languages such as AED,l1 BLISS,12 PL/I and
ESPOL13 have been used to create systems software,
including compilers and operating systems, for large
computers. We regard it as unlikely that implementation
languages will soon be operational on minicomputers,
due to their high initial cost and inefficiency of generated
code. (Only if substantial computer time is invested in
optimizing time and space will minis be able to support
such implementation languages.) We do feel that the
trend toward using larger computers to support minis
will continue, and that it will soon be possible for
systems programmers to use large-computer-based
implementation language processors and debugging
systems as accepted tools of the trade. Already a
compiler for the BLISS language, an implementation
language developed at Carnegie-:\lellon originally for
the DEC system-IO, has been produced to generate code
for the PDP-II on the DEC system-IO.

108

Spring Joint Computer Conference, 1972

THE MINI AS A BASE FOR DEDICATED
SYSTEMS
Over the past five years (which represents virtually
the entire history of the minicomputer in terms of
number installed), there has been a noticeable shift in
the hardware/software tradeoffs in pricing and using
minicomputers in dedicated system applications. Several
people have long maintained that the price of the
software for a dedicated system should, as a rule of
thumb, equal the price of the hardware. Although
apparently true four years ago, this cannot possibly be
true today. Hardware costs of minicomputer mainframes and memories have been decreasing exponentially at an apparent rate of about 25 percent a year,
while software costs have been slowly rising, at the rate
of inflation. Thus, if the hardware/software cost ratio
was around 1/1 four years ago, it is more like 1/2.5
today, and the gap is steadily widening.
All of the extensibility promised by recent hardware
developments, including the modular construction of
the new machines and the increasing use of ROM's,
should have an accelerating affect on the applications of
minis to dedicated systems, steadily reducing the cost
of the hardware required for a given task.
We see implementation languages beginning to
relieve the trend toward higher software costs and hope
they will continue to do so in the future. But we see
problems in the high cost of training existing programmers to use implementation languages, the lack of
acceptance by lower-level programmers, and general
questions arising as to whether such languages and
compilers really appropriately solve more difficult
problems (such as those that are space and/or time
critical) .
We predict that in the next few years the current
problems regarding implementation languages will be
vigorously attacked on several fronts, and we feel
reasonably certain that they will be increasingly used in
dedicated systems, particularly those which are neither
space nor time critical. For critical systems, we feel that
some time will be required before compilers for implementation languages, and indeed the languages themselves, are improved and tested to the point that they
can be of real value.
Several people, including one of the authors, have
used interpretive languages to simplify the construction
of dedicated systems. In this technique, an existing
interpreter, for a language such as ESp4 or FOCAL,15 is
modified so as to minimize the core requirements for the
interpreter by removing unwanted features and adding
additional ones. The resulting extended machine is thus
an ESI machine, or a FOCAL machine; the user

program in the higher level language is stored in
memory and executed completely interpretively. John
C. Alderman, in a paper presently in manuscript form,
has referred to such languages as "plastic languages", in
the sense that the systems programmer, in designing the
dedicated system, can modify the interpreter for the
language, and thereby change the virtual machine, in
much the same way as writable ROM's can be used.
Indeed, the two approaches can easily be combined; one
could wire the interpreter in an ROM and plug it into
the computer, thus creating an unalterable virtual
machine for FOCAL or ESI.
It should be noted that the use of the "plastic
language" technique is limited to those systems which
are not time critical, since the interpretive nature of
program execution makes the resulting virtual machine
relatively slow. One of the authors has been quite
successful in applying this technique to a proprietary
dedicated system, where its advantages are quite
significant particularly regarding ease of modification
of the higher-level application code.
SUMMARY AND SOME SPECULATIONS
In closing, we would like to summarize a few points
made earlier, and to exercise our license to speculate a
little on the near future of minicomputers.
First, the user of minicomputers for the solution
of general-purpose applications in data processing,
scientific programming, or engineering, will find minicomputers increasingly indistinguishable from larger
computers. With luck, he will not find that interactive
control, which now distinguishes most minis from larger
systems, has been thrown out in the wash.
Second, the cost/performance ratio of minicomputer
hardware will continue to improve at the same rate as it
has over the last five years.
Third, the minicomputer user will continue to
receive the benefits of cost/performance ratios through
decreases in cost for the same, or slightly improved,
performance while the large computer user will generally
continue to receive more performance at the same cost.
Fourth, and as a consequence of the above, all
applications of minicomputers will become increasingly
more economical. Thus, many applications which are
not performed on minis today, or many which are not
done on computers at all, will utilize minis in the near
future as prices continue to drop.
It might be argued that time sharing could just as
easily be used in the future to solve problems which do
not use computers at all now. It is undoubtedly the case
that time sharing will continue to be used for those

The Future of Minicomputer Programming

problems which require its unique assets, i.e., essentially
as much processor time, as much I/O, as much core and
disk space as required, when you need it, purchased on
an "as you use it" basis. But even at the most favorable
rates available today, time sharing is much more
expensive than using a mini. The lowest price we know
of for time sharing is about $8 an hour for as much time
as you can use, though this is on a relatively small
system with quite heavy loading and a lot of contention.
On the other hand, even at today's prices, a mini can
be bought for $5000. If this is written off over three
years, and used 40 hours a week, an effective price of
only about one dollar an hour can be approximated.
A few years from now, this should drop to around 25
cents an hour.
We see the possibility of people providing a variety of
"plug-in packages" for popular minis, quite likely
software provided in the disguise of ROM hardware to
provide the supplier with proprietary protection,
product standardization, and integrity against unauthorized user changes. Some of these standard plug-in
packages might be:
(a) The CO GO virtual machine for the civil
engineer.
(b) The JOSS@ virtual machine for the engineer and
statistician, replacing today's electronic desk
calculators.
(c) The small business virtual machine, providing
the retailer with a small machine capable of
performing routine bookkeeping.
(d) The homemaker virtual machine, providing the
busy housewife with a menu planner, household
controller, alarm system, and checkbook
balancer.
In conclusion, if the designers and product planners
of minis think more clearly on what minis can do in
both program creation and program execution, we may
see an end to the minicomputer syndrome.

109

"He nodded and went out ... and in a moment I
heard Winnie-the-Pooh-bump, bump, bumpgoing up the stairs behind him."

Ending of Winnie-the-Pooh, A. A. Milne
REFERENCES
1 A W HOLT W J TURANSKI
Extended machine-Another approach to interpretive storage
allocation
Under Army contract DA-36-039-sc-75047 Moore School of
EE U of Pa 1960
2 C J SIPPLE
Computer handbook and dictionary
Bobbs-Merrill Indianapolis 1966
3 R W WATSON
Timesharing system design concepts
McGraw-Hill New York 1970
4 PDP-7 CORAL manual
Applied Data Research Inc Princeton N J 1967
5 Broadcast programmer user's manual
Applied Data Research Inc Princeton N J 1968
6 I nterdata microprogramming manual
Interdata Ocean Park N J
7 A KOTOK
DEC debugging tape
Memo MIT-l rev MIT December 1961
8 D J WAKS
Interactive computer languages
Instruments and Control Systems November 1970
9 D J WAKS
The MIMIC programming automation system
Applied Data Research Inc Internal memorandum July
1971
10 MIMIC user's guide
Applied Data Research Inc Ref #01-70411M May 1971
11 AED manual
Softech Cambridge Massachusetts
12 BLISS-tO manual
Carnegie-Mellon Univ Pittsburgh Pa
13 ESPOL manual
Burroughs Corp Detroit Mich
14 D J WAKS
Conversational computing on a small machine
Datamation April 1967
15 FOCAL user's manual for PDP-8
Digital Equipment Corp

The current state of minicomputer software
by JOSEPH F. OSSANNA
Bell Telephone Laboratories, Inc.
Murray Hill, New Jersey

the most common in currently available machines. The
range of memory sizes available in a typical current
machine is from 4K words (K = 1024) to 32K words.
Basic instruction sets typically lack multiply and
divide, decimal and floating-point arithmetic, arbitrary shifting, and fancy character string manipulation. Although minicomputer memories are smaller
than those of large machines, the memory cycle times
frequently are similar, with the result that computing
speeds are similar in applications where a smaller word
size and the absence of some types of arithmetic are
not a factor. Basic input/output structures usually
employ a single time-shared bus with limited device addressing and with limited parallelism during data transfer. Features such as memory protection, relocation,
and segmentation are usually nonstandard or unavailable. Often few fast registers are included. The selection of peripherals standardly interfaced to a given
machine typically has been limited. In the past, the
only reliable peripherals available have been expensive
ones originally designed for the larger computer systems.
To some extent, what has just been said above is
becoming less true with time. The spectacular advances in integrated circuit technology in recent years
have resulted in dramatic price declines. Core memory
and peripherals have also become less expensive. The
price of a basic system consisting of the central processor (cpu), 4KX16 bits of core memory, and a Model
33ASR teletypewriter has dropped from about $25,000
in 1966 to about $8,000 in 1971. 1 The circuit technologyadvances have also made increased system
capability economically attractive. The following
amendments to the list of minicomputer characteristics
are presently apropos.

INTRODUCTION
Noone who has watched the spectacular growth of
the minicomputer industry needs to be told that people
are finding new small computer applications at an
astonishing rate. Undoubtedly there are many reasons
for this striking increase in minicomputer utilization.
Certainly one reason is the increasing sophistication
of minicomputer software. This paper will summarize
the development of this sophistication, and will try
to characterize its present state. Minicomputer hardware evolution will be discussed because of its effect
on minicomputer software evolution. The range of
minicomputer uses and users will be characterized
along with their varying software organizations. Commentary on techniques of minicomputer software
development is included. A number of examples of
both past and present minicomputer software systems
are presented.
MINICOMPUTER HARDWARE
A minicomputer is a "minicomputer" by nature of
its hardware which is relatively simple, physically
small, and comparatively inexpensive. This is accounted for by the following general characteristics
compared to the "ordinary" large computer.
•
•
•
•
•
•

Shorter word length
Smaller memories
Fewer and simpler instructions
$impler input/output capabilities
Minimal features
Fewer peripherals

• Instruction sets improving; fast multiply, divide,
and floating-point optionally available. More and
better addressing modes being designed.
• Memory protection, relocation, and segmentation
becoming optionally available.

In addition to the above, limited software support by
the manufacturer and lower marketing costs have
contributed to the lower price of the minicomputer.
Wordlengths range from 8 to 24 bits with 16 bits being
111

112

Spring Joint Computer Conference, 1972

• Larger sets of fast general registers becoming
common.
• New bus concepts are providing better input/
output structures.
• Priority interrupt structures and interrupt vectors
are becoming standard.
• Smaller and well designed peripherals are available
at reasonable cost.
• Less expensive disk storage is becoming available
in sizes commensurate with small machines.
Manufacturers have achieved this and are providing
increased software support without noticeably stemming the price decline.
These recent improvements in small machine architecture have attracted more sophisticated applications and more sophisticated systems designers. The
advent of inexpensive disk storage is probably the most
important occurrence influencing minicomputer software evolution.
A tabular summary of currently available minicomputers and their characteristics can be found in
Reference 2. Similar information along with projections
of the future of the minicomputer industry are given
in Reference 1.

In a survey conducted within Bell Laboratories in
the Spring of 1971 of approximately 200 minicomputer
systems the following usage breakdown was reported.
31 % Computerized testing of equipment and
devices.
19% Data acquisition and reduction.
18% General-purpose computing, some with data
acquisition.
15% Peripheral control (plotters, cameras, displays, unit-record equipment).
9% Intelligent graphic terminals and interactive
graphic systems; general-purpose graphicoriented computing.
7% Process control.

It is possible to observe different software organizations across these various types of users. Some of the
differences are clearly due to the nature of the applications. Many are due to the nature of available software
support, to the software experience of the programmers
involved, and to hardware limitations. In the next
section these differences are characterized.
SOFTWARE ASPECTS

MINICOMPUTER USES AND USERS
Most minicomputer systems consist of a generalpurpose small machine configured in a way suitable for
some particular application. Tailoring the size and
complexity of a system to the requirements of a particular job can result in an economy of specialization
that outweighs the economy of scale of using a part
of a larger machine. 3 ,4 Accordingly, one would expect
the range of applications to break down in a way that
reflects this economic bias. Auerbach1 reports that in
1970 minicomputer dollar sales were divided as follows.
45% Industrial and process control.
3% Peripheral control (COM, OCR, line printers,
etc.).
20% Communications control (concentrators,
switching) .
10% Computations.
22% Data acquisition and reduction.
Process control and data acquisition often involve
intimate connection to distributed sensors or laboratory
instruments. This is often infeasible for centrally
located large machines, especially when coupled with
the necessity for rapid control by the user and his program.

The choice of a software organization for a minicomputer system can profoundly affect hardware requirements, general efficiency, the range of applications, extensibility, and the ease of software maintenance and modification. The best organization in a
particular case depends on which considerations are
paramount. Other considerations include the following.
• Are the application programs to be run under an
operating system?
• Is there to be on-line secondary storage?
• Are there crucial real-time response requirements?
• Are there to be multiple simultaneous users?
• Is the system to be self-supporting-i.e., can the
application programs be developed and maintained
on the system?
• Is there a justification or need for core protection,
relocation, or some sort of virtual memory?
An "operating system" is a collection of basic and frequently used utility programs essential for convenient
and efficient use of a machine. For many people this
loose definition means the sum of all the programs they
use that were written by someone else and consequently
not easily modified. lVlost minicomputer operating
systems are simple and basic compared to those used

Current State of Minicomputer Software

on large machines. The most basic form of operating
system consists of programs to perform physical input/output and handle code and/or format conversion
of the transmitted data, and a program to bring the
user's program into core and give control to it. If the
minimization of core usage is paramount, the generality
of even a basic operating system may need to be foregone and only the absolutely necessary input/output
programming be included directly in the user's program.
Such inclusion of operating system functions in application programs is not uncommon on small machines.
If the same machine is to be used to develop the
user's programs, other support programs are needed.
An editor is needed to create and modify the user's
source text (unless he is doing it manually, for example
using cards). An assembler or compiler is needed to
translate this source text into executable machine code.
Optionally a debugger is useful for analyzing program
troubles. Operationally, the first two are run like user
programs, and the latter is usually combined with the
user program if needed.
If there is justification for on-line random-access
secondary storage such as a disk or drum, a different
perspective is possible. The less frequently used portions of any operating system and of the user's program
need not be permanently core resident, and core requirements can be minimized without foregoing the
convenience and generality of an operating system.
Further, support programs like those mentioned above
can be stored on disk for handy use (by disk will
usually be meant any such secondary device). Additional support in the form of libraries of user and utility
programs can be easily kept along with a binder program that can search libraries and combine collections
of program modules into executable units. Greater
convenience is obtained when the operating system
provides organized access to the disk by means of some
sort of a file system. A well designed file system is
usually the foundation of the better general-purpose
operating systems.
Real-time response requirements can have strong
implications for software system design. By real-time
we do not here mean the requirements of controlling
conventional peripherals such as disks, tapes, unitrecord equipment, or most communication lines. In
these cases a too-slow response usually causes retries
and degrades efficiency but is not ordinarily fatal.
What is meant are the response requirements of controlling such things as a steel rolling mill, a linear accelerator, or an oil refinery. Industrial process control
systems typically receive a variety of external stimuli
requiring a wide range of response times. This necessitates a hierarchical priority structure for the inter-

113

ruption and execution of programs. When there is
more than a few such programs the scheduling can become quite complex. Operating systems for such situations are usually different than general-purpose ones;
process control systems are discussed later. Data acquisition systems and communications control systems
can have real-time response probJems, if peaks can
occur that would temporarily tax their processing
capacity and it is important that no data be lost.
Unlike a process control system which supervises
known external processes with generally known chari
acteristics, a multi-user system such as a general-purpose time-sharing system faces user submitted tasks
of more-or-less unknown characteristics. For example,
resources such as processor time, core space, and file
system space demanded by the user processes vary
dynamically, and the system generally must schedule
adaptively and enforce various limits on resource
utilization. Even if a minicomputer system is economically justified when wholly committed to some
application, a multi-user capability can permit software development to take place while the main application is running. An example of a multi-user system
is given later.
Core protection is a hardware feature that enables
the operating system to make sensitive regions of core
storage inaccessible, thereby protecting those regions
from damage by being written or preventing information from being read. This feature is uncommon in
minicomputer systems that operate with debugged
programs, but is usually mandatory in multi-user
systems that permit users to write and execute arbitrary programs. Relocation is a hardware feature that
permits a program to be loaded at any convenient
place in core memory, and to be moved (while interrupted) to another place. This feature can be a great
asset to, for example, a process control system trying
to juggle a myriad of different sized programs between
disk and core. Virtual memory5 is a concept where a
program can think it has more core than it really has
or even than there is.
RETROSPECTION
When one looks at the minicomputer systems being
used in the early 1960s one sees minimal hardware with
typically no disk storage and minimal software support in the form of operating systems, compilers,
editors, etc. The temptation was therefore great to
make use of the nearest computer center with its big
machine, big disk, and varied software support.
One of the first minicomputer applications that the

114

Spring Joint Computer Conference, 1972

author came in contact with at Bell Laboratories circa
1964 was an experimental remote graphical display
system called GRAPHIC-1. 6 The hardware consisted
of a Digital Equipment Corporation (DEC) PDP5
computer with 4K X 12 bits of core, a modified DEC
Type 340 display scope, a 4KX36 bit display memory,
a light pen, Model 33ASR teletypewriter, and a card
reader. In addition there was a high-speed connection
to the direct data channel of a nearby IBM 7094.
Support software consisted of an assembler and postprocessor to assemble, merge, and link relocatable
programs to form executable units for the PDP5, a
display material assembler, and a library of input/
output and inter-computer communication programs.
These support programs ran on the 7094 and produced
cards that were read into the PDP5. End users of the
system could write in a higher-level graphical language
called GRIN6 which also ran on the 7094, and could
use the system to submit a regular batch job to the
7094. This dependence on the local big machine was a
natural yielding to the temptation to do software development in a convenient environment.
GRAPHIC-27, a successor system to the one above,
emerged in 1967 and is notable for its relatively sophisticated software. It is implemented on a DEC
PDP9 computer with 8K X 18 bits of core, a fast fixedhead disk, display, light pen, fast paper tape reader/
punch, and a dial-up 2000 bit/sec link to the local big
machine. As in the preceding case all the software for
the PDP9 was written using support programs on the
local computing center large machine, a Honeywell
Information Systems 635. The end user is provided
with a graphical programming language called GRIN-27
and an assembler, both of which run on the 635. In the
next version of the system these will run on the PDP9
itself. GRIN-2 provides the ability to control the manmachine interaction, to create and edit graphical data
structures, and to control the display. The system may
be used in a stand-alone mode or it may be connected
to the 635 and used in a mode where programs executing
in the 635 send over programs or data on demand to
the PDP9. One of the more interesting aspects of the
software in this system is that it provides a form of
virtual memory to the user program. To do this, each
user's program and data is broken up into blocks which
are assigned unique identification numbers (IDs). All
references between blocks are in terms of this ID and
an offset within the block. When a block is referenced
it is retrieved from disk or possibly from the big machine. Only the currently needed blocks are actually in
core at a given time. The user is relatively free from
worrying about the size of core; one user application
program consists of nearly 60K PDP9 words.

Another example is a small laboratory computer
system used for the acquisition and reduction of data
from a spectrometer. It originally consisted of a DEC
PDP8 with 4K X 12 bits of core, a Model 33ASR teletypewriter, a DEC Model 34D display, a home-made
analog-to-digital converter, an extended arithmetic
element, and interfaces to laboratory equipment. The
user wrote his own application software in a few months
using a DEC supplied editor and assembler on the
PDP8 itself. Both user and support programs were
stored on paper tape and had be be loaded using the
reader on the 33ASR. How long does it take to read
4K X 12 bits at the rate of 10 8-bit characters per second? This user eventually got 128K X 12 bit drum primarily to facilitate the acquisition of more data than
would fit into core. He now uses a DEC supplied diskbased operating system for program development and
to run his application. This system is typical of quite
a few minicomputer systems within Bell Laboratories.
A more recent (1968) example of a laboratory computer system designed for self-service by a variety of
users at Bell Laboratories is described in Reference 8.
The hardware consists of a Honeywell DDP224 with
floating-point instructions, 32K X24 bits of core, two
disk drives for 2.4 million word removable disk packs,
magnetic tape, a card reader, analog-to-digital and
digital-to-analog converters primarily for speech and
music, a console typewriter, various graphical input
and output devices, and miscellaneous devices such as
a piano keyboard. Extensive software support is provided for the user in the form of a simple disk operating
system with utilities for all the various devices, an
assembler, a Fortran compiler, an editor, a loader, and
a large library of useful programs. A simple file system
is provided along with disk utilities for physical disk
accessing. Disk conflicts are avoided by informal agreements and by many users having their own disk packs.
The operating system will bring whatever program the
user wants into core from disk but the user must manually transfer control to its starting location. This
machine has been very successfully used by more than
a dozen users for various research projects. A main
drawback is the necessity for users to sign up for time
on the machine, and a limited multi-user capability
would undoubtedly be welcome. The system is much
like a user-operated batch processing system. Even
though some of the applications involve real-time
response and are demanding of the processor, such
tasks as file editing and compiling could go on at a
lower priority or be done concurrently with less demanding tasks. Such an ability would require a better
file system for user isolation and some scheme for rotating user programs through or sharing core. In this

Current State of Minicomputer Software

system, such additions would be tantamount to a
complete redesign.
INTROSPECTION
Just as in the case of software design evolution on
big machines, the evolution of software on small
machines has not been homogeneous throughout the
field. The inertia inherent in the use of successful software can last for times comparable to the current age
of the minicomputer era. Most of the systems described
earlier are still working. There probably isn't any
early software design or development techniques that
isn't still being practiced today. The major impetus
for software design improvement comes from the introduction of more advanced machines and from the
infusion of fresh software techniciar s. Attracted by
the newer small machines and often experienced on
big ones, these fresh workers are beginning to achieve
on the minicomputer a decree of software design
sophistication previously seen only on larger machines.
In the next section an attempt will be made to characterize minicomputer software currently in common
use and to describe some forefront efforts.
CURRENT EXAMPLES

115

The number of task-oriented programs is usually
sufficiently large that economy dictates that they not
all be core resident; thus programs need to be brought
into core when needed. The existence of the shorter
real-time requirements as well as the desire for reasonable efficiency dictates that several programs reside
simultaneously in core. Thus a process control system
takes on the appearance of a multi-programmed timesharing system. In contrast with time-sharing systems,
the scheduling of the execution and interruption of
programs is more complex in process control systems. lO
The relative priority of programs is typically dependent
on process conditions, operator intervention, and even
such things as the time of day. While the general technique is to respond to hardware interrupts and place
programs into execution priority queues, provision
must usually be made for certain high priority programs to purge certain other low priority programs
from queues and for low priority programs to inhibit
their interruption at certain critical times. Some sort
of organized provision is required for the interlocking
of shared data bases. Although most of the programming is done in assembly language and in Fortran, a
number of process control oriented languages have
been developed and used. l l The process control field
has in some ways reached a greater level of sophistication than other fields of application.

Industrial process control
Communications control
All indications are that this field will be one of the
largest users of minicomputers.l Work in this field, not
all involving minicomputers, is relatively extensively
documented. 9,lO As indicated previously, process control
applications 'often involve a wide range of real-time
response requirements. Control algorithms involve the
operation of complex multi-loop negative feedback
systems. Most systems involve two forms of control:
direct digital control in which the computer directly
controls process variables; and supervisory control
in which the computer sets the operating points of
otherwise independent analog controllers. The response
required in direct digital control ranges from milliseconds to seconds, while that required for supervisory
control ranges from seconds to minutes. In addition,
there is usually an overall optimizing and adaptive
control function that slowly modifies the control
algorithms. On top of this response time hierarchy can
be management information and long-term scheduling
functions involving delays measured in days or weeks.
Direct digital control tasks are usually many in number
but relatively simple while supervisory control tasks
are fewer in number but relatively complex.

This field includes communication line concentrators
and controllers used as communication front-ends for
large computer systems, as nodes in communication
networks, and as message switching centers. The latter
application requires secondary storage while the others
do not. Data line concentration and control can usually
be done less expensively and more flexibly with a minicomputer than with wired hardware controllers.
An example of a minicomputer front-end is the line
concentrator used to interface varied terminal equipment to the Michigan Time-Sharing System. l2 This
system was experimental and its hardware complement
is not necessarily optimized. It consists of a DEC
PDP8 with 12KX12 bit of core memory, a Model
33ASR teletypewriter, a high-speed paper tape reader/
punch (to facilitate software development), an extended arithmetic element, an interface to the local
IBM 360/67's multiplexor channel, and interfaces to
standard telephone data sets operating at all the
standard speeds. The lower speed interfaces are bit
buffered and the faster ones are character buffered.
The system performs a limited form of terminal type

116

Spring Joint Computer Conference, 1972

identification of low speed asynchronous typewriter
terminals and handles a variety of IBM and teletypewriter terminals. Because the speed of operation of
each line is program controlled, statistical sharing of
the access lines reduces the required number of telephone ports. The system-terminal interface is better
human engineered than that obtained using standard
IBJ\;I hardware line controllers. Full duplex operation
of teletypewriters is standard and read-ahead of the
terminal keyboard is provided. 13
While such a system is less complex than many process control systems, the bit and/or character completion interrupt rate is high and the responding programs
can't dawdle. The low number of distinct tasks combined with the high task rate dictates that the software
all be core resident. The system described above was
equipped to serve 16 low speed asynchronous lines and
4 voice grade synchronous lines; however, a system
of this kind more typically can serve between 32 and
64 low speed lines along with several voice grade lines.

Paper tape operating systems
The above heading may overdignify the collection
of software that it refers to, but this kind of software
support is one the oldest and is still common. If one
has a typical basic minicomputer configuration consisting of a processor, 4K words of core, and a teletypewriter with paper tape handling, one either does
his software development using support programs
stored on paper tape or uses some other machine for
development and reserves the basic machine to run
the application. The main drawback with paper tape
based support is the slow rate of reading and punching
paper tape. This drawback can be largely mitigated
by adding a high speed reader/punch. Surprisingly
enough, the convenience of working on your own
machine and the fact that a cycle of editing, assembling,
and reloading may be shorter than the time required
to travel to and wait on the local computer center, may
make the use of a paper tape operating system feasible.
Of course, access to a good time-sharing system with
the right kind of program support or to another machine like yours but better equipped is probably preferable.
An example of a current paper tape system in DEC's
paper tape software for the PDP11. 14 It provides an
absolute loader for reading in all programs, a reasonable
text editor, an assembler, floating-point simulation, a
math package, a collection of input/output utilities,
and an octal debugger. The editor is used to create
and edit programs at the teletypewriter; during editing,

the old copy of the source is read off paper tape a block
at a time, edited, and then punched. Assembling a
program consists of reading in the assembler, feeding
the source program to the assembler twice, and receiving an executable object copy of your program from
the punch. Your program can then be tried by loading
it; after loading the loader will transfer control to it
automatically. If it works, fine; if not the octal debugger
can be loaded into vacant core (if any) and used to poke
around in the remnants. All of this is or is not as awkward as it seems depending on the alternatives open
to you. With enough core a simple core resident operating system containing all the support programs with
some core left for the user would be even more convenient; the additional cost is comparable to the cost
of the smaller disks.

Disk operating systems
It has been observed several times previously that
the addition of disk storage to a minicomputer system
makes a world of difference. Even the simplest diskbased operating system greatly magnifies the convenience of working on your own machine, which becomes like using a one-user time-sharing system. ::Vlultiuser systems are possible and desirable and are discussed later. Much of what is possible with disk is
possible in a slower more restricted way using randomly accessible magnetic tapes such as DEC's
DECtape,15 or even small tape cartridges.
An example of a recently available (circa 1968) disk
operating system for a machine that has been around
in some form for awhile is the PS/8 operating system
for the PDP8 family of machines. 16 It requires 8K words
of core and a disk or DECtape.
Another example is DEC's disk operating system for
the PDP11.I7 It requires at least 8K words of core, a
small disk augmented by DECtape, or a larger disk,
a high speed paper tape reader/punch, and a console
typewriter. The support software includes a command
interpreter, a reasonable text editor, an assembler, a
Fortran compiler, an octal debugger, a file utility
package, floating-point simulation, a math package,
and a linker to combine programs. The operating system
provides a reasonable file system and does input/output
for the user. Core is divided into five regions: a small
region at the bottom containing the interrupt vectors
which indicate the location of interrupt handling programs; next a small area for the resident monitor; an
area for the user program at the top of core; below that
the stack (where parameters are stored temporarily
during the transfer of control between programs); and

Current State of Minicomputer Software

a free area divided into blocks and used for buffers,
temporary tables, and device drivers brought into core.
To invoke a system support program such as the
editor or a user program written to run under the
system, the user types a request on the console keyboard which can include information about which
input and output devices are to be used during the run.
User programs can be used interactively and can be
interrupted for debugging.

Multi-user time-sharing systems

It is an accepted fact nowadays that the time-shared
use of a computer is one of the more effective ways of
increasing the productivity of a group of users in need
of computing service. The advantages of "working on
your own machine" are effectively extended to the
whole group at once. A multi-user system is inherently
more complex than a single user one; it is necessary
to multiprogram and/or swap user programs between
disk and core and to keep track of everyone's input/
output and machine conditions. It is helpful too, if
users can be prevented from injuring each other and
the system.
We shall present here, as an example of a multiuser
system, a system recently developed (primarily by
. K. L. Thompson) at Bell Laboratories which is felt
to be at the forefront of minicomputer software design.
This system utilizes a DEC PDPll/20 computer with
12KX16 bits of core storage, a 60 cycle clock, a 256K
work fixed-head disk, a disk drive for 1.2 million word
disk cartridges, a dual DECtape drive, 8 low speed
asynchronous line interfaces for remote typewriters,
and a little-used paper tape reader/punch.
Core is divided into an 8K word/region containing
the totally core resident operating system and a 4K
word region for the user program and his stack. The
system space includes about 2K used for a pool of
dynamically allocated buffers. The operating system
maintains an excellent file system, creates and manages
user processes executing core images), does input/
output for the user, and performs all scheduling functions. Scheduling is by placing ready-to-run users on
one of three queues, depending on whether the user
has interacted (has just typed an action character on
his console), some pending input/output has completed,
or the user has run out of time allotted for execution.
All users are swapped between the fixed-head disk and
the same region of core.
The main feature of this system is a versatile, convenient file system with complete integration between

117

disk files and all input/output devices. There are three
kinds of files; ordinary disk files, directories, and
special files representing physical devices. A directory
is like an ordinary file except that only the system can
modify it. The file system is a tree structured hierarchy
originating at a root directory. Any type of file can
occur at any level. Files have names of eight of fewer
characters. At any given time a user process is associated
with a particular current directory. When the user
program wishes to open or create a file, it gives the
system the file name of a file in the current directory
or it gives a path name which either specifies the absolute location in the tree or the location relative to
the current directory. If the reference is successful, the
system returns a file identification number to be used
for future references. File system protection consists
of associating with the file at time of creation the name
of the creator and permitting him to specify whether
he and others can read and write the file. Files are
formatless and are regarded as strings of 8-bit bytes.
Another feature of the system is the ability to initiate
asynchronously executing processes from within a
program or from command level. Commands are normally terminated with semicolons or new-lines; the
command interpreter creates a process to execute the
command and waits for its completion. If the command
is terminated instead by an ampersand, the same thing
occurs except that the command interpreter doesn't
wait. Argument strings typed with a command are
made available to the program by placing them on
the stack.
The name of any executable program can be used
as a command. The name is first searched for in the
current directory and if that fails it is then searched
for in a system library. A myriad of commands are
available including those for listing directories, moving, copying, and deleting files, changing the owner
and mode of a file, and changing the current directory.
Other programs available include a context text editor,
an assembler, a symbolic debugger, a linking loader, a
dialect of Basic, Fortran, a text formatter, games such
as chess, and various experimental languages.
The system operates 24 hours a day, seven days a
week. A user community of about a dozen people access
the machine regularly although it is not a service offering. The group that owns the machine uses it heavily
for preparing documentation using the editor and text
formatter. The maximum of eight simultaneous users
(limited by the number of lines) does not tax the
machine's capacity. Because of the lack of core protection, any user can write, assemble, and run a program that could damage the system and cause a system
crash. However, since most users use debugged pro-

118

Spring Joint Computer Conference, 1972

grams like the editor or text formatter, and because
those few who develop new programs are careful, surprisingly few crashes occur. A future version of this
operating system will be developed for a version of the
PDP11 having core protection and relocation.

Virtual memory systems

One of the more interesting areas in minicomputer
software is the use of virtual memory to manage the
core and secondary storage of a small machine. A
system in an earlier example, GRAPHIC-2, supported
a form of virtual memory without the use of special
hardware. Another similar example is a small timesharing system on a Honeywell DDP51618• A different
example involves the use of hardware assisted segmentation and paging on a specially modified Interdata
Model 319 •

CONCLUSIONS
There has been a decided evolution toward greater
sophistication in the design and use of minicomputer
software during the relatively short years of the minicomputer era, although many of the earlier methods
are still in use. A major force toward software improvement has been the introduction of new and better
machines and the advent to relatively inexpensive
disk storage. The expanding minicomputer field has
benefited from the attraction of fresh software design
talent often with large machine experience. Some
recent forefront efforts are yielding minicomputer
operating systems with features previously found only
on large machine systems.

REFERENCES
1 Minicomputers

Auerbach Technology Evaluation Series EDP Series No 4
Auerbach Info Inc Philadelphia Pa 1971
2 D J THEIS L C HOBBS
The minicomputers revisited
Datamation Vol 17 No 10 pp 25-34 May 15 1971
3 M V MATHEWS
Choosing a scientific computer for service
Science Vol 161 p 2368 July 5 1968

I

4 J R COX JR
Economies of scale and specialization in large computing
systems
Computer Design November 1968
5 P J DENNING
Virtual memory
Computing Surveys Vol 2 No 3 pp 153-189 September 1970
6 W H NINKE
Graphic-l-A remote graphical display system
AFIPS Conference Proceedings Vol 27 Part 1 1965 FJCC
Spartan Books Washington D C pp 839-846
7 C CHRISTENSEN E N PINSON
Multi-function graphics for a large computer system
AFIPS Conference Proceedings Vol 31 1967 FJCC
Thompson Books Washington D C pp 697-711
8 P B DENES M V MATHEWS
Laboratory computers: Their capabilities and how to make
them work for you
Proceedings of the IEEE Vol 58 No 4 pp 520-530 April 1970
9 Special issue on computers in industrial control
Proceedings of the IEEE Vol 58 No 1 January 1970
10 C L SMITH
Digital control of industrial processes
Computing Surveys Vol 2 No 3 pp 211-241 September 1970
11 H E PIKE JR
Process control software
Proceedings of the IEEE Vol 58 No 1 pp 87-97 January 1970
12 D L MILLS
Preprocessors in a data communication environment
Proceeding of ACM Conference on Problems in the
Optimization of Data Communications Systems
Pine Mountain Ga pp 286-310 October 1969
13 J F OSSANNA J H SALTZER
Technical and human engineering problems in connecting
terminals to a time-sharing system
AFIPS Conference Proceedings Vol 37 1970 FJCC
p 355-362
14 PDPll paper tape software programming handbook
DEC-11-GGPA-D Digital Equipment Corporation
Maynard Massachusetts 1970
15 PDPll peripherals and interfacing handbook
Digital Equipment Corporation Maynard Massachusetts
1971
16 PSI8 system user's guide
DEC-P8-MEFA-D Digital Equipment Corporation
Maynard Massachusetts 1970
17 PDPll disk operating system
DEC-II-SERA-D Digital Equipment Corporation
Maynard Massachusetts 1971
18 C CHRISTENSEN A D HAUSE
A multiprogramming, virtual memory system for a small
computer
AFIPS Conference Proceedings Vol 36 1970 SJCC AFIPS
Press Montvale New Jersey pp 683-690
19 B H LISKO V
The design of the venus operating system
Proceedings of the Third ACM Symposium on Operating
Systems Principles Stanford University pp 11-16 October
1971

Real-time fault detection for small computers*
by J. R. ALLEN
Bell Telephone Laboratories
Naperville, Illinois

and

S. S. YAU**
Northwestern University
Evanston, Illinois

INTRODUCTION

excessive storage, noncontiguous memory locations
or excessive execution time.5-7 Much of the previous
work attempts to locate faults as well as detect them.
While fault location is desirable, it is more expensive
and requires much more time and storage than fault
detection. Many applications do not require fault location. It may be more feasible to either interrupt the
task or perform the task manually during the diagnosis
and repair interval; the most important thing is to
recognize that the computer may be performing the
task incorrectly.
An earlier technique attempted to simulate each
instruction using different instructions and comparing
the simulation result with the actual result. 7 This
technique requires that the computer be somewhat
operational and that it be capable of comparing the
two results. A means is needed for determining that
the test routine is executed periodically.
In this paper, we propose a real-time fault detection
scheme for small computers which is effective for faults
in the central processor unit (CPU), core memory and
I/O bus. It requires an external monitor which is
simple, inexpensive, and interfaces to the computer's
I/O bus just as any other peripheral device. The monitor
periodically triggers a program interrupt, causing the
computer to execute a predefine test routine. During
the course of the routine's execution, several key bit
configurations are transmitted to the monitor. If the
computer fails to respond or if the bit configuration
does not match the one that is expected, then the
computer is assumed to be faulty and the device may
either cause a power down or sound an alarm.
The proposed technique compares favorably to the
previously referenced techniques in fault detection.
Certain faults will not be detected, however, because

Advancing technology and declining costs have led to
a sharp increase in the number and variety of small
computers in use. Because small computers are readily
suited for many real-time applications, a great deal
of work has been directed toward simplifying the interface between the computer and its peripherals. Hardware interrupting capability and a specially designed
I/O bus are required for peripheral device interfacing
in a real-time environment and such things as direct
memory access, data channels, and multilevel hardware
and software interrupt capability are common. These
machines tend to be parallel, synchronous computers
with a relatively simple architecture.
In a real-time environment, fault detection can be of
major importance. Much of the past work has been
directed toward the design of additional hardware,
internal to the computer, which allows critical feedback
loops to be controlled and often inserts special registers
for the maintenance task. 1- 4 These techniques require
that the maintenance circuitry be designed concurrently with the computer itself and have access to
components internal to the computer. Many problems
can arise from attempting to modify an existing computer. For example, critical timing and gate fan-out
can be disturbed, and most warranties become void
if unauthorized modifications are made to a computer.
Other techniques cannot be used for real-time fault
detection because they require manual intervention,

* Portions of this Work were supported by U. S. PHS Grant
No.5 POI GM 15418-04.
** Depts. of Electrical Engineering and Computer Sciences,
and Biomedical Engineering Center.
119

120

Spring Joint Computer Conference, 1972

INPUT

OUTPUT

Figure I-Typical computer architecture

internal modification to the computer is not allowed.
In the past, real-time fault detection has carried a price
tag comparable to the cost of the computer itself. A
major advantage of this technique is that its low cost
makes a great deal of fault detection possible in applications which would not previously have been cost
effective. The fact that the technique assumes that no
modification may be made to the computer means that
many existing systems could make use of the method
without extensive modifications.
COMPUTER ARCHITECTURE
The proposed fault detection method may be used
with a variety of small computers, all of which are very
similar in architecture. Included in this class of computers are such machines as Digital Equipment Corporation's PDP-8, PDP-9/15; Hewlett-Packard's HP2100; Honeywell's DDP-516; Data General's Nova1200 and N ova-800; Xerox Data System's Sigma-3;
and Hitachi's HITAC-10. All of these are parallel,
synchronous machines with hardware interrupt and
I/O bus.
Figure 1 shows a block diagram of a typical small
computer. The program counter (PC) contains the
address of the next instruction to be executed. The
memory buffer register CMB) serves as temporary storage
for information being written into and read from
memory. The address of the memory cell to be accessed
is placed in the memory address register (MA). The
decoded contents of the instruction register (IR) controls
the instruction sequencer. Other registers commonly
found are an accumulator (AC), general purpose registers
(GPR), an arithmetic register (AR) and an index register
(IX). Most small machines make use of some subset of
these registers.

Most of the logic functions are performed in the
general purpose logic unit (ADR). A pulse on the hardware interrupt lead will cause the instruction sequencer
to save the appropriate registers and to begin executing
a different program.
ADDITIONAL HARDWARE REQUIREMENTS
This section explains the function of each portion
of the block diagram for the monitor hardware shown
in Figure 2.
The DEVICE SELECT modules (DS1 and DS2)
are basically an array of AND gates which allow the
peripheral device control signals and data signals to
pass only when the proper device select code is present
on the device select bus. This allows several peripheral
devices to share the same I/O bus without interfering
with one another. Three device codes are required,
XX, XX, and YY. It is desirable to have one device
code (XX), which is the complement of the other to
verify that each bit of the device select bus can be set
to both logical states.
Device codes XX and YY cause the WIRED
REGISTER to be gated onto the Input Bus. The
WIRED REGISTER is constructed simply by attaching alternate bits to a voltage representing a logical
one and the remaining bits to logical zero. When
device code YY is selected, the "DEVICE = YY"
lead is enabled causing the contents of the WIRED
REGISTER to be complemented before being placed
on the Input Bus. Reading from both device XX and
device YY causes both a 1 and a 0 to be read from each
bit position. Many computers determine the status of
a peripheral device by executing an instruction which
causes the next instruction to be skipped if a status
FF is set. By executing this instruction with device
code XX the BUSY/IDLE FF will appear to be busy;
if device code YY is used, the "DEVICE = YY" lead
causes the FF to appear to be idle. In this way the
device status testing feature may be checked.
Device code XX is used when outputting bit configurations to the monitor for comparison to the
expected value. The INTERRUPT TIMER is simply
a monostable FF which, after an appropriate delay,
will cause a program interrupt to be sent to the computer and at the same time sets a FF, which enables
the RESPONSE TIMER. The testing frequency is
set by adjusting the monostable's delay time.
The RESPONSE TIMER is used to determine that
the computer is taking too long to respond and may be
"lost." If the RESPONSE TIlVIER is not reset or
disabled before it "times out," an OVERTIME signal

Real-Time Fault Detection for Small Computers

INPUT
BUS

DEVICE
SELECT
(DS1 )

~---t

DEVICE
DEVICE
STATUS

121

WIRED REGISTER
= 525252

= YY

DEVICE
CODE
(XX)
OR
(YY)

WIRED BUSY/IDLE
= BUSY

COMPUTER
PRffi

INTERRUPT

OUTPUT
READY
OUTPUT
BUS

DEVICE
SELECT
(DS2)

PI

DEVICE
CODE
(XX)

ROM
INHIBIT

FAULT

OJERTlrvE
Figure 2-Block diagram for monitor hardware

is generated, indicating that a fault has been detected.
A circuit to perform the RESPONSE TIMER function
is shown in Figure 3.
The ADDRESS COUNTER is simply a cyclic
counter designed to count modulo N, where N is the
number of responses expected during a normal test.
When the counter resets, a DONE signal is generated
which disables the RESPONSE TIMER and resets
the INTERRUPT TIMER. The ADDRESS

OVERTIME

Figure 3-Response timer

COUNTER is incremented after each output from the
computer to sequentially address the contents of the
read-only memory (ROM). The ROM need not be
large and may be built economically from a diode
array.
The respDnse from the computer and the expected
response, read from the ROM, are both buffered and
compared by the MATCH LOGIC. When enabled,
the MATCH LOGIC basically OR's together each bit
of the XOR of the two buffers to produce the MISMATCH signal. An OUTPUT READY signal from
the computer is used to load the BUFFER, enable the
MATCH LOGIC, reset the RESPONSE TIMER, and
incremEnt the ADDRESS COUNTER, all after appropriate delays.
If either a MISMATCH or an OVERTIME signal
is produced, the FAULT FF is set. This inhibits any
further output to the monitor, thus preserving the
contents of the ADDRESS COUNTER and the two
buffers as an aid for the diagnosis of the fault.

122

Spring Joint Computer Conference, 1972

The FAULT signal may be used in whatever way
seems appropriate; it may stop the computer, sound an
alarm, or trigger an interrupt to call some form of selfdiagnosis program, which may attempt to actually
locate the fault.
All circuits may be built using conventional methods
and commercially available logic gates. The total cost
of the hardware components is estimated at approximately $250.
GENERAL GUIDELINES
Small computers seldom have a large amount of
core memory, often as little as 4,000 words. Often,
external storage is limited to paper tape, which requires manual intervention to be read. In order for a
real-time fault detection scheme to be useful in these
circumstances, its memory requirements should be
small enough to allow it to remain resident in a very
small core memory and still leave room for the system
programs.
A large number of faults are severe enough to either
stop execution or at least to make sequential instruction execution impossible. No additional effort need
be made to detect such a fault; the resulting failure
to produce the required sequence of responses will
cause the fault to be detected. However, faults which
affect only a single bit position of a bus or register can
be among the most troublesome. This type of fault
may allow execution to continue, perhaps indefinitely,
without an indication the fault exists.
Certain portions of the computer are very difficult
to check under the assumed restrictions. Input-Output
leads, other than those used by the monitor, cannot
be checked without adding more hardware for each
set of leads. Such Input-Output leads include Direct
Memory Access, Data Channel, Console Controls, and
special device channels. These devices usually appear
as a data bus input which cannot be controlled. It can,
however, be determined that none of these inputs is
stuck at a one level as this would always cause the
output of the bus to be one.
The instruction control circuitry cannot be checked
directly. There are no instructions which access most
of the control leads. Therefore, the correct operation
of a control lead can only be determined by checking
conditions caused by that lead, such as the complementing of a register. A thorough check of the control
circuitry, under the given constraints, would be
lengthy. It can, however, be determined that most of
the gating signals can be produced. This can be done
by executing every instruction type and checking to

see that the proper data transfers have taken place.
This method would intuitively seem to be very effective and can be accomplished in a short period of time.
Because the test routine is periodically required to
change the contents of memory locations outside of its
own boundaries, the interrupt facility must be disabled
during the executio:l of the test. This is necessary to
insure that all locations are restored before control is
released by the test routine. Since it is undesirable to
lock out high-priority tasks for a long period of time,
the execution time of the routine should either be very
short or the routine should be segmented to allow the
servicing of high-priority tasks.
There are a number of ways to cause the external
monitor to recognize that a fault has occurred. One
of the most reliable ways is to design the test in such
a way that the computer will output an unexpected
bit configuration in the event of a fault. This technique
is demonstrated by the following example. The accumulator is first loaded with a bit pattern A and then
caused to skip over an instruction which would place
A on the I/O bus. After the skip, the AC was changed
to a pattern B and output to the monitor. If the skip
did not occur, pattern A would have been output and
would not have matched the expected pattern B.
Another method is to cause the program to "loop"
in the event of an error. The normal sequence of output
bit patterns will then cease and the monitor will recognize the cessation of response as an indication of a
fault. Use of these techniques reduces the read-only
memory requirements for the monitor.
TESTING TECHNIQUES
This section describes several techniques, which
may be used to test the various computer components.

Registers
Registers in parallel synchronous machines commonly resemble the configuration in Figure 4. Although
the actual circuitry may vary, the function is very

A

Figure 4-Flip-flop

Real-Time Fault Detection for Small Computers

simple and well defined. When lead C becomes enabled,
the information on lead A (usually a major bus) is
gated into the FF. When lead C is disabled, the FF
retains the state of lead A. A variation of this type of
register requires a fourth lead which clears the register
prior to the enabling of lead C which then OR's the
state of lead A into the FF. Verification that each bit
of a register can be set to both logical states completes
a functional test of the FF. A single possibility
remains-a stuck at 1 fault on lead C. This fault is very
severe because lead C is common to every bit of the
register. Having lead C stuck at 1 would cause lead A
to be fed directly into the FF and would totally incapacitate the register. In most cases the state of lead
A changes many times between the setting and the
reading of a register, thereby, destroying the original
contents. If this does not happen automatically, an
effort should be made to cause it to happen.
To check a programmable register, such as the accumulator, the register is first loaded with a bit configuration. The contents of the register are then output
through the I/O bus to the external monitor. The
programmable register is then loaded with the complement of the first bit configuration and its contents
again output to the monitor. This procedure also
checks the I/O bus drivers, and the outputs of each
bus between the accumulator and the I/O bus.
Not all of the registers generally used in small
machines are directly accessible under program control.
In these cases a variety of techniques must be used in
order to infer that the register can be set and read
correctly. Five such registers were described in the
introduction.
One of these registers is the arithmetic register (AR).
Because the contents of the general purpose registers
is commonly stored into AR so that AR may be used
as the operand, many tests of the general purpose
registers require the data flow to pass through AR,
testing it at the same time. This commonly happens
in the output instruction itself, meaning that no extra
effort is required to check AR.
The second nonprogrammable register is the memory
buffer (MB). This register is used to contain the data
word core memory read-write operations; it must be
capable of being set and cleared in order to correctly
access core memory. If two complementary words can
be read from memory, then the MB is operative.
The third nonprogrammable register is the instruction register (IR) which contains the OP code. This
register is different from the above registers in that its
contents are never gated to a point at which it could be
displayed. In this case a set of instructions may be
selected in such a way that together they incorporate

123

both logical states for each bit. If it can be verified
that each of these operations can be performed successfully, then it may be assumed that IR is operative.
The fourth nonprogrammable register is the memory
address register (MA). This register is tested in the
following manner: the contents of the sequence of
addresses (0, 1, 2,4, 8, ... ,2 n- \ where n is the number
of bits in MA, is saved in a test routine buffer area in
real core for future restoration. Second, two complementary flags X and X are written into location 0
and read back. The flag X is left in location O. Another
flag (Y) is then written into each of the other n locations. If, after the n write operations, the contents of
location 0 is still X, then the MA register is operative
and the n + 1 locations used for this test should be
restored. To see this, assume that a bit (A) of MA is
stuck at either 1 or O. This is not to say that bit A is
the only inoperative bit, but only one of possibly several. In this case, when an attempt is made to write
into location 0, the flag will actually be written into
another location (B). (If every faulty bit is stuck at 0,
then B =0.) Later when an attempt is made to write
into location 2A , this data will also be written into
location B, overwriting the original flag. In general,
location B will be overwritten once for every inoperative bit in MA. When an attempt is made to read from
location 0, the overwritten contents of location B will
be returned, which will no longer be the flag originally
placed there. It should also be noted that a fault in the
address decoding circuitry or the memory itself cannot .
mask a fault in the MA.
The fifth nonprogrammable register, the program
counter (PC), may be tested in much the same way as
the MA register. The first flag to be written into location 0 is the binary configuration of a "JUMP TO A"
instruction. Into the remaining n locations is written
a "JUMP TO B" instruction. After the MA register
has been checked, a transfer is made to location O.
This causes the PC to be loaded with a binary zero
and the "JUMP TO A" instruction there to be executed. At location A, a signal is made to the monitoring
unit that the transfer was successful and the contents
of location 0 are changed to a "JUMP TO C" instruction. The code at location C will cause the program to
loop, or output an unexpected word which will cause
an error conditipn to arise. The test routine then proceeds to transfer to each of the locations 1,2,3 ... 2n - 1•
Each transfer should cause a return to location B,
which simply continues the sequence. However, as
with the MA register, if any bit of the PC is inoperative,
then the "JUMP TO C" instruction will be executed
and an error condition generated.
All of the above registers are found in most com-

124

Spring Joint Computer Conference, 1972

logical state. This can be done by gating both a 1 and
a 0 onto the bus from every AND gate.

1
2--'L-~

3---1
4--""1-__

10

5-----I-~

6 --""'L___
Figure 5-Bus structure

puters and the methods described are generally applicable.
In the methods for checking MA and PC, it is important to insure that addresses 0, 1, 2, ... 2n - 1 do not
lie in critical parts of the test routine. This is simply a
matter of convenience; if this restriction is undesirable,
a slightly more general algorithm can be used to allow
complete freedom in the location of the test routine.
Since all of the n + 1 locations lie in the first 2n locations, the program could be loaded anywhere in the
second half of the memory.

Databu8
A computer data bus typically consists of some variation of the circuit shown in Figure 5. Although there
are many ways to implement this function, using different types of logic gates, nearly all faults will behave
as though one of the leads numbered 1-10 has become
frozen at one logical state. Certain varieties of logic
allow the OR function to be accomplished simply by
tying the outputs of gates A, B, and C together. This
arrangement also satisfies the above statement. One
input of each AND gate is usually common to all bit
positions and functions as a gating lead for transferring
data onto the bus.
A data bus may often be directly accessible to a
number of peripheral devices for such features as
direct memory access or a data channel. When this
happens, one or more of the AND gates in Figure 5
may have inputs which cannot be controlled without
interfering with certain of the peripheral devices. There
will, therefore, be a few of the AND gates which will
not be checked.
For the remaining AND gates, the objective is to
verify that each input and output can assume either

Control circuitry
Unlike a data bus or a register, the circuitry which
controls the gating and timing for the instruction execution is neither simple in function nor standard in
design.
The approach taken here is to include segments of
code in the test routine which will exercise each instruction and check to see that it is performed correctly. This thoroughly tests the instruction decoder
by providing it with all possible inputs. The control
circuitry is the most difficult part of the computer to
check because there is virtually no means of direct
communication between this circuitry and the I/O
bus. All tests must be made by performing an operation
and verifying that the correct operations have taken
place. It is possible, however, that something totally
unexpected may happen in addition to normal operation of the instruction. To detect a fault such as this
would require an extensive test for every instruction.
There is no method known, at present, which would
produce such a test using only the I/O bus with no
hardware modifications to the computer. If such a
method were available, it is likely that the storage requirement and execution time would limit its usefulness for a real-time environment. Fortunately, faults
which occur in the control circuitry are usually quite
severe and grossly affect the instruction execution.
Therefore, a thorough exercising of each instruction
appears to be the best approach to this problem and
may be relied upon to detect the majority of such
faults.
The length of the test can be reduced by studying
logic diagrams in an attempt to find sections of logic
used by more than one instruction. In some computers,
for example, indirect addressing is handled by the
same microinstruction cycle in every instruction. It
would not be necessary, therefore, to test indirect
addressing with each instruction.
Correct operation of certain instructions may be
assumed if execution of the test routine is not possible
without them. For example, it may be assumed that
the JUMP instruction is operative because the first
instruction executed after a hardware interrupt is a
JUMP to the routine which is to handle the interrupt.
Although the approach used in this case is largely
intuitive, if a little time is spent familiarizing oneself
with the computer's logic and timing, the number of

Real-Time Fault Detection for Small Computers

faults which can escape detection can be greatly reduced.

BIT 1

BIT 2

..

BIT N

,.....

r-

~
>

Logic function and condition logic

I.J.I

Most Boolean operations may be easily tested by
exhaustion of their respective truth tables.
As a general rule, small computers have a ripplecarry adder. Because the circuitry is simpler, this form
of adder is easier to check than one using carry-Iookahead. To check an adder, it is necessary to verify
that each bit position can both generate and sink a
carry. Both of these tests may be made simultaneously
for all bits by adding a word of alternating ones and
zeros to itself (252528 +252528) and then adding that
same word's complement to itself (52525 8 +52525 8).
It is also necessary to verify that each bit position can
propagate a carry. This is accomplished by adding 1 to
77777 8. Adding 77777 8+ 777778 verifies that every bit
position can simultaneously generate and sink a carry.
The remainder of the truth table may be verified by
adding 00000 8+00000 8, 77777 8+00000 8, and 00000 8+
77777 8.
It is desirable to consult the logic drawings in order
to determine how to test the overflow and conditional
transfer logic. Although the implementation of this
logic varies between machines, it is quite straightforward and simple to check.

Core memory
The core memory is, perhaps, the functional element
which will fail most frequently. This may be attributed
to the requirement for high-power circuits operating
under closer tolerances than the conventional logic

MA3

125

MA2

+Figure 6-Core memory bit slice

a:
o
I

x

'--

..

I

....

Y - DRIVERS

Figure 7-Memory addressing structure

gates used in the rest of the computer. Many faults
which occur in a core memory are the type which may
be present for a long time before being discovered, such
as a fault which affects only a rarely used part of memory. The ability to read and write at every address
does not mean that the memory is free from faults; a
faulty address decoder may read or write at two locations simultaneously.
Small computers commonly use a 2-1/2D arrangement for the memory address decoding. 8 This method
relies on a coincidence of current on an X-axis lead and
a Y-axis lead to select a core to be written or read. To
do this the address bits are divided into two fields,
which independently control the X and Y current
drivers. In addition, each of these fields is further divided into two subfields. For example, if there are n
bits in the field which selects the Y lead, then half of
these bits will select one of 2110/2 current sources; the
other half will select one of 2110/2 current sinks. Since
every source is connected to every sink, the independent selection of one source and one sink selects one of
the 2110 Y-axis leads. Different sources and sinks are
used for the read and write operations.
Figure 6 depicts the addressing scheme for a 16-word
memory requiring a 4-bit MA. Only a single bit position of the memory word is shown. Other bits of the
same word are selected by replicating the Y-axis
drivers for each bit position as shown in Figure 7.
During the write cycle, only the Y-axis drivers corresponding to bits which are to be set to 1 will be enabled. Because the read and write operations require
currents in opposite directions, separate drivers are
required for each of these operations. This means that
a fault may affect the read operation and not the wri~e
operation and vice versa.
The test procedure for checking the address decoder
is to select one of the four subfields, having length m,
to be checked first. The contents of each of the 2m
locations obtained by selecting all combinations of
these m bits and holding the remaining bits constant

126

Spring Joint Computer Conference, 1972

are stored in a buffer area. Each of the 2m locations
is then set to zero. Into one of the locations is written
a word of all ones. Each of the remaining locations is
checked to see that its contents is still zero. The originallocation is then checked and cleared. This process
is repeated for each of the 2m locations. Upon completion of .the test, the contents of the locations are restored and the test is repeated for each of the remaining three subfields.
To justify this test, assume that one of the input
leads to a read current source were stuck at O. This
would mean that at least one bit in the set of test words
could not be read as a one and would be detected by
the test. It is also possible that an input to a write
current source could be stuck at O. Because of a core
memory's destructive read-out, the corresponding bit,
or bits, could be read once and then never rewritten
as a 1. Again, at least one bit of the set of test words
would be stuck at 0 and the fault would be detected.
Suppose now that an input to a read current source
were stuck at 1. This means that one of the 2m addresses will select two read current sources at the same
time, dividing the read current. The result will now
depend upon the tolerances of the memory. The divided
currents may not be sufficient to cause a core to switch.
At least one test bit would then appear to be stuck at
o and the fault would be detected. The divided currents may, however, each be sufficient to switch a core.
During its execution, the test will cause a 1 to be
written by using lead A. Later, when an attempt is
made to read a 0 by using lead B, lead A will also be
selected and a 1 will be read. Similarly, an input to a
write current source may be stuck at 1. If the resulting
split in the write current is insufficient to switch a core,
the inability to write into certain test locations will be
detected as before. If each half of the divided current
is sufficient to switch a core, the writing of a 1 into some
location C will also write a 1 into some location D. This
extra 1 will be detected when location D is checked
for a O. Because this test is considerably longer than
the previous tests, it may be desirable to partition the
test. A very natural partition would be to check each
group of current sources separately.
The only way to check individual cores in the memory is to read and write using every location. Although
this must be a lengthy test, some time saving can be
realized if the locations are checked by reading a word
and writing its complement back into the same location. If the complement can be read back, the word is
good. This method makes use of whatever is already
in the memory location and, therefore, saves the time
which would have been required to save the contents
to the location and initialize the location. This test is

normally not included in the test program because of
the time required for its execution.

SUMMARY
This procedure has been applied to a DEC PDP-9
computer with two 8K core memory modules. The test
routine requires 550 words of core memory and a maximum of 8 milliseconds per pass. The time needed to
test the core memory increases with the size of the
memory itself; but, by segmenting the test so that only
a portion of the core is checked during each pass, it is
possible to increase the memory size without increasing
the amount of time required for a pass. All tests of the
CPU itself are made each pass, but 12 passes are required to completely test the memory. The hardware
monitor requires 58 words of read-only memory and
solely determines the frequency at which the tests
are made. This frequency may be adjusted according
to the work load on the computer.
This technique would seem to have many applications on small machines which have previously avoided
fault detection because of the cost or the need to make
hardware changes to the computer.

ACKNOWLEDGMENTS
The authors would like to thank IVlessrs. Gary F.
DePalma, G. Wayne Dietrich and J. S. Tang of Northwestern University for helping in the implementation
of this fault detection scheme on the DEC PDP-9
computer.

REFERENCES
1 E G MANNING
On computer self-diagnosis: Part I-Experimental study of a
processor
IEEE Trans Electronic Computers EC-15 pp 873-881 1966
2 E G MANNING
On computer self-diagnosis: Part II-Generalizations and
design principles
IEEE Trans Electronic Computers EC-15 pp 882-890 1966
3 R W DOWNING J S NOWAK
L S TUOMENOKSA
No 1 ESS maintenance plan
Bell System Technical Journal Vol 43 pp 1961-2019 1964
4 K MALING E L ALLEN JR
A computer organization and programming system for
automated maintenance
IEEE Trans Electronic Computers EC-12 pp 887-895 1963

Real-Time Fault Detection for Small Computers

5 C V RAVI
Fault location in memory systems by program
Proceedings of AFIPS Spring Joint Computer Conference
pp 393-401 1969
6 M S HOROVITZ
- Automatic checkout of small computers
Proceedings of AFIPS Spring Joint Computer Conference
pp 359-365 1969

127

7 T R BASHKOW J FRIETS A KARSON
A programming system for detection and diagnosis of machine
malfunctions
IEEE Trans Electronic Computers EC-12 pp 10-17 1963
8 P A HARDING M W ROLUND
Bit access problems in 2Y2D 2-wire memories
Proceedings of AFIPS Fall Joint Computer Conference
pp 353-362 1967

An organization for
successful project management
by DON SMITH, JR.
Computer Sciences Corporation

EI Segundo, California

INTRODUCTION

be exercised as a function that unduly limits imagination. The intent of control is to assure that considerations of product function, cost and schedule remain
clearly visible, and that decisions made which significantly affect such considerations are made consciously,
with the effect of such decisions having received due
consideration. Concerning the time at which control
should be initiated, it is felt that "control begins when
the first germ of an idea for a project appears in the
organization-a discernible effort which will require an
expenditure of organizational resources (human effort,
time, money, physical resources) and lead to an organizational objective."l References 2 and 3 contain related
reading not totally in accord with the above view.
There are, of course, many problems of software
production other than those related to project management that can prevent the end product from being
successful, such as: a faulty or unknown product definition; badly estimated product life; too rapid a development speed; major design problems; poor staffing; and
inappropriate marketing (see also Sections III and
IV of Reference 4). Good management can in many
cases, however, assist in minimizing such problems by
providing early visibility of the product and its problems, and by providing an environment allowing timely
remedial action.
Prior to continuing with the body of this paper, one
reference is particularly recommended for project
planners. This reference, by Bemer,5 contains an extremely comprehensive and useful "Checklist for
Planning Software System Production." Reference 4,
also by Bemer, is further recommended reading.

Successful software development requires that the
product be accepted, that schedules are met, and that
costs are acceptable. The number of software development efforts that do not meet one or more of these
criteria is large. Conversely, there are many examples
of successful development. The total number and
variety of considerations that affect the probability
of success is so large as to be beyond the scope of any
individual paper. There is one important element of
software development that appears to have been
somewhat overlooked, however, and is the subject of
this paper.
This paper presents the thesis that the probability
of software development success is much increased by:
(1) a proper separation of responsibility within the
project organization, combined with; (2) extensive
formal procedures; the combination of the two providing a system of checks and balances that gives
continuous, accurate visibility of project status.
A general project organization is presented here
that is felt to be widely applicable, and that achieves
the required set of checks and balances. The formal
procedures required to enforce the organizational
division are not described completely or in detail, but
examples are given.
It is felt that viable commercial products will only
rarely be successfully developed with project organizations that do not provide some equivalent to the checks
and balances approach described here. It can be
argued that superior products may be developed at
less cost and more quickly by small expert groups
carrying the project from inception to completion. The
technical contributions possible from such an approach
cannot be denied, but the need still exists to place
these contributions in an environment that assures
their control. It should be noted that control need not

MAJOR PROBLEMS IN SOFTWARE
DEVELOPMENT
This section describes the problem areas that are
felt to be historically most common. The problems

129

130

Spring Joint Computer Conference, 1972

described in this section are felt to be significantly
reduced by the organization and procedures later
described.
In the most general sense, the two major problem
classes are:
Those that make the customer unhappy; and
Those that make the developer unhappy.
Problems in the above two classes might also be
classified as follows:
Unsatisfactory product
Schedule delays
Excessive costs
The above problem classes clearly are interactive, as
schedule problems lead to cost problems, an unsatisfactory product leads to remedial action (cost, schedule), etc. Thus the division is to some degree artificial,
but is useful for descriptive purposes.
The above three classes of problems will now be
discussed in more detail.
Unsatisfactory Product

The major causes of user dissatisfaction with the
product are:
1. Too Many Bugs
2. Instability
3. Unsatisfactory Performance

make it work, or the initial design is simply unsatisfactory in some way. In such instances an approach
sometimes followed is to "program around the problem", leading to further problems in all areas of system
performance, including possibly the undoing of some
important initial design concept unknowingly.
A further cause of program complexity is due to the
excessively "sophisticated," "elegant," "clever," or
"efficient" programmer. Most, if not all, . systems
operating today have sections that either never will
work quite properly or, if they do, dare not be modified
to meet new requirements, due to their initial implementation by a programmer with one of the above
attributes.
Poor implementation is a very common source of
bugs. The cost of finding and repairing problems caused
by poor implementation is so large as to make it quite
clear that proper project staffing, detail design reviews,
and strictly enforced unit test requirements are of
extreme importance.
A situation leading to the existence of a continually
high bug rate sometimes occurs when a product undergoes an evolution process in which new features are
introduced simultaneously with ongoing maintenance.
In such instances, synchronization between new features
and bug fixes becomes a problem. An approach sometimes encountered under these conditions is to create a
"safe" local environment by minimizing dependencies
upon other parts of the system, even to the extent of
creating duplicate or similar local tables, functions, etc.
The problems in future maintenance and modifications
are obvious.
2. Instability

1. Too Many Bugs

The reasons for an excessively high number of bugs
are many, including: (1) over-complex initial design;
(2) implementation not consistent with initial design;
(3) inappropriate implementation; and (4) uncontrolled
evolution. These points are elaborated upon below.
The design may be so complex that the system in
fact cannot be debugged. This complexity can be
introduced in a number of. ways. The initial design
concept may, for example, unduly require complex
module interactions, extensive time-dependent characteristics, multiple and non-obvious uses of the same
information by many parts of the system, etc.
Complexity can be introduced during modifications
following initial design if the initial implementors, or
the next generation of designers and implementors,
either cannot understand the initial design, cannot

The term "stability" will be used here to characterize the degree to which a job, once entered into the
system, will terminate only due to a user error, and
further, the effect of the user error is minimal (e.g.,
execution terminated, but files created to that time
are not lost). If a user's program frequently must be
rerun due to problems not of his own making, or if
the severity of the problem is not consistent with the
severity and probability of the error, then the system
may be said to be "unstable."
Instability was not a problem in the days prior to
multi-programming, as only one job was generally lost,
and a rerun usually was successful. In multi-programming batch systems even extreme instability could be
tolerated (and was) for a while, as a rerun often worked.
In time, however, more capable I/O devices such as
removable disks became available, with the attendant
need for extensive support software. The major stability

Organization for Successful Project Management

problem then became one of file creation and retention.
This problem remains in many systems.
With the advent of real-time and time-sharing systems,
stability has become much more important. In such
systems there are, typically, from 20 to 100 users
simultaneously somewhere in the processing cycle (in
core with the CPU, in core, swapped, etc.). Losing the
execution state, and possibly the files, of this many
programs, or of critical programs, is extremely serious.
The most significant factors affecting a system's
stability are the complexity of design and implementation, and the degree of attention paid by designers
and implementors to automatic system recovery. Even
good automatic recovery techniques cannot overcome
problems inherent in an over-complex system.
3. Unsatisfactory Performance

The performance of a system may be unsatisfactory
to the users. The performance of most batch systems
is not so bad that users consider it intolerable, though
it is still a major concern. The basic algorithms for
obtaining satisfactory batch throughput are basically not complex, but as batch systems attempt to
service an increasingly large community of hardware
and users, the simplicity possible disappears. Thus, the
major operating batch systems available vary widely
in design, and in classes of service performed well.
Batch systems with performance problems generally
are troubled with excessive overhead, complexity due
to the variety of user-types intended to service, difficulties in core management, and inadequate support
for large data bases.
In the time-sharing area there have been notable
instances where the performance was not what was
required. A number of reasons exist for performance
problems in time-sharing systems, for example, the
basic assumptions were over-ambitious, not well thought
out, or inadequately scoped (with modeling, for example). A more frequently epcountered cause of unsatisfactory performance in time-sharing systems is the
attempted retrofitting of a batch system to support
time-sharing users.
Schedule delays

The most frequent cause of a missed schedule is, of
course, the initial creation of an unrealistic schedule.
Other reasons, generally related to the first at least
implicitly, include ill-defined or missing requirements,
changes in baseline assumptions, the customer interface relation, plus many of the causes of product and
cost problems as described elsewhere in this section.
There are frequent instances in which the product

131

was initially ill-defined and underwent a process of
definition through its development. The conditions
under which the initial estimates were given often
change, including such changes in the available resources (money, skill, computer time). Requirements
to support new hardware previously unenvisioned are
often introduced.
The type of customer interface can have a major
effect upon schedule. The customer interface is defined
here as that person or persons who define, interpret,
and control all requirements that come from the
customer. The customer's relevant technical and
management experience, maturity, willingness to respond to suggested changes, understanding of problems,
and readiness to assist in achieving satisfactory mechanics of living together, are quite important. In
particular, it is extremely important that the customer
not require that all possible "bells and whistles" be
included in his product. He should be reasonable in
terms of tradeoffs, where considerable design and
implementation simplicity can· be gained by providing
somewhat less function to the user. The customer
must be convinced that simplified or limited functional
capabilities will often improve the eventual performance
and stability, and will increase the ability to add
future enhancements to the system.
Excessive costs

A major software development problem for the
developer, in addition to user-related problems, IS
cost. Major causes of cost over-run include:
1.
2.
3.
4.
5.
6.

Schedule Delays
Low Initial Estimates
Staffing Too Rapidly
Staffing With Quantity, Rather Than Quality
Follow-on Costs
Type of Contract

1. Schedule Delays
Delayed schedules generally lead to higher cost,
unless the developer had the foresight to see the
schedule was unrealistic and staffed according to a
reasonable schedule.
2. Low Initial Estimates

Some excellent techniques for estimating project
schedules and costs have been presented in the litera-

132

Spring Joint Computer Conference, 1972

ture. 6 Persons making schedule and cost estimates
must previously have been closely involved with
projects of similar size and complexity. They must
have accurate cost and progress summaries of the
previous projects. It is useful to know the original
estimates for previous projects, and eventual results.
The value of PERT-type techniques in making
initial estimates is limited, due to the lack of detail
concerning the project available at that time. A PERT
network or the equivalent should be constructed, however, even if only on a very gross scale, as a means for
forcing upon the estimators a mildly rigorous framework in which to place their estimates. Of particular
importance in ~he PERT are, of course, those things
that frequently lead to schedule problems. Foremost
among these are a knowledge of: (1) dependencies
outside the project; (2) the period required for initial
staffing, defining the organization, and other activities
required to have the people know what they are supposed to be doing, why, and when; and (3) those major
activities within the project which may proceed in
parallel, and which must proceed serially.
Machine time estimates are almost always underestimated, on projects of all sizes, and usually by a
large factor (two to four). Even when machine time
estimates are made by reasonable and experienced
people, they are often made invalid by the eventual
uncontrolled and wasteful manner in which the computer is used. Even today we find use of "block" or
"hands-on" time on large, fast machines. Unless
projects develop techniques for optimal use of computer time, including the support software required
to remove the need (except in rare cases) for hands-on
time, problems of cost, geographically separate computer installations, and inability to maintain schedules
will generally arise.
Some activities in project development can proceed
quite nicely in parallel by defining the major interfaces
early. For example, a compiler can often be developed
in parallel with an operating system, as its interface
needs are small. Similarly, applications design and
coding may often overlap development of the support
system.
3. Staffing Too Rapidly

Staffing a project is an important and complex
issue. There are never as many good people available
as a manager would like. A manager is aware that a
certain general level of manpower will be required to
do a job, and then the staffing search begins, trying to
identify people who are available, have relevant ex-

perience and skills, etc. Initial estimates that a project
will need a certain number of programmers should not
lead to the addition of "head count" simply to meet
predictions. In general; projects staff too quickly with
people anxious to produce code, and not quickly enough
nor with enough skill with managers and supporting
staffs (e.g., integration and test activities, described
later). Programmers are often brought on board in
order to start doing something before they really know
what to do. A good generalization is to always have the
minimum number of programmers possible on a project.

4. Staffiing With Quantity, Rather Than Quality

No matter how insensitive, trivial, simple, or straightforward a piece of code is to write, it will cost more,
often much more, if a poor programmer is given the
job. Sometimes the cost is hidden, perhaps for years,
but once programs "work" in some sense there is a
great reluctance to replace them, which tends to extend the life of some rather poor examples of the programmer's art.
In such complex areas as systems or real time software, unless there is a very large amount of review
talent available, people should not be brought onto the
project unless they are extremely skilled. (It can be
argued that this statement should be enlarged to include all types of programming.)
Relevant experience and resumes of people cannot be
considered the most important criteria for hiring. Extensive experience cannot overcome the lack of an
organized approach, insight, maturity in tradeoffs,
and a willingness to make very sure that a program
really works correctly.
It should not be assumed that key people will be
available through hiring, or transfer from other parts
of the company.

5. Follow-on Costs

Unrealistic estimates of follow-on costs after the
first release of a system are often made. Follow-on
costs may· include maintenance, enhancements due to
oversights in the initial product (frequently stability
and performance problems fall into this cateogry),
user enhancements required to stay competitive, a
need to support new hardware, etc. The larger a software system is the more reluctance there is to replace
it. Thus the product life may be long, with a fairly
continuous, and costly, development cycle.

Organization for Successful Project l\fIanagement

133

6. Type of Contract
The basic types of contracts are cost-plus fee (percentage of cost, award, incentive, etc.) and fixed price.
Virtually any type of contract is satisfactory if the
contract administrators on both sides are both knowledgeable and reasonable. Cost-plus contracts are felt
to be superior to fixed price contracts for all cases
except the (relatively rare) instances in which the
product, dependencies, etc., actually can be specified
in great detail. For example, the author has observed
in some detail a cost-plus contract with highly skilled
technical and management interfaces, and a fixed price
contract with a vague contract and inexperienced
interfaces. The cost-plus contract could have been
costly, but was not, due to the expertise of the contract
managers. The fixed price contract in theory limited
the cost, but in fact, due to extensive requirements
above the scope of the contract, resulted in contract
renegotiation, higher cost, schedule problems, ill will,
and eventual replacement of contract managers on
both sides.
There are, of course, instances of cost or product
problems in cost-plus contracts, if, for example, expensive and not necessarily talented personnel are
"dumped" onto the contract for profit and/or convenience. A sometimes-encountered problem in fixed
price contracts is a "buy-in," followed by either minimum possible contract interpretation or change of
scope. Again, experience and reasonableness on both
sides is required in order to prevent the contract type
from perhaps heavily contributing to cost and other
problems.
OPTIMAL 'PROJECT ORGANIZATION
This section describes a general project organization that assists in providing a check-and-balance
relation in a project that will contribute to project
visibility, control, and other factors important to
meeting project goals. This organization, and the
corresponding procedures of which examples are given,
is felt to have wide applicability, but is not, of course,
an exact model of any particular project. An organization will inevitably be shaped by the job to be done,
people available, company policies, etc.
This section discusses the following topics:
General Project Organization
Project Managers
Development Activities
Integration Activities

PROJECT
MANAGER

I

~DEVELOPMENT

DEVELOPMENT
~TASK 1

DEVELOPMENT
TASK 2

••
•

-~

DEBUGGING
TOOLS

PERFORMANCE
MEASUREMENT
TOOLS

DEP=NDEt\CY
CONSULTING
AND PROBLEM
DIAGNOSIS

···

I

INTEGRATION

I--

PROJECT TEST

-

TECHNICAL
REVIEW

---

TEST TOOL
GENERATION

-

BOOKKEEPING ~

TEST PLAN
GENERATION

-

INITI,\L
TESTING

~

TEST CASE
WRITING

-

PROBLEM
RESOLUTION
ANDlOR
IDENTIFICATION

r--

TEST CASE
EXECUTION

~

SCAFFOLDING
~
DEVELOPMENT

··

···
Figure 1-Project organization

Test Activities
Procedures
Staff and General Support Activities

General project organization
Figure 1 shows a project organization that it is felt
is generally applicable for a wide range of development
projects. Many of the functions shown in this figure
are not, of course, required precisely as shown in particular projects, but the major functions implied, or
their equivalent, are felt to be required in some form
for projects on the order of five people or more.
The key element of the figure, and indeed of this
paper, is the division of responsibility into separate
functional groups, such as those termed here Development, Integration, and Project Test. This division is
felt to be an absolute necessity. This division must
occur early enough in the project life so that each
functional group can adequately prepare.

134

Spring Joint Computer Conference, 1972

The following sections describe the Development, Integration, and Project Test groups in more detail. The
general responsibilities of these three groups are:
Development:
Integration:
Project Test:

Design, write, debug and unit
test new code.
Integrate all code. Be the project
"bookkeeper.' ,
Determine the status of integrated
code.

It is critical that people who are developing the product not be simultaneously responsible for all the bookkeeping functions, integration of new code, and confirmation that the integrated code works. The project
organization must be such that all groups have strong
technical people, and receive full support from the
project manager. Without an appropriate division of
responsibilities, and a corresponding set of procedures,
both visibility of true project status and control over
development are very difficult to achieve. Among the
typical problems that result are: not knowing what
code is really in a particular version of the system; and
a requirement to accept a programmer's statement for
the status of a module ("90 percent done, only a few
minor things don't work").
Project managers

The three levels of project management discussed
here are:
1. Project Manager
2. The Project Manager's Manager
3. First Level of Management Within the Project
One comment relative to all levels of management
should be made before going into further details.
Managers are assigned a responsibility, and must be
allowed to make decisions within their assigned responsibility without undue requirements to justify
their decisions. If a reasonable set of checks and
balances exists (e.g., Review Boards), and if the
managers chosen have appropriate experience and
judgment, then their scope of decision making should
not be frequently tampered with. Frequently no decision is worse than nearly any timely and moderately
rational decision.
1. Project Manager

The most important single person on a project is
the project manager. Therefore, choice of this person

should be made with appropriate care. There are a
wide variety of attributes that it is desirable to have
in a project manager, and a set of attributes that if
they exist in a project manager almost assuredly doom
the project to failure.
The project manager must be technically strong
enough to understand the important technical decisions made by those under him, to ask the rig~t
questions about those decisions, and to change them
if needed. In particular, he must be able to cause the
project to move toward realizable goals, and be able
to say "no" to impractical ideas, and enforce it.
The project manager must have both technical and
managerial maturity. All too often managers are chosen
on the basis of strong technical skills plus a desire to
be "promoted." Opposite extremes would be the assignment of a weak technical person to a managers role
because nobody else would put up with the customer
interface or personnel problems, or because the person
just happened to be available.
Another characteristic that must be contained within
the project manager is a desire to become involved. He
must manage the project, not simply spend occasional
time in reviews, believe all that is told him, and dilute
his activities with marketing for new business or other
company activities. It is always easier for a manager.
to assume that since good people are working in a
certain area, and everyone is working hard, the end
result will work out all right, and that he need not take
the time to dig into that area in detail. On reflection,
it almost always turns out that one or more areas do
not develop satisfactorily, regardless of the skill of
those most closely involved. Frequent reviews of design, implementation, test status, dependency status,
schedule milestones, etc., by the project manager, are
required.
It is not felt to be possible for a project manager to
be in some sense a "pure" manager, that is, manage
PERT charts, organization charts, staffing, facilities,
and so forth, and allow others to make the larger
technical decisions uninspected. This would rule out
software project managers whose experience is only
in other types of work.

2. The Project Manager' s Manager

In addition to the project manager being of appropriate technical and supervisory capability, it is
also critical that his immediate supervisor have relevant
experience, a set of both common and complementary
skills, and not be so sure of the project manager that an
independent check of status and problems is never

Organization for Successful Project Management

made. Every project manager needs someone reviewing his major decisions, a person to whom he may
bring problems and receive real help, and someone to
just talk to at times in order to remain objective about
his project.
3. First Level of Management Within the Project

A superior project manager can, with appropriate
organization and procedures, control up to 20-30
people satisfactorily with a set of managers reporting
to him that are really "technical task leaders" -strong
technical people with some supervisory capability,
each supervising 3-5 people. Above the 20-30 level,
however, support of full-time supervisory people
within the project is required.
Development activities

Figure 1 shows a number of possible functions to be
included within development. Many additional or
different functions exist, of course, for any particular
project. This is felt to be a reasonable example set,
however. The particular activities to be described in
this section are:
1.
2.
3.
4.

Major Development Function
Debugging Tools
Performance Measurement Tools
Dependency Consulting and Problem Diagnosis

Before beginning a discussion of the above, it should
be mentioned that this paper does not attempt to
discuss the merits of such very important development
considerations as: software specification or implementation languages; types of debug tools; tradeoffs
between speed, space, portability, flexibility, cost and
schedule; the value of formal proofs; etc. The emphasis
here is on functions that must somewhere be performed,
not how they are best performed.
Two characteristics of the development process that
frequently occur will first be briefly mentioned: the
effect of design changes during implementation; and
the occasional need to replace significant design or
implementation efforts. A great deal of interpretation·
of the initial high level design takes place during detailed design and implementation. If not carefully
controlled (via documentation and review) it is possible
to develop a product substantially different from and/
or inferior to that initially intended.
Occasionally it is realized that a significant mistake
was made in design or implementation. The tempta-

135

tion always exists to "live with it," "fix it up later,"
or "program around it." Generally such approaches
are a mistake-significant problems must be removed
when discovered, or at least a plan for their removal
created and begun. Too often the problems, if put off,
remain in the system for a long period of time and
cause far more difficulty than if remedied early.
1. Major Development Function
The major development function is, of course, responsibility for the overall design, detail design, debug,
checkout, and internal documentation activities required for product implementation. Worth mentioning
is the undesirability of fragmenting the responsibility
for this effort in a manner that results in a manager
with overall knowledge of the entire development not
having full control over work for which he is responsible.
2. Debugging Tools

The creation of debugging tools is a distinct programming task, with substantial requirements to be
defined, lead time needed for development, etc. In
general there remains far too much dependence upon
octal or hexadecimal dumps as the major aid to resolving difficult problems. Including appropriate (e.g.,
brief, symbolic) tools in a system initially is generally
inexpensive; adding them later is quite difficult.
3. Performance Measurement Tools

Performance measurement tools must be included
in development planning. This requirement needs
planning, lead time, etc. The capture and processing
of performance information is something that should
go on very early in a system, but often does not. Obtaining early indication of performance problems is
often critical, however, as their repair can require
major surgery.
4. Dependency Consulting and Problem Diagnosis

Programming projects usually have significant dependencies on areas outside their direct control, for
example, the hardware employed, support software,
and communications facilities. Where such dependencies
exist, it is best to assume that non-trivial problems will
occur, and place in the project appropriate skills to
isolate the problems and assist the appropriate support
group in their removal. Since such problems often arise

136

Spring Joint Computer Conference, 1972

due to misunderstandings resulting from inadequate
documentation, or perhaps just a complex dependency,
the ready availability of consulting assistance within
the project will be valuable.
Integration activities

Put briefly, this group's activities are to provide a
major portion of the independent control and visibility
of development activities that is required. The Integration Group lies or~anizationally between the Development Group and the Project Test Group. This
group receives new code from Development; integrates
the various pieces of new code received from Development; performs the bookkeeping tasks on detailed
status of all changes that have come in; assures proper
approval levels ; and other similar tasks, prior to passing
on a new release for testing.
The control over development resulting from this
sort of activity is obvious-nothing goes into the
system unless properly identified and approved, and
extensive documentation exists should the changes
need to be altered (or, in extreme cases, removed). The
visibility provided above an approach which has
Development personnel alone report on system status
is a bit less obvious, but critical. Development personnel
tend to be optimistic about their code, tend to report a
feature as fully provided even though only part of it
is done, and to otherwise exhibit human traits. Integrations' job is to be more hard-headed-something
is done only if the code was turned in, with appropriate
documentation (e.g., updated internals), and a repeatable test sequence (without which the change
is not accepted). Thus a project manager can know
exactly what is completed.
It is becoming more and more common in the industry
for the integration function to include very strong
technical people, for such purposes as: (1) providing
the ability to inspect new code submitted to the system
for general technical correctness; and (2) identifying
integration problems well enough to fix some, and if
not to provide good information to Development
people. If all the the project technical strength lies
in other groups, the Integration Group must always
borrow· technical resources from these other groups,
which they give up grUdgingly. An intermediate approach is to assign people from Development to each
new release, thus providing additional technical muscle
for integration activities.
Another important function of the Integration Group
is to perform some level of initial testing on the product
in order to assure that the major new functions will

work together and were integrated properly. Typically
a small set of regression tests is run by Integration to
assure that no major regressions have occurred prior
to approving a new system for more extensive testing.
In addition to the above principal activities, a number of other activities may be convenient to include in
the Integration Group. An item that may come under
Integration is one that is termed here "scaffolding
development." In the development of a new project
it is always required that some subset of the system be
generated first as an anchor on which the fuller system
can be developed, that some other system be used as
a vehicle for creating assemblies, load elements, etc.
The term "scaffolding" is used to define the set of code
and procedures that is developed to substitute for
missing interfaces or missing SUbsystems in order that
a partial system can run, or that phasing from one
system to another goes smoothly.
Enforcement of such standards or requirements
as linkage and naming conventions and memory utilization may also be conveniently performed by Integration.
Automated tools may help such activities.

Test activities

This section describes a series of testing levels, and
their place in the project organization. A fundamental
corollary of this section is the now (hopefully) clearly
established requirement that successful projects must
include: (1) early creation of test plans, procedures,
and staff; and (2) one or more groups established for
testing a product that are organizationally distinct
from and equal to the Development Group.
A testing approach that has proved quite successful
is one in which there are a number of separate and
distinct test activities, with minimal overlap, each
fulfilling a needed function. A possible set of testing
levels, chosen for purpose of example, is the following
five level set:
1. Unit Testing by Development programmers.

These tests show that the new function(s)
operate in a private environment. Development
managers must review the unit test plans in
detail, as a poor job at this level will be very
costly later.
2. Integration Tests, including rerunning of some
of the above unit tests, testing the ability of the
system to operate without major regression such
that the next testing phase can concentrate on
testing new code.

Organization for Successful Project Management

3. Project Test. This is the major test activity and
is discussed in more detail below. This group
runs extensive tests on new systems to confirm
that new features work.
4. Regression Test. In addition to testing that new
features work, one must also ensure that things
that used to work still do. This may be done
either within the project (e.g., by Project Test),
or by an organizationally separate group. The
regression testing activity differs somewhat from
Project Test activities in that: (1) the volume of
testing is larger; (2) the features tested are
generally more stable than the new features;
and (3) the regression testing group has more
lead time, better documentation, etc., than the
group testing new features, thus need not be
quite as good "detectives" to determine what
the new features really are.
5. Field Test. Regardless of the amount of prior
test, non-trivial bugs always exist in the final
release. For this reason a field test should be
scheduled, in which the new system is mounted
in one, or a few sites, and watched for a while,
prior to full release.

The Project Test Group normally performs the
following functions:
1. Test Tool Generation
2. Test Plan Generation
3. Test Case Writing
4. Test Execution
1. Test Tool Generation
Test tool generation requires both "hooks" in the
system, and programs to process and analyze the
results. To minimize the requirements for support upon
the Development Group, it is advisable to develop
test tools that are carefully designed to capture all
information that is likely to be useful, but impose
minimum space and complexity requirements upon the
system. These tools should not be the last functions
integrated. With early data definition, the required data
processing programs may be developed in parallel with
the system. Typical of the test tools that are required
for development of modern systems are a means to
easily and repeatedly run large series of programs. For
example, a common practice is to simulate a large
number of users in a time-sharing environment, with

137

input coming from precatalogued files rather than
on-line users, but seen by the system in a very similar
way. These "prestored" jobs may contain test programs, a sample of real user programs, or both. Information captured from these test tools should record
such information as is later needed to determine such
things as response times, if or not the output compares
on a line-by-line basis to previous runs, and so forth.
2. Test Plans

Extensive study of documentation and listings plus
detailed planning is required to develop a set of test
plans that may be reasonably executed and analyzed.
Test plans must include enough detail so test cases are
not written with dependencies on functions not yet
integrated. Among the many types of tests that must
exist are those for testing: functional capabilities;
stability; performance; fallback (the ability for a system to be replaced by an earlier release if it fails); and
the ability to support various hardware variations,
including degraded mode operations in which only a
subset of the hardware is available.
3. Test Case Generation

This is a difficult effort to do well if the test programs
themselves are to: (1) not produce more bugs than
they find; (2) efficiently and completely implement the
test specifications; and (3) be self checking to a large
degree.
4. Test Execution

Test execution includes the actual running of the
tests, creation of files used for later analysis to determine
if the tests ran properly, documentation of results,
getting the information back to the Development Group
and consulting on procedures used, and so forth. With
automated test tools this effort can be reduced very
significantly, with only a few people required to test
features not easily tested automatically.
Procedures

The type of procedures required to assist in providing
project control and visibility may be very large. This
paper does not attempt to give a detailed set of procedures. The following list, provided as an example,
gives information which would be expected to be

138

Spring Joint Computer Conference, 1972

submitted by all Development programmers when
their code is ready for Integration.
System level upon which the changes are based
System level intended for inclusion of the changes
Change identification
Change description
Listing of the changes
Card deck (or the equivalent)
Changed internal documentation
Changed operational documentation
Changed external documen tation
Dependencies upon other changes
Modules changed
Copy of the unit test passed to confirm unit
testing, and instructions for reproducing the test
results in the integrated system
Approval signatures
For an example of support software to aid in implementing procedures of the above type, see the CLEAR
system description of Reference 7.
A further example of a procedure usually needed is
an automated planning aid of some sort. There are a
number of reasons why a mechanized aid (such as
PERT) is useful. These include:
1. A common basis for discussing project status is

defined. Even if it is not quite everything that
would be desired, everybody gets used to using
it, and the shortcomings are overcome.
2. The mechanical difficulty of experimenting with
changes in work required, people available,
slipping dependencies, etc., is much less, as one
need change merely a few data cards and rerun
a program to get an initial feel for problems,
tradeoffs, etc.
To meet the above objectives, the scheduling aid
must have a number of attributes, including: (1) the
output must be prepared by computer, not the local
art department, as waiting a week to see the latest
chart makes the whole thing useless; (2) the input
preparation must be relatively simple; and (3) the
process must be flexible enough and closely enough
related to the projects' detailed activities to be a widely
usable day-to-day planning tool (for example, listings
should be produced that sort activities by start date,
end date, person assigned, release version, etc.).

Staff and general support activities

There are a variety of activities that must exist
within either the project or a supporting organization
that do not always fall neatly into the Development,
Integration or Project Test Groups. Those discussed
here are:
1.
2.
3.
4.
5.
6.

Staffing Assistance
Customer Interface and Support
Review Board
Operations Support
Documentation
Status, Cost and Schedule Data Collection,
Reporting

1. Staffing Assistance

In the early days of a project, when many people
must be interviewed, resumes must be reviewed, and
so forth, the project manager should not have to (and
cannot) do all the recruiting for the project. It is also
felt, however, that this job cannot be delegated completely to a personnel department. A good personnel
department can be very valuable by performing such
activities as obtaining candidate names and performing
initial screening for quality and relevant experience.
Technical men on the project must do all detailed
screening, recruiting and staffing for the project, however. This is a difficult job to do well, as people range
from uncommunicative geniuses to imposing charlatans.
Nevertheless, detailed interviews combined with extensive checkups of references can assist greatly in
minimizing the dead wood brought aboard. Realistically, it must be faced that more people must be
hired than are needed, as some will not work out and
must be discarded in short order.
2. Customer Interface and Support

A major element of the customer interface must, of
course, be the project manager himself. This is so since
he alone is responsible for the project, and therefore
only he (or hjs manager, but hopefully not independently) can commit the project. It is often the case,
however, that there is a need for frequent discussions
between vadous people within the project and within
the marketing organization, or other organizations
working with the project, such that a continuous and
heavy transmission of information back and forth
across the project interface must exist. The project
manager is generally too busy to both perform this

Organization for Successful Project Management

function and manage the project, so it is wise to set up
a small group, perhaps one person, reporting to the
project manager, to provide a continually available
interface to the customer. This may include such
customer support functions as assisting in preparation
of rough external documentation and/ or proposals
for the customer, looking in advance at conversion
problems when the system becomes operational, etc.
A further important role of the customer interface
may be one of providing appropriate visibility concerning progress and problems. It is fairly easy for a
project manager and a customer to both be working
hard and think the other one knows what each is
doing, but to discover that in fact major differences of
opinion occur. A good interface can reduce these
problems.
3. Review Board
A review board should be established that includes
people who are generally not assigned full time to the
project, but remain cognizant of technical activities
going on in the project through their continuous participation on the board. This board includes senior
technical people from wherever is appropriate. The
purpose of this review board is to review major decisions either already made or that must be made before
going on. This helps assure that all relevant experience
available is brought to bear. Items reviewed should be
of both technical and administrative (e.g., cost, schedule) nature.
4. Operations Support
Computer operators need someone to call on for help
occasionally, efficient machine room procedures need
to be developed that are generally rather different in
project development from those in a typical production
shop, etc.

139

people who must run the computer center, documentation for user managers, training documentation, etc.
One of the major unsolved problems of the computer
industry is the creation of appropriate documentation,
at a reasonable cost. It always seems to get done
eventually, but is always painful to the programming
staff, and not infrequently to users.
6. Status, Cost and Schedule Data Collection, Reporting
Projects sometimes begin with good procedures in
place for creation of status, cost and schedule collectio n,
etc., but as time goes on less and less use is made of such
procedures. A frequent cause is the lack of staff to
regularly collect and report upon the data collected.
This can be a substantial job, but if done properly
provides management with early indications of potential trouble areas.
SUMMARY
The proper management of programming projects
requires means for visibility and control. To know
what is actually going on in a project, to not have
critical path activities slip, to head off such difficult-tosolve problems as memory over-use and slow performance, and with all this to meet a tight schedule and
budget, is a challenge met by few. The primary attributes that must be contained in a project to provide
good visibility and control are:
1. Division of responsibility in a manner that gives
good checks and balances (separate groups for
Development, Integration and Test).
2. A large set of procedures, rigidly enforced, that
supplement the above organization by forcing
an automatic flow of information.
3. Managers, supervisors, and task leaders at all
levels that have good technical judgment, and
will "dig" to find out the true status of all work.

5. Documentation
REFERENCES
Documentation is always a problem, both where to
place it organizationally as well as who should do it.
There is a very wide variety of types of documentation
to be done, usually far more than is obvious at budget
time. Among the major types are, of course, the internal
documentation for the system (usually done in Development, with the support from elsewhere). Another obvious type is the external documentation for the user.
There is also the question of documentation to support

1 C KING
Systems analysis and project management
McGraw-Hill Book Company New York 1968 p 255
2 ME CONWAY
Datamation Vol 14 No 4 April 1968 pp 28-32
3 R H KAY
The management and organization of large scale software
development projects
AFIPS Conference Proceedings Volume 34 1969 SJCC
pp 425-433

140

Spring Joint Computer Conference, 1972

4 R W BEMER

Manageable software engineering
Software Engineering Volume 1 Computer and Information
Sciences Academic Press 1970
5 R W BE MER
Checklist for planning software system production
NATO Conference Software Engineering Report on
Conference 1968 pp 165-180

6 J E ARON
Estimating resources for large programming systems
NATO Conference Software Engineering Report on
Conference 1969 pp 68-79
7 H M BROWN
Support software for large systems
NATO Conference Engineering Report on Conference 1969
pp 53-60

Commercial data processing machines in
government applications
byJ. D. ARON
IBM Federal Systems Divisi'.Jn
Gaithersburg, Maryland

BENEFITS OF USING COMMERCIAL
HARDWARE

INTRODUCTION
When a major military weapons system is designed,
it is often so far ahead of the then current commercial
technology that special approaches are needed to make
the system feasible. This has led to the development
of many special purpose computing systems as components of large government procurements. But special
purpose hardware is often too complex to be built on
normal schedules; furthermore, the software to go with
it must be deferred until the special machine is finished.
The sequential nature of the hardware/software development cycle means that any slip in the schedule of
either element directly affects the total system schedule.
One obvious way to avoid cost and schedule problems
due to spec:al purpose computing systems is to substitute commercially available computng systems for
them.
There is a lag of some 3-5 years between the specification of a major government application and the
detailed design of related non-government systems.
Dur'ng this period, the hardware and software designs
of the computing industry generally incorporate the
special characteristics of the government system for
their standard product line. By the time the government system goes into operation, contemporary commercial systems have caught up. Thus, the convergence
of government and commerc'al needs is leading to
standard computing systems which meet all but a few
of the needs of the special military and federal civilian
applications. In those cases where the commercial system
is totally responsive to the requirements of the special
system, it offers sufficient benefits to recommend it in
preference to special purpose hardware. In other cases
where the commercial offerings are only partly responsive, there are still significant advantages to the use of
commercial systems (modified as necessary) to be
evaluated by the system manager.

Salient benefits

The benefits of using commercial hardware depend
on which elements of the system design have the highest
priority in the mind of the user. For instance, in evaluating commercial data processing alternatives for the
SAFEGUARD system, the Army l:sted five system
characteristics in relative order of importance and
weighted them to emphasize the ranking. Performance,
including throughput and some aspects of reliability,
carried 40 percent of the weight. Product Deliverability
was next in importance, followed closely by Implementation Risk. Some 10 percent of the weight was
assigned to Growth Potential and Cost carried a
nominal 5 percent. Commercial alternatives will score
very high in the last four characteristics. Will they stand
up in Performance? Probably, yes. The computing
performance of general purpose mach'nes has been
growing by an order of magnitUde every five years.
There is no sign that the growth will stop.
The commercial computer approach is strongly
enhanced by the availability of compatible families.
This feature of the commercial market was introduced
in a limited way in 1962. Taking advantage of this, for
instance, the USAF Command Post Project 473L was
able to install an IBM 1401 computer very early in the
system design stage to test out concepts related to disk
storage and display consoles. Later, as the workload
on this facility grew, the 1401 was replaced by the
larger 1410 without substantially altering the system.
Through the emulation capabilities of the third generation S/360, some of the original 473L programs could
still be used after the 1410 reached the limit of its
utility. Most manufacturers now offer commercial families of compatible machines. The same degree of com141

142

Spring Joint Computer Conference, 1972

patibility is seldom offered in the special purpose computer market for simple economic reasons: neither the
buyer nor the vendor has a cost justification for developing any features other than those directly applicable to
the special application. Consequently, there is less
growth capability in special purpose machines procured
for military systems than there is in the standard commercial product line of a given manufacturer.
Referring again to 473L, the use of the 1401 as an
interim test bed illustrates a common aspect of the
system development process. In order to make progress
on the overall system it is important to overlap many
activities. Programming, as an example, will proceed
while the hardware is still being built. In 473L it was
necessary to create a simulator of the Librascope
L-3055 computer, specially procured for the project.
The simulator ran on a commercial 709 located in the
programming facility. By using the simulator, the
programmers were shielded from delivery delays in
the L-3055.
The rigid product test protocols observed by most
manufacturers further increase the confidence that
commercial machines will perform according to their
advertised parameters. The risk, as has occurred on
special procurements, that a computer will be delivered with some of its instruction set still undefined
and perhaps not included in the circuitry is negligible
with commerical machines.
If the performance and reliability of commerc'al
machines are sufficient to justify their use to the systems engineers who design the military and federal
civilian systems, then the software support available
with the machines should throw the decision well over
in favor of the commercial product. Sof~ware, which
includes development aids as well as the deliverable computer programs, has become the most difficult aspect of
large systems to plan and control. Project management

is generally unfamiliar with the nature of software and
lacks the experience to estimate and schedule the programming effort accurately; However, since a data
processing system is a package of hardware and :~dt­
ware, in which the software is the only feature directly
accessible to the user, the system cannot be completed
until the software has satisfactorily passed its tests.
It is specifically in the area of software that commercial
machines have a marked advantage over special purpose implementations.
Vendor software, available with the first delivery of
machines, normally includes a basic operating system
which controls the hardware function and facilitates
the preparation and execution of user programs. In
addition, the vendor supplies a. variety of language
processors: basic assembly· language for manipulating

the hardware instruction set, higher level languages
such as FORTRAN, Algol, COBOL, JOVIAL, and
PL/1 for application programs, and simulation languages such GPSS and SIMSCRIPT for building
models. The higher level languages are easier to use
than the basic assembly language and speed up the
development effort. The languages have the added
benefit that they are easy to learn and can be transf erred from one machine to another with relative ease.
The advantages of higher level languages are so selfevident that some have been written to run on special
purpose processors. But the resources applied by the
general purpose machine manufacturer to come up
with a comprehensive efficient high language processor
are too extensive to be duplicated on each special
processor. The result is most often a l'mited subset of
the full language and an inefficient compiler.
This 1ast point, when extended to cover additional
areas of vendor support and product enhancement,
emphasizes one more significant benefit of commercial
machines : Commercial systems are usually less expensive
because they ach"'eve economies of scale inaccessible to
special products.
Characteristics of applications of interest

There are three general classes of government applications which can be identified according to the stringency
of their unique requirements:
Class I-Problems such as inventory management, management information systems, finance
and accounting, etc., which are performed daily
or less often in an office environment.
Class II-Problems such as assisting commanders in operational situations or controlling
weapons and space missions. An office environment
with special security, reliability, and availability
provisions is required in fixed installations. Installations in aircraft or ships may call for special
equipment.
Class III-Problems such as air navigation,
weapons guidance, or space veh:cle maneuver
control in an environment in which temperatures
and other physical parameters can vary widely
and where the computing element may have to be
shaped so as to fit into a small space. Reliability
must be very high and maintenance may be impractical once the mission has started.
Class I problems are normally handled by commercial
hardware. Class II problems are dominated by the

Commercial Data Processing Machines in Government Applications

environmental constraints and are normally handled
by special hardware*. Class II problems, which are
the primary subject of this paper, present the opportunity for tradeoffs between special and standard
hardware. The typical tradeoff to be made is whether
to place a specially designed machine in an uncontrolled
field environment or to create a ,spec'ally designed
controlled environment in which to place a commercial
machine. The commercial machine approach is most
appropriate for fixed installations at headquarters
locations and for transportable facilities in vehicular
vans and airlift pods. The decision can swing either way
for ship and submar~ne installations. The airborne
case will almost always call for special hardware to
meet space and weight constraints.
The SAFEG UARD advanced ballistic missile defense system falls in the second class. So do Air Traffic
Control and the ground support for the Apollo manned
space flight system. In each case there is a need for
large capacity storage, fast computation, versatile
input/ output devices, communication with other systems, high availability, and the flexibility to respond
to changing workload requirements.
Performance

No effective measure of computer performance
has been developed that applies to more than one
situation; therefore, it is common to describe performance requirements by the arbitrary value of the instruction execution time. The lack of other throughput
requirements is usually due to the inability of the
system designers to anticipate the effect on throughput
of interactions among the programs in the job stream.
At best, the designers can lay down specifications for
system throughput based on the real time requirements
of one critical activity. Most of the complex systems of
interest to the government involve many related
activities; e.g., the relations between radar data and
aircraft tracks and between aircraft tracks and flight
plans and between aircraft tracks and traffic control
procedures. The relationships cannot be unravelled so
that the system design requires all of the computing
to be done on a single computer configuration t where
all the related information is available at the same time.
While it may be useful to categorize machines based
on a single parameter, selection of a machine for a
particular application should be based on a more

* Some Class III problems require so many identical computers
that economies of scale can be realized.
t Which may contain multiple OPUs.

143

thorough analysis of its capability to handle the
specifics of the job. The selection of computer hardware
should be one of the last things done in the design
phase. Premature selection will force the designers to
distort the rest of the system to conform to the computer. Problem definition, workload sizing, allowable
computing overlaps, deferrable computations, absolute
real-time deadlines, I/O rates, and other job descriptors should be determined first. Then a balanced
computer configuration can be selected (using a gross
model for timing and storage evaluation) which will
do the job. If this policy is followed, the lead time for
computer delivery will be compressed.
There are very few performance requirements that
cannot be handled by off-the-shelf hardware. The per-

formance criteria in which commercial machines exceed
the capabilities of most special purpose machines include:
1. Range of speeds available for a family of central

processors;
2. Range of memory capacity for a given processor
or family of processors;
3. Number and diversity of input/output devices
available.
• card handling equipment
• printers
• typewriters and teletypewriter terminals
• displays and plotters
• communications adapters
• tapes
• disk units
• drum units
• on-line sensors and output controllers
• other computers
4. number of computer programs available
• to support the machine operations
• to support programmers
• to solve problems
• to support terminal users
• to support system analysts
A characteristic of a commercial product line is the
way in which the above facilities are coordinated so
that a large number of possible configurations of the
system can be used efficiently. In the typical special
processor whatever support is provided in the way of
balanced performance or software support is optimized
around the original problem statement and may be
somewhat clumsy when used for a variation of the
problem or for a different problem.

144

Spring Joint Computer Conference, 1972

The areas in which commercial and special machines
can be roughly the same include:
1. Ability to multiprogram (time-share more than
one program at a time);
2. Ability to multiprocess (run one problem on
more than one computer to share the load) ;
3. Ability to handle real-time inputs;
4. Ability to connect redundant system elements
through cross-channel switches;
,
5. Ability to interface with special processors of a
different type;
6. Ability to nterface with special input/output
devices.
The fact that commercial market requirements have
grown to include these features makes the standard
products highly competitive with special machines.
However. there are performance limitations in many
commercial machines which can be avoided in special
machines at the expense of balanced machine operation.
The areas in which special purpose processors can be
superior include:
1. Instantaneous speed of input/output (bits per
second per channel);
2. Maximum capacity of I/O channels (bits per
second for all channels taken together);
3. Interference between memory cycles and I/O
cycles;
4. Ability to do parallel processing (run many
copies of the same program at once);
5. Do self-diagnosis and error correction.
With few exceptions, the special purpose processors
used in military and federal civilian applications were
built by the same people who build the commercial
products. Therefore, there is no technical reason why
the same capabilities could not be offered by them in
their standard product line. Their decision not to make
such products available is an economic decision.
Software and compatibility

As mentioned earlier, the computer programs required to construct and operate a complex system are
beginning to dominate the project. Not only are the
costs, as a proportion of project cost, increasing but
the schedule impact of software development is being
felt in later operational dates. The larger the programming task is, the more severe the impact is. In order
to shorten the overall development schedule two steps

are recommended:
1. Use existing tested software where applicable.
2. Build and test programs in parallel with other
elements of the project.

These steps are facilitated by the use of commercial
machjnes because the vendor can supply a library of
tested support programs. Commercial test machines
compatible with the proposed operational computer
can also be obtained. The library of software for commercial machines extends beyond basic operating
systems, languages, and utilities. Information handling
systems which assist the user build and maintain files
as well as query them are offered in versions which stress
speed of retrieval and versions which provide great
file handling flexibility at slower speeds. Management
control support programs can be obtained which
process project activity network data. Mathematical
and statistical routines, output display formatters and
report generators, flowchart programs, and various
aids to the programmer are also found in vendor
libraries. *
The process of programming consists of designing the
logical set of steps to solve a problem and then coding
and testing the steps. Both logical design and coding
are subject to error; the errors, or "bugs" are detected
by running program segments with test data. As the
programmer finds and corrects the bugs he then repeats
the process of design, code and test until his unit of
programming is correct. Later his unit will be integrated
with the programs written by others and the group of
programs will be tested against the system specification.
Without exception, additional errors will be detected
at this point. However, it is not clear whether the new
error is due to a faulty program unit, a faulty test case,
a machine error, an operator's mistake, or a faulty
system spec. Therefore, the analysis of the error involves a great deal of trial and error and a lot of machine time. It is very important that this process be
carried out on a machine which acts exactly the way the
final operational system will act if all the errors are to
be found. Thus, the machine used by the programmers
for debugging their program units should ideally be
compatible with the machine in the operational system.
Programmers need large blocks of uninterrupted
computer time. Rather than sharing an engineering
prototype, programmers want their own machine that
will let them get started on productive work at the
earliest possible time.

* Modern libraries include programs from many sources; some are
available at no charge, others are sold, leased, or licensed.

Commercial Data Processing Machinoes in Government Applications

Carrying this concept one step further, many programming managers are examining methods for increasing programmer productivity bygjving the programmer better access to a computer and by giving
him better tools at the computer. The access problem
is addressed by installing a time-sharing system which
allows the programmer to do his work at a terminal,
cutting out the middlemen in the computer facility. *
The tools question is addressed by providing programs
to maintain the programmer's library and history files.
With these tools, the programmer can create test data
files, program files, and command files so that he can
invoke a set of commands to execute a set of programs
against specified test data. He can do this without
handling any of the input data more than once, saving
himself a lot of paperwork and a lot of running back
and forth to the machine room. When the machine
he is using is compatible with the final operational
machine, it is a simple matter to transfer the set of
completed work to the operational system to signify
that he is done. When the final machine is different,
there is an extensive requirement for translation, reprogramming, and retesting before the program can
be accepted for the final system. In other words, the
compatibility of the support machine with the final
machine shortens the time and lowers the cost of producing
a final version of the programming system.
The benefits of the compatibility concept carryover
to the operational system in some instances. Several
government systems have been specified in such a way
as to have all programming done at a central point. In
TACFIRE, an Army artillery fire control system, the
programming was to be done in the U.S. and shipped
to tactical installations at field locations around the
world. The programs, written in PL/1, would be
debugged and tested on a commercial machine in the
U.S. using a compiler modified so as to create output
programs in the language of the field machines. Under
these conditions, it must be assumed that no changes
of any type were to be made to the programs in the
field. Such a system is feasible but is more difficult to
manage than one in which the ability to make a change
in the field exists. Compatibility between the base
machine and the field machines would provide that
option in systems similar to T ACFIRE.
A considerable advantage of commercial machines
for the fast startup of a project and for the installation
of the initial capability lies in the ease of training the
project staff to use the equipment. The likelihood that

* For simple debugging, the time-sharing system may look like a
subset of the operational machine. The use of "virtual machines"
can eliminate this restriction if required.

145

trained personnel can be hired to use commercial
machines is high and getting hIgher as schools add data
processing courses to their curricula. The likelihood
that trained people exist for a special purpose machine
is nil. Furthermore, the nature of the training for a
commercial machine is identical to that offered by the
vendor or any number of independent computer training
schools. The training program for a special purpose
processor is almost always unique and may be unsuitable for teaching institutions. The corollary of the
training problem is that many people are willing to
work on a general purpose machine whereas they are
reluctant to accept employment to work on a unique
machine. Their reasons are tied to their future career
plans. Employment history shows that a computer
engineer or programmer has more opportunities for
advancement when he is in the main stream of the
industry that when he is associated with a special
purpose one-of-a-kind system.

Hardware and compatibility

There are several other factors affecting the specifications of military and federal civilian systems. Some
are spurious; for instance, it is not unknown for a buyer
to specify an advanced componentry because it is newnot because it is essential. This was common during
the transition from vacuum tubes to transistors. Although such a spec may have been necessary to achieve
a performance objective, in some situations it simply
increased the risk of on-time delivery. Other specs are
more significant because they reduce the system cost
and reduce the complexity of the system both functionally and operationally. An example is the specification of a standard interface for connecting input/
output devices to the computer. At the many Air
Force and NASA ranges, for instance, there was a proliferation of special sensors to track rockets and aircraft and to process communications from space vehicles
and from remote tracking stations. Acquired at different times for different purposes, the sensors had a
wide variety of interfaces. Consequently, when it became evident that unified range operations would improve the support provided to all range users, a whole
new set of "black boxes" had to be acquired to connect the sensors into the common network. In this respect, commercial machines are ahead of the government. Standard interfaces that allow off-the-shelf
equipment of one manufacturer to interface with that
of another manufacturer are the norm. Vendor specifications of their standard interface in terms of wiring
diagrams and voltage levels are readily available so

146

8pring Joint Computer Conference, 1972

that it is reasonably easy to procure peripheral devices
that meet the standard. This facilitates the use of other
vendors' devices and permits the attachment of special
purpose sensor and control devices to the central computer. The result is a capacity for horizontal growth.
Manufacturers provide for vertical growth by designing a compatible family which includes central
computers of various speeds. Thus, the IBM 8/360
line provides for compatible processors (each capable
of reading the same programs and handling the same
input/output records) that can handle anywhere from
5.33 bits per microsecond to 2370.37 bits per microsecond. While the bits per microsecond do not relate
directly to performance, they do give a feel for the very
wide range of capability found in a compatible family.
Additional vertical growth can be obtained by increasing
the amount of storage available on the central computer. This contributes to throughput by reducing the
amount of traffic between the central computer and the
auxiliary storage devices. Here, too, the range is
enormous running from a few thousand characters to
several million characters of storage in the same family.
An analysis of the combined computational and information handling capability of a line such as the 8/360
shows a ratio of overall performance of 36 X 106 between the very large 8/360-195 and the very small
8/360-20. More realistically, there is a range of two
orders of magnitude in the performance of the Model
195 versus the Model 65 which would be a typical
development support machine for the large processor.
The existence of compatible families of commercial
machines permits the installation of a small machine
for which complete software support will be available
in more or less the same form as the support for a larger
version of the machine so that the scaffolding developed
around the small machine is directly transferrable to
its successor. Thus, maximum use can be made of commercial components early in the schedule without compromising the flexibility of the system design.

Reliability and serviceability

Under the topic of reliability and serviceability are
included considerations of availability (is the machine
ready when requested?), reliability (does the machine
function correctly?), maintainability (how long does
it take to service and repair?), and modifiability (how
easy is it to add a feature to correct a recurrent problem?). In engineering terms, these characteristics are
often provided by redundant facilities. In some machines, the redundancy is built into each box by repeating circuits twice or three times. More commonly,
the system as a whole is redundant with more than

one processor connected through cross-channel switches
to multiple copies of the input/output devices. When
one element fails or deteriorates, it is removed from
the system for maintenance and the rest of the system
continues to operate. The level of redundancy is established so that the remaining equipment can handle
the entire application (fail-safe) or some subset of the
application (fail-soft). In addition, the software is
designed to permit frequent checkpoints which copy
the status of the machine so that, if a subsequent error
occurs, the program can back up to the checkpoint
and restart with correct data. The time required for
automatic restart is small compared to the repair time
of the machine and, in fact, the operator may not even
notice that an interruption occurred. The ability to do
these things was developed on special purpose machines
but is now generally available on all major commercial machines.
The reliability which is demanded of individual
units of equipment may exceed the design ljmits of
commercial hardware. This degree of reliability, however, may be somewhat unrealistic. Enemy action,
failure of sensors, or natural catastrophe might cause
a system failure quite independent of the condition of
the individual system elements. For instance, suppose
an air traffic control system were based on data from
satellite-borne sensors passed to the ground through a
communications ground station. In principle, one
ground station would suffice for the system. In practice,
one ground station is inadequate because it could be
put out of action by an earthquake, fire, aircraft accident, broken transmission line, etc. At least two
ground stations are needed to make the system reliable.
The additional ground stations could share the system
workload or could act as backup for the prime station.
In each station there could be a duplex or multiprocessor computer to increase its availability. Now the
system as a whole is more likely to work properly than
if there were only one station regardless of the reliability
of the individual units in the single ground station.
Thus, although commercial machines fail to meet the
initial hardware specs of many special applications, the
need for these restrictive reliability standards can be
called into question in those applications where system
reliability results from good system design.
Component technology in commercial hardware
equals or exceeds the performance called for in contemporary special hardware. The large volume of the commercial vendors had led to the development of mass
production techniques for componentry which have a
high yield at very low cost. The comparable process
technology for special components would require the
same initial development expense without the equivalent product base against which to amortize the cost. A

Commercial Data Processing Machines in Government Applications

related benefit of mass production is that the lifetime in
the field for a given family of components is quite high.
This makes it economically feasible for a manufacturer
to continue to produce spare parts for that component
family long after new production of the machine is
terminated.
The fact that commercial hardware does use production quantity components leads to a very high
degree of standardization with the system. The number
of different parts used is generally held down to facilitate
the logistics of resupplying the field maintenance staff.
A great deal of effort goes into making the system simple
to maintain: extensive diagnostic aids are provided,
pluggable replacement assemblies of optimum cost
(trading off repair versus throwaway) are designed,
multiple sourcing for parts is planned, training material
is designed to be explicit yet easy to learn and understand, machines are assembled for easy access to
components, etc. Commercial machines are built,
wherever possible, to use standard power sources and
to place a minimum burden on the user for special
office conditions or construction. The commercial
system development cycle includes the preparation
of training programs for maintenance people as well
as engineers and programmers. In most cases, a pool of
experienced maintenance people exists at the time of
delivery of the first field machine. Similarly, a large
and adequate stock of spare parts and replacement
units is placed on the shelf to meet the needs of the users.
The byproducts of mass production are not obtained
in special purpose computers. Here, reliability is obtained by more careful parts inspection, by designing
for larger margins of safety, and by continujng operation while minor repairs are in progress. The degree of
reliability achieved approaches that desired as close as
the buyer's budget permits. The net result is that, in
area~ of service and reliability, the commercial standard
is very high and, although not higher than what the
government buyer wants, it is often a good deal higher
than what he ends up buying.
Flexibility

The use of standards to improve the general purpose
product could restrict the flexibility of commercial
systems. Fortunately, this has not occurred. The
standards normally apply to components and interfaces
in such a way that system modification is quite easy.
This can be observed in applications where one aspect
of the problem must be processed at a much faster rate
than other aspects. As an example, a communications
satellite may store data received as it travels around
the globe and then spew it out all at once when it

147

passes over a receiving station near its home base. The
data must be accepted when the satellite is overhead
because there will never be another opportunity to
pick up the message. In this case, commercial machines
can still be applied as, indeed, they are. A special input
buffer is required to collect and hold the satellite output; the buffer is a very high speed recorder. Then, at
computer speed, the buffer transfers the data to the
computer. In some instances, such as at missile ranges
where the data stream is to be sampled before it is
analyzed, the buffer may do a limited amount of data
screening, editing, and summarizing before transferring
the stream to the computer. This combination of an
"intelligent channel" with a computer is a special case
of the commercial machines' ability to interface with
special I/O devices. When the input stream exceeds
the computer capacity for extended periods of time,
it is necessary to replace the computer with a higher
speed processor. In practice, this requirement occurs
with both commercial and special processors; however,
the replacement is often more practical with commercial machines from compatible families.
In those problems that call for a parallel processor,
several options are available. Very few problems are
so well structured that, at all times, they can be subdivided into exactly the same number of identical
computations. Thus, a machine like the Illiac which
provides 64 parallel processors may be fully utilized
only when a 64 part problem is being processed. Most
problems involve some serial processes in addition to
the parallel processes. For instance, in a system which
analyzes seismic data to detect earthquake events, the
process may start with some housekeeping to set up
the input record format and allocate some memory
locations to the results of the analysis. Then, by applying a transform algorithm to the input data the
results can be computed and stored in the allocated
space. The frequency with which the computer is asked
to compute the transform may be small in the light
of other jobs to be done in the facility. Therefore, instead of buying a parallel computer, the project manager will consider augmenting a standard commercial
machine with a low cost Fast Fourier Analyzer box
that attaches to an input channel of his computer.
The speed of the FFA is only used for FFA problems;
the rest of the time it is ignored.

LIMITATION OF COMMERCIAL HARDWARE
The advantages listed above are not without limits.
Several limiting features of commercial machines have
been mentioned but bear repeating. Others related to
commercial business practice are also relevant.

148

Spring Joint Computer Conference, 1972

Environment

A typical office environment implies a room with air
conditioning and good janitorial services, plenty of
enclosed storage space, space for maintenance people,
etc. Such facilities are often available for military
systems even when the room is inside a bombproof
shelter. When the computer is in a properly shielded
environment, a special effort to "harden" the computer against shock, vibration, fungus, vermin, dirt,
electromagnetic and nuclear radiation, etc., is redundant. On the other hand, some machines are meant
to be used on board ships, in jeeps, in aircraft, in remote locations without normal stateside services, etc.
In these cases, the hardware itself may be designed
to be protected against the hostile environment. The
hardening takes the form of specially built components
which, in general, cost more than those used in commercial products; therefore they are not found in offthe-shelf equipment except for the machines aimed at
the process control market (steel mills, paper mills,
refineries, etc).
It has been demonstrated many times that commercial hardware can be installed in military vehicles
so that it can be transported without damage and can
be operated in the vehicle given an appropriate enclosure. Transportability requirements are not uniform, however, and the degree of transportability
varies from machine to machine. The most powerful
machines tend to exceed the floor area of one van.
Certain general trends have improved the ability of
the industry to build transportable machines: smaller
boxes that are easier to place in a vehicle, more liberal
temperature ranges, etc. These features are evident in
the reduction of setup time for a commercial machine.
In the 1950s a week was allowed to assemble a large
computer and check out the problems that may have
occurred in the move via padded van from the factory.
In 1970, a day or two is all that is required with very
few problems introduced by the transport. When the
same machine is to be placed in a van-as has been
done in the Army CS-3 system-some additional precautions are required. Most of them are mechanical.
Stiffening of the cabinets and the movable panels in
the machines may be required to reduce the effects of
shock and vibration. The whole machine may be
mounted on shock absorbers to shield it from the environment. And a short checkout cycle may be added
to the set-up procedure after the van comes to a stop
and the machine is turned on. In general, the commercial machine is not operated while the transport is
moving (except on board ship).
The input/output devices for the commercial market

present a more severe problem in transportable systems. They are primarily mechanical devices with
sensitive alignment and close tolerances between high
speed moving parts. They do not stand up as well as
the electronic computer. It is normal for the project
manager to substitute militarized I/O devices for the
commercial products in transportable installations.
Specially designed disk and tapes have been built for
this purpose and, by virtue of the standard interface
concept, can be attached to a variety of computers. A
transportable system can consist of all off-the-sl:elf
hardware or a combination of standard processors and
special peripheral devices. Thus, it is not essential to
assume that all elements of a military system must be
hardened. If a commercial machine is the best one for
the application, it can often be installed in such a way
as to be protected from the environment.
When it comes to the third class of applications
where the environment is so hostile that special hardening is required, the commercial machines are no
longer feasible. Machines in Class III are usually very
small both physically and functionally. They are built
to fit into odd-shaped spaces. They weigh very little.
Their word sizes and instruction sets are smaller than
those offered in commercial machines. Their input and
output devices may bear no resemblance at all to the
cards, tapes, and disks found in larger information
handling systems. As an example, the computer in a
space vehicle may be used only to calculate orbital
rendezvous parameters or descent speeds and angles.
Its inputs may be from instruments in the cockpit of
the capsule; instruments used nowhere else except in
this particular space mission. Its size may be that of a
home tape recorder to permit it to fit in the astronaut's
console. Its memory may be only large enough for a
single computation; a new computation may require
reloading of the memory by radio from an earth station.
The computations it performs may be so well worked
out in advance that the magnitUdes of all the numbers
in the computations are known; therefore, there is no
need for floating point instructions in the repertoire
of the computer. The programs are probably written
and optimized in machine language so as to take as
little memory as possible; therefore, no high level
language compiler or massive operating system is
called for. All these features tend to make the general
purpose capabilities of commercial hardware and software unnecessary for the space computer. In fact, the
bulk represented by the standard features of commercial hardware is undesirable in the space computer.
On the other hand, it is essential that the space computer work when it is needed. This leads to a high
degree of redundancy in the design of the system in

Commercial Data Processing Machines in Government Applications

order to increase the reliability, availability, and failsafe characteristics of the system. Since, in the example
of the space capsule, there is no practical way to maintain or repair the computer, it is possible to design the
computer to be discarded on failure and replaced by a
spare. Obviously, the priorities for a system of this
type are quite different from those set for commercial
computers. These priorities make specialization an
asset in the third class of application where it is a penalty
in the other two classes.
On the other hand, some applications in Class II
call for the same environment as Class III even though
they require the functional capabilities of Class II
machines and programs. Examples are surface and
undersea naval applications, airborne applications or
airborne back-up for ground based systems, and long
duration manned space laboratory missions. Some of
the applicable specifications might be:

1. Dimensions - 26" X 48" X 66" for passage
through watertight hatches
2. Weight-45# per box for 2-man lift
3. Temperature and Humidity-operate in shelters
with interior temperature 60°-90°F, relative
humidity 15-95 percent, operate for limited
periods at -65° - 125°F, non-operating exposure to -80° - 160°F.
4. Other-withstand salt, fog, rain, sand and dust,
sunshine, fungus, high altitude, 5g vibration,
30g shock, vermin.

+

+

It is not cost effective to design normal commercial
hardware to withstand these extreme conditions. However, it is possible to build hardened machines to specs
that are compatible with commercial machines. This
will permit the benefits of commercial support in the
development process to be realized. It may also facilitate communication between hardened systems and
normal systems; i.e., a ground based command center
and its airborne alternate.
Commercial practice

The project manager who is convinced that commercial data processing is appropriate for his project
may find that there are some obstacles to his getting
what he needs. The practice in the industry is to withhold information on advanced developments until the
machines are fully tested and are ready for public announcement. Prior to this time, the existence of a
suitable machine may be unknown to the project
manager. His best move in these circumstances is to

149

make his needs known through an industry briefing.
Then, by agreeing to protect the proprietary rights
of the vendors, he can obtain the advanced information
for use in his decision process.
There is a tendency for government project managers
to schedule the system so that they get to install the
very first machine of a new product line. Although the
vendor does a very thorough job of factory test, the
first one or two machines off the production line are
still liable to have bugs in them. The project manager
would be better off to downgrade the glamour of the
first installation and place more weight on the stability
of the later machines in the production line.
A commercial machine is suitable for a government
system when it meets all the requirements of the
government system. However, the commercial machine
was designed for a broader market than the single
government application. It contains many features in
addition to those needed by the project. There are two
disadvantages and one advantage to this. The cost of
the unnecessary features is included in the price of the
machine. The cost is not restricted to the acquisition
price of the machine. The added features also take up
space and use up time in the operational system. This
disadvantage is offset by the fact that the commercial
machine is usually much less expensive than the special
purpose alternative. In some critically timed real-time
systems, the added features must be removed. This
problem ties in to the second disadvantage. The more
features a machine has, the more complex it is and the
more things that can go wrong with it. The effects of
complexity are controlled by good system development
procedures but their impact on operations and maintenance cannot be ignored. The advantage of the added
features found on commercial machines is that the
programmers can usually find ways to use the features
to improve the system software.
There are other features that are generally useful
in government systems which are seldom found in commercial machines. The average business data processing
application does not call for them. An example is the
ability to remove a unit of the computer for service
without interrupting the computer operation. The
ability to reconfigure around -a failed unit has been
provided with some commercial systems but they are
designed to stop while the unit is removed and then
restart with some manual intervention to describe
the new configuration. In systems with enough redundant elements to permit continuous operation there
is no reason to stop the computer to remove a unit;
however, special modifications may be needed to
prevent the computer from automatically stopping
under these conditions. The modifications essentially

150

Spring Joint Computer Conference, 1972

place a switch in the hardware that isolates the failed
unit electronically the same way a switch in the software permits the logical rearrangement of boxes.
When the project manager recognizes the need for
a modification to the commercial machine there is
generally no great problem in designing and installing
the change. However, the industry business practice
may increase the cost impact of that change. The
normal maintenance of commercial hardware and
software has been designed to give maximum service
at minimum cost. This is achieved by standardizing
the training and diagnostic aids given the se~vice
personnel. A corollary of this approach is that the
serviceman is not well equipped to understand user
modifications to the hardware or software; therefore,
his service commitment may be modified or even
voided by certain types of modifications. The protection against loss of service is simple; the project manager
and the service supplier should mutually agree to a
service agreement which spells out the extent of the
service commitment and alerts the manager in advance
of the exposure he has. The reverse of this situation
may have similar impact. The vendor of commercial
hardware normally makes engineering changes to the
machines over a period of years. The purpose of the
changes is to correct minor problems, facilitate service,
reduce failure rates, etc. The changes are transparent
to the user except in cases where the user has modified
the hardware. The project manager must be prepared
to trade off the benefits attributed to the engineering
change against the value of his modification.
CHARACTERISTICS OF THE DEVELOPMENT
PROCESS
The systems included in the second class above are
dominated by large real-time information handling
systems-SAGE, Air Traffic Control, SAFEGUARD,
TACFIRE, Naval Tactical Data System, Marine
Tactical Data System, Apollo, Orbiting Astronomical
Observatory, National Military Command System,
Intelligence Data Handling System, etc. The consequence of size is complexity. There are so many interactions among the elements of a large system that no
one man has the ability to comprehend and manage
the total entity. As a consequence, the system is organized into subsystems and smaller components to
limit the span of control of each manager to a scope
that he can handle. The step by step delineation of
system components changes the focus of attention from
the system itself to the parts of the system. As a result,
the structural interactions which define the system
may not get enough attention to ensure their integrity.

Project control
The concept of "change" is basic to system development. It is unrealistic for a system manager to assume
that the objectives established at the outset of a project
will be unaffected by changes in the environment or in
the detailed plans fo~' implementing a given function.
Rather than be crippled by an inflexible plan, the
manager establishes procedures which permit the
formal modification of his baseline specification by
changes which are agreed to by all affected parties.
Such a set of procedures protects the system against
arbitrary changes but permits necessary changes. In
order to be effective, the change control process must
be able to determine the interactions of each proposed
change with the rest of the system.
The government calls the control procedure "configuration management" and provides vendors with
guidelines for describing the work breakdown and
keeping track of the base specification. For a large
system, it takes about ten years to reach the operational phase of the cycle. Lots of things change during
that period which can upset earlier commitments.
Brigadier General W. R. Reed, U.S. Army, suggested
how serious the problem can be when, after eight years
of a study and design effort, it was realized that changes
had occurred in computer technology that had a profound impact on the environment being studied. In
fact, he estimated that computers improved by a factor
of ten every 3.8* years. Such an order of magnitude
improvement required a new definition of the environment in which the computers were to be used. Gen.
Reed was talking about the Army tactical fire control
system, TACFIRE, which in eight years had been
obsoleted twice before it ever reached the acquisition
stage until 1968 by which time its specs were again
being overtaken by new technology. The guideline
implied by this situation is that computer specs should
not be frozen early in the system definitjon stage since
they will probably have to be redone later.
Postponing the actual computer decision does not
impede the progress of the system. The data processing
subsystem can be described in terms of the functional
and performance characteristics desired. These characteristics can then be incorporated into a model of
the subsystem which can be exercised to evaluate the
design concept and predict the performance of the
actual hardware when it is selected according to the

* As compared to my estimate of 5 years. The rate of computer
improvements is hard to determine but remarks by Lowell D.
Amdahl, president of COMPATA, Inc., at the June 1970 meeting
of the IEEE computer group indicated that Gen. Reed's figures
have not changed substantially since 1962.

Commercial Data Processing Machines in Government Applications

approved design. The model is a computer program
which can be run on a standard commercial machine.
(This technique, used with great success in the Apollo
program, has added value when the computer used to
exercise the model is compatible with the computer
ultimately procured for the system. When this is the
case, parts of the model may be reusable in the ultimate
system.)
The model is a design aid and may be thrown away
after the total system goes into operation. Preferably
it is retained as the basis for continuing improvement of
the operational systems. Nevertheless, it is never more
than a part of the scaffolding required to support the
system builders. Other parts of the scaffolding for a
data processing subsystem are test programs and data
generators; input/output simulators; computer services
for running engineering problems and debugging programs; compilers, sorts, and other programs to prepare
system programs for execution; controlled libraries
to separate work in process from released work; project
control administration and analysis (as in PERT);
and many other activities both technical and managerial. The optimum environment-from the standpoint
of pro}ect control, training, cost, and testing-is one in
which the same computer family is used for all functions
of control, support, and ultimate operations. The advantage of sticking with one computer family throughout
the life of the project is that predictable results can be
achieved on schedule without the distractions posed
by a new, incompatible machine.
System development guidelines

Various guidelines are generally accepted as constructive when dealing with large systems. One such guideline attempts to strengthen the system structure without tying the hands of the component developers. It
calls for the design to be done from the top down. That
means that the structure of each level of the system is
designed before the details of the next lower level are
developed. Top down design is an effective device for
identifying and controlling the interfaces within the
system. In addition, this approach minimizes the constraints on the component designers because it provides
them with a set of functional and performance objectives for their area of responsibility without telling
them how to build their specific "black box". Since
each element of the system is simply a "black box" to
the level above it, a different black box with the same
external characteristics can be substituted for the
original element without making any other changes
to the system. This is one reason why it is feasible to
use a simulated environment during the development

151

of a system; simulated black boxes are used until the
real thing is available. Such design flexibility is essential during the design stages of the system specifications.

Phased implementation

Aware of the need for adapting to changes in the
system design, the system requirements, and the system environment, experienced system managers lay
out a phasing plan which will reach the final system
in useful steps. They start with an initial operating
capability (IOC) to get a minimal capability for meeting operational requirements and to provide an environment in which to test out the design concepts for
the operational system. Only by installing an IOC can
the designers evaluate their ideas against realistic
man-machine tests and modify the final system to
overcome the weaknesses observed in the lOCo The
existence of the IOC often leads to more pervasive
changes to the system design as well. Considering the
long lead time for most large systems, the original requirements statement is often out of date when the
IOC is installed. Top management does not realize this
until they try to use the lOCo Then they observe that
some of the things they asked for are not appropriate
to the problems they face today. In addition, for the
first time they have an opportunity to observe how the
data processing system can contribute to their decision
making functions. This leads them over a period of
time to restate the functions assigned to the computer
so as to take advantage of its speed and flexibility. Invariably, their new definitions of the computer workload place more work on the machine and less on the
user. Therefore, it is normal for the final operational
system to represent an upward growth from the lOCo
Recognizing that the IOC is a test vehicle, not the
ultimate system, it should be installed at the least
expense but in a form that is easily modified. The
best way to minimize the cost of the IOC is to acquire
a commercial computer. In this situation, the original
design and development costs have been borne by the
vendor and are distributed equitably among all the
users of that computer. A special purpose machine in
the IOC passes all the design and development \costs
as well as the manufacturing cost along to the single
buyer.
The decision to select off-the-shelf hardware for a
government system affects the balance of the system
plan. The timing of the decision to use commercial
data processing equipment should be made in the
system definition phase of the development cycle. It
should occur after the overall system design and all

152

Spring Joint Computer Conference, 1972

of the subsystem functions have been defined and
before the subsystem component specifications are
complete. Having decided to use commercial technology, the actual selection of a machine should be
deferred until the start of the acquisition phase to
take advantage of the latest available technology. As
stated earlier, the system specifications can be written
around function and performance objectives rather
that detailed characteristics of the data processor so
that the delayed procurement does not slow up the
design process. By selecting a machine that is part of
a compatible family of computers, the manager can
allow for future growth requirements. To achieve the
benefits stated earlier, the manager must verify that
the compatible family includes basic software packages,
that the maximum capacity machine in the family is
large enough to permit substantial vertical growth, and
that the family has a published standard interface.

SUMMARY AND CONCLUSION
Most of the performance and reliability specificat~ons
for military and federal civilian applications can be
handled by one or more machines available off-theshelf. With minor modifications to their functional
capability, addition of special I/O boxes, and installation in suitable enclosures, the commercial machines
can generally fit all the requirements of ground-based
application areas. In fact, because of the family characteristics of many commercial machines, they outperform the typical special purpose machine with
respect to growth capability and cost effectiveness.
The delivery schedules for commercial machines are
sUbstantially more reliable than those for specially
engineered equipment. Although the first machine
delivery off the production line in commercial practice
may vary from schedule by several months, subsequent
deliveries are sufficiently certain to permit vendors to
accept penalty clauses for late delivery as a normal
business practice. By comparison, special machines
have been as much as three years late with delays of
one year from the projected schedule occurring with
some frequency. The reason for the delays is seldom
poor workmanship on the part of the builder. Most
of the time it is due to the fact that changes to the
machine specs occur during the machine development
cycle which cause rework and rescheduling. The commercial machines have been fully specified before they
are announced and before delivery commitments are
accepted; therefore, the specs are not subject to change
in the same way. The price of commercial machines is
more stable than the price of the typical cost-plus

special machine; again, because of the different impact
of product changes. More important to the integrity of
the application, commercial machines have already
passed stringent product tests before they are announced for sale. The project manager can have very
high confidence that a machine that meets his requirements on paper will perform properly in fact. He cannot have the same level of confidence in a special purpose machine since he must commit himself to its
design specs without any assurance that the machine
so specified can be built and, if buildable, will perform
exactly as planned. His ability to predict these things
at procurement time simply falls far short of his ability
to predict-and measure-the same things on off-theshelf systems. At the same time, he is able to compare
his requirements to the offerings of several competitive
vendors in the commercial market in order to select
the least expensive system for his project.
Risk reduction is a key advantage in the eyes of the
project manager. In addition, the advantages in the
development process are significant. The fact that a
test cell can be established for the engineers and a
separate support machine can be set up for the software
team contributes to shortening the system schedule.
The testing itself becomes less risky. Because the computer and its vendor software have been extensively
tested before shipment, the application programmers
can simplify their test detective work by assuming
that the commercial data processing subsystem are
error-free; therefore, errors must lie in the application
programs or test cases. The assumption will not always
be valid but the order it imposes on the error analysis
procedure will speed up the process. In particular, the
assumption that the various programs in the system
have been fully debugged directs the attention of the
test team to the interactions among the components
where it belongs and away from the internal workings
of each program unit.
Since systems are built and used by people, a major
effort in any system development involves the training
of the development team and the operational and
maintenance teams. The earlier the training can start
the better as long as the material taught is truly representative of the final operational system. When using
commercial machines, the knowledge that the machine
and its software are well defined permits training in
this area to begin immediately after the procurement
decision. Effective training can be procured from a
variety of sources without the need for structuring a
permanent educational office in the project. Moreover, the computer time needed for the trainees can
be obtained on the vendor's machine (which, by
definition, will be compatible with the project machine)

Commercial Data Processing Machines in Government Applications

without interfering with the test activities on the
project machines.
The project manager concerned with meeting a set
of operational objectives at minimum cost on a firm
schedule must minimize the risk associated with each
element of his system. By specifying commercial data
processing subsystems he can satisfy his functional and
performance needs in the large class of command and
control applications as he has traditionally done in

153

administrative applications. He will accomplish this
with less cost, equal or higher performance in both
the development cycle and in the operational installations, simpler logistics, and with much less risk of
slippage or overrun. A general guideline to follow,
contrary to past practice, would be that commercial
data processing should be used in all cases except those
in lvhich there is a specific obstacle to prevent them from
doing the job.

Programming language efficiency
in real-time software systems
by J. O. HENRIKSEN
University of Michigan
Ann Arbor, Michigan

and
R. E. MERWIN
SAFEGUARD System Office of U. S. Army
Arlington, Virginia

implementation language." The systems implementation language in effect attempts to represent a range on
the continuum of programming languages. It permits
the programmer to readily access and exploit hardware
features, but allows him to perform the bulk of his coding by utilizing a less cumbersome higher level language.
There are several attempts to analyze programming
languages described in the literature. 1 ,2,3 In the sections
which follow, an investigation is described in which representative programs from a phased-array radar realtime software system are coded in selected programming
languages. Performance measures are described, results
tabulated, and conclusions are drawn on the basis of
these results. This investigation was carried out under
the sponsorship of the SAFEGUARD System Office
of the U.S. Army by Brown University,4 the System
Development Corporation,5 University of Michigan, 6
and the Westinghouse Corporation. 7

INTRODUCTION
Early in the development cycle of a real-time software
system, the designer must select one or more programming languages to be used in writing the system.
As shown in Figure 1, there is available today a continuum of programming languages ranging from
"high-level" languages like PL/I to "low-level"
traditional assembly languages.
At the present time, high-level languages are widely
used in conventional scientific and commerical software
production, while low-level languages are widely used
in the development of real-time systems. The wide
acceptance of high-level languages in conventional
applications may be attributed to favorable costperformance tradeoff. Given an application whose
data and program structures can in a reasonable
straightforward manner be represented in a high-level
language, use of the high-level language will result
in conservation of human resources at the expense of
machine resources. Real-time systems represent a class
of applications where machine performance becomes a
critical resource. In this case, factors other than fiscal
cost of the machine resource become dominant. As a
consequence, the program and data structure of a realtime system must be hardware motivated and any programming language used to implement such systems
must allow the programmer to fully exploit the characteristics of the hardware. Since the design of program
and data structure is hardware-motivated, artificial software restrictions, in the form of language limitations,
are unacceptable. Such considerations have given rise to
a new type of programming language, called "systems

MODUS OPERANDI
Three exis ting programs developed to con trol the
phased array radar used in the SAFEGUARD AntiBallistic lVIissile System test program on K wajalein
Atoll were selected as typical examples of real-time
software. A functional description including flow charts
and data sets was prepared for each of these programs
based upon the actual assembly language code for the
equivalent function produced for the SAFEGUARD
data processor. From the supplied functional descriptions, the study participants constructed programs in
various languages and ran standard sets of test data

155

156

Spring Joint Computer Conference, 1972

LOW-LEVEL
LANGUAGES

HIGH-LEVEL
LANGUAGES

FORTRAN

PL/l

PL/360

(Exte nded Assem bier
with expression
capability)

Assembly
Language

Figure I-Continuum of programming languages

for performance measurements. Five languages; PL/1,
FORTRAN-IV-H, JOVIAL, Brown University's Language for System Development (LSD), and IBM 360
basic assembly language were compared in performance
runs on IBM 360-67 hardware. FORTRAN-V and
SLEUTH assembly language were compared on the
UNIVAC-1108. Of the languages compared, PL/I,
FORTRAN-IV, and V are selected as representative
high-level languages, JOVIAL as a precursor of systems
implementation languages, LSD as systems implementation language currently being developed, and
IBM 360 basic assembly language as a baseline for
performance measurement.
ALGORITHM DESCRIPTIONS

GETTASK
The first· algorithm modelled, G ETTASK, is a task
dispatcher for a single task list multi-processor. In the
system studies, tasks are related in PERT-like networks
such as the one shown in Figure 2.
In such a network, the completion of Task #1 allows
the simultaneous execution (if 3 processors are available) of Tasks 2, 3, and 4. In general, a given task may
have any number of predecessor tasks which must be
completed prior to its running, and a task may have an
arbitrary number of successors. In the case where more
than one task is eligible to be run at the same time, a
priority scheme is used to assign a task to a processor.
The implementation of such a precedence network is
achieved by use of absolute enablement bits (AEBs)
and conditional enablement bits (CEBs). Associated
with each task is a CEB word, an AEB, and a successor
list. Each element in a successor list contains a pointer
to another task's CEB word and a mask to be logically
ORed with the CEB word. In the example above, the
successor list for Task #1 would contain pointers to
Tasks #2, #3, and #4. Each CEB in a CEB word corresponds to a unique precedence condition. For example,
the CEB word for Task #5 in the above network would

have one bit to be set upon completion of Task #2 and
another upon completion of Task #3. Each time the
logical OR is performed, a check is made to see if all
CEBs are set to 1, and if so, the AEB for the corresponding task is set to 1, indicating that the task is
ready for dispatching. The system is general enough
to allow enablement of tasks as a funct.ion of time or
system conditions by allowing certain dedicated bits
to be set only by the operating system.

EXLIGEN
The second algorithm modelled, EXLIGEN, is a
portion of a radar control program execution list
generator which converts requests for radar transmissions, according to time and type, into a fast access
execution list format for later processing. Scheduling of
transmissions is done on a cyclic basis: a request made
in cycle n is handled by the scheduler in cycle n + 1 and
actually transmitted in cycle n+2. A master "menu" of
allowable transmissions is available to several subsystems within the radar control program, and it is possible
that these subsystems can make conflicting transmission
requests. The list generation algorithm is carried out
in two passes: in pass 1, a scan is made of all requests
in order of increasing time, and requests are consolidated according to request type; and in pass 2, a list
is constructed and ordered by priority of request type
with certain requests of the same type consolidated into
single list entries.

UPDATE
The third algorithm modelled, UPDATE, is a portion
of a Kalman filter algorithm used to filter radar return
data. On the basis of signal-to-noise ratio in the radar
returns, weights are calculated to be applied to the
current radar observations, and using these weights, a

Figure 2-Task precedence lattice

Programming Language Efficiency

state vector for an object in track is updated. The
algorithm is completely described by recursively applied
equations, which are amenable to solution in any
FORTRAN-like language.

TABLE I-University of Michigan Comparative Performance
Data for FORTRAN IV-H and PL/1
Versus Assembly Language on
IBM 360 MOD 67-2

Assembly FORTRANLanguage
IV-H

SUMMARY OF RESULTS
The results of the individual comparative studies
submitted by the four participants are shown below. The
four performance cirteria chosen were, number of
source statements, number of object instructions,
number of storage words required to contain the
programs and data, and program running times.
Comparative number of source statements reflect
ease of expression in the two languages, i.e., a program
that requires more source statements in one language
than another is less naturally expressed in this language. Comparative numbers of object instructions
are a partial measure of translator efficiency but do not
reveal the impact of run-time routines called by the
translator. Comparative object code storage requirements of language translators reflecting storage efficiency represents usage of a critical machine resource in
most real-time applications. Specific comments on these
criteria are included in the discussion of each study
results.

157

PL/I
F-5

GETTASK
(Strict Data Structure)
Number of Source
Statements
Number of Object
(nstructions (words)
Storage size (Bytes)
CPU Run Time
(milliseconds)

79

50

48

75

251

327

314
2.84

444
6.74

183
0.70

GETTASK (Redesigned
Data Structure)
Number of Source
Statements
Number of Object
Instructions
Storage Size
CPU Run Time

67

39

48

65

170

292

83
0.49

244
1.78

413
3.14

259

122

133

228

477

1100

305
1.83

655
4.98

1205
19.20

228

126

130

200

405

783

276
1.42

557
2.86

EXLIGEN
(Strict Data Structure)

The University of Michigan

The IVlichigan study was carried out on an IBM
360jl\lOD67-2 computer with 1.51\1 bytes of storage
and compared FORTRAN, PLjI, and IBlVI 360 basic
assembly language. In addition to coding the three
algorithms with a "strict" interpretation of the original
data structure, Michigan investigators carried out a
redesign of the data structures used in GETTASK and
EXLIGEN. The revised implementations, using redesigned data structures, were functionally equivalent
to the original descriptions but exhibit enhanced
translator performance.
Results, as presented in Table I, show a marked
superiority of assembly language programs on the
IBM 360. On the average for all cases tested, FORTRAN programs ran 2.7 times as long, and PLjI
programs 7.4 times as long, as the corresponding
assembly language programs. Results similar to this
were noted in a benchmark study 8 which compared
assembly language and FORTRAN on several large
current systems. While the PLjI language offers a
great deal of generality in the range of problems and
data structures it can handle, it is at the expense of
performance. Because of the wide range of the language,

Number of Source
Statements
N umber of Object
Instructions
Storage Size
CPU Run Time
EXLIGEN (Redesigned
Data Structure)
Number of Source
Statements
Number of Object
Instructions
Storage Size
CPU Run Time

1074
7.03

UPDATE
(Strict Data Structure)
Number of Source
Statements
Number of Object
Instructions
Storage Size
CPU Run Time

88

27

28

89

134

351

91
0.74

194
1.39

447
2.32

158

Spring Joint Computer Conference, 1972

TABLE II-System Development Corporation Comparative Performance Data for JOVIAL vs Assembly Language on
IBM 360 MOD 67 and Comparative Performance of JOVIAL on UNIVAC 1108 and CDC 3800 and IBM 360 MOD 67
JOVIAL
Assembly Language
IBM 360

IBM 360

UNIVAC 1108

CDC 3800

79
75
183
0.70

97*
198
399
2.02

77**
119
159***
3.4

73**
158
154****
2.1

233
647
1146
4.47

232
449
566
2.0

454
566
2.72

GETTASK (Strict Data Structure)
Number of Source Statements
Number of Ob,:ect Instructions
Storage Size (32 bit words)
CPU Run Time (ms)
EXLIGEN (Strict Data Structure)
Number of Source Statements
N umber of Object Instructions
Storage Size
CPU Run Time

259

228
305
1.83

228

UPDATE (Strict Data Structure)
N umber of Source Statements
Number of Object Instructions
Storage Size
CPU Run Time
* Includes 17 direct statements
** Includes 5 direct statements
*** 36 bit words
**** 48 bit words

88

41
133

89
91
0.74

producing an optimizing compiler is difficult, and the
language has not had a long enough history to reach the
state of development of compilers for other languages.
One of the big disadvantages of FORTRAN and even
PL/I is that the languages do not have syntactic forms
which correspond directly to powerful hardware
capabilities, i.e., the hardware is too highly masked
by the use of these languages. For FORTRAN, the
narrow range of syntactic forms appears to be the
biggest weakness. On the whole, for the problems
studied, FORTRAN appeared to produce reasonably
efficient code for the statements allowed in the language,
but the range of available statements was clearly
restrictive to the programmer. The best performance
of FORTRAN and PL/I was on the algebraic UPDATE
program, which reflects that UPDATE was the most
naturally expressed (in these languages) of the three
problems.
The improvements in performance obtained by redesign of the data structures are interesting to note.
For all languages, data structure redesign yielded performance enhancement, but the improvements obtained
were substantially greater for FORTRAN and PL/I.
This simply illustrates the fact that performance III

171
1.79

41
96
40
0.78

41
102
40
1.52

high-level languages suffers as program and data
organizations become more and more removed from
basic structures in the languages. Since program and
data organization in real-time systems are often dictated
by hardware organization and data formats, applicability of high-level languages may be relatively low.
SDC

The SDC Study was performed principally on an
IBM 360/lVIOD67 and additionally on the UNIVAC
1108 and CDC 3800 using the JOVIAL language. The
goals of this study were to exhibit performance for
another language on IBM 360 equipment and to explore the ease of transferability of software between
dissimilar machines. The JOVIAL language exhibits a
great deal of flexibility in definitional capabilities for
data structures. It represents a substantial improvement over FORTRAN in this respect, but is not
quite as wide ranging as PL/I. The JOVIAL language
also allows a programmer to insert assembly language
instructions into a program in order to utilize the hardware features he may desire. JOVIAL does not have (in

Programming Language Efficiency

159

TABLE III-Brown University
Comparative Performance Data for LSD vs FORTRAN IV, PLII and Assembly Language on IBM 360 MOD 67-1

LSD
Assembly Language FORTRAN IV

PLjI
P-5

I

48
327
444
6.74

50
159
199
2.2

II

GETTASK (Strict Data Structure)
N umber of Source Statements
Number of Instructions
Storage Size (Bytes)
CPU Run Time (ms)

79
75
183
0.70

50
251
311
2.84

259
228
305
1.83

122
477
655
4.98

88
89
91
0.74

27
134
194
1.39

EXLIGEN (Strict Data Structure)
Number of Source Statements
N umber of Instructions
Storage Size
CPU Run Time

133
1100
1205
19.2

126
440
677

UPDATE
Number of Source Statements
N umber of Instructions
Storage Size
CPU Run Time

the IBlYI 360 version) optimization features which are
as extensive as those of FORTRAN-IV-H, but produces "reasonable" code, certainly much better than
that of PL/I. Performance of IBM 360 JOVIAL is
given in Table II. The numbers shown may be meaningfully compared with the University of Michigan numbers for the strict data structures. As one might expect,
JOVIAL performed better than FORTRAN-IV-H,
much better than PL/I, and worse than IBM 360
basic assembly language in the GETTASK and
EXLIGEN problems. In the UPDATE problem,
however, the optimizing features of FORTRAN-IV-H
enabled it to outperform JOVIAL.
The algorithms were executed on the UNIVAC
1108 and CDC 3800 by simply changing the data
definition statements to account for different word
sizes. Additionally, driver programs had to be altered
because of differences in system input-output and timer
routines. The significant fact is that with the exception
of "direct" assembly language statements in GETTASK, no executable statements in the programs required change. The framework for carrying out such a
transfer to a different machine is relatively easily used,
as illustrated by the fact that the CDC 3800 conversion
was done as a minimal effort by a programmer unfamiliar with the original IBM 360 JOVIAL version.

28
351
447
2.32

31
159
133
0.78

29
151
120
0.78

Brown University

The LSD language is being developed by Brown
University as a systems programming language for the
IB1VI 360. LSD is syntactically similar to PL/I, but
not nearly as broad in scope. I t is specifically tied to the
organization of the IBlYI 360 hardware, for example, the
16 general purpose registers of the IBM 360 can be
directly referenced and manipulated in LSD statements.
The design philosophy of LSD can be summarized by
saying that it attempts to make the hardware readily
accessible to the programmer while retaining the ease
of usage of a high-level language. In order to produce
optimal code, the programmer must be thoroughly
familiar with IBM 360hardware, as only the simplest
forms of optimization are performed by the compiler.
The Brown University investigators used University
of Michigan implementations of the three programs as a
starting point. PL/I statements were then transliterated into LSD statements by means of an automatic
transliteration program. Results for compilation of the
resultant LSD source code are shown in Table III under
the column labeled LSD-I. The data generated for
EXLIGEN by LSD could not be verified and should be
regarded as ten tatine. Next, the investigators carried
out an optimization of the LSD code at the source

160

Spring Joint Computer Conference, 1972

TABLE IV-Westinghouse
Comparative Performance Data for FORTRAN V and SLEUTH
(Assembly Language) on UNIVAC 1108

SLEUTH

FORTRAN V

GETTASK
Number of Source Statements
N umber of Object Instructions
Storage Size (in 36 bit words)
CPU Run Time (milliseconds)

212

50
192
256

173
205
1.2

IllS

1.2

IllS

746
828
2.6

IllS

EXLIGEN
N umber of Source Statements
N umber of Object Instructions
Storage Size
CPU Run Time

673
645
684
2.6

177
IllS

UPDATE
N umber of Source Statements
Number of Object Instructions
Storage Size
CPU Run Time

228
212
227

35
181
212
.53

IllS

.35

IllS

level for the UPDATE program, taking advantages of
facilities not provided by PL/I. The results are shown
in column labelled LSD-II. University of lVlichigan
FORTRAN-IV and PL/I results are included for
purpose of comparison. Timings shown for Brown
University results have been adjusted upward by 10
percent from the measured. values on an IBM 360/
MOD67I-1 in order to make them directly comparable
to the timings obtained on the University of Michigan
IBM 360/MOD67-2 (1.5M Bytes Storage).
Westinghouse

The Westinghouse study was performed on the
UNIVAC 1108 and compared with the SLEUTH
assembly language with FORTRAN V, UNIVAC's
highly-touted optimizing FORTRAN compiler. Two
programmers were employed, one coding only in
FORTRAN and the other only in SLEUTH. They
designed, together with the project supervisor, compatible data structures so that a single driver program
could drive either the FORTRAN V or SLEUTH
versions of a particular algorithm. The data structures
were amenable to problem solution on the UNIVAC
1108 and were not the same as data structures originally
developed for the SAFEGUARD data processor.
On the whole, the performance of FORTRAN V

as shown in Table IV was of surprisingly high quality.
The design of compatible data structures for SLEUTH
and FORTRAN V appears to have been slightly
slanted toward FORTRAN, i.e., to force the SLEUTH
programmer to use a data structure that can also be
used by FORTRAN (especially in the areas of manipulating data pointers) is somewhat of a handicap. For the
UPDATE algorithm, which was purely algebraic in
nature, relatively good performance was expected from
FORTRAN. The algorithm was a relatively small
piece of code and was simple enough to be easily handled
by a compiler, i.e., assembly code "tricks" could not be
employed to any significant advantage. In actual performance, the FORTRAN version ran significantly
better than the SLEUTH version. If the SLEUTH
version were to be recoded using the FORTRAN
version as a guide, it is probable that it could be made
to perform better than the FORTRAN version. The
significant fact is that in the time frame allotted to
this study, FORTRAN actually produced a better
program, reflecting that in certain cases a cleverly
written compiler can actually surpass human
performance.
CONCLUSIONS
The following conclusions relative to the performance
in terms of efficient object code production and CPU
running times for programming languages, i.e., highlevel or assembly, are drawn from the results summarized above.
(a) If CPU running time and storage utilization are
the primary criteria for evaluation, assembly
language coding is distinctly superior to highlevel languages available today.
(b) System's Implementation Languages, which
appear to offer the advantages of high-level
languages with respect to reducing software
development costs, also produce object code
with efficiency approaching that of assembly
languages. This performance improvement,
largely achieved by allowing programmers
to take advantage of system hardware features,
implies a machine dependence of such languages
and loss of transferabili ty of programs written
in these languages from one computer architecture to another.
(c) Careful design of program data structures can
greatly improve the performance of present-day
higher-level languages in production of efficient
object code.

Programming Language Efficiency

(d) The production costs associated with high-level
languages are lower, up to a threshold at which
specific desired manipulations cannot easily be
made in the language.
(e) Transferability is easily achieved in high-level
languages, provided that direct usage of machine
dependent characteristics is carefully controlled.
(f) Data structures designed for a particular
machine architecture must be modified if any
kind of efficiency is desired in transferral to
another machine architecture.
(g) The "ideal" high-level language must allow
flexibility in data definition capabilities as
JOVIAL does and FORTRAN IV does not, but
be realistic in scope, as PLjI is not.

ACKNOWLEDGMENTS
The programming language efficiency study was carried
out by four groups under the overall guidance of the
authors. The study directors were Prof. B. Arden,
University of l\1ichigan; Mr. P. Waszkiewicz, Westinghouse; }\tIr. R. Knight, SDC and Prof. A. Van Dam,
Brown University. The coding was done by Mr. J.
Hamilton, University of Michigan; Messrs. G. H.
Rouillard and R. L. Specht, Westinghouse; Mr. R.

161

Brunstrum, SDC and Messrs. R. D. Bergeron, J. D.
Gannon and J. V. Guttag, Brown University.
REFERENCES
1 F J CORBATO
PL/l as a tooljor system programming
Datamation May 1969
2 H HESS C MARTIN
A tactical command and control subset of P L /1
Datamation April 1970
3 R RUBEY
A comparative evaluation of PL/l
Datamation December 1968
4 A VANDAM R D BERGERON J D GANNON
J V GUTTAG
Programming language comparison study
Brown University Report
5 R L BRUNSTRUM
A study of JOVIAL programming language effectiveness for
SAFEGUARD programs
SDC TM 4553/000/000
6 BARDEN J A HAMILTON
Study of programming language effectiveness
University of Michigan Report #0322-1-F
7 P WASZKIEWICZ
BMD object code efficiency study
Final Report for Contract DAHC 60-70-C-048 dated 20
March 1970 Westinghouse Electric Corp
8 B N DICKMAN
BTL Private Communication

A review of
recursive filtering algorithms
by BERNARD FRIEDLAND
The Singer Company
Little Falls, New Jersey

of each other and of Uk and Vk for all k~n. The optimum
estimate xn of X n, given Yn, Yn-I, ... can be expressed by
means of the recursion equations

INTRODUCTION
The recursive filtering theory introduced scarcely a
decade ago by Kalman1,2 and Kalman and Bucy3 has
been widely hailed as a major development in data
processing, perhaps as important as the work of Weiner4
on linear filtering.
The introduction of Kalman's filtering theory could
not have come at a more propitious time. The theory
was expressed in the vector-matrix notation which had
only recently been introduced to control engineers, and
problems to which the theory was applicable were
known to many investigators. Perhaps the most important reason for the almost immediate reception of the
theory is that it is expressed essentially in the form of a
computer program-in other words, it is naturally
suited to implementation on a high-speed digital
computer. Digital-computer implementation of earlier
filtering and smoothing algorithms, on the other hand,
did not seem to be very promising.
The fundamental result of Kalman's first papers can
be stated fairly concisely: consider the discrete-time
dynamic process evolving according to the "transition
equation"

(1.3)
(1.4)

where

in which (') denotes matrix transposition,
Qn

is the covariance matrix of the excitation
noise Un, i.e.,

and

Rn is the covariance matrix of the observation
nOIse.

(1.1)

The recursive nature of the Kalman filtering algorithm
and its immediate translation into a computer program
is illustrated in the flow chart of Figure la.
The reader may have noticed that the sense in which
the estimate, computed by the algorithm defined by
(1.3)-(1.6), is optimum has not yet been defined. This
omission is intentional, because, quite remarkably, the
estimate is optimum in every reasonable sense: it is the
least-squares estimate, the minimum-variance estimate,
and a maximum-likelihood estimate. It is also the
conditional mean given the observation data, i.e.,

where
is the "state vector" of the process at the nth
instant of observation
Un
is a vector of random excitations
cI>n is the (known) "transition matrix"
r n is a known matrix
Xn

Suppose that noisy observations Yn of the state are made
in accordance with
(1.2)
and, further, that

Un

and

Vn

are gaussian, independent

The other quantities in (1.3)-(1.7) also have statistical
163

164

Spring Joint Computer Conference, 1972

significance, namely:
~n=E[Xn

I Yn-l, Yn-2,

INITIAL CONDITIONS

20 , ~O

,

_I

COMPUTE TRANSITION MATRIX cPn -1 ;
EXTRAPOLATE STATE TO NEXT OBSERVATION
In= f(i n_ 11

,

TIME·UPDATE COVARIANCE MATRIX
1\

'n=cPn-1 Pn-19~-1 +111-1 Qn-1rn'-1

,
I

COMPUTE SENSITIVITY MATRIX Hn;
COMPUTE EXPECTED OBSERVATION
Yn=h(ln1

,
,

... J, conditional mean of Xn,
prior to observation Yn

Pn= E[ (xn-xn) (Xn -Xn) 'J, conditional a posteriori
covariance matrix
Pn=E[(Xn-~n) (Xn-~n)'J, conditional

a priori
covariance matrix

It is noted that the covariance matrices Pnand Pn
and hence the gain matrices Kn are independent of the
observation data. Hence the latter can be computed
off-line and stored for on-line implementation of (1.3)
as indicated in the flow chart of Figure 1b. When Un
and Vn are correlated, Kalman's recursive filtering
algorithm is somewhat more complicated and uses the
covariance matrix Cn=E[unv n']' The more general
algorithm is given in References 1 and 2.

INITIAL CONDITIONS

20 , ~O

COMPUTE GAIN MATRIX
- '"
I
,.
I
]-1
Kn-PnHnlHn nHn+Rn

/

_I

-t

""

READ DB::RYATION /

1\

xn=cPn-1 xn-1

,

COMPUTE EXPECTED OBSERVATION
Yn=Hnxn

COMPUTE RESIDUAL

,

,
,
,
,

EXTRAPOLATE STATE TO NEXT OBSERVATION

fn=Yn-Yn

/

REAO OB::RYATION/

CORRECT STATE ESTIMATE
'X n-xn
-- +K nf n

~

COMPUTE RESIDUAL
fn=Yn-Yn

NO

RESIDUAL Iriln is needed in two places: to
update the state estimate via (1.4) and to update the
covariance matrix via (1.6). It is worth noting, however, that the transition matrix is not needed to update
the state estimate. Instead the differential equation
(2.16) can be integrated over the interval [tn, tn+lJ
with x(t n) =Xn to obtain x(t n +1 ) =Xn +l). This additional
computation may be justified when it is believed that
the evaluation of the transition matrix may be inaccurate, because inaccuracies in the transition matrix
in updating the covariance matrix (1.5) are far less
serious than errors in the transition matrix used to
evaluate the estimate of the state. The former type of
error will result in using a somewhat erroneous gain
matrix K n , but the latter will result in a direct error in
the estimate of the state.
When random excitation is present on the dynamics,
a variety of theoretical problems arise the treatment of
which entails sophisticated mathematical concepts.
Jazwinski's book 6 contains a very 'well written account
of the relevant mathematical techniques. The major
difficulty arises because the continuous time analog of
the random excitation Vn is white noise which has very
disagreeable mathematical properties. Consider the
effect of adding white noise to the process (2.16), i.e.,
(2.18)

x=A (t)x+B(tH

with ~ being white noise having a known spectral
density matrix. If ~ were nonrandom, the solution to
(2.18) would be

(2.19)
Since Ht) is white noise, hmvever, the integral in (2.19)
must be interpreted in a stochastic sense. In accordance
with standard theory, the integral

with observations taken at discrete-times

is a random variable, uncorrelated with Vk,
zero mean and covariance matrix:

The solution to (2.16) can be expressed by
x (t n+1 ) = cI> (tn+l, tn) x (t n)

where cI>(tn+l, tn) is the transition matrix, which is the
solution at time tn+l to the matrix differential equation
~=A(t)cI>

(2.17)

with cI>(tn) =1, the identity matrix. Obviously this
transition matrix is used in place of cI>n, and the earlier
discrete-time results are directly applicable.

k~n

having

(2.20)
where ~ (t) is the spectral density matrix of the white
noise ~(t), i.e., E[~(tH'(T)J=~(t)O(t-T). Hence,
except for the possible difficulty in evaluating (2.20),
the discrete-time theory is applicable to (2.19).

168

Spring Joint Computer Conference, 1972

When the observations are continuous, however, i.e.,
yet) =H(t)x(t) +7](t)

Hence, as

we obtain

x=A (t)a;+K(y-H(t)x)

(2.21)

with 7] (t) being white noise, the discrete-time algorithm
is not directly applicable. A heuristic deviation of the
continuous-time equations of Kalman filter is possible
by use of a limiting process as described by Kalman. 2
For small intervals of time, the solution to (2.18) can
be approximated by

Llt~O,

(2.24)

with

Also, the variance equations (1.6)-(1.7), which can
be written in the form
F n+l-1 = (if!nF nif!n' + I'nQnI' n)-l+ H n+t' Rn+lHn+l
become

where

F n+!-l = {Fn+[A (tn)Pn+PnA'(t n) +B(tn)~(tn)B'(tn)]Llt

+0 (Llt2) }-l+H' (tn)N-1 H (t n) Llt
is a random variable of zero mean and variance
~ (tn) Lltn, owing to the integration of white
noise for an interval Lltn.

Vn

Owing to the white noise on the observations it is
not possible to sample the output y (t) at discrete times;
instead, it is necessary to smooth the output during the
intervals. Simple averaging is easiest to treat. For this
type of smoothing
1
Yn= Llt

ft n yet) dt=y(tn) +wn=H(tn)x(tn) +Wn
tn-l
(2.23)

where
1
w n= Llt

ftn 7](t) dt
tn-l

The integral in Wn is a random variable of zero mean and
variance N Llt where N is the spectral density matrix of
the white noise 7]. Accordingly
Wn

is a random variable of zero mean and variance

(1/ Llt) 2N Llt = N / Llt
Using (2.22) and (2.23) as the characterization of an
approximate discrete-time system, and applying the
discrete-time filtering algorithm, gives
a;(tn+1) = [1 +A (t n) Llt] {x(t n)

+PnH' (t n) Rn

-1

[Yn - H (t n) X (t n) ] }

Substituting Rn = N / Llt into this equation and rearranging terms gives
a; (t n+!) - a; (t n )

Llt
= [A (tn)a;(t n) + F nH' (t n)N-1 (Yn - H (tn)a;(t n) ]+O(Llt)

Upon rearranging terms and omitting terms of 0 (Llt2)
we obtain
n =A (t )P +P A'(t )
Fn+1-F
Llt
n
n
n
n

Finally, passing to the limit as

Llt~O,

we get

F=A (t)F+FA' (t) +B(t) ~(t)B' (t)
-FH'(t)N-1H(t)F

(2.25)

Thus the optimum state estimate evolves in accordance with the differential equation of the original
process, but forced by the term K(y-Ha;). The covariance matrix P evolves in accordance with the
matrix Riccati equation (2.25).
Rigorous treatment of the continuous-time process
entails rather sophisticated concepts of stochastic
processes. The original treatment by Kalman and
Bucy3 is entirely rigorous, but is confined to linear
systems. More general formulations which, in principle,
are capable of generalization to nonlinear processes,
have been developed by Stratonovich,7 Kushner,8.9
Bucy,I° and Kailath and Frost,1l·12 and by others.
EXTENSION OF THE THEORY
Like most theories, the theory of recursive filtering
is applicable exactly in almost no practical situation:
few processes are linear, almost no random noise is
gaussian (although what it is if not gaussian is another
problem), and frequently the actual process model is
not known. All these problems have received attention
in the decade since the appearance of the Kalman-Bucy
papers, and are still receiving attention at the present
time. A comprehensive survey of the various extensions
which have been published is an overwhelming assign-

Review of Recursive Filtering Algorithms

ment-a comprehensive bibliography could easily
contain a thousand items. There are, however, several
trends in the investigations being pursued which can be
outlined in broad perspective.

the previous section is applicable, and the deviations
from the nominal trajectory are given by
(3.7)

en = en+Kn(Yn-Hnen)
Nonlinear discrete-time processes

(3.8)

or in terms of the total state

A general discrete-time process could be represented
by the difference equation
(3.1)

(3.2)

Yn=h(xn, vn)

Xn+1 = f(xn)

+ ~nen

=f(xn) -~n(Xn-Xn) +~n(Xn-Xn)

~n = [af(Xn,
aXn

a general observation may be expressed by

where, in most Un and Vn are random variables about
which very little is known. The usual way of handling a
nonlinear problem is to linearize it along a nominal
solution. In the present case, suppose a nominal
sequence Xo, Xl, ... ,xn were known, and, moreover, it
is known a priori that the random quantities Un and Vn
are "small enough" to insure that the differences
(3.3)
are small. Then (3.1) and (3.2) become

Xn+l =f(xn) +~n(Xn-Xn)

169

0)]

Xn=~n

Note that except for the difference between ~n and
(3.9) can be written

(3.4)

4>n

(3.10)
Moreover, in many situations the estimated solutions
xn is more accurate than any a priori nominal solution
xn~Xn; in fact, there may be no reasonable way of
determining Xn other than by making it identical to
the xn, i.e., by defining the nominal solution as the
running estimate. In this case (3.9) and (3.10) are
identical. The same reasoning gives

Xn=Xn+Kn[Yn-h(Xn) ]

+ IinUn

(3.9)

(3.11)

The recursive algorithm (3.10) and (3.11) with the
gain matrix computed from (1.5) and (1.6) with

but

xn+l=f(xn)

is the so-called "extended" Kalman filter, as it is now
termed. These equations were used as early as 1962 by
Smith.I3 The following features of the extended Kalman
filter are worth emphasizing. See Figure 2.

Yn=h(xn) = nominal observation
where

• No nominal trajectory is required
• Covariance matrices Pn, Fn, and gain matrix Kn
must be computed on-line
• Statistical optimality is only approximate.

or

en+l = ~nen+ IinUn+O(en2)
Yn -Yn =EInen+Znvn+O (e n2)

(3.5)
(3.6)

Since (3.5) and (3.6), after omitting the terms of
O(e n 2 ) constitute a linear system, the linear theory of

Although no nominal trajectory is required, it is
necessary to compute the covariance matrix on-line
and this computation occupies the bulk of the computation requirements. It is not insignificant that strict
optimality cannot be assured for the extended Kalman
filter; as a matter of fact, it often happens that the
estimate given by (3.10) and (3.11) actually diverges
from the true trajectory as the number of observations
processed increases. This "divergence problem," to be
discussed subsequently, could result because the terms
of O(e n 2 ), so casually omitted in developing the filtering
equations, in fact, may not be negligible. Their presence

170

Spring Joint Computer Conference, 1972

INITIAL CONDITIONS

~O' ~O
•

•

COMPUTE TRANSITION MATRIX cP n-1·,
EXTRAPOLATE STATE TO NEXT OBSERVATION

,
,
,
,
,

xn = fl~n-11

TIME-UPDATE COVARIANCE MATRIX
1\

'P n=cPn-l

Pn- 1cP n-1 +rn-1 Qn-1rn'-1

COMPUTE SENSITIVITY MATRIX Hn;
COMPUTE EXPECTED OBSERVATION
Yn=h(ln 1

COMPUTE GAIN MATRIX
- '"
I
ITnH'n+Rn)-1
Kn-PnHnlHn

/

READ OB::RYATION /

COMPUTE RESIDUAL

,

rn=Yn-Yn

CORRECT STATE ESTIMATE
'Xn=!n +Kn rn

I
Figure 2

can introduce a statistical bias into the results; the
effect, paradoxically, is most serious when the random
noise represented by f' nUn and ZnVn in (3.5) and (3.6),
respectively, is small relative to the nonlinear terms.
When the random terms are large they tend to swamp
the nonlinear terms; i.e., those of O(e n2 ); when they are

small the nonlinear terms may be predominate. Since
the nonlinear terms add to the random terms, one is
tempted to increase the covariance matrices of the
latter in a heuristic attempt to account for nonlinearity.
This approach is often quite successful, but could be
dangerous because the nonlinear terms are not random,
but are related to the linear terms in a systematic way .
The limitations of the linearized Kalman filtering
equation (3.7) and (3.8) or the extended Kalman
filter (3.10) and (3.11) have led to a number of investigations, some still continuing, of more accurate
extensions of the basic theory or of alternate approaches.
These investigations appear to have been motivated by
two considerations: the desire to achieve performance
closer to the optimum, and the need to avoid problems
which arise in applying the linearized or extended
algorithm.
The desire to avoid the "divergence" attributable to
omission of nonlinear terms is a practical motivation
which may be handled in various ways, not necessarily
related to achieving "better" (i.e., closer to optimum)
performance. In the presence of nonlinearities and/or
nongaussian random variables, the very definition of the
optimum estimate is a problem: in the linear, gaussian
case the conditional mean is also the minimum variance
estimate and the maximum likelihood (Bayes) estimate.
In the linear, but nongaussian case, the minimum
variance estimate (which is what is obtained by
applying the Kalman-filtering algorithm) is not always
the conditional mean, and neither may be the maximum
likelihood estimate. In the nonlinear case, moreover,
none of the estimates can be expressed by an exact
recursion algorithm; errors are introduced by use of
truncated approximations the effects of which are very
difficult to assess. As a practical matter performance of
nonlinear filters can be assessed only by Monte-Carlo
stimulation: a "fix" which works well in one application
may be useless or even worse than the basic extended
algorithm in another.
Improved estimation algorithms can generally be
classified in two categories: higher order, explicit
algorithms and iterative algorithms. In the former, the
updated estimate Xn+l is obtained from xn by an explicit
computation which entails no iteration and no check
of accuracy; in the iterative techniques, the updated
estimate Xn+l is an implicit function of xn which is
solved for iteratively.

Iterative techniques
Iterative techniques for treatment of nonlinear
problems may be visualized as generalizations of the

Review of Recursive Filtering Algorithms

ancient Newton-Raphson technique for solving nonlinear equations. Suppose, for example, that we have a
single observation y from which it is possible to determine the state x through the solution of the system of
equations represented by

y=h(x)

(3.12)

If this is true, the Jacobian matrix
H(x) =

[:~]

is nonsingular in the vicinity of the solution to (3.12).
The standard N ewton-Raphson iteration algorithm for
solving (3.12) is

x=x+[H(x) J-I[y-h(x) ]

(3.13)

where

x
x

is a prior estimate of the solution
is a revised estimate

When x differs significantly from x, x is replaced by x
and the iteration is continued until II x- x II is sufficiently small in accordance with some criterion established by the user.
Comparison of (3.13) with the observation update
equation (3.11) of extended Kalman filtering reveals a
very striking similarity. In Kalman filtering the gain
matrix

multiplies the residual y-h(x) while in the NewtonRaphson algorithm the residual is multiplied by Hn- I •
If the observation noise is absent, and H n -1 exists,
however, the Kalman filter gain becomes

Kn = P nHn' (H n') -1 P n-1 H n-1 = H n-1
In other words the Kalman filter gain is the same as the
N ewton-Raphson weighting matrix when the latter
exists and the noise is negligible. The Kalman gain
matrix may thus be regarded as a generalized version of
the N ewton-Raphson gain which reduces to the latter
in the case when noise is absent and H n-1 exists. When
Hn- I does not exist, i.e., when the number of observations is insufficient to permit determination of the
state, but noise is absent, then the Kalman gain matrix
Kn=PnHn'(HnPnHn')-I is a "generalized inverse" of
Hn in the sense that HnKn=I, regardless of the value
of Pn •

171

Although the Kalman filter uses a more general gain
matrix, it does not perform the iterations of the X ewtonRaphson technique. In the linear case, of cours(', the
iterations are not necessary. In the nonlin('ar case,
however, one would expect that the initial ('stimate x
of the state could be improved upon by iteration unless
the uncertainty in the observation has an effect equal
to the effect of the nonlinearity. Thus, in an application
entailing highly accurate, but nonlinear, sensors, one
could expect significant benefit from use of the iterations; conversely, when the sensor noise is large relative
to the nonlinearity, little improvement due to the
iteration is to be expected.
Assuming that iterations are to be employed, what
is a suitable convergence criterion? If (3.12) is solved
exactly-to the precision available to the computerthen all past history of the process is ignored. If no
iterations are used, then nonlinear effects are disregarded. A reasonable convergence criterion would be
to iterate until the contribution of the error to the
residual vector y- h (x) is just about as large as the
nonlinear effect. The (approximate) covariance matrix
of the residual is H nP nH n' + Rn. Since, in the absense
of nonlinear effects, most of the residuals can be expected to be less than their corresponding theoretical
standard deviation, i.e.,

it would be reasonable to continue iteration until (3.14)
is satisfied. The addition of the Newton-Raphson
iteration cycle to account for nonlinear observations
entails a negligible complication of the basic algorithm,
as the flow-chart of Figure 3 shows. The operating
time, of course, will be increased in proportion to the
average number of iterations necessary to pass the
convergence test. Whether this additional running
time is justified depends on the improvement achieved.
Moreover, in an application in which the computer is
dedicated to the Kalman filtering algorithm, there may
be time available for the iteration so that the additional
cost could be inconsequential.
The ideas inherent in the N ewton-Raphson iteration
technique may be extended to the case in which the
state cannot be determined from a single observation,
but requires a series of observations and knowledge of
the process dynamics. The general equations may be
derived, using considerations of least-squares by combining the analysis of the second section and of this
section. The inherent statistical parameters can be
brought into the problem formulation explicitly. Typical
developments are to be found in COX,14 and Friedland
and Bernstein. Is

172

Spring Joint Computer Conference, 1972

INITIAL CONDITIONS

~O' ~O
-t-COMPUTE TRANSITION MATRIXCPn_l;
EXTRAPOLATE STATE TO NEXT OBSERVATION

,
,
,
,

xn = = [af/ ax] analytically.
Owing to the definition of f as the solution of a system
of ordinary differential equations, however, it is
possible to compute the transition matrix by numerical
integration of the matrix differential equation

.

cJ? =

[aa]
ax

cJ?

(3.20)

with the initial condition (tn - 1 ) =1, where [aa/ax] is
the Jacobian matrix of a(x) evaluated along the
solution to (3.18). Thus x(t n) and cJ?n are evaluated
concurrently by numerical integration of a system of
n (n+ 1) differential equations. The process differential
equations must be integrated to an accuracy consistent
with the observation errors; in other words, the numerical errors in obtaining Xn=X(t n) from X(tn-l) must be
of a lower order than the correction Kn[Yn-h(xn)].
The computation of the transition matrix, however,
requires accuracy only consistent with the accuracy to
which the statistical parameters are known. In practice
this usually means that the numerical integration
algorithm used for (3.20) can be less sophisticated than
that used to integrate (3.18). For example, while a
fourth-order Runge-Kutta algorithm might be needed
to integrate (3.18), it could well happen that a simple,

174

Spring Joint Computer Conference, 1972

Likewise the observations can be expressed as

first-order Euler algorithm

Yn=h(x n, b, vn)

q;n=I+ [::] (tn-tn_.)

would provide sufficient accuracy for the state transition matrix.
Nonlinear dynamics with random excitation create
problems on the frontiers of investigation in the mathematical theory of stochastic processes. The very meaning of differential equations with white noise excitation
is open to serious question: almost nothing is known
about how to interpret a general differential equation of
the form x=a(x,~) with ~ being white noise; the
meaning of the more restrictive equation

in which the white noise ~ is additive, is open to two interpretations, depending upon whether one uses the
mathematically-favored "Ito calculus" or the "Stratonovich calculus" unless the matrix B does not depend on
x. A lucid discussion of the two interpretations is given
by Jazwinski. 6 Since white noise is a mathematical abstraction which cannot exist in nature, the different interpretations are of more interest to mathematicians
than to engineers and physicists. Moreover, unless a
very precise analysis of the physical behavior of the dynamic process is made, it is usually impossible to establish the precise nature of the random excitation. For this
reason it would seem reasonable to account for all the
random effects in a typical process by a model of the
form
X n+l

These equations are general enough to include as
special cases observation bias and constant (unknown)
forcing terms. Each observation bias is represented by
a parameter bi which appears only in the observation
equation. Each constant forcing term appears only
in the dynamic equations unless it contributes to a
direct measurement.
There is a standard trick for handling parameter
estimation, namely to treat b as a part of an enlarged
state vector of k+m components.
Zn=

x=a(x)+B(xH

=f(x n) + r nUn

where r n and Un are selected empirically to account for
the cumulative random errors caused by all random
excitation during the intervals between the observations.
Parameter estimation

In various applications there may be a number of
parameters to be estimated in addition to the dynamic
state variables. Suppose the parameters are designated
as bi (i= 1, ... , m) and arranged in a vector

b=[]
Then the discrete-time dynamics can be represented as
(3.21)

(3.22)

[~:]

Since b is a constant it evolves In accordance with
the equation
bn+1 =b n
The initial condition bo for the estimate is taken as the
expected value before any observations, usually zero.
The standard extended linear algorithm (or any other
nonlinear extension) is applied to estimate Zn; the
resulting estimate contains the estimate xn in the
presence of (initially) unknown parameters are well as
an estimate bn of the unknown parameters. The method
works effectively and, in fact, often is the key to the
success of the Kalman filtering algorithm in practical
applications which abound in uncertain parameters. In
the sense that the filter by estimating the uncertain
parameters adapts to their presence, the technique may
be and, in fact, has been termed "adaptive."
One of the problems with this method of parameter
estimation is that the dimension of the big vector Zn
can be quite large and, as a result the calculations, may
require the manipulation of large matrices. In addition
to requiring considerable storage, the usual numerical
difficulties associated with large-matrix calculations
may be present. In an attempt to avoid such numerical
difficulties, Friedland17 developed a computation technique, which is mathematically equivalent to dealing
with the large vector Zn and the associated covariance
matrices, but in which the estimation of the parameter
vector bn is decoupled from the estimation of the state
vector. In particular, the algorithm consists of computing the estimate xn of the state as if the parameter
vector b were equal to its expected value prior to any
observations, say zero, and the corresponding residual
vectors fn=Yn-h(xn). These residuals are used as the
input to a "parameter estimator" which produces the
optimum estimate bn of the parameter b. The estimate
bn is then multiplied by a matrix V n to yield the cor-

Review of Recursive Filtering Algorithms

rected estimate:
(3.23)
In applying this method, there are usually parameters
which cannot be estimated, i.e., bn changes negligibly
from its value prior to any observations. It is clear from
(3.23) that such parameters need not be included in the
state vector Zn or in the parameter vector bn . It is
cautioned, however, that the covariance matrix, say, Pn
which accompanies the computation of Xn does not
realistically represent the accuracy of the estimated
state. When uncertain parameters are present, the
actual covariance matrix of the state is given by
(3.24)
where Vn is the matrix in (3.23) and Mn is the covariance matrix of the parameter vector, i.e.,
(3.25)
When the uncertainty is large it is quite possible that
V nMnV n' is of the same order of magnitude as Pn or
perhaps even larger.
THE "DIVERGENCE" PROBLEM
Almost as soon as Kalman's recursive filtering
algorithm was announced there were a number of
investigators ready to apply it to their specific problem.
It was quickly discovered that a practical difficulty of
the method is that the estimate of the state may tend
to diverge from the true state and, in fact, may tend to
be ridiculous. Kalman showed that the filtering algorithm is stable, i.e., erroneous covariance matrices
for the dynamic noise and the observation noise will
not cause the estimate to diverge from the true state.
Consequently, the divergence could not be attributed
to an inherent instability of the algorithm. Other
explanations for the divergence problem had to be
found. It became evident that the divergence problem
cannot be attributed to a single source. Sometimes it
may be due to difficulty in propagating the estimate of
the state, in accordance with (3.10) and (3.11); sometimes in propagating the covariance matrix In accordance with (1.6) and (1.7); sometimes both.
Modeling errors

Errors in propagating the estimate of the state may
result because of numerical errors in integrating the
dynamic equations x = f(x), or because the dynamic
equations do not really represent the true behavior of
the process. The state of the art in numerical integration

175

having been very advanced by the time the recursive
filtering algorithm was introduced, the effect of numerical errors could reasonably be discarded. The
possibility that the differential equations being integrated, however, do not accurately represent the
true physical behavior of the process, however, is not
so easily dismissed. The true behavior of the process
may not be sufficiently well understood to be modeled
accurately, or else an accurate dynamic model may be
impractically complicated. The consequence of these
"modeling errors" could very well be the divergence of
the estimated state from the true state. Possible cures
for the modeling errors which have been applied with
success in various applications include:
• Representation of the modeling errors by "pseudonoise"
• Bounding of the covariance matrix
• Use of finite-or fading-memory filtering
• Selective improvement of modeling.
The performance of the Kalman filter is achieved
through the correlation of the state of the process at a
given time to the state at earlier times. This correlation
is established through the dynamics of the process. It
follows that if the dynamic model is incorrect, the
correlations assumed to be developed may be unreliable,
and their use could be dangerous. Any noise present in
the process excitation retards the development of this
correlation, and it is thus reasonable to represent
uncertainty in the model as having the same effect as
would be produced by noise. The covariance matrix of
this "pseudo-noise" is selected so that the standard
deviation in the latter is about equal to the level ot
uncertainty in the dynamic model.
A technique related to the use of pseudo-noise is a
priori covariance matrix bounding. The rationale for
this technique is that, on physical grounds, we would
regard it as impossible to achieve better than a specified
accuracy in estimating some of the state variables. If
the covariance matrix indicates that higher ac<;uracy is
being achieved, the matrix is increased to the a priori
lower limit. Thus, instead of adding the covariance
matrix r nQnr n' corresponding to a known dynamic
noise level at each step, this matrix is adjusted so that
P n+l = ipnPnipn' + r nQnr n' does not decrease below a specified lower limit. Similarly, the observation-updated covariance matrix Pn=Pn-PnHn'(HnPnHn'+Rn)-lHnPn
can be kept from falling below a specified limit.
Another point of view on modeling uncertainties is
represented by the idea that the validity of the dynamic
model may be of limited duration. For example, there
may be certain long-term trends which the model does

176

Spring Joint Computer Conference, 1972

i.e., the conditional mean given the most recent N
observations: each time a new observation is made, the
oldest observation is deleted. One method of obtaining
a finite-memory estimate is to use a non-recursive
algorithm. For example, assuming no dynamic noise,
and following the development in the second section,
the least-squares estimate of Xn given Yn, . . . Yn-N+b
for a linear process, is given by

of the data be assumed as the age of the data is increased. This can be accomplished by assuming that the
noise covariance matrix increases from its "nominal"
value in proportion to the number of samples elapsed.
The computational advantage of the assumption of
gradual diminution of data importance is that the data
processing can usually be represented by a recursive
algorithm. For example, Tarn and Zaborszky,I8 have
shown that if the effective covariance matrix is taken as
slRn (s > 1) where l is the number of elapsed samples the
implementation is achieved by simply multiplying the
term n8n

(4.7)
and entails an additional matrix inversion. In most
cases, however, the additive noise as represented by
r nQnr n' would be expected to be quite small, and the inverse of the bracketed matrix in (4.7) can be approximated by bn- bn'l' n'r nQnr n''I' nb n. Thus (4.7) would be
approximated by
(4.8)
The computation of the additional term in (4.8) not
present in (4.7) entails two additional matrix multiplications, which may not prove significantly better to
evaluation of (4.7).
I t is worth pointing out that the matrices to be
inverted in all aspects of Kalman filtering are symmetric and (theoretically) positive-definite. Use of
inversion algorithms that are specific for such matrices
might be desirable. In particular, the Gauss-Seidel
iterative method for inverting bn-1+'I'n'r nQnr n''I'n,
with bn used to start the iteration, would very likely
converge in one or two iterations.
AnQther method for dealing with the ill-conditioned
matrices that arise in the recursive least-squares
algorithm, has been termed the "square-root method."
The method is based on representing each covariance
matrix as the product of a lower triangular matrix and
its transpose, i.e.,
(4.9)
where S is a matrix in which Sij=O for j>i. When P
and S are scalars S = vip, hence the name of the
method. (In a strict sense a lower triangular matrix S
satisfying (4.9) is not the square root of P. A true
matrix square root, say W, satisfies W2=P, and when
P is symmetric, W is also symmetric and thus cannot
be lower triangular.)
A survey of the background and current status of the
square-root method is contained in a recent paper by
Kaminski, Bryson and Schmidt. 19 In the absence of
process noise, the square root algorithm may be expressed by the formulas

Kn = SnFnGn'-lGn-l

( 4.10)

Fn=Sn'Hn'

( 4.11)

GnGn' = Rn+Fn'Fn

(4.12)

where
and
i.e., Gn

IS

the (unique) lower triangular factor of

(4.13)

where

VnVn'=Rn
Only triangular matrices are inverted in (4.10) and
(4.13) which is a considerable advantage. The major
computational chore is in the factorization of the
matrix Rn+FnFn'. This factorization problem is somewhat analogous to the spectral factorization problem
which arises in Wiener filtering (see Friedland20 for a
discussion of this connection as well as for independent
development of the Cholesky-Banachiewicz algorithm19
for accomplishing the factorization).
When process noise is present, a more complicated
algorithm is needed, but the basic ideas are the same.
The large consumer of computer capacity is the
triangularization operation impJicit in (4.12) . The
efficiency of the square-root method thus depends on
the algorithm used to find Gn • The authors of Reference
19 have made an extensive study of suitable algorithms
and conclude that Householder's algorithm is adaptable
to this problem. A count of operations made in Reference 19 shows that the square-root algorithm may
typically require only as much as 30 percent of additional computer time over that required by the
conventional (Kalman-Bucy) algorithm and even less
time than use of the information-matrix algorithm.
The numerical advantage of the square-root method is
claimed to be equivalent to doubling the precision of
calculations: " ... a single precision square-root filter
would provide the accuracy equivalent of a double
precision conventional filter in ill-conditioned problems."19
CONCLUDING REMARKS
No survey of the first decade of Kalman filtering would
be complete without a discussion of applications which
were investigated almost as soon as the theory appeared. (Since the Swerling paper, 5 which predates
Kalman's paper by a year, deals with an application,
it would be reasonable to assert that applications were
investigated even before Kalman's theory appeared.)
Coming at the time of the rapid expansion of the
country's aerospace program, it is understandable that
the majority of appliyations were in the aerospace field.
G. Smith's very timely paper13 aroused considerable

Review of Recursive Filtering Algorithms

interest when it was presented and perhaps was to a
very large measure responsible for the rapid assimilation
of the method by aerospace engineers. The application
of the method to orbit and trajectory determination
described in the book21 of a notable expert, R. Battin,
helped to establish the importance of the theory. Since
the earliest papers, which demonstrated feasibility of
the method largely through simulations, the number of
applications which have been studied is overwhelming.
Hundreds of papers demonstrating potential performance have been presented at technical meetings
and have been published in the journals of technical
societies. Moreover, the published studies represent
only a small fraction of those actually performed. Many
others are documented in company internal technical
reports or in final reports of limited circulation (many
also classified) prepared under government contract.
The recursive filtering algorithm is so simple that
almost anyone can develop a simulation program.
Many organizations evidently have done so.
Application of the Kalman filtering technique to
processing of real-world data has naturally been more
limited than application studies conducted through
simulation. Nevertheless, the number and importance
of real-world applications of this technique is most
impressive. Those who have listened to the broadcasts
of Apollo flight conversations must have heard reference
to "state-vector updates" -clearly the language of
Kalman filtering. And also the substance. A review of
the extensive use of Kalman filtering in the Apollo
program by Battin and Levine is contained in a compendium22 of theory and applications papers that were
presented at a 1970 AGARD meeting. Another important application of Kalman filtering has been to
aided-inertial navigation. The Kalman filter, in this
application, is used to optimally mix data from an
inertial platform which has very low inherent shortterm errors, but which can build up substantial secular
drifts, and non-inertial (e.g., radio ranging, LORAN,
doppler) navigation aids which have opposite characteristics, namely that they are relatively drift-free but
typically quite noisy. The Kalman filtering algorithm
is implemented using an airborne digital computer on
the C5-A military transport. A description of the system
is given in Reference 22. Inertial navigation applications have advanced to the point that implementation
of the Kalman filtering algorithm is now a significant
design consideration, in particular, with regard to the
design of airborne digital computers to be used in
such systems.
Kalman filtering applications appears to be significantly less widespread outside of the aerospace field.
Perhaps one reason for this is that dynamic models

179

which playa large role in Kalman filtering are not well
established for processes if interest, especially in very
large-scale systems (e.g., urban dynamics, ecological
systems, etc.). The existence of an analytically-defined
dynamic model would appear to be a minimum prerequisite for application of the recursive filtering
algorithm, unless methods can be found for using the
algorithms in the absence of such models. In the field
of industrial processes, Kalman filtering applications
have been reported in conjunction with direct digital
control. An early, and by now rather celebrated,
application in the Swedish paper-making industry was
presented by Astrom.23 Other applications in the paper
industry, the cement industry, the metallurgical
industry, the electric pm\Ter industry, have been
reported or proposed.
The recursive filtering technique developed by
Kalman and Bucy would appear to be mature and
vigorous despite its youth. The easy theoretical problems
seem to have been solved, / and the reasons 'why the
difficult problems are difficult have been discovered;
approximate methods have been developed to facilitate
engineering applications and to develop insights;
applications in diverse fields have been studied and
often implemented; the basic results are teachable and
are included in many curricula in systems engineering.
Like many engineering analysis techniques of the past,
some of the glamor of Kalman filtering is likely to wear
off. What remains, hmvever, will continue to be useful
for many years to come.
REFERENCES
1 R E KALMAN
A new approach to linear filtering and prediction problems
Trans ASME J Basic Eng Series D Vol 82 pp 34-45 March
1960
2 R E KALMAN
New methods in Wiener filtering theory
In Proc 1st Symp Engineering Applications of Random
Function Theory and Probability J L Bogdanoff and
F Kozin Eds N ew York Wiley 1963 pp 270-388
3 R E KALMAN R BUCY
New results in linear filtering and prediction theory
Trans ASME J Basic Eng Series D Vol 83 pp 95-108 March
1961
4 N WIENER
The extrapolation, interpolation, and smoothing of stationary
time series with engineering applicat£ons
New York Wiley 1949
5 P SWERLING
First order error propagation in a stagewise smoothing
procedure for satellite observations
J Astronaut Sci Vol 6 pp 46-52 Autumn 1959
6 A H JAZWINSKI
Stochastic processes and filtering theory
New York Academic Press 1970

180

Spring Joint Computer Conference, 1972

7 R L STRATONOVICH
Conditional Markov processes
Theory of Probability and Applications Vol 5 pp 156-178
1960
8 H J KUSHNER
On the dynamical equations of conditional probability density
functions with applications to optimum stochastic control
theory
J Math Anal Appl Vol 8 p 332 1964
9 H J KUSHNER
On the differential equations satisfied by conditional probability
densities of Markov processes
SIAM J on Control Vol 2 pp 106-119 1964
10 R S BUCY
Nonlinear filtering theory
IEEE Trans on Automat Contr Vol 10 p 198 April 1965
11 T KAILATH
An innovations approach to least-squares estimation-Part I:
Linear filtering in additive white noise
IEEE Trans Automat Contr Vol AC-13 pp 646-655
December 1968
12 T KAILATH P FROST
An innovations approach to least-squares estimation-Part II:
Linear smoothing in additive white noise
IEEE Trans Automat Contr Vol AC-13 pp 655-660
December 1968
13 G SMITH
M ultiuariable linear filter theory applied to space vehicle
guidance
Presented at SIAM Symposium on Multivariable System
Theory Cambridge Mass November 1962
14 H COX
On the estimation of state variables and parameters for noisy
dynamic systems

15 B FRIEDLAND I BERNSTEIN
Estimation of the state of a nonlinear process in the presence
of nongaussian noise and disturbances
J Franklin Institute Vol 281 pp 455-480 July 1966
16 R S BUCY K D SENNE
Digital synthesis of nonlinear filters
Automatica Vol 7 No 3 pp 287-298 1971
17 B FRIEDLAND
Treatment of bias in recursive filtering
IEEE Trans Automat Contr Vol AC-14 pp 359-367 August
1969
18 T J TARN J ZABORSZKY
A practical, nondiverging filter
AIAA J Vol 8 pp 1127-1133 June 1970
19 P G KAMINSKI A E BRYSON JR S F SCHMIDT
Discrete-square root filtering: A survey of current techniques
IEEE Trans on Automat Contr Vol AC-10 No 6 pp 727-735
December 1971
20 B FRIEDLAND
Least squares filtering and prediction of nonstationary
sampled data
Inform Contr Vol 1 pp 297-313 1958
21 R H BATTIN
Astronautical guidance
New York: McGraw-Hill 1964
22 C T LEONDES ed
Theory and applications of Kalman filtering
AGARDograph No 139 NATO Advisory Group for
Aerospace Research and Development February 1970
23 K J ASTR(jM
Computer control of a paper machine-An application of
linear stochastic control theory
IBM J Res Develop Vol 11 pp 389-405 1967

On computational methods for dynamic and
static optimization*
by D. H. JACOBSON
Harvard University
Cambridge, Massachusetts

INTRODUCTION

certain of the second-variational algorithms remain as
attractive methods.
Our work in trajectory optimization (or, more
generally, computation of optimal controls) has been
concerned with the development of a class of algorithms
and a methodology of computation based on Dynamic
Programming. The approach which is called Differential
Dynamic Programming (DDP) arose as a consequence
of an early stimulating paper6 and is quite extensively
described in Reference 7. While no theorems of convergence are given in Reference 7, conditions and proofs
for continued descent are provided, and the algorithms
have successfully solved a number of substantial
numerical problems. Thus, there is still room for
theoretical extensions in the form of convergence proofs
and rate of convergence studies, though these will be
nontrivial. Mayne's8 recent approach to DDP may
prove to be useful in these theoretical problems.
In parameter optimization which, basically, involves
choosing the values of n variables to minimize a scalar
function, the most famous and widely used methods are
given in References 9 and 10. These methods are based
on quadratic modelling of the function to be minimized
and hence are quasi-Newton in type. Interestingly
Fletcher and Powell's algorithm appeared in 1963,
and has been very popular, but it was not until 1971
that a proof of convergence was offered by Powell.ll
Our interest in the function minimization problem
led us to propose a new class of algorithms which is
based upon the concept of an homogeneous function. 12
Our algorithm12 is but one possible example of the use
of the homogeneous model and it is likely that others
will be forthcoming. The algorithm is roughly at the
stage that Fletcher and Powell's was circa 1964 in that
computational experience suggests that it is attractive,
while convergence and rate of convergence studies are
yet to come.
A recent book which is appealing in its novelty of
approach to the theoretical questions of convergence

In the 1960s the joint impact of fast digital computers
and the space age stimulated the ingenuity of a number
of researchers in optimization and prompted them to
invent new and/or better (faster, more elegant) methods
for solving, numerically, optimization problems of
different types. Two areas that received much attention
were trajectory optimization and parameter optimization. That is, the computational problems of determining optimal trajectories (generally, functions of
time) and optimal parameter values by minimizing
(maximizing) appropriate performance criteria.
Many of the (very successful) algorithms developed
were heuristic in that they were good ideas translated
skillfully, albeit non-rigorously in the mathematical
sense, into algorithms and computer programs. More
recently, more effort has been assigned to the theoretical
problems of convergence and rate of convergence of
algorithms. But, and this is an important point, new
powerful algorithms rarely arise out of purely abstract
treatments while on the other hand good heuristic
methods seldom manifest themselves unless their
inventors have at least some deep, albeit informal,
understanding of theories of convergence which would
enable them to propose an algorithm which is "unlikely
not to converge." Thus, good heuristics and theory of
algorithms should complement one another in the
invention and development of numerical methods.
Certain trajectory optimization algorithms that
manifested themselves, as powerful numerical methods
for solving real aerospace problems are described in
References 1 and 5. The reader should acquaint himself
with these because, though some of the methods are
dated, insight into the development of computational
methods in optimization can be gained and, moreover,

* This research is supported by the Joint Services Electronics
Program on Contract N00014-67-A-0298-0006.
181

182

Spring Joint Computer Conference, 1972

and rate of convergence is Polak's. 13 Here, general
theorems on convergence are presented and applied
to known and new algorithms. Though this general
theorem approach is appealing and useful it is not a
panacea; indeed, some effort appears to be needed to
twist the algorithm described in Reference 12 into the
framework and verification of a number of required
conditions seems to be nontrivial. 14
With this background and philosophy noted, we
continue with subsequent sections of this paper which
describe briefly the notions of DDP for control optimization, and homogeneous modelling for function
optimization. These are two approaches which seem to
be attractive and which, as outlined above, offer
potential for future research.
OPTIMAL CONTROL COMPUTATION

Problem formulation
We are concerned with the problem of finding a
control function u ( .) which minimizes

V(Xo, u(·), to) =

t!

I

L(x, u, t) dt+F[x(tj)J

(1)

to

subject to the dynamic system constraints

x=f(x, u, t); x(to) =Xo

(2)

and the terminal and control constraints

-.f;(x(t j » =0

(3)

g(u(t»~O

(4)

Here, L:R nXR mXRL-7R\ F:Rn~R1, f:RnXRmXR1~
Rn, -.f;:Rn~R8, g:Rm~Rq, and all these functions are
assumed to be three times continuously differentiable
in each argument. The initial and final times to, tj are
assumed to be given.
In general, one is unable to find the absolute minimum of V (some sort of global search technique would
be required) unless V is a convex functional of u(·)
which would exclude the possibility of there existing
a number of local minima having different V values.
Typically what one can find is a stationary point of V
or, at best, a local minimum of V.
It is known that a necessary condition (Pontryagin's
Principle) for V(xo,u('),t o) to have a relative minimum with respect to u(·) at u(·) =Uo(.) is that there
exist multipliers poER+\ vERB, A(') absolutely continuous, not all zero, such that

where

H(x, u, A, t) = poL (x, u, t) +ATf(x,

U,

t)

(6)

and

UO(t) = arg min H (x, u, A, t)

(7)

U(t)EU

where

u= {u(t) :g(u(t»

~O}

(8)

Usually one assumes that the problem is normal (i.e.,
that the conditions can be satisfied with po:;eO) so that
po can be set equal to unity.
Thus, at the very least, one is interested in determining a control function which satisfies the above
necessary condition.
Certain algorithms [2J, [3J are based directly on
second-order expansions of the above optimality
conditions, but we prefer to use the notion of DDP
which is intuitively more appealing and gives rise to
algorithms which are significantly different from those
arising from expansions of conditions (5) - (7) . Of
course, with hindsight, it is possible to derive these
algorithms by expanding (5)-(7) but it is the Dynamic
Programming formulation which gave rise to these in
the first place (see Reference 15 for some discussion
of this).
For the purpose of this presentation we shall assume
g ( • ) = 0 (i.e., no control constraints) and at the outset
we shall assume -.f;(.) =0 (no terminal constraints)
though we shall allow -.f;( ·):;e0 later in the paper (see
Reference 7 for DDP algorithms that handle control
constraints) .
We define the optimal value function VO(x, t) by
..1

VO(x, t) =

min

jt! L(x, u, t) dt+F(x(tj»

(9)

U(T) ,t0]. There is a host of other methods
based on quadratic models (Quasi-Newton methods)
and each has its advantages and disadvantages when
compared with References 9 and 10; see, for example

184

Spring Joint Computer Conference, 1972

Reference 17. The important point is that researchers
in this field have exploited and continue to exploit,
admittedly cleverly, the quadratic model. Thus, the
homogeneous model, described below, seems to be a
departure from conventional approaches (though a
certain method that arises from the homogeneous
model is closely related to Newton's method).

Homogeneous function as a model for minimization
algorithms

The continuously differentiable function C (x) is
said to be homogeneous of degree "I if
(22)

C(x) ="1-1 (x-x*)T(ac/ax) (x) +w

Clearly a quadratic function is homogeneous of degree
2. An example of a non-quadratic homogeneous function is
C(x)

= [Y2(X-X*)TQ(X-X*)Jp, p>l, Q>O

(23)

Since Cxx(x*) =0 convergence of conjugate gradient
methods is particularly poor for this type of function
[12].
Multiplying (22) by 'Y yields

Note that this is a Newton step modified by the scale
factor ("1-1). Thus Newton's method, which minimizes
a quadratic in one step, minimizes a homogeneous
function if a step length of ("1-1) is used. This appears
to be unknown in the function minimization literature
though analogous behavior, in the problem of locating a
repeated root of an equation, was recognized in 1870 by
Schroder. Unfortunately, methods which generate
estimates of the second derivative matrix (inverse)
from past data, for example Fletcher and Powell, do
not preserve this valuable property; this is another
motivation for estimating x*, "I, w directly from (24),
as is done in Reference 12.

CONCLUSION
In this paper our intent is to place in perspective certain
approaches to the development of optimization techniques, and to suggest certain research directions.
Two areas of recent activity, namely dynamic and
static optimization via DDP and homogeneous modelling, are introduced. DDP and homogeneous modelling
are two novel approaches to optimization which could
be exploited further.

~

'YC(x)

= (x-x*)T(ac/ax) (x) +w,

'Yw=w

(24)

N ow, the attractiveness of this model is apparent;
namely, the unknowns x*, "I, w appear linearly and can
be solved for, given n+2linearly independent vectors
[C(Xi), (ac/ax) (Xi), -IJ,

i=I, ... n+2

(25)

Our new algorithm, for general functions, described in
Reference 12 is one possible procedure for iteratively
updating the estimates of x*, "I, w as new data points
become available. Numerical experience indicates that
the algorithm is at worst competitive with Fletcher
and Powell's and, in a number of representative
examples, is almost twice as fast in terms of number of
evaluations of the pair [C (x), (aC / ax) (x)].
Though the class of homogeneous functions is larger
than, and includes, quadratic functions, a suitable
modification of Newton's method will find the minimum,
x*, in one step. Differentiating (24) with respect
to x yields
[(a 2c/ax2) (x)J(x-x*)

= ("1-1) (ac/ax) (x)

(26)

whence, if the required inverse exists and is positive
definite,
x*=x- ("1-1) [(a 2c/ax2) (x) J-1 (ac/ax) (x)

(27)

REFERENCES
1 H J KELLEY
Methods of gradients
In Optimation Techniques G Leitmann ed Academic Press
New York 1962
2 H J KELLEY R E KOPP H G MOYER
A trajectory optimization technique based upon the theory of
the second variation
In Progress in Astronautics and Aeronautics Vol 14 New
York Academic Press 1964 pp 559-582
3 S R McREYNOLDS A E BRYSON JR
A successive sweep method for solving optimal programming
problems
Proc 1965 Joint Automatic Control Conference No 6 P 551
4 H J KELLEY B R UZZELL S S McKAY
Rocket trajectory optimization by a second-order numerical
technique
AIAA NASA-MSC Astrodynamics Conference Houston
Texas December 12-14 1967
5 C W MERRIAM III
Optimization theory and the design of feedback controls
McGraw-Hill New York 1964
6 D Q MAYNE
A second-order gradient method of optimizing non-linear
discrete time systems
Int J Control 3 1966 pp 85-95
7 D H JACOBSON D Q MAYNE
Differential dynamic programming
American Elsevier New York 1970

Computational Methods for Dynamic and Static Optimization

8 D Q MAYNE
Differential dynamic programming-A unified approach to
the optimization of dynamic systems
To appear in Advances in Control Systems C T Leondes ed
1972
9 R FLETCHER C M REEVES
Function minimization by conjugate gradients
Computer Journal 7 July 1964 pp 149-154
10 R FLETCHER M J D POWELL
A rapidly convergent descent method for minimization
Computer Journal 6 1963 pp 163-168
11 M J D POWELL
On the convergence of a variable metric algorithm
J Inst Math Applic 7 1971 P 21
12 D H JACOBSON W OKS MAN
An algorithm that minimizes homogeneous functions of n
variables in (n + 2) iterations and rapidly minimizes general
functions
J Math Anal Appl 1971 To appear

185

13 E POLAK
Computational methods in optimization-A unified
approach
Academic Press New York 1971
14 E POLAK D H JACOBSON
Informal Talks Spring 1971
15 W F DENHAM
Review of Reference 7
IEEE Trans Automatic Control Volume 16 August 1971
pp 389-390
16 D H JACOBSON M M LELE J L SPEYER
New necessary conditions of optimality for control problems
with state variable inequality constraints
J Math Anal Appl35 1971 pp 255-284
17 B A MURTAGH R W H SARGENT
Computational experience with quadratically convergent
minimization methods
Computer J Volume 13 May 1970 pp 185-194

Piecewise linear approximations of fewest line segments
by D. G. WILSON
Virginia Commonwealth University
Richmond, Virginia

INTRODUCTION

at discrete abscissa values within a variable tolerance.
Our algorithms can also be used to approximate continuous functions. However, in this case a partition of
the interval of interest must be chosen first, the values
of the function at these points computed, and an initial
continuous piecewise linear approximation obtained by
linear interpolation. It is evident that our algorithms
cannot give a "good" fit if this initial approximation is
not "good." It is also evident how to make this initial
approximation "good." But it is not at all obvious how
to make it how "good." We have not solved this
problem in general. Perhaps a combination of Phillip's
algorithm and ours could be used to solve the problem
for continuous functions whose domains are separable
into intervals over which the second derivative is of
one sign.
In the second section we give a precise statement of
the problem we have solved. Section three contains the
basic algorithm and the modification. Section four
contains the proofs which validate the algorithm.
Section five contains some sample results. Section six
acknowledges the assistance of others. A listing of a
FORTRAN program which implements our algorithms
is appended.

Schwerdtfeger4.5 has considered the problem of interpolation and curve fitting over a given partition by a
sum of continuous sectionally linear functions. He
showed how to construct an orthogonal system of these
functions over a given partition and how to use this
system to obtain an approximation of a given function
which is best in the least square sense.
Stone,6 Bellman,! and Gluss 2 have analyzed various
aspects of the problem of obtaining a piecewise linear
approximation, not necessarily continuous, with a given
number of line segments which is best in the least
square sense.
IVlore recently, Phillips3 has given an algorithm for
obtaining a continuous piecewise linear approximation
to a function whose second derivative is of one sign.
This algorithm gives an approximation which is of
fewest segments among those with a given deviation.
The output from this algorithm is a partition of the
given interval and the parameters of a straight line
over each subinterval of the partition.
We consider the problem of approximating a continuous sectionally linear function by another piecewise
linear function, which mayor may not be continuous,
satisfying:

STATEMENT OF THE PROBLEM

(a) the approximation is within a given deviation,
which need not be constant, of the given function
and
(b) the approximation is extremal in the sense that
there is no other piecewise linear approximation
which is within the same or lesser deviation and
which has fewer line segments.

Let P denote a partition of the finite interval [a, b].
Let f (x) be a continuous function defined on [a, bJ
which is linear on each subinterval [Xi-I, xiJi = 1, ... , n.
Let 0(x) be the continuous sectionally linear extension
to [a, bJ, obtained by linear interpolation, or 0 (x) = OJ
when x=xjEP, where 0i>O, j=O, ... , n, are the
permissible deviations at the points of P.
Then the problem is, given Uo = a, determine m, pi, qi,
and Ui, i= 1, ... , m such that F(x) given by:

We give an algorithm which solves the problem as
stated and a modification which gives a continuous
piecewise linear, approximation which is within a given
deviation of the given function and which is extremal
among such approximations in the sense given above.
We thus solve the problem of fitting data known only

187

188

Spring Joint Computer Conference, 1972

when xE [Ui-I, Ui) for i = 1, ... ,m and
F(um) =Pmx+qm,

satisfies If(x)-F(x)l:::;o(x) for xE[a,bJ and m,
the number of linear segments of F, is a minimum.

Xk(x, A, B)

THE ALGORITHM

rmax[x, {Xi I xiEP, Xi ~k (Zi-I, Xh, Ai-I),
then go to Termination step 1.
4. If Zi = Zi-I, then go to Termination step 2.
5. Compute: Ai=Pk(Z*, Zi-I Zh Yi),
Bi=Qk(Z*, Zi-I, Zh Yi)'

6. Increment j by

+ 1 and go to Iteration step 1.

Proof:

The functions are rational and hence continuous on
(x, b]. Let Xi and Xi+! be successive points of P n [x, b].
That Sk and Sk are linear in (Y-X)-I for yE (Xi, Xi+!]
follows from substituting
LJ.I(Y) =LJ.I(Xi) + [LJ.I(Xi+l) -LJ.I(Xi) ](Y-Xi) / (Xi+I-Xi)

Termination:

1. If X(k)=+1, then set Pk=Sk(ZhYi)' If
X(k) = -1, then set Pk= Sk(Zh Yi)' Set qk= f(zi) +
"A(k)O(Zi) -PkZi' Set X(k+l) =X(k). Go to
Termination step 3.
2. If X(k) = -1, then set Pk=Sk(Zi, Yi)' If
"A(k) = 1, then set Pk = Sk (Zh Yi)' Set qk = f(zi) +
"A(k)o(z) -PkZi' Set X(k+1) = -X(k).
3. Set: Uk=Yh

+

for p,=t into the definition of Sk equation (2.1) and
for p,=b into the definition of Sk equation 2.2. Writing
(Y-Xi) = (y-x) + (X-Xi) and dividing out (y-x)
gives an expression linear in (Y-X)-I.
Corollary 1:

For a fixed XE [a, b], if Xi and Xi+! are successive
points of Pn[x,b],then Sk(X,y) and Sk(X,Y) are
monotone functions of Y for Y E (Xi, Xi+l].
Corollary 2:

Ao= Sk(ZO, Xh),
Bo= Sk (zo, Xh).
If the approximation is to be continuous, then
set z* = Zh otherwise set z* = Yi' If the approximation is to be continuous and k> 1, then
recompute Uk-I, the abscissa value at the intersection of the current and previous segments.
Set: j = 1, increment k by
1 and go to
Iteration step 1.
4. Set: Pk = {~k (Zi-I, b, Ai-I) +Uk (Zi-I, b, B i- I) }/2,

+

For fixed xE [a, b], Sk(X, y) and Sk(X, y) take their
minimum and maximum values respectively at points
y' and y" which belong to pn (x, b].
Lemma 2:

For a fixed XE [a, b], A and B, if Xi and Xi+! are
successive points of pn (x, b] with ~k(X, Xi, A) ~
Uk(X, Xi, B) and ~k(X, Xi+!, A)  ~k (x, Xi, A)
or
Sk (x, Xi+l) <
Uk(X, Xi, B) and not both.

qk=f(Zi-l) +"A(k) o(Zi-I) -Pkzi-I,

Proof:

uk=b.

We show first that under the hypothesis not both
inequalities may hold. Since Sk(X, Xi+!) ~Sk(X, Xi+!) ,
both inequalities would imply Uk (X, Xi, B) > ~k(X, Xi, A)
which contradicts the hypothesis.
We now show that under the hypothesis not both
inequalities may fail. From the definition of ~k and Uk,
and lemma 1: If Sk (x, Xi+!) ~ ~k (X, Xi, A) and
Uk(X, Xi, B) ~~k(X, Xi, A),
then
Uk(X, Xi+l, B) ~
~k(X, Xi, A); similarly if Sk(X, Xi+!) ~Uk(X, Xi, B) and
~k(X, Xi, A) ~Uk(X, Xi, B),
then
~k(X, Xi+l A) ~
Uk (X Xi, B). Thus, if the hypothesis held but both
inequalities failed we would have: ~k (x, Xi, A) ~
Uk(X, Xi+l, B) > ~k(X, Xi+l, A) ~Uk(X, Xi, B). But this
implies Sk (x, Xi+l) > Sk (x, Xi+!) which is impossible.

If the approximation is to be continuous and
k> 1, then recompute Uk-I, the abscissa value at
the intersection of the current and previous
segments. End.

VALIDATION
In this section we show that Yk(x, A, B) can be
computed, that the algorithm just given does generate
a piecewise linear approximation which is extremal in
. the sense already defined and finally that the modification to be implemented for a continuous approximation

190

Spring Joint Computer Conference, 1972

Proof:

Lemma 3:

For a fixed xE [a, b], A and B, let Xi and Xi+! be
successive points of P(](x,b] with ~k(X,Xi,A)~
Uk (X, Xi, B) and Uk (X, Xi+l, B) > ~k (x, Xi+l, A) . If
Sk(X, Xi+l) > ~k(X, Xi, A), then Yk(x, A, B) is the z
value for which
Lb(Z) = (z-x)

~k(X,

Xi, A) +f(x) +A(k)o(x);

while if Sk(X, Xi+!)  ~k (x, Xi, A), then Sk (x, z) is
an increasing function of z for Z E (Xi, Xi+l] and we are
interested in the Z for which Sk(X, z) = ~k(X, Xi, A),
while if Sk (x, Xi+!) < Uk (X, Xi, B), then Sk (x, z) is a
decreasing function of z for zE (Xi, Xi+!] and we are
interested in the z for which Sk(X, z) =Uk(X, Xi, B).
This lemma shows constructively that Yk(x, A, B)
can be computed. This is the only function we have
defined about which there was potential doubt.
It is evident that our algorithm generates a piecewise
linear approximation which is within 0 of f. We now
show that this approximation is extremal.
For convenience we identify the last Zj associated
with the kth segment as ek, the abscissa value of the
eyepoint of this segment. This value is available at the
termination step of each segment. Note that

Since each segment, except possibly the right most,
terminates on either L t or Lb we have shown that each
approximating segment, again except possibly the
right most, has at least two points on the boundary of
our two dimensional tunnel. The extremal property of
our approximation follows from each approximating
segment, except possibly the right most, having at
least three points on the boundary which alternate
between the boundary lines.
We will prove this assertion in the next two lemmas.
The first of these merely establishes a useful geometric
fact.
Lemma 4:

Let asx, <,
S, or =. If A(k) = +1 and Sk(X, y)Rsk(x, z), then
Sk(X, y)Rsk(y, z). If A(k) = -1 and Sk(X, y)RSk(x, z),
thensk(x, y)RSk(y, z).
~,

If A(k) = +1, then the hypotheses imply:

[Lt(y) -Lt(x) ](z-x)R[Lb(z) -Lt(x)] (y-x).

In this relation we substitute (z-y+y-x) for (z-x)
on the left and [Lb(Z) -Lt(y) +Lt(y) -Lt(x)] for
[Lb(z) -Lt(x)] on the right. The result is:
[Lt(y) -Lt(x) ](z-y)R[Lb(z) -Lt(y) ](y-x).

The conclusion, Sk(X, y)Rsk(y, z), follows from dividing
this relation by (z-y)(y-x) >0.
The argument is similar in the case A(k) = - 1.
Lemma 5:
If the kth approximating segment is not the right
most and terminates on Lp., where,." = b or t, then there
exist x'E [Uk-I, Uk) and x"E (x', Uk) such that Lp.(x') =
X'Pk+A(k)o(x') and Lv(x") =X"Pk+A(k)o(x") where
if ,." = b, then v = t and vice versa.

Proof:
The idea of the proof is simple although the notation
is complicated. The outline of the proof is as follows.
If the kth segment is not the right most, then the slope
of this segment is both the maximum of the minimum
permissible slopes for approximating segments through,
(ek' Lp.(ek» which intersect the vertical segment over
Uk-I, and the minimum of the maximum permissible
slopes for approximating segments through this eyepoint which intersect this vertical segment. Furthermore each of these slopes is determined by a point on
the boundary. One of these points is the terminal point
of the segment, the other is the point whose existence
this lemma asserts.
There are four possible cases determined by:
Lt(Uk) =UkPk+qk with A(k) = ±1, and Lb(Uk) =UkPk+qk
with A(k) = ± 1. We shall consider the two cases with
A(k) = + 1. The other two are similar to these.
We consider first A(k) = +1 and Lt(Uk) =UkPk+qk.
Then Lt(ek) =ekPk+qk, x'=ek and we need to find
x" E (x', Uk). If ek = Uk-I, then the slope of the line
through (Uk-I, Lt(Uk-I» and (Uk+l, Lt(Uk+!» is the
minimum permissible slope of an approximating
segment over [Uk-I, Uk]. By lemma 3 and corollary 2 of
lemma 1 this minimum slope is the slope of a line from
(Uk-I, Lt(Uk-I»
through (Xi, Lb(Xi»
for some
Xi E P(] (Uk-I, Uk]. Furthermore, this Xi is not Uk since
Lt(Uk) =UkPk+qk. In this case x" is this Xi.
If ek¢.uk-I, then to determine Uk, Pk and qk more than
one pass through the iteration phase of our algorithm
was required. Let ek* and Yk* be respectively Zj-2 and
Yi-I, where ek = Zi from the determination of Uk, Pk and

Piecewise Linear Approximations of Fewest Line Segments

qk and let Xk * = min {x I x E P, x ~ Yk * }. Then
Pk= ~k(ek, Uk, A) =uk(ek, Uk, B),

where
and
If there were no x" E (ek' Uk) such that Lb (x") =
X"Pk+qk, then Pk would equal Band sk(ek, Xi) would be
less than B for each Xi E pn (ek' Uk]. But this is impossible. For the algorithm which gives the value of Yi
insures that Sk(ek*, ek) :::;sk(ek*,xk*); and lemma 4 then
implies Sk (ek*' ek) :::;Sk (ek' Xk*). Finally, since A= + 1, we
have B=Sk(ek*, ek). Hence sk(ek, Xk*) ~B, and the
existence of an x" is established.
We suppose now that A(k) = +1 and Lb(Uk) =
UkPk+qk. Then Lt(ek) =ekPk+qk and we will show that
there exists x' E [Uk-I, ek) such that Lb(x') = X'Pk+qk.
This follows from Sk(ek, Uk) =Pk(Uk-I, ek*, ek, Yk*). For
Sk (ek' Uk) = Uk (ek' Uk, B) = ~k (ek' Uk, A), and if this is
not A, namely Pk(Uk-I, ek*, ek, Yk*), then there exists
some xiEPn(ek, Uk) such that Sk(ek, Xi)  1 the kth segment extended to the

191

left intersects the (k - 1) th segment between the x"
and Uk of lemma 5. That this approximation is extremal
follows from the observation made in the proof of
corollary 2 of lemma 5.
SAMPLE RESULTS
The appended FORTRAN program, with a suitable
driver, was run a number of times. An input parameter
determined if the approximation was to be continuous
and whether or not the deviation was to vary. If the
deviation was not to vary it was taken as the first
input tolerance.
One set of test data was the following:
INPUT DATA, NUMBER OF POINTS=20

x

Y

TOLERANCE

1.0000
2.0000
3.0000
4.0000
5.0000
6.0000
7.0000
8.0000
9.0000
10.0000
11.0000
12.0000
13.0000
14.0000
15.0000
16.0000
17.0000
18.0000
19.0000
20.0000

0.7175
0.6250
0.6250
0.6250
0.6563
0.7500
0.6563
0.6406
0.7500
0.5000
0.7500
0.6250
0.6250
0.6250
0.6563
0.7500
0.6563
0.6406
0.7500
1.0000

0.1250
0.0625
0.0625
0.1250
0.1250
0.2500
0.1250
0.0313
0.0312
0.0156
0.1250
0.0625
0.0625
0.1250
0.1250
0.2500
0.1250
0.0313
0.0312
0.0156

The results, when the deviation was taken as constant,
namely 0.125, were:
2 LINE SEGMENTS WERE REQUIRED TO
FIT THESE DATA EQUATION OF
APPROXIMATION IS Y=PX+Q
FOR U.LT.X.LT.V

P

Q

U

v

Y(U)

Y(V)

0.0
0.6250 1.0000 19.0000 0.6250 0.6250
0.3750 -6.5000 19.0000 20.0000 0.6250 1.0000
whether or not the approximation was required to be
continuous. When the deviation was permitted to vary,

192

Spring Joint Computer Conference, 1972

the results were:

The results were:

6 LINE SEGMENTS WERE REQUIRED TO
FIT THESE DATA EQUATION OF
APPROXIMATION IS Y=PX+Q
FOR U.LT.X.LT.V

P

Q

v

U

0.0113 0.5812 1.0000 8.6372
-0.0627 1.2828 8.6372 9.3075
-0.1893 2.4086 9.3075 10.0947
0.0832 -0.2904 10.0947 11.9235
0.0172 0.3621 11.9235 18.6778
0.2393 - 3. 7867 18.6778 20.0000

Y(U)

Y(V)

0.5925
0.7415
0.6467
0.5497
0.5673
0.6835

0.6791
0.6995
0.4977
0.7018
0.6835
1.0000

when the approximation was not required to be continuous, and:
6 LINE SEGMENTS WERE REQUIRED TO
FIT THESE DATA EQUATION OF
APPROXIMATION IS Y=PX+Q
FOR U.LT.X.LT.V

P

Q

v

u

0.0113 0.5812 1.0000 8.0000
0.0469 0.2965 8.0000 9.0000
-0.2032 2.5474 9.0000 10.0000
0.1094 -0.5781 10.0000 11.0000
0.0067 0.5513 11.0000 18.6084
0.2329 -3.6572 18.6084 20.0000

Y(U)

Y(V)

0.5925
0.6719
0.7188
0.5156
0.6250
0.6759

0.6719
0.7188
0.5156
0.6250
0.6759
1.0000

when the approximation was required to be continuous.
These results show that it may not require any
additional segments to have the approximation be
continuous for a given set of tolerances.
Another set of test data was:

5 LINE SEG:\IENTS WERE REQUIRED TO
FIT THESE DATA EQUATIOX OF
APPROXLUATION IS Y =PX+Q
FOR U.LT.X.LT.V

P

Q

U

v

-0.7500 4.8000 0.0
2.5333
0.2727 2.2091 2.5333 4.0000
0.8333 -0.0333 4.0000 7.4800
-0.2632 8.1684 7.4800 9.0360
- 1 . 6500 20. 7000 9.0360 12.0000

Y(U)

Y(V)

4.8000
2.9000
3.3000
6.2000
5.7905

2.9000
3.3000
6.2000
5.7905
0.9000

when the approximation was required to be continuous
and the deviation was taken as 0.2; and:
5 LINE SEGl\1ENTS WERE REQUIRED TO
FIT THESE DATA EQUATION OF
APPROXIlVIATION IS Y=PX+Q
FOR U.LT.X.LT.V

P

Q

U

v

-0.7000 4.8000 0.0
2.4530
0.0130 3.0510 2.4530 4.0000
0.7990 -0.0930 4.0000 7.9099
-0.3000 8.6000 7.9099 9.1905
-1.7237 21.6847 9.1905 12.0000

Y(U)

Y(V)

4.8000
3.0829
3.1030
6.2270
5.8428

3.0829
3.1030
6.2270
5.8429
1.0000

when the approximation was required to be continuous
and the deviation was permitted to vary.
The program will accept any non-negative tolerance
including zero. If all tolerances are zero the program
gives the parameters for linear interpolation.

INPUT DATA, NUMBER OF POINTS = 13
X

Y

TOLERANCE

0.0
1.0000
2.0000
3.0000
4.0000
5.0000
6.0000
7.0000
8.0000
9.0000
10.0000
11.0000
12.0000

5.0000
4.0000
3.1000
3.1000
3.1000
4.0000
5.0000
6.0000
6.0000
6.0000
4.0000
2.5000
1.0000

0.2000
0.1000
0.3000
0.0100
0.0030
0.2000
0.3000
0.5000
0.2000
0.1000
0.7500
1.0000
0.2000

ACKNOWLEDGMENTS
This problem was originally given to me by lVlr. Fred
Stahl of the John D. Kettelle Corporation. I am indebted to Dr. W. A. Thedford of Virginia Commonwealth University for a suggestion which led to the
modification for a continuous approximation.
Mr. W. T. Lipscomb III, a student at V.C.U.,
programmed a preliminary version of the algorithm and
in numerous discussions contributed some of the
descriptive terminology. His name appears as a coauthor of the appended listing.
Sincere appreciation goes to my wife Gwendolyn
who typed this manuscript.

Piecewise Linear Approximations of Fewest Line Segments

193

1 R BELLMAN

3 G M PHILLIPS
Algorithms for piecewise straight line approximations
The Computer J 11 2 August 1968 pp 211-212
4 H SCHWERDTFEGER
Interpolation and curve fitting by sectionally linear functions

On the approximation of curves by line segments using
dynamic programming
Comm ACM 4 6 June 1961 p 284
2 B GLUSS
Further remarks on line segment curve-fitting using
dynamic programming
Comm ACM 5 8 August 1962 pp 441-443

Canad Math Bull 3 1 January 1960 pp 41-57
5-Further remarks on sectionally linear functions
Canad Math Bull 4 1 January 1961 pp 53-55
6 H STONE
Approximation of curves by line segments
Math of Comp 15 73 January 1961 pp 40-47

REFERENCES

194

Spring Joint Computer Conference, 1972

APPENDIX

FORTRAN IV G LEVEL
C
C
C
C

MAIN

19

PIECWISE LINEAR APPROXIMATION OF FEWEST
LINE SEGMENTS WITHIN A GIVEN TOLERANCE.
BY D G WILSON AND W T LIPSCOMB III
VIRGINIA COMMONWEALTH UNIVERSITY.

C

SUBROUTINE STL(X,Y,E,N,U,P,Q,K,ITCH)
DIMENSION X(9),Y(9),E(9),U(9),P(9),Q(9)
X AND Y ARE INPUT DATA ARRAYS OF N ELEMENTS
Y = P(I)*X + Q(I) IS THE EQUATION OF THE
ITH SEGMENT OF THE PIECEWISE LINEAR APPROXIMATION. THE ITH SEGMENT EXTENDS FROM
X = UeI) to X = U(I+l1. K IS THE NUMBER
OF SEGMENTS.
IF THE INDICATOR ITCH IS
EITHER 1 OR 3, THE APPROXIMATION MUST BE
CONTINUOUS.
IF ITCH IS 2 OR 3, E IS A
TABLE OF N PERMISSIBLE DEVIATIONS..
IF ITCH
IS LESS THAN OR EQUAL TO 1, THEN E(l) IS
THE SINGLE PERMISSIBLE DEVIATION.

0001
0002

r'
C
C
C
C
C
C

C
C
C
C
C

C
C

* * * * * * * *
INITIALIZATION

* * * * *

* *

* *

* *

* *

*

c
C

FROM SCRATCH

C
.J = 1

000:3
C
C

C

C
0004

0005

C
C

0001;.

0007
000::::

0009
0010
0011

0012
001:3

0014
0015

r'
r'
C:

IS THE INDEX INTO THE U ARRAY.
ILLEGITIMATE DATA CAUSES ERROR RETURN WITH
K, THE NUMBER OF LINEAR SEGMENTS, EQUAL O.
THE MINIMUM NUMBER OF DATA POINTS IS TWO.
IF (N.LE.l) GO TO 777
IF (E(l).LT.O.O) GO TO 777
DEVIATIONS MUST BE NONNEGATIVE
CHECK FOR DATA OUT OF ORDER.
DO 29 L =. 2, N
IF (X(L-l).GE.X(L» GO TO 777
IF (ITCH.LE.l) GO TO 29
IF (E(L).LT.O.O) GO TO 777
29 CONTINUE
EP:3LN = E( 1 )
YINIT = Y(l) - EPSLN
:::;dN = 1.0
KEEP = 1
U(l) = X(l)
U(M) IS THE LEFTMOST ABCISSA VALUE FOR THE
MTH SEGMENT AND THE RIGHTMOST ABCISSA VALUE
FOR THE (M-l)TH SEGMENT.
J

I

0011:..

= 1

I IS THE INDEX INTO THE X AND Y ARRAYS.
YEYE = Y(l) + EPSLN
XEYE, YEYE ARE THE COORDINATES OF THE
CURRENT EYEPOINT.

C
0017
C
C
,-.

'-'

FOR EACH LINE SEGMENT

C

c

3!:i

0018
0019

0020

c

CONT I NUE
IF (U(J).GE.X(N» GO TO 777
TEST FOR END OF DATA
XEYE = U(.J)

Piecewise Linear Approximations of Fewest Line Segments

FORTRAN IV G LEVEL
C
rC:

0021
C
C
C

C
0022

c
002::::

0024

0025
C

r-

C
C
(l021::..
0027
C

r-

C
C
C

0029

c
c
c

STL

19

U(J-l), YINIT ARE THE COORDINATES OF
THE POINT OPPOSITE THE ORIGONAL EYEPOINT
OF THE CURRENT SEGMENT.
INIT :: 1
I NIT U:: THE I NDE X OF THE F I'R::::T 1 NPUT
X VALUE IN THE CURRENT SUBDIVISION.
THIS MAY NOT BE THE INITIAL X-VALUE
OF THE CURRENT SEGMENT.
IF (XEYE .GE. XCI») I:: 1+1
TEST FOR SEGMENT ENDING AT AN INPUT X VALUE
IF (ITCH.NE.l.AND.ITCH.LT.3) KEEP:: IN IT
IF (ITCH.GE.2) EPSLN :: SGN*E(I)
DX:: X(I) - XEYE
DX :: DISTANCE FROM CURRENT EYEPOINT TO XCOORDINATE OF POINT CURRENTLY BEING CONSIDERED. TO BE USED IN COMPUTING MAX AND MIN
SLOPES SMAX AND SMIN RESPECTIVELY
SMAX :: (Y(I) + EPSLN - YEYE)/DX
SMIN:: (YCI) - EPSLN - YEYE)/DX
IPIV :: I
IPIV IS THE INDEX OF THE RIGHTMOST DATA
POINT FOR WHICH THE CANDIDATE FOR SMAX IS
LESS THAN OR EQUAL TO THE CURRENT SMAX.
THIS LOCATES THE CANDIDATE FOR NEW EYEPOINT
IF PIVOTING IS NECE~SARY.
IGRAZE :: I
IGRAIE IS THE INDEX OF THE RIGHTMOST DATA
POINT FOR WHICH THE CANDIDATE FOR SMIN IS
GREATER THAN OR EQUAL TO THE CURRENT SMIN
.J :: .J + 1

00::::0
C
C
r-

C
C

INCREMENT INDEX INTO OUTPUT ARRAYS
END OF INITIALIZATION

*

* * * * * * * * *

* *

*

* *

*

* * *

* * *

DETERMINE MAX AND MIN SLOPES FOR SEGMENT

C

0031
0032

55 CONTINUE

c

IF (I .EI). N) GO TO 705
TEST FOR END OF DATA WITHIN CURRENT SEGMENT
I :: 1+1

00:::::::
C

00:34

0035
C

0031:..
00:37
C

003::::
00::::9

C
C
C
C
r-

0040
C

C
C

INCREMENT INDEX INTO DATA ARRAYS
57 CONTINUE
DX:: XCI) - XEYE
DX AS BEFORE
IF (ITCH.GE.Z) EPSLN :: SGN*E(I)
TEMP1 :: (Y(I) + EPSLN - YEYE)/DX
TEMP1 IS A CANDIDATE FOR SMAX
TEST :: TEMP1 - SMAX
IF (SGN.LE.O.O) TEST:: -TEST
SGN WILL BE POS IF PREVIOUS SEGMENT
ENDS AT TOP OF TUNNEL, NEG IF PREVIOUS
SEGMENT ENDS AT BOTTOM OF TUNNEL
IF SGN IS NEG CONSIDER TUNNEL TO BE UPSIDE
DOWN FOR TESTS WITH TEMPl AND TEMP2.
IF (TEST) 75, 91, 9~:;
IF CANDIDATE FOR SMAX IS GE OLD SMAX,
THEN KEEP OLD SMAX. OTHERWISE CANDIDATE
BECOMES THE NEW SMAX. EPSLN IS NEG IF

195

196

Spring Joint Computer Conference, 1972

FORTRAN IV G LEVEL
C

19

STL

INITIAL EYEPOINT IS AT BOTTOM OF TUNNEL.
75 CONTINUE

0041
C
r
r
0042
004:3
0044
004~;

004t.
0047

0048
0049

r
C

0050
0051
0052
005::::

0054
0055

C
C
r
C
C
005l:;..
0057

005::::
0059
OOt.O

CANDIDATE FOR SMAX IS LESS THAN OLD SMAX.
TEST IF CANDIDATE IS ALSO LESS THAN OLD
SMIN.
IF SO END SEGMENT AT TOP OF TUNNEL.
TEST = TEMPl - SMIN
IF (SGN.LE.O.O) TEST = -TEST
IF (TE!::;T .LT. 0.0) GO TO lZ1
!::;MAX = TENPl
91 CONTINUE
IPIV = I
95 CONTINUE
TEMP2 = (Y(I) - EPSLN - YEYE)/DX
COMPUTE CANDIDATE FOR NEW SMIN AND CONPARE
WITH OLD MINIMUM SLOPE.
TEST = SMIN - TEMPZ
IF (SGN.LE.O.O) TEST = -TEST
IF <. TE~::;T) 9}, 99, 55
97 CONTINUE
TEST = TEMPZ - SNAX
IF (SGN.lE.O.O) TEST = -TEST
COMPARE NEW CANDIDATE FOR MIN SLOPE
WITH OLD NAX SLOPE.
IF NEW MIN IS
GREATER THAN OLD MAX CHECK IF PIVOT
IS POSSIBLE. OTHERWISE SET MIN SLOPE
TO NEW VALUE AND CONSIDER NEXT DATUM.
IF (TEST.GT.O.O) GO TO 101
st'll N = TEMP2
9'~ CONT I NUE
IGRAZE = I
GO TCI 55

C
C

C

*CHECK
* * *IF *PIVOT
* * * * * * * * * * * * * * * * *
POSSIBLE

C

0061
0062
C
C
C
C

006:::
0064
0065
OOt.,~.

00/:;..7
0068
OOt.9

0070

.-.

1_.

C

C
C

007 1

0072
0073
0074
0075

101 CONTINUE
IF (XEYE.EG!.X(IPIV}) GO TO 125
X(IPIV) IS THE X-COORD OF THE LAST DATUM
FOR WHICH THE CANDIDATE FOR SMAX WAS LESS
THAN OR EQUAL TO THE OLD SMAX.
IF XEYE IS
EQUAL TO X(IPIV) NO PIVOT IS POSSIBLE.
IF (ITCH.GE.2) EPSLN = SGN*E(IPIV)
XEYE = X(IPIV)
Y( IPIV) + EP~=;LN
YEYE
Sl"lIN =
Sl"lAX = (YINIT - YEYE)/(U(J-1) - XEYE)
IF (KEEP.GE.IPIV) GO TO 105
IT = IPIV - 1
TEMP2 = YEYE + EPSLN
COMPUTE THE NIN OF THE SLOPES FROM ALL
PRECEEDING DATA POINTS OF CURRENT SEGMENT
TO (X(IPIV),Y(IPIV) + 2*EPSLN). THIS WILL
BE A FIRST APPROXIMATION TO THE NEW SMAX.
DO 103 L = KEEP, IT
IF (ITCH.GE.2) TEMPZ
= YEYE + SGN*E(L)
TEMP1 = (Y<'L) - TEMPZ)/(X(L) - XEYE)
TEST = TEMP1 - S~~X
IF (SGN.LE.O.O) TEST = -TEST

Piecewise Linear Approximations of Fewest Line Segments

FORTRAN IV G LEVEL
0076
0077
0078
0079
0080

19

STL

IF (TEST.LT.O.O) SMAX :: TEMPl
103 CONTINUE
105 CONTINUE
IF (IPIV.GE.I-1) GO TO 57
IT = I - 2
C

C

COMPUTE THE MIN OF THE SLOPES FROM ALL
SUCCEEDING DATA POINTS OF THE CURRENT
C
SEGMENT TO (X(IPIV),Y(IPIV»
IF THIS IS
C
LESS THAN THE PREVIOUSLY COMPUTED VALUE,
C
THEN IT BECOMES THE NEW SMAX.
TEMP2 = YEYE - EPSLN
DO 111 L = IPIV,IT
DX = X(L+l) - XEYE
IF (ITCH.GE.2) TEMP2 = YEYE - SGN*E(L+l)
TEMPl ::: (Y(L+l) - TEMP2)/DX
TEST ::: TEMP1 - SMAX
IF (SGN.LE.O.O) TEST = -TEST
IF (TEST) 107, 109, 111
107 CONTINUE
:::;MAX ::: TENP1
109 CONTINUE
IPIV ::: L + 1
111 CONTINUE
GO TO 57

C

0081
00:32
008:3
0084
0085
0081:.,

00::::7

0089
0090
0091
0092
009:3
0094

c

* * * * * * * * * * * * * * * * * ~ * * * *
END CURRENT SEGMENT
121 CONTINUE
TEMP2 ::: SNIN
KEEP ::: IGRAZE
c
EQ OF THIS SEGMENT IS
c
Y :: SMIN * (X - XEYE) + YEYE
NEW EYEPOINT WILL BE AT THE INTERSECTION
C
ro
OF THIS LINE WITH THE LINE BETWEEN
( X( 1-1 ) , Y( 1-1 ) +EP:::;;LN) AND (X <. I ) ,y <. I) +EP::;:LN )
C
IF (ITCH.LE.l) GO TO 135
GO TO 129
C

r

0095

0097

0098
0099

C

0100
0101
0102
0103
0104
C

ro

C
C
C

0105
C

C

0106
0107
0108
o 10':t
0110
0111

125 CONTINUE
SGN ::: -::;GN
EP:::;LN ::: -EPSLN
TENP2 ::: SMAX
KEEP:: IPIV
EQUATION OF THIS SEGNENT IS
Y :: SMAX * (X - XEYE) + YEYE
NEW EYEPOINT WILL BE AT THE INTERSECTION
OF THIS LINE WITH THE LINE BETWEEN
(X( 1--1) ,y( 1-1 )-EPSLN) AND (X( I) ,Y( I )-·EPSLN)
IF (ITCH.LE.l) GO TO 135
IF ITCH.LE.l, THEN EPSLN IS A CONSTANT
NAMELY E(l).
129 CONTINUE
TEMPl ::: EPSLN - SGN*E(I-l)
GO TO 1:37
13~i CONT I NUE
TEMPl ::: 0.0
137 CONTINUE

197

198

Spring Joint Computer Conference, 1972

FORTf~~AN

IV

13

LE',jEL

01 1'-'.::..

1 '1

TEMP1 ::: (Y(I) - Y(I-l) + TEMP1)/
(X(I) - X(I-I»)
U(J) ::: (Y(I) + EPSLN - YEYE - TEMPl *
XCI) + TEMP2*XEYE)/(TEMP2 - TEMP1)
1
P( ,J-1) ::: TE\':1P2
PCM) IS THE SLOPE OF THE MTH SEGMENT
Q(J-l) ::: YEYE - TEMP2 * XEYE
Q(M) IS THE INTERCEPT OF THE MTH SEGMENT
YEYE::: TEMP2*U(J) + Q(J-l)
(XEYE,YEYE) WILL BE THE COORDINATES OF THE
NEW EYEPOINT.
XEYE WILL BE SET TO U(J).
IF SEGMENT ENDS AT BOTTOM OF TUNNEL, THEN
START NEXT SEGMENT WITH EYE POINT AT BOTTOM
OF TUNNEL.
IF SEGMENT ENDS AT TOP, START
NEXT WITH EYEPOINT AT TOP OF TUNNEL.
TEMP 1 ::: EP!:::LN
IF (ITCH.LE.l) GO TO 141
TEMP1 ::: EPSLN + (SGN*E(I-1) - EPSLN)*
1
(XCI) - U(.J»/(X(I) -, XCI-l»
1.41 CONTINUE
YINIT ::: YEYE - TEMP1 - TEMP1
IF APPRO X MUST BE CONTINUOUS, THEN U(J-l)
MAY HAVE TO BE RECOMPUTEDo
IN THIS CASE
ITCH WILL BE 1 OR :3.
IF (ITCH.NE.l.AND.ITCH.LT.3) GO TO 35
145 CONTINUE
IF (INIT.EQ.l) GO TO 35
IF INIT IS 1 THE CURRENT SEGMENT IS THE
INITIAL SEGt1ENT.
IF (XEYE.EQ.U(J-1» GO TO 35
IF XEYE IS STILL U(J-1), THEN NO PIVOT WAS
MADE AND U(J-1) NEED NOT BE RECOMPUTED.
U(J-1) :::(Q(J-2) - Q(J-1»/
(P(J-1) - P(J-2»
1
GO TO :::5
* * * * * * * * * * * * * * * * * * * * * *
END OF DATA ENCOUNTERED
1

01 1 ,-',
.~

01 14
C
01 15
C

01 1/;.

c·-'

C

r'-'
C

C
r'

01 17
01 1'-'1='
01 19
0120
0121
C
C
C
0122

012:3
0124
C

0125

c

c
0126
0127
C
C
C'

0128
0129

01::::0
01:31
01:32

01:3:3
01::::4

01:35
01 :36

705 CONTINUE
U(.J) ::: X(N)
P(J-l) ::: O.5*(SMAX + SMIN)
Q(J-l) ::: YEYE - XEYE * P(J-l)
IF (ITCH.EQ.l.0R.ITCH.GE.3) GO TO 145
777 CONTINUE
K:::.J-l
RETURN
END

Experimental results on a new computer method for
generating optimal policy variables in (s, S) inventory
control problem
by P. E. VALISALO, B. D. SIVAZLIAN and J. F. MAILLOT
University of Florida
Gainesville, Florida

computer and on the analog computer. The feasibility
of using analog computers was demonstrated in a set of
experiments published in 1970 by Sivazlian and
Valisalo. 5 By using dimensional analysis and using
numerical inversion techniques for Laplace transforms,
Sivazlian4 generated a set of graphs for the case of
gamma distribution demand with integer order, to
obtain the optimal values of Sand Q for all possible
values of input variables. The computational feasibility
of the problem was also discussed.
Although both analog and digital computer techniques proved successful, certain computational
deficiencies were encountered in both methods. In
using analog computers, experimental errors were
generated when increasing the number of integrators.
Further the derivation of results for complex demand
distrib~tions was limited by the capability of the
analog computer system. In using digital computation,
the discretization of the problem and the numerical
method utilized could generate solution instability.
These two deficiencies were ultimately resolved by
combining the conceptual basis of analog computation
with the capacity and speed of digital computers by
using the Continuous Simulation and Modeling Programming (C.S.M.P.) on the IBM 360/65 digital
computer. The C.S.M.P. is a simulation language which
works on block diagrams as an analog computer does
but which utilizes a digital program. The present paper
presents preliminary results obtained using this computation technique and discusses some inherent merits
of this method.

INTRODUCTION
The problem of developing a computable solution to
the optimal periodic review stationary (S, S) inventory
control problem has not received the same level of
attention as the theoretical works first initiated in 1951
by the well-known paper of Arrow, Harris, Marschak. 1
Even for some of the simplest situations, perhaps
closest to practice, involving a fixed set-up cost, and a
linear holding and shortage cost, the solution to the
mathematical problem of determining the optimal
values of Sand S to minimize the total expected cost
per period, requires the formal solution of an integral
equation of the Volterra type and an optimization
problem of a fairly complex objective function involving the decision variables Sand S.
Explicit theoretical solutions for sand S can be
obtained as computable formulas for some very simple
demand distributions as for example the negative
exponential distribution. Approximations to the optimal
solutions were proposed by Roberts 2 in 1962. In 1965,
Veinott and Wagner6 developed an algorithmic procedure applicable to instances when the demand
distribution is described by a discrete random variable;
the study fails to discuss the computational efficiency
of the algorithm and its usability in practice particularly
in relation to the large number of input variables (at
least five) which are necessary to compute a single pair
of optimal values of (S, S). In practice, this facet of the
computational problem cannot be ignored since inventory control involves usually several thousand of
commodities, e~ch commodity necessitating frequent
updating of the set of input variables due to changes in
economic or other conditions. In 1968, Sivazlian3
derived a set of equations to compute the optimal
values of Sand Q= S - S and developed conceptual
approaches to solve these equations on the digital

THEORETICAL CONSIDERATIONS
A brief discussion of the theoretical results as obtained by Sivazlian3 is necessary.

199

200

Spring Joint Computer Conference, 1972

TABLE I

Xl2 = REALPL(O. ,P, XII)
XI3=REALPL(0. ,P,XI2)
XI4=REALPL(0. ,P,X13)
XI5=REALPL(0. ,P,XI4)
XI6=REALPL(0. ,P,XI5)
XI7=REALPL(0. ,P,XI6)

****CONTINOUS SYSTEM MODELING PROGRAM****
***PROBLEM INPUT STATEMENTS***
INITIAL
P=IO.jX
A=XjIC.
PARAM S=(O. ,2. ,4. ,6. ,8., 12.),X=19.
DYNAMIC
XLO=O.
XLI =REALPL(A,P,XLO)
XL2 = REALPL(O. ,P, XLI)
XL3 = REALPL(O. , P, XL2)
XL4 = REALPL(O. , P, XL3)
XL5 = REALPL(O. , P, XL4)
XL6 = REALPL(O. ,P, XL5)
XL7 =REALPL(O., P, XL6)
XL8=REALPL(0. ,P,XL7)
XL9 = REALPL(O. , P, XL8)
XLlO = REALPL(O. ,P, XL9)
XLll =REALPL(O. ,P,XLlO)
XLI2=REALPL(0. ,P,XLll)
XLI3=REALPL(0. ,P,XLI2)
XLl4 = REALPL(O. ,P, XLI3)
XLI5=REALPL(0. ,P,XLI4)
XLI6 = REALPL(O. ,P, XLI5)
XLI7=REALPL(0. ,P,XLI6)
XLl8 = REALPL(O. ,P, XLI7)
XLI9=REALPL(0. ,P,XLI8)
XLD = 11. *XLI9
SM=XI9-XL
XL=INTGRL( -10. ,XLD)
PROCED C=BLOC(TIME,S)

XI8=REALPL(0. ,P,XI7)
XI9 = REALPL(O. ,P, XI8)
BM=INTGRL(O. ,SMI)
FINISH SM = O.

Consider the periodic review inventory control
problem of a single commodity system where the
demand per period for the commodity is described
by a continuous random variable ~ (0 < ~ < 00) with
probability density function ¢(O identically and
independently distributed from period to period. Assume
that the following cost components affect the operation
of the system: a fixed order cost K, a holding cost and
a shortage cost. Complete backlogging is allowed and
delivery of orders is immediate. Let L (x) be the expected holding and shortage cost over one period when
the stock level at the beginning of the period following
a decision is x. An (S, S) policy is in effect, that is,
whenever the stock level at the beginning of a period
lies between Sand S, no order is placed, and whenever
the stock level falls below S, it is brought up to S. It
can be shown3 ,4 that for S 2:: 0 the values of Sand
Q = S - S which minimize the total expected cost per
period for the stationary inventory system are solutions
to the system of equations
(1)

m(S, Q) =0
and

IF(TIME-S)I,2,2
C=O.
GOT03
2 C=1.
3 CONTINUE
ENDPRO

fQ m(S, x) dx=K

1

SMI=C*SM
Xl = REALPL(O. ,P, SMI)
X2=REALPL(0. ,P,XI)
X3 = REALPL(O. ,P ,X2)
X4=REALPL(0. ,P,X3)
X5=REALPL(0. ,P,X4)
X6=REALPL(0. ,P,X5)
X7=REALPL(0. ,P,X6)
X8 = REALPL(O. ,P ,X7)
X9 = REALPL(O. ,P, X8)
XIO=REALPL(O. ,P,X9)
XU = REALPL(O. ,P, XIO)

(2)

o

where m (S, x) satisfies the Volterra integral equation

2 (6+x)

m(.6 ,x)

+

-1

~(s)

Figure I-Feedback system simulating the equation
m(S, x) = - l(S

+ x) + 1:1) m(S, x

- u) cp (u) du

Experimental Results on a New Computer Method

Figure 2-Flow chart for the digital simulation when h
p = 10, n = 4 and a = .40

201

1,
100

Q

m(S, x) =-L'(S+x)+

IX m(S, x-~)cp(~) d~

(3)

Figure 4-C.S.M.P. results for m(S, x) when n = 1, a = .1 and
increments of .01

o

Let

p is the unit shortage cost. Differentiating (4) with
respect to x, we obtain the following expression for l(x) :

l(x) =L'(x)
l(s, S) =£{l(S+x)}

l(x) = (h+p)
([>(s) =£{cp(x)}

We shall restrict our attention to the case when

Then, from taking the Laplace transforms on both sides
of (3) and solving for fii(S, s) we obtain

Thus, the integral equation (3) can be solved using the
feedback system of Figure 1.
The optimal values Sand Q can be determined by
observing that the output function m (S, x) must
satisfy equations (1) and (2). The interesting practical
case which was investigated was the following:
Assume. proportional holding and shortage costs,
measured at end of period, then

IX (x-u)cp(u) du+p f""
o

cp ( .) is a gamma density function of integer order n,

i.e.,
cp(~)

) _ -l(s, s)

m S, s - 1- ([> ( s )

L(x) =h

(5)

o

fii(s, S) =£{m(S, x)}

_(

IX cp(u) du-p

(u-x)cp(u) du

x

(4)
In inventory terminology, h is the unit holding cost and

(a~) n-l

= (n-1)!

ae-a~a>O,

n=1, 2, ...

(6)

Note then that in the s domain
([>(s) =an/(s+a)n

n=1, 2,...

(7)

THE CONTINUOUS SYSTEM MODELING
PROGRAM AND EXPERIMENTAL RESULTS
For illustrative purpose the numerical values of h = 1,
p = 10 and a = .1 On were used. The selection of this
particular value of a yields an expected demand of 10
units per period irrespective of the order of the gamma
distribution. In Reference 5 a parallel connection was
used to generate the gamma distribution. In contradistinction, a series connection is used in this paper
involving a cascade of n filters of a/ (s+a). Thus, the

103

Q

Figure 3-Analog equivalent of Figure 2

Figure 5-C.S.M.P. results for m(S, x) when n = 4, a = 4 and
increments of .01

202

Spring Joint Computer Conference, 1972

TABLE II-n = 1. Comparison Data for Alternative Methods Used in Solving for Q and K
Q

S

Analog

0

K

Digital
1.0 (inc.)

Digital
0.1 (inc.)

Digital
0.01 (inc.)

100.0

100

100

Analog

Digital
1.0 (inc.)

Digital
0.1 (inc.)

500

499.9

499.4

Digital
0.01 (inc.)

2

78.9

81

79

80

315.7

332.6

319.2

320.1

4

62.9

64

63

63

200.6

211.0

202.3

203.1

6

49.7

51

50

50

124.9

132.0

126.3

126.8

8

38.9

40

39

39

76.4

81.0

77.4

77.7

12

22.8

23

23

23

26.2

28.0

26.6

26.8

$ 2.45

$ 3.05

$ 8.52

Computing Cost

S, then c = -1 thus initiating the feedback loop. At the
same time, the last integrator marked 1/s is turned on
on operate mode. The logic part has been left out in
Figure 3 for the sake of simplicity and because it has
well been defined in Reference 5. The C.S.M.P. program
for n= 1 to n= 19 (Table I) ,vas so designed as to print
out the Q and K values when the function m (S, x)
reaches zero.

entire problem was to be redesigned in such a way that
the number of feedback loops as used in the original
analog circuitry5 was eliminated; instead, a serial first
order loop approach was implemented. Figure 2
illustrates the flow chart of the digital simulation when
n=4, while Figure 3 is the analog equivalent of Figure
2. Referring to Figure 2, when time is less than S, c = 0
and the feedback loop is idle. When time is greater than

TABLE III-n=4. Comparison Data for Alternative Methods Used in Solving for Q and K
K

Q
S

Analog

Digital
1.0 (inc.)

Digital
0.1 (inc.)

Digital
0.01 (inc.)

Analog

Digital
1.0 (inc.)

0

102.9

103

103

103

528.5

537.4

537.4

537

2

81.8

83

81

81

338.4

354.5

338.3

339.5

4

60.0

62

60

60

189.4

201.5

190.2

191.3

6

41.6

43

41

41

94.1

100.8

94

94.6

8

26.5

27

26

26

41.1

44.2

40.8

41.1

12

7.1

7

6

6

5.6

5.8

5.2

5.3

Computing Cost

$ 2.59

Digital
0.1 (inc.)

$ 3.66

Digital
0.01 (inc.)

$ 12.37

Experimental Results on a New Computer Method

DISCUSSION
A significant marked improvement results for the
output function m (S, x) ; this is illustrated in Figures
4, 5 and 6 for values of n= 1, 4 and 19 respectively.
The fact that the function m (S, x) can be generated
for a gamma distribution of an order as high as n= 19
is significant, particularly in the context of previous
work.
Tables II and III report respectively some of the
numerical results for n = 1 and n = 4 obtained from
analog computation and digital computation using
C.S.M.P. Increments of 1.00, .10 and .01 were used for
comparison purposes.
I t may be noticed that the order of magnitude of n
depends on the size of the analog installation, 5 whereas
the digital does not seem to have any limitations on the

103
Q

Figure 6-C.S.M.P. results for m(S, x) when n = 19, a = 1.9 and
increments of .01

203

value of n at all. It is evident that the advantage of the
analog system is not present in the discretized problem
particularly when an immediate visual or graphical
picture is desired for m (S, x) .
REFERENCES
1 K J ARROW T HARRIS Y MARSHAK
Optimal inventory policy
Econometri,ca 19 1951 pp 250-272
2 D M ROBERTS
A pproximations to optimal policies in a dynamic inventory
model
Studies in Applied Probability and Management ScienceK J Arrow S Karlin H E Scarf eds Stanford University
Press 1962 pp 207-229
3 B D SIVAZLIAN
Optimality and computation of the stationary (s, S) inventory
control problem
Technical Report No 7 Project THEMIS Department of
Industrial and Systems Engineering The University of
Florida Gainesville Florida May 1968
4
Dimensional and computational analysis in stationary
(s, S) inventory problems with gamma distributed demand
Management Science Vol 17 1971 pp 307-311
5
P E VALISALO
The utilization of a hybrid computer system in solving for
optimal policy variables in inventory problems
Proceedings of the Sixth AICA Congress Munich Germany
August 31-September 4 1970
6 A F, VEINOTT JR H M WAGNER
Computing optimal (s, S) inventory policies
Management Science Volume 111965 pp 525-552

Bounds on multiprocessing anomalies
and related packing algorithms
by R. L. GRAHAM
Bell Telephone Laboratories, Inc.
Murray Hill, New Jersey

essential to have on hand the worst examples one can
think of before conjecturing and (hopefully) proving
bounds on worst-case behavior, numerous such examples will be given throughout the text.
Before concluding this section} it seems appropriate
to make a few remarks concerning the general area of
these topics. Recent years have seen the emergence of
a vital and important new discipline, often called
"analysis of algorithms." As its broad objective, it
seeks to obtain a deeper understanding of the nature of
algorithms. These investigations range, for example,
from the detailed analysis of the behavior of a specific
sorting routine, on one hand, to the recent negative
solutiont to Hilbert's Tenth Problem by j\'iatijasevic 37
and Julia Robinson,43 on the other. It is \vithin this
general framework that the present. discussion should
be viewed.

INTRODUCTION

It has been known for some time that certain rather
general models of multiprocessing systems frequently
exhibit behavior which could be termed "anomalous,"
e.g., an increase in the number of processors of th2
system can cause an increase in the time used to complete a job. 42 ,36,2o In order to fully realize the potential
benefits afforded by parallel processing, it becomes important to understand the underlying causes of this
behavior and the extent to which the resulting system
performance may be degraded.
In this paper we survey a number of theoretical results obtained during the past few years in connection
with this topic. We also discuss many of the algorithms
designed either to optimize or at least to improve the
performance of the multiprocessor system under
consideration.
The performance of a system or an algorithm can be
measured in several rather different ways.5 Two of the
most common involve examining the expected behavior
and the worst-case behavior of the object under consideration. Although knowledge of expected behavior
is generally more useful in typical day-to-day applications, theoretical results in this direction require assumptions concerning the underlying probability distributions of the parameters involved and historically
have been extremely resistant to attack.
On the other hand, there are many situations for
which worst-case behavior is the appropriate measure
(in addition to the fact that worst-case behavior does
bound expected behavior). This type of analYEis is currently a very active area of research, and theoretical
insight into the worst-case behavior of a number of
algorithms from various disciplines is now beginning to
emerge (e.g., see References 7, 14, 15, 19,20,21,26, 27,
29, 32, 33, 44, 47, and especially Reference 41.) It is
this latter measure of performance which will be used
on the models and algorithms of this paper. Since it if:!

A GENERAL MULTIPROCESSING SYSTEM
Let us suppose we have n (abstract) identical processors Pi, i = 1, ... , n, and we are given a set of tasks
::I = {Tli ... , T r} which is to be processed by the Pi.
Weare also given a partial order t t < on ::I and a function ,u:::I~(0, 00). Once a processor Pi begins to execute
a task Tj, it works without interruption until the completion of that task, t t t requiring altogether ,u (T j ) units
of time. It is also required that the partial order be
respected in the following sense: If T i < T j then T j cannot be started until Ti has been completed. Finally,
we are given a sequence L = (T io . . . , T i r ) , caJled the

t Which roughly speaking shows that there is no universal
algorithm for deciding whether a diophantine equation has
solutions or not.
tt See Reference 31 for terminology.
ttt This is known as nonpreemptive scheduling as opposed to
preemptive scheduling in which the execution of a task may be
in terrupted. 5
205

206

Spring Joint Computer Conference, 1972

~O

T1/3 0

T9/ 9

T1

T3

T9

3

2

9

T5/4

T2/2

Ts/4
T3/ 2

0':

T7/4
Ta/4

T4/ 2

T2

T5

¢1

2

4

4

T4

T6

Ts

¢2

2

4

4

4

Figure 3-The timing diagram D' when L' is used

Figure 1-A simple graph G

(priority) list (or schedule) consisting of some permutation of all the tasks 3. The Pi execute the T j as follows:
Initially, at time 0, all the processors (instantaneously)
scan the list L from the beginning, searching for tasks
Ti which are "ready" to be executed, i.e., which have no
predecessors under <. The first ready task T j in L
which Pi finds immediately begins to be executed by
Pi; Pi continues to execute T j for the p,(Tj) units of
time required to complete T j • In general, at any time
a processor Pi completes a task, it immediately scans
L for the first available ready task to execute. If there
are currently no such tasks, then Pi becomes idle. We
shall also say in this case that Pi is executing an empty
task which we denote by 'P (or 'Pi). Pi remains idle until
some other P k completes a task, at which time Pi
(and, of course, P k ) immediately scans L for ready
tasks which may now exist because of the completion
of T j • If two (or more) processors both attempt to
start executing a task, it will be our convention to
assign the task to the processor with the smaller index.
The least time at which all tasks of T have been completed will be denoted by w.
We consider an example which illustrates the working of the preceding multiprocessing system and various
anomalies associated with it. We indicate the partial
order < on T and the function p, by a directed graph t

0:

T,

T9

3

9

T2

T5

T7

2

4

4

T3

T6

Ts

2

4

4

Figure 2-The timing diagram D for G

t For terminology in graph theory, see Reference 23.

G ( <, p,). In G ( <, p,) the vertices correspond to the T i
and a directed edge from Ti to T j denotes T i < T j. The
vertex T j of G( <, p,) will usually be labeled with the
symbols Tj/p,(Tj). The activity of each Pi is conveniently represented by a timing diagram D (also
known as a Gantt chart. 2 D consists of n horizontal
half-lines (labeled by the Pi) in which each line is a
time axis starting from time and is subdivided into
segments labeled according to the corresponding
activity of the Pi. In Figure 1 we show a simple graph

°

G.
In Figure 2, we give the corresponding timing diagram
D assuming that the list L= (TI' T 2 , ••• , T 9 ) is used
with·three processors. The finishing time is w = 12.
Note that on D we have labeled the intervals above by
the task and below by the length of time needed to
execute the task.
It is evident from the definition of w that it is a
function of L, p" < and n. Let us vary each of these
four parameters in the example and see the resulting
effect this variation has on w.
(i) Replace L by L' = (Tl; T 2, T 4 , T 5, T 6 , T a, T 9,
T 7 , T s), leaving p" < and n unchanged (Figure
3). For the new list L', w'=w'(L', p" <, n) =14.
(ii) Change < to <' by removing T4 < T5 and
T 4  0) by varying anyone of the three parameters L, J.I..
and <. Note that (2) implies that using the worst
possible list instead of the best possible list still only
results in an increase in w of at most a factor of 2-1/n.
When n = 1, (1) implies w'l w~ 1 which agrees with
the obvious fact that the aforementioned changes in
L, J.I.., < and n can never cause increase in the running
time when compared to that for single processor. On
the other hand, when n> 1 then even a large increase

T

02

T

1

I

'°

,

'f':

T 1004

1<1>

1000

€

w=1000+2£

Figure 12-2 processors are used to execute the tasks of G

fSince a partial order on J is a subset of J X J, <' C < has the
obvious meaning.
tt Recent examples of M. T. Kaufman (personal communication)
show that in many cases the bounds of (1) and (2) can be achieved
even when J.!(T) = 1 for all T.

PI
P2

D':

P3

T,

T4

T lOO4

C

1

1000

T2

T5

<1>

C

1

1000

T3

Ts

c

1

11000 <1> T 1OO3

€

1

<1>

1000

w'=1001+€

<1>

1000

Figure 13-1000 processors are used to execute the tasks of G

SOME SPECIAL BOUNDS
We next consider results arising from attempts at
finding lists which keep the ratio of wiWo close to one.
Since for any given problem, there are just finitely
many possible lists then one might be tempted to say:
"Examine them all and select the optimum." Not much
insight is needed, however, to realize that due to the
explosive growth of functions such as n!, this is not a
realistic solution. What one is looking for instead is an
algorithm which will guarantee that wi Wo is reasonably
close to one provided we are willing to expend an appropriate amount of energy applying the algorithm. Unfortunately, no general results of this type presently
exist. There is a special case, however, in which steps in
this direction have been taken. This is the case in which
< is empty, i.e., there are no precedence constraints
between the tasks. We shall restrict ourselves to this
case for the remainder of this section.
Suppose, for some (arbitrary) k, the k tasks with the
largest values of J.I.. have been selected t and somehow

t i.e., holding a processor idle when it could be busy and interrupting the execution of a task before completion.
t Recent results of Blum, Floyd, Pratt, Rivest and Tarjan41 allow
this to be done in no more than 6r binary comparisons where r
denotes the number of tasks.

Bounds on lVlultiprocessing Anomalies

arranged in a list Lk which is optimal with respect to
this set of k tasks (i.e., for no other list can this set of
k tasks finish earlier). Form the list L(k) by adjoining
the remaining tasks arbitrarily but so that they follow
all the tasks of L k • Let w (k) denote the finishing time
using this list with a system of n processors. If Wo denotes
the global optimum, i.e., the minimum possible finishing time over all possible lists then the following result
holds.

w(k) <1+ I-I/n
Wo 1+ [k/n]

°1

°2n-2

°2

°2n-3

Do:

wo"'3n

P

«n-2

n-2

Pn- 1

Pn

°n+1

an

°n-1
a2n

°2n-1

°2n+l

n

for 1:=:;i:=:;k+1,

order for w(k) to be assured of being within 10 percent
of the minimum value Wo, for example, it suffices to
optimally schedule the largest 9n tasks.
Another heuristic technique" for approximating the
optimal finishing time Wo is to use the "decreasing"
listt L*= (Til' T i2 , ... ) where Jl(TiJ '2.Jl(T i2 ) '2. ....
The corresponding finishing time w* satisfies the following inequality.

I

for k+2:=:;i:=:;k+l+n(n-I).

Theorem. 20

(3)

For k=O(mod n) this bound is best possible.
For the case of k=O(mod n) the following example
establishes the optimality of the bound from below.
For 1:=:;i:=:;k+1+n(n-1), define Jl(T i ) by
Jl(T i ) =

{

For this set of tasks and the list L (k) = (Tl' ... , T k ,
T k +2, ... , T k+1+n(n-l) , T k+1 ) we have w(k) =k+2n-1.

Pi
P2

0*: P3

Pn

P2

Figure I5-The timing diagram Do using an optimal list

Theorem. 20

Pn - 1

Pi

209

°1

°2n

°2

a 2n - 1

°3

°2n+1

°2n-2

°n-1

On+2

On

°n+l

w*= 4n-1

Figure I4-The timing diagram D* using the decreasing list L*

This bound is best possible.
For n= 2, (6) yields a bound of 7/6 which is exactly
the ratio obtained from the canonical example vdth
five tasks having execution times of 3, 3, 2, 2 and 2.
More generally, the follmving example shows that (6)
is exact. ;) consists of r = 2n+ 1 independent tasks Tk
with Jl(Tk) =ak=2n-[(k+I)/2] for l:=:;k:=:;2n and
Jl(T2n+1 ) =a2n+l=n (where [x] denotes the greatest
integer not exceeding x). Thus

= (2n-l, 2n-l, 2n-2, 2n-2, . .. ,n+l, n+l, n, n, n)

In Figure 14, ;) is executed using the decreasing list
L* = (Tl' T 2, ... , T 2n+1 ).
In Figure 15,;) is executed using an optimal list.

Since wo=k+n, and k=O(mod n) then
w(k)=I+ l-l/n
Wo
l+[k/n]

as asserted.
For k=O, (3) reduces to (2) while for k=n we have
w(n)/wo:=:;3/2-1/2n.

(6)

w* / wo:=:; 4/3 -1/3n.

(4)

The required optimal assignment of the largest n tasks
to the n processors is immediate-just assign each of
these tasks to a different processor. For k = 2n, .(3)
reduces to
(5)
w(2n)/wo:=:;4/3-1/3n,
a bound which will soon be encountered again.
An important property of (3) is that the right-hand
side tends to I as k gets larger compared to n. Thus, in

T1

T1

6

6

cp

T2

T3

T2

T4

3

3

3

2

T4

T5

T3

2

2

3

Wo =6

w(6) =7

Figure I6-Example illustrating difference between L* and L(2n)

t Such a list can be formed in essentially no more than r log r Ilog 2
binary comparisons. 33

210

Spring Joint Computer Conference, 1972

It is interesting to observe that although the righthand sides of (5) and (6) are the same, arranging the
tasks by decreasing execution time does not necessarily
guarantee that the largest 2n tasks will be executed
optimally by L*. An example showing this (due to
J. H. Spencer (personal communication» is given in
Figure 16. The execution times of the tasks are
(6,3,3, 2, 2, 2) and three processors are used.
The following result shows that if none of the execution times is large compared to the sum of all the execution times then w* cannot be too far from woo
Theorem. IS

If

problems seems remote indeed. There are several special
cases, however, for which such algorithms exist.
For the case when Jl. (T) = 1 for all tasks T and < is a
forest, t Hu28 has shown that the following algorithm
generates an optimal list Lo.
(i) Define the level A(T) of any terminal t t task T
to be 1.
(ii) If T' is an immediate successor of T, define
A(T) to be A(T') +1.
(iii) Form the list Lo= (Til' T i2 , ... , Ti r ) in order of
decreasing A values, i.e., A(Til ) C:.A(Ti2) C:. ••• C:.
A(Tir ) •
Theorem. 2s

< is empty and

Lo is an optimal list when Jl. (T) = 1 for all T and

max Jl. (T) / ~ Jl. (T) ~ (3

< is a tree.

T

then
(7)
Another approach is to start with a timing diagram
resulting from some arbitrary list and then make pairwise interchanges between tasks executed by pairs of
processors which decrease the finishing time, until this
can no longer be done. If w' denotes the final finishing
time resulting from this operation then it can be shown18
that
w'/wo~2-2/(n+1)

(8)

and, furthermore, this bound cannot be improved.
SOME ALGORITHMS FOR OPTIMAL LISTS
There seems little doubt that even for the case when
is empty, Jl.(T) is an integer, and n=2, any algorithm which determines an optimal list for any set of
tasks must be essentially enumerative t in its computational efficiency. This problem can be rephrased as
follows:

<

Given a sequence S= (81, ... ,8 r ) of positive integers
find a choice of ei = ± 1 such that

The only other case for which an efficient algorithm
is currently known is when Jl. (T) = 1 for all T, n = 2 and
< is arbitrary. In fact, two quite distinct algorithms
have been given. One of these, due to Fujii, Kasami
and Ninomiya ll ,12 is based on a matching algorithm for
bipartite graphs of Edmonds 8 and appears to be of
order O(r3). The other, due to Coffman and Graham,3
uses the following labeling technique:
Assuming there are r tasks, each task T will be assigned a unique label a(T)e{1, 2, ... ,r}.
(i) Choose an arbitrary terminal task To and define
aCTo) = 1.
(ii) Assume the values 1, 2, ... , k-1 have been
assigned for some k~r. For each unlabeled task
T having all its immediate successors already
labeled, form the decreasing sequence M (T) =
(ml' m2, ... , m5) of the labels of T's immediate
successors. These M (T) are lexicographicallyt
ordered. Choose a minimal M (T') in this order
and define a (T') = k.
(iii) Form the list L*= (Til' T i2 , ... , TiT) according to decreasing a values, i.e., a(Ti l ) >
a(Ti2) > ... >a(Tir ).
Theorem. 3

L* is an optimal list when Jl. (T) = 1 for all T and
n=2.

is minimized.
Thus any hope for efficient algorithms which produce
optimal schedules for more general multiprocessing

t More precisely, the number of steps it may require cannot be
bounded by a fixed polynomial in the number of bits of information needed to specify the input data.

t This means that every task T has at most one immediate
successor T', i.e., T < T' and for no Til is T < Til < T'. Actually, by adding a dummy task To preceded by all other tasks, <
can be made into a tree, without loss of generality.
tt i.e., a task with no successor.
t i.e., dictionary order, so that (5, 4, 3) precedes (6, 2) and
(5, 4, 3, 2).

Bounds on lVlultiprocessing Anomalies

This algorithm has been shown to be of order 0 (r 2 )
and so, in a sense, is best possible since the partial
order < can also have this order of number of elements.
The increase in complexity of this algorithm over
Hu's algorithm seems to be due to the greatly increased
structure an arbitrary partial order may have when
compared to that of a tree. Even relatively simple
partial orders can defeat many other algorithms which
might be thought to be optimal for this case. The example in Figure 17 illustrates this.
An optimal list for this example is L*= (T10 , T 9 , • • • ,
T 1 ) where we assume p,(Ti) = 1 for all i. Any algorithm
which allows TlO not to be executed first is not optimal, as,
for example, executing tasks on the basis of the longest
chain to a terminal task (i.e., according to levels), or
executing tasks on the basis of the largest number of
successors.
For n>2 and p,(T) = 1 for all T, the algorithm no
longer produces optimal lists as the example in Figure 18
shows.
It would be interesting to know the worst-case behavior
of the lists produced by this algorithm for general n.
The current state of affairs here seems to be similar
to that of the job-shop scheduling problem5 ,30 for which
optimal schedules can be efficiently generated when
n = 2, while for n> 2 no satisfactory algorithms are
known.

211

Tg

Ta

Figure 18-A counterexample to optimality when n

=3

L which (approximately) minimizes the finishing time
w. We now invert this question as follows: For a fixed

A DUAL PROBLEM
Up to this point, we have generally regarded the
number of processors as fixed and asked for the list

Tg

deadline w*, we ask for a list L which when used \yill
(approximately) minimize the number of processors
needed to execute all tasks by the time w*. Of course,
the two questions are essentially equivalent, and so no
efficient algorithms are known for the general case. t
Nevertheless, a number of recent results are now available for several special cases and these will be the subject of this section.
We first make a few remarks concerning the general
case. It is not hard to see that if A* denotes the length
of the longest chain t t in the partially-ordered set of
tasks 3, then we must have W*~A*. Otherwise, no number of processors could execute all tasks of 3 in w* time
units. On the other hand, if sufficiently many processors
are available then all tasks of 3 can be executed in
time A*. In fact, if m* denotes the maximal number of
mutually incomparable t tasks of 3, then it is never
necessary to have more than m* processors in the system since clearly no more than m* can be in operation
at anyone time.

t Both of these questions are raised in Reference 10.
tt i.e., a sequence T i1 < T i2 < ... < Tim with Lk IJ. (T iJ

Ta
Figure 17-A useful graph for counterexamples

maximal.
t T i and T i are incomparable if neither T i
hold.

<

T i nor T i

<

Ti

212

Spring Joint Computer Conference, 1972

For the case in which J.I. (T) = 1 for all tasks T, lower
bounds for both problems are provided by results of
HU. 28 In this case, if A(T) denotes the level of a task
T as defined in the preceding section, let m denote the
maximum level of any task in 3 and for 0 ~ k ~ m, let
A(k) denote the number of tasks having level strictly
greater than k.

this problem, but the amount of computation necessary
soon becomes excessive as the size of the problem grows.
Several heuristic algorithms have been suggested9 ,15,4o
for approximating No. One of these, which we call the
"first-fit" algorithm, is defined as follows: For a given
list L= (ai2' ai2' ... , air), the aik are successively assigned in order of increasing k, each to the box B j of
lowest index into which it can validly be placed. The
number of boxes thus required will be denoted by
NFF(L) , or just N FF , when the dependence on L is
suppressed.
If L is chosen so that ail ~ ai2 ~ ••• ~ air then the
first-fit algorithm using this list is called the "first-fit
decreasing" algorithm and the corresponding NFF(L)
is denoted by N FFD.
Instead of first-fit, one might instead assign the next
ak in a list L to the box in which the resulting unused
capacity is minimal. This is called the "best-fit"
algorithm and N BF will denote the number of boxes
required in this case. The corresponding definitions of
"best-fit decreasing" and N BFD are analogous to first-fit
decreasing and N FFD and are omitted.
One of the first questions which arises concerning
these algorithms is the extent by which they can ever
deviate from No. Only for N FF is the behavior accurately
known.

Theorem. 28

Theorem. 47 ,15

16

10(X5)

50

6(X7)

42

34

34

51

51

(X 3)

(X 7)

51
(X5)

Figure 19-An example with N FF IN 0

(X10)

= 17/10

If n processors can execute 3 with finishing time w
then
(9)
w~ max (k+A(k)/n).
oSk'::;m

For other early results dealing with these and related
problems, the reader may consult References 1, 5, 13,
24, 38, 42, 45, and 46.
For the remainder of this section, we restrict ourselves
to the special case in which there are no precedence
constraints on the tasks. In this case the second problem
becomes a special case of the one-dimensional cutting
stock problem15 ,17 as well as a special case of the assembly-line balancing problem. 5
We can also think of the problem in the following
terms. Weare given a set of objects i,O with Oi having
weight ai=}.t(T i ), l~i~r. We have at our disposal an
unlimited supply of boxes Bj, each with a maximum
capacity of w* units of weight. It is required to assign
all the objects to the minimum number No of boxes
subject to the constraint that the total weight assigned
to any box can be no more than w*. In this form, this
question takes the form of a typical loading or packing
problem. 9 Integer linear programming algorithms have
been given9 ,16,17,25 for obtaining optimal solutions for

For any e>O, if No is sufficiently large then

NFF/No < 17/10+e.

(10)

The 17/10 in (10) is best possible. An example for
which NFF/No= 17/10 is given in Figure 19 (where

2.0

~ 1.5
0::

.-_...----

1. 0 "---1...&..1-'-1--1. ---'-1-------'-1 1 1
"'7654 3 2
---1.

a
Figure 20-The function R(a)

Bounds on l\1ultiprocessing Anomalies

w* = 101). The multiplicity of types of boxes and objects are given in parentheses.
For any e>O examples can be given with NFF/No~
17/10-e and No arbitrarily large. It appears, however,
that for No sufficiently large, N FF/ No is strictly less
than 17/10.
In order to achieve a ratio NFF/No close to 17/10 it is
necessary15 to have some of the Oli exceed w* /2. Conversely, if all Oli are small compared to w* then NFF/No
must be relatively close to one. This is stated precisely
in the following result.

.1
5

2

"5

~+2£
5
(X5n)

NFFD=11n:

1-8

£

5£

2

!-£

2

(X5)

(X5n)

(Xn)

5"
(X5n)

The right-hand side of (11) cannot be replaced by any
smaller function of a.
We denote the right-hand side of (11) by R(Ol) and
illustrate it in Figure 20.
It is conjectured15 that the worst-case behavior of
NBF/No is the same as that of NFF/No but this has not
yet been established. It is known that R(Ol) is also a
lower bound for NBF/No when max Oli~OlW*.
As one might suspect, N FFD/ No cannot differ from
1 by as much as N FF/ No can. This is shown in the
following result.

(X5n)

5"

~+2£
5

Suppose max Oli/W*~Ol. Then for any e>O, if No is
sufficiently large then
(11)

2

5"

~-2£
Theorem. 15

213

Figure 22-An example with NFFD/NBFD

= 11/10 and No large

Theorem. 15

For any E>O, if No is sufficiently large then

N FFD/ No < 5/4+e.

(12)

The example in Figure 21 shows that
NFFD/No~ 11/9

(13)

is possible for No arbitrarily large. It is conjectured
that the 5/4 in (12) can be replaced by 11/9; this has
been established 15 for some restricted classes of Oli.
The preceding remarks also apply, mutatis mutandis,
to the ratio N BFD/ No. This is implied by the following
somewhat surprising result.

1_ 2 £
4

~-28

Theorem. 15

1+ 28

4

1+
2£
4
(X6n)

(X 3n)

88

1.- 28
4

t- 2

£

1

4- 2 £
*-2E
(X6n)

(X2n)

(X 3n)

Figure 21-An example with NFFD/No = 11/9 and No large

If max Oli/W* ~ 1/5 then N FFD = N BFD.
The quantity 1/5 above cannot be replaced by any
smaller number as the example in Figure 22 shows.
This example raises the whole question concerning
the extent by which the numbers N FF, N BF, N FFD and
N BFD may differ among themselves (assuming that No
is large). The example in Figure 22 shows that
NFFD/NBFD~II/10 is possible for arbitrarily large No.
On the other hand, the example of Figure 23 shows that
N BFD/NFFD~ 13/12 is possible for arbitrarily large No.
These two examples represent the worst behavior of
N FFD/ N BFD and N BFD/ N FFD currently known.
Another algorithm which has been proposed 40 proceeds by first selecting from all the Oli a subset which
packs B1 as well as possible, then selecting from the

214

Spring Joint Computer Conference, 1972

1000 using the first-fit decreasing algorithm then we
find N FFD = 3 which is optimal. However, if all the
weights are decreased by one, so that now the weights
(759, 394, 394, 378, 378, 240, 199, 104, 104, 39) are
packed into boxes of capacity 1000 using the first-fit
decreasing algorithm, we have N FFD = 4 which is clearly
not optimal. In fact, the following example shows that
N FF can increase when some of the (Xi are deleted. In
Figure 24 the list L= (7, 9, 7, 1, 6, 2, 4, 3) is used with
the first-fit algorithm to pack boxes of capacity 13,
resulting in N FF (L) = 3.
If the number 1 is deleted from L, to form the list
L' = (7, 9, 7, 6, 2, 4, 3), then we see in Figure 25 that
NFF(L') =4.

t-€

i-2£

-k-E

t+€

.i +£
3

1+€
3
(X6n)

(X6n)

i-

~+e:

2£

(X6)

3

(X6n)

(X6n)

DYNAMIC TASK SELECTION

(Xn)

Figure 23-An example with NBFD/NFFD = 13/12 and No large

remaining (Xi a subset which packs B2 as well as possible,
etc. Although more computation would usually be required for this algorithm than for the first-fit decrea~ing
algorithm it might be hoped that the number N of
boxes required is reasonably close to No. This does not
have to be the case, however, since examples exist for
any e>O for which No is arbitrarily large and

As an alternative to having a fixed list L prior to
execution time which determines the order in which

2
6

2

2
4

N'=4:

7

9

7

QO

N/N o> 2: 1/(2n -1)-e.

(14)

n=l

Figure 25-A non optimal packing using the deleted list L'

The quantity
00

2: 1/ (2n-1) = 1.606695 ...
n=l

in (14) is conjectured 15 to be best possible.
Some of the difficulty in proving many of the preceding results and conjectures seems to stem from the
fact that a decrease in the values of the (Xi may result
in an increase in the number of boxes required. For
example, if the weights (760, 395, 395, 379, 379, 241,
200, 105, 105, 40) are packed into boxes of capacity

3

4

,

2

6

N =3:

7

9

Figure 24-An optimal packing using L

7

tasks should be attempted, one might employ an algorithm which determines the scheduling of the tasks in a
dynamic way, making decisions dependent on the
intermediate results of the execution. Unfortunately,
no efficient algorithms of this type are known which
can prevent the worst possible worst-case behavior.
Perhaps the most natural candidate is the "criticalpath" algorithm, 5 which always selects as the next task
to be executed, that available task which belongs to the
longest t chain of currently unexecuted tasks. This type
of analysis forms the basis for many of the project
planning techniques which have been developed such
as PERT, CPM, etc. 39 Its worst-case behavior can be
bad as possible as the example in Figure 26 shows
(where O0I\X2>01\ (X2 divides Xl)]
then 1 else undefined.

Thus, je is properly less defined than jPlI e.g., je(1, 0)
is undefined whilejPl(l, 0) = 1.*
There are two ways to view this problem: either (a)
theoreticians are wasting their time by developing
methods for proving properties of programs which "do
not exist" in practice. They should concentrate their
efforts in developing direct methods for proving
properties of programs as they are actually executed;
or (b) existing computer systems should be modified,
since they are computing recursive programs in a way
which prevents their user from benefiting from the
results of the theory of computation. Language designers and implementors should look for efficient
computation rules which always lead to the least
fixpoint. "Call by name," for example, is such a computation rule, but unfortunately it often leads to very
inefficient computations. An efficient computation rule

* It can actually be shown, in general, that for every recursive
program P and any computation rule C, if f c and f p are not
identical, then f c must be less defined than f p (Cadiou [3]).

We now describe the computational induction method
for proving properties of recursive programs. The idea is
essentially to prove properties of the least fixpoint f P
of a given recursive program P by induction on the
level of recursion.
Let us consider, for example, the recursive program
F(x)~

P 2:

if x=o then 1 else x F(x-l),
o

over the natural numbers. The least fixpoint function

f P2 (x) of this recursive program is the factorial function x! .
Let us denote now by Ji(x) the partial function
indicating the "information" we have after the ith
level of recursion. That is,
jO(x) is undefined (for all x) ;
P(x) is ifx=O then 1 else x o fO(x-l), i.e.,
if x = 0 then 1 else undefined;
f2(x) is ifx=O then 1 else x oP(x-l), i.e.,
ij x = 0 then 1 else x (if x-I = 0 then 1 else undefined) , or
0

in short,
if x = 0 V x = 1 then 1 else undefined;

etc.

Computation of Recursive Programs

In general, for every i,

i~ 1,

Ji (x) is if x = 0 then 1 else X· Ji-l (x - 1) ,
which is
if x < i then x! else undefined.
This sequence of functions has a limit which is exactly
the least fixpoint of the recursive program; that is,
limJi(x) =x!
The important point is that this is actually the case
for any recursive program P. That is, if P is a recursive
program of the form
F (x) ¢=:r[F] (x),

For our purpose there is no need to specify the domain
of the programs or the meaning of p, hand k. We
would like to prove, using the two forms of induction,
that
fps(x, y) =gp,(x, y) for all x and y.
Proof by simple induction

If we restrict ourselves to simple induction, it is
much more convenient to prove a stronger result than
the desired one. This often simplifies proofs by induction by allowing a stronger induction assumption, even
though we have to prove a stronger result. So, we
actually show that
cp(fps, gp,): \fxVy{[fp 3(X, y) =gp,(x, y)]

and Ji (x) is defined by

1\ [gp,(x, h(y)) =h(gp,(x, y))]}

fO(x) is undefined (for all x),

holds. We proceed in two steps:

and
Ji(x) is r[Ji-l] (x) for

i~1,*

(a) cp( jO, gO), i.e., VxVy{ [fO(x, y) =gO(x, y)]

then

1\ [gO (x, h(y)) =h (gO (x, y))]}.

lim Ji(x) =fp(x).

\fx\fy{ [undefined

i

This suggests an induction rule for proving properties of
fp. To show that some property cp holds for fp, i.e.,
cp ( f p), we show that cp (Ji) holds for all i ~ 0, and
therefore we may conclude that cp(limJi), i.e., cp( fp),
holds.
i
There are two ways to state this rule. Both are
essentially equally powerful. These are actually the
rules for simple and complete induction on the level
of recursion.
(a) simple induction
if cp(fO) holds and \fi[cp(Ji)==}cp(fi+l)] holds,
then cp (fp) holds.
(b) complete induction
if 'Ii {[ ( Vj s.t. j < i) cp (fi) ]==}cp (fi)} holds, **
then cp ( fp) holds.

The simple induction rule is essentially the "JL-rule"
suggested by deBakker and Scott, 6 while the complete
induction rule is the "truncation induction rule" of
Morris. 7
Example: Consider the two recursive programs7
P3:

F (x, y)¢=: if p (x) then y else h(F(k(x), y)),

1\ [undefined

=undefined]

=undefined] }.

(b) \fi[cp(Ji, gi)==}cp(fi+l, gi+l)]'

We assume
\fx\fy{ [Ji(x, y) =gi(X, y)]
1\ [gi(X, h(y)) =h(gi(x, y))]},

and prove
Vx\fy{[fi+l(X, y) =gi+l(X, y)]
1\ [gi+l (x, h(y)) =h(gi+l (x, y))]}.

fi+l (x, y)

= if p (x) then y else h ( Ji (k (x), y) )
= if p(x) then y else h(gi(k(x), y))
= if p(x) then y else gi(k(x), h(y))
=gi+l(X, y).

gi+l(X, h(y))= ifp(x) thenh(y) elsegi(k(x), h2 (y))
= ifp(x) thenh(y) elseh(gi(k(x), hey)))
=h(if p(x) then y else gi(k(x), h (y)))
=h(gi+l(x, y)).

and
P4 :

221

G(x, y)¢=: if p(x) then y else G(k(x), h(y)).

* Where J[fi-l] is the result of replacing fi=l for all occurrences
of F in J[F]
** Note that this indicates implicitly the need to prove q;(fO) separately, since for i = 0 there is no j s. t. j < i.

Proof by complete induction
Using complete induction we can prove the desired
result directly; that is, we prove that
CP(fp3' gp,): VXVy[fp3(X, y) =gp,(x, y)]

222

Spring Joint Computer Conference, 1972

holds. This is done by showing first that cp ( f O, gO) and
cp ( p, gl) hold, and then that cp ( ji, gi) holds for all
i2=:2. (We treat the cases for i =0 and i = 1 separately,
since to prove cp ( ji, gi) we use the induction hypothesis
for both i-I and i-2.)

induction on the following simple flowchart program:

(a) cp( f O, gO), i.e., VxVy[JO(x, y) ==gO(x, y)].
VxVy[undefined == undefined].
(b) cp( fI, gl), i.e., VxVy[JI(x, y) ==gl(X, y)].

P (x, y) == if p (x)
== if p (x)
== if p(x)

then y else h ( fO (k (x) , y) )
then y else undefined
then y else gO(k(x), h(y))

==gl(X, y).
(c) (Vi2=: 2) [cp (ji-2, gi-2) /\ cp( ji-I, gi-l)=}cp (ji, gi)]
We assume
VxVy[ji-2(X, y) ==gi-2(X, y)]
and
VxVy[ji-l(X, y) ==gi-l(X, y)],
and deduce
VxVy[ji(x, y) ==gi(X, y)].
ji(x, y) == if p(x) then y else h( ji-l (k(x), y))

== ifp(x)
== if p (x)

thenyelseh(gi-l(k(x), y))
then y else h (if p (k (x)) then y
else gi-2(k 2(x) , h(y)))

==

ifp(x) thenyelse (ifp(k(x)) thenh(y)
else h (gi-2(k 2(x) , h(y))))

== if p (x)

then y else (if p (k (x)) then h (y )
else h( ji-2(k2(x) , h(y))))

==
==

ifp(x) then y elseJi-l(k(x), hey))
if p (x) then y else gi-l (k(x), h(y))

==gi(X, y).
THE INDUCTIVE ASSERTIONS METHOD
The most widely used method for proving properties
of "flowchart programs" is presently the inductive
assertions method, suggested by FloydS and Naur.9 It
can be shown that for any proof by inductive assertions,
there is a naturally corresponding computational
induction proof. We shall illustrate the inductive
assertion method and its relation to computational

We wish first to use the inductive assertions method
to show that the above flowchart program over the
natural numbers computes the factorial function, i.e.,
z=x!, whenever it terminates. To do this, we associate
a predicate Q (x, Yl, Y2), called an "inductive assertion,"
with the point labelled a in the program, and show that
Q must be true for the values of the variables x, Yl, Y2
whenever execution of the program reaches point a.
Thus, we must show (a) that the assertion holds when
point a is first reached after starting execution, (i.e.,
that Q(x, 0, 1) holds) and (b) that it remains true
when one goes around the loop from a to a (i.e., that
Yl~X/\Q(X, Yl, Y2) implies Q(x, Yl+l, (Yl+1)·Y2)).
To prove the desired result we finally show (c) that
z=x! follows from the assertion Q(x, Yl, Y2) when the
program terminates (i.e., that Yl=X/\Q(X, Yl, Y2)
implies Y2=X!).
We take Q(x, Yl, Y2) to be Y2=yd. Then:
(a) Q(x, 0, 1) is 1 =01.
(b) We assume Yl~X and Q(x, Yl, Y2), i.e., Y2=yd. Then
Q(x, Yl+l, (Yl+l) 'Y2) is (Yl+l) 'Y2= (Yl+l)!,
i.e., (Yl+l) ·yd= (Yl+l)!.
(c) We assume Yl=X and Q(x, Yl, Y2), i.e., Y2=Yl!, then
Y2 = Yl! = x! as desired.
To show the relation between this method and
computational induction, we must first translate the
flowchart program into a recursive program. Following
the technique of McCarthy,lO we find that the above

Computation of Recursive Programs

flowchart program isfp5(x, 0,1), i.e., the least fixpoint
of the recursive program Po (with Yl = and Y2 = 1)
where

°

Po: F (x, Yl, Y2) {= if Yl = x then Y2
else F(x, Yl+1, (Yl+1) ·Y2).
We shall prove by (simple) computational induction
that f p5(X, 0,1) ex!, i.e., the value of fp5(X, 0,1) is x!
whenever fp5(X, 0, 1) is defined, which is precisely what
the above proof by inductive assertions showed.
We take cp (F) to be the following predicate:
("Ix, Yl, Y2) {Q(x, Yl, Y2)::::}[F(x, Yl, Y2) ex!]},
where Q (x, Yl, Y2) is Y2 = yd, the induction assertion
used before. Obviously cp ( fO) holds. To show that
cp (Ji) implies cp ( fHI) for i 2:: 0, we consider two cases:
either Yl = x, in which case the proof follows directly
from (c) above, or Yl~X, which follows directly from
(b) .
By computational induction we therefore have cp ( f p) ,
i.e., Q(x, Yl, Y2)::::}[fp(x, Yl, Y2) ex!] for all x, Yl, Y2.
But since Q(x, 0, 1) is known from (a) to hold, we
conclude that fp (x, 0, 1) ex!, as desired.
REFERENCES
1 Z MANNA S NESS J VUILLEMIN
Inductive methods for proving properties of programs
In Proceedings of ACM Conference on Proving Assertions
about Programs ACM New York January 1972

223

2 S C KLEENE
Introduction to meta-mathematics
Van Nostrand Princeton New Jersey 1952
3 J M CAD IOU
Recursive definitions of partial functions and their
computations
PhD Thesis Computer Science Dept Stanford University
To appear
4 J VUILLEMIN
Proof techniques for recursive programs
PhD Thesis Computer Science Dept Stanford University
To appear
5 R MILNER
Implementation and applications of Scott's logic for
computable functions
In Proceedings of ACM Conference on Proving Assertions
about Programs ACM New York January 1972
6 J W DEBAKKER D SCOTT
A theory of programs
Unpublished memo August 1969
7 J H MORRIS
'
Another recursion induction principle
CACM Vol 14 No 5 pp 351-354 May 1971
8 R W FLOYD
Assigning meanings to programs
In Proceedings of a Symposium in Applied Mathematics
Vol 19 Mathematical Aspects of Computer Science pp 19-32
Ed J T Schwartz
9 P NAUR
Proof of algorithms by general snapshots
BIT Vol 6 pp 310-316 1966
10 J McCARTHY
Towards a mathematical science of computation
In Information Processing:
Proceedings of IFIP 62
pp 21-28 Ed C M Popplewell Amsterdam North Holland
1963

Mathematical concepts in programming language semantics
by DANA SCOTT
Princeton University
Princeton, New Jersey

leaving only what is familiar remaining. If you can do
it the first way, you can do it the second way, obviously; the converse is not obvious though. A contextual translation scheme may be very sensitive to
the context: a transformation appropriate for one
occurrence of an expression may not work elsewhere.
The negative integers can be used as a good example
here. The rules of algebra are such that all minus signs
can be eliminated from an equation by multiplying out
the formal polynomials and then using transposition.
(Different rules are used for different contexts, note.)
If it is the question of an algebraic law with variables,
we use this trick: Suppose we wish to assert that the
equation f(x) =g(x) holds for all x at both positive
and negative values. Of course f(x) =g(x) holds for all
non-negative x. But so does f( -x) =g( -x). In other
words one equation has been equivalently translated
into two, in which the variable can be restricted to the
more familiar range. Now Descartes may have been
willing to do algebra this way, but we would no longer
consider it reasonable. We have developed our theory of
numbers so as to include both positive and negative
quantities, and we have gone on to imaginary and
complex numbers with great gains in understanding.
In the new algebra, expressions are directly meaningful
and no translations are required. Nevertheless we prove
that the new algebra is consistent by constructing a
model out of familiar stuff. Complex numbers were
fairly easy to handle; quaternions were harder. You all
know examples and know that mathematicians are
busy every day finding other weird structures. Whether
the results deserve other than a mother's love is another
question.
What does this discussion have to do with programming languages? Very much I feel. Programming
languages have introduced a new dimension into the
problem of semantics. In the first place there has been
an explosion in the size and complexity of the expressions that must be considered. In view of the com-

INTRODUCTION
In mathematics after some centuries of development
the semantical situation is very clean. This may not be
surprising, as the subject attracts people who enjoy
clarity, generality, and neatness. On the one hand we
have our concepts of mathematical objects (numbers,
relations, functions, sets), and on the other we have
various formal means of expression. The mathematical
expressions are generated for the most part in a very
regular manner, and every effort is made to supply all
expressions with denotations. (This is not always so
easy to do. The theory of distributions, for example,
provided a non-obvious construction of denotations for
expressions of an operational calculus. The derivative
operator was well serviced, but one still cannot multiply
two distributions.)
The point of such activity is that the formal rules of
the calculus of expressions allow solutions of problems
to be found and give us ways of checking correctness of
proposed solutions. It is by no means the case that
mathematical inspiration is thus reduced to automatic
algebra, but the possibility of formal manipulation is a
great help. Not only can we record useful lemmas, but
a precise language is essential for teaching and communication.
I t is of course possible to pick formalisms out of thin
air and to ask people to accept their usefulness on
mystical grounds. (The operational calculus was
developed a little that way.) There is no denying that
clever guesswork can be very successful, but ultimately
it is fair to ask the mystic just what he is talking about.
A way to counter that question is to show how the
concepts being symbolized in the new language are
explained in terms of familiar notions. To do this we
can try either to correlate directly denotations definable
in familiar terms with the expressions of the new
language or to show how to translate the new expressions out of every context in which they might occur

225

226

Spring Joint Computer Conference, 1972

plications, every effort is made to allow the writer of
the program to keep tiresome details implicit: some
controls can be written in, but generally it is the compiler that will take care of the boring parts. Now many,
many compilers have been written-even students can
do it these days. A compiler can be viewed as a translator
from the source language (unfamiliar) into machine
language (familiar). Why cannot we say, then, that
the semantical problems of programming language are
solved? The answer is, I beHeve, that every compiler
(if it is meant for a real machine) is a compromise.
There must be as many compilers as there are machines,
each reflecting limitations and peculiarities of the given
machine. Should not the ideal of language definition be
machine independent?
Certainly the introduction of abstract machines does
not settle this difficulty of a multiplicity of translation
schemes. After all even for an abstract machine the
compiler writer must choose specific ways of keeping
track of the order or depth of nesting of computation
initiations. There may be different ways of doing this,
all of which lead to the same results. The variety of
approaches even on an abstract machine may make it
quite impossible to define in any· meaningful way just
what is a single computation step. Therefore, the idea
of the state of the computation is not apparently at all
well determined by the source language alone. When a
specific compiler is fixed, however, we may very well
want to investigate how it handles computation steps.
But the question remains: do they have anything to do
with the semantical definition of the original language?
I think not.
Before pursuing the question of the proper level at
which semantics enters, we should take note of a
second dimension-expanding consequence of programming language study. Mathematical concepts generally
have a rather static quality. True, mathematicians study
flows on manifolds and many-body problems, but it
seems to me that often the interest centers on global
qualities or asymptotic behavior. What is peculiar in
programming language-especially from a linguistic
point of view-is that exactly the same symbols may
possess a quite different import in different segments
of a program. This is most apparent in the way variables
(identifiers) are used. I need give no examples here;
all of you understand why variables are not employed
in the assignment statement in a "mathematical" way.
The dynamic character of command execution requires
a quite different treatment of variables, and this
dynamic urge permeates the whole semantic analysis.
The principal virtue of the programming language is
that the compounding of the various operations need
only be indicated in a rather schematic way, since the

calculation is meant to be automatic in any case. But
the calculation is not meant as a game or a joke. It is
something that needs precision, so we must be able to
"follow" what happens in some rather definite sense.
What we are discussing is how definite this has to be in
order to have a good semantical definition of a language.
Some years ago, Christopher Strachey began a
project of trying to expose the semantics of a programming language as a series of mutually recursive func. tional equations.! The particular complex of equations
would be "syntax directed" in the sense that each
clause of the recursive syntactical specification of the
language would have a corresponding equation. The
equations taken together would define the meaning of a
program, because made to correspond to a program
text would be a recursively defined function. This
function was intended as a state-transformation function: the function that takes an initial state to the final
state that results from executing the program. In many
instances the notion of "state" used here could be taken
to be "state of the memory" or some abstraction from
that idea to make the definition machine independent.
The formaHsm Strachey used to state his equations
was a modified version of the A-calculus. There was an
inherent difficulty in this approach: The A-calculus at
the time was just another symbolic calculus. 2 The
criteria for equivalence of expressions were rather weak,
and it was not clear in which directions they should be
expanded. The advantage of the A-calculus was that it
was "clean," especially in its handling of Ivariables,
which was done along the usual "mathematical"
lines. 3 ,4 Thus it was felt that some progress had been
made in explaining the unfamiliar in terms of the
familiar. Still, the project was not quite complete.
One objection to the A-calculus the present author
had was that it possessed no mathematical semantics.
It was another kind of operational calculus. True, the
calculus had been proved consistent, but the consistency
proof did not seem to give clear hints as to how to
extend usefully the principles of equivalence of expressions. 5 This uncertainty was particularly unsettling in
view of the many inconsistent extensions that had been
proposed. The main difficulty rested on the thoroughly
type1ree style of functional application and abstraction
used in the A-calculus, where, for example, a function
could be applied to itself as an argument. 6 And it was
just this type-free character of the system that Strachey
wanted to exploit.
During the fall of 1969 the author resided in Oxford
in order to learn more about Strachey's ideas on programming languages. After long, and sometimes rather
heated, discussions on the role of mathematics in
semantics, it slowly began to dawn on the author that

Mathematical Concepts in Programming Language Semantics

there might be an "objective" interpretation of the
A-calculus. As explained elsewhere/· s it was possible
finally to combine ideas and techniques from many
sources into a coherent theory of models for the
A-calculus. The key step was to find the right idea of
an abstract domain (which turned out to be a kind of
topological space) so that an appropriate notion of a
function space would be a domain of the same kind.
From that point it was only a matter of time until the
question of whether a domain might exist that could be
isomorphic ally identified with its own function space
would arise. Fortunately the author was able to see how
to effect the required mathematical construction, and a
new approach to functional calculi was opened up.
This sounds most abstract and impractical, but the
spaces constructed are actually no worse then the real
numbers. The "irrational" elements can be explained
as limits of infinite sequences in ways that are quite
reminiscent of classical analysis. 9 And what is more
important proofs about the properties of the elements
can he given inductively by "successive approximation"
in a simple and natural way. Furthermore it is possible
to discuss the effectiveness and computability of various
elements and processes so as to tie in the abstractions
with actual computation.
In this paper it will not be possible to discuss the
mathematical details, though a few words will be
inserted here and there to resolve puzzles about whether
the method is reasonable.lO Instead it will be shown how
the theory of these abstract domains can be applied to
typical semantical problems, thus supplying the
mathematical foundation needed for Strachey's equational approach. It is not claimed that the project for a
mathematical semantics is at all completely finished,
but the ideas have been found to be so flexible that we
have gained full confidence that we can do serious
model building incorporating features whenever the
need for them is realized. ll
LOCATIONS AND STORES
There are many levels of storage from core to disk to
tape to card hopper to the mind of the user sitting at a
console. Some of these are more addressible than others
(and more reliable). Some require special handling,
especially as regards allocation of space in preparation
for future acts of storage. In the present discussion we
shall not treat these subtleties, even though they are
very important for good compiler operation. We shall
simplify the presentation for the sake of illustration by
making these assumptions:
• There are but two facets to storage: internal and
external.

227

• The internal storage is addressed by elements of a
homogeneous collection of locations.
• The contents stored at each location always may be
read out (nondestructively), and at any time new
contents may be read in updating (destroying)
the old contents.
• The current state of the store allows a distinction
between the area of active locations (with conte'!ts)
and passive or free locations (without contents).
• At any time a new location may be selected from
those free and placed in the active area.
• At any time a location may be lost or retired to
the free list.
• One part of the external store allows reading in of
fresh information (input).
• The other part of the external store allows writing
of computed information (output).
• External reading and writing are independent
operations: what is written cannot be read back
unless it has been separately stored internally.
The statements of these rather natural assumptions
have been given first in fairly precise yet intuitive
language. The point of the present paper is to show how
to "mathematize" such assumptions in terms of a model
that can be incorporated into a full semantical definition. (No formal language has been discussed at this
point, however.) To carry out the mathematical
modelling, we postulate first the existence of several
domains that will be interrelated by the model:
The basic domains

L = locations

v = stored values
S = states of the store
T = truth values
Possibly it would have been better to say "storable
values" since not every element of V is actually stored.
Just what these quantities are supposed to be will be
left open until the next section. One has a variety of
choices depending on the kind of language that is to
be interpreted.
These domains alone do not specify the model because
they have not yet been supplied with any structure.
This can be effected by listing the operations and
transformations tha~ may be applied to the domains in

228

Spring Joint Computer Conference, 1972

various combinations:
The store operators
Contents: L-{S~V]
Update: LXV~[S~SJ
Area: L~[S~TJ
New:

S~L

Lose: L~[S~SJ
Read:

S~VXS

Write: V~[S~SJ

Given any two domains Do and D 1, we write [Do~DlJ
for the space of all (admissible) functions from Do into
D 1• (At this stage we do not need to worry just which
functions are admissible.) We write f: Do~Dl to
indicate that f is just such a function. What we have
listed above are the functions that correspond to our
intuitive ideas about the structure of the store. In order
to explain how this works, the following variables will
be used (with or without sub- and superscripts) restricted to the indicated domains:
a:L,

(3:V,

O':S, r:T

Suppose, then, a is a particular location and 0' is the
current state of the store. The function value Contents(a) (0') is to be the V-value stored by 0' at a.
Conversely, let {3 be a given V-value. The pair (a, (3) in
LXV provides the desired information for updating the
store. Therefore, when we write
Update(a, (3) (0') =0"

we want 0", the transformed store, to be just like 0'
except in having (3 stored now in location a. Similarly
Area (a) (0') is true or false according as a is in the active
area of 0'. The function Lose(O') transforms 0' into the
store 0''' which is just like 0' except that a has been freed.
Exactly what Read and Write do depends on the
activities of the mad scientist at the console. Supposing,
however, that he does not ruin the equipment, whenever
Read (0') is activated something will happen. This
transformation can be recorded as a pair ({3', 0"), where
(3' is a storable value, and 0" has the same internal
state as 0' did, but the external condition is made all
eager and ready for the next input. In a similar way, the
function Write({3') may be regarded as only affecting
the external portion of the store.
The functional notation of mathematics has the gloss
of precision. But so far the gloss is the only aspect

introduced, since note that the above explanations of
what the functions are supposed to do are just as
informal as the original assumptions given in ordinary
language. What must be avoided in this kind of work is
the Fairthorne Hovercraft effect described12 as an "approach in which we use extremely sophisticated techniques and mathematical devices to skim at very high
speed and great expense over the subject of concern
without ever touching it."
Now in mathematical model building the way to
touch ground is to find out how to formulate with
precision the postulates that correspond to the intuitive
assumptions. Notational precision is not enough-if
there is no way of proving useful theorems. So far our
postulates have been rather weak: nothing more than
simply noting the functional characters (or logical
types) of certain operators. The next step is to say
exactly how these operators are connected.
What I wish to claim is that each of the intuitive
assumptions previously informal1y indicated can be
expressed rigorously by an equation. For example,
after updating the store at a location, the contents of
the location wiH be found to be what is expected and
the location will be found to be active. This statement
makes two equations as follows: r
Contents (a) (Update(a, (3) (0'» =(3
Area(a) (Update(a, (3) (0'» = true

These equations are meant to hold for all a, (3, 0'. What
about locations a' different from a? If a' ~ a, we expect
that:
Contents (a') (Update(a, (3) (0')) = Contents (a') (0')

Similarly in the case of Area. If we introduce the
equality relation on L:

Eq:

LXL~T

and conditional expressions, these four equations can be
reduced to two in the obvious way.
In writing these equations, one puzzle is what to
write in the cases where the functions are possibly
undefined. A solution is to introduce a special value to
correspond to this case. The symbol for this value
adopted here is -L. We write f(x) =.L to indicate that
the function x is undefined at x. (Other symbols in use
are n, w, *, and UU.) This convention is useful in the
main equation relating Contents to Area:
Contents(a) (0') =if Area(a) (0')
then Contents ( a) (0')
else .L

Mathematical Concepts in Programming Language Semantics

There is not enough room here to formulate all the
necessary equations; thus, my claim must remain just
that. 13 But it does not seem to me that the claim is too
implausible. Note, however, that these postulates on the
character of the store would not completely specify
everything. The exact nature of V is left· open at this
stage of the model building. Concerning L, all we would
know is that there are infinitely many locations, because
new ones can be produced indefinitely. Actually that is
probably enough to know about L until one gets into
problems of allocation. The input/output phase has
also been left a little vague, but that is not necessarily
bad either. If we can prove any theorems at all, it is
better to prove them from fewer assumptions. Some
assumptions are needed, nevertheless; and it requires
experimentation to find just the right balance. Part of
the thesis of this paper is that the mathematical style
advocated allows for this experimentation to take place
in a convenient way.

229

following variables are used in restricted senses:
~:Id,

v:Num,

w:Op,

'Y:Cmd,

E:Exp

The syntax for Id, N um, and Op will not be given since
it is standard. The remaining two categories are defined
as follows:
Commands

'Y : : = EO: =El , write E, !E , E~'YO, 'Yl ,
dummy , 'Yo; 'Yl , while Edo 'Y ,
let ~:;:; Ein 'Y ,let ~ = Ein 'Y ,letrec ~ be e in 'Y ,
('Y)
Expressions

e: : = ~, ..L , read , 'Y result is e , eO~el, e2 ,
A LANGUAGE
There were no surprises in the discussion of storage in
the previous section, and there are no surprises planned
for this section either. All we shall do here is to indulge
in some very modest language design. Any real innovation is saved for the section on semantics. And this is
how it should be, otherwise we would not be giving
solutions to natural problems. It is quite possible,
though, that after the semantical approach has been
appreciated language design practice will be altered.
Strachey has argued for this,14 but the effects remain to
be seen. In any case we hope to develop a semantical
style within which the consequences of different design
choices can be studied.
To start with our language will be divided into the
usual syntactical categories:
The syntactical domains

Id = identifiers
N um = numerals
Op = (binary numerical) operations
Cmd = commands
Exp = expressions
A feature of our method is that we treat these domains
on a par with the basic and semantical domains. They
are different, since they are constructed for syntactical
purposes; but they are domains nevertheless. The

e: T , true , false , eo = el ,
e: N I v , eOwel ,
e:C, :'Y'
e: P , A~. E 'eoe! I
e:R'

1 e'

ie'

(e)

Some comments are necessary: (i) There is an
unpleasant conflict in this syntax between the use of
words versus the use of symbols. The trouble is that
there are not enough symbols-especially on keyboards-otherwise all constructs could be symbolized.
But then one has to remember what the symbols are
for, so it is better to use words-:-especially English
words. But it takes so long to write out all those words.
The situation is hopeless. (ii) There is an unpleasant
ambiguity in this syntax. The same string could be
parsed in several different ways. Necessarily, then, the
meaning of a command or an expression will have to
depend on the parse. But we· will pretend in writing
equations that everything can be determined from the
string alone. If that worries you, please write in the
parentheses (you are allowed to by the last clause of
the definition). But no one can stand to write in all
those parentheses. The situation is hopeless. But for the
semantical theory it does not really matter.15
The style of language definition was chosen to give a
few hints as to the meanings. But I hope there are some
constructs that seem quite mysterious on a first reading.

230

Spring Joint Computer Conference, 1972

Some explanation is in order. Take commands first.
The first clause gives us assignment statements. Everyone knows what they mean-except what does it mean
to have a compound expression on the left? Well, never
mind. The next command is obviously intended to
invoke output. That was easy. For the next clause it
would have been better to write do E. In this language
commands can be set up and (their closures) stored
away for later execution. This command means that E
should be evaluated out; and if the value is a command
closure, then it should be done. If not, what then?
Never mind. Next we have the conditional command
(Boolean-valued expressions are possible). To execute
dummy, do nothing-except waste time. The semicolon
provides the means for sequencing, or composition, of
commands. Next we have the while statement. Its
effect is well-known. Finally there are three kinds of
initialization of parameters in blocks. But which is
which?
An odd fact about many programming languages is
that identifiers are used for many different purposes
even though they form just one syntactical category.
The context is expected to give the clue as to use. It is
not such a bad idea. When one starts to write a program,
the number of identifiers to be used is probably not
known. To have to divide them up into various subcategories would complicate the language a great deal,
and restrict the ways they could be chosen, by tiresome
rules. They have only a local significance in any case, so
some rough, informal conventions of programming
style are sufficient to assure readability of programs.
The three types of initialization in this language
illustrate three quite different uses of identifiers. In the
first, we begin by evaluating E. It will turn out to be
either an L-value or a V-value. Whatever it is, we
associate the same value with ~ and go on to execute 'Y
under this assignment (keeping assignments to other
identifiers the same as before, of course). In the second,
we evaluate E. If the value is a V-value, we are happy.
If the value is an L-value, we find the contents of the
current state of the store in that location-a V-value.
In either case we now have a V-value. Next we find a
new L-value outside the active area of the store and
attach it to ~.Finally we update this location with the
computed V-value. Thus prepared, we can now execute
'Y. (The only reason for being so complicated is that in
'Y we would like to be able to use ~ on the left of assignment statements.) The first two cases are not so very
different, but the third presents a fresh aspect.
At the time of making a recursive definition, we want
to associate the "import" of E with ~, but we do not
want to evaluate E. Also E may contain ~ (a free occurrence of the identifier) , and we want ~ to mean the same

as we just said. Having made this tie-up without
actually evaluating anything, we begin to execute 'Y.
Every time we find a (free) ~, in effect, we want to
replace it be E and continue the evaluation. That is to
say, E will be evaluated only when it is called for by an
occurrence of ~. Since E contains ~, this may happen
repeatedly. This sequence of events is quite unlike the
non-recursive initializations where the ~'s in E are not at
the same as the r s in 'Y.
Turning now to expressions, the explanations can be
rather short. The read expression invokes input and has
a V-value. The result is combination allows for the
command 'Y to be executed before E is evaluated. Next
we see the conditional expression. The E: X expressions
are all Boolean-valued and are tests on the nature of the
value of E. In lines two and three of the definition we
have obvious Boolean-valued or numerical-valued expressions. In line four we have to do with (closures of)
commands, and :'Y forms just such a closure making a
command into an expression. Line five has to do with
procedures. First we find "A-abstraction (functional
abstraction) which forms a (closure of) a procedure
from an expression with respect to a formal parameter.
N ext we have application of a procedure to an argument. Line six, finally, has to do with references. We
can make a reference (to the value of E), or we can
look up a reference. References bring in the problem of
sharing, but we will not treat it in this paper. Nor shall
we discuss arrays. Note too that labels and jumps have
not been included.
The explanations just given have not been very full;
but the programming concepts mentioned are familiar,
and most of us would now have a fairly good idea of
what a program written in this language would do.
Such intuitive understanding is not rigorous semantics,
however, and as everyone knows sticky points can arise.
Just as we could turn the intuitive assumptions about
the store into precise equations, so must we formalize
our semantical understanding, as will be outlined in the
next section.
THE SEMANTICS
The plan of the semantical definition is that every
command and every expression shall denote something.
It is the construction of the domains in which the values
lie that requires the mathematics. We have spoken
already about the basic domains L, V, S, and T. Of
these Land T can be given independently in advance,
but V and S can only be formed in conjunction with the
over-all semantical project. To do this we have to look
at the kinds of expressions there are to be found in the

Mathematical Concepts in Programming Language Semantics

231

language and to provide appropriate domains. The
uses of the identifiers also have to be taken into account.
This analysis suggests these domains in addition to the
four already isolated:

To understand how these functional types are
arrived at, consider a command 'Y. Given an environment p and a state of the store u, we can write the
equation
e ('Y) (p) (u) = u'

The semantical domains

to indicate that u' will be the state achieved after
execution of 'Y. Similarly for expressions the equation

N = numerical values
E = expression values
W = dynamic values
D = denoted values
C = command values
P = procedure values
R = reference values
The denoted values accumulate all the possible values
that might be attached to an identifier. A scheme of
such attachments is called an environment. Mathematically it is just a function from identifiers to denoted
values. All our evaluations will have to take place
within (or relative to) such an environment. The
following variable is restricted to environments:
p: Id~D

Environments can change, but the meanings of the
numerals and the numerical operations are fixed. The
way to fix them is to define in the standard way these
two functions:
Numval:

See) (p) (u)

indicates that 1] is the value found for e, while u' is the
state achieved after the act of evaluation.
An immediate question is why the p and u are
separated as arguments. The answer is that they enter
into the evaluations in different ways. For one thing,
they change at quite different rates with p staying fixed
much longer than u. For another, we will be tempted to
copy p, but we will generally never feel free to ask for a
copy of the whole store-there just is no room for that.
Possibly in simulating a small machine on a large
machine we could conceive of programming the copying
of the store, but this is not yet a standard concept. In a
way p enters at a more conscious level, while u flows
along as the unconscious. Much of the action on u is
meant to be automatic, though there is communication
between the levels. Besides these reasons, it is often the
case that we want to discuss e ('Y) (p) without reference
to a particular u; thus it is convenient to be able to drop
it off as the last (deepest) argument.
For stylistic reasons and as an aid to the eye, we shall
use emphatic brackets with the semantical functions:
S[e](p) (u)

Num~N

Opval: Op~[NXN~NJ

Explicit definitions need not be given here.
Ultimately a command means a store transformation.
In mathematics expressions have "static" expression
values, but in programming it turns out that commands
can be invoked in evaluating a command. Thus an
expression has an effect as well as a value. We also have
to remember that expressions are sometimes used for
their L-values and sometimes for their V-values. All of
this can be summarized in several semantical functions
which have these logical types:

These are helpful because the expressions tend to get
along and to pile up their own parentheses. Before we
can discuss the semantical equations, however, we must
return to the definitions of the various domains.
The domains L, T and N are given. The rest are
constructed. The constructions can be summarized as
follows:
The domain equations

V=T+N+C+P+R
E=V+L

The semantical functions

e:

Cmd~[[Id~DJ~[S~SJJ

= (1], u')

W=S~EXS

D=E+W

S: Exp~[[Id~DJ~[S~EXSJJ

C=S~S

£: Exp~[[Id~DJ~[S~LXSJJ

P=E~W

"0: Exp~[[Id~DJ~[S~VXSJJ

R=L

232

Spring Joint Computer Conference, 1972

We shall not need variables over all of these domains.
The following restricted variables are used:
?]:E,

o:W,

(1:C

One domain is missing from the list: namely, S. The
construction of S is a bit complicated and needs more
discussion of L than we have time for here. Roughly
S=AX[L~VJXI/O,

where the A-coordinate represents the area; the middle
coordinate, the contents-function; and the last, the
input/output features. But this is a little too rough,
though we must leave it at that. ls
. What is essential to note here is the highly recursive
character of these domain equations; in particular, V
involves Sand S involves V. The involvement comes
about through the use of function domains such as
[S~SJ and [L~V]. Since V-values are storable values,
something seems wrong here. We said earlier that we
would not store (i.e., copy) stores, yet we are asking to
store a store junction (1: S~S. There is actually no
conflict here. Functions involve their arguments in a
potential, not actual, manner. In implementing such a
language, functions would be stored as finite descriptions
(i.e., texts of definitions) not as infinitary abstract
objects. From the point of view of mathematical conception, however, we want to imagine in theory that it
is the functions that are stored. If we did not want to do
this, we should explicitly program the syntax of function definition and the necessary interpretive operations.
In any case, storing a function is done without storing
the store.
Granting the reasonableness of the connections
between V and S, it is still fair to ask whether such
domains exist. This is where the real mathematics
enters. The idea mentioned in the Introduction of
constructing A-calculus models can be employed to
construct these more involved domains. It requires a
combination of lattice theory and topology to achieve
the proper kind of function theory.17 On set-theoretical
grounds it is clear that when we write [S~S ] we cannot
mean to take arbitrary functions, otherwise the cardinality of S (and of V) would become unbounded. The
point is that the functions defined by programs are of a
very special sort. Looked at in the right way they are
continuous functions, and there are many fewer continuous functions than there are arbitrary functions.
And this turned out to be the secret: by restricting the
function spaces to the continuous functions, the required domains can indeed be constructed. Expensive
as this device is, the Hovercraft effect is avoided by
showing that such a theory of domains fits in very well

with the theory of computable functions (recursive
functions) and that a]] the functions required by the
se~antics of the language are indeed computable. In
particular the theory provides a basis for justifying the
existence of functions defined by involved recursions
(like the semantical functions) and for proving properties of such functions. 18 ,19
It should be stressed that the semantical domains
make no explicit reference to the syntax of the language.
True, we gave the language first, and then cooked up
the domains to match. It could have easily been the
other way round. Take V for example. There were five
main sections to the definition of an expression corresponding to five sorts of values an expression could
have. (Strictly speaking this is not true. The expressions eOel and i e could have arbitrary values. It might
have been more logical to put these clauses on the first
line of the definition.) Therefore in the construction of
V, we had to provide for five sorts of elements, T, N, C,
P, and R. The summation operation (+) on domains
has to be defined as a disjoint union (and a little care is
needed with the topology of the reSUlting space). If we
had wanted, we could have included other sorts of
summands. They would not have been reflected in the
language, however. It is an interesting question
whether the language reflects enough of the structure of
the domain V, but one that we cannot pause to consider
here. The point is that language design and domain
construction are parallel activities, each can (and
should) affect the other.
Finally it remains to illustrate some of the equations
needed to define the semantical functions:

Some semantical equations
e[eo: =el](p) = Update*Pair (£ [eo](p) ) (00 [el](p) )
e[writee](p) = Write *8 [e](p)
eho; 'Yl](p) = ehl](p)oeho](p)
e[!e](p) =Do*8[e](p)
e[let ~=e in 'Y](p) = (A?]- eh](p[17/~J)) *He](p)
e [letrec ~ be e in 'Y] (p)

= eh](p[Fixpoint(Ao-8[e] (p[o/~J)) /~J)
For the e-function there should be 11 equations in
all; and for the 8-function, 21 equations. Then the
semantical definition would be complete. Note how the
equations are mutually recursive functional equations:
the e- and 8-functions occur on both sides of the

Mathematical Concepts in Programming Language Semantics

equations in functional contexts. Note too that there is
much unexplained notation.
In order to be able to combine functions, we need at
least two kinds of composition; because some functions
are of type [S~SJ, and some are of type [S~XXS].
We can see how this works in one example. Let:
f=£[EO](p):

S~LXS

g=eu[El](p):

S~VXS

We want:
Pair(f) (g): S~[LXVJXS.

Suppose 0- is a given state. Thenf( u) = (a, u'). Carrying
over 0-' to the next step, g (u') = ({3, u"). So we can
define:
Pair ( f) (g) (u)

233

CONCLUSION
The presentation in this paper has been but a sketch.
For a complete semantics even of this small language,
many more details would be required. But it is hoped
that enough of the project has been exposed to convince
the reader that it is possible to carry out such a plan.
And it is not even too painful to. do so: not so many
mathematical constructs are required, and the equations need not be so very complicated. Of course,
judgment of the worth of doing so should be withheld
until the semantical equations for a really serious
language are fully written out.
REFERENCES

= ((a, (3), u").

(The reason for doing it this way is to get the effect of
two separate evaluations, because there were two
expressions EO and El needing evaluation. ) Then by
definition:
(Update*Pair( f) (g)) (u)

= Update (a, (3) (u")

*

This shows how is a form of functional composition. In
the third equation we wrote 0, since this was just the
ordinary composition of two [S~S ] functions.
The notation p[7]/~J means that the original environment p has been altered to assign the value 7] to the
argument~. (Remember that the arguments of environments are the formal identifiers as syntactic objects.)
The import of the fifth equation then is to evaluate E
first, pass on the value to the environment, and then
execute the command starting in the state achieved
after evaluation of E. Note that E is evaluated in the
original environment.
The Fixpoint function in the last equation is applied
to a function F: W ~W. All our domains are constructed
so that functions defined by expressions always have
fixed points-ifthey have the same domain of definition
and range of values, of course. The domains are lattices
as well as topological spaces, so we can speak of the
least solution to the equation:

oo=F(oo).
This 00 = Fixpoint (F) . Fixed points of functional
equations solve recursions. So in the letrec command, we
first set up the solution 00, and then execute the command in the environment p[oo/~]. This explains our
mathematical concept of recursion. 20 Note that there are
no stacks, no pointers, no bookkeeping. None of those
devices of implementation are relevant to the concept.
That is why this is a mathematical semantics.

1 C STRACHEY
Towards a formal semantics
In T B Steel (ed) Formal Language Description Languages
(North-Holland 1966) pp 198-220. Cf. also Ref 15 for
another description of the present program
2 H B CURRY ET AL
Combinatory logic
Vol 1 (North-Holland 1958) Vol 2 (North-Holland 1972
in press) This is a basic reference with a very large
bibliography
3 P J LANDON
The mechanical evaluation of expressions
Comp J 6 pp 308-320 1964
4 A EVANS JR
P AL-a language for teaching programming linguists
In Proc ACM 23rd Nat Conf Brandon Systems Princeton
N J The PAL language carries out many of the ideas
introduced by Landon
5 Cf. Ref 2 p 78
6 The first proof of inconsistency was given by Kleene and
Rosser for a system of Church. The proof was later much
simplified. Cf. Ref 2 pp 258 ff
7 D SCOTT
Outline of a mathematical theory of computation
Proc Fourth Annual Princeton Conf on Info Sci and Sys
Princeton 1970 pp 169-176
8 D SCOTT
Continuous lattices
Proc Dalhousie Conf Springer Lecture Notes in Math 1972
in press
9 D SCOTT
The lattice of flow diagrams
In E Engeler (ed) Semantics of Algorithmic Languages
Springer Lecture Notes in Math Vol 188 1971 pp 311-366.
This paper provides many examples of the limit concept.
Cf. also Ref 10
10 D SCOTT
Lattice theory, data types and semantics
NYU Symp on Formal Semantics Prentice-Hall 1972 in
press. This is a general introduction more detailed in some
respects than Ref 7

234

Spring Joint Computer Conference, 1972

11 C STRACHEY
Varieties of programming language
Proc ACM Conf Venice 1972 to appear. This paper
contains more examples
12 R A F AIRTHORNE
Remarks in P Atherton (ed) Classification Research
Munksgaard Copenhagen 1965 p 210
13 C STRACHEY
A n abstract model of storage
In preparation. This report will give complete details
14 Cf. Ref 11
15 D SCOTT C STRACHEY
Toward a mathematical semantics for computer languages
Proc of Symp on Computers and Automata Microwave
Research Institute Symp Ser Vol 21 Polytechnic Institute
of Brooklyn 1972 in press. A nearly identical language and

16
17
18

19

20

its semantics is outlined in this paper together with some
more of the mathematical background
Cf. Ref 13
Cf. Refs 7 and 8
R MILNER
Implementation and applications of Scott's logic for
computable functions
SIGPLAN Notices Vol 7 No 1 January 1972 pp 1-6.
(=SIGACT News No 14)
J W DE BAKKER
Recursive procedures
Math Centre Tracts 24 Mathematisch Centrum Amsterdam
1971. Other useful references are contained in these two
papers
Cf. Refs 9, 15 and 19 for further discussion of recursion

Applications of language theory to compiler design
by J. D. ULLMAN
Princeton University
Princeton, New Jersey

Go defines arithmetic expressions over operators + and
*, with no structured variables, and with a representing
any identifier.
The way in which a CFG serves to define strings of
terminal symbols is as follows.
Definition: Let G= (N, ~,P, S) be a CFG. We define
the relation =::}
on (NU ~) *, by: if a and (j are any strings
G
in (NU~) *, and A~')' is a production, then aA{j=::}a,),{j.
G
If a is in ~*, then aA{j =::} a,),{j and if {j is in ~*, then
Glm
aA{j =::} a')'{j; lm and rm stand for leftmost and rightmost,
Grm
respectively. The transitive closure of any relation R,
denoted R+, is defined by:

INTRODUCTION
There are certain aspects of language theory that have
had, or can have, significant impact on the design and
implementation of compilers. These areas are, principally, the subjects of context free grammars and syntax directed translations. It is perhaps to be expected
that the deep and interesting theorems of language
theory do not usually find application. Rather, it is the
definitions of formal constructs and their elementary
properties that find use.
In this paper, we will discuss some of the ways in
which the language theorist can help the compiler designer. First, we will discuss classes of context free
grammars that have fast parsing algorithms and discuss
briefly what these algorithms are. Then we shall discuss
schemes for specifying the translations which must be
performed by the compiler.

(1) if aRb, then aR+b;
(2) if aR+b, and bR+c, then aR+c;
(3) aR+b only if it so follows from (1) and (2).
The reflexive-transitive closure of relation R, denoted
R*, is defined by aR*b if and only if a = b or aR*b.
* for example, to express the noThus, we can use a=::}{j,

CONTEXT FREE GRAMMARS
Let us proceed to the principal formalism of use to
compiler writers, the context free grammar.
Definition: A context free grammar (CFG) is a fourtuple (N, ~, P, S), where N and ~ are finite, disjoint
sets of nonterminals and terminals, respectively; S in N,
is the start symbol, and P is a finite list of productions
of the form A~a, where A is in N and a in (NU~) *.t
Example: A good example grammar, which will be
subsequently referred to as Go, is ({E, T, F},
{a, (,), +, *}, P, E), where P consists of the following
productions.

G

tion that a can become {j by some (possibly null) sequence of replacements of left sides of productions by
their right sides.
We will, whenever no ambiguity results, drop the
subscript G from the nine relations =::}, =::} ,=::} ,and their
G .Glm Grm
transitive, and reflexive-transitive closures.
We say L (G), the language defined by G, is {w I w is
* l. L (G) is said to be a context-free lanin ~* and S=::}w
guage (CFL).
Convention: Unless we state otherwise, the following
convention regarding symbols of a context free grammar holds.

(1) E~E+T
(2) E~T
(3) T~T*F
(4) T~F

(5)
(6)

F~(E)

( 1) A, B, C, ... are nonterminals.
(2) ... , X, Y, Z are either terminals or nonterminals.
(3) a, b, c, ... are terminals.
(4) u, ... , z are terminal strings.

F~a

t If X is any alphabet, then X* denotes the set of finite length
strings of symbols in X, including e, the string of length O.

235

236

Spring Joint Computer Conference, 1972

(5) a, /3, ,,(, ... are strings of terminals and/or

nonterminals.
( 6) S is the start symbol; except in Go, where E is
the start symbol.
(7) e denotes the empty string.
We may, using this convention, specify a CFG merely
by listing its productions. Moreover, we use the shorthand A -7al I ••• I an to stand for the productions
A-7aI, A-7a2, ... ,A-7an.

Definition: Let G= (N, ~, P, S) be a CFG. If
'~an, then we say there is a derivation of an
from al. If ai~ai+I' 1:::; i < n, we call this a leftmost derial~a2~"

vation, and if

ai~ai+l,
rm

1:::; i

< n, it is a rightmost deriva-

tion. Most often, we are interested in the case where
al

= S. If S~a, then a is a sentential form. If S~a, it is

a left sentential form, and if

*

S~a,
rm

lm

it is a right sentential

form.
Example: Let us consider Go, and the string a*a+a
in L (Go). It has the following derivations, among
others.
(1)

E~E+T~T+T~T+F

(2)

~T*F+ F~T*a+ F~F*a+ F
~F*a+a~a*a+a
E~E+T~T+T~T*F+T

The construction of a tree defined above is called
top down. We can also construct the same tree bottom
up, as follows.
(1) Begin with an isolated node corresponding to
each symbol of an. As this algorithm proceeds,
we will have a collection of trees corresponding
to each step of the derivation. At the end, there
will be one tree for the first sentential form al
(i.e., S).
(2) Suppose we have a collection of trees for ai,
1 < i:::; n, where to each symbol of ai there corresponds a root of one of the trees. If ai is constructed from ai-I by replacing A by /3, create a
new node, labeled A, whose direct descendants
are the roots of the trees for the symbols of /3.
The order of symbols in /3 reflects the order of
the descendants. If, however, /3 = e, create one
descendant for the node labeled A, and label the
descendant e.
Example: The unique parse tree for a*a+a in Go is
shown below. Note that the leaves of the tree read
a*a+a, from the left.

E

~F*F+T~a*F+T~a*a+T
~a*a+F~a*a+a
(3) E~E+T~E+F~E+a~T+a
~T*F+a~T*a+a~F*a+a~a*a+a

Derivation (1) is neither rightmost nor leftmost. (2)
is leftmost and (3) is rightmost. F*a+F is a sentential
form of Go, but happens not to be a left or right sentential form. a*a+a is both a left and right sentential
form, and is in L(Go).
Given a derivation of w from S we can construct a
parse tree for w as follows. Let S = al~a2 .. .~an = w.
(1) Begin with a single node labeled S. This node is
a trivial tree, and is said to be the tree for al.
In general the tree for ai will have a leaf corresponding to each symbol of ai. Initially, the lone
symbol S of al corresponds to the lone node.
(2) Suppose we have constructed the tree for ai,
i < n. Let ai+1 be constructed by replacing some
instance of A in ai by /3. To this instance of A
there corresponds a leaf. Make descendants of
that leaf for each symbol of /3, ordered from the
left. If /3 is the empty string, then we create a
single descendant, labeled e.

E

T

T

1

j

T

F

/~

I

F

/I~
+

*

1
F

I

a

a

I

a

It is easy to show that the top down and bottom up
methods of tree construction yield the same tree when
applied to one derivation.
An important property of a CFG is that it be unambiguous, that is, no word in its language has more than
one parse tree. Because of the way syntax directed
translation algorithms work on parse trees, an ambiguous programming language is very likely to provide
surprising machine code when (at least some of) it~
programs are compiled. It is easy to show that the con-

Applications of Language Theory to Compiler Design

dition of unambiguity is tantamount to saying that
each word in the language has a unique leftmost derivation and a unique rightmost derivation.

Example: The lists for Go, with input a*a are shown
below.

II

10

E~·E+T,O F~a·,O

EARLEY'S ALGORITHM
There is one outstanding method of recognizing the
words of an aribtrary CFL and building parse trees,
although many others have been proposed. This is the
method of Earley.l Descriptions of other general
methods can be found in References 2 and 3. Earley's
method works as follows.
~, P, S) and let al ... an be the
word we wish to recognize or parse. We construct lists 10, II, ... , In, of items; an item is of
the form [A~a·{3, iJ, where A~a{3 is a production and i an integer.
(2) Construct 10 as follows.
(i) Add [S~·a, OJ to 10, for each S~a in P.
(ii) If [A~·Ba, OJ is on 10, add [B~·{3, OJ to
10, if it is not already there, for each B~{3
inP.
(3) Suppose we have constructed Ii-I. Construct
I i as follows.
(i) For all [A~a·ai{3, jJ on Ii-I, add
[A~aai·{3,jJ to Ii. Recall that ai is the
ith input position.
(ii) If [A~a· ,jJ is on list Ii, add [B~{3A .'Y, kJ
to Ii, if [B~{3·A'Y, kJ is on I j •
(iii) If [A~a·B{3,jJ is on Ii, add [B~·'Y, iJ to
Ii for all B~'Y in P.

(1) Let G= (N,

We can show that item [A~a·(3)jJ is placed on
I i if and only if there is a leftmost derivation

As a special case of the above, al ... an is in L (G) if
and only if [S~a·, OJ is on In for some a. Thus, it is
easy to see how Earley's algorithm can be used to
recognize the words of a language. Moreover, once the
lists have been constructed, it is possible to build the
parse tree of the word. We shall not explore this further
here, but the intuitive idea behind the tree construction algorithm is to let the item [S~a·, OJ on In
represent the root, then look for those complete (dot at
the right end) items which lead to its being placed on
In. Make these items correspond to the descendants of
the root, and proceed top down, finding "causes" for
each item corresponding to a node.

237

E~·T,O

T~F·,O

T~·T*F, 0

E~T·,O

T~·F,

T~T·*F,O

F~·

0

12
T~T*·F,

0
F~· (E), 2
F~·a, 2

13
F~a·,

2

T~T*F·,
E~T·,

0

0

T~T·*F,

0

(E), 0

F~·a,O

List 13 is constructed as follows. [F~a., 2J is added
by rule (3i), because [F~ ·a, 2J is on 12 • [T~T*F·, OJ
is added to 13 by rule (3ii) , because [T~T*· F, OJ is
on 12 and [F~a·, 2J is on 13 • [E~T., OJ and
[T~T·*F, OJ are added 'because [E~·T, OJ and
[T~· T*F, OJ are on 10, and [T~T*F·, OJ is on Ia.
Since [E~T·, OJ is on Is, a*a is in L (Go).
Earley's algorithm can be implemented in O(n2)
steps of a random access computer if the underlying
grammar is unambiguous, and in O(n3 ) steps for an
arbitrary grammar. Moreover, on many grammars of
practical interest, Earley's algorithm operates in 0 (n)
steps. It is the fastest known general parsing algorithm.
LL GRAMMARS
We will now begin the study of several subclasses of
the context free grammars. None of the three classes
we consider is capable of generating all the context
free languages. However, confronted with a context
free language that is associated with a real programming language, it is highly likely that grammars in the
classes to be discussed do exist.
Our first subclass of grammars, called LL(k), for
left to right scan, producing a leftmost derivation, with
k symbollookahead, was first examined in Reference 4.
The LL (l) case was developed independently in Reference 5. Development of the theory can be found in
References 6 and 7. The general idea can be summarized
as follows.
Let G= (N,~, P, S) be a CFG, and let w be in ~*. We
may attempt to find a leftmost derivation for w by
starting with S and trying to proceed to successive left
sentential forms. Suppose we have obtained

where ai=xA{3, and x is a prefix of w. If there are
several productions with A on the left, we must select
the proper one. It is desirable that we be able to do so
using only information which we have accumulated so
far during the parse (which we represent by saying
that we "know what (3 is") and the k symbols of w be-

238

Spring Joint Computer Conference, 1972

yond prefix x, for some small k. If we can always make
this decision correctly, we say G is LL (k ) .
If a grammar is LL(k), we can parse it deterministically in a simple fashion. One pushdown list, which
holds the portion of a left sentential form to the right
of the prefix of terminals (A,8 in the case of ai, above)
is used. (There is also some other information on the
list, but we shall not discuss this here. A discussion
can be found in in Reference 3.) The input w is scanned
left to right, and if ai has been reached, the input
pointer will have scanned over prefix x, and is ready
to read the first k symbols of w. The arrangement is
shown below.

Stated less formally, suppose we are parsing w, and
have so far reached left sentential form xAa. We have,
as indicated in the informal parsing procedure which
introduced the section, not scanned w more than k
symbols beyond x. Thus, either xy or xz could be w, as
far as we know. Suppose A~,8 and a~'Y are two productions. Then the LL(k) definition assures us that
independent of w, but depending on x, a and the first
symbols of w beyond x (which are y:k, or equivalently,
z: k), we may uniquely select the proper production
with which to replace A.
Example: Consider the grammar

Ib
B~bSS I a
S~aBB

w

x

t

top

input pointer

I

pushdown list

~~

A!3
If production A ~'Y is chosen to expand A, the pushdown list is made to hold "1,8. Then, any terminals on
top of the pushdown list are compared with the input
immediately to the right of the input pointer, and the
next left sentential form will be properly represented.
The process of expanding the topmost nonterminal on
the pushdown list then repeats. Note that while expanding nonterminals, we could construct a parse tree
top down if we wished.
It should be noted that the pushdown list may carry
information other than grammar symbols, in order to
summarize at the top of the list, the important information about what is in the list (,8 in our example).
However, this information is not essential, if the grammar is modified properly. We now give the formal
definition of an LL(k) grammar.
Definition: If a is a string, let I a I denote the length
of a. Let a: k denote the first k symbols of a, or all of
a if I a I 

u:

0

500 BIT PACKETS PLUS OVERHEAD

r

~

:::r

::0

0

I\)

c
C)
:::r
\J
c

0
0

~

UI

~

r

1000 BIT PACKETS PLUS OVERHEAD
I\)

0

curve A with the points obtained by simulation, the
curve should actually be recomputed for the slightly
skewed distribution that resulted. It is notable that the
delay estimates from the simulation (which used a
dynamic routing strategy) and the computation (which
used a static routing strategy and the time delay formula) are in close agreement. In particular, they both
accurately determined the vertical rise of the delay
curve in the range just above 400 kilobits/second, the
formula by predicting infinite delay and the simulation
by rejecting the further input of traffic.
In practice and from the analytic and simulation
studies of the ARPANET, the average queueing delay
is observed to remain small (almost that of an unloaded
net) and well within the design constraint of 0.2 seconds
until the traffic within the network approaches the
capacity of a cutset. The delay then increases rapidly.
Thus, as long as traffic is low enough and the routing
adaptive enough to avoid the premature saturation of
cutsets by guiding traffic along paths with excess capacity,
queueing delays are not significant.

0

III

=i

en
.....
en
m
0

Channel capacity optilllization

~

0
0

1000 BIT PACKETS WITHOUT OVERHEAD
500 BIT PACKETS WITHOUT OVERHEAD

~

UI

0

.I:>

o
o

.I:>

g------~------~------~------~----~

Figure 3-Delay

VB.

throughput

total throughput slightly greater than 400 kilobitsl
second is reached. The delay then increases rapidly.
Curves C and D respectively represent the same
situations when the overhead of 136 bits per packet and
per RFNM and 152 bits per acknowledgment are
included. Notice that the total throughput per IMP
is reduced to 250 kilobits/second in case C and to
approximately 200 kilobits/second in case D.
In the same figure, we have illustrated with x's the
results of a simulation performed with a realistic
routing and metering strategy. The simulation omitted
all network overhead and assumed fixed lengths of
1000 bits for all packets.
It is difficult to develop a practical routing and flow
control procedure that will allow each IMP to input
identical amounts of traffic. To compare the delay

One of the most difficult design problems is the
optimal selection of capacities from a finite set of
options. Although there are many heuristic approaches
to this problem, analytic results are relatively scarce.
(For the specialized case of centralized networks, an
algorithm yielding optimal results is available. 11 ) While
it is possible to find an economical assignment of
discrete capacities for, say, a 200 IMP network, very
little is known about the relation between such capacity
assignments, message delay, and cost .
To obtain theoretical properties of optimal capacity
assignments, one may ignore the constraint that
capacities are obtainable only in discrete sizes. In
Reference 21 such a problem was posed where the
network topology and average traffic flow were assumed
to be known and fixed and an optimal match of capacities to traffic flow was found. Also, the traffic was
assumed to be Markovian (Poisson arrivals and
exponential packet lengths) and the independence
assumption and decomposition method were applied.
For each channel, the capacity Ci was found which
minimized the average message delay T, at a fixed
total system cost D. Since AilJ.i.. is the average bit rate on
the ith channel, the solution to any optimal assignment
problem must provide more than this minimal capacity
to each channel. This is clear since both Equations (6)
and (7) indicate that T i will become arbitrarily large
with less than (or equal to) this amount of capacity.
It is not critical exactly how the excess capacity is

Computer Communication Network Design

assigned, as long as C i > AilJ.l.. Other important parameters and insights have been identified in studying the
continuous capacity optimization problem. For example, the number of excess dollars, De, remaining
after the minimum capacity AilJ.l. is assigned to each
channel is of great importance. As De~O, the average
delay must grow arbitrarily large. In this range, the
critical parameters become p and n where p = 'YI J.l.C is
the ratio of the rate 'YI J.l. at which bits enter the network
to the rate C at which the net can handle bits and
n = AI 'Y, where A= I)i is the total rate at which packets
flow within the net. The quantity p represents a dimensionless form of network "load" whereas n is easily
shown to represent the average path length for a
packet.
As the load p approaches lin, the delay T grows very
quickly, and this point p= lin represents the maximum
load which the network can support. If capacities are
assigned optimally, all channels saturate simultaneously
at this point. In this formulation n is a design parameter
which depends upon the topology and the routing
procedure, while p is a parameter which depends upon
the input rate and the total capacity of the network.
In studying the ARPANET23 a closer representation
of the actual tariffs for high speed telephone data
channels used in that network was provided by setting
D = Li diC i where 0 ~ a ~ 1. * This approach requires
the solution of a non-linear equation by numerical
techniques. On solving the equation, it can be shown
that the packet delay T varies insignificantly with a
for .3 ~ a ~ 1. This indicates that the closed form
solution discussed earlier with a = 1 is a reasonable
approximation to the more difficult non-linear problem.
These continuous capacity studies have application to
general network studies (e.g. , satellite communications )33
and are under continued investigation. 25 ,26,46
In practice, the selection of channel capacities must
be made from a small finite set. Although some theoretical work has been done in this case by approximating the discrete cost-capacity functions by
continuous ones, much remains to be done. I3 ,25 Because
of the discrete capacities and the time varying nature
of network traffic, it is not generally possible to match
channel capacities to the anticipated flows within the
channels. If this were possible, all channels would
saturate at the same externally applied load. Instead,
capacities are assigned on the basis of reasonable
estimates of average or peak traffic flows. It is the
responsibility of the routing procedure to permit the
traffic to adapt to the available capacity,l4 Often two

* Of course the tariffs reflect the discrete nature of available
channels. The use of the exponent a provides a continuous fit
to the discrete cost function. For the ARPANET, a~.8.

267

IMP sites will engage in heavy communication and
thus saturate one or more critical network cutsets. In
such cases, the routing will not be able to send additional flow across these cuts. The network will therefore
experience "premature" saturation in one or a small set
of channels leading to the threshold behavior described
earlier.
DISCUSSION
A major conclusion from our experience in network
design is that message switched networks of the ARPA
type are no longer difficult to specify. They may be
implemented straightforwardly from the specifications;
they can be less expensive than other currently available
technical approaches; they perform remarkably well as
a communication system for interconnecting timesharing and batch processing computers and can be
adapted to directly handle teletypes, displays and many
other kinds of terminal devices and data processing
equipment. I6 ,3o
The principal tools available for the design of networks are analysis, simulation, heuristic procedures,
and experimentation. Analysis, simulation and heuristics
have been the mainstays of the work on modeling and
topological optimization while simulation, heuristic
procedures and experimental techniques have been the
major tools for the actual network implementation.
Experience has shown that all of these methods are
useful while none are all powerful. The most valuable
approach has been the simultaneous use of several of
these tools.
Each approach has room for considerable improvement. The analysis efforts have not yet yielded results
in many important areas such as routing. However, for
prediction of delay, this approach leads to a simple
threshold model which is both accurate and understandable. Heuristic procedures all suffer from the
problem that it is presently unclear how to select
appropriate heuristics. It has been the innovative use
of computers and analysis that has made the approach
work well. For designing networks with no more than a
few hundred IMPs, present heuristics appear adequate
but a good deal of additional work is required for networks of greater size. Simulation is a well developed tool
that is both expensive to apply and limited in the overall
understanding that it yields. For these reasons, simulation appears to be most useful only in validating models,
and in assisting in detailed design decisions such as the
number of buffers that an IMP should contain. As the
size of networks continues to grow, it appears that
simulation will become virtually useless as a total design
tool. The ultimate standard by which all models and

268

Spring Joint Computer Conference, 1972

conclusions can be tested is experimentation. Experimentation with the actual network is conceptually
relatively straightforward and very useful. Although,
experiments are often logistically difficult to perform,
they can provide an easy means for testing models,
heuristics and design parameters.
The outstanding design problems currently facing
the network designer are to specify and determine the
properties of the routing, flow control and topological
structure for large networks. This specification must
make full use of a wide variety of circuit options.
Preliminary studies indicate that initially, the most
fruitful approaches will be based on the partitioning of
the network into regions, or equivalently, constructing
a large network by connecting a number of regional
networks. To send a message, a Host would specify
both the destination region and the destination IMP
in that region. No detailed implementation of a large
network has yet been specified but early studies of their
properties indicate that factors such as cost, throughput,
delay and reliability are similar to those of the present
ARPANET, if the ARPA technology is used. 9
Techniques applicable to the design of large networks
are presently under intensive study. These techniques
appear to split into the same four categories as small
network design but approaches may differ significantly.
For example, large nets are likely to demand the placement of high bandwidth circuits at certain key locations
in the topology to concentrate flow. These circuits will
require the development of a high speed IMP to connect
them into the net. It is likely that this high speed IMP
will have the structure of a high speed multiplexor, and
may require several cooperating processors to obtain
the needed computer power for the job. Flow control
strategies for large networks seem to extrapolate nicely
from small network strategies if each region in the large
network is viewed as a node in a smaller network.
However, this area will require additional study as will
the problem of specifying effective adaptive routing
mechanisms. Recent efforts indicate that efficient
practical schemes for small networks will soon be
available. These schemes seem to be applicable for
adaptive routing and flow control in networks constructed from regional subnetworks. The development
of practical algorithms to handle routing and flow
control is still an art rather than a science. Simulation is
useful. for studying the properties of a given heuristic,
but intuition still plays a dominant role in the system
design.
Several open questions in network design presently
are: (1) what structure should a high bandwidth IMP
have; (2) how can full use be made of a variety of high
bandwidth circuits; (3) how should large networks be
partitioned for both effective design and operation;

and (4) what operational procedures should large
networks follow? Much work has already been done in
these areas but much more remains to be done. We
expect substantial progress to be achieved in the next
few years, and accordingly, the increased understanding
of the properties of message switched networks of
all sizes.
ACKNOWLEDGMENT
The ARPA Network is in large part the conception of
Dr. L. G. Roberts of the Advanced Research Projects
Agency to whom we owe a debt of gratitude for his
support and encouragement. We also acknowledge the
helpful contributions of S. Crocker and B. Dolan of
ARPA. At BBN, NAC, and UCLA many individuals,
too numerous to list, participated in the network effort
and we gratefully acknowledge their contributions.
REFERENCES
1 P BARAN S BOEHM P SMITH
On distributed communications
Series of 11 reports by Rand Corporation Santa Monica
California 1964
2 "Specifications for the interconnection of a Host and
an IMP
BBN Report No 1822 1971 revision
3 S CARR S CROCKER V CERF
Host-Host communication protocol in the ARPA network
SJCC 1970 pp 589-597
4 S CROCKER et al
Function oriented protocols for the ARPA network
SJCC 1972 in this issue
5 D W DAVIES
The control of congestion in packet switching networks
Proc of the Second ACM IEEE Symposium on problems
in the Optimization of Data Communications Systems
Palo Alto California Oct 1971 pp 46-49
6 D FARBER K LARSON
The architecture of a distributed computer system-An
informal description
University of California Irvine Information and
Computer Science Technical Report #11 1970
7 W D FARMER E E NEWHALL
A n experimental distribution switching system to handle
bursty computer traffic
Proc of the ACM Symposium on Problems in the
Optimization of Data Communication Systems 1969
pp 1-34
8 H FRANK W CHOU
Routing in computer networks
Networks John Wiley 1971 Vol 1 No 2 pp 99-112
9 H FRANK W CHOU
Cost and throughput in computer-communication networks
To appear in the Infotech Report on the State of the
Art of Computer Networks 1972
10 H FRANK I T FRISCH
Communication transmission and transportation networks
Addison Wesley 1972

Computer Communication Network Design

11 H FRANK I T FRISCH W CHOU
R VAN SLYKE
Optimal design of centralized computer networks
Networks John Wiley Vol 1 No 1 pp 43-571971
12 H FRANK I T FRISCH W CHOU
Topological considerations in the design of the
ARPA computer network
SJCC May 1970 pp 581-587
13 L FRATTA M GERLA L KLEINROCK
The flow deviation method; An approach to
store-and-forward network design
To be published
14 G FULTZ L KLEINROCK
Adaptive routing techniques for store-and-forward
computer-communication networks
Proc of the International Conference on
communications 1971 pp 39-1 to 39-8
15 F HEART R KAHN S ORNSTEIN
W CROWTHER D WALDEN
The interface message processor for the ARPA
computer network
SJCC 1970 pp 551-567
16 R E KAHN
Terminal access to the ARPA computer network
Proc of Third Courant Institute Symposium Nov 1970
To be published by Prentice Hall Englewood Cliffs, NJ
17 R E KAHN W R CROWTHER
Flow control in a resource sharing computer network
Proc of the Second ACM IEEE Symposium on
Problems in the Optimization of Data Communications
Systems Palo Alto California October 1971 pp 108-116
18 R E KAHN W R CROWTHER
A study of the ARPA network design and performance
BBN Report No 2161 August 1971
19 J F C KINGMAN
Some inequalities for the queue GI/G/l
Biometrica 1962 pp 315-324
20 L KLEINROCK
Queueing systems; Theory and application
To be published by John Wiley 1972
21 L KLEINROCK
Communication nets: Stochastic message flow and delay
McGraw-Hill 1964
22 L KLEINROCK
Models for computer networks
Proc of the International Conference on Communications
1969 pp 21-9 to 21-16
23 L KLEINROCK
Analysis and simulation methods in computer
network design
SJCC 1970 pp 569-579
24 T MARILL L G ROBERTS
Toward a cooperative network of time-shared computers
FJCC 1966
25 B MEISTER H MULLER H RUDIN JR
Optimization of a new model for message-switching
networks
Proc of the International Conference on Communications
1971 pp 39-16 to 39-21
26 B MEISTER H MULLER H RUDIN
New optimization criteria for message-switching
networks
IEEE Transactions on Communication Technology
Com-19 June 1971 pp 256-260

269

27 N. A. C. Third Semiannual Technical Report for the
Project Analysis and Optimization of Store-and-Forward
Computer Networks
Defense Documentation Center Alexandria Va
June 1971
28 N. A. C. Fourth Semiannual Technical Report for the
Project Analysis and Optimication of Store-and-Forward
Computer Networks
Defense Documentation Center Alexandria Va Dec 1971
29 The Host/Host protocol for the ARPA network
Network Working Group N I C No 7147 1971 (Available
from the Network Information Center Stanford
Research Institute Menlo Park California)
30 ORNSTEIN et al
The terminal IMP for the ARPA network
SJCC 1972 In this issue
31 J PIERCE
A network for block switching of data
IEEE Convention Record N ew York N Y March 1971
32 E PORT F CLOS
Comparisons of switched data networks on the basis of
waiting times
IBM Research Report RZ 405 IBM Research
Laboratories Zurich Switzerland Jan 1971 (Copies
available from IBM Watson Research Center
POBox 218 Yorktown Heights New York 10598)
33 H G RAYMOND
A queueing theory approach to communication
satellite network design
Proc of the International Conference on Communication
pp 42-26 to 42-311971
34 L G ROBERTS
Multiple computer networks and inter-computer
communications
ACM Symposium on Operating Systems
Gatlinburg Tenn 1967
35 L G ROBERTS
A forward look
SIGNAL Vol XXV No 12 pp 77-81 August 1971
36 L G ROBERTS
. Resource sharing networks
IEEE International Conference March 1969
37 L G ROBERTS
Access control and file directories in computer networks
IEEE International Convention March 1968
38 L G ROBERTS B WESSLER
Computer network development to achieve resource sharing
SJCC 1970 pp 543-549
39 L G ROBERTS B WESSLER
The ARPA computer network
In Computer Communication Networks edited by
Abramson and Kuo Prentice Hall 1972
40 R A SCANTLEBURY P T WILKINSON
The design of a switching system to allow remote
access to computer services by other computers
Second ACM/IEEE Symposium on Problems in the
Optimization of Data Communications Systems
Palo Alto California October 1971
41 R A SCANTLEBURY
A model for the local area of a data communication
network-Objectives and hardware organization
ACM Symposium on Problems in the Optimization
of Data Communication Systems Pine Mountain Ga
1969 pp 179-201

270

Computer Communication

Ne~work

Design

42 R H THOMAS D A HENDERSON
M cRoss-A multi-computer programming system
SJCC 1972 In this issue
43 R VAN SLYKE H FRANK
Reliability of computer-communication networks
Proc of the Fifth Conference on Applications of
Simulation New York December 1971
44 R VAN SLYKE H FRANK
Network reliability analysis-I
Networks VolIN0 3 1972
45 E WOLMAN
A fixed optimum cell size for records of various length
JACM 1965 pp 53-70
46 L KLEINROCK
Scheduling, queueing and delays in time-sharing
systems and computer networks
To appear in Computer-Communication Networks
edited by Abramson and Kuo Prentice Hall 1972
47 A H WEIS
Distributed network activity at IBM
IBM Research Report RC3392 June 1971

48 M BEERE N SULLIVAN
Tymnet-A serendipitous evolution
Second ACM IEEE Symposium on Problems in the
Optimization of Data Communications Systems Palo
Alto California 1971 pp 16-20
49 W TEITELMAN R E KAHN
A network simulation and display program
Third Princeton Conference on Information Sciences
and Systems 1969 p 29
50 P BURKE
The output of a queueing system
Operations Research 1956 pp 699-704
51 J R Jackson
Networks of waiting lines
Operations Research Vol 5 1957 PI? 518-521
52 D B McKAY D P KARP
Network/440-IBM Research Computer Sciences
Department Computer Network
IBM Research Report RC3431 JUly 1971

Function-oriented protocols for the ARPA Computer Network
by STEPHEN D. CROCKER

JOHN F. HEAFNER

ROBERT M. METCALFE

Advanced Research Projects Agency
Arlington, Virginia

The RAND Corporation
Santa Mon ca, California

Massachusetts Institute of Technology
Cambridge, Massachusetts

and

JONATHAN B. POSTEL
University of California
Los Angeles, California

INTRODUCTION

message exchange between ARPANET Interface
Message Processors (IMPs). 2 ,5 A high level protocol is
one with primitives closely related to a substantive use.
At the lowest levels the contents of messages are unspecified. At higher levels, more and more is stated
about the meaning of message contents and timing. The
layers of protocol are shown in Figure 3.
A second way of structuring sets of protocols and
their design is bound up in the word factoring. At any
level of protocol are sets of format and timing rules
associated with particular groupings of agreements. In
the IMPs we find certain protocols pertaining to error
handling, while others to flow control, and still others
to message routing. At the ARPANET's user-level
communications interface there are, among others,
separable protocols associated with establishing connections and logical data blocking. These protocols do
not nest, but join as modules at the same level.
Before moving on to consider the higher level function-oriented protocols, let us first make a few statements about underlying protocols. There are three
lower level software protocols which nest in support of
the user-level communications interface for the ARPANET. The lowest of these is the IMP-IMP protocol
which provides for reliable communication among
IMPs. This protocol handles transmission-error detection and correction, flow control to avoid message
congestion, and routing. At the next higher level is the
IMP-HOST protocol which provides for the passage
of messages between HOSTs and IMPs in such a way
as to create virtual communication paths between
HOSTs. With IMP-HOST protocol, a HOST has
operating rules which permit it to send messages to
specified HOSTs on the ARPANET and to be informed
of the dispensation of those messages. In particular, the
IMP-HOST protocol constrains HOSTs in their transmissions so that they can make good use of available

Much has been said about the mechanics of the ARPA
Computer Network (ARPANET) and especially about
the organization of its communications subnet. 1 ,2 ,3 ,4 ,5
Until recently the main effort has gone into the implementation of an ARPANET user-level communications
interface. Operating just above the communications
subnet in ARPANET HOST Computers, this ARPANET interface is intended to serve as a foundation for
the organization of function-oriented communications. 6 ,7 See Figures 1 and 2 for our view of a computer
system and the scheme for user-level process-to-process
communications. It is now appropriate to review the
development of protocols which have been constructed
to promote particular substantive uses of the
ARPANET, namely function-oriented protocols.
We should begin this brief examination by stating
what we mean by the word "protocol" and how protocols fit in the plan for useful work on the ARPANET.
When we have two processes facing each other across
some communication link, the protocol is the set of
their agreements on the format and relative timing of
messages to be exchanged. When we speak of a protocol, there is usually an important goal to be fulfilled.
Although any set of agreements between cooperating
(i.e., communicating) processes is a protocol, the protocols of interest are those which are constructed for
general application by a large population of processes
in solving a large class of problems.
In the understanding and generation of protocols
there are two kinds of distinctions made. Protocols in
the ARPANET are layered and we speak of high or
low level protocols. High level protocols are those most
closely matched to functions and low level protocols
deal with communications mechanics. The lowest level
software protocols in the ARPANET involve reliable
271

272

Spring Joint Computer Conference, 1972

M
p
File System

Terminal Control

Termina 1
Operating
System
Boundary
Termina 1

Figure 1-0ur view of a computer system

communications capacity without denying such availability to other HOSTs.
The HOST-HOST protocol, finally, is the set of
rules whereby HOSTs construct and maintain communication between processes (user jobs) running on
remote computers. One process requiring communications with another on some remote computer system
makes requests on its local supervisor to act on its
behalf in establishing and maintaining those communications under HOST-HOST protocol.
In constructing these low levels of protocol it was the
intention to provide user processes with a general set
of useful communication primitives to isolate them
from many of the details of operating systems and
communications. At this user-level interface functionoriented protocols join as an open-ended collection of
modules to make use of ARPANET capabilities.
The communications environment facing the designers of function-oriented protocols in the ARPANET

is essentially that of a system of one-way byte-oriented
connections. Technically speaking, a "connection" is a
pair: a "send socket" at one end and a "receive socket"
at the other. Primitives provided at the user-level
interface include:
1.
2.
3.
4.
5.

Initiate connection (local socket, foreign socket),
Wait for connection (local socket),
Send, Receive (local socket, data),
Close (local socket),
Send interrupt signal (local socket).

Processes in this virtual process network can create
connections and transmit bytes. Connections are subject to HOST-HOST flow control and the vagaries of
timing in a widely distributed computing environment,
but care has been taken to give user processes control
over their communications so as to make full use of
network parallelism and redundancy. The kind of
agreements which must be made in the creation of

Function-Oriented Protocols for ARPA Computer Network

273

Figure 2-Two communicating processes

function-oriented protocols relate to rules for establishing connections, to the timing rules which govern
transmission sequences, and to the content of the bytestreams themselves.
USE OF REMOTE INTERACTIVE SYSTEMS
The application which currently dominates ARPANET activity is the remote use of interactive systems.
A Telecommunications Network (TELNET) protocol
is followed by processes cooperating to support this
application. 8 A user at a terminal, connected to his
local HOST, controls a process in a remote HOST as if
he were a local user of the remote HOST. His local
HOST copies characters between his terminal and
TELNET connections over the ARPANET. We refer
to the HOST where the user sits as the using HOST,
and to the remote HOST as the serving HOST. See
Figure 4.

At the using HOST, the user must be able to perform the following functions through his TELNET
user process ("user-TELNET") :
1. Initiate a pair of connections to a serving HOST,

2.
3.
4.
5.

Send characters to the serving HOST,
Receive characters from the serving HOST,
Send a HOST-HOST interrupt signal,
Terminate conn.ections.

The user-TELNET needs to be able to distinguish between (1) commands to be acted on locally and (2)
input intended for the serving HOST. An escape character is reserved to mark local commands. Conventions
for the ARPANET Terminal IMP (TIP) userTELNET are typical. 9
In most using HOSTs, the above functions are provided by a user-TELNET which is a user-level program.
A minimal user-TELNET need only implement the
above functions, but several additional support func-

274

Spring Joint Computer Conference, 1972

_ _ _ _ _ _ -USER LEVEL- -

-

-

-

-

-

Actua 1 Communica tion
Virtua 1 Communication (=Protocol)

Figure

3~The

layers of protocol

tions are often provided (e.g., saving a transcript of a
session in a local file, sending a file in place of usertyped input, reporting whether various HOSTs are or
have been up).
In the serving HOST it is desirable that a process
controlled over the ARPANET behave as it· would if
controlled locally. The cleanest way to achieve this
goal is to generalize the terminal control portion (TCP)
of the operating system to accept ARPANET terminal
interaction. It is unpleasant to modify any portion of
a working computer system and modification could be
avoided if it were possible to use a non-supervisor
process (e.g., "server-TELNET" or "LOGGER") to
perform the job creation, login, terminal input-output,
interrupt, and logout functions in exactly the same way

USING HOST

I

M
P

Terminal Control

Termina 1

I
M
p

Termina 1 Control

SERVING HOST
Figure 4-Data flow for remote interactive use

Function-Oriented Protocols for ARPA Computer Network

M

Figure 5-Data flow scheme for server

as a direct console user. Prior to the development of the
ARPANET, no operating system provided these functions to nOD-supervisor processes in anywhere near the
required completeness. Some systems have since been
modified to support this generalized job control scheme.
See Figures 5 and 6.
Efforts to standardize communications in the TEL-

275

NET protocol focused on four issues: character set,
echoing, establishing connections, and attention
handling.
The chosen character set is 7-bit ASCII in 8-bit
fields with the high-order bit off. Codes with the highorder bit on are reserved for TELNET control functions. Two such TELNET control function codes are
the "long-space" which stands for the 200 millisecond
space generated by the teletype BREAK button, and
the synchronizatiQn character (SYNCH) discussed below in conjunction with the purpose of the TELNET
interrupt signal.
Much controversy existed regarding echoing. The
basic problem is that some systems expect to echo,
while some terminals always echo locally. A set of conventions and signals was developed to control which
side of a TELNET connection should echo. In practice,
those systems which echo have been modified to include
provision for locally echoing terminals. This is a nontrivial change affecting many parts of a serving HOST.
For example, normally echoing server HOSTs do not
echo passwords so as to help maintain their security.
Terminals which echo locally defeat this strategy, how-

N C P

M

p

Terminal Control

LOGGER must be a background service program capable of initiating jobs
Figure 6-Alternate data flow scheme for a server

276

Spring Joint Computer Conference, 1972

M

Figure 7-Data flow and processing of the character
input stream

ever, and some other protection scheme is necessary.
Covering the password with noise characters is the
usual solution.
The HOST-HOST protocol provides a large number
of sockets for each HOST, but carefully refrains from
speeifying which ones are to be used for what. To establish communication between a user-TELNET and a
server-TELNET some convention is required. The
Initial Connection Protocol (ICP)lO is used:
1. Connection is initiated from a user-TELNET's
receive socket to a serving HOST's socket 1
(a send socket).
2. When the initial connection is established, the
serving HOST sends a- generated socket number
and closes the connection. This socket number
identifies an adjacent socket pair at the serving
HOST through which the user-TELNET can
communicate with a server-TELNET.
3. TELNET connections are then initiated between the now specified pairs of sockets. Two
connections are used to provide bi-directional
communication.

Note that socket 1 at the serving HOST is in use only
long enough to send another socket number with which
to make the actual service connections.
One of the functions performed by·a terminal control
program within an operating system is the scanning of
an input stream for attention characters intended to
stop an errant process and to return control to the
executive. Terminal control programs which buffer input sometimes run out of space. When this happens to
a local terminal's input stream, a "bell" or a question

mark is echoed and the overflow character discarded,
after checking to see if it is the attention character. See
Figure 7. This strategy works well in practice,but it
depends rather strongly on the intelligence of the human
user, the invariant time delay in the input transmission
system, and a lack of buffering between type-in and attention checking. None of these conditions exists for
interactive traffic over the net: The serving HOST cannot control the speed (except to slow it down) or the
buffering within the using HOST, nor can it even know
whether a human user is supplying the input. It is thus
necessary that the terminal control program or serverTELNET not, in general, discard characters from a network input stream; instead it must suspend its acceptance of characters via the HOST-HOST flow control
mechanism. Since a HOST may only send messages
when there is room at the destination, the responsibility
for dealing with too much input is thus transferred back
to the using HOST. This scheme assures that no characters accepted by the using HOST are inadvertently lost.
However, if the process in the serving HOST stops accepting input, the pipeline of buffers between the userTELNET and remote process will fill up so that attention characters cannot get through to the serving
executive. In the TELNET protocol, the solution to
this problem calls for the user-TELNET to send, on
request, a HOST-HOST interrupt signal forcing the
server-TELNET to switch input modes to process network input for attention characters. The serverTELNET is required to scan for attention characters
in its network input, even if some input must be discarded while doing so. The effect of the interrupt signal
to a server-TELNET from its user is to cause the buffers between them to be emptied for the priority processing of attention characters.
To flip an attention scanning server-TELNET back
into its normal mode, a special TELNET synchronization character (SYNCH) is defined. When the· serverTELNET encounters this character, it returns to the
strategy of accepting terminal input only as buffer
space permits. There is a possible race condition if the
SYNCH character arrives before the HOST-HOST
interrupt signal, but the race is handled by keeping
a count of SYNCHs without matching signals. Note
that attention characters are HOST specific and may
be any of 129 characters-128 ASCII plus "long
space"-while SYNCH is a TELNET control character
recognized by all server-TELNETs. It would not do
to use the HOST-HOST signal alone in place of the
signal-SYNCH combination in attention processing,
because the position of the SYNCH character in the
TELNET input stream is required to determine where
attention processing ends and where normal mode input
processing begins.

Function-Oriented Protocols for ARPA Computer Network

277

FILE TRANSFER
When viewing the ARPANET as a distributed
computer operating system, one initial question is that
of how to construct a distributed file system. Although
it is constructive to entertain speculation on how the
ultimate, automated distributed file system might look,
one important first step is to provide for the simplest
kinds of explicit file transfer to support early substantive use.
During and immediately after the construction of the
ARPANET user-level process interface, several ad hoc
file transfer mechanisms developed to provide support
for initial use. These mechanisms took two forms: (1)
use of the TELNET data paths for text file transfer and
(2) use of raw byte-stream communication between
compatible systems.
By adding two simple features to the user-TELNET,
text file transfer became an immediate reality. By
adding a "SCRIPT" feature to user-TELNETS
whereby all text typed on the user's console can be
directed to a file on the user's local file system, a user
need only request of a remote HOST that a particular
text file be typed on his console to get that file transferred to his local file system. By adding a "SENDFILE" feature to a user-TELNET whereby the contents of a text file can be substituted for console type-in,
a user need only start a remote system's editor as if to
enter new text and then send his local file as type-in
to get it transferred to the remote file system. Though
crude, both of these mechanisms have been used with
much success in getting real work done.
Between two identical systems it has been a simple
matter to produce programs at two ends of a connection
to copy raw bits from one file system to another. This
mechanism has also served well in the absence of a more
general and powerful file transfer system.
Ways in which these early ad hoc file transfer mechanisms are deficient are that (1) they require explicit
and often elaborate user intervention and (2) they depend a great deal on the compatibility of the file systems involved. There is an on-going effort to construct
a File Transfer Protocol (FTP)1l,12 worthy of wide
implementation which will make it possible to exchange
structured sequential files among widely differing file
systems with a minimum (if any) explicit user intervention. In short, the file transfer protocol being developed provides for the connection of a file transfer'
user process ("user-FTP") and file transfer server
process ("server-FTP") according to the Initial Connection Protocol discussed above. See Figure 8. A user
will be able to request that specific file manipulation
operations be performed on his behalf. The File Transfer Protocol will support file operations including (1)

M

Background File Service Program or Server-FTP

Figure 8-Data flow for file transfer

list remote directory, (2) send local file, (3) retrieve remote file, (4) rename remote file, and (5) delete remote
file.
It is the intention of the protocol designers to regularize the protocol so that file transfer commands can
be exchanged by consoles file transfer jobs engaged in
such exotic activities as automatic back-up and dynamic file migration. The transfers envisioned will be
accompanied with a Data Transfer Protocol (DTP)ll
rich enough to preserve sequential file structure and in
a general enough way to permit data to flow between
different file systems.
USING THE ARPANET FOR REMOTE
JOB ENTRY
A very important use of the ARPANET is to give a
wide community of users access to specialized facilities.
One type of facility of interest is that of a very powerful
number-cruncher. Users in the distributed ARPANET
community need to have access to powerful machines
for compute-intensive applications and the mode of
operation most suited to these uses has been batch
Remote Job Entry (RJE). Typically, a user will generate
a "deck" for submission to a batch system. See Figure 9.
He expects to wait for a period on the order of tens of
minutes or hours for that "deck" to be processed, and
then to receive the usually voluminous output thereby
generated. See Figure 10.
As in the case of file transfer, there are a few useful
ad hoc ARPANET RJE protocols. A standard RJE
protocol is being developed to provide for job submission to a number of facilities in the ARPANET.
This protocol is being constructed using the TELNET
and File Transfer protocols. A scenario which sketches
how the protocol provides the RJE in the simplest,
most explicit way is as follows:
Via an ARPANET RJE process, a user connects his

278

Spring Joint Computer Conference, 1972

I
M
P

File

I
M
P

Terminal
Control

Queue of
Submitted Jobs

Prepared "deck"

Figure 9-Submission of RJE input

terminal to an RJE server process at the HOST to
which he intends to submit his job "deck." Through
a short dialogue, he establishes the source of his input

I
M

P

and initiates its transfer using the File Transfer Protocol. At some later time, the user reconnects to the appropriate RJE server and makes an inquiry on the

I
M
P

Fi Ie Sys tern

Figure lO-Retrieval of RJE output

Function-Oriented Protocols for ARPA Computer Network

status of his job. When notified that his input has been
processed, he then issues commands to the serving
HOST to transfer his output back.
We can of course imagine more automatic ways of
achieving these same functions. A user might need only
type a job submission command to his local system.
Automatically and invisibly, then, the local system
would connect and converse with the specified RJE
server causing the desired output to later appear in the
users file area or perhaps on a local line printer. The
intention is to design the RJE protocol so that the explicit use can start immediately and the more automatic
RJE systems can be built as desired.
OTHER PROTOCOLS AND CONCLUSIONS
One of the more difficult problems in utilizing a network of diverse computers and operating systems is that
of dealing with incompatible data streams. Computers
and their language processors have many ways of
representing data. To make use of different computers
it is necessary to (1) produce a mediation scheme for
each incompatibility or (2) produce a standard representation. There are many strong arguments for a
standard representation, but it has been hypothesized
that if there were a simple way of expressing a limited
set of transformations on data streams, that a large
number of incompatibilities could be resolved and a
great deal of computer-computer cooperation expedited.
The bulk of protocol work is being done with the
invention of standard representations. The TELNET
protocol, as discussed, is founded on the notion of a
standard terminal called the Network Virtual Terminal
(NVT). The File Transfer Protocol is working toward
a standard sequential file (a Network Virtual File?).
So it is also with less advanced protocol work in graphics
and data management.
There is one experiment which is taking the transformational approach to dealing with incompatibilities.
The Data Reconfiguration Service (DRS) is to be
generally available for mediating between incompatible
stream configurations as directed by user-supplied
transformations. 13
ACKNOWLEDGMENTS
Function-oriented protocols have been the principal
concern of the ARPANET Network Working Group
(NWG). A list of people who have contributed to the
development of the protocols discussed would include,
Robert Braden, Howard Brodie, Abhay Bhushan,

279

Steve Carr, Vint Cerf, Will Crowther, Eric Harslem,
Peggy Karp, Charles Kline, Douglas McKay, Alex
McKenzie, John Melvin, Ed Meyer, Jim Michener,
Tom O'Sullivan, Mike Padlipsky, Arie Shoshani, Bob
Sundberg, Al Vezza, Dave Walden, Jim White, and
Steve Wolfe. We would like to acknowledge the contribution of these researchers and others in the ARPA
N etwork Working Group, without assigning any responsibility for the content of this paper.
REFERENCES
1 L G ROBERTS B D WESSLER
Computer network development to achieve resource sharing
AFIPS Conference Proceedings May 1970
2 F E HEART et al
The ~'nterface message processor for the ARPA
computer network
AFIPS Conference Proceedings May 1970
3 L KLEINROCK
Analytic and simulation methods in computer
network design
AFIPS Conference Proceedings May 1970
4 H FRANK I T FRISCH W CHOU
Topological considerations in the design of the ARPA
Computer network
AFIPS Conference Proceedings May 1970
5 Specifications for the interconnection of a Host and an IMP
Bolt Beranek and Newman Inc Report No 1822
February 1971
6 C S CARR S D CROCKER V G CERF
HOST-HOST communication protocol in the
ARPA Network
AFIPS Conference Proceedings May 1970
7 HOST/HOST protocol for the ARPA Network
ARPA Network Information Center #7147
8 T O'SULLIVAN et al
TELNET protocol
ARPA N etwork Working Group Request For
Comments (RFC) #158 ARPA Network Information
Center (NIC) #6768 May 1971
9 S M ORNSTEIN et al
The Terminal IMP for the ARPA Computer Network
AFIPS Conference Proceedings May 1972
10 J B POSTEL
Official initial connection protocol
ARPA Network Working Group Document #2 NIC
#7101 June 1971
11 A K BHUSHAN et al
The data transfer protocol
RFC #264 NIC #7812 November 1971
12 A K BHUSHAN et al
The file transfer protocol
RFC #265 NIC #7813 November 1971
13 R ANDERSON et al
The data reconfiguration service-An experiment
in adaptable process/process communication
The ACM/IEEE Second Symposium On Problems In
The Optimization Of Data Communications Systems
October 1971

McROSS-A multi-computer programming system*
by ROBERT H. THOMAS and D. AUSTIN HENDERSON
Bolt, Beranek and Newman, Inc.
Cambridge, Massachusetts

INTRODUCTION
This paper describes an experimental "distributed"
programming system which makes it possible to create
multi-computer programs and to run them on computers connected by the ARPA computer network
(ARPANET).1 The programming system, which is
called McROSS (for Multi-Computer Route Oriented
Simulation System), is an extension of a singlecomputer simulation system for modelling air traffic
situations 2 developed by Bolt, Beranek and Newman,
Inc. (BBN) as a tool for air traffic control research.
The McROSS system provides two basic capabilities.
One is the ability to program air traffic simulations
composed of a number of "parts" which run in geographically separated computers, the distributed parts
forming the nodes of a "simulator network." The
second is the ability of such a simulator network to
permit programs running at arbitrary sites in the
ARPANET to "attach" to particular nodes in it for the
purpose of remotely· monitoring or controlling the
node's operation.
The McROSS distributed programming system is
unique in several ways:

(~)

lator network might be run at BBX and on the
next some might be run at BB~, others at
RAND and still others at the University of
Utah. This mode of using the ARPANET is
significantly different from the normal one in
which programs are bound to particular network sites at program composition time. (The
only constraint on the binding of nodes to
ARPANET sites is the requirement that each
node run on a PDP-IO under the TENEX
operating system. 5)
The responsibilities of a node in a simulator network can be conveniently partitioned into subtasks which can be performed more or less
independently of one another. The McROSS
implementation mirrors this partitioning. Functions performed at the nodes are realized by
groups of loosely connected, concurrently evolving processes.

The distributed simulation system represents an
initial step in an on-going research program which is
investigating techniques to make it easy to create, run
and debug computations involving the coordinated behavior of many computers. The McROSS system is
intended to serve both as an experimental vehicle for
studying problems related to distributed computation
and as a tool for air traffic control research. Its two
goals are well matched. A satisfactory solution to the
nation's air traffic problems is likely to include a network of airborne and ground based computers working
together on a single distributed computation: the
scheduling and control of aircraft maneuvers. Thus, the
air traffic control problem is a rich source of interesting
problems in partitioned computation which can be used
to measure the usefulness of the distributed computational techniques developed.
This paper is a report on one phase of a continuing
research program. The intent is to describe interesting
aspects of an experimental distributed programming

(a ) Use of McROSS generates inter-computer traffic
in which a group of programs are engaged in
substantive conversation. There is relatively
little previous experience with such intercomputer, program-to-program conversations.
(b) The component nodes of a simulator network
are not bound to particular ARPANET sites
until simulation "run time." Thus on different
runs the same distributed program can be distributed in different ways over the ARPANET.
For example, in one run all the nodes of a simu-

* This work was supported by the Advanced Projects Research
Agency of the Department of Defense under Contract No.
DAHC-71-C-0088.

281

282

Spring Joint Computer Conference, 1972

system and to share our experience with others considering the construction of such systems. The paper
does no more than hint at how the McROSS system
can be used in air traffic control research.
The next section provides background useful for
subsequent discussion of the distributed programming
system. After than, the McROSS system is described,
first in terms of the facilities it provides for creating
distributed simulations, and then in terms of interesting
aspects of its implementation. The paper closes with a
discussion of some of the issues brought into focus by
the experience of implementing and using a distributed
programming system.
COMPONENTS OF THE McROSS SYSTEM
The main components of the distributed programming system are:
1. The ARPA computer network;
2. The TEN EX operating system for the PDP-IO;

and
3. A simulation programn¥ng system known as
ROSS (for Route Oriented Simulation System).
These components became operational within 6-10
months of one another, at which time it became feasible
to implement the distributed programming system
being described.
The ARPANET

The ARPA computer networkI,3,4 is a set of autonomous computer systems (hosts) which are interconnected to permit resource sharing between any pair of
them. The goal of the ARPANET is for each host to
make its resources accessible from other hosts in the net
thereby permitting persons or programs residing at one
network site to use data and programs that reside and
run at any other. Each host interfaces with the network
through an Interface Message Processor (IMP) ,3 a
small dedicated general-purpose computer. The IMPs,
which reside at the various ARPANET sites, are connected by 50 kilobit common carrier lines and are
programmed to implement a store and forward communication network. In passing from host A to host B
a message passes from host A to IMP A, through the
IMP communication network from IMP A to IMP B
(in general passing through a number of intermediate
IMPS) and finally from IMP B to host B.
At each host there is a Network Control Program
(NCP) whose function is to provide an interface be-

tween the network and processes within the host. The
use the IMP store and forward network to provide processes with a connection switching network.
Thus, they enable processes in different hosts to establish connections with one another and to exchange
information without directly concerning themselves
with details of network implementation such as the
way in which hosts are connected to and communicate
with IMPs.
Information can flow in only one direction on an
ARPANET connection. Thus, before two processes are
able to engage in a dialogue they must establish two
such connections between them. A connection is completely specified by its two ends which are called
sockets. A network socket is itself uniquely specified by
a host identifier and a socket identifier. The purpose of
the socket identifier is to specify a process or group of
processes within a host and a socket relative to that
process or process group. Thus, it is useful to think of a
socket as having a three component "socket name" of
the form H. P . N. H is the "host" component which
identifies an ARPANET host, P is the "process" component which identifies a process group within Hand N
is the "process-local" component which identifies a
socket relative to P. In the sequel

}~·CPs

HI,PI.NI~H2,P2.N2

is used to denote a connection between sockets
HI. Pl. N I and H 2. P 2. N 2 where ~ indicates the direction of information flow over the connection.
For a connection to be established between two
processes each must request that it be established. There
are two common ways in which connections are established. In the first, the processes play symmetric
roles. Each specifies, as part of a "request for connection" (RFC), the socket name at its end of the connection, the socket name at the remote end of the
connection and the direction of information flow. If the
two RFCs "match" the connection is established. This
connection procedure requires a priori agreement upon
the sockets to be used for the connection. The second
common connection procedure is used in situations in
which one process wishes to provide some sort of service
to other processes. The "serving" process establishes
a ltstening socket within its host which is receptive to
RFCs from any other process in the network and then
"listens" for connection attempts. The serving process
uses facilities provided by its NCP to detect the occurrence of a connection attempt and to determine its
source. When such an attempt is made the serving
process can choose to accept or reject it. This connection procedure requires that only one socket name,
that of the serving process's listening socket, be known

McROSS

a priori. In the remainder of this paper
[H.P.N~JL

and
[H.P.N~ JL

are used to denote connections established in a listening
state.
The TENEX operating system

TENEX5 is a time sharing system for the DEC
PDP-I0 processor augmented with paging hardware
developed at BBN. For purposes of this paper it is
useful to describe TENEX in terms of the virtual
processor it implements for each logged-in user (i.e.,
user time sharing job) .
The instruction repetoire of the TENEX virtual
processor includes the PDP-I0 instruction set with the
exception of the direct I/O instructions. In addition, it
includes instructions which provide access to virtual
processor capabilities implemented by the combination
of the TENEX software and hardware.
The TENEX virtual processor permits a user job to
create a tree-structured hierarchy of processes. Such
processes have independent memory spaces and computational power. At different stages in its lifetime a
single user job ma)\ include different numbers of processes in various states of activity. Several mechanisms
for interprocess communication are provided by the
TEN EX virtual machine. Processes can interact by
sharing memory, by interrupts and by direct process
control (e.g., one process stops, modifies and restarts
another which is "inferior" to it in the hierarchy) .
A memory space is provided by the virtual processor
which is independent of the system configuration of
core memory. Each process has a memory space of
256K words which is divided into 512 pages each of
512 words. A process can specify read, write and execute
protection for pages in its memory space as it sees fit.
The virtual machine includes a file system which
provides a mechanism for storing information on .and
retrieving it from external devices attached to TEN