1973 06_#42 06 #42

1973-06_#42 1973-06_%2342

User Manual: 1973-06_#42

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

Download
Open PDF In Browser	View PDF

AFIPS
;:~

i. <

~ .

,<,

CONFERENCE
PROCEEDINGS
VOLUME 42

1973
, ~ < ••

NATIONAL
COMPUTER
CONFERENCE
AND
EXPOSITION

A'FI PS PRESS
210SUM'MIT 'AVENUE' '
MONTVALE. NEW JERSEY 07645 ','

June 4-8, 1973

New York, New York

The ideas and opinions expressed herein are solely those of the authors and are
not necessarily representative of or endorsed by the 1973 National Computer
Conference 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

©1973 by the American Federation of Information Processing Societies, Inc.,
Montvale, ~ew 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

PART I
SCIENCE AND TECHNOLOGY

CONTENTS
PART I-SCIENCE AND TECHNOLOGY PROGRAM
DELEGATE SOCIETY SESSION
The Association for Computational Linguistics
Linguistics and the future of computation ..................... .
An abstract-Speech understanding .......................... .
An abstract-Syntax and computation ........................ .
An abstract- Literary text processing ......................... .

1
8
8
8

D. G. Hays
D. E. Walker
J. J. Robinson
S. Y. Sedelow

Society for Information Display
The augmented knowledge workshop ......................... .
Graphics, problem-solving and virtual systems ................. .

D. C. Engelbart
R.Dunn

Association for Computing Machinery
Performance determination-The selection of tools, if any ....... .
An abstract-Computing societies-Resource or hobby? ........ .

31
38

T. E. Bell
A. Ralston

Special Libraries Association
An abstract-Special libraries association today ................ .
An abstract-Copyright problems in information processing ..... .
An abstract-Standards for library information processing ...... .

39
39
39

E. A. Strahle
B. H. Weil
L. C. Cowgill
D. Weisbrod

Association for Educational Data Systems
An abstract-A network for computer users ....................
An abstract-Use of computers in large school systems ..........
An abstract-Training of teachers in computer usage ...........
An abstract- How schools can use consultants .................

40
40
41
41

B. K. Alcorn
T. McConnell
D. Richardson
D.R. Thomas

J. R. Rice

T. E. Hull

49
50
50
51

J.McLeod
P. W. House
T. Naylor
G. S. Fishman

H. Campaigne

W. F. Simon

G. M. Sokol

53-56

C, L Smith

.
.
.
.

Society for Industrial and Applied Mathematics
NAPSS-like systems-Problems and prospects ................. .
An abstract-The correctness of programs for numerical computation ................................................. .
The Society for Computer Simulation
An abstract-The changing role of simulation and simulation councils ...................................................... .
An abstract-Methodology and measurement
An abstract-Policy models-Concepts and rules-of-thumb ...... .
An abstract-On validation of simulation models ............... .
I'

••••••••••••••••••

IEEE Computer Society
An abstract-In the beginning ............................... .
An abstract-Factors affecting commercial computers system
design in the seventies ..................................... .
An abstract-Factors impacting on the evolution of military computers ................................................... .
Instrument Society of America
Modeling and simulation in the process industries .............. .
Needs for industrial computer standards-As satisfied by ISA's
programs in this area ..................................... .

T. J. Williams
K. A. Whitman

Quantitative evaluation of file management performance improvements ................................................... .

T. F. McFadden
J. C. Strauss

A method of evaluating mass storage effects on system performance .................................................... .

M. A. Diethelm

PERFORMANCE EVALUATION

The memory bus monitor-A new device for developing real-time
systems
Design and evaluation system for computer architecture

75
81

An analysis of multi programmed time-sharing computer systems

00000000000000000000000000000000000000000000000000

000

Use of the SPASM software monitor to evaluate the performance of
the Burroughs B6700

Evaluation of performance of parallel processors in a real-time environment

101

A structural approach to computer performance analysis

109

00000000000000000000000000000000000000000000000000

Ro E. Fryer
Ko Hakozaki
M. Yamamoto
T.Ono
N.Ohno
Mo Umemura
M.A. Sencer
C. L. Sheng
J. Mo Schwartz
D.S. Wyner
Go Ro Lloyd
RoE. Merwin
P. H. Hughes
GoMoe

NETWORK COMPUTERS-ECONOMIC CONSIDERATIONSPROBLEMS AND SOLUTIONS
Simulation-A tool for performance evaluation in network computers
0

00000000000000000000000000000000

ACCNET-A corporate computer network
A system of APL functions to study computer networks
A high level language for use with computer networks
On the design of a resource sharing executive for the ARPANET
Avoiding simulation in simulating computer communications networks
0

121

133
141
149
155

E. K. Bowdon, Sr.
SoA.Mamrak
F. R. Salz
MoL. Coleman
To D. Friedman
H. Z. Krilloff
R. Ho Thomas

165

R. M. Van Slyke
W.Chow
Ho Frank

An implementation of a data base management system on an
associative processor
Aircraft conflict detection in an associative processor
A data management system utilizing an associative memory.

171
177
181

Associative processing applications to real-time data management

187

R.Moulder
H. R. Downs
Co R. DeFiore
P. B. Berra
Ro R. Linde
L. O. Gates
T.FoPeng

0000000000000

ASSOCIATIVE PROCESSORS

••••

•

••

•

••

•

•••

•

AUTOMATED PROJECT MANAGEMENT SYSTEMS
A computer graphics assisted system for management ...

••••

••

•

197

R. Chauhan

203

211

WoGorman
M. H. Halstead

215

Jo E. Brown

TUTORIAL ON RESOURCE UTILIZATION IN THE
COMPUTING PROCESS
On the use of generalized executive system software
Language selection for applications
0

•••

••

•••

•••••••••••••

••

••••

INFORMATION NETWORKS-INTERNATIONAL COMMUNICATION SYSTEMS
An abstract-A national science and technology information
system in Canada ...
An abstract-Global networks for information, communications
and computers ....
0

•••

••

•

••

•

•••••••

•

INTELLIGENT TERMINALS
A position paper-Panel Session on Intelligent terminalsChairman's Introduction .................................. .
A position paper-Electronic point-of-sale terminals ............ .
Design considerations for knowledge workshop terminals ........ .
Microprogrammed intelligent satellites for interactive graphics .. .

217
219
221
229

I. W. Cotton
Z. Thornton
D. C. Engelhart
A. van Dam
G. Stabler

Fourth generation data management systems .................. .
Representation of sets on mass storage devices for information
retrieval systems ......................................... .

239

V.K.M. Whitney

245

Design of tree networks for distributed data .................... .
Specifications for the development of a generalized data base
planning system . . . . . . . . . . . . . . . . . . . . . . . . . . .

251

S. T. Byrom
W. T. Hardgrave
R. G. Casey

TRENDS IN DATA BASE MANAGEMENT

259

J. F. Nunamaker, Jr.
D. E. Swenson
A~B:-~wnifistoh

Database sharing-An efficient mechanism for supporting concurrent processes ............................................ .

271

Optimal file allocation in multi-level storage systems ............ .
Interaction statistics from a database management system ...... .

277
283

P. F. King
A. J. Collmeyer
P. P. S. Chen
J. D. Krinos

290

W. E. Hanna, Jr.

The evolution of virtual machine architecture .................. .

291

An efficient virtual machine implementation .................. .

301

Architecture of virtual machines ............................. .

309

J. P. Buzen
U. O. Gagliardi
R. J. Srodawa
L. A. Bates
R. P. Goldberg

CONVERSION PROBLEMS
An abstract-Utilization oflarge-scale systems ................. .
VIRTUAL MACHINES

COMPUTER-BASED INTEGRATED DESIGN SYSTEMS
The computer aided design environment project COMRADE-An
overview ................................................ .
Use of COMRADE in engineering design ...................... .
The COMRADE executive system ............................ .

319
325
331

The COMRADE data management system .................... .

339

PLEX data structure for integrated ship design ................ .
COMRADE data management system storage and retrieval techniques .................................................. .

347
353

The COMRADE design administrative system ................. .

359

A. Bandurski
M. Wallace
M. Chernick

365

D. A. Davidson

367

H. J. Highland

371

J. Maniotes

T.Rhodes
J. Brainin
R. Tinker
L. Avrunin
S. Willner
A. Bandurski
W.Gorman
M. Wallace
B. Thomson

ACADEMIC COMPUTING AT THE JUNIOR/COMMUNITY
COLLEGE-PROGRAMS AND PROBLEMS
A business data processing curriculum for community colleges ....
Computing at the Junior/Community College-Programs and
problems ............ " ............ , ...... " ........ " ... .
The two year and four year computer technology programs at
Purdue University ........................................ .

Computing studies at Farmingdale ........................... .
Computer education at Orange Coast College-Problems and programs in the fourth phase .................................. .
An abstract-Computing at Central Texas College .............. .

379

C. B. Thompson

381
385

R. G. Bise
A. W. Ashworth, Jr.

387
395

A. L. Scherr
T. F. Wheeler, Jr.

401
407

W. A. Schwomeyer
E. Yodokawa

413

H.Chang
T. C. Chen
C. Tung
W.C. Hohn
P. D. Jones

STORAGE SYSTEMS
The design of IBM OS/VS2 release 2 .......................... .
IBM OS/VS1-An evolutionary growth system ............... ,.
Verification of a virtual storage architecture on a microprogrammed computer ........................................... .
On a mathematical model of magnetic bubble logic ............. .
The realization of symmetric switching functions using magnetic
bubble technology ........................................ .

The Control Data STAR-100 paging station .................... .

421

NATURAL LANGUAGE PROCESSING
The linguistic string parser .................................. .

427

A multiprocessing approach to natural language ................ .
Progress in natural language understanding-An application to
1unar geology ............................................ .
An abstract-Experiments in sophisticated content analysis ..... .
An abstract-Modelling English conversations ................. .

435

R. Grishman
N. Sager
C. Raze
B. Bookchin
R.Kaplan

441
451
451

W.A. Woods
G. R. Martin
R. F. Simmons

An abstract-The efficiency of algorithms and machines-A survey
of the complexity theoretic approach ........................ .
An abstract- Hypergeometric group testing algorithms ......... .

452
452

abstract-The file transmission problems .................. .
abstract--Analysis of sorting algorithms ................... .
abstract-Min-max relations and combinatorial algorithms ... .
abstract-The search for fast algorithms ................... .

453
453
453
453

J. Savage
S. Lin
F.K. Hwang
P. Weiner
C. L. Liu
W. R. Pulleyblank
I. Munro

DISCRETE ALGORITHMS-APPLICATIONS AND
MEASUREMENT

An
An
An
An

APPLICATIONS OF AUTOMATIC PATTERN RECOGNITION
Introduction to the theory of medical consulting and diagnosis ....

Pattern recognition with interactive computing for a half dozen
clinical applications of health care delivery .................. .
Interactive pattern recognition-A designer's tool .............. .
Auto-scan-Technique for scanning masses of data to determine
potential areas for detailed analysis ......................... .

455

463
479

E. A. Patrick
L. Y. L. Shen
F. P. Stelmack
R. S. Ledley

E. J. Simmons, Jr.

485

D. L. Shipman
C. R. Fulmer

489

R. S. Ledley
H.K. Huang
T. J. Golab
Y. Kulkarni
G. Pence
L. S. Rotolo

INGREDIENTS OF PATTERN RECOGNITION
SPIDAC-Specimen input to digital automatic computer ....... .

497
503
509

R. B. Banerji
M.F. Dacey
L.Uhr

518

R. Brody

518
518

J. Davis
G. Huckell

Computer architecture and instruction set design ............... .

519

P. Anagnostopoulos
M.J. Michel
G. H. Sockut
G. M. Stabler
A. van Dam

A new m-i-R-icompYte-r-Jmulti-pro-G€-SSQ-I"f-w.-theARPA network ..... .

529

A method for the easy storage of discriminant polynomials ....... .
A non-associative arithmetic for shapes of channel networks ..... .
The description of scenes over time and space .................. .
ADVANCED HARDWARE
An abstract-Tuning the hardware via a high level language
(ALGOL) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
An abstract-1O- 5 -10- 7 cent/bit storage media, what does it
mean? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
An abstract-Computer on a chip and a network of chips ........ .
THE GROWING POTENTIAL OF MINI; SMALL SYSTEMS

Data integrity in small real-time computer systems ............. .
The design and implementation of a small scale stack processor
system .................................................. .
Operating system design considerations for microprogrammed
mini-computer satellite systems ............................ .

539

F ..E.-HeartS. M. Ornstein
W. R. Crowther
W. B. Barker
T. Harrison
T. J. Pierce

545

M. J. Lutz

555

J. E. Stockenberg
P. Anagnostopoulos
R. E. Johnson
R.G.Munck
G. M. Stabler
A. van Dam

563
563

M. A. Melkanoff
B. H. Barnes
G. L. Engel.
M. A. Melkanoff

565
569
581
589
603

F. A. Stahl
G. E. Mellen
1. S. Reed
R. Turn
C. H. Meyer

More effective computer packages for applications ............. .

607

EASYSTAT -An easy-to-use statistics package ................ .
ACID-A user-oriented system of statistical programs .......... .

615
621

W. B. Nelson
M. Phillips
L. Thumhart
A. B. Tucker
R.A. Baker
T. A. Jones

A GRADUATE PROGRAM IN COMPUTER SCIENCE
An abstract-Another attempt to define computer science ....... .
An abstract-The master's degree program in computer science .. .

CRYPTOLOGY IN THE AGE OF AUTOMATION
A homophonic cipher for computational cryptography .......... .
Cryptology, computers and common sense ..................... .
Information theory and privacy in data banks ................. .
Privacy transformations for data banks ....................... .
Design considerations for cryptography ....................... .
DESIGN AND DEVELOPMENT OF APPLICATION PACKAGES
FOR USERS

A DAY WITH GRAPHICS

Graphics Applications I
Graphics and Engineering-Computer generated color-sound
movies .................................................. .

625

L. Baker

629

R. Notestine

635
639

C. M. Williams
C. Newton

643

R. Resch

651

W.W.Newman

657

R. C. Gammill

663
677
685

N. Negroponte
J. Franklin
I. Sutherland

Packet switching with satellites .............................. .
Packet switching in a slotted satellite channel .................. .

695
703

N.Abramson
L. Kleinrock
S.S.Lam

Dynamic allocation of satellite capacity through packet reservation ..... , ............................................... .

711

L. G. Roberts

Chairman's introduction-Opposing views .................... .
The future of computer and communications services ........... .
Social impacts of the multinational computer .................. .

717
723
735

A new NSF thrust-Computer impact on society ............... .

747

M. Turoff
L. H. Day
B. Nanus
L. M. Wooten
H. Borko
P. G. Lykos

Graphics computer-aided design in aerospace .................. .
Graphics and digitizing-Automatic transduction of drawings into
data bases ............................................... .
Graphics in medicine and biology ............................ .
Graphic Applications II
Graphics and art-The topological design of sculptural and architectural systems .......................................... .
Graphics and education-An informal graphics system based on
the LOGO language ....................................... .
Graphics and interactive systems-Design considerations of a
. software system .......................................... .
Graphics and architecture-Recent developments in sketch
recognition .............................................. .
Graphics and electronic circuit analysis ....................... .
Graphics in 3D-Sorting and the hidden surface problem ....... .
SATELLITE PACKET COMMUNICATIONS

VIEWS OF THE FUTURE-I

VIEW OF THE FUTURE-II
The impact of technology on the future state of information
technology enterprise ..................................... .
The home reckoner- --A scenario on the home use of computer::; ... .

751
759

What's in the cards for data entry? ........................... .

765

L. A. Friedman
C. A. R. Kagan
L. G. Schear
G. Bernstein

773

J. R. Norsworthy

781

K. D. Leeper

What is different about tactical military operational programs ....
What is different about the hardware in tactical military systems ..

787
797

What is different about tactical military languages and compilers.
What is different about tactical executive systems .............. .

807
811

G. G. Chapin
E. C. Svendsen
D.L.Ream
R.J. Rubey
W. C. Phillips

ENVIRONMENTAL QUALITY AND THE COMPUTER
Assessing the regional impact of pollution control-A simulation approach ....................... , ...... , ................... .
An automated system for the appraisal of hydrocarbon producing
properties ............................................... .
WHAT'S DIFFERENT ABOUT TACTICAL MILITARY COMPUTER SYSTEMS

Linguistics and the future of computation
by DAVID G. HAYS
State University of New York
Buffalo, ~ew York

My subject is the art of computation: computer architecture, computer programming, and computer application. Linguistics provides the ideas, but the use I make of
-them-is-not--the-l-ing:uist!-s--uS€; whic-h -w-G--Uld--oo-an- -attempt
at understanding the nature of man and of human
communication, but the computer scientist's use. In
ancient India, the study of language held the place in
science that mathematics has always held in the West.
Knowledge was organized according to the best known
linguistic principles. If we had taken that path, we would
have arrived today at a different science. Our scholarship
draws its principles from sources close to linguistics, to be
sure, but our science has rather limited itself to a basis in
Newtonian calculus. And so a chasm separates two cultures.

THREE Llr\GUISTIC PRIXCIPLES
Since I cannot treat the entire field of linguistics. I
ha-ve-4esen--te---s-ketch three pIincif}les that---se-em--mest
basic and far-reaching. Two of them are known to every
linguist and applied automatically to every problem that
arises. The third is slightly less familiar; I have begun a
campaign to give it due recognition.
As everyone knows, the capacity for language is innate
in every human specimen, but the details of a language
are acquired by traditional transmission, from senior to
younger. As everyone knows, language is a symbolic system, using arbitrary signs to refer to external things,
properties, and events. And, as everyone certainly knows
by now, language is productive or creative, capable of
describing new events by composition of sentences never
before uttered. Hockett 9 and Chomsky 3 explain these
things. But of course these are not principles; they are
problems for which explanatory principles are needed.
My first principle is stratification.12 This principle is
often called duality of patterning, although in recent
years the number of levels of patterning has grown. The
original observation is that language can be regarded as a
system of sounds or a system of meaningful units; both
points of view are essential. One complements the other
without supplanting it. Phonology studies language as
sound. It discovers that each of the world's languages uses
a small alphabet of sounds, from a dozen to four times
that many, to construct all its utterances. The definition
of these unit sounds is not physical but functional. In one
language, two sounds with physically distinct manifestations are counted as functionally the same; speakers of
this language do not acquire the ability to distinguish
between the sounds, and can live out their lives without
knowing that the sounds are unlike. English has no use
for the difference between [p] and [p'], the latter having a
little puff of air at the end, yet both occur: [p] in spin, [p'
] in pin. Since other languages, notably Thai, use this
difference to distinguish utterances, it is humanly possible not only to make the two forms of / p / but also to hear
it. Thus languages arbitrarily map out their alphabets of
sounds. lC
Languages also differ in the sequences of sounds that
they permit. In Russian, the word vzbalmoshnyj 'extrava-

The scientific reliance on calculus has been productive.
Often understood as a demand for precision and rigor, it
has simultaneously made theoreticians answerable to
experimental observation and facilitated the internal
organization of knowledge on a scale not imagined elsewhere in human history. Very likely, a reliance on linguistic laws for control of science during the same long
period would have been less successful, because the principles of linguistic structure are more difficult to discover
and manipulate than the principles of mathematical
structure; or so it seems after two thousand years of
attention to one and neglect of the other. How it will seem
to our descendants a thousand years hence is uncertain;
they may deem the long era of Western study of mathematical science somewhat pathological, and wonder why
the easy, natural organization of knowledge on linguistic
lines was rejected for so many centuries.
However that may be, the prospect for the near term is
that important opportunities will be missed if linguistic
principles continue to be neglected. Linguistics is enjoying
a period of rapid growth, so a plethora of ideas await new
uses; the computer makes it possible to manipulate even
difficult principles. Traditional mathematics seems not to
say how computers much beyond the actual state of the
art can be organized, nor how programs can be made
much more suitable to their applications and human
users, nor how many desirable fields of application can be
conquered. I think that linguistics has something to say.
1

National Computer Conference, 1973

gant' is reasonable, but the English speaker feels that the
initial sequence /vzb/ is extravagant, because initial Iv/
in English is not followed by another consonant, and furthermore initial I zl is not. The Russian word violates
English rules, which is perfectly satisfactory to Russian
speakers, because they are unacquainted with English
restrictions. As Robert Southey put it, speaking of a Russian,

And last of all an Admiral came,
A terrible man with a terrible name,
A name which you all know by sight very well
But which no one can speak, and no one can spell.

(Robert Southey, 'The March to Moscow.') Phonology,
with its units and rules of combinations, is one level of
patterning in language.
That languages are patterned on a second level is so
well known as to require little discussion. English puts
its subject first, verb second, object last-in simple
sentences. Malagasy, a language of Madagascar, puts
the verb first, then the object, last the subject.ll Other
orders are found elsewhere. English has no agreement
in gender between nouns and adjectives, but other languages such as French and Russian, Navaho and Swahili,
do; nor is gender controlled by semantics, since many
gender classes are without known semantic correlation.
Gender is as arbitrary as the English rejection of initial
/vzb/ .
The units that enter into grammatical patterns are
morphemes; each language has its own stock, a vocabulary that can be listed and found once more to be arbitrary. It seems true that some color names are universal
-needed in all languages to symbolize genetic capacities
-but other color name~ are al~o coined, ~uch a~ the English scarlet and crimson, on arbitrary lines. \,8
The existence of a third level of symbolic patterning is
best shown by psychological experiments. Memory for a
story is good, but not verbatim. Only the shortest
stretches of speech can be remembered word for word;
but the ideas in quite a long stretch can be recited after
only one hearing if the hearer is allowed to use his own
words and grammatical structures. 5 The comparison of
pictures with sentences has been investigated by several
investigators; they use models in which below is coded as
not above, forget is coded as not remember, and so on,
because they need such models to account for their subjects' latencies (times to respond measured in milliseconds). Using such models, they can account for the differences between times of response to a single picture,
described with different sentences, to an impressive
degree of precision. 12
Each level of symbolic patterning should have both
units and rules of construction. On the phonological level
the units are functional sounds; the rules are rules of
sequence, for the most part. On the grammatical level the

units are morphemes and the rules are the familiar rules
of sequence, agreement, and so on. On the third level,
which can be called semological or cognitive, the units are
often called sememes; the morpheme 'forget' corresponds
to the sememes 'not' and 'remember'. The rules of organization of this level have not been investigated adequately.
Many studies of paradigmatic organization have been
reported, sometimes presenting hierarchical classifications of items (a canary is a bird, a dog is a quadruped,
etc.), but this is only one of several kinds of organization
that must exist. Classification patterns are not sentences,
and there must be sentences of some kind on the semological level. Chomsky's deep structures might be suitable,
but Fillmore 6 and McCawley 13 have proposed different
views. What is needed is rapidly becoming clearer,
through both linguistic and psychological investigations.
The relations that help explain grammar, such as subject
and object, which control sequence and inflection, are not
the relations that would help most in explaining the interpretation of pictures or memory for stories; for such
purposes, notions of agent, instrument, and inert material
are more suitable. But the organization of these and other
relations into a workable grammar of cognition is unfinished.
Up to this point I have been arguing only that language
is stratified, requiring not one but several correlated
descriptions. Now I turn to my second principle, that
language is internalized. Internalization is a mode of storage in the brain, intermediate between innateness and
learning. Concerning the neurology of these distinctions I
have nothing to say. Their functional significance is easy
enough to identify, however.
What is innate is universal in mankind, little subject to
cultural variation. Everyone sees colors in about the same
way. unless pathologically color blind. Everyone on earth
has three or more levels of linguistic patterning. The distinctions among things (nouns), properties (adjectives),
and events (verbs) are so nearly universal as to suggest
that this threefold organization of experience is innate. To
have grammar is universal, however much the grammars
of particular languages vary. The innate aspects of
thought are swift, sure, and strong.
What is internalized is not the same in every culture or
every person. But whatever a person internalizes is reasonably swift, sure, and strong; less than what is innate,
more than what is learned. Besides the mechanisms of
linguistic processing, various persons internalize the skills
of their arts and crafts; some internalize the strategies of
games; and all internalize the content of at least some
social roles.
The contrast between learning and internalization is
apparent in knowledge of a foreign language. A person
who has learned something of a foreign language without
internalization can formulate sentences and manage to
express himself, and can understand what is said to him,
although slowly and with difficulty. A person who has
internalized a second language is able to speak and
understand with ease and fluency.

Linguistics and the Future of Computation

Similarly in games, the difference between a master of
chess, bridge, or go is apparent. But something more of
the difference between learning and internalization is also
to be seen here. The novice has a more detailed awareness
of how he is playing; he examines the board or the cards
step by step, applying the methods he has learned, and
can report how he arrives at his decision. Awareness goes
with learned skills, not with internalized abilities.
Internalized abilities are the basis of more highly organized behavior. The high-school learner of French is not
able to think in French, nor is the novice in chess able to
construct a workable strategy for a long sequence of
moves. When a language has been internalized, it
becomes a tool of thought; when a chess player has internalized enough configurations of pieces and small
sequences of play, he can put them together into strate~._The_musician_ intexnali~_e~__ chQrd_~, meI9dje~_,--.I:!!ld
ultimately passages and whole scores; he can then give his
attention to overall strategies, making his performance
lyrical, romantic, martial, or whatever.
What makes learning possible is the internalization of a
system for the storage and manipulation of symbolic
matter. If a person learns a story well enough to tell it, he
uses the facilities of symbolic organization-his linguistic
skills-to hold the substance of the story. Much of the
content of social roles is first learned in this way; the
conditions of behavior and the forms of behavior are
learned symbolically, then come to be, as social psychologists put it, part of the self-that is, internalized. In fact,
the conversion of symbolic learned material into internalized capacities is a widespread and unique fact of human
life. It must be unique, since the symbol processing
capacity required is limited to man. This ability gives
man a great capacity for change, for adaptation to different cultures, for science: by internalizing the methods of
science, he becomes a scientist.
The amount that a person internalizes in a lifetime is
easy to underestimate. A language has thousands of
morphemes and its users know them. Certainly their
semantic and grammatical organization requires tensmore plausibly hundreds-of thousands of linkages. A
high skill such as chess takes internalize knowledge of the
same order of magnitude, according to Simon and Barenfeld. 15
I think that internalized units are more accurately
conceived as activities than as inert objects. All tissue is
metabolically active, including the tissue that supports
memory. Memory search implies an activity, searching,
in an inactive medium, perhaps a network of nodes and
arcs. More fruitfully we can imagine memory as a network of active nodes with arcs that convey their activity
from one to another. A morpheme, then, is an activity
seeking at all times the conditions of its application.
My third principle in linguistics is the principle of
metalinguistic organization. Language is generally recognized as able to refer to itself; one can mention a word in
order to define it, or quote a sentence in order to refute it.
A very common occurrence in grammar is the embedding

of one sentence within another. A sentence can modifv a
word in another sentence, as a relative clause:
.
The boy who stole the pig ran away.
A sentence can serve as the object of a verb of perception,
thought, or communication:
I saw him leave. I know that he left.
You told me that she had left.
And two sentences can be embedded in temporal, spatial,
or causal relation:
He ran away because he stole the pig.
He stole the pig and then ran away.
He is hidin~_ far from the spot where he stole the pig.
An embedded sentence is sometimes taken in the same
form as if it were independent, perhaps introduced by a
word like the English that, and sometimes greatly altered
in form as in his running away.
The definition of abstract terms can be understood by
metalinguallinkages in cognitive networks. The definition
is a structure, similar to the representation of any sentence or story in a cognitive network. The structure is
linked to the term it defines, and the use of the term
governed by the content of the structure. Science and
technology are replete with terms that cannot be defined
with any ease in observation sentences; they are defined,
I think, through metalingual linkages. What kind of program is a compiler? What kind of device can correctly be
called heuristic? These questions can be answered, but
useful answers are complicated stories about the art of
proglamming, not simple statements of perceptual conditions, and certainly not classificatory statements using
elementary features such as human, male, or concrete.
I can indicate how vast a difference there is between
metalingual operations and others by proposing that all
other operations in cognitive networks are performed by
path tracing using finite-state automata, whereas metalingual operations are performed by pattern matching using
pushdown automata. These two systems differ in power; a
finite-state machine defines a regular language and a
pushdown automaton defines a context-free language.
A path in a cognitive network is defined as a sequence
of nodes and arcs; to specify a path requires only a list of
node and arc types, perhaps with mention that some are
optional, some can be repeated. A more complex form of
path definition could be described, but I doubt that it
would enhance the effectiveness of path tracing procedures. In Quillian's work, for example, one needs only
simple path specifications to find the relation between
lawyer and client (a client employs a lawyer). To know
that a canary has wings requires a simple form of path
involving paradigmatic (a canary is a kind of bird) and
syntagmatic relations (a bird has wings). The limiting
factor is not the complexity of the path that can be

National Computer Conference, 1973

defined from one node to another, but the very notion
that node-to-node paths are required. 4 • 14
Pattern matching means fitting a template. The patterns I have in mind are abstract, as three examples will
show. The first, familiar to linguists, is the determination
of the applicability of a grammatical transformation. The
method, due to Chomsky, is to write a template called a
structure description. The grammatical structure of any
sentence is described by some tree; if the template fits the
tree of a certain sentence, then the transformation applies
to it, yielding a different tree. These templates contain
symbols that can apply to nodes in grammatical trees,
and relations that can connect the nodes. Chomsky was, I
think, the first to recognize that some rules of grammar
can be applied only where structure is known; many
phenomena in language are now seen to be of this kind.
Thus linguists today ask for tree-processing languages
and cannot do with string processors.
My second example is the testing of a proof for the
applicability of a rule of inference. A proof has a tree
structure like the structure of a sentence; whether a rule
of inference can be applied has to be tested by reference
to the structure. 'If p and q then p' is a valid inference,
provided that in its application p is one of the arguments
of the conjunction; one cannot assert that p is true just
because p, q, and a conjunction symbol all occur in the
same string.
Finally, I come to metalingual definition. The definition is itself a template. The term it defines is correctly
used in contexts where the template fits. As in the first
two examples, the template is abstract. A structure
description defines a class of trees; the transformation it
goes with applies to any tree in the class. A rule of inference defines a class of proofs; it applies to each of them.
And a metalingual definition defines a class of contexts,
in each of which the corresponding term is usable. Charity has many guises; the story-template that defines charity must specify all of the relevant features of charitable
activity, leaving the rest to vary freely.
When the difference in power between finite-state and
context-free systems was discovered, it seemed that this
difference was a fundamental reason for preferring context-free grammars in the study of natural language.
Later it became evident that the need to associate a structural description with each string was more important,
since context-free grammars could do so in a natural way
and finite-state automata could not. Today linguists and
programmers generally prefer the form of context-free
rules even for languages known to be finite state, just
because their need for structure is so urgent. It may prove
the same with pattern matching. In proofs, in transformations, and in definitions it is necessary to mark certain
elements: the conclusions of inferences, the elements
moved or deleted by transformation, and the key participating elements in definition. (The benefactor is charitable, not the recipient.) Until I see evidence to the contrary, however, I will hold the view that pattern matching is
more powerful than path tracing.

Pattern matching is, surely, a reflective activity in
comparison with path tracing. To trace a path through a
maze, one can move between the hedges, possibly marking the paths already tried with Ariadne's thread. To see
the pattern requires rising above the hedges, looking down
on the whole from a point of view not customarily
adopted by the designers of cognitive networks. That is,
they often take such a point of view themselves, but they
do not include in their systems a component capable of
taking such a view.
COMPUTER ARCHITEC'TURE
I turn now to the art of computation, and ask what
kind of computer might be constructed which followed
the principles of stratification, internalization, and
metalingual operation.
Such a computer will, I freely admit, appear to be a
special-purpose device in comparison with the generalpurpose machines we know today. The human brain, on
close inspection, also begin::) to look like a :special-purpose
machine. Its creativity is of a limited kind, yet interesting
nevertheless. The prejudice in favor of mathematics and
against linguistics prefers the present structure of the
computer; but a special-purpose machine built to linguistic principles might prove useful for many problems that
have heretofore been recalcitrant.
Stratification is not unknown in computation, but it
deserves further attention. The difficulties of code translation and data-structure conversion that apparently still
exist in networks of different kinds of computers and in
large software systems that should be written in a combination of programming languages are hard to take. The
level of morphemics in language is relatively independent
of both cognition and phonology. In computer architecture, it should be possible to work with notational
schemes independent of both the problem and the inputoutput system. Whether this level of encoding both data
and their organization should be the medium of transmission, or specific to the processor, I do not know. But it is
clear that translators should be standard hardware items,
their existence unknown in high-level languages. Sophistication in design may be needed, but the problems seem
not insurmountable, at least for numerical, alphabetic,
and pictorial data. The design of translators for data
structures is trickier, and may even prove not to be possible on the highest level.
The lesson to be learned from the separation of grammar and cognition is more profound. Language provides a
medium of exchange among persons with different interests and different backgrounds; how they will understand
the same sentence depends on their purposes as well as
their knowledge. Much difficulty in computer programming apparently can be traced to the impossibility of
separating these two levels in programming languages.
Programs do not mean different things in different contexts; they mean the same thing always. They are there-

Linguistics and the Future of Computation

fore called unambiguous, but a jaundiced eye might see a
loss of flexibility along with the elimination of doubt.
Many simple problems of this class have been solved; in
high-level languages, addition is generally not conditioned
by data types, even if the compiler has to bring the data
into a common type before adding. More difficult problems remain. At Buffalo, Teiji Furugori is working on a
system to expand driving instructions in the context of
the road and traffic. He uses principles of safe driving to
find tests and precautions that may be needed, arriving at
a program for carrying out the instruction safely. Current
computer architecture is resistant to this kind of work; it
is not easy to think of a program on two levels, one of
them providing a facility for expanding the other during
execution. An interpreter can do something of the sort;
but interpretive execution is a high price to pay. If computer hardware provided for two simultaneous monitors
of the data stieain, orieexecufiil-g -a -complIed program
while the other watched for situations in which the compiled version would be inadequate, the separation of
morphemics and cognition might better be realized.
In teaching internalization to students who are mainly
interested in linguistics, I use microprogramming as an
analogy. What can be seen in the opposite direction is the
fantastic extent to which microprogramming might be
carried with corresponding improvement in performance.
If the meaning of every word in a language (or a large
fraction of the words) is internalized by its users, then one
may hope that microprogramming of a similar repertory
of commands would carry possibilities for the computer
somewhat resembling what the speaker gains, to wit,
speed.
A computer could easily be built with a repertory of
10,000 commands. Its manual would be the size of a desk
dictionary; the programmer would often find that his
program consisted of one word, naming an operation, followed by the necessary description of a data structure.
Execution would be faster because of the intrinsically
higher speed of the circuitry used in microprogramming.
Even if some microprograms were mainly executive,
making numerous calls to other microprograms, overall
speed should be increased. At one time it would have
been argued that the art could not supply 10,000 widely
used commands, but I think that time is past. If someone
were inclined, I think he could study the literature in the
field and arrive at a list of thousands of frequently used
operations.
Parallel processing adds further hope. If a computer
contains thousands of subcomputers, many of them
should be operating at each moment. Even the little we
know about the organization of linguistic and cognitive
processing in the brain suggests how parallel processing
might be used with profit in systems for new applications.
A morphemic unit is the brain seems to be an activity,
which when successful links a phonological string with
one or more points in a cognitive network. If these units
had to be tested sequentially, or even by binary search,
the time to process a sentence would be great. Instead all

of them seem to be available at all times, watching the
input and switching from latency to arousal when the
appropriate phonological string appears. If each were a
microprogram, each could have access to all input. Conflicts inevitably arise, with several units aroused at the
same time. Grammar serves to limit these conflicts; a
grammatical unit is one with a combination of inputs
from morphemic units. When a morphemic unit is
aroused, it signals its activation to one or several grammatical units. When a proper combination of morphemic
units is aroused, the grammatical unit is in turn aroused
and returns feedback to maintain the arousal of the
morphemic unit which is thereupon enabled to transmit
also to the cognitive level. Thus the condition for linkage
between phonology and cognition is a combination of
grammatical elements that amounts to the representation
of a sentence structure. This is Lamb's model of stratal
orgariizafioii, and shows -how grammar reauces-TeiicaT
ambiguity. The problem it poses for computer architecture is that of interconnection; unless the morphemic
units (like words) and the grammatical units (like phrasestructure rules) are interconnected according to the
grammar of a language, nothing works. The computer
designer would prefer to make his interconnections on the
basis of more general principles; but English is used so
widely that a special-purpose computer built on the lines
of its grammar would be acceptable to a majority of the
educated persons in the world-at least, if no other were
on the market.
A similar architecture could be used for other purposes,
following the linguistic principle but not the grammar of a
natural language. Ware l6 mentions picture processing and
other multidimensional systems as most urgently needing
increased computing speed. Models of physiology, of
social and political systems, and of the atmosphere and
hydrosphere are among these. Now, it is in the nature of
the world as science knows it that local and remote interactions in these systems are on different time scales. A
quantum of water near the surface of a sea is influenced
by the temperature and motion of other quanta of water
and air in its vicinity; ultimately, but in a series of steps,
it can be influenced by changes at remote places. Each
individual in a society is influenced by the persons and
institutions close to him in the social structure. Each
element of a picture represents a portion of a physical
object, and must be of a kind to suit its neighbors.
To be sure, certain factors change simultaneously on a
wide scale. I f a person in a picture is wearing a striped or
polka-dotted garment, the recognition of the pattern can
be applied to the improvement of the elements throughout the area of the garment in the picture. A new law or
change in the economy can influence every person simultaneously. Endocrine hormones sweep through tissue
rapidly, influencing every point almost simultaneously.
When a cloud evaporates, a vast area is suddenly exposed
to a higher level of radiation from the sun.
These situations are of the kind to make stratification a
helpful mode of architecture. Each point in the grid of

National Computer Conference, 1973

picture, physiological organism, society, or planet is connected with its neighbors on its own stratum and with
units of wide influence on other strata; it need not be
connected with remote points in the same stratum.
Depending on the system, different patterns of interaction have to be admitted. Clouds are formed, transported,
and evaporated. Endocrine glands, although they vary in
their activity, are permanent, as are governments. Both
glands and governments do suffer revolutionary changes
within the time spans of useful simulations. In a motion
picture, objects enter and depart.
How the elements of the first stratum are to be connected with those of the next is a difficult problem. It is
known that the cat's brain recognizes lines by parallel
processing; each possible line is represented by a cell or
cells with fixed connections to certain retinal cells. But
this does not say how the cat recognizes an object composed of several lines that can be seen from varying orientations. Switching seems unavoidable in any presently
conceivable system to connect the level of picture elements with the level of objects, to connect the level of
persons with the level of institutions, to connect the elements of oceans with the level of clouds, or to connect the
elements of the morphemic stratum with the level of cognition in linguistic processing.
In computation, it seems that path tracing should be
implicit, pattern matching explicit. The transmission of
activity from a unit to its neighbors, leading to feedback
that maintains or terminates the activity of the original
unit, can be understood as the formation of paths. Something else, I think, happens when patterns are matched.
A typical application of a linguistically powerful computer would be the discovery of patterns in the user's
situation. The user might be a person in need of psychiatric or medical help; an experimenter needing theoretical
help to analyze his results and formulate further experiments; a lawyer seeking precedents to aid his clients; or a
policy officer trying to understand the activities of an
adversary. In such cases the user submits a description of
his situation and the computer applies a battery of patterns to it. The battery would surely have to be composed
of thousands of possibilities to be of use; with a smaller
battery, the user or a professional would be more helpful
than the computer.
If the input is in natural language, I assume that it is
converted into a morphemic notation, in which grammatical relations are made explicit, as a first step.
On the next level are thousands of patterns, each linked
metalingually to a term; the computer has symbolic patterns definitive of charity, ego strength, heuristics, hostility, and so on. Each such pattern has manifold representations on the morphemic stratum; these representations may differ in their morphemes and in the grammadical linkages among them. Some of these patterns, in
fact, cannot be connected to the morphemic stratum direetly with any profit whatsoever, but must instead be
linked to other metalingual patterns and thence ultimately to morphemic representations. In this way the

cognitive patterns resemble objects in perception that
must be recognized in different perspectives.
Grammatical theory suggests an architecture for the
connection of the strata that may be applicable to other
multistratal systems. The two strata are related through a
bus; the object on the lower stratum is a tree which reads
onto the bus in one of the natural linearizations. All of the
elements of all of the patterns on the upper stratum are
connected simultaneously to the bus and go from latent to
aroused when an element of their class appears; these
elements include both node and arc labels. When the last
item has passed, each pattern checks itself for completeness; all patterns above a threshold transmit their arousal
over their metalingual links to the terms they define.
Second -order patterns may come to arousal in this way,
and so on.
If this model has any validity for human processing, it
brings us close to the stage at which awareness takes over.
In awareness, conflicts are dealt with that cannot be
reduced by internalized mechanisms. The chess player
goes through a few sequences of moves to see what he can
accomplish on each of them; the listener checks out those
occasional ambiguities that he notices, and considers the
speaker's purposes, the relevance of what he has heard to
himself, and so on. The scientist compares his overall
theoretical views with the interpretations of his data as
they come to mind and tries a few analytic tricks. In
short, this is the level at which even a powerful computer
might open a dialogue with the user.
Would a sensible person build a computer with architecture oriented to a class of problems? I think so, in a
few situations. Ware listed some problems for which the
payoff function varies over a multibillion-dollar range:
foreign policy and arms control, weather and the environment, social policy, and medicine. With such payoffs, an
investment of even a large amount in a more powerful
computer might be shown to carry a sufficient likelihood
of profit to warrant a gamble. In the case of languageoriented architecture, it is not hard to develop a composite market in which the users control billions of dollars
and millions of lives with only their own brains as tools to
link conceptualization with data. A president arrives at
the moment of decision, after all the computer simulations and briefings, with a yellow pad and a pencil; to give
him a computer which could help his brain through multistratal and metalingual linkages of data and theories
would be worth a substantial investment.
Can these applications be achieved at optimal levels
without specialized architecture? I doubt it. Parallel
processing with general-purpose computers linked
through generalized busses will surely bring an improvement over serial processing, but raises problems of delay
while results are switched from one computer to another
and does nothing to solve software problems. Specialized
architecture is a lesson to be learned from linguistics with
consequences for ease of programming, time spent in
compilation or interpretation, and efficiency of parallel
processing.

Linguistics and the Future of Computation

COMPUTATIONAL LINGUISTICS
I have delayed until the end a definition of my own
field, which I have presented before. 7 It should be more
significant against the background of the foregoing discussion.
The definition is built upon a twofold distinction. One
is the distinction, familiar enough, between the infinitesimal calculus and linguistics. The calculus occupies a
major place in science, giving a means of deduction in
systems of continuous change. It has developed in two
ways: Mathematical analysis, which gives a time-independent characterization of systems including those in
which time itself is a variable-time does not appear in
the metasystem of description. And numerical analysis,
in which time is a variable of the metasystem; numerical
analysis deals in algorithms.
.Linguistics, aIs-o~-h~is develo-ped {n twowaYs.Thefirrie~
independent characterizations that Chomsky speaks of as
statements of competence are the subject of what is called
linguistics, with no modifier. This field corresponds to the
calculus, or to its applications to physical systems. Timedependent characterizations of linguistic processes are the
subject matter of computational linguistics, which also
has two parts. Its abstract branch is purely formal, dealing with linguistic systems whether realized, or realizable,
in nature; its applied branch deals with algorithms for the
processing of naturally occurring languages.
I have undertaken to show that the concepts of abstract
computational linguistics provide a foundation for nonnumerical computation comparable to that provided by the
calculus for numerical computation. The work is still in
progress, and many who are doing it would not be comfortable to think of themselves as computational linguists.
I hope that the stature of the field is growing so that more
pride can attach to the label now and hereafter than in
earlier days.

REFERENCES
1. Berlin, Brent, Kay, Paul, Basic Color Terms: Their Universality
and Evolution, Berkeley, University of California Press, 1969.
2. Chase, William G., Clark, Herbert H., "Mental Operations in the
Comparison of Sentences and Pictures," in Cognition in Learning
and Memory, edited by Lee W. Gregg, New York, Wiley, 1972, pp.
205-232.
3. Chomsky, Noam, Language and Mind, New York, Harcourt Brace
Jovanovich, enlarged edition, 1972.
4. Collins, Allan M., Quillian, M. Ross, "Experiments on Semantic
Memory and Language Comprehension," in Gregg, op. cit., pps.
117-137.

5. Fillenbaum, S., "Memory for Gist: Some Relevant Variables,"
Language and Speech, 1966, Vol. 9, pp. 217 -227.
6. Fillmore, Charles J., "The Case for Case," in Universals in Linguistic Theory, edited by Emmon Bach and Robert T. Harms, ~ew
York, Holt, Rinehart and Winston, 1968, pp. 1-88.
7. Hays, David G., The Field and Scope of Computational Linguistfcs, ·1971· Thlettiatftfifat~eefifig-on C6ihIyo.ratfoiiIilLifigUistlcs;
Debrecen.
8. Hays, David G., Margolis, Enid, Naroll, Raoul, Perkins, Revere
Dale. "Color Term Salience," American Anthropologist, 1972, Vol.
74, pp. 1107-1121.
9. Hockett, Charles F., "The Origin of Speech," Scientific American,
1960, Vol. 203, pp. 88-96.
10. Ladefoged, Peter, Preliminaries to Linguistic Phonetics, Chicago,
University of Chicago Press, 1971.
11. Keenan, Edward L., "Relative Clause Formation in Malagasy," in
The Chicago Which Hunt, edited by Paul M. Peranteau, Judith N.
Levi, and Gloria C. Phares, Chicago Linguistic Society, 1972.
12. Lamb, Sydney M., Outline of Stratificational Grammar, Washington, Georgetown University Press, revised edition, 1966.
13. McCawley, James D., "The Role of Semantics in a Grammar," in
Bach and Harms, op. cit., pp. 125-169.
14. Quillian, M. Ross, "The Teachable Language Comprehender,"
Communications of the ACM, 1969, Vol. 12, pp. 459-476.
15. Simon, Herbert A., Barenfeld, M., "Information-processing Analysis of Perceptual Processes in Problem Solving," Psychological
Review, 1969, Vol. 76, pp. 473-483.
16. Ware, Willis H., "The Ultimate Computer," IEEE Spectrum,
March 1972.

National Computer Conference, 1973

Speech understanding

Literary text processing

by DONALD E. WALKER

by SALLY YEATES SEDELOW

Stanford Research Institute
Menlo Park, California

University of Kansas
Lawrence, Kansas

ABSTRACT

Research on speech understanding is adding new
dimensions to the analysis of speech and to the understanding of language. The accoustic, phonetic, and phonological processing of speech recognition efforts are being
blended with the syntax, semantics, and pragmatics of
question-answering systems. The goal is the development
of capabilities that will allow a person to have a conversation with a computer in the performance of a shared task.
Achievement of this goal will both require and contribute
to a more comprehensive and powerful model of language
-with significant consequences for linguistics, for computer science, and especially for computational linguistics.

To date, computer-based literary text processing bears
much greater similarity to techniques used for information retrieval and, to some degree, for question-answering,
than it does to techniques used in, for example, machine
translation of 'classical' artificial intelligence. A literary
text is treated not as 'output' in a process to be emulated
nor as a string to be transformed into an equivalent verbal representation, but, rather, as an artifact to be analyzed and described.
The absence of process as an integrating concept in
computer-based literary text processing leads to very
different definitions of linguistic domains (such as semantics and syntactics) than is the case with, for example,
artificial intelligence. This presentation explores some of
these distinctions, as well as some of the implications of
more process-oriented techniques for literary text processing.

Syntax and computation
by JANE J. ROBINSON
The University of Michigan
Ann Arbor, Michigan

ABSTRACT
Algorithms have been developed for generating and
parsing with context-sensitive grammars. In principle, the
contexts to which a grammar is sensitive can be syntactic,
semantic, pragmatic, or phonetic. This development
points up the need to develop a new kind of lexicon,
whose entries contain large amounts of several kinds of
contextual information about each word or morpheme,
provided in computable form. Ways in which both the
form and content of the entries differ from those of traditional dictionaries are indicated.

The augmented knowledge workshop
by DOUGLAS C. ENGELBART, RICHARD W. WATSON, and JAMES C. NORTON
Stanford Research Institute
Menlo Park, California

Workshop improvement involves systematic change not
only in the tools that help handle and transform the
materials, but in the customs, conventions, skills, procedures,- we-rk-ing-met-heds-,fH'-g-ani-z-ati-onal-rG-ies,---t-r-aining,-etc., by which the workers and their organizations harness
their tools, their skills, and their knowledge.
Over the past ten years, the explicit focus in the Augmentation Research Center (ARC) has been upon the
effects and possibilities of new knowledge workshop tools
based on the technology of computer timesharing and
modern communications. 18 -41 Since we consider automating many human operations, what we are after could
perhaps be termed "workshop automation." But the very
great importance of aspects other than the new tools (i.e.,
conventions, methods, roles) makes us prefer the "augmentation" term that hopefully can remain "wholescope." We want to keep tools in proper perspective
within the total system that augments native human
capacities toward effective action.I-3.1O.16.18.24
Development of more effective knowledge workshop
technology will require talents and experience from many
backgrounds: computer hardware and software, psychology, management science, information science, and operations research, to name a few. These must come together
within the framework of a new discipline, focused on the
systematic study of knowledge work and its workshop
environments.

CONCEPT OF THE KNOWLEDGE WORKSHOP
This paper discusses the theme of augmenting a knowle-dgeworkshop. -The first part-of-the-paper describes the
concept and framework of the knowledge workshop. The
second part describes aspects of a prototype knowledge
workshop being developed within this framework.
The importance and implications of the idea of knowledge work have been described by Drucker. 3.4 Considering
knowledge to be the systematic organization of information and concepts, he defines the knowledge worker as the
person who creates and applies knowledge to productive
ends, in contrast to an "intellectual" for whom information and concepts may only have importance because
they interest him, or to the manual worker who applies
manual skills or brawn. In those two books Drucker
brings out many significant facts and considerations
highly relevant to the theme here, one among them
(paraphrased below) being the accelerating rate at which
knowledge and knowledge work are coming to dominate
the working activity of our society:
In 1900 the majority and largest single group of
Americans obtained their livelihood from the farm.
By 1940 the largest single group was industrial workers, especially semiskilled machine operators. By
1960, the largest single group was professional,
managerial, and technical-that is, knowledge workers. By 1975-80 this group will embrace the majority
of Americans. The productivity of knowledge has
already become the key to national productivity,
competitive strength, and economic achievement,
according to Drucker. It is knowledge, not land, raw
materials, or capital, that has become the central
factor in production.

TWO WAYS IN WHICH AUGMENTED
KNOWLEDGE WORKSHOPS ARE EVOLVING

Introduction
First, one can see a definite evolution of new workshop
architecture in the trends of computer application systems. An "augmented workshop domain" will probably
emerge because many special-purpose application systems are evolving by adding useful features outside their
immediate special application area. As a result, many will
tend to overlap in their general knowledge work supporting features.
Second, research and development is being directed
toward augmenting a "Core" Knowledge Workshop
domain. This application system development is aimed
expressly at supporting basic functions of knowledge

In his provocative discussions, Drucker makes extensive use of such terms as "knowledge organizations,"
"knowledge technologies," and "knowledge societies." It
seemed a highly appropriate extension for us to coin
"knowledge workshop" for re-naming the area of our
special interest: the piace in which knowledge workers do
their work. Knowledge workshops have existed for centuries, but our special concern is their systematic improvement, toward increased effectiveness of this new breed of
craftsmen.
9

National Computer Conference, 1973

work. An important characteristic of such systems is to
interface usefully with specialized systems. This paper is
oriented toward this second approach.
NATURAL EVOLUTION BY SCATTERED
NUCLEI EXPANDING TOWARD A COMMON
"KNOWLEDGE WORKSHOP" DOMAIN
Anderson and Coover 15 point out that a decade or more
of application-system evolution is bringing about the
beginning of relatively rational user-oriented languages
for the control interfaces of advanced applications software systems. What is interesting to note is that the functions provided by the "interface control" for the more
advanced systems are coming to include editors and generalized file-management facilities, to make easier the
preparation, execution, and management of the specialpurpose tools of such systems.
It seems probable that special application-oriented
systems (languages) will evolve steadily toward helping
the user with such associated work as formulating models,
documenting them, specifying the different trial runs,
keeping track of intermediate results, annotating them
and linking them back to the users' model(s), etc. When
the results are produced by what were initially the core
application programs (e.g., the statistical programs), he
will want ways to integrate them into his working notes,
illustrating, labeling, captioning, explaining and interpreting them. Eventually these notes will be shaped into
memoranda and formal publications, to undergo dialogue
and detailed study with and by others. 15
Once a significant user-oriented system becomes established, with a steady growth of user clientele, there will be
natural forces steadily increasing the effectiveness of the
system services and steadily decreasing the cost per unit
of service. And it will also be natural that the functional
domain of an application system will steadily grow outward: "as long as the information must be in computer
form anyway for an adjacent, computerized process, let's
consider applying computer aid to Activity X also."
Because the boundary of the Application System has
grown out to be "next to" Activity X, it has become
relatively easy to consider extending the computerized-information domain a bit so that a new application process can support Activity X. After all, the
equipment is already there, the users who perform
Activity X are already oriented to use integrated
computer aid, and generally the computer facilitation
of Activity X will prove to have a beneficial effect on
the productivity of the rest of the applications system.
This domain-spreading characteristic is less dependent
upon the substantive work area a particular application
system supports than it is upon the health and vitality of
its development and application (the authors of Reference
15 have important things to say on these issues): however.
it appears that continuing growth is bound to occur in

many special application domains, inevitably bringing
about overlap in common application "sub-domains" (as
seen from the center of any of these nuclei). These special
subdomains include formulating, studying, keeping track
of ideas, carrying on dialogue, publishing, negotiating,
planning, coordinating, learning, coaching, looking up in
the yellow pages to find someone who can do a special
service, etc.
CONSIDERING THE CORE KNOWLEDGE
WORKSHOP AS A SYSTEM DOMAIN IN ITS
OWN RIGHT
A second approach to the evolution of a knowledge
workshop is to recognize from the beginning the amount
and importance of human activity constantly involved in
the "core" domain of knowledge work-activity within
which more specialized functions are embedded.
If you asked a particular knowledge worker (e.g., scientist, engineer, manager, or marketing specialist) what
were the foundations of his livelihood, he would probably
point to particular skills such as those involved in designing an electric circuit, forecasting a market based on various data, or managing work flow in a project. If you
asked him what tools he needed to improve his effectiveness he would point to requirements for aids in designing
circuits, analyzing his data, or scheduling the flow of
work.
But, a record of how this person used his time, even if
his work was highly specialized, would show that
specialized work such as mentioned above, while vital
to his effectiveness, probably occupied a small fraction of his time and effort.
The bulk of his time, for example, would probably
be occupied by more general knowledge work: writing
and planning or design document; carrying on dialogue with others in writing, in person, or on the telephone; studying documents; filing ideas or other
material; formulating problem-solving approaches;
coordinating work with others; and reporting results.
There would seem to be a promise of considerable
payoff in establishing a healthy, applications oriented
systems development activity within this common, "core"
domain, meeting the special-application systems "coming
the other way" and providing them with well-designed
services at a natural system-to-system interface.
It will be much more efficient to develop this domain
explicitly, by people oriented toward it, and hopefully
with resources shared in a coordinated fashion. The alternative of semi-random growth promises problems such as:
(1) Repetitive solutions for the same functional prob-

lems, each within the skewed perspective of a particular special-applications area for which these
problems are peripheral issues,
(2) Incompatibility between diferent application software systems in terms of their inputs and outputs.

The Augmented Knowledge Workshop

(3) Languages and other control conventions inconsist-

ent or based on different principles from one system to another, creating unnecessary learning barriers or other discouragements to cross usage.
In summary, the two trends in the evolution of knowledge workshops described above- are each valuable and
are complementary. Experience and specific tools and
techniques can and will be transferred between them.
There is a very extensive range of "core" workshop
functions, common to a wide variety of knowledge work,
and they factor into many levels and dimensions. In the
sections to follow, we describe our developments, activities, and commitments from the expectation that there
soon will be increased activity in this core knowledge
workshop domain, and that it will be evolving "outward"
to meet the other application systems "heading inward."

BASIC ASSUMPTIONS ABOUT AUGMENTED
KNOWLEDGE WORKSHOPS EMBEDDED IN A
COMPUTER NETWORK

such as the language, control conventions, and methods
for obtaining help and computer-aided training.
This characteristic has two main implications. One, it
means that while each domain within the core \vorkshop
area or within a specialized application system may have
a vocabulary unique to its area, this vocabulary will be
used within language and control structures common
throughout the workshop system. A user will learn to use
additional functions by increasing vocabulary, not by
having to learn separate "foreign" languages. Two, when
in trouble, he will invoke help or tutorial functions in a
standard way.
Grades of user proficiency
Even a once-in-a-while user with a minimum of learning will want to be able to get at least a few straightforwardthi-ngsoone. In faet,even an expert-user-iu--onedomain will be a novice in others that he uses infrequently. Attention to novice-oriented features is required.
But users also want and deserve the reward of
increased proficiency and capability from improvements
in their skills and knowledge, and in their conceptual
orientation to the problem domain and to their workshop's system of tools, methods, conventions, etc. "Advanced vocabularies" in every special domain will be
important and unavoidable.
A corollary feature is that workers in the rapidly evolving augmented workshops should continuously be
involved with testing and training in order that their skills
and knowledge may harness available tools and methodology most effectively.

The computer-based "tools" of a knowledge workshop
will be provided in the environment of a computer network such as the ARPANET. 7 .8.14 For instance, the core
functions will consist of a network of cooperating processors performing special functions such as editing, publishing, communication of documents and messages, data
management, and so forth. Less commonly used but
important functions might exist on a single machine. The
total computer assisted workshop will be based on many
geographically separate systems.
Once there is a "digital-packet transportation system,"
it becomes possible for the individual user to reach out
through his interfacing processor(s) to access other people
and other services scattered throughout a "community,"
and the "labor marketplace" where he transacts his
knowledge work literally will not have to be affected by
geographical location. 27
Specialty application systems will exist in the way that
specialty shops and services now do-and for the same
reasons. When it is easy to transport the material and
negotiate the service transactions, one group of people will
find that specilization can improve their cost/ effectiveness, and that there is a large enough market within reach
to support them. And in the network-coupled computerresource marketplace, the specialty shops will grow-e.g.,
application systems specially tailored for particular types
of analyses, or for checking through text for spelling
errors, or for doing the text-graphic document typography
in a special area of technical portrayal, and so on. There
will be brokers, wholesalers, middle men, and retailers.

One cannot predict ahead of time which domains or
application systems within the workshop will want to
communicate in various sequences with which others, or
what operations will be needed in the future. Thus,
results must be easily communicated from one set of
operations to another, and it should be easy to add or
interface new domains to the workshop.

Coordinated set of user interface principles

Availability of people support services

There will be a common set of principles, over the
many application areas, shaping user interface features

An augmented workshop will have more support services available than those provided by computer tools.

Ease of communication between, and addition of,
workshop domains

User programming capability
There will never be enough professional programmers
and system developers to develop or interface all the toois
that users may need for their work. Therefore, it must be
possible, with various levels of ease, for users to add or
interface new tools, and extend the language to meet their
needs. They should be able to do this in a variety of programming languages with which they may have training,
or in the basic user-level language of the workshop itself.

National Computer Conference, 1973

There will be many people support services as well:
besides clerical support, there will be extensive and
highly specialized professional services, e.g., document
design and typography, data base design and administration, training, cataloging, retrieval formulation, etc. In
fact, the marketplace for human services will become
much more diverse and active. 27
Cost decreasing, capabilities increasing
The power and range of available capabilities will
increase and costs will decrease. Modular software
designs, where only the software tools needed at any given
moment are linked into a person's run-time computer
space, will cut system overhead for parts of the system
not in use. Modularity in hardware will provide local
configurations of terminals and miniprocessors tailored
for economically fitting needs. It is obvious that cost of
raw hardware components is plummeting; and the
assumed large market for knowledge workshop support
systems implies further help in bringing prices down.
The argument given earlier for the steady expansion of
vital application systems to other domains remains valid
for explaining why the capabilities of the workshop will
increase. Further, increasing experience with the workshop will lead to improvements, as will the general trend
in technology evolution.
Range of workstations and symbol representations
The range of workstations available to the user will
increase in scope and capability. These workstations will
support text with large, open-ended character sets, pictures, voice, mathematical notation, tables, numbers and
other forms of knowledge representation. Even small
portable hand-held consoles will be available. 13

Careful development of methodology
As much care and attention will be given to the development, analysis, and evaluation of procedures and
methodology for use of computer and people support services as to the development of the technological support
services.
Changed roles and organizational structure
The widespread availability of workshop services will
create the need for new organizational structures and
roles.
SELECTED DESCRIPTION OF AUGMENTED
WORKSHOP CAPABILITIES
Introduction
\Vithin the framework described above, ARC is developing a prototype workshop system. Our system does not

meet all the requirements outlined previously, but it does
have a powerful set of core capabilities and experience
that leads us to believe that such goals can be achieved.
Within ARC we do as much work as possible using the
range of online capabilities offered. We serve not only as
researchers, but also as the subjects for the analysis and
evaluation of the augmentation system that we have been
developing.
Consequently, an important aspect of the augmentation
work done within ARC is that the techniques being
explored are implemented, studied, and evaluated with
the advantage of intensive everyday usage. We call this
research and development strategy "bootstrapping."
In our experience, complex man-machine systems can
evolve only in a pragmatic mode, within real-work environments where there is an appropriate commitment to
conscious, controlled, exploratory evolution within the
general framework outlined earlier. The plans and commitments described later are a consistent extension of this
pragmatic bootstrapping strategy.
To give the reader more of a flavor of some of the many
dimensions and levels of the ARC workshop, four example areas are discussed below in more detail, following a
quick description of our physical environment.
The first area consists of mechanisms for studying and
browsing through NLS files as an example of one functional dimension that has been explored in some depth.
The second area consists of mechanisms for collaboration support-a subsystem domain important to many
application areas.
The third and fourth areas, support for software engineers and the ARPANET Network Information Center
(NIC), show example application domains based on functions in our workshop.
General physical environment
Our computer-based tools run on a Digital Equipment
Corporation PDP-10 computer, operating with the Bolt,
Beranek, and Newman TENEX timesharing system. 9 The
computer is connected via an Interface Message Processor (IMP) to the ARPANET.7 s There is a good deal of
interaction with Network researchers, and with Network
technology, since we operate the ARPA Network Information Center (see below).39
There is a range of terminals: twelve old, but serviceable, display consoles of our own design,26 an IMLAC display, a dozen or so 30 ch/sec portable upper/lower case
typewriter terminals, five magnetic tape-cassette storage
units that can be used either online or offline, and a 96character line printer. There are 125 million characters of
online disk storage.
o

The display consoles are equipped with a typewriterlike keyboard, a five-finger keyset for one-handed
character input, and a "mouse"-a device for controlling the position of a cursor (or pointer) on the
display screen and for input of certain control
commands. Test results on the mouse as a ~creen-

The Augmented Knowledge Workshop

selection device have been reported in Reference 25,
and good photographs and descriptions of the physical systems have appeared in References 20 and 21.
The core workshop software system and language,
called NLS, provides many basic tools, of which a number will be mentioned below. It is our "core-workshop
application system."
During the initial years of workshop development,
application and analysis, the basic knowledge-work functions have centered around the composition, modification,
and study of structured textual material. 26 Some of the
capabilities in this area are described in detail in Reference 26, and are graphically shown in a movie available
on 10an~1The structured:te.xt manipulation has heendevelop_ed
extensively because of its high payoff in the area of
applications-system development to which we have
applied our augmented workshop. We have delayed
addition of graphic-manipulation capabilities
because there were important areas associated with
the text domain needing exploration and because of
limitations in the display system and hardcopy printout.
To build the picture of what our Core Knowledge
Workshop is like, we first give several in-depth examples,
and then list in the section on workshop utility service
some "workshop subsystems" that we consider to be of
considerable importance to general knowledge work.
STUDYING ONLINE DOCUMENTS

Introduction
The functions to be described form a set of controls for
easily moving one around in an information space and
allowing one to adjust the scope, format, and content of
the information seen. 26 .41
Given the addition of graphical, numerical, and vocal
information, which are planned for addition to the workshop, one can visualize many additions to the concepts
below. Even for strictly textual material there are yet
many useful ideas to be explored.

View specifications
One may want an overview of a document in a table-ofcontents like form on the screen. To facilitate this and
other needs, NLS text files are hierarchically structured
in a tree form with subordinate material at lower levels in
the hierarchy. 26
The basic conceptual unit in NLS, at each node of
the hierarchical file, is called a "statement" and is
usually a paragraph, sentence, equation, or other unit
that one wants to manipulate as a whole.

A statement can contain many characters-presently, up to 2000. Therefore, a statement can contain
many lines of text. Two of the "view-specification"
parameters-depth in the hierarchy, and lineS peT
statement-can be controlled during study of a
document to give various overviews of it. View specifications are given with highly abbreviated control
codes, because they are used very frequently and
their quick specification and execution make a great
deal of difference in the facility with which one studies the material and keeps track of where he is.
Examples of other view specifications are those that
control spacing between statements, and indentation for
levels in the hierarchy, and determine whether the identifications associated with statements are to be displayed,
whi~.h br(1Il~_h(~sl ill the tree.a,r~t(). b_~ disRla-y~~:t,. :wh~th~r
special filters are to be invoked to show only statements
meeting specified content requirements or whether statements are to be transformed according to special rules
programmed by the user.

Moving in information space
A related viewing problem is designating the particular
location (node in a file hierarchy) to be at the top of the
screen. The computer then creates a display of the information from that point according to the view specifications currently in effect.
The system contains a variety of appropriate commands to do this; they are called jump commands
because they have the effect of "jumping" or moving one
from place to place in the network of files available as a
user's information space.26.33-39
One can point at a particular statement on the screen
and command the system to move on to various positions relative to the selected one, such as up or down
in the hierarchical structure, to the next or preceding
statement at the same hierarchical level, to the first
or last statement at a given level, etc.
One can tell the system to move to a specifically
named point or go to the next occurrence of a statement with a specific content.
Each time a jump or move is made, the option is
offered of inciuding any of the abbreviated view specifications-a very general, single operation is "jump
to that location and display with this view."
As one moves about in a file one may want to quickly
and easily return to a previous view of the path as one
traverses through the file and the specific view at each
point, and then aliowing return movement to the most
recent points saved.
Another important feature in studying or browsing in a
document is being able to quickly move to other documents cited.

National Computer Conference, 1973

There is a convention (called a "link';) for citing
documents that allows the user to specify a particular
file, statement within the file and view specification
for initial display when arriving in the cited file.
A single, quickly executed command (Jump to Link)
allows one to point at such a citation, or anywhere in
the statement preceding the citation, and the system
will go to the specific file and statement cited and
show the associated material with the specified view
parameters. This allows systems of interlinked
documents and highly specific citations to be created.
A piece of the path through the chain of documents is
saved so that one can return easily a limited distance
back along his "trail," to previously referenced documents. Such a concept was originally suggested by Bush 1
in a fertile paper that has influenced our thinking in
many ways.

function is available for both display and typewriter
terminal users over the ARPANET.
The technique is particularly effective between displays because of the high speed of information output and
the flexibility of being able to split the screen into several
windows, allowing more than one document or view of a
document to be displayed for discussion.
When a telephone link is also established for voice
communication between the participants, the technique
comes as close' as any we know to eliminating the need for
collaborating persons or small groups to be physically
together for sophisticated interaction.
A number of other healthy approaches to teleconferencing are being explored elsewhere. 11.12.16.17 It would be
interesting to interface to such systems to gain experience
in their use within workshops such as described here.
RECORDED DIALOGUE SUPPORT

Multiple windows

Introduction

Another very useful feature is the ability to "split" the
viewing screen horizontally and/ or vertically in up to
eight rectangular display windows of arbitrary size. Generally two to four windows are all that are used. Each
window can contain a different view of the same or different locations, within the same or different files. 39

As ARC has become more and more involved in the
augmentation of teams, serious consideration has been
given to improving intra- and inter-team communication
with whatever mixture of tools, conventions, and procedures will help.27.36.39
If a team is solving a problem that extends over a considerable time, the members will begin to need help in
remembering some of the important communicationsi.e., some recording and recalling processes must be
invoked, and these processes become candidates for
augmentation.
If the complexity of the team's problem relative to
human working capacity requires partitioning of the
problem into many parts-where each part is independently attacked, but where there is considerable interdependence among the parts-the communication between
various people may well be too complex for their own
accurate recall and coordination without special aids.
Collaborating teams at ARC have been augmented by
development of a "Dialogue Support System (DSS),"
containing current and thoroughly used working records
of the group's plans, designs, notes, etc. The central feature of this system is the ARC Journal, a specially managed and serviced repository for files and messages.
The DSS involves a number of techniques for use by
distributed parties to collaborate effectively both using
general functions in the workshop and special functions
briefly described below and more fully in Reference 39.
Further aspects are described in the section on Workshop
Utility Service.

COLLABORATIVE DIALOGUE AND
TELECONFERENCING

Introduction

The approach to collaboration support taken at ARC to
date has two main thrusts:
(1) Support for real-time dialogue (teleconferencing)

for two or more people at two terminals who want
to see and work on a common set of material. The
collaborating parties may be further augmented
with a voice telephone connection as well.
(2) Support for written, recorded dialogue, distributed
over time.
These two thrusts give a range of capabilities for support of dialogue distributed over time and space.
Teleconferencing support

Consider two people or groups of people who are geographically separated and who want to collaborate on a
document, study a computer program, learn to use a new
aspect of a system, or perform planning tasks, etc.
The workshop supports this type of collaboration by
allowing them to link their terminals so that each sees the
same information and either ('an control the system. This

Document or message submi.<;sion

The user can submit an NLS file, a part of a file, a file
prepared on another system in the ARPANET
(document). or text t~'ped at submission time (message)

The Augmented Knowledge Workshop

to the Journal system. When submitted, a copy of the
document or message is transferred to a read -only file
whose permanent safekeeping is guaranteed by the Journal system. It is assigned a unique catalog number, and
automatically cataloged. Later, catalog indices based on
number, author, and "titleword out of context" are created by another computer process.
Nonrecorded dialogue for quick messages or material
not likely to be referenced in the future is also permitted.
One can obtain catalog numbers ahead of time to interlink document citations for related documents that are
being prepared simultaneously. Issuing and controlling of
catalog numbers is performed by a Number System (an
automatic, crash-protected computer process).
At the time of submission, the user can contribute such
information as: title, distribution list, comments, keyW-6-fa-S,eat-affig--numbers of-documents this- new one
supersedes (updates), and other information.
The distribution is specified as a list of unique identification terms (abbreviated) for individuals or groups. The
latter option allows users to establish dialogue groups.
The system automatically "expands" the group identification to generate the distribution list of the individuals
and groups that are its members. Special indices of items
belonging to subcollections (dialogue groups) can be prepared to aid their members in keeping track of their dia10gue. An extension of the mechanisms available for
group distribution could give a capability similar to one
described by Turoff. 17
Entry of identification information initially into the
system, group expansion, querying to find a person's or
group's identification, and other functions are performed
by an Identification System.

Document distribution
Documents are distributed to a person in one, two, or
all of three of the following ways depending on information kept by the Identification System.
(1) In hardcopy through the U.S. or corporation mail
to those not having online access or to those desiring this mode,
(2) Online as citations (for documents) or actual text
(for messages) in a special file assigned to each
user.
(3) Through the ARPANET for printing or online
delivery at remote sites. This delivery is performed
using a standard Network wide protocol.
Document distribution is automated, with online delivery performed by a background computer process that
runs automatically at specified times. Printing and mailing are performed by operator and clerical support. \Vith
each such printed document, an address cover sheet is
automatically printed, so that the associated printout
pages only need to be folded in half, stapled, and stamped
before being dropped in the mail.

Document access
An effort has been made to make convenient both
online and offline access to Journal documents. The
master catalog number is the key to accessing documents.
Several strategically placed hardcopy master and access
collections (libraries) are maintained, containing all
J oumal documents.
Automatic catalog-generation processes generate
author, number, and titleword indices, both online and in
hardcopy.38 The online versions of the indices can be
searched conveniently with standard NLS retrieval capabilities. 37 ,39,41
Online access to the full text of a document is accomplished by using the catalog number as a file name and
loading the file or moving to it by pointing at a citation
and asking the -system to "}ump;;
as -(fescrlbed-e~~~
lier.

there

SOFTWARE ENGINEERING AUGMENTATION
SYSTEM

Introduction
One of the important application areas in ARC's work
is software engineering. The economics of large computer
systems, such as NLS, indicate that software development and maintenance costs exceed hardware costs, and
that software costs are rising while hardware costs are
rapidly decreasing. The expected lifetime of most large
software systems exceeds that of any piece of computer
hardware. Large software systems are becoming increasingly complex, difficult to continue evolving and maintain. Costs of additional enhancements made after initial
implementation generally exceed the initial cost over the
lifetime of the system. It is for these reasons that it is
important to develop a powerful application area to aid
software engineering. Areas of software engineering in
which the ARC workshop offers aids are described below.

Design and review collaboration
During design and review, the document creation, editing, and studying capabilities are used as well as the collaboration, described above.

Use of higher level system programming languages
Programming of NLS is performed in a higher level
ALGOL-like system programming language called L-10
developed at ARC. The L-10 language compiler takes its
input directly from standard NLS structured files. The
PDP-10 assembler also can obtain input from NLS files.
It is planned to extend this capability to other ianguages, for example, by providing an interface to the
BASIC system available in our machine for knowledge
workers wishing to perform more complex numerical
tasks.

National Computer Conference, 1973

We are involved with developing a modular runtimelinkable programming system (MPS), and with planning
a redesign of NLS to utilize MPS capabilities, both in
cooperation with the Xerox Palo Alto Research Center.
MPS will:

(2)

(1) Allow a workshop system organization that will

(3)

(2)
(3)
(4)
(5)

make it easier for many people to work on and
develop parts of the same complex system semiindependently.
Make it easier to allow pieces of the system to exist
on several processors.
Allow individual users or groups of users to tailor
versions of the system to their special needs.
Make it easier to move NLS to other computers
since MPS is written in itself.
Speed system development because of MPS's
improved system building language facilities, integrated source-level debugging, measurement facilities, the ability to construct new modules by combining old ones, and to easily modify the system by
changing module interconnection.

System documentation and source-code creation
Source-code creation uses the standard NLS hierarchical file structures and allows documentation and other
programming conventions to be established that simplify
studying of source-code files.

Debugging

(5)
(6)

(7)

Maintenance
Maintenance programmers use the various functions
mentioned above. The Journal is used for reporting bugs;
NLS structured source code files simplify the study of
problem areas and the debugging tools permit easy modification and testing of the modifications.
THE ARPA NETWORK INFORMATION CENTER
(NIC)

Introduction

A form of source-level debugging is allowed through
development of several tools, of which the following are
key examples:
(1) A user program compilation and link loading facil-

ity that allows new or replacement programs to be
linked into the running system to create revised
versions for testing or other purposes.
(2) NLS-DDT, a DDT like debugging facility with a
command language more consistent with the rest of
NLS, and simplifies display of system variables
and data structures, and allows replacement of
system procedures by user supplied procedures.
(3) Use of several display windows so as to allow source
code in some windows and control of DDT in others for the setting of breakpoints and display of
variables and data structures.

Measurement and analysis
A range of measurement tools has been developed for
analyzing system operation. These include the following:
(1) Capabilities for gathering and reporting statistics

un many operalillg

(4)

zation of system components in various modes,
queue lengths, memory utilization, etc.
The ability to sample the program counter for
intervals of a selectable area of the operating system or any particular user subsystem to measure
time spent in the sampled areas;
Trace and timing facilities to follow all procedure
calls during execution of a specified function.
The ability to study page-faulting characteristics of
a subsystem to check on its memory use characterist.ics.
The ability to gather NLS command usage and
timing information.
The ability to study user interaction on a task basis
from the point of view of the operating-system
scheduler.
The ability to collect sample user sessions for later
playback to the system for simulated load, or for
analysis.

~)~tem

parameters such as utili-

The NIC is presently a project embedded within
ARC.39 Workshop support for the NIC is based on the
capabilities within the total ARC workshop system.
As useful as is the bootstrapping strategy mentioned
earlier, there are limits to the type of feedback it can
yield with only ARC as the user population. The NIC is
the first of what we expect will be many activities set up
to offer services to outside users. The goal is to provide a
useful service and to obtain feedback on the needs of a
wider class of knowledge workers. Exercised within the
NIC are also prototypes of information services expected
to be normal parts of the workshop.
The NIC is more than a classical information center, as
that term has come to be used, in that it provides a wider
range of services than just bibliographic and "library"
type services.
The NIC is an experiment in setting up and running a
general purpose information service for the ARPANET
community with both online and offline services. The
services offered and under development by the NIC have
as their initial basic objectives:
(1) To help people with problems find the resources
(people, systems, and information) available within
the network community that meet thf'ir nPNio;:..

The Augmented Knowledge Workshop

(2) To help members of geographically distributed
groups collaborate with each other.
Following are the NIC services now provided to meet
the above goals in serving the present clientele:
.Current online services
(1) Access to the typewriter version (TNLS) and display version (D~LS) of the Augmentation
Research Center's Online System (NLS) for
communique creation, access, and linking between
users, and for experimental use for any other information storage and manipulation purpose suitable
for NLS and useful to Network participants.
(2) Access to Journal, Number, and Identification
Systems. to al1o.w ..mes.,c;;;ages and documents to . be
transmitted between network participants.
(3) Access to a number of online information bases
through a special Locator file using :KLS link
mechanisms and through a novice-oriented query
system.
Current offline services
(1) A 'Network Information Center Station set up at
each network site.
(2) Techniques for gathering, producing and maintaining data bases such as bibliographic catalogs, directories of network participants, resource information, and user guides.
(3) Support of Network dialogue existing in hardcopy
through duplication, distribution, and cataloging.
(4) General Network referral and handling of document requests.
(5) Building of a collection of documents potentially
valuable to the Network Community. Initial concentration has been on obtaining documents of
possible value to the Network builders.
(6) As yet primitive selective document distribution to
Station Collections.
(7) Training in use of NIC services and facilities.
Conclusion
The Network Information Center is an example prototype of a new type of information service that has significant future potential. Even though it is presently in an
experimental and developmental phase, it is providing
useful online and offline services to the ARPANET
community.

so that we can begin to transfer the fruits of our past work
to them and with their assistance, to others, and so that
we can obtain feedback needed for further evolution from
wider appiication than is possibie in our project alone. 28
We want to find and support selected groups who are willing to take extra trouble to be exploratory, but who:
(1) Are not necessarily oriented to being core-workshop
developers (they have their own work to do).
(2) Can see enough benefit from the system to be tried
and from the experience of trying it so that they
can justify the extra risk and expense of being
"early birds."
(3) Can accept assurance that system reliability and
stability, and technical! application help will be
available to meet their conditions for risk and cost.
ARC is establishing a Workshop Utility Service, and
promoting the type of workshop service described above
as part of its long-term commitment to pursue the continued development of augmented knowledge workshops in a
pragmatic, evolutionary manner.
It is important to note that the last few years of work
have concentrated on the means for delivering support to
a distributed community, for providing teleconferencing
and other basic processes of collaborative dialogue, etc.
ARC has aimed consciously toward developing experience
and capabilities especially applicable to support remote
and distributed groups of exploratory users for this next
stage of wider-application bootstrapping.
One aspect of the service is that it will be an experiment in harnessing the new environment of a modern
computer network to increase the feasibility of a wider
community of participants cooperating in the evolution of
an application system.
Characteristics of the planned service
The planned service offered will include:
(1) Availability of Workshop Utility computer service

to the user community from a PDP-IO TEKEX
system operated by a commercial supplier.
(2) Providing training as appropriate in the use of
Display NLS (DNLS), Typewriter NLS (TNLS),
and Deferred Execution (DEX) software subsystems,
(3) Providing technical assistance to a user organization "workshop architect" in the formulation,
development, and implementation of augmented
knowledge work procedures within selected offices
at the user organization. 6

PLANS FOR A WORKSHOP UTILITY SERVICE
Motivation
It is now time for a next stage of application to be
established. We want to involve a wider group of people

This assistance will include help in the development of NLS use strategies suitable to the user
environments, procedures within the user organization for implementing these strategies, and
possible special-application NLS extensions (or

National Computer Conference, 1973

simplifications) to handle the mechanics of particular user needs and methodologies.
(4) Providing "workshop architect" assistance to help
set up and assist selected geographically distributed user groups who share a special discipline or
mission orientation to utilize the workshop utility
services and to develop procedures, documentation,
and methodology for their purposes.
GENERAL DESCRIPTION OF SOME WORKSHOP
UTILITY SUBSYSTEMS

Introduction
Within a particular professional task area (mission- or
discipline-oriented) there are often groups who could be
benefited by using special workshop subsystems. These
subsystems may be specialized for their specific application or research domain or for support of their more general knowledge work. Our goal is to offer a workshop utility service that contains a range of subsystems and associated methodology particularly aimed at aiding general
knowledge work, and that also ~;upports in a coordinated
way special application subsystems either by interfacing
to subsystems already existing, or by developing new
subsystems in selected areas.
In the descriptions to follow are a number of workshop
subsystem domains that are fundamental to a wide range
of knowledge work in which ARC already has extensive
developments or is committed to work. For each subsystem we include some general comments as well as a brief
statement of current ARC capabilities in the area.

Document development, production, and control
Here a system is considered involving authors, editors,
supervisors, typists, distribution-control personnel, and
technical specialists. Their job is to develop documents,
through successive drafts, reviews, and revisions. Control
is needed along the way of bibliography, who has checked
what point, etc. Final drafts need checkoff, then production. Finally distribution needs some sort of control. If it
is what we call a "functional document" such as a user
guide, then it needs to be kept up to date. 39 There is a
further responsibility to keep track of who needs the
documents, who has what version, etc.
Within the ARC workshop, documents ranging from
initial drafts to final high-quality printed publications
can be quickly produced with a rich set of creation and
editing functions. All of ARC's proposals, reports, designs,
letters, thinkpieces, user documentation, and other such
information are composed and produced using the workshop.
Documents in a proof or finished form can be produced
with a limited character set and control on a line printer
or typewriter, or publication quality documents can be
produced on a photocomposer microfilm unit.

Presently there are on the order of two hundred special directives that can be inserted in text to control
printing. These directives control such features as
typefont, pagination, margins, headers, footers, statement spacing, typefont size and spacing, indenting,
numbering of various hierarchical levels, and many
other parameters useful for publication quality work.
Methodology to perform the creation, production,
and controlling functions described above has been
developed, although much work at this level is still
needed.
In terms of future goals, one would like to have display
terminals with a capability for the range of fonts available on the photocomposer so that one could study page
layout and design interactively, showing the font to be
used, margins, justification, columnization, etc. on the
screen rather than having to rely on hardcopy proofsheets.
To prepare for such a capability, plans are being
made to move toward an integrated portrayal mechanism for both online and hardcopy viewing.

Collaborative dialogue and teleconferencing
Effective capabilities have already been developed and
are in application, as discussed above. There is much yet
to do. The Dialogue Support System will grow to provide
the following additional general online aids:
Link-setup automation; back-link annunciators and
jumping; aids for the formation, manipulation, and study
of sets of arbitrary passages from among the dialogue
entries; and integration of cross-reference information
into hardcopy printouts. Interfaces will probably be made
to other teleconferencing capabilities that come into existence on the ARPANET.
It also will include people-system developments: conventions and working procedures for using these aids
effectively in conducting collaborative dialogue among
various kinds of people, at various kinds of terminals, and
under various conditions; working methodology for teams
doing planning, design, implementation coordination; and
so on.

Meetings and conferences
Assemblies of people are not likely for a long time, if
ever, to be supplanted in total by technological aids.
Online conferences are held at ARC for local group meetings and for meetings where some of the participants are
located across the country.
Use is made of a large-screen projection TV system to
provide a display image that many people in a conference
room can easily see. This is controlled locally or remotely
by participants in the meeting, giving access to the entire
recorded dialogue data base m: needed during the meeting
and also providing the capability of recording real-time

The Augmented Knowledge Workshop

meeting notes and other data. The technique also allows
mixing of other video signals.

Management and organization
The capabilities offered in the workshop described in
this paper are used in project management and administration. 39 Numerical calculations can also be performed
for budget and other purposes, obtaining operands and
returning results to NLS files for further manipulation.
Where an organization has conventional project management operations, their workshop can include computer
aids for techniques such as PERT and CPM. We want to
support the interfacing that our Core Workshop can provide to special application systems for management processes.
We -aYe---especiatly--lnteFested -at this stage-, in-1l1an-a:ge~
ment of project teams-particularly, of application-systems development teams.

area to apply their techniques and systems in the workshop domain.
In training new and developing users in the use of the
system, we have begun using the system itself as a teaching environment. This is done locally and with remote
users over the ARPANET.

Software engineering augmentation
A major special application area described above, that
has had considerable effort devoted to it, is support of
software engineers. The software-based tools of the workshop are designed and built using the tools previously
constructed. It has long been felt 24 .29 that the greatest
"bootstrapping" leverage would be obtained by intensively developing the augmented workshop for software
engineers; --and--we--ho-pe---to--stimul-at-e and- -sup-port--more--activity in this area.

Knowledge workshop analysis
Handbook development
Capabilities described above are being extended toward
the coordinated handling of a very large and complex
body of documentation and its associated external references. The goal is that a project or discipline of everincreasing size and complexity can be provided with a
service that enables the users to keep a single, coordinated "superdocument" in their computer; that keeps up
to date and records the state of their affairs; and provides
a description of the state of the art in their special area.
Example contents would be glossaries, basic concept
structure, special analytic techniques, design principles,
actual design, and implementation records of all developments.

Research intelligence
The provisions within the Dialogue Support System for
cataloging and indexing internally generated items also
support the management for externally generated items,
bibliographies, contact reports, clippings, notes, etc. Here
the goal is to give a human organization (distributed or
local) an ever greater capability for integrating the many
input data concerning its external environment; processing (filtering, transforming, integrating, etc.) the data so
that it can be handled on a par with internally generated
information in the organization's establishing of plans
and goals; and adapting to external opportunities or
dangers.3s

Computer-based instruction
This is an important area to facilitate increasing the
skills of knowledge workers. ARC has as yet performed
little direct work in this area. We hope in the future to
work closely with those in the computer-based instruction

Systematic analysis has begun of the workshop environment at internal system levels, at user usage levels,
and at information-handling procedure and methodology
levels. The development of new analytic methodology and
tools is a part of this process. The analysis of application
systems, and especially of core-workshop systems, is a
very important capability to be developed. To provide a
special workshop subsystem that augments this sort of
analytic work is a natural strategic goal.
CONCLUSION-THE NEED FOR LONG-TERM
COMMITMENT
As work progresses day-to-day toward the long-term
goal of helping to make the truly augmented knowledge
workshop, and as communities of workshop users become
a reality, we at ARC frequently reflect on the magnitude
of the endeavor and its long-term nature. 22
Progress is made in steps, with hundreds of shortterm tasks directed to strategically selected subgoals,
together forming a vector toward our higher-level
goals.
To continue on the vector has required a strong commitment to the longer-range goals by the staff of ARC.
In addition, we see that many of the people and organizations we hope to enlist in cooperative efforts will need a
similar commitment if they are to effectively aid the
process.
One of ARC's tasks is to make the long-term objectives of the workshop's evolutionary deveiopment, the
potential value of such a system, and the strategy for
realizing that value clear enough to the collaborators
we seek, so that they will have a strong commitment
to invest resources with understanding and patience.

National Computer Conference, 1973

One key for meeting this need will be to involve them
in serious use of the workshop as it develops. The
plans for the Workshop Utility are partly motivated
by this objective.
Although the present ARC workshop is far from
complete, it does have core capabilities that we feel
will greatly aid the next communities of users in their
perception of the value of the improved workshops of
the future.
ACKNOWLEDGMENTS
During the 10 year life of ARC many people have contributed to the development of the workshop described
here. There are presently some 35 people-clerical, hardware, software, information specialists, operations researchers, writers, and others-all contributing significantly toward the goals described here.
The work reported here is currently supported primarily by the Advanced Research Projects Agency of the
Department of Defense, and also by the Rome Air Development Center of the Air Force and by the Office of
Naval Research.
REFERENCES
1. Bush, V., "As We May Think," Atlantic Monthly, pp. 101-108,
July 1945 (SRI-ARC Catalog Item 3973).
2. Licklider, J. C. R., "Man-Computer Symbiosis," IEEE Tmnsactions on Human Factors in Electronics, Vol. HFE-1, pp. 4-11,
March, 1960 (SRI-ARC Catalog Item 6342).
3. Drucker, P. F., The Effective Executive, Harper and Row, New
York, 1967 (SRI-ARC Catalog Item 3074).
4. Drucker, P. F., The Age of Discontinuity-Guidelines to our
Changing Society, Harper and Row, New York, 1968 (SRI-ARC
Catalog Item 4247).
5. Dalkey, N., The Delphi Method-An Experimental Study of
Group Opinion, Rand Corporation Memorandum RM-5888-PR,
1969 (SRI-ARC Catalog Item 3896).
6. Allen, T. J., Piepmeier, J. M., Cooney, S., "Technology Transfer to
Developing Countries-The International Technological Gatekeeper," Proceedings of the ASIS, Vol. 7, pp. 205-210, 1970 (SRIARC Catalog Item 13959).
7. Roberts, L. G., Wessler, B. D., "Computer Network Development
to Achieve Resource Sharing," AFIPS Proceedings, Spring Joint
Computer Conference, Vol. 36, pp. 543-549, 1970 (SRI-ARC Catalog Item 4564).
8. Roberts, L. G., Wessler, B. D., The ARPA Network, Advanced
Research Projects Agency, Information Processing Techniques,
Washington, D.C. May 1971 (SRI-ARC Catalog Item 7750).
9. Bobrow, D. G., Burchfiel, J. D., Murphy, D. L., Tomlinson, R. S.,
"TENEX-A Paged Time Sharing System for the PDP-10," presented at ACM Symposium on Operating Systems Principles,
October 18-20, 1971. Bolt Beranek and Newman Inc., August 15,
1971 (SRI-ARC Catalog Item 7736).
10. Weinberg, G. M., The Psychology of Computer Programming, Van
Nostrand Reinhold Company, New York, 1971 (SRI-ARC Catalog
Item 9036).
11. Hall, T. W., "Implementation of an Interactive Conference System," AFIPS Proceedings, Spring Joint Computer Conference, Vol.
38, pp. 217-229,1971 (SRI-ARC Catalog Item 13962).
12. Turoff, M., "Delphi and its Potential Impact on Information Systems," AFIPS Proceedings, Fall Joint Computer Conference. Vol.
39. pp. 317-~2n. Jfl71 (SRI-ARC' CAtalog Ttpm ,flnnl

13. Roberts, L. G., Extensions of Packet Communication Technology
to a Hand Held Personal Terminal, Advanced Research Projects
Agency, Information Processing Techniques, January 24, 1972
(SRI-ARC Catalog Item 9120).
14. Kahn, R. E., "Resource-Sharing Computer Communication Networks," Proceedings of the IEEE, Vol. 147, pp. 147, September
1972 (SRI-ARC Catalog Item 13958).
15. Anderson, R. E., Coover, E. R., "Wrapping Up the Package-Critical Thoughts on Applications Software for Social Data Analysis,"
Computers and Humanities, Vol. 7, No.2, pp. 81-95, November
1972 (SRI-ARC Catalog Item 13956).
16. Lipinski, A. J., Lipinski, H. M., Randolph, R. H., "Computer
Assisted Expert Interrogation-A Report on Current Methods
Development," Proceedings of First International Conference on
Computer Communication, Winkler, Stanley (ed), October 24-26,
1972, Washington, D.C., pp. 147-154 (SRI-ARC Catalog Item
11980).
17. Turoff, M., "'Party-Line' and 'Discussion' Computerized Conference Systems," Proceedings of First International Conference on
Computer Communication, Winkler, Stanley (ed), October 24-26,
1972, Washington, D. C., pp. 161-171, (SRI-ARC Catalog Item
11983).

BY OTHER PEOPLE, WITH SUBSTANTIVE
DESCRIPTION OF ARC DEVELOPMENTS

18. Licklider, J. C. R., Taylor, R. W., Herbert, E., "The Computer as a
Communication Device," International Science and Technology,
No. 76, pp. 21-31, April 1968 (SRI-ARC Catalog Item 3888).
19. Engelbart, D. C., "Augmenting your Intellect," (Interview with D.
C. Engelbart), Research/Development, pp. 22-27, August 1968
(SRI-ARC Catalog Item 9698).
20. Haavind, R., "Man-Computer 'Partnerships' Explored," Electronic Design, Vol. 17, No.3, pp. 25-32, February 1, 1969 (SRIARC Catalog Item 13961).
21. Field, R. K., "Here Comes the Tuned-In, Wired-Up, Plugged-In,
Hyperarticulate Speed-of-Light Society-An Electronics Special
Report: No More Pencils, No More Books-Write and Read Electronically," Electronics, pp. 73-104, November 24, 1969 (SRI-ARC
Catalog Item 9705).
22. Lindgren, N., "Toward the Decentralized Intellectural Workshop,"
Innovation, No. 24, pp. 50-60, September 1971 (SRI-ARC Catalog
Item 10480).

OPEN-LITERATURE ITEMS BY ARC STAFF
23. Engelbart, D. C., "Special Considerations of the Individual as a
User, Generator, and Retriever of Information," American Documentation, Vol. 12, No.2, pp. 121-125, April 1961 (SRI-ARC Catalog Item 585).
24. Engelbart, D. C., "A Conceptual Framework for the Augmentation
of Man's Intellect," Vistas in Information Handling, Howerton and
Weeks (eds), Spartan Books, Washington, D.C., 1963, pp. 1-29
(SRI-ARC Catalog Item 9375).
25. English, W. K., Engelbart, D. C., Berman, M. A., "Display-Selection Techniques for Text Manipulation," IEEE Tmnsactions on
Human Factors in Electronics, Vol. HFE-8, No.1, pp. 5-15, March
1967 (SRI-ARC Catalog Item 9694).
26. Engelbart, D. C., English, W. K., "A Research Center for Augmenting Human Intellect," AFIPS Proceedings, Fall Joint Computer Conference, Vol. 33, pp. 395-410, 1968 (SRI-ARC Catalog
Item 3954).
27. Engelbart, D. C., "Intellectual Implications of Multi-Acces!'
Computer Networks," paper presented at Interdisciplinary Conference on Multi-Access Computer Networks, Austin, Texa~, April
Hl':'(), prf'print (SRI ARC .JQurllJI FilcS~Sjl.

The Augmented Knowledge Workshop

28. Engelbart, D. C., Coordinated Information Services for a Discipline- or Mission-Oriented Community, Stanford Research Institute Augmentation Research Center, December 12, 1972 (SRIARC Journal File 12445). Also published in "Time SharingPast, Present and Future," Proceedings of the Second Annual Computer Communications Conference at California State University,
San Jose, California, January 24-25, 1973, pp. 2.1-2.4, 1973.
Catalog Item 5139).

RELEVANT ARC REPORTS
29. Engelbart, D. C., Augmenting Human Intellect-A Conceptual
Framework, Stanford Research Institute Augmentation Research
Center, AFOSR-3223, AD-289 565, October 1962 (SRI-ARC Catalog Item 3906).
30. Engelbart, D. C., Huddart, B., Research on Computer-Augmented
Information Management (Final Report), Stanford Research Institute Augmentation Research Center, ESD-TDR-65-168, AD 622
5Z0,-Marili1905\SRr~ARCCatalog Item 9(90).
31. Engelbart, D. C., Augmenting Human Intellect-Experiments,
Concepts, and Possibilities-Summary Report, Stanford Research
Institute Augmentation Research Center, March 1965 (SRI -ARC
Catalog Item 9691).
32. English, W. K, Engelbart, D. C., Huddart, B., Computer Aided
Display Control-Final Report, Stanford Research Institute
Augmentation Research Center, July 1965 (SRI-ARC Catalog Item
9692).
33. Engelbart, D. C., English, W. K, Rulifson, J. F., Development of a
Multidisplay, Time-Shared Computer Facility and ComputerAugmented Management-System Research, Stanford Research
Institute Augmentation Research Center, AD 843 577, April 1968
(SRI-ARC Catalog Item 9697).
34. Engelbart, D. C., Human Intellect Augmentation TechniquesFinal Report, Stanford Research Institute Augmentation Research

Center, CR-1270 N69-16140, July 1968 (SRI-ARC Catalog Item
3562).
35. Engelbart, D. C., English, W. K, Evans, D. C., Study for the

Development of Computer A.ugmented ,Management TechniquesInterim Technical Report, Stanford Research Institute Augmentation Research Center, RADC-TR-69-98, AD 855 579, March 8,
1969 (SRI-ARC Catalog Item 9703).
36. Engelbart, D. C., SRI-ARC Staff, Computer-Augmented Manage-

ment-System Research and Development of Augmentation Facility
-Final Report, Stanford Research Institute Augmentation
Research Center, RADC-TR-70-82, April 1970 (SRI-ARC
Catalog Item 5139).
38. Engelbart, D. C., Experimental Development of a Small ComputerAugmented Information System-Annual Report, Stanford Research Institute Augmentation Research Center, April 1972
(SRI-ARC Catalog Item 10045).

39. Online Team Environment-Network Information Center and
Computer Augmented Team Interaction, Stanford Research Institute Augmentation Research Center, RADC-TR-72-232, June 8,
1-972 {SRI-ARC Jo-urnal:File 13041).

RELEVANT ARTICLES IN ARC/NIC JOURNAL
40. Engelbart, D. C., SRI-ARC Summary for IPT Contractor Meeting,
San Diego, January 8-10, 1973, Stanford Research Institute Augmentation Research Center, January 7, 1973 (SRI-ARC Journal
File 13537).

MOVIE AVAILABLE FROM ARC FOR LOAN
41. Augmentation of the Human Intellect-A Film of the SRI-ARC
Presentation at the 1969 ASIS Conference, San Francisco (A 3Reel Movie, Stanford Research Institute Augmentation Research
Center, October 1969 (SRI-ARC Catalog Item 9733).

Graphics, problem solving and virtual systems
byR.M.DCNN

u.s. Army Electronics Command
Fort Monmouth, :\ew Jersey
system so that he has a "feel" for its characteristics in
terms of personal judgments that may be quite subjective.
interactive computing mechanisms in problem solving
situations should extend and amplify man's basic abilities
for creative thinking and discovery. These mechanisms
should improve his ability to perceive previously unrecognized characteristics. They should permit and support
man's definition of new and meaningful symbols by
which he designates his perceptions. They should aid in
making any specification of values he chooses to assign to
his symbolized perceptions. And, interactive computing
mechanisms should aid in specifying and retaining any
combination of evaluated, symbolized perceptions. Of
particular interest are the combinations that man's creative faculty perceives as being related so as to form a
higher order entity.

IKTRODUCTION
Man naturally uses many languages when he thinks creatively. Interactive compli6ti!~( mec-naffisrtfs Infefiaea to
augment man's higher faculties must provide for appropriate man-machine dialogues. The mechanisms must not
constrain man's linguistic expressiveness for communication in the dialogues. To do so is to limit or retard the
creative activity.
This paper explores some basic concepts for problem
solving through interactive computing. Characteristics of
the interactive access process and over-all system concepts are discussed. The evolution of a recognition automaton is proposed based on current work toward a multiconsole, interactive graphics Design Terminal.
BASIC CONCEPTS
Certain notions about problem solving, virtual systems,
use-directed specification and interactive graphics are
central to the concluding proposal of this discussion.
These notions do not all reflect the current state-of-theart or even that of the very near future. However, they do
characterize the objectives and capabilities that should be
the goals of interactive computing mechanism research
development and use.

Virtual systems
A virtual system is considered to be an organized,
temporary collection of resources that is created for a
specific transient purpose.
Computer-based virtual systems combine processes,
processors, data storage mechanisms. Interactive, computer-based virtual systems are considered to include
people as another type of resource. The specific purposes
that generate virtual systems are considered to be functionally classifiable. As a result, one can associate a specific purpose with a type of virtual system in terms of the
function of the virtual system, or the process that carried
out its formation, or the structure of its physical or functional organization or any combination of these attributes.
The resources that are available for use in a computerbased virtual system may be centralized or widely distributed. Today's trend points to the general case for the
future as being distributed resources interconnected by
communications networks. Network-oriented, computerbased virtual systems are extensible by the simple expedient of interconnecting more and/ or different resources.
The problems associated with the design and control of
extensible distributed computing systems were investigated as early as 1965 by Cave and Dunn,2 and since then
by many others.3.4.5.6.7.s.9.1o

Problem solving
"Problem solving" is considered to be a process that
involves creative thinking and discovery. Problem solving
in a computer-based system is considered to be the activity of a human exploring a concept or system for which a
computer-based description has been or is being devised.
The human tries to perceive, alter and/ or assess the
description, behavior, performance or other quality of the
concept or system. Very often the system or concept has
time-dependent characteristics which add to its complexity.
The essence of the problem solving process is variation
and observation of the system under study. Alexander!
pointed out that human cognition functions to discover
and identify the "misfit variable" that is the cause of the
problem. To do so, the human needs to "toy" with the

National Computer Conference, 1973

For problem solving processes that incorporate interactive computing mechanisms, a particular type of computer-based, network-oriented virtual system is of specific interest. This system type exhibits two hierarchical
characteristics. First, it allows and supports a hierarchy
of functional uses to which it may be put. And second, it
also embodies the capacity to interconnect and support
access to resources on a hierarchical basis.

Use-directed specification
Use-directed specification is considered to be a process
within a time-ordered activity. The subjects and history
of activity determine the semantics and pragmatics of the
specification. l l In this context, semantics is taken to be
the process of identifying relations between elements of a
specification and the intents that are to be signified by
those elements. Pragmatics is taken to be the process of
identifying the extent and manner by which the signified
intents can be of value to the time-ordered activity. For
activities that are not deterministic, the semantic and
pragmatic processes establish the operational context and
effect of use-directed specifications on a probablistic
basis.
Use-directed specification presumes an identified system of pragmatic values based upon the goals of the activity. For many time-ordered activities, the goals are
unclear. Therefore, the associated system of pragmatic
values are poorly defined or may not exist at all at the
start of the activity. Such activities require rules of
thumb, strategies, methods or tricks that are used as
guides until the goals and pragmatic value !'y!'tem are
established. This heuristic 12 approach requires a feedback
mechanism as part of the means by which the activity is
conducted. Feedback is used to provide information
which may lead to adjustments in the heuristics and clarification of the activity's goals and pragmatic value system.
Adaptive, use-directed specification will be used to
characterize activities that operate in the manner just
described. Adaptive, use-directed specifications are of
particular interest for problem solving activities that
incorporate interactive mechanisms in the environment of
network-oriented, computer-based virtual systems with
hierarchical characteristics.

I nteractiue graphics
Interactive graphics is considered to be a computerbased process with the human "in-the-Ioop." "Interactive" describes the relation between the human and the
computer-based process. The interactive relation is characterized by a rate of response to human service requests
that is both useful and satisfying to the human. If the rate
is too fast, the substance of the response may not be useful to the human. If the rate is too slow, the human may
not he sMisfierl. Dunn. \3 Boehm, et 81.. 14 ;:mrl many

others have explored detailed characteristics of interaction in a graphics environment.
Interactive graphics is considered to have three principal purposes.1 5 One purpose is to improve the quality and
rate of the input/ output relation between people and
machines. Another purpose is to provide assistance to
people during detailed specification of some particular
abstract representation. The remaining purpose is to
provide assistance to people in visualizing and evaluating
some attribute, behavior or performance of a specified
abstract representation.
All three purposes, but especially the latter two, are of
particular interest for problem solving activities that
incorporate interactive computing mechanisms.
VIRTUAL SYSTEM ACCESS AND INTERACTIVE
GRAPHICS
Most interactive computing systems contain an inherent assumption about certain knowledge required of the
users. In some systems, the assumption is open and
stated. In others, a less obvious, more troublesome situation may exist. Users of interactive computing systems
rarely can consider the system as a "black box" into
which parameter identification and values are entered
and from which problem solving results are received.
Most often the user is minimally required to explicitly
know: the "black box" function to be used; the identification of the shared main computer that supports the
"black box" function; the way in which the function must
be requested; the way in which service on the supporting
computer must be requested; and the type of information
that must be provided to the function and the supporting
computer. Some interactive systems require even more of
the user.
The user of most of today's interactive systems can
reasonably be required to have knowledge of the kind
referred to above. However, when one considers the types
of interactive systems that are likely to exist tomorrow,
these requirements are not merely unreasonable, they
may be impossible to be satisfied by typical users.
Consider the use of interactive computing mechanisms
by problem solving activities via an extensible, networkoriented, distributed resource computing system. Over
time, such a system will undergo significant changes in the
number, type and pattern of dispersion of resources that
are inter-connected. For an individual user, as his efforts
progress or change, the combinations of resources appropriate to his purposes will also change. Any economic
implementation of such a system will not be free of periods or instances when "busy signals" are encountered in
response to requests for service. Therefore, it is likely that
most resources will have some level of redundancy in the
system.
The following conclusion must be drawn. If the human
user of interactive computing systems must continue to
satisfy today's requirements in the environment of tomorrow's svstemf-;, then the enormous potential of these svs-

Graphics, Problem Solving and Virtual Systems

tems will be lost to the user. It appears that this conclusion can be obviated. If one analyzes interactive access
characteristics along with system functions and relations
in a certain way, it appears feasible to reduce the burden
of system knowledge upon the user to a manageable level
in the environment of sophisticated interactive networks
of the future.
Interactive access performance characteristics
The basic motivation for interactive access is to allow
people to function as on-line controllers and participants
in the computing process. Consequently, we must consider characteristics of interactive access mechanisms
from the view of both human and system performance.
Further, if we consider performance characteristics in the
context of a complex process such as "problem solving"
then, in a very loose sense, we have taken a "worst· case"
approach.
The first thing to consider is that interaction is carried
on by means of a dialogue. This implies the existence of a
language known to both parties. The question is-what
should be the scope of reference of this language? Should
it be the mechanisms of computing? Or the functioning of
the interactive device? Or the topics which give rise to the
body of information pertinent to the problem to be solved?
Ideally, one should not need to be concerned with
computing mechanisms or interactive devices, but only
with information relevant to the problem. Practically, one
may want or need at least initial and, perhaps, refresher
information on mechanisms and devices. One can then
conclude that the principal concern of the language
should be the topics which relate to the problem. The
discourse should permit tutorial modes or inquiry dialogues on other issues only at the specific request of the
user. Raphael's16 work and that of others have established a solid foundation for the inquiry capability.
But, what of the problem solving topics? Should a separate language exist for each one? Could that be feasible as
the domain of interactive problem solving expands?
Clearly, it is not even feasible with today's primitive use.
Tomorrow's uses will make this matter worse. It may be
equally unreasonable to expect that machine systems can
be provided with a human's linguistic faculty for some
time. However, there are at least two feasible approximations.
The first is exemplified by MATHLAB.17 In this effort, the machine is being programmed with the rules of
analytical mathematics. Then the user interactively
writes a mathematical equation on a machine sensible
surface, the equation is solved analytically by the machine and the graph of the solution is displayed on an interactive graphics device. The process also requires
that the machine is programmed to recognize handwritten entries. It does this task imperfectly and has to
be corrected through re-entry of the symbols. The sensible input surface and the visible output surface together form the interactive mechanism of feedback until
man and machine have reached agreement. A related

example is the "turtle" language of Papert'slS Mathland.
This first type of approximation provides a linguistic
mechanism for a broad topic of discourse and in addition,
provides an interactive feedback mechanism that allows
man and machine to work out misunderstandings in the
dialogue.
The second approximation is exemplified by the work
of Pendergraft. lu9 In this effort, the main concern
became the evolution of computer-based, linguistic systems of a certain kind-a semiotic system. These systems
are based on semiotics, the science of linguistic and other
signs and how they are used (first identified by Charles
Sanders Pierce and later elaborated upon by Morris 21).
"A semoitic system can be precisely specified as a system of acts rather than of things. Such a specification
describes what the system does, not what it is in a physical sense. The specification of acts consists of two basic
parts:
"(a) Potential acts. Individually, these may be thought
of as mechanical analogues of habits. Collectively, they
constitute a body of knowledge delimiting what the system can do, what is within its competence.
"(b) Actual acts. These are individually the analogues
of behaviors realizing the potential acts or habits. They
relate to one another within a single taxonomic structure
that centers on a history of the success or failure of elementary senso-motor behaviors, or inferred projections of
that history. Together and in their relations, these actual
acts constitute a pattern of experience delimiting what the
system observes in the present, remembers of the past, or
anticipates for the future.
"Among the potential acts, there must be certain acts
which determine how the current pattern of experience is
to be "deduced" from the current body of knowledge. The
very realization of habits as behaviors depends upon this
logical part of the specification. Deductive behaviors realizing these logical habits themselves, may appear in the
experimental pattern being constructed; usually the system will not be aware of its logical behaviors. 19
An automatic classification system was defined and
constructed 11 that provided the mechanism for the unifying taxonomic structure. It was demonstrated to be capable of assessing probability of class membership for an
occurrence. It also was demonstrated to be capable of
detecting the need and carrying out effort to reclassify the
data base upon the occurrence of a "misfit."
This second type of approximation provides a mechanism for man and machine to interactively teach each
other what is relevant in their dialogue. It also provides a
capability for both partners to learn useful lessons for the
problem solving activity based on their actual history of
success and failure. This latter point is particularly relevant for the situation when another user wishes to do
problem solving in an area in which the system has
already had some "experience."
In summary, the interactive access mechanisms for
problem solving ought to have the following performance

National Computer Conference, 1973

APPL I CAT I ON
FU,,"CT I or,

+-------------------~

HUMAN
INPUT
FUNCTION

HUMA\J
I r-iPUT
~UNCT

STORAGE
FUNCTION

I Or..;

GRAPHICS SYSTEM FUNCTIONS AND RELATIONS

sioned as having at least two distinct types of components. One component type contains information about
variables and their values. The other component type
contains information about the identity and parameters
of the function that is to utilize the variable data.
Considered this way, inter-function data are messages
between elements of the graphics system. They convey
service requests for specified functions. Message structured service requests of a limited kind for computer
graphics has been considered in the environment of distributed resource, network-oriented systems. 20
In order to successfully support interactive graphics
access in a network environment, careful distribution of
the graphics system functions must be accomplished
within the network facilities. And equally important, the
relationships between graphics system functions must be
preserved.

Figure 1

characteristics. The mechanisms should be oriented to
discourse on the subject of the problem. Recourse to subsidiary dialogues, e.g. tutorial inquiry, etc., at the request
of the human, should be provided to facilitate the operation of the mechanism by the user. The mechanisms
should bear the burden of trying to deduce the system
implications of a human's service request, rather than the
human needing to direct or set up the implementation of
service in response to the request. Use of the wide bandwidth channel provided by interactive graphics for manmachine communication at a rate comfortable to the
human is the concluding feature of this characterization.

DESIGN TERMINAL
One approach for network-oriented, interactive graphics is illustrated by a Design Terminal configuration 13
under development at the author's installation. Some
limited experience with it in conjunction with network
access has been gained. 22 The Design Terminal is basically a multi-console terminal with the ability to independently and concurrently interconnect graphics consoles, graphics functions and network-based application
and storage functions.

Objectives
Interactive graphics systems functions and relations
Figure 1 illustrates the relations that exist among the
five essential functions in any interactive graphics system. The human output function presents images in a
form compatible with human viewing and cognition. The
human input function mechanizes requests for attention and provides a means for entry of position, notation or
transition data that will affect the graphics and other
processes. The storage function retains images or their
coded abstractions for subsequent processing. The application function is the set of higher order, "black box"
processes that will utilize information inherent in images
as input data. Finally, the graphics function performs the
three types of sub-processes that are the heart of the
graphics process. One type of sub-process provides for
composition, construction or formation of images. The
second type of sub-process provides for manipulation or
transformation of images. The third type of sub-process
(attention handling) links the composition and/ or manipulation sub-processes to interaction, intervention or use
by higher order processes being performed either by the
application function or by the user. Notice that the rela-

tions between the graphics system functions are ones of
data flow within an overall system.
observe the following. -The data that flo\vs from one
function of the system to another can al.ways be envi\\TC

Two issues have motivated the development of the
Design Terminal. First, in certain types of installations,
there is considered to be a need to insure that interactive
facilities for problem solving and design specification are
functionally matched and economically operated with a
multi-source capability from hardware suppliers. This
issue involves concern for the relation between types of

MEDEA PROJECT
EXPERIMENTAL TEST BED
Fi~1)re

Graphics, Problem Solving and Virtual Systems

display mechanisms (e.g. refresh CRT's, DVST's, printer/
plotters, etc.), the types of graphics' use and the probability of occurrence and volume need for each type of use.
Second, for an installation that requires many intelligent
terminals, there is the concern for the total system implementation and support costs.
The solution that is being pursued is a little farther
around the "wheel of reincarnation"23 than other related
configurations. A general purpose mini-processor and a
special purpose display processor form the heart of a
terminal with remote access to many shared computers.
The general purpose mini-processor is being multi-programmed in a certain way to support concurrent, independent graphics activities emanating from the terminal.
The main thrust is to expand the number of concurrently
active graphics consoles at the terminal so as to achieve a
satisfactory distribution of the total cost of the terminal
over each concurrently active console. Figure 2 illustrates
the test bed on which this effort is being conducted.
The Design Terminal configuration is concerned with
providing an interactive graphics terminal with the following capabilities: (a) in its simplest form, it is a singleconsole intelligent terminal; (b) the local mini-processor
and special purpose processor facilities for providing the
graphics function are shared by many interactive graphics consoles; (c) the graphics consoles currently active
may employ widely different display mechanisms; (d) a
majority of all the connected consoles can be concurrently
active; (e) the current use of each active console can
involve display of different images than those being generated for all other active consoles at the terminal; (f) the
terminal can concurrently obtain support for the graphics
system application and storage functions from more than
one shared main computer system; and (g) the current
use of each active console can involve a different application on a different shared main computer than is involved
for all other active consoles at the terminal. The distribution of graphics system functions for the Design Terminal
configuration are illuustrated in Figure 3.

~--------------------------------------~
"~/- - - - - - - - - - - - -,
: Q----jJ i~Ur-.CTICNS
-

~-~- ---- - -7---i

DESIGN TERMINAL cm.JFIGURATION

Figure 3

C6~~~~E~'1ARED

Experience
Although the development of the Design Terminal is
still incomplete, our experience so far has provided
insight into the difficulties of problem solving on networkbased, virtual systems through interactive graphics.
The first point is not new. It is yet another confirmation of something well known to the computing profession
and industry. Most users of computing, particularly in an
interactive environment, cannot afford to be bogged down
in the mechanics of the computer system. They certainly
don't care about the subtle intricacies or enduring truths
and beauties of the system that turn on its builders and
masters. Therefore, the intricate knowledge about access
to and use of distributed resources must somehow be
built-in to the system.
The second point is also not completely unknown. The
telecommunications people have been considering alternatives for a long time. The efforts of Hambrock, et aJ.24
and Baron 25 are two of the most significant to our current
situation. In a large, dynamic and expanding network,
one cannot maintain deterministic directories of every
possible combination of resources and associated interconnection schemes that are being used or can be
expected to be used. The transmission facilities would be
jammed with up-date traffic and the resource processors
would be heavily burdened with directory maintenance.
For the user and the system builder, this point appears
to raise a paradox. The user doesn't want to and can't
manage to know everything about the network. And the
maintenance of directories within the network would
impose a severe utilization of scarce resources.
The approach of the ARPANET represents an interim
compromise for this problem, based upon Baran's work
on distributed communication systems. However, the user
is still required to know a great deal about the use of each
resource in the network even though the communications
problem is taken care of for him. For each resource of
interest; (a) he must know that the resource exists; (b) he
must know where within the net it is located; and (c) he
must know the usage procedure required by the processor
of that resource. He may be required to know much more.
For users of interactive mechanisms with extreme accessibility provided for by the Design Terminal type configuration, this approach to locating and specifying essential
resources is especially troublesome.
The conclusion we draw toward the problem we pose is
that the resource directory function cannot be built into
either the resource processors or the interconnection facilities of the network. We also conclude that attempts to
moderate search traffic loading in random techniques 24
and relieve switching bottlenecks can be successful 6 provided the search criteria and routing mechanism are carefully defined.
There is one more point to be considered. It is raised by
the cost of computer software development and the growing diversity of available computing resources. We cannot
afford and shall not be able to afford explicit re-design of
resource linkages each time a new, useful combination is

National Computer Conference, 1973

devised that provides additional higher level capability.
The interactive access mechanims to network-based virtual systems must provide or be able to call upon a generalized, dynamic linkin,g function. This function will link
together distributed resource modules it has determined
to be available and to form the appropriate basis for satisfying an interactive service request.
HIERARCHICAL ACCESS TO VIRTUAL
SYSTEMS VIA INTERACTIVE GRAPHICS
Cherry27 has observed "that recognition, interpreted as
response according to habits, depends upon the past experience from which an individual acquires his particular
habits." Although his interest was human communication, one should recall the earlier discussion on basic
concepts. In particular, consider Cherry's observation in
the context of adaptive, use-directed specification and the
extensions and amplification of man's basic abilities as a
result of problem solving through interactive computing
mechanisms. In this context, this observation provides a
significant suggestion toward possible answers to many
of the difficulties cited above.

Semiotic coupler function
In the linguistic environment, Pendergraft 11 characterized a self-regulating system with goal-directed behavior
in terms useful to our purpose. A hierarchy of processes
was described. The perception process tries to recognize
input data in terms of familiar attributes. The symbolization process assigns identifiers to the recognized data. The
valuation process associates the assigned symbols to processes that effect the response of the system to input data.
It does so in terms of the system's current knowledge of
pragmatic values that will satisfy its goal directed performance.
For problem solving through interactive graphics access
to distributed resource networks, the goal would be for the
system to correctly determine and cause the interconnection of a virtual system necessary to satisfy each interactive service request. Correctness would be a probablistic
measure that would improve with experience for a given
problem solving area.
The input data to the perception process would be the
image data and/ or symbol string that specifies the interactive service request. The output of the perception process would be the syntactic parsing of the service request
over the language of service requests. The perception
process also operates on a probablistic basis derived from
experience.
The input data to the symbolization process would be
the identification of processing functions that are
required to satisfy the service request. The output of the
symbolization process would be the identification of the
network's known distributed resources that must be
assembled into a virtual system to carry out the processing functions. Again, .the performance of the symboiiza-

tion process will improve as experience increases with
both the problem solving topic and the network resources.
In situations where processing functions are specified for
which network resources are unknown or unavailable, two
options exist. Either the symbolization process appro xi mates the function in terms of known resources or the
network is searched.
The input data to the valuation process would be the
identification of resource modules that will be called upon
to satisfy the service request. The output of the valuation
process would be the identification of the processing
sequence and data flow relationships that must exist
amongst the activated resource modules. This valuation
process is extremely dependent on experience for
improved performance in a given problem solving area.

Adaptive classifier function
Each of the preceding processes depends upon feedback
from experience to improve performance. Pendergraft
suggests that the processes applied to stimulus information should also be applied to response information. 11
For us, this suggests that the user should interactively
"grade" the system's performance. The system would then
apply the three preceding processes to the "grading"
information in order to adjust the probability assignments to the estimates of relationship and to the classification structure for service requests vs. processing functions. When "misfits" were identified and/ or when the
probabilities computed for relationships dropped below
some threshold, the classification structure would be
recomputed. Pendergraft and Dale28 originally demonstrated the feasibility of this approach in the linguistic
environment using a technique based on Needham'!=;29
theory of clumps.
As new resources are added to the network, the processing functions that they provide are entered into the classification structure with some initial (perhaps standard)
probability assignment for relations to all known types of
service requests. These probabilities are then revised
based upon the feedback from the user's grading of the
system's performance.

Use-directed specification function
The user is of pivotal importance toward specifying
service requests and generating performance grades for
the system. Yet, as was indicated earlier, he must be
capable of the actions without being required to have
elaborate knowledge of the system's internal content,
structure or mechanisms. It is in this area that interactive graphics plays a vital role in expediting the problem
solving dialogue between man and machine.
Consider the simple concept of a "menu," that is, a set
of alternatives displayed to the user for his selection. In a
complex problem solving area, the result of a user selection from one meHU cail lead It) the display of a :;uburdi

Graphics, Problem Solving and Virtual Systems

nate menu for further specification of the task to be performed. In effect, this process leads to a concept of the
dialogue as a selection process of the alternative paths in
trees of menus.
We claim that generalized sub-trees can be devised for
areas of problem solving methodology that can be parametrically instantiated to a given topic at run-time only
guided by previous menu selections during the current
session at the terminal. Furthermore, we claim that this
sub-tree concept can be devised so as to allow a given subtree to be invoked from a variety of parent nodes in the
specification process. Work on the Design Terminal
includes an effort to implement this concept.
The specification process cannot be fully accommodated by the mechanism of the parametric dialogue tree.
Procedures illustrated by the MATHLAB techniques, the
methods of Coons/o the Space Form 3l system and more
conventional interactive graphics layout, drafting, and
curve plotting techniques will all be required in addition to alphanumeric data entry in order to complete the
specification. The point is that the semantics of these
specifications, in terms of the problem solving processing functions that are required, will have been directed
by the current use of the dialogue mechanism.
One set of choices that is always displayed or selectable
represents the user's evaluation alternatives of the system's performance. Another optional set is one that places
the system in the role of a tutor, either for use of the system or for the use of a processing function to which the
system provides access.
Another set of options should also be callable. In this
case, the user may want to access a specific processing
function. He may not know its name or the location of the
resources in the distributed system that support it. If he
does have specific identification, he may use it. If he
lacks an identifier, the user will generally know of some
attribute of the process. Therefore, he should be able to
enter a search mode in which he can construct the search
criteria for the known attribute in whatever terms that
the system supports.
The set of use-directed specifications that are achieved
in the above manner form the set of interactive service
requests that are input to the semiotic coupler function.
The selection of evaluation alternatives forms the feedback input to the adaptive classifier function.

The Recognaton performs four principal functions.
Three of them have already been described: semiotic
coupling; adaptive classification; and use-directed specification. The fourth function generates messages into the
distributed resource network. It uses the output data of
the valuation process of the semiotic coupling function.
These messages request assignment and activation of
network resources according to the processing sequence
and inter-process data flow requirements that were determined from the current status of the pragmatic value
system. The messages are the immediate cause for the
formation of the virtual system.
The functions of the Recognaton represent a significant
computational load at a rather sophisticated level. It is
unlikely that the cost to implement this computation
could be afforded for a single interactive graphics console.
Therefore, we conclude that multiple inte-ractiv.e graphi-es
consoles must be serviced by a given Recognaton. Figure
4 illustrates an access node with the Recognaton functions
based on the configuration of the Design Terminal that
was discussed earlier.

SUMMARY
This discussion began with a concern for an interactive
mechanism to facilitate man-machine dialogues oriented
to man's creative thought processes. The intent was to
consider problem solving as a test-case, creative process
with practical implications. The activity of the mechanism was taken to be to serve as a means for specification
of and hierarchical access to virtual systems formed in a
distributed resource computing network. A recognition
automaton, the Recognaton, has been proposed which
appears to serve the purpose and does not impose system
level conflicts. Implementation of the Recognaton
appears feasible as an extension of the Design Terminal
multi-console, interactive graphics configuration.

~;:-~-------------------.......

'~'----

---

~WJ.----i!:!!i:l~,:i"
/

~ECOC;\:ITIO'\

A RECOGNITION AUTOMATON (RECOGNATON)
We suggest that distributed resource computing networks should contain nodes of at least two distinct types.
The first type is a service node at which the computing
resources of the network are connected. The second type
is the access node. It is to the access node that the user is
connected through his interactive graphics console.
"\Ve further suggest that the access node is the point in
the network which implements the functions necessary to
provide interactive hierarchical access to virtual systems
in the network. We call the implementation vehicle at the
access node a recognition automaton or Recognaton.

FU\CT I or-..

CY-----

/ GRAPb.ICS
FUNCT I 0\5

'ECvG'.A T0,\ CQ,\F I GURA T I or.

Figure 4

National Computer Conference, 1973

REFERENCES

1. Alexander, C., Notes on the Synthesis of Form, Harvard University
Press, 1964.
2. Cave, W. C., Dunn, R. M., Saturation Processing: An Optimized
Approach to a Modular Computing System, ECOM Technical
Report - 2636, US Army Electronics Command, November 1965.
3. Dunn, R M., Gallagher, J. C., Hadden, D. R, Jr. Distributed
Executh'e Control in a Class of Modular Multi-processor Computing Systems via a Priority Memory, ECOM Technical Report 2663, U.S. Army Electronics Command, January 1966.
4. Dunn, R M., Modular Organization for Nodes in an Adaptive,
Homeostatic Process-Oriented Communications System. ECOM
Technical Report - 2722, US Army Electronics Command, June
1966.
5. Dunn, R M., "Homeostatic Organizations for Adaptive Parallel
Processing Systems," Proceedings of the 1967 Army Numerical
Analysis Conference, ARO-D Report 67-3, pp. 99-110.
6. Dunn, R M., Threshold Functions as Decision Criteria in Saturation Signalling, ECOM Technical Report - 2961, US Army Electronics Command, April, 1968.
7. Roberts, L. G., Wessler, B. D., "Computing Network Development
to Achieve Resource Sharing," Proceedings of the Spring Joint
Cumputer Cunference, 1970, pp. 543.
8. Walden, D. C., "A System for Interprocess Communications in a
Resource Sharing Computer Network," Communications of the
ACM, Vol. 15, No.4. April 1972, pp. 221-230.
9. Mink, A., "A Possible Distributed Computing Network," Proceedings of the Computer Science Conference, Columbus, Ohio, February 1973.
10. Lay, M., Mills, D., Zelkowitz, M., "A Distributed Operating System for A Virtual Segment-Network," Proceedings of the AIAA
Conference, Huntsville, Alabama, April 1973.
11. Pendergraft, E. D., Linguistic Information Processing and
Dynamic Adaptive Data Base Management Studies, Final Report,
Linguistic Research Center/University of Texas. Austin, November 1968. chap. 3.
12. Slagle, J. R, Artificial Intelligence: The Heuristic Programming
Approach. McGraw Hill Book Company, 1971.
l2. D 1mn, R. M., "Computer G r apl,ic,,: Capabijitie". C()c;t" ::I wI U"efulness." Proceedings of SHARE XL, Denver. ~1arch 1973.

14. Boehm, B. W., Seven, M. J., Watson, R. A., "Interactive Problem
Solving - An Experimental Study of 'lock-out' Effects." Proceedings of &lCC, 1971, pp. 205-216.
15. Dunn, R M., "Interactive Graphics: Stand-Alone. Terminal. Or?,"
Proceedings of IEEE INTERCON, March 1973.
16. Raphael, B., SIR: A Computer Program for Semantic Information
Retrieval, Doctoral Dissertation, M.I.T., June 1964.
17. MATHLAB, Project MAC, M.I.T., Cambridge, Mass.
18. Papert, S., "The Computer as Supertoy," Spring Joint Computer
Conference, 1972.
19. Pendergraft, E. D., Specialization of a Semiotic Theory, ECOM
Technical Report - 0559-1, Contract No. DAAB07 -67 -C-0569,
TRACOR, INC., Austin, Texas, February 1968.
20. Cotton, I. Level 0 Graphic Input Protocol, ARPANET Network
Graphics Working Group, NIC #9929, May 1972.
21. Morris, C., Signs Language and Behavior, Prentice-Hall, Inc.,
1946.
22. Gray, B. H., "An Interactive Graphics Design Terminal Concept,
Implementation, and Application to Structural Analysis," Proceedings of Fourth Annual Pittsburgh Modeling and Simulation
Conference, April 1973.
23. Myer, T. H., Sutherland, I. E., "On the Design of Display Processors," Communications of ACM, Vol. 11, No.6, June 1968, pp.
410-414.
24. Hambrock, H., Svala, G. G., Prince, L. J., "Saturation Signaling Toward an Optimum Alternate Routing," 9th National Communication Symposium, Utica, N.Y., October 1963.
25. Baran, Paul, On Distributed Communications, Vols. I-X, Memorandum RM-3420-PR, the Rand Corporation, Santa Monica.
August, 1964.
26. Nehl, W., "Adaptive Routing in Military Communications Systems," Proceeding of the Military Electronics Conference, 1965.
27. Cherry, C., On Human Communications, (Sec. Ed), The M.I.T.
Press, 1966, pp. 275.
28. Pendergraft. E., Dale, N., Automatic Linguistic Classification,
Linguistics Research Center, University of Texas, Austin, 1965.
29. Needham, R., The Theory of Clumps II, Cambridge Language
Research Unit. Cambridge, England. 1961.
3Q. Coons, S. A.• Surfaces for Computer·Aided Design of Spaccfcims.
Project MAC Technical Report MAC-TR-41, M.I.T., Cambridge.
June. 1967.
~L Carr. S. C" Genm",t>"ic Mndeling. RADC Techniclll Hepnrt - TR.69-248. University of Utah. Salt Lake City. June 1969.

Performance determination-The selection
of tools, if any
by THOMAS E. BELL
The Rand Corporation
Santa Monica, California

listing conditioned data, generating tentative reports,
trying to employ them, and then revising the reports. The
following summaries indicate some of the important
analysis characteristics of simulation, accounting systems, and other available tools. Most of the technical
details are omitted because they are only marginally relevant to this discussion. * *

As interest in computer performance analysis has grown,
the dedication of some analysts to a single tool and analysis approach appears to have become stronger. In most
instances this affection probably comes from increased
familiarity and success with an approach combined with
a resulting lack of familiarity and success with other
approaches.
Other equally experienced analysts use a variety of
approaches and tools, and may give the appearance that
any tool can be used in any situation. Only a little experience is necessary, however, to conclude that personal
inspection, accounting data, hardware monitors, software
monitors, benchmarks, simulation models, and analytical
models are not equally cost effective for performing general operations control, generating hypotheses for performance improvement, testing performance improvement hypotheses, changing equipment, sizing future systems, and designing hardware and/ or software systems.
The analyst new to performance analysis may become
confused, discouraged, and, eventually disinterested in
the field as he attempts to start an effective effort. This
paper attempts to aid him by presenting an overview.
Tools are described; applications are listed; and important considerations are reviewed for selecting a tool for a
specific application.

Personal inspection
Personal inspection can imply an uninspired glance
at the machine room. This sort of activity often leads to
beliefs about an installation based more on preconceived
notions than on reality. This "tool" usually is employed
in an "analysis" involving occasional glances at a machine room when the observer sees precisely what he
expected to see (whether it's true or not, and often even in
the face of significant, contrary evidence). Since the
observer may only glance at the machine room for a few
minutes two or three times per day, his sample of the
day's operation is very incomplete. This type of performance analysis, although common, is without redeeming
social value, and will not be considered further. Other
types of personal inspection are more valuable for performance analysis.
Each time a piece of unit record equipment processes a
record, it emits a sound. The performance analyst can use
this sound to roughly estimate activity and judge the
occurrence of certain system-wide problems. For example, a multiprogrammed system may be experiencing
severe disk contention in attempting to print spooled
records. Quite often, this problem manifests itself in
strongly synchronized printing from the several printers
on a large system. As the disk head moves from track to
track, first one then another printer operates. When one
printer completes output for its job, the other printer(s)
begins operating at a sharply increased rate.

ALTERNATIVE TOOLS AND APPROACHES
An analyst's approach to analyzing a system's performance can, to a large extent, be described by the tools he
uses. For example, an analyst using simulation as his tool
performs an analysis based on abstracting important
characteristics, representing them correctly in a simulation, checking the results of his abstractions, and performing simulation experiments. * If he were analyzing
accounting data, his procedure would probably involve

** See References 2 and 3 for some details. Further material can be
found in References 4-7. A review of monitors available in 1970 appears in Reference 8.

* More complete procedural suggestions for pursuing a simulation
analysis can be found in Reference 1.

National Computer Conference, 1973

Multiple, rapidly spinning tapes and extremely active
disk heads can, in some environments, indicate severe
trouble. In other environments (where loads should be
causing this kind of behavior), they may indicate a
smoothly running system. Unfortunately, most installations fall somewhere between these two extremes, leaving
analysts-and managers-with an amorphous feeling of
unease.
The clues from personal inspection can be valuable, but
an experienced eye, accompanied with an equally experienced ear, is often necessary to make sense from the raw
environment. Fortunately, alternatives are available.

Accounting systems
Accounting systems aggregate computer usage by task,
job, or other unit of user-directed work. The primary
objective of the accounting system's designer is cost allocation, which sometimes compromises the usefulness of
accounting system data, particularly where overhead is
involved.*
Although accounting data can be deceptive, analysts
can determine the actual data collection methods used
and perform analyses based on a good understanding of
potential errors.** Accounting data also have some distinct advantages for analyses. They are usually quite
complete because they are retained for historical purposes, and changes in collection methods are well documented so that users can examine them for correctness.
The data are collected about the system's work and organized in precisely the correct way to facilitate workload control-by requests for computer work (by job). In
addition to serving as input for reports about computer
component usage, accounting data (sometimes combined with operations logs) can be used to determine the
use to which this activity was devoted. For example, a
user would seldom be using a simulation language if he
were involved in writing and running payroll programs,
and simulation execution could, prima facie, be considered of negligible value to the organization in this
circumstance.
For most analysts, accounting data have the advantage of immediate availability, so analysis can begin
without delays for acquisition of a tool. However, immediate data availability does not necessarily imply immediate usability. Accounting systems are commonly very
extensive, so analysts are often overwhelmed with the
quantity of items collected and the number of incidences of each item. All these data are usually placed in
poorly formatted records on a file along with irrelevant
or redundant data. The data conditioning problem may
therefore be a major hurdle for successful analysis.
Inadequate documentation of the details of data collec* Determining system overhead is not trivial, and one of the least trivial problems is defining precisely what the term means. The appendix
suggests some of its constituents.
** See Reference 9 for some useful techniques to employ a.ccounting
rlHtIl.

tion by manufacturers and inadequacies in the data collection (leading to variability in addition to significant
bias) can confuse any analysis results unless the analyst
is very careful.

Monitors
Performance monitors (whether implemented in hardware or software) are designed to produce data revealing
the achieved performance of the system. These tools
produce data, not understanding, so the analyst does not
buy his way out of the need for thoughtful analysis when
he purchases one.
A hardware monitor obtains signals from a computer
system under study through high-impedance probes
attached directly to the computer's circuitry. The signals
can usually be passed through logic patchboards to do
logical ANDs, ORs, and so on, enabling the analyst to
obtain signals when certain arbitrary, complex relationships exist. The signals are then fed to counters or timers.
For example, an analyst with a hardware monitor could
determine (1) the portion of CPt} time spent performing
supervisory functions while only one channel is active, or
(2) the number of times a channel becomes active during
a certain period. Because hardware monitors can sense
nearly any binary signal (within reason), they can be
used with a variety of operating systems, and ~ven with
machines built by different manufacturers. This capability to monitor any type of computer is usually not a critically important characteristic, because the analyst is
usually concerned with only one family of computers.
Some hardware monitors are discussed in References 2-5
and 10-14.
The hardware monitor's primary disadvantage for
analysis is its great flexibility. Analysts with extensive
experience have learned the most important performance
possibilities to investigate, but even the notes distributed
by vendors of these monitors often prove inadequate for
aiding the novice. Cases of wasted monitoring sessions
and of monitors sitting in back rooms are seldom documented, but their validity is unquestionable. In some
cases even hardware monitor vendors, while attempting to
introduce clients to their monitors, have held a session on
an unfamiliar machine and failed miserably. (In most
cases, they have proved how valuable it is to have their
expertise on hand to aid in performing a complex analysis
with a minimum of fuss and bother.)
Software monitors consist of code residing in the
memory of the computer being monitored. This means
that they can have access to the tables that operating
systems maintain, and thereby collect data that are more
familiar to the typical performance analyst. Since he
usually was a programmer before he became an analyst,
descriptions of data collection are often more meaningful
to him than the descriptions of hardware monitor data
collection points. In addition, most software monitors are
designed to produce specific reports that the designers
found to be particularly meaningful for the hardware!
snft-wRrp ('omhinntinn hping monitorprl This recu('Ps thi"

Performance Determination

difficulty of analysis, particularly where the design of
application jobs is under consideration. Hardware monitors, in systems where a program may reside in a variety
of places, do not typically produce reports on individual
problem performance that can be easily interpreted, but
software monitors typically can. For more material on
some software monitors see References 2, 3, 7, and 16-20.
The answer to every analyst's problem is not a software
monitor. Software monitors require a non-negligible
amount of memory, often both central memory and rotating memory. In addition, some amount of I/O and CPU
resources are necessary for operating the monitor. This all
amounts to a degradation in system performance, and at
the precise time when people are concerned with performance. As a result, the analyst needs to choose carefully
how much data he will collect and over how long a period.
This necessity adds to the analyst's problems~ and is
usually resolved in favor of short runs. This, in turn,
leads to data of questionable representativeness. Since
computer system loads usually change radically from
hour to hour, the analyst may be led to conclude that one
of his changes has resulted in significant changes in performance, when the change actually resulted from different loads over the short periods of monitoring.
The choice between hardware and software monitors
(and between the subtypes of monitors in each groupsampling vs full time monitoring, separable vs integrated,
recording vs concurrent data reduction, and so on) is
largely dependent on situation-specific characteristics.
Application in the specific situation usually involves
monitoring the normal environment of the existing computer. An alternative exists: a controlled, or semi-controlled, environment can be created. This analysis
approach is closely related to the use of batch benchmarks and artificial stimulation.

Benchmarks
A batch benchmark consists of a job, or series of jobs,
that are run to establish a "benchmark" of the system
performance. The benchmark run is usually assumed to
be typical of the normal environment but to have the
advantage of requiring a short time for execution. The
most common use of benchmarks is for equipment selection, but analysts often use benchmarks for determining
whether a change to their systems has improved the performance of the benchmark job stream. The conclusion
about this performance (usually measured primarily by
the elapsed time for execution) is then assumed to be
directly related to the normal environment; an improvement of 20 percent in the benchmark's performance is
assumed to presage an improvement of 20 percent in the
real job stream's performance. Benchmark work is
described in References 21 and 22.
For an on-line system this technique would not be
applicable because on-line jobs exist as loads on terminals
rather than as code submitted by programmers. The
analog to the benchmark job in a batch system is artifi-

cial stimulation in the on-line environment. Through
either hardware or software techniques, the computer
system is made to respond to pseudo-inputs and the
response is measured. A stimulator, implemented in software, is described in Reference 23.
The obvious difficulty in using batch or on-line benchmarking is relating the results to the real job stream. The
temptation is to assume that jobs presented by users are
"typical" and that the results will therefore be applicable
to reality, or that the on-line work described by the users
is actually what they do. Neither assumption is generally
true.
Running benchmarks or artificially stimulating a system implies some kind of measurement during a period of
disrupting the system's operation; then the results must
be related to reality. Performance modeling has the same
difficulty in relating its results to reality, but it does not
disrupt the system's operation.

Performance modeling
Simulation modeling of computer system performance
has seemed an attractive technique to analysts for years,
and it has been used in response to this feeling. An analyst may design his own simulation using one of the general or special purpose languages, or employ one of the
packaged simulators on the market. * In either case, he
can investigate a variety of alternative system configurations without disrupting the real system, and then examine the results of the simulated operation in great
detail. Virtually all such simulations model the operation of the system through time, so time-related interactions can be thoroughly investigated. Some simulation
experiences are described in References 29-35. Problems and objectives in simulating computers are described in Reference 36.
Analytical models are usually steady-state oriented,
and therefore preclude time-related analysis. However,
they usually do provide mean and variance statistics for
analyses, so those analyses requiring steady-state solutions (e.g., most equipment selections) could employ the
results of analytical modeling. Simulations, on the other
hand, must be run for extensive periods to determine the
same statistics, and analysts need to worry about problems like the degree to which an answer depends on a
stream of random numbers. Examples of analytical
modeling are given in References 37 -42.
The problem that often proves overwhelming in using
either type of modeling is ensuring that the model (the
abstraction from reality) includes the most important
performance-determining characteristics and interactions
of the real system. Without this assurance, the model is
usually without value. Unfortunately for the analyst,
indication that a particular model was correct for another
installation is no real assurance that it is correct for his
installation. Unique performance determinants are
* For information about such languages and packages see References
24-2R.

National Computer Conference, 1973

usually found in operating system options, configuration
details, and workload characteristics. Therefore, a validation exercise of a simulative or analytical model is usually
a necessity if specific values of output parameters are to
be used in an analysis.
APPLICATIONS
The applications of computer performance analysis can
be categorized in a variety of ways, depending on the
objective of the categorization. In this paper the objective
is to aid in selecting an appropriate tool and analysis
approach. The following categorization will therefore be
adopted:
General control: Many installations are run by intuition. Freely translated, this means that they are not
managed, but instead allowed to run without control.
All attempts at other applications of performance
analysis will be of marginal utility without control
based on adequate operating information.
Hypothesis generation: Computer system performance
improvement involves generating hypotheses, testing
hypotheses, implementing appropriate changes, and
testing the changes.* Useful information for hypothesis generation often appears so difficult to specify
and obtain that random changes are attempted to
improve the system. The failure rate for performance
improvement efforts without explicit hypothesis
generation is extremely high.
Hypothes~

testing: Given an interesting hypothesis, an
analyst's first impulse is to assume its correctness
and begin changing the system. This usually results
in lots of changes and little improvement. Hypothesis
testing is imperative for consistently successful
computer system performance improvement.

Equipment change: The friendly vendor salesman says
his new super-belchfire system will solve all your
problems. The change is too large to be classified as a
performance improvement change. Should you take
his word for it and make him rich, or do your own
analysis? If you choose to do your own analysis,
you're in this category when you're upgrading or
downgrading your system.
Sizing: Sizing a new system is a step more difficult than
equipment change because it often involves estimating workload and capacity in areas where extrapolation of existing characteristics is impossible or unreliable. This situation does not occur so often as equipment change, but usually involves much higher costs
of incorrect decisioni". Typical situations are bringing
in a new computer for a conceptualized (but unreal* This is a summary of the steps suggested in Reference 43.

ized) workload, centralization of diverse workloads
previously run on special purpose hardware/software
systems, and decentralization of workload from a
previously large system to a series of smaller ones.
Vendor selection is included in this category since the
performance-related part of this problem can be
described as sizing and verifying (or merely verifying,
in the case of some procurements) the performance of
a certain size system.
System design: Whether dealing with hardware or software, designers today usually are concerned with
performance. If the designers are in the application
area, the concern for performance often comes too
late for doing much about the mess. Early consideration, however, can be expensive and unfruitful if
carried on without the proper approach.

The easiest situation would be for each of these categories to have exactly one tool appropriate for application in analyses, but performance analysis has more dimensions than the single one of analysis objective. Two
of the most important ones are analyst experience and
type of system under consideration.

ANALYST EXPERIENCE
Some groups of analysts have considered single systems
(or a single model of system processing essentially the
same load at several sites) over a period of years. These
groups have often developed simulation and analvtical
tools for one type of analysis, and then, with th~ tool
developed and preliminary analysis already performed,
apply them in other situation~. Similarly, they may have
used accounting data for a situation where it is particularly applicable, and then have applied it in an analysis
in which accounting data's applicability is not obvious.
The ability of group members to apply a variety of familiar tools freely in diverse situations is one of the reasons
for maintaining such groups.
Some other groups have developed analysis techniques
using a single tool to the extent that their members can
apply it to a much wider variety of situations than
expected because they have become particularly familiar
with its characteristics and the behavior of the systems
they are analyzing. As a result, such groups have proved
able to enter strange installations and produce valuable
results by immediately executing rather stylized analyses
to check for the presence of certain hypothesized problems.
The analyst with less than one or two years of performance analysis experience, however, cannot expect to
achieve the same results with the~e approaches. The
remainder of this paper will consider the situation of the
more typical analyst who is not yet extensively experienced.

Performance Determination

TYPE OF SYSTEM
Software monitors are obviously commercially available for IBM System 360 and 370 computers, but their
existence for other systems is often unrecognized. This
sometimes leads analysts to believe that personal inspection is the only alternative for any other system. In fact,
virtually every major computer system on the market
currently possesses an accounting system; hardware
monitors will work on any system (with the exception of
certain very high speed circuits); batch benchmarks can
be run on any system; and models can be constructed for
any system (and have been for most). In addition, software monitors have been implemented for most computer
systems in the course of government-sponsored research.
The analyst's problem is to discover any required,
obscure tools and to be able to- use them
without undue
emphasis on learning the tools' characteristics.
The world of performance analysis tools is not so
smooth as may be implied above. First, benchmarks for
on-line systems are nearly impossible to obtain for any
system without assistance of the computer system vendor.
Second, many tools are simply no good; their implementers did a poor job, or they are poorly documented, or
they don't do the thing needed for the problem at hand.
Third, searching out the appropriate tool may require
more time than the analyst can spend on the entire performance analysis. Fourth, the analyst seldom has prior
knowledge of whether one of the first three problems will
arise, so he doesn't know where to concentrate his search.
Fortunately, any of several different types of tools can be
used in most analyses, so the analyst can pick from several possibilities rather than search for some single possibility. The choice is largely dependent on the category of
analysis being performed.
CATEGORY OF ANALYSIS
Having presented some important analysis characteristics of various tools, limited the discussion to apply only
to analysts without extensive experience, and begged the
question of tool availability, the important step remains
of matching analysis objective with type of tool and analysis. Suggestions about tool selection for each analysis
objective are given below; they should be interpreted in
the context of the discussion above.
GeneraL control

Accounting data generally have proven most appropriate for general control. They are organized correctly
for generating exception reports of system misuse by
programmers (incorrect specification of job options, violating resource limitations, and running jobs inappropriate for their assigned tasks). They also usually provide
valuable information about operations (number of

reloads of the operating system, number of reruns, incidence of the system waiting for tape mounts, etc.). Further, it provides data on the level of chargeable resource
utilization so that financial management can be
performed.
Accounting data's primary disadvantage is the difficulty of generating meaningful reports from it. It also
requires operators' adherence to appropriate standards of
operation for maintaining reliable data. Further, it
usually can provide reports no sooner than the following
day. One alternative is to use a very inexpensive hardware monitor with dynamic output for on-line operational
control and to use accounting data for normal reporting.
(Regular use of monitors, perhaps one use per month, can
also be adopted to supplement the accounting data.)
The most commonly used general control technique is
one of the least useful. Personal inspection is inadequate
for anything except the case of a manager continually on
the floor-and he needs an adequate system of reporting
to detect trends that are obscured by day-to-day problems. The techniques in this section may appear too
obvious to be important, but we find that ignoring them is
one of the most common causes of poor computer system
performance.
Hypothesis generation

Hypothesis generation for system performance
improvement is based on the free run of imagination over
partly structured data, combined with the application of
preliminary data analysis techniques. In general, the data
leading to the most obvious relationships prove best, so
personal inspection and partly reduced accounting data
often are most useful. Quick scans of system activity,
organized by job, often lead to hypotheses about user
activity. An analyst can often hypothesize operational
problems by visiting several other installations and trying
to explain the differences he observes.
Some installations have found that regular use of a
hardware or software monitor can lead to generating
hypotheses reliably. The technique is to plot data over
time and then attempt to explain all deviations from historical trends. This approach may have the advantage of
hypothesis formulation based on the same data collection
device that is used for hypothesis testing.
Hypothesis testing

Nearly any tool can be used for testing performance
improvement hypotheses. The particular one chosen is
usually based on the type of hypothesis and the tool used
in generating the hypothesis. For example, hypotheses
about internal processing inefficiencies in jobs can
usually be best tested with software monitors designed to
collect data on application code. Hypotheses about the
allocation of resource use among programmers can
usually be tested most readily through the use of account-

National Computer Conference, 1973

ing data. Simulative and analytical models can often be
used to perform tests about machine scheduling and the
trade-off of cost and performance, particularly when
hypothesis generation employed modeling.
After a hypothesis is tested, implementation of a
change is usually the next step. Following implementation, the resulting performance change requires examination to ensure that the expected change, and only that
change, has occurred. Although the same tool may be
used for both parts of hypothesis testing, employing a
different tool provides the advantage of forcing the analyst to view the system from a slightly different point of
view, and therefore reduces the chance of ignoring important clues in seemingly familiar data. This advantage
must be traded-off against the advantage of easing detection of perturbations in the familiar data caused by
implemented changes.
A special note is in order for the use of benchmarks in
hypothesis te~ting. If a hypothesis involves a characteristic of the basic system, a completely controlled test
often can test the hypothesis far more thoroughly than
other types of tests. For example, an analyst might
hypothesize that his operating system was unable to initiate a high-priority job when an intermediate-priority job
had control of the CPU. While he could monitor the
normal system until the condition naturally occurred, a
simple test with the appropriate benchmark jobs could
readily test the hypothesis. We have found that artificial
stimulation of on-line systems can similarly test
hypotheses rapidly in both controlled tests and monitoring normal operation. The temptation to examine only
"the normal system" should be resisted unless it proves to
be the most appropriate testing technique.

Equipment change
Equipment change might involve upgrading the system's CPU, changing from slow disks to faster ones, or
adding a terminal system. All these changes might be
considered merely major tuning changes, but they involve
enough financial risk that more analysis is devoted to
them than normal system performance improvement
efforts. In addition, the analyst has a very stylized type of
hypothesis: how much performance change results from
the hardware change? These special characteristics of
equipment change lead to increased use of benchmarks
and simulation.
When the alternative configuration exists at another
installation (usually a vendor's facility), analysts can
generate a series of benchmarks to determine how well
the alternative performs in comparison with the existing
system. Recently, synthetic benchmarks have come to be
used more extensively in this process, particularly in test
designs which examine particular system characteristics,
or which include carefully monitoring normal system utilization to improve the meaningfulness of the benchmarks.
Tn other ('ases there is no svstem available for running
the benchmarks. Simulation is often employed in this

environment. The most important problem in this type of
analysis is ensuring the validity of the workload description on the alternative system and the validity of the
alternative's processing characteristics. Unvalidated
simulations may be the only reasonable alternative, but
the risk of employing them is usually high.

Sizing
The technique used most commonly today in sIzmg
computers is listening to vendor representatives and then
deciding how much to discount their claims. This situation is partly the result of the difficulties involved in
using the alternatives-benchmarking and modeling.
Although analytical modeling is conceptually useful, its
use in sizing operations has been minimal because its
absolute accuracy is suspect. Simulative modeling
appears less suspect because the models are closer to
commonly-used descriptions of computer systems. The
sensitivity of simulation models to changes in parameters
can often be verified, at least qualitatively, so analysts
can gain some degree of faith in their correctness.
All the problems of using benchmarking in equipment
change analyses are present when benchmarking is used
in sizing analyses. In addition, the relationship of benchmarks to workloads that will appear on a future system is
especially difficult to determine. A synthetic benchmark
job might be quite adequate for representing workload
mea~ingfully on a modification of the existing system,
but Its characteristics might be very wrong on a completely different system. (This same problem may be true
for simulations, but a validated simulation should facilitate correct workload descriptions.)

Design
Tool selection in design must be divided into two parts
-selection in the early design phase and selection in the
implementation phase. In the earlier phase, performance
analysis must be based on modeling because, without any
implemented system, real data cannot be collected. The
later phase might, therefore, seem particularly suited to
the data collection approaches. In fact, modeling appears
to be a good technique to employ in concert with monitored data in order to compare projections with realized
performance. Collecting data without using modeling may
decrease management control over development and
decrease the ease of data interpretation.
Design :fforts can begin by using modeling exclusively,
and then mtegrate monitoring into the collection of tools
as their use becomes feasible.
FINAL COMMENT
Computer performance analysis tools and approaches
are in a period of rapid development, so the appropriateness of their application in various situations can be
expected to change. In addition. individual analysts often

Performance Determination

find that an unusual application of tools proves the best
match to their particular abilities and problems. The
suggestions above should therefore not be interpreted as
proclamations of the best way to do performance analysis, but as general indications of potentially useful
directions.
Inadequate understanding of computer system performance currently precludes quantifying problems
across large numbers of systems. Each analyst must feel
his way to a solution for each problem with only helpful
hints for guidance. If improved understanding is developed, the artistic procedure discussed in this paper may
evolve into a discipline in which analysts have the assurance they are using the correct approach to arrive at the
correct answer.
REFEREl\;CES
1. Morris, M. F., "Simulation as a Process," Simuletter, Vol. 4, No.1,
October 1972, pp. 10-21.
2. Bell, T. E., Computer Performance Analysis: Measurement
Objectives and Tools, The Rand Corporation, R-584-NASA/PR,
February 1971.
3. Canning, R. G. (ed.), "Savings from Performance Monitoring",
EDP Analyzer, Vol. 10, ~o. 9, September 1972.
4. Murphy, R. W., "The System Logic and Usage Recorder," Proc.
AFIPS 1969 Fall Joint Computer Conference, pp. 219-229.
5. Rock, D. J., Emerson, W. C., "A Hardware Instrumentation
Approach to Evaluation of a Large Scale System," Proc. of The
24th National Conference (ACM), 1969, pp. 351-367.
6. Johnston, T. Y., "Hardware Versus Software Monitors," Proc. of
SHARE XXXIV, Vol. I, March 1970, pp. 523-547.
7. Kolence, K W., "A Software View of Measurement Tools," Datamation, Vol. 17, No.1, January 1, 1971, pp. 32-38.
8. Hart, L. E., "The User's Guide to Evaluation Products," Datamation, Vol. 16, No. 17, December 15,1970, pp. 32-35.
9. Watson, R. A., Computer Performance Analysis: Applications of
Accounting Data, The Rand Corporation, R-573-NASA/PR, May
1971.
10. Bell, T. E., Computer Performance Analysis: Minicomputer-Based
Hardware Monitoring, The Rand Corporation, R-696-PR, June
1972.
11. Estrin, G., Hopkins, D., Coggan, B., Crocker, S. D., "SNUPER
Computer: A Computer in Instrumentation Automation," Proc.
AFIPS 1967 Spring Joint Computer Conference, pp. 645-656.
645-656.
12. Carlson, G., "A "Cser's View of Hardware Performance Monitors,"
Proc. IFIP Congress 1971, Ljubljana, Yugoslavia.
13. Cockrun, J. S., Crockett, E. D., "Interpreting the Results of a
Hardware Systems Monitor," Proc. 1971 Spring Joint Computer
Conference, pp. 23-38.
14. Miller, E. F. Jr., Hughes, D. E., Bardens, J. A., An Experiment in
Hardware Monitoring, General Research Corporation, RM-1517,
July 1971.
15. Stevens, D. F., "On Overcoming High-Priority Paralysis in Multiprogramming Systems: A Case History," Comm. Of The ACM,
Vol. 11, :\lo. 8, August 1968, pp. 539-541.
16. Bemer, R. W., Ellison, A. L., "Software Instrumentation Systems for Optimum Performance," Proc. IFIP Congress 1968, pp.
39-42.
17. Cantrell, H. N., Ellison, A. L., "Multiprogramming System Performance Measurement and Analysis," Proc. 1968 Spring Joint
Computer Conference, pp. 213-221.
18. A Guide to Program Improvement with LEAP, Lambda LEAP
Office, Arlington, Virginia (Brochure).
19. Systems Measurement Software (SMS! 360) Problem Program
Efficiency (PPE) Product Description, Boole and Babbage, Inc.,
Cupertino, California (Brochure).

20. Bookman, P. G., Brotman, G. A., Schmitt, K. L., "lJse Measurement Engineering for Better System Performance," Computer
Decisions, Vol. 4, No.4, April 1972, pp. 28-32.
21. Hughes, J. H., The Construction and Use of a Tuned Benchmark
for U1VIVAC 1108 Performance Evaluation-An interim report,
The Engineering Research Foundation at the Technical lJ niversity
of Norway, Trondheim, Norway, Project No. 140342, June 1971.
22. Ferrari, D., "Workload Characterization and Selection in Computer Performance Measurement," Computer, July/August 1972,
pp.18-24.
23. Load Generator System General Information Manual, Tesdata
Systems Corporation, Chevy Chase, Maryland (Brochure).
24. Cohen, Leo J., "S3, The System and Software Simulator," Digest
of The Second Conference on Applications of Simulation, Kew
York, December 2-4, 1968, ACM et aI., pp. 282-285.
25. Nielsen, Xorman R., "ECSS: An Extendable Computer System
Simulator," Proceedings, Third Conference on Applications of
Simulation, Los Angeles, December 8-10, 1969, ACM et aI., pp.
114-129.
26. Bairstow, J. N., "A Review of System Evaluation Packages,"
Computer Decisions, Vol. ,2, .xo. 6, July 1970, Pg. 20.
27. Thompson, William C., "The Application of Simulation in Computer System Design and Optimization," Digest of The Second
Conference on Applications of Simulation, New York, December 24, 1968, ACM et aI., pp. 286-290.
28. Hutchinson, George K, Maguire, J. ~., "Computer Systems
Design and Analysis Through Simulation," Proceedings AFIPS
1965 Fall Joint Computer Conference, Part 1, pp. 161-167.
29. Bell, T. E., Modeling the Video Graphics System: Procedure and
Model Description, The Rand Corporation, R-519-PR, December
1970.
30. Downs, H. R., Nielsen, N. R., and Watanabe, E. T., "Simulation of
the ILLIAC IV-B6500 Real-Time Computing System," Proceedings Fourth Conference on Applications of Simulation, December
9-11,1970, ACM et aI., pp. 207-212.
31. McCredie, John W. and Schlesinger, Steven J., "A Modular Simulation of TSS/360," Proceedings, Fourth Conference on Applications of Simulation, New York, December 9-11, 1970, ACM et aI.,
pp.201-206.
32. Anderson, H. A., "Simulation of the Time-Varying Load on Future
Remote-Access Immediate-Response Computer Systems," Proceedings, Third Conference on Applications of Simulation, Los
Angeles, December 8-10, 1969, ACM et a!., pp. 142-164.
33. Frank, A. L., "The Use of Simulation in the Design of Information
Systems," Digest of The Second Conference on Applications of
Simulation, New York, December 2-4, 1968, ACM et aI., pp. 87 -88.
34. Dumas, Richard K, "The Effects of Program Segmentation on Job
Completion Times in a Multiprocessor Computing System," Digest
of The Second Conference on Applications of Simulation, 0;"ew
York, December 2-4,1968, ACM et aI., pp. 77, 78.
35. Nielsen, Norman R., "An Analysis of Some Time-Sharing Techniques," Comm. of The ACM, Vol. 14, No.2, February 1971, pp.
79-90.
36. Bell, T. E., Computer Performance Analysis: Objectives and Problems in Simulating Computers, The Rand Corporation, R-1051PR, July 1972. (Also in Proc. 1972 Fall Joint Computer Conference, pp. 287-297.)
37. Chang, W., "Single-Server Queuing Processes in Computer Systems," IBM Systems Journal, Vol. 9, No.1, 1970, pp. 37-71.
38. Coffman, E. G. Jr., Ryan Jr., Thomas A., "A Study of Storage
Partitioning Using a Mathematical Model of Locality," Comm. of
The ACM, Vol. 15, ~o. 3, March 1972, pp. 185-190.
39. Abate, J., Dubner, H., and Weinberg, S. B., "Queuing Analysis of
the IBM 2314 Disk Storage Facility," Journal of The ACM, Vol.
15, ~o. 4, October 1968, pp. 577 -589.
40. Ramamoorthy, C. V., Chandy, K. M., "Optimization of Mem·
ory Hierarchies in Multiprogrammed Systems," Journal of The
ACM, Vol. 17, No.3, July 1970, pp, 426-445.
41. Kimbleton, S. R., "Core Complement Policies for Memory Allocation and Analysis," Proc. 1972 Fall Joint Computer Conference,
pp. 1155-1162.

National Computer Conference, 1973

42. DeCegama, A., "A Methodology for Computer Model Building,"
Proc. 1972 Fall Joint Computer Conference, pp. 299-310.
43. Bell, T. E., Boehm, B. W., Watson, R. A., Computer Performance Analysis: Framework and Initial Phases for a Performance
Improvement Effort, The Rand Corporation, R-549-1-PR, November 1972. (Much of this document appeared as "Framework and
Initial Phases for Computer Performance Improvement," Proc.
1972 Fall Joint Computer Conference, pp. 1141-1154.)

APPENDIX-COMPUTER OVERHEAD
Accountancy requires that computer overhead costs
be borne by users who are charged directly for their
demands on the system. Data collection systems tend to
include this requirement as a basic assumption underlying their structures. The resulting aggregation obscures the type of overhead most prominent in a system,
the resources heavily used by overhead activities, and
the portion of total system capability devoted to overhead activities. System analysis requires these data;
they need definition and should be available for performance analysis.
From the viewpoint of performance analysis, at least
five components of overhead can be identified in most
multiprogramming systems. These are:
1. I/O handling
2. User resource request handling
3. System handling of spooled I/O
4. Job or sub-job (e.g., job step or activity) initiation/
termination
5. System operation (including task switching, swapping, maintaining system files, etc.)
I/O handling may require large amounts of time, but
this is largely controllable by the individual user. Item
one, therefore. may not be a candidate for inclusion in a
definition of overhead in many analyses.
User resource request handling (at least at the time of
job or sub-job initiation) is similarly controllable by the
users except for required system-required resources (such
as system files). Item two might be included in definitions
more often than item one, particularly since item two is

often influenced strongly by installation-specified practices (such as setting the number of required files).
System handling of spooled I/O is under the control of
users to the extent that they do initial and final I/O, but
the alternatives open to installation managements for
influencing its efficiency are often very great. For example, changing blocking sizes or using an efficient spooling
system (such as HASP) can have gross effects on the
amount of resources consumed in the process. Installation
management's control over this is so high that item three
is often included in a definition of overhead.
Initiation and termination appear to consume far more
resources than usually assumed. User-specified options
influence the amount of resource usage, but installationchosen options and installation-written code can impact
usage to a large degree. The choice of specific operating
system, order of searching files for stored programs, layout of system files, and options in the operating system
can change the resources used to such an extent that item
four should be included in overhead in nearly all cases.
System operation is always included as a part of overhead. The difficulty of :separating thi~ element of overhead from all the rest is very difficult, so analyses usually
assume that it is included as part of one of the other
elements. One technique for quantifying its magnitude
is to decide on the parts of code whose execution represent it and then to measure the size of these elements.
The same parts of code can be monitored with a hardware
monitor to determine the amount of processor time and
I/O requests that arise from execution of the code. The
sizes of system files are usually not difficult to obtain for
determining the amount of rotating memory used by this
type of overhead. This technique, however, will nearly
always underestimate that amount of overhead since
pieces of overhead are so scattered through the system.
Ideally, each of the types of overhead would be identified and measured so that installations could control the
amount of each resource that is lost to it. If the resource
loss to overhead were known for typical systems. each of
the applications of performance analysis would be eased.

Computing societies-Resource or
hobby?
by ANTHONY RALSTON
State University of New York
Buffalo, New York

ABSTRACT
The fodder for a technical society is people but people
can nevertheless use as well as be used by the society.
Such use can be passive (e.g., publishing articles in the
society's journals) or active through direct participation
in the professional activities or administration of the
~o('iety. Ap. in thr up.{' of FIll romputing resourcep-o there is a
potential for both profit and loss; these will be examined.
in part at least, seriously.

Special Libraries Association Session

The special libraries association today

Standards for library information
processing

by E. A. STRABLE

Special Libraries Association
New York, New York

ABSTRACT
Special librarians are part of the larger library community but can be differentiated from other groups of librarians (school, public, academic) by where they practice
their profession, by the groups with whom they work, and
most importantly, by their goals and objectives. The
major objective, the utilization of knowledge for practical
ends, brings special librarianship thoroughly into information processing in some unusual and unique ways. The
Special Libraries Association is the largest society to
which special librarians belong. The Association, like its
members, is also involved in a number of activities which
impinge directly upon, and affect, the role of information
processing in the U.S.

Esso Research and Engineering Company
Linden, New Jersey

ABSTRACT
Present copyright laws were developed largely to protect "authors" against large-scale piracy of books, articles, motion pictures, plays, music, and the like. These
laws and related judicial decisions have in recent years
raised serious questions as to the legality of such modern
information processing as the photocopying, facsimile
transmission, microfilming, and computer input and
manipulation of copyrighted texts and data. Congress has
so far failed to clarify these matters, except for sound
recordings. It has proposed to have them studied by a
National Commission, but it has repeatedly refused to
establish this without aiso passing revisions chiefly dealing with cable-TV. Emphasis will be placed in this talk on
consequences for libraries, library networks, and other
information processors, and on recent legislative developments.

by LOGAN C. COWGILL

Water Resources Scientific Information Center
Washington, D.C.
and
DA VID L. WEISBROD

Yale University Library
New Haven, Connecticut

ABSTRACT
Technical standards will be described in terms of their
intent, their variety (national, international, etc.), their
enumeration, and their development process. Their
importance will be evaluated in terms of their present
and future usefulness and impact.

National Computer Conference, 1973

A network for computer users

Uses of the computer in large school
districts

by BRUCE K. ALCORN
Western Institute for Science and Technology
Durham, North Carolina

by THOMAS J. McCONNELL, JR.
Director, Atlanta Public Schools
Atlanta, Georgia

ABSTRACT
ABSTRACT
Computer networks are an accepted fact in the world of
computing, and have been for some time. Not so well
accepted, however, is the definition of a computer network. Some claim that to be a network the communications system must connect a group of computers as
opposed to a network of terminals communicating with
one computer. Still others hold that both are examples of
computer networks; the first being a ring network and the
latter a star network.
Within education, computer networks of many descriptions exist. Most such activities have dealt with the institutions of higher education, but there are some notable
exceptions. These networks are operated by universities,
independent non-profit corporations, branches of state
governments, and private industry. Some are time-sharing systems, some operate in the remote batch mode, and
others offer both types of service. Most of the computing
done through these networks has been for instructional
purposes; however, a great many research problems are
processed with administrative applications last in amount
of activity, although increasing.
During 1968 the National Science Foundation initiated
a number of projects which gave a great impetus to
computer networks, mainly among colleges and universities. This effort continues today in a different form
through the Expanded Research Program Relative to a
National Science Computer Network of the NSF.
Currently the National Institute of Education is supporting the development of the Nationwide Educational
Computer Service, a network designed to help colleges
and school systems meet their computing needs at a
minimum of cost. This network will consist of a large
scale computer serving a series of intelligent terminals in
institutions in various parts of the United States. The
system is configured in such a way so as to assist the
student, faculty, and administrator at a cost effective
rate. The factors involved in producing this saving
include the particular hardware and software at the central site and at the terminal location, the mode of operation and the effective use of existing tele-communication
facilities.

In this age of accountability in education it is apparent
that the most economical and efficient systems conceivable must be made available to the administrator. This
fact is true at all levels of management from the classroom to the superintendent.
Most large school districts could not perform all of the
tasks required of them if they had to operate in a manual
mode. This fact is certainly not unique to school districts
but is a common problem of our dynamic society.
The administrative use of the computer in most school
districts came about as a result of a need for more efficient and faster methods of performing accounting functions. After their first introduction they generally just
"growed" as Topsy would say. Most large school districts
today will have a rather sophisticated set of hardware and
software supported by a very fine staff of professionals.
With the advent of tighter budget control and with most
educators today clamoring for some form of "program
budgeting" the computer is an even more vital ingredient
that is required if we are to provide for quality education.
Additionally, it is no longer sufficient to provide automation to the administrative functions in a school district. The computer is fast becoming an essential part of
our instructional program. This instructional role of the
computer is coming into being in the form of Computer
Managed Instruction (CM!) as well as Computer Assisted
Instruction (CAl).
Although development of uses for the computer for
instructional purposes has only been under way for a few
short years, we have witnessed some very dramatic
results. Most educators are in agreement as to the effectiveness of the computer for instructional purposes; the
fact that it has not expanded as many had hoped and
assumed is a function of finances rather than a shortcoming of the Implementation.
Education can expect to have some very rewarding
experiences in its relationship with the computer and the
computer professional in the seventies. This fact will
come about as a result of developments in computer technology both in hardware and in software. Also, the reduction in the cost factor should be of such magnitude that
computer services will be available to more school districts and at a cost that they can afford.
With proper organization and cooperation the computer
can begin to realize its full potential in bringing about
efficient. effective education in its many aspects.

Association for Educational Data Systems Session

Training of teachers in computer
usage

How schools can use consultants

by DUANE E. RICHARDSON

ARIES Corporation
Minneapolis, Minnesota

by DONALD R. THOMAS

Northwest Regional Educational Laboratory
Portland, Oregon

ABSTRACT
ABSTRACT
I plan to discuss the need in teacher education for
training and experience in the selection of instructional
materials for use on computers and the teacher's role in
helping to identify criteria for developing additional
instructional materials.
§£~£LfLc_ ~~s~~~_sio_n__ ~il) h~_ dj:!".e~t~g _~t c:l~_sqjbing a
course which will guide teachers through the development
of a set of criteria by which to judge the value of such
instructional applications and will demonstrate how the
criteria can be applied. The course will allow the teacher
to practice application of the criteria to sample instructional uses from his particular interest.

Data processing consulting firms today offer a variety
of professional services to schools. Users of these services,
however, often differ in their opinions of the value of
these services.
The point of this presentation is simply that unsatisfactory consultant relationships can have their source not
onlyi!1 the consultant himself, but also in the schoo) use
of the consultant's services. In other words, use of consultive services implies a two-way relationship which is subject to misuse and abuse by either party.
The experience throughout the educational computer
area demonstrates that time and effort devoted to sound
use of consultants will pay substantial dividends. That
factor should be a major one in the planned use of a
consultant.
An experienced consultant will bring expertise to a
study based upon his experiences with other clients. This
should result in client confidence and in assuring that the
unique needs of the clients will be identified and
addressed.

NAPSS-like systems-Problems and prospects
by JOHN R. RICE
Purdue University
West Lafayette, Indiana,

NAPSS-NUMERICAL ANALYSIS PROBLEM
SOLVI;\JG SYSTEM

The first of these is the best understood and least difficult at the present time. The next four are very substantial problem areas, but the pilot NAPSS system
shows that one can obtain acceptable performance and
results. Symbolic problem analysis (except for things
like symbolic differentation, is not made in the pilot
NAPSS system and, in a numerical analysis context,
this is an undeveloped area. The interface with the operating system is very complex in the pilot system and is
an area of unsolved problems. Basically the pilot
::-.JAPSS system needs more resources than the operating
system (which is indifferent to NAPSS) provides for one
user. The final problem area, portability is as difficult
for NAPSS as for other complex software systems.
All of these problem areas except 5 and 6 are present
in any problem solving system with a level of performance and scope similar to NAPSS. Examples include
statistical systems (BMD,SPSS,OSIRIS); linear programming and optimization packages (LP90,OPTIMA);
engineering problem solving systems (COGO,NASTRA:r\,ICES) and so forth. There is considerable variation in the present characteristics of these systems, but
they have as ultimate goal to provide a very high level
system involving many built-in problem solving procedures of a substantial nature.
Only a brief discussion of the first four problem areas
is presented here because they are either less difficult or
already widely discussed in the literature. The next two
problem areas are specific to ~APSS-like systems and
several pertinent points are discussed which have arisen
from an analysis of the pilot NAPSS system. The final
two are widely discussed in the literature but still very
difficult for a NAPSS-like system. Some alternatives
are presented, but the best (or even a good) one is still to
be determined.

This paper arises from the development of ;\JAPSS
and discus-s-es the p-roblems solved and still it> be solved in
this area. The original paper contains two phrases which
define the objectives of NAPSS (and NAPSS-like systems) in general, yet reasonably precise, terms:
"Our aim is to make the computer behave as if it
had some of the knowledge, ability and insight of
a professional numerical analyst. "

"describe relatively complex problems in a simple mathematical language-including integration, differentiation, summation, matrix operations~ algebraic and differential equations, polynomwl and other approximations as part of the
bas ic language."
A pilot system has been completed at Purdue and runs on
a CDC 6500 with an Imlac graphics console. It does not
contain all the features implied by these objectives, but it
has (a) shown that such a system is feasible and (b)
identified the difficult problem areas and provided
insight for the design of a successful production system.
The purpose of this paper is to identify the eight principal problem areas, discuss four of them very briefly and
the other four in somewhat more detail. Several of these
problem areas are specific to NAPSS-like systems, but
others (including the two most difficult) are shared with
a wide variety of software systems of a similar level and
nature.
The presentation here does not depend on a detailed
knowledge of NAPSS, but specific details are given in the
papers listed in the references.1. 2 ,3,4.5.6.7
PROBLEM AREAS
The eight principal problem areas are listed below:
1.
2.
3.
4.
5.
6.
7.
8.

LANGUAGE DESIGN AND PROCESSING

Language Design and Processing
Simulating Human Analysis (Artificial Intelligence)
Internal System Organization
User Interface
Numerical Analysis Polyalgorithms
Symbolic Problem Analysis
Operating System Interface
Portability

Ordinary mathematics is the language of NAPSS
modulo the requirement of a linear notation. While this
linear notation does lead to some unfamiliar expressions,
it is not an important constraint. NAPSS has also
included a number of conventions from mathematics that
are not normally found in programming languages
(e.g., 1=2, 4, .. " N). Incremental compilation is used to
43

National Computer Conference, 1973

obtain an internal text which is then executed incrementally. This approach is, of course, due to the interactive
nature of NAPSS.
The creation of this language processor was a very
substantial task. The primary difficulties are associated
with the fact that all variables are dynamic in type and
structure, function variables are data structures (not
program structures) and that many operators are quite
large and complex due in part to the wide variety of operand types. For example, several integrals may appear in
one assignment statement and each of these may lead to
interaction with the user. The current NAPSS language
processor is relatively slow, partly because of the nature
of the language, partly because of the incremental and
interactive approach and partly because it is the first one.
However, it performs well enough to show that it is not a
major barrier to obtaining an acceptable production system.
SIMULATING HUMAN ANALYSIS (ARTIFICIAL
INTELLIGENCE)
The original objectives include a large component of
automatic problem solving in the NAPSS system. This
component lies primarily in the polyalgorithms and
manifests itself in two ways. First, there are facilities
to analyze the problem at hand and to select an appropriate numerical analysis technique. This analysis
continues during the computation and specific techniques
may be changed several times during the execution of a
poly algorithm. The second manifestation is in incorporating common sense into the polyalgorithms. This is both
difficult and time consuming as it requires a large number of logical decisions and the collection and retention of
a large amount of information about the history of the
polyalgorithm's execution. The automation of problem
solving in NAPSS-like systems leads inevitably to large
codes for the numerical analysis procedures. A routine
using the secant method may take a few dozen Fortran
statements, but a robust, flexible and convenient nonlinear equation polyalgorithm requires many hundreds of
statements

INTERNAL SYSTEM ORGANIZATION
NAPSS and NAPSS-like systems are inherently large.
The compiler, interpreter, command processor and supervisor are all substantial programs. A polyalgorithm for
one operator like integration or solution of nonlinear
equations can easily run to 1000 lines of Fortran code.
Data structures created during executions may also be
quite large (e.g., matrices and arrays of functions). The
organization of this system naturally depends on the
hardware and operating system environment. The current
pilot system is organized with three levels of overlays with
a paging system and runs in a memory of about 16,000

words (CDC 6500 words have ten characters or 60 bits or
multiple instructions). Many other configurations are
feasible and this area does not, in itself, pose a major
barrier to an acceptable production system. Currently
NAPSS performs quite well provided one ignores operating system influences, i.e., when NAPSS is the only program running. However, it is unrealistic to assume that
NAPSS-like systems have large computers dedicated to
them or that the operating system gives them preferential
treatment (compared to other interactive systems in a
multiprogramming environment). Thus the internal system organization is determined by outside factors, primarily by the requirements of the interface with the
operating system.
USER INTERFACE
A key objective of NAPSS-like systems is to provide
natural and convenient operation. This means that substantial investment must be made in good diagnostic
messages, editing facilities, console, and library and file
storage facilities. These requirements for a NAPSS-like
system are similar to those of a variety of systems. The
pilot NAPSS system does not have all these facilities
adequately developed and the primary effort was on editing, an operating system might provide many of these
facilities in some cases.
A more novel requirement here is the need for access to
a lower level language like Fortran. Note that applications
of NAPSS-like systems can easily lead to very substantial
computations. The intent is for these computations to be
done by the polyalgorithms where considerable attention
is paid to achieving efficiency. Inevitably there will be
problems where these polyalgorithms are either inapplicable or ineffective. Detailed numerical analysis procedures (e.g., Gauss elimination) are very inefficient if
directly programmed in NAPSS and thus some outlet to a
language with more efficient execution is needed. In such
a situation, NAPSS is a problem definition and management system for a user provided numerical analysis procedure.
There are several limits on this possibility due to differences in data structures and other internal features. An
analysis of the pilot NAPSS system indicates, however,
that a useful form of this facility can be provided with a
reasonable effort.
NUMERICAL ANALYSIS
A NAPSS-like system requires at least ten substantial
numerical analysis procedures:
1.
2.
3.
4.

Integration
Differentiation
Summation of infinite series
Solution of linear systems (and related items like
matrix inverses and determinants)

NAPSS-LIKE Systems

5.
6.
7.
8.
9.
10.

Matrix eigenvalues
Interpolation
Least squares approximation (of various types)
Solution of nonlinear equations
Polynomial zeros
Solution of ordinary differential equations

The objective is to automate these numerical analysis
procedures so that a user can have statements like:
AXS~

EQ2:

additional symbolic procedures must also be added
including at least a reasonable symbolic integration procedure.
N.A1PSS currently has two basic types of functions, the
symbolic function and the tabulated (or discrete) function. (There are also the standard built-in functions.)
Both of these may internally generate substantial data
structures. Consider, for example, the result of a very
common process, Gram-Schmidt orthogonalization. The
program in NAPSS may well appear as:

fF(X), (X~A TO B)

Xi 2*COS(X) -F(X)/(1 +X) =A *B/2
G(X) =F(X -A1\S)/(1 +X)

/* DEFIXE QUADRATIC SPLIXE */
Q(X)~X

SOLVE EQ2 FOR X
EQ3:

Y"(T)-COS(T) Y'(T) + TY(T) =G(T-X) -AXS

_SDhYE_RQ3 FOR_Y(l:J_QX

i 2 FOR X> =0

(O~2}\VITH Y(O)~O,

Y(2)~3

The user is to have confidence that either these procedures are carried out accurately or that an error message
is produced.
These procedures grow rapidly in size as one perfects
the polyalgorithms. One polyalgorithm developed for the
current NAPSS system is about 2500 Fortran statements
(including comments). This large size does not come from
the numerical analysis which constitutes perhaps 20
percent of the program. It comes from simulation of
common sense (which requires numerous logical and
associated pieces of information), the extensive communication facilities for interaction with the user and various
procedures for searching, checking accuracy and so forth,
aimed at providing robustness and reliability. A further
source of complexity is the fact that all of these polyalgorithms must automatically interface. Thus we must be
able to interpolate or integrate a function created by the
differential equation solver as a tabulated function (or
table valued function), one of the function types provided
in NAPSS. Since this output is not the most convenient
(or even reasonable) input to an integration polyalgorithm, one must make a special provision for this interface. For example in this case NAPSS could have a completely seperate poly algorithm for integrating table valued functions or it could use a local interpolation scheme
to obtain values for the usual polyalgorithm. The latter
approach is taken by the pilot NAPSS system.
In addition to numerical analysis procedures, NAPSS
currently has a symbolic differentiation procedure and
numerical differentiation is only used as a back-up for
those functions which cannot be differentiated symbolically (e.g., the gamma function). One may use Leibniz
rules for differentiating integrals and piecewise symbolically differentiable functions present may be handled
symbolically, so the numerical back-up procedure is infrequently used. It is noted below that future versions of
NAPSS should have more function types and that there
should be considerably more symbolic analysis of the
program. If these features are added, then a number of

S(X)~.5(Q(X) -3Q(X -1) +3Q(X -2) -Q(X -3»
/* FIRST THREE LEGEXDRE POLYXO~nALS
i3(X)IoF-=f;-]r(X)[iI~)(BrX5[2]~i.-5XT 2~.5

GRA~I-SCH::\nDT

FOR

K~3,4,·

FOR ORTHOGOXAL BASIS */

. ·,21 DO

T~(K -2)/10-1, TE::\IP(X)~S((X - T)/10)
TE::\IP(X)~ TE:\,fP(X)
(Y~

-1 TO 1»,

- SU:\l ((fTE~lP( Y)B( Y) [J],

J~,l,· .. , K-1)

B(X)[K]~TE:YIP(X)/(fTE~IP(Y)

2, (Y~ -1 TO 1»

.5;

The result is an array B(X)[K] of 22 quadratic spline
functions orthogonal on the interval [-1,1]. These statements currently cause NAPSS difficulty because all of
the functions are maintained internally in a form of
symbolic text. By the time the 22nd function is defined
the total amount of the text is quite large (particularly
since S(X) is defined piecewise) and the evaluation time
is also large because of the recursive nature of the definition. The integrations are, of course, carried out and constant values obtained.
This difficulty may be circumvented in the pilot
NAPSS by changing the code and a non-recursive text
representation scheme has been found (but not implemented) which materially reduces the evaluation time in
such situations. These remedies, however, do not face up
to the crux of the problem, namely many computations
involve manipulations in finite dimensional function
spaces. NAPSS should have a facility for such functions
and incorporate appropriate procedures for these manipulations. This, of course, adds to the complexity of the
language processor, but it allows significant (sometimes
by orders of magnitude) reductions in the size of the data
structures generated for new functions and in the amount
of time required for execution in such problems. Once this
type function is introduced, then it is natural to simultaneously identify the case of polynomials as a separate
function type. Again NAPSS would need appropriate
manipulation procedures, but then even a simple symbolic integration procedure would be valuable and allow
the program presented above to be executed in a very
small fraction of the time now required.

National Computer Conference, 1973

SYMBOLIC ANALYSIS
We have already pointed out the usefulness of symbolic
algorithms (e.g., differentiation, integration), but there is
also a significant payoff possible from a symbolic analysis
of the program. This may be interpreted as source language optimization and, as usual, the goal is to save on
execution time by increasing the language processing
time. There are three factors that contribute to this situation. First, NAPSS is a significantly higher level (more
powerful) language than, say, Fortran and it is much
easier to inadvertently specify a very substantial computation. Second, NAPSS allows one to directly transcribe
ordinary mathematical formulas into a program. Many
mathematical conventions ignore computations and
hence, if carried out exactly as specified, lead to gross
inefficiency. Finally, the ultimate class of users are people who are even less aware of the mechanics and procedures of computation than the average Fortran programmer. Indeed one of the goals of a NAPSS-like system is to
make computing power easily available to a wider class of
users.
The second factor is most ~pparent in matrix expressions where everyone is taught to solve linear equations
by (in NAPSS) X+-A H -1)B and matrix expressions like
(D+U-IL)-IL-IU are routinely applied to vectors. The
inefficiencies of computing inverse matrices are well
known and algorithms have been developed for processing each expression without unnecessarily computing
matrix inverses. Another simple example comes from integration where the statement
Df-J(JF(X)G(Y), (Xf-O TO 1», (Yf-O TO 1)

is the direct analog of the usual mathematical notation.
These two examples may be handled by optimization of
single NAPSS statements. This presents no extraordinary
difficulty in the current system, but optimization involving several statements presents severe difficulties for the
current system design because it is an incremental language processor and all variables are dynamic.
Symbolic analysis of groups of statements is worthwhile
and many of these situations are fairly obvious or correspond to optimizations made in common compilers. The
following group of statements illustrate a situation unique
to NAPSS-like languages (or any language where functions are true variables, i.e., data structures).
H(X)f-GA'(X -A)/GB'(A -X)
G(X)f-JF(T), (Tf-O TO X)
PLOT G(X) FOR Xf-Q TO 10
SOLVE Y'(T) + G(T) Y(T) = H(T/lO)/(l + G(T»
FOR Y(T) \VITH Y(0)f-2 OK Tf-Q TO 10
SOLVE G(W)/W-H(W-A)=TAX(WIA) FOR W

The first two statements define functions in terms of
operators implemented by polyalgorithms (assume that
GA(X) or GB(X) cannot be differentiated symbolically)

and the last three statements required numerous evaluations of these functions. The straightforward approach
now used simply makes these evaluations as needed by
the PLOT or SOLVE processors. However, it is obvious
that very significant economies are made by realizing that
these functions are to be evaluated many times and thus,
introducing the following two statements,
APPROXIMATE H(X) AS HH(X) ON 0 TO 10
APPROXIMATE G(X) AS GG(X) ON 0 TO 10
and then by using HH(X) and GG(X) in the last three
statements. A good symbolic analysis of the program
would recognize this situation and automatically replace
the symbolic definition of H(X) and G(X) by the approximations obtained from the approximation algorithm. It is
clear that a symbolic analysis would not be infallible in
these situations, but it appears that the savings made in
the straightforward situations would be significant.
OPERATING SYSTEM INTERFACE
The most likely environment (at this time) for a
NAPSS-like system is a medium or large scale computer
with a fairly general purpose multiprogramming mode of
operation. From the point of view of NAPSS the key
characteristics of this environment are (a) The operating
system is indifferent to NAPSS, i.e., NAPSS does not
receive special priority or resources relative to jobs with
similar characteristics. (b) Central memory is too small.
(c) Heavy, or even moderate, use of NAPSS in an interactive mode makes a significant adverse impact on the
overall operation of the computer. One may summarize
the situation as follows: NAPSS is too big to fit comfortably in central memory for semi-continuous interactive
use. Thus it must make extensive use of secondary
memory. The result is that in saving on one scarce
resource, central memory space, one expends large
amounts of another equally scarce resource, access to
secondary memory.
One may consider five general approaches to the organization of a NAPSS-like system in an effort to obtain
acceptable performance at an acceptable cost and with an
acceptably small impact on the operating system. The
first is to operate in a small central memory area and to
be as clever as possible in instruction of programs and the
access to secondary storage. In particular, paging would
be heavily if not entirely controlled by the NAPSS system
in order to optimize transfers to secondary storage. This is
the approach used in the current pilot NAPSS system.
The second approach is to use the virtual memory facilities of the operating and hardware system and then treat
NAPSS as though it were in central memory at all times.
The third approach is obtain enough real memory to hold
all, or nearly all, of NAPSS. This approach includes the
case of running a NAPSS-like system on a dedicated
computer. The fourth approach is to limit NAPSS to
batch processing use.

NAPSS-LIKE Systems

The final approach is to use distributed computing
involving two processors. One processor is for language
processing. A substantial memory is required because
quite large data structure may be generated by NAPSS.
A minicomputer with a disk might be suitable to handle
a number of consoles running NAPSS. The other processor is that of a medium or large scale computer and its
function is to execute poly algorithms. These programs
would reside in this central computer's secondary storage rather than in the minicomputer's memory. The
necessary language and data structures would be transferred to the main computer when a polyalgorithm is to
be executed.
The batch processing approach fundamentally changes
the nature of the system and is hard to compare with the
others. The other approaches have one or more of the
following disad'laIliage.s:
1. The performance (response time) may be slow,

especially when the computer is heavily loaded.
2. A very substantial investment in hardware is
required.
3. The system is difficult to move to a new environment.
The performance of the pilot ~APSS system suggests that
each of these approaches can lead to a useful production
system. Those that invest in special hardware would no
doubt perform better, but it is still unclear which
approach gives the best performance for a given total
investment (in hardware, software development, execution time and user time).
PORTABILITY

The development of the pilot NAPSS system was a
significant investment in software, perhaps 8 to 12 man
years of effort. The numerical analysis polyalgorithms
are reasonably portable as they are Fortran programs
with only a few special characteristics. Indeed one can
locate some suitable, if not ideal, already existing programs for some of the numerical analysis. The language
processor is very specific to the operating system interface
and the hardware configuration. It is about 90 percent in
Fortran, but even so changing environments requires
perhaps 8 to 12 man months of effort by very knowledgeable people.

NAPSS-like systems must be portable in order to get a
reasonable return from the development effort as few
organizations can justify such a system on the basis of
internal usage . .I.~ number of approaches to (nearly) machine independent software do exist (e.g., boot strapping, macros, higher level languages) which are very
useful. However, I believe that a survey of widely distributed systems similar to NAPSS in complexity would
show that the key is an organization which is responsible for the portability. This organization does whatever is necessary to make the system run on an IBM
360;75 or 370/155, a UNIVAC 1108, and CDC 6600 and
so forth. No one has yet been able to move such a system
from sayan IBM 370 to a CDC 6600 with a week or two
of effort.
Another approach is to make the system run on
II!El9-jt!:r!lJ!!l(:Ll~rg~__ ~U:~_M _aeQ'_~__ ~n_d _aLQ'~L( within )standarrl
configurations) and ignore the rest of the computers.
The emergence of computer networks opens up yet
another possibility for portability, but it is too early to
make a definite assessment of the performance and cost
of using a NAPSS-like system through a large computer
network. Networks also open up the possibility of a really
large NAPSS machine being made available to a wide
community of users.
REFERENCES
1. Rice, J. R, Rosen S., "NAPSS-A Numerical Analysis Problem

Solving System," Proc. ACM National Conference, 1966, pp. 5156.
Rice, J. R, "On the Construction of Polyalgorithms for Automatic
Numerical Analysis" in Interactive Systems for Experimental
Applied Mathematics, (M. Klerer and J. Reinfeld, eds.l. Academic Press, New York, 1968, pp. 301-313.
Rice, J. R, "A Polyalgorithm for the Automatic Solution of Nonlinear Equations," Proc. ACM National Conference, 1969, pp.
179-183.
Roman, R V., Symes, L. R., "Implementation Considerations in a
~umerical Analysis Problem Solving System" in Interactive Systems for Experimental Applied Mathematics, (M. Klerer and J.
Reinfeld, eds.), Academic Press, New York, 1968, pp. 400-410.
Symes, L. R., Roman, R. V., "Structure of a Language for a
Numerical Analysis Problem Solving System" in Interactive Systems for Experimental Applied Mathematics, (M. Klerer and J.
Reinfelds, eds.), Academic Press, New York, 1968, pp. 67-78.
Symes, L. R, "Manipulation of Data Structures in a Numerical
Analysis Problem Solving System," Proc. Spring Joint computer
Conference, AFIPS, Vol. 36, 1970, p. 157.
Symes, L. R., "Evaluation of NAPSS Expressions Involving
Polyalgorithms, Functions, Recursion and Untyped Variables," in
Mathematical Software (J. R. Rice, ed.), Academic Press, new
York, 1971, pp. 261-274.

National Computer Conference, 1973

The correctness of programs for
numerical computation
byT. E. HULL
University of Toronto
Toronto, Canada

ABSTRACT
Increased attention is being paid to techniques for
proving the correctness of computer programs, and the
problem is being approached from several different points
of view. For example, those interested in systems programming have placed particular emphasis on the importance of language design and the creation of well-structured programs. Others have been interested in more
formal approaches, including the use of assertions and
automatic theorem proving techniques. Numerical analysts must cope with special difficulties caused by round
oft' and truncation error, and it is the purpose of this
talk to show how various techniques can be brought
together to help prove the correctness of programs for
numerical computation.

The Society for Computer Simulation Session

The changing role of simulation and
the simulation councils
by JOHN MCLEOD

Simulation Councils, Inc.
La J olIa, California

ABSTRACT
Simulation in the broadest sense is as old as man.
Everyone has a mental model of his world. Furthermore
he will use it to investigate-mentally-the possible
results of alternative courses of action.
Simulation as we know it, the use of electronic circuits
to m9del real or ilI!~gi!lary .thi1).g§L beg~n about 3f,i -years
ago. Since that time we have seen such vast changes in
both the tools and the techniques of simulation that only
the underlying philosophy remains unchanged.
And the uses and abuses of simulation have changed
radically, too. Seldom has a technology, developed primarily to serve one industry-in the case of simulation
the aerospace industry --so permeated seemingly unrelated fields as has simulation. Today simulation is used
as an investigative tool in every branch of science, and in
many ways that by no stretch of the term can be called
science.
These changes have had their impact on our society,
too. The first Simulation Council was founded in 1952
after we had tried in vain to find a forum for discussion of
simulation among the established technical societies. As
interest grew other Simulation Councils were organized,
and in 1957 they were incorporated and became known as
Simulation Councils, Inc. Because the nine regional
Simulation Councils now comprise the only technical
society devoted exclusively to advancing the state-of-theart of simulation and serving those people concerned with
simulation, we are now known as SCS, the Society for
Computer Simulation.
In 1952 the analog computer was the best tool for simulation, and not one of the technical societies concerned
with the up-and-coming digital computers was interested
in the analog variety. So circumstances, not purpose,
decreed that the Simulation Councils should become
thought of as the analog computer society. We are not,
and never have been; the Society for Computer Simulation is concerned with the development and application of
the technology, not the tool!

That being the case, and realizing the applicability of
the simulation technology to the study of complex systems in other fields, the society fostered the necessary
technolog-j transfer by soliciting and publishing articles
describing applications first in medicine and biology, and
for the last several years, in the social sciences.
To foster the change in role of simulation from that of a
tool for the aerospace industry to that of a means for
studying and gaining and understanding of the problems
of our society required that the society also change. This
change was first reflected in the technical content of our
journal Simulation. It has always been our policy to publish articles describing unusual applications of simulation, but until a few years ago that was the only reason
material describing a socially relevant use of simulation
appeared in Simulation. Now it is our policy to solicit
such_ articles, .and.publish as .many as are approved by
our editorial review board. Therefore much of the material in our journal is now concerned with socially relevant
issues.
The Society for Computer Simulation also publishes a
Proceedings series. Of the three released to date, all are
relevant to societal problems.
The changing role of the society is also evidenced by
changes in official policy and in the organization itself.
The change in policy was elucidated by our President in
an article published in the April 1970 issue of Simulation,
which stated in part" ... the Executive Committee feels
that [our society's] primary mission today should be to
assist people who want to use simulation in their own
fields and particularly to assist people who are dealing
with the world's most urgent and difficult [societal]
problems ... "
The principal organizational change is the establishment of the World Simulation Organization to stimulate
work towards the development of simulation technology
applicable to the study of problems of our society from a
global point of view.
Concomitant with the spread of simulation to all disciplines has been the increase in interest within technical
societies which are only peripherally concerned with
simulation. Although these societies are primarily dedicated to other fields, several have formed committees or
special interest groups with aims and objectives similar to
those of the Society for Computer Simulation.
However, the Society for Computer Simulation remains
the only technical society dedicated solely to the service
of those concerned with the art and science of simuiation,
and to the improvement of the technology on which they
must rely. That others follow is a tribute to our leadership.

National Computer Conference, 1973

Up, up and away

Policy models-Concepts and rules-ofthumb

by THOMAS NAYLOR
Duke University
Durham, North Carolina

by PETER w. HOUSE
Environmental Protection Agency
Washington, D.C.

ABSTRACT
ABSTRACT
In 1961, Jay Forrester introduced economists, management scientists and other social scientists to a new methodology for studying the behavior of dynamic systems, a
methodology which he called Industrial Dynamics. Following closely on the heels of Industrial Dynamics was
Urban Dynamics, which purported to analyze the nature
of urban problems, their cases, and possible solution to
these problems in terms of interactions among components of urban systems. More recently, Forrester has
come forth with World Dynamics. We and the inhabitants of the other planets in our universe are now anxiously awaiting the publication of Universe Dynamics, a
volume which is to be sponsored by the Club of Olympus,
God, the Pope, Buddha, Mohammed, and the spiritual
leaders of several other major religions of this world and
the universe. Not unlike World Dynamics and other
books by Jay Forrester, Universe Dynamics will be characterized by a number of distinct features. These features
will be summarized in this paper.
In this presentation we shall comment on the methodology used by Forrester in World Dynamics as well as the
methodology which is being set forth by his disciples who
publish The Limits of Growth and the other people
involved in the Club of Rome project. We shall address
ourselves to the whole question of the feasibility of constructing models of the entire world and to model structures alternative to the one set forth by Forrester, et al.
It is first necessary to consider what possible objectives
one might have in trying to prove programs correct, since
different correctness criteria can be relevant to any particular program, especially when the program is to be
used for numerical computation. Then it will be shown
that careful structuring, along with the judicious use of
assertions, can help one to organize proofs of correctness.
Good language facilities are needed for the structuring,
while assertions help make specific the details of the
proof.
Examples from linear algebra, differential equations
and other areas will be used to illustrate these ideas. The
importance of language facilities will be emphasized, and
implications for Computer Science curricula will be
pointed out. A useful analogy with proofs of theorems in
mathematics and the relevance of this analogy to certification procedures for computer programs will be discussed.

The desire to build policy models or models for policy
makers is based on two foundations. First, the need to
solicit funds to pay for the construction of models means
that those who want to construct models have to promise
a "useful" product. Since a large portion of the models
built are to support some level of policy, public or private,
there is a deliberate attempt to promise output which will
be useful to the decision process. Secondly, it is clear
from history that the advisor to the throne is a coveted
position and one dreamed of by many scientists. It is also
clear that the day is coming when models will playa large
role in making such policy. The advisory role then shifts
to the model builder.
Unfortunately, the reality of model development for the
policy level does not appear to agree with the rhetoric.
This presentation will review the concept of policy models
and suggest some rules-of-thumb for building them.

The Seciety fer Cemputer Simulatien Sessien

On validation of simulation models
by GEORGE S. FISHMAN

Yale University
New Haven, Connecticut

ABSTRACT
Befere an investigater can claim that his simulatien
medel is a useful tee 1 fer studying behavier under new
hypethetical cenditiens, he is well advised to. check its
censistency with the true system, as it exists befere any
change is made. The success ef this validatien establishes
a basis fer cenfidence in results that the medel generates
under --new- conditions_After-all,- if a model-cannot ;rep-roduce system behavier without change, then we hardly
expect it to. preduce truly representative results with
change.
The preblem ef hew to. validate a simulatien model
arises in every simulatien study in which seme semblance
ef a system exists. The space deveted to. validatien in
Nayler's boek Computer Simulatien Experiments with
Models of Economic Systems indicates both the relative
importance of the tepic and the difficulty of establishing
universally applicable criteria fer accepting a simulatien
model as a valid representatien.
One way to. approach the validation of a simulation
model is through its three essential cempenents; input,
structural representation and eutput. For example, the
input censist of exegeneus stimuli that drive the model
during a run. Censequently one would like to. assure
himself that the probability distributions and time series
representations used to characterize input variables are
consistent with available data. With regard to. structural
representation one would like to. test whether or not the
mathematical and logical representations do not conflict
with the true system's behavier. With regard to output
ene ceuld feel cemfortable with a simulation model if it
behaved similarly to. the true system when expesed to. the
same input.
Interestingly enough, the greatest effort in medel validatien ef large econometric medels has concentrated on
structural representation. No. doubt this is due to the fact
that regression methods, whether it be the simple leastsquares methed or a more comprehensive simultaneous
equatiens techniques, in addition to providing precedures
for parameter estimation, facilitate hypothesis testing
regarding structural representation. Because of the availability of these regression methods, it seems hard to
believe that at least some part of a medel's structural
representation cannot be validated. Lamentably, seme
researchers choose to discount and avoid the use of available test precedures.
With regard to input analysis, techniques exist for
determining the temporal and probabilistic characteristics of exogeneous variables. Fer example the auteregres-

sive-moving average schemes described in Box and
Jenkins' beok, Time Series Analysis: Forecasting and
Control, are available today in canned statistical computer programs. Maximum likeliheed estimation procedures are available for mest commen prebability distribution and tables based on sufficient statistics have
begun to appear in the literature. Regardless of how little
data is available, a medel's use would benefit from a
conscientious effort to characterize the mechanism that
produced those data.
As mentioned earlier a check of censistency between
model and system eutput in res pense to the same input
would be an apprepriate step in validation. A natural
question that arises is: What ferm should the consistency
check take? One approach might go as fellows: Let Xl>
... , Xn be the medel's output in n consecutive time intervals-and let Yn . . .; -¥n-OO-tM-system's -0Utput -fuf n consecutive time intervals in response to the same stimuli.
Test the hypethesis that the joint prebability distribution
of Xl> ... , Xn is identical with that ef Y1, • • • , Y n.
My ewn feeling is that the above test is too stringent
and creates a misplaced emphasis en statistical exactness.
I weuld prefer to. frame output validatien in mere of a
decision making centext. In particular, one questien that
seems useful to answer is: In response to the same input,
does the model's output lead decision makers to take the
same action that they would take in respense to the true
system's eutput? While less stringent than the test first
described, its implementation requires access to. decision
makers. This seems to me to. be a desirable requirement
for enly through continual interaction with decision
makers can an investigator hope to gauge the sensitive
issues to. which his model should be respensive and the
degree ef accuracy that these sensitivities require.

National Computer Conference, 1973

In the beginning
by HOWARD CAMPAIGNE
Slippery Rock State Teachers College
Slippery Rock, Pennsylvania

ABSTRACT
The history of computers has been the history of two
components; memories and software. These two depend
heavily on each other, and all else depends on them.
The early computers had none of either, it almost
seems in retrospect. The Harvard Mark I had 132 words
of 23 decimal digits, usable only for data. ENIAC had
ten registers of ten decimals, each capable of doing
arithmetic.
It was von Neuman who pointed out that putting the
program into the memory of ENIAC (instead of reading it
from cards) would increase the throughput. Thereafter
computers were designed to have data and instructions
share the memory.
The need for larger storage was apparent to all, but
especially to programmers. EDVAC, the successor to
ENIAC, had recirculating sounds in mercury filled pipes
to get a thousand words of storage. The Manchester
machine had a TV tube to store a thousand bits.
Then the reliable magnetic core displaced these expedients' and stayed a whole generation. It was only in recent
times when larger memories became available that the
programmer had a chance. And of course it is his sophisticated software which makes the modern computer system responsive and effective.

Factors affecting commercial
computers system design in the
seventies
by WILLIAM F. SIMON
Sperry UNIVAC
Blue Bell, Pennsylvania

ABSTRACT
The design of a digital computer for the commercial
market today must, of course, face up to the pervasive
influence of IBM. But technological maturity in some
areas is slowing the rate of change so that designs seem to
converge on certain features. Microprogramming of the
native instruction set (or sets?) with emulation of a range
of older systems is such a feature. Virtual memory
addressing may be another. Characteristics of main stor-

age, random access mass storage devices, data exchange
media seem to converge while terminals and communications conventions proliferate and diverge. Some reasons
for these phenomena are evident; others will be suggested.
Whatever happened to hybrid packaging, thin films,
large scale integration, and tunnel diodes? The more
general question is: why do some technologies flourish
only in restricted environments, or never quite fulfill the
promise of their "youth?" Or is their development just
slower than we expected? While these answers cannot be
absolute, some factors affecting the acceptance of new
technologies can be identified.

Factors impacting on the evolution of
military computers
by GEORGE M. SOKOL
US Army Computer Systems Command
Fort Belvoir, Virginia

ABSTRACT
This paper will trace Army experience in ADP for the
combat environment, with emphasis on the role of software as a factor in influencing computer organization and
design. Early Army activity on militarized computers
resulted in the Fieldata family of computers, a modular
hierarchy of ADP equipment. Subsequently, ~oftware
considerations and the evolution of functional requirements resulted in extended use of commercially available
computers mounted in vehicles. The balance between
central electronic logic and peripheral capability is central to the design of militarized computers, but constraints of size, weight and ruggedness have greatly limited the processing capability of fieldable peripheral
equipment. The systems acquisition process also impacts
on the available characteristics of militarized computers.

Modeling and simulation in the process industries
by CECIL L. SMITH and ARMANDO B. CORRIPIO
Louisiana State University
Baton Rouge, Louisiana

and
RA YMOND GOLDSTEIN
Pica tinny Arsenal
Dover, New Jersey

builds up, the drainage rate decreases and the retention
increases. This process continues until all of the free liquid has drained through the wire. In general, these processes are not well-understood (especially from a quantitative standpoint), and as a result, the equations used to
describe them have been primarily empirical.
The action of the suction boxes and press rolls is also a
physical process, and again are not well-understood. Similarly, the drying of sheets is also a complex physical
process .. Initially, the sheet contains a high percentage of
water, and it is easily driven off. But as the sheet becomes
drier, the remaining water molecules are more tightly
bound (both chemically and physically) to the fiber, and
the drying rate decreases. Quantitatively, the relationships are not well-developed, and again empiricism is
relied upon quite heavily.
A model of the paper machine should be capable of
relating the final sheet density (lbs/ft2), sheet moisture,
and other similar properties to inputs such as stock flow,
machine speed, dryer steam pressure, etc.

I:\fTRODUCTION
The objective of this paper is to present what is at least
the authors' general assessment of the state-of-the-art of
modeling and simulation in the process industries, which
in this context is taken to include the chemical, petrochemical, pulp and paper, metals, waste and water treatment industries but excluding the manufacturing industries such as the automobile industry. Since a number of
texts l.2.3 are available on this topic for those readers interested in a more technical treatment, this discussion will
tend to be more general, emphasizing such aspects as
economic justification, importance of experimental and/
or plant data, etc.
EXAMPLES

Paper machine
In the process customarily used for the manufacture of
paper, an aqueous stream consisting of about 0.25 percent
by weight of suspended fiber is jetted by a head box onto a
moving wire. As the water drains through the wire, a certain fraction of the fiber is retained, forming a mat that
subsequently becomes a sheet of paper. The wire with the
mat on top passes over suction boxes to remove additional
water, thereby giving the mat sufficient strength so that it
can be lifted and passed between press rolls. It then
enters the dryer section, which consists of several steamheated, rotating cylinders that provide a source of heat to
vaporize the water in the sheet. The final sheet generally
contains from 5 to 10 percent water by weight.
The paper machine is a good example of a model consisting almost entirely of relationships to describe physical processes. The formation of the mat over the wire is a
very complex physical process.'·5 Initially, the wire has no
mat on top, and the drainage rate is high but the retention
(fraction of fiber retained on wire) is low. As the mat

TNT process
Whereas the model for the paper machine consists
almost entirely of relationships describing physical processes, the description of chemical processes forms the
heart of many models. For example, the manufacture of
trinitrotoluene (TNT) entails the successive nitration of
tol uene in the presence of strong concentrations of nitric
and sulphuric acids. In current processes, this reaction is
carried out in a two phase medium, one phase being
largely organic and the other phase being largely acid. 6
According to the currently accepted theory, the organic
species diffuse from the organic phase to the acid phase;
where all reactions occur. The products of the reaction
then diffuse back into the organic phase.
In this process, the primary reactions leading to the
production of TNT are well-known at least from a stoichi53

National Computer Conference, 1973

ometric standpoint. However, many side reactions occur,
including oxidation of the benzene ring to produce gaseous products (oxides of carbon and nitrogen). These
reactions are not well-understood, but nevertheless must
be included in a process model. Similarly, the relationships describing the diffusion mechanism are complex
and include constants whose quantitative values are not
available. In this particular process, the solubility of the
organic species in the acid phase is not quantitatively
known.
From a model describing the TNT process, one should
be able to compute the amount of product and its composition from such inputs as feed flows and compositions,
nitrator temperatures, etc.
STEADY-STATE VS. DYNAMIC MODELS
A steady-state model is capable of yielding only the
equilibrium values of the process variables, whereas a
dynamic process model will give the time dependence of
the process variables.
Using the paper machine as an example, the design of
the plant would require a model that gives the final sheet
moisture, density, and other properties obtained when the
inputs are held at constant values for long periods of time.
This would be a steady-state model. On the other hand,
one of the most difficult control problems in the paper
industry occurs at grade change. 7 For example, suppose
the machine has been producing paper with a sheet density of 60 lbs/ 1000ft2. Now the necessary changes must be
implemented so that the machine produces paper with a
sheet density of 42 lbs/l000ft 2. Since virtually all of the
paper produced in the interim must be recycled, the time
required to implement the grade change should be minimized. Analysis of this problem requires a model that
gives the variation of the paper characteristics with time.
This would be a dynamic model.
ECONOMIC JUSTIFICATION
Due to the complexity of most industrial processes,
development of an adequate process model frequently
requires several man-years to develop, significant outlays
for gathering data, and several hours of computer time.
Therefore, some thought must be given to the anticipated
returns prior to the start of the project. In essence, there
is frequently no return from just developing a model; the
return comes from model exploitation.
Virtually every project begins with a feasibility study,
which should identify the possible ways via which a
model can be used to improve process performance, estimate the returns from each of these, develop specific
goals for the modeling effort (specify the sections of the
process to be modeled; specify if the model is to be
steady-state or dynamic, etc.), and estimate the cost of
the modeling efforts. Unfortunately, estimating returns
from model exploitation is very difficult. Furthermore,
return" e:m be nivined into tangiblf' rf'hlrnR for which

dollar values are assigned and intangible returns for
which dollar values cannot readily be assigned. For
example, just the additional insight into the process
gained as a result of the modeling effort is valuable, but
its dollar value is not easily assigned. Perhaps the day
will come when the value of process modeling has been
established to the point where models are developed for
all processes; however, we are not there yet.
For many processes, the decision as to whether or not to
undertake a modeling project is coupled with the decision
as to whether or not to install a control computer, either
supervisory or DDC. In this context, perhaps the most
likely subjects are plants with large throughputs, where
even a small improvement in process operation yields a
large return due to the large production over which it is
spread. B Many highly complex processes offer the opportunity to make great improvements in process operation,
but these frequently necessitate the greatest effort in
model development.
Typical projects for which a modeling effort can be
justified include the following:
1. Determination of the process operating conditions
that produce the maximum economic return.
2. Development of an improved control system so that
the process does not produce as much off-specification product or does not produce a product far above
specifications, thereby entailing a form of "product
give-away." For example, running a paper machine
to produce a sheet with 5 percent moisture when the
specification is 8 percent or less leads to product
give-away in that the machine must be run slower in
order to produce the lower moisture. Also, paper is
in effect sold by the pound, and water is far cheaper
than wood pulp.
3. Design of a new process or modifications to the current process.

Although many modeling efforts have been in support
of computer control installations, this is certainly not the
only justification. In fact, in many of these, hindsight has
shown that the greatest return was from improvements in
process operation gained through exploitation of the
model. In many, the computer was not necessary in order
to realize these improvements.
MODEL DEVELOPMENT
In the development of a model for a process, two distinct approaches can be identified:
1. Use of purely empirical relationships obtained by
correlating the values of the dependent process variables with values of the independent process variables.
2. Development of detailed heat balances, material
balances, and rate expressions, which are then
romhinf'n to form the OVPTl'Ill monf'l of the process.

Modeling and Simulation in the Process Industries

The first method is purely empirical, whereas the second
relies more on the theories regarding the basic mechanisms that proceed within the process.
'Nhile it may not be obvious at first, both of these
approaches are ultimately based on experimental data.
Since regression is used outright to obtain the empirical
model, it is clearly based on experimental data. For any
realistic process, the detailed model encompassing the
basic mechanisms will contain parameters for which no
values are available in the literature. In these cases, one
approach is to take several "snapshots" of the plant,
where the value of as many process variables as possible
are obtained. In general, the normal process instrumentation is not sufficient to obtain all of the needed data.
Additional recording points are often temporarily added,
and samples are frequently taken for subsequent laboratory analysis. With this data available, a multivari:,1ble
search technique such as Pattern 13 ,14 can be used to determine the model parameters that produce the best fit of
the experimental data.
In efforts of this type, the availability of a digital
computer for data logging can be valuable. The proper
approach is to determine what data is needed in the
modeling effort, and then program the computer to obtain
this data from carefully controlled tests on the process.
The use of a digital computer to record all possible values
during the normal operation of the process simply does
not yield satisfactory data from which a model can be
developed.
Another point of contrast between the empirical model
and the basic model involves the amount of developmental effort necessary. The empirical model can be developed with much less effort, but on the other hand, it
cannot be reliably used to predict performance outside
the range within which the data was obtained. Since the
detailed model incorporates relationships describing the
basic mechanisms, it should hold over a wider range than
the empirical model, especially if the data upon which it
is based was taken over a wide range of process operating
conditions.
NUMERICAL METHODS
In the development and exploitation of process models,
numerical techniques are needed for the following operations:
1. Solution of large sets of nonlinear algebraic equa-

tions (frequently encountered in the solution of
steady-state models).
2. Solution of large sets of nonlinear, first-order differential equations (frequently encountered in the solution of unsteady state models).
3. Solution of partial differential equations (usually
encountered in the solution of an unsteady-state
model for a distributed-parameter system).
4. Determination of the maximum or minimum of a
high-order, nonlinear function (usually encountered

in either the determination of the model parameters
that best fit the experimental data or in the determination of the process operating conditions that produce the greatest economic return).
Only digital techniques are discussed in this section;
analog and hybrid techniques will be described subsequently.
In general, the numerical techniques utilized for process models tend to be the simpler ones. The characteristic
that generally presents the most difficulties is the size of
the problems. For example, the model of the TNT plant
described in Reference 9 contains 322 nonlinear equations plus supporting relationships such as mole fraction
calculations, solubility relationships, density equations,
etc.
In the solution of sets of nonlinear algebraic equations,
the tendency is to use direct substitution methods in an
iterative approach to solving the equations. In general, a
process may contain several recycle loops, each of which
requires an iterative approach to solve the equations
involved. The existence of nested recycle loops causes the
number of iterations to increase significantly. For example, the steady-state model for the TNT process involves
seven nested recycle loops. Although the number of iterations required to obtain a solution is staggering, the problem is solved in less than a minute on a CDC 6500.
A few types of equations occur so frequently in process
systems that special methods have been developed for
them. An example of such a system is a countercurrent,
stagewise contact system, which is epitomized by a distillation column. For this particular system, the Thetamethod has been developed and used extensively. 10
In regard to solving the ordinary differential equations
usually encountered in dynamic models, the simple Euler
method has enjoyed far more use than any other method.
The advantages stemming from the simplicity of the
method far outweigh any increase in computational efficiency gained by using higher-order methods. Furthermore, extreme accuracy is not required in many process
simulations. In effect, the model is only approximate, so
why demand extreme accuracies in the solution?
Although once avoided in process models, partial differential equations are appearing more regularly. Again,
simple finite difference methods are used most frequently
in solving problems of this type.
Maximization and minimization problems are encountered very frequently in the development and exploitation
of process models. One very necessary criterion of any
technique used is that it must be able to handle constraints both on the search variable and on the dependent
variables computed during each functional evaluation.
Although linear programming handles such constraints
very well, process problems are invariably nonlinear.
Sectional linear programming is quite popular, although
the conventional multi variable search techniques coupled
with a penalty function are also used.
Over the years, a number of simulation languages such
as CSMP and MIMIC have been used in simulation. 11 On

National Computer Conference, 1973

the steady-state side, a number of process simulation
packages such as PACER, FLOTRAN, and others have
appeared. 12 An alternative to these is to write the program
directly in a language such as Fortran.
One of the problems in steady-state simulation is the
need for extensive physical property data. Many of the
steady-state simulation packages have a built-in or readily available physical properties package that is a big plus
in their favor. However, many prefer to use subroutines
for physical properties, subroutines for the common unit
operations, and subroutines to control the iteration procedures, but nevertheless write in Fortran their own master
or calling program and any special subroutine for operations unique to their process.
For dynamic process models with any complexity,
Fortran is almost universally preferred over one of the
simulation languages.
COMPUTATIONAL REQUIREMENTS
With the introduction of computing machines of the
capacity of the CDC 6500, Univac 1108, IBM 360/65,
and similar machines produced by other manufacturers,
the computational capacity is available to solve all but
the largest process simulations. Similarly, currently available numerical techniques seem to be adequate for all but
the very exotic processes. This is not to imply that
improved price/performance ratios for computing machines would be of no benefit. Since the modeling effort
is subject to economic justification, a significant reduction
in computational costs would lead to the undertaking of
some modeling projects currently considered unattractive.
As for the role of analog and hybrid computers in process simulation, no significant change in the current situation is forecast. Only for those models whose solution
must be obtained a large number of times can the added
expense of analog programming be justified. However, for
such undertakings as operator training, the analog computer is still quite attractive.

coefficients occurring in the relationships comprIsmg a
process model are simply not available for most processes
of interest.
This paper has attempted to present the state-of-the-art
of process modeling as seen by the authors. This discussion has necessarily been of a general nature, and exceptions to general statements are to be expected. In any
case, these should always be taken as one man's opinion
for whatever it is worth.
ACKNOWLEDGMENT
Portions of the work described in this paper were supported by the Air Force Office of Scientific Research
under Contract F -44620-68-C-0021.
REFERENCES
1. Smith, C. L., Pike, P. W., Murrill, P. W., Formulation and Optimi-

2_
3.
4_

6.
7_

8.
9.

10_
11.

SUMMARY
At this stage of process modeling and simulation, the
generally poor understanding of the basic mechanisms
occurring in industrial processes is probably the major
obstacle in a modeling effort. Quantitative values for diffusions, reaction rate constants, solubilities, and similar

12.

13.

14_

zation of Mathematical Models, International Textbook Company,
Scranton, Pennsylvania, 1970.
Himmelblau. D. M .• Bischoff. K R, Process Analysis and Simulation-Deterministic Systems, Wiley, New York, 1968.
Franks, R. G_ K, Modeling and Simulation in Chemical Engineering, Wiley-Interscience, New York, 1972.
Schoeffler, J_ D., Sullivan, P_ R., "A Model of Sheet Formation
and Drainage on a Fourdrinier," Tappi, VoL 49, No.6, June 1966,
pp_ 248-254_
Sullivan, P_ R., Schoeffler, J_ D., "Dynamic Simulation and Control of the Fourdrinier Paper-Making Process," IFAC Congress,
London, June 20-26.1966.
Slemrod, S., "Producing TNT by Continuous Nitration," Ordnance, March-April 1970, pp_ 525-7.
Brewster, D. R, The Importance of Paper Machine Dynamics in
Grade Change Control, Preprint No. 17.2-3-64, 19th Annual ISA
Conference and Exhibit, New York, October 12-15,1964_
Stout, T. M., "Computer Control Economics," Control Engineering, VoL 13, No.9, September 1966, pp_ 87 -90_
Williams, J. K, Michlink, F. P., Goldstein, R., Smith, C. L., Corripio, A. R, "Control Problem in the Continuous TNT Process,"
1972 International Conference on Cybernetics and Society, Washington, D.C_, October 9-12, 1972.
Holland, C. D., Multicomponent Distillation, Prentice Hall, Englewood Cliffs, New Jersey, 1963.
Smith, C. L., "All-Digital Simulation for the Process Industries,"
ISA Journal, VoL 13, No.7, July 1966, pp_ 53-60.
Evans, L. R, Steward, D. G., Sprague, C. R., "Computer-Aided
Chemical Process Design," Chemical Engineering Progress, VoL
64, No.4, April 1968, pp. 39-46.
Hooke, R., Jeeves, T_ A., "Direct Search Solution of Numerical
and Statistical Problems," The Journal of the Association for
Computing Machinery, VoL 8, No_ 2, April 1961, pp. 212-229_
Moore, C_ F., Smith, C. L., Murrell, P. W., IBM SHARE Library,
LSU, PATE, SDA No_ 3552,1969.

Needs for industrial computer standards-As satisfied
by ISA's programs in this area
by THEODORE J. WILLIAMS
Purdue University
West Lafayette, Indiana

and

KIRWIN A. WHITMAN
Allied Chemical Corporation
Morristown, New Jersey

INTRODUCTION

ACCEPTA~CE

TESTING OF DIGITAL PROCESS

COMPUTERS
Never before has the relevancy of institutions been questioned as critically as today. Many of us have now
learned what should have always been evident; that the
key to relevance is the satisfaction of needs. The computer industry, and those technical societies that support
it, should view this new emphasis on service as an opportunity to stimulate its creative talents. The implication of
the "future shock" concept requires that we must anticipate problems if we are ever to have enough time to solve
them.
But in what way can a technical society serve; should it
be a responder or a leader? Ironically, to be effective, it
must be both. It must respond to the requests of individuals in the technical community to use the society's apparatus for the development, review and promulgation of
needed standards. The development and review stages
can be done by groups of individuals, but it remains for
the technical society to exert a leadership role to make
these standards known and available to all who might
benefit from them.
Thus, our purpose here is to bring to your attention two
new, and we feel exciting, industrial computer standards
developments that have been undertaken by the Instrument Society of America, as well as a discussion of further actions contemplated in this field. The first is RP55,
"Hardware Testing of Digital Process Computers." The
second is the work cosponsored with Purdue University
on software and hardware standards for industrial computer languages and interfaces. This latter work is exemplified by the ISA series of standards entitled S61, "Industrial Computer FORTRAN Procedures," among others.
Both standards development projects have succeeded in
furthering ISA's commitment "to provide standards that
are competent, timely, unbiased, widely applicable, and
authoritative."

Needs
A Hardware Testing Committee was formed in October
1968 because a group of professionals recognized certain
specific needs of the process computer industry. The user
needed a standard in order to accurately evaluate the
performance of a digital computer and also to avoid the
costly duplication of effort when each user individually
writes his own test procedures. Conversely, the vendor
needed a standard to avoid the costly setting up of different tests for different users and also to better understand
what tests are vital to the user.

Purpose
The purpose of the committee has been to create a
document that can serve as a guide for technical personnel whose duties include specifying, checking, testing, or
demonstrating hardware performance of digital process
computers at either vendor or user facilities. By basing
engineering and hardware specifications, technical advertising, and reference literature on this recommended
practice, there will be provided a clearer understanding of
the digital process computer's performance capabilities
and of the methods used for evaluating and documenting
proof of performance. Adhering to the terminology, definitions, and test recommendations should result in clearer
specifications which should further the understanding
between vendor and user.

Scope
The committee made policy decisions which defined
the scope of this recommended practice to:

National Computer Conference, 1973

(1) Concern digital process computer hardware testing

rather than software testing. However, certain
software will be necessary to perform the hardware
tests.
(2) Concern hardware test performance at either the
vendor's factory or at the user's site. This takes
into account that it would be costly for a vendor to
change his normal test location.
(3) Concern hardware performance testing rather than
reliability or availability testing. These other characteristics could be the subject for a different series
of long term tests at the user's site.
(4) Concern hardware testing of vendor supplied
equipment rather than also including user supplied
devices. Generally, the vendor supplied systems
includes only that equipment from the input terminations to the output terminations of the computer
system.
(5) Consider that specific limits for the hardware tests
will not exceed the vendor's stated subsystem specifications.
(6) Consider that before the system contract is Rigned,
the vendor and user will agree upon which hardware testing specifications are applicable. It was
not the intent of the standard to finalize rigid specifications or set specific rather than general acceptance criteria. This recognizes that there are many
differences both in vendor product design and in
user requirements.
(7) Consider that the document is a basic nucleus of
tests, but other tests may be substituted based on
cost, established vendor procedures, and changing
state of the art. Although requirements to deviate
from a vendor's normal pattern of test sequence,
duration or location could alter the effectiveness of
the testing, it could also create extra costs.
(8) Consider that the document addresses a set of tests
which apply to basic or typical digital process
computers in today's marketplace. Where equipment configurations and features differ from those
outlined in this standard, the test procedures must
be modified to account for the individual equipment's specifications.
(9) Consider that the document does not necessarily
assume witness tests (i.e., the collecting of tests for
a user to witness). This collection mayor may not
conform to the vendor's normal manufacturing
approach. There are three cost factors which
should be considered if a witness test is negotiated:
a. Added vendor and user manhours and expenses.
b. Impact on vendor's production cycle and
normal test sequence.
c. Impact on user if tests are not performed correctly in his absence.
Recommended test procedures
It will not be attempted in this paper to detail reasons
for particular procedures in the areas of peripherals.

environmental, subsystem and interacting system tests.
Time will only permit naming the test procedure sections
and what they cover. In this way you may judge the
magnitude of this undertaking and the probable significance of this recommended practice.
(1) Central Processing Unit-including instruction
complement, arithmetic and control logic, input/
output adapters, I/O direct memory access channel, interrupts, timers and core storage.
(2) Data Processing Input/ Output Subsystems
including the attachment circuitry which furnishes
logic controls along with data links to the input/
output bus; the controller which provides the
buffer between the computer and the input/ output
device itself; and finally the input/ output devices
themselves.
(3) Digital Input/ Output-including operation, signal
level, delay, noise rejection, counting accuracy,
timing accuracy and interrupt operation.
(4) Analog Inputs-including address, speed, accuracy/linearity, noise, common mode and normal
mode rejection, input resistance, input over-voltage recover, DC crosstalk, common mode crosstalk and gain changing crosstalk.
(5) Analog Outputs-incl uding addressing, accuracy,
output capability, capacitive loading, noise, settling
time, crosstalk and droop rate for sample and hold
outputs.
(6) Interacting Systems-including operation in a
simulated real time environment in order to check
the level of interaction or crosstalk resulting from
simultaneous demands on the several subsystems
which make up the system.
(7) Environmental-including temperature
and
humidity, AC power and vibration.

Costs
The committee constantly had to evaluate the costs of
recommended tests versus their value. Typical factors
affecting the costs of testing are:
(1)
(2)
(3)
(4)
(5)
(6)
(7)
(8)

Number of separate test configurations required
Methods of compliance
Sequence, duration, and location of tests
Quantity of hardware tested
Special programming requirements
Special testing equipment
Effort required to prepare and perform tests
Documentation requirements

The additional testing costs may be justified through
factors such as reduced installation costs, more timely
installation, and early identification of application problems.

Needs for Industrial Computer Standards

Documentation
Another unique feature of this recommended practice is
that it has given special attention to documentation of
evidence of tests performed on the hardware. Three types
of documentation are proposed in order that the user may
choose what is most appropriate cost-wise for his situation.
Type 1 would include any statement or evidence
provided by the manufacturer that the hardware has
successfully passed the agreed-upon tests.
Type 2 would be an itemized check list indicating
contractually agreed-upon tests with a certification
for each test that had been successfully performed.
Type 3 would be an individual numerical data printout; histograms, etc., compiled during the performance of the tests.
It is, therefore, the aim to provide maximum flexibility in
documentation related to the testing.

Board of review
The committee was composed of eight vendors, eight
users, and two consultants. In addition to the considerable experience and varied backgrounds of the committee, an extensive evaluation by a Board of Review was
also required.
Serious effort was given to insuring that a wide
cross-section of the industry was represented on the
Review Board. Invitations were sent to the various ISA
committees, to attendees at the Computer Users Conference, and various computer workshops. Announcements
also appeared in Instrumentation Technology and Control Engineering. Interest was expressed by approximately 250 people, and these received the document
drafts. A very comprehensive questionnaire was also sent
to each reviewer in order that a more meaningful interpretation of the review could be made. Subsequently, 117
responses were received. In addition to the questionnaire
response, other comments from the Review Board were
also considered by the appropriate subcommittee and
then each comment and its disposition were reviewed by
the SP55 Committee. The magnitude of this effort can be
judged from the fact that the comments and their disposition were finally resolved on 44 typewritten pages.
The returned questionnaires indicated an overwhelming acceptance and approval of the proposed documents.
The respondents, who came from a wide variety of
industrial and scientific backgrounds, felt that it would
be useful for both vendors and users alike. They gave the
document generally high ratings on technical grounds,
and also as to editorial layout. Some reservation was
expressed about economic aspects of the proposed testing
techniques, which is natural considering that more testing
is caiied for than was previously done. However, ninetyone percent of the respondents recommended that RP55.1
be published as an ISA Recommended Practice." Only
three percent questioned the need for the document. The

responses were also analyzed for any generalized vendoruser polarity. Fortunately, the percentage of those recommending acceptance of the document were in approximate proportion to their percentages as vendors, users, or
consultants. In other words, there was no polarization into
vendor, user or consultant classes.
The recommended practice was subsequently submitted to the American National Standards Institute and is
presently being evaluated for acceptability as an ANSI
standard. ISA's Standards and Practices Board has met
with ANSI in order to adopt procedures permitting concurrent review by both ISA and ANSI for all future
standards.
PRESENT EFFORTS AT PROCESS CONTROL
SYSTEM LANGUAGE STANDARDIZATION
As mentioned earlier, standardization has long been
recognized as one means by which the planning, development, programming, installation, and operation of our
plant control computer installations as well as the training of the personnel involved in all these phases can be
organized and simplified. The development of APT and
its variant languages by the machine tool industry is a
very important example of this. The Instrument Society
of America has been engaged in such activities for the
past ten years, most recently in conjunction with the
Purdue Laboratory for Applied Industrial Control of
Purdue University, West Lafayette, Indiana.4.6
Through nine semiannual meetings the Purdue Workshop on Standardization of Industrial Computer Languages has proposed the following possible solutions to the
programming problems raised above, and it has achieved
the results listed below:
(1) The popularity of FORTRAN indicates its use as at
least one -of the procedural languages to be used as
the basis for a standardized set of process control
languages. It has been the decision of the Workshop
to extend the language to supply the missing functions necessary for process control use by a set of
CALL statements. These proposed CALLS, after
approval by the Workshop, are being formally
standardized through the mechanisms of the
Instrument Society of America. One Standard has
already been issued by ISA,7 another is being
reviewed at this writing, 8 and a third and last one is
under final development. 9
(2) A so-called Long Term Procedural Language or
L TPL is also being pursued. A set of Functional
Requirements for this Language has been
approved. Since the PL/ 1 language is in process of
standardization by ANSI (the American National
Standards Institute), an extended subset of it (in
the manner of the extended FORTRAN) will be
tested against these requirements. 12 Should it fail,
other languages will be tried or a completely new
one will be developed.

National Computer Conference, 1973

(3) The recognized need for a set of problem-oriented
languages is being handled by the proposed development of a set of macro-compiler routines which
will, when completed, allow the user to develop his
own special language while still preserving the
transportability capability which is so important
for the ultimate success of the standardization
effort. This latter will be accomplished by translating the former language into one or the other of the
standardized procedural languages before compilation.
(4) To establish the tasks to be satisfied by the above
languages, an overall set of Functional Requirements has been developed. 10
(5) In order that all Committees of the Workshop
should have a common usage of the special terms of
computer programming, the Glossary Committee of
the Workshop has developed a Dictionary for
Industrial Computer Programming which has been
published by the Instrument Society of America 11
in book form.
The Workshop on Standardization of Industrial Computer Languages is composed entirely of representatives
of user and vendor companies active in the on-line
industrial digital computer applications field. Delegates
act on their own in all Workshop technical discussions,
but vote in the name of their companies on all substantive
matters brought up for approval. It enjoys active representation from Japan and from seven European countries
in addition to Canada and the United States itself. Procedures used in meetings and standards development are
the same as those previously outlined for the Hardware
Testing Committee.
As mentioned several times before, it is the aim and
desire of those involved in this effort that the Standards
developed will have as universal an application as possible. Every possible precaution is being taken to assure
this.
The nearly total attention in these and similar efforts
toward the use of higher level languages means that the
vendor must be responsible for producing a combination
of computer hardware and of operating system programs
which will accept the user's programs written in the
higher level languages in the most efficient manner. A
relatively simple computer requiring a much higher use of
softw~re accomplished functions would thus be equivalent, except for speed of operation, with a much more
sophisticated and efficient computer with a correspondingly smaller operating system.
The present desire on the part of both users and vendors for a simplification and clarification of the present
morass of programming problems indicates that some
standardization effort, the Purdue cosponsored program,
or another, must succeed in the relatively near future.

Future possibilities and associated time scales
The standardized FORTRAN extensions as described
can be available in final form within the next one to two

years. Some of those previously made have been implemented already in nearly a dozen different types of
computers. The actual standardization process requires a
relatively long period of time because of the formality
involved. Thus, the 1974-75 period appears to be the key
time for this effort.
The work of the other language committees of the
Workshop are less formally developed than that of the
FORTRAN Committee as mentioned just above. Successful completion of their plans could result, however, in
significant developments in the Long Term Procedural
Language and in the Problem Oriented Languages areas
within the same time period as above.
In addition to its Instrument Society of America sponsorship' this effort recently received recognition from the
International Federation for Information Processing
(IFIP) when the Workshop was designated as a Working
Group of its Committee on Computer Applications in
Technology. The Workshop is also being considered for
similar recognition by the International Federation of
Automatic Control (IFAC).
As mentioned, this effort is achieving a very wide
acceptance to date. Unfortunately, partly because of its
Instrument Society of America origins and the personnel
involved in its Committees, the effort is largely based on
the needs of the continuous process industries. The input
of interested personnel from many other areas of activity
is very badly needed to assure its applicability across all
industries. To provide the necessary input from other
industries, it is hoped that one or more of the technical
societies (United States or international) active in the
discrete manufacturing field will pick up cosponsorship of
the standardization effort presently spearheaded by the
Instrument Society of America and, in cooperation with
it, make certain that a truly general set of languages is
developed for the industrial data collection and automatic
control field.
RECOMMENDED PRACTICES AND
STANDARDIZATION IN SENSOR-BASED
COMPUTER SYSTEM HARDWARE
In addition to the work just described in programming
language standardization, there is an equally vital need
for the development of standards or recommended practices in the design of the equipment used for the sensorbased tasks of plant data collection, process monitoring,
and automatic control. Fortunately, there is major work
under way throughout the world to help correct these
deficiencies as well.
As early as 1963 the Chemical and Petroleum Industries Division of ISA set up an annual workshop entitled
The User's Workshop on Direct Digital Control which
developed an extensive set of "Guidelines on Users'
Requirements for Direct Digital Control Systems." This
was supplemented by an equally extensive set of "Questions and Answers on Direct Digital Control" to define
and explain what was then a new concept for the application of digital computers to industrial control tasks. A re-

Needs for Industrial Computer Standards

cently revised version of these original documents is
available.6 The Workshop has continued through the
years, picking up cosponsorship by the Data Handling and
Computation Division and by the Automatic Control Division in 1968 when it renamed the ISA Computer Control Workshop. The last two meetings have been held at
Purdue University, West Lafayette, Indiana, as has the
Workshop on Standardization of Industrial Computer
Languages described above.
The ESONE Committee (European Standards of
Nuclear Electronics) was formed by the EURATOM in
the early 1960's to encourage compatibility and interchangeability of electronic equipment in all the nuclear
laboratories of the member countries of EURATOM. In
cooperation with the NIM Committee (Nuclear Instrumentation Modules) of the United States Atomic Energy
Commission,---they -have--r-ecent1-¥-developed a-co-mpl-etely

compatible set of interface equipment for sensor-based
computer systems known by the title of CAMAC.1- 3.13
These proposals merit serious consideration by groups in
other industries and are under active study by the ISA
Computer Control Workshop.
Japanese groups have also been quite active in the
study of potential areas of standardization. They have
recently developed a standard for a process control operator's console (non CRT based)l4 which appears to have
considerable merit. It will also be given careful consideration by the Instrument Society of America group.
It is important that the development of these standards
and recommended practices be a worldwide cooperative
endeavor of engineers and scientists from many countries.
Only in this way can all of us feel that we have had a part
in the development of the final system and thus assure its
overall acceptance by industry in all countries. Thus,
both the ISA Computer Control Workshop and the Language Standardization Workshop are taking advantage of
the work of their compatriots throughout the world in
developing a set of standards and recommended practices
to guide our young but possible overly-vigorous field.
While we must be careful not to develop proposals
which will have the effect of stifling a young and vigorously developing industry, there seems to be no doubt
that enough is now known of our data and control system
requirements to specify compatible data transmission
facilities, code and signal standards, interconnection
compatibility, and other items to assure a continued
strong growth without a self-imposed obsolescence of
otherwise perfectly functioning equipment.
SUMMARY
This short description has attempted to show some of the
extensive standards work now being carried out by the
Instrument Society of America in the field of the applica-

tions of digital computers to plant data collection, monito ring, and other automatic control tasks. The continued
success of this work will depend upon the cooperation
with and acceptance of the overall results of these developments by the vendor and user company managements
and the help of their personnel on the various committees
involved.

REFERENCES
1. CAMAC-A Modular Instrumentation System for Data Handling,
AEC Committee on Nuclear Instrument Modules, Report TID25875, United States Atomic Energy Commission, Washington,
D.C., July 1972.
2. CAMAC Organization of Multi-Crate System, AEC Committee on
N-ucleal' --I-Rstrumen-t-Modules-, Report TID 25816;-Bnited States
Atomic Energy Commission, Washington, D.C., March 1972.
3. Supplementary Information on CAMAC Instrumentation System,
AEC Committee on Nuclear Instrument Modules, Report TID
25877, United States Atomic Energy Commission, Washington,
D.C., December 1972.
4. Anon., Minutes, Workshop on Standardization of Industrial
Computer Languages, Purdue Laboratory for Applied Industrial
Control, Purdue University, West Lafayette, Indiana; February
17-21; September 29-0ctober 2,1969; March 2-6; November 9-12,
1970; May 3-6; October 26-29, 1971; April 24-27; October 2-5,
1972; May 7-10,1973.
5. Anon., "Hardware Testing of Digital Process Computers," ISA
RP55.1, Instrument Society of America, Pittsburgh, Pennsylvania,
October 1971.
6. Anon., Minutes, ISA Computer Control Workshop, Purdue Laboratory for Applied Industrial Control, Purdue University, West
Lafayette, Indiana; May 22-24; November 13-16, 1972.
7. Anon., "Industrial Computer System FORTRAN Procedures for
Executive Functions and Process Input-Output," Standard ISAS61.1, Instrument Society of America, Pittsburgh, Pennsylvania,
1972.
8. Anon., "Industrial Computer System FORTRAN Procedures for
Handling Random Unformatted Files, Bit Manipulation, and Data
and Time Information," Proposed Standard ISA-S6l.2, Instrument Society of America, Pittsburgh, Pennsylvania, 1972.
9. Anon., "Working Paper, Industrial Computer FORTRAN Procedures for Task Management," Proposed Standard ISA-S61.3,
Purdue Laboratory for Applied Industrial Control, Purdue University, West Lafayette, Indiana, 1972.
10. Curtis, R. L., "Functional Requirements for Industrial Computer
Systems," Instrumentation Technology, 18, No. 11, pp. 47-50,
November 1971.
11. Glossary Committee, Purdue Workshop on Standardization of
Industrial Computer Languages, Dictionary of Industrial Digital
Computer TerminoLogy, Instrument Society of America, Pittsburgh, Pennsylvania, 1972.
12. Pike, H. E., "Procedural Language Development at the Purdue
Workshop on Standardization of Industrial Computer Languages,"
Paper presented at the Fifth World Congress, International Federation of Automatic Control, Paris, France, June 1972.
13. Shea, R. F., Editor, CAMAC Tutorial Issue, IEEE Transactions on
NuclearScience, Vol. NS-18, Number 2, April 1971.
14. Standard Operator's Console Guidebook, JEIDA-17-1972, Technical Committee on Interface Standards, Japan Electronics Industry
Development Association, Tokyo, Japan, July 1972.

Quantitative evaluation of file management
performance improvements*
byT. F. McFADDEN
McDonnell Douglas Automation Company
Saint Louis, Missouri

and

J. C. STRAUSS
Washington University
Saint Louis, Missouri

IXTRODUCTIOX

Automation Company XDS Sigma 7 running under the
BT}I opE'rating system.
The modE'ls developed hE're are extremely simple, detE'rministic representations of important aspE'cts of filE' managemrnt. This usr of simple models to reprrsent very complex
systrms is finding incrrasing application in computrr system
performancE' work. The justification for working \\-ith these
simple models on this application are twofold:

Operating systE'ms generally provide file management sE'rvice
routines that are employed by usrr tasks to accE'SS secondary
storage. This paper is conccrnrd with quantitative evaluation
of several suggested performance improvements to the file
managemE'nt system of the Xerox Data Systems (XDS)
opE'rating systems.
The file management system of the new XDS UnivE'rsal
Time-Sharing System (UTS) operating systE'm includes the
same service routines employed by the older operating system-the Batch Time-Sharing :\Ionitor (BT:\I). :\Iodels for
both UTSI and BT.1P have been developed to facilitate performance investigation of CPU and core allocation strategies.
These models do not, however, provide capability to investigate performance of the file management strategies.
A \vealth of literature is available on file management systems. A report by Wilbur3 details a ne\v file management design for the Sigma Systems. Other articles havE' been published
to define basic file management concepts,4,5 to discuss various
organization techniques 4,5, 6 and to improve understanding of
the current Sigma file management systE'm. 6, 7 HowE'vE'r, there
is little published \vork on the performance of file management
systems.
The task undertaken here is to develop and test a simple
quantitative method to evaluate the performance of proposed
modifications to the file management system. :\lodels are
developed that reproduce current performance levels and
these models are employed to predict the performance improvements that will result from the implementation of
specific improvement proposals. The models are validated
against measured performance of the :\IcDonnell Douglas

1. File management system behavior is not well understood and simple models develop understanding of the
important prOCE'sses.
2. When applied properly, simple models can quantify
difficult design decisions.
The underlying hypothesis to this and other \vork with simple
models of computer systems is that system behavior must be
understood at each successive level of difficulty before proceeding to the next. The success demonstrated here in developing simple models and applying them in the design
process indicates that this present work is an appropriate
first level in the complexity hierarchy of file management
system models.
The work reported here has been abstracted from a recent
thesis. s Additional models and a more detailed discussion of
system measurement and model verification are presented in
Reference 8.
The paper is organized as follows. The next section describes the XDS file management system; current capabilities
and operation are discussed and models are developed and
validatrd for opening and reading a file. Several improvpment
proposals are then modeled and evaluated in the third section.

* Abstracted from an M. S. Thesis of the same title submitted to the
Sever Institute of Technology of Washington University by T. F.
McFadden in partial fulfillment of the requirements for the degree of
Master of Science, May 1972. This work was partially supported by
National Science Foundation Grant GJ-33764X.

CURREXT XDS FILE

:\fAl\AGE:\IEl'-~T SYSTE~I

This spction is divided into three parts: description of the
file management capabilities, description of the file manage63

National Computer Conference, 1973

ment. syst.em structur(', and d('velopm('nt and validation of
models for t.he open and rf'ad operations.

Description of capabilities
A file, as definf'd by XDS,1 is an organized coll('ction of
space on the sf'condary storage devices that may be creat('d,
retrieved, modified, or deleted only through a call on a file
management routine.
Each file is a collection of records. A record is a discrete
subset of the information in a file that is accf'ssed by the USf'r
independent of other records in the file. When the ~le is
created the organization of the rf'cords must be specIfied.
Records may be organized in a consecutive, keyed, or random
format.
The space uSf'd by a consf'cutivf' or kf'yed filf' is dynamically
controlled by the monitor; the space used by a random file
must be requested by the USf'r when the file is created and it
never changes until the file is relf'ased.
.
Open-When a file is going to be used it must bf' madf' avaIlable to the user via a file management routine callf'd OPEN.
When the file is openf'd, thf' user may specify one of the following modes: IN, that is, read only; OUT-w~ite only;
I NOUT-update ; OUTIX-scratch. Whpn a file IS opened
OUT or OUTIX it is being created; when it is openrd IX or
INOUT it must alrf'ady exist. Thf' opf'n routine will Sf't some
in-core pointers to the first record of t.hp file if it has been
openf'd I~ or I~OUT and to some free spacf' that has bee~
allocated for the file if it has been opened OUT or OUTr~.
These pointf's arf' never ust'd by thp ust'r dirf'ctly. When the
ust'r reads or writf's a rf'cord tht' in-corf' pointf'rs art' uSf'd by
file management to tract' the appropriatf' rf'cord.
Close-Whpn the user has completrd all oprrations on the
file he must call anothf'r routinp namf'd CLOSE. A filp can
be closed with RELEASE or with SAVE. If RELEASE is
specifipd then all spacf' currf'ntly allocatpd to thr filf' is placrd
back in the monitor's free spacr pool and all pointers are
deleted. If SAVE is specifipd thpn thp in-core pointt'rs are
written to file directories maintainrd by the monitor so that
the file can be found when it is next opened.
Read and W rite-There are a number of operations that
may be performed on records. The two that are of primary
interest are read and write. In a consecutive file the records
must be accessed in the order in \\'hich they are written.
Records in a keyed file can be accessed directly, with the associated key, or sequentially. Random files are accessed by
specifying the record number relative to the beginning of the
file. Random file records are fixed length (2048 characters).
When reading or writing the user specifies the number of
characters he wants, a buffer to hold them, and a key or record
number.

an account dirrctory (AD). Thrre is an rntry in the AD for
('ach account on the systrm that has a filp. Thp rpsult of the
AD sparch is a pointpr to the' fiIP dirpctory. Th('re' is only one
AD on th<' syst('m and it is maintainpd in the 'linked-sector'
format (doublr linke'd list of sector size [256 word] blocks).
Each ('ntry in the AD contains th(' account number and
the disc addrpss of the file directory (FD). An FD is a 'linkpdsector' list of filp names in the corresponding account. With
each file namf' is a pointer to t.he File Information Table
(FIT) for that file.
Th<> FIT is a 1024 charactpr block of information on this
file. It contains security, file organization, and allocation information. The FIT points to the table of keys belonging to
this file.
Figure 1 presents a schematic of the file structure.
Sequential Access and Keyed Structure-In describing record
access, attE'ntion is rE'stricted to spqupntial accessf's. The structure of consecutive and keyed filps is identical. Both file
organizations allow sE'quential accesses of records. Because the
structures are the same and both permit sequential accesses
there is no true conspcutivp organization. All of the code for
this organization is imbrdd('d in th(' k('yed file logic. The only
difference betwE'en the two structures is that records in a
consecutive file may not be accessed directly.
Thp r('sult of this implementation is that most processors
havE' b(,pn written using keyed files rather than consecutive
files bpcause t here is an additional capability offprpd by
keyed files and th('re is no diffprE'nce in speed in sequentially
accessing r('cords on E'ither structure. :\Ieasurements have
establishpd that only 16 pE'rcpnt of th(' rpads on thE' systpm
are done on consecutive files while 94 percf'nt of the reads on
the system arp sequpntial accesses. For th('s(' rpasons, ('mphasis is plac('d on improving srqu('ntial accpssf'S.
Once a filp is opened thf'rp is a pointf'r in thf' monitor CurrE'nt Fil(' Us('r (CFU) tablp to a list of kpys called a :\laster
Index (:\lIX). Each .:\IIX entry points to one of the data
granules associated ,,·ith th<> file. Data granules arC' 2048
character blocks that contain no allocation or organization
information. Figurp 2 is a schematic of the rE'cord structure.
Each entry in the :\IIX contains the following fields:

FILE DIRECTORY

CORE

FILE INFORMATION TABLES

F ILE 1 ----t--7
FILE2 - - t - - - - '

FILEn --,------'

ACCOUNT
DIRECTORY
ACCTl
ACCT2

~
i

~r-"

ACCTn ~

File management system structure

___--"
FILEI
FILE2

~ •••
•••

The structures used to keep track of files and records are
described.
File Structure-The account number specified by a calling
prugram is used as a key tu search a table of accounts called

,~
' ...
Figure l-File "tructufe

FILEn
SECURITY
RECORD POINTER

File Management Performance Improvements

(a) KEY-In a cons('cutive file the keys arc three bytes in
length. The first key is ahvays zero and all others follow and are incrrmrntrd by onr.
(b) DA-Thc> Disc Addrrss of the data buff~r that contains thr nrxt srgmrnt of thp record that is associated
with this key. Data buffers are always 204:8 characters
long. Thr disc address field is 4 characters.
(c) DISP-Thr byte displacrmrnt into thr granule of the
first charactrr of the rrcord segmrnt.
Cd) SIZE-Xumber of characters in this record segment.
(e) C-A continuation bit to indicate whethrr there is
another rrcord segment in another data granule.
(f) FAK-First Apprarance of Key-When FAK= 1 then
this entry is the first with this kpy.
(g) EOF-When set, this field indicates that this is the
last key in the ~IIX for this file. End Of File.

Space Allocation-The Sigma systems have two types of
secondary storage devicps-fixed head and moving head.
Thp fixed head device is called a RAD (Rapid Access Device);
the moving hpad device is a disc. The allocation of space on
these devices is completely and dynamically controlled by
the monitor subject to user demands.
The basic allocation unit is a granule (2048 characters)
which corresponds to one page of memory. The basic access
unit is a sector (1024 charactprs). A sector is the smallest
unit that can be read or ,vritten on both devices.
The account directories, file directories, filr information
tables and master indices arp always allocated in units of a
sector and are always allocated on a RAD if there is room.
Data granules are allocated in singh> granulp units and are
placed on a disc if there is room. The S\VAP RAD is never
used for file allocation.
Table I presents the characteristics for the secondary
storage devices referenced here.
If s is the size in pages of an access from device d, the average time for that access (TAd(s» is:
TAd(s) = Ld + Sd + 2*s*T~fd
where:
Ld is thf' aVf'rage latf'ncy time of drvice d
Sd is the average seek time of device d
T~ld is the average multiple sector transfer time of device d.
When accessing AD, FD, ::\lIX or FIT sectors, the average
transfer time for a single sector from device d is:

CORE

CFU
FILEI

MASTER INDEX

KEYl
KEY2

- ACCTZKEYn

~
Figure 2- Record structure

DATA GRANULE

TABLE I-Speeds of Sigma Secondary Storage Devices

DEVICE
Variable Kame
Capacity (granules)
Latency (average ms)
Seek Time-average
-range
Transfer Time (one sector) (ms per sector)
Transfer Time (multiple
sectors) (ms per sector)

7212 RAD 7232 RAD
Symbol
SRAD
RAD
2624
17
0
0

.34

3072
17
0
0
2.67

.41

2.81

L
S

7242 DISC
PACK
DP
12000
12.5
75 ms
25-135 ms
3.28
4.08

,,,here:
Td IS the average single sector transfer time for device d.

illodels of current operation
:\fodrls are devf'loped and validated for the open file and
read rpcord opprations. The model algorithms are closely
patternf'd after a simple description of system operation such
as found in Referencf's 3 or 8. Reff'rence 8 also develops a
model for the write operation and describes in detail the
measurrmf'nts for specifying and validating the modf'ls.
Open 111 odel-A simple model for the time it takes to opf'n
a file is:
TO = TPC + TOV + TFA + TFF + TFFIT
,vhere:
TPC
TOV
TFA

time to process the request for monitor services.
= time to read in monitor overlay.
= timp to search AD and find the entry that
matches the requested account.
TFF = time to search FD and find FIT pointer for the
requested file.
TFFIT = time to read FIT and transfer the allocation and
organization information to the CFU and user
DCB.
=

The functions for TOV, TF A, TFF and TFFIT can be refined and expressed using the following paramf'tf'rs:
PADR = probability that an AD is on a RAD instead of a
disc pack.
PFDR = probability that an FD is on a RAD instead of a
disc pack.
PFITR = probability that an FIT is on a RAD.
XAD =aVf'rage number of AD sectors.
XFD = average number of FD sectors per account.
TADl = time it takes to discover that the in-core AD
sector does not contain a match.
TFDl = same as TADl for an FD sector.
TAD2 = timf' it takes to find the correct f'ntry in the incorf' AD sector given that the entry is either in
this Sf'ctor or thf're is no such account.

National Computer Conference, 1973

TABLE II -Observable Open Parameters
PADR
PFDR
PFITR
NAD
NFD
SO

186.17 ms
.1 ms
1.5 ms
.1 ms
1.5 ms
.333
1.7 ms

TO
TAD1
TAD2
TFD1
TFD2
PON
TPC

1.00
.872
.906
6 sectors
2.6 sectors
2.5 pages

TFD2 = same as TAD2 for an FD sector.
PON = the probability that, when a request is made for
the open overlay, it is not in core and therefore
the RAD must be accessed.
SO
= number of granules occupied by the open overlay
on the SWAP RAD.
The time for the open overlay can be expressed as:
TOV = PON*TAsRAD(SO)
and the time to find the file directory pointer is:
NAD
TFA=PADR* --*(TS RAD +TAD1)

being spent on opening a file. The system has symbiont
activity going on concurrently with all other operations. The symbionts buffer input and output between
the card reader, on-line terminals, the RADs and the
line printer. So the symbionts steal cycles which are
being measured as part of open and they also produce
channel conflicts. Neither of these is considered by the
model.
(b) The figure NFD is supposed to reflect the number of
file directories in an account. The measured value is
2.6. Unfortunately there is a large percentage (40
percent) of accounts that are very small, perhaps less
than one file directory sector (30 files). These accounts
are not being used. The accounts that are being used
90 percent of the time have more than three file directory sectors. Therefore if the average number of FD
sectors searched to open a file had been observed
rather than computed, the computed value for TO
would have been closer to the observed TO.

Read M odel-To simplify the read model these assumptions
are made:
(a) This read is not the first read. The effect of this assumption is that all buffers can be assumed to be full. Since

NAD
*(TSDP+TADl)
+ (1-PADR)* _.-

TABLE IV-Observed Read Parameters

+TAD2-TAD1
and the time to find the file information table pointer is:
NFD
TFF=PFDR* - - *(TSRAD+TFDl)
2

+ (l-PFDR)* NFD *(TS DP +TFD1)
2

+TFD2-TFD1
and the time to read the file information table is:
TFFIT= PFITR*TS RAD + (1-PFITR)*TS DP
Table II contains the values of observable parameters
measured in the period January through .:\larch, 1972.
Table III contains the values of computable parameters
discussed in the open model.
The difference between the 1\vo figures, the observed and
computed values of TO, is 33 percent. There are a number of
ways this figure can be improved:
(a) When the TO of 186 ms was observed, it was not possible to avoid counting cycles that were not actually
TABLE III -Computed Open Parameters
TAsRAD(SO)
TOV
TFA
TFF
TO

19.0
6.3
60.7
30.3
125.4

ms
ms
ms
ms
ms

TPC
TTR
TR

0.65 ms
1.00 ms
20.35 ms

TMS
PMIXR
NEM

2 ms
0.585
47.7 entries

there are an average of 193 records per consecutive
filf', the assumption is reasonable.
(b) The record being read exists. This assumption implies
thf' file is not positioned at the end of file. Again, only
1 percent of the time will a read be on the first or last
record of the filf'.
(c) Thf' rf'cord size is If'sS than 2048 characters. This assumption is made so that the monitor blocks the record. The average rf'cord size is 101.6 characters.
These assumptions not only simplify the model, but they
reflect the vast majority of reads.
The time to read a record can therf'fore be written as:
TR = TPC + TGE + TTR + PEC*TGE
where:
TPC = time to process request to determine that it is a read
request. This parameter also includes validity
chf'cks on the user's DCB and calling parameters.
TGE=time to get the next key entry (even if the next
entry is in the nf'xt ':\IIX) and make sure that the
corresponding data granule is in core.
TTR = time to transfer entire record from monitor blocking
buffer to user's buffer.
PEe = the probability that a record has two rntricsentry continued.

File Management Performance Improvements

The probability, PKVr, that the next ~lIX entry is in the
resident :ynx can be expressed as a function of the average
number of entries, NE::.Yr, in a MIX sector:
XEM-1
PEM= NEM

The probability, PEG, that the correct data granule is in
core is a function of the number of times the data granule
addresses change when reading through the ~UX relative to
the number of entries in the MIX.
Table IV presents the observed values of the parameters
used in the sequential read model. The computed results for
the read model are found in Table V.
The difference between the computed and observed values
for TR is 42 percent. The error can be improved by refining
the observed values to correct the following:
(a) The symbionts were stealing cycles from the read record routines and producing channel conflicts that the
timing program did not detect.
Cb) In addition, the observed value of TR includes time
for reads that were direct accesses on a keyed file.
These direct accesses violate some of the read model
assumptions because they frequently cause large scale
searches of all the ~laster Index sectors associated
\vith a file.
~IODELS

OF THE PROPOSALS

In this section, two of the performance improvement proposals presented in Reference 8 are selected for quantitative
evaluation. One proposal impacts the open model and the
other proposal impacts the read model. The models developed
previously are modified to predict the performance of the file
management system after implementation of the proposals.
A proposal that impacts the open/close routines
I mplementation Description-To preclude the necessity of
searching the AD on every open, it is proposed that the first
time a file is opened to an account the disc address of the
FD will be kept in one word in the context area. In addition,
as an installation option, the system will have a list of library
accounts that receive heavy use. When the system is initialized for time-sharing it will search the AD looking for the
disc address of the FD for each account in its hpuvy use list.
The FD pointers for each heavy use account will be kept in a
parallel table in the monitor's data area.
The result is that bettrr than 9.1 prrcent of all opens and
closes will be in accounts whose FD pointers are in core. For
these opens and closes thr AD search is unnecessary.
TABLE V-Computed Read Parameters
TR
TGE
PEM

11.8 ms
9.7 ms
0.979

PEC

PDG
TRMIX

0.042
0.93
49.18 ms

Effect on Open lllodel-For the majority of opens the above
proposal gives the open model as:

TO' = TPC + TOV + TFF + TFFIT
=TO-TFA
= 125.4-60.7 = 64.7
This represents a percentage improvement of 51.5 percent.
(The figures used for TO and TFA are in Table III).
A proposal that impacts the read/write routines
I mplementation Description-The significant parameter in
the read model is the time to get the next entry, TG E.
There are two expressions in TGE \vhich must be considered:
the first is the average time to get the next ::\traster Index
eI:L.try;.th~ f?e.QQnd, i~ the .~y:ex.ag.e time to m.a.kBsure the._correct
data granule is in core. The levels of these expressions are
1.03 and 6.7 ms. It is apparent that the number of times that
data granules are read is contributing a large number of
cycles to both the read and write models.
One of the reasons for this, of course, is the disproportionately large access time on a disc pack compared to a
RAD. Xevertheless it is the largest single parameter so it
makes sense to attack it. A reasonable proposal to decrease
the number of data granule accesses is to double the buffer
size. The model is developed so that the size of the blocking
buffer parameter can be varied to compare the effect of various sizes on the read and write model.
Effect of Proposal on the Read ill odel-The proposal outlined
above \vill impact only one parameter in the read, PDG.
PDG represents the probability that the correct data granule
is in core. Its current value is 0.93.
XO\v, there are three reasons that a ~laster Index entry
will point to a different data granule than the one pointed to
by the entry that preceded it:

1. The record being written is greater than 2048 characters and therefore needs one entry, each pointing to a
different data granule, for every 2048 characters.
2. The original record has already been overwritten by a
larger record, requiring a second ~raster Index entry
for the characters that \vould not fit in the space reserved for the original record. The second entry may
point to the same data granule but the odds are ten
to one against this because there are, on the average,
10.6 data granules per file.
3. There was not enough room in the data granule currently being buffered 'when the record was written.
When this occurs the first .:\Iaster Index entry points
to those characters that would fit into the current data
granule and the second entry points to the remaining
characters that are positioned at the brginning of the
next data granule allocated to this file.
The first two reasons violate the assumptions for the read
model and are not considered further here.
The third reason is the only one that will be affected by
changing the data granule allocation. It follows that if there

National Computer Conference, 1973

T.ABLE VI-Impact of Blocking Buffer of Size N Pages on Read Model
N (pages)

PDG (ms)

TGE (ms)

TR(ms)

1
2
5
10

.930
.955
.970
.975

9.729
7.337
5.903
5.424

11.78
9.20
7.80
7.30

are 10.6 dat.a granules per file by doubling the allocation size
there
be 5.3 data 'granulrs' prr filr. This rfff'ctivf'ly divides by two the probability that a record had to be continupd
becausf' of the third itf'm abovr. Tripling thr sizr of thp blocking buffer and data 'granule' would divide t.he probability by
three.
The question to be resolvpd at this point is: What sharp of
the 7 percent probability that thp data granule addrpss will
change can bp attributed to the third reason above?
A reasonable approximation can be dpvplop('d by tIl(> following argument:

,,,ill

(a)
(b)
(c)
(d)
(e)

There are 2048*n charactE'rs in a data 'granule'.
There are 101.6 characters per rf'cord.
Therefore thf're arf' 20.V5*n rE'cords per data 'granule'.
The 20*n record will have two :\iaster Index entries.
Then, on the average, one out of every 20*n entries
will have a data granule address that is different from
the address of the preceding entry. This probability is
1/(20.15*n) which is .0496/n.

Then for n= 1, as in the original read and write models, 5
of the 7 percf'nt figure for 1-PDG is attributable t.o records
overlapping data granule boundaries. The actual equation
for PDG is:
.05)
PDG=l- ( .02+ ~
where n is the number of granules in the monitor's blocking
buffer.
The impact of various values of n on the read modE'1 is listE'd
in Table VI. It is obvious that by increasing the blocking buffer size, the performancE' of the read model can be improved.
However the amount of improvement decreases as n increases.
If there are no other considerations, a blocking buffer size
of two promises an improvement of 21 percent in the read
routine. Perhaps a user should be allowed to set his own blocking buffer size. A heavy sort user that has very large files, for
example, can be told that making his blocking buffers three
or four pages long will improve the running time of his job.
A final decision is not made here because the profile of jobs
actually run at any installation must be considered. In addition, there are problems like: Is thpre enough core available?

Is the swap channel likely to become a bottleneck due to
swapping larger users? These problems are considrred in
Rpferrnce 8 and found not to causp difficulty for the operational range considered here.
COXCLUSIONS
This paper does not. pretend to dpvelop a completp filp managpment systpm model. Such a model would npcessarily contain modPl functions for pach file managpmrnt activity and
some IDPans of combining thpsr functions with the rrlative
frequency of each activity. The model result would thpn be
relatpd to systpm pprformancp parametprs such as thr numbpr of usprs, thp pxppcted intrractive response time and the
turn-around timr for compute bound jobs.
Thp dpscribed rpsearch rppresents an pffort to model a file
management system. Thp modpl is detailed enough to allow
certain parampters to bp changed and thus show the impact
of proposals to improve the syst.em.
The development of the modPl is straightforward, based on
a relati,Tely detailed knmdedge of the system. This type of
model is sensitive to changes in the basic algorithms. The
model is developed both to further understanding of the system and to accurately predict the impact on the file management system of performance improvements.
Work remains to be don£' to integrate the model into overall
system performance measures. However comparisons can be
made with this model of different file managrment strategies.
DevelopmE'nt of similar models for oth£'r systE'ms will facilitate the search for good file managemf'nt strategif's.
REFERENCES
1. Bryan, G. E., Shemer, J. E., "The UTS Time-Sharing SystemPerformance Analysis and Instrumentation," Second Symposium
on Operating Systems Principle.~, October 1969, pp. 147-158.
2. Shemer, J. E., Heying, D. W., "Performance Modeling and Empirical Measurements in a System Designed for Batch and TimeSharing Users," Fall Joint Computer Conference Proceedings,
1969, pp. 17 -26.
3. Wilbur, L. E., File Management System, Technical Design Manual, Carleton University, 197I.
4. Chapin, N., Common File Organization Techniques Compared,"
Fall Joint Computer Conference Proceedings, 1969, pp. 413-422.
5. Collmeyer, A. J., "File Organization Techniques," IEEE Computer
Group News, March 1970, pp. 3-1I.
6. Atkins, D. E., Mitchell, A. L., Nielson, F. J., "Towards Understanding Data Structures and Database Design," Proceedings of
the 17th International Meeting of the XDS Users Group, Vol. 2,
November 1971, pp. 128-192.
7. Xerox Batch Processing Monitor (BPM), Xerox Data Systems,
Publication No. 901528A, July 1971.
8. McFadden, T. F., Quantitative Evaluation of File Management
Performance Improvements, M. S. Thesis, Washington University,
St. Louis, Missouri, May 1972.

A method of evaluating mass storage effects on system
performance
by M. A. DIETHELM
Honeywell Information Systems
Phoenix, Arizona

Ii\TRODUCTION

allocate the files in such a manner as to maximize system
performance. In -tIie case of adding a fast device to the
configuration, this objective is strongly correlated, within
reasonable limits, with an allocation policy which maximizes the resulting 110 activity to the fastest device in
the mass storage configuration. This allocation policy
can be mathematically modelled as an integer linear
programming problem which includes the constraint of
a specified amount of fast device storage capacity.
Having the file allocations and resulting I/O activity
profiles for a range of fast access device capacities, the
expected system performance change can be estimated by
use of an analytical or simulation model which includes
the parameters of proportionate distribution of I/O activity to device types and device physical parameters as well
as CPU and main memory requirements of the job
stream. The results of application of an analytic model
are described and discussed in the latter paragraphs as a
prelude to inferring any conclusions. The analytic model
is briefly described in the Appendix.

A significant proportion of the cost and usefulness of a
computing system lies in its configuration of direct access
mass storage. A frequent problem for computing installation management is evaluating the desirability of a
change in the mass storage configuration. This problem
often manifests itself in the need for quantitative decision
criteria for adding a fast (er) direct access device such as a
drum, disk or bulk core to a configuration which already
includes direct access disk devices. The decision criteria
are hopefully some reasonably accurate cost versus performance functions. This paper discusses a technique for
quantifying the system performance gains which could be
reasonably expected due to the addition of a proposed
fast access device to the system configuration. It should
be noted that the measurement and analysis techniques
are not restricted to the specific question of an addition to
the configuration. That particular question has been
chosen in the hope that it will serve as an understandable
illustration for the reader and in the knowledge that it has
been a useful application for the author.
The system performance is obviously dependent upon
the usage of the mass storage configuration, not just on
the physical parameters of the specific device types configured. Therefore, the usage characteristics must be
measured and modelled before the system performance
can be estimated. This characterization of mass storage
usage can be accomplished by considering the mass storage space as a collection of files of which some are permanent and some are temporary or dynamic (or scratch). A
measurement on the operational system will then provide
data on the amount of activity of each of the defined files.
The mass storage space is thereby modelled as a set of
files, each with a known amount of I/O activity. The
measurement technique of file definition and quantification of 110 activity for each is described first in this
paper along with the results of an illustrative application
of the technique.
The next step in predicting the system performance
with an improved (hopefully) mass storage configuration
is to decide which files will be allocated where in the
revised mass storage configuration. The objective is to

MASS STORAGE FILE ACTIVITY
MEASUREMENT
The first requirement in determining the files to be
allocated to the faster device is to collect data on the
frequency of access to files during normal system operation. Thus the requirement is for measurements of the
activity on the existing configuration's disk subsystem.
Such measurements can be obtained using either hardware monitoring facilities or software monitoring techniques. Hardware monitoring has the advantage of being
non-interfering; that is, it adds no perturbation to normal
system operation during the measurement period. A
severe disadvantage to the application of hardware monitoring is the elaborate, and expensive, equipment
required to obtain the required information on the frequency of reference to addressable, specified portions of
the mass storage. The preferred form of the file activity
data is a histogram which depicts frequency of reference
as a function of mass storage address. Such histograms
can be garnered by use of more recent hardware monitors
69

National Computer Conference, 1973

which include an address distribution capability, subject
to, of course, the disadvantages of cost, set up complexity,
and monitor hardware constrained histogram granularity.
A more flexible method of gathering the required information is a software monitor. This method does impose a
perturbation to system operation but this can be made
small by design and code of the monitor program. It has
the strong advantage of capturing data which can be
analyzed ::lfter the fact to produce any desired reports
with any desired granularity. A software monitor designed to work efficiently within GCOS* was utilized to
obtain file activity data for the analysis described for
illustration.
This 'privileged' software obtains control at the time of
initiation of any I/O command by the processor and
gathers into a buffer information describing the I/O
about to be started and the current system state. This
information, as gathered by the measurement program
used for this study includes the following:
Job Characteristics
Job and activity identification
File identification of the file being referenced
Central Processing Unit time used by the job
Physical I/O Characteristics
Subsystem, channel and device identification
I/O command(s) being issued
Seek address
Data transfer size
The information gathered into the data buffer is written to tape and subsequently analyzed by a free standing
data reduction program which produced histograms of
device and file space accesses, seek movement distances,
device utilization and a cross reference listing of files
accessed by job activities. Of primary concern to the task
of selecting files to be allocated to a proposed new device
are the histograms of device and file space accesses.
A histogram showing the accesses to a device is shown
in Figure 1. This histogram is one of 18 device histograms
resulting from application of the previously described
measurement techniques for a period of 2 1/4 hours of
operation of an H6070 system which included an 18
device DSS181 disk storage subsystem. The method of
deriving file access profiles will be illustrated using Figure
1. The physical definition of permanently allocated files
is known to the file system and to the analyst. Therefore,
each area of activity on the histograms can be related to a
permanently allocated file if it is one. If it is not a permanently allocated area, then it represents the collective
activity over the measurement period of a group of temporary files which were allocated dynamically to that
physical device area. Figure 1 depicts the activity of some
permanent files (GCOS Catalogs, GCOS-LO-USE, SWLO-USE, LUMP) and an area in which some temporary
files were allocated and used by jobs run during the

~E.q(a:~T Pli03a 81

L.' TV

Or Oe'cJ~Qe~~E

:~;xJ~;xX!~";~!'" ~~ ~ .. ~~ ... ~~ ... ~~. ~~
I.

I
I,
I

)GCOS-LO-USE

o x); X')' xx XX)Oc,(xlC1000': x x It'XXJ:

II
:''''''''''''

) "',Lo-U,",

:,
I

I
I

:~~~~o

LUMP

~
I

:
I

I
I,

: ~; ~ ~ xx (Y x'OC X X):

STl-HISC

Figure 1-Histogram of accesses to device 1 space

measurement period (STI-MISC). The leftmost column
of the histogram gives the number of accesses within each
5 cylinder area of the disk pack and consequently is used
to calculate the number of accesses to each file, permanent or temporary, defined from the activity histograms
for each device. Often the accessing pattern on a device is
not concentrated in readily discernible files as shown in
Figure 1 but is rather randomly spread over a whole
device. This is the case with large, randomly accessed
data base files as well as for large collections of small,
user files such as the collection of programs saved by the
systems' time sharing users. In these cases the activity
histograms take the general form of the one shown in
Figure 2. In this case no small file definition and related
activity is feasible and the whole pack is defined as a file
to the fast device allocation algorithm. The resulting files
defined and access proportions for the mentioned monito ring period are summarized in Table I. The unit of file
size used is the "link," a GCOS convenient unit defined
as 3840 words, or 15360 bytes. Table I provides the inputs
to the file allocation algorithm which is described in the
following section.
'!

;1.,,"" ••
"'!..-il.

~,~!~,

-1 ::'

:'F

PE er::'I':" T
u:
1'5

'10

~:..j:-

:-!.'.': 1 _

t']

"0,1'
•) 3
~

],J4

:l,H
9.)'
~ •J1
:i.)'
J.)l
':'. )~

"0,
"

C,)')

D.H
'),)4

J.H
'). J ~
J.l1

J.n
J.)d

.),

1).)5
~

).Jd

;J.n
:~:
J,n

:.J'
:.Jd
I J 4

.; ~

~ 1..

?':i

: . : . . ; .. .....;!.... r • : • • ~

-:-

• • • • : • • • • 1• • • •

, I.)' ~

~ :: ~ ~
,,,

"'"

,
!

,»
i~ ~ ~ ~
,.'"
110' ~

110' ~).

III. ~ .)( •
1'(:W ... w ,

i:: ~ ~

10',:1'
111.10
IICO
11()'1(0..... )
IlO:)I'x
Il(lt ~ 1
:1(''''

10'"'
/ .. ) . r

~:; x

! .0',

i::; the acrunym for the General Comprehcn:;i\'c Operating
Supervisor software for H6000 systems,

i~.;.;C

I
I
I

" Gcas

•• :

) GCOS CA!ALOGS

IHxllX):.O"XXXklOt'J(XJ(X

FiguTe 2-Histogram of acces:;:es to device 2 :;:pace

Mass Storage Effects on System Performance

THE PROBLEM

TABLE I-Measured File Activity
Dual607o--Monitoring Period Approx. 2.25 Hours
DSS181 (16 used. devices)-149180 Accesses
Exposure (3D) Workload (6/23/72)
File Name

Size (Links)

Activity (%)

GCOSCAT
GLOB-HI-USE
GLOB-LO-USE
SU-HI-USE
SW-LO-USE
SW-SYSLIB
LUMP
#P
#S
PACK16
STI-MISC
-G-WAD-FILES
SYOU2
DEV. CATS
PACK 11
PACK 10
D6SCRATCH
D7SCRATCH
D13 C SCRATCH
D3 SCRATCH 1
D3SCRATCH2
D4 MISC
SYOU 1
D7 MISC
PACK8
PACK9

80
18
140
40
150
40
20
55
200
750
150
1200
360
1200
1200
100
180
90
150
90
600
1200
600
1200
1200

4.1
12.7
3.5
0.9
1.7
1.3
0.8
0.9
4.5
3.9
2.8
-4.7
9.1
2.6
3.1
4.1
3.1
2.0
1.4
2.7
1.0
3.3
9.0
1.4
2.7
4.0

OTHER

7940

8.6

150

Xote: 1 Link =3840 Words = 15360 bytes.

OPTIMAL FILE ALLOCATION TO FAST DEVICE
WITH LIMITED CAPACITY
Having a set of mass storage files defined as well as a
measured profile of the frequency of access to each, the
next step is to postulate an allocation of these files to the
mass storage subsystems. For purposes of illustration it
will be assumed that this allocation problem may be
characterized as the selection of that subset of files which
will fit on a constrained capacity device. The selected
files will then result in the maximum proportion of I/O
activity for the new device being added to the mass storage configuration. This problem of selecting a subset of
files may be formulated as an integer linear programming
application as follows.
GIVEN
A set of n pairs (8i' Ii) , defined as:
8i= Size (links) of the ith file,

Select from the given set of files that subset which maximizes
the sum of the reference frequencies to the selected subset
while keeping the sum of the selected subset file sizes less
than or equal to the given fast device capacity limitation.
lVIATHE::.\1ATICAL FORMULATION
Define

Oi =

o- ith file is not selected
{1-ith file is selected for allocation to fast device.

Then the problem is to find,

:MAX Z= [

:E /i·Oi]
i=l,n

Subject to,
L....J
"

8··0·d and the comptrxity of
the time-sharing ' - 3 computer systems, TSCS, necessitate a
good deal of effort to be spent on the analysis of the resource
allocation problems which are obviously tied to the cost and
the congestion properties of the system configuration. In this
paper we study the congestion problems in the multiprogramming ' - 3 TSCS's.
The activity in the past sixteen years in the analysis of the
congestion properties of the TSCS's by purely analytical
means has been concentrated on the study of the central processing unit (or units), CPU ('s), and the related
queues. A good survey of the subjf'ct has bf'f'n provided by
}IcKinney.4 In the meantime more contributions to this area
have appeared in the literature. 5- 11
There has been a separatf' but not so active interest in the
study of the congestion problems in the multiprogramming
systems. Heller '2 and }lanacher'3 employed Gantt charts
(cf. 12) in the scheduling of the sequential "job lists" over
different processors. Ramamoorthy et a1.'4 considered the
same problem with a different approach. A single server
priority queueing model was applied by Chang et al. ls to analyze multiprogramming. Kleinrock '6 used a 2-stage (each
stage with a single exponential server) "cyclic qUf'ueing"'7
model to study the multistage sequential srrvers. Later
Tanaka 'S extended thr 2-stage cyclic queuring model to include the Erlang distribution in one of the stagf's. Gavf'r19
extendrd the 2-stage cyclic queueing model of multiprogramming computer systems furthf'r by including an arbitrary
number of identical procrssors with rxponrntial service timrs
in thf' input-output, 10, stagr in providing the busy period
analysis for the CPU undrr various procrssing distributions.
Herr wr prrsent a multiprogramming modrl for a genrral
purpose TSCS, whrrr thr arrival and thf' drparture processes
of thr programs along with thr main systrm resourcrs, i.e.,
the CPl~'s, thp diffprrnt kind of lOP's and thp finitr main
memory sizf', are included and their relationships are
examined.
:\IODEL

2:i:l

The configuration of the TSCS wr want to study consists of
ko~ 1 identical CPU's with m groups of lOP's whf're the ith

National Computer Conference, 1973

the system rquation, following Fell~r,21 by relating the state
of the system at time t+h to that at time t, as follows:

IOP's

kl·/-LI

cpu's

P(no, n1, ... , nm; t+h) = {l- [C L hi+ L Iljaj(nj)]h}
i=l

;=0

XP(no, ... , nm; t)
m

+ L h;E ihP(nO, ... , n;-I, ... , nm; t)

ko./-Lo

;=1
m

+ L ao(no+ 1) llorOj E jhP(no+l, ... , l1j-l, .. . , 11m; t)

;=1

+ L ai(n;+l)lliTiOE ohP(no-l, ... , n;+I, ... , n m ; t)
i=1

1- POl

+C L

Figure I-System configuration

ai(ni+l)ll;(I-T;o)h

i=1

preemptive-resume type of interrupt policy where the interrupted program sequence continues from the point \vhere it
was stopped when its turn comes. All the 10 and the CPU
queues are conceptual and assumed to be formed in the main
memory.
In this model the processing times of all the CPU's and the
lOP's are assumed to be independent and distributed negative exponentially. The processors in the -ith group all have
the same mean service time 1/ Ili, where i = 0, 1, ... , m. The
transition probabilities between the lOP groups and the
CPU group are assumed to be stationary. These assumptions
have already been used successfully by other authors investigating the TSCS in one form or other (cf. 4 and other references on TSCS).

XP(no, ... , ni+ 1, ... , nm; t) +O(h).
m

where

i=O

m
Lni~N,
i=O

ai(n) =min{n,

Ei=min{ni'

kd,

-i=O,I, ... ,m

II,

i=O, 1, ... , m.

By the usual procrss of forming the derivative on the left
hand side and letting it equal to zero for steady-state and
also replacing P(no, 711, ••• ,11m; t) by P(no, 1l1, . . . ,11m), we
have
In

;=1

hiE iP(nO, ... ,71,.-1, ... , n m ).

i=1
m

+ L ao(no+l)llot]iE ;P(no+l, ... ,n;-I, ... ,nm)
;=1
m

+ L ai(ni+ 1)Il;PiE iP (no-l, ... ,ni+ 1, ... , nm)
i=l

i=O, 1, ... , m

(1)

;=0

and

;=1

where

Lni..W," Opns.
Res., Vol. 9, May-June 1961, pp. 383-387.

APPENDIX
The general "network of waiting lines" (network of queues)
was described in Reference 20. Here we add one more condition to that stated in Reference 20 by allowing no more than
N customers in the system at any time. If a new customer
arrives to find N customers already in the system, he departs
and never returns.
Then following the previously defined notation in earlier
sections, we can write the system equation for general network of waiting lines as

Multiprogrammed Time-Sharing Computer Systems

where
m

{l-[C L Ai+ L JLjO!j(nj) Jh}P(nl' "" n m ; t)
i=1

j=1

(10)

i=1 j=1

i=1

Tij,

+CL O!i(ni+1)JLi(1-Ti)hP(nl, ' , " ni+ 1, ' , " n m ; t)
+O(h),

L
i=1

+ L AiE ihP(nl, ' , " ni- 1, ' , " nm ; t) + L L
i=1

Ti=

It can be shown that the solution to (10) in steady state
is given by the theorem stated earlier,
In this case it is difficult to obtain a closed form solution
for 1\ /s,

Use of the SPAS M soft ware monitor to eval uate the
performance of the Burroughs B6700
by JACK M. SCHWARTZ and DONALD S. WYNER
Federal Reserve Bank of New York
New York, ~ew York

features of this system which distinguish it from many
other systerhs are:
.. .

INTRODUCTION

The need for system performance measurement and
evaluation

• Each task has assigned to it a non-overlayable area
of memory called a stack. This area provides storage
for program code and data references* associated
with the task as well as temporary storage for some
data, history and accounting information.
• Multiple users can share common program code via
a reentrant programming feature.
• The compilers automatically divide source language
programs into variable sized program code and data
segments rather than fixed sized pages.
• Core storage is a virtual resource which is allocated
as needed during program execution. (This feature is
discussed in more detail below.)
• Secondary storage including magnetic tape and
head-per-track disk is also allocated dynamically by
the MCP.
• Channel assignments are made dynamically; that is
they are assigned when requested for each physical
110 operation.
• I 10 units are also assigned dynamically.
• Extensive interrupt facilities initiate specific MCP
routines to handle the cause of the interrupt.
• The maximum possible B6700 configuration includes
3 processors, 3 multiplexors, 256 peripheral devices,
1 million words of memory (six 8-bit characters per
word or 48 information bits per word), and 12 data
communications processors.

The benefit to be derived from a large multi-purpose
system, such as the B6700, is that many jobs of very diverse characteristics can (or should) be processed concurrently in a reasonable period of time. Recognizing that
certain inefficiencies may result from improper or uncontrolled use, it is necessary to evaluate the computer
system carefully to assure satisfactory performance. To
this end, the objective of our work in the area of performance evaluation is to:
1. determine the location(s) and cause(s) of inefficiencies and bottlenecks which degrade system performance to recommend steps to minimize their
effects,
2. establish a profile of the demand(s) placed upon
system resources by programs at our facility to help
predict the course of system expansion,
3. determine which user program routines are using
inordinately large portions of system resources to
recommend optimization of those routines
4. establish control over the use of system r~sources.

Among the techniques which have been applied to date
in meeting these objectives are in-house developed software monitors, benchmarking, and in-house developed
simulations. This paper discusses the software monitor
SPASM (System Performance and Activity Softwar~
Monitor), developed at the Federal Reserve Bank of New
York to evaluate the performance and utilization of its
Burroughs B6700 system.

The current B6700 system at the Federal Reserve Bank
of New York shown in Figure 1 includes one processor,
one 110 multiplexor with 6 data channels, one data
communications processor and a number of peripheral
devices. In addition, the system includes a virtual memory consisting of 230,000 words of 1.2 micro-second
memory, and 85 million words of head per track disk
storage.
The management of this virtual memory serves to illustrate the involvement of the MCP in dynamic resource

THE B6700 SYSTEM
The B6700 is a large-scale multiprogramming computer
system capable of operating in a multiprocessing mode
which is supervised by a comprehensive software system
called the Master Control Program (MCP).1,2 Some of the

* These references are called descriptors and act as pointers to the
actual location of the code or data

National Computer Conference, 1973

,"-" m

f_m__

l"m-J-

January 1973
Schwartz/Wyner
SPASM

l m"_-"_}
*

14 memory modules, each having 98.3 KB; total 1.4 MH.

Figure I-Configuration of the Federal Reserve Bank of New York B6700 computer system

allocation. This process is diagrammed in Figure 2. Main
memory is allocated by the MCP as a resource to current processes. When a program requires additional
memory for a segment of code or data, an unused
area of sufficient size is sought by the MCP. If it
fails to locate a large enough unused area, it looks for an
already allocated area which may be overlaid. If necessary, it links together adjacent available and in-use areas
in an attempt to create an area large enough for the current demand. When the area is found, the desired segment is read in from disk and the segments currently
occupying this area are either relocated elsewhere in core
(if space is available), swapped out to disk or simply
marked not present. In any case, the appropriate descriptor must be modified to keep track of the address in
memory or on disk of all segments involved in the swap.
All of these operations are carried out by the MCP; monitoring allows us to understand them better. For additional
information on the operation and structure of the B6700
see Reference 3.

B6700 PERFORMANCE STATISTICS
The complexity of the B6700 system provides both the
lleces~ity to monitor and the ability to monitor. The per"

vasive nature of the MCP in controlling the jobs in the
system and in allocating system resources made it necessary for the system designers to reserve areas of core
memory and specific cells in the program stacks to keep
data on system and program status. This design enables
us to access and collect data on the following system
parameters:
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•

system core memory utilization
I/O unit utilization
I/O queue lengths
processor utilization
multiplexor utilization
multiplexor queue length
peripheral controller utilization
system overlay activity
program overlay activity
program core memory utilization
program processor utilization
program I/O utilization
program status
scheduler queue length
response time to non-trivial requests

These data are vital to the evaluation of our computer
system. Table I presents examples of the possible uses for
some of these statistics.

Spasm Software Monitor

Swapped
to
Disk

Marked
not
Present

TABLE I-Examples of Collected Statistics and Their Possible Uses

~
Unused
Core
50 Words

Data

Segment 6
Segment 4
Program 2
~ Program 2 ~
(Code) 100 Words~(Data) 100 words~

AREA 6

Unused
Core
50 Words

Segment 2
Program 5
100 Words

Figure 2-B6700 memory allocation procedure
1. Space is needed for a 300 word segment for one of the current tasks.

2. A large enough unused area is not located.
3. The MCP finds a contiguous location made up of areas 1 through 4
which is 300 words long.
4. Area 1 contains a 50 word data segment. The MCP relocates this
segment into area 5, makes note of its new core address and removes
area 5 from the unused linkage.
5. Area 2 is unused. It is removed from the unused linkage.
6. Area 3 contains a 100 word code segment. There are no unused areas
large enough to contain it. Therefore, it is simply marked not present. Since code cannot be modified during execution, there is no reason to write it out to disk-it is already there.
7. Area 4 contains a 100 word data segment. It is written out to disk
and its new location is recorded.
8. The 300 word segment is read into core in the area formerly occupied
by areas 1 through 4 and its location is recorded.

DESCRIPTION OF THE SPASM SYSTEM
The B6700 System Performance and Activity Software
Monitor, SPASM, is designed to monitor the performance
of the system as a whole as well as that of individual user
programs. It consists of two separate programs, a monitor
and an analyzer, both of which are described below. The
principal criteria governing its design are:
(a) to make a software monitor capable of gathering all
the pertinent data discussed in the previous section,
(b) to minimize the additionai ioad pi aced upon the
system by the monitor itself, and
(c) to provide an easily used means of summarizing
and presenting the data gathered by the monitor in
a form suitable for evaluation by technical personnel and management.

A bility to gather pertinent data
The Mastor Control Program concept of the B6700
helps in many ways to simplify the acquisition of the data

Use

System core memory utilization

Determine need for additional
memory
I/O unit utilization, I/O unit queue Determine need for Disk File Optilengths
mizer and/or additional disk
storage electronic units, printers
or disk file controllers
Processor queue length and com- Determine need for additional proposition
cessor
Evaluate effect of job priority on
execution
Determine processor boundedness
of mix
Determine effect of processor utilization on demand for I/O (in
conjunction with I/O unit data)
System--evoosy--activ-ity
- Determine- - need-- -for----additional
memory
Determine need for better task
scheduling
Determine when thrashing* occurs
Job overlay activity
Evaluate program efficiency
Evaluate system effect on job execution
Job core memory utilization
Evaluate program efficiency
Change job core estimates
Scheduler queue length
Determine excess demand for use
of system
Evaluate MCP scheduling algorithm
* Thrashing is the drastic increase in overhead I/O time caused by the
frequent and repeated swapping of program code and data segments. It
is caused by having insufficient memory to meet the current memory
demand.

listed in Table 1. Such information as a program's core
usage, processor and 1;0 time, and usage of overlay areas
on disk are automatically maintained in that program's
stack by the MCP. A relatively simple modification to the
MCP permits a count of overlays performed for a program to be maintained in its stack. Data describing the
status of programs are maintained by the MCP in arrays.
Information on system-wide performance and activity
is similarly maintained in reserved cells of the MCP's
stack. Pointers to the head of the processor queue, I; 0
queues and scheduler queue permit the monitor to link
through the queues to count entries and determine facts
about their nature. Other cells contain data on the system-wide core usage; overlay activity, and the utilization
of the 1;0 multiplexor. An array is used to store the status of all peripheral devices (exclusive of remote terminals) and may be interrogated to determine this information.
All of the above data are gathered by an independently
running monitor program. The program, developed with
the use of a specially modified version of the Burroughs
ALGOL compiler, is able to access all information maintained by the MCP. The program samples this information periodically and stores the sampled data on a disk
file for later reduction and analysis.

National Computer Conference, 1973

interactively or
following:

Minimization of load upon the system

To minimize the additional load on the B6700, the
monitor program is relatively simple, and very efficient.
A somewhat more sophisticated analyzer program is used
to read back the raw data gathered by the monitor and
massage it into presentable form. This analysis is generally carried out at a time when its additional load upon
the system will be negligible. The system log has indicated that the monitor does indeed present a minimal
load requiring about 1/4 of 1 percent processor utilization
and 2 1/4 percent utilization of one disk I! 0 channel.

•
•
•
•

batch mode will produce any of the

Graphs of data versus time
Frequency distribution histograms of data
Correlation and regression analyses among data
Scanning for peak periods

The options are selected via an input language consisting
of mnemonics.
(1) Graphs of data versus time are produced to show the
minute-by-minute variations in parameters of interest.
The graphs are "drawn" on the line printer using symbols
to represent each curve. Any number of parameters may
be plotted on one graph, and a key is printed at the end
identifying all symbols used in the graph and listing the
mean values of each. To aid in tailoring the most desirable presentation, rescaling of the ordinate and time axes
is permitted. In addition, the user may select a specific
time interval of interest and plot that interval only. Fig-

Easy means of analysis and presentation

The raw data gathered by the monitor can be used
directly in some cases; however, to serve best the purpose
for which SPASM was designed (i.e., as a management
reporting system) several useful presentations have been
engineered. The analyzer program, which may be run

I" T T <,
t;O •

1/1

•

1'\')

1111

II'

vvvv v

Vv
V

v vv

V V

• T

1 •
..

'11

110

19 .. T
11\ ..
17 ..

vvv

1" ..

I/VVV

vv vvv vvvvvvv vv
vvVv

vvvvv V
VVVVV

14 ..

VVV'IVV

13 ..

IIU'llilJlI'1

vv,

VUUII

UltIIIIIJULJIJIIUU!llllJ

1'i ..

tlU

lJIIIIIIlIl""IUIJIl

IIUI111

lJU

1? ..

"
"

'111

II'I

LIP I!

10 *

TT
IJ

'9 ..

?8 *
'7 *
,(, *
,')

'4 *
'3 *

'? *

IIIIII1I1111

VVV

TTT

""UIII!

TVVV
"
IJII'IIllIll'" t IIUlIll;1
1.1
VVV
T
TTT

VII If

nc S I '1L I Rr SMO"l/OR.lF"r.T

'1 *

*11

*
*
*

11
,?
11

'0 ..
09 *
nil

06 ..

05
nil
03
07

*
*

1111

lJll
Ull

illlil

,n *
19 *
HI *
17 *
16 *
15

II
1111

T1ME I NTF"RVAI

09,'7

0991
Tn 1110n

KEY
SCALE
S'I'SAVL TTTTTT
lI"lIT
I4rA"l'"
19A77.1773<;8
S'I'SOLY UIJUUUII
t liN IT
'4FAN:
110911.901111110
SYSSVE VVVVVV
1 UNIT

",rAN.

, ') I'" 7,7?

nATEI

001000 wnRn"'1"'<)/1 /11

1 ". 1 n,,,, 1)::>1

J.'1I1""RI'i"

nc '11,

I. "'I1O:;Q II Q7n

",70~<11Q?'1

2.lAA?~7Q4

C; Y <;5 VF

'.'1",,,,,nIl7

7.Q9QR77Q,

In'lt)7'.(j~1''(\I'''1)

~'I71?~7nl\,3)4?"'l'~

,,,,,3.'l41\6,,6n

1 n'i",

11,

7'1217QOII.1I0"~'1"'"

,,,RQ3.MI'QI74"

III 7 ~ I

1l.IIIH'I91

0.11111'14,,7

~II. A .. ~1I7

(\. 71

Pr.I1LAY
PCnl.A v
nr.nLAY
CnnLH
SVC;SV"
sysnLY
PRnCIJT

'1r.

sYc;nLV

sYsc;vr

UHll.AV

2,11?'14n""

PRO~IIT

1.()nOnOOllr no
<1.JQ/j">"'?<1.-111

1 .1l0OOOOIH' 00
<).IlQ,c,flHt,'-01
1.00nn'lon. 00
11.''',,>/jl~qr-nl
1 • nnnnnoor no
... 'iR4;:>QQ<1.-"11
.... 7;:>7n;:>1"r-Ol
/).4/\, Q"J'-01
-?, 7141)'" q~-.,! -'.110 'II)QO ..... - 0 I -7.1117<1,,<14,-01 -1I.Q?Cl900Ir-n,
3.;>'''>~,QQ,-nl
'.AQo;II\79r-o'
1,0<)30;11)11"'.-'"
1.111<1n::>' ..... -01

I.Ooooooor 00
;:>.21)1145'8(-01

,:001l0001l .. on

1754
p"nC'IT

e;1I~

o;nllRrr nr VA"IATT"N
TnT

nr SqIlARrC;
I1R Tr. T... AI. 11'11 T 5

M(AN

rnRRrLATToN

rnR~

SQ11ARrs
OOTr.I'IAL ""'ITe;

1.1I0nnoooo
1!.43R74141

R[SII1IIAL

0.000404"5

VARtARLE
PCOLAY
nCnLAY
CnOLAY

r.nHrTcIPH
0.on44RI
0.0,<:1,,9, ••
-o.nlal, ... •
o.onooo" ••
O.tJ'l1100"' ••

Syssvr

c; YSOI Y

CrJ'IISTA'JT
5 •• ,

Cnfll<;TANT

rnNST~"'T

e;. E. rnrr.
O.nI)H,n
o. n07173
n. nil"!! 7
o.l1noono
o.ooonnn

RrTA
n.o">l'1,7
0.;>R391'i
-0.1197119
0.3791::>5
0.41\13VI

-".4'510ll44
".n5 7 413R?

S.·. RrT'
o.n'l9Q::>"
O. n0;2 7 19
0.00;171\0
.1.nlln73
o.n'HQl

1.3n61~/I

5.'11341 7
-2.112",,,3
12.2011118
20.4901",4

'1.,/11,1'/1'59

RHCl

'"'. <:I'i/'~

1)4",

PART[ aL R
0.031230
0.\27'708
0.050;;130
0.l'8n\4'5
0.4/10079

R-<;/l
An J. R-<;Q

-7./1/"''1701 I

S .... Ee;TT"ATE

T PRnR
0.'108,11\
I.OOOnnO
0.9791';9
1.0001100
I.noo'loo

11.'54nQI\6QR
OIJRIITN OIAT"nN

'1.091002'17

'.tJt)nOOonn

p~nRAIIJL

TTY

Figure 5-Results of regression and correlation analysis

and overlay rate parameters. These results are seen to
show that, for example, the overlay statistics are highly
correlated to the amount of "SAVE" core in the system.
This is understandable since the larger the "SAVE" core
the greater the chance of needing to swap segments.
(4) Scanning for peak periods is a necessity in most
computer systems, especially those operated in a data
communication environment where the load fluctuates

widely. The analyzer can scan the entire day's data and
flag time intervals (of length greater than or equal to
some specified minimum) during which the mean value of
a parameter exceeded a desired threshold. For example. a
period of five minutes or longer in which processor utilization exceeded 75 percent can be easily isolated (see
Figure 6). Using this techniq ue a peak period can be
automatically determined and then further analyzed III
more detail.

Spasm Software Monitor

_NI)TNG
F"NDING
_NnTNG
_NDTNG
F'NOTNG

PRnCUT
PRnCllT
PRnr.UT
PROCIJT
PRnCIJT
PRnr.UT
rnR ??~O
rnR 4920 SEcnNns F"NnTNG 1'S:O~ PRnr.IJT
F"nR n420 SEcnNOS _"IOT"Ir. 10;:\::» PRnr.IJT

rnR
rnR
rnR
rnR
rnR

0740
::»160
0700
13::»0
04RO

n91'Sn
11101,
1 t 149
\::»131
1::»139
SEcn"-JDS r~!D TN('; 1l!37

SEcnNOS
SECnNns
SEcnNDS
SEcnNOS
SECnNDS

ElCCI"_nEn
ElCC·-nEO
[XC·F"nEn
nC-EnE"
rlCC·rnEn
EXCI"r:-()En
rlCc_rnrn
EXc .. nEn

THRESH"I n
THRESHn, 0
THRESHn!.O
THRESHnlO
THRF:SHnLn
TIiRESfHll n
THRESHn, 0
THRESHn, n

Figure 6-Periods of peak processor utilization

The design criteria discussed above have been met and
a software monitoring system has been developed which is
comprehensive, and easily used, and yet presents a negligible load upon the B6700 computer.
CONCLUSION AND OUTLOOK
The SPASM system has proven to be very instrumental
in the performance evaluation of the B6700 system at the
Bank. Several areas in which it has been and is currently
being used are as follows:
• The statistics on processor queue length, multiplexor
utilization, and disk controller utilization were used
to aid in the analysis of the need for a second processor*, second multiplexor and additional controllers.
• The job core utilization data have been used to evaluate the effect of alternate programming techniques
on memory use.
• Disk utilization data have been examined to identify
any apparent imbalance of disk accesses among the
disk electronics units.
• Processor queue data are being used to determine the
effect of task priority on access to the processor.
• System overlay data are being used to determine the
adequacy of automatic and manual job selection and
scheduling.
• Processor utilization figures, as determined from the
processor queue data, were used to determine the
effect of core memory expansion on processor utilization.
Some future possible uses planned for SPASM include:
• Use of the scheduler queue statistics to evaluate the
efficiency of the current MCP scheduling algorithm
and to evaluate the effect changes to that algorithm
have on the system performance.
• Use of the response time data to evaluate system
efficiency throughout the day with different program
mixes.
• Evaluation of resource needs of user programs.
• Evaluation of the effect that the Burroughs Data
Management System has on system efficiency.
• Building of a B6700 simulation model using the collected statistics as input.
• Building an empiricai modei of the B6700 system by
using the collected regression data.
* See Appendix A for a discussion of how the processor queue data was
used to determine processor utilization.

The SPASM system has enabled us to collect a greatdeal of data on system efficiency and, consequently, a
great deal of knowledge on how well the system performs
its functions. This knowledge is currently being used to
identify system problems and to aid in evaluating our
current configuration and possible future configurations.
Mere conjecture on system problems or system configurations in the absence of supporting data is not the basis for
a logical decision on how to increase system efficiency.
Performance measurement and evaluation are essential to
efficient use of the system.

REFERE~CES
1. B6700 Information Processing Systems Reference Manual, Bur-

roughs Corp. May, 1972.
2. B6700 Master Control Program Reference Manual, Burroughs
Corp. November, 1970
3. Organick, E. I., Cleary, J. G., "A Data Structure Model of the
B6700 Computer System," Sigplan Notices, Vol. 6, No.2, February
1971, "Proceedings of a Symposium on Data Structures in Programming Languages."

APPENDIX A
The use of processor queue data to determine
proCEssor utilization

The SPASM system records the length of the processor
queue periodically. The processor utilization will be based
upon these examinations, taking into account that the
monitor itself is processing at this instant of time. If the
processor queue is not empty, the monitor is preventing
some other job from processing. Consequently, if the
monitor were not in the system the processor would be
busy with some other task at that instant of time. This
is considered to be a processor "busy" sample. On the
other hand, if the processor queue is empty at the sample
time there is no demand for the processor other than the
monitoring program itself. Therefore, if the monitor
were not in the system at that instant of time the processor
would be idle. This is considered a processor "idle"
sample. Processor utilization can therefore be estimated as:
...
No. "busy" samples
processor utilIzatIOn = total N o. sampI es
This sampling approach to determining processor utilization was validated by executing controlled mixes of
programs and then comparing the results of the sampling
calculation of processor utilization to the job processor
utilization given by:
processor utilization =
processor time logged against jobs in the mix
elapsed time of test interval

Table II compares the results of these two calculations.

100

National Computer Conference, 1973

TABLE II-Comparison of Processor Utilization Statistics By Sampling
Technique and By Processor Time Quotient Technique
Average Processor lJtilization (%)

Test Series 1
Test Series 2

Sampling Technique

Processor Time Quotient

99.1
57.6

96.5
53.5

In a second type of test, processor idle time was monitored (by means of a set of timing statements around the

idling procedure) to gain a close measure of utilization.
The total idle time was subtracted from the total elapsed
time of the test to obtain the processor busy time and
hence the utilization. Over a period of five hours the respective processor utilization calculations were:
Sampling Technique
Idle Timing

46.3%
48.0%

These results make us confident of the validity of using the processor queue sampling technique to accumulate processor utilization statistics during any given time
interval.

Evaluation of performance of parallel processors in a
real-time environment
by GREGORY R. LLOYD and RICHARD E.

MERWI~

SAFEGUARD System Office
Washington, D.C.

number of separate data sets (array processing). A more
eo-mplex ease involves different ealeulationson separate data
sets (multiprocessing) and finally, the greatest challenge to
the parallel processing approach occurs \\'hen a single calculation on a single data set must be decomposed to identify
parallel computational paths within a single computational
unit. A number of mathematical calculations are susceptible
to this type of analysis, e.g., operations on matrices and
linear arrays of data.
The computational support required for a phased array
radar is represf'ntative of problems exhibiting a high degree
of parallelism. These systems can transmit a radar beam in
any direction within its field of view in a matter of microseconds and can provide information on up to hundreds of
observed objects for a single transmission (often called a
"look"). The amount of information represented in digital
form which can be generated by this type of radar can exceed
millions of bits per second and the analysis of this data
provides a severe challenge to even the largest data processors. Applications of this radar system frequently call for
periodic up dates of position for objects in view which are
being tracked. This cyclic behavior implies that a computation for all objects must be completed between observations.
Since many objects may be in view at one time, these computations can be carried out for each object in parallel.
The above situation led quite naturally to the application
of associative paral1el processors to provide part of the computational requirements for phased array radars. A number
of studies9 ,IO,II,I2 have been made of this approach including
use of various degrees of parallelism going from one bit wide
processing arrays to word oriented processors. As a point of
reference this problem has also been analyzed for implementation on sequential pipelined machines. 1o One of the main
computational loads of a phased array radar involves the
filtering and smoothing of object position data to both
eliminate uninteresting objt>cts and providt> more accurat.e
tracking information for objt>cts of interest. A technique for
elimination of unintert>sting objects is referred to as bulk
filtering and the smoothing of data on interesting objects is
carried out with a Kalman filter.
The following presf'nts an analysis of the results of the
above studies of the application of associative parallel processors to both the bulk and Kalman filter problems. The two

IXTRODUCTIOK
The use of parallelism to achieve greater processing thruput
for computational problems exceeding the capability of
present day large scale sequential pipelined data processing
systems has been proposed and in some instances hardware
employing these concepts has been built. Several approaches
to hardware parallelism have been taken including multiprocessors l ,2,3 which share common storage and input-output
facilities but carry out calculations with separate instruction
and data streams; array processors4 used to augment a host
sequential type machine 'which executes a common instruction stream on many processors; and associative processors
which again require a host machine and vary from biP to
'word oriented6 processors which alternatively select and
compute results for many data streams under control of
correlation and arithmetic instruction streams. In addition,
the concept of pipelining is used both in arithmetic processors7 and entire systems, i.e., vector machines8 to achieve
parallelism by overlap of instruction interpretation and
arithmetic processing.
Inherent in this approach to achieving greater data
processing capability is the requirement that the data and
algorithms to be processed must exhibit enough parallelism to
be efficiently executed on multiple hardware ensembles.
Algorithms which must bf' executed in a purely sequential
fashion achieve no benefit from having two or more data
processors available. Fortunately, a number of the problems
requiring large amounts of computational resources do
exhibit high degrees of parallelism and the proponents of the
parallel hardware approach to satisfying this computational
requirement have shown considerable ingenuity in fitting
these problems into their proposed machines.
The advocates of sequential pipelined machines can look
forward to another order of magnitude increase in basic
computational capability bf'fore physical factors will provide
barriers to further enhancement of machine speed. \Vhf>n this
limit is reached and ever bigger computational problems
remain to be solved, it seems likely that the parallel processing approach will be one of the main techniques used to
satisfy the demand for greater processing capability.
Computational parallelism can occur in several forms. In
the simplest case the identical calculation is carried out on a
101

102

National Computer Conference, 1973

criteria used to evaluate the application of parallel hardware
to these problems are the degree of hardware utilization
achieved and the increase in computational thruput achieved
by introducing parallelism. The latter measure is simply the
ratio of computational thruput achieved by the array of
processing elements to the thruput possible with one element
of the array. The Parallel Element Processing Ensemble
(PEPE) considered as one of the four hardware configurations is the early IC model and is not the improved ~iSI PEPE
currently under development by the Advanced Ballistic
~1issile Defense Agency.
Finally, a comparison of hardware in terms of number of
logical gates is presented to provide a measure of computational thruput derived as a function of hardware complexity.
The paper concludes with a number of observations relative
to the application of the various associative parallel hardware
approaches to this computational requirement.
FILTER

CO~IPUTATIONS

The bulk and Kalman filters play complementar~T roles in
support of a phased array radar. The task assigned to the
radar is to detect objects and identify those with certain characteristics e.g. objects which will impact a specified location
on the earth, and for those objects so identified, to provide
an accurate track of the expected flight path. The bulk filter
supports the selection process by eliminating from consideration all detected objects not impacting a specified area
while the Kalman filter provides smoothed track data for all
impacting objects. Both filters operate upon a predictive
basis with respect to the physical laws of motion of objects
moving in space near the carth. Starting with an observed
position, i.e., detection by a radar search look, the bulk filter
projects the position of the object forward in time, giving a
maximum and minimum range at which an impacting object
could be found in the next verification transmission. Based
upon this prediction the radar is instructed to transmit
additional verification looks to determine that this object
continues to meet the selection criteria by appearing at the
predicted spot in space following the specified time interval.
Those objects which pass the bulk filter selection criteria
are candidates for pr<.>cision tracking by the radar and in this
case the Kalman filter provides data smoothing and more
precise estimates of the object's flight path. Again a prediction is made of the object's position in space at some future
time based upon previously measured positions. The radar is
instructed to look for the object at its predicted position and
determines an updated object position measurement. The
difference between the measured and predicted position is
weighted and added to the predicted position to obtain a
smoothed position estimate. Both the bulk and Kalman
filter are recursive in the sense that measurement data from
one radar transmission is used to request future measurements based upon a prediction of a future spatial position of
objects. The prediction step involves evaluation of several
terms of a Taylor expansion of the equations of motion of
spatial objects. DrtaiJed discussion of thr mathC'matical basis
for thc'se filters can be found ill the: literature UIl jJhas(~d
array radars. !~"o

The computations required to support the bulk filter are
shown in Figure 1. The radar transmissions are designated as
either search or verify and it is assumed that every other
trans~ission is assigned to the search function. When an
object is detected, the search function schedules a subsequent
verification look typically after fifty milliseconds. If the
verification look confirms the presence of an object at the
predicted position another verification look is scheduled
again after fifty milliseconds. When no object is detected on a
verification look, another attempt can be made by predicting
the object's position ahead two time intervals i.e., one
hundred milliseconds, and scheduling another verification
look. This procedure is continued until at least M verifications have been made of an object's position out of N attempts.
If N - M attempts at verification of an object's position
result is no detection then the object is rejected. This type of
filter is termed an M out of N look bulk filter.
Turning now to the Kalman filter the computational
problem is much more complex. In this case a six or seven
element state vector containing the three spatial coordinates,
corresponding velocities, and optionally an atmospheric drag
coefficient is maintained and updated periodically for each
tracked object. A block diagram of this computation is shown
in Figure 2. The radar measurements are input to state
vector and weighting matrix update procedures. The
weighting matrix update loop involves an internal update of
a covariance matrix which along with the radar measurements is used to update a ,veighting matrix. The state vector
update calculation generates a weighted estimate from the
predicted and measured state vectors. The Kalman filter
computation is susceptible to decomposition into parallel
calculations and advantage can be taken of this in implementations for a parallel processor.
CO~IPUTATIOXAL ~IODELS

Bulk filter

The bulk filter is designed to eliminate with a minimum
expenditurr of computational resources a large number of
unintrresting objects which may appear in the field of view
of a phased array radar. A model for this situation requires

CORRELATE
RETURN WITH
PREDICTED

ASSIGN DllJECT
TO PROCESSIIIG

ELEMENT

REOUEST
vtRl'ICATION

TRANSMISSION

DllJECT POSITIOII

IIITIATE
PRECISION
TRACK

Missed IM,NI

M
Detections

REJECT
OBJECT

Detections I----~

REOUEST NEXT

VERIFICATION
TRANSMISSION

Figure 1 -Bulk filter flow diagram

Performance of Parallel Processors

assumptions for the number and type of objects to be handled,
efficiency of the filter in eliminating uninteresting objects,
and radar operational parameters. These assumptions must
produce a realistic load for the filter "\vhich would be characteristic of a phased array radar in a cluttered environment.
The assumptions, which are based upon the Advanced
Ballistic ::\'iissile Agency's Preliminary Hardsite Defense
study, are:

to + 25 ms

to + 50ms

103

to + 75ms

1-----50ms----~1

Search Return

1st Verify Return

Figure 3-Correlation and arithmetic phases

1. The radar transmits 3000 pulses, i.e. looks, per second
and every other one of these is assigned to search.
2. New objects enter the system at a rate of 100 per 10
milliseconds (Yrs) all of "'\-",hich are assumed to be
detected on one search look.
3. Fifteen objects are classified as being of interest, i.e.
impacting a designated area (must be precision
tracked), and 85 of no interest (should be eliminated
from track).
4. Following detection an attempt must be made to
locate each object not rejected by the filter every
50 NIs.
5. The filter selection criteria is 5 (::.vI) detections out of
7 (N) attempts. Failure to detect the object three
timt>.s in the sequence of 7 looks results in rejection.
6. The filter is assumed to reduce the original 100 objects
to 70 at the end of the third; 45 at the end of the
fourth; 30 at the end of the fifth; 25 at the end of the
sixth; and 20 at the end of the seventh look; thus
failing to eliminate 5 uninteresting objects.

being processed to determine if it represents new positional
information for an object being tracked by that processor.
For all objects in process, new data must be received every
50 2.\fs or it is considered to have not been redetected and
hence subject to rejection by the filter. The associative
processors studied were unable to carry out the required
calculations·within the pulse repetition rate of the radar
(330 J.l.sec). To achieve timely response, the processing was
restructured into correlation and arithmetic cycles as shown
in Figure 3. During the first 25 msec interval, the processors
correlate returns from the radar with internal data (predicted
positions). During the subsequent 25 msec interval, processors carry out the filter calculations and predict new
object positions. This approach allmved all required processing to be completed in a 50 msec interval. Objects which
fail the selection criteria more than two times are rejected
and their processor resources are freed for reallocation.

Ka-Zman filter
Based upon the above assumptions the bulk filter accepts
500 new objects every 50 ::.vIs. When operational steady state
is reached, the processing load becomes 100 search and 290
verify calculations every 10 ::\1s. Each object remains in the
filter for a maximum of 350 ::\fs and for a 50 ::.vfs interval 1950
filter calculations are required corresponding to 10,000 new
objects being detected by the radar per second.
The above process can be divided into two basic steps. The
first involves analysis of all radar returns. For search returns
the new data is assigned to an available processor. For verify
returns each processor must correlate the data with that
Track Return

Track Request
RADAR

RADAR TO STATE
VECTOR COORDINATE
TRANSFORMATION

EVALUATION APPROACH

UPDATE
STATE
VECTOR

UPDATE
WEIGHTING
MATRIX

MEASUIIEIIEIfT

PREDICT
NEXT STATE
VECTOR

STATE VECTOR
TO RADAR
COORDIIATE
TRANSFORIIA llOfI

Figure 2-Kalman filter flow diagram

The Kalman filter computation requires many more
arithmetic operations than the bulk filter. The radar becomes
the limiting factor in this case since only one object is assumed
for each look. Assuming a radar capable of 3000 transmissions
per second and a 50 ::'\ls update requirement for each precision track, a typical steady state assumption ·would be 600
search looks and 2400 tracking looks per second (corresponding to 120 objects in precision track). At this tracking
load it must again be assumed that the 50 ::\ls update interval
is divided into 25 :\ls correlation and compute cycles as was
done for the bulk filter and shown in Figure 3. This implies
that 60 tracks are updated every 25 .:'\'1s along with the same
number of verify looks being received and correlated.

UPDATE
COVARIANCE
MATRIX

The three quantities of interest in determining the relation
between a parallel processor organization and a given
problem are: resources required by the problem, resources
available from the processor configuration, and time constraints (if any). A more precise definition of these quantities
follows, but the general concept is that the processor capabilities and problem requirements should be as closely
balanced as possible.
Quantitative resource measures and balance criteria are
derived from Chen's14 analysis of parallel and pipelined
computer architectures. Chen describes the parallelism
inherent in a job by a graph with dimensions of parallelism

104

National Computer Conference, 1973

execution time with only one such processor (speedup over
the job). Expressing 11' in terms of job width W gives for
any job step

HARDWARE
SPACE
= MTA

11'=

JOB SPACE

~WITI~T

sequential processor execution time
•
•
parallel processor executIOn tIme

WeT)
'

(3)

Similarly, averaging this quantity over an entire job during
the available time gives:
N

L W(Ti)IlT

i=O

ir= - - - - - -

(4)

ir=iiM

(5)

Figure 4-Hardware and job space diagram

width (number of identical operations which may be performed in parallel) and execution time. The ratio p is defined
for a job as the area under the step(s) showing parallelism
(width W> 1) divided by the total area swept out by the
job. Thf' hardware pfficiency factor, '1], is the total job work
space (defined as the product of execution time and the
corresponding job width lV summed over all computations)
over the total hardware work space (defined as the product
of total execution time and the number, M, of available
parallel processors). This provides a measure of utilization of
a particular hardware ensemble for each segment of a computation. A modification of Chen's 'I] allows consideration of
time constraints. Hardware space will now be defined as a
product of the total time available to carry out the required
computation times 1t.f, the number of processors available.
Call this ratio ii. The work space is as defined above except
that periods of no processor activity may be included, i.e.,
job width W =0. Figure 4 illustrates these concepts showing a
computation involving several instruction widths carried out
in an available computation time Ta. The stepwise value of 'I]
varies during job execution and the average value for the
whole job becomes: (Ta is divided into N equal time intervals =IlT, W(T i ) >0 forK steps).

i i = - - - - - where
MTa

T/= - - - - -

MKIlT

(1,2)

Note that under this interpretation, ii measures the fit between this particular problem and a given configuration.
If ii = 1.0 the configuration has precisely the resources required to solve the problem within time constraints, assuming
that the load is completely uniform (with non-integral ,,'idth
in most cases). Although ii will be much less than 1.0 in most
cases, it is interesting to compare the values obtained for
processors of different organizations and execution speeds,
executing the same job (identical at least on a macroscopic
scale). Implicit in the stepwise summation of the instruction
time-processor width product are factors such as the
suitability of the particular instruction repertoire to the
problem (number of steps), hardware technology (execution
time), and organizational approach (treated in the following
section) .
A criterion 11' is expressed as the inverse ratio of time of
execution of a given job with parallel processors to the

or simply:
which states that the speed of execution of a computation on
parallel hardware as contrasted to a single processing element
of that hardware is proportional to the efficiency of hardware
utilization times the number of available processing elements.
Again, ir measures the equivalent number of parallel processors required assuming a uniform load (width = if,
duration = Ta).
PROCESSOR ORGANIZATIONS
General observations
In the analysis which follows, job parallelism is calculated
on an instruction by instruction step basis. For the purposes
of this discussion, consider a more macroscopic model of job
parallelism. Sets of instructions with varying parallelism
widths will be treated as phases (lJI i ) , with phase width
defined as the maximum instruction width within the phase.
(see Figure 5, for a three phase job, with instructions indicated by dashed lines).
Given this model, it is possible to treat the parallel component in at least three distinct ways (see Figure 6). The
simplest approach is to treat a parallel step of width N as N
steps of width one which are executed serially. This would
correspond to three loops (with conditional branches) of
iteration counts Wl, W 2, W a, or one loop with iteration count
max[Wl , W 2 , W a]. The worst case execution time (macroscopic model) for width N would be T=Nts.
Parallel processing, in its purest sense, devotes one processing element (PE) to each slice of width one, and executes
the total phase in T = ta, where ta is the total execution time
for any element. Variations on this basic theme are possible.
For example, STARAN, the Goodyear Aerospace associative

PARALLELISM
WIDTH

I
I

r-I

r--'I

¢3

¢2

:
---"'1

W3
I

-..,

I
I

r-I

- t l - -t2 - - -t3 Figure 5-Three phase jtlb space diagram

TIME

Performance of Parallel Processors

processor,5,9,l2 is actually an ensemble of bit-slice processors lS
arranged in arrays of 256 each having access to 256 bits of
storage. The ensemble is capable of bitwise operations on
selected fields of storage. Since the bulk filter algorithm
requires 768 bits of storage for the information associated
with one filter calculation, i.e. track, a "black box" model
devotes three PE's to each object in track (generally one of
the three is active at any instruction step).
The converse of the STARA~ case is exemplified by the
Parallel Element Processing Ensemble (PEPE) ,6 which
devotes M PE's to N tracks, Jf ~l:ill}ffi!1~tJ~~.h~n~l~db.y.sgparateJ)roce,ss.Qrs.

A third approach is analogous to the pipelining of instruction execution. Assuming that each phase has execution time
tp, one could use one sequential processor to handle execution
of each phase, buffering the input and output of contiguous
DATA

RESULT
ts

T = Nts

Sequential Processor

DATA

.....

RESULT

T = ta
f----......

f----DN

f-----

105

phases to achieve a total execution time of T= (N -l+m)tp
for an 1l.f stage process. The Signal Processing Element (SPE)
designed by the US Naval Research Laboratory'5 can utilize
this strategy of functional decomposition, linking fast microprogrammed arithmetic units under the control of a
master control unit to achieve tp~M-'ts for "sequential" machines of the CDC 7600, IB1I 370/195 class
(T~ [~"11-'(N -1) +l]ts).
One other factor of considerable importance is the number
of control streams active in each processor array. The simplest
arrangement is a single control stream, broadcast to all
elements from a central sequencing unit. Individual PE's may
be deactivated for part of a program sequence by central
direction, or dependent upon some condition determined by
each PE. Dual control units mean that arithmetic and
correlative operation can proceed simultaneously, allowing
the t\'"Q .ph~_s~ ~trl1tegy.Qutli:u.e_d.__.e_a.dier t.o.IDrrk. efficiently
(one control stream would require an "interruptible arithmetic" strategy, or well defined, non-overlapping, search/
verify and arithmetic intervals). These two control streams
can act on different sets of PE's (e.g. each PE has a mode
register which determines the central stream accepted by that
PE), or both control streams can share the same PE on a
cycle stealing basis (PEPE IC model).

Configurations considered

Table I presents the basic data on the four hard,vare configurations considered for the bulk filter problem. Sizing
estimates are based upon the assumptions described previously, i.e. 1950 tracks in processing at any given time (steady
state). Over any 25 11s interval, half of the tracks are being
correlated, half are being processed arithmetically.
The Kalman filter results compare the performance of
STARAN, PEPE (IC model), and the CDC 7600 in sustaining a precise track of 120 objects (1 observation each
50 ::\1s) using a basic model of the Kalman filter algorithm.
The STARAN solution attempts to take advantage of the
parallelism within the algorithm (matrix-vector operations).
Twenty-one PE are devoted to each object being tracked .
PEPE would handle one Kalman filter sequence in each of its
PE's, performing the computations serially within the PE.

CO :VIPARATIVE RESULTS

Parallel Processor
Bulk filter
RESULT

DATA

§~--DI§

T = IN+lltp
=

IN-l+Mltp

For M Stages

L---.lN

Functional Pipeline

Figure 6- Decomposition of parallelism in three processor organizations

Table II presents the values for 'YJ, 71, ir, and execution time
for each of the 4 processor configurations. As has been explained earlier 'YJ and ij differ only in the definition of hardware
space used in the denominator of the 'YJ expression. It is
interesting to note that although the efficiency 71 over the
constrained interval is not large for any of the parallel
processors, all three do utilize their hardware efficiency over
the actual arithmetic computation ('YJ). The implication is
that some other task could be handled in the idle interval, a

106

National Computer Conference, 1973

TABLE I-Bulk Filter Processor Configuration Comparison
STARAN
3 PE/TRACK

HONEYWELL
PE/TRACK

PEPE (IC model)
PE/20 TRACK

1950

Number of PE's (1950 track load)

30 Arrays =7680 PE's

32 bit fixed point Add time/PE

18.0,usee

Control Streams

Single-(Standard opDouble-Each PE may
tion) all PE's correlate
be in correlation or
arithmetic mode
or perform arithmetic
functions

Approximate gate count/PE (not including storage)

82 (21,000/256 PEarray)

Gate Count for configuration (PE's
only)

100

.75,usee

630,000

CDC 7600
SEQUENTIAL

.25,usec

27.5-55 n.s. (60 bit)

Double-EACH PE may Single pipelined
perform correlation and
arithmetic functions
simultaneously

2,400

9,000

170,000

4.68X106

900,000

170,000

Adds/secX1()6 (",MIPS)

427

2600

400

Gates/track

320*

2400

450

* Based on a 30 Array configuration-246 are required for the algorithm.

more sophisticated filter algorithm could be used, or the
PE's could be built from slower, less expensive logic. It
should be stressed that the gate counts given are strictly
processing element gates, not including memory, unit control,
or other functions.
Kalman filter
As noted above, 60 precision tracks must be updated in
25 ~'ls while 60 track looks are being correlated. Benchmark
data for the CDC 7600 indicates that a Kalman filter calculation consisting of 371 multiplies, 313 add/subtracts, 2
divides, 6 square roots, and 1 exponentiation will require
approximately 0.3 ~ls (18 1\1s for 60 tracks). This leaves a
reserve of 7 ~1s out of a 25 Ms interval for correlation. An
analysis of the STARAN processor applied to the Kalman
filter l2 indicates that with 21 processing elements assigned to
each precision track the calculation can be carried out in
slightly less than 25 Ms. This performance is achieved by
decomposing the filter calculation into 56 multiplies, 61
add/subtracts, 3 divides, 4 square roots and is achieved at
the cost of 322 move operations. Figure 7 shows the processor
activity for the first 15 instructions of the Kalman filter
sequence. One bank of STARAN processing elements (5256
element arrays) containing 1280 processors is required to
update tracks for 60 objects in one 25 ::Vls interval and correlate returns during the other. The PEPE configuration would
require 60 processing elements (two track files per element)
taking advantage of this hardware's ability to do arithmetic
calculations and correlations simultaneously, achieving a
45 percent loading (11.3 ~ls execution time per Kalman filter
sequence) of each PEPE processing element. Table III
summarizes the Kalman filter results.

tions described in the studies. 9 ,IO,1l,12 Each of the proposed
configurations is more than capable of handling the required
calculations in the time available. System cost is really
outside the scope of this paper. In particular, gate count is
not a good indicator of system cost. The circuit technology
(speed, level of integration) and chip partitioning (yield,
number of unique chips) trade-offs possible "ithin the current
state of the art in LSI fabrication relegate gate count to at
most an order of magnitude indicator of cost.
Each of the three parallel processor organizations represents
a single point on a trade-off curve in several dimensions (i.e.
processor execution speed, loading, and cost, control stream
philosophy, etc.). Given an initial operating point, determined
by the functional requirements of the problem, the system
designer must define a set of algorithms in sufficient detail to
TABLE II-Results of Bulk Filter Analysis

STARAN
3 PEl
TRACK
Correlation time
7J~1
7I"¢1

1i~1

ir~l

Arithmetic time
7J~2
7I"~2

1i~2
7I"~2

Total time
."
71"

OBSERVATIONS AXD COXCLUSIOKS
It should be emphasized that this study was not an attempt
to perform a qualitatiyc cyaluation of the procC'~SQr organiza-

.".MIPS

-----

1.8 msec
.036
139
.0026
9.9
14.5 msec
.66
2450
.38
1470
16.3 msec
.30
2270
.19
1480
128

CDC
HONEYPEPE (IC 7600 SEWELL
model) PE/20 QUENPE/TRACK TRACKS
TIAL
15.9 msec
.035
34
.022
22
5.1 msec
.80
780
.16
159
21 msec
.11
216
.093
181
286

2.1 msee
.68
68
.057
5.7
3.85 msec
.79
79
.122
12.2
5.95 msec
.75
75
.18
18
300

22 msec
1.0
1.0
.88
.88

Performance of Parallel Processors

convince himself that he can operate 'within any given constraints. Fine tuning of the system is accomplished by
restructuring the algorithms, redefining the operating point,
or both. In the two cases treated in this paper, elapsed time
is the crucial measure of system performance (in a binary
sense-it does or does not meet the requirement). The
purpose of the 7] and 71 calculations, as well as the step by step
processor activity diagrams is to provide some insight-beyond
the elapsed time criteria which might be helpful in restructuring algorithms, or modifying some aspect of the system's
architecture such as control stream philosophy. The properties of the processor activity diagrams are of significant
interest in determining the number of PE's that are required
to handle the given load (uniform load implies fewer PE's
and higher 7]). The measures used in this paper are of some
interest because of the fact that they are functions of problem
width and instruction execution time) allowing factors such
as the selection of a particular instruction set to enter into
the values of the resultant tuning parameters.
Several more specific observations are in order. First, for
the particular bulk filter case considered, the CDC 7600 can
easily handle the computational load. Proponents of the
parallel processor approach ,,,"ould claim that quantity
production of PE's, utilizing LSI technology, would enable
them to produce equivalent ensembles at less than a CDC
7600's cost. In addition, computation time for the parallel
ensembles is only a weak function of the number of obj ects in
the correlation phase, and essentially independent of object
load in the arithmetic phase. Therefore, it would be simple to
scale up the capabilities of the parallel processors to handle
loads well beyond the capability of a single, fast sequential
processor. The functional pipelining approach advocated by
the Xaval Research Laboratory would appear to be the
strongest challenger to the parallel approach in terms of
capabilities and cost (and to a somewhat lesser extent,
flexibility). Very rough estimates indicate that the bulk filter
case presented here could be handled by no more than two
arithmetic units (each with ,....,.,10,000 gates) and a single
microprogrammed control unit (,....,.,5,000 gates). Tasks which
stress the correlative capabilities of parallel arrays rather than

# ACTIVE
ElEMENTS

ELASPED TIME IMICROSECOfl)S}

Figure 7-STARAN Kalman filter loading (one track, first 15
instructions)

107

TABLE III-Results of Kalman Filter Analysis

Time
7f
11"

'ii
ir

7f}LMIPS
gates/track

STARAN

PEPE (IC model)

CDC 7600

25 Ms
"".5
640
"".5
640
36
875

11.3 Ms
>.9
>54
.45
27
108
4500

18 Ms
1
1
.72
.72
13
1400

NOTE: Correlation time for the Kalman filter is not significant ("" 100
}Ls) since each track is assigned a unique track number number (120

total). Accordingly, only total time figures are presented.

the parallel arithmetic capabilities should show the parallel
array architecture to its greatest advantage.
ACKNO'WLEDG:\;IEKTS
The authors wish to express their gratitude to ~fessrs.
Brubaker and Gilmore, Goodyear Aerospace Corporation
for providing STARAK logic gate counts and Kalman filter
computation timing estimates; to }Ir. W. Alexander, Honeywell Inc. for providing PEPE and Honeywell Associative
Processor Logic gate counts; and to Jlr. J. Burford, Control
Data Corporation for providing the CDC 7600 logic gate
counts. The study reports9 ,lo,1l were prepared under the
direction of the Advanced Ballistic ~,1issile Defense Agency,
whose cooperation is greatly appreciated."

REFERENCES
1. Conway, M. E., "A Multi-Processor System Design," Proceedings

AFIPS, FJCC, Vol. 24, pp. 139-146, 1963.
2. Stanga, D. C., "UNIVAC l108 Multi-Processor System," Proceedings AFIPS, SJCC, Vol. 31, pp. 67-74,1967.
3. Blakeney, G. R., et aI, "IBM 9020 Multiprocessing System," IBM
Systems Journal, Vol. 6, No.2, pp. 80-94,1967.
4. Slotnik, D. L., et aI, "The ILLIAC IV Computer, IEEE Transaction on Computers, Vol. C-17, pp. 746-757, August 1968.
5. Rudolph, J. A., "STARAN, A Production Implementation of an
Associative Array Processor," Proceedings AFIPS, FJCC, Vol. 41,
Part I, pp. 229-241, 1972.
6. Githens, J. A., "A Fully Parallel Computer for Radar Data Processing," NAECON 1970 Record, pp. 302-306, May 1970.
7. Anderson, D. W., Sparacio, F. J., Tomasula, R. M., "Systemj360
~Y10D 91 Machine Philosophy and Instruction Handling," IBM
Journal of Research and Development, Vol. II, No.1, pp. 8-24,
January 1967.
8. Hintz, R. G., "Control Data Star 100 Processor Design," Proceedings COMPCON '72, pp. 1-10, 1972.
9. Rohrbacher, Terminal Discrimination Development, Goodyear
Aerospace Corporation, Contract DAHC60-72-C-0051, Final
Report, March 31, 1972.
10. Schmitz, H. G., et aI, ABMDA Prototype Bulk Filter Development,
Honeywell, Inc., Contract DAHC60-72-C-0050, Final Report, April
1972, HWDoc #12335-FR.
11. Phase I-Concept Definition Terminal Discrimination Development Program, Hughes Aircraft Company, Contract DAHC60-72C-0052, March 13, 1972.

108

National Computer Conference, 1973

12. Gilmore, P. A., An Associative Processing Approach to Kalman
Filtering, Goodyear Aerospace Corporation, Report GER 15588,
March 1972.
13. Kalman, R. E., "A New Approach to Linear Filtering and Prediction Problems," Journal of Basic Engineering, Vol. 820, pp. 35-45,
1960.

14. Chen, T. C., "Unconventional Superspeed Computer Systems,"
Proceedings AFIPS, SJCC, Vol. 39, pp. 365-371, 1971.
15. Ihnat, J., et aI, Signal Processing Element Functional Description,
Part I, NRL Report 7490, September 1972.
16. Shore, J. E., Second Thoughts on Parallel Processing, :t\aval
Research Laboratory Report #7364, December 1971.

A structural approach to computer performance
analysis
by P. H. HUGHES and G. MOE
University of Trondheim
Norway

is a series of requests for action by one or more devices,
usually in a simple, repetitive sequence.
The way in which instructions are interpreted means that
the central processor is involved every time I/O action is to
be initiated, so that every program can be reduced to a
cycle of requests involving the CPU and usually one or more
other devices.
In a single program system, devices not involved in the
current program remain idle, and the overlap between CPU
and I/O activity is limited by the amount of buffer space
available in primary store. Performance analysis in this
situation is largely a matter of device speeds and the design
of individual programs.
~Iultiprogramming overcomes the sequential nature of
the CPU-I/O cycle by having the CPU switch between
several such programs so as to enable all devices to be driven
in parallel. The effectiveness of this technique depends upon
several factors:

IXTRODUCTIOK
The perfOl'm-aR~-e analysis of computer systems is as yet a
rather unstructured field in which particular aspects of
systems or items of software are studied 'with the aid of
various forms of models and empirical measurements.
Kimbleton 1 develops a more general approach to this problem
using three primary measures of system performance. The
approach to be described here represents a similar philosophy
but deals only with throughput as the measure of system
performance. This restriction results in a model which is
convenient and practical for many purposes, particularly in
batch-processing environments. It is hoped that this approach
will contribute to the development of a common perspective
relating the performance of different aspects of the system to
the performance of the 'whole.
The present work arises out of a continuing program of
performance evaluation begun in 1970 on the UNIVAC 1108
operated by SIXTEF (a non-profit engineering research
foundation) for the Technical University of Norway (KTH)
at Trondheim. The status of the Computing Centre has since
been revised, such that it now serves the newlv formed
University of Trondheim which includes NTH.
Early attention focused on trying to understand EXEC 8
and to identify possible problem areas. One of the early
fruits of the work is described in Reference 2. However the
main emphasis for most of 1971 was on the development of
benchmark techniques supported by a software monitoring
package supplied by the University of Wisconsin as a set of
modifications to the EXEC 8 operating system. 3 •4 It was in an
effort to select and interpret from the mass of data provided
by software monitoring that the present approach emerged.
The operation of a computer system may be considered at
any number of logical levels, but between the complexities of
hardware and software lies the relatively simple functional
level of machine code and I/O functions, at ","hich processing
takes physical effect. The basis of this paper is a general
model of the processes at this physical level, to which all
other factors must be related in order to discover their net
effect on system performance.

(i) the buffering on secondary storage of the information
flow to and from slow peripheral devices such as
readers, printers and punches ('spooling' or 'symbiont
activity') .
(ii) the provision of the optimum mix of programs from
those 'waiting to be run so that the most devices may
be utilised (coarse scheduling).
(iii) a method of switching between programs to achieve
the maximum processing rate (dynamic scheduling).

These scheduling strategies involve decisions about
allocating physical resources to programs and data. The
additional complexity of such a system creates its own
administrative overhead which can add significantly to the
total v,"orkload. The success of the multiprogramming is
highly sensitive to the match behveen physical resources and
the requirements of the workload. In particular there must be:
(iv) provision of sufficient primary store and storage
management to enable a sufficient number of programs to be active simultaneously.
(v) a reasonable match between the load requirements on
each device and the device speed and capacity so as
to minimise 'bottleneck' effects whereby a single
overloaded device can cancel out the benefits of
multiprogramming.

THE GENERAL XATURE OF THE WORKLOAD
At the level we shall consider, a computer is a network of
devices for transferring and processing information. A program
109

110

National Computer Conference, 1973

CPlj

I/O DEV:CES

(FH"32 )
(FH880)

p processes

values for each device. First-in first-out queuing disciplines
are also assumed. This is not strictly valid under EXEC 8 in
the case of the CPU, but the assumption does not upset the
general behaviour of the model.

(FASTRAND)
(MAGNETIC TAPE)

Throughput and load
Figure I-Configuration used by the model. Names in parentheses
denote corresponding equipment

Such a system, if properly configured and tuned, can
achieve a throughput rate several times greater than a single
program system. Performance analysis becomes much more
complex, but correspondingly more important.
A

~VIODEL

OF THE PHYSICAL WORKLOAD

We wish to model a number of independent processes, each
consisting of a cycle of CPU-I/O requests. In real life, the
nature of these processes changes dynamically in an extremely complex way and we introduce several simplifying
assumptions:
(i) the processes are statistically identical and are always
resident in core store.
(ii) requests by a process are distributed among devices
according to a stationary, discrete probability distribution function f.
(iii) the time taken to service a request on a particular
device i is drawn from a stationary distribution
function s.
Figure 1 illustrates the network we have been using.
The names in parentheses refer to the particular equipment
in use at our installation. FH432, FH880, and FASTRAND
constitute a hierarchy of fast, intermediate, and large slow
drums respectively.
We restrict the model to those devices which satisfy the
constraint that any process receiving or waiting to receive
service from the device must be resident in core store. If a
process requires service from a device which does not satisfy
this constraint (e.g., a user terminal) it is no longer 'active'
in the terms of the model. Normally it ",ill be replaced in
core by some other process which is ready to proceed. This
restriction rules out an important class of performance
variables such as system response time, but has corresponding advantages in dealing with throughput.
At any instant the number of active, in-core processes p is
discrete, but the average over a period of time may be noninteger, as the mix of programs that will fit into core store
changes. In addition p includes intermittent processes such as
spooling which will contribute fractionally to its average
value. We will refer to p as the multiprogramming factor.
This is to be distinguished from the total number of open
programs (including those not in core store) which is sometimes referred to as the degree of multiprogramming.
In the first instance, all distribution functions have been
assumed to be negative exponential vlith appropriate mean

We may define the throughput of such a network to be the
number of request cycles completed per second for a given
load. The load is defined by two properties
(i) the distribution of requests between the various
devices
(ii) the work required of each device.
This 'work' cannot be easily specified independently of the
ch~racteristics of the device, although conceptually the two
must be distinguished. The most convenient measure is in
terms of the time taken to service a request, and the distribution of such service times ",ith respect to a particular
device.
For a given load, the distribution of requests among
N devices is described by a fixed set of probabilities
fi (i = 1, ... N). The proportion of requests going to each
device over a period of time will therefore be fixed, regardless
of the rate at which requests are processed. This may be
stated as an invariance rule for the model, expressible in two
forms "ith slightly different conditions:
For a given load distribution f
(i) the ratio of request service rates on respective devices
is invariant over throughput changes and
(ii) if the service times of devices do not change, the ratio
of utilizations on respective devices is invariant over
throughput changes.
Behaviour of the model

Figures 2 (a), 2 (b) show how the request service rate and
the utilization of each device vary with the number of active
processes p, for a simulation based on the UNIVAC 1108
configuration and workload at Regnesentret.
These two figures illustrate the respective invariance rules
just mentioned. Furthermore the b;o sets of curves are
directly related by the respective service times of each device
j. In passing we note that the busiest device is not in this
case the one with the highest request service rate, \vhich is
alwavs the CPU. Since we have assumed that service times
are i~dependant of p (not entirely true on allocatable devices),
it is clear that the shape .of every curve is determined by the
same function F(p) which we will call the multiprogramming
gain function, shown in Figure 2 (c) .
This function has been investigated analytically by
Berners-Lee. 5 Borrowing his notation, we may express the
relationship of Figure 2(b) as
Xj(p)=F(p)xj

for j=1,2, ... N

(1)

A Structural Approach to Computer Performance Analysis

::~:::: rr re~~es:s ~er
50

sec.

ra:e

Fig.2(a)~_

!'a't':'o be-':'Nee:::

curves deter:nined
bv t:he load on
d~vices
FH u 32

~~~~:::D

~_ _ _ _ _ _ _ ~ag"etic tape
1

Improving system throughput

_
:AST~ANCl

0.8

0.6

2(b)~_--- cpu

0.4

ratio between
curves determir.ed
by the product 0:
load and service
tine far each
device

~
-

FH432

,.,"',. ""

(i) by increasing the mUlti-programming factor
(ii) by improving the match between system and workload

(iii) by reducing the variance of request service times
(iv) by improving the efficiency of the software so that
the same payload is achieved for a smaller total
\vorkload.

s lODe of C:.lrve
det~rmined by
rela"'[ive device
utilizations

Fig.

We shall consider in detail two ways of improving the
throughput of such a system:

Later we shall encounter two further ways by which
throughput could be improved:

FH880

0.'

cesses q satisfying q~min(p, N) are actually being serviced
at any instant, while (p-q) processes ,vill be queuing for
service.
It follows that the time-averaged value of q must be F (p),
so that one may regard F (p) as the true number of processes
actually receiving service simultaneously. Since q is limited
by the number of devices N it follows that the maximum
value of F (p) must be N which we would expect to be the case
in a perfectly balanced system, at infinitely large p.

Utili:~:ir _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _

Fig.

111

Figure 2-Behaviour of model as a function of the multiprogramming
factor p

where Xj(p) is the utilization of device j when p processes
are active and Xj is identical with Xj(l), the corresponding
utilization when only one process is active.
Now when only one process is active, one and only one
device will be busy at a time, so that
(2)

Summing equations (1) for all devices, we have

Increasing the multiprogramming factor

We may increase the number of active processes by either
acquiring more core store or making better use of what is
available by improved core store management, or smaller
programs. The latter two alternatives may, of course, involve
a trade-off with the number of accesses required to backing
store.
The maximum gain obtainable in this way is limited by
the utilization of the most heavily used device-the current
"bottleneck." If the present utilization of this device is X m ,
and the maximum utilization is unity, then the potential
relative throughput gain is l/Xm (Figure 3). The practical
limit will of course be somewhat less than this because of
diminishing returns as p becomes large. A simple test of
whether anything is to be gained from increasing p is the
existence of any device whose utilization approaches unity.
If such a device does not exist then p is a "bottleneck."
However, the converse does not necessarily apply if the
limiting device contains the swapping file,

Xj(p) =F(p)

(3)

Matching system and workload

j=l

That is, the multiprogramming gain for some degree of
multiprogramming p is equal to the sum of the device
utilizations.
It is instructive to consider the meaning of the function
F(p) . .:\Iultiprogramming gain comes about only by the
simultaneous operation of different devices. If there are p
parallel processes on lv~ devices, then some number of pro-

This method of changing performance involves two effects
which are coupled in such a way that they sometimes conflict
with each other. They are:
(a) Improvement In monoprogrammed system
formance
(b) Improvement in multiprogramming gain

per-

112

National Computer Conference, 1973

The limiting throughput corresponding to F I is obtained
by substituting in (4) using (5) and (6).
1

LfiSi

R z= - - · By definition
m,..l~ ~iprogrammir..g

factor

Figure 3(a)-The effect of increasing multiprogramming on the
utilization of the limiting device m

so that
1
R ,= fmsm

Mlll"[:' :;!"'ogramrr.'::lg

Gair:

(7)

For a balanced system,

Figure 3(b)-The effect of increasing multiprogramming on the
multiprogramming gain function F(P)

These two components of system performance are seen in
(4) where r is the total no. of requests processed per second
on all devices when p = 1, and R is the corresponding total at
the operational value of p (Fig. 2(a)).
R=F(p)r

(4)

Clearly we may improve the total performance R by improving either r or F (p), but we shall see that any action we
take to improve one has some "effect on the other.
At p = 1 the mean time to perform any request is L fiSi
hence
1
r= LfiSi

(5)

In considering the potential mUltiprogramming gain F (p ) ,
it is useful to examine the limiting value F I as p becomes large.
Applying equation (1) to the limiting device m we have

F(p) = Xm

and, as p becomes large,
1
F ,= -

(6)

The only way of improving F, is to reduce the monoprogrammed utilization x m • But since m is the limiting device
and

it follows that Xm must have a lower bound of liN, at which
point all Xi must be equal to liN and F,=~V. This is the
condition for a balanced system.

and from (4) Rz (balance)=Nr
It is important to note that while a balanced system is a
necessary and sufficient condition for a maximum potential
multiprogramming gain F it is not necessarily an appropriate
condition for a maximum"throughput R at some finite value
of p. This is because of the coupling between F(p) and r.
We shall now use equations (5) to (8) to examine informally the effect, at high and low values of p, of two
alternative ways of improving the match between system
and workload. They are
(i) to reduce device service times
(ii) to redistribute the load on I/O devices
Effect of reducing service time
Let us consider reducing service time Sf on device i From
(5), r will always be improved, but it will be most improved

(for a given percent improvement in Sf) when !isf is largest
with respect to L fiSi i.e. when j = m, the limiting device.
From (7), if j ¥=m, Rz is not affected by the change but if
j = m then Rz is inversely proportional to the service time.
Thus we may expect that for the limiting device, an improvement in service time will always result in an improvement in throughput but this will be most marked at high
values of p. Speeding up other devices will have some effect
at low values of p, diminishing to zero as p increases (Fig.
4(a)) .
If a limiting device j is speeded up sufficiently, there will
appear a new limiting device k. We may deal with this as two
successive transitions with j = m and j ¥=m separated by the
boundary condition !iSj = fkSk.
Redistributing the load
This alternative depends on changing the residence of files
so that there is a shift of activity from one device to another.
Here we must bear in mind two further constraints. Firstly
this is not possible in the case of certain devices, e.g. the CPU
in a single CPu system. t:;econdly, a conservation rule

A Structural Approach to Computer Performance Analysis

System
Thr;ughPU'

j=n

RR,

113

redistribution depends both on the multiprogramming factor
and on how the load on the limiting device is affected by the
change. Redistribution is most effective if it reduces the load
on the limiting device. Successive applications of this criterion
will eventually lead to one of two situations:
either
(1) the CPU becomes the limiting device (CPU-bound
situation) .
or

rr.ul-: iprogrammi:-.g f ac"':or p

Figure 4(a)-The effect of reducing service time on device j

System
Throughput
i=m (liciting device)

RR,

Original curve
j=~

(limiLing device)

rnultiprograIT~ing

factor p

Figure 4(b)-The effect of redistributing the load from device i to a
faster device j

usually applies such that work removed from one device i
must be added to some other devicej.
That is
(9)
Consider the effect of s"\\'-itching requests from any device i
to a faster device j. Since Sj

(I:

'''Yo_cal Workload /

!ly:oaT:c

p~.yroa:

I -,-,,'-n._ .... '- - .. '
H

LEVEL 11

SCP.E[)ULltJG C'f

wORKU!\J

TO OF'?Iv.TSE

;.)or~>:",~

:":::VEL ~

~!"'

'::)N~'I:;L'!=!=~~G

:-: ':::'~. ::"[1'" -:-C

.:\.1r:

:;f.~:SJ:< .

."':£:.-:~;-!

""'t:::

·w..,:C'~;r:_">~D

Figure

8-Structur~1

view of pl'rform~n('e

~n~lv<;i"

At this level the users processing requirements are given
explicit shape in some programming language, or by the
selection of a particular application package. Processing is
defined in terms of records, files and algorithms. The net
result from this level of decision making is the identifiable
workload of the computer. This is the 'payload', which the
user wishes to pay for and which the installation seeks to
charge for. Unfortunately, accounting information provided
by the system is often only available on a device-oriented
rather then file-oriented basis, and compounded with effects
from lower levels in the system.
This is the level at which benchmarks are prepared for
purposes of computer selection or testing of alternative configurations. In the case of computer selection, the aim must be
to withhold as many decisions as possible about how the
users requirements ,,"ill be implemented, since this is so
dependent upon available facilities. The alternative is to
follow up the ramifications of each system. Thus in general,
a quantitative approach to computer selection is either inaccurate or costly, or both.
Benchmarks for a given range of computers are a more
feasible proposition since they can be constructed on the
output of levpl .5, leaving open as man:v rf'source allocation

A Structural Approach to Computer Performance Analysis

decisions as possible, so that the most can be made of alternative configurations.

Level 4 translation
By this is intended the whole range of software including
input/output routines and compilers by which the punched
instructions of the programmer are translated into specific
machine orders and the results translated back again into
printed output.
Factors involved at this level 'will include optimization of
code, efficiency of compilers, buffer sizes determined by
standard I/O routines. It is clear that these will in turn affect
the core size of programs, the length of CPU requests and the
number and length of accesses to different files. The output
from this stage is the generated \vorkload, and its relation to
the payload might be thought of as the 'efficiency' of the
system software. Improving this efficiency is the fourth way
of improving system performance, referred to in a previous
section.

Level 3 static resource allocation
At this level, decisions are concerned with matching processing requirements to the capacity of the configuration.
Decisions are made about the allocation of files to specific
devices, taking account of configuration information about
physical device capacity, number of units, etc. We also
include here the decision to 'open' a job, implying the assignment of temporary resources required for its execution. This
is done by the coarse scheduling routines, which also decide
on the number and type of jobs to be simultaneously open
and hence the job mix which is obtained. Both user and
operator may override such decisions, subordinating machine
efficiency to human convenience.
The decisions taken at this level may influence the maximum number of parallel processes and the relative activity
on different I/O devices.

Level 2 dynamic resource allocation
By 'dynamic' we mean decisions taken in real time about
time-shared equipment, namely the CPu and primary store.
The number of active parallel processes is that number of
processes which are simultaneously requesting or using
devices in the system. To be active a process must first have
primary store, and the dynamic allocation of primary store
governs the number of processes active at any instant.
Given the processes with primary store, the system must
schedule their service by the CPU, which in turn gives rise
to requests for I/O devices. The rules for selection among
processes and the timeslice that th('~· are allo\\-ed "'ill influence
the instantaneous load on devices. In terms of the model, this
will influence the shape of the distributions of load f and
service time s which in turn influence the shape of the gain
function F (p).

119

Level 1 execution
At this level, the final load has been determined, so that
the remaining effects on performance are due to the physical
characteristics of the devices. Unfortunately, it is difficult to
express the load in terms which are independent of the
specific device. The function f gives the distributions of
requests, but the service time s is a compound of load and
device speed as we have discussed. However, it is at least a
quantity which can be directly monitored for a given workload and configuration, and one may estimate how it is
affected by changes in device characteristics.
In principle, the important parameters of our model can
be monitored directly at this level of the system, although
\ve have not yet succeeded in obtaining an empirical value for
p. However, the model depends for its simplicity and power
on the correct use of the distributions of these parameters
and investigations continue in this area.
CO~CLUSION

We have presented a set of concepts which have been developed in an effort to master the performance characteristics
of a complex computer system. These concepts, together ,,-ith
the simple queuing model which enables us to handle them,
have proven their usefulness in a variety of practical situations, some of which have been described.
The application of these concepts depends upon having
the necessary information provided by monitoring techniques, and conversely provides insight in the selection and
interpretation of monitor output. While such abstractions
should whenever possible be reinforced by practical tests,
such as benchmarks, they in turn provide insight in the
interpretation of benchmark results.
In its present form the model is strictly concerned \"ith
throughput and is not capable of distinguishing other performance variables such as response time. This severely
restricts its usefulness in a timesharing environment, but is
very convenient in situations where throughput is of prime
concern.
Consideration of the distinct types of decisions made
within the computer complex, suggests that it may be possible
to assess the effect of different system components on overall
performance in terms of their effect on the basic parameters
of the model.
It is thought that the approach described may be particularly useful to individual computer installations seeking an
effective strategy for performance analysis.

REFERENCES
1. Kimbleton. S. R.. "Performance Evaluation-A Structured

Approach," Proceedings AFIPS Spring Joint Computer Conference, 1972, pp. 411-416.
2. Strauss, J. C., "A Simple Thruput and Response Model of EXEC 8
under Swapping Saturation," Proceedings AFIPS Fall Joint
Computer Conference, 1971, pp. 39-49.

120

National Computer Conference, 1973

3. Draper, M. D., Milton, R. C., UNIVAC 1108 Evaluation Plan,
University of Wisconsin Computer Center, Technical Report No.
13, March 1970.
4. Hughes, P. H., "Developing a Reliable Benchmark for Performance Evaluation," NordDATA 72 Conference, Helsinki, 1972. Vol.
II, pp. 1259-1284.

5. Berners-Lee, C. M., "Three Analytical Models of Batch Processing
Systems," British Computer Society Conference on Computer
Performance, University of Surrey, Sept. 1972, pp. 43-52.
6. Florkowski, J. H., "Evaluating Advanced Timesharing Systems."
IBM Technical D~~closure Bulletin, Vol. 14, No.5, October 1971.

Simulation-A tool for performance evaluation in
network computers
by EDWARD K. BOWDON, SR., SANDRA A. MAMRAK and FRED R. SALZ
University of Illinois at Urbana-Champaign
II rbana, Illinois

Since the model was developed for a hypothetical network, we needed to ensure that the results were valid and
that no gross errors existed in the model. Our approach
was to design a general n node network simulator and
then to particularize the input parameters to describe
ILLINET (the computer communications network at the
University of Illinois). For a given period, system
accounting records provided exact details of the resources
used by each task in the system including CPU usage,
input/ output resources used, core region size requested,
and total real time in the system. Using the first three of
these parameters as input data, we could simulate the
fourth. Comparison of the actual real time in the system
to the simulated real time in the system authenticated the
accuracy of the model. Extrapolating from these results,
we could then consider the more general network with
reasonable assurance of accurate results.

I~TRODUCTION

The success or failure of network computers in today's
highly competitive market will be determined by system
performance. Consequently, existing network computer
configurations are constantly being modified, extended,
and hopefully, improved. The key question pertaining to
the implementation of proposed changes is "Does the
proposed change improve the existing system
performance?" Unless techniques are developed for
measuring system performance, network computers will
remain expensive toys for researchers, instead of becoming cost effective tools for progress.
In order to analyze and evaluate the effects of proposed
changes on system performance, we could employ a
number of different techniques. One approach would be
to modify an existing network by implementing the proposed changes and then run tests. Unfortunately, for
complex changes this approach becomes extremely costly
both in terms of the designer's time and the programmer's
time. In addition, there may be considerable unproductive machine time.
Alternatively, we could construct a mathematical
model of the envisioned network using either analytical or
simulation techniques. Queueing theory or scheduling
theory could be employed to facilitate formulation of the
model, but even for simple networks the resulting models
tend to become quite complex, and rather stringent simplifying assumptions must be made in order to find solutions. On the other hand, simulation techniques are limited only by the capacity of the computer on which the
simulation is performed and the ingenuity of the programmer. Furthermore, the results of the simulation tend
to be in a form that is easier to interpret than those of the
analytical models.
To be of value, however, a simulation model must be
accurate both statistically and functionally. In order to
ensure that the analysis of proposed changes based on the
simulation results are realistic, the model's performance
must be measured against a known quantity: the existing
network.
In this paper we present a simulation model for a hypothetical geographically distributed network computer.

MODEL DEVELOPMENT
We begin the development of our network model by
focusing our attention on ILLINET. This system contains
a powerful central computer with copious backup memory which responds to the sporadic demands of varying
priorities of decentralized complexes. The satellite complexes illustrated in Figure 1 include:
(1) Simple remote consoles.
(2) Slow I/O.
(3) Faster I/O with an optional small general purpose
computer for local housekeeping.
(4) Small general purpose computers for servicing
visual display consoles.
(5) Control computers for monitoring and controlling
experiments.
(6) Geographically remote satellite computers.
This network was selected for study because it represents
many of the philosophies and ideas which enter into the
design of any network computer. The problems of interest
here include the relative capabilities of the network, identification of specific limitations of the network, and the
121

122

National Computer Conference, 1973

LOW SPEED "REMOTES"

computer conceptually performs three major functions:
queue handling and priority assignment; processor allocation; and resource allocation other than the CPU (such as
main storage, input/ output devices, etc.).
The goal of the single node optimization was to develop
a priority scheme that would minimize the mean flow
time of a set of jobs, while maintaining a given level of
CPU and memory utilization. The IBM 360/75 was taken
as the model node, the present scheduling scheme of the
360;75 under HASP (Houston Automatic Spooling Priority System)! was evaluated, and as a result a new priority
scheme was devised and analyzed using the simulation
model.

r::::7

NODE DESCRIPTION

OUCHTONE
TELEPHONES

LOW SPEED "LOCALS"

HIGH SPEED "LOCALS"

r:::::7

1"""I

L:J

MEDIUM SPEED "REMOTES·

Figure l-ILLINET-University of Illinois computer
communications network

interrelationship between communication and computing.
From a long range viewpoint, one of the more interesting
problems is the effect on system performance of centralized vs. distributed control in the operating system.
From a postulation of the essential characteristics of
our computer network, we have formulated a GPSS
model for a three node network, illustrated in Figure 2.
Jobs entering the nodes of the network come from three
independent job streams, each with its own arrival rate.
A single node was isolated so that performance could be
tested and optimized for the individual nodes before
proceeding to the entire network. A node in a network

The logical structure of the HASP and OS /360 systems
currently in use on ILLINET is illustrated in Figure 3
and briefly described in the following paragraphs.

Job initiation
Under the present HASP and O.S. system jobs are read
simultaneously from terminals, tapes, readers, disks, and
other devices. As a job arrives, it is placed onto the HASP
spool (which has a limit of 400 jobs). If the spool is full,
either the input unit is detached, or the job is recycled
back out to tape to be reread later at a controlled rate.
Upon entering the system, jobs are assigned a "magic
number," Y, where the value of Y is determined as follows:

Y=SEC+.l*IOREQ+.03*LINES.

SEC represents seconds of CPU usage, LINES represents
printed output, and IOREQ represents the transfer to or

ILl

PLACE JOB
ON
O.S.QUEUE

JOB
ACCOUNTING

Figurr ?-- Hypf)thptir~l nrtwnrk romplltpr

(1)

FiglJ1"P ::I~- T,ngif'fll <;t1"llf'tll1"P

"f HARP

Simulation

123

The O.S. supervisor is then called to allocate core
space. The first block of contiguous core large enough to
contain the step request is allocated to the job. If no such
space is available, the initiator must wait, and is therefore
tying up both the O.S. and HASP initiators. No procedures in O.S. exist for compacting core to avoid fragmentation. Once core is allocated, the program is loaded, and
the job is placed on a ready queue with the highest nonsystem priority.
PREPARE TO
RUN NEXT
STEP

o.s. scheduler
Jobs are selectively given control of the CPU by the
O.S. scheduler. The job with the highest dispatching
priority is given control until an interrupt occurs-either
user initiated or system initiated.

CALL SUPERVISOR
TO ALLOCATE
CORE SPACE

HASP dispatcher
SCHEDULER
CHECK LIMITS

(Yes)

(No) Ret'Jrn

Initiator

Every two seconds, a signal is sent by the dispatcher to
interrupt the CPU, if busy. All of the jobs on the ready
queue are then reordered by the assignment of new dispatching priorities based on resources used in the previous 2 second interval. The job that has the lowest ratio
of CPU time to 110 requests will get the highest dispatching priority. (For example, the jobs that used the least
CPU time will tend to get the CPU first on return from
the interrupt.) During this period, HASP updates elapsed
statistics and checks them against job estimates, terminating the job if any have been exceeded.

Figure 3b-Logical structure of 0.8.

Job termination
from core storage of blocks of data. Based on this magic
number, a "class" assignment is given to each job.
Anyone of seven initiators can be set to recognize up to
five different classes of jobs, in a specific order. It is in
this order that a free initiator will take a job off the spool
and feed it to O.S. For example, if an initiator is set CBA,
it will first search the spool for a class C job; if not found,
it will look for a class B. If there is no B job, and no A job
either, the initiator will be put in a wait state. Once the
job is selected, it is put on the O.S. queue to be serviced
by the operating system.

o.s.

initiation

After a job is placed on the O.S. queue, there is no
longer any class distinction. Another set of initiators
selects jobs on a first-come, first-served basis and
removes them from the O.S. queue. It is the function of
these initiators to take the job through the various stages
of execution.
The control cards for the first (or next) step is scanned
for errors, and if everything is satisfactory, data management is called to allocate the devices requested. The initiator waits for completion.

When execution of the job is completed, control is
returned to the HASP initiator to proceed with job termination. Accounting is updated, the progression list is set
to mark completion, and Print or Punch service is called
to produce the actual output. Purge servi<;e is then called
to physically remove the job from the system. The initiator is then returned to a free state to select a new job from
the spool.
The main goal of the HASP and O.S. system is to
minimize the mean flow time and hence the mean waiting
time for all jobs in the system, provided that certain
checks and balances are taken into account. These
include prohibiting long jobs from capturing the CPU
during time periods when smaller jobs are vying for CPU
time, prohibiting shorter jobs from completely monopolizing the CPU, and keeping a balance of CPU bound and
II 0 bound jobs in core at any given time. At this point
the question was asked: "Could these goals be achieved
in a more efficient way?"
PROPOSED PRIORITY SCHEME
In a single server queueing system assuming Poisson
arrivals, the shortest-processing-time discipline is optimal

124

National Computer Conference, 1973

with respect to mimmizmg mean flow-time (given that
arrival and processing times of jobs are not known in
advance of their arrivals). 2 This result is also bound to the
assumption that jobs are served singly and totally by the
server and then released to make room for the next job.

Processing time
With respect to OS /360 there are several levels and
points of view from which to define processing or service
time. From the user's point of view processing time is, for
all practical purposes, the time from which his program is
read into HASP to the time when his output has been
physically produced-punched, filed, plotted and/ or
printed. Within this process there are actually three levels
of service:
(1) The initial HASP queuing of the job, readying it
for O.S.; a single server process in the precise sense
of the word.
(2) The O.S. processing of the job; a quasi single server
process where the single-server is in fact hopping
around among (usually) four different jobs.
(3) The final HASP queueing and outputting of the
job; again a true single-server process.

job's priority). A summary of the dynamics of the proposed priority scheme is depicted in Figure 4.

Dynamic priority assignment
Once the initial static priority assignment has been
determined for each job, a dynamic priority assignment
algorithm is used to ensure that the checks and balances
listed previously are achieved. The restraints which are
enforced by the dynamic priority assignment are needed
JOBS
PRT
(Static)

WAITING
QUEUE

DPA and SBM
(Dynamic)

The second level of service was used as a reference point
and processing time was defined as the total time a job is
under O.S. control, whether it is using the CPU or not.
The total time a job is under control of O.S. consists of
four time elements:

"
READY
QUEUE

(1) Waiting for core-this quantity is directly related to

the region of core requested by a job and can be
represented by a . R where a is a statistical measure
of the relationship of core region requests to seconds waiting and R is the region size requested.
(2) Direct CPU usage-this quantity can be measured
in seconds by a control clock and is denoted by
CPUSEC.
(3) Executing I/O-this quantity includes the time
needed for both waiting on an 110 queue and for
actually executing 1/0. It is directly related to the
number of I/O requests a job issues and can be
represented by {3 . 10 where {3 is a statistical measure of the relationship of the number of 1I 0
req uests to seconds waiting for and executing I/O,
and 10 is the number if I/O requests issued.
(4) Waiting on the ready queue-this quantity is heavily dependent on the current job configuration.
Since the O.S. queue configuration a job encounters
is unknown when the job enters HASP, this waiting
time is not accounted for in the initial assignment.

HASP DISPATCHER
(Dynamic)

CPU

(Static)

OUTPUT
QUEUE

The total job processing time, PRT, may be expressed
as follows:

PRT=a· R+CPUSEC+{3· 10

(2)

This number, calculated for each job, becomes an initial
priority assignment (the lower the number the higher the

JOBS
Figurel

Prupuseu priulity .:l,;siglll11cnt scheme

Simulation

before a job enters O.S., so the dynamic priority assignment is made while jobs are waiting on the HASP queue.
The dynamic priority assignment, DPA, was implemented by measuring a job's waiting time at its current
priority. The job's priority is increased if the time spent
at the current level exceeds an upper limit established for
that level.
System balance
At this point jobs are on the HASP queue, ordered by a
dynamically adjusted PRT priority assignment, ready to
be picked up by an initiator that is free. As soon as an
initiator chooses a job, that job leaves HASP control and
enters O.S. control. Jobs then move between the O.S. run
and ready queues under the influence of the HASP dispatcher discussed earlier. The HASP dispatcher guarantees the highest CPU use level possible, given ihaf the set
of jobs has been initiated according to its DPA values.
However, CPU and memory utilization may fall below
some predetermined level because a particular set of initiated jobs simply does not maintain system balance. 3
Therefore, one more dynamic assignment, SBM-System
Balance Measure, was introduced. An SBM assignment
enables jobs to take positions in the job queue independently of their DPA. If the utilization of CPU and memory
is below a predetermined level, the system is said to be
out of balance, and the next job initiated for processing
should be the one that best restores balance (where the
one with the lowest DPA is chosen in case of ties).
NODE VALIDATION

tion of how much processing time that job required. The
prediction was to be made from user estimates of the
resources required by a job. In our previous discussion a
formula was devised to make this initial priority assignment, based on user predictions of CPU seconds. kilobytes of core and number of I/O requests and on t~o statistical measures-a and {3. Recall a is a measure of the
relationship of core region request to seconds waiting for
this request, and {3 is a measure of the relationship of the
number of I/O requests to seconds waiting for and executing this I/O so that

PRT=a . COREQ+CPUSEC +{3' [0

The first step in the proposed priority scheme was to
assign an initial static priority to a job, based on a predic-

+ (3 . [0

(4)

where {3 was the only unknown.
Using a light job stream (average arrival rate of one job
every 40 seconds and a CPU utilization of 8 percent with
3 percent of the jobs waiting for core) an exponential distribution of wait times distributed around a mean of 54
msec gave the closest match between the simulated and
real O.S. time distributions. {3 was assigned the value
0.038 seconds per I/O request, since in an exponential
distribution 50 percent of the values assigned will be less
than 69 percent of the mean. The simulation was then
used with a heavier job stream (one job every 15 seconds)
for the determination of a. Statistics were produced correlating the size of a step's core request and the number of
milliseconds it had to wait to have the request filled. A
least squares fit of the data yielded the relationship:

WC=maxIO, . 7K2-100K!

(5)

where Wc is milliseconds of wait time and K is the number of kilobytes core requested. The PRT, in its final
form thus became:

PRT=CPUSEC+38iO
Parameter determinations

(3)

Neither the a nor {3 measure was immediately available
from the present monitoring data of the 360. The simulation was used in two different ways to determine these
measures. The particular GPSS simulation being used,
while allocating cote in the same way as the 360, does not
set up all the I/O mechanisms actually used by the 360
when a job issues a request. The simulator assigns some
time factor for the request and links the job to a waitingfor-I/O chain for the duration of the assigned time. The
approach used in obtaining the {3 factor was to create a
job stream for which the total time in O.S. was known
and for which all the components contributing to time in
O.S. were known except for the 10 factor. Of the four
factors that contribute to a job's time in O.S. only actual
CPU time could be positively known. A job stream in
which jobs did not have to wait for core and in which jobs
essentially had the CPU to themselves when they were in
a ready state was required. Thus the equation was
reduced to:
Time in O.S. = CPUSEC

The proposed priority assignment was then implemented on the simulator and statistics for jobs run on the
ILLINET system were collected and used to determine
the frequency distributions for the variables needed to
create the simulation of the IBM 360;75. The model thus
created was used for three distinct purposes. The first of
these uses was as a tool to collect data not directly or easily accessible from the actual ILLINET system. It was in
this capacity that the simulator yielded a and {3 factors
needed for the PRT formula. The second use of the model
was as a tuning instrument for finding the best adjustments of values for the DPA and SBM. The third use of
the model was for evaluating the advantages (or disadvantages) of the new priority scheme by comparing various system measures for identical job streams run under
both the old and new schemes. (A fourth use of the model
might also be included here. The convincing results that it
provided became the deciding factor in obtaining from
the system designers the money and personnel needed to
implement and test the proposed priority scheme under
real-time conditions.)

125

+ max iO,

. 7K2-100KI (6)

where CPUSEC is the number of CPU milliseconds
required, 10 is the number of I/O requests, and K is kilobytes of core.

126

National Computer Conference, 1973

Dynamic tuning
The values for the maximum waiting times for jobs
with given PRTs were determined by putting the PRTs
into a loose correspondence with the existing class divisions. A small job is guaranteed thirty minute turnaround
time and a slightly larger job is guaranteed a turnaround
of ninety minutes. Since the simulations generally were
not set to simulate more than ninety minutes of real time,
the guaranteed turnaround for very large jobs was set to
an arbitrarily high value. Since test runs using the PRT
were showing very satisfactory values for CPU and core
utilization, about 96 percent and 73 percent respectively,
a simple system balance measure was adopted. The SBM,
System Balance Measure, adjustment checks CPU and
memory use individually every two seconds and signals
the initiator to choose as its next job the one that would
best restore the utilization of the respective resource. The
criterion for resource underuse is less than 30 percent
utilization. The criterion for choosing a job to restore
CPU use is the highest CPU /10 ratio. The criterion for
choosing a job to restore memory use is the largest core
request that fits into core at the time.

NODE PERFORMANCE
After the proposed priority scheme was developed, the
simulation model was used to evaluate the node performance under each of three conditions:
(1) Using the existing magic number technique.
(2) Using the static PRT technique.
(3) Using the dynamically adjusted PRT (including
the DPA and SBM measures).

For each of these tests, an hour of real time was simulated, with identical job streams entering the system. Table
I illustrates the results of these tests including O.S. and
turnaround times for the job streams, as well as CPU and
core utilization values.
In this evaluation we are particularly interested in
three measures of system performance:
(1) Turnaround time-system performance from the
user's point of view.
(2) System throughput-system performance from the
system manager's point of view.
(3) System balance-system performance from the
device utilization point of view.
In particular, we note the striking decrease in overall
turnaround time for jobs processed under the proposed
PRT scheduling algorithms. When the resource utilization
is kept above some critical level and a maximum waiting
time is specified, we observe that the turnaround time for
the entire system can, in fact, increase.

TABLE I -System Performance Measures for Three Priority Schemes
PRESENT
SCHEME
Mean HASP Time·
Class A
B
C
D
A-D

PRT
(Static)

PRT
(Dynamic)

100
100
100

8
98

28
9
17

100

Mean O.S. Time·
Class A
B
C
D
A-D

100
100
100

74
54
47

94
69
91

100

Mean Turnaround Time·
A-D

100

94
75
482

96
73
560

98
73
515

% CPU Utilization
% CORE Utilization
Total Jobs Processed

• Relative time units (times are normalized to 100 units for each priority
class).

NETWORK MODELING
Having developed a simulation model for a single node,
we now turn to the problem of constructing a model for a
network of three such nodes as illustrated in Figure 2.
Jobs entering the system come from three independent
job streams with different arrival rates. At selected intervals, the relative "busyness" of each center is examined.
Based on this information, load-leveling is performed
between centers.
The three node network model was written in IBM's
GPSS (General Purpose Simulation System),4 and run on
an IBM 360;75. Once the simulation language and computer were selected, the next step was to formulate a
design philosophy.
DESIGN PHILOSOPHY

Simulated time unit
A major decision regarding any simulation model is the
length of the simulated time unit. A small time unit
would be ideal for a computer system simulation. However, other ramifications of this unit must be considered.
It is desirable to simulate a relatively long real-time
period in order to study the effect of any system modifications. This would be extremely lengthy if too small a
time unit were chosen, requiring an excessive amount of
computer time. Also, depending on the level of simulation, the accuracy could actually deteriorate as a result of
the fine division of time. These and other considerations
led to the selection of 1 millisecond as the clock unit.
Using a time unit of 1 millisecond immediately results
in the problem of accounting for times less than 1 ms. Of

Simulation

course, these times could not be ignored, but at the same
time, could not be counted as a full clock unit. A compromise approach was used-that of accumulating all of
these small pieces into a sum total of "system overhead,"
to be run during initiation/termination.*
System time chargeable to a job therefore, is executed
during initiation/termination. Additionally, nonchargeable overhead is accounted for at each interrupt of a job in
the CPU, and at the reordering of dispatching priorities of
jobs on the ready queue.

Entity representation
Before proceeding to write a simulation program, careful consideration had to be given to the way in which
actual system entities were to be represented by the simutator~---'ilre-propertiesof a given systemfe-ature--to-lJe-simu--lated had to be defined and the GPSS function most
closely matching the requirements selected. For example,
representation of the HASP Spools was of primary importance, and GPSS offers a number of possibilitiesqueues, chains, etc. The requirement that transactions be
re-ordered at any time ruled out the queue representation, and the optional automatic priority ordering possible
with a user chain led to its selection. Chains also offered
the best method of communication between nodes of the
network since it is possible to scan the chains and remove
any specific job. This is essential for the implementation
of any load-leveling or system balancing algorithm.
The structure of GPSS played another important part
in determining the representation of jobs. A job could
have been represented as a table (in the literal programming and not GPSS sense) that would contain the information about this job, and be referenced by all other
transactions in the simulation. This would have led to a
simulation within the simulation, an undesirable effect.
Therefore, jobs are represented as transactions which
keep all pertinent information in parameters. Unfortunately, this led to some rather complex timing and
communication considerations which had to be resolved
before the simulator could run.

Timing and communication
There is no direct method of communication between
two transactions in GPSS, so whenever such contact was

127

necessary, alternate procedures were devised. For example, at some points an initiator must know the size of core
requested by a given job. The receiving transaction must
put itself in a blocked state, while freeing the transaction
from which the information is required. The information
is then put in a savevalue or other temporary location by
the sending transaction. After signalling the receiving
transaction that the information is present, this transaction puts itself in a blocked state, and thus allows the
receiving transaction to regain control of the simulator in
order to pick up the contents of the savevalue. This procedure is non-trivial, since in an event-driven simulation,
there may be any number of transactions ready to run
when the sending transaction is blocked. The priorities of
the ready transactions, and knowledge of the scheduling
algorithms of the simulation language itself, must be
anaIY:l~d to en,!;!!l~_GQ!rectr~~_\llts.
During the simulation, the jobs waiting to be executed
are not the only transactions waiting to use the simulated
CPU. Transactions representing the scheduler and dispatcher also require this facility. Therefore, we must
ensure that only one transaction enters the CPU at any
given time since this is not a multiprocessing environment. Logic switches are set and facility usage tested by
every transaction requesting the CPU.
GPSS IMPLEMENTATION
With this design philosophy, we proceed to outline the
representation of the various HASP and O.S. entities at
each node. The logical structure of the simulation process
occurring at each node, shown in the flow charts of Figures 5 through 8, is summarized in the following paragraphs. 5

Jobs
Each job is represented by one GPSS transaction with
parameters containing information such as creation time,
number of milliseconds that will be executed, size of core
requested, etc. The parameters are referenced throughout
the simulation to keep a record of what was done, and
indicate what the next step will be. In this way, by moving the transaction from one section of the model to
another, different stages of execution can be indicated.

HASP and O.S. initiators
* It is impossible to measure accurately (within 10 percent) the amount
of system time required for a given job. In a period of simulated time T,
an error Es = TsNse will be accumulated, where Ns is the number of
relatively short (~1 ms) amounts of system time needed, Ts is the total
time spent on each of these short intervals, and e is the percentage error
in the simulated time given to this operation. Similarly, the error for
long intervals E, can be shown to be Tl~1I.[,e where T, and Ni are as above
for some longer periods (~1000 ms). The simulation shows the ratio
TsN,j T,N, is approximately 2, resulting in a greater error with the
smaller time unit.

There are two sets of initiators, one for HASP, and
another for O.S., each requiring the same information
about the jobs they are servicing. The HASP initiator for
a specific job must be dormant while the O.S. initiator is
running. Therefore, seven transactions are created, each
of which represents either a HASP or O.S. initiator. Each
transaction is created as a HASP initiator and put in an
inactive state awaiting the arrival of jobs. After the initia-

128

National Computer Conference, 1973

tive state, it must be taken off the current events chain
and placed on a chain specifically representing that wait
condition.

Queues
All HASP and O.S. queues are represented by user
chains as discussed earlier. In addition to facilitating
ordering of objects on the queues, chains gather the
proper waiting time and size statistics automatically.

CPU-scheduler

ASSIGN
NUMBER,
CLASS

The scheduler has the responsibility of determining
which task will next get control of the CPU. The scheduler is represented by one high priority transaction that
unlinks jobs from the ready queue and lets them seize the

ASSIGN NUMBER
MAKE CLASS
SETTINGS

ASSIGN REQUESTS
FOR EACH STEP
(TIME, I la, CORE)

UNLINK JOB
FROM SPOOL

ON
SPOOL

INITIALIZE

JOB

Figure 5-Job creation flow chart

tor completes initiation of a job and places it on the O.S.
queue, the HASP initiator becomes the O.S. initiator.
This O.S. initiator flows through the core allocation and
other resource allocation routines to request core space,
and finally places the job on the ready queue to run. This
initiator then becomes dormant waiting for the job (or job
step) to complete. At each step completion, the initiator is
awakened to request resource~ for the succeeding step.
When the entire job completes, the initiator is returned to
an inactive state where it again performs its HASP function. \Vhenever an initiator or job is to be put in an inac-

r-------i~

INITIALIZE
STEP
REQUESTS

(Y•• )

ASSIGN CORE
LINK TO
READY QUEUE

Figure 6-HASP and O,S. initiator flow chart

Simulation

129

RETURN TO
READY QUEUE

(No)
(Yes)

UNLINK FROM
READY QUEUE
ASSIGN SLICE
CHECK LIMITS

DE -ALLOCATE
CORE
UPDATE STATS
RECORD TIMES

RESET CORE
MAP
FREE JOBS
AWAITING CORE

SET JOB TO
OUT OF CORE
OVERHEAD

(Yes)

(No)

DISPATCHER
INTERRUPT

RUN JOB FOR
THIS SLICE

EVERY 2 SEC.

ENTER COMPLETION TIME
FREE INITIATOR

ISSUE
1/0
REQUEST

UPDATE
ELAPSED
STATS

SET JOB 10 IN
CORE OVERHEAD

RETLRN 10
READY QUEUE

LINK TO
COMPLETED
CHAIN

Figure 7b-CPU-Scheduler flow chart (cont.)

facility corresponding to the CPU. While this job is
advancing the clock in the facility, no other transactions
are permitted to enter. Although GPSS automatically
permits only one job in each facility, this is not sufficient
protection against more than one transaction entering the
CPU. Therefore, this condition is explicitly tested by all
transactions requesting the CPU. Multiple transactions
are allowed to enter blocks representing II 0 requests, and
other system processes, since these functions in the real
system are actually carried out in parallel. When the
CPU is released, control is returned to the scheduler,
which allocates the facility to the next job on the ready
queue.

Dispatching priority assignment
Figure 7a-CPC-Scheduler flow chart

The HASP dispatching priority assignment is carried
out by one final transaction. Every 2 seconds this transac-

130

National Computer Conference, 1973

Q
DISPATCHER
--~

.....

WAIT TWO
SECONDS

INTERRUPT
CPU

NETWORK PERFORMANCE
After having tested the simulation model, a hypothetical network consisting of three nodes with independent
job streams and arrival rates, was investigated. Network
balance was maintained using a load-leveling algorithm
on the network that periodically (about five times the
arrival rate of jobs at the busiest center) examined the
queues at each center. The number of jobs in the queue of
the busiest center was compared to the number of jobs
in the queue of the least busy center, and this ratio used
as the percentage of jobs to be sent from the busiest center to the lightest center. This distributed the number of
jobs in the network so that each center would be utilized
to the maximum possible degree. Naturally, the users
submitting jobs to the highest center experienced an increase in turnaround time, but this is outweighed by
the increased throughput for the network.
To demonstrate how the simulator could be used to
evaluate loadleveling or other network balancing algorithms, two simulation runs were made: the first having
no communication between centers, and the second with
the load-leveling algorithms implemented as described
above. Performance data for the two networks, evaluated
according to the criteria outlined earlier, is illustrated in
Table II.
TABLE II-System Perfonnance Measures for a Hypothetical Network
Without
Load Leveling

"
RE-ASSIGN
DISPATCHING
PRIORITY

RE-LINK JOBS
TO
READY QUEUE
Figure 8-Dispatcher flow chart

tion is given control of the simulator, and proceeds to reassign the dispatching priority of the jobs on the ready
queue and those jobs currently issuing I/O requests. The
job in control of the CPU (if any) is interrupted, and
placed back on the ready queue according to its new
priority.
When all of the re-ordering is complete, the scheduler is
freed, and the dispatcher is made dormant for another
two seconds.

Turnaround Time*
Center 1
Center 2
Center 3
Network
Average Queue Length
Center 1
Center 2
Center 3
Network

99
100
44

With
Load Leveling

89
80
95
87

125
4
"'0
43

42
25
23
30

CPU Utilization
Center 1
Center 2
Center 3
Network

.985
.902
.518
.802

.982
.952
.931
.955

Core Utilization
Center 1
Center 2
Center 3
Network

.685
.698
.326
.569

.713
.684
.668
.688

System Throughput**
Center 1
Center 2
Center 3
Network
* Relative time units.
** Jobs per hour.

330
196
98
624

256
256
234
746

Simulation

CONCLUSIONS
NETWORK SIMULATION RESULTS

Validation
Our simulation model for a network center is a valid
tool for measuring and evaluating network performance
only if we accurately simulate the intercommunication
among the network centers and the control of jobs within
each center. Therefore, an essential goal of our simulation
effort was to verify the accuracy of representing the interaction among the simulated entities of ILLINET. Frequently, spot checks were made and tests were designed
to ensure that the proper correspondence existed between
the real and simulated environments. Hence, the evaluation measurements taken, effectively predict the expected
system performance of future networks.

System evaluation
The GPSS simulation of the IBM 360;75 was used to
develop and test a new priority scheme suggested as an
alternative to the present system used on the 360. An initial static priority assignment was determined which uses
user estimates of CPU, I/O requests and core required by
a job. Subsequent priority adjustments are made to
reward a job for its long wait in the system or to restore
some minimum level of utilization of the CPU and core.
Test runs of the new priority scheme on the simulator
suggest very substantial improvements in terms of minimizing turnaround time and utilizing system resources.
The emphasis is on evaluating scheduling disciplines
since the only degree of freedom open to a network manager to affect system congestion is a choice of scheduling
algorithms with priority assignments. (A network manager can seldom affect the arrival rate, service rate or the
network configuration on a short term basis.)
The simulation was then extended to a three node
network to study the effect of implementing load-leveling
and other network balancing algorithms. Simulation runs
show an improved turnaround time for heavily loaded
centers and at the same time a larger increase in total
throughput and utilization of network resources.
THE ROAD AHEAD
Until recently, efforts to measure computer system
performance have centered on the measurement of
resource (including processor) idle time. A major problem
with this philosophy is that it assumes that all tasks are
of roughly equal value to the user and, hence, to the operation of the system.

131

As an alternative to the methods used in the past, we
have proposed a priority assignment technique designed
to represent the worth of tasks in the system. 6 We present
the hypothesis that tasks requiring equivalent use of
resources are not necessarily of equivalent worth to the
user with respect to time. We would allow the option for
the user to specify a "deadline" after which the value of
his task would decrease, at a rate which he can specify, to
a system determined minimum. Additionally, the user
can exercise control over the processing of his task by
specifying its reward/ cost ratio which, in turn, determines the importance the installation attaches to his
requests. The increased flexibility to the user in specifying rewards for meeting deadlines yields increased reward
to the center. The most important innovation in this
approach is that it allows a computing installation to
maximize reward for the use of resources while allowing
the user to specify deadlines for his results. The demand
by users upon the resources of a computing installation is
translated into rewards for the center. Thus, the computing installation becomes cost effective, since, for a given
interval of time, the installation can process those tasks
which return the maximum reward.
Using our network simulator to demonstrate the efficacy of this technique is the next step in the long road to
achieving economic viability in network computers.
ACKNOWLEDGMENTS
We are particularly grateful to Mr. William J. Barr of
Bell Laboratories for inviting us to write this paper. His
constant encouragement and his previous endeavors in
the Department of Computer Science at the University of
Illinois at Urbana-Champaign have made this work possible.
This research was supported in part by the National
Science Foundation under Grant No. NSF GJ 28289.

REFERENCES
1. Simpson, T. H., Houston Automatic Spooling Priority System-II

(Version 2), International Business Machines Corporation, 1969.
2. Schrage, L., "A Proof of the Optimality of the Shortest Remaining
Processing Time Discipline," Operations Research, Vol. 16, 1968.
3. Denning, P., "The Working Set Model for Program Behavior,"
Communications of the ACM, Vol. 11, No.5, 1968.
4. - - - , General Purpose Simulation System/360 Introductory
User's Manual GH20-0304-4, International Business Machines
Corporation, 1968.
5. Salz, F., A GPSS Simulation of the 360/75 Under HASP and O.s.
360, University of Illinois, Report ~o. UIUCDCS-R72-528, 1972.
6. Bowdon, E. K., Sr., and Barr, W. J., "Cost Effective Priority
Assignment in :--.Ietwork Computers," Proceedings of the Fall Joint
Computer Conference, 1972.

ACCNET-A corporate computer network
by MICHAEL L. COLEMAN
Aluminum Company of America
Pittsburgh, Pennsylvania

Corporation machines;38 the Distributed Computer System (DCS) at the University of California at Irvine; IS the
Michigan Educational Research Information Triad, Inc.
(MERIT), a joint venture' between Michigan State U niversity, Wayne State University, and the University of
Michigan;2.12.30 the OCTOPUS System at the Lawrence
Berkeley Laboratory;41 the Triangle Universities Computation Center (TUCC) Network, a joint undertaking of
the Duke, North Carolina State, and North Carolina
Universities;,'4 ad the TSS Network, consisting of interconnected IBM 360/67s.39.47.53 But perhaps the most
sophisticated network in existence today is the one created by the Advanced Research Projects Agency (ARPA),
referred to as the ARPA network. 9 )''>,20.22.28.33.34.40.42.44.46 The
ARPA network is designed to interconnect a number of
various large time-shared computers (called Hosts) so
that a user can access and run a program on a distant
computer through a terminal connected to his local
computer. It is set up as a message service where any
computer can submit a message destined for another
computer and be sure it will be delivered promptly and
correctly. A conversation between two computers has
messages going back and forth similar to the types of
messages between a user console and a computer on a
time-shared system. Each Host is connected to the network by a mini-computer called an Interface Message
Processor (IMP). A message is passed from a Host to its
IMP, then from IMP to IMP until it arrives at the IMP
serving the distant Host who passes it to its Host. Reliability has been achieved by efficient error checking of
each message and each message can be routed along two
physically separate paths to protect against total line
failures.
The ARPA network was designed to give an end-to-end
transmission delay of less than half a second. Design
estimates were that the average traffic between each pair
of Hosts on the network would be .5 to 2 kilobits per second with a variation between 0 and 10 kilo bits per second
and the total traffic on the network would be between 200
and 800 kilobits per second for a 20 IMP network. 20 To
handle this load, the IMPs were interconnected by leased
50KB lines.
For the initial configuration of the ARPA network,
communication circuits cost $49,000 per node per year
and the network supports an average traffic of 17 kilobits

I~TRODUCTION

The installation of a Digital Equipment Corporation DEC
ro, in close proximity to an existing IBM 370/165, initiated an investigation into the techniques of supporting
communication between the two machines. The method
chosen, use a mini -computer as an interface, suggested
the possibility of broadening the investigation into a study
of computer networks-the linking of several large computer systems by means of interconnected mini-computers. This paper explains the concept of a network and
gives examples of existing networks. It discusses the justifications for a corporate computer network, outlines a
proposed stage by stage development, and analyzes and
proposes solutions for several of the problems inherent in
such a network. These include: software and hardware
interfaces, movement of files between dissimilar machines, and file security.
WHAT IS A NETWORK?
A computer network is defined to be "an interconnected set of dependent or independent computer systems
which communicate with each other in order to share
certain resources such as programs or data-and/ or for
load sharing and reliability reasons."19 In a university or
a research environment, the network might consist of
interconnected time-sharing computers with a design goal
of providing efficient access to large CPU s by a user at a
terminal. In a commercial environment a network would
consist primarily of interconnected batch processing
machines with a goal of efficiently processing a large
number of programs on a production basis. One example
of the use of a network in a commercial environment
would be preparing a program deck on one computer,
transmitting it to another computer for processing, and
transmitting the results back to the first computer for
output on a printer.
OTHER NETWORKS
Functioning networks have been in existence for several
years.4.19.36 These include: CYBERNET, a large commercial network consisting of interconnected Control Data
133

134

National Computer Conference, 1973

per node. Each IMP costs about $45,000 and the cost of
the interface hardware is an additional $10,000 to
$15,000. 23 The IMPs are ruggedized and are expected to
have a mean time between failures of at least 10,000
hours-less than one failure per year. They have no mass
storage devices and thus provide no long term message
storage or message accounting. This results in lower cost,
less down time, and greater throughput performance. 46
TYPES OF NETWORKS
There are three major types of networks: Centralized,
Distributed, and Mixed. 19
A Centralized network is often called a "Star" network
because the various machines are interconnected through
a central unit. A network of this type either requires that
the capabilities of the central unit far surpass those of the
peripheral units or it requires that the central unit does
little more than switch the various messages between the
other units. The major disadvantage of a network of this
type is the sensitivity of the network to failures in the
central unit, i.e., whenever the central unit fails, no
communication can occur. The most common example of
this type of network is one consisting of a single CPU
linked to several remote batch terminals.
A Distributed network has no "master" unit. Rather,
the responsibility for communication is shared among the
members; a message may pass through several members
of the network before reaching its final destination. For
reliability each unit in the network may be connected to
at least two other units so that communication may continue on alternate paths if a line between two units is out.
Even if an entire unit is disabled, unaffected members
can continue to operate and, as long as an operable link
remains, some communication can still occur. The ARPA
network is an example of a Distributed network.
A Mixed network is basically a distributed network
with attached remote processors (in most cases, batch
terminals) providing network access to certain locations
not needing the capability of an entire locally operated
computer system. These remote locations are then
dependent on the availability of various central CPUs in
order to communicate with other locations.
Within a network, two types of message switching may
occur: circuit switching and packet switching. Circuit
switching is defined as a technique of establishing a
complete path between two parties for as long as they
wish to communicate and is comparable to the telephone
network. Packet switching is breaking the communication
into small messages or packets, attaching to each packet
of information its source, destination, and identification,
and sending each of these packets off independently to
find its way to the destination. In circuit switching, all
conflict and allocation of resources must be resolved
before the circuit can be established thereby permitting
the traffic to flow with no conflict. In packet switching,
there is no dedication of resources and conflict resolution
occurs during the actual flow. This may result in some"
what uneven delays being encountered by the traffic. F

WHY A NETWORK?
By examining the general characteristics of a network
in the light of a corporate environment, specific capabilities which provide justification for the establishment of a
corporate computer network can be itemized. 25 These are:
load balancing
avoidance of data duplication
avoidance of software duplication
increased flexibility
simplification of file backup
reduction of communication costs
ability to combine facilities
simplification of conversion to remote batch terminal
enhancement of file security
Load balancing
If a network has several similar machines among its
members, load balancing may be achieved by running a
particular program on the machine with the lightest load.
This is especially useful for program testing, e.g., a
COBOL compilation could be done on any IBM machine
in the network and achieve identical results. Additionally,
if duplicate copies of production software were maintained, programs could be run on various machines of the
network depending on observed loads.
Avoidance of data duplication

In a network, it is possible to access data stored on one
machine from a program executing on another machine.
This avoids costly duplication of various files that would
be used at various locations within the corporation.
Avoidance of software duplication

Executing programs on a remote CPU with data supplied from a local CPU may, in many cases, avoid costly
software duplication on dissimilar machines. For example, a sophisticated mathematical programming system is
in existence for the IBM 370. With a network, a user
could conversationally create the input data on a DEC 10
and cause it to be executed on the 370. Without a network, the user would either have to use a more limited
program, travel to the 370 site, or modify the system to
run on his own computer.

Flexibility

Without a network each computer center in the corporation is forced to re-create all the software and data files
it wishes to utilize. In many cases, this involves complete
reprogramming of software or reformatting of the data
files. This duplication is extremely costly and has led to
considerable pressure for the use of identical hardware

ACCNET-A Corporate Computer Network

and software systems within the corporation. With a
successful network, this problem is drastically reduced by
allowing more flexibility in the choice of components for
the system.
Simplification of file backup
In a network, file backup can be achieved automatically by causing the programs which update the file to
create a duplicate record to be transmitted to a remote
machine where they could be applied to a copy of the
data base or stacked on a tape for batch update. This
would eliminate the tedious procedure of manually transporting data from one machine to another; the resulting
inherent delay in the updates would be eliminated. 11
Reduction of communication costs
The substitution of a high bandwidth channel between
two separate locations for several low bandwidth channels
can, in certain cases, reduce communication costs significantly.
A bility to combine facilities
With a network, it is possible to combine the facilities
found on different machines and achieve a system with
more capability than the separate components have individually. For example, we could have efficient human
interaction on one machine combined with a computational ability of a second machine combined with the
capability of a third machine to handle massive data
bases.
Simplification of conversion
Converting a site from its own computer to a remote
batch terminal could be simplified by linking the computer at the site into the network during the conversion.
Enhancement of file security
By causing all references to files which are accessible
from the network to go through a standard procedure,
advanced file security at a higher level than is currently
provided by existing operating systems may be achieved.
This will allow controlled access to records at the element
level rather than at the file level.
EXISTING SITUATION
The existing configuration of the DEC 10 installation
provides a 300 (to be extended to 1200) baud link to the
370 via a COMTEN/60, a mini-computer based system
which provides store-and-forward message switching
capability for the corporate teletype network. This link is

135

adequate to support the immediate needs of a Sales Order
Entry System but is totally inadequate for the general
capability of making the computational power and the
massive file storage of the 370 available to a usei on the
DEC 10.
Five DATA 100 terminals provide remote batch service
into the 370 for users at various locations including three
plants and a research center. Most of the other plants
have medium scale computer systems to support their
local data processing needs. All make extensive use of
process control mini-computers and two have UNIVAC
494 systems which can handle both real-time control and
batch data processing.
Approximately 25 interactive CRTs scattered throughout various sales offices across the country have recently
been installed to upgrade our Sales Order Entry System.
Each terminal is connected to the DEC 10 on a dial-up
300 baud line.
PROPOSED SOLUTION
The most obvious solution to the problem of 370-DEC
10 communication would be to connect the DEC 10 to the
370 in a "back-to-back" fashion. To provide an upward
flexibility, however, it is proposed that rather than connecting the machines in that way, they will be connected
using a mini-computer as an interface. By designing the
system which controls their interaction with a network
approach, additional communication links may be
obtained with a relatively small software investment. For
example, if in the future, our research center obtains a
large computer that they wish to incorporate into the
communications process of the other two, an additional
mini-computer would be placed there and connected via a
communication line to the other.
This approach has several advantages. First, by going
through a mini-computer, each of the two interfaces can
be very carefully debugged in isolation and thus not affect
the other machine. Second, once an IBM interface to the
mini-computer is designed, one can connect any IBM
machine into the network without rewriting any of the
other interfaces. We would not have to write an IBM to
UNIVAC interface, an IBM to CDC interface, an IBM to
Honeywell interface, etc. Third, the only change necessary in the existing portion of the network, as the network
expands, would be to inform the mini-computers of the
presence of the other machines.
System description
In order to effectively describe a system as potentially
complex as this one, we shall make use of techniques
being developed under the classification of "Structured
Programming."17.37.48,55,56 The system will be broken down
into various "levels of abstraction," each level being
unaware of the existence of those above it, but being able
to use the functions of lower levels to perform tasks and
supply information. When a system is specified in terms

136

National Computer Conference, 1973

of levels, a clear idea of the operation of the system may
be obtained by examining each level, starting from the
top, and continuing down until further detail becomes
unimportant for the purposes of the specification.
Let us now examine the first few levels of a portion of
the proposed system. The top-most level is level 6, under
that is level 5, and so on. We shall look at what occurs in
the case of a user at a terminal on the DEC 10 submitting
a program to a distant IBM 370 under HASP.
• Level 6
On level 6 is found user and program processes. All
interaction with the user or with a program written
by the user occurs on this level. In fact, after this
level is completely specified, the User Manual for the
system can be written. In our example, an examination of what is happening would show the following
<;;teps:
User creates the input file and a file for the
output;
User logs onto the network specifying his ID
number;
User types "SUBMIT" command specifying the
input file, the output file, and the Host on which
the program is to be run. This submit command
calls on the HASP Submit-Receive function on
level 5;
User waits a brief period until he gets an "OK"
from the terminal signifying that the program
has been submitted. He is then free to either
perform other actions or to sign off of the network;
At some later time the user receives an "output
ready" message on his terminal;
User can now examine his output file.
• Level 5
On level 5 is found the HASP Submit-Receive
function, HSR, and functions to perform network
access control, file access control, and remote program contr'ol. Let us examine the actions of the HSR
function applied to our example:
The HSR function obtains the name of the
HASP-READER process of the specified Host.
It then calls on a level 4 function to pass the
input file to that process. When the level 4 function which controls process-to-process communication is completed, it will return a value corresponding to the job number that HASP has
as:;igned;

The HSR function sends an "OK" to the user. It
then obtains the name of the HASP-WRITER
process on the specified Host and calls on a level
4 to pass the job number and to specify the
output file to the HASP-WRITER. Control
returns when the output file is complete;
The HSR function then sends an "OUTPUT
READY" message to the user .
• Level 4
On level 4 is found the functions which control the
file descriptors, file access, and process-to-process
communication. Examining the actions of the process-to-process communication function, PPC, applied
to our example, we find:
The PPC function converts the name of the
process into a "well-known port" number and
then establishes a logical link to the desired
process;
It then formulates a message containing the
information to be passed and uses a level 3 function to transmit the message;

It then receives a message in reply (which contains the job number in one case, and the output,
in another). It passes this up to level 5 after
destroying the links.

• Level 3
Level 3 contains, among others, the function which
transfers a message from one Host to another. To do
this it:
Takes the message, breaks it into pages, and
calls a level 2 function to transmit each page;
When the last page has been transmitted, it waits
for an acknowledgment;
If the acknowledgment indicates that a reply is
being sent, it receives each page of the reply and
passes up to level 4.

• Level 2
On level 2
steps are:

handled the passing of pages. The

The page is transferred from the Host to its
IMP;
The page is then translated into the standard
neti'\'ork representation and broken into packet,,;

ACC~ET -A

A level 1 function
packet.

called to transmit each

• Levell
At level 1 is handled the details of transmitting a
packet from IMP to IMP. This includes retransmission in case of errors.

Stages of development
In order to allow the concept of a corporate computer
network to be evaluated at minimum expense, it is desirable to break the development into discrete stages, each
stage building on the hardware and software of the previous stage to add additional capability.
• Stage 1
This first stage would connect the DEC 10 to the
local IBM 370/165 by using a single mini-computer.
It would allow a user on the DEC 10 to conversationally build a program on a terminal and submit it to
the 370 to be run under HASP. His output would be
printed either at the 370, at the DEC 10, or at his
terminal. This stage would also support the transfer
of files consisting solely of character data to be transferred from one machine to the other.
The mini-computer hardware required for the
stage would include: one CPU with 16-24K of memory, power monitor and restart, autoload, and teletype; two interfaces, one to the 370 and one to the
DEC 10; a real time clock; and a cabinet. The
approximate purchase price would be $25,000 to
$35,000 with a monthly maintenance cost of approximately $300. In addition, a disk and controller
should be rented for program development. This cost
is approximately $500 per month and would be carried for the remaining stages.
• Stage 2
The second stage would remove the restriction on
file transfer and allow files consisting of any type of
data to be accessed from the other machine. At this
stage, strict security controls would be integrated into
the system.
The additional hardware required for this stage
would include an additional CPU with 8K of memory
and adaptors to interconnect the two CPUs. The
approximate purchase cost would be $9,000-$12,000,
with a monthly maintenance cost of approximately
$75.
• Stage 3
This stage would expand the network to include
computers at other locations. Additional hardware at
the original site would include one synchronous
communication controller for each outgoing line at a
cost of $2,000-S2,500 with a maintenance cost of $25,

Corporate Computer Network

137

and appropriate modems. Total cost for the original
site, assuming two outgoing line~, would be between
$36,000 and $49,500, excluding disk rental, modems,
and communication lines.
• Stage 4
This stage could be developed in parallel with stage
3. It would add the capability for a user on a terminal attached to one machine to submit and interact
with a program executing on the other machine. )Jo
additional hardware would be required.
• Stage 5
This stage consists of the design and implementation of automatic back-up procedures. Most of the
preliminary analysis can be done in parallel with
stages 2-4. These procedures would automatically
create duplicate transactions of updates to critical
files and have them routed to an alternate site to be
applied to the back-up data base. ~o additional
hardware is required.
HANDLING OF FILES IN A NET\VORK
The handling of files in a non-homogeneous, distributed
network poses several complex problems. These include
control of access and transfer of information between
dissimilar machines.

Control of access
That any system supporting multiple, simultaneous use
of shared resources requires some sort of flexible, easy to
use method of controlling access to those resources seems
obvious to everyone (with the possible exception of the
designers of IBM's OS/360), the main problem being how
to provide the control at a reasonable cost. Restricting
ourselves just to file access control, we see many potential
methods with varying degrees of security and varying
costS.JO· 13 ,14,31.43 All provide control at the file level, some at
the record level, and others at the element level. By
designing our system with a Structured Programming
approach, it should be possible to modify the method we
choose, upgrading or downgrading the protection until a
cost-benefit balance is reached.
Most designers of file access control systems have
mentioned encryption of the data-we shall be no different. Apparently finding the cost prohibitive, they have
failed to include this capability in their final product. In
the proposed network, however, translation between the
data representations of dissimiliar machines will be performed (see below), so the added cost of transforming
from a "scrambled" to an "unscrambled" form will be
small.
Each file access control system is based on a method
which associates with each user-file pair a set of descriptors listing the rights or privileges granted to that user for
that file (e.g., Read Access, Write Access, Transfer of
Read Access to another user). Conceptualized as entries
in a matrix, these descriptors are almost never stored as

138

National Computer Conference, 1973

such due to its sparceness. Rather, they are stored as lists,
either attached to each element of a list of users or
attached to each element of a list of files.
Assuming that we have a system for controlling file
access, one design question for a distributed network is
where to store the file access descriptors? For example, let
us look at a network with three machines: A, B, and C,
and a file, F, located at A but created by a user at B. To
be accessible from the other machines, the file must be
known by them and therefore, each machine must have a
file descriptor stating that file F is located at A. If we also
distribute the file access descriptors, an unauthorized
user at C could gain access to the file by obtaining control
of his machine and modifying the file access descriptors.
Hence, each file access descriptor should be stored at the
same location as the file it protects.

Transfer of information
The complexity of transferring information between
two machines is increased by an order of magnitude when
dissimilar machines are involved.1.7·s Using ASCII as the
standard network code allows the interchange of files
containing character data but does not address the problem of different representations of numerical data, e.g.,
packed decimal, short floating point, long floating point,
etc.
Two alternatives present themselves: either allow each
machine to translate from the representation of every
other machine to its own or use a standard network representation and have each machine translate between its
own and the network's. The first is attractive when only a
few different types of machines will be allowed on the
network (If there are N different types of machines, then
N(N-l) translation routines might have to be written).
The second alternative requires more effort in developing
the standard network representation, but is really the
only choice when the number of different types is larger
than three or four.
Another problem is the large amount of translation that
must take place. It may not be desirable to place this
CPU laden task on a time-sharing machine for fear of
degrading response time so the solution seems to lie in
executing the translation within the IMPs. If performing
translation interferes with the ability of the IMP to perform communication, an additional CPU can be attached
to each in order to perform this task. With hardware costs
decreasing 50 percent every two or three years, this seems
an attractive solution.
INTERFACES

IAfJD--JIost interface
The ARPA network is optimized toward supporting
terminal interaction. 28 A commercial network must be
optimized toward maximizing throughput of lengthy data
files which produces large peak loads requiring high

bandwidth channels between each Host and its IMP. In
order to allow an IMP to communicate with its Host with
a minimum of CPU intervention by either party, data
must be transferred directly between the memory of the
IMP and the memory of the Host. This can be achieved
by connecting to an equivalent of the memory bus of the
DEC 10 or multiplexor channel of the 370. With this type
of interconnection, it will be necessary to configure the
software so that each member of the communicating
partnership appears to the other member as if it were a
peripheral device of some sort, presumably a high-speed
tape drive. Communication, therefore, would take place
by one member issuing a READ while the other member
simultaneously issues a WRITE. 24

IAfJD-IAfJD interface
The IMPs will be linked by standard synchronous
communication interfaces. Initial plans call for 40.8KB
full duplex leased lines, but 19.2KB lines could also be
used. A Cyclical Redundancy Check will provide detection of errors and cause the offending packet to be
retransmitted.

Software interfaces
One of the main reasons for using mini-computers
between the Hosts is to insure that the number of interface programs which must be written only grows linearly
with the number of different types of Hosts. The effort in
writing subsequent versions of the IMP-Host interface
can be minimized by at least two methods:
1. Put as much of the system software as possible into
the IMPs. Make use of sophisticated architecture 3
(e.g., multi-processor mini-computers, read-only
memory) to obtain the power required.
2. For that portion of the system which resides in the
Host, write the software using a standard, high-level
language (e.g., FORTRAN) for as much of the code
as possible.
REFERENCES
1. Anderson, Robert, et aI, Status Report on Proposed Data Reconfiguration Services, ARPA Network Information Center Document No. 6715, April 28, 1971.
2. Aupperle, Eric, "MERIT Computer Network: Hardware Considerations" Computer Networks, R. Rustin (Ed.), Prentice-Hall,
Englewood Cliffs, N.J., 1972, pp. 49-63.
3. Bell, G., Cady, R., McFarland, H., Delagi, B., O'Laughlin, J.,
Noonan, R., "A New Architecture for Mini-Computers-The DEC
PDP-H," Proc. AFIPS 1970 SJCC, Vol. 36, AFIPS Press, Montvale, N.J., pp. 657-675.
4. Bell, G., Habermann, A. N., McCredie, J., Rutledge, R., Wulf, W.,
"Computer Networks," Computer, IEEE Computer Group, September/October, 1970, pp. 13-23.
5. Bjorner, Dines, "Finite State Automation-Definition of Data
Communication Line Control Procedures," Proc. AFIPS 1970
FJCC, Vol. 37, AFIPS Press, Montvale, N.J., pp. 477-49l.
6. Bowdon. Edward, K., Sr., "~etwork Computer Modeling" Proc.
ACM Annual Conference, 1972, pp. 254-264.

ACCNET-A Corporate Computer Network 139

7. Bhushan, Abhay, The File Transfer Protocol, ARPA Network
Information Center Document No. 10596, July 8, 1972.
8. Bhushan, Abhay, Comments on the File Transfer Protocol, ARPA
Network Information Center Document No. 11357, August 18,
1972.
9. Carr, C. Stephen, Crocker, Stephen D., Cerf, Vinton G., "HostHost Communication Protocol in the ARPA Network" Proc.
AFIPS 1970 &/CC, Vol. 36, AFIPS Press, Montvale, N.J., pp. 589597.
10. Carroll, John M., Martin, Robert, McHardy, Lorine, Moravec,
Hans, "Multi-Dimensional Security Program for a Generalized
Information Retrieval System," Proc. AFIPS 1971 FJCC, Vol. 39,
AFIPS Press, Montvale, N.J., pp. 571-577.
11. Casey, R G, "Allocation of Copies of a File in an Information
Network," Proc. AFIPS 1972 &/CC, Vol. 40, AFIPS Press, Montvale, N.J., pp. 617-625.
12. Cocanower, Alfred, "MERIT Computer Network: Software Considerations," Computer Networks, R Rustin (Ed.), Prentice-Hall,
Englewood Cliffs, N.J., 1972, pp. 65-77.
13. Conway, R W., Maxwell, W. L., Morgan, H. L., "On the Imple-mentation-of-S-ecurity Measures in Information Systems" Comm:
of the ACM, Vol. 15, April, 1972, pp. 211-220.
14. Conway, Richard, Maxwell, William, Morgan, Howard, "Selective
Security Capabilities in ASAP-A File Management System,"
Proc. AFIPS 1972 &/CC, Vol. 40, AFIPS Press, Montvale, N.J.,
pp. 1181-1185.
15. Crocker, Stephen D., Heafner, John F., Metcalfe, Robert M., Postel, Jonathan B., "Function-Oriented Protocols for the ARPA
Computer Network," Proc. AFIPS 1972 &/CC, Vol. 40, AFIPS
Press, Montvale, ~.J., pp. 271-279.
16. deMercado, John, "Minimum Cost-Reliable Computer Communication Networks," Proc. AFIPS 1972 FJCC, Vol. 41, AFIPS Press,
Montvale, N.J., pp. 553-559.
17. Dijkstra, E. W., "The Structure of the 'THE' Multiprogramming
System," Comm. of the ACM, Vol. 11, May, 1968.
18. Farber, David, "Data Ring Oriented Computer Networks" Computer Networks, R Rustin (Ed.), Prentice-Hall, Englewood Cliffs,
N.J., 1972, pp. 79-93.
19. Farben, David J., "Networks: An Introduction," Datamation,
April, 1972, pp. 36-39.
20. Frank, Howard, Kahn, Robert E., Kleinrock, Leonard, "Computer
Communication Network Design-Experience with Theory and
Practice," Proc. AFIPS 1972 &/CC, Vol. 40, AFIPS Press, Montvale, N.J., pp. 255-270.
21. Frank, Howard, "Optimal Design of Computer Networks," Computer Networks, R Rustin (Ed.), Prentice-Hall, Englewood Cliffs,
N.J., 1972, pp. 167-183.
22. Frank, H., Frisch, LT., Chou, W., "Topological Considerations in
the Design of the ARPA Computer Network," Proc. AFIPS 1970
&/CC, Vol. 36, AFIPS Press, Montvale, N.J., pp. 581-587.
23. Frank, Ronald A., "Commercial ARPA Concept Faces Many
Roadblocks," Computerworld, November 1,1972.
24. Fraser, A. G., "On the Interface Between Computers and Data
Communications Systems," Comm. of the ACM, Vol. 15, July,
1972, pp. 566-573.
25. Grobstein, David L., Uhlig, Ronald P., "A Wholesale Retail Concept for Computer Network Management," Proc. AFIP.'; 1972
FJCC, Vol. 41, AFIPS Press, Montvale, N.J., pp. 889-898.
26. Hansen, Morris H., "Insuring Confidentiality of Individual
Records in Data Storage and Retrieval for Statistical Purposes,"
Proc. AFIPS 1971 FJCC, Vol. 39, AFIPS Press, Montvale, N.J.,
pp. 579-585.
27. Hansler, E., McAuliffe, G. K., Wilkov, R S., "Exact Calculation of
Computer Network Reliability," Proc. AFIP.'; 1972 FJCC, Vol. 41,
AFIPS Press, Montvale, N.J., pp. 49-54.
28. Heart, F. E., Kahn, R. E., Ornstein, S. M., Crowther, W. R., Walden, D. C., "The Interface Message Processor for the ARPA
Computer ~etwork," Proc. AFIP.'; 1970 &/CC, Vol. 37, AFIPS
Press, Montvale, N.J., pp. 551-1567.

29. Hench, R R, Foster, D. F., "Toward an Inclusive Information
Network," Proc. AFIP.'; 1972 FJCC, Vol. 41, AFIPS Press, Montvale, N.J., pp. 1235-1241.
30. Herzog, Bert, "MERIT Computer Network," Computer Networks,
R. Rustin (Ed.), Prentice-Hall, Englewood CHiis, ~.J., 1972, pp.
45-48.
31. Hoffman, Lance J., "The Formulary Model for Flexible Privacy
and Access Controls," Proc. AFIPS 1971 FJCC, Vol. 39, AFIPS
Press, Montvale, N.J., pp. 587-601.
32. Hootman, Joseph T., "The Computer Network as a Marketplace,"
Datamation, April, 1972, pp. 43-46.
33. Kahn, Robert, "Terminal Access to the ARPA Computer Network" Computer Networks, R Rustin (Ed.), Prentice-Hall, Englewood Cliffs, X.J., 972, pp. 147-166.
34. Kleinrock, Leonard, "Analytic and Simulation Methods in Computer Network Design," Proc. AFIPS 1970 &/CC, Vol. 36, AFIPS
Press, Montvale, N.J., pp. 569-579.
35. Kleinrock, Leonard, "Survey of Analytical Methods in Queueing
Networks," Computer Networks, R Rustin (Ed.), Prentice-Hall,
Englewood Cliffs, N.J., 1972, pp. 185-205.
36. Lichtenberger, W.,· (Ed), Tentative SpecT[ications for a Network of
Time-Shared Computers, Document No. M-7, ARPA, September
9,1966.
37. Liskov, B. H., "A Design Methodology for Reliable Software Systems," Proc. AFIPS 1972 FJCC, Vol. 41, AFIPS Press, Montvale,
N.J., pp. 191-199.
38. Luther, W. J., "Conceptual Bases of CYBERNET," Computer
Networks, R Rustin (Ed.), Prentice-Hall, Englewood Cliffs, N.J.,
1972, pp. 111-146.
39. McKay, Douglas B., Karp, Donald P., "IBM Computer Network/
440," Computer Networks, R. Rustin (Ed.), Prentice-Hall, Englewood Cliffs, N.J., 1972, pp. 27-43.
40. McQuillan, J. M., Cro\\iher, W. R, Cosell, B. P., Walden, D. C.,
Heart, F. E., "Improvements in the Design and Performance of the
ARPA Network," Proc. AFIPS 1972 FJCC, Vol. 41, AFIPS Press,
Montvale, N.J., pp. 741-754.
41. Mendicino, Samuel F., "OCTOPUS: The Lawrence Radiation
Laboratory Network," Computer Networks, R Rustin (Ed.), Prentice-Hall, Englewood Cliffs, N.J., 1972, pp. 95-110.
42. Metcalfe, Robert M., "Strategies for Operating Systems in Computer Networks," Proc. ACM Annual Conference, 1972, pp. 278281.
43. Needham, R M., "Protection Systems and Protection Implementations," Proc. AFIPS 1972 FJCC, Vol. 41, AFIPS Press, Montvale, N.J., pp. 571-578.
44. Ornstein, S. M., Heart, F. E., CroMher, W. R, Rising, H. K.,
Russell, S. B., Michel, A., "The Terminal IMP for the ARPA
Computer Network," Proc. AFIPS 1972 &/CC, Vol. 40, AFIPS
Press, Montvale, N.J., pp. 243-254.
45. Roberts, Lawrence G., "Extensions of Packet Communication
Technology to a Hand Held Personal Terminal," Proc. AFIP.';
1972 &/CC, Vol. 40, AFIPS Press, Montvale, N.J., pp. 295-298.
46. Roberts, Lawrence G., Wessler, Barry D., "Computer Network
Development to Achieve Resource Sharing," Proc. AFIPS 1970
&/CC, Vol. 36, AFIPS Press, Montvale, N.J., pp. 543-549.
47. Rutledge, Ronald M., Vareha, Albin L., Varian, Lee C., Weis,
Allan R., Seroussi, Salomon F., Meyer, James W., Jaffe, Joan F.,
Angell, Mary Anne K., "An Interactive Network of Time-Sharing
Computers," Proc. ACM Annual Conference, 1969. pp. 431-441.
48. Sevcik, K. C., Atwood, J. W., Grushcow, M. S., Holt, R C., Horning, J. J., Tsichritzis, D., "Project SUE as a Learning Experience,"
Proc. AFIP.'; 1972 FJCC, Vol. 41, AFIPS Press, Montvale, N.J.,
pp.331-338.
49. Stefferud, Einar, "Management's Role in Networking," Datamation, April, 1972, pp. 40-42.
50. Thomas, Robert H., Henderson, D., Austin, "McROSS-A MultiComputer Programming System," Proc. AFIPS 1972 &/CC, Vol.
40, AFIPS Press, Montvale, N.J., pp. 281-293.

140

National Computer Conference, 1973

51. Tobias, M. J., Booth, Grayce M., "The Future of Remote Information Processing Systems." Proc. AFIPS 1972 FJCC, Vol. 41,
AFIPS Press, Montvale, N.J., pp. 1025-1035.
52. Walden, David C., "A System for Interprocess Communication in
a Resource Sharing Computer :\"etwork," Comm. of the ACM, Vol.
15, April, 1972, pp. 221-230.
53. Weis, Allan H., "Distributed ~etwork Activity at IBM," Computer
Networks, R. Rustin (Ed.), Prentice Hall, Englewood Cliffs, ~.J.,
1972, pp. 1-2.5.

54. Williams, Leland H., "A Functioning Computer Network for
Higher Education in North Carolina," Proc. AFIPS 7972 FJCC,
Vol. 41, AFIPS Press, Montvale, N.J., pp. 899-904.
55. Wulf, William A., "Systems for Systems Implementors-Some
Experience From BLISS," Proc. AFIPS 1972 FJCC, Vol. 41,
AFIPS Press, Montvale, ~.J., pp. 943-948.
56. Wulf, W. A., Russell, D. B., Habermann, A. N., "BLISS: A Language for Systems Programming," Comm. of the AC.\f. Vol. 14,
December, 1971, pp. 780-790.

A system of APL functions to study computer networks
by T. D. FRIEDMAN
IBM Research Laboratory
San Jose, California

A collrction of programs and procrdural ('onvrntions will
be dC'scribrd which wrrr devPloppd as part of a largpr study
of modf'ling and dpsign of eomputpr nptworks. This work
was condlli'trd undpr Xavy Contract XOO14-72wC-0299, and
was based on approaches developed by Dr. R. G. Casry, to
whom I am indebtpd for his hrlpful suggrstions and rncouragement. The programs arp written on the APL terminal system. For proper understanding of the programming
language uspd, it is drsirable' for thp rf'adpr to refe'r to Referener 1.
Thpsp programs make' it possible to crpatr, modify and
evaluatp graph theorptic rf'presentations of computpr nptworks in minutes whilp working at t he terminal.

13
14
I.j

6
'7
I

8
9
10
11
12

2
2
2
Li

3
3
3

6
6

1
1
3
4
5

10
14
15

The ovprall concpptual framr\york for rrprpsent.ing net.works \vill first bp discusspd.
We assume a spt of fixpd nodps locatpd at gpographically
dispprspd locations, somp of which contain copies of a given
data file. Cprtain nodes are interconnrct.ed by transmission
links. Togrthpr, t.he nodrs and links constitutp a particular
network configuration. Each node is assignrd a unique
idrnt.ification number, and the links are likewise idrnt.ified
by link numbers. An arbitrary configuration of an n-node
ident.ifird by link numbers. An arbitrary configuration of
an n-node network is represented by a link list, which consists of an m-by-3 array of the m link numbrrs, rarh of
\yhich is followrd by the identification of thp t,,"O nodes it.
connects. For example, a six-node network with all possible
links providpd would be represented by the following link
list:
1
1
1
1

This nptwork is depicted sehpmatieally in Figurr 1. (Xote
that. paLh link is rpprpsentpd in thp .figure by thr least significant digit of its idpntification numbrr.)
Any othrr configuration of a six-node network is npcessarily a subset of thr prpceding nC'twork. Onp such subset
is thp follO\ying configuration, representing the network
shown in Figure 2.

COXCEPTUAL FRA:\IEWORK

1
2
3
4

4
4
5

5
4
6
6

For certain operations, it is useful to rpprf'sent a network
by its connection matri.r, in which the ith element of the jth
row idpntifies the link connecting node i to j. If no link is
prf'sent, or if i = j, then the element is zero.
Thus, the fully connf'cted six-node nehvork described
above would be characterized by the connection matrix:
0
1
2
3
4
5

1
0
6
7
8
9

2
6
0
10
11
12

3
7
10
0
13
14

4
8
11
13
0
15

5
9
12
14
15
0

Likf'wise, the configuration represented in Figure 2 would
be characterized by the conneetion matrix

2
3
4

0
1
0
0
4
0

6
3
4
5
6
4
5
6

0
0
0
0
0

0
0
0
10
0
0

0
0
10
0
0
14

4
0
0
0
0
15

0
0
0
14
15
0

BASIC NETWORK FUXCTIOXS
In this section, functions for modeling and evaluating
the networks are described.
141

142

National Computer Conference, 1973

( 1) 2 22 2 4 "" 4444 44 4 4444444 44 4 4 44 44 44 4 4 44 44 4444 4 444 44 "444 44 44 44 44 44 ( 5 )
135
2222222222
11111111111
885
355
2222222222
11111111111
883 5
3 55
2222( 3)1111
88 3
5
3
55
602
88 33
3
55
6 a 2
88
3
55
6
a 2
88
3
55
6
2
88
3
33
55
6
22
88
3
3
55
6
2
88
3
3
55
6
2
88
3
33
556
2 88
3
3
655
88
3
6
55
88
2
3
3
6
55
88
2
3
3
550
88
2
3
3
6
23
5 8
36
855
32
63
66
3
880
55
33
22
6
3
88
a
55
2
6
3
88
a
55 3
2
388
55
2
6
8833
3
55
2
6
88
3
3
55
2
6
88
3
3
55
2
88
3
33
55
2
88
3
3
55
2
2
88
66
88
5\5
22

33~/

6
88
77(4)"44
55
2
6 88
77777777
44444444
55 2
1 688
77777777
44"44444
552 5
168 77777777
44444444
555
(2) 77 999 9999 99 99999999999 9 9999 99 999999 99 99999999 99 999999999 999 99 (6)

Figure 1
}Veiwork

topology

An APL function, FORMC:VI, creates the connection
matrix as output when given the link list and the node
count.
The function OKC)'1 determines "\vhether a network
configuration connects all nodes together. It is possible to
determine whether all nodes are connected by calculating
the inner product of a Boolean form of the connection matrix, repeated n-l times for an n-node network. However,
the OKC}1 function carries out this determination with
somewhat less processing, by performing n-l successive
calculations of

then, LINKSI UNION LINKS2 results in:
1
2

1
1
1

4
6
7

3
5
3
4

2
2

3
3
4
5

11
14
15

4
5

6
6

The CSP program searches for the shortest path spanning
two nodes in a given network. It operates by first seeking a
direct link between the nodes if one exists. If one does not,
it follows each link in turn which emanates from the first
node, and calls itself recursively to see if the second node can
eventually be reached. A control parameter C is needed to
limit the depth of recursion so as to avoid infinite regress.
SPAN is a function to call CSP without requiring the
user to specify the recursion control parameter, C. SPAN
operates by calling CSP with the control parameter set to
the node count minus 1, since at most n-l links are required
for any path in an n-node network.
CSP and SPAN return only one set of links spanning the
two given nodes, and this set consists of the fewest number
of links possible. However, more than one such set of that
number of links may be possible. The function MCSP
operates exactly like CSP, except it finds all sets of the
minimum number of links which span the two nodes. ~ISP AN
corresponds to SPAN by allowing the user to omit the control terms, but calls ~ICSP rather than CSP.

X etwork traffic
C:VIS~C:YIS V

V /(GMS V . ;\BC:YI)/BC:VI,

where BC:\! is a Boolean form of the connection matrix,
GM, i.e., BC:Jl[I ;J] = 1 if CM[I ;J];;cO or if I =J; BC)'l
[I ;J] = 0 otherwise; and C:VIS is initially defined as BC:\P.
OKCM determines that all nodes are connected if and only
if at the conclusion C}IS consists only of 1'so
The function U~ION finds the union of two link lists,
and presents the link list of the result in ascending order.
For example, if we define LIXKSI as
2
4
6
7

1
1
2
2
3
3
5

3
5
3
4
4
5
6

10
14

1
1
3

2
.5
4

()

I.!)

11
1.5

We assume that the average amount of query and update
activity emanating from ('ach node to each file is known.
This information is provided in a table called FILEACT,
i.e., file activity.
(1) 44444 44 4 4 4"4 44444 4 4 44 44" 4 4" 44 44 44 44 44 44 44 44 44 44 44 44 4 4 "4 4" 44 44 ( 5 )

5
5
5

(3)

and LIXKS2 as
1

1
( 4)444
4~444444

;.. 4 uJ.. W.4L1.4

444444"4

1
(2 )

444 (6)

Figure 2

A System of APL Functions to Study Computer Networks

On the basis of these data, the activity on each link of the
network can be calculated when the location of the files is
specified. The function LCACT calculates the link update
activity; using CSP to find the sets of links between each
node and each copy of the file. It then adds the appropriate
update activity from the FILEACT table to the total transmission activity of each link.
The function LQACT derives the query activity on each
link using a similar approach. However, a query from a
node need only be transmitted to the nearest copy of the
file. A function, PATH, finds the set of links connecting a
node to the nearest copy of a file located at one or more
nodes. LQACT uses PATH to select the links affected, then
accumulates the total query activity on all links.
LACT finds the total activity on all links as the sum of
LUACT and LQACT.
In the experiments run to date, five separate transmission
capaCIties were available for each link, namely,' 100; 200,
400, 1000 and 2000 kilo bits per second. It is most economic
to employ the lowest capacity line needed to handle the
activity of each link. The function ~IINCAP accomplishes
this goal by examining the activity of all links as determined
by LUACT and LQACT, and it then calculates the minimal
capacity needed in each link. If the activity of any link exceeds the maximal capacity possible, this is noted in an
alarm.

Cost calculations
It is assumed that the costs are known for maintaining
each possible link at each possible capacity in the network.
This information is kept in TARTABLE, i.e., the tarriff
table. In addition, the costs to maintain any file at any node
are given in the F~IAIXT table.
By reference to the TARTABLE, the function FOR::\ILTAR determines the monthly cost of all links, called LTAR.
Using LTAR and the FJIAIKT table, the function TARRIF
calculates the monthly cost of a configuration when given
the nodes at which the files are located.
A function, GETTARRIF, derives this same cost data
starting only with the link list and the locations of the
files. In turn, it calls FOR::\ICJI to develop the connection
matrix, then it calls LQACT and LUACT to determine
activity on all links, then ::\II~CAP to determine minimal
link capacities, then FOR::\ICTAR to derive LTAR, and
finally it calls T ARRIF to determine the total cost.
An abbreviated version of the latter function, called
GETLTF, derives the link costs but does not find the total
file maintenance cost.

XETWORK JIODIFICATIOX FUXCTIOXS
The cost of maintaining a network may on occasion be
reduced by deleting links, by adding links, or by replacing
certain links with others.
The function SXIP removes links from a network whenever this 10\\"('rs cost or leaves the cost. unchanged. SXIP
must have the nodes specified at which files are located, and

143

the link list. It proceeds by calculating the link activity,
then it calls ::\UXCAP to determine the capacity of each
link. It deletes all links that carry no traffic. Then it attem pts to delete each of the remaining links from the net\vork, starting with the least active link. At each step, it
calls OKC::VI to check that all nodes remain connected in
the network-if not, that case is skipped. Mter it determines
the cost effects of all possible deletions of single links, the
one link (if any) is deleted which lowers cost most (or at
least leaves it unchanged). Mterwards, it repeats the entire
process on the altered network and terminates only when it
finds that no additional links can be removed without increasing cost or disconnecting the nehvork.
The function JOIN will add the one link, if any, to a
specified node 'which most reduces cost. Mter one link is
added, it repeats the process to determine if any others may
also be added to that node. It follO\vs a scheme similar to
S~IP, except that a link will not be added 'if the' cost is
unchanged as a result.
JOIXALL accomplishes the same process on a net\vork,vide basis, i.e., a link will be added anywhere in the net'work if it reduces the cost.
REPLACE substitutes ne\v links for old ones whenever
this reduces cost. It begins by calling SNIP to delete all
links whose removal will not raise costs, then it selectively
attempts to delete each of the remaining links and attach
a new link instead to one of the nodes that the old link had
connected. Mter trying all such possible replacements and
calculating the resulting costs, it chooses the one replacement, if any, which lowers the cost the most. Then, the
whole process is repeated on the modified network, and
terminates only when no further cost reduction is possible.

:\IESSAGE-COST-ORIEXTED FUXCTIOXS
The preceding functions assume an "ARPA-type" design2 ,3 in which total costs are based on fixed rental rates for
transmission lines for the links according to transmission
capacities, plus the cost of maintaining files at specific
nodes. However, networks may also be considered in which
the costs are calculated according to message traffic across
links. A family of functions have been written similar to the
functions described above, but for \vhich costs are calculated
according to the moment-to-moment transmission activity.
Those functions are described in this section.
A table, TC, specifies the transmission cost for sending
messages over each link. It is assumed that the link capacities are fixed, and are given by the parameter LCAP. A
function, FOR~ILCOST, uses TC and LCAP to create
LCOST, the list of message transmission cost rates for the
links.
Rather than simply finding a shortest set of links connecting hvo nodes, in this case it becomes necessary to compare the different total transmission costs for each possible
set of links. The function ECSP is provided to do this.
ECSP is similar to JICSP, but instead of returning all sets
of the minimal number of links connecting two given nodes,
it returns only the most eeonomical single set of links.

144

National Computer Conference, 1973

14
145
146
15
24
245
1456
134
1345
135
4
45
246
25
124
1245
1346
156
2456
234
2345
136
13456
46
13
235
1246
125
1356
456
34
345
2346
256
12456
1234
12345
16
236
23456
23
1235
346
2356
12346
1256
3456
35
1236
123456

ALLCOSTS drrivrs a tablr, COST~lATRIX, gIvmg the
total eosts for f'aeh file whrn locatpd at f'aeh possiblf' node.
FICO ('rratrs a tablf' of eosts for all possiblr combinations
of a filp at difff'rl'nt nod('s, shown in Figurf' 3. Thp first. column
speeifif's thr nodf's at which t.hf' file is locatf'd and column 2
supplies thp cost. The configuration uSf'd to derive this
table was a fully connpctpd six-node network.
FOR~IQ~I usrs LIXKQACT to cre>atf' a tablf' of query
costs for each filf' when located at rach node. FOR~lUM
forms a similar tablf' for update costs.
TRL\l corrf'sponds to SXIP, and deletes links from a
network until the cost no longf'r drops.
SUPP (for supplement) corresponds to .JOI~ALL, and
adds links to a network until t he cost no longer drops.

64000
64000
71200
72000
73600
73600
75200
75200
75200
79200
80000
80000
80800
81600
81600
81600
82400
83200
84800
84800
84800
86400
86400
87200
87200
88800
88800
89600
90400
91200
91200
91200
92000
92800
92800
92800
92800
95200
96000
96000
96800
96800
98400
100000
100000
100800
102400
103200
104000
104000

DIAGRA}nn~G

26
123
12356
36
3
5
1
126
356
56
2
12
6

104800
104800
108000
110400
111200
112000
112000
112800
114400
123200
125600
129GOO
159200

Figure 3

Like ::.Yrcsp, ECSP requires a recursion control parameter. ESP (which corresponds to ~lSPAN) calls ECSP,
and provides the recursion control parameter implicitly as
the node count minus 1.
LINKUACT and LINKQACT correspond to LUACT
and LQACT but the links between nodes are chosen by
ECSP rather than CSP so as to obtain lowest cost. LQACT
calls ROUTE, which operates like PATH except that it
chooses the most economic set of links connecting a node to
one of several copies of a file. LINKACT corresponds to
LACT in the same way.
The function COST corresponds to T ARRIF, but it
calculates the cost according to the total activity on each
link times the component of LCOST corresponding to that
link. The function TOTCOST calculates the sum of the
costs over all links calculated by COST, and the function

FUXCTIONS

Functions are provided to diagram nehYork configurations developf'd by the prrcrding functions. The diagram is
prf'parf'd as a matrix of blank characters, with nodes indicah'd by parenthf'sizrd numbrrs, and links indicatrd by
a linf' compoS<"d of a numbf'r or other character. Figures 1
and 2 arf' f'xamplf's of such diagrams.
DEPICT crf'ates such a matrix when given the dimensions and the positions in the matrix at which the nodes
are to be located.
BLAZE draws a line betwf'rn any two elements in the
matrix, "'hen given the location of thr elements and the
sprcial charactrr with which the> linE' is to be drawn.
COXXECT dra\ys a line, using BLAZE, betw(,f'n two
nodf's, looking up the locations of f'ach nodf' in thf' picture
matrix to do so.
COXXECTALL diagrams an f'ntirf' network configuration whf'n givf'n its link list as an argumf'nt. Each link is
drawn using thf' If'ast significant digit of thf' link number.
Figurf's 1 and 2 Wf're producf'd by CONXECTALL.
A function caIlf'd SETUP is used to initializf' the link list,
connection matrix and node> count parameter for various
preassigned network configurations. The statement "SETUP
5" for rxample initializes the prespecified network configuration number five.
~IE~10-PAD

FUNCTIONS

Provisions were made for a memorandum-keeping system
which may be of interest to other APL users, inasmuch as
it is not restricted just to the network study.
The "niladic" function NOTE causes the terminal to
accept a line of character input in which the user may write
a comment or note for future references. The note is then
marked with the current calendar date and filed on the top
of a stack of notes (called XOTES). The function ~fEl\lO
displays all previous notes with their dates of entry, and
indexes each with an identification number. Any note may
be deleted by the SCRATCH function. The user simply
fo11O\vs the word SCRATCH by the indices of notes to be
deleted.

A System of APL Functions to Study Computer Networks

(1) 444<;44444444444444444444444444444444 44 4~44 444441+'44444444444 4 (5)

145

(1) 22 22
1
2222222222

(5 )

5
2222222222
2222(3)
2

(3 )

2
2

22
2

2
2
2
2
22

22
(4) 44 4

(4) 444
44444444

2
2

44444444
44444444

44444444

(2 )

44444444

444 (6)

4L,.44444l.-

(2 )

Figure 4a

2 5
25
.. 44 (6)

Figure 4d
(1)2222
1
2222222222

(5 )

35
3 5

2222222222
(3 )

2222(3)

3
3

33
3
3

3
3
33
3
3
03

(q
77777777

44'4-!....4444
L4Lr~4L.44

77777777

~44i!4111..j.~

77777777
(2 )77

5
44 (6)

Figure 4b

5
(6 )

Figure 4e

(1 ):,222

1
(2 )

(5)

These functions have proven useful for keeping re('ords
of currrnt activities, ideas, and problems from one work
session to the next.

~222222222

2=222~2222

:2 L 2 L ( 3)

EXA:\IPLES OF EXPERL\IEXTS WITH THE
SYSTE:\I
In this section, thrr(' sample experiments "'ill br> discussed. The records of the terminal st'ssion art' included in
an Appendix to show how the experiments were conducted.
In the first run, we start with configuration five, by issuing
the command
SETUP .1.

(4 ) ........ 4
4444- 44 44
44444444
44 ... 1..:.4-+44

(2 )

The system responds by typing IICASE ;) IS XOW SET
UP." This establishes the link list and connection matrix
of the configuration shown in Figure 4a.
We then issue the statement

4" 4 (6)

Figure 4c

o REPLACE 3

146

National Computer Conference, 1973

(1) 222244444444444''''44444444444444444444444444444 4444 444444 44 44 4 (5)
135
2222222222
11111111111
885
1 355
2222222222
11111111111
863 5
1
3 55
2222(3)1111
88 3
5
3
55
G02
88 33
55
6 0 2
88
3
55
fj
0
2
88
3
3
88
2
55
33
88
55
22
3
88
2
55
3
3
55
2
88
3
55 (j
2 88
33
3
655
88
3
3
G
55
88
2
3
G
55
0
88
2
3
3
6
550
88
2
3
23
36
5 8
63
855
32
33
22
66
3
880
55
2
6
3
88
55
3
6
88
55 3
3
2
388
55
2
8833
3
55
6
88
3
3
55
2
6
88
3
55
2
2
88
3
33
55
2
88
3
3
55
6
88
3 0 3
55
6
88
303
55
22
6
88
77(4)444
55
2
6 88
77777777
44444444
55 2
1 688
77777777
44444444
552
168 77777777
44444444
555
(2) 7799 99 99 99 99 99 99999 99999999999999999 99 99 999 9 99 99 99999 99 999 99 9 (6)

Figure 5a
(1)2222

1111(5)
2222222222

11111111111
2222222222

11111111111

2222( 3 )1111
602
6 0 2
6

2
22
2
5

2
2

2
2
2
6

(:,)
2
2
(6 )

5
(2)

Figure 5b
(1)2222

1111(5)
2222222222

11111111111
2222222222

11111111111
2222( 3 )1111
02
o 2
2
2
22

2
2

2
2
2

which signifies that a file is located at the 3rd node, and
that alternative links are to be tested in the network to
find configurations which are less costly.
In the listing of the terminal session, a partial trace is
made of REPLACE and of SNIP, called by REPLACE,
to show the cost of each configuration as it is calculated
Each time a configuration is discovered which has a 10weI
cost than any of the preceding cases, its link list is displayed.
Thus, we start \vith the configuration shown in Figure 4a.
SNIP finds it cannot delete any links. The cost of this
configuration is 2700. REPLACE then attempts to change
a link, but the resulting cost is 2750, and because it is more
expensive than the original case, it is discarded. REPLACE
then tries a second alteration, the cost of which is found to
be 2550, which is less than the original cost. The link list
of this configuration is displayed, and the revised network
is shown in Figure 4b. The reader can note that link 1 has
been replaced by link 7.
Following this, three more modifications are examined
and the first two are found more expensive than the last acceptable change. The third, however, costs 1550 and thus
is noted, and is shown in Figure 4c. Here we see that link 4
in the original configuration has been replaced by link 2.
A large number of additional modifications are examined,
but only when it arrives at the configuration shown in
Figure 4d is a more economic case found. Finally, REPLACE discovers that the configuration in Figure 4e is
lower in cost than any others preceding it, costing 1300.
Several additional cases are examined, following this, but
none is lower than this last configuration, which is then
displayed at the conclusion of execution.
Npxt., in a second run, we attempt to add links to the
final configuration derived in the first run to see if a still
cheaper case could be discovered. JOIN ALL was called
with the file specified at node 3, but each new link it attempted to add failed to decrease the cost below 1300. Thus,
no change was made.
In a third run, a fully connected network was specified,
as shown in Figure 5a. REPLACE was called, again with
the file at node 3. REPLACE called SNIP, which removed
ten links to produce the configuration shmvn in Figure 5b,
having a cost of 1500. REPLACE then modified the network
to produce the structure in Figure 5c, having a cost of 1350.
Thus, we see that sometimes an arbitrary configuration
such as that in the first run may be a better starting point
for REPLACE then a fully connected network, since the
first run resulted in a more economic configuration than did
the third.

2
2

REFERENCES

2
2

(4 )
1
1
1
( 2)

2
(G)

Figure 5c

1. APL/360-0S and APL/360-DOS, User's Manual, IBM Corporation, White Plains, New York, Form Number SH20-0906.
2. Roberts, L. G., Wessler, B. D., "Computer Network Development
to Achieve Resource Sharing," Proceedings of AFIPS &/CC 1970,
pp. 543-549.
3. Frank, H., Frisch, I. T., and Chou, W., "Topological Considerations in the Design of the ARPA Computer ~etwork:' ibid. pp.
581.

A System of APL Functions to Study Computer Networks

Fi rst Run

A P PEN 0 I X

-------

SETUP 5
CASE 5 IS 110rl SET UP

o REPLACE 3
SNIP[2]
1

415
10
3
4
14
4
6
15
5
6

SNIP[4] 2700
REPLACE[3]

1700
1800
1900
2000
1500
1550
2000
2100
1650

RE'PLACE[ 18J 1550

112
415
10
3
4
14
4
6
15
5
6

REPLACE[18] 2750
REPLACE[18] 2550
REPLACE[22]
415
724
10
3
4
14
4
6
15
5
6

REPLACE[18] 2750
REP LA Cl' [ 1 8 ] 2 8 5 0
REPLACE[18] 1550
REPLAC8[22]
112
213
10
3
4
14
4
6
15
5
6

REPLACE[18]
REPLACE[18]
REPLACE[18]
REPLACE[18]
REPLACE[18]
REPLACE[18]
REPLACE[18]
REPLACE[18]
REPLACE[18]
REPLACE[18]
REPLACE[18]
REPLACE[18]
REPLACE[18]
REPLACE[18]
REPLACE[18]
REPLACE[18]
REPLACE[18]
REPLACE[18]

REPLACE[18]
REPLACE[18]
REPLACE[18]
REPLACE[18]
REPLACE[18]
REPLACE[18]
REPLACE[18]
REPLACE[18J
REPLACE[18]

1800
2800
2700
2400
3250
2400
2400
2600
2950
2100
2300
2000
2000
3150
3250
1700
1750
2050

REPLACE[18J
REPLACE[18J
REPLACE[18J
RBPLACE[18J
REPLACE[18J
REPLACE[18]
REPLACE[18]
REPLACE[18]
REPLACE[18J
REPLACE[18]
REPLACE[18]
REPLACE[18]
REPLACE[18J
REPLACE[18J
REPLACE[18J
REPLACE[18]
REPLACE[18]
REPLACE[18]
REPLACE[18]
REPLACE[18]
112
213
10
3
4
11
3
5
3
6
1'2

1500
1450
1700
1800
1500
1850
2550
1650
1450
1550
1550
1650
1550
1650
1350
1400
2150
2250
1500
1400

REPLACE[18]
REPLACE[18]
R8PLACE[18]
REPLACE[18J
REPLACE[18J
REPLACE[18]
REPLACE[18]
REPLACE[22]
1
2
12
14
'15

1
1
3

4
5

2050
1800
2700
2800
1850
1600
1500
2
3
6
6
6

REPLACE[18] 2300
REPLACE[18J 2650
REPLACE[18] 1300
REPLACE[22]
1

2
3

10
13
15

4
5

5
6

REPLACE[18]
REPLACE[lB]
REPLACE[18]
REPLACE[18J
REPLACE[18]
REPLACE[18J
REPLACE[18J
REPLACE[18J
REPLACE[18J
REPLACE[18]
REPLACE[18]
REPLACE[18J
REPLACE[18]
REPLACE[18]
REPLACE[18J
REPLACE[18]
REPLACE[18]
REPLACE[18]
REPLACE[18]
REPLACE[18]
REPLACE[18]
REPLACE[18]
REPLACE[18]
REPLACE[18]
REPLACE[18]
REPLACE[18]
REPLACE[18]
112
213
10
3
4
13
4
5
15
5
6

2400
2500
1400
1700
1800
1500
1350
1450
1500
1700
1900
1550
2100
2650
1600
1400
1500
2050
2400
1550
2200
2300
1400
2150
2250
1350
1350

147

148

National Computer Conference, 1973

APPENDIX

Second Run

Third Run

lIL+O JOINALL 3
JOINALL[3]
1
2
10
13
15

2
3
4
5
6
JOINALL[5] 1300
JOINALL[10] 1300
JOINALL[10J 2200
JOINALL[10] 2150
1
1
3
4
5

JOINALL[18]
JOINALL[10]
JOINALL[10]
JOINALL[10]
JOINALL[10]
JOINALL[18]
JOINALL[10]
JOINALL[10]
JOIiVALL[18]
JOINALL[10]
JOINALL[18]
JOINALL[18]

1450
1300
1300
2250
7

1400
1350
7

1350
7

HL
1
2
10
13
15

1
1
3
4
5

2
3
4
5
6

o REPLACE 3
SNIP[2]
1
2
3
4
5
6
7

8
9
10
11
12
13
14
15

1
1
1
1
1
2
2
2
2
3
3
3
4
4
5

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

SNIP[4] 1500
REPLACE[ 3]
2
6
10
11
12

1
2
3
3
3

3
3
4
5
6

REPLACE[ 18]
REPLACE[ 18]
REPLACE[18]
REPLACE[18]
REPLA CE[ 18]
REPLACE[22]
1
2
10
11
12

1
1
3
3
3

REPLACE[18]
REPLACE[18]
REPLACE[18]
REPLACE[18]
REPLACE[18]

1650
1650
1900
2000
1350
2
3
4
5
6

1450
1700
1800
1800
190 a

A high-level language for use with multi-computer
networks
by HARVEY

z. KRILOFF

University of Illinois
Chicago, Illinois

INTRODUCTION

NETWORK LANGUAGE REQUIREMENTS

Two basic trends can be observed in the modern evolution
of computer systems. They are the development of computer systems dedicated to a single task or user
(minicomputers) where the sophistication of large computer systems is being applied to smaller units, and the
trend of very large systems that locate the user remotely
from the computer and share resources between more and
more locations. It is to the latter case that this paper is
directed. This trend reaches its culmination in the design
of distributed computer systems, where many individual
computer components are located remotely from each
other, and they are used to jointly perform computer
operations in the solution of a single problem. Systems
such as these are being developed in increasing numbers,
although they are yet only a small fraction of the total
number of computer systems. Examples of such systems
range from those that are National and International in
scope (the United States' APRANET,l Canada's CANUNET,z the Soviet Union's ASUS system 3 and the European Computer Network Project 4 ), the statewide systems
(the North Carolina Educational Computer System''; and
the MERIT Computer Network6 ), to single site systems
(The Lawrence Radiation Laboratory Network' and Data
Ring Oriented Computer Networks8 ). These systems and
others have been designed to solve problems in the areas
of research, education, governmental planning, airline
reservations and commercial time-sharing. Taken
together they demonstrate a capability for computer utilization that places more usable computer power in the
user's control than he has ever had before. The challenge
is to make effective use of this new tool.
Development of this new mode of computer usage has
followed the same set of priorities that has prevented
effective utilization of previous systems. A large body of
information has been collected on the hardware technology of network systems,9 but little effort has been
expended on the development of software systems that
allow the average user to make effective use of the network. A systematic examination of the requirements and
a design for a language that uses the full facilities of a
number of computer networks is needed.

After the language design had begun, it developed that
the concept of what a computer network was, and how it
was to be used, was not well understood. An effort was
therefore begun to classify computer networks and their
operations. This classification scheme indicated that a
language for computer networks would have to be constantly changing because networks evolve from one form
to another. It is this dynamic behavior that makes the
design of a single language for different types of networks
a high priority requirement.

Types of computer networks
A classification scheme was developed based on the
resource availability within the computer network and
the network's ability to recover from component failure.
The scheme consists of six (6) different modes of network
operatioI) with decreasing dependability and cost for the
later modes.
1. Multiple Job Threads: This consists of a system
where all components are duplicated and calculations are compared at critical points in the job. If a
component should fail, no time would be lost.
Example: NASA Space Flight Monitoring
2. Multiple Logic Threads: This is identical with the
previous mode except peripherals on the separate
systems can be shared.
3. Multiple Status Threads: In this mode only one set
of components performs each task. However, other
systems maintain records of system status at various
points in the job. If a component should fail all work
since the last status check must be re-executed.
Example: Remote Checkpoint-Restart
4. Single Job Thread: In this mode one computer system controls the sequencing of operations that may
be performed on other systems. If a system failure
occurs in the Master computer, the job is aborted.
5. Load Sharing: In this mode each job is performed
using only a single computer system. Jobs are transferred to the system with the lightest load, if it has all

149

150

National Computer Conference, 1973

necessary resources. If the system fails you may lose
all record of the job. Example: HASP to HASP job
transfer.
6. Star: In this mode only one computer system is
available to the user. It is the normal time-sharing
mode with a single computer. If the system is down
you can't select another computer.

using these type commands may not be transferable
to other networks. These type commands allow
direct connection to a computer system, submission
of a RJE job, reservation of a system resource,
network status checking, select network options,
access to system documentation, and establishment
of default options.

All presently operating networks fall within one of the
above modes of operation, and additional modes can be
developed for future networks. Operation within the first
two and last two modes require no additional language
features that are not needed on a single (non-network)
computer system. Thus, the language to be described will
be directed toward utilizing the capabilities of networks
operating in modes 3 and 4. In order to evaluate its usefulness, implementation will be performed on both the
ARPANET and MERIT Networks. Both networks can
operate in modes 3 and 4, and possess unique features
that make implementation of a single network language a
valid test of language transferability.

The network language must allow the user to perform all
these operations by the easiest method. Since the average
user will know very little about the network, the system
must be supplied with default parameters that will make
decisions that the user does not direct. These defaults can
be fitted to the network configuration, the individual user
or a class of problems.
User operations must be expressible in a compressed
form. Operations that the user performs very often should
be expressed by a single command. This will prevent
programming errors and it will allow for optimization of
command protocol. As new operations are required they
should be able to be added to the language without affecting already defined commands.

Computer network operations
Additional language constraints
In designing the language we recognized three (3) types
of operations that the network user would require.
1. Data Base Access: Four operations are necessary for

this type of usage. The user can copy the entire data
base from one computer system to another, or he
could access specific elements in the data base, or he
could update the data base, or he could inquire
about the status of the data base. Decisions on
whether to copy the data base or access it element
by element depend on data transfer speeds and the
amount of data needed, therefore they must be
determined for each job.
2. Subtask Execution: Tasks may be started in one of
four different modes. In the Stimulus-Response
mode a task is started in another machine while the
Master computer waits for a task completion message. In the Status Check mode the subtask executes
to completion while the Master task performs other
work. The subtask will wait for a request from the
Master to transmit the result. The third mode is an
interactive version of status checking where the
status check may reveal a request for more data.
The final mode allows the subtask to interrupt the
master task when execution is completed. Most
networks do not have the facilities to execute in
mode four, however all other modes are possible.
The novice will find mode one easiest, but greater
efficiency is possible with modes two and three.
3. Network Configuration: This type of usage is for the
experienced network user. It provides access to the
network at a lower level, so that special features of a
specific network may be used. Programs written

Three of the six constraints used to design the network
language have already been described. The list of features
that were considered necessary for a usable language are:
1. All purely systems requirements should be invisible

to the user.
2. The language should be easily modified to adapt to
changes in the network configuration.
3. The language should provide easy access to all features of the network at a number of degrees of
sophistication.
4. The language should provide a method for obtaining
on-line documentation about the available resources.
5. The fact that the system is very flexible should not
greatly increase the system's overhead.
6. The language syntax is easy to use, is available for
use in a non-network configuration, and it will not
require extensive modification to transfer the language to another network.
These requirements are primarily dictated by user needs,
rather than those required to operate the hardware/software system. It is the hope that the end result would be a
language that the user would use without knowing that he
was using a network.
The demand for on-line documentation is particularly
important. Most software systems are most effectively
used at the location where they were developed. As you
get farther from this location, fewer of the special features
and options are used because of lack of access to documentation. Since most of the systems to be used will
reside on remote computers, it is important that the user

A High-Level Language for Use with Multi-Computer Networks

be able to obtain current documentation while he uses the
system. That documentation should reside on the same
computer as the code used to execute the system.
Options used to determine which computer system you
are communicating with should not have to exist in interpretable code. This generality often leads to heavy overhead that defeats the advantages of a computer network.
An example of this was the Data Reconfiguration Service
created by Rand 10 as a general data converter that could
be used when transferring data from one computer to
another on the ARPANET. Because it was written to
execute interpretly, data conversion can only be performed at low speed. While high-speed and low-overhead
were not conditions of their implementation, an operationallanguage should not produce such restricted conditions of usage.
The final condition that the language be easily used
and operate on a single computer, led to the investigation
of available extendable languages. Using an already
developed language has certain advantages, people will
not need to learn a new language to use the network, program development can continue even when the network is
not operating, and network transparency is heavily dictated by the already designed language syntax. It was a
belief that a network language should not be different in
structure than any other language that led to the investigation of a high-level language implementation.
THE NETWORK LANGUAGE
An available language was found that met most of the
requirements of our network language. The language is
called SPEAKEASYll and it consists of a statement interpreter and a series of attachable libraries. One set of these
libraries consist of linkable modules called "linkules"
that are blocks of executable code that can be read off
the disk into core and executed under control of the interpreter. This code, that may be written in a high-level
language such as FORTRAN, can be used to perform the
necessary protocols and other system operations required
by the network. Thus, the user would not be required to
know anything other than the word that activates the
operation of the code. Each user required operation could
be given a different word, where additional data could be
provided as arguments of the activating word.
Since there are almost no limitations on the number of
library members, and each user could be provided with
his own attachable library, the language can be easily
extended to accommodate new features created by the
network. Linkules in SPEAKEASY could be created that
communicate with ind{vidual computer systems or that
perform similar operations in more than one system.
Where the latter is implemented, an automatic result
would be the creation of a super control language. Since
one of the factors that prevent the average user from
using more than one computer system is the non-uniformity of the operating systems, the development of a

151

network language will eliminate this problem. Using data
stored in other libraries, the network language could
supply the needed control syntax to execute a specified
task. This operation is not very much different from what
the user does when he is supplied control cards by a consultant that he uses until it is outdated by systems
changes.
The SPEAKEASY language presently provides the
facility to provide on-line documentation about itself
based on data in attachable libraries. This would be
extended to allow the SPEAKEASY interpreter to read
from libraries resident on a remote computer. Therefore,
the documentation could be kept up-to-date by the same
people responsible for developing the executing code.
Since SPEAKEASY linkules are compiled code, and
there may exist seperate modules that are only loaded
into core--whEm needed, minimal overhead is provided by
adding new operations to the system. This is the same
technique used to add operations to the present system,
therefore no difference should be detectable between resident and remote linkules.
NET\VORK MODULE PROTOCOLS
Where a single computer version of SPEAKEASY has
an easy task to determine how a command should be
executed, a multi-computer version makes more complex
decisions. Therefore it is necessary that there be established a well defined pattern of operations to be performed by each linkule.

Linkule order of operations
Each linkule that establishes communication with a
remote (slave) computer system should execute each of
the following ten operations, so as to maintain synchronization between the Master task and all remote subtasks.
No module will be allowed to leave core until the tenth
step is performed.
1.

3.
4.
5.
6.
7.
8.

Determine System Resources Needed.
Establish the Network Connections.
a) Select the Computer Systems that will be used.
b) Establish the System Availability.
c) Perform the Necessary Connect & Logon Procedures.
Allocate the Needed Computer System Resources
to the Job.
Provide for System Recovery Procedures in the
case of System Failure.
Determine what Data Translation Features are to
be used.
Determine whether Data Bases should be moved.
Start the main task in the remote computer executing.
Initiate and Synchronize any subtasks.

152

National Computer Conference, 1973

9. Terminate any subtasks.
10. Terminate the remote task and close all related
system connections.
In the present single computer version of SPEAKEASY
only tasks 3 and 7 are executed, and a more limited form
of task 4 is also performed. Where the overhead in opening and closing network connections is greater then the
cost of leaving the connections open, the 10th task will not
terminate any connection once made, allowing the next
linkule to check and find it open.
Information on the systems availability can be
obtained by inquiry from the network communications
software. Procedures and resource information can be
obtained from data stored in local or remote data set, by
inquiry from the user, or by inquiry from the system. All
allocation procedures will be performed by submitting the
appropriate control commands to the standard operating
system on the relevant computer.
Since the SPEAKEASY system will have the necessary
data about the origination and destination computers for
any unit of data being transfered, it can link to a linkule
that is designed for that translation only. This linkule
could take advantage of any special features or tricks that
would speed the translation process, thus reducing overhead during the translation process.

Requirements for network speakeasy
The minimal requirements to execute the Network
version of SPEAKEASY is a computer that will support
the interpreter. At the present time that means either an
IBM 360 or 370 computer operating under either the O/S
or MTS operating systems, or a F ACOM 60 computer
system. The network protocols for only two operations are
required. The Master computer must be able to establish
a connection to a remote computer and it must be able to
initiate execution of a job in the remote computer system.
The remote site should provide either a systems routine
or a user created module that will perform the operations
requested by the Master computer. This program, called
the Network Response Program, is activated whenever a
request is made to the remote computer. There may be
one very general Network Response Program, or many
different ones designed for specific requests. Figure 1
shows the modular structure of the Network Language in
both the Master and Slave (Subtask) computing systems.
Because the network features of the language are
required to be totally transparent to the user, no examples of network programming are shown. The reader
should refer to previously published papers on Speakeasy
for examples of programming syntax.
SUMMARY
A network version of the SPEAKEASY system is
described that consists of a series of dynamically linked

"ASTER

cOIIPUTER

SLAVE

COMPUTER

Figure I-The modular structure of the Network Speakeasy
System. Dotted lines indicate dynamic linkages, dashed
lines are telecommunications links, and solid lines are
standard linkages.

modules that perform the necessary language and system
protocols. These protocols are transparent to the user,
producing a language that has additional power without
additional complexity. The language uses attached libraries to provide the necessary information that will tailor
the system to a specific network, and to supply on-line
documentation. Since the modules are compiled code, the
generality of the system does not produce a large overhead.

ACKNOWLEDGMENT
The author is indebted to Stanley Cohen, developer of the
SPEAKEASY system. His assistance and support made
this extension possible.
REFERENCES
1. Roberts, L. G., "Resource Sharing Networks," Proceedings of

IEEE International Conference, 1969.
2. Demercado, J., Guindon, R., Dasilva, J., Kadoch, M., "The Canadian Universities Computer Network Topological Considerations,"
The First International Conference on Computer Communication,
1972.
3. Titus, J., "Soviet Computing-A Giant Awake," Datamation, Vol.
17, No. 24, 1971.
4. Barber, D. L. A., "The European Computer Network Project," The
First International Conference on Computer Communication,
1972.
5. Denk, J. R., "Curriculm Development of Computer Usage in
North Carolina," Proceedings of a Conference on Computers in the
Undergraduate Curricula.
6. Herzog, B., "Computer Networks," International Computing
Symposium, ACM, 1972.
7. Mendicino, S. F., "OCTOPUS-The Lawrence Radiation Laboratory Network," Computer Networks, Prentice-Hall, Englewood
Clitfs. ~ .•J., Hr;2.

A High-Level Language for Use with Multi-Computer Networks

8. Farber, D., "Data Ring Oriented Computer Networks," Computer
Networks, Prentice-Hall, Englewood Cliffs, N.J., 1972.
9. Frank, H., Kahn, R. E., Kleinrock, L., "Computer Communication
Network Design-Experience with Theory and Practice," Networks, Vol. 2, 1972.

153

10. Harslem, E. F., Heafner, J., Wisniewski, T. D., Data Reconfiguration Service Compiler-Communication Among Heterogeneous
Computer Center Using Remote Resource Sharing, Rand Research
Report R-887 -ARPA, 1972.
11. Cohen, S., "Speakeasy-RAKUGO," First USA Japan Computer
Conference Proceedings, 1972.

A resource sharing executive for the ARP ANET*
by ROBERT H. THOMAS
Bolt, Beranek and Newman, Inc.
Cambridge, Mass.

with paging hardware. In comparison to the TIPs, the
TENEX Hosts are large. TENEX implements a virtual
processor with a large (256K word), paged virt_~_~L_I!l~_ITI~
ory for -each user process. In addition, it provides a multiprocess job structure with software program interrupt
capabilities, an interactive and carefully engineered
command language (implemented by the TENEX
EXEC) and advanced file handling capabilities.
Development of the RSEXEC was motivated initially
by the desire to pool the computing and storage resources
of the individual TENEX Hosts on the ARPA~ET. We
observed that the TENEX virtual machine was becoming
a popular network resource. Further, we observed that for
many users, in particular those whose access to the network is through TIPs or other non-TENEX Hosts, it
shouldn't really matter which Host provides the TENEX
virtual machine as long as the user is able to do his
computing in the manner he has become accustomed*. A
number of advantages result from such resource sharing.
The user would see TENEX as a much more accessible
and reliable resource. Because he would no longer be
dependent upon a single Host for his computing he would
be able to access a TENEX virtual machine even when
one or more of the TENEX Hosts were down. Of course,
for him to be able to do so in a useful way, the TENEX
file system would have to span across Host boundaries.
The individual TENEX Hosts would see advantages also.
At present, due to local storage limitations, some sites do
not provide all of the TENEX subsystems to their users.
For example, one site doesn't support FORTRAN for this
reason. Because the subsystems available would, in effect,
be the "union" of the subsystems available on all
TENEX Hosts, such Hosts would be able to provide
access to all TENEX subsystems.
The RSEXEC was conceived of as an experiment to
investigate the feasibility of the multi-Host TENEX
concept. Our experimentation with an initial version of
the RSEXEC was encouraging and, as a result, we
planned to develop and maintain the RSEXEC as a
TENEX subsystem. The RSEXEC is, by design, an evo-

INTRODUCTION
The Resource Sharing Executive (RSEXEC) is a distributed, executive-like system that runs on TENEX Host
computers in the ARPA computer network. The
RSEXEC creates an environment which facilitates the
sharing of resources among Hosts on the ARPANET. The
large Hosts, by making a small amount of their resources
available to small Hosts, can help the smaller Hosts provide services which would otherwise exceed their limited
capacity. By sharing resources among themselves the
large Hosts can provide a level of service better than any
one of them could provide individually. Within the environment provided by the RSEXEC a user need not concern himself directly with network details such as communication protocols nor even be aware that he is dealing
with a network.
A few facts about the ARPANET and the TENEX
operating system should provide sufficient background
for the remainder of this paper. Readers interested in
learning more about the network or TENEX are referred
to the literature; for the ARPANET References 1,2,3,4;
for TENEX. References 5,6,7.
The ARPANET is a nationwide heterogeneous collection of Host computers at geographically separated locations. The Hosts differ from one another in manufacture,
size, speed, word length and operating system. Communication between the Host computers is provided by a
subnetwork of small, general purpose computers called
Interface Message Processors or IMPs which are interconnected by 50 kilobit common carrier lines. The IMPs
are programmed to implement a store and forward
communication network. As of January 1973 there were
45 Hosts on the ARPANET and 33 IMPs in the subnet.
In terms of numbers, the two most common Hosts in
the ARPANET are Terminal IMPs called TIP s 12 and
TENEXs.9 TIP ss.9 are mini-Hosts designed to provide
inexpensive terminal access to other network Hosts. The
TIP is implemented as a hardware and software augmentation of the IMP.
TENEX is a time-shared operating system developed
by BBN to run on a DEC PDP-10 processor augmented

* This, of course, ignores the problem of differences in the accounting
and billing practices of the various TENEX Hosts. Because all of the
TENEX Hosts (with the exception of the two at BBN) belong to ARPA
we felt that the administrative problems could be overcome if the technical problems preventing resource sharing were solved.

* This work was supported by the Advanced Projects Research Agency
of the Department of Defense under Contract No. DAHC15-71-C-0088.

155

156

National Computer Conference, 1973

lutionary system; we planned first to implement a system
with limited capabilities and then to let it evolve, expanding its capabilities, as we gained experience and came to
understand the problems involved.
During the early design and implementation stages it
became clear that certain of the capabilities planned for
the RSEXEC would be useful to all network users, as well
as users of a multi-Host TENEX. The ability of a user to
inquire where in the network another user is and then to
"link" his own terminal to that of the other user in order
to engage in an on-line dialogue is an example of such a
capability.
A large class of users with a particular need for such
capabilities are those whose access to the network is
through mini-Hosts such as the TIP. At present TIP users
account for a significant amount of network traffic,
approximately 35 percent on an average day. IO A frequent
source of complaints by TIP users is the absence of a
sophisticated command language interpreter for TIPs
and, as a result, their inability to obtain information
about network status, the status of various Hosts, the
whereabouts of other users, etc., without first logging into
some Host. Furthermore, even after they log into a Host,
the information readily available is generally limited to
the Host they log into. A command language interpreter
of the type desired would require more (core memory)
resources than are available in a TIP alone. We felt that
with a little help from one or more of the larger Hosts it
would be feasible to provide TIP users with a good
command language interpreter. (The TIPs were already
using the storage resources of one TENEX Host to provide their users with a network news service. IO . 11 Further,
since a subset of the features already planned for the
RSEXEC matched the needs of the TIP users, it was
clear that with little additional effort the RSEXEC system could provide TIP users with the command language
interpreter they needed. The service TIP users can obtain
through the RSEXEC by the use of a small portion of the
resources of several network Hosts is superior to that they
could obtain either from the TIP itself or from any single
Host.
An initial release of the RSEXEC as a TENEX subsystem has been distributed to the ARPANET TENEX
Hosts. In addition, the RSEXEC is available to TIP users
(as well as other network users) for use as a network
command language interpreter, preparatory to logging
into a particular Host (of course, if the user chooses to log
into TENEX he may continue using the RSEXEC after
login). Several non-TENEX Hosts have expressed interest
in the RSEXEC system, particularly in the capabilities it
supports for inter-Host user-user interaction, and these
Hosts are now participating in the RSEXEC experiment.
The current interest in computer networks and their
potential for resource sharing suggests that other systems
similar to the RSEXEC will be developed. At present
there is relatively little in the literature describing such
distributing computing systems. This paper is presented
to record our experience with one such system: we hope it

will be useful to others considering the implementation of
such systems.
The remainder of this paper describes the RSEXEC
system in more detail: first, in terms of what the
RSEXEC user sees, and then, in terms of the implementation.
THE USER'S VIEW OF THE RSEXEC
The RSEXEC enlarges the range of storage and computing resources accessible to a user to include those
beyond the boundaries of his local system. It does that by
making resources, local and remote, available as part of a
single, uniformly accessible pool. The RSEXEC system
includes a command language interpreter which extends
the effect of user commands to include all TENEX Hosts
in the ARPANET (and for certain commands some nonTENEX Hosts), and a monitor call interpreter which, in
a similar way, extends the effect of program initiated
"system" calls.
To a large degree the RSEXEC relieves the user and
his programs of the need to deal directly with (or even be
aware that they are dealing with) the ARPANET or
remote Hosts. By acting as an intermediary between its
user and non-local Hosts the RSEXEC removes the logical distinction between resources that are local and those
that are remote. In many contexts references to files and
devices* may be made in a site independent manner. For
example, although his files may be distributed among
several Hosts in the network, a user need not specify
where a particular file is stored in order to delete it; rather, he need only supply the file's name to the delete
command.
To a first approximation, the user interacts with the
RSEXEC in much the same way as he would normally
interact with the standard (single Host) TENEX executive program. The RSEXEC command language is syntactically similar to that of the EXEC. The significant
difference, of course, is a semantic one; the effect of
commands are no longer limited to just a single Host.
Some RSEXEC commands make direct reference to
the multi-Host environment. The facilities for inter-Host
user-user interaction are representative of these commands. For example, the WHERE and LINK commands
can be used to initiate an on-line dialogue with another
user:
<-WHERE (IS USER) JONES**
JOB 17 TTY6 USC
JOB 5 TTY14 CASE
<-LINK (TO TTY) 14 (AT SITE) CASE
* Within TENEX, peripheral devices are accessible to users via the file
system; the terms "file" and "device" are frequently used interchangeably in the following.
** "+--" is the RSEXEC "ready" character. The words enclosed in parentheses are "noise" words which serve to make the commands more
understandable to the user and may be omitted. A novice user can use
the character ESC to cause the RSEXEC to prompt him by printing the
noise words.

A Resource Sharing Executive for the ARPA~ET

Facilities such as these play an important role in
removing the distinction between "local" and "remote"
by allowing users of geographically. separated Hosts to
interact with one another as if they were members of a
single user community. The RSEXEC commands directly
available to TIP users in a "pre-login state" include those
for inter-Host user-user interaction together with ones
that provide Host and network status information and
network news.
Certain RSEXEC commands are used to define the
"configuration" of the multi-Host environment seen by
the user. These "meta" commands enable the user to
specify the "scope" of his subsequent commands. For
example, one such command (described in more detail
below) allows him to enlarge or reduce the range of Hosts
encompassed by file system commands that follow.
Another "meta" command enableshirn to spe.cify _a set of
peripheral devices which he may reference in a site independent manner in subsequent commands.
The usefulness of multi-Host systems such as the
RSEXEC is, to a large extent, determined by the ease
with which a user can manipulate his files. Because the
Host used one day may be different from the one used the
next, it is necessary that a user be able to reference any
given file from all Hosts. Furthermore, it is desirable that
he be able to reference the file in the same manner from
all Hosts.
The file handling facilities of the RSEXEC were designated to:

157

designed to allow use of partial pathnames for frequently
referenced file, for their users. *
It is straightforward to extend the tree structured
model for file access within a single Host to file access
within the entire network. A new root node is created with
branches to each of the root nodes of the access trees for
the individual Hosts, and the complete pathname is
enlarged to include the Host name. A file access tree for a
single Host is shown in Figure 1; Figure 2 shows the file
access tree for the network as a collection of single Host
trees.
The RSEXEC supports use of complete pathnames
that include a Host component thereby making it possible
(albeit somewhat tedious) for users to reference a file on
any Host. For example, the effect of the command
~AI>PENP (FJL~) [CASEIDSK:DATA.
NEW (TO FILE) [BBN]DSK: DATA.OLD**

is to modify the file designated CD in Figure 2 by appending to it the file designated (2) .
To make it convenient to reference files, the RSEXEC
allows a user to establish contexts for partial pathname
interpretation. Since these contexts may span across several Hosts, the user has the ability to configure his own
"virtual" TENEX which may in reality be realized by the
resources of several TENEXs. Two mechanisms are
available to do this.
The first of these mechanisms is the user profile which
is a collection of user specific information and parameters

1. Make it possible to reference any file on any Host by

implementing a file name space which spans across
Host boundaries.
2. Make it convenient to reference frequently used files
by supporting "short hand" file naming conventions,
such as the ability to specify certain files without
site qualification.
The file system capabilities of the RSEXEC are designed
to be available to the user at the command language
level and to his programs at the monitor call level. An important design criterion was that existing programs be
able to run under the RSEXEC without reprogramming.
File access within the RSEXEC system can be best
described in terms of the commonly used model which
views the files accessible from within a Host as being
located at terminal nodes of a tree. Any file can be specified by a pathname which describes a path through the
tree to the file. The complete pathname for a file includes
every branch on the path leading from the root node to
the file. While, in general, it is necessary to specify a
complete pathname to uniquely identify a file, in many
situations it is possible to establish contexts within which
a partial pathname is sufficient to uniquely identify a
file. Most operating systems provide such contexts,

Figure I-File access tree for a single Host. The circles at
the terminal nodes of the tree represent files

* For example, TENEX does it by:
1. Assuming default values for certain components left unspecified in
partial pathnames;
2. Providing a reference point for the user within the tree (working
directory) and thereafter interpreting partial pathnames as being relative to that point. TENEX sets the reference point for each user at login
time and, subject to access control restrictions, allows the user to change
it (by "connecting" to another directory).
** The syntax for (single Host) TENEX path names includes device.
directory, name and extension components. The RSEXEC extends that
syntax to include a Host component. The pathname for@specifies: the
CASE Host; the disk ("DSK") device; the directory THOMAS; the
name DATA; and the extension NEW.

158

National Computer Conference, 1973

Figure 2-File access tree for a network. The single Host access tree from Figure 1 is part of this tree

maintained by the RSEXEC for each user. Among other
things, a user's profile specifies a group of file directories
which taken together define a composite directory for the
user. The "contents" of the composite directory are the
union of the "contents" of the file directories specified in
the profile. When a pathname without site and directory
qualification is used, h is interpreted relative to the user's
composite directory. The composite directory serves to
define a reference point within the file access tree that is
used by the RSEXEC to interpret partial pathnames.
That reference point is somewhat unusual in that it spans
several Hosts.
One of the ways a user can reconfigure his "virtual"
TENEX is by editing his profile. With one of the "meta"
commands noted earlier he can add or remove components of his composite directory to control how partial
pathnames are interpreted.
An example may help clarify the role of the user profile, the composite directory and profile editing. Assume
that the profile for user Thomas contains directories
BOBT at BBN, THOMAS at CASE and BTHOMAS at
USC (see Figure 2). His composite directory, the reference point for pathname interpretation, spans three
Hosts. The command
<-APPEND (FILE) DATA.NEW (TO FILE) DATA.OLD
achieves the same effect as the APPEND command in a
previous example. To respond the RSEXEC first consults
the composite directory to discover the locations of the
files, and then acts to append the first file to the second;
how it does so is discussed in the next section. If he
wanted to change the scope of partial pathnames he uses,
user Thomas could delete directory BOBT at BBN from
his profile and add directory RHT at AMES to it.
The other mechanism for controlling the interpretation
of partial pathnames is device binding. A user can
instruct the HSEXEr tn interpret subspquent use of ::l

particular device name as referring to a device at the Host
he specifies. After a device name has been bound to a
Host in this manner, a partial pathname without site
qualification that includes it is interpreted as meaning
the named device at the specified Host. Information in
the user profile specifies a set of default device bindings
for the user. The binding of devices can be changed
dynamically during an RSEXEC session. In the context
of the previous example the sequence of commands:
+-BIND (DEVICE) LPT (TO SITE) BBN
+-LIST DATA. NEW
<-BIND (DEVICE) LPT (TO SITE) USC
<-LIST DATA.NEW
produces two listings of the file DATA.NEW: one on the
line printer (device "LPT") at BBN, the other on the
printer at USC. As with other RSEXEC features, device
binding is available at the program level. For example, a
program that reads from magnetic tape will function
properly under the RSEXEC when it runs on a Host
without a local mag-tape unit, provided the mag-tape
device has been bound properly.
The user can take advantage of the distributed nature
of the file system to increase the "accessibility" of certain
files he considers important by instructing the RSEXEC
to maintain images of them at several different Hosts.
With the exception of certain special purpose files (e.g.,
the user's "message" file), the RSEXEC treats files with
the same pathname relative to a user's composite directory as images of the same multi-image file. The user
profile is implemented as a multi-image file with an image
maintained at every component directory of the composite directory. *

'" The profile is somewhat special in that it is accessible to the user only
through the profile erliting rommands. and is otherwise transparent.

A Resource Sharing Executive for the ARPANET

Implementation of the RSEXEC
The RSEXEC implementation is discussed in this section with the focus on approach rather than detail. The
result is a simplified but nonetheless accurate sketch of
the implementation.
The RSEXEC system is implemented by a collection of
programs which run with no special privileges on TENEX
Hosts. The advantage of a "user-code" (rather than
"monitor-code") implementation is that ordinary user
access is all that is required at the various Hosts to develop, debug and use the system. Thus experimentation with
the RSEXEC can be conducted with minimal disruption
to the TENEX Hosts.
The ability of the RSEXEC to respond properly to
users' requests often requires cooperation from one or
more remote Hosts. When such cooperation is necessary,
tile RSEXEC program interacts with RSEXEC "service"
programs at the remote Hosts according to a pre-agreed
upon set of conventions or protocol. Observing the protocol, the RSEXEC can instruct a service program to perform actions on its behalf to satisfy its user's requests.
Each Host in the RSEXEC system runs the service
program as a "demon" process which is prepared to provide service to any remote process that observes protocol.
The relation between RSEXEC programs and these
demons is shown schematically in Figure 3.

The RSEXEC protocol
The RSEXEC protocol is a set of conventions designed
to support the interprocess communication requirements
of the RSEXEC system. The needs of the system required
that the protocol:

Figure 3-Schematic showing several RSEXEC programs
interacting, on behalf of their users, with remote server programs

159

1. be extensible:
As noted earlier, the RSEXEC is, by design, an
evol utionary system.
2. support many-party as well as two-party interactions:
Some situations are better handled by single multiparty interactions than by several two-party interactions. Response to an APPEND command when the
files and the RSEXEC are all at different Hosts is
an example (see below).
3. be convenient for interaction between processes
running on dissimilar Hosts while supporting efficient interaction between processes on similar Hosts:
Many capabilities of the RSEXEC are useful to
users of non -TENEX as well as TENEX Hosts. It is
important that the protocol not favor TENEX at
the expense of other Hosts.

The RSEXEC protocol has two parts:
1. a protocol for initial connection specifies how programs desiring service (users) can connect to programs providing service (servers);
2. a command protocol specifies how the user program
talks to the server program to get service after it is
connected.
The protocol used for initial connection is the standard
ARPANET initial connection protocol (ICP).12 The
communication paths that result from the ICP exchange
are used to carry commands and responses between user
and server. The protocol supports many-party interaction
by providing for the use of auxiliary communication
paths, in addition to the command paths. Auxiliary paths
can be established at the user's request between server
and user or between server and a third party. Communication between processes on dissimilar Hosts usually
requires varying degrees of attention to message formatting, code conversion, byte manipulation, etc. The protocol addresses the issue of convenience in the way other
standard ARPANET protocols have. 13 ,14.15 It specifies a
default message format designed to be "fair" in the sense
that it doesn't favor one type of Host over another by
requiring all reformatting be done by one type of Host. It
addresses the issue of efficiency by providing a mechanism with which processes on similar Hosts can negotiate
a change in format from the default to one better suited
for efficient use by their Hosts.
The protocol can perhaps best be explained further by
examples that illustrate how the RSEXEC .uses it. The
following discusses its use in the WHERE, APPEND and
LINK commands:
-WHERE (IS USER) JONES
The RSEXEC querie~ each non-local server program
about user Jones. To query a server, it establishes
connections with the server; transmits a "request for
information about Jones" as specified by the protocol;

160

National Computer Conference, 1973

and reads the response which indicates whether or not
Jones is a known user, and if he is, the status of his
active jobs (if any).
--APPEND
(FILE)
DATA.NEW
(TO
FILE)
DATA.OLD
Recall that the files DATA.NEW and DATA.OLD are
at CASE and BBN, respectively; assume that the
APPEND request is made to an RSEXEC running at
USC. The RSEXEC connects to the servers at CASE
and BBN. Next, using the appropriate protocol
commands, it instructs each to establish an auxiliary
path to the other (see Figure 4). Finally, it instructs
the server at CASE to transmit the file DATA. NEW
over the auxiliary connection and the server at BBN
to append the data it reads from the auxiliary connection to the file DATA.OLD.
+-LINK (TO TTY) 14 (AT SITE) CASE
Assume that the user making the request is at USC.
After connecting to the CASE server, the RSEXEC
uses appropriate protocol commands to establish two
auxiliary connections (one "send" and one "receive")
with the server. It next instructs the server to "link"
its (the server's) end of the auxiliary connections to
Terminal 14 at its (the server's) site. Finally, to complete the LINK command the RSEXEC "links" its
end of the auxiliary connections to its user's terminal.

The RSEXEC program
A large part of what the RSEXEC program does is to
locate the resources necessary to satisfy user requests. It
can satisfy some requests directly whereas others may
require interaction with one or more remote server programs. For example, an APPEND command may involve
AUXILIARY

CONNECTION

Figure 4-configuration of RSEXEC and two server programs required
to satisfy and APPEND command when the two files and the
RSEXEC are all on different Hosts. The auxiliary connection is used
to transmit the file to be appended from one server to the other

interaction with none, one or two server programs
depending upon where the two files are stored.
An issue basic to the RSEXEC implementation concerns handling information necessary to access files:
in particular, how much information about non-local
files should be maintained locally by the RSEXEC? The
advantage of maintaining the information locally is that
requests requiring it can be satisfied without incurring
the overhead involved in first locating the information
and then accessing it through the network. Certain highly
interactive activity would be precluded if it required
significant interaction with remote server programs. For
example, recognition and completion of file names* would
be ususable if it required direct interaction with several
remote server programs. Of course, it would be impractical to maintain information locally about all files at all
TENEX Hosts.
The approach taken by the RSEXEC is to maintain
information about the non-local files a user is most likely
to reference and to acquire information about others from
remote server programs as necessary. It implements this
strategy by distinguishing internally four file types:
1. files in the Composite Directory;
2. files resident at the local Host which are not in the
Composite Directory;
3. files accessible via a bound device, and;
4. all other files.

Information about files of type 1 and 3 is maintained locally by the RSEXEC. It can acquire information about
type 2 files directly from the local TEi'TEX monitor, as
necessary. No information about type '* files is maintained locally; whenever such information is needed it is
acquired from the appropriate remote server. File name
recognition and completion and the use of partial pathnames is rest ricted to file types 1, 2 and 3.
The composite directory contains an entry for each
file in each of the component directories specified in the
user's profile. At the start of each session the RSEXEC
constructs the user's composite directory by gathering
information from the server programs at the Hosts specified in the user profile. Throughout the session the
RSEXEC modifie!' the composite directory. adding
and deleting entries, as necessary. The composite directory contains frequently accessed information (e.g., Host
location, size, date of last access, etc.) about the user's
files. It represents a source of information that can be
accessed without incurring the overhead of going to the
remote Host each time it is needed.
* File name recognition and completion is a TENEX feature which
allows a user to abbreviate fields of a file pathname. Appearance of ESC
in the name causes the portion of the field before the ESC to be looked
up, and, if the portion is unambiguous, the system will recognize it and
supply the omitted characters and/ or fields to complete the file name. If
the portion is ambiguous, the system will prompt the user for more
characters by ringing the terminal bell. Because of its popularity we felt
it important that the RSEXEC support this feature.

A Resource Sharing Executive for the ARPANET

The RSEXEC regards the composite directory as an
approximation (which is usually accurate) to the state of
the user's files. The state of a given file is understood to
be maintained by the TENEX monitor at the site where
the file resides. The RSEXEC is aware that the outcome
of any action it initiates involving a remote file depends
upon the file's state as determined by the appropriate
remote TEKEX monitor, and that the state information
in the composite directory may be "out of phase" with the
actual state. It is prepared to handle the occasional failure of actions it initiates based on inaccurate information
in the composite directory by giving the user an appropriate error message and updating the composite directory.
Depending upon the severity of the situation it may
choose to change a single entry in the composite directory,
reacquire all the information for a component directory,
ox rebuild the entire composite directory.

The service program for the RSEXEC
Each RSEXEC service program has two primary responsibilities:
1. to act on behalf of non-local users (typically
RSEXEC programs), and;
2. to maintain information on the status of the other
server programs.

The status information it maintains has an entry for each
Host indicating whether the server program at the Host is
up and running, the current system load at the Host, etc.
Whenever an RSEXEC program needs service from some
remote server program it checks the status information
maintained by the local server. If the remote server is
indicated as up it goes ahead and requests the service;
otherwise it does not bother.
A major requirement of the server program implementation is that it be resilient to failure. The server should
be able to recover gracefully from common error situations and, more important, it should be able to "localize"
the effects of those from which it can't. At any given time,
the server may simultaneously be acting on behalf of a
number of user programs at different Hosts. A malfunctioning or malicious user program should not be able to
force termination of the entire service program. Further,
it should not be able to adversely effect the quality of
service received by the other users.
To achieve such resiliency the RSEXEC server program is implemented as a hierarchy of loosely connected,
cooperating processes (see Figure 5):
1. The RSSER process is at the root of the hierarchy.
Its primary duty is to create and maintain the other
processes;
2. REQSER processes are created in response to
requests for service. There is one for each non-local
user being served.

161

/ /
/

/
/
/

Figure 5-Hierarchical structure of the RSEXEC service program

3. A ST ASER process maintains status information
about the server programs at other sites.
Partitioning the server in this way makes it easy to localize the effect of error situations. For example, occurrence
of an unrecoverable error in a REQSER process results in
service interruption only to the user being serviced by
that process: all other REQSER processes can continue
to provide service uninterrupted.
When service is requested by a non-local program, the
RSSER process creates a REQSER process to provide it.
The REQSER process responds to requests by the nonlocal program as governed by the protocol. When the nonlocal program signals that it needs no further service,
the REQSER process halts and is terminated by RSSER.
The STASER process maintains an up-to-date record
of the status of the server programs at other Hosts by
exchanging status information with the STASER processes at the other Hosts. The most straightforward way to
keep up-to-date information would be to have each
STASER process periodically "broadcast" its own status
to the others. Unfortunately, the current, connectionbased Host-Host protocol of the ARPANET16 forces use of
a less elegant mechanism. Each STASER process performs its task by:
1. periodically requesting a status report from each of
the other processes, and;
2. sending status information to the other processes as
requested.

To request a status report from another STASER process, STASER attempts to establish a connection to a
"well-known" port maintained in a "listening" state by
the other process. If the other process is up and running,
the connection attempt succeeds and status information is sent to the requesting process. The reporting process then returns the well-known port to the listening
state so that it can respond to requests from other proc-

162

National Computer Conference, 1973

esses. The requesting process uses the status report to update an appropriate status table entry. If the connection
attempt does not succeed within a specified time pe.riod,
the requesting process records the event as a mIssed
report in an appropriate status table entry.
When the server program at a Host first comes up, the
status table is initialized by marking the server programs
at the other Hosts as down. After a particular server is
marked as down, STASER must collect a number of status reports from it before it can mark the program as up
and useful. If, on its way up, the program misses several
consecutive reports, its "report count" is zeroed. By
requiring a number of status reports from a remote server
before marking it as up, STASER is requiring that the
remote program has functioned "properly" for a while. As
a result, the likelihood that it is in a stable state capable
of servicing local RSEXEC programs is increased.
STASER is willing to attribute occasionally missed reports as being due to "random" fluctuations in network
or Host responses. However, consistent failure of a remote server to report is taken to mean that the program
is unusable and results in it being marked as down.
Because up-to-date status information is crucial to the
operation of the RSEXEC system it is important that
failure of the STASER process be infrequent, and that
when a failure does occur it is detected and corrected
quickly. STASER itself is programmed to cope with
common errors. However error situations can arise from
which STASER is incapable of recovering. These situations are usually the result of infrequent and unexpected
"network" events such as Host-Host protocol violations
and lost or garbled messages. (Error detection and control
is performed on messages passed between IMPS to insure
that messages are not lost or garbled within the IMP
subnet: however, there is currently no error control for
messages passing over the Host to IMP interface.) For all
practical purposes such situations are irreproducible,
making their pathology difficult to understand let alone
program for. The approach we have taken is to ~ckn?wl
edge that we don't know how to prevent such sIt~atI?ns
and to try to minimize their effect. When functIOnmg
properly the STASER process "reports in" periodicall~.
If it fails to report as expected, RSSER assumes that It
has malfunctioned and restarts it.

Providing the RSEXEC to TIP users
The RSEXEC is available as a network executive program to users whose access to the network is by way of a
TIP (or other non-TENEX Host) through a standard
service program (TIPSER) that runs on TENEX Hosts.*
To use the RSEXEC from a TIP a user instructs the TIP
to initiate an initial connection protocol exchange with
one of the TIPSER programs. TIPSER responds to the
* At present TIPSER is run on a regular basis at only one of the
TENEX Hosts; we expect several other Hosts will start running it on a
ff'gnl:H hH~i~ "hortly.

ICP by creating a new process which runs the RSEXEC
for the TIP user.
CONCLUDING REMARKS
Experience with the RSEXEC has shown that it is capable of supporting significant resource sharing among the
TENEX Hosts in the ARPANET. It does so in a way that
provides users access to resources beyond the boundaries
of their local system with a convenience not previously
experienced within the ARPANET. As the RSEXEC
system evolves, the TENEX Hosts will become more
tightly coupled and will approach the goal of a multi-Host
TENEX. Part of the process of evolution will be to provide direct support for many RSEXEC features at the
level of the TENEX monitor.
At present the RSEXEC system is markedly deficient
in supporting significant resource sharing among dissimi1ar Hosts. True, it provides mini-Hosts, such as TIPs,
with a mechanism for accessing a small portion of the
resources of the TENEX (and some non-TENEX) Hosts,
enabling them to provide their users with an executive
program that is well beyond their own limited capacity.
Beyond that, however, the system does little more than to
support inter-Host user-user interaction between Hosts
that choose to implement the appropriate subset of the
RSEXEC protocol. There are, of course, limitations to
how tightly Hosts with fundamentally different operating
systems can be coupled. However, it is clear that the
RSEXEC has not yet approached those limitations and
that there is room for improvement in this area.
The RSEXEC is designed to provide access to the
resources within a computer network in a manner that
makes the network itself transparent by removing the
logical distinction between local and remote. As a result,
the user can deal with the network as a single entity
rather than a collection of autonomous Hosts. We feel
that it will be through systems such as the RSEXEC that
users will be able to most effectively exploit the resources
of computer networks.
ACKNOWLEDGMENTS
Appreciation is due to W. R. Sutherland whose leadership
and enthusiasm made the RSEXEC project possible. P.
R. Johnson actively contributed in the implementation of
the RSEXEC. The TENEX Group at BBN deserves recognition for constructing an operating system that made
the task of implementing the RSEXEC a pleasant one.
REFERENCES
1. Roberts, L. G., Wessler, B. D., "Computer Network Development

to Achieve Resource Sharing," Proc. of AFIPS SJCC, 1970, Vol.
36, pp. 543-549.
2. Heart, F. E., Kahn, R. E., Ornstein, S. M., Crowther, W. R., Walden, D. C., "The Interface Message Processor for the ARPA
Computer :\'etwork," Proc. of J.FJPS SJCC, 1970, Vol. 36.

A Resource Sharing Executive for the ARPANET

3. McQuillan, J. M., Crowther, W. R., Cosell, B. P., Walden, D. C.,
Heart, F. E., "Improvements in the Design and Performance of
the ARPA ~etwork," Proc. of AFIPS FJCC, 1972, Vol. 41, pp.
741-754.
4. Roberts, L. G., "A Forward Look," Signal, Vol. XXV, No. 12, pp.
77 -81, August, 1971.
5. Bobrow, D. G., Burchfiel, J. D., Murphy, D. L., Tomlinson, R. S.,
"TENEX, a Paged Time Sharing System for the PDP-lO,"
Communications of the ACM, Vol. 15, No.3, pp. 135-143, March,
1972.
6. TENEX JSYS Manual-A Manual of TENEX Monitor Calls,
BBN Computer Science Division, BBN, Cambridge, Mass., November 1971.
7. Murphy, D. L., "Storage Organization and Management in
TENEX," Proc. of AFIPS FJCC, 1972, Vol. 41, pp. 23-32.
8. Ornstein, S. M., Heart, F. E., Crowther, W. R., Rising, H. K.,
Russell, S. B., Michel, A., "The Terminal IMP for the ARPA
Computer Network," Proc. of AFIPS SJCC, 1972, Vol. 40, pp. 243254.
~~ Kahn, R. E., "Terminal Access to the ARPA Computer Network,"
Courant Computer Symposium 3-Computer Networks, Courant
Institute, New York, ~ov. 1970.

163

10. Mimno, N. W., Cosell, B. P., Walden, D. C., Butterfield, S. C.,
Levin, J. B., "Terminal Access to the ARPA ~etwork-Experience
and Improvement," Proc. COMPCON '73, Seventh Annual IEEE
Computer Society International Conference.
11. Walden, D.C., TIP User's Guide, BBN Report No. 2183, Sept.
1972. Also available from the Network Information Center at Stanford Research Institute, Menlo Park, California, as Document NIC
#10916.
12. Postel, J. B., Official Initial Connection Protocol, Available from
Network Information Center as Document NIC #7101.
13. Postel, J. B., TELNET Protocol, ARPA Network Working Group
Request for Comments #358. Available from Network Information
Center as Document NIC #9348.
14. Bhushan, A. K., File Transfer Protocol, ARPA Network Working
Group Request for Comments #358. Available from Network Information Center as Document NIC #10596.
15. Crocker, S. D., Heafner, J. F., Metcalfe, R. M., Postel, J. B.,
"Function Oriented Protocols for the ARPA Computer Network,"
Proc. of AFIPS SJCC, 1972, Vol. 40, pp. 271-279.
16. McKenzie, A., Host/Host Protocol for the ARPA Network. Available from the Network Information Center As Document NIC
#8246.

Avoiding simulation in simulating computer
communication networks*
by R. VAN SL YKE, W. CHOU, and H. FRANK
Network Analysis Corporation
Glen Cove, ~ew York

to analysis. In the next three sections we give many illustrations drawn from practice of these ideas.

INTRODUCTION
Computer communication networks are complex systems
often involving human operators, terminals, modems,
multiplexers, concentrators, communication channels as
well as the computers. Events occur at an extraordinary
range of rates. Computer operations take place in microseconds, modem and channel operations take place on the
order of milliseconds, while human interaction is on a
scale of seconds or minutes, and the mean time between
failures of the various equipments may be on the order of
days, weeks, or months. Moreover, many systems are
being designed and built today which involve thousands
of terminals, communication links, and other devices
working simultaneously and often asynchronously.
Thus, in addition to the ordinary difficulties of simulation, the particular nature of computer communication
networks gives rise to special problems. Blind brute force
simulations of systems of this degree of complexity
usually result in large, unwieldy, and unverifiable simulation programs only understood by the creator (if by him)
and/ or statistically insignificant estimates due to unacceptable computational time per sample.
In order to obtain useable results careful attention
must be paid to determining the key features of the system to be considered before the simulation is designed
and approximating, ignoring or otherwise disposing of the
unimportant aspects. In this paper, we discuss three
approaches we have found useful in doing this. While
these ideas may seem obvious especially in retrospect, our
experience has been that they have often been overlooked.
The first technique takes advantage of situations where
the significant events occur infrequently. A common
example is in studies involving infrequent data errors or
equipment failures. The second idea is the converse of the
first and arises from simulations in which the significant
events occur most of the time and the rare events are of
less importance. The final idea is to make as much use as
possible of analytic techniques by hybrid simulations
reserving simulation for only those aspects not amenable

IMPORTANT RARE EVENTS
In a computer communication environment there coexist various events occurring at widely varying rates.
Often the activities of interest are events which occur
rarely or are the result of composite events consisting of a
relatively infrequent sequence of events. This suggests the
possibility of ignoring or grossly simplifying the representation of interim insignificant events. For this the simulator has one big advantage over the observer of a real system in that he can "predict" the future. In a real operational environment there is no way to predict exactly the
next occurrence of a randomly occurring event; in a simulated environment often such an event can be predicted
since the appropriate random numbers can all be generated in advance of any calculation (if their distribution is
not affected by generating the next random number).
Once the future occurrence time is known, the simulated
clock can be "advanced" to this time. The intervening
activities can either be ignored or handled analytically.
Extending this idea further the clock in the usual sense
can be dispensed with and time can be measured by the
occurrence of the interesting events much as in renewal
theory.

Example J-Response time simulation of terminalconcentrator complexes
In performing response time simulations for terminals
connected by a multidrop polled line connected to a concentrator or central computer one can often save large
amounts of computer time by avoiding detailed simulation of the polling cycle in periods of no traffic. Unless the
traffic load is very heavy, large time intervals (relative to
the time required for polling) between two successive
messages will occur rather frequently. In a real transmission system, the concentrator just polls terminals during
this period; if the simulation does the same, large

* This work was supported bv the Advanced Research Projects Agency
of the Department of Defense under Contract No. DAHC 15-73-C-0135.

166

National Computer Conference, 1973

amounts of computer time may be wasted. In a simulation program, after one message is transmitted, the time
the next message is ready to be transmitted can be predicted.
Therefore, the program may advance the clock to the
time when the next message is ready and determine
which terminal should be polled at that time (ignoring the
polling that goes on in the interim).
For each terminal v. hich is not waiting for a reply
message from the concentrator, the program can predict
the time when it has an inbound message to send to the
concentrator by generating as the inter-message time at
the terminal, a random number based on input information. For the concentrator, the program can predict in the
same way when it has a reply message to deliver. Among
these messages the time the first message is ready to send
is determined. The time elements involved in polling one
terminal is usually deterministic and known. Therefore, if
Tl is the time at the end of the current complete message
transaction, and T2 is the time when the next message
begins to wait for transmission, the terminal being polled
at T2 can be determined. Let this terminal be ID. The
concentrator did not start to poll ID at exactly T2 but
started at some earlier time Ta. In the simulation program, the clock can be advanced to Ta and no activities
between Tl and T2 need be simulated. ID is polled at Ta
and the simulation is resumed and continues until the
transaction for the next message is completed.
INSIGNIFICANT RARE EVENTS
In contrast to the situation in the previous section
where rare events were of critical importance, often activities resulting from rare events are of little interest in the
simulation. These often numerous insignificant rare
events can lead to difficulties both in the coding of the
simulation and its execution. Firstly, an inordinate
amount of coding and debugging time can be spent in
representing all the various types of insignificant events.
On the other hand, in the operation of the system, the
rare events often can occur only when more significant
events of much higher frequency also occur. Thus, each
time such frequently occurring events are realized, one
must check for the occurrence of the rare events which
can grossly increase the computer time of the simulation.
To reduce these undesirable effects, one may either eliminate the insignificant rare events from the simulation
completely, or at least simplify the procedures relevant
to the insignificant events so as to reduce the coding
efforts and shorten running time.

Example 2-Detecting and recovering from transmission
errors a
In using a simulation program to predict terminal
response time on a polled multidrop line, the transmission
of all messages and their associated control sequence is
simulated. For each type of transmission, errors may
appear in a variety of different forms, such as no ac-

knowledgment to a message transmission, unrecognized
message, the loss of one or more crucial characters, and
parity errors. For each of them, there may be a different
way to react and a different procedure for recovery. In a
typical system, there are over forty different combinations of errors and procedures for their treatment. Therefore, it is impractical and undesirable to incorporate
every one of the procedures into the program. Even if all
the error handling procedures were simulated in the
program, there is only limited effect on the response
time under normal conditions (i.e., the message transmission error rate and the terminal error rate should be
at least better than 10- a) but the program complexity
and the computer running time would both be increased
by a factor of 10 to 100. With respect to response time,
the errors can be easily handled in the program. Whatever the form of error, it must stem from one of the
following three sources: a line error during the transmission of the original message; an error caused by a
malfunctioning terminal; or a line error during the
transmission of an acknowledgment. The error prolongs
the response time by introducing the extra delay caused
by either the retransmission of the message and its
associated supervisory sequences or by a time-out. If the
timer is expired and the expected reply or character has
not been detected by the concentrator, action is taken to
recover from the error. This action may be a retransmission, a request for retransmission, or a termination
sequence. The time-out is always longer than the total
transmission time of the message and the associated
supervisory sequences. Rather than considering the
exact form of an error and its associated action, whenever the simulated transmission system detects an
error, a delay time equal to the time-out is added to the
response time.
With these simplifications introduced into the simulation program, the error handling procedures still require a
large percentage of overall computer time. When a leased
line is initially installed, the errors are very high mainly
due to the maladjustment of the hardware. However,
when all the bugs are out, the error rate has a very limited effect on the response time. Therefore, for a slight
sacrifice in accuracy the program may be run neglecting
errors to save computer time.

Example 3-Network reliability in the design and
expansion of the ARPA computer network (SJCC;
1970), (SJCC; 1972)
It was desired to examine the effect on network performance of communication processor and link outages. 10 . 11 The initial design was based on the deterministic
reliability requirement that there exist two node disjoint
communication paths between every pair of communication nodes (called Interface Message Processors, IMPs) in
the net. A consequence of this is that in order for the
network to become disconnected at least two of its elements, communication links or IMPs must fail. Since the

Avoiding Simulation in Simulating Computer Communication

IMPs and communication lines are relatively reliable
(availability on the order of .98) disconnectiom are quite
rare so a simulation model appropriate for the analysis of
the communication functions of the network would have
to run an enormously long time before a single failure
could be expected, let alone two failures. To illustrate the
ideas involved, let us consider the simplified problem of
determining the fraction of the time, h(p), the network is
disconnected given that links are inoperable a fraction p
of the time. (We assume for purposes of illustration that
IMPs don't fail. Depicted in Figure 1 is a 23 IMP, 28 link
version of the ARPA network.) An obvious method of
determining h(p) would be to generate a random number
for each link i of the network; if the number ri is less than
p the link is removed, otherwise it is left in. After this is
done for each link the connectivity of the remaining
})etwork is determined. Tbis is done many tim.es and the
fraction of the times that the resulting network is disconnected provides an estimate of h(p). Unfortunately, a
good part of the time ri>p for each i, occasionally ri~p
would hold for one i, and only rarely would ri~p for two or
more i; thus, many random numbers would be generated
to very little purpose. An effective way to sort out the significant samples is by using a Moore-Shannon expansion
of h(p). We have
m

h(p)=L C(k)pk(l-p)m-k

where m is the number of links and C(k) is the number
of distinct disconnected subnetworks obtained from the
original network by deleting exactly k links. Clearly,

O~C(k)~(;).

Thus we have partitioned the set of pos-

sible events into those in which 0 links failed, 1 link failed
and so on. In practice, it turns out that only a few of
these classes of events are significant, the values of C(k)
for the remaining classes are trivially obtained. Thus
it takes at least n - 1 links to connect a network with n
nodes so that C(k)=(;) for k=m-n, " ' , m. Similarly, C(O)=C(l)=O for the ARPA network because at
least 2 links must be removed before the network becomes disconnected. For the network depicted in Figure
1 where m = 28, n = 23 the only remaining terms which
are not immediately available are C(2), C(3), C(4), C(5),
and C(6) (See Table 1). C(2) and C(3) can be obtained
rather quickly by enumeration and the number of subtrees is obtainable for formula giving C(6), thus leav-

Figure I-Network for reliability analysis

~etworks

167

TABLE I-Exactly Known C(k) for 23 ~ode 28 Link ARPA Net
Number
of links
Operative

Number
of links
Failed

Num.ber of
Nets

Number of
Failed Nets

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

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

1
28
378
3276
20475
98280
376740
1184040
3108105
6906900
13123110
21474180
30421755
37442160
40116600
37442160
30421755
21474180
13123110
6906900
3108105
1184040
376740
98280
20475
3276
378
28
1

1
28
378
3276
20475
98280
376740
1184040
3108105
6906900
13123110
21474180
30421755
37442160
40116600
37442160
30421755
21474180
13123110
6906900
3108105
1184040
349618

13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
Notes: a:
b:
c:
d:

Method of
Determination
a

a
b

?
827
30
0
0

c
c
d
d

not enough links to connect 23 nodes.
number of trees calculated by formula.
enumerated.
less failed links than minimum cutset.

ing only C(4) and C(5) undetermined. These can be obtained by sampling; in general, by stratified sampling.
Thus we have not only been able to dispose of frequently occurring but unimportant events corresponding
to C(O), and C(l) but also to the rare and unimportant
events corresponding to C(7) through C(28).
HYBRID SIMULATIONS
Hybrid simulations refer to models which involve both
analytic techniques and simulation techniques. Since
analytic techniques are often more accurate and faster
than simulation, it is usually worth the effort to model as
much of the system as is possible analytically.
A complete computer communication system is in
general a composite system of many complicated subsystems, involving the interaction of a variety of computer
subsystems, terminal subsystems and functiona lly independent transmission subsystems. Many of these systems
are complicated and not well defined. For example, there
is no simple macroscopic characterization of the hardware
and software in a computer system or of how the hard-

168

National Computer Conference, 1973

ware and software interact with each other while dealing
with message traffic. It is therefore practically speaking
impossible to simulate a whole ~ystem without using some
analytic representations or employing some approximations. In place of simulation, the functioning of a subsystem can often be represented by an empirical model.
In deriving analytic models, however, simplification is
always necessary to make formulation manageable. For
example, message flow is often assumed to follow a Poisson pattern, and the message length distribution is sometimes approximated by an exponential distribution.
Analytic approaches can give quite acceptable results, if
the problem is properly modeled.
Example 4- Throughput analysis of distributed networks
In the topological design of distributed computer networks such as the ARPA network a rapid method for
analyzing the throughput capacity of a design under consideration is essential. Analyzing the traffic capacity in
detail is a formidable task, involving modeling the traffic
statistics, queuing at the IMPs, the routing doctrine, error
control procedures, and the like for 30 or 40 IMPs and a
comparable number of communication links. In order to
examine routing methods, Teitelman and Kahn9 developed a detailed simulation model with realistic traffic
routing and metering strategy capable of simulating small
versions of the ARPA Network. Since, in the design of the
topology, traffic routing is performed for hundreds of
possible configurations, such a simulation is impractical
so that a deterministic method of traffic analysis was
developed! requiring orders of magnitude less in computing times and thus allowing its repeated use. The two
models were developed independently. Based on a 10
IMP version of the ARPA Network shown in Figure 2,
average node-to-node delay time is plotted versus network
traffic volume in Figure 3. The curve is from the deterministic analytic model while the x's are the results of
simulation. The analytic results are more conservative
than the simulation results due to the simplification
introduced in the analytic model but the results are strikingly close. 6
The topological design is chosen with respect to some
predicted traffic distribution from the computers in the
network. Since such predictions are highly arbitrary, it is

Figure

2--~etwork

for throughput analysis

Figure 3-Throughput for network shown in Figure 2

necessary to determine how robust the design is with
respect to errors in the prediction of traffic. This was
done by choosing the average traffic levels at each computer randomly4 and using the analytic throughput analyzer to evaluate the network for varying input traffic
patterns. Thus, the availability of a quick throughput
analyzer allowed a more macroscopic simulation than
would have been computationally feasible if the throughput would have had to be calculated by simulation.
Example 5- Time spent at a concentrator 3
In the study of a general centralized computer communication network, one of the most difficult tasks is to
estimate accurately the time span between an inbound
message's arrival at the concentrator and the time the
reply is ready for transmission back to the terminal which
generated the inbound message.
The system we model for this example has several
concentrators and one central computer. Several multidrop lines, called regional lines, are connected to a concentrator, called a regional concentrator terminal (RCT).
Each RCT is connected to the central computer system
(CPS) via a high speed trunk line. After an inbound
message reaches the RCT it undergoes the following processes before the reply is transmitted back to the terminal:
(1) waiting for processing by the RCT, (2) processing by
the RCT, (3) waiting for access to the inbound trunk
(from RCT to CPS), (4) transmitting on the inbound
trunk, (5) waiting for processing by the CPS, (6) CPS
processing the inbound message to obtain the reply, (7)
reply waiting for access to the outbound trunk, (8) transmitting on the outbound trunk, (9) waiting for RCT to
process, (10) processing by the RCT, (11) waiting for
access to the regional line.

Avoiding Simulation in Simulating Computer Communication Networks

In our application, the RCT is under-utilized while the
CPS is highly utilized. Items (1), (2), (9) and (10) are
times relevant to the RCT and are negligibly small. Items
(4) and (8) are transmission times and can be obtained by
dividing message length by the line speed. The network
control procedure in our model does not allow a second
message to be delivered if the reply to the first has not
been returned. Therefore, there is no waiting for the reply
to access the regional line, and item (11) is zero. A combination of an analytic model and an analytic function is
used to obtain item (3), as shown below. An empirical
distribution is used for the combination of items (5) and
(6). An analytic function is used for determining item (7).
When an inbound message arrives at the RCT, it is
processed and queued at the output buffer for transmission to the CPS. The waiting time for access to the
inbound trunk line from the RCT to the CPS depends on
the traffic load of other regional lines connected to the
same RCT. To determine how long the message must
wait, the number of regional lines having a message waiting at the RCT for transmission to the CPS must be
determined. We assume that the average transaction rate
(which is the sum of the transaction rates of all terminals
connected to the same RCT) on the trunk connecting the
RCT to the CPS is known and that the message arrivals
to the trunk have a Poisson distribution and their length
has an exponential distribution. Then, the probability of
N or more messages is ps where P is the trunk utilization
factor, i.e., the ratio of average total traffic on the
inbound trunk to the trunk speed. A random number with
this distribution can be generated from one uniformly
distributed random number by inverting the cumulative
distribution function.
These messages include those waiting at terminals and
those at the RCT. A random number for each of these
inbound messages is generated to determine which
regional line the message is from. The number of regional
lines having inbound messages in waiting is thus determined. The network flow control procedure in our model
allows no more than one inbound message from each of
these regional lines at the RCT. Therefore, the number of
non-empty buffers is no more than the number of lines
having inbound messages in waiting. Conservatively, the
former number is set to be equal to the latter. The waiting for access to the trunk is then equal to the number so
obtained multiplied by the time required to transmit one
average inbound message from the RCT to the CPS.
The time interval between the time at the end of the
transmission of an inbound message to the CPS and the
time the reply has returned to the RCT, depends on the
CPS occupancy and the trunk utilization. The CPS occupancy is a direct consequence of the transaction rate of
the whole system. The trunk utilization is a direct result
of the transaction rate input from all the regional lines
connected to the ReT. In our model the time waiting for
processing at the CPS and the processing time for each
message is given as an empirical distribution. With the

169

help of a random number generator, the time spent at
CPS can be determined. The time a reply or an outbound
message spends in waiting for the trunk is conservatively
estimated by using the following analytic formula
Probability (waiting time>t) =Pe·

(l-Plt

A~·:-;

where p is the trunk utilization factor and A VS is the
average time required to transmit an outbound message. s
CONCLUSION
Computer communication networks can be quite large
and immensely complex with events occurring on a vast
time scale. Rarely can all aspects of such a system be
simulated at once for any but the most trivially small and
simple systems. Therefore, simulations must be designed
for relatively restricted purposes and careful attention
must be paid to ways and means of simplifying and ignoring factors not directly pertinent to the purposes. Here we
have suggested three ways to avoid unnecessary simulation: (1) by not simulating in detail insignificant events
which occur at a much higher rate than the significant
ones, (2) by ignoring rare events of little practical significance and (3) by using hybrid simulations with extensive
use of analytic modeling where applicable. A number of
examples drawn from practice illustrate the application
of these ideas to computer communication systems.
REFERENCES
1. Chou, W., Frank, H., "Routing Strategies for Computer Network
Design," Proc. of the Symposium on Computer-Communications
Networks and Teletraffic, Polytechnic Institute of Brooklyn, 1972.
2. Frank, H., Chou, W., "Routing in Computer Networks," Networks,
1. No.2 pp. 99-112, 1971.
3. Frank H., Chou W., "Response Time/Capacity Analysis of a
Computer-Communications Network," Infotech State of the Art
Reports: Network Systems and Software, Infotech, Maidenhead,
Berkshire, England, 1973.
4. Frank, H., Chou, W., "Properties of the ARPA Computer Network," to be published, 1973.
5. Frank, H., Chou, W., Frisch, I. T., "Topological Considerations in
the Design of the ARPA Computer Network," &lCC Conf Rec. 36,
pp. 581-587 (1970).
6. Frank H., Kahn, R., Kleinrock, L., "Computer Communication
Network Design-Experience with Theory and Practice," Proceedings of the Spring Joint Computer Cont., AFIPS Press, 1972.
7. Kershenbaum, A., Van S!yke, R. M., "Recursive Analysis of
Network Reliability," Networks, Jan. 1973.
8. Saaty, T. L., Elements of Queueing Theory, McGraw-Hill, New
York 1961.
9. Teitelman, W., Kahn, R. E., "A Network Simulation and Display
Program," Third Princeton Conference on Information Sciences
and Systems, 1961.
lO. Van Slyke, R. M., Frank, H., "Network Reliability Analysis-I"
Networks, 1, No.3, 1972.
11. Van Slyke, R M., Frank, R., "Reliability in Computer-Communications Networks," Proc. of 1971 ACM Winter Simulation Conference.

An implementation of a data management system on
an associative processor
by RICHARD MOULDER
Goodyear Aerospace Corporation
Akron, Ohio

der of this paper will describe the hardware configuration
of the- author's facility, the data stor-age-scheme-,--the
search technique, the user oriented data definition and
manipulation languages, and some of the benefits and
problems encountered in utilizing an Associative Processor for DBMS.

INTRODUCTION
Recent years have witnessed a widespread and intensive
effort to develop systems to store, maintain, and rapidly
access data bases of remarkably varied size and type.
Such systems are variously referred to as Data Base
Management Systems (DBMS), Information Retrieval
Systems, Management Information Systems and other
similar titles. To a large extent the burden of developing
such systems has fallen on the computer industry. The
problem of providing devices on which data bases can be
stored has been reasonably well solved by disc and drum
systems developed for the purpose and commercially
available at the present time. The dual problem of providing both rapid query and easy update procedures has
proved to be more vexing.
In what might be called the conventional approach to
DBMS development, sequential processors are employed
and large, complex software systems developed to implement requisite data processing functions. The results are
often disappointing.
A promising new approach has been provided by the
appearance of the Associative Processor (AP). This new
computer resource provides a true hardware realization of
content addressability, unprecedented I/O capability,
and seems ideally suited to data processing operations
encountered in data management systems. Many papers
have been written about the use of associative processors
in information retrieval and in particular about their
ability to handle data management problems. l To the best
of the author's knowledge no actual system has been previously implemented on an associative processor.
This paper will detail the author's experience to date in
implementing a data management system on an associative processor. It should be noted that the data management system to be described in the following pages is not
intended as a marketable software package. It is research
oriented, its design and development being motivated by
the desire to demonstrate the applicability of associative
processing in data management and to develop a versatile, economical data base management system concept
and methodology exploiting the potential of an associative
processor and a special head per track disc. The remain-

HARDWARE CONFIGURATION
This section will describe the computer facility
employed by the author and available to Goodyear Aerospace Corporation customers. The STARAN* Evaluation
and Training Facility (SETF) is a spacious, modern, well
equipped facility organized around a four-array
STARAN computer. Of particular significance to DBMS
efforts is the mating of STARAN to a parallel head per
track disc (PHD). The disc is connected for parallel I/O
through STARAN's Custom Input/Output Unit (ClOU).
Of the 72 parallel channels available on the disc, 64 are
tied to STARAN. The switching capability of the CIOU
allows time sharing of the 64 disc channels within and
between the STARAN arrays. (The SETF STARAN is a
4 array machine, each array containing 256 words of 256
bits each.) The switching provision allows simulations of
AP /PHD systems in which the number of PHD channels
are selectable in multiples of 64 up to 1024 total parallel
channels.
In order to provide for rather general information
handling applications and demonstrations, the STARAN
is integrated, via hardware and software, with an XDS
Sigma 5 general purpose computer, which in turn is integrated with an EAI 7800 analog computer. Both the
STARAN and the Sigma 5 are connected to a full complement of peripherals. The Sigma 5 peripherals include a
sophisticated, high-speed graphics display unit well
suited for real time, hands-on exercising of the AP / PHD
DBMS. A sketch of the SETF is given in Figure l.
The Custom Input/Output Unit (CIOU) is composed of
two basic sections. One section provides the communication between the Sigma 5 and the AP. This communication is accomplished by the Direct Memory Access capa* TM. Goodyear Aerospace Corporation, Akron, Ohio 44315

171

172

National Computer Conference, 1973

STAr-AN

5-1000

LINE[
PRINTER

Figure l-STARAN evaluation and training facility

bility of the Sigma 5 computer. The second section of the
CIOU is composed of the Parallel Input/ Output Unit
(PIOU). This unit interfaces the AP with the PHD. As
previously mentioned the PHD is composed of 72 tracks
of which 64 tracks are tied to STARAN. The disc is
composed of one surface which is sub-divided into 384
sectors consisting of 64 tracks, each track having a bit
capacity of 256 bits per sector. The time per revolution
for the disc is approximately 39 msec. It should be noted
that Goodyear Aerospace Corporation did not manufacture this disc and that there are several manufacturers
providing parallel head per track devices. Given this
hardware configuration, a data storage scheme was developed.
DATA STORAGE SCHEME
A hierarchical data structure was chosen for our initial
effort since it is probably the structure most widely used
for defining a data base. In order to utilize the parallel
search capabilities of the AP and the parallel communication ability of the AP /PHD system, it was decided to
reduce the hierarchical structure to a single level data
base. The method used was similar to the one suggested
by DeFiore, Stillman, and Berra. I In this method each
level of the hierarchy is considered a unique record type.
Associated with each record type are level codes indicating the parentage of the particular record. The association
of level numbers with record type is purely logical and
does not imply or require a correspondingly structured
data storage scheme.
It should be noted that each record contains a level
code for each of the preceding levels in the hierarchical
structure. The different records are stored on the PHD in
a random fashion. No tables or inverted files are introduced. Only the basic data file is stored on the disc. Since
we have an unordered and unstructured data base, it is
necessary to search the entire data base in order to
respond to a query. The searching of the entire data base
presents no significant time delays because of the parallel
nature of both the AP and the PHD. This data storage
scheme was selected because it provides an easy and efficient means of updating the dHtH hHse dl1P to the lHck of

multiplicity of the data. It should be emphasized that this
scheme is not necessarily the best approach for all data
bases. It appears to be well suited for small to moderately
sized data bases having hierarchical structure with few
levels. Data bases which are to be queried across a wide
spectrum of data elements are especially well suited for
this type of organization since all data elements can participate in a search with no increase in storage for
inverted lists or other indexing schemes. Since there is no
ordering of the data base and no multiplicity of data
values, updating can be accomplished very rapidly with a
minimum amount of software.
SAMPLE DATA BASE
The data base selected for the AP jPHD DBMS development program is a subset of a larger data base used by
the SACCS/DMS and contains approximately 400.000
characters. It is a four-level hierarchical structure composed of command, unit, sortie, and option records.
A tree diagram of the selected data base is shown in
Figure 2.
Figure 3 gives an example of an option record.
Definitions for the option record are as follows:
(1) Record Type-indicates the type of record by
means of the level number; also indicates the word
number of this record. If a logical record requires
more than one array word, these words will be
stored consecutively with each word being given a
word number.
(2) Level Codes-these codes refer to the ancestry of
the particular record. They consist of an ordinal
number.
(3) Data Item Names-These are elements or fields of
one particular record type. Each field has a value.
There may not be any two or more fields with the
same name.
(4) Working Area-This is that portion of an array
word not being used by the data record.

Figure ?-Tree rlil'lgmm of ~E'le('teo oMa hasp

Implementation of a Data Management System

RECORD

LEVEL

TYPE

CODE
1

CODE
2

LEVEL
CODE
3

LEVEl

OPTION
NUMBER

CODE
4

C
I:U,PON
TYPE

S
L

U C
rl 0

WORKING

T 0
R E
Y

"" I
I

173

array, a bit map of searched sectors is kept. This bit map
will allow minimization of rotational delay.
DATA BASE MANAGEMENT SYSTEM

' - - - - " ' - ' - '- - - - - - - - ' - - -_ _ _ _ _~I'----I

LEVEL CODES

RECORD

RECORD ATTRIBUTE

WORKI~IG

AREA

Figure 3-0ption record layout

SEARCH TECHNIQUE
In order to search the entire data base, the data will be
arranged in sectors consisting of 64 tracks. Each track
will be composed of 256 bits. The STARAN Associative
Processor employs 256 bit words; each associative array
being composed of 256 such words. A PHD sector will
therefore contain one fourth of an array load. In our
current system we are utilizing the first 64 words of the
first array for data storage. With the addition of more
tracks on the PHD we could utilize a greater portion of an
array with no additional execution time due to the parallel nature of our input. (The AP can of course time share
the 64 tracks currently available in order to simulate
larger PHD's.) With this technique it is possible to read
in a sector, perform the required search, then read in
another sector, perform a search, continuing in this fashion until the entire data base is searched.
For our current PHD, the time for a sector to pass
under the read/ write heads is approximately 100 J,Lsec.
Preliminary studies have shown that complex or multisearches can be performed in this time span. Utilizing
this fact it should be possible to read every other sector on
one pass of our disc. With two passes the entire data base
will have been searched. This assumes that the entire
data base is resident on one surface. Additional surfaces
would increase this time by a factor equal to the number
of surfaces.
Figure 4 shows an associative processor array and the
every other sector scheme employed when searching the
PHD. It should be emphasized that due to the hierarchical structure of the data base more than one data base
search will be required to satisfy a user's request and that
the time to search and output from the associative array
is variable. In order to minimize the time to search the
disc when a 100 J,Lsec is not sufficient time to process an
Parallel Input/Output

.--_ _ _ _

-,vru~

ASSOC 1'\ T!VE
ARRAY

100 f../Sec to perform complex searches

Data definition module
This module defines a file definition table. This table
relates the data structure as the user views it, to a data
storage scheme needed by the software routines. Every
data base will have only one file definition table. This
table will contain the following information.
(1) File name-the name of the particular data base
(2) Record name-the name of each logical record type
(3) Data items-the name of each attribute in a given
logical record type
(4) Synonym name-an abbreviated record or attribute name
(5) Level number-a number indicating the level of the
record
(6) Continuation number-this number is associated
with each attribute and indicates which AP word of
a multi-word record contains this attribute
(7) Starting bit position-the bit position in an AP
word where a particular attribute starts
(8) Number of bits-the number of bits occupied by an
attribute in an AP word
(9) Conversion code-a code indicating the conversion
type: EBCDIC or binary
The language used to define the data definition table is
called the Data Description Language (DDL). The
DDL used in our system has been modeled after
IBM's Generalized Information System DDL.

255 Bits
Per Sector

P::.rallel Rl'a::!'Write
ElectrOnics

lr~
ui~

ASSOCIA rp.:r: FnCCESSCR

The DBMS software is composed of four modules: the
Data Definition, File Create, Interrogation and Update
modules. Since our DBMS is intended for research and
not a software product package, we have not incorporated
all the features that would be found in a generalized
DBMS. Our system will provide the means to create,
interrogate and update a data base. The following discussion will briefly describe each module.

File create module
Once the file definition table has been created, the file
create module is run. This module populates a storage
medium with the data values of a particular data base.

Interrogation module

D~SC

100 ,usee to read a sector

Figure 4-AP! PHD tie-in

This module is the primary means for interrogating the
data base. Since our DBMS is intended to demonstrate
the applicability of Associative Processors in DBMS, we

174

National Computer Conference, 1973

have developed a user oriented language. This Data
Manipulation Language (DML) is modeled after SDC's
TDMS system. It is conversational in nature and requires
no programming experience for its utilization. At present
there is only one option in the interrogation module
implemented in our DBMS. This option is the print
option.
The print option is used to query the data base. The
user is able to query the data base using any data item(s)
as his selection criteria. The form of a query follows:
Print Name(s) Where Conditional Expression(s)
• Name(s)-Any data item name or synonym
• Conditional Expression (CE)-Selection criteria for
searches
The form of the CE is:
Data Item Name Relational Operator Value
Relational Operators
EQ-Equal to
NE-Not equal to
LT - Less than
LE-Less than or equal to
GT -Greater than
GE-Greater than or equal to
Logical Operators (LO )-link conditional expressions
together:
CE Logical Operator CE Logical operators
• AND-Logical And
• OR-Inclusive Or
At present the output from a query will be in a fixed
format. It is anticipated that a formatting module will be
added to the system. An example of the print option and
its output are shown below.
Query
Print Unit Name, Sortie Number where
Option Number EQ 6 and Weapon Type NE Mark82
and Country Code EQ USA *
Output
Unit Name-303BW
Sortie Number-1876

Update module
This module performs all the updating of the data base.
There are four options available to the user. These are
change, delete, add, and move. These options are
described helow.

Change option
The change option performs all edits to the data base.
All records satisfying the change selection criteria are
updated. The form of the change option follows:
Change Name to Value Where Conditional Expression(s)
• N ame-Any data item name or synonym
• Value-Any valid data value associated with the
above name; this is the new value
• Conditional Expression-same as the print option .
An example of the change option follows:
Change Unit Name to 308BW Where
Unit Number EQ 1878 And Option Number GE 6*
It should be noted that all records that satisfy the unit
number and option number criteria will have their unit
names changed to 308BW.

Delete option
This option will delete all records that satisfy the conditional expression. All subordinate records associated with
the deleted records will also be deleted. The form and an
example of the delete option follows:
Delete Record Name Where Conditional Expression(s)
Record Name-any valid record name (e.g. command, unit, sortie, option)
Conditional Expression(s)-same as print option
Example:
Delete Sortie Where Sortie Number EQ 7781 *
In this example all the sortie records with sortie number equal 7781 will be deleted. In addition all option
records having a deleted sortie record as its parent will
also be deleted.

Add option
This option adds new records to the data base. Before a
new record -is added to the data base, a search will be initiated to determine if this record already exists. If the
record exists a message will be printed on the graphic
display unit and the add operation will not occur. The
form of the add option follows.
Add Record Name to Descriptor Where Description of
Data
• Record Name-any valid record name (i.e. command, unit, sortie, option)
• Descriptor-special form of the conditional expres!';ion in whirh 'EQ' is the only allowed relational

Implementation of a Data Management System

operator; the descriptor describes the parentage of
the record being added to the data base.
• Description of Data-This item is used to define the
data base; the form of this item is the same as a
conditional expression with the requirement that
'EQ' is the only allowed relational operator.
An example of the add option follows:
Add Unit To Name EQ 8AF Where
Unit Name EQ 302BW And Unit Number EQ 1682
And Aircraft Possessed EQ 85*
In this example the command record for the 8AF must
be in the data base before this unit record can be added
to the data base. In the case of a command record being
added to the data base, the descriptor field is omitted
from the above form.

Move option
This option allows the user to restructure the data base.
The move option will change the level codes of the
affected records. The affected records are those satisfying
the conditional expression, in the move command, as well
as all subordinate records. The move option has the following form:
Move Record Name to Descriptor Where Conditional
Expression
• Record Name-any record name
• Descriptor-this item describes the new parentage of
the record that is to be moved; the form is the same
as the add option
• Conditional Expression-same as the print option
An example of the move option follows:
Move Sortie to Name EQ 12AF and Unit Number
EQ 2201
Where Sortie Number EQ 41 and Option Number
GT 12*
In this example all sortie records which have a sortie
number equal to 41 and an option record with option
number greater than 12 will have its parentage (i.e., level
codes) changed to the 12AF and 2201 unit. Also included
in this restructuring will be all option records which have
the changed sortie record as a parent.

Status
Currently the Data Definition and the Create Module
are operational and our sample data base has been created and stored on the PHD. A simplified version of the
Interrogation Module is running and performing queries
using the AP and PHD. In this version the translator for
the query is executed on the Sigma 5 and a task list is

175

constructed. This task list is transmitted to the AP where
the desired searches are performed and the output of the
searches are transmitted to the Sigma 5 via Direct Memory Access. In the simplified version of the Interrogation Module no optimation of the software has been
attempted. At the moment the number of disc sectors
skipped between reads during a search of the data base is
governed by the size of the task list and is not modified
by the actual time available to process the task list. No
sector bit map has been implemented. It is anticipated
that future versions of the Interrogation Module will be
optimized and a bit map will be introduced into the system.
The change and delete options of the Update Module
are also operational. The search routines currently
employed in the Update Module are the same routines
found in the Interrogation Module. With a continuing
effort, the attainment of our design goals and the completion of our research data base management system should
be realized. Further progress reports will be issued as our
development efforts are continued.
CONCLUSION
Preliminary results indicate that an AP working in conjunction with a sequential computer affords the best configuration. With this marriage comes the best of two
computer worlds, each performing what it is best capable
of doing. With the ability to rapidly search the entire data
base we have provided the user extreme flexibility in
constructuring his search criteria. We have provided this
with no additional storage for inverted files and no sacrifice in update time. Associative processing brings to data
base management designers and users the ability to query
and update data bases in a fast and efficient manner with
a minimum amount of software.
With proper programming of AP's, multi-queries can
be processed during a single array load, thus greatly
increasing the throughput of the system. The future holds
great promise for associative processors and we are striving to lead the way. Many questions must be answered
such as:
(1) how to use conventional storage devices in combination with PHD's,
(2) what hardware requirements must be provided for
a minimum configured AP;
(3) the role of the sequential and AP computers in a
hybrid configuration, and
(4) how much software is required to provide a data
management capability on AP's.
In the near future these problems and others will have
answers. Subsequent reports will elaborate on the performance of the system. Our work to date has sh~wn
that associative processors truly provide an attractive
alternative to conventional approaches to data retrieval
and manipulation.

176

National Computer Conference, 1973

ACKNOWLEDGMENTS
The help of P. A. Gilmore, E. Lacy, C. Bruno, J. Ernst
and others at Goodyear Aerospace is gratefully acknowledged.

REFERENCES
1. DeFiore, C. R., Stillman, N. J., Berra, P. B., "Associative Tech-

niques in the Solution of Data Management Problems" Proceedings of ACM pp. 28-36, 1971.

Aircraft conflict detection in an associative processor
by H. R. DOWNS
Systems Control, Inc.
Palo Alto, California

PROBLEM

If MD is less than a specified criterion the aircraft are
assumed to be in danger of conflict.
More complicated algorithms are also under study.
These involve altitude;turning rates, etc.

DESCRIPTIO~

A major problem in Air Traffic Control (ATC) is
detecting when two aircraft are on a potential collision
course soon enough to take some corrective action. Many
algorithms are being developed which may lead to automating the process of conflict detection. However, these
algorithms typically require large amounts of computing
resource if they are to be performed in real-time. This
paper describes some techniques which may be used by
an associative processor to perform the conflict detection
operation.

Associative processors

An associative processor is a processor which may
access its memory by 'content' rather than by address.
That is, a 'key' register containing some specific set of
bits is compared with a field in each word of memory and
when a match occurs, the memory word is 'accessed' (or
flagged for later use). This type of memory is typically
implemented by having some logic in each memory word
which performs a bit-serial comparison of the 'key' with
the selected field. 1
Many associative processors have enough logic associated with each memory word to perform inequality
compares (greater or less than) and some arithmetic
operations. In others, memory words may be turned on or
off; that is, some words may not be active during a particular comparison. This associative processor may be
viewed as a parallel-array computer where each word of
memory is a processing element with its own memory and
the 'key register' is contained in a control unit which
decodes instructions and passes them to the processing
elements. Some examples of this type of computer are the
Sander's OMEN,2 the Goodyear Aerospace STARAN,3
and the Texas Instruments SIMDA.
Some additional capabilities which these computers
may have are: (1) the ability to compare operands with a
different key in each processing element (both compare
operands are stored in one 'word') and (2) some form of
direct communication between processing elements.
Typically, each processing element can simultaneously
pass data to its nearest neighbor. More complex permutations of data between processing elements are also possible.
These processors are often referred to as associative
array processors, though parallel-array is perhaps more
descriptive.

Conflict detection

In a terminal ATC environment, each aircraft in the
area will be tracked by a computer which contains a state
estimate (position and velocity) for each aircraft within
the 'field of view' of the radar or beacon. The information
available on each aircraft may vary (e.g., elevation may
be available for beacon-equipped aircraft) but some form
of estimate will be kept for each aircraft under consideration. The conflict detection algorithm typically considers
each pair of aircraft and uses their state estimates to
determine whether a conflict may occur. The algorithm
may perform one or more coarse screening processes to
restrict the set of pairs of aircraft considered to those
pairs where the aircraft are 'near' each other and then
perform a more precise computation to determine
whether a conflict is likely.
The algorithm is typically concerned with some rather
short interval of time in the future (about one minute)
and it must allow for various uncertainties such as the
state estimate uncertainty and the possible aircraft
maneuvers during this time interval.
As an example of the kind of algorithms being considered for detection of conflicts between a pair of aircraft. a
simple algorithm will be described. The relative distance
at the initial time, DR, is computed. Then, the scalar
quantity relative speed, SR, is computed for the initial
time. If T is the iook-ahead time, then the estimated miss
distance MD is

SOLUTIO~

APPROACHES

This section presents several ways to solve the conflict
detection problem with the use of an associative processor

177

178

National Computer Conference, 1973

and provides some estimate of the order of each
approach. (The order is a measure of how the computation time increases as the number of aircraft increases.)
Straightforward associative processing approach
The data for each aircraft under consideration can be
placed in a separate processing element of the associative
processor and each aircraft can be simultaneously compared with the remaining aircraft. This technique
requires each aircraft to be compared with all other aircraft.
If there are n aircraft under consideration there must
be at least n processing elements (or associative memory
words). The data on a single aircraft is placed in the key
register and compared with the appropriate field in each
processing element. Each compare operation in this algorithm is actually fairly complex, involving some arithmetic computations before the comparison can be made.
This approach compares every aircraft with every other
aircraft (actually twice) and appears to use the computing
resources of the associative array rather inefficiently. In
fact, the entire algorithm must be executed n times. Since
n comparisons are made each time the algorithm is executed, a total of n 2 comparisons are made. (There are n(n
-1) / 2 unique paris of aircraft to be considered.)
It is more efficient to consider the associative processor
for performing some sort of coarse screening procedure,
and for all pairs which the AP determines may conflict to
be passed to a sequential processor for a more detailed
check. This assumes that the sequential processor can
execute the complicated algorithm more quickly than a
single processing element of the AP and that the AP can
significantly reduce the number of pairs under consideration.
An efficient algorithm for a serial processor
One approach which has been suggested for solving this
problem is to divide the area under consideration into
boxes and to determine whether two aircraft are in the
same or neighboring boxes. If they are then that pair of
aircraft is checked more carefully for a possible conflict.
This process is an efficient method for decreasing the
number of pairs of aircraft to be checked in detail for a
possible conflict. These boxes help to 'sort out' the aircraft according to their positions in the sky.
The boxes can be described in a horizontal plane and
may have dimensions of 1 or 2 miles on a side. An aircraft
can be assigned to a box by determining a median position estimate for some time and choosing the box which
contains this estimate. If the aircraft turns or changes
velocity, then it may not arrive at the expected point at
the time indicated but it cannot be very far from this
point. For terminal area speeds and turning rates, an
aircraft will typically not be more than about one box
width away from the expected location.

To check for conflicts, it is necessary to check possible
conflicts in the same box and in boxes which are adjacent
or near to the given box. If all aircraft in each box are
compared with all other aircraft in this box and with all
aircraft in boxes to the north, east and northeast, then all
possible pairs are checked. By symmetry, it is not necessary to check boxes to the west, south, etc.
The exact size of the boxes and the number of boxes
checked for possible conflicts are determined by the aircraft speeds and measurement uncertainties. It is desirable to make them large enough so that only neighbors one
or two boxes away need to be checked and yet small
enough so that the number of aircraft per box is usually
one or zero.
Note, that this scheme does not check the altitude. If
aircraft densities increased sufficiently and the altitude
were generally available, then it might be desirable to
form 3 dimensional boxes, accounting for altitude.
Sort boxes on an associative processor
A similar operation can be performed on an associative
processor by assigning each box to a single processing
element. If the boxes are numbered consecutively in rows
and 'consecutive boxes are assigned to consecutive processing elements, then adjacent boxes can be compared by
translating the contents of all processing elements by an
appropriate amount. For a square area containing 32 X
32 (= 1024) boxes, the numbering scheme shown in Figure
1 will suffice.
In this numbering scheme, all aircraft in Box 1 are
compared with the aircraft in Box 2, Box 33 and Box 34.
Similarly, all aircraft in Box 2 are compared with the
aircraft in Box 3, Box 34, and Box 35. When these comparisons have been completed, all possible pairs within a
box and in neighboring boxes will be detected.
If only one aircraft were in each box, then each aircraft
data set would be stored in the appropriate processing
element and comparisons with neighboring boxes would
be carried out by transferring a copy of each data set
along the arrows shown in Figure 2 and comparing the
original data set with the copy. When these neighboring
boxes have been checked, then all possible conflicting
pairs have been discovered.

.
1-g93

1024

Figure I-Boxes in 32X32 surveillance area

Aircraft Conflict Detection in an Associative Processor

When there is more than one aircraft in a box, then
additional processing is required. The first aircraft which
belongs in a box is stored in the proper processing element
and a flag (bit) is set indicating this is its proper box. Any
additional aircraft are placed in any available processing
element. A pointer is set up linking all aircraft belonging
in a specific box. In an associative processor, all that is
necessary is to store the I.D. of the next aircraft in the
chain in a particular processing element. The contents of
various fields of a word and the links to the next word are
shown in Figure 3.
When the data is stored as indicated above, then every
aircraft in box i can be retrieved by starting with processing element i. If the I.D. in Field B is not zero, then the
next aircraft data set is located by performing an equality
test using Field B from processing element i in the key
register and comparing with Field A in all processing
elements.
When comparing the aircraft in one box with those in
another box, every aircraft in the first box must be com-

'~
L
L:'\r'\

-~~

neighbor on right
c:-'\

c"' c"'"'---r_association
_ _ _ _~

132 33134 I 35

·]

/'-7-/-'-::7,.-L--:;'~...-!--n-e-ig-h-bo-r-bel ow

---~~~--/

association

Associative Array Processor
Figure 2-Data transfer for comparison with neighboring boxes

pared with every aircraft in the other box. This is done by
making a copy of the state estimates for each aircraft pair
and placing each pair of state estimates in a single processing element. When the conflict detection algorithm is
executed, all the pairs are checked simultaneously. That
is, each processing element operates on a pair of state
estimates and determines, by a fairly complicated algorithm, whether the aircraft pair represented in this processing element may be in danger of colliding.
If the memory available in each processing element
pair is sufficient, then one pair can be stored in each
element. In this case, the array is used very efficiently
since many elements can execute the detailed conflict
detection algorithm simultaneously. If there are more
processing elements than pairs, then the detailed conflict
detection algorithm need only be executed once in order
to check all pairs for possible conflict.
If there are no processing elements available for storing
a potentially conflicting pair, then the algorithm is executed on the pairs obtained so far, non-conflicting pairs
are deleted and conflicting aircraft are flagged. The prucess then continues looking for more conflicting pairs.
The algorithm just described is similar to the one
described for sequential computers but takes advantage

proces S 'j n~!
clc,conl i"i

flag

;Field
/\

rA/C

Ale.

Field
B

~ ~~~t

~_L_s_tate estl"'::~j;j I\jt-

;i:,;:::i;j

spare

~_.D.~ ___ _

nI-1 :;~te estimatell :;~t 1.0.1
. ----------,

.____------

A/C
I
state estimate

spare

--~--------~

processing
el ement fk

179

Figure 3-Storage of A/C state estimates for A/C in Box #i

of the parallel and associative processing capabilities of
an associative array computer to speed up the execution
of the algorithm. If the associative processor has more
elements than there are boxes and than there are pairs to
check, then the algorithm requires essentially one pass.
A sliding correlation algorithm

Another approach to restricting the number of pairs of
aircraft is possible on an associative array processor. This
approach requires that the aircraft be arranged in order
of increasing (or decreasing) range in the processing elements. That is, the range from the radar to the aircraft in
processing element i is less than the range to the aircraft
in processing element i+ 1. A number of techniques are
available for performing this sort. They are discussed in
the next section.
The technique consists of copying the state estimates
and I.D.'s of each of the aircraft and simultaneously
passing them to the next adjacent processing element.
Each element checks the two aircraft stored there for a
possible conflict and flags each of them if a conflict
occurs. The copied state estimates are then passed to the
next processing element and another conflict check
occurs. The process continues until all aircraft pairs in a
given processing element are more than r nautical miles
apart in range (where r is the maximum separation of two
rrocess i ng
.... _.---

e]er~c'nt

llur1ber
initio'] st2te
estilirote

copied state
estinwte

Figure 4-Storage during the kth conflict comparison

180

National Computer Conference, 1973

aircraft state estimates when a conflict might conceivably
occur during the specified time interval). Since the aircraft are range ordered, there is no point in testing any
additional pairs. Also, due to the symmetry of the algorithm, it is not necessary to check the other way.
Ordering the state e.'dimates

In the algorithms described earlier, a certain ordering
of the aircraft state estimates in the processing elements
was required.
The ordering can be performed by checking the
arrangement of the data each time a track update is performed. Each aircraft which has moved to a new box has
its corresponding state estimate moved to the appropriate
processing element at this time. It is assumed that the
track update rate is sufficiently high so that state estimates need only move to neighboring boxes. This assumption improves the efficiency with which data is moved
since many state estimates can be moved simultaneously.
For instance, all objects which moved one box to the east
can be simultaneously transferred to their new box. Similarly, for objects moving in other directions, a single
transfer is necessary.
The second, third, etc., aircraft in a box must be handled separately. Also, when a box is already occupied,
then special handling is required to determine where the
new state estimates are stored. Since most boxes contain
only one or fewer aircraft, the amount of special handling
will be small.
The sorted list described in the previous section may
also be done by keeping the list stored and performing
minor iterations each time the state estimates are
updated. This process is quite straightforward.
A more interesting method is to perform a total sort of
the state estimates. This can be done fairly efficiently by
using a 'perfect shuffle' permutation of the processing
element data. The algorithm is described in Stone 4 and
requires log2 n steps (where n is the number of aircraft).
SUMMARY
Comparison of techniques

The algorithm in the section "Straightforward Associative Processing Approach" is quite inefficient and
requires n passes through the pairwise conflict detection
algorithm. This can be quite expensive if n is large and
the algorithm is complex.
The algorithm in the section "Sort Boxes on an Associative Processor" greatly reduces the number of executions
of the pairwise conflict detection algorithm at the expense
of some data management overhead. If the box sizes can

be chosen appropriately this is quite efficient. Some studies have shown that a few percent of the pairs need to be
checked. That is, the number of potentially conflicting
pairs after checking for box matching is p. n(n - 1) /2
where p is about .05. If a total of four boxes must be
checked for conflicts (nearest neighbor boxes only), then
the number of times the pairwise conflict detection algorithm must be executed is quite small. There are about
n 2 /40 potentially conflicting pairs and if the number of
processing elements is large enough, these can all be
checked at one time.
The algorithm described in the preceding section has
been estimated to check about 10 percent of the potentially conflicting pairs. Comparing with the section
"Straightforward Associative Processing Approach," this
requires one-tenth the time or about n/l0 pairwise conflict detection executions (plus the sort). This is more
than the sliding correlation algorithm previously discussed, but the data management is less and fewer processing elements are required. Depending on the execution
time of the pairwise conflict detection algorithm one of
these approaches could be chosen, the first one if the
pairwise algorithm is expensive and the second if the
pairwise algorithm is cheap.
Conclusions

This paper has presented some approaches to organizing the conflict detection algorithm for Air Traffic Control on an associative array processor. The relative efficiencies of these approaches were described and some of
the implementation problems were explored.
Other techniques of real-time data processing on a
parallel-array computer have been described in Reference 5. The problem described here illustrates the fact
that developing efficient algorithms for novel computer
architectures is difficult and that straightforward techniques are often not efficient, especially when compared
with the sophisticated techniques which have been developed for serial computers. The techniques described here
may also be applicable to other problems for associative
arrays.
REFERENCES
1. Stone, H., "A Logic-in-Memory Computer," IEEE Transactions on

Computers, January 1970.
2. Higbie, L., "The OMEN Computers: Associative Array Processors," Proceedings of COMPCON, 1972, page 287.
3. Rudolph, J. A., "A Production Implementation of an Associative
Array Processor-STARAN," 1972, FJCC Proceedings, page 229.
4. Stone, H., "Parallel Processing with the Perfect Shuffle," IEEE
Transactions on Computers, February 1971.
5. Downs, H. R., "Real-Time Algorithms and Data Management on
ILLIAC IV," Proceedings of COMPCON, 1972.

A data management system utilizing an associative
memory*
by CASPER R. DEFIORE**
Rome Air Development Center (ISIS)
Rome, New York

and
P. BRUCE BERRA
Syracuse University
Syracuse, New York

knowledge of its content. The information stored at
unknown locations can be retrieved on the basis of some
knowledge of its content by supplying the contents of any
portion of the word.
An associative memory contains a response store associated with every word which is at least one bit wide. Its
purpose is to hold the state of events in the memory. The
response store, provides an easy way of performing boolean operations such as logical A~D and OR between
searches. In the case of logical AND for example, in a
subsequent search only those words whose response store
were set would take part in the search. In addition boolean operations between fields of the same word can be
performed by a single search. The applicability of boolean operations is a most important requirement for a
data management system since the conditional search for
information in a data base requires their use.
The instruction capabilities of associative memories are
usually grouped into two categories: search instructions
and arithmetic functions. The search instructions allow
simultaneous comparison of any number of words in the
memory and upon any field within a word. A partial list
of search instructions include the following: equality,
inequality, maximum, minimum, greater than, greater
than or equaL less than, less than or equal. between limits, next higher, and next lower. All of these instructions
are extremely useful for data management applications.
For example, the extreme determination (maximum/
minimum) is useful in the ordered retrieval for report
generation. An associative memory can perform mass
arithmetic operations, such as adding a constant to specific fields in a file. The type of operations are as follows:
add, subtract, multiply, divide, increment field and decrement field.

I~TRODUCTION

There are a wide variety of data management systems in
existence.I-3.6.7.10-V; These systems vary from those that are
fairly general to those that are very specific in their performance characteristics. The former systems tend to
have a longer life cycle, while sacrificing some efficiency,
whereas the latter are more efficient but tend to become
obsolete when requirements are modified. 9
In addition, current data management systems have
generally been implemented on computers with random
access memories, that is, the data is stored at specified
locations and the processing is address oriented. In contrast, using associative or content addressable memories,
information stored at unknown locations is processed on
the basis of some knowledge of its content. Since much of
the processing of data management problems involve the
manipulation of data by content rather than physical
location, it appears that associative memories may be
useful for the solution of these problems.
In order to demonstrate the feasibility of utilizing a
hardware associative memory, a data management system called Information Systems For Associative Memories (IF AM) has been developed and implemented. After
presenting a brief description of associative memories, the
implementation and capabilities of IF AM are described.

DESCRIPTIO~

OF ASSOCIATIVE MEMORIES

Associative memories differ considerably from random
access memories. 16 Random access memories are address
oriented and information is stored at known memory
addresses. In associative memories, information stored at
unknown locations is retrieved on the basis of some

IFAM IMPLEMENTATION

* This research partially supported by RADC contract AF 30(602)70-C-0190, Large Scale Information Systems.
** Present Address, Headquarters, DCA. Code 950, NSB, Washington.
D.C.

IF AM is an on-line data management system allowing
users to perform data file establishment, maintenance,
181

182

National Computer Conference, 1973

retrieval and presentation operations. Using this system it
is easy for users to define a meaningful data base and
rapidly achieve operational capability. Discussed below
are the hardware and software aspects of IF AM.
Hardware

IF AM is implemented on an experimental model associative memory (AM) at Rome Air Development Center
(RADCl. The AM, developed by Goodyear, is a content
addressable or parallel search memory with no arithmetic
capability. It contains 2048 words where each word is 48
bits in length. The search capability consists of the 11
basic searches described previously, all performed word
parallel bit-serial. As an example of the timing, an exact
match search on 2048-48 bit words takes about 70 microseconds.
The AM operates in conjunction with the CDC 1604
Computer via the direct memory access channel as shown
in Figure 1. Information transfers between the AM and
the 1604 are performed one word at a time at about 12
microseconds per word.
The CDC 1604 computer is a second generation computer with 32000-48 bit words and a cycle time of 6.4
microseconds. It has various peripheral and input/ output
devices. one of which is a Bunker Ramo (BR-85) display
console. The display unit is capable of visually presenting
a full range of alphabetic, numerical or graphical data.
The console allows direct communication between the
operator and the computer. The display unit contains a
program keyboard, an alphanumeric keyboard, a control
keyboard, curser control. and a light gun. The IFAM user
performs his tasks on-line via the BR-85 display console.
Software

Both the operational programs and the data descriptions used in IF AM are written in JOVIAL, the Air Force
standard language for command and control.
The operational programs manipulate the data in the
AM and are utilized in the performance of retrieval and

update operations. These programs are written as
JOVIAL procedures with generalized input! output
parameters which operate on data in the AM. By changing the parameters, the same procedures can be used for
many different operations resulting in a more general and
flexible data management system.
The data descriptions are used to specify the format of
the data such as the name of a domain, its size, type,
value, the relation to which it belongs, etc. They are used
in conjunction with the operational programs to process
information within IFAM. The data descriptions specify
the data format to the operational program which then
performs the desired task. Providing an independence
between these two means the information and the information format can change without affecting the programs
that operate on the information and conversely.
In addition, the data and data descriptions are maintained separately from the data. This separation means
that multiple descriptions of the same data are permitted
and so the same data can be referred to in different ways.
This can be useful when referencing data for different
applications.
The next section describes the capabilities of IF AM
using a personnel data base as a test model.
IFAM CAPABILITIES
Test Model Description

As a test model for IF AM a data base has been implemented containing information about personnel. The data
structure for the test model, shown in Figure 2, is as follows:
PERSONNEL (NAME, SOCIAL SECURITY NUMBER, CATEGORY, GRADE, SERVICE DATE,
DEGREES)
DEGREES (DEGREE,DATE).
For this structure PERSONNEL is a relation that contains six domains and DEGREES is a relation that contains two domains. The occurrence of the domain degrees

~:~:::,'

PERSONNEL

• 48 !lIT HORD

DIRECT MEMORY
• 32 K CORE

/
BR - 85

NA.'ffi

SSN

GRADE

CATeGORY

GRADe

S':RVICE DATZ

J~GREE

DATE

185

--.L

SOCIAL SECURITY /',lJMBER
.)erg

·~31711.!

570725

fe?.or::!cs

032513165

621113

Feate

425626582

510820

~eed

057254321

480530

:-15

Ph.D.

NAME

Figure 9-Sixth display

_B_

CONCLUSION
This paper has described the utilization of an associative
schemata for the solution of data management problems.
There are advantages and disadvantages in utilizing associative memories for data management. Among the
advantages shown by this implementation are that this
method superimposes little additional structure for machine representation and eliminates the need for indexing. From an informational standpoint, an index is a
redundant component of data representation. In the associative method, all of the advantages of indexing are
present with little data redundancy. A comparison between IF AM and an inverted list data management system given in Reference 4 shows that the inverted list
technique requires 3 to 15 times more storage.
Also provided in Reference 4 is a comparison between
IF AM and inverted lists in the area of query response
time. It is shown that queries using inverted lists take as
much as 10 times longer than IFAM. In the inverted list
technique, as more items are indexed response time to
queries tend to decrease, whereas update time normally
increases. This is so because directories and lists must be
updated in addition to the actual information. Since
IF AM does not require such directories, the overhead is
kept at a minimum and updating can be accomplished as
rapidly as queries. In addition, the associative approach
provides a great deal of flexibility to data management,
allowing classes of queries and updates to adapt easily to
changing requirements. Thus, this system is not likely to
become obsolete.
One of the disadvantages of associative memories is the
cost of the hardware. The increased cost is a result of
more complex logic compared to conventional memories.
This cost is justified in instances such as those described
above. On the other hand, if factors such as speed and
flexibility are not important, then the less costly current
systems are preferable.

DEGREE

Figure lO-Sample retrieval request
REFERE~CES

1. Bleier, R., Vorhaus, R., "File Organization in the SDC Time

3.
4.

6.
7.
8.

10.
11.

12.
13.

14.
15.

16.

Shared Data Management System (TDMS)", IFIP Congress,
Edinburg, Scotland, August, 1968.
CODASYL System Committee Technical Report, "Feature Analysis of Generalized Data Base Management Systems", ACM Publication, May, 1971.
Dodd, G., "Elements of Data Management Systems", Computer
Surveys, June, 1969.
DeFiore, C., "An Associative Approach to Data Management",
Ph.D. Dissertation, Syracuse University, Syracuse, New York,
May, 1972.
DeFiore, C., Stillman, N., Berra, P. Bruce, "Associative Techniques In The Solution of Data Management Problems", Proc. of
the 197] ACM National Conference, 1971.
"GE 625/635 Integrated Data Store", GE Reference Manual,
August, 1965.
"Generalized Information Management (GIM), Users Manual",
TRW Doc. #3]8]-C, 15 August, 1969.
Minker, J., "An overview of Associative or Content Addressable
Memory Systems And A KWIC Index to the Literature: 19561970", Computing Reviews, Vol. 12, No. 10, October, 1971.
Minker, J., "Generalized Data Management Systems - Some
Perspectives", University of Maryland, TR 69-101, December,
1969.
Prywes, N., Gray, R., "The Multi-List System for Real Time Storage and Retrieval", Information Processing, 1962.
Prywes, N., Lanauer, W., et aI., "The Multi-List System - Part I,
The Associative Memory", Technical Report I, AD 270-573,
November, 1961.
Sable, J., et aI., "Design of Reliability Central Data Management
System", RADC TR 65-189, July, 1965.
Sable, J., et aI., "Reliability Central Automatic Data Processing
System", RADC TR 66-474, August, 1966.
SDC TM-RF-104/000/02, "Management Data Processing Systems", (Users Manual), 20 June, 1969.
SDC TM-RF-lO;OOO/O], "Management Data Processing System",
(On-Line File Manipulation Techniques), 20 June, 1969.
Wolinsky, A., "Principles and Applications of Associative Memories", TRW Report 5322.01-27, 31 January, 1969.

Associative processor applications to real-time data
management
by RICHARD R. LINDE, ROY GATES, and TE-FU PENG
System Development Corporation
Santa Monica, California

for data management applications, we have described a
machine that has-many more processing elements than
the classical array processors and whose processing elements are smaller (256 bits) and, hence, provide more
distributed logic. For cost reasons, our machine cannot be
fully parallel, having logic at every bit; for efficiency
reasons, however, we selected a byte-serial, external-bytelogic machine design as opposed to the bit-serial processors that are widely described in the literature. For
example, three cycles are required for this type of machine to perform an 8-bit add, whereas 24 cycles are
required for the bit-serial, external-logic machines, yet
the byte-serial logic cost is very little more than that of
the equivalent bit-serial logic.
Past studies have shown that data management systems implemented on an AP can become I/O-bound quite
quickly due to the AP's microsecond search operations
relative to slow, conventional, I/O-channel transfer rates. 4
Hence, for our associative memory (AM), we have
hypothesized a large, random-access data memory for
swapping files to and from the AMs at a rate of 1.6 billion
bytes/ sec. Other studies have considered the use of associative logic within high-capacity storage devices (logicper-track systems) such as fixed-head-per-track disc
devices. 2 •5
Thus, for reasons of efficiency, at a reasonable cost, we
have described a byte-serial, word-parallel machine,
called the Associative Processor Computer System
(APCS), that consists of two associative processing units,
each having 2048 256-bit parallel-processing elements.
This machine is linked to a conventional processor that is
comparable to an IBM 370/145 computer. In order to
compare this machine with a sequential machine, we
have programmed several real-time problems for both
machines and compared the resultant performance data.
The set of problems for the study were derived in part
from an analysis of the TACC testbed developed at Hanscom Field, Mass. The TACC is the focal point of all air
activity within the Tactical Air Control System (TACS).
The TACS is a lightweight, mobile surveillance and
detection system, assigned to a combat area at the disposal of Air Force Commanders for making real-time air
support and air defense oriented decisions.

INTRODUCTION
This paper describes a research study concerning the
potential of associative processing as a solution to the
problem of real-time data management. 1 The desired outcome of the research was an evaluation of the comparative
advantages of associative processing over conventional
sequential processing as applied to general real-time
Data Management System (DMS) problems. The specific
DMS application framework within which the study was
carried out was that of the data management functions of
the U.S. Air Force Tactical Air Control Center (TACC).
The primary feature used to select an associative processor (AP) configuration was "processing efficiency," by
which is meant the number of successful computations
that can be performed in a given time for a certain cost.
In DMS applications, processing efficiency is influenced
by large-capacity storage at low cost per bit, the record
format, search speed, and the ability to search under logical conditions and to combine search results in Boolean
fashion. The primary technique used for comparing an
AP's performance with that of a sequential processor was
to arrive at a set of actual execution rates for the class of
real-time data management problems. These execution
rates, coupled with the assumption that parallel computers cost four or five times more than their equivalent
sequential computer counterparts, will yield an estimate
of an AP's cost-effectiveness for the DMS problem.
Obviously, the more data that can be processed in parallel, the greater the processing efficiency; and DMS applications, by their nature, have a high degree of parallelism
and, hence, they dictated the type of parallel processor
used for the comparisons. As a result, we dealt with
machines that fit into the general category of the associative processors. 2 These are machines that execute single
instruction streams on multiple data paths; or, viewed
another way, they are machines that can execute a program on a (large) set of data in parallel. The classical
array processors, such as the ILLIAC-IV and PEPE
machines, are characterized by a relatively small number
of sophisticated processing elements (e.g., a network of
mini-computers), each containing several thousand bits of
storage. 3 In order to obtain a high processing efficiency
187

188

National Computer Conference, 1973

The TACC is divided into two divisions: Current Plans
and Current Operations. Current Plans is responsible for
developing a 24-hour fragmentary (FRAG) order that
defines the air activities within the combat area during
the next 24-hour period, and Current Operations monitors
those activities in real time. Some of the Current Operations functions were programmed for the IBM 1800
computer at the testbed, and an analysis· was made of a
scenario, relating to a testbed demonstration, for determining those functions critical to Current Operations and,
therefore, important candidates for our study.
Also, a study was made of several data management
systems (SDC's DS/2, CDMS, and CONVERSE, and
MITRE'S AESOP-B) to arrive at a set of associative
processor DMS primitives. 6 . 7 . 8 ,9 Those primitives that
appeared to be most important to DMS functions were
evaluated. We used the primitives required by update
and retrieval applications for writing APCS programs,
and compared the APCS performance result::> against
conventional programs, written for data bases stored
physically in random-access fashion.
A relational data-structure model provided us with a
mathematical means of describing and algorithmically
manipulating data for an associative processor. Because
relational data structures are not encumbered with the
physical properties found in network or graph-oriented
models, they provide independence between programs
and data. The T ACC testbed data structure provided us
with examples for describing and logically manipulating
relational data on the APCS in a DMS context.
The study results enabled us to make re~ommendations
for further studies directed toward arriving at cost-effective parallel-machine solutions for real-time DMS problems. APCS-like machine descriptions will continue to
evolve for the next several years. We do not recommend
that the APCS or the various future versions (which, like
the APCS, will have to be fixed for comparison purposes
even though their structures may not be optimally costeffective) be considered a cost-effective solution to the
DMS problem. Instead, we hope that they will serve as
starting points for the machine evolution studies that will
have to precede any attempt to describe the "ultimate"
solution for data management.

The central processor is an integration of five units: two
associative processing units (APUs), a sequential processing unit (SPU), an input/output channel (IOC), and a
microprogrammed control memory. The APU s provide a
powerful parallel processing resource that makes the system significantly different from a conventional one. From
a conventional system-architectural point of view, the
APU s can be viewed as a processing resource that has a
large block of long-word local registers (in this case, 4K X
256 bits) with data manipulation logic attached to each
word; an operation is performed on all registers simultaneously, through content addressing. Actually, the central
processor has three different processors-II 0, sequential,
and parallel-and all three can operate simultaneously.
The three processors fetch instructions from the program
memory, interpret the microprograms from control
memory, and manipulate the data from data memory.
The memory system consists of three units: primary
memory, control memory, and secondary storage. The
data management functions and the data base of the data
management system are independent of each other; for
this reason, the primary memory is subdivided into program memory and data memory for faster information
movement and for easy control and protection. This separation is another special feature of the system. The program memory is assumed to be large enough to store
executive routines, data management functions, and user
programs for the three processing units; consequently,
program swap operations are minimized. The data memory can store the data base directory and several current
active data files.
Finally, two additional resources, terminals and displays and other peripherals, are added to make up a
complete real-time system. The other peripherals include
tape units and unit-record devices such as line printers,
card readers, and punches.
The reading and writing of AP words are controlled by
tag vectors. The word logic is external to each AM word
for actual data operations and control. The word logic

Secondary
Storage

ASSOCIATIVE PROCESSOR COMPUTER SYSTEM
A complete associative processor computer system
(APCS) for a real-time data management application is
shown in Figure 1. It is not a so-called "hybrid" system,
with an interconnection of serial and associative processors; rather, it is a totally integrated associative computer. The central processor functions as an active
resource that controls the overall system and performs
information transformation. The memory system acts as
a passive resource for the storage of information. Numerous data paths are provided between the central processor
and various memory and external units for efficient information movement.

Sequential
Processing Un! t
Program
!1emory
Data
l'1emory

Control
Memory

Central Processor

Figure I-Associative processor computer system (APCSi

Associative Processor Applications to Real-Time Data Management

consists of two main portions: byte operation logic and tag
vectors. The byte operation logic includes byte adders,
comparison logic, and data path control logic. There are
three types of tag vectors: hardware tag vectors, tag vector
buffers, and tag vector slices. The hardware tag vectors
consist of four hardware control tag columns: word tag
vector (TVW), control tag vector (TVC), step tag vector
(TVS), and response tag vector (TVR). The TVW indicates whether a corresponding AM word is occupied; it is
set as the AM is loading and reset when it is unloading.
The TVC controls the actual loading and unloading of
each AM word in a way analogous to that in which mask
bits control the byte-slice selection, except that it operates
horizontally instead of vertically. The setting of TVS
indicates the first AP word of a long record (one containing more than one AP word). The use of the TVR is the
same as the familiar one, where a c9rr~,sponding tag bit. is
set if the search field of an AP word matches the key. In
addition, most tag-manipulation logic (such as set, reset,
count, load, store, and Boolean) is built around the TVR.
The status and bit count of the TVR vector can be displayed in a 16-bit tag vector display register (TVDR) to
indicate the status of various tag vectors for program
interpretation. These four hardware tag vectors are
mainly controlled by hardware, which sets and resets
them during the actual instruction execution. In addition,
they can also be controlled by software for tag vector initiation or result interpretation. The contents of various
hardware tag vectors can be stored temporarily in the
eight tag vector buffers if necessary. This is particularly
useful for simultaneous operations on multiple related
data files or for complex search operations that are used
for multiple Boolean operations on the results of previous tag-vector settings. The use of the five tag vector
slices is similar to that of the tag vector buffers except
that they can be stored in the DM along with the corresponding AP words and loaded back again later.

A RELATIONAL DATA MODEL FOR THE TACC
TESTBED
Let us now consider a data structure for the APCS in
terms of the TACC testbed DMS.
Set relations provide an analytical means for viewing
logical data structures on an associative processor.lO.lL12
Given sets (8,82 , • • • , Sn). If R is a relation on these sets,
then it is a subset of the Cartesian Produce 8 l X82 • • • 8 n ,
and an n-ary relation on these sets. The values of elements in this relation can be expressed in matrix form
where each jill column of the matrix is called the jill
domain of R and each row is an n-tuple of R. Domains
may be simple or non-simple. A simple domain is one in
which the values are atomic (single valued), whereas nonsimple domains are multivalued (i.e., they contain other
relations). As an example of set relations applied to associative processing, consider the example of the TACC
testbed.

F:~E

A.'<) ?R.OPERTY DESCR!?70RS

1:-r7TTTT

'..:o:::~s
'!-t::::

189

?RC?~R:-:'

;;

Reo

)

\'
I.

" "6 "7
)

I
:

;
i
i

!I
i

I
:

PROPERTY DESCR.:;:PTORS

:-;-A.."1E"

s~~~~ !

(;'1I

i
i
I

~'~IT

SY;ES

i
i

~~~~~R

I
I

Cl' I I
(' ..•.... i
.....

...... ,

Ie :

I /
I ,,"'.

I i
I

I [
!

i !

Figure 2-T ACC tested- storage
structure on the APCS
..
..

The testbed defines a "property" as one item of in formation (e.g., one aircraft type for a designated base). An
"object" is a collection of properties all relating to the
same base, unit, etc. Objects are the basic collections of
data within a file (e.g., an air base file would have one
object for each designated base, and each object would
contain all properties for one base). A complex property is
a collection of properties (such as data and time) that are
closely related and that can be accessed either individu··
ally or as a group (date/time).
The data base files are structured to show property
number, property name, complex property indicator,
property type, EBCDIC field size, range/values, and
property descriptions. They are self-described and contain both the data (the property values) and the descriptions of the data. The descriptive information constitutes
the control area of the file, and the data values constitute
the object area of the file. The control area contains an
index of all objects in the file (the object roll), and an
index and description of all properties in the file (the
property roll). The object roll contains the name of every
object in the file, along with a relative physical pointer to
the fixed-length-record number containing its data; the
property roll defines the order of property-value data for
each object and points to the location of the data within
the object record.
Figure 2 illustrates how AM #1 might be used to logically represent a testbed file control area. It contains two
relations:

and

which represent an index of all the files in the testbed
(R l ) and a list of all the property descriptors associated
with the file (R 2 ). The first domain (file name) of relation
R I is the primary key; that is, it defines a unique set of
elements (or n-tuples) for each row of R I •

190

National Computer Conference, 1973

AM H2 DATA
T
V
S

FTRASGN
W

NA.'1E
A;lEF

I PCAS!

NAME

ADEF I PCAsl

UNIT

ICAS
UNIT

ICAS

Alc TYPE

BASE

I INTD I

CAIR

r Em
I

TOT:

\ CAPE
BASE

AtC TYPE

TOT

CAPE

INTO I

ICASFRAG
NA.'IE

UXIT !TYPEI TXJ1T lAIC TYPE ISORT

r
I

FIRST-MSN

I !

:
I

ir:

1-------------

SEARCH AND RETRIEVAL COMPARISONS

1-------------

f------------j
~A.'IE

cNIT ITYPEI T:01T

lAIC

TYPE ISORT I

F1RST-MSN

flight characteristics (range, speed, etc.) occurring within
the primary relation. To normalize this relation, the
primary key or a unique marker is inserted in the nonsimple domain, the non-simple domain is removed from
the primary relation, and the sequence is repeated on the
secondary relation, tertiary relation, etc., until all nonsimple domains have been removed. DeFiore lo has
described and illustrated this technique on an AP and
calls the data structure containing only simple domains
the Associative Normal Form (ANF).

1.\
I

Figure 3-TACC testbed property values on the APCS

The domain labeled "Vector" contains the address of
the tag vector that delineates the property values for the
file; they are contained in AM #2. The domains labeled
"AM #" and "Words/Record" contain the AM number
for the property values and the number of physical AM
words per record. The domain labeled "Property ID"
contains a marking value that identifies the property
descriptors in relation R2 for each file name of primary
key in relation R I • Tag vectors TVO and TV1 mark those
words in AM #1 containing relations RI and R 2 , respectively; this is necessary because two domains of the
respective relations may be of the same size and content,
thus simultaneously satisfying search criteria. The programmer must AND the appropriate vector, either TVO
or TV1, with TVR after such a search to obtain the relevant set of N-tuples.
Since the APCS uses a zero-address instruction set,
parameter lists must be defined in control memory for
each APCS instruction to be executed. Obviously, controlmemory parameter lists are needed to define search criteria for relations R1 and R2 and table definitions (not
shown) for creating these lists before the descriptors contained iIi AM #1 can be used to define another set of lists
for accessing the property values in AM #2 (see Figure 3).
Figure 3 illustrates the relations that describe the
Fighter Assignment File (FTRASGN) and the Immediate
Close Air Support Frag Order File (lCASFRAG) property
values. They are represented by n-ary relations containing a set of simple domains, 1 through n, which contain
the actual data values for the elements: first mission
number, last mission number, aircraft/type, etc. The
domain labeled UNIT is the primary key for the relation
and corresponds to the unit number contained in the
testbed object roll.
H the domain representing aircraft type contained
more than one aircraft and a set of simple domains
describing each aircraft, then a non-simple domain would
occur in a primary relation. That is, there might be F104
and F105 fighter aircraft and parameters relating to their

A search and retrieval comparison was performed using
the APCS and a sequential computer, the IBM 370/145,
as the comparative processors. Two problems involving
fact and conditional search and retrieval were coded. A
random-access storage structure was chosen for the conventional case; the conventional dictionaries were unordered. The data structure for the APCS can be shown by
the relation

It is an ll-tuple requiring two words per record.
Branching or updating more than one word per record
presents no particular problem.1o.13.14 Table I contains
data (normalized to the 370/145) from these measures.
The APCS was between 32 and 110 times faster than the
sequential processor, depending upon the algorithm and
the number of keys searched. However, system overhead
time to process the 1;0 request and to transfer the data
from disc to data memory (no overlap assumed) was
charged to the sequential and associative processors.
Therefore, after 4000 keys, the APCS times tended to
approximate those of the sequential processor since an
IBM 2314 device was required for swapping data into the
DM.

UPDATE COMPARISONS
In the conventional case, the measurements involved
ordered and unordered dictionaries; in the associative
case, no dictionary was used. For both cases, we used
fixed-length records, 64 bytes/ record, and assumed that
update consisted of adding records to the file, deleting
records from it, and changing fields within each record.
As in retrieval, the personnel data base was used for the
measurements. It consists of a set of simple domains
shown by the general relation R1 (an, a 12, . . " a 1n ).
Updating the data base involved a series of searches on
the domain a 1n such that a subset of al!t was produced: the
list of length I r 1n I.
The set of n-tuples in the relation R can be changed
using the APCS Store Data Register command in
Nir 1n I insertions, where N in the APCS measurements

Associative Processor Applications to Real-Time Data Management

191

TABLE I-Retrieval Measurements (Data Normalized to 370/145)

APCS Tl
1000
2000
4000
8000

FACT RETRIEVAL
370/145 T2

.341 ms
.401
.613
913.1

CONDITIONAL SEARCH AND RETRIEVAL
APCS
370/145
RATIO T2/Tl

RATIO T2/Tl

10.888 ms
18.345
36.617
1,011.853

31.8
45.6
60.0
1.11

.695 ms
1.098
1.926
915.35

53.135 ms
105.928
211.810
1,335.624

76.5
96.4
110.0
1.45

• APCS EASIER TO PROGRAM, ALTHOuGH IT TOOK MORE CODE
• APCS REQ"GIRED 15% LESS STORAGE

consists of three domains: department number, division,
and employee ID. In each case, a batch update technique
was used, and one-half the data records were modified: 20
percent changed, 15 percent added, 15 percent deleted.
Since no dictionary was needed in the associative case,
there was a 15 percent savings for data storage for the
APCS. The system calls and tables used in the Search
and Retrieval calculation were used in the Update measures, as well.
Assuming that the list r 1n and the Update list are both
in sorted order, data values could be inserted into the list
r1n using the parallel transfer capabilities of the APCS in
m times the basic cycle time, where m is the number of
bytes in the set of n-tuples to be changed.
Table II shows the normalized (to the 370/145) timings
for the APCS and a conventional computer (370/145) for
the Update measurement. The measurements for the
conventional case involved ordered and unordered dictionaries.
The search algorithm for the conventional case was
applied to an ordered dictionary, where a binary search
technique was used involving (rIog2 v(x)) -1 average
passes; v(x) denotes the length of the dictionary. For the
unordered case, it was assumed that a linear search technique found the appropriate dictionary key after a search
of one-half the dictionary entries.
Since the Search and Retrieval measurements were
severely limited by conventional I/O techniques, the
Update measures were projected for mass storage devices
(semi-conductor memory) holding four million bytes of
data. Hypothetically, such devices could also be bubble
and LSI memories or fixed-head-per-track discs; in either

case, the added memories are characterized by the parallel-by-word-to-AM transfer capability.
Since N/2 records were updated over an N-record data
base, the conventional times increased as a function of
N2/2, whereas the APCS times increased as a function of
N. Even though a four-megabyte semiconductor memory
would probably not be cost effective for conventional
processing, it was hypothesized as the storage media for
the conventional processor so as to normalize the influence of conventional, channel-type I/O in the calculations. Even so, the APCS showed a performance improvement of 3.4 orders of magnitude over conventional processing for unordered files consisting of 64,000 records.
SEARCH AND RETRIEVAL WITH RESPECT TO
HIERARCHICAL STRUCTURES
A comparison was made between the associative and
sequential technologies using hierarchically structured
data. Consider a personnel data base containing employee
information, wherein each employee may have repeating
groups associated with his job and salary histories. The
non-normalized relations for this data base are:
employee (man #, name, birthdate, social security number, degree, title, job history)
job history (jobdate, company, title, salary history)
salary history (salary date, salary, percentile)
The normalized form is:
employee (man #, name, birthdate, social security number, degree, title)

TABLE II-Execution Times-Update-APCS vs. Conventional Times
(Normalized to 370/145)
CONVENTIONAL (T2) DICTIONARIES
NUMBER OF
RECORDS

APCS (Tl)

UNORDERED

1000
2000
4000
8000
16000
64000

.046 sec.
.108
.216
.433
.865
2.916

2.874
11.386
4.5.326
180.861
722.422
11 ,548.198

ORDERED
.719 sec.
2.912
10.26.'3

38.091
146.440
2,271.915

RATIOS (T2/Tl) DICTIONARIES
UNORDERED

ORDERED

62.4
105.0
210.0
416.0
825.0
3,875.0

15.6
26.9
43.5
87.9
169.0
770.0

192

National Computer Conference, 1973

job history (man #, jobdate, company, title)
salary history (man #, jobdate, salary date, salary, percentile)

the length of RI (il), the number (C) of comparison criteria, and the length ( IPII ) of the list formed after a search
of RI times the average number of items, a, in the simple
domain a 21 • This is represented by:

and the Associative Normal Form is:
RI(a ll , a 12 , ala, a 14 , a 15 , a 16 ,
R 2(a 21 , a22, a2S, O'll 0'2)
Rs(as h as 2 , aaa, 0'1, 0'2)

0'1)

The total number of searches, nl, required for the relation RI is the sum of the number of possible search arguments for each domain in R I • Similarly, the number of
searches for R2 and Ra can be represented by n 2 and na.
The number of words, or processing elements (PEs), satisfying a search on RI is I kll, and for R2J I k21. Since the
0' I values from the PEs satisfying the search conditions
for R I are used as arguments for searching R 2 , the total
number of ~earchei" po~sible for R2 is equal to n 2 + IkJ I:
analogously, the total number for Ra is equal to n a+ Ik21.
Therefore, the total number of searches for one APCS
data load required for the three relations hi:

T=n +n +n s +IkII+lk 1·
l

The first comparison dealt with a search and retrieval
problem for a personnel data base consisting of the three
relations R I , R 2 , and Ra. These relations required 50,000
records, each contained within two PEs. The problem
dealt with the query:
PRINT OUT THE MAN #, SALARY DATE, AND
SALARY FOR THOSE EMPLOYEES LQ 40, WITH MS
DEGREES, WHO ARE ENGINEERS, AND WHO
HAVE WORKED AT HUGHES.
In the associative case, the total number of searches
required was:

where N = number of APCS data loads. (Note: the
multi-conditional search on RI can be made with one
search instruction.)
For the total data base, it was assumed that varying
numbers of records satisfied the RI search, i.e.,

Holding the term C II constant in T2 and examining the
two equations TI and T2 it can be seen that, for this particular query, as the number of responding PEs increases,
the associative performance improvement ratio will
decrease; that is, as the number of 0'1 and 0'2 searches
increases, as a result of an increase in the number of PEs
responding to primary and secondary relation multi-conditional searches, the performance improvement ratio for
the APCS decreases. This is illustrated by Table III.
However, as the number of records increases (C 11-> 'Xl),
the performance ratio increases for the APCS when holding the number of responding PEs constant over the
measures.
Based on the search and retrieval problems that have
been investigated, it can be concluded that with respect to
conventional random-access storage structures, the performance improvement for the APCS is affected by the
amount of parallelism inherent within a search, the
number of multi-field searches spread over a set of
domains, and the degree of hierarchical intra -structure
manipulation, with respect to 0'1 and 0'2 searches, invoked
by the query.
A set of queries that tends to produce the following
effects will improve the APCS performance ratio:
• Queries invoking an increase in the number of PEs
participating in a series of searches.
• Queries requiring an increasing number of multifield searches.
• Queries requiring increasing volumes of data
(assuming that high -speed parallel I/O devices are
available for loading the APCS).
The APCS performance ratio decreases as the queries
tend to produce:
• A decreasing number of PEs invoked by a series of
searches.

(EMPLOYEES LQ 40, DEGREE EQ MS, TITLE EQ
ENGINEER);
and that a variable number of the records marked after
the 0'1 search satisfied the R2 search for 'HUGHES'.
For the conventional case, it was assumed that a random-access storage structure existed and that an unordered dictionary was used for calculating record
addresses if needed. An index in R I was used to access the
records belonging to R 2 , and an index in Ra was used to
obtain the values to be printed. The total number of
Search Compare instructions required was a function of

TABLE III-Hierarchical Search and Retrieval
(50,000 Records) (Normalized to 370/145)
al AND a2
SEARCHES

11
110
600

1100
2300

APCS TIME (Tl)

IBM 370/145
TIME (T2)

RATIO
T2/Tl

6.167 MS
14.785
50.87
81.87
150.07

901.951 MS
910.51
952.6
989.8
1077 .3

150
62
18
12
7

Associative Processor Applications to Real-Time Data Management

• An increasing number of 0'1 and 0'2 searches with
respect to hierarchy.
• An increase in the use of slow, conventional channel
I/O techniques.
TACC APPLICATION SYSTEM AND ASSOCIATIVE
PROCESSING ANALYSIS
After having looked at specific DMS subfunctions on
an AP, it is of interest to see their importance applied to
the processing activities of a real-time system and to
evaluate an AP's impact from a total system viewpoint.
The desired outcome of this study is to have a capability to evaluate the impact of associative processing on the
future data automation efforts of the Tactical Air Control
System (TACS). A portion of the data management sys-tem-p-rocessingoperations were defined;forthe purpose of
this study, in the context of the on-going Advanced Tactical Command and Control Capabilities (ATCCC) Studies. The results presented below were derived from an
analysis of a scenario for the T ACe Current Operations
Division that was under investigation on a testbed facility
at Hanscom Field, Massachusetts. The testbed consisted
of functional software for the Current Operations and a
data management system operating on an IBM 1800/
PDP-8 distributed system. 15
A real-time associative processor data management
system (AP / DMS) study model was developed with
equivalence to the T ACC testbed system in mind. A practical comparison was made between the two systems in
order to determine which system better meets TACC data
management requirements. The AP IDMS design also
serves as a basis for projections of the future effects of
sophisticated application of associative processing technology on hardware, data structures, and future data
management systems. The following describes the API
DMS and the comparison methodology and results. The
comparison measurements are normalized to bring the
hardware, data structures, and data management systems
to equivalent levels.
The testbed system (running on the IBM 1800 computer) and the AP IDMS (running on the APCS) were
compared first with both using IBM 2311 discs as peripheral storage, then with both using IBM 2305 fixed-headper-track discs. In the first case, the number of instruction executions for both systems was multiplied by the
average instruction time for the IBM 1800; in the second,
the multiplier was the average instruction for the APCS.

AP/DMS

The AP I DMS was req uired to provide a data management environment for the comparison of associative processing techniques with the sequential techniques used in
conventional data management systems. It was aimed at
the development of cost-effectiveness and performance

193

ratios and as a background for the analysis of advanced
associative processors.
This general statement of requirements was used to
derive a set of general capability and performance
requirements for the system. The equivalence between
the testbed system and the API DMS was the overriding
requirement. The testbed data base and scenario were
kept in the same form to achieve the desired results. The
user language was tailored to match both the testbed system and the AP IDMS. The notion of normalizing computer instruction times implies a similarity in the software and the data flow. The I/O requirements were
accorded separate but equal status to provide an ability
to make both simple and complex changes to the system
configuration.

System organization
The concern for system equivaience pervades all phases
of system design-starting with the system's logical organization and physical configuration. An API DMS system
organization aimed at meeting the requirements discussed
above was established. The basic organizational concept
was that the data processing capability should be concentrated in the associative processor. Such a system organization offers better and faster response to user queries
and provides a capability for system growth and change
and favorable conditions for system design and implementation.
The APCS computer performs the following functions:
1. Generation, storage, and maintenance of the sys-

tem data base.
2. Storage of general-purpose and application programs.
3. Dynamic definition of data base organization.
4. Execution of message processing programs and, in
support of those programs, retrieval from and manipulation of data base files.
5. Message reformatting-specifically, conversion from
data base format to display format.
6. Immediate response to message and data errors,
reducing the processing time for inconsistent users queries.

Measurements
The AP/DMS was coded in JOVIAL-like procedures
using the APCS instruction set. An instruction path
derived from the testbed scenario was given to a counting
program, and a comprehensive set of statistics was generated for the AP / DMS. Similar measurements were made
from several SDC testbed documents to derive a set of
testbed ~tatistics.
Table IV presents the test-run results. The total time
for the TACC testbed was 29.9 seconds; the TACC API
DMS time was 11.8 seconds. These times were normal-

194

National Computer Conference, 1973

TABLE IV-Comparison Normalized to IBM 1800-2311 Base
TACC AP/DMS
TESTBED
SP ONLY

AP+SP

AVG. TIME PER
OPERATION

4810

NO. OF OPERATIONS

2,161,700

994,300

217,000

777,300

OPERATION
TIME

10,397,777

4,782,583

1,043,770

3,738,813

I/O OPERATION TIME

19,589,770

7,063,731

8,731

7,055,000

TOTAL TIME

29,987,547 11,846,314 1,052,501

10,793,813

RATIO

TESTBED:

AP/DMS

2.5:1

ized to the IBM 1800/2311 operational times. Table V
was normalized to APCS/2305 operational times. In the
latter case, the performance ratio was approximately 3:1;
that is, the AP performed the equivalent task three times
faster than the conventional processor.
Statistics showed that the APCS spent 80 percent of its
time in parameter· definition and passing functions,
whereas the testbed computer spent 3.8 percent of its
time with such functions. The APCS defined its instruction operands from data definition parameters located in
an AM-resident dictionary, and sequences of code pas~ed
these parameters from JOVIAL procedure to procedure.
The associative processor does use more parameters
than the sequential processor, but not 20 times as many;
statistics showed that 73.7 percent of the AP /DMS time
was spent in dictionary operation. It can be concluded
that there were too many calls to the dictionary, causing
too many parameters to be used and passed. Another
factor in the AP / DMS performance is the use of the
JOVIAL procedure call technique. This technique uses
elaborate register and address saving and restoring code.
This code is unnecessary, particularly for one AP procedure calling another AP procedure.
When we reduce the parameter passing and dictionary
calls by 90 percent and disregard I/O times, the performance ratio is approximately 30: I-however, we can improve this ratio even more.
The TACC data base used by the AP /DMS was biased
in favor of sequential computing. The size of the data
base was 400KB, consisting of 50 files containing 1850
domains which involved an average of 68 processing
elements. Cost-effective parallel computation techniques
favor the reverse-68 domains spread over 1850 processing elements. The T ACC data base can be reduced to 500
domains, which would have the net effect of involving
more parallel processing elements and reducing the time
spent in parameter setup, producing a 60: 1 CPU gain
over sequential processing for the TACC problems.

CONCLUSIONS AND RECOMMENDATIONS
In order to investigate real-time DMS functions on an
associative processor, a hypothetical Associative Processor Computer System (APCS) was described. The
description was carried to the instruction level in order to
have an associative machine on which to code Air Force
Tactical Air Control Center (TACC) and update and
retrieval problems for comparison with corresponding
conventional (sequential) codings.
A T ACC testbed scenario describing an operational
demonstration of the T ACC Current Operation functions
was analyzed and from this analysis it was concluded that
of the DMS functions most able to use an associative
processor, the great majority of tasks in an operational
situation fell in the three data management areas of
retrieval, update, and search, with 60 percent of the total
processing tasks being associated with data search and
retrieval.
For this reason, it was decided to investigate Search
and Retrieval and Update subfunctions on the APCS.
This investigation involved coding Search and Retrieval
and Update problems for the APCS and for a conventional computer, an IBM 370/145. From an analysis of
various conventional physical data organizations, the
random-access storage structure was chosen for comparison with the APCS because of its similarity to testbed
data organizations, because of its widespread use in other
systems,16 and because of other studies relating to list
organizations. 1o Hierarchical and non-hierarchical record
structures were investigated.
APCS performance improvements, normalized to the
IBM 370/145 computer, varied from 32 to 110 times
faster for Search and Retrieval and from 15 to 210 times
faster for update; this assumes that a half-million-byte
mass storage device (semi-conductor memory) with a
parallel I/O bandwidth of 1.6 billion bytes/second exists
for loading the associative memory. By increasing the size
of this device, more cost-effective performance ratios were
achieved for the two DMS measures; other mass storage
devices which may be more cost-effective for associative
memories are bubble memories, fixed head-per-track
discs,17 and LSI memories.
TABLE V-Comparison Normalized to APCS-2305 Base
TACC AP/DMS
TESTBED-----------------AP
SP ONLY AP+SP
SP
AVG. TIME PER OPERA291
291
291
291
TION
2,161,700 994,300 217,000 777,300
NO. OF OPERATIONS
OPERATION TIME
829,055 289,341
63,147 226,194
1,756,270 587,351
I/O OPERATION TIME
351 587,000
2,585,325 876,692 63,498 813,194
TOTAL TIME
RATIO

TESTBED: AP/DMS

3.0:1

Associative Processor Applications to Real-Time Data Management

From the testbed scenario analysis, three critical realtime functions were selected to provide us with a real Air
Force problem to investigate. We obtained program listings for these functions and converted them to analogous
APCS code. The JOVIAL language, augmented with
APCS instructions, was used for coding the functions.
Due to the data structuring and coding tehniques used, a
3: 1 improvement, normalized to the testbed IBM 1800
computer, was initially shown for the APCS. This
improvement ratio was due to the fact that almost a literal translation was made for converting testbed data
structures to the APCS. Also, the JOVIAL techniques
used for coding the APCS required twenty-five times as
much overhead for passing parameters between subroutines as did the testbed code. By restructuring the testbed
data in order to gain more parallelism and by reducing
-the-parameter passing overhead to that of the testbed, we
concluded that a 60:1 improvement could be gained for
the APCS, and we would expect to obtain that ratio upon
repeating the measures. This assumes that a sufficient
quantity of mass storage exists for swapping data into the
AMS with a bandwidth of 1.6 billion bytes/sec. Based on
our study, recommendations are made for future associative processor research studies relating to high-order
languages, firmware implementation techniques, generalized tag operations, LSI design and AP cell implementation, and memory organization and data movement.

195

REFERENCES
1. Linde, R R, Gates, L. R, Peng, T., Application of Associative
Processing to Real-Time Data Management Functions, Air Force
Systems Command, Rome Air Development Center, Griffiss AFB,
New York, 1972.
2. Minker, J., A Bibliography of Associative or Content-Addressable
Memory Systems-1956-I97I, Auerbach Corporation, Philadelphia, 1971.
3. Session I-Parallel Processing Systems, 1972 Wescon Technical
Papers, Los Angeles Council, IEEE.
4. Dugan, J. A., Green, R S., Minker, J., Shindle, W. E., "A Study of
the Utility of Associative Memory Processors," Proc. ACM

National Conference, 1966.
5. Parhami, B., "A Highly Parallel Computing System for Information Retrieval," AFIPS Cont. Proc., Vol. 41, Part II, pp. 681-690,
1972.
6. DS/2 Data Management System Technical Description, System
Development Corporation, Santa Monica, California.
7. CDMS Data Management System Technical Description, System
Development Corporation, Santa Monica, California.
8. Kellogg, C. H., "A Natural-Language Compiler for On-Line Data
Management," AFIPS Cont. Proc., Vol. 33, Part 1,1968.
9. Hazle, M., AESOP-B Data Management System, MITRE Corporation, MTR-851, 1970.
10. DeFiore, C. R, An Associative Approach to Data Management,
PhD Thesis, Syracuse University, 1972.
11. Childs, D. L., "Description of Set-Theoretic Data Storage," IFIPS

Congo Proc., 1968.
12. Codd, E. F., "A Relational Model of Data for Large Shared Data
Banks," Comm. ACM, June, 1970.
13. DeFiore, C. R, Stillman, N. J., Berra, P. B., "Associative Techniques in the Solution of Data Management Problems," Proc.
ACM National Conf., 1971.
14. Rudolph, J. A., "A Production Implementation of an Associative
Array Processor-STARA~," AFIPS Cont. Proc., Vol. 41, Part I,
1972, pp. 229-242.

ACKNOWLEDGMENT

15. Definition of General Purpose and Tactical Air Control Center
Functional Software, System Development Corporation, TM-LX-

This work was sponsored by Air Force Systems Command, Rome Air Development Center, Griffiss AFB, New
York under Contract No. F30602-72-C-0112.

346/200/00, Lexington, Mass., 1971.
16. Dodd, G., "Elements of Data Management Systems," Computer
Surveys, June 1969.
17. Barnes, G. H., et aI., "The ILLIAC IV Computer, IEEE Trans.
Computers, Vol. C-17 pp. 746-751, August 1958.

A computer graphics assisted system for management
by ROHI CHAUHAN
Tektronix, Incorporated
Beaverton, Oregon

However, after introduction of a less than $4,000 Computer Display Terminal by Tektronix, Inc., in October
1971, the use of high speed interactive graphing terminals
in several phases of business planning and control activities has now become an economically practical reality.
Several companies are known to have implemented,
rather quickly, some simple but elegant and profitable
graphics assisted systems. Two companies that have
publicly talked about their applications are U niroyaP
and International Utilities. 6
This paper will suggest how it is possible to configure
simple low cost Decision Support Systems, via description of a system called GAMA-1 for Graphics Assisted
Management Applications. This system is being used at
Tektronix Inc., Beaverton, Oregon, for corporate planning and production scheduling purposes. The discussion
is focused on characteristics of such business systems,
software architecture, simplicity of design, and ease of
its usage, all of which, of course, is with reference to the
GAMA-l.

U\TRODUCTIOK
Everyone agrees that a "picture is worth a thousand
words". However, it is not yet obvious that it would make
good business sense for managers to make liberal use of
Computer Graphing in almost all phases of business decision-making. This paper asserts that it is convenient and
practical where something worthwhile can be gained by
study of variation of such important parameters as
demand, inventory level, or sales, with time or with
respect to another independent variable. This assertion is
predicated on the assurance that:
A. Graphs can be obtained easily as soon as they are
needed and in the form they are needed.
B. Graphs are very easy to obtain and modify, and
C. Graphing is cost effective.
Some examples of activity areas where business data
graphing is known to be definitely profitable are corporate
planning, purchasing, resource allocation, production
scheduling, and investment portfolio analysis. However,
today, only in a very few management decision -making
processes can it be said that computer data graphing is
being used as a daily routine. Reasons are primarily that
the three conditions mentioned above have not so far
been met to users' satisfaction.
The need for easy graphing with desired flexibility dictates use of computer assisted graphing on display terminals providing both graphic output as well as graphic
input and hard copy capabilities. Management systems
involving such Computer Display Terminals have been,
until recently, quite expensive,l·2 and difficult to justify
for common business applications. Also, the choice of
computer display terminal suppliers and their product
lines were very limited. The software packages that would
really make the job of a "business programmer" easy
were practically non-existent. As such, the application of
Display Terminal Graphics in business decision-making
has remained limited to a very few places, like IBM, 3
and there too apparently on somewhat of an experimental
basis. A significant number of industries have been using plotter type graphics, 4 but only sparingly because of
inconvenience, lack of flexibility, and expense.

SYSTEMS CONFIGURATION
The GAMA-1 system is an imaginative attempt at
exploiting capabilities furnished by modern computers in
timesharing environment. Tektronix 4010 type computer
display terminals, Tektronix 4610 type hardcopy units for
the 4010's, knowledge of quantitative methods that are
frequently used in decision-making process, simple data
organization concepts, and FORTRAN are utilized. Figure 1 shows a multi-terminal GAMA-1 system's configuration. The computer system presently being used is a
PDP-10.
FUNCTIONAL REPRESENTATION
As depicted in Figure 2, the GAMA-l system can be
functionally used in three ways, i.e.,
1. Graphing of user data files (complete with specified
annotation), movement of the produced pictures as
desired to fit suitably on the screen, and finally,
making hard copies for a report.
2. Manipulation of user data, e.g., adding and subtracting of two series, updating, smoothing, etc., and then
performing the task described above, in step 1.
197

198

National Computer Conference, 1973

commonly used methods of moving averages, forecasting
by graphing and inspection. Also, hooks have been
designed, into GAMA-l, so that programs of other desirable techniques can be integrated into the system.

SOFTWARE ATTRIBUTES

4010

T/S COMPUTER
SYSTEM

~:.

4010 iOMPlITER
OISPLAY TERMINAL(,/

4610 HARD COpy UNIT

Figure I-GAMA-l system's configuration

3. Statistical analysis of the user data, systematic
making of forecasts, and generation of reports as in
atep 1.
For data manipulation, analysis, and forecasting, several useful techniques such as adaptive exponential
smoothing, census method X-II, pairing, and regression
analysis are furnished, together with the simple but

)

GRAPHING AND
PICTURE
MANIPULATION

DATA FIlES

f--

8-1/2xll
DATA

~ MANIPULATION

REPORTS

OATA ANALYSIS
AND
FORECASTING

---

Figure 2-GAMA-l functional representation

The GAMA-l software has been designed to provide the
following most desired features into the system.
1. An ease of use as reflected by the self-guiding, conversational nature of the system. A conversational
program is normally thought of as one where the
user responds to the queries from the system, one at
a time. However, this standard can be surpassed by
making all possible choices open to the user known
to him at all times. This has been accomplished in
the GAMA-l software by extensive display of menus
of the available choice~ and use of the graphic
cross hair for selection of the chosen menu item.
2. Ability to combine usage of several data manipulation, analysis, and forecasting techniques as desired,
i.e., adaptability to varying user requirements.
3. Liberal use of graphing throughout the system for
easy comprehension of results of various GAMA-l
operations.
4. Easy interfaceability with user's own programs furnishing capability of further growth of the system.
5. No need for the GAMA-l users to do any applications programming.
6. Mechanism for saving, if so desired, the results that
are generated during a GAMA-l session in the format in which they can be directly fed back as data
into the subsequent GAMA-l sessions.
7. Extensive report generation capabilities allowing the
user easily to compose his report pages consisting of
graphs of original data as well as the results of the
GAMA-l analysis programs saved before. Complete
control over the size and positioning of the graphs,
form of the axes, grid super-imposition, alphanumeric annotations (both vertical and horizontal),
and movement of the report element on a page is
provided. Also, any page of a saved report may be
retrieved, modified, and saved again. This feature
can be exploited for storing the frequently used
preformatted report pages, retrieving them later as
needed, filling the blanks (with graphs of new data
or annotations) for making up a new report.

SYSTEMS ARCHITECTURE
The GAMA-l is a file oriented system designed to function in one of the five GAMA modes at anyone time, i.e.,
1. Option Select Mode (OSM):
2. Data Manipulation Mode (DMM),
3. Analysis and Forecasting Mode (AFM),
4. Report Generation Mode (RGM)' or
5. Help Mode

A Computer Graphics Assisted System for Management

As illustrated in Figure 3, OSM is the central interface
mode which must be entered before any other mode can
be invoked. A typical GAMA-l session will mostly consist
of operations in one or more of the three work modes, i.e.,
the DMM, AFM, and RGM. The system's activity in any
of these three work modes is performed by a set of applications programs whose purpose is related to the nomenclature of the modes.
During a normal conversational session the system uses
three types of disk files, namely,

ir=
....

GAMA FILE,
DATA FILE, and
REPORT FILE,
whose simplified functional relationships are shown in
Figure 3.

NEXT SEGMENT POINTER

NEXT DISPLAY ELEMENT POINTER
DISPLAY ELEMENT TYPE
DEPENDENT INFORMATION

...J

c:r:I-W
::E
C!:I
c:r:...Jc:r:
c.!l c:r:o...
u
c:r: ...... w
I-...J

I.I-z ......
OWI.I-

NEXT DISPLAY ELEMENT POINTER

o
z ...... 1o
0::::

...... 1-0

DISPLAY ELEMENT TYPE
DEPENDENT INFORMATION

I- zo...
o::::ww

o::EO::::
0... c.!l

wc:r:

(/) (/)

......

::c
I-

I+~

r--

I
Gama file

The GAMA FILE is the central work file used for
conducting information flow between various modules of
the GAMA-1 software. It is read by the programs in
DMM, AFM, and RGM, and it can be modified by the
program in DMM and AFM. It can have several segments in it, each of them being a binary representation of
the original data or the data resulting from operations on
a GAMA FILE SEGMENT by one of the applications
programs. Use of this technique saves information storage
costs and adds to run time efficiency.
Figure 4 describes the general design philosophy of the
GAMA FILE. It is simple. A complete display normally
consists of more than one display element, which can be
added to, removed from, or moved on the display screen,
but may not be subdivided. The display elements may be
either "Graph" or an "Annotation", as defined below.

199

I
I
I
I
I
I

I
I
I
I
I

I...

NEXT SEGMENT POINTER
NEXT DISPLAY ELEMENT POINTER
I
I

(MAY BE SEVERAL SEGMENTS
OR REPORT PAGES)
I

a
a
END OF FILE
Figure 4-GAMA FILE layout

Graph-Binary representation of data, both numeric
(to be graphed) and alphanumeric, that must be treated
as one unit. For example, a GAMA FILE segment generated from a DATA FILE (Figure 5) would contain only
one element which would be of type "GRAPH".

DATA FILE

Annotation-A display element created by the GAMA1 programs during DMM, AFM, or RGM under user
control. Annotations do not have names. Annotations
cannot exist outside of RGM unless they are associated
with a graph. Annotations may be either graphic or
alphanumeric.
GJl.~A

Alphanumeric Annotation-It is a string of alphanumeric characters, alternately referred to as labels. Multiple lines are permitted, in both horizontal and vertical
configurations.

FILE

(SEGMENTS)

Graphic Annotation-Lines or points that have been
added to a "Graph", by graphic cursor input.
Data file

Figure 3-GAMA-l file relationships

The DATA FILES, to be created from raw data by
using computer system's text editor, contain data to be
analyzed by GAMA-l in character strings. The data is

200

National Computer Conference, 1973

classified under four categories, which must follow after
declaration of the headers by the same name. Figure 5
shows an example of the DATA FILE.
/TITLE

"XYZ COMPANY"; "ABC DIVISION";
"CONSOLIDATED SALES"

/TYPE*

MONTHLY FROM 6706 to 6805

/ YUNITS "THOUSANDS $"
/XUNITS "YEARS"
/DATA
255
76

179 87
98

140 82

16 100

Figure 5-A DATA FILE using one year data

It is to noted that:

• A character string following a "/", until a blank
space is encountered, constitutes the HEADER.
Once a header has been declared, it is associated
with the data following it until a new header is declared or an end of file is encountered.
• All information is entered in free format separated
by blanks. The entry of each line is terminated by a
carriage return.
• The actual numbers representing data must start on
the next line following the header / DATA. Also, the
data must be the last entry.
• Length and order of /TITLE, /TYPE, /XU:NITS,
and/YUNITS type information is arbitrary inasmuch as it occurs before I DATA. Any of these types
may also be omitted.
• A ";" in the TITLE type information indicates the
beginning of a new line.
The DATA FILES can be generated either by using a
text editor, from raw data, or from a GAM A FILE segment by using the INTERPRT command in DMM. A
DATA FILE is read only by using the CREATE command in DMM for generation of a GAMMA FILE segment; it is the GAMA FILE segment which is read or
written by all other applications programs. After a
GAMA FILE segment has been made, the corresponding
DATA FILE can be deleted because it can always be
re-created by selection of the INTERPRT command in
the DMM when required.
* Possible types are DAILY, WEEKLY, MONTHLY, PERIODICAL,
QUARTERLY, YEARLY, and PAIRS. In case of PAIRS the format
will be ,'TYPE PAIR nnn, where nnn is the number of pairs; then, in
the lJATA all the X components ot the paw; are llsted firlit iollowed by
the Y components.

Report file
In the Report Generation Mode (RGM), a report page
is first composed in a one dimensional real array, called
Display Data Array (DDA), and later saved as a page in
the REPORT FILE. A report page, i.e., DDA of the
RGM, consists of all information that is on display on the
screen, with exception of the GAMA-1 system prompts.
While in the RGM the DDA always contains all information that is necessary to reproduce the current display.
When a display is saved the DDA is written into the
REPORT FILE on disk with the specified page number.
The DDA may be filled up gradually, via usage of
RGM commands, from information in the GAMA FILE
segments or it can be loaded from an existing page in the
REPORT FILE.
It is to be noted that the information in the DDA is
organized in form of one or more linked display elements.
Each of these elements can be manipulated (i.e., deleted,
moved, etc.) as one unit by the RGM commands. Also,
the other types of display elements have been linked via
pointers to allow one refresh* routine to scan through and
redraw the complete display in DMM, AFM or RGM.
This feature has been made possible by choice of identical structures of the display elements in both GAMA
FILE segments and the display data array.
GAMA-l USAGE CONSIDERATIONS
Because of the system's self-guiding, responsive, and
conversational nature, a GAMA-1 session is naturally
very creative and interesting. Unlike most systems, a user
of GAMA-l is not required to guess and key in the
answers at every stage. All alternatives available to a user
are displayed before him as a menu on the right hand
margin of the display terminal screen, as shown in Figure
6. A selection of any menu item can be readily made by
positioning just the horizontal line of the graphic crosshair cursor over the desired item and touching a key.
Quite often, selection of one menu item results in the
display of a subsidiary menu comprising the alternatives
that are available in relationship to the previously
selected activity. For example, with reference to Figure 6,
once the RGM's DISPLAY command in menu I is chosen, the menu II appears. A convenient mechanism for
transfer of control from one set of activities to another is
built into the system. For example, input of a "$" character in response to any input request, anywhere, results in
cancellation of the going activity and the main menu of
that mode is activated.
After a while in a GAMA-1 session, a display often gets
cluttered because of systems prompts and menus. For
such situations, a clean, clutter-free, and current display
(i.e., showing effect of MOVE and DELETE commands
and addition of any new display elements) can be
* Selection of the REFRESH command clears the entire screen and
displays a fresh page. It is uflen used to redi"play the "amI" informatiull
after erasing the screen. free of the unnece~!'ary clutter.

A Computer Graphics Assisted System for Management

DMM
Aft<'
RGt-:
HELP
EXIT

OSM MAIN MEN\;

~~~rTE
AFM MAIN MENU
GRAPHIC
CROSSHAIR CURSOR

RGM MAIN MENU

LIST

(I. )

DISPLAY MENU IN RGM

(II. )

LIST
JUDGEMENTAL
INSPECTION
PAl RING
CMX-II
AVERAGING
EXPO Sf()OTH
ADAPTIVE
REGRESSION
GRAPH
END

REFRESH
LABEL
I'KlVE
DELETE
SAVE
CLEAR
HELP
END

NO TITLE
NO LABEL
NO AXIS
NO DATA
NO X LAB
NO Y LAB
NO GRID
X LOG
Y LOG
SUB TIC
CENTERED
DASHED
LETTER
POSITION
END

INTERPRT
UPDATE
ZOOM
Sf()OTH
COMBINE
GRAPH
TABLE
DELETE
HELP
END

obtained by either selection of the REFRESH command
or typing an "*,, followed by a carriage return.
Default options

Inasmuch as an extensive usage of the menu mechanism furnishes complete control over selection of data
manipulation, analysis, and forecasting techniques, and
picture (i.e., graph and annotations) manipulation
(Figure 7), certain default options are also available to
the users. For example, referring again to Figure 6, when
menu II is active, selection of END draws the picture
with the alternatives that have been chosen in menu II
and returns control to the main RGM menu, i.e., menu I.
If no alternatives, in menu II, are chosen before END is
activated, a graph using the default options is produced.
As is evident from Figure 6, a GRAPH command for a
quick look at graphic representations of data, without the
ABC Ca1PANY
CONSOLIDATED ORDERS
EXPO SMOOTHED FORECAST

GRAPHS MAY BE

POSITIONED AND
SHAPEo UNDER

~zeeee

~16B08
N

NOiES ANO COMMi:.NTS

MY BE AOOED
WHERE HEEDED

o
5

8009

SMOOTHING CONSTANT = .154
49ae

eI
DRIGINAL DATA

It may be desirable to speed up a GAMA-1 session by
cutting down on the bulk of conversation with the system.
Such a facility is implemented via a control file option. If
this option is selected, completion of a normal GAMA-1
session results in saving of a control file which can later
be executed any number of times to reproduce the same
GAMA -1 session with different sets of data. The system,
when run as governed by a control file, asks only a minimum number of necessary questions. such as identification of the new data, etc.
This option will be particularly appreciated by managers and those users who do not have a need to get into the
"nitty gritty" of the GAMA-l system. They can have a
control file for a session tailored to their requirements by
an analyst and execute it, with their data, for results with
just about no questions asked.

HELP TO USERS
While in the Option Select Mode (OSM), users have a
choice of selecting the HELP Mode for a reasonably
detailed description of the GAMA-1 system. In this mode,
an attempt is made to advise users of the system's various
capabilities and to furnish adequate guidance for their
usage in a conversational style.
A limited (one page only) amount of information pertaining to a particular work mode (e.g., DMM, AFM, or
RGM) is also available if the HELP command is selected
out of the main menu in the respective mode.
THE GAMA-1 RESULTS
Results generated during activities in DMM and AFM
can be saved into the GAM A FILE as new segments or as
replacement of the existing segments. Each of the final
report pages can be saved, with respective page numbers,
into the REPORT FILE.
Figures 8 and 9 are reproductions of true hard copies of
three pages, for example, of a report generated in the
RGM. Tabular outputs are produced separately by each
applications program.
SUMMARY

L
A

Control file option

Izee9

o
o

bother of choosing any display options whatsoever, is also
provided in the DMM and AFM so that application of
right techniques can be facilitated.

Figure 6-Some of the GAMA-l menus

USER CONTROL

201

6!J-7079-71 71-7272-73 73-74
YEARS

Figure 7-Some picture positioning options- A true hard copy of the
display

At last, the long awaited usage of Computer Graphics in
business decision-making is here. It is now also costeffective. Looking ahead, it appears certain that after five
years, if not sooner, we will be able to say that the largest
numbers of applications of computer graphing terminals
are in business, not in computer aided design as today.
Svstems such as GAMA-1 are on the threshold of emergen~e all over. They are very versatile in being potentially
applicable to a variety of business environments, sepa-

202

National Computer Conference, 1973

T38808

~=m

SMOOTHED SEASONALIZED

+-__~~~____~

o
s

SZ~ ~____~______~______

24000

,,\

1970

12000

'I\J

6090

1971

1972

1973

1978 1971 1972. 1973 1974

YEARS

YEARS
ABC COMPANY
TOTAL PRODUCT ORDERS (SOLID LINES)
EXPO SMOOTHED SEASONALIZED FORECAST (DASHEO LINES)

L
L
A
R
S

Dl28e0
~~~-+-7~--+-~~~~--~~----~
o
L

18000

.,. 1/

o
o

4800

~----~------~~~--+-~~~-------i

IJ\

aeee

EXPO SMOOTHED SEASONALIZE0300ae

512000
A

SI8809

TOTAL PRODUCT ORDERS

TOTAL. f'ROOUCT ORDERS

ABC COMPANY FORECAST

ABC COI1PAHY

ABC COMPANY
TOTAL PRODUCT ORDERS

~biAft1'NVI

L
A
R 6800
S

1970

1971

1972

1973

YEARS

1970

1971

1972.

1973

1974

YEARS
Figure 8-Method of inspection in AFM

XYZ COP1PANY'

Wi·lll ~IJlfi II
68

rately as well as a functional module of complex Corporate Information Systems.
Future developments will be in the area taking advantage of distributed computing in business decision support systems, exploiting minis or intelligent terminals for
processing of pictures and small applications functions,
locally, leaving the large number crunching jobs to the big
computers in remote locations. The possibility of simple
turnkey systems using a large mini is also very promising.

ORDER ANALYSIS

48e

This paper would be incomplete without due acknowledgments to Roz Wasilk, my colleague, for her help by participation in discussions, in working out the details in
various file designs, and in programming several modules
of the GAMA-1 software. The author also wishes to
express his sincere gratitude for the foresight demonstrated by Peter G. Cook and Larry Mayhew in accepting
my ideas and furnishing necessary encouragement and
support without which the project would never have gotten off the ground. Finally, my thanks to Judy Rule who
has been a great help by enthusiastically making sure
that the typing and artwork were completed in time, at a
very short notice, and to a number of other individuals
who have contributed to the success of GAMA-l.

vrI~O

T 0

H F

329
0
U 0
S R
A 0 24e

I \

R 160
S S

RAW DATA

iii
72-73

73-74

74-75

FISCAl. YEARS

Figure 9--Two report

ACKNOWLEDGMENTS

page~

REFERENCES
1. Machover, C., "Computer Graphics Terminals-A Backward
Look", AFIPS Conference Proceedin/?s, Vol. 40, 1972, AFIPS Press,
Montvale, N.J., pp. 439-446.
2. Hagan, T. G., Stotz, R. H., "The Future of Computer Graphics,"
AF]PS Conference Proceedings, Vol. 40, 1972, AFIPS Press, Montvale, N.J., pp. 447-452.
3. Miller, I. M., "Economic Art Speeds Business Decision-making",
Computer Decisions, Vol. 4, No.7, July 1972, Hayden Publishing
Co., Rochelle Park, N.J., pp. 18-21.
4. Shostack, K., Eddy, C., "Management by Computer Graphics,"
Harvard Business Review, November-December, 1971, pp. 52-63.
5. Friedman, H., Scheduling with Time-Shared Graphics, Joint
ORSAjTIMSjAIIE Meeting, Atlantic City, N.J., 1972. Unpublished.
6. Curto, C. J., Analytic Systems for Corporate Planning-The
State-of-the-Art, Joint ORSA/TIMS/ AIlE Meeting, Atlantic City.
N.J., 1972. Unpublished.

On the use of generalized executive system software
by WILLIAM

GORMA~

Computer Sciences Corporation
Silver Spring, Maryland

the operating system and of its interface between a job
and the hardware available to perform that job.
It is the purpose of this paper to suggest ways to effectively use a third· generation operating system. Most of
the examples used will be from the most generalized and
complicated of them all-IBM OS/360. Our examination
of operating systems will begin with the typical hardware
resources of a computing plant and the OS response to
those resources. A brief overview of the user tools supplied by the operating system will then be presented, followed by discussions on bugs and debugging and other
problems of performance.
Our conclusion will cover the most valuable and cantankerous resource of all-human. Lack of space prevents
a complete tutorial, but it is the author's hope that many
questions and ideas will be raised in the reader's mind.
Perhaps a thoughtful user may see ways to regain effective use of his computing facility, or as Herb Bright says,
"Learn to beat OS to its knees."

INTRODUCTION
The characteristic of third generation computing systems
that most distinguishes them from previous ones is that
they are designed to perform multiprogramming. The
purpose of multiprogramming is cost-effective utilization
of computer hardware, which is achieved by reducing the
CPU time otherwise lost waiting for completion of I/O or
operator action. An operating system is necessary to
achieve multiprogramming: to schedule jobs, allocate
resources, and perform services such as 1/0.
Since these systems must be very generalized in order
to accommodate the vast spectrum of potential application program requirements, they require some specific
information from the user if they are to perform effectively. To supply the needed information and intelligently
(efficiently) use the system, then, the user must have
some understanding of the operating system's function as
related to his particular needs.
A third generation computing system has so much
generality that to use or understand it one must wade
through stacks of manuals that seem neither clear nor
convenient. Problems plague users, who get caught in a
juggling act with executive system control language. The
unwary become hopelessly involved, generating endless
control card changes, with attendant debugging problems
and loss of valuable personnel time. Other users have
gotten almost mystic about their job control language
(JCL), taking an "it works don't touch it" attitude. With
indirection such as this, even competent organizations can
become very inefficient, using far more hardware, software, and human resources than are actually needed for
the work at hand.
Before we surrender and send out an appeal for the
"save money" salesmen, let's examine the purposes of
executive system software and determine if the application of a little horse-sense doesn't go a long way toward
solving our dilemma. Randal}! notes in his excellent paper
on operating systems that the quite spectacular improvements that are almost always made by tuning services
"are more an indication of the lamentable state of the
original system, and the lack of understanding of the
installation staff, than of any great conceptual sophistic a tion in the tools and techniques that these companies
use." Clearly, the key to effective use is understanding of

HARDWARE RESOURCES

CPU time
The first and most val uable resource we shall examine
is that of computer time itself. Emerson has said, "Econ0my is not in saving lumps of coal but in using the time
whilst it burns." So it is with computer time. Most large
computer shops run their computers 24 hours a day, yet
typically their central processing units are doing useful
work for far too small a percentage of that time.
Cantrell and Ellison 3 note that "The second by second
performance of a multiprogrammed system is always
limited by the speed of the processor or an I/O channel or
by a path through several of these devices used in
series. . .. If some limiting resource is not saturated,
there must be a performance limiting critical path
through some series of resources whose total utilization
adds up to 100%." To achieve the theortical potential of
a computing system, we must manipulate it so as to increase the percentage of resource use. Analysis of the
bottlenecks that cause idle time generally reveals that
resource needs of companion runs are in conflicting demands in such a manner as to gain greater use of the
CPU.
203

204

National Computer Conference, 1973

There are three states of CPU time: wait, system, and
active. System wait time is time when the CPU is idle.
System time is that time spent in supervisory routines,
I/O and other interrupt processing, and error handlingmost of which is considered overhead. Active time is the
time spent executing problem programs. Any reduction of
system or wait time makes more time available for problems, thus contributing to greater efficiency.
I/O channel time
The channel handles the transfer of information
between main storage and the I/O devices and provides
for concurrency of I/O and CPU operation with only a
minimum of interference to the CPU. Whenever I/O
activity overloads a CPU, idle time can result because the
CPU might be forced to wait for completion of I/O activity in order to have data to process. Such cases might be
an indication of poor job mix.
Problems also result from the frequency and duration
of I/O activity. When data is moved in many small
bursts, competition for channels and devices can markedly slow the progress of the operating system.
Main storage
Main storage, or memory, is probably the most expensive and limiting resource in a computing systtm, besides
the CPU itself. Many programs use huge amounts of
memory-often more than is available. Since the consumption of memory by programmers seems, like Parkinson's Law, to rise with availability, it is doubtful that
expansion of memory will alone solve the average main
storage problem. Expansion of memory without a corresponding increase in the average number of jobs residing in memory at execution time is a dubious proposition.
Certain portions of the operating system must reside
permanently in main memory in order to execute; but the
basic system is too large, with many portions too infrequently used, to make it all resident. Memory not used by
the system then serves as a pool of storage from which the
system assigns a partition or region to each job step as it
is initiated.
One memory scheme used by the 360 breaks memory
up into fixed-length parts or partitions, and the user program is allocated the smallest available partition that will
accommodate it. Another 360 scheme has the system allocate (de-allocate) memory at execution time in the specific amounts requested. This method is more complicated, with more overhead, but it permits a greater variation
in the number and size of jobs being executed.
The most common abuse of memory that I have
observed is over-allocation, or more simply the request
for greater amounts of memory than are used. Fragmentation, a particularly frustrating problem, results from
the requirement that memory be allocated to user jobs in
single continuous chunks. As jobs of varying size are given
memory, the memory assignments are at first contiguous

to one another. When a job finishes, the space it occupied
is freed and can be assigned to another job or jobs. However, if subsequent jobs require less than the full amount
vacated, small pieces or fragments of unused memory
occur and must wait until jobs contiguous to them are
ended and can be combined back into usable size. As a
result, when we wish to execute programs with large storage needs, the operator often must intervene and delay
the initiation of other jobs until enough jobs terminate to
create the necessary space. Thus, our CPU can become
partially idle by virtue of our need to assemble memory
into a single contiguous piece large enough to start our
job.
Direct-access storage 4
Direct-access storage is that medium (drum, disk, or
data cell) where data can be stored and retrieved without
human intervention. Modern computing demands could
not be met without direct-access storage, and operating
systems could never reach their full potential without it.
The operating system uses direct-access to store system
load modules and routines for use upon demand. Control
information about jobs waiting to be processed, jobs in
process, and job output waiting to be printed or punched
is stored on direct-access devices by the operating system.
The system also provides facilities whereby user programs have access to temporary storage to hold intermediate data.
Magnetic tapes
Data can be recorded on magnetic tape in so many
different forms that we frequently sacrifice efficiency
through lack of understanding. We often encounter difficulty with I/O errors not because of bad tapes, but rather
due to incorrect identification to the operating system of
recording format and such trivial things as record size.
Further errors can develop from contradictions between
our program's description and the JCL description of the
same data.
We generally inform the operating system of the
recording format, etc., through JCL parameters. The
system provides many services in the handling of tapes,
one of the more important ones being the ability to identify data sets on tape by comparing JCL parameters with
labels written as separate files in front of the data being
identified. In my diagnostic work, I have identified more
I/O errors as due to bad JCL and wrong tape mounts
than as legitimate I/O errors. Due to the perishable
nature of tape, provision for backup must also be made.
Unit-record devices
Printers, card readers, and punches all fit into this
category. The operating system rarely reads or writes user
data directly from user programs to these units. Normally, data input from a card reader or output to a punch or

On The Vse Of Generalized Executive System Software 205

printer is stored as an intermediate file on direct-access
devices, so that the system can schedule the use of these
relatively slow devices independently of the programs
using them. High volume and slow speed can occasionally
cause system degradation.

two programmers in an installation are using a complicated higher-level language, those users can encounter
serious debugging problems for which no help is available
from fellow programmers, due to a lack of expertise in
that language.

SOFTWARE TOOLS

Input/output control systems

Many of the tools of the operating system are independently developed segments or modules collected into libraries for use by the system and the user. Additional
libraries are created to contain installation-developed
routines, programs, and utilities.

The IOCS portion of the system automatically synchronizes 1;0 operations with the programs requesting them,
provides built-in automatic error handling, and is further
extended by system schemes to handle queues of 1;0
requests from many totally unrelated programs. The
system also permits the user to change his output medium
with only a simple change to JCL. Users need to write
1;0 code at the device level only when introducing
unique, special-purpose hardware to a system.

Utilities
Supplied with our operating system are numerous service programs or utilies for performing frequently used
operations such as sorting, copying, editing, or manipulating programs and data. Among the services supplied are
programs to update and list source files, print or punch
all or selected parts of data sets, and compare sets of
data.
Generally these programs are easy to use once learned,
are control card driven, and have" ... the priceless ingredient of really good software, abrasion against challenging
users."2 They are generally stable from operating system
release to release.

User-written utilities
This brings us to the subject of user-written utilities
and programs. A search that I personally made at one
installation uncovered over 20 user-written utilities, all
occupying valuable disk space and all performing the
same function-updating program source files. The only
reason for this that I could discover was that the user was
unable or unwilling to understand the utility already
available. Despite what I termed waste, the writers, to a
man, thought their approach sensible.
Many useful utilities have been user-written, and often
copies can be secured from the writers at no charge or low
charge.

Programming languages and subroutine libraries
Programming languages have been developed to reduce
the time, training, expense, and manpower required to
design and code efficient problem programs. Essentially
they translate human-readable code into machine-readable instructions, thus speeding up the programming process. With these language translators come subroutine
libraries of pretested code to handle functions such as
deriving the square root of a number of editing sterling
currency values.
It is beyond the scope of this paper to discuss language
selection, but one note seems in order. When only one or

Linkers and loaders
The 360 linkage editor combines program segments
that were compiled or assembled separately into a single
program ready to be loaded. We can therefore make
changes without recompiling an entire program. The linkage editor also permits us to create a program too large
for available hardware by breaking it into segments that
can be executed and then overlaid by other segments yet
to be executed.
The loader handles minor linkage tasks and physically
loads into main storage the programs we wish to execute.
JCLASA GLUE
Operating system job control languages (JCL) have
been established to enable us to bypass the operator and
define precisely to the system the work we wish to perform. JCL reminds me of glue: used properly, it's effective; used poorly, it's a mess.
I look upon the differences between the major operating systems as trade-offs between simplicity and flexibility. UNIVAC and most of the others have opted for simplicity, while IBM has stressed flexibility. For example,
UNIVAC uses a very simple control language with singleletter keys that identify the limited range of options
permitted via control card. IBM, on the other hand,
allows extreme flexibility with literally dozens of changes
permitted at the control card level-a not very simple
situation.
I consider 360 JCL to be another language-quite flexible, but unfortunately a little too complicated for the
average user. To execute a job on the 360 we need three
basic JCL cards: a job card to identify our job and mark
its beginning, an execute card to identify the specific
program we wish to execute, and data definition (DD)
cards to define our data sets and the 1;0 facilities needed
to handle them.
When we supply information about a data set via JCL
rather than program code, it becomes easier to change

206

National Computer Conference, 1973

parameters such as block size, type of 1/0 device used,
etc., than it would be with other control languages, simply
because· no recompilation is required as is frequently so
with the other approaches. However, due to the complexity of the process we can unknowingly make mistakes.
For example, to create printed output under 360 OS we
need only code SYSOUT=A on the DD card describing
the data set. Since printed output is usually stored on
intermediate disk files, a block size is needed; but unless
block size is specified, the output may end up unblocked.
Also we might not be able to estimate the volume of
printed output that would be generated before our job
fails for lack of space allocated to handle the printed
output.
Numerous and extremely troublesome problems are
generated when our use of JCL is uninformed or haphazard. The large number of JCL parameters required to
properly execute a job introduces error possibilities due to
sheer volume and an inability to remember every detail
required by a large process. Even proficient JCL users
may require several trial runs to iron out bugs, while
uninformed users frequently give up and instead borrow
JCL that allegedly works, even though that JCL may not
really match their needs. It therefore becomes imperative
that we devise ways to help users assume their proper
responsibilities and get away from JCL as much as possible.
IBM assists by making provisions for cataloged libraries of JCL called procedures. To invoke a p.i'Ocedure, a
user need supply only a job card and an execute card for
each procedure we wish to execute. Within a procedure,
necessary details can be coded in symbolic form, with the
procedure equating our symbols to proper JCL values.
Any value so defined can be changed merely by indicating the symbol and its new value on the execute card
invoking the procedure. We can also add or override DD
cards and DD card parameters by supplying additional
cards containing values to be changed or added.
BUGS AND DEBUGGING
Diagnosing bugs

Diagnosing bugs in user programs requires a clear
understanding of the relationship between system services
and problem programs.
Bugs call to mind complicated dumps and endless
traces, 110 errors that aren't 110 errors at all, and other
frustrating experiences. Certain higher-level languages
include debugging facilities, trace facilities, and other
diagnostic capabilities that can further complicate the
diagnostic process whenever they are unable to properly
field and identify an error.
Our problem, then, in debugging is the rapid reduction
of bugs to their simplest terms, so that proper corrections
can be easily and simply made. Here we see the need for
informed diagnosticians.

Worthwhile procedures for debugging

Often there is more than one path to a problem solution. We should avoid the trial-and-error, pick-andchoose methods because they are expensive and generally
unproductive.
Here is a quick overview of my formula for diagnosing
abnormal terminations ("ABEND"s).
First, examine the operating system's reported cause
for the ABEND. Try to get a clear understanding of why
the operating system thought an error occurred. If any
point is not clear, consult the appropriate reference
manuals. Research the ABEND description until it is
understood.
Before progressing, ask these questions: Can I in general identify the instructions subject to this error? Can I
recognize invalid address values that would cause this
error? If either answer is yes, proceed; if no, dig some
more.
Next, examine the instruction address register portion
of the program status word (PSW) which reveals the
address of the next instruction to be executed. Check the
preceding instruction to see if it was the one that failed. If
this process does not locate the failing instruction, perhaps the PSW address was set as the result of a branch.
Check each register at entry to ABEND. Do they look
valid or do they look like data or instructions? Are a reasonable percentage of them addresses within our region of
memory?
If register conventions are observed, tracing backwards
from the error point might reveal where a program went
awrv. The beautv of higher-level languages is that they
con;istently follo~ some sort of register use convention.
Once these are learned, debugging becomes simpler.
The process just described continues point by point
backwards from the failure to the last properly executed
code, attempting to relate the progress of the machine
instructions back to the original language statements. If
this process fails, attempt to start your search at the last
known good instruction executed and work forward.
The same kind of process is followed with 1/0 errors
and errors in general: first identifying the exact nature of
the error which the system believes to have occurred; next
identifying via register conventions pertinent items such
as the data set in error-going as far back into the machine level code as necessary to isolate the error type.
I have a whole string of questions that I ask myself
when debugging and it seems that I'm forced to dream up
new ones constantly. Let me sum up my approach with
four statements:
• Get a clear understanding of the nature of the error.
• Ask yourself questions that bring you backwards
from failure point to the execution of valid code.
• If this yields nothing, try to approach the error forward, working from the last known valid execution of
code.

On The Use Of Generalized Executive System Software

• If none of these approaches gets results, try recreating the error in a small case. Perhaps you'll find
that the first step-undertanding the error-was not
really completed.

PERFORMANCE PROBLEMS
The improvement of system performance and the elimination of bottlenecks has attracted wide attention of late
perhaps because economy and good business practic~
dictate that it be so. Unfortunately, no cookbook
approach yet exists, and it remains up to us to discover
one for ourselves. The tools are legion,5.6 and are sometimes quite expensive and difficult to interpret. The tools
include accounting data, failure statistics, operator shift
reports, various types of specially developed system interrogation reports, simulations, and hardware and software
monitors. The availability of tools and the level of sophistication of systems personnel may dictate whether these
tools are handled in-house or contracted out on a consulting basis.
Our first step is to outline each system resource to
determine its fit into the overall system scheme and how
our use may affect that fit. A manager might begin this
process with a sort of time and motion study, eliminating
as many handling problems associated with introduction
of jobs to the computer as possible and smoothing the
work flow between users, schedulers, messengers, operators, etc., and the computing system itself. The worst
bottleneck might, in fact, be the one that prevents a tape
or a card deck from being where needed when needed.
Assuming that these things have been accomplished, we
then poll the operators and the users for their impressions
of how well the system serves their needs, at which time
we might be forced to reexamine our work procedures.
Our next step properly belongs to systems programmers. Their study should concentrate on those aspects of
the system that consume the greatest asset of all-time.
There are many techniques and packages available that
measure system activity, and these should be put to work.
Since the system contains the most heavily used code, our
systems programmer places the most active system modules in main memory, intermediate-activity modules in
the fastest available secondary storage hardware such as
drums, and lower-activity modules in larger-volume,
lower-speed (and lower traffic-density) hardware, perhaps large disks or tape. The direct-access addresses of
the most frequently fetched routines ought to be resident
to eliminate searches for them, and where possible these
data sets should reside on the devices with the fastest
access speeds. System data sets on direct-access devices
with movable arms should have the most active of these
routines stored closest to their directories, so that seek
arm travel is kept to a minimum. Educated trial and
error is necessary before reasonable balance in these
areas can be achieved.

207

N ext we study each of the online storage facilities and
their use. Questions as to adequacy, reliability, method of
backup, and recovery ought to be asked. Criteria for the
allocation of direct-access space should be established
based upon criticality of use, volume and frequency of
use, and cost-effectiveness when compared with available
alternatives.
Follow this with the determination and elimination of
unused facilities which should be identifiable through the
tools previously mentioned.
After our system examination comes an examination of
user programs and processes. In this part of our improvement cycle we first look at production programs, starting
with the heaviest users of computer time and resources.
Many times we find them in an unfinished state with
improvements possible through the elimination of ~nnec
essary steps. An important item to observe is the use of
unblocked records or the operation of production programs from source rather than from object or executable
load modules. Production programs that require the
movement of data from card to disk or tape to disk preparatory to use should be avoided when a simple change
to JCL makes this same data available directly to the
program without the intervening steps. What is required
is that an experienced, knowledgeable, and objective eye
be brought to bear upon production programs and other
user processes.
Production programs should be examined to determine
where the most CPU time is spent in executing and, consequently, what code could be improved to yield the best
results.
With OS 360, users can reduce wait time, system time,
channel time, and device time by assembling records into
blocks set as close as possible to addressable size. This
reduces the number of times the I/O routines are
invoked, as well as the number of channel and device
requests and the seek time expended. With blocking,
fewer I/O operations are needed and our programs spend
less time in a nonexecutable state waiting on I/O completion. We gain additionally because blocking permits
greater density on the storage devices. Many users are
unaware of the fact that gaps exist between every record
written on a track of a direct-access device. For example,
the track capacity on an IBM 2314 disk is 7294 characters. If 80-byte card images are written as one block of
7280 characters, only one write is required to store 91
records on a track; yet if these records are written
unblocked, only 40 records will fit on a track because of
the inter-record gaps, and 40 writes are invoked to fill
that track.
Using large block sizes and multiple buffers introduces
additional costs in terms of increased memory required
for program execution. Obviously, we should balance
these somewhat conflicting demands.
A frustrating problem encountered by users of some
systems is that of proper allocation of direct-access space.
Since printed or punched output is temporarily stored on

208

National Computer Conference, 1973

direct-access, such a job's output volume needs to be
known so, that the user can request the necessary space
through his JCL. Jobs can abnormally terminate if insufficient space is allocated to data sets being created or
updated. Over-allocation is wasteful and reduces space
available for other jobs, as well as permitting excessive
output to be created without detection. The space
required should if possible be obtained in one contiguous
chunk, as less CPU time and access time are used than if
data is recorded in several pieces scattered across a unit.
Another problem is locating files or even individual
records within files. The system provides catalogs to point
to the unit upon which a specific data set resides, but
improper use or nonuse of these catalogs or of suitable
substitutes can prevent a job from executing, due to an
inability to identify where the data set resides. The use of
a catalog introduces the problem of searching the catalogs
for the individual data set's identity; and if these catalogs
are excessively long, useful time (both CPU and II 0) can
be lost, since every request for a data set not specifically
identified as to unit results in a search of the system catalogs.
Because of the changing nature of user requirements, a
data set occupying permanently allocated space might
occupy that space long after it is no longer used, simply
because we are unaware of the fact. Techniques exist to
monitor space, but users can easily cheat them.
Proper estimation and allocation of direct-access space
needs is a must, as is the release of unused or temporary
space as soon as its usefulness has ceased. At nearly any
installation one can find unused data sets needlessly tying
up valuable space and sometimes forcing the system to
fragment space requests due to the volume of space so
wasted.
Proper tape handling is mainly a user problem. Blocking should be employed for efficiency's sake. Data should
be blocked to the largest sizes possible, consistent with
memory availability, to reduce the amount of tape
required to contain a data set and the average I/O transfer time consumed per record. Use of the highest densities
provides for faster data transfer and surprisingly greater
accuracy because of the built-in error recovery available
with high density techniques.
To protect tapes from inadvertent destruction the use
of standard-label tapes is encouraged as a site-imposed
standard. This permits the operating system to verify that
the tape mounted by the operators is the one requested by
the user's program.
When processing multiple volume files, two tape drives
should be allocated, if available, to permit a program to
continue processing rather than wait for the mounting of
subsequent tapes when earlier tapes are completed. Further, users should free tape drives not being used in subsequent steps.
Systems programmers usually provide for blocking of
card input and certain output types through default values and control card procedure libraries. Users ought not
to unblock this 1/ O.

Careful reduction of the volume of printed data to that
actually needed by the ultimate recipient serves both the
user and the system by reducing output volume. A typical
high speed printer can consume some 35 tons of paper a
year, and I can't even estimate the average consumption
of cards for a punch unit. Perhaps, like me, you flinch
when you observe the waste of paper at a typical computer site. To further reduce the waste of paper, users are
well advised to go to microfilm where these facilities exist,
particularly for dictionary type output.
It is amazing how many users are still dependent on
punched cards in this generation. Processing large volumes of cards requires many extra 110 operations and
machine cycles that could be avoided by having these
data sets on tape or disk. True, to update a card deck one
only needs to physically change the cards involved; but
the use of proper update procedures with tape or disk is a
far more efficient and accurate use of computer and
human time.
This brings us to the subject of software tool usage. The
most frequent complaints associated with vendor-supplied utilities are that they are difficult to use and that
the documentation is unclear. This is probably due to
their generality. Another difficulty is finding out what is
available.
To answer the difficulty-of-use problem, we might
point out that it is simpler and more productive to try to
understand the utilities available than to write and debug
new ones. A small installation cannot afford the luxury of
user-developed utilities when existing ones will do the job.
Often it is better to search for what one is sure must exist
than to create it. Still another avenue to investigate would
be whether other installations might have the required
service routine developed by their users.
Since available utilities are usually more or less
unknown to installation users, consideration might be
given to assigning a programmer the responsibility of
determining the scope of the utilities available and how to
use them. This information could then be passed on to
fellow programmers. In fact, a good training course would
justify its costs by eliminating unnecessary programming
and enabling installations programmers to select and use
utilities that perform trivial tasks quickly. With vendorsupplied utilities, the first use or two might appear difficult, but with use comes facility.
The use of programming languages ought not be an ego
trip. Programmers should be forced to practice "egoless
programming"7 and to follow recognized practices. Efficiency dictates that programs be written in modular form
and that they be straightforward, well documented, and
without cute programming gimmicks or tricks, lest the
next release of the operating system render the program
nonexecutable. Programmers themselves should realize
that they cannot escape later responsibility for the problems of "tricky" programs, as long as they work for the
same employer.
Our eval uation process then continues with research
into how new programs and problem program systems are

On The Use Of Generalized Executive System Software

tested and developed. It is the writer's experience that
only rarely has much consideration been given to the efficiency of program development and testing. Frequently
the heaviest consumers of computer resources are programmers with trial-and-error methods of debugging and
complex or "clever" coding. Again, understanding the
system can yield us an insight into relative inefficiencies
of program development and how they might be overcome.
Once we have attempted everything within our means,
we might then consider outside performance improvement or consulting services.
A final suggestion on resource consumption is a point
regarding cost allocation. If a resource does not cost the
user, he or she is not likely to try hard to conserve it.
Proper allocation of cost in relation to resource use is both
a form of control and an attempt to influence users to
adjust their demands to the level most beneficial to the
system. In short, users ought not to be given a free ride.

A CASE FOR SPECIALISTS
Merging the many parts of a third generation computing system into an effective problem-solving instrument
requires that we inform the system of a myriad of details.
Efficiency and economy in their most basic forms dictate
that we simplify our work as much as possible. Some way
must be devised to supply to the system with the detail it
needs without typing up some 40 percent (as has actually
happened-I cannot bear to cite a reference) of programmer time with JCL and associated trivia. What we are
striving for is a lessening of the applications programmer's need to know operating system details.
As already noted, the first step is to have knowledgeable system programmers supply as many efficient procedures and other aids as possible and to have them generate a responsive system. Also, those same systems people
can generate libraries of control language to cover all the
regular production runs (and as many of the development
and other auxiliary processes as are practical after sufficient study).
I propose, however, that we go one step further in this
area.

Chief programmer team
One exciting concept to emerge recently has been that
of the Chief Programmer Team. s Significantly increased
programmer productivity and decreased system integration difficulties have been demonstrated by the creation
of a functional team of specialists, led by a chief programmer applying known techniques into a unified methodolog-y. Managers of programming teams would do well
to study this concept. Properly managed, this process has
the programmer developing programs full-time, instead of
programming part-time and debugging JCL part-time.

209

Programmer assistance9
Our examination of the use of third generation systems
has continually pointed out the need for including sufficiently knowledgeable people in the process of system use.
A focal point for users needing assistance should be created. This is usually done anyway informally, as users
search out fellow programmers and systems people who
might have answers to their problems. I propose that
experienced, knowledgeable, and systems oriented people
be organized into a team to answer user questions and to
provide diagnostic assistance. This same group could aid
in developing standards, optimizing program code, and
teaching courses tailored to user needs. My own experience in a programmer assistance center has shown that
such services greatly increases the productivity of a DP
installation's personnel.
Diagnostic services
A cadre of good diagnostic programmers should be used
to assist programmers who are unable to isolate their
program bugs or who need assistance with utilities, JCL,
or any other aspect of the operating system. Such a group
should keep a catalog of the problems encountered for
handy future reference and as a way for determining
personnel training needs or system enhancements. The
group could aid in locating and correcting software errors
by creating small kernels or test programs designed solely
to re-create the error. Through the use of such kernels,
various error solutions could be tested without disturbing
the users main program or process.
Program optimization service
These same personnel might also be charged with
research into and development of simple and efficient
programming techniques. These techniques could then be
implemented in the optimization of the most heavily used
programs or systems. Once we identify our largest program consumers of computer time and their most heavily
used routines, we can find it cost-effective to thoroughly
go over such code, replacing the routines identified with
more efficient ones.
Known programming inefficiencies and their correction
might be identified by an occasional thorough review of
the computer-generated output. For example, the entire
output of a weekend might be reviewed in search of poor
use of I/O processing. Runs with poor system usage might
then be earmarked, and the programmers responsible,
notified and given suggestions for possible improvements.
The most frequently encountered poor practices might
then be subjects of a tutorial bulletin or training session
for programmers.
Conventions and standards
"Standards" is a dirty word to many people, but when
large numbers of programming personnel are found to be

210

National Computer Conference, 1973

employing poor practices, our systems group would be
charged with developing optimum alternatives. Effective
streamlining of frequently used facilities could be accomplished through the publication of tested techniques and
standards or conventions. With standards for guidance,
the user has a yardstick to determine if his utilization of
system resources meets a minimum acceptable level.
Prior to the design of new problem program systems,
these standards would play an important role in ensuring
that optimum use of available facilities was achieved.
"Structured Programming"IO,ll and other developing
techniques for making the programming practice manageable should be researched and used as the basis for developing usable installation standards.

Instructors
The accumulation of expertise within a single group
would be almost wasteful if this knowledge were not disseminated among the users of the system. A logical extension to our assistance group, then, would be the assignment of instructors who would conduct tutorial seminars
and develop tailored training courses and user manuals.
SUMMARY
I have attempted in this paper to give you my views on
coping with a highly generalized operating system. I have
found that complexity is the main problem facing users of
third generation systems. My formula suggests that we
insulate the general user I programmer from OS detail to
the maximum extent possible, and that we provide the
user community with a technically competent consultative group to assist in fielding problems with which the
user need not be concerned.
ACKNOWLEDGMENTS
I wish to extend my sincere thanks and appreciation to
Messrs. Evmenios Damon and Chesley Looney of the

National Aeronautics and Space Administration, Goddard Space Flight Center; Carl Pfeiffer and Ian Bennett
of Computer Sciences Corporation; Dave Morgan of
Boole and Babbage, Inc.; and John Coffey of the National
Bureau of Standards. In particular, I wish to thank Herb
Bright of Computation Planning, Inc., for his many hours
of discussion and words of encouragement.

REFERENCES
1. Randall, B., "Operating Systems: The Problems of Performance
and Reliability," IFlPS 71, vol. 1,281-290.
2. Bright, H. S., "A Philco multiprocessing system," Proc, FJCC'64
Parl II, AFIPS Vol. 26 pp. 97-141, sec. 14 par. 1, Spartan Books,
Washington 1965.
3. Cantrell, H. N., Ellison, A. L., "Multiprogramming System Performance Measurement and Analysis," AFIPS Conference Proceedings SJCC, 1968, pp. 213-221.
4. Gorman, W., Survey and Recommendations for the Use of DirectAccess Storage on the M&DO IBM System/360 Model 95 Computer, Computer Sciences Corporation Document No. 9101-08800OlTM, (Jan. 1973), NASA Contract No. NAS 5-11790.
5. Lucas, H. C., Jr., "Performance Evaluation and Monitoring,"
ACM Computing Surveys, 3,3 (Sept. 71), pp. 79-91.
6. Sedgewick, R., Stone, R., McDonald, J. W., "SPY: A Program to
Monitor OS/360," AFIPS Conference Proceedings FlCC, 1970, pp.
119-128.
7. Weinberg, G. M., The Psychology of Computer Programming. New
York: Van Nostrand Reinhold, 1971.
8. Baker, F. T., "Chief Programmer Team Management of Production Programming," IBM Systems Journal, 11,1 (1972), pp. 56-73.
This topic was also discussed by Harlan Mills of IBM in his paper,
"Managing and motivating programming personnel," given in this
morning's session on Resource Utilization in the Computing
Community.
9, Damon, E. P., "Computer Performance Measurements at Goddard
Space Flight Center," CPEUG-FIPS Task Group 10, National
Bureau of Standards, Oct. 72.
10. Dijkstra, E. W., "The Structure of the "THE" Multiprogramming
System," CACM, 11, May 1968, pp. 341-346.
11. McCracken, D., Weinberg, G., "How To Write a Readable FORTRA~ Program," Datamation, 18,10, Oct. 1972, pp. 73-77.

Language selection for applications
by M. H. HALSTEAD
Purdue University
Lafayette, Indiana

It may strike you as a truism to note that if the solution
to a problem depends upon too many variables, we are
apt to reduce the multiplicity of variables to one, base an
important decision upon that one, and thereafter proceed
as though there had never been, and would never be, any
reasonable alternative to our choice.
This approach, when applied to the problem of choosing a programming language with which to implement a
given class of problems, results in advice of the following
sort: For scientific and engineering problems, use FORTRAN; for problems with large data bases, use COBOL;
for command-and-control, use JOVIAL; and for systems
implementation, use PLj S. Except for academic work
avoid ALGOL; and with respect to those opposite ends of
the spectrum, APL and PLj 1, merely report that you are
waiting to see how they work out. Now, obviously, advice
of this type might be correct, but just as clearly, it will
sometimes be erroneous, primarily because it ignores
most of the variables involved.
It would seem only prudent, therefore, to examine some
of those dimensions along which languages might be
compared, with a view toward increasing our understanding of their relative importance in the decision process.
However, there are four items which we should discuss in
some detail first. These are:

1.
2.
3.
4.

C. Implementation
Cl. Writing Program (Coding)
C2. Preparing Test Data
D. Testing
D1a. Finding :\1inor (Syntactic) Errors
D1b. Correcting }1inor Errors
D2. Eliminating Test
Data Errors
D3a. Finding }lajor (Logical) Errors
D3b. Correcting }Iajor Errors
E. Documenting
Totals

For the first item, I will use the best data of which I am
aware, from an unpublished study of Fletcher Donaldson,l done some years ago. Without presenting the details
of his study, we note that his measurements of programmers in two different installations, when reduced to hours
of programming activity per 40 hour week, yielded the
following figures.
Group 2
Group 1
1.24 Hours/Week
3
4
3

5.60

1.24

7.45

4.95

.31

6.18

1.24

3
40

1.24
40.00

From these data, let us combine those activities which
are almost certainly independent of any language which
might be chosen: Understanding the Objective, and Finding an Approach. For installation 1 this gives 7 hours, and
for installation 2 it gives 7.14 hours, or roughly one day
per week. From this it is apparent that, no matter how
much improvement might be expected from a given language, it can only operate upon the remaining four days
per week.
With respect to the problem of global versus local inefficiencies in programs, there are even fewer data, but the
broad outlines are clear, and of great importance. Let us
look first at local inefficiency. This is the inefficiency in
object code produced by a compiler which results from
the inevitable lack of perfection of its optimizing pass.
According to a beautiful study reported by Knuth,2 the
difference to be expected from a "finely tuned FORTRAK -H compiler" and the "best conceivable" code for
the same algorithm and data structure averaged 40 percent in execution time. This is not to say that the difference between well written machine code and code compiled from FORTRAN will show an average difference of
the fun 40 percent, for even short programs wili seldom
be "the best conceivable" code for the machine.
With the present state of measurements in this area it
is too soon to expect a high degree of accuracy, but let us

How a programmer spends his time.
The difference between local and global inefficiency.
The role of the expansion ratio.
Variance in programmer productivity.

A. Understanding Objective
B. Devising:vI ethods
Bl. Finding Approach
B2. Flow Charting

5.90
1.24
211

212

National Computer Conference, 1973

accept for the moment a figure of 20 percent for the average inefficiency introduced by even the best optimizing
compilers. Now this inefficiency is the only one we are in
the habit of examining, since it applies linearly to small
as well as to large programs, and we are usually forced to
compare only small ones.
The other form of inefficiency is global, and much more
difficult to measure. This is the inefficiency introduced
by the programmer himself, or by a programming team,
due to the size and complexity of the problem being
solved. It must be related to the amount of material
which one person can deal with, both strategically and
tactically, at a given time. Consequently, this form of
inefficiency does not even appear in the small sample
programs most frequently studied. But because programs
in higher level languages are more succinct than their
assembly language counterparts, it is responsible for the
apparent paradox which has been showing up in larger
tests for more than a decade. This paradox probably first
appeared to a non-trivial group during the AF ADA Tests 3
in 1962, in which a Command-and-Control type program
was done in six or seven languages and the results of each
compared for efficiency against a "Standard" done in
assembly language. When the initial results demonstrated
that many of the higher level language versions, despite
their obvious local inefficiencies, had produced object
code programs which were measurably more efficient
than the "Standard," the paradox was attributed to programmer differences, and the entire test was redone. In
the second version, the assembly language version was
improved to reflect the best algorithm used in a higher
level language, and the paradox dissappeared. As recently
as 1972, the paradox was still showing up, this time in the
Henriksen and Merwin study. 4 In that study, several
operating programs which had been written in assembly
language were redone in FORTRAN.
If we direct our attention to their comparison of
FORTRAN V and SLEUTH, the assembly language for
the 1108, we find that two of their three programs gave
the same execution times, while for the third they report:

more than linearly with program size, it follows that
anything which will make an equivalent program
"smaller" in its total impact upon the minds of the programmers will reduce its global inefficiency even more
rapidly than the reduction in size itself. With an expansion ratio of about four, it appears that the effects of
local and global inefficiencies balance for programs of
about 50 statements or 2000 instructions, but these figures are extremely rough.
The fourth item listed for discussion, the variance in
programmer productivity, enters the language picture in
several ways. First, of course, it is because of the large
size of this variance that many of the measurements
needed in language comparisons have been so inconclusive. But this need not blind us to another facet. Since the
time, perhaps 15 years ago, when it was first noted that
chess players made good programmers, it has been recognized that programming involved a nice balance between
the ability to devise good over-all strategie~, and the ability to devote painstaking attention to detail. While this is
probably still true in a general way, the increasing power
of computer languages tends to give greater emphasis to
the first, and lesser to the second. Consequently, one
should not expect that the introduction of a more powerful language would have a uniform effect upon the productivity of all of the programmers in a given installation.
On the basis of the preceding discussion of some of the
general considerations which must be borne in mind, and
leaning heavily upon a recent study by Sammet, 5 let us
now consider some of the bulk properties which may vary
from language to language. While it is true that for many
purposes the difference between a language and a particular compiler which implements it upon a given machine is
an important distinction, it is the combined effect of both
components of the system which must be considered in
the selection process. For that purpose, the costs of some
nine items directly related to the system must somehow
be estimated. These will be discussed in order, not of
importance, but of occurrence.
1. Cost of Learning. If one were hiring a truck driver to

"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."
While the dimensions of global inefficiency have not
yet been well established, it tends to become more important as the size of a job increases. Since it is a non-linear
factor, it overtakes, and eventually overwhelms, the local
inefficiency in precisely those jobs which concern all of us
most, the large ones.
This brings us, then, to a consideration of the Expansion Ratio, the "one-to-many" amplification from statements to instructions, provided by computer languages
and their compilers. Since the global inefficiency varies

drive a truck powered by a Cummins engine, it
would be irrelevant as to whether or not an applicant's previous experience included driving trucks
with Cummins engines. It would be nice if prior
familiarity with a given language were equally
unimportant to a programmer, but such is not quite
the case. The average programmer will still be learning useful things about a language and its compiler
for six months after its introduction, and his production will be near zero for the first two weeks. According to a paper by Garrett,6 measurements indicate
that the total cost of introducing a new language,
considering both lost programmer time and lost
computer runs, was such that the new language must
show a cost advantage of 20 percent over the old in
order to overcome it. Since those data were taken
quite a long while ago, it is probably safe to estimate

Language Selection for Applications

that increasing sophistication in this field has
reduced the figure to 10 percent by the present time.
Cost of Programming. Obviously, this is one of the
most important elements of cost, but difficult to
estimate in advance. If we restrict this item strictly
to the activity classified as C1 in Donaldson's study,
then it would appear to be directly related to the
average expansion ratio obtained by that language
for the average application making up the programming load. Here the average job size also becomes
important, and for a given installation this appears
to increase. In fact, some years ago Amaya7 noted
through several generations of computers, it had
been true that "The average job execution time is
independent of the speed of the computer."
Cost of Compiling. While it has been customary to
calculate this item from measurements of either
source statements of object instructions generated
per unit machine time, some painstaking work by
Mary Shaw8 has recently shown that this approach
yields erroneous results. She took a single, powerful
language, and reduced it one step at a time by
removing important capabilities. She then rewrote a
number of benchmark programs as appropriate for
each of the different compilers. She found that when
compilation time was measured for each of the separate, equivalent programs, then the more powerful
compiler was slower only if it contained features not
utilizable in a benchmark. For those cases in which
a more powerful statement was applicable, then the
lessened speed per statement of the more powerful
compiler was dramatically more than compensated
for by the smaller number of statements in the
equivalent benchmark program.
Cost of Debugging. Here again, since debugging varies directly with the size and complexity of a program, the more succinctly a language can handle a
given application, the greater will be the reduction
in debugging costs. While the debugging aids in a
given compiler are important, their help is almost
always limited to the minor errors rather than the
major ones.
Cost of Optimizing. Since a compiler may offer the
option of optimizing or not optimizing during a given
compilation, it is possible to calculate this cost
seperately, and compare it to the improvements in
object code which result. For example, FORTRANH9 has been reported to spend 30 percent more time
when in optimization mode, but to produce code
which is more than twice as efficient, FORTRANhand, Frailey lO has demonstrated that, under some
conditions optimization can be done at negative cost.
This condition prevails whenever the avoidance of
nonessential instructions can be accomplished with
sufficient efficiency to overcompensate for the cost
of generating them.
Cost of Execution. If, but only if, a good optimizing
compiler exists for a given language, then it can be

213

expected that the local inefficiencies of different
high level languages will be roughly comparable.
The inevitable global inefficiencies will still exist,
however. It is here, as well as in programming cost,
that a language well suited to the application can
yield the greatest savings. Again, the data are inadequate both in quantity and quality, but cost savings
of a factor of two are well within my own experience.
This does not apply to those languages which are
primarily executed in interpretive mode, such as
SNOBOL, where large costs of execution must be recovered from even larger savings in programming
costs.
7. Cost of Documentation. In general, the more powerful, or terse, or succinct a language is for a given
application, the smaller the amount of additional
documentation that will be required. While this is
true enough as a general statement, it can be pushed
too far. It seems to break down for languages which
use more symbolic operators than some rough upper
limit, perhaps the number of letters in natural language alphabets. Allowing for this exception in the
case of languages of the APL class, it follows that the
documentation cost of a language will vary inversely
with the expansion ratio obtainable in the given
applications area.
8. Cost of Modification. Since it is well known that any
useful program will be modified, this item is quite
important. Here any features of a language which
contribute to modularity will be of advantage. Block
structures, memory allocation, and compile time
features should be evaluated in this area as well as
for their effect on initial programming improvement.
9. Cost of Conversion. Since hardware costs per operation have shown continual improvements as new
computers have been introduced, it is only reasonable to expect that most applications with a half-life
of even a few years may be carried to a new computer, hence this element of potential cost should
not be overlooked. If one is using an archaic language, or one that is proprietary, then the cost of
implementing a compiler on a new machine may
well be involved. While this cost is much less than
it was a decade ago, it can be substantial. Even with
the most machine-independent languages, the problems are seldom trivial. Languages which allow
for the use of assembly language inserts combine
the advantage of permitting more efficient code
with the disadvantage of increasing the cost of
conversion. As noted by Herb Bright,11 a proper
management solution to this problem has existed
since the invention of the subroutine, and consists of properly identifying all such usage, and
requiring that it comform to the subroutine linkage
employed by the language.
In examining the preceding nine elements of cost, it is
apparent that many of them depend upon the expansion
ratio of a language in a given application area. In deciding

214

National Computer Conference, 1973

OR.IE""ED

M!.l,<.:..HIN::'
LANGVI'G-E

Figure 1

upon a new language, or between two candidates, it might
be useful to attempt to plot them upon a globe, with longitude representing possible application areas, and latitude
representing any convenient function of the expansion
ratio. The plot should look something like Figure 1, where
it can be seen that languages range from machine language, in which any application may be handled, girdling
the equator, through general purpose, procedure oriented languages in the tropics, to highly specialized,
problem oriented languages in the arctic. The pole,
which implies an infinite expansion ratio for all applications areas, must be reserved for programming via
mental telepathy.
While there is some current research under way12
which may yield more basic insight into the problems in
this area, it is only a year or so old, and the most that can
be said is that it is not yet sufficiently developed to be
of present assistance.
A very interesting technique which has moved part of
the way from research to practice, however, should be
mentioned in conclusion. This involves a practical
approach to the problem of language extension. Unlike
the extensible-language approach, which seemed to open
the door to a dangerous, undisciplined proliferation of
overlapping and even incompatible dialects within a single installation, this alternate approach to language extension is based upon the older concept of precompilers. As
suggested by Garrett 6 and demonstrated by Ghan,12
dramatic savings in programming costs can be achieved
in shops having sufficient work in any narrow application
area. This has been done by designing a higher level,
more specialized language, and implementing a translator
to convert it to a standard procedure oriented language.
In this process, the higher-level language may readily
permit inclusion of statements in the standard procedure
oriented language, and merely pass them along without
translation to the second translator or compiler. This
process, by itself, has the obvious inefficiency that much
of the work done by the first translator must be repeated
by the second. While the process has proved economical
even with this inefficiency, Nvlin!4 has recently demonstrated the ability to reorganize, and thereby remove the

redundant elements, of such a preprocessor-compiler
system automatically, provided that both are written in
the same language.
In summary, let us first note that we have not offered a
simple table with line items of preassigned weights, nor a
convenient algorithm for producing a yes-no answer to the
question "Should I introduce a language specifically to
handle a given class of programming jobs." Instead, we
realize that, with the current state of the art, it has only
been feasible to enumerate and discuss those areas which
must be considered in any sound management decision.
From those discussions, however, we may distill at least
four guidelines. First, it is abundantly clear that great
economies may be realized in those cases in which the
following two conditions prevail simultaneously:
(1) There exists a language which is of considerably

higher level with respect to a given class of applications programs than the language currently in use,
and
{2} The given class of applications programs represents
a non-trivial programming work load.
Secondly, there is important evidence which suggests
that a higher level language which is a true superset of a
high level language already in use in an installation may
merit immediate consideration.
Thirdly, it must be remembered that data based upon
comparisons between small programs will tend to underestimate the advantage of the higher level language for
large programs.
Finally, the potential costs of converting programs written in any language to newer computers should neither be
ignored, nor allowed to dominate the decision process.
REFERENCES
1 Donaldson, F. W., Programmer Evaluation, 1967, unpublished.
2 Knuth, Donald E., "An Empirical Study of Fortran Programs,"
Softwave-Practice and Experience, Vol. 1, ~R 2, April/June
1971, pp. 105-133.
3. The AFADA Tests, conducted by Jordan, were unpublished, but
see Datamation, Oct. 1962, pps. 17-19.
4. Henriksen, J. 0., and Merwin, R. E., "Programming Language
Efficiency in Real-Time Software Systems, SJCC 1972, pp. 155·
161.
5. Sammet, Jean, "Problems in, and a Pragmatic Approach to, Programming Language Measurement." FJCC Vol. 1 39, 1971, pp.
243-252.
6. Garrett, G. A., "Management Problems of an Aerospace Computer
Center." FJCC 1965.
7. Amaya, Lee, Computer Center Operation, unpublished lecture.
8. Shaw, Mary, Language Structures for Contractible Compilers,
Ph.D. Thesis, Carnegie-Mellon University, Dec. 1971.
9. Lowrey, Edward S., Medlock, C. W., "Object Code Optimization"
CACM, Vol. 12, Jan. 1969, pp. 13-22.
10. Frailey, Dennis, A Study of Code Optimization Using a General
Purpose Optimizer, Ph.D. Thesis, Purdue University, Jan. 1971.
11. Bright, Herb, private communications.
12. Halstead, M. H., "Natural Laws Controlling Algorithm Structure,"
SIGPLAN Notices Vol. 7. NR 2, Feb. 1972, pp. 22-26.
13. Ghan, Laverne, "Better Techniques for Developing Large Scale
Fortran Programs," Proc. 1971 Annual ACM Cont. pp. 520-537.
11 "\Tylin, W. C .Jr., S"ructural RCJrga'1ization cf _"\fuitipa" Co'nputc
Programs, Ph.D. Thesis. Purdue. ,June 1972.
r

Information

~etworks-International

Communication Systems Session

A national scientific and technical
information system for Canada

Global networks for information,
communications and computers

by JACK E. BROWN

by KJELL SAMUELSON

National Science Librarian
Ottawa, Canada

Stockholm University and Royal Institute of Technology
Stockholm, Sweden

215

ABSTRACT

Canada is in the process of developing a national scientific and technical information (STI) system. It is
designed to ensure that scientists, researchers, engineers,
industrialists and managers have ready access to any
scientific or technical information or publication required
in their day-to-day work. In 1970 impetus was given the
program when the National Research Council (NRC) was
assigned formal responsibility for planning and development, with the National Science Library (NSL) serving as
the focal point or coordinating agency for local STI services. During the last two years, emphasis has been placed
on the strengthening of two existing networks-a network
of 230 libraries linked to the NSL by the "Union List of
Scientific Serials in Canadian Libraries"-the CANjSDI
network, a national current awareness service at present
using 12 data bases, and linked to the NSL by 350 Search
Editors located in all parts of Canada. This service is
being expanded to provide remote access to the CANjSDI
data bases by an interactive on-line system. In recent
months, steps have been taken to establish regional referral centres and link into the system little used pockets of
subject expertise and specialized STI resources.

When working with the concept of worldwide or global
networks a clear distinction should be made between at
least three different aspects. First of all, information
networks based on globally distributed knowledge has a
long time bearing on accumulated information and data.
Secondly, computer networks that are gradually coming
into existence provide various means of processing new or
already existing information. For some years to come,
computer networks will only to a limited extent provide
adequate information and knowledge support. Thirdly,
communication networks have existed for decades and
are gradually improved by advancements in technology.
The combined blend of all three kinds of international
networks will have a considerable impact on global socioeconomical and geo-cultural trends. If bidirectional
broadband telesatellites and universal, multipoint personto-person communications are promoted, there is hope for
"free flow" of information. It appears recommendable
that resources should be allocated to this trend rather
than an over-emphasis on "massaged" and filtered data
in computer networks.

A position paper-Panel session on intelligent
terminals-Chairman's introduction
by IRA W. COTTON
National Bureau of Standards
Washington, D.C.

Intelligent terminals are those which, by means of
stored logic, are able to perform some processing on data
which passes through them to or from the computer systems to which they are connected. Such terminals may
vary widely in the complexity of the processing which
they are capable of performing. The spectrum ranges
from limited-capability point-of-sale terminals through
moderately intelligent text-oriented terminals up to powerful interactive graphics terminals. The common thread
that ties all these types of terminals together is their processing power and the questions relating to it.

by some 3000 miles, and the U. S. Postal Service
would not have sufficed to meet publication
deadlines.
Van Dam and Stabler of Brown University discuss the opportunities presented by a super intelligent terminal, or "intelligent satellite" in their
terms. Such systems offer the most power, but
also require the most caution, lest this power be
misused or dissipated through poor system design.
It is, of course, impossible to report in advance on the
panel discussion which is part of the session. The position
papers raise most of the issues that I expect will be discussed. Perhaps some means can be found to report on
any new points or insights gleaned from the discussion. In
addition, all of the work is ongoing, and all of the authors
(and the chairman) welcome further discussion beyond
the confineS of this conferenCe.

What, for example, is the proper or most efficient division of labor between the terminals and
the central computer?
What are the limits, if any, to the power which
can be provided in such terminals?
Need we worry about the "wheel of reincarnation" syndrome < ME68 > in which additional
processing power is continually added to a terminal until it becomes free-standing ... and then
terminals are connected to it?

The standards program at NBS requires participation by manufacturers and users.
Englebart specifically invites inquiries regarding
his system in general and the mouse in particular.
The academic community has always been the
most open for critical discussion and the
exchange of ideas.

This session was planned to at least expose to critical
discussion some of these questions, if not answer them.
Position papers were solicited to cover each of the three
points on the spectrum identified above.
Thornton of the Bureau of Standards points out
the need to take a total systems approach and to
develop relevant standards-specifically for
point-of-sale terminals, but the argument applies
to the more sophisticated terminals as well.
Engelbart at Stanford Research Institute discusses his experiences with "knowledge workshop" terminals, and predicts the widespread
acceptance of such terminals by knowledge
workers of all kinds. That day may be nearer
than some might think: two of the three papers
for this session were transmitted to the chairman
via remote terminal, and one was actually
reviewed online in a collaborative mode. In the
latter case, author and reviewer were separated

In short, we recognize that a session such as this may
well raise as many questions as it answers, but we hope
that it may serve as a stimulus to further discussion.
A Short Bibiiography on Inteliigent Terminais
BA173 Bairstow, J. N., "The terminal that thinks for
itself," Computer Decisions, January 1973. pp. 10-13.
BA268 Bartlett, W. S., et aI., "SIGHT, a satellite interactive graphic terminaL" 1968 A CM National Conference, pp. 499-509.
BE71 Bennett, William C. "Buffered terminals for data
communications," TELECOMM, June 1971, p. 46.
CH67 Christensen, C., Pinson, E. N., "Multi-function
graphics for a large computer system," FJCC 1967, pp.
697 -712.
217

218

National Computer Conference, 1973

C068 Cotton, Ira W., Greatorex, Frank S., "Data structures and techniques for remote computer graphics,"
FJCC 1968, pp. 533-544.
CP71 "CPU chip turns terminal into stand-alone machine," Electronics, 44:12, June 7, 1971, pp. 36-37.
CR72 Crompton, J. C., Soane, A. J., "Interactive
terminals for design and management reporting in engineering consultancy," Online 72, International Conference on Online Interactive Computing, Sept. 4-7, 1972,
BruneI University, Uxbridge, England, pp. 187-208.
D072 Donato, A. J., "Determining terminal requirements," Telecommunications, Sept. 1972, pp. 35-36.
EN73 Engelbart, Douglas C., "Design considerations
for knowledge workshop terminals," NCCE 1973.
GI73 Gildenberg, Robert F., "Word processing," Modem Data, January 1973, pp. 56-62.
GR72 Gray, Charles M., "Buffered terminals ... more
bits for the buck," Communication.>; Report, December
1972, p. 39.
H071 Hobbs, L. C., "The rational for smart terminals," Computer, Nov.-Dec. 1971, pp. 33-35.
H072 Hobbs, L. C., "Terminals," Proceedings of the
IEEE, Vol. 60, No. 11, Nov. 1972, pp. 1273-1284.
IB71 "IBM enters terminal in credit checking race,"
Electronics, March 15, 1971, pp. 34/36.
IN72 "Intelligent terminals," EDP Analyzer, 10:4,
April 1972, pp. 1-13.
KE72 Kenney, Edward L., "Minicomputer-based
remote job entry terminals," Data Management, 10:9,
Sept. 1971, pp. 62-63.
KN70 Knudson, D., Vezza, A., "Remote computer display terminals." Computer Handling of Graphical Information, Seminar, Society of Photographic Scientists and
Engineers, Washington, D. C., 1970, pp. 249-268.
MA69 Machover, Carl, "The intelligent terminal."
Pertinent Concepts in Computer Graphics, Proc. of the
Second University of Illinois Conference on Computer
Graphics, M. Fairman and J. Nievergelt (eds.), University of Illinois Press. Urbana, 1969, pp. 179-199.
MA172 Machover, C., "Computer graphics terminalsA backward look," SJCC 1972, pp. 439-446.
MA270 Marvin, Cloyd E., "Smart vs. 'dumb' terminals:
cost considerations," Modem Data, 3:8, August 1970, pp.
76-78.
MC71 McGovern, P. J. (ed.), "Intelligent terminals
start popping up all over," EDP Industry Report, June
30, 1971, pp. 1-7.

ME68 Meyer, T. H., Sutherland, I. E., "On the design
of display processors," CACM, 11:6 June 1968, pp. 410414.
NI68 Ninke, W. H., "A satellite display console system
for a multi-access central computer," Proc. IFIP Congress, 1968, pp. E65-E71.
OB72 O'Brien, B. V., "Why data terminals," Automation, 19:5, May 1972, p. 46-51.
PR71 "Programmable terminals," Data Processing
Mag, 13:2, February 1971, pp. 27-39.
RA68 Rapkin, M. D., Abu-Gheida, O. M., "Standalone/remote graphic system," FJCC 1968, pp. 731-746.
R0172 Roberts, Lawrence G., "Extension of packet
communication technology to a hand-held personal terminal," SJCC 1972, pp. 295-298.
R0272 Rosenthal, C. W., "Increasing capabilities in
interactive computer graphics terminals," Computer,
Nov.-Dec. 1972, pp. 48-53.
R0367 Ross, Douglas T., et al., "The design and programming of a display interface system integrating multiaccess and satellite computers," Proc. A CM / SHARE 4th
Annual Design Autumatiun Wurkshup, Los Angeles, June
1967.
RY72 Ryden, K. H., Newton, C. M., "Graphics software for remote terminals and their use in radiation
treatment planning," SJCC 1972, pp. 1145-1156.
SA71 Sandek, Lawrence, "Once upon a terminal," Think,
37:9, Oct. 1971, pp. 39-41.
SC171 Schiller, W. L., et aI., "A microprogrammed
intelligent graphics terminal," IEEE Trans. Computers,
C-20, July 1971, pp. 775-782.
SC272 Schneiderman, Ron., "Point-of-salesmanship,"
Electronic News, January 17, 1972, pp. 4-5.
SMI71 "Smart remote batch terminals share computer
processing loads," Data Processing Mag., 13:3, March
1971, pp. 32-36.
SM270 Smith, M. G., "The terminal in the terminaloriented system," Australian Compo J., 2:4, Nov. 1970,
pp. 160-165.
TH73 Thornton, M. Zane, "Electronic point-of-sale
terminals," NCCE 1973.
VA73 Van Dam, Andries, Stabler, George M., "Intelligent satellites for interactive graphics." NCC&E 1973.
WE73 Wessler, John J., "POS for the supermarket,"
Modern Data, January 1973, pp. 52-54.

A position paper-Electronic point-of-sale terminals
by M. ZAl\;E

THORNTO~

National Bureau of Standards
Washington, D.C.

The electronic point-of-sale terminal is the newest form
of computer technology being introduced into the retail
industry. Industry interest in the terminal is focused on
its potentially great advantages for retailers in improving
their productivity and performance in merchandise control and credit customer control. The electronic point-ofsale terminal's appeal over the standard cash register lies
in its potential for impacting the total merchandise system through increasing the speed and accuracy of transactions and providing a method of capturing greater
quantities of data essential to the effective management
of the merchandise system. At the check-out counter, the
terminal equipped with an automatic reading device and
credit verification equipment will permit the rapid completion of the sales transaction and, at the same time,
capture and enter into the central system all the data
necessary for closer, more effective control of the merchandise system.
The full potential of the electronic point-of-sale terminal cannot be realized by simply trying to insert it into
the retail environment as a replacement for the electromechanical cash register. The terminal must be effectively integrated into an overall systems approach to the
entire merchandising system. It must be equipped with
an effective capability to automatically read merchandise
tickets and labels; this, in turn, requires the adoption by
the retail industry of merchandise identification standards and either a single technology or compatible technol-

ogies for marking merchandise and automatically reading
the tickets and labels. Further, the terminal must be
effectively integrated with supporting computer systems,
which raises still other needs related to data communications interconnections, network design and optimization,
data standards, and software performance standards and
interchangeability criteria. Without a thorough systems
approach encompassing the entire merchandising system,
the great promise of the electronic point-of-safe terminal
may never be realized; indeed, the terminal could become
the costly instrument of chaos and widespread disruption
in the retail industry.
The ~ational Retail Merchants Association is taking
steps to insure that the proper preparations are made to
smooth the introduction of the electronic point-of-sale
terminal on a broad scale. The Association's first major
objective is to develop merchandise identification standards by the end of 1973. At the request of the NRMA, the
National Bureau of Standards is providing technical
assistance to this effort. Equipment manufacturers, other
retailers, merchandise manufacturers, tag and label
makers, and other interested groups are also involved.
Given the merchandise identification standards, the
emphasis will shift to the implementation of the standards in operational systems where primary effort will be
focused on network design, data communications and
interfacing terminals with computers, and software development.

219

Design considerations for knowledge workshop
terminals
by DOUGLAS C. ENGELBART
Stanford Research Institute
Menlo Park, California

tion is included, not only to provide a guide for selective
follow up, but also to supplement the substance to the
body of the paper by the nature of the commentary.

IN"TRODUCTION
The theme of this paper ties directly to that developed in
a concurrent paper "The Augmented Knowledge Workshop," 1 and assumes that: "intelligent terminals" will
come to be used very, very extensively by knowledge
workers of all kinds; terminals will be their constant
working companions; service transactions through their
terminals will cover a surprisingly pervasive range of
work activity, including communication with people who
are widely distributed geographically; the many "computer-aid tools" and human services thus accessible will
represent a thoroughly coordinated "knowledge workshop"; most of these users will absorb a great deal of
special training aimed at effectively harnessing their
respective workshop systems-in special working methods, conventions, concepts, and procedural and operating
skills.
Within the Augmentation Research Center (ARC), we
have ten years of concentrated experience in developing
and using terminal systems whose evolution has been
explicitly oriented toward such a future environment;
from this background, two special topics are developed in
this paper:

CONTROL MEANS

Introduction
Our particular system of devices, conventions, and
command-protocol evolved with particular requirements:
we assumed, for instance, that we were aiming for a VI:orkshop in which these very basic operations of designating
and executing commands would be used constantly, over
and over and over again, during hour-after-hour involvement, within a shifting succession of operations supporting a wide range of tasks, and with eventual command
vocabularies that would become very large.
THE MOUSE FOR DISPLAY SELECTION
During 1964-65 we experimented with various
approaches to the screen selection problem for interactive
display work within the foregoing framework. The tests 6 •7
involved a number of devices, including the best light pen
we could buy, a joy stick, and even a knee control that we
lashed together. To complete the range of devices, we
implemented an older idea, which became known as our
"mouse," that came through the experiments ahead of all
of its competitors and has been our standard device for
eight years now.
The tests were computerized, and measured speed and
accuracy of selection under several conditions. We
included measurement of the "transfer time" involved
when a user transferred his mode of action from screen
selection with one hand to keyboard typing with both
hands; surprisingly, this proved to be one of the more
important aspects in choosing one device over another.
The nature of the working environment diminished the
relative attractiveness of a light pen, for instance, because
of fatigue factors and the frustrating difficulty in constantly picking up and putting down the pen as the user
intermixed display selections with other operations.

(1) What we (at ARC) have learned about controlling

interactive-display services, and the means we have
evolved for doing it-the partiuclar devices (mouse,
keyset, key board), feedback, and protocol/skill
features; and design data, usage techniques, learnability experience, and design data, usage techniques, learnability experience, and relevant needs
and possibilities for alternatives and extensions.
(2) Our considerations and attitudes regarding the distribution of functions between terminal and
remote shared resources-including assumptions
about future-terminal service needs, our networking experience, and foreseen trends in the associated technologies.
References 2-19 include considerable explicit description of developments, principles, and usage (text, photos,
and movies) to support the following discussion. Annota221

222

National Computer Conference, 1973

The mouse is a screen -selection device that we developed in 1964 to fill a gap in the range of devices that we
were testing. It is of palm-filling size, has a flexible cord
attached, and is operated by moving it over a suitable
hard surface that has no other function than to generate
the proper mixture of rolling and sliding motions for each
of the two orthogonally oriented disk wheels that comprise two of the three support points.
Potentiometers coupled to the wheels produce signals that the computer uses directly for X- Ypositioning of the display cursor. It is an odd-seeming phenomenon, but each wheel tends to do the proper
mix of rolling and sideways sliding so that, as the
mouse is moved, the wheel's net rotation closely
matches the component of mouse movement in the
wheel's "rolling" direction; one wheel controls updown and the other left-right cursor motion.
Exactly the same phenomenon, applied in the mechanical integrators of old-fashioned differential
analyzers, was developed to a high degree of accuracy in resolving the translation components; we
borrowed the idea, but we don't try to match the
precision. Imperfect mapping of the mouse-movement trajectory by the cursor is of no concern to the
user when his purpose is only to "control" the position of the cursor; we have seen people adapt unknowingly to accidental situations where that mapping required them to move the mouse along an arc
in order to move the cursor in a straight line.
That the mouse beat out its competitors, in our tests
and for our application conditions, seemed to be based
upon small factors: it stays put when your hand leaves it
to do something else (type, or move a paper), and reaccessing proves quick and free from fumbling. Also, it
allows you to shift your posture easily, which is important
during long work sessions with changing types and modes
of work. And it doesn't require a special and hard-tomove work surface, as many tablets do. A practiced,
intently involved worker can be observed using his mouse
effectively when its movement area is littered with an
amazing assortment of papers, pens, and coffee cups,
somehow running right over some of it and working
around the rest.
ONE-HANDED, CHORDING KEYSET AS
UNIVERSAL "FUNCTION" KEYBOARD
For our application purposes, one-handed function
keyboards providing individual buttons for special
commands were considered to be too limited in the range
of command signals they provided. The one-handed
"function keyboard" we chose was one having five pianolike keys upon which the user strikes chords; of the
thirty-one possible chords, twenty-six represent the letters
of the alphabet. One is free to design any sort of alphabetic-sequence command language he wishes, and the
user is free to enter them through either his standard
(typewriter-like) keyboard or his keyset.

The range of keyset-entry options is extended by cooperative use of three control buttons on the mouse. Their
operation by the mouse-moving hand is relatively independent of the simultaneous pointing action going on. We
have come to use all seven of the "chording" combinations, and for several of these, the effect is different if
while they are depressed there are characters enterede.g. (buttons are number 1 to 3, right to left) Button 2
Down-Up effects a command abort, while "Button 2
Down, keyset entry, Button 2 Up" does not abort the
command but causes the computer to interpret the
interim entry chords as upper case letters.
These different "chord-interpretation cases" are shown
in the table of Appendix A; Buttons 2 and 3 are used
effectively to add two bits to the chording codes, and we
use three of these "shift cases" to represent the characters
available on our typewriter keyboard, and the fourth for
special, view-specification control. ("View specification"
is described in Reference 1.)
Learning of Cases 1 and 2 is remarkably easy, and a
user with but a few hours practice gains direct operational
value from keyset use; as his skill steadily (and naturally)
grows, he will come to do much of his work with one hand
on the mousp. and the other on the keyset, entering short
literal strings as well as command mnemonics with the
keyset, and shifting to the typewriter keyboard only for
the entry of longer literals.
The key set is not as fast as the keyboard for continuous
text entry; its unique value stems from the two features of
(a) being a one-handed device, and (b) never requiring
the user's eyes to leave the screen in order to access and
use it. The matter of using control devices that require
minimum shift of eye attention from the screen during
their use (including transferring hands from one device to
another), is an important factor in designing display
consoles where true proficiency is sought. This has proven
to be an important feature of the mouse, too.
It might be mentioned that systematic study of the
micro-procedures involved in controlling a computer at a
terminal needs to be given more attention. Its results
could give much support to the designer. Simple analyses,
for instance, have shown us that for any of the screen
selection devices, a single selection operation "costs"
about as much in entry-information terms as the equivalent of from three to six character strokes on the keyset.
In many cases, much less information than that would be
sufficient to designate a given displayed entity.
Such considerations long ago led us to turn away completely from "light button" schemes, where selection
actions are used to designate control or information entry.
It is rare that more than 26 choices are displayed, so that
if an alphabetic "key" character were displayed next to
each such "button," it would require but one stroke on
the keyset to provide input designation equivalent to a
screen-selection action. Toward such tradeoffs. it even
seems possible to me that a keyboard-oriented scheme
could be designed for selection of text entities from the
display screen, in which a skilled typist would keep his
hands un keybuard and his eye~ U11 the :;creen at all time:;,

Design Considerations For Knowledge Workshop Terminals

where speed and accuracy might be better than for
mouse-keyset combination.
NOTE: For those who would like to obtain some of
these devices for their own use, a direct request to us is
invited. William English, who did the key engineering on
successive versions leading to our current models of
mouse and key set is now experimenting with more
advanced designs at the Palo Alto Research Center
(PARC) of Xerox, and has agreed to communicate with
especially interested parties.
LANGUAGE, SKILLS AND TRAINING
I believe that concern with the "easy-to-learn" aspect
of user-oriented application systems has often been
wrongly emphasized. For control of functions that are
done-very frequently ,- payoff in higher efficiency warrants
the extra training costs associated with using a sophisticated command vocabulary, including highly abbreviated
(therefore non-mnemonic) command terms, and requiring
mastery of challenging operating skills. There won't be
any easy way to harness as much power as is offered, for
closely supporting one's constant, daily knowledge work,
without using sophisticated special languages. Special
computer-interaction languages will be consciously developed, for all types of serious knowledge workers, whose
mastery will represent a significant investment, like years
of special training.
I invite interested skeptics to view a movie that we have
available for loan,13 for a visual demonstration of flexibility and speed that could not be achieved with primitive
vocabularies and operating skills that required but a few
minutes (or hours even) to learn. No one seriously expects
a person to be able to learn how to operate an automobile,
master all of the rules of the road, familiarize himself
with navigation techniques and safe-driving tactics, with
little or no investment in learning and training.
SERVICE NETWORK
One's terminal will provide him with many services.
Essential among these will be those involving communication with remote resources, including people. His terminal
therefore must be part of a communication network.
Advances in communication technology will provide very
efficient transportation of digital packets, routed and
transhipped in ways enabling very high interaction rates
between any two points. At various nodes of such a network will be located different components of the network's processing and storage functions.
The best distribution of these functions among the
nodes will depend upon a balance between factors of
usage, relative technological progress, sharability, privacy, etc. Each of these is bound to begin evolving at a
high rate, so that it seems pointless to argue about it now;
that there will be value in having a certain amount of
local processor capability at the terminal seems obvious,

223

as for instance to handle the special communication
interface mentioned above.
EXTENDED FEATURES
I have developed some concepts and models in the past
that are relevant here, see especially Reference 5. A
model of computer-aided communication has particular
interest for me; I described a "Computer-Aided HumanCommunication Subsystem," with a schematic showing
symmetrical sets of processes, human and equipment,
that serve in the two paths of a feedback loop between the
central computer-communication processes and the
human's central processes, from which control and information want to flow and to which understanding and
feedback need to flow.
There are the human processes of encoding, decoding, output transducing -(motor actions), aiid--input
transducing (sensory actions), and a complementary
set of processes for the technological interface: physical transducers that match input and output signal
forms to suit the human, and coding/ decoding processes to translate between these signal forms in providing I! 0 to the main communication and computer
processes.
In Reference 5, different modes of currently used
human communication were discussed in the framework of this model. It derived some immediate possibilities (e.g., chord keysets), and predicted that there
will ultimately be a good deal of profitable research
in this area. It is very likely that there exist different
signal forms that people can better harness than they
do today's hand motions or vocal productions, and
that a matching technology will enable new ways for
the humans to encode their signals, to result in significant improvements in the speed, precision, flexibility, etc. with which an augmented human can control
service processes and communicate with his world.
It is only an accident that the particular physical
signals we use have evolved as they have-the evolutionary environment strongly affected the outcome;
but the computer's interface-matching capability
opens a much wider domain and provides a much
different evolutionary environment within which the
modes of human communication will evolve in the
future.
As these new modes evolve. it is likely that the transducers and the encoding/ decoding processes will be
built into the local terminal. This is one support
requirement that is likely to be met by the terminal
rather than by remote nodes.
To me there is value in considering what I call "The
User-System, Service-System Dichotomy" (also discussed
in 5). The terminal is at the interface between these two
"systems," and unfortunately, the technologists who
develop the service system on the mechanical side of the
terminal have had much too limited a view of the user
system on the human side of the interface.

224

National Computer Conference, 1973

That system (of concepts, terms, conventions,
skills, customs, organizational roles, working
methods, etc.) is to receive a fantastic stimulus and
opportunity for evolutionary change as a consequence
of the service the computer can offer. The user system has been evolving so placidly in the past (by
comparison with the forthcoming era), that there
hasn't been the stimulus toward producing an effective, coherent system discipline. But this will change;
and the attitudes and help toward this user-system
discipline shown by the technologists will make a
very large difference. Technologists can't cover both
sides of the interface, and there is critical need for
the human side (in this context, the "user system")
to receive a lot of attention.
What sorts of extensions in capability and application
are reasonable-looking candidates for tomorrow's "intelligent terminal" environment? One aspect in which I am
particularly interested concerns the possibilities for digitized strings of speech to be one of the data forms handled
by the terminal. Apparently, by treating human speechproduction apparatus as a dynamic system having a limited number of dynamic variables and controllable
parameters, analysis over a short period of the recentpast speech signal enables rough prediction of the forthcoming signal. and a relatively low rate of associated data
transmission can serve adequately to correct the errors in
that prediction. If processors at each end of a speechtransmission path both dealt with the same form of
model, then there seems to be the potential of transmitting good quality speech with only a few thousand bits per
second transmitted between them.
The digital-packet communication system to which the
"computer terminal" is attached can then become a very
novel telephone system. But consider also that then storage and delivery of "speech" messages are possible, too,
and from there grows quite a spread of storage and
manipulation services for speech strings, to supplement
those for text, graphics, video pictures, etc. in the filling
out of a "complete knowledge workshop."
If we had such analog-to-digital transducers at the display terminals of the NLS system in ARC, we could easily extend the software to provide for tying the recorded
speech strings into our on-line files, and for associating
them directly with any text (notes, annotations, or transcriptions). This would allow us, for instance, to use crossreference links in our text in a manner that now lets us by
pointing to them be almost instantly shown the full text of
the cited passage. With the speech-string facility, such an
act could let us instantly hear the "playback" of a cited
speech passage.
Records of meetings and messages could usefully be
stored and cited to great advantage. With advances in
speech-processing capability, we would expect for
instance to let the user ask to "step along with each press
of my control key by a ten-word segment" (of the speech
he would hear through his speaker), or "jump to the next
occurrence of this word". Associated with the existing

"Dialogue Support System" as discussed in Reference 1,
this speech-string extension would be very exciting. There
is every reason to expect a rapid mushrooming in the
range of media, processes, and human activity with which
our computer terminals are associated.
ACKNOWLEDGMENTS
During the 10 year life of ARC many people have contributed to the development of the workshop using the
terminal features described here. There are presently
some 35 people-clerical, hardware, software, information specialists, operations researchers, writers, and
others-all contributing significantly toward our goals.
ARC research and development work is currently
supported primarily by the Advanced Research Projects
Agency of the Department of Defense, and also by the
Rome Air Development Center of the Air Force and by
the Office of Naval Research. Earlier sponsorship has
included the Air Force Office of Scientific Research, and
the National Aeronautics and Space Administration.
Most of the specific work mentioned in this paper was
supported by ARPA, NASA, and AFOSR.
REFERENCES
1. Engelbart, D. C., Watson, R. W., Norton, J. C., The Augmented

Knowledge Workshop, AFIPS Proceedings National Computer
Conference, June 1973, (SRI-ARC Journal File 14724)
2. Engelbart, D. C., Augmenting Human Intellect: A Conceptual
Framework, Stanford Research Institute Augmentation Research
Center, AFOSR-3223, AD-289 565, October 1962, (SRI-ARC Cata·
log Item 3906)
The framework developed a basic strategy that ARC is still following-"bootstrapping" the evolution of augmentation systems by
concentrating on development~ and applications that best facilitate
the evolution and application of augmentation systems. See the
companion paper' for a picture of today's representation of that
philosophy; the old report still makes for valuable reading, to my
mind-there is much there that I can't say any better today.
In a "science-fiction" section of the report, I describe a console
with features that are clear precedents to the things we are using
and doing today-and some that we haven't yet gotten to.
3. Engelbart, D. C., A Conceptual Framework for the Augmentation
of Man's Intellect Vistas," in Information Handling, Howerton and
Weeks (Editors), Spartan Books, Washington, D. C., 1963, pp. 129, (SRI-ARC Catalog Item 9375)
This chapter contains the bulk of the report2; with the main exclusion being a fairly lengthy section written in story-telling, sciencefiction prose about what a visit to the augmented workshop of the
future would be like. That is the part that I thought tied it all
together-but today's reader probably doesn't need the help the
reader of ten years ago did. I think that the framework developed
here is still very relevant to the topic of an augmented workshop
and the terminal services that support it.
4. Engelbart, D. C., Sorenson, P. H., Explorations in the Automation
of Sensorimotor Skill Training, Stanford Research Institute.
NAVTRADEVCEN 1517-1, AD 619 046, .January 1965, (SRI-ARC
Catalog Item 11736).
Here the objective was to explore the potential of using computeraided instruction in the domain of physical skills rather than of
conceptual skills. It happened that the physical skill we chose, to
make for a manageable instrumentation problem, was operating

Design Considerations For Knowledge Workshop Terminals

10.

11.

the five-key chording key set. Consequently, here is more data on
keyset-skill learnability; it diminished the significance of the
experiment on computerized skill training because the skill turned
out to be so easy to learn however the subject went about it.
Engelbart, D. C., Augmenting Human Intellect: Experiments,
Concepts, and Possibilities-Summary Report Stanford Research
Institute, Augmentation Research Center, March 1965, (SRI-ARC
Catalog Item 9691).
This includes a seven-page Appendix that describes our first keyset
codes and usage conventions-which have since changed. Two
main sections of about twelve pages, each of which is very relevant
to the general topic of "intelligent terminal" design, are discussed
above under "Extended Features."
English, W. K, Engelbart, D. C., Huddart, B., Computer Aided
Display Control-Final Report Stanford Research Institute,
Augmentation Research Center, July 1965, (SRI-ARC Catalog
Item 9692).
About twenty percent of this report dealt explicitly with the screenselection tests (that were published later in [7]; most of the rest
provides environmental description (computer, command language,hierarchical file-structuring conventions,etc.) that is interesting only if you happen to like comparing earlier and later stages
of evolution, in what has since become a very sophisticated system
through continuous, constant-purpose evolution.
English, W. K, Engelbart, D. C., Berman, M. A., " Display-Selection Techniques for Text Manipulation," IEEE Transactions on
Human Factors in Electronics, Vol. HFE-8, No.1, pp. 5-15, March
1967, (SRI-ARC Catalog Item 9694).
This is essentially the portion of [6] above that dealt with the
screen-selection tests and analyses. Ten pages, showing photographs of the different devices tested (even the knee-controlled
setup), and describing with photographs the computerized selection
experiments and displays of response-time patterns. Some nine
different bar charts show comparative, analytic results.
Licklider, J. C. R., Taylor, R. W., Herbert, E., "The Computer as a
Communication Device," International Science and Technology,
No. 76, pp. 21-31, April 1968, (SRI-ARC Catalog Item 3888).
The first two authors have very directly and significantly affected
the course of evolution in time-sharing, interactive-computing, and
computer networks, and the third author is a skilled and experienced writer; the result shows important foresight in general, with
respect to the mix of computers and communications in which
technologists of both breeds must learn to anticipate the mutual
impact in order to be working on the right problems and possibilities. Included is a page or so describing our augmented conferencing experiment, in which Taylor had been a participant.
Engelbart, D. C., Human Intellect Augmentation Techniques,
Final Report Stanford Research Institute, Augmentation Research
Center, CR-1270, N69-16140, July 1968, (SRI-ARC Catalog Item
3562).
A report especially aimed at a more general audience, this one
rather gently lays out a clean picture of research strategy and environment' developments in our user-system features, developments
in our system-design techniques, and (especially relevant here)
some twenty pages discussing "results," i.e. how the tools affect us,
how we go about some things differently, what our documentation
and record-keeping practices are, etc. And there is a good description of our on-iine conferencing setup and experiences.
Engelbart, D. C., "Augmenting Your Intellect," (Interview With D.
C. Engelbart), Research Development, pp. 22-27, August 1968,
(SRI-ARC Catalog Item 9698).
The text is in a dialog mode-me being interviewed. I thought that
it provided a very effective way for eliciting from me some things
that I otherwise found hard to express; a number of the points
being very relevant to the attitudes and assertions expressed in the
text above. There are two good photographs: one of the basic work
station (as described above), and one of an on-going augmented
group meeting.
Engelbart, D. C., English, W. K, "A Research Center for Augmenting Human Intellect," AFIPS Proceedings-Fall Joint Com-

225

puter Conference, Vol. 33, pp. 395-410, 1968, (SRI-ARC Catalog
Item 3954).
Our most comprehensive piece, in the open literature, describing
our activities and developments. Devotes one page (out of twelve)
to the work-station design; also includes photographs of screen
usage, one of an augmented group meeting in action, and one showing the facility for a video-based display system to mix cameragenerated video (in this case, the face of Bill English) with computer-generated graphics about which he is communicating to a
remote viewer.
12. Haavind, R., "Man Computer 'Partnerships' Explored," Electronic
Design, Vol. 17, No.3, pp. 25-32, 1 February, 1969, (SRI-ARC
Catalog Item 13961).
A very well-done piece, effectively using photographs and diagrams
to support description of our consoles, environment, working practices, and experiences to a general, technically oriented reader.
13. Augmentation of the Human Intellect-A Film of the SRI-ARC,
Presentation at the 1969 ASIS Conference, San Francisco, (A 3Reel Movie). Stanford Research Institute, Augmentation Research
Center, October 1969, (SRI-ARC Catalog Item 9733).
14. Field R. K., "Here Comes the Tuned-In, Wired-Up, Plugged-In,
Hyperarticulate Speed-of-Light Society-An Electronics Special
Report: No More Pencils, No More Books-Write and Read Electronically," Electronics, pp. 73-104, 24 Kovember, 1969, (SRIARC Catalog Item 9705).
A special-feature staff report on communications, covering comments and attitudes from a number of interviewed "sages." Some
very good photographs of our terminals in action provide one
aspect of relevance here, but the rest of the article does very well in
supporting the realization that a very complex set of opportunities
and changes are due to arise, over many facets of communication.
15. Engelbart, D. C., "Intellectual Implications of Multi-Access
Computer Networks," paper presented at Interdisciplinary Conference on Multi-Access Computer Networks, Austin, Texas, April
1970, preprint, (SRI-ARC Journal File 5255).
This develops a picture of the sort of knowledge-worker marketplace that will evolve, and gives examples of the variety and flexibility in human-service exchanges that can (will) be supported. It
compares human institutions to biological organisms, and pictures
the computer-people networks as a new evolutionary step in the
form of "institutional nervous systems" that can enable our human
institutions to become much more "intelligent, adaptable, etc."
This represents a solid statement of my assumptions about the
environment, utilization and significance of our computer terminals.
16. Engelbart, D. C., SRI-ARC Staff, Advanced Intellect-Augmentation Techniques-Final Report, Stanford Research Institute,
Augmentation Research Center, CR-1827, July 1970, (SRI-ARC
Catalog Item 5140).
Our most comprehensive report in the area of usage experience and
practices. Explicit sections on: The Augmented Software Engineer,
The Augmented Manager, The Augmented Report-Writing Team,
and The Augmented Presentation. This has some fifty-seven screen
photographs to support the detailed descriptions; and there are
photographs of three stages of display-console arrangement
(including the one designed and fabricated experimentally by
Herman Miller, Inc, where the keyboard, keyset and mouse are
built into a swinging control frame attached to the swivel chair).
17. Roberts, L. C., Extensions of Packet Communication Technology
to a Hand Held Personal Terminal, Advanced Research Projects
Agency. Information Processing Techniques, 24 January, 1972.
(SRI-ARC Catalog Item 9120).
Technology of digital-packet communication can soon support
mobile terminals; other technologies can soon provide hand-held
display terminals suitable for interactive text manipulation.
18. Savoie, R., Summary of Results of Five-Finger Keyset Training
Experiment, Project 8457 -21, Stanford Research Institute, Bioengineering Group, 4, p. 29, March 1972, (SRI-ARC Catalog Item
11101).

226

National Computer Conference, 1973

Summarizes tests made on six subjects, with an automated testing
setup, to gain an objective gauge on the learnability of the chording
keyset code and operating skill. Results were actually hard to
interpret because skills grew rapidly in a matter of hours. General
conclusion: it is an easy skill to acquire.
19. DNLS Environment Stanford Research Institute, Augmentation
Research Center, 8, p. 19, June 1972, (SRI-ARC Journal File
10704).
Current User's Guide for ARC's Display Online :::System (DNLS).
Gives explicit description on use of the keyset, mouse, and the
basic interaction processes.

APPENDIX B: PHOTOGRAPHS

APPENDIX A: MOUSE AND KEYSET, CODES
AND CASES

Note: We generally use the keyset with the left hand;
therefore, "a" is a "thumb-only" stroke. Of the three buttons on the mouse, the leftmost two are used during keyset input effectively to extend its input code by two bits.
Instead of causing character entry, the "fourth case"
alters the view specification; any number of them can
be concatenated, usually terminated by the "P' chord to
effect a re-creation of the display according to the altered view specification.

~Iouse

010
-1-

000

Buttons:
Case

-0-

100

110

-2-

-3-

Figure I-Our current standard work station setup: Mouse in right
hand controls cursor on screen: keyset under left hand supplements
keyboard for special, two-handed command execution operation.
Separation of control and viewing hardware is purposeful, and
considered by us to be an advantage enabled by computerized work
stations.

Keyset Code

0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X

0
0
0
0
0
0
0
X
X
X
X
X
X
X
X
0
0
0
0
0
0
0
0
X
X
X
X
X
X
X
X

0 0
0 X
0 X
X 0
X 0
X X
X X
0 0
0 0
0 X
0 X
X 0
X 0
X X
X X
0 0
0 0
0 X
0 X
X 0
X 0
X X
X X
0 0
0 0
0 X
0 X
X 0
X 0
X X
X X

X
0
X
0
X
0
X
0
X
0
X
0
X
0
X
0
X
0
X
0
X
0
X
0
X
0
X
0
X
0
X

a
b
c
d
e
f
g
h

A
B
C
D

#
$

%
&

j
k
1
m
n

F
G
H
I
J
K
I
M
N

p
q
r

p
q
R
S
T
U

t
u
v
w
x
y
z

V
W

X
Y
Z

(
)
@

+
/
0
1

2
3
4

5
6
7
8
9

<
>
SP

ALT
/
TAB CR

show one level less
show one level deeper
show all levels
show top level only
current statement level
re-create display
branch show only
goff
show content passed
i or k off
show content failed
show plex only
show statement numbers
hide statement numbers
frozen statement windows
frozen statement off
show one line more
show one line less
show all lines
first lines only
inhibit refresh display
normal refresh display
all lines, all levels
one line, one level
blank lines on
blank lines off
(nothing)
(nothing)
(nothing)
centerdot
(nothing)

Figure 2-Closeup of Keyset. Finger pressure and key travel are quite
critical. It took many successive models to achieve a really satisfactory
design.

Figure 3-Closeup of Mouse. There are characteristics of the "feel,"
depending upon the edging of the wheels, the kind of bearings, etc. that
can make considerable difference. We happened to hit on a good
combination early, but there have been subsequent trials (aimed at
improvements, or where others more or less copied our design) that
didn't work out well. The play in the buttons, the pressure and actuating
travel, are also quite important.

Design Considerations For Knowledge Workshop Terminals

Figure 4-Clostmp of underside of mouse (old model), showing
orthogonal disk-wheels. We now bring the flexible cable out the "front."
Size and shape haven't changed, in later models. Bill English (the
operator in Fig. 1, and mentioned in the text above) is now
experimenting with new mouse sizes and shapes.

227

Intelligent satellites for interactive graphics*
by ANDRIES VAN DAM
and
GEORGE M. STABLER
Brown University
Providence, Rhode Island

mainframe or human command. Xote that if the terminal
contains a mini, micro or microprogrammable computer
which runs a standard program to service the terminal,
and not arbitrary, user loaded programs, the terminal has
a fixed function and is still just an intelligent terminal by
our definitiont (e.g., a VIATRON, or SYCOR alphanumeric display). Only when the device contains a general
purpose computer which is easily accessible to the ordinary user for any purpose and program of his choice, do
we promote the terminal to an intelligent satellite
(computer). Note that this notation is in conflict with that
of Hobbs who calls this last category smart or intelligent
terminal, and does not discuss our class of intelligent
terminals. Machover's19 definition tallies more with ours
since his intelligent terminal could be constructed purely
with nonprogrammable hardware (e.g., the Evans and
Sutherland LDS-l display).
Our view of the idealized intelligent satellite is one
which is powerful enough to run a vast number of jobs
(e.g., student programs) completely in stand alone mode.
In satellite mode it uses the host less than 50 percent of
the time, as a fancy "peripheral" which supplies an archival (possibly shared) database, massive computational
power (e.g., floating point matrix inversion for the analysis part of the application), and input/ output devices
such as high speed printers, plotters, microfilm recorders,
magnetic tape, etc.

INTRODUCTION

Semantics
In the last four or five years it has become increasingly
fashionable to speak of "intelligent," "smart," or "programmable" terminals and systems. Very few mainframe
or peripheral manufacturers omit such a device from
their standard product line. Although "intelligence,"
like beauty or pornography, is in the eye of the beholder,
the adjective generally connotes that the device has a
degree of autonomy or processing ability which allows it
to perform certain (classes of) tasks without assistance
from the mainframe to which it is connected. Many such
devices are programmable by virtue of including a mini,
microprogrammable or micro computer.**
While operational definitions are pretty hazy and nonstandard, we call a device a terminal if a user interacts
with a mainframe computer (host) through it (e.g., a teletype or an alphanumeric display console). Hobbs 15
lists 6 classes ofterminals:**
(1) keyboard/ printer terminals;
(2) CRT terminals;

(3)
(4)
(5)
(6)

remote-batch terminals;
real-time data-acquisition and control terminals;
transaction and point-of-sale terminals;
smart terminals.

We consider the terminal to be intelligent if it contains
hard, firm, and/ or software which allows it to perform
alphanumeric or graphic message entry, display, buffering, verifying, editing, and block transmissions, either on

Distributed computing
The term "distributed computing" refers both to
devices at remote locations, and logic up to the point of a
programmable computer, which has been used to enhance
the intelligence of the devices.t Such distributed or

* The research described in this paper is supported by the National
Science Foundation, Grant GJ -28401X, the Office of Naval Research,
Contract N00014-67-A-0191-0023, and the Brown University Division of
Applied Mathematics.
** A synonym is the "Computer on a Chip," e.g., the INTEL 8008.

t This is true even if the program can be modified slightly i or replaced

* * * Rather than repeating or paraphrasing the several excellent surveys
on terminals here, the reader is referred directly to them. Suggested are
References 4,6,15 and 19, as well as commercial reports such as those
put out by Auerbach and DataPro.

:j: Note that the development of ever more sophisticated channels and
device controllers started the trend of distributing intelligence away
from the CPU. (Programmable) data concentrators and front end processors are further extensions of the principle.

in the case of Read Only Memory) to allow such things as variable field
definitions on a CRT displayed form, etc.)

229

230

National Computer Conference, 1973

decentralized computing with remote intelligent terminals
and especially satellites is a fact of life today. This is so
despite the attempts by most computer center administrators in the middle and late 1960's to have individual
and department funds pooled to acquire a large, central,
omni-purpose computer satisfying everyone's needs.
Indeed, the hardware architects,12 (ACM 72 National
Conference panel participants) are predicting even more
decentralization, with complete mini or micro computers
in homes, offices, and schools, both to provide programmable intelligence to terminals and peripherals, and to
serve as local general purpose computers for modest processing tasks. Some of the reasons for this phenomenon are
psychological, others technical:
(1) The hardware technology has made it possible; the
price of mass produced logic and memory (even of
small disks and drums) has decreased dramatically, and more so for mini's than for mainframe
hardware; even Foster's "computer on a chip"12 is a
reality before his predicted 1975 date. Consequently, minis (and even midis) have become
widely affordable; OEM minis may be part of scientific equipment or of terminals costing under
$7,000! This is partially due to the pricing structure
of the mini manufacturers who do not tack on mainframe manufacturer's type overhead for such frills
as universal software and customer services.

(d) The corresponding conservation of resources, of
both mainframe and communications link, due
to fewer and more compact interactions and
transmissions; the vastly superior user response
time (especially given the saturated multi-programmed or time-shared operating systems
typical today); and the real or "funny" money
savings of not unnecessarily using the host.
(e) The ability to do (significant) work, minimally
message composition using simple cassettes,
while the host is down or a core partition for
the applications program is not available.
(f) Returning to the transmission link, the advantage of being able to live without its constant
availability; incurring fewer errors due to lesser
use; being able to be satisfied with a lower
speed and therefore less delicate, more widely
available and lower cost link.
(g) The ability, with sufficient intelligence, to
emulate existing older devices, to the point of
providing with one device "plug for plug compatible" replacements for several existing ones.
(h) And finally, the enormous advantage of having
locally, hopefully general purpose, processing
power for arbitrary customization.
An outline of potential problem areas

(2) The advantages of distributed (remote) logic and
computing are indisputable:
(a) the convenience and psychological advantage of
having a terminal or remote job entry station in
or near your office, especially if it can do simple things like accumulate messages and print
or edit them locally.
(b) in the ideal case, the even greater convenience
and sense of power rightfully restored to someone who controls the destiny of his very own
little, but complete, computer system. No more
fighting with the computing center, or contending with other users for scarce resources; presumably less lost data and fewer system
crashes since there's no interuser interference
within a fragile operating system. (To be fair, if
the local machine is then hooked into the central host in satellite mode, the problems of reliability may be worse, due to communications
errors for example.)
(c) The advantage of avoiding extraneous user
effort by being able to build a message or a
picture* locally, and immediately verify and
edit it, before entering information into the
mainframe; this convenience is in contrast to
cycles of enter I verify I correct steps which are
separated in time.

While distributed logic and computing offer genuinely
enhanced capability and cost effectiveness, a number of
problems which the user ought to be aware of do crop up.

" Let alone scaling and rotating it, doing lightpen tracking to build it.
etc.

** Note that if the device does contain a user accessible general purpose

Hardware problems
(a) Either you choose among the many off-the-shelf
software supported, but unchangeable devices, ** or
(b) you build yourself, in hardware, or preferably in
firmware, a customized terminal just right for your
application. You then have to implement your
device and the supporting software, both probably
incompatible with anybody else's gear.

Inte rfacing problems
(a) If you buy a standard device, connected over a
standard (channel or front end) interface, you
might be lucky and have no operating system support problems. The non-standard device might need
a special purpose interface and might not be recognized (the "foreign attachment" gambit). Even
standard interfaces are notorious for crashing operating systems. In any case, "mixed systems" containing multiple vendor hardware are coming of
age, but lead to many "our system works, it must

computer, inflexibility may be tempered with appropriate software.

Intelligent Satellites for Interactive Graphics

be their system" traumas. As an aside, maintenance on the device may not be cheap, so many
installations use "on call" arrangements.
(b) To make interfacing easy, obtain flexible remoteness, and avoid the foreign attachment maintenance support problem, telephone communications
links are very popular. Modems and lines are
expensive for more than 1200 baud transmission,
however, and even low speed lines are notoriously
noisy (especially in rainy weather)!
Host operating system support

Terminal systems today generally are supported with a
host operating system: minicomputers rarely are. Homebrew customized systems, by definition, are not. Providing your own host support at the II 0 level for such systems is usually a reasonable task for experienced systems
programmers; higher level, truly integrated support,
however, may be a real research problem.
Local software support

This type of support ranges from minimal (say a local
assembler) to reasonably complete; for a mini it is often a
full disk operating system, with FORTRAN and, if you're
very lucky, a cross compiler for a higher level procedural
language, which compiles on the host, and produces code
for the satellite. Even if a standard language like FORTRAN is available on both host and satellite, thereby
obviating having to learn to program in two languages, the
versions will be incompatible, due to differences in architecture and instruction set of the machines, and in compiler implementation.
Reserving host resources

Making sure that real (or virtual) core and disk space
are available for the new device is an often overlooked or
underestimated problem.
THE EVOLUTION FROM TERMINAL TO
SATELLITE
Despite all the facilities intelligent terminals provide,
they still contribute only a relatively small (but possibly
quite sufficient) amount of processing power to the total
needs of the program or system. For example, display
regeneration and housekeeping, communications handling, and simple local interrupt fielding are typical tasks
which can be allocated to an intelligent terminal for interactive graphics. Such functions can be lumped together
into an area we will call "hardware enhancement." This
term is meant to indicate that the basic goal to which the
intelligence of the terminal is being directed is the sim ulation of a more sophisticated piece of hardware. Raising
the level of the interface which the terminal presents to

231

Figure 1

the mainframe effectively lightens the load placed on the
mainframe by simplifying the requirements of the low
("access method" or "symbiont") level support for the
terminal.
The operational distinction we have made between
intelligent terminals and satellites is the use to which the
intelligence of the remote terminal system is put. For
intelligent terminals this intelligence is primarily directed
into areas such as hardware enhancement and low level
support. On the other hand, the intelligence of a satellite
is sufficiently high to allow it to be applied directly to the
processing requirements of the application program.
(Some hardware implications of this requirement are
discussed below.)
The transformation of an intelligent terminal into a full
satellite is a long and, as Myer and Sutherland have
pointed oue o somewhat addictive process (" ... for just a
little more money, we could ... "). For example, in the
graphics case, one first adds a data channel to mainframe
core to service the display. Then special display registers
and channel commands are incrementally added. A local
memory is inserted to free mainframe core. The display is
given its own port (i.e., primitive data channel) into the
local memory, and the wheel of reincarnation is rolling.
The end result of this process is a system of the general
form shown in Figure 1.
THE SATELLITE

CONFIGURATIO~

The diagram in Figure 1 says nothing about the power
or complexity of the various components. As Foley 11 has
pointed out, there are many ways in which the pieces of
such a satellite system can be chosen. and the implementation of an optimal (highest cost/ performance ratio)
configuration for a particular application may entail the
examination of hundreds or even thousands of different
combinations of subsystems. In the following, we are not
as concerned with optimality as with defining a lower
bound on the total processing power of the satellite below
which it becomes infeasible to view the satellite as a general processor (at least for the purpose of satellite graphics).
The argument for having a satellite system as opposed
to an intelligent terminal is to do nontrivial local processing (real-time transformations and clipping, local attention handling, prompting. providing feedback, data-hase
editing, etc.), while leaving large-scale computation and
data-base management to the mainframe. In order to
perform satisfactorily for a given (class of) job(s), the
satellite must possess "critical intelligence." Analogous to

232

National Computer Conference, 1973

the "critical mass" concept, critical intelligence defines a
threshold of local power which allows the majority of
tasks to be executed locally without recourse to the mainframe; it is a complex and application-dependent figure
of merit describing such parameters as the architecture
and instruction set of the processor, and the primary and
secondary storage capacity and access time. It is unfortunately not readily expressed quantitatively, although
Foley does try to quantize trade-offs for several classes of
applications. Below critical intelligence, i.e., if the satellite does not have (reasonably fast) secondary storage,
sufficient local memory, and a powerful instruction set, it
simply may not be able to do enough processing fast
enough to make the division of labor worthwhile. Many
minicomputers used as satellites have too few generalpurpose registers and core, inadequate bit and byte
manipulation instructions, and minimal operating systems. On such machines, it is seldom possible to handle
non-trivial applications programs in stand-alone mode
satisfactorily (i.e., not just drawing, but handling data
structure editing as well), manufacturers' claims notwithstanding.*
In some cases, the shortcomings of a standard minicomputer can be overcome by the use of microprogramming. Microprogrammed processors have a very real
advantage over those which are hardwired in that it is
frequently possible to redefine a weak architecture or
instruction set. Hardware deficiencies such as minimal
core may be offset by, for example, an instruction set
which has been designed to accommodate often used algorithms. Entire subroutines or their most critical parts
may be put in the firmware. An example of the considerable savings in core and execution time which can be
achieved with thoughtful firmware instruction set design
is described in Reference 2.
Given a satellite system sufficiently powerful to run
stand-alone applications, the question arises, "Why go
on?" If the satellite has gone once around the wheel and
has become self-sufficient, we no longer have a satellite,
but another mainframe, and the need for satellite/mainframe interaction disappears. Indeed, this approach was
taken, for example, by Applicon, Inc., whose IBM 1130/
storage tube system has been carefully and cleverly tailored to a modest application (lC layout), providing one
of the few money making instances of computer graphics. 3
ADAGE'sI3 more powerful midi systems also were
enhanced for example with a fast, high-capacity disk to a
point where they support a wide variety of graphic applications without recourse to an even larger computer.
If stand-alone mode is no longer sufficient, the local
system may again be enhanced, but in most cases a duplication of facilities with an existing large mainframe is not
* Yet it is astonishing how many programmers who would not dream of
writing a program in 32 kilobytes of 360 user core, with the powerful 360
instruction set and good disks behind it, have the chutzpah (typically
justly rewarded) to write the same program for a 32-kilobyte mini with a
slower, more primitive architecture and instruction set and a painfully
,.,luw tli"h..

cost effective, and a crossover point is reached at which
communication with the mainframe becomes cheaper
than satellite enhancement. In a sense, the satellite is a
saddlepoint (an optimal strategy) in the range of configurations bounded at one end by simple display terminals
and at the other by full stand-alone graphics processors.

SOFTWARE STRATEGIES AND APPLICATIONS
Given the typical hardware configuration outlined
above, it is interesting to examine some of the ways in
which such systems have been utilized. These will be presented roughly in order of increasing utilization of the
satellite's intelligence.

Hardware enhancement
At the low end of the spectrum, the facilities of the satellite system are used soley to complement capabilities of
the display processor. In such systems, the display processor can typically do little more than display graphic
data out of a contiguous data list in core. All other display
functions-subroutining, transformations, windowing,
clipping, etc.-are performed by the satellite processor.
Little if any processing power is left over for more application-oriented processing. In fact, there is little difference between a satellite used in this manner and an intelligent terminal; the approach is noted here only because
some intelligent terminals may have the hardware structure described in Figure 1.

Device simulation/emulation
Another "non-intelligent" use of a satellite is to emulate and/ or simulate another display system. The rationale for this is almost always the presence of a large package of existing software for the display being emulated.
Rather than discard many man-years of software development, the choice is made to under-utilize the facilities
of the satellite system in order to support the existing
applications. Another reason for using the satellite in
simulation/ emulator mode is that it may be possible to
provide higher performance and access to new facilities
for existing programs (e.g., control dial and joystick input
for a 2250 program). In addition, satellite simulation may
allow remote access graphics (over telephone lines or a
dedicated link) where not previously possible. **
At Brown, we have implemented three such systems to
provide support for IBM 2250 Mod 1 and Mod 3 programs. Two of these were simulators using an IBM 1130/
2250 Mod 427 and an Interdata Mod 3/ ARDS storage
** As a commercial example, ADAGE is now offering a display system
with simulator software incorporating man\' of these ideas [ADAGE,
Ul7:2J.

Intelligent Satellites for Interactive Graphics

tube;26 and one now being completed is an emulator using
a Digital Scientific Meta 4 and a Vector General display
system. Our experience has indicated that it is indeed
useful to be able to continue to run old programs while
developing more suitable support for the new system. In
addition, we have found that device emulation is a good
"benchmark" application for gaining experience with and
assessing the capabilities of the new system. On the other
hand, in no instance have we found that device emulation
made full use of the satellite facilities.

Black box approaches
We are now to the point of considering programs which
require the full services of the mainframe! satellite configuration. Such -programs are characterized by a need for
the graphics capability of the satellite processor and a set
of other requirements (computing power, core, bulk secondary storage, etc.) which cannot be completely satisfied
by the satellite. In addition, we will assume that the satellite possesses the critical intelligence referred to above.
It is at this point that the "division of labor" problem
arises, i.e., determining the optimal way in which the
various subtasks of a large application should be allocated to the two processors. This question has as yet
received no adequate treatment (a possible approach is
outlined below), and it is indicative of the difficulties
inherent in the problem that no current system for satellite graphics provides a truly general solution.
The most common treatment of the satellite processor
is as a black box. GIN031 and SPINDLE16 typify this
approach in which all hardware and operating system
details of the satellite are hidden from the applications
program. The satellite is provided with a relatively fixed
run-time environment which performs tasks such as display file management, attention queueing, light-pen
tracking, and data-structure management (in conjunction
with mainframe routines). Access to these facilities from
the application program is usually in the form of a subroutine library callable from a high -level language (e.g.,
FORTRAN).
This approach has the attractive feature of "protecting" the applications programmer from getting involved
in multiple languages, operating system details, and
hardware peculiarities. In addition, a well-designed system of this type can be easily reconfigured to support a
new satellite system without impacting the application
program. On the other hand, defining a fixed satellite!
mainframe task allocation may incur unnecessary systems overhead if the allocation should prove to be inappropriate for a particular application. Particularly in the
case of high-powered satellites, it may be difficult to provide access to all the facilities of the satellite without
requiring the applications programmer to "get his hands
dirty" by fiddling with various pieces of the system.
Worst is poor use (inadequate use) of local facilities,
wasting power and incurring charges on the mainframe.

233

Systems for interconnected processing
While the black-box approach hides the satellite from
the programmer, interconnected processor (lCP) systems
(connecting one or more small satellites to a large host)
allow (and sometimes require) cognizance of both the
mainframe and satellite processors. At the lowest level,
such a "system" consists of no more than a communications package or access method. At a slightly higher level
are packages such as IBM's processor-to-processor
(PTOP) routines for 360! 1130 communications. 22 These
routines provide a high-level communication interface
together with data conversion capabilities.
More sophisticated systems are exemplified by Bell
Labs' GRIN _27 and UNIVAC's Interactive Control Table
(ICT) approach. B In these systems, a special-purpose
language is provided with which the application programmer specifies the detailed data structure manipulation
and! or attention handling which is to take place during
an interactive session. Once this specification has been
made, it becomes part of the system environment of both
processors. The Univac system allows this environment to
be changed at runtime by providing for the dynamic loading of new satellite programs for full attention handling
and data structure manipulation. Thus the programmer
has at least some control over the activities of the satellite
processor.
A very general system of this type has been outlined by
Ross et al./ 4 in which a Display Interface System (DIS)
is described. The DIS consists of "minimal executives" in
both the satellite and mainframe processors. These executives act in conjunction to provide attention and programhandling mechanisms in both machines. Additional features, such as satellite storage management and display
file handling, are available in the form of system-provided routines which can be allocated to either processor.
Effectively, the DIS provides a "meta-system" which can
be used by a systems programmer to tailor the appearance of the mainframe! satellite interface to provide
optimal utilization of the satellite configuration. While a
full DIS system has not yet been implemented, the basic
design principles were used with apparently good success
in the design of the GINO package. 31
What objections to the preceding systems can be
raised? The Univac system requires bi-linguality and the
overhead of a local interpreter, a deficiency recognized by
the implementers.9 This particular system also failed to
achieve critical intelligence since the hardware on which
it was implemented lacked mass storage, general purpose
registers, and a decent instruction set. The Grin-2 experiment is somewhat more ambiguous, with in-house users
apparently satisfied and some outsiders dissatisfied, with
such features as a fixed (ring) data structure, an
unwieldy programming language, not enough local core,
etc. The GINO satellite system, though used very successfully, has had only relatively minor housekeeping and
transformation functions executed locally, thereby not
saving very much on host resources in this intelligent

234

National Computer Conference, 1973

terminal mode. Thus, a truly general purpose, flexible,
easy to use, and cost effective system for host-satellite
communication is yet to be achieved.

tions, windowing, and clipping. SIMALE is a high -speed
parallel processor with writeable control store! Webber,
1973!.
The 360 Interface-The communications link to the
mainframe (an IBM 360;67 under CP67;CMS) is a multiplexer channel interface. The interface, which is driven
from firmware, is non-specific, that is, it can appear as
any IBM -supported device. Eventually, this link will be
downgraded to a medium to low speed (e.g., 1200 BAUD)
communications line.
The local operating system-The operating system
which runs on the local processor was built using the "extended machine" or "structured" approach typified by
Dijkstra's THE System. 10 With this approach, the operating system is developed as a series of distinct levels, each
level providing a more intelligent "host" machine to the
next level. The design of the system facilities the vertical
movement of various facilities between levels as experience dictates. As facilities become stabilized on the lowest
level, they can be moved into the firmware with no
impact on user programs.

A SYSTEM FOR STUDYING SATELLITE
GRAPHICS

An environment for interconnected processing

BROWN UNIVERSITY
GRAPHICS SYSTEM

S I MAL E

(TRANSFORM.~TION PROCESSOR)

Figure 2

The Brown University graphics system (BUGS)
For the past eighteen months the Graphics Project at
Brown University has been implementing a laboratory
system for the investigation of a variety of questions
relating to satellite graphics. The salient features of the
system (shown in Figure 2)* are as follows.**
The local processor: The general-purpose processor of
the system is a microprogrammable Digital Scientific
Meta 4. It has been provided with a 360'-like firmware
defined instruction set with additions and modifications
to enhance the ability of the processor to meet the needs
of the operating system and graphics applications.
The display processor: A second Meta 4 was chosen to
serve as a programmable display processor to drive the
Vector General display. While the Vector General itself is
a relatively powerful processor, this "level of indirectness" was added to allow complete freedom in designing
(and altering) the display instruction set seen by the user.
The SIMALE- It was determined that even with the
high speed of the Meta 4, it would not be possible to provide full three-dimensional transformations (with windowing and clipping) at a speed sufficient to display
1000-2000 vectors. For this reason, we have designed the
SIMALE (Super Integral Microprogrammed Arithmetic
Logic Expediter) to perform homogeneous transforma* A PDP 11/45 with a Vector General display is a cheaper commercial
system sharing many of the characteristics of the BUGS system. We are
providing a FORTRA::-.r based graphics subroutine package for this svstern, both for standalone and for 360/370 satellite mode.
** For more complete information about the system, see References 2
:mri ~8

The system outlined above, which admittedly has gone
around the wheel of reincarnation several times, has been
designed with the goal of keeping each subsystem as
open-ended as possible, thus allowing maximum flexibility in subsystem/task allocation. This approach is also
being taken in the design of system software to support
graphics applications requiring both satellite and mainframe facilities.
With currently extant systems, the ramifications of
splitting an application between the mainframe and the
satellite are many and frequently ugly. Minimally, the
programmer must become acquainted with a new instruction set or an unfamiliar implementation of a higher-level
language. In addition, the vagaries of the satellite operating system must be painfully gleaned from Those-in-theKnow. With luck, there will be some sort of support for
110 to the mainframe, but probably no good guidelines on
how best it should be used. Most importantly, the programmer will have little or no knowledge about how to
split his application between the two processors in such a
way as to make optimal use of each. In other words, mistakes are bound to occur, mistakes of the kind which
frequently require a significant amount of recoding and;
or redesign.
The basic goal of the ICP system outlined below is to
alleviate these problems while placing minimal constraints on the programmer's use of the two processors.
The aim is to provide not merely a high-level access
method or system environment through which the satellite can be referenced, but rather a set of tools which will
allow the programmer to subdivide an applications program or system between the satellite and the mainframe
",,'jthout constant reference to the fact that he is working

Intelligent Satellites for Interactive Graphics

with two dissimilar processors. These tools include the
following: *
• A completely transparent I/O interface between the
mainframe and the satellite. I/O between the two
processors should take place at a purely logical level
with no consideration of communications protocol,
interface characteristics, or timing dependencies.
• A run-time environment to support inter-process
communication as described below. In the limit, this
environment should be sufficiently powerful to allow
dynamic (run time) redefinition of the task/processor allocation.
• A high-level language with translators capable of
generating code for both machines. Minimally, this
language should let the programmer disregard as far
as possible differences in the hardware and operating
system defined characteristics of the two processors.** Optimally, the language should provide
constructs to maximize the ease with which the various tasks of a large application can be moved from
one processor to the other.

235

• The ability to completely redefine the compile-time
code generators. This allows implementation of a
compiler which will generate code for either the satellite or the mainframe.
• Extensibility mechanisms. In particular, semantic
extensibility allows the definition of new data types,
storage classes, and scopes for variables.
• The ON ACCESS mechanism. This facility, which is
similar to PL/l's CHECK statement, allows compiletime definition of routines which are to be invoked
whenever a particular variable is accessed at run
time.
• Operating system independence. The constructs
which are generated by the compiler have been
designed to be as independent as possible of the
operating system under which they are to run. In
addition, the run-time environment required by an
LSD program has been kept as small as possible.
• Run-time symbol table access. Complete information
about the scope, type and storage class of all variables is available at run time.

The language for systems development

LSD extended for the ICP system

Of the tools mentioned above, the most important is the
high-level language in which the application is going to be
written. Indeed, the language is the heart of our approach
to ICPing since it provides the uniform environment in
which the programmer can work with little or no regard
for the final task/processor subdivision of the application.
If he wishes, the language will also let him hand-tool each
routine for the processor on which it will run.
The language which we are using for both the Iep system and application programs is the Language for Systems Development (LSD).5 LSD is a general-purpose
procedure-oriented language with many of the features
and much of the syntax of PL/I. In contrast to PL/I,
however, the language enables the programmer to get as
close as he wants to the machine for which he is programming rather than hiding that machine from him. Thus,
while the ordinary applications programmer can simply
use it as a FORTRAN replacement, a systems programmer can explicitly perform operations on main memory
locations and registers; he can intersperse LSD code with
assembly language or machine language (through the
CODE/ENCODE construct). LSD also will provide a
variety of extension mechanisms to permit the user to
tailor the language to specific problems or programming
styles. Some of the features of LSD which make it an
ideal vehicle for the ICP system are the following:

The fundamental extension to be made to LSD for
ICP'ing is the addition of a new scope for variables and
procedures. Currently, an LSD variable may have one of
three scope attributes-LOCAL, GLOBAL, or EXTERNAL. A LOCAL variable is accessible only within the
procedure in which it is allocated. A GLOBAL variable
may be known to all procedures in the system. EXTERNAL indicates that the variable has been defined as a
GLOBAL in some other procedure which is external to
the current procedure. A procedure can be either external
or internal. An internal procedure is defined within
another procedure. An external procedure is the basic
unit of programming within the system; that is, it can be
compiled separately from all other procedures with no
loss of information.
For the use of ICP applications, a new scope will be
defined which will be referred to here as ICPABLE. A
declaration of ICPABLE defines the named variable or
procedure as one which may reside in the other processor. t This declaration· will force the compiler to take the
following actions:

* The approach taken is similar to that of J. D. Foley in his current
National Science Foundation sponsored research in computer graphics;
the envisiuned run-time environments and facilities, however, are quite
dissimilar, as will be described below.
** Note that microprogramming is a very handy implementation tool for
making the satellite architecture and instruction set somewhat similar to
that of the host, thereby reducing the load on the compiler design team.

• On variable access or assignment, a run-time routine
must be called which has the task of returning the
value (or address) of the variable, possibly accessing
the other processor to obtain the current value of the
variable.
• On a call of a procedure which has been declared
ICPABLE, a similar check must be made as to the
current whereabouts of the procedure. If the procet This definition is similar to Foley's GLOBAL; however, assignments
between processors are not run-time alterable in Foley's system, a significant and far reaching difference.

236

National Computer Conference, 1973

dure is in the other processor, an appropriate mechanism for passing of control and parameters must be
invoked.
The end effect of this extension will be that the programmer need have only very vague ideas about the eventual disposition of his programs and data. During program development, any unclear areas can be resolved by
declaring all affected variables and routines as ICPABLE. If the referenced object is in the same processor as
the "referencor," overhead will be minimal; if it is not,
overhead beyond the necessary communications delay
will hopefully still be minimal. * Once the application has
been shaken down, this minimal overhead can be
removed by suitable redeclarations of the ICPABLE
variables and procedures.

The run-time environment
As currently envisioned an application requiring satellite graphics will run in an environment consisting of five
levels.
• At the lowest level will be a set of routines (in each
processor) which handle the lowest level physical
I/O. A standard interface will be defined between
these routines and higher levels to ensure flexibility
with respect to the variety of possible satellite/
mainframe links.
• Above the low level I/O package will be an (LSD
callable) access method for explicit use by the LSD
programmer as well as the routines supporting
implicit inter-process communication. Also at this
level will be any system supplied routines which are
found necessary to interface with the lowest level
facilities on the two processors (e.g., a routine to
actually start display regeneration).
• The access method will be used for the most part by
a third level of routines in charge of performing all
necessary data transmission and conversion.
• Between the data conversion routines and the actual
LSD program will be a supervisory package which
keeps track of the current procedure/variable/processor assignment. When dynamic movement of variables and procedures between processors becomes
feasible, it also will be undertaken at this level.
• The highest level of the run-time environment will
consist of a "meta-system" which is used for system
resource utilization, response measurements, and
dynamic reconfiguring of the application program.
The idea here is to provide a logical "joystick" with
which the programmer (or user) can make real-time
decisions as to the optimal deployment of the various
* The overhead inflicted by various flavors of special purpose run-time
environments is notoriously unpredictable: the "minimal" overhead for
ICPABLE variables and procedures could prove to be entirely unacceptable.

pieces of the application. By moving the stick in the
"360 direction" he causes some of the modules to be
loaded and executed in that machine; by moving in
"the other direction," he causes modules to be
shifted to the satellite. Observing response or some
graphically displayed resource utilization and cost
data, he can manipulate the stick, trying for a
(temporal) local optimum.

A hypothetical example
In order to illustrate a use of the system described
above, we offer for consideration a piece of a larger application consisting of four procedures-DISKIO, DSUPDATE, BUFFGEN, and ATTNWAIT-together with a
MAINLINE representing the rest of the application.
DISKIO is a routine which handles I/O to bulk storage
on the mainframe; DSUPDATE is in charge of modifying
and updating the graphic data structure; BUFFGEN
generates a display file from the data structure; and
ATTNWAIT processes attentions from the graphic input
devices.
While the programmer is writing these routines, he
disregards the eventual destinations of these routines, and
programs as if the system were to appear as:*'*

MAINFRAME

SATELLITE

MAINLINE

+
...

BUPFGEN
DISKIO
t
DSUPDATE

ATTNWAIT

Figure 3

However this disregard while implementing does not
mean that the programmer is unaware of the fact that he
is indeed working with two processors, and that at some
point certain processor/task assignments are going to be
made. While he is reasonably certain that DISKIO is
going to run in the mainframe and ATTNWAIT in the
satellite, he is less sure about BUFFGEN and DSUPDATE and therefore declares these routines ICPABLE.
He then (in effect) tells the compiler, "Compile DISKIO
for the mainframe, ATTNW AIT for the satellite, and
DSUPDATE and BUFFGEN for both processors."
When the system is ready for testing, he invokes the
highest level of the run-time environment and requests
•• Arrows represent call;;; system routilles have beeIl omitt.ed for clarity.

Intelligent Satellites for Interactive Graphics

his program be run with a trial allocation of tasks as follows:

MAINFRAME

SATELLITE

237

make the best of a bad situation, the programmer moves
the DSUPDATE routine into the satellite:

MAINFRMtI-E

SATELLITE

MAINLINE

•

BUFFGEN

ATTNWAIT

DISKIO

DSUPDATE

ATTNWAIT

DSUPDATE

Figure 4

After running with this allocation for a while, the programmer reenters the "meta-system" level to see what
kind of statistics have been gathered during the session.
The statistics indicate that during those times when some
demand was being made on the total system (i.e., periods
during which the total application was not quiescent
while waiting for a user action), the satellite processor was
relatively idle. The programmer therefore decides to try a
reallocation of tasks by moving the BUFFGEN routine
into that satellite, resulting in:

MAINFRAME

SATELLITE

MAINLINE
BUFFGEN

DISKIO

ATTNWAIT

Figure 6

While the satellite may now be overloaded (e.g., overlays
may be needed), response time is still improved since less
work is being done in the currently "crunched" mainframe.
Hopefully this example gives some idea of the power we
envision for the full Iep system. Obviously this description has glossed over many of the difficulties and implementation probiems which we will encounter. In particular, the problem of data base allocation and the transporting of pieces of a data structure between the two processors with different machine defined word sizes presents a
formidable problem. Since we do not want to "inflict" a
built-in data structure facility on the user it may become
necessary to require of him more than minimal cognizance of the two processors for problems involving data
structure segmentation.
CONCLUSIONS

Figure 6

This configuration improves the utilization of the satellite, and the programmer returns to the application environment for further experimentation.
After a while, response time degrades drastically. On
investigation it is found that two systems and four PL/ I
compiles are currently running in the mainframe, To

Decentralization and distribution of computing power is
coming of age, and is expected to be the standard of the
future, with perhaps several levels and layers of hosts and
satellites, embedded in a network. Special-purpose-application dedicated intelligent terminals are already proliferating because they are cost effective and their hardware / firmware / software design is straightforward. Intelligent satellite computing, on the other hand, is still in its
infancy, especially in its full generality where there is a
genuine and changeable division of labor between host
and satellite. Few design rules of thumb exist beyond the
"buy-Iow/sell-high" variety (for example, interactions on
the satellite, number-crunching and data base manage-

238

National Computer Conference, 1973

ment on the host). Even fewer tools exist for studying
varying solutions, and their implementation is a far from
trivial task.
We hope to be able to report some concrete results of
our investigation into this important problem area in the
near future.

REFERENCES AND SELECTED BIBLIOGRAPHY
1. ADAGE Corp., Technical Description of ADAGE Interactive

Graphics System/370, News release, March 1972.
2. Anagostopoulos, P., Sockut, G., Stabler, G. M., van Dam, A.,
Michel, M., "Computer Architecture and Instruction Set Design,
NCCE, June 4,1973.
3. The Design Assistant, Applicon Corp., News Release, 1972.
4. Bairstow, J. N., "The Terminal that Thinks for Itself," Computer
Decisions, January 1973, 10-13.
5. Bergeron, D., Gannon, J., Shecter, D., Tompa, F., van Dam, A.,
"Systems Programming Languages," Advances in Computers, 12,
Academic Press, October 1972.
6. Bryden, J. E., "Visual Displays for Computers," Computer Design,
October 1971, pp. 55-79.
7. Christensen, C., Pinson, E. N., "Multi-Function Graphics for a
Large Computer System," FJCC 31,1967, pp. 697-712.
8. Cotton, I. W., Greatorex, F. S., Jr., "Data Structures and Techniques for Remote Computer Graphics," FJCC 33, 1968, pp. 533544.
9. Cotton, I. W., "Languages for Graphic Attention-Handling," International Symposium on Computer Graphics, Brunei, April 1970.
10. Dijkstra, E. W., "The Structure of THE Multiprogramming System," CACM, 11, 1968, pp. 341-346.
11. Foley, J. D., "An Approach to the Optimum Design of Computer
Architecture," CACM, 14, 1971, pp. 380-390.
12. Foster, C., "A View of Computer Architecture," CACM, 15, 1972,
pp. 557 -565.
13. Hagan, T. G., Nixon, R. J., Schaefer, L. J., "The Adage Graphics
Terminal," FJCC, 33, 1968, pp. 747-755.
14. Hobbs, L. C., "The Rationale for Smart Terminals," Computer,
November-December 1971, pp. 33·35.
15. Hobbs. L. C., "Terminals," Proc. IEEE, 60, 1972. pp. 1273-1284.

16. Kilgour, A. C., "The Evolution of a Graphics System for Linked
Computers," Software-Practice and Experience, 1, 1971, pp. 259268.
17. Knudson, D., and Vezza, A., "Remote Computer Display Terminals," Computer Handling of Graphical Information, Seminar,
Society of Photographic Scientists and Engineers, Washington,
D.C., 1970, pp. 249-268.
18. Machover, C., "Computer Graphics Terminals-A Backward
Look," SJCC, 1972, pp. 439-446.
19. Machover C., "The Intelligent Terminal, Pertinent Concepts in
Computer Graphics," Proc. of the Second University of Illinois
Conference on Computer Graphics, M. Faiman and J. Nievergelt
(eds.), University of Illinois Press, Urbana, 1969, pp. 179-199.
20. Myer, T. H., Sutherland, I. E., "On the Design of Display Processors, CACM 11, 1968, p. 410.
21. Ninke, W. H., "A Satellite Display Console System for a MultiAccess Central Computer," Proc. IFIPS, 1968, E65-E71.
22. Rapkin, M. D., Abu-Gheida, O. M., "Stand-Alone/ Remote
Graphic System," FJCC, 33, 1968, pp. 731-746.
23. Rosenthal, C. W., "Increasing Capabilities in Interactive Computer Graphics Terminals," Computer, November-December 1972,
pp.48-53.
24. Ross, D. T., Stotz, R. H., Thornhill, D. E., Lang, C. A., "The
Design and Programming of a Display Interface System Integrating Multi-Access and Satellite Computers," Proc. ACM;SHARE
4th Annual Design Workshop, June 1967, Los Angeles.
25. Ryden, K. H., Newton, C. M., "Graphics Software for Remote
Terminals and Their Use in Radiation Treatment Planning,"
SJCC, 1972, pp. 1145-1156.
26. Schiller, W. L., Abraham, R. L., Fox, R. M., van Dam., A., "A
Microprogrammed Intelligent Graphics Terminal," IEEE Trans.
Computers C-20, July 1971, pp. 775-782.
27. Stabler, G. M., A 2250 Modell Simulation Support Package, IBM
PID No. 1130-03.4.014, 1969.
28. Stabler, G. M., The Brown University Graphics System, Brown
University, Providence, R. I., February, 1973.
29. van Dam, A., "Microprogramming for Computer Graphics,"
Annual SEAS Conference, Pisa, Italy, September 1971.
30. Webber, H., "The Super Integral Microprogrammed Arithmetic
Logic Expediter (SIMALE)," SIGMICRO, 6, 4, 1972.
31. Woodsford, P. A., "The Design and Implementation of the GINO
3D Graphics Software Package." Software-Practice and Experience, 1. 1972,pp.335-365.

Fourth generation data management systems
by KEVIN M. WHITNEY
General Motors Research Laboratories
Warren, Michigan

I~TRODUCTION

AND HISTORY

second generation of data management facilities became
available to speed the job of generating reports and writing new application packages. These report generators,
file maihtenance packages, and inquiry systems provided
easy-to-use facilities for selecting, summarizing, sorting,
editing, and reporting data from files with a variety of
formats. A user language simple enough for non-programmers to use was sometimes provided, although using
more advanced system facilities often required some
programming aptitude. This second generation of data
management systems brought non-procedural user languages and a greater degree of program independence
from data formats and types.
Much more general capabilities were incorporated into
third generation systems such as IDS, IMS, and the
CODASYL report specifications. l All of these systems
emphasize the effective management of large amounts of
data rather than the manipulation or retrieval of data
items. All have facilities to manage data organized in
much more complicated data structures than the sequential structures used by earlier systems. Relationship's
among data items in many different files are expressible
and manipulable in the data management systems. Provisions for the recovery from many different types of system errors, head crashes, erroneous updates, etc. are integral parts of these systems. Audit trails of modifications
of the data base are often automatically maintained, and
new file descriptions are handled by standard system
facilities. In general, many of the functions which previous generations of data management systems left to the
operating system or to user application programs are
automatically incorporated in these systems. Many of the
third generation systems provide a convenient user
inquiry language, a well-defined interface for user application programs, and new language facilities to aid the
data administrator in the description and maintenance of
the data base.
A fourth generation data management system will continue the development of all these trends toward generality, flexibility, and modularity. Other improvements will
result from theories and concepts now being tried in
experimental systems. Much greater degrees of data
independence (from user program changes, from data
description and storage changes, from new relationships
among the data) will be common; user languages will

Many hundreds of programming systems have been
developed in recent years to aid programmers in the
management of large amounts of data. Some trends in the
development of these data management systems are followed in this paper and combined with ideas now being
studied to predict the architecture of the next generation
of data management systems. The evol ution of data
management facilities can be grouped into several generations with fuzzy boundaries. Generation zero was the era
when each programmer wrote all his own input, output,
and data manipulation facilities. A new generation of
facilities occurred with the use of standard access methods and standard input/ output conversion routines for all
programs at an installation or on a particular computer
system. The second generation of data management was
the development of file manipulation and report writing
systems such as RPG, EASYTRIEVE, and MARK IV.
Much more comprehensive facilities for the creation,
updating, and accessing of large structures of files are
included in the third generation of generalized data
management systems such as IMS/2, IDS, and the
CODASYL specifications. Each of these generations of
data management systems marked great increases in
system flexibility, generality, modularity, and usability.
Before speculating on the future of data management, let
us survey this history in more detail.
Standard access methods, such as ISAM, BDAM and
SAM which formed the first generation data management
facilities were mainly incorporated in programming languages and merely gathered some of the commonly performed data manipulation facilities into standard packages for more convenient use, The main benefit of these
standard facilities was to relieve each application programmer of the burden of recoding common tasks. This
standardization also reduced program dependency on
actual stored data structures and formats. Although these
access methods and input/ output conversion routines
were often convenient to use, they could only accommodate a limited number of different data structures and
data types.
As computer systems became more common, more
widely used, more highly depended on, and eventually
more essential to the functioning of many businesses, a
239

240

National Computer Conference, 1973

APPLI CATl ON
PR(XJRAM
USER
SERVICES

APPLI CATION

QUERY

TELEPROCESS I f'XJ

PRCNRAM

LANGUAGE

MJNITOR

DATA DESCRIPTION AND MANIPULATION

DBA

FACILITIES

SERVICES

DATA ACCESS AND CONTROL FACILITIES

Figure I-Information management system structure.

become much less procedural; and data manipulation
facilities for use in writing application programs will
become simpler and more powerful. Concepts from set
theory and relation theory will become more widely used
as the advantages of a sound theoretical basis for information systems become more widely appreciated.
Increasingly, information management systems will make
more of the optimization decisions relating to file organization and compromises between different user requirements. The trend to bending the computer toward user
requirements rather than bending the user to the requirements of the computer will continue resulting in progressively easier to use systems.
One organization of the facilities of an information
management system may be the division into modules
shown in Figure 1. This modularity may represent software or hardware (or both) boundaries and interfaces. A
data access and control module is needed to manage data
flow to and from the storage media. This data management module is used by the data description and manipulation module in providing data description and manipulation at a level less dependent on the storage structure of
this data. The user can access data through application
processors or through a system provided query language
processor. A variety of system services are grouped into
the user services module and the data base administrator
services module. User services include such conveniences
as on-line manuals, help and explain commands, and
command audit trails. Data base administrator services
include facilities to load and dump data bases, to perform
restructuring of data and storage organizations, to monitoring performance, and to control checkpointing and
recovery from errors.
Impacting the fourth generation information management systems are the theories and methodologies of data
description and manipulation, the relational view of
information, the establishment of sound theoretical foundations for information systems, and the development of
networks of cooperating processors. Each of these topics
will be discussed in one of the following sections. Following those sections is a description of our experiences with
RDMS, a relational data management system which
illustrates some of these new theories and methodologies.

DATA DESCRIPTION AND MANIPULATION
Certainly the most complex and difficult problem facing the designers, implementers, and users of an information management system is the selection of language facilities for the description and manipulation of data.
Although many attempts have been made to separate
data description from data manipulation, it must be
noted that data description and data manipulation are
inextricably intertwined. While the declarative statements which describe a data base may indeed be kept
separate from the statements in application programs
which manipulate the data in the data base, nevertheless
the data description facilities available determine and are
determined by the data manipulation facilities available.
Descriptive statements for vectors aren't very useful
without vector manipulation statements, and vice versa.
The description of data may be done at a wide variety
of level~ of generality ranging from general statements
about the relationships between large sets of data items to
explicit details about the actual storage of the data items.
Information management systems of the next generation
will have data description facilities at a variety of levels
to serve different classes of users. At least three main
levels of data description can be distinguished, the information structure for the users, the data structure for the
data base administrators, and the storage structure for
the system implementers and the system.
The information structure which determines the user's
view of the data is (ideally) quite abstract, indicating the
relationships among various types of data items, but
omitting details such as data item types, precisions, field
lengths, encodings, or storage locations. The user should
also be free of system performance considerations such as
indexing schemes or file organizations for efficient
retrieval of the data items, particularly since his access
requirements may conflict with those of other users. In
any event the system or the data administrator is in a
better position than anyone user to make those arbitrations. An example of the information structure for some
data described by a relational model is shown in Figure 2.
A second level of data description is necessary to specify the structure (logical) of the data which will facilitate
the efficient retrieval of the data representing the information in the data base. This second level of description
is the data structure and represents additional informa-

PEOPLE (NAME. AGE. HEIGHT. WEIGHT)
S H I RT S (S H I RT #, COL 0 R, S I Z E, COL L AR )
S LAC K S (S LAC K S #, COL 0 R, S I Z E, F AB RIC)

OWN S - S H I RT S (N AME, S H I RT # )

oVI NS - S LAC KS (N A['1 E, S LAC KS # )
Figure 2-An information structure specified by a relational model

Fourth Generation Data Management Systems

tion about the patterns of retrieval expected for information in the data base. The set occurrence selection facility
of the CODASYL proposal is an example of this level of
data description. CODASYL schema data description
statements for the information structure of Figure 2 are
shown in Figure 3.
A still more detailed level of data description is the
storage structure of the data which represents the actual
organization of the data as stored in the system's storage
media. At the storage structure level, items of concern
include field types, lengths, encodings, relationship pointers and index organizations. Figure 4 shows a diagram of
pointers and storage blocks specifying a storage structure
for the data described in Figure 3.
Data manipulation facilities must also exist at a variety
of levels corresponding to the data description levels. As
data description becom€s more general, the corresponding
data manipulation becomes less procedural and more
descriptive. E. F. Codd's relational model of datal
described in the next section provides an example of a
highly non-procedural data manipulation language.

PEOPLE

INFORMATIO~

Information management systems deal fundamentally
with things such as people, ages, weights, colors