AESOP: A PROTOTYPE FOR O'N-LiNE USER CONTROL OF ORGANIZATIO'NAL DATA
STORAGE, RETRIEVAL AND PROCESSING
Edward Bennett, Edward C. Haines, and John K. Summers
The MITRE Corporation
Bedford, Mass.
play-13 display console with a photoelectric light
pencil, an on-line typewriter, and a StrombergCarlson 3070 medium-speed printer.
The AESOP system is designed to take advantage of the range of capabilities implied by this
central processor and the user station equipment.
However, the design philosophy is tailored to the
general characteristics of management and command users rather than to specific characteristics of
either the equipment or a specific organizational
job.
The following description of the prototype, and
of the conceptual foundations underlying the design,
deals mainly with those aspects of the system which
emphasize the user's on-line control capability.
The description is divided into two sections, the
first dealing with the long-range conceptual objectives which influence the design of the AESOP prototype and the second dealing· with the system
characteristics as they are experienced by the user
of the currently operational All Model.
OVERVIEW
AESOP is an experimental on-line information
control system realized in the Systems Design Laboratory of The MITRE Corporation. It serves as a
prototype for a class of management or command
information systems capabJe of giving the members
of the using organization as much on-line control
over system performance as possible. It is a CRT
display-oriented system in that the user experiences the information system primarily through his
CRT displays and exercises his control through his
light pencil. This control is not limited to that level
of the organization responsible for programming the
system, but applies upward to the highest level of
executive personnel interested in obtaining direct
access to the system.
The current version of the AESOP prototype operates on an IBM 7030 (Stretch) computer (65K
memory with 64-bit words) with a 353 disk storage
unit holding two million words. 1 Each of the four
user stations consists of an on-line Data-Dis-
CONCEPTUAL OBJECTIVES
*Software characteristics appear in the Appendix. The program is configured to permit continuous modification of system performance, both on-line and off-line, with minimum
recoding requirements. As a result, the models of the system
change regularly and the model operating at the time of the
FJCC meeting may contain capabilities other than those
realized and operating at the time this report was prepared.
The flexibility of an on-line information processing system often determines not only its ability
to respond to new and changing demands upon it,
435
From the collection of the Computer History Museum (www.computerhistory.org)
436
PROCEEDINGS -
FALL JOINT COMPUTER CONFERENCE,
but may, in fact, also determine how extensively the
system will be used outside of the limited fraternity
of professional scientists and engineers involved in
its development and management. System flexibility
is particularly critical when the on-line capability
in question is intended to be more than a multiaccess, - remote station computer sharing facility.
When operating in an organizational context, the
users of an on-line system need to do more than
develop, store and execute their own job-oriented
programs. They must also share the common data
base, common data retrieval and updating routines,
and the various on-line processing procedures designed to use this common data base for various
organizational purposes.
Further, in the case of an organizational system,
flexibility involves not only the system's ability to
be changed off-line to meet changing on-line requirements, but also its ability to be changed online to meet the constantly changing needs and time
constraints of its various users. In addition, an organization-wide system must interface with users
of widely varying background, experience, needs,
and position. A system tailored only to the needs of
junior users is no better than one tailored only to the
needs of the executive suite.
The fixed information-processing procedures usually employed at the lower levels of an organization,
for financial accounting, billing, payroll, and so
forth, may leave little room for creativity or imagination on the part of on-line users of the system.
In most cases, in fact, there is little need for such
creativity. On the other' hand, the hardest task masters, with the greatest demand for on-line control,
are the military or industrial planners, ranging in
organizational level and function, but working collectively on the same total data base. Especially at
the higher levels of an organization, where the organization'S data base is used for global planning
and decision, there i~ a need for creative approaches to information processing. The senior executive
wqo might use an on-line information system for
situation monitoring, resource allocation planning,
or for insight into the timing of executive decisions, benefits from as much freedom to mold and
configure the performance of his information system as is possible within the limits of his job.
The concept of on-line information control implies the ability of such users of the system to
change the performance of the system to meet their
own changing needs or wishes. With adequate con-
1965
trol, they can experiment with the display of alternative data formats or configurations, with alternative sequences of data retrieval, with alternative
formulae for summarizing, processing, or analyzing
data.
The on-line user needs to be able to express his
desires by communicating with the system is an easily usable language. The language itself must have
a syntax and vocabulary tailored to increase the executive user's interest in the system, his creativity
in using it, and his flexibility and facility in accomplishing any changes he wishes to make. This implies that the language should have a syntax and vocabulary complex enough to permit a flexible range
of alternatives. However, the system should make
the on-line use of that language little more than a
matter of the on-line user sensing, choosing and
pointing out his communication desires. Keeping
track of well-formed syntax and vocabulary constraints and implications need not be the on-line
user's problem.
An advantage of on-line control for information storage is in the generation and editing of
personal files. Such personal files, from the user's
point of view, are not files as they exist in fact
within the machine structure. The user's concept of
his file is more likely conditioned by his past experience with manual or mechanical files; and his
impression of the files )Vi thin a computer system
can be, therefore, mainly a matter of how he experiences these files at his own input-output station,
how he generates or edits his file, and how he retrieves data from such files. For an on-line user,
this experience can be influenced by the way in
which data are reported to him by the system,
through his own display device, in his own work
environment. He can come to "understand" a file as
simply the set of possible reports derived from the
file, the lists, tables, and matrices, as they appear
before him.
This implies that, no matter what logic is applied
to the management of the data base inside the machine, the surface appearance of the data base must
be under the user's on-line control. He should be
able to set up the file display, the object and property names, the formats of these files, including sequence and arrangement of data, as he desires. He
should be able to generate, store and revise the
structure of his displays, on-line, in much the
same fashion as he generates, revises and stores any
From the collection of the Computer History Museum (www.computerhistory.org)
AESOP: PROTOTYPE FOR ON-LINE USER CONTROL
other portion of his personal data base, and using
the same general on-line control language.
In addition to the user's need for on-line control over the generation, retrieval, and display
characteristics of his data base, he needs control
over the generation, revision, naming and execution
of his job-oriented processing routines, as well as
the storage and retrieval of such processing routines
as part of his data base. He needs to be able to manipulate logical and arithmetic operators, planning
factors and parameters, models and projections of
relevant job-oriented operations. The system executive program must carry the burden. of making his
job-oriented generation of algorithms little more
than a matter of looking at his display, choosing
among acceptable alternatives and pointing to express his desires.
The need for on-line control is not necessarily
Figure
437
limited to any level of organization. On the other
hand, senior executives should not have to use this
control to create data of low aggregation or detailed
procedures normally the responsibility of system
analysts. However, if an executive so desires, he
should be able to use his control to access the system at the lower organizational levels when he
wants to.
THE AESOP (MODEL A/I) PROTOTYPE
The AESOP A/I prototype in the form described following has been operational since August
1965. From a conceptual standpoint. the system
contains two major features. The first is an information retrieval capability which can be operated
entirely by means of a CRT display and a light pencil as shown in Fig. 1. The second is a facility to
1. The Data-Display-13 Console with light pencil
on the right and notebook display on the CRT.
From the collection of the Computer History Museum (www.computerhistory.org)
438
PROCEEDINGS -
FALL JOINT COMPUTER CONFERENCE,
construct and operate on-line logical and mathematical procedures, again using only a CRT display
and a light pencil.
Since an understanding of the user's view of this
data base is essential to an understanding of many
of the other system capabilities to be described, it
will be presented first. It will be followed by a description of the communication tree which the user
uses to "talk to" the system. The final capability
described will be the on-line procedure generation
capability.
PAGE
UNCLASSIFIED
~I
SECTION 81
AIRFIELDS
LN
NAME
~~I
ABADAN
- - - - - - - -- ---
~P.J2
A IRF IELD-ORDNANCE
AS OF 2~ 168ez
THE USERS' NOTEBOOK
The users of the system experience the total data
base through tabular displays on their DD-13 cathode ray tubes. Any tabular display can be reproduced in hard copy, on call, on the S-C 3070
medium-speed printer (see Fig. 2). The hard copy
is always a precise reproduction of the CRT tabular
display.
Each display is a section of a page of a file in
the user's notebook. Each display consists of 30
OF. 81
OF
13
STATUS
COUNTRY
LAT
LONG
IRAN
3U2N
4814E
REF-NO
£lEV
MA INTCE
--_ .. --_ . --- ... -------- .. --------------- .. --- _... ----_ .. ----
A HWAlWE S T
IRAN
3119N
4838E
II
51
~~3
A HWAlNOR TH
IRAN
3121N
4841E
41
~~4
BATMAN
TURKEY
3755N
4118E
1749
1'11'15 DE·lFUL
IRAN
3223N
4825E
I'I~~
5 ••
5731
HAMADAN
IRAN
3452N
4832E
81'17
I SF AHAN
IRAN
3237N
I'II'I~
JASK
IRAN
2539N
5141E
5749E
~~9
KERMAN
IRAN
3.15N
5658E
1'111
KHURAMAB.AD
1 2 MIRJAWA
q 13 QOM
IRAN
3326N
4818E
~
IRAN
2911N
6125E
IRAN
3441N
5nlE
358.
1'114
SH I·RAl
IRAN
2932N
5235E
4938
1'115
1'116
SilL TANABAD
IRAN
IRAN
34117N
4944E
6154E
1'111'1 KARMAN
1.AH lOAN
1965
5238
4331
2928N
375.
UNCLAS SiF lED
a
Figure 2.
Stromberg-Carlson 3070 print copy (a) of CRT
display (b).
lines numbered consecutively 1-30, 31-60, and
so forth. There are as many· pages in a file as there
are such sets of 30 lines. Each display is 64 characters wide. These 64 characters. are divided into columns. The number of columns depends upon how
many characters constitute a column and how much
space is desired between columns. A set of columns
is< referred to as a section of a file. There are as
many sections as there are sets of columns. The
user's selection of a specific page and section of a
file specifies a subset of lines and columns. Customarily, but not necessarily, lines identify objects,
columns identify properties.
The user's notebook contains as many files as are
required to hold the organization's data base. It also
contains an arbitrary number of files with completely blank pages (see Fig. 3). These blank pages
serve as the environment within the notebook in
which the individual user builds his private data
base and personal report formats. In such cases, the
resulting personal files and reports, developed either
on-line or off, are retained in the large computerbased notebook.
In AESOP, the distinction between a public file
and a private one, a temporary file and a permanent
file, a file and a report, becomes somewhat artificial. Procedural rules establish that a public file
should not be revised ty unauthorized members of
the .organization. Working files . are simply. private
files that the user intends to erase at some later
time, but which need not be destroyed if he changes
his . mind. Private files are generated, either online or off, from outside the existing data base or
by "copy" operations from other files, public or
From the collection of the Computer History Museum (www.computerhistory.org)
AESOP: PROTOTYPE FOR ON-LINE USER CONTROL
Figure
3-~
439
CRT Display of an empty notebook page/section. Light pencil commands appear at the upper
and lower right.
private. Both files and reports, from the user's
viewpoint, are simply CRT tabular notebook displays or their hard-copy reproductions.
The user of the system can browse through a file
by firing his light pencil on either a page;,.turning,
a section-turning, or a line-display command in
the lower right~hand corner of the tabular display.
He can turn pages and sections both forward and
backward to scan all of the objects and properties
of the file. He can also light pencil a specific line
number or name, after having light· penciled a request for the display of a line, and have all of the
columns of data and the column headings displayed
for him (see Fig. 4).
The format of each page and section of each file,
which in effect is the format of a specific tabular
CRT display, is under theon-line control of the
system users. Among the parameters of the display
open to on-line control are the following:
( a) whether or not the line (object) names are
to be displayed;
(b) the number of columns (properties) to be
displayed in each section of the file;
(c) the specific columns (properties) that are
to be displayed and their sequence;
( d) the location and the size of the column in
which each property is to be displayed;
(e) the choice of right, left or decimal justification of the data for any property.
Format is determined by data contained in one
of the standard notebook files in exactly the same
fashion as any other portion of the data base. In
this "display adaptation" the names of all of the other
files of the system are recorded as lines or objects.
The columns contain all of the format parameters
From the collection of the Computer History Museum (www.computerhistory.org)
440
PROCEEDINGS -
FALL JOINT COMPUTER CONFERENCE,
1965
UNCL.ASSIrIED
AIRrIEL.DS
JASIC
COUNTRY
L.AT
L.ONG
EL.EV
REr- NO
MAINTCE
NAVAJOI
NAVAJD2
NAVAJD~
CONTROL.
AIDS
L.IGHTSI
L.IGHTS2
IRAN
25~9N
57"'9E
TOWER
SEO-rL.H
L.IGHTS~
L.IGHTS'"
L.I GHTS5
AP-NO
AP- AREA
AP-SURr
AP-WT
AP-USABL.E
HS-NO
HS-AREA
HS-SURr
HS-WT
HS-USABL.E
WX
TIME:
DATE:
REMARKS 1
RtHARKS2
RWYS
PRIHARY
StCOARY
CAP
RNWAY
AVGASCAP
JeT.UCAP
8OHII-CAP
ROCK-CAP
UL.
-ORY-WX
DIRT
C12'"
15
2
A"""
CL.AY
610O
AMMO-CAP
91-096
100- I ~0
11S-1A5
JP'"
JPS
'''''11
7S"
Sill
2S11
AP- I Ii
HVAR
rrAR
AIM9B
AGM12B
S"CAL.
2"1'11'1
UNITt
UNJT2
TABUL.AR
TREE
"""'0i
9""0i
ellUi
S""
511i
'''11
56
Iii"
Sill
6U
t""""
2~""
A7ABL.0
UNJT~
UNITA
UNIT5
AL.TERNATE
AL.TER-L.OC
ct~"
NEXT PAGE
PREY PAGE
NEXT SECT
7"
OPEN
16""
26JUN
PREY SECT
RESTORt
I
rAIR
DISP LINE
Cl~"
152""
19""""
8""""
115915
18e
UNCL.ASSlf"U:O
Figure 4.
CRT Display of all column names and values for
a specific line (name JASK) of a file (name
AIRFIELDS) selected by use of the display line
command (DISP LINE).
open to on-line control. Values of those parameters are interpreted by the system to determine the
specific formats displayed to the user. Thus, when
this "display adaptation" file is changed or updated
on-line, in the same fashion as any other file in
the system, there is an immediate resulting alteration of the display formats. (Compare Fig. 5 with
Fig. I).
The on-line ability to reformat the notebook
display provides a report generation capability.
When a particular report is desired, one or more
notebook pages are formatted to reflect the desired
report structure. Data can then be copied or generated into that portion of the notebook and a hard
copy can be made of the resulting display. As a final step, the display can be returned to its original
form.
COMMUNICATION TREE
Communication with the system for the purpose
of data retrieval, browsing through the notebook,
data generation or format control is mainly accomplished by means of the light pencil and the display
of the communication tree (see Fig. 6). The communication tree not only handles all of the problems
of syntax and vocabulary necessary to access the
data base, but it also shows the user all of the
linguistic implications down each of the branches of
the tree. In addition, at the top of the display as a
message is being constructed, it shows him all of
his previously selected options to serve as a shortterm memory aid.
The branching points heading down the tree indicate legitimate options. The user indicates his de-
From the collection of the Computer History Museum (www.computerhistory.org)
441
AESOP: PROTOTYPE FOR ON-LINE USER CONTROL
UNCLAlllrlCD
'AGt ,.
seCTlOH ,.
AIRrICLDI
LH
MAH[
H1 ABA DAN
H2
H3
H"
85
86
'"
"S
89
'"
'"
"2
ItS
""5"
"6
AHWAIW[ST
AHWAINORTH
BATHAN
D[ZrUL
HAHADAN
IsrAHAN
JASK
KERHAN
KERHANSHAH
KHURAHABAO
HIRJAWA
OOH
SHIRAZ
SULTANABAO
ZAHIOAN
RWYS
3
1
2
"3
2
"
t
2
1
5
2
"
PRIHARY
opeN
rAIR
GOOD
OP[N
GOOD
POOR
OPEN
rAIR
OPEN
POOR
OPEN
POOR
OPEN
GOOD
OPEN
LAT
LONe
3'22N
3119N
3121N
3755N
3223N
3"52N
3237N
2539N
3.t5N
3"t9N
3326N
29.tN
3""tN
2932N
3"'7N
2928N
"SU[
"S3S[
"S"'[
""S[
"S25[
"S32[
5''''E
5749E
5658E
"n7E
"StSE
6t25E
5'5tE
5235E
"9""E
6'5"E
or 'f
or
••
[Ltv
COUNTRY
"
IRAN
IRAN
IRAN
TURK[Y
IRAN
IRAN
IRAN
IRAN
IRAN
IRAN
IRAN
IRAN
IRAN
IRAN
IRAN
IRAN
5'
.at
1749
511
5131
5238
"331
375.
35 ••
"938
• TA8UL.Aa
• TUC
• NEXT PAGC
.• PRty
PAGE
• NEXT seCT
• PRn seCT
• RtSTOII£
• DIll' L I .
""CLA•• lrleD
. On-line reformatted display of page 1,
1
of the AIRFIELDS file, originally formatted as
in Figure 2. Columns have been rearranged, new
columns added, spacing altered and right-hand
justification of the COUNTRY column has been
substituted.
sires by pointing the light pencil at the desired option currently displayed at the top of the tree. Each
light pencil action (1) generates a display :record of
the part of the message constructed to date, and (2)
moves the tree upward to indicate the next legitimate choice to be made or (3) displays a list of
possible options to be taken at that particular point
in the construction of his communication. Using
the tree, the user need have no prior knowledge of
either the current system index, vocabulary, or syntax, and he need not keep a record of the communication he is in the process of constructing.
For example, as in Figs. 7 and 8, to construct a
call on the file, the user first requests the communication tree by light penciling the word TREE in the
upper right~hand portion of his display. He then light
pencils "GET" at the top of the tree. This action
writes GET at the top of the display and moves
FILENAME to the top of the tree (Fig. 7a). Light
penciling FILENAME then shifts the display to supply a list of all the names of the files currently in the
system (Fig. 7b). He points his light pencil at the
file he wants, such as AIRFIELDS, which (1) puts
GET AIRFIELDS at the top of the display, and (2)
returns the communication tree display with the next
From the collection of the Computer History Museum (www.computerhistory.org)
442
PROCEEDINGS -
Figure 6.
FALL JOINT COMPUTER CONFERENCE,
The basic communication tree with all wellformed control statements indicated by downward branches.
valid option displayed at the top of the tree (Fig. 7c).
If he chooses OBJECTNAME, all of the current object names in the AIRFIELDS file are displayed,
enabling him to choose the desired object by light
penciling it (Fig. 7d). The object name, for example
KARMAN, is then transferred to the top of the dis~1""<1
P~uJ
1965
By the alternate selection of appropriate column
names and the use of the alphanumeric matrix and
accumulator, the user can modify his data base
on-line (see Figs. 8b, c, d, and e). The result appears as in line 10 of Fig. 8f (see line 10 of Fig. 2
for prior file appearance) .
......
...1 -tho r>n..",..",., .... ;" ... +.;n.... +roo C'hnu7C' +1,0
.... oV+ ,,, ... 11rl
u~'"" \..1...1.'-" ,""VJ..1..l..J..I..I.U.l..I..I..","".l.V.I...l. \..J.. ..... '" ..:J.I..I.V l'Y
"'.I..I.V ..L.&.V~:lr." 'Y L4-..L"'~
LJ
options (Fig. 7e).
To generate a string of characters for inclusion in
the notebook, a matrix of alphanumeric characters
and an accumulator are displayed simultaneously.
The user selects characters by pointing the light pencil at them in sequence. His choices are recorded in
the accumulator and errors can be canceled by a
suitable light pencil command. When the appropriate
character string has been generated, the command
PROCESS moves the display to the next option
(Figs. 7f and 8a).
played, and' executed by the user who need know
nothing more about the communication language
than is necessary to point out his desires. By using
the tree to review the catalog of currently available
file names, object names within files, and property
names within files, the user is able to browse
through the data structure as well as to familiarize
himself with the range of options and implications
available to him.
The sophisticated user is not restricted to this
mode of communication if his knowledge of the
From the collection of the Computer History Museum (www.computerhistory.org)
AESOP: PROTOTYPE FOR ON-LINE USER CONTROL
a
443
c
b
f
Figure 7.
Steps in the on-line construction of a file modification command as described in detail in the
text.
system exceeds that implied by the look, choose,
and point philosophy. Users who know the syntax
and vocabulary of the system may directly compose
on the on-line typewriter any message that can be
generated by means. of the light pencil and communication tree. In fact, at any time in the evolution of the AESOP prototype, the typewriter user
has a more extensive language, portions of which, in
sequence, are transferred to the tree as this proves
useful. Currently, requests to print hard-copy, to
erase or to transfer portions of the notebook into
other portions are accomplished only by means of the
typewriter. System error messages are primarily
provided on the typewriter.
PROCEDURE GENERATION
The user can also process the data of the system,
either by executing or modifying established routines or by constructing new routines using his light
pencil and CRT display. In order to do this, he
calls up an on-line algorithm construction display
From the collection of the Computer History Museum (www.computerhistory.org)
444
PROCEEDINGS -
FALL JOINT COMPUTER CONFERENCE,
a
b
d
e
Figure 8.
1965
c
f
Figure 7 continued.
called OAK-TREET. The display appears as a
tree with one branch displaying commands which
can be light penciled to build and execute a program. A second branch displays some basic classes
of operators and operands or previously established
functions to be used as parts of this program. A
workspace within which to build a tree representation of the desired procedure exists as another
branch (Fig. 9a).
Each time a user light pencils a command, it appears in the upper right-hand corner of the display
(Fig. 9b). When he light pencils a class of operators, the specific operators within that class are displayed on a separate branch of the tree (Fig. 9c).
When he light pencils one of these specific operators, it also appears in the upper right-hand corner
of the display (Fig. 9d). Once a command and an
operator are so displayed, he can then light pencil
any portion of a tree in the workspace and the command will be executed, using the operator in question, at that specific location in the workspace
(Fig. ge). In this general fashion, the user builds,
From the collection of the Computer History Museum (www.computerhistory.org)
AESOP: PROTOTYPE FOR ON-LINE USER CONTROL
e
Figure 9.
f
Steps in the on-line construction of a primitive
procedure to mUltiply 4 by 5.
From the collection of the Computer History Museum (www.computerhistory.org)
445
446
PROCEEDINGS -
FALL JOINT COMPUTER CONFERENCE,
stores, retrieves, modifies, links, and in other ways
develops a catalog of logical and mathematical
expressions for use with his data base.
Numbers are generated by means of a special display of a tree of numerical characters which can be
added in an accumulator by light pencil selection.
These numerical strings are then transferred to the
upper right-hand accumulator in the OAKTREET display for further use.
The OAK-TREET capability operates in two
modes C. The/first displays the commands, operators
and workspace simultaneously. This mode may
crowd the workspace but the display logic drops
portions of the workspace tree off the display face,
leaving branch markers to indicate what parts are
gone whenever the workspace density exceeds a critical value. The second mode is used for inspection.
It turns the entire display face over to the workspace tree. In this mode, any point on the construction can be brought to the top of the display by
means of the light pencil in order to expose more of
the details of the tree below that point.
1965
As an example of the use of the OAK-TREET
feature consider Figs. 10, 11· and 12. A user interested in .a gross estimate of fuel consumption as a
function of distance for a high performance aircraft
in level flight might build the following planning procedure. Using the command REPLACE and a previously stored subroutine with the name JT1, he puts
this routine into the workspace by pointing the/ light
pencil at the node immediately below the/ word
WORKSPACE (Fig. lOa). The previously defined
routine JT1
., is then displayed at that point in the
workspace. In this example, the routine is a gross
ca1culation of fuel consumption and is called POLLBS. It involves multiplying the fuel consumption
rate by the ratio of the distance flown over the average speed of the aircraft. The user may substitute
parameters into this procedure (see Fig. lOb) and
then call for it to be executed by pointing the light
pencil at the command EVALUATE. The result of
the calculation will be printed by the on-line typewriter.
Figure 10. On-line retrieval of aprestored routine and insertion of parameters.
To set up a more complex expression for evaluation, the user· now changes the distance flown to the
variable C multiplied by 100. He does this by replacing 800 with the arithmetic operator X (multiply), then setting the branches to C and the number
100. Both are done with the command REPLACE
(see Fig. 11 a). The user now temporarily stores this
modified routine under the arbitrary name GUS. He
then uses the workspace to establish a new variable D
set to the value of the routine stored under the name
GUS. He does this by putting the logical operator =
immediately under the word WORKSPACE (thereby
erasing everything else) and then adding under it the
variable D and the expression stored under the name
GUS (see Fig. lIb).
This new expression is now stored temporarily
under the name JOE. A conditional expression is then
built in the workspace by putting the logical operator
From the collection of the Computer History Museum (www.computerhistory.org)
AESOP: PROTOTYPE FOR ON-LINE USER CONTROL
a
447
b
Figure 11. On-line modification of a procedure, storage and
use as a subprocedure.
IF-THEN-ELSE immediately_ below the word
WORKSPACE. The user then introduces the logical
operator TYPE on both terminal branches of the
conditional to indicate that both results of the conditional test should be typedby the on-line typewriter.
He then adds the variable D to the true branch, and
the same'plus a marker of four dots to the false
branch (see Fig. 12a).
The conditional test is set as a comparison to be
made by the operator LEQ meaning less than or equal
to. The comparison is to be made between the value
of D and the number 400 (see Fig. 12b). This portion of the routine is now stored under an· arbitrary
name ED and a next routine is constructed in order
to execute the previously defined routines.
This next routine involves the use of the operator
DO. It is used to first find the value of D and then
perform the conditional test. This is accomplished
by putting the routine previously stored under the
name JOE as a first branch for DO and then using
the command REPLACE, inserting the routine previously stored under name ED (see Fig. 12c). This
DO procedure is now stored under the name SAM
and a next. higher order routine is built.
This next routine involves the operator FOR which
is used to run through a sequence of values for a
given variable. The variable in this case is the C
which was previously used as the variable for distance
in the fuel calculation. C will be set to values from 1
to 10. The previously defined DO expression, stored
under the name SAM, is then added to be evaluated
for these values of the variable C (see Fig. 12d).
The system can be shifted to the second or inspection mode and the complete routine can be expanded for viewing of any part of the tree (see· Fig.
12e). The light pencil is used to bring any portion
of the tree to the top center (see Fig. 12f).
When the command.EVALUATE.is executed, the
typewriter prints the results of the fuel calculation
from 100 to 1000 miles in increments of 100 miles
followed by the indication of four dots when the fuel
requirement exceeds 400.
The total routine can now be stored as a permanent p::trt of the data base and later used in its entirety. The routine can also be returned to the
workspace for modification or to detach subroutines for other purposes. As long as the total routine remains filed in the data base, it is '. available
for inspection and application on-line.
As complex or extensive routines are constructed,
it beco:nes increasingly undesirable to display the
total structure to the operational user of the routine. In such ca,ses only the name of the routine and
the names of the insertable parameters need be displayed in the OAK~TREET workspace. The appropriate values for these parameters can then be
inserted by the user and the named routine evaluated on call. (See Figure 13 for example.)
In this example a routine called STATUS requires
the insertion of a destination code (AREA), the
type of aircraft(AC-TYPE), and number of aircraft
(NO-AC) to be flown to that destination, and the
number of originating airfields to be checked for the
availability of these aircraft (NO-AF). The routine
From the collection of the Computer History Museum (www.computerhistory.org)
448
PROCEEDINGS -
FALL JOINT COMPUTER CONFERENCE,
1965
a
e
d
f
Figure 12. Steps in the on-line construction of a complex
procedure using previously on-line defi~ed and
stored subprocedures. Expansion for inspection
in (e) and (f). See text for a detailed description
nf
th .. nrnf'..i!nr..
- .............. -
t"' ... - - - - -... - .
then locates up to this number of originating airfields
with sufficient aircraft available, in order of increasing distance from the destination. It lists the airfields,
the number of aircraft available, the organizational
designation of the aircraft, the distance and time required to reach the destination.
The detailed structure of user routines such as
STATUS is examined and debugged in another display environment called DEBUG. (See Fig. 14.) In
the DEBUG function, the structure of the routine is
displayed as the second leftmost limb of a tree along
with a set of commands which permit the programmer to examine any selected portion of the routine
in question and then modify and redefine it.
A routine is brought to the top of the second
leftmost limb of the DEBUG tree by an on-line
typewriter command DEBUG (name). Any subtree
of that routine is then moved to the top of that
limb by pointing the light pencil at the node on top
of the substructure in question. The structure can
From the collection of the Computer History Museum (www.computerhistory.org)
AESOP: PROTOTYPE FOR ON-LINE USER CONTROL
a
449
b
')FH:.Jl
11 F8(~ ~':71ITrs
flISTM:CE '120 f!'!
l\nAOM:
13 F86 ~'dfITr-S
OIST,'UlCF. 320 ~,,1
Tt:lr ./0. 'IP!
c
Figure 13. The use of OAK-TREET for parameter insertion
in fixed procedures.
also be displayed, in whole or in part, by itself, in
either a multinode or single node state.
By light pencil, using the command·OAK, the substructure displayed on the second leftmost branch of
the DEBUG tree is moved into the workspace of
OAK-TREET. In this position· it can be modified
using the standard OAK-TREET capabilities. The
modified structure is then moved back to the second
leftmost limb of the DEBUG environment by light
penciling the OAK-TREET command KEYBOARD.
The modified structure replaces the previous structure in the system by light penciling the redefinition
command DEFTR. The revised and redefined function can then be evaluated using the command TEST.
This procedure for on-line program development
and revision applies to all of the user and system
functions constructed in and interpreted by the
AESOP list processor, TREET (see the Appendix
for details). For example, it is possible to DEBUG
(FACTORIAL) as in Fig. 14(a), (b), (c) and (d)
or DEBUG (STATUS) as in (e) and (f). It is also
possible, for example, to DEBUG (OAK) or DEBUG (DEBUG).
In previous examples, data used in the execution
of a user's routine were inserted by means of the
user's light pencil. The results of executing the routine were printed by the on-line typewriter. However, it is also possible to have the routine call for
data directly out of the computer-based notebook
and then place the results of its execution in the
notebook. In effect, the TREET processor can be
considered one of the on-line users of the notebook-based file. The TREET processor retrieves
data from the notebook using any of the system retrieval capabilities available to the other on-line
users of the notebook. It stores data in the notebook using· the same range of storage capabilities
available to human users of the system. It uses the
same communication language.
For example, in Fig. 15, the file BLANK is organized as a scratchpad for keeping track of the input and output data derived from the evaluation of
the STATUS 1 routine. The routine STATUS 1 differs from STATUS (see Fig. 13) mainly in its use
of the notebook for its data base. Working headings
are established in BLANK for COLI through
COL4 to fix the column locations for input to
STATUS 1. Column headings are established in
From the collection of the Computer History Museum (www.computerhistory.org)
450
PROCEEDINGS -
FALL JOINT COMPUTER CONFERENCE,
1965
1" 'Vj
TA~
·l~f\~~
A~l\1\
T " 1~ /\t\
UYT~D
"!\ A
"
~
uCI~ ~
i""
"~~
I
'rnT
a
b
c
d
e
f
Figure 14. Steps in the generation or modification of an interpreted system or user procedure. See text for
details.
From the collection of the Computer History Museum (www.computerhistory.org)
AESOP: PROTOTYPE FOR ON-LINE USER CONTROL
b
~uS1
CO'I',(HOS
RrPLACr
CLr
S
ARlTH2
[l
T
TACTi CAL
1
rVALuur
LOGIC2
OAMAGr
['
1
J
K[y'OA~O
HAMtS2
OAMAGt,
[
1
J
STo~r
NUM.t~'
STATUS
[
AOD-~T
\
[~AI[
1
VA~IA'~ts
ACr
WOR"r
ST nuS!
~
'Ou~Ct-LH
onT-LH
1
STATUII
1
0
'
1
Y
os
c
d
e
Figure 15. Steps in the use of the notebook for data input
to and data output from user procedures. See
text for details.
From the collection of the Computer History Museum (www.computerhistory.org)
451
452
PROCEEDINGS -
FALL JOINT COMPUTER CONFERENCE,
then select those for transfer into permanent organization files and/or reports.
COL6 through COL10 for recording outputs from
STATUS 1. STATUS 1 is constructed to include a
data call on the file BLANK in order to list input
data from COLI through COL4, as shown in Fig.
15 ( a). It also includes a data change order to insert
output data in COL6 through COL10 as in Fig.
15 (b) . Source and destination line numbers are
supplied by the on-line user in OAK-TREET, as
in Fig. 15 ( c ). Input data qre then either generated
on-line or transferred from other portions of the
notebook into BLANK, as in Fig. 15 ( d); the appropriate line numbers are inserted into STATUS 1,
as in Fig. 15 (e); and the execution of the STATUS 1 routine updates the notebook as in Fig.
15 (f).
Using this type of on-line capability, in conjunction with capabilities for moving data from one
location in the notebook to another, the human user
of AESOP can execute routines, store resulting data
in temporary notebook files, review these results, and
I--
TREET
LIST
PROCESSOR
I--
I/O
EXECUTIVE
PROGRAM
DISPLAY
CONSOLES
APPENDIX
Aesop Software Structure
The Aesop prototype is an evolutionary experimental system. As such it is incremental in growth.
To facilitate this growth an attempt has been made
to make the system modular as much as seemed
practical. There are certain elementary system functions such as data retrieval, data updating and data
display. At another level there are additional functions that are preprocessors or switching routines for
the elementary functions. As an example there is a
COpy action that will copy data from one system
file into another. It does this by using the data retrieval and then the data updating routines in
succession. Fig. 16 outlines the functional organization of the system.
~
I----~
LP
INPUT
EXECUTIVE
PUSHBUTTON
INPUTS
1965
~
-
TREE
I-L....e
PROCESSING
TREE
DISPLAY
re
r-ei
TYPEWRITER INPUTS
~
I
COPY
SWAP
ETC
TYPEWRITER
OUTPUTS
FILE AND
OBJECT
DISPLAYS
LIST
~ CHANGE
RENAME
...... RETRIEVAL
PROGRAM
~
Figure 16. Simplified schematic of the AESOP A/I software
interrelations.
The total system occupies about 35,000 computer
words. The remainder of the computer core memory is used as free storage space for list structures.
The two prime considerations in the construction of
the system were:
1. Ease of extension to permit the system to
grow as new capabilities are added to it.
2. Speed of operation to give the operator
fast response to all of his inputs.
Economy of storage has not been a prime consideration. All of the system data base is stored in the
disk unit.
TREET is a general-purpose list processing
system* written for the IBM 7030 computer at the
From the collection of the Computer History Museum (www.computerhistory.org)
AESOP: PROTOTYPE FOR ON-LINE USER CONTROL
MITRE Corporation. All programs in TREET are
coded as functions. A function normally has a
unique value (which may be an arbitrarily complex
list structure), a unique name, and operates with
zero or more arguments. A function may or may
not have an effect on the system. Some functions
are used for their effect, some for their value, and
some for both. The OAK-TREET function as it
appears to the operator has commands, data classes
and data which can be used for procedure construction.
What follows is a simplified explanation of the
principal nodes of the limbs of the OAK-TREET
tree. OAK-TREET is constructed in TREET and
OAK-TREET expressions are evaluated by the
interpretive list processor.
OAK-TREET
COMMANDS
REPLACE - The effect of this command is to
place in the workspace, at the point indicated
by the light pencil, the expression, symbol, or
structure indicated by its argument.
EVALUATE - When this command is signalled by the light pencil the expression in the
workspace is evaluated.
KEYBOARD - When this command is signalled by the light pencil, the system will expect
the next command to come from the on-line
typewriter.
STORE - A copy of the expression which" is
indicated by the light pencil is maintained in
the system under the name of the· argument.
ADD-R T - The expression indicated by the
first argu~ent of this command will be added to
the workspace with the same parent as the node
indicated by the light pencil.
*See E. C." Haines, "The TREET List Processing Language." SR-133, The MITRE Corporation (April 1965).
ERASE - Removes the node (and all nodes
dependent upon it) indicated by the light pencil
from the workspace.
DATA
ARITH2 - Arithmetic Operators.
+ - Computes the sum of its arguments.
- - Computes the difference of its arguments.
x-
453
Computes the product of its arguments.
DIV - Computes the quotient of its arguments.
SUMMATION - Sums an expression while
a variable goes from some number to another in increments of one.
FACTORIAL - Computes the factorial of
its argument.
EXPONENT - Raises its first argument to
the power indicated by its second argument.
EQUALS - A predicate which checks for
equality of its two arguments.
LEQ - A predicate which is true if its first
argument is less than or equal to its second argument.
L T - A predicate which is true if its first
argument is less than its second argument.
LOGIC2 - Logical Operators.
TYPE - Types out the value of its arguments on the typewriter.
DO - A convenient way of grouping several
expressions under one node.
EVAL - Evaluates its argument which must
be an expression in Cambridge Polish
notation.
CONS - Computes the list of its second
argument augmented by its first argument.
MEM 1 - Computes the first member of its
argument which must be a list.
REM 1 - Computes the list of its argument
with its first member removed.
AND - Logical Intersection. Value is TRUE
if both arguments are not NIL.
OR - Logical union. Value is TRUE if
either (or both) argument is not NIL;
NIL otherwise.
NOT - Logical negation. Value is TRUE if
its argument is NIL.
A TOM - A predicate which asks whether
its argument is atomic.
EQUALS - A predicate which checks for
equality of its two arguments.
PROG2 - Has as its value its second argument. It is useful for attaching a different
value to a computation.
WHILE - Evaluates its second argument
while its first argument is (evaluates to)
true.
From the collection of the Computer History Museum (www.computerhistory.org)
454
PROCEEDINGS -FALL JOINT COMPUTER CONFERENCE,
IF-THEN - IF (al THEN a2) The value
of this expression is the value of a2 if a1
evaluates to true; NIL otherwise.
IF-TH-ELSE - IF (a1 THEN a2 ELSE a3)
The value of this expression is the value
of a2 or a3 depending on whether a1 is
true or false.
FOR - Provides a convenient way to execute an expression (its fourth argument)
for a numerical range (between the values
of its second and third arguments) of a
variable (its first argument).
= - This is the assignment operator. It sets
its first argument (which must be a variable) to the value of its second argument.
Q - Quotes its argument.
ADL - The second argument of ADL must
be a variable which evaluates to a list.
ADL sets that variable to CONS (EVAL( argl) arg2) thus effectively adding something to a list.
CHOP - The single argument of CHOP
must be a variable which evaluates to a
list. The value of CHOP is the first member of that list. The variable is set to the
remainder of the list.
FNA - The value of FNA is the value of
its argument considered as a function applied to no arguments. Its only purpose
is to represent a function of no arguments
in tree structure.
NAME - The value of NAME is the value
of its first argument. The second argument
is ignored. Name is used to label an
expression.
NAMES
This is a set of undefined symbols which may
be used as the name under which a routine is
stored for later use.
NUMBERS
This calls up a function which nerrnits any
integer to be constructed by pointing the light
pencil to its digits in sequence.
VARIABLES
This is a set of variables which can be used
in an expression in the workspace.
DEBUG
DEBUG is a function which allows other functions to be displayed and changed on-line. It
works with any interpreted function but cannot dis-
1965
play a machine language coded function. Most of
the work of debugging a function is done within
DEBUG using the light penciL In the DEBUG display are five branches -from left to right, (1) COMMANDS, (2) name of the function to be examined,
(3) type of. function, (4) ARGS, and (5) PVARS.
VIEW ACTIONS
If any node other than one in COMMANDS limb
is light penciled, then the multiple rooted subtree
headed by that node replaces the tree structure in
the second leftmost branch to the right of the
COMMANDS branch. This feature allows one to
view all of a function that is otherwise too large to
fit on the display, to concentrate attention on a particular substructure of a function, or to select which
part of the tree will be taken into OAK-TREET
for modification.
COMMANDS
RESTORB - This restores the display to its
original· position thereby cancelling all previous
view actions.
BACKUP - This command cancels the last
previous view action (if any have been performed since the last RESTORE).
OAK - The tree on the second leftmost branch
of DEBUG, to the right of the COMMANDS
branch, is placed in the workspace of OAKTREET and the OAK-TREET function is entered. Changes to the tree may be made as
desired. DEBUG is then reentered with this
modified structure by light penciling the command KEYBOARD in OAK-TREET.
KEYBOARD - This command returns control to the on-line typewriter keyboard. If the
control has been returned to the on-line typewriter, the DEBUG function may be reentered
without starting over again by typing R ( ) .
Changes may also be made using keyboard tree
changing functions.
DEFTR - DEFTR redefines the function according to the present (modified) configuration
of the tree. (Changes made to the displayed
version are not reflected in the function itself
until this is done.)
TEST - This command initiates the processing
for execution of the function displayed. The
value of the function is printed by the on-line
typewriter.
From the collection of the Computer History Museum (www.computerhistory.org)
AESOP: PROTOTYPE FOR ON-LINE USER CONTROL
BRANCH TWO
On the second leftmost branch appears the name
of the function being examined, and under it a list
of statements and location symbols. Location symbols are represented by a node containing that
symbol. Statements are represented by trees in the
same fashion as in OAK.
TYPE
The function type is normally regular type R.
Type F indicates that the arguments of the function
should not be evaluated prior to evaluating the
function itself. Type U functions allow an arbitrary
number of arguments to be specified; the arguments
455
are collected in a single list and given to the function
as one argument. A type FU function is the combination of types F and U.
ARGS
The list of
will be set as
function when
of the symbols
arguments specifies which symbols
the values of the arguments of the
it is called. The old values (if any)
are automatically saved and restored.
PVARS
The value of an argument in the program variables
list is automatically saved and restored by the
function.
From the collection of the Computer History Museum (www.computerhistory.org)
From the collection of the Computer History Museum (www.computerhistory.org)