This document proposes a new interactive computing system for CERN. It begins by outlining the computing environment and user needs at CERN to justify developing a new system. Existing interactive systems are discussed but found lacking for CERN's purposes. The proposed system aims to be intuitive for scientists, allow array-based calculations, be fully interactive, support both manual and programmatic modes, integrate with external libraries and files, and be terminal-independent. The language design draws from FORTRAN for familiarity but adds new features like array handling and protection. Key aspects are summarized, including variable types, constants, operators, and array declarations and operations. The system aims to balance usability and power for scientists doing numerical problem-solving interactively.

1. DD-jh
CERN - DATA HAlIDLINTI DIVISION
DD/Internal Report/71/6
J, Moszczynski
C. Vandoni
F. Wittmann
June 1971
A Man-Computer Interactive System

3. -1-
Foreword
The first question, which no doubt comes into mind on seeing the title
of this paper, is why propose a new interactive system when already many of these
systems exist and why not take over an already existing one.
We try to answer this question by mentioning the particular environment
where this system snould be used and looking at the computing facilities which
exist there. Some of the other systems are mentioned and we try to outline why
these systems are not fully suited to our purpose.
In the second part of this paper we propose the new interactive
language and in the third section we will discuss some problems of implementation.

4. -2-
1. The boundary conditions of a new system
1 .1. The environment
At CERN the computer users are essentially physicists and mathematicians
and most of the programming is related to scientific applications. FORTRAN is
normally used as a batch processing language. For this work, two large CDC
computers (6600 and 6500) are available; a CDC 7600 will be available next year.
There also exist several smaller computers, and an interactive file-
handling system on-line to the CDC 6600/6500 allows remote submittal and man-
ipulation of programs on-line. But there are, nevertheless, many people at
CERN who have only small problems to solve and who do not want to undertake a
major programming effort. They want to handle their numerical problems without
having to learn more about programming and systems than they will need for
solving their given task.
The problems to be solved at CERN are of the following two main types:
a) Data analysis and picture analysis which use "standard" programs
to process a lot of data from experiments.
b) Calculations to design accelerators, beam optics including the
influence of space charge, experimental statistical analysis, phase
space calculations, fitting of theoretical models by experimental
data, problems of theoretical physics, etc.
The interactive language described in Part 2 will be of help to some of
the users who have problems of type (b), especially if these problems are in a
state where the user tries different methods and wants to develop algorithms by
trial and error. Sometimes at this stage, not even the problem is well defined
when the user decides to compute something. But sometimes algorithms already
completely developed need survey in execution in order to direct them. The
language allows one to handle those problems preferably which need real interaction
in execution stage. The language is not thought to be a language for professional
programmers, but for occasional users. Also, problems of type (b), involving
extended calculations (concerning execution time) will not be suitable for this
system.

5. -3-
Considering this situation, the following criteria could be used in
the design of an interactive language at CERN.
1 .2 The requirements of an interactive system at CERN
As stated above the system should allow on-line specification, evaluation
and manipulation of algorithms. We think that the requirements of such a system
should be near to those listed below. This list is surely not complete and some
points are probably debatable, but it is thought of as a guide-line for design
only. These requirements had been found useful either by good experience with
GAMMA [6,7] or because these features have been most missed in the present GAMMA
version or because they had been found extremely useful in other systems (see
Section 1 .3).
1 ) The appearance of the language should be close to the normal
mathematical notation so that the mathematically-trained user
can easily work with it.
It is desirable forthe syntax of the language to be of a type
familiar to the user who is sometimes (or often) a user of a
normal batch-processing language. This would mean that FORTRAN
statements should be allowed as far as possible for an interactive
system.
One of the 'weak' points of the present GAMMA system has been that
a new language has to be learned by the user.
2) The system should not only allow operation on scalars but also
on arrays which should be considered as basic items of calculation.
Such an array can represent a function of one or more variables.
Any unnecessary programming, that means programming which is not
dictated by the problem itself, should not be needed on the part
of the user, e.g. the definition of arrays should always be a
definition of characteristics (dimension and number of components)
and of actual values, and the user must be able to define arrays
implicitly.

6. -4-
3) Full interaction (that means that the user can intervene at any
moment and in any step of a calculation) between the computer and
the user should be treated as essential. The response thereby should
be nearly immediate for small calculations and reasonable for larger
ones.
4) The system should be able to work in two different modes:
a) In "manual mode". For simple operations the user should not
have to type a complete program, but just have to type a simple
statement. In that way the system could be used as a function
desk calculator.
b) "Automatic mode". This means that the user should be able to
establish, to store, to run and to edit programs in the "inter-
active language". The user should be able to keep full control
over the execution of such programs.
5) The language should be easy to learn for those familiar with FORTRAN
and those who use programming languages only occasionally, and it
should be built up in such a way that the user who wants only to
use a special subset (e.g. FORTRAN) of it is not forced to learn it
al~ and that for more ambitious programming the language will yet
be rather powerful.
6) The system should include extended graphic display facilities. The
user is much more easily able to trace out his results by seeing a graph
than looking through an extended set of numbers. By a display, the
ability of the human mind in analysing pictures can be combined with
a fast digital computer. The display turned out to be essential
in the present GAMJ11A system.
7) The system should allow access to a large library of programs written
in other languages and treated as "non-interactive black boxes".
8) The system should allow easy access to external data-files on tapes
or cards or disk-files. This point was added to the present GAMl'IIA
system because it was asked for by users.

7. -5-
9) The system should be to a large amount terminal independent, i•e,
it should be possible to connect terminals as teletypes, storage
scopes, refreshed displays with normal or specialised keyboards
maintaining the same basic syntax even by using a different alpha-
bet. Of course some facilities (such as graphics) depend on the
type of terminal.
10) An editing system for programs and data should be available which
should be powerful, but easy to learn.
11) It should be possible to add new operators or data-types to the
system maintaining the same basic syntax. It turned out that in
GAMMA this nflexibility feature" was extremely useful.
12) It should be possible to translate programs written in the inter-
active language into a batch-processing language (e.g. FORTRAN)
with a minimum of effort or preferably in an automatic way.
This is an essential point if a user wants to use an algorithm
developed on the interactive system in batch-processing or to exchange
programs with people not having access to the interactive system.
That point was very much missed by some users in the present GAMlvlA
system.
1 ,3, The features of some already existing systems
When developing a new interactive language one should have a look at
other already-existing systems and to learn as much as possible from them and
try to take over as much as possible, considering the restrictions and requirements
we have here at CERN. In this context we restrict ourselves to some systems
which have similar features to the system we would like to have.
a) AMTRAN [3]: In the present version it is implemented on an IBM
1130. The language is close to mathematical notation, but it is
in its basic notation quite different from FORTRAN. So FORTRAN
users would have to learn another language. Very few conventions
are used in this language, but the capabilities are restricted in
respect of graphics and access to external files (library, data).

8. -6-
b) APL [4]: This is a very powerful interactive language regarding
array handling. The language is logically built up and well form-
alized. It is however far from being similar to FORTRAN and even
to reach compatibility would be very difficult. The language is,
even for people who know other programming languages, hard to learn
and to use.
c) BASIC [5]: This language is restricted and has features which do
not correspond with the desire for it to be close to FORTRAN. It
is implemented on many computers of different sizes.
d) GA1V1MA [6,8]: This is the system which has been implemented at CERN
and which developed from a Culler-Fried system [9]. It has been
used since 1968 for different applications. A large number of mod-
ifications and improvements have been made to the original system,
but the Culler-Fried philosophy (specialized keyboards, 11 level"-
concept, accumulator concept, single-letter identifiers, global
variables only) has been maintained.
This system allowed us to gain experience of an interactive system
with graphical facilities. Some other features have been added
to the original Culler-Fried version, because they turned out
extremely useful (e.g. library, protection of data, naming and
calling of programs, a new editing system). But the deficiencies
of the present language have been the reasons for developing the
language presented here.
e) SPEAKEASY [8]: This system in use at Argonne National Laboratory
is one of the systems which are best suited to interactive (mathe-
matical) use. It was developed from a batch-processing language.
A more complete description of existing interactive systems is given in [2].
2. The language
In this section we will not give a detailed description of the language,
not only because this would become rather lengthy, but also because it is not
yet defined in all details. The point that the language should be readable and

9. -7-
understandable to FORTRAN users was a guide in the designing of this language
and we tried to make the language compatible with FORTRAN. On the other hand
FORTRAN is not an ideal language for interactive use so that some new features,
which are typical interactive commands, will have to be added to FORTRAN.
2.1 Basic alphabet and data types
The alphabet of the interactive language is a device-independent internal
string of up to 128 characters. As the system is in many respects terminal-inde-
pendent, it is able to accept commands typed in differently represented alphabets.
The facilities are obviously dependent on the type of the terminal (for example
without a display the DISPLAY command must change its meaning).
The data representation is not different for reals and integers as in
FORTRAN. Complex and double precision calculation should be possible.
2.2. Constants and identifiers
Constants might be entered in a format-free manner, for example as
2, 2.0, 123.456 E-23, + 3.14159.
For identifiers the FORTRAN conventions are used, ignoring the distinction
between reals and integers.
The experience of the present GAMMA users showed that in interactive
computing some problems rise which do not exist in batch-processing. On of
these problems is the fact that a user may destroy his data by accident. There-
fore a protection of data and programs against overwriting is introduced and
there will be two operators followed by operands.
PROTECT A, ••• and DEPROTECT A, •••
If the user tries to overwrite protected items, he gets a warning.
2.3. Variables and arrays
A variable can be a scalar or an array. It is referenced by an identifier.
Scalars have the meaning as in FORTRAN, arrays may have (in principle) any dim-
ension and any number of components.

10. -8-
A variable can get its value and its properties in a value assignment
statement.
When at the stage of execution a variable is used which was not defined
before an error signal occurs. It should be emphasised that all errors are
signalled to the user, but they are never fatal for him.
(1)
(2)
(3)
The assignment statement has the form
x = y
Y is an expression
The variable X then gets all the properties of the expression Y.
An array X will de defined as:
x ARRAY (N1&N2&N3 .•.&Nn,a1&a2&••• )
Thereby N. are the number of components for each dimension j (1~j_~n)
l
and the N. are integers~ 1. These N. are called characteristics. The
l l
a. are component values or sets of values and they are listed in the
l
following sequence:
x ' x ' x ' x11 ••• 21 '
11. •• 11 11 ••• 12 11. .. 1N
n
• ' ' 'X11 ••• 2N ' ' ' ' ' X N N 1 ' ' ' ' 'X__ N N N
n -TI1 2' " n- TI1 2' " n-1 n
The N. and a. may also be expressions (for example other array declar-
l l
ations). All component values not set in the definition will be assumed
to be equal to 1 •
So a reduced form of (1) may be written.
which has all values set to 1 •
Another explicit form of array declaration has the form
X =ARRAY (N1&N2&N3••• &Nn,a-'j3)
where a and S are scalars (or expressions with a scalar result) and
the component values are defined as:
S-a
=a+ N -1 (j-1)
n
j 1, ••• ,N
n

11. -9-
for i 1=1, ••• ,N 1
n- n-
All operations between two arrays are done componentwise and each
operator acting on an array or a scalar will act on each component separately.
Operations between arrays of different types are illegal. Operations between
an array and a scalar are executed in combining the scalar with each component
of the array.
Any definition of a variable defined before by the same identifier
redefines this variable by characteristics and values. Variables defined ina
subprogram are local to that program if not stated otherwise.
A difference between our interactive language and FORTRAN is that a
variable is always defined by characteri.stics and values.
The subscripts allow access to single components and subarrays of an
array X defined as in (1).
Y X (i 1 i ) with 1 < i . < N.
• • •' n J J
puts the component X. .
l1 .•. in
into Y.
The i. (subscripts) are integers. They can be expressions with a scalar
J
result which will be rounded to the nearest positive integer in the allowed range.
The statement
y = x ( ' ••• 'i j ' ••• ' ik' .•. )
with < ij < Nj 1 ~ ik ~ Nk
defines an array Y which is a subarray of X and where the corresponding indices
(j and k) are fixed with the values ij and ik.
If j the statement reads
y x (i1, ••• ,ik, ••• ,)
If k n the statement reads
y x (, ... ,i., ... ,i)
J n

12. -10-
The number of commas must be n - 1 • The array Y has the dimension of
X minus the number of fixed values i .•
J
Its characteristics are
After an array has been defined (explicitly or implicitly by context)
it is possible to change a component by an assignment statement:
z, where Z is a scalar or an expression with a
scalar result.
Similarly, the subarray X(, •.. ,ij, ••• ,ik, •••,)
can be changed by
x (' ... 'i j' ••. 'ik' ••• ')
is an array with the characteristics
Z where Z
or a calculable expression having an array of these characteristics as a result.
2.4. Arithmetic expression statements
The main difference between the interactive language and FORTRAN in
this area is that here the operators may work on arrays as operands. So the
user is not obliged (but he is able) to use explicit indexing.
The feature of having arrays as basic items involves having special
operators which have only a meaning applied till arrays. Let X be an array defined by
then
(1 ) Y = SUlVI(X)
Y. . .
i1, .•. ,in-1J < j < N
- n
with
(2) y DIFF(X)

13. with
for all
-11-
Y. . . = (X. . . 1 - X. . .)
i1 '•. in-1 J i1 • •. in-1 J+ i1 '•. in-1 J
1(j(N -1
--n
Y. . N
i1 ••.• i 1
n- n
X. . N -X. N
i1 • • • .in-1 n i1 •' .in-1 n-1
(3) Y MAX(X)
Y. . = max {x. . }
i1 • •• in i1 ••.in
where max takes the largest value of all arguments
~ i1 ~ iN1
< i < iN
- n-
n
(4) Y = NCO(X)
gives an array whose explicit definition would be
(5) If Z is an array
Z = ARRAY(N1&N2&N3•• .&Nn_1&Mn,a1 ,& ••• )
then
Y = X&Z gives an array Y
where Y has the characteristics
Y = ARRAY (N1&N2&••• N 1&N +M )
n- n n
and the component values are:
If S is a scalar
then Y = X&S
X. . . for 1 < i <N.
i 1 ••. in_1i - - i
Z. . . N
i1 • • .in-1 i- n
for N < i < N +M
n - - n n
has the characteristics (N1 , ••• ,N 1 ,N +1)
n- n

14. and the components are
Y. . .
l1···ln-1l
-12-
X. . .
l1 • • .in-1l
s
< i < N
- n
i=N +1
n
(6) y RS(x,s) where s is a scalar O< s < N1
X.
l1 ••• i. 1(i-s) s < i ~ Nn
n-
x.
l1 · .. i 1(i-s+N) 1 < i < s
n- n
(7) Y LS (x,s) where s is a scalar 0 < s < Nn
X. i 1 (i+s)
0 < i < N -S
Y. i 11 · •. n
i n-
l1 n-1
X. i 1 (i+s+N ) N -s < i < N
11 · •• n - n
n- n
It should be stated that on the right hand side of an assignment
statement, all variables can be expressions having an array ora scalar as
result. If the characteristics of the array do not match at execution time
an error will be signalled.

15. At the end of this paragraph some examples should be given for one and two dimensional arrays:
Xis a one-dimensional array ('vector')
Then
1) X =ARRAY (n)
gives an array with all n components equal to 1.
2) X = ARRAY (n, 1 -> n)
gives the array (1 , 2, ••• , n)
3) Y = x(m) 1 < m < n
puts the m-th component of X in Y
4) X(k) = Y 1 < k < n
puts the value of Y (scalar) in the k-th component.
5) S is a scalar then
y = X&5
6)
gives a one dimensional array with (n+1) components,
the first n's being xi, the component (n+1) equal to S.
y SUM(X) is the running sum.
7) y NCD(X) gives a scalar with value n.
Xis a two-dimensional array ('matrix')
1 ) X = ARRAY (n & n)
gives a matrix with all components equal to 1.
2) X = ARHAY (n & n, _, n)
gives the matrix
(
1,2,3, ...n)
1,2,3, .•• n
3) Y=X(m,) 1 < m < n
gives a vector Y which is built up by then-th row of
the matrix X. In this case Y would be defined by the
above equation as an array.
4) x( ,k) = Y
puts the one-dimensional array Y into the k-th column
of X.
5) Let Z be a matrix of the dimensions (n,2)
z (
z,x)
z,x
z,x
X = ( 1 , 2 , ••• ,n)
1,2, •.•,n
then
y = X Z =(:::::::::::~:) ( n(n+1))
=(12 •••n) then Y = SUM(X) = 1 '~' 6 , •••, 2
12 ••• n • n(n+1)
1,3,6, •••, 2
6) If x
7) Y =NCO (x) gives a one-dimensional array with two
components i.e. (n,n)
I
--'"
IJJ
I

16. -14-
An example of a three-dimensional array.
There are three matrices given, x, Y and Z (all of dimension N x u) and an
operator (or sequence of operators) DP should act on all of these matrices.
This is
This could be written as:
xr OP X
yr = OP Y
zr = OP Z
The user could define as well a three-dimensional array T by:
T = ARRAY (3&N&N, X&Y&Z)
T1 = DP T
X' T (1 '
yr T (2,
zr T (3'
convenient if DP is a large sequence of arithmetic operators
2.5. The IF statement, GD T¢ statement, D@ loops
The relational operators have a structure similar to that of FORTRAN.
Relational expressions may be used in IF-statements.
The statement numbering will be done as in FORTRAN. The IF statement
as in FORTRAN will be allowed and it is written
IF(<expr>)<statement>
However the IF statement in the following (Algol-68) form should be accepted as
well
THEN {<statement>} ELSE {<statement>} FI
IF <expr) <expr > <expr)
The G¢ T¢ <Label) has the same meaning as in FORTRAN as well as the
computed G¢ T¢ (label 1 , ••• , label n) K, where K is a scalar or an expression
with a scalar result which is cut to be the nearest positive integer. All labels
can be expressions with positive integer results (after rounding).
The D¢ loop is externally written as in FORTRAN
D¢ label i=m1 ,m2,m3
but m1,m2,m3 can be any real number (or expressions having a scalar result).

17. -15-
2.6. Display operators
This group of operators is used for graphic display terminals only
and the syntax is mainly taken over from the present GAMMA system.
The most general command is:
DISPLAY (a-->b, c-->d) A%B,c%D, ••• ,
where a,b,c,d, are scalars or expressions with scalar results and A,B,C,D, ••.
are one-dimensional arrays.
Then
A is displayed in Y-direction against B in X-direction
C is displayed in Y-direction against D in X-direction
and the X-values run from a to b, the Y-values from c to d.
The DISPLAY command without an argument in the brackets or with only
one argument fits the display of A against Bon the screen, so that the screen
(with or without a remaining restriction from the bracket) is fully used. The
function C is then displayed over D.
If %B, %D are missing the corresponding function is displayed against
the last defined X-values.
Example:
DISPLAY A%B,C
displays A against B using the complete screen and displays that part of C
against B which fits on tne screen.
A facility to display curves in a logarithmic scale will be provided
as well as display facilities for multi-dimensional arrays (or projections of
them). The user is able to display functions in dotted mode.
The command
TYPE X,Y,list
displays the "list" starting at the coordinate values X and Y on the present
screen. X and Y are scalars;
text and/or scalars.
"list" may be text or variables representing

18. -16-
The command
PRINT X,Y, .••
prints X,Y on the on-line printer. A similar command PUNCH could be used to
punch programs and data.
2.7, Subprograms
Subprograms are written and called as in FORTRAN and the FORTRAN
library should be accessible.
2.8. Global and local data
All variables defined in a subprogram are local to this program. The
possibility of declaring some of the variables global to this subprogram and the
main program ("manual mode") will be provided by a declaration statement
GLOBAL X, Y, •••
to be inserted in.the subprogram.
As far as the language is described here it is possible to write
normal FORTRAN programs and run them in the interactive language if all dec-
laration statements are left out. Complex calculation is not treated in this
description of the language; it is indispensable to add it later. A link
between complex and real data has to be thought of with all consequences.
At the end of this section we will give an example showing the diff-
erences from FORTRAN.

19. FOR'l'RAN
PROGRAM CIRCLE
DIMENSION s(100),c(100)
STEIJ = 0. 0628
x = 0
D¢ 1=1, 100
S(I) SIN(X)
c(I) cos(x)
1 X = X+STEP
CALL DISPLAY (c,s,100)
STOP
EJT])
-17-
The FOR'l1RAN subroutine DISPI~AY
is assumed to be able to display
the circle.
3, Implementation
3.1. The computer to implement tne system
Interactive language
X = ARRAY (100,o->6.28)
DISPLAY cos(x)%SIN(X)
Several solutions exist already as regards the kind of computer to
drive an interactive system. The computers are different in size and
speed ranging from an IBM 1130 of AMTRAN to IBM 360/91 of APL.
So the question of what is the optimal solution for an interactive
system as regards computational speed, access time to files, availability of
computer tim~ etc., is very difficult to answer generally and the question can
only be answered by looking at the particular needs of the users.
The experience at CERN with GAlllll'iA and with FOCUS [1] showed us that an
interactive system should not be completely cut off from the main computer facilities
(when these are available). An isolated system will always be restricted to
a certain kind of problem and to a certain class of users. The main disadvantage
of such a disconnection is not the smaller speed or the size of the computer but
rather the access which is missing to files and library programs and the compat-
ibility problems with batch processing.

20. -18-
For this reason we think that the best solution is to implement
the interactive system as a parasite of the main computer facilities, e.g. of
the CDC 6600. In this way we hope that it will be possible to solve the problems
concerning compatibility with batch processing, the access to external files
and the problem of having a large library of subprograms as is available for
batch processing.
3.2. Problems of implementation
Here some of the problems will be quoted which have been encountered
in the implementation of such a system.
The most important of these is the reaction time of the system for
a user who is working at the terminal. In this respect a small dedicated
computer will probably answer faster for small calculations, because a large computer
cannot answer very quickly to frequent interruptions. On the other hand, for
running larger and larger programs the capacity and the speed becomes more and
more visible.
By statistical measurements it was found out that user's actions are
rather frequent at peaks (up to 3 actions per second) but these peaks are rare
and the "thinking time" between them is of the order of 30-45 seconds. There-
fore a way has to be found now to smooth out these peaks in order not to have
to disturb the computer too often. This means that the large computer should
only be disturbed when an answer is really requested from it. Therefore the
terminals will not be connected directly to the CDC 6600 but they will be
linked to it via a Hewlett-Packard 2116B as a "clerical computer" whose functions
are:
a) to multiplex the different terminals working with diff-
erent data rates (graphic displays, teletypes, keyboards
etc.)
b) to perform a basic syntactical check for correctness of
a single statement
c) to allow the editing of user's programs
d) to inform the users of the status of their problems.

21. -19-
So the 6600 will only be asked for a computation when a set of
statements is completed and ready for execution, e.g. when the user wants
to see a result or when a user's program is completely defined or edited.
Another problem is in regard to the priorities of the load on the
main system which should consider the batch processing problems at least as
important as the interactive problems. This imposes a ve-ry severe limitation
on the core storage available for the interactive system (at present 20 K of
a total 131 K). The system will therefore make extensive use of segmentation
and it will be subdivided into several overlays and segments residing on disks
and drums. One has therefore to look for a subdivision of programs and
userB data in such a way that the user does not feel too much the access time
to external storage media.
3.3. The terminals
For the terminal layout and the hardware used for display there is
some experience at CERN from FOCUS and GAJ'llMA. GAJ'llMA was originally imple-
mented on a refreshed display (CDC 250) and later on a storage tube display
(Tektronix T4002), FOCUS makes extensive use of teletypes and storage tube
displays T4002. As a result of this experience it turns out that at present
storage tube based terminals are well suited to interactive use. On the other
hand, large efforts are made to develop cheaper display terminals which are
refreshable. So in some years' time other display terminals could turn out to
be better suited.
For the input, teletypes and specialized keyboards are available.
It depends very much on the problem and on the users which of these are
preferred. If a user is used to Working on typewriters, he will probably prefer
a normal teletype to a specialized keyboard where for some basic operators
keys are available.
A specialized keyboard however is thought to be the most easy for
the average user to input his programs and data. The system will be designed
so that it is terminal-independent and a subset of the system will allow desk-
calculator facilities on a normal teletype.

22. -20-
Figure 1 shows the layout of the terminal now in use for GAMMA. It
consists of a T4002 storage scope display and of a specialized keyboard.
3.4, Some software problems
The implementation of the system will be modular to allow a certain
independence from the computer, from the operating system, from the terminals
used, etc. This was decided because of the rapid evolution on the one hand and a
possible change of the computer on the other hand.
The implementation on a modular basis was also desired because the system
will start with a minimal set of facilities and other or more complicated fea-
tures (such as recursivity) will be implemented later.
The source statements are treated in the following way. The original
language (as described before) is translated into an intermediate form, similar
to a polish notation. This intermediate language is turn interpreted.
For the user's programs two copies are kept by the system:
a) The original (source) program which is used when the user wants
to correct or display it.
b) The translated version when the user wants to execute it.
The intermediate form is in a certain way "data-independent",.which means
that the data-type is only defined at execution time. The user can by this
method, run a program once by defining certain variables as scalars and the next
time by treating them as arrays.
It is also worth mentioning that the whole system is based on a
dynamic storage allocation and retrieval scheme which allows any part of the
system to retrieve any information,regardless of its actual position, just by
asking its name.
The swapping between users will be implemented primarily on a very
simple principle. Each user is served in a round-robin way within the limit
of a slice of time and each user keeps control on the computer at least until
a complete statement is evaluated. If a user exceeds his time slice he will
get less (or no) time at the next turn. A dynamic time slicing scheme will
be implemented. The user swopping at a lower level (i.e. multiplexing the

23. -21-
various inputs and outputs from/to terminals) will be done by the Hewlett-Packard
2116B. A re-entrant editor will also be present there to allow editing of
programs of several users at a time.
Finally, it is worth noting that almost the complete 6600 part of the
system will be written in FORTRAN, with the exception of a few machine-dependent
routines written in machine language. In this way the implementation will become
easier and the system will get a certain degree of machine independence.
This description of the implementation is, as the language part, not
a definite one and several problems are not yet treated here (e.g. the problem
of library connection).

24. -22-
Fig. 1: The present GANI!VJA terminal

25. -23-
Bibliography:
(1) E,M, Palandri
The FOCUS remote access system. Presented at the Int.
conf. on data handling systems in high energy physics,
Cambridge, England, 23-25 March 1970.
(2) M. Klerer, J. Reinfelds
Interactive systems for experimental applied mathematics
Proc. of the Ass. for Computing Machinary, Inc. Symposium
held in Washing.ton, D.C., August 1967.
(3) N. Eskelson, H. Kopetz
A preliminary description of the IBM 1130 AMTRAN. Amtran
Report 1969-6, University of Georgia, Athens.
(4) A.D. Falkoff, K.E. Iverson
APL/360/. User's Manual. IBM 1968.
(5) M.V. Farina
Programming in BASIC, the time-sharing language. Englewood
Cliffs, N.J., Prentice-Hall, 1968.
(6) CERN computer manuals
GAMMA users manual, CERN, Geneva, Data Handling Division.
(7) L.B. Smith, C.E. Vandoni
Graphical man-machine interactive systems for numerical
problems CERN report CERN 70-23.
(8) s. Cohen, C.M. Vincent
An introduction to Speakeasy. Argonne Physics Division,
Informal Report PHY-1968E.