⟦dcc18dbec⟧

TextFile

JOB SJ 4 292932 TIME 3 0 SIZE 30000 PERM DISC1 100 1 TEMP DISC 500 10

MODE LIST.YES

DES80COMPRG=SET 100 DISC1
(DES80COMPRG=SLANG TYPE.YES LIST.NO XREF.NO TTDUETCOM
DES80COMPRG=CHANGEENTRY DES80COMPRG DES80COMPRG DES80COMPRG DES80COMPRG DES80COMPRG 3.0 DES80COMPRG
END)
M. VERSION
<:DES80COM, VERS. 3, 13.7.78:>
N.
M. CORRECTION OF EO, E1, E3, ..., E7:

...

N.
M. PROCESS CATALOG START
0, <:DES80:> ,0,0
M. PROCESS CATALOG END
N.

SCOPE PROJECT DES80COMPRG
FINIS

Figure 8.
\f

*DES80COMPRG=SET 100 DISC1
*DES80COMPRG=SLANG TYPE.YES LIST.NO XREF.NO TTDUETCOM
4 0 FPNAMES
269 22 TYPE
269 22 VERSION
286 6 TYPE
287 6 CORRECTION OF E0, E1, E3, ..., E7:
292 6 TEXTS
355 202 TYPE
356 202 USER CATALOG START
366 436 USER CATALOG END
390 436 TYPE
391 436 NO PRINTERS
2227 3454 TYPE
2228 3454 PROCESS CATALOG START
2230 3464 PROCESS CATALOG END

NEW DUETCOM2 SIZE 5388 BUF 5 AREA 5 WORK 0 0 0 DISC

SLANG OK 1/4410/9
*DES80COMPRG=CHANGEENTRY DES80COMPRG DES80COMPRG DES80COMPRG DES80COMPRG DES80COMPRG 3.0 DES80COMPRG
*END
*SCOPE PROJECT DES80COMPRG
*FINIS

Figure 9.
\f

1_._ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _I_N_T_R_O_D_U_C_T_I_O_N_ 1.

1_._1_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _P_u_r_p_o_s_e_ 1.1

Target Group This manual is intended for the group of people
who are responsible for the daily running of DES80
(the Data-Entry-System for SYSTEM80).

Survey Chapter 1 gives a short survey of the system.

Establishment The establishment and maintenance of the system
Maintenance take place in cooperation between the operating
department and the individual user's consultant.
The operating department is responsible for that
which concern all users. This part of the respon-
sibility is described in chapter 2. The consultant
is responsible for everything which concerns the
user he is working with. The work of the consul-
tant is described in ref. 1.

Upstart The daily start up of the system is described in
chapter 3.

Restart Likewise restart of the system after breakdown is
described here.

Commands Chapter 4 describes the commands which can be used
by the operator.

Closing Chapter 5 describes the daily closing of the sy-
stem.

Errors Finally, a survey of possible errors is given in
chapter 6.
\f

1_._2_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _S_u_r_v_e_y_ _o_f_ _t_h_e_ _S_y_s_t_e_m_ 1.2

Below DES80 is looked at from different point of
view.

User The designation 'user' is in the following applied
Operator to a company or institute using the system. To
each user a number of operators will be attched,
they will type via terminals.

The individual user can consider DES80 as a system
which can be used by on-line typing and replace-
ment in bundles of transactions for SYSTEM80. In
fig. 1 you see how a user with three operators
uses the system.

Figure 1.
\f

In ref. 7 a further description of the general
user functions is given.

On a superior view DES80 can be described as a
system used by several users by typing transac-
tions for SYSTEM80. This is outlined in fig. 2
where four users with eight operators are typing
simultaneously.

Figure 2.

For the operating department DES80 consists of:

- a user description file (DES80CAT),
- a communication module (DES80COM),
- a program used for initialization and termina-
tion (DES80UPDATE),
- a terminal operating system (DES80ONLINE),
- the user's read-in programs,
- the user's local data descriptions,
- various other files.
\f

1_._2_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _S_u_r_v_e_y_ _o_f_ _t_h_e_ _S_y_s_t_e_m_ 1.2

This way of looking at DES80 is described in fig.
3.

Figure 3.
\f

F_ 2_._ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _E_S_T_A_B_L_I_S_H_M_E_N_T_ _A_N_D_ _M_A_I_N_T_E_N_A_N_C_E_ 2.

2_._1_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _I_n_ _G_e_n_e_r_a_l_ 2.1

There is a number of tools to help establish and
maintain the system:

DES80USER With this program the consultant and the operating
department create a file containing information
about the individual user (DES80CAT).

DUETCOM The communication module is an s-process
(DES80COM), in which the program DES80COMPRG is
executed. DES80COMPRG is created by an adaption of
TTDUETCOM with the so-called options.

SODA-LD This program is used by the consultant for the
creation of a compiled local data description for
the individual user. (In the following the abbre-
viation ld is used for local data).

DUETABLER The program DUETABLER is used by the consultant
for compiling the user's read-in program which is
written in the DUET language.

SYSDOK This program is used for creation and maintenance
of the text files.

DES80ONLINE A part from these tools the system includes two
and program files (DES80ONLINE and DES80UPDATE) and a
DES80UPDATE number of job- and data files.

Sections 2.2 to 2.5 concentrate on the establish-
ment and maintenance of the user description file
(DES80CAT), the communication module, the local
data descriptions and the read-in programs and
change of BOSS-adaptions, while section 2.6 gives
a survey of the files of the entire system.
\f

2_._2_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _U_s_e_r_ _D_e_s_c_r_i_p_t_i_o_n_ _F_i_l_e_ 2.2

The running data entry-system requires a descrip-
tion of the individual users, their configuration,
and status. This information is stored in a file
created by the operating department which can be
read and updated by the running system. The file
contains part general information, e.g. the maxi-
mum number of users and operators, and part spe-
cific information about the individual users. E.g.
information is stored about the individual user's
operators.

Creation The user description file is created by the ope-
rating department in cooperation with the user
(the consultant). Part of the information must be
specified by the user and part of it by the ope-
rating department.

The operating department provides the user with a
user No., a catalog base, a kitname for transac-
tion files and, a number for each of his opera-
tors.

The user description file is created by means of
the program DES80USER, which makes a compilation
of a textual description to a description on bi-
nary form. The standard name of the binary file
is DES80CAT).

The user description in its textual form is stored
in a sysdok file and maintained by SYSDOK (ref.
2).
\f

Updating Both DES80USER and the operating system can update
the user description file. The information which
can be changed by DES80USER concerns the sysdok
file, catalog bases, kitname and identification of
user, operator, and printers. The running system
can update information about the transaction flows
and the identification of the operators.

A more detailed description of DES80USER is found
in appendix B, in ref. 1.

BOSS The connection between BOSS user catalog and the
catalog bases is shown in fig. 4.

USER No. 3

THE DES80 SYSTEM USER No. 2

USER No. 1

PRIVATE FILES OF DES80

Figure 4.

There are three types of bases:

------ The DES80-system is started up on this base so
that the system is able to see the scopes of all
users and use the private files of DES80.

-.-.- The private files of DES80 are in this base, e.g.
the user description file, programs and workfiles
containing bundles.

- - - This base corresponds to the user's base for the
routine-project in which e.g. the database de-
scription is stored, and the batch-modules are
executed.
\f

Fig. 5 shows an example of a print out from the
compilation of a user description file.

DES80 USER CAT.UPD. V1 TESTDATA 10.10.1979 1
VERS.13 11.08.1979 (last vers.19) Section 1

1. USER FILE sect. vers. 13

10 CATALOG:
15 USERBASE: 12860 12864
20 MAX USER: 5 MAXOP: 10
30 USER 1 desa desa descrip 51
40 USERBASE: 12865 12869 DISC1
50 OP: 1 1
60 OP: 2 2
70 OP: 4 3
75 OP: 7 4 JONATHAN
80
90 USER: 2 desb desb descrip 51
100 USERBASE: 12870 12874 dk290155
110 OP: 3 1
115 OP: 5 2 JOHN
120
130 USER: 3 desc desc descrip 51
140 USERBASE: 12875 12879 DISC2
160 OP: 6 1 MARY

Figure 5.

In the example the private files of the system
have the base from 12860 to 12864. User No. 1 has
the base from 18265 to 12269. User No. 2 has the
base from 12870 to 12874 and user No. 3 from 12875
to 12879. The DES80 system in the example is thus
to be started up on a base covering the interval
from 12860 to 12879.

2_._3_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _C_o_m_m_u_n_i_c_a_t_i_o_n_ _M_o_d_u_l_e_ 2.3

TTDUETCOM The communication module DES80COM, which must be
used in DES80, is created by an adaption of
TTDUETCOM with the so-called options. Ref. 3 con-
tains a description of the method.

The DES80 adaption includes:

- correction of constants
- translation of texts from English to other
languages
- instertion of a terminal catalog
- insertion of a process catalog

Please note that a line printer cannot be used via
DES80COM in DES80.

The options in fig. 6 are all in accordance with
the user description in fig. 5. Here M. results in
a print out of the succeeding comment, whereas N
has the result that the slang-compiler again reads
from the TTDUETCOM textfile.

The order in which information for the terminal
catalog must be stated is shown in the example on
page 24 in ref. 3.

The first line in the terminal catalog refers to
the central operator. The other lines refer to the
user's operators. The number in brackets <: and :>
is the <operator No.> which is stated in the user
description file (see ref. 1 and section 2.2 of
this manual). The name in brackets <:and:> is the
<user _id> from the user description file. The last
figure in each line must be part of a consecutive
numbering of the individual user's operators. The
central operator must have number 0.
\f

An example of the duetcom-options is found in the
file DES80OPT.
\f

F_ M. VERSION
<:DES80COM, VERS. 3, 13.7.79:>
N.
M. CORRECTION OF E0, E1, E3, ....., E7:
E0= 1 ; NUMBER OF RECEIVING PROCESSES
E1= 4 ; NUMBER OF ACTIVE TERMINALS
E5= -1 ; TEST.No.
E6= 1 ; FILLCHAR
M. TEXTS
A1 : <:BYE:> ,0,0
A2 : <:MESSAGE:>, 0
A3 : <:USER No. TOO BIG <10>:>
A4 : <:USER No. MISSING <10>:>
A5 : <:ERROR IN USER NAME <10>:>
A6 : <:USER ALREADY EXISTS <10>:>
A7 : <:ERROR IN PROCESSNAME <10>:>
A8 : <:TERMINAL ALREADY EXISTS <10>:>
A9 : <:UNFORTUNATELY WE DO NOT KNOW YOU <10>:>
A10: <:TYPE USER NAME AND NUMBER <10>:>
A11: <:THANKS FOR TO DAY <10>:>
N.
M. USER CATALOG START
0 H. 0,0,0,0,0,0,0,0 W. 0,0,<:00,:> , <:DESOP:> , 0,0,0
0 H. 0,0,0,0,0,0,0,0 W. 0,0,<:01,:> , <:DESA :> , 0,0,1
0 H. 0,0,0,0,0,0,0,0 W. 0,0,<:02,:> , <:DESA :> , 0,0,2
0 H. 0,0,0,0,0,0,0,0 W. 0,0,<:03,:> , <:DESB :> , 0,0,1
0 H. 0,0,0,0,0,0,0,0 W. 0,0,<:04,:> , <:DESA :> , 0,0,3
0 H. 0,0,0,0,0,0,0,0 W. 0,0,<:05,:> , <:DESB :> , 0,0,2
0 H. 0,0,0,0,0,0,0,0 W. 0,0,<:06,:> , <:DESC :> , 0,0,1
0 H. 0,0,0,0,0,0,0,0 W. 0,0,<:07,:> , <:DESA :> , 0,0,4
M. USER CATALOG END
N.
M. NO PRINTERS
N.
M. PROCESS CATALOG START
0, <:DES80:> ,0,0
M. PROCESS CATALOG END
N.

Figure 6.\f

In one of the last lines of the print out from the
compilation of the communication module some para-
meters (size, buf, and area) are printed. These
are used to start the communication module. Fig.
7 shows an example of this.

new duetcom2 size 5388 buf 5 area 5 work ...

Figure 7.

Fig. 8 shows an example of a job file which crea-
tes a communication module with the name DESCOMPRG
whereas fig. 9 shows primary output from the job
run.

DES80COMPRG should lie on the system level (the
widest possible bases) so that it can be located
by the operating system s.
\f

F_ (skema side 18 i kladde)
\f

F_ (skema side 19 kladde)
\f

F_ 2_._4_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _L_o_c_a_l_ _D_a_t_a_ _D_e_s_c_r_i_p_t_i_o_n_s_ _a_n_d_ _R_e_a_d_-_i_n_ _P_r_o_g_r_a_m_s_ 2.4

Allocation of The following two elements of the data-entry-
responsibility system are vital for the individual user:

- The user's ld-description
- The user's read-in program

Consultant Both these must be established and tested by the
consultant and he is responsible for correct ver-
sions of

- The ld-description in compiled form
- The read-in program in text form

being available on the user's routine project.

General All the user's compiled read-in programs should be
merged into the same program file. Thus a new com-
piled read-in program is established by the con-
sultant in cooperation with the operating depart-
ment.

Operating The operating department is solely responsible for
department the replacement of the existing program file with
the new one.

Partly because it is important that the establish-
ment takes place in correct order, and partly be-
cause of the distribution of responsibility the
routine stated below must be observed carefully.

Point 1. Usually the development of a user system takes
place on another machine than the one used for the
user's operations. Thus it will be necessary to
copy the files listed below, from magnetic tape to
disc store.
\f

- ld-description in compiled form
- read-in program in textual form.

This takes place on the routine project of the
user. The consultant carries the sole responsibi-
lity for this.

Point 2. The total program file (normally called DES80DUET)
with the read-in programs is divided into blocks
numbered from 0 and onwards (see ref. 4). The
operating department gives the consultant one or
more block numbers which must be used for the
compilation of the read-in program. A reasonable
convention would be to provide block numbers for
users so that user No. 1 gets block 10 to 19, user
No. 2 gets block 20 to 29 and so on.

Point 3. The consultant can now compile the read-in program
and merge it with the official version of the pro-
gram file. A new version in a new program file is
created (this could be called NEWDUET). The con-
sultant checks that the program is correctly crea-
ted.

Point 4. The operating department checks by comparing the
log print outs from the creation of the official
version and the new one

- that no other users are affected by the
compilation
- that the program file is created correctly

Point 5. The operating department turns the new version
into the official version. The log print out
remains with the operating department as documen-
tation.

NB! Please note that items 3, 4, and 5 must only be
performed for one user at the time.
\f

2_._5_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _B_O_S_S_-_A_d_a_p_t_i_o_n_s_ 2.5

If the DES80-process is to be started up under
BOSS (see chapter 3), the following must be taken
care of:

Catalog A BOSS user catalog structure (see ref. 10) should
be established corresponding to the one described
in section 2.2.

A user with the name DES8 and one user index cove-
ring the entire project interval must exist, or be
created.

Fig. 10 shows an example which corresponds to fi-
gures 4 and 5. It will be seen that the files of
DES80 lie with user DES, the files of user No. 1
with DESA and so on.

11 DES8 292932 0 20 1 12860
5 PRESERVE YES
6 PRESERVE YES
11 DES 292932 0 1 5 12860
11 DESA 292932 0 1 5 12865
11 DESB 292932 0 1 5 12870
11 DESC 292932 0 1 5 12875

Figure 10

Options If a job under BOSS here DES80 (see chapter 3) is
able to communicate with a process outside BOSS,
this must be described in the BOSS-options for the
insstallation in question.

The name of the process, in which the communica-
tion module is executed, is insterted on page 1
in the options, after e44. Standard name is
DES80COM (see section 3.2).
\f

The buffer size of terminals communicating with
DES80COM is inserted after e20. The size is 100.

Fig. 11 shows the relevant part of page 1 in op-
tions with the adaptions mentioned in boxes.

e44: ; list of process names simulated by boss (8 bytes each)

<:des80com:> , 0

e45: ; end list of process names

e20:h.; list of buffer sizes (bytes) for process control

100

Figure 11.

2_._6_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _F_i_l_e_s_ 2.6

To establish, maintain, and operate DES80 a number
of files are required on disc store.

These files can be divided into the following
categories:

- job files
- program files
- data files.

Below a short survey of the files is presented,
and it is explained how to create the files, or
reference is given to a more detailed explanation.
\f

JOBFILES INITJOB These files are created by the
ONLINEJOB operating department - if necessary
FINISJOB with the assistence of a consultant
the use is described in sections 3.4,
3.5, and 5.2. Syntas for calls of
program se ref. 1.

PROGRAMFILES DES80USER Fetched from the system tape.
DES80UPDATE
DES80ONLINE
SODALD
DUETABLER

TTDUETCOM The two first mentioned files are
DES80OPT fetched from system tape and are used
DES80COMPRG as described in section 2.3 for the
creation of the third file.

DATAFIELS SODATABLE Fetched from system tape working file
DUETTABLE for @JOBSTATUS must be available to
BRTABLE2 all users.
DES80FINIS

DES80CAT See section 2.2. The name can be adap-
ted.

DES80DUET See section 2.4. The name can be adap-
ted.

DES80DATA Permanent files created by system ge-
DES80LOG nerating. Names can be adapted. The
LIST OUT files contain information of status
and log, se ref. 1.
\f

DES80RETURN By system generating a file the name
of each user is created on his own
base. No file with this name is allo-
wed to exist on the private base of
the DES80-system. When the transaction
file is used it must be renamed to
DES80RETURN.

DESVAR00 Created and administrated by
DESVAR0XX DES80ONLINE.
WRJXXXXXX
\f

F_ 3_._ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _S_T_A_R_T_ _U_P_ _A_N_D_ _R_E_S_T_A_R_T_ 3.

3_._1_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _I_n_ _G_e_n_e_r_a_l_ 3.1

Routine In this section the daily routine for start up and
restart of DES80 are described. It is presupposed
that DES80 has been established on the installati-
on.

Both start up and restart are normally made under
the basis operation system s (ref. 5).

Processes The data entry-system requires two processes. The
first DES80COM, is used for communication between
the terminals and the operating system. This pro-
cess is always created under s.

The second process, DES80, is used for

- initialization
- termination
- the running system.

This process might be initialized from BOSS.

Operating In section 3.2 the communication module is descri-
system bed and the creation of the DES80-process is de-
scribed in section 3.3. Section 3.4 discusses ini-
tialization runs. Finally start up of the running
system is described in section 3.5.
\f

3_._2_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _C_o_m_m_u_n_i_c_a_t_i_o_n_ _M_o_d_u_l_e_ 3.2

The first to be created when starting up or after
a machine break-down is the process (DES80COM),
through which the user's terminals communicate
with DES80. If the DES80 process is to be initia-
lized by means of BOSS DES80COM must be created on
the installation before BOSS.

Fig. 12 shows how to start the process.

ATT s
NEW DES80COM LOGIN <low> <up>
READY
ATT s
USER <low> <up> PROJECT <low> <up>
READY
ATT s
SIZE <sss> ARE <aaa> BUF <bbb> TEMP <kit> 0 0
READY
ATT s
PROG <des80comprg> RUN
....

Figure 12.

The name of the process is DES80COM. The estab-
lishment of the program to be executed in DES80COM
is described in section 2.3. The size, buf, and
area (<sss>, <bbb>, and <aaa>) of the process must
be those stated at the compilation. <kit> states
the name of the kit, which is used for temporary
resources. The base (<low> and <up>) which is used
by start up is the base containing DES80's private
files - i.e. the one corresponding to the dot and
dash line in fig. 4, while the project base is co-
vering the whole DES80-system.
\f

Fig. 13 shows an example in which the communica-
tion module of the system established in chapter 2
is stated.

ATT s
NEW DES80COM LOGIN 12860 12864
READY
ATT s
USER 12860 12864 PROJECT 12860 12879
READY
ATT s
SIZE 5388 AREA 5 BUF 5 TEMP DISC 0 0
READY
ATT s
PROG DES80COMPRG RUN
. . .

Figure 13.

It should be mentioned that the process could be
described in s usercat and started by the job com-
mand.

3_._3_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _T_h_e_ _D_E_S_8_0_ _P_r_o_c_e_s_s_ 3.3

Apart from the communication process a process,
DES80, which should be used for initialization,
termination and the running system must be crea-
ted.

It can either be created under the operating sy-
stem s or under BOSS. The advantage of BOSS is
that it is easier to use for the central operator,
and that a rarely used dataentry system can be
swopped out, so that the system is not unnecessa-
rily loaded. On the other hand it is unacceptable
that DES80 can be swopped out, if DES80 is used
intensely by at least one operator during a full
day.
\f

s By use of s a process (DES80) must be created,
which is used for initialization, finishing and
the running system. You must pay attention to the
parametres below when creating the process:

Size Size should be at least 100000 half words. By in-
creasing size the time of reply is descreased. A
(near) optimal value for size can be determined by
performance-examinations as described in ref. 8
and sections 4.5 and 4.6.

Buf Must be 16.

Area Must be 16.

BS DES80ONLINE must be able to create and use a num-
ber of temporary and permanent files on one or
more disckits. Both the number of entries and the
number of segments depend on the input situation.
An upper limit for the number of entreis for both
types of files is given by the expression:

(number of terminals) + 30 . (number of users)

Bases The bases which are to be used at start up must
include the base with the private files of DES80
and all the users bases corresponding to the solid
line in fig. 4.
\f

Fig. 14 shows an example of a start of the
DES80-process by means of s.

ATT S
NEW DES80 SIZE 100000 BUF16 AREA16
READY
ATT S
BS DISC 2000 20
READY
ATT S
BS DISC1 2000 20
READY
ATT S
BASE 12860 12879 RUN

Figure 14.

BOSS When using BOSS the initialization, finishing, and
start up of the running system are made by enroll-
ment of jobs (the command NEWJOB in BOSS, see ref.
9).

Size, buf, area, and temporary, and permanent re-
sources respectively are stated in the job-line.
Jobname and index should be DES80 and 0 respecti-
vely; the process name is then DES80 and the cor-
rect bases will be used, if the user catalog has
been adapted as explained in section 2.5.

Fig. 15 shows an example of a job line stating a
process under boss corresponding to the one cre-
ated in fig. 14.

JOB DES8 0 292932 SIZE 100000 BUF 16 AREA 16 TEMP
DISC 2000 20,
PERM DISC1 2000 20

Figure 15.
\f

3_._4_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _I_n_i_t_i_a_l_i_z_a_t_i_o_n_ 3.4

Below is described

- when
- why and
- how

an initalization of the running system is made.

When Initialization is made every morning before star-
ting up the running system - and only then. After
breakdown of the running system or the machine, on
which it is installed, the running system is re-
started w_i_t_h_o_u_t_ initialization. If the running sy-
stem has not been closed with a finishing run (see
chapter 5) between two initialization runs, the
log information for the transaction journal is de-
leted.

Why The purpose of an inistailization run is to pre-
sent the corrected ld-descriptions and information
from the user-description file on a form which the
running system can access. An initialization run
might cause error messages as described in ref. 1
appendix C.

How Initialization can, as mentioned previously, be
made either by means of the operating system s or
BOSS.

s First it is described how the initialization is
made by means of s:
\f

In the process, the creation of which is described
in section 3.3, the program DES80UPDATE is started
by means of the job file INITJOB. It is done as
follows:

I INITJOB

Example Fig. 16 shows an example of print out from the
program on the VDC:

I INITJOB
*DES80UPDATE BASE.1286012864 USER.DES80TEST,
RUN.INIT LOG.DES80LOG
START DES80UPDATE, V47, 10.03.80 11.03.1980
09.52.01 RUN.INIT LOG.DES80LOG
- - - - >>> DES80UPDATE LOG <<<

CATBASE: 12860 12879
STD BASE: 12860 12879
USERBASE: 12860 12879
MAXBASE: 12860 12879
OWNBASE: 12860 12879

DES80CAT: DES80TEST
SYSDOK: DES80SYS
SECTION 1 DES80CAT
VERSION: 21
CREATED. 15.01.1980 14.42.42
DES80 CONTEXT: DES80DATA
MAX USERS 5 OPERATORS
MAX OPERATORS 10

USER: DESA
DESCRIPFILE desadescrp 51. UNCHANGED
LDNAME: CREATED 2.09.1977 10.05.26 BY SJA

USER: DESB
DESCRIPFILE: desbdescr 51. UNCHANGED
LDNAME: CREATED 27.12.1977 14.42.35 BY DESB
\f

USER: DESC
DESCRIPFILE: descdescr 51. UNCHANGED
LDNAME: CREATED 18.07.1977 15.55.11 BY SJC

END DES80UPDATE V47, 10.03.80 11.03.1980 09.52.40
CPU: 2
END 132
*FINIS

Figure 16.

BOSS By initialization under BOSS the job file INITJOB
is enrolled as follows:

NEWJOB INITJOB

The log print out from the run arrives after the
execution of the job on the printer, but is as de-
scribed in fig. 16.

3_._5_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _T_h_e_ _T_e_r_m_i_n_a_l_ _O_p_e_r_a_t_i_n_g_ _S_y_s_t_e_m_ 3.5

Below is described partly under which circumstan-
ces the terminal operating system can be expects
to work correctly, partly how it is started.

The daily routine is as follows:

Morning In the morning an initialization run is made.

Day Then the terminal operating system is started. If
the system breaks down during the day it is re-
started w_i_t_h_o_u_t_ initialization.

Evening Finally the system is closed in the evening (see
chapter 5).
\f

An example with two break downs is shown in fig.
17.

initialization (INITJOB see section 3.4)
terminal operating system (ONLINEJOB see this chapter).
----------------------------(BREAK DOWN)
terminal operating system (ONLINEJOB see this chapter).
----------------------------(BREAK DOWN)
terminal operating system (ONLINE JOB see this chapter).
finish (FINISHJOB see section 5.2).

Figure 17.

The terminal operating system can, as previously
mentioned, be started either by means of s or
BOSS.

s Under s the terminal operating system is started
up by means of the job file ONLINEJOB in the
process, the creation of which was described in
section 3.3. It takes place as follows:

I ONLINEJOB
\f

Example Fig. 18 shows an example with print outs on the
VDC.

DES80 1980.03.11 12.30.33 CPU: 11.22 SEC.
*TELESCOP BASE.412050.412059 INPUT.DES80COM MEDLOG.JA DUETP.DES80DUET

START TELESCOP, V4.7, 10.03.1980 11.03.1980 12.30.34
TELESCOP BASE.412050.412059 INPUT.DES80COM MEDLOG.JA DUETP. ,
DES80DUET

<<< DES80ONLINE LOG >>>

AREA 14 BUF 15 SIZE 110000

DISC: 42 SEGM/SLICE
TEMP 1008 SEGM 24 ENTR
LOGIN 0 SEGM 0 ENTR
PERM 0 SEGM 0 ENTR

DISC1: 42 SEGM/SLICE
TEMP 42 SEGM
LOGIN 42 SEGM 6 ENTR
PERM 42 SEGM 6 ENTR

DISC2: 63 SEGM/SLICE NO RESOURCES

CATBASE: 12860 12879
STDBASE: 12860 12879
USERBASE: 12860 12879
MAXBASE: 12860 12879
OWNBASE: 12860 12879

INPUT: DES80COM ONLINE
VIRTUAL FILE: DES80DATA
LOG OUTPUT ON: DES80LOG
MAX USERS: 5
MAX OPERATORS: 10
NO. OF DBFILES: 10
MAX BUNDLES: 10
\f

DUETSYSTEM: VERSION : 95 EAH 16.08.79
ACTIVATED : 11.05.80 - 12.30

DUETFILE: IDENT : 1 HUS OG LADE
AREA : DES80DUET
VERSION : 6 DESB 27.04.79 - 13.59

USER USER NAME USER BASES STATE DUET START
NO. BLOCK
1 DESA 12865 12869 OK 10
2 DESB 12870 12874 OK 20
3 DESC 12875 12879 OK 30

Figure 18.

BOSS When starting under BOSS the job file ONLINEJOB is
enrolled like this:

NEWJOB ONLINEJOB

The log print out from the run comes on the
printer after the terminal operating system has
been closed, but looks as the one described in
fig. 18. If there are any error messages they will
appear at the same place.

Note P_l_e_a_s_e_ _N_o_t_e_
That if the process name DES80COM is adapted in
BOSS's options (see section 2.5) this name cannot
be used when starting up of the terminal operating
system under s.
\f

F_ 4_._ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _O_P_E_R_A_T_O_R_ _C_O_M_M_A_N_D_S_ 4.

4_._1_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _I_n_ _G_e_n_e_r_a_l_ 4.1

When an operator is about to start his work at a
terminal, he must first switch it on and then
LOGIN. When the operations have been finished he
LOGOUT's.

LOGIN After the terminal has been switched on and con-
nected to the system which is to be used, the at-
tention key is pressed (esc, bell, cancel, or the
like according to the type of terminal). If there
is connection between the system and the terminal
the answer on the terminal will be 'att'.

The operator then types the name of the communica-
tion process followed by change to new line. If
the process is created it will react by printing
'type name and number', if not 'unknown' will be
printed.

Syntax As a supplement to name and number the communica-
tion form below can be stated:

s
name number
d_

s means single buffer and D double buffer. Ref. 7
contains a more detailed description of the two
communication forms.
\f

LOGOUT This operation is performed by typing 'BYE' and
can be performed any time. Until the next LOGIN
the operator is considered passive.

In the following chapter the commands are descri-
bed which are available for the central operator
of DES80. A command is characterized by an initial
@.

4_._2_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _@_C_L_A_I_M_ 4.2

Purpose Information about disc-kits is printed.

Syntax @CLAIM

Method Area, buf, and size are printed. The items listed
below are printed for each disc kit having resour-
ces, when the command is submitted.

- name
- length of track (SEGM/SLICE)
- number of segments (SEGM)
- number of entries (ENTR)

The last two items of information are given for
the three scopes:

- TEMP
- LOGIN
- PERM

If there are not resources, only name, length of
track and the information NO RESOURCES are prin-
ted.
\f

Example Fig. 19 shows an example with three disc-kits.

@CLAIM
AREA 12 BUF 14 SIZE 100000
DISC: 21 SEGM/SLICE
TEMP 2016 SEGM 18 ENTR
LOGIN 0 SEGM 0 ENTR
PERM 0 SEGM 0 ENTR

DISC1: 42 SEGM/SLICE
TEMP 1260 SEGM 0 ENTR
LOGIN 1260 SEGM 8 ENTR
PERM 1260 SEGM 8 ENTR

DISC2: 63 SEGM/SLICE NO RESOURCES

Figure 19.

4_._3_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _@_C_L_O_S_E_ 4.3

Purpose closing DES80 is prepared.

Syntax @CLOSE

Method When the operator logs out after having used the
command @CLOSE the DES80 process is closed. All
active terminals are subsequenthly logged out.
Such a forced logging out is the same as a
break-down for these terminals. Thus the operator
ought to make certain before logging out that all
terminals are passive (see @DISPLAY and @MESSAGE).

The system acknowledges by printing date and hour.
\f

Example Fig. 20 shows an example.

@CLOSE
OPERATOR CLOSE 16.09.79 17.00.10

Figure 20.

4_._4_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _@_D_I_S_P_L_A_Y_ 4.4

Purpose By means of this command information about the
terminals which can be connected to DES80 is prin-
ted.

Syntax @DISPLAY

Method The print-outs are formatted so that the terminals
are identified to the left by number, user name,
and index. To the right is stated if the terminals
are either connected to DES80 (ACTIVE) or not
(PASSIVE). For the active terminals time of latest
trasaction is printed. Finally date and hour is
printed.

Example Fig. 21 shows an example.

DISPLAY

TERMINAL USER INDEX STATE LATEST TRANSACTION
1 1 PASSIVE
2 2 PASSIVE
3 1 ACTIVE 14.45.10
4 3 ACTIVE 14.47.30
5 2 PASSIVE
6 1 ACTIVE 14.50.10
7 4 ACTIVE 14.56.50
16.09.1978 16.57.10

Figure 21.
\f

4_._5_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _@_H_O_T_N_E_W_S_ 4.5

Purpose The system prints a text to the operators when
they log in.

Syntax @HOTNEWS <text>

Method In <text> the message which is to be passed on is
stated. When an operator logs in he receives the
message:

FROM CENTRAL OPERATOR
<text>

An earlier hotnews is removed by typing @HOTNEWS
without text.

Note that @MESSAGE and @HOTNEWS are different in that:

- @MESSAGE is printed for operators logged in
- @HOTNEWS is printed for operators logging in.

Example Fig. 22 shows an example in which the central
operator broadcasts a message saying, that the
system runs with limited resources.

HOTNEWS THE SYSTEM RUNS WITH LIMITED RESOURCES

Figure 22.
\f

Fig. 23 shows the message as it is experienced by
an operator logging in:

ATT DES80COM
TYPE USER NAME AND NUMBER
ILM 2 s
FROM CENTRAL OPERATOR
THE SYSTEM RUNS WITH LIMITED RESOURCES
STATE ID
ID SESAM

Figure 23.

4_._6_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _@_M_E_S_S_A_G_E_ 4.6

Purpose The central operator can send a message to all
active operators logged in to DES80.

Syntax @MESSAGE <text>

Method <text> states the message which is to be passed
on. All active operators receive a line similar to
the line written by the central operator - i.e. it
opens with the command name.

Example Fig. 24 shows a warning from the central operator
saying that DES80 will be closed in 5 minutes.

MESSAGE CLOSING IN 5 MINUTES

Figure 24.
\f

4_._7_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _@_P_E_R_F_O_R_M_A_N_C_E_ 4.7

Purpose To begin a performance examination of the DES80-
system.

Syntax @PERFORMANCE

Method The following answer acknowledges the command.

OPERATOR PERFORMANCE START <date> <hour>
FIRST TRANSACTION <trans-no>

The <trans-no> is the number of the transaction
which is the first to undergo examination.

Hour of arrival, waiting, place and queue, cpu-
time, processing time, response time, and various
numbers of segment transports are recorded for all
lines, being typed after the command has been sub-
mitted. The examination is finished with the com-
mand @PERFORMANCE. The recorded data is written in
the file with the standard name DES80LOG (see ref.
1). The analysis below is made by the program
TELESTATAC as described in ref. 8.

Error ***PERFORMANCE ALREADY STARTED

A performance examination has been started earlier
and has not been finished.

Example Fig. 25 shows an example illustrating the start of
a performance examination.

@PERFORMANCE
OPERATOR PERFORMANCE STAT 16.09.1979 10.00.10.
FIRST TRANSACTION 2035

Figure 25.
\f

4_._8_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _@_-_P_E_R_F_O_R_M_A_N_C_E_ 4.8

Purpose This command ends a performance examination of the
DES80-system.

Syntax @-PERFORMANCE

Method The operator receives the following answer:

OPERATOR PERFORMANCE END <date> <hour>
TRANSACTION INTERVAL <from> <to>

<From> and <to> are the numbers of the first and
last transaction in the examination. The numbers
can be used as parametres for the call of
TELESTATAC (see ref. 8).

Error ***PERFORMANCE NOT STARTED

The performance examination has not been started
by PERFORMANCE or it has been finished by another
operator.

Example Fig. 26 shows an example of finishing a
performance examination.

@-PERFORMANCE
OPERATOR HOURS END 16.09.1979 12.00.05
TRANSACTION INTERVAL 2035 4103

Figure 26.
\f

4_._9_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _@_S_Y_N_T_A_X_ 4.9

Purpose The command enables the operator to get a general
view of the existing commands and to get a detai-
led description of the individual commands.

Syntax @SYNTAX command

Method If only @SYNTAX is typed, a list of the commands
which can be used is printed. If @SYNTAX is follo-
wed by a command name a detailed description of
this command is printed.

Example Fig. 27 shows an example in which a list of
commands is presented.

@SYNTAX
List of commands
@BYE
@CLAIM @CLOSE
@DISPLAY
@HOTNEWS
@MESSAGE
@PERFORMANCE @-PERFORMANCE
@SYNTAX
@TIME

By typing i.e. SYNTAX @CLAIM you get a description
of @CLAIM

Figure 27.
\f

In Fig. 28 an example illustrates a situation
where a detailed description of the command @CLAIM
is given.

@SYNTAX @CLAIM
syntax: @CLAIM

This command prints information about disc-kits.

Figure 28.

4_._1_0_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _@_T_I_M_E_ 4.10

Purpose To print date and hour.

Syntax @TIME

Example Fig. 29 shows an example of how to use the com-
mand.

@TIME
DATE AND HOUR 20.11.1979 09.49.25

Figure 29.

F_ 5_._ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _C_L_O_S_I_N_G_ 5.

5_._1_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _I_n_ _G_e_n_e_r_a_l_ 5.1

This section describes the daily routine for clo-
sing DES80.

Finishing The closing comprises a correct finishing of the
running system in which vital information is writ-
ten in the user description file. This is descri-
bed in section 5.2.

Safety Then safety copies of files on project level and
of DES80's private files are made, as described in
section 5.3.

Documentation If necessary, transaction journals and log-print
outs are filed away. This part of the closing is
described in sections 5.4 and 5.5.

Performance Finally in certain cases a performance examination
of the DES80-system is made. This is described in
section 5.6.

5_._2_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _F_i_n_i_s_h_i_n_g_ 5.2

The running system must be stopped in a way which
disturbs the users the least, and so that it is
certain that nothing of what has been typed cor-
rectly during the day is lost.

Routine The daily finishing of the running system inclu-
des:

- checking if any active operators are attached to
the system. This is done with the command
@DISPLAY.
\f

- by means of @MESSAGE any active operators are
warned of the closing.

- submitting the command @CLOSE.

- submitting the command @BYE.

- Execution of the finishing run by means of the
job file FINISHJOB.

- removal of the process DES80COM and if necessary
DES80.

The first four items of this routine are made un-
der DES80, whereas the last ones usually are made
under s.

Example Fig. 30 shows how a central operator logs in with
the purpose of checking the number of active ope-
rators. As there are a few, the central operator
broadcasts a message saying that the system closes
in 5 minutes. It is later ascertained that there
no longer are active operators and the system is
subsequently closed with @CLOSE and @BYE.
\f

ATT DES80COM
TYPE USER NAME AND NUMBER
DESOP 0 S

OPERATOR LOGGED IN 10.10.1979 17.00.30
@DISPLAY
TERMINAL USER INDEX STATE LATEST TRANSACTION
1 DESA 1 PASSIVE
2 DESA 2 PASSIVE
3 DESB 1 ACTIVE 16.01.30
4 DESA 3 ACTIVE 16.30.40
5 DESB 2 PASSIVE
6 DESC 1 ACTIVE 16.50.10
7 DESA 4 ACTIVE 17.02.50
@MESSAGE CLOSING WITH IN 5 MINUTES
@MESSAGE CLOSING WITHIN 5 MINUTES
10.10.1979 17.00.45

@DISPLAY
TERMINAL USER INDEX STATE LATEST TRANSACTION
1 DESA 1 PASSIVE
2 DESA 2 PASSIVE
3 DESB 1 PASSIVE
4 DESA 3 PASSIVE
5 DESB 2 PASSIVE
6 DESC 1 PASSIVE
7 DESA 4 PASSIVE
10.10.1979 17.04.55
@CLOSE
OPERATOR CLOSE 10.10.1979 17.05.10
@BYE
THANK YOU

Figure 30.
\f

Finishing run After the running system has been closed, a
finishing run must be executed.

Why The purpose is to update information vital to the
system. If the finishing run is omitted, it re-
sults in a loss of the corresponding transaction
journal.

How The finishing run is started similarly to the
initializing run. This means either in the process
DES80 (see section 3.3) and by means of the
command:

I FINISHJOB

or by enrolling FINISHJOB under BOSS:

NEWJOB FINISHJOB

Example Fig. 31 shows an example with print outs from the
program when started under s.
\f

I FINISHJOB
*DES80UPDATE BASE.12860.12864 RUN.FINISH DES80CAT.DES80TEST LIST.YES
START V4, 04.10.79 10.10.1978 17.09.21
BASE.12860.12864 RUN.FINISH DES80CAT.DES80TEST, LIST.YES

DES80CAT: DES80TESTR

SYSDOK: DES80SYS AFSNIT: 1. DES80CAT VERSION: 21 CREATED: 13.19.79.
DES80 CONTEXT: DES80DATA
MAX: USERS OPERATORS
5 10
USER: DESA FINISHED
USER: DESB FINISHED
USER: DESC FINISHED

POSTING LOG: DES80LOG NUMBER OF INDIVIDUALS: 166
SORTING OK: WRK000016 NUMBER OF INDIVIDUALS: 166
LOG ON LISTOUT NOT PRINTED
END DES80UPDATE, V4, 04.10.79 10.10.1979 17.09.49 CPU:2
END 128

Figure 31.

When the finishing run is correctly executed, the
processes DES80COM and DES80 can be removed. This is
done as shown in fig. 32 (see ref. 5).

ATT S
PROC DES80COM REMOVE
READY
ATT S
PROC DES80 REMOVE
READY

Figure 32.
\f

5_._3_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _S_a_f_e_t_y_ _C_o_p_i_e_s_ 5.3

The creation of safety copies must be adapted to
the routine of the individual operating depart-
ment.

It is advisable that everything on project level
and on DES80's private files are copied.

This can be executed under BOSS in a job with a
userbase as DES80's private files (see fig. 4).

Fig. 33 shows an example.

JOB QUO .... STAT 1

...
SAVE MTXXXXXX.LAST SCOPE.USER
SAVE MTXXXXXX.LAST SCOPE.PROJECT
...

Figure 33.

5_._4_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _T_r_a_n_s_a_c_t_i_o_n_ _J_o_u_r_n_a_l_s_ 5.4

A posting log contains all the lines typed between
a initialization and a termination run.

Grouping Lines are numbered consecutively as they are re-
ceived by the system, and ordered in groups accor-
ding to their combination of user number and ter-
minal number.

Within each group the lines come in the same order
as they were typed, but jumps in the numbering can
occur if other terminals have got some of the num-
bers in between.
\f

Error marking The lines which are inccorect are marked to the
left with an '*' whereas the lines which are de-
leted because of errors in the preceding lines are
marked with a '-' (only if double buffer is used).

Example Fig. 34 shows an example of a page for user No. 3
and terminal No. 1.

In the upper left corner the system, the program,
the user, and the terminal are identified. In the
middle the print out type (journal) is stated. To
the right is the date, hour, and page number.

It is noted that line 195 is incorrect and that
line 196 because of double buffering is deleted.

DES80 10.10.1979 17.10.10
DES80UPDATE, V4, 04.10.79 POSTING JOURNAL PAGE7
USER: 3
TERMINAL: 1

- 166
173 AM1 12341 23 59 23 30
174
* 195 4710 120
- 196
198 4710 100
199 BS
205 AM1 15551 0 0 0 0
221 BS
222
226 AM1 15551 1 59 1 59
227
230 4710
231 BS
* 240 AS 0 0 0 0
- 241

Figure 34.
\f

The journal is created by DES80UPDATE in a finish-
ing run. This is done in a file with the name
LISTOUT. If the file is permanent, it is not auto-
matically printed. This will have to be specified
under s with the command:

LP = COPY LISTOUT

or under BOSS with

CONVERT LISTOUT

If LISTOUT is not permanent, it is deleted when
operating under s, but it is automatically printed
when operating under BOSS.

The operating department must agree with the indi-
vidual consultant if a user's posting journals are
to be

- discarded
- filed by the operating department
- sent to the consultant
- sent to the user or
- a combination of the above-mentioned.

5_._5_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _L_o_g_ _P_r_i_n_t_-_O_u_t_s_ 5.5

For the sake of documentating the use of the sy-
stem all check-print-outs from the system ought
to be saved.

The log print-outs have a special use in error si-
tuations or if any doubts about version No. and/or
dates should occur.
\f

5_._6_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _P_e_r_f_o_r_m_a_n_c_e_ 5.6

A performance examination is started by the com-
mand @PERFORMANCE and finished by the command
@-PERFORMANCE (see sections 4.5 and 4.6).

The program TELESTATAC gives a statistical analy-
sis as described in ref. 8.

Input for TELESTATAC is:

- transaction- or time interval
- sorting criterion
- logfile from DES80 (its standard name is
DES80LOG).
\f

F_ 6_._ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _E_R_R_O_R_ _M_E_S_S_A_G_E_S_ 6.

6_._1_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _I_n_ _G_e_n_e_r_a_l_ 6.1

In a system as complex as DES80, there are vaious
possibilities for making errors. Below you will
find a survey of the error messages, which are de-
scribed in other manuals and a reference to these.
The error messages which are special for DES80 at
runtime are described thoroughly.

Responsibility The error messages should make it possible for the
operating department either to solve the problem
and make the relevant actions, or to decide who is
responsible for the error and then contact this
Doubt person. If there is any doubt, the operating de-
parment should contact the development group.

In sections 6.2 to 6.4 we give a survey of error
messages which can occur when the system is being
created.

Sections 6.5 to 6.8 describe and give a survey of
the error messages from the running system.

6_._2_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _E_r_r_o_r_s_ _W_h_e_n_ _C_r_e_a_t_i_n_g_ _t_h_e_ _U_s_e_r_ _D_e_s_c_r_i_p_ _F_i_l_e_ 6.2

Errors and warnings are not the same. When an er-
ror occurs the execution of the program is stopped
and no user description is created. A warning has
no effect on the execution of the program.
\f

The normal appearance error and warning print-outs
are:

ERROR
LINE <Line No> <text>
WARNING

In fig. 35 the possible e_r_r_o_r_ texts are displayd.

THE NUMBER OF USERS IS LARGER THAN THE MAXIMUM NUMBER OF USERS ALLOWED
THE NUMBER OF OPERATORS IS LARGER THAN THE MAXIMUM NUMBER OF OPERATORS ALLOWED
!PHYSICAL USER NO. NOT CONSECUTIVE
!THE PHYSICAL OPERATOR NO. IS ALREADY IN USE
!THE OPERATOR NO. EXCEEDS USERUPDAT'S DIMENSION
!PHYSICALLY OPERATOR NO. NOT CONSECUTIVE
THE MAXIMUM NUMBER OF OPERATORS EXCEEDS 99, WHICH IS THE CURRENT MAX. THE SYSTEM
CAN PROCESS
SYNTAX ERROR IN A CATALOG LINE
SYNTAX ERROR IN A USER LINE
SYNTAX ERROR IN A CAT BASE LINE
SYNTAX ERROR IN AN OPERATOR LINE

Figure 35.

Fig. 36 shows the w_a_r_n_i_n_g_s_ from the program for
creation of the user description file.

A NUMBER CONTAINS TOO MANY DIGITS
A TEXT STRING IS TOO LONG
A SECTION PART IS TOO LONG
TOO MANY LEVELS IN A SECTION
THE MAXIMUM NUMBER OF USERS HAS BEEN DECREASTED
THE MAXIMUM NUMBER OF OPERATORS HAS BEEN DECREASED
PREVIOUS OPERATOR IDENTIFICATION HAS BEEN DELETED
PREVIOUS OPERATOR IS NO LONGER ACTIVE

Figure 36.
\f

Please note, that the first four warnings in fig.
36 ought to result in a re-compilation of the user
description file.

A more detailed description of errors and warnings
can be found in appendix B in ref. 1.

As only the operating department and the consul-
tant in cooperation deliver data for the user de-
scription file, it will usually be easy to find
and correct any possible error.

6_._3_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _E_r_r_o_r_s_ _w_h_e_n_ _C_r_e_a_t_i_n_g_ _t_h_e_ _C_o_m_m_u_n_i_c_a_t_i_o_n_ _M_o_d_u_l_e_ 6.3

The errors occurring when creating the communica-
tion module concern the construction of FP-para-
metres and duetcom options. See ref. 3 and 6.

Corresponding to each of the occurring catalog en-
tries the following error texts can occur:

*** ILLEGAL TEXT LENGTH
*** ILLEGAL COMMAND TEXT

*** ILLEGAL USERCAT ENTRIES

*** ILLEGAL PRINTER CATALOG ENTRIES

*** ILLEGAL PROCESS CATALOG ENTRIES

6_._4_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _E_r_r_o_r_s_ _w_h_e_n_ _I_n_s_e_r_t_i_n_g_ _t_h_e_ _R_e_a_d_-_I_n_ _P_r_o_g_r_a_m_s_ 6.4

In section 2.4 is described how the consultant is
responsible for a well-tested local data descrip-
tion and read-in program.
\f

However, errors may occur under the transmission
to the central system; these are recorded by the
compiler DUETTABLER.

In section 4.5 in ref. 4 there is a complete list
of error messages from the compiler.

Fig. 37 gives an outline of the error messages
which might occur during the installation.

The development group ought to be contacted in ca-
se of error No. 59, 62, and 65 occurring.

13: USERNO INCOMPATIBLE WITH LD DESCRIPTION <userno><ld _user>
37: LISTAREA CANNOT BE CREATED <area _name><no>
51: NOT DUETREG IN OLDDUETREG
52: ILLEGAL VERSION OF OLDDUET <version><old _version>
54: DUETWORK CANNOT BE CREATED
59: BLOCK LOCATION ERROR
62: SYSTEMERROR: VARIABLE NAME ADDRESS CONFLICT <no><adr>
64: UNKNOWN DUETBLOCK SPECIFIED FOR TRANSLATION <blockno>
65: SYSTEM ERROR: MISSING COTO IN BYTEAKTION <no>
66: INSERT DUETBLOCK: EXISTING BLOCKNO <blockno>
67: ILLEGAL USERNO FOR CHANGE/DELETE DUETBLOCK <blockno>
68: UNKNOWN DUETBLOCK SPECIFIED FOR DELETE <blockno>
71: PROGRAM NO IN TEXT DO NOT MATCH WITH OLDDUET
<programno><old _program>
72: DUET PROGRAM NAME TOO LONG
73: SPECIFIED LD-NUMBER DO NOT MATCH LD-FILE <ldno><old _ldno>

Figure 37.

6_._5_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _E_r_r_o_r_s_ _i_n_ _t_h_e_ _R_u_n_n_i_n_g_ _R_e_a_d_-_I_n_ _P_r_o_g_r_a_m_s_ 6.5

The individual program errors are described in de-
tail in ref. 4. Fig. 38 presents a list of error
No.'s and error texts. Error No. 12 is supplemen-
ted with an error text as shown in fig. 39.

ERROR NO. ERROR TEXT
1 ILLEGAL BLOCKNO OR BLOCK MISSING <block _no>
2 ILLEGAL BLOCKREF, USER CONFLICT <block _no> <user _no>
3 ILLEGAL ENTRYPOINT <entry _no>
4 PRINT CHANNEL NOT SELECTED
5 ILLEGAL VARIABLE NUMBER <var _no>
6 INDEX <var _no><index _value>
7 ILLEGAL CHANNEL NUMBER <channel _no>
8 INST.COUNT EXCEEDED <inst _count><max _inst>
9 ILLEGAL SET NUMBER <set _no>
10 USAGE CONFLICT <set _no>
11 RECORD STATE ILLEGAL FOR THIS OPERATION <set _no><rec _st>
12 MOVE ERROR <set _no><text><addr><value>
13 SET CLOSED FOR SEQ.ACCESS BY NEWSET ON ANOTHER SET <set _no>
14 DAUGHTER RECORDS ASSOCIATED WITH CURRENT RECORD
16 CURRENT RECORD REMOVED FROM DB <set _no>
17 MOTHER RECORD MISSING IN SIDE CHAIN <set _no>
18 MOTHER RECORD REMOVED FROM DB <set _no>
19 ILLEGAL STATE FOR MOTHER SET <set _no><record _stated>
20 ILLEGAL CURRENT RECORD TYPE IN MOTHER SET <set _no>
21 RECORD TYPE ILLEGAL IN SET <set _no><record _type>
22 PRINTVALUE EXCEEDS FIELD RANGE <channel><value>
23 ILLEGAL PRINT POSITION <start _pos>
24 PRINT FIELD EXCEEDS LINE BUFFER <start _pos><amount>
25 ILLEGAL BS.OPERATION, POSITION AFTER EOF <set _no>
26 ILLEGAL DELETE POSITION <set _no>
27 SET NOT OPEN FOR SEQUENTIAL ACCESS <set _no>
28 ILLEGAL SPECIAL ACTION <algol _no>
29 ILLEGAL NUMBER OF PARAMETERS <algol _no><param _no>
30 ILLEGAL TYPE OF PARAMETER <algol _no><param _no>
31 ILLEGAL ZERO DIVISION

Figure 38.
\f

NO. ERROR TEXT
1 SPILL DURING TRANSFER FROM VAR
2 SPILL DURING TRANSFER TO VAR
3 INDEX
4 ILLEGAL NUMBER OF REPET. IN RPG

Figure 39.

Please note that the consultant has the sole re-
sponsibility for the correct functioning of the
Duet program.

6_._6_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _E_r_r_o_r_s_ _i_n_ _t_h_e_ _D_u_e_t_-_S_y_s_t_e_m_ 6.6

A further description of the error texts coming
from the duet system is given in ref. 4. In fig.
40 error No.'s and error texts are listed.

NO. ERROR TEXT
1 DUETREL <duetrel><duetstop>
2 BIT 23 = 0
3 'DUETNAVN'
4 VALUE OF 'UDTRYK' <val><duetstop>
5 BIT 23 = 1 <duetstop>
6 LD-TABLES <setnr>
7 CHECKSUM <setnr>
8 RECORDLENGTH <setnr>
9 CONNECT MISSING IN SIDE CHAIN <setnr>
10 FILE EXPANSION IMPOSSIBLE <result cf>
11 RECORD CREATION TOO EXPENSIVE <result cf>
12 DELETION OF LAST RECORD IN FILE
13 SKIPWORD
14 OVER/UNDERFLOW <staktrin>
15 ERROR IN BLOCK TRANSFER <blocknr><fejltekst>
16 MOVE ERROR
17 ILLEGAL TYPE OF VALUE ELEMENT <type>

Figure 40.
\f

The development group is responsible for this type
of errors.

6_._7_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _E_r_r_o_r_s_ _i_n_ _t_h_e_ _S_u_r_r_o_u_n_d_i_n_g_s_ 6.7

DES80UPDATE Some errors are caught by the program DES80UPDATE
which is used for initialization and termination
runs. These error messages are described in ref.
1's appendix C. Fig. 41 present a survey of the
error text.

VIRTUAL FILE NOT EXISTING
VIRTUAL FILE CANNOT BE INITIALIZED
VIRTUAL FILE NOT INITIALIZED
SET-CAT-BASE ERROR
ILLEGAL BASES
ERROR IN LOOK-UP OF THE LOG FILE
SORT PROCBS ALARM
ERROR IN SORTING OF THE LOG FILE
RECORD TYPE ERROR ON THE LOGFILE
OPEN OUT AREA ALARM
LD-FILE NOT PRESENT
LD-FILE>S SECTION TYPE NOT SODA
LD-FILE>S COMPILATION-STATE NOT OK
LD-FILE>S CONTROL POST CANNOT BE FOUND
LD-FILE>S VERSION DO NOT CORRESPOND TO THE REQUIRED VERSION
LD-DESCRIPTION CONTAINS MORE FILES
BLOCKLENGTH OF TRANSACTION FILE NOT 1 SEGMENT
DESCRIPTION FILE NOT EXISTING
ERROR AT BUFLENGTH
POSTING JOURNAL ON <list out name> NOT REMOVED
POSTING JOURNAL ON <list out name> NOT PRINTED
CONVERT <list out name><error text>
THE FILE WITH THE SORTED RECORD <list name> HAS NOT BEEN REMOVED
TOO MANY PERMANENT VARIABLES

Figure 41.
\f

DES80ONLINE However this is not sufficient to secure correct
surroundings for the system. DES80UPDATE may have
been used incorrectly or unintentional changes may
have taken place between the execution of
DES80UPDATE and DES80ONLINE.

Below errors concerning the files which the run-
ning system uses are described.

*** ILLEGAL BASES

ONLINEJOB is started on the wrong bases. Own base
must lie within user base. The run is interrupted.

*** VIRTUAL FILE NOT INITIALIZED: <filename>

The run is stopped. The reason is usually that the
initialization run has been executed incorrectly.

*** NO INITIALIZATION RUN HAS BEEN EXECUTED

The run is stopped. The reason is that initiali-
ation has not been executed or has been executed
incorrectly.

*** DESVAR0x NOT CREATED, NO ENTRIES/SEGMENTS

The reason is lack of resources.

*** CRE./RES: filename RESULT: <numbl> <numb2>

There are problems with the creation or reserva-
tion of the area.

If
<numbl> = 1: too few area processes
<numbl> = 3 or 4: the area does not exist.

In other instances the development group is
contacted.
\f

*** OPEN TRANS - INIT ERROR <filename>

RESULT FROM MONITOR 52 CREATE = <res>
or 8 RESERVE AREA

There are problems with opening a zone. The same
actions as by the previous error message.

*** SET CAT BASE ERROR:

RESULT FROM MONITOR 72 SET CATBASE = <res>

The error message can occur by the start of
ONLINEJOB and the run is interrupted. Own base
must lie within user base and the content must
equal or be contained in the standard base.

*** INPUT UNDEFINED <inputname>

The process stated by input.inputname in ONLINEJOB
does not exist.

LACK OF RESOURCES BY NEW BUNDLE USER.<name>

*** GENERATE FILE: <res>

RESULT FROM MONITOR 40 CREATE ENTRY = <res>
or 50 PERMANENT ENTRY
or 74 SET ENTRY BASE

When correcting bundles, new files are required.

*** TRANSFILE: <name> FOR USER <name>

RESULT FROM MONITOR 42 LOOK UP ENTRY = <res>

The cause of the error can be catalog a i/o-error
or an illegal name-format.
\f

FOR USER <name>

*** TRANSFILE <name> FOR USER <name> NOT MOVED

RESULT FROM MONITOR 74 SET ENTRY BASE = <res>

The transaction file could not be moved from the
base where DES80's private files lie to the base
of the user.

*** TRANSFILE: <name FOR USER <name> NOT EXISTING

RESULT FROM MONITOR 42 LOOKUP ENTRY = <res>

The transaction file which should be sent does not
exist.

*** TRANSFILE: <name> FOR USER <name> CANNOT GET
THE NAME: <names>

RESULT FROM MONITOR 46 RENAME ENTRY = <res>

This can for instance be due to a catalog
i/o-error or an illegal name-format.

*** RETURN FILE: DES80 RETURN NON EXISTING

RESULT FROM MONITOR 42 LOOKUP ENTRY = <res>

There must be a return file in each user's base -
see section 2.6.

*** RETURN FILE: DES80 RETURN NOT REMOVED

RESULT FROM MONITOR 48 REMOVE ENTRY = <res>

The file should be removed manually from DES80's
private base.
\f

*** NO RESOURCES FOR SWOPAREA: <name>
DEMAND: TEMP <kit><length>

RESULT FROM MONITOR 40 CREATE ENTRY = <res>

The DES80 process has been started with too few
resources on the kit stated.

*** SYSTEM ERRO: INACTIVE FILE <filename>
USER <name>

The buffer length is 0 for a database file. This
is due to the fact that the file was not present
when the initialization run was executed.

*** CAT I/O ERROR ON <filename> FOR USER <name>

Hard error.

*** FILE NAME <filename> FOR USER <name> NOT
EXISTING IN THE CATALOG

A database file has been removed after the
initialization.

*** FILENAME <filename> FOR USER <name> HAS
ILLEGAL FORMAT

Hard error.

*** THE FILE <filename> FOR USER <name> UNDER
UPDATING

An operator tries to open a file which is being
updated by another system.

*** ERROR BY JOB ENROLLMENT. USER: <name>

RESULT FROM MONITOR 18 WAIT ANSWER = <res>
\f

<number> refers to the result of the jobenrollment
- see ref. 9 page 10-6.

*** BASICFILE: <name> FOR USER <name> CANNOT BE
REMOVED

RESULT FROM MONITOR 48 REMOVE ENTRY = <res>

The file ought to be removed manually from the
private base of DES80.

*** ERROR SENDING BUNDLE USER <name1>
BUNDLE: <name2>

The print out supplements the error messages con-
cerning transfile, returnfile, and basicfile so
that the user/bundle can be identified.

*** DISCLOG <name> NOT EXISTING/NOT PERMANENT

The file which should be used by the creation of
the transaction journal does not exist or is not
permanent.

*** READ IN PROGRAM IS ABSENT FOR USER <name>

That part of the read in program which converns
the relevant user is wrong. Check the log print
outs from the insertion of the relevant program
block(s) and check if possible later insertions
have ruined something. If this does not give any
solution ot the problem then contact your consul-
tant and execute with im a re-compilation as de-
scribed in section 2.4. If necessary the problem
can be solved by using a safety copy.

*** LOCAL DATA DESCRIPTION INCORRECT FOR USER
<name>
\f

Contact your consultant.

Below errors in the surroundings resulting in the
break-down of DES80ONLINE are described.

GIVEUP 0 ALGOLCHECK
CALL FROM .....
CALL FROM .....
DEVICE STATUS <filename>
<text>

Here the explanatory <text> could be:

END OF DOCUMENT

meaning that area processes or a file are missing.

STACK

This error message is caused by the same reasons
as the immediately proceding error-message.

C. EXPAND

The virtual file (DES80DATA) cannot be expanded;
this is due to lack of resources.

CONNECT

There is a discrepancy in the files between
DES80ONLINE and DES80UPDATE. System error.

6_._8_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _O_t_h_e_r_ _E_r_r_o_r_s_ 6.8

The errors described here concern the implementa-
tion of the system.

*** TERMINAL UNKNOWN
\f

The cause of this error is a discrepancy between
the description of users and operators in the user
description file and in the communication module.

Finally algol error messages can occur caused by
system errors. When these occur the development
group must be contacted. Fig. 42 gives a survey.

BLOCK MODEKIND SHARE C. IN CURN
BREAK MOVESIZE SH.STATE C. ARRAY
CASE MOVEFELD CREATE
ENTRY ODDFIELD SYNTAX CONTEXT
FIELD PARAM VALUE
INDEX RECLEN Z.KIND
INTEGER REAL Z.LENGTH
LENGTH SEGMENT Z.STATE

Figure 42.

If the error concerns a bundle the message is:

BUNDT: <bundtnavn> TRANSAKTIONSFIL: <workname>
TILSTAND:<bitmaske>
TEXT: <workname> BILAG: <nr>
LINIE: <nr>

If the bundle is being corrected the following is
added:

GL TEXT: <workname> POSITION: <pos>

Finally context variables are printed:

CONTEXT <status> BILAG: <nr> LINIE: <nr>
TOP TILBAGE STAKPIL MODE <to> <ti> <st> <mo>
INDDATA: <datalinie>
\f

A_._ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _I_N_D_E_X_ A.

Area
Attention

Base
Blocknumber
BOSS
Break-down
BUF
BYE

Catalog base
CLAIM
CLOSE
Closing
Commands
Communication module
Communication process

Datafiles
DES 8
DES80
DES80COM
DES80COMPRG
DES80DATA
DES80DUET
DES80LOG
DES80ONLINE
DES80OPT
DES80RETURN
DES80UPDATE
DES80USURP
DESVAR00
DESVAR0XX
DISPLAY
DUET
DUETCOM
\f

DUET system
DUET TABLE
DUET TABLER

Error
Establishment

Files
FINISJOB
Finishing

Grouplevel
Groupuser

Initialization
INITJOB

Job files

LD
LISTOUT
LOG IN
LOG OUT
Log print out
Local Data Description

Maintenance
Message

ONLINE JOB
Operating Department
Operating System
Operator
Operator Commands
Operator No
OPTION
\f

Performance
PERFORMANCE
-PERFORMANCE
Process
Process Catalog
Process Files

Restart
Read in Program
Routine project

s
Safety copies
Size
SODA-LD
SODATABLE
Start up
SYSDOK
SYSTEM80
System tape

Terminal Catalog
Terminal Operating System
TTDUETCOM

USTABLE
USER
User Catalog
User Descrip File
User File

Warnings
\f

Vejledning i valg og
brug af
AV-Midler

A/S REGNECENTRALEN Juli 1978
Informationsafdelingen RCSL 42 - i 1003\f

Forfatter: Mikael Simon

NØGLEORD:

EKSTRAKT: Denne manual beskriver kort forskellige former for
Audiovisuelle midler.

Tavler
Flip-over
Overhead
Lysbilleder
Div.
Generelle råd

Reservation

INDHOLDSFORTEGNELSE

1 INTRODUKTION Side 5

2 TAVLER 6
2.1 Kridttavle 6
2.2 Burretavle eller flonellograf 7
2.3 Magnettavle 7
2.4 Emaljetavle 7

3 FLIP-OVER 9
3.1 Bordmodel 9
3.2 Fritstående model 10

4 OVERHEAD11
4.1 Udarbejdelse af manuskript 11
4.2 Fremstilling af overheadfilm 12
4.2.1 Reprokamera 12
4.2.2 Cibachrome 12
4.2.3 Silketryk 12
4.2.4 Termofax (3M) 13
4.2.5 Fotokopieringsmaskine 13
4.3 Fremvisning 13

5 DIAS, FILM og VIDEOTAPE 15
5.1 Dias 15

6 GENERELLE RÅD 17
6.1 Produktion 17
\f

1 INTRODUKTION

Denne vejledning i valg og brug af audiovisuelle hjælpemid-
ler er især henvendt til sælgere og instruktører. For dem
gælder det om at få kunden/eleven til, på den korteste tid,
at forstå og huske den givne instruktion i længst mulig tid
efter mødet.

En måde at opnå dette på, er ved at påvirke kunden/eleven
både auditivt og visuelt. Ved undersøgelser har det vist
sig, at man kun husker 10% 3 dage efter en instruktion, der
er henvendt til øret, og ca. 20% når instruktionen kun er
for øjet; men når disse to metoder kombineres, opnås en
reflektion på omkring 65%.

De vigtigste kombinationer vil i det efterfølgende blive
gennemgået (tavle, burretavle, magnettavle, flip-over, over-
head, lysbilleder). Valget af kombination vil derefter kunne
træffes efter vurdering af antal tilskuere, lokaleforhold,
økonomiske muligheder m.v.
\f

F_ 2 TAVLER

Tavler bedst egnet til ikke komplicerede emner, der spontant
kan tegnes eller skrives med et minimum af forberedelser.
Hvis man holder dette for øje, kan man være helt sikker på,
at kombinationen med at tegne og tale samtidig er god til at
holde koncentrationen fanget hos publikum. Dog skal man være
opmærksom på ikke at vende ryggen mod publikum i for lang
tid for at tegne på tavlen, da det ellers kan blive distra-
heret af andre ting.

En stor fordel er det, at det tegnede kan blive stående un-
der hele undervisningsforløbet uden at lyset er dæmpet og
uden forstyrrende lyde fra en blæsermotor.

Såvidt muligt bør man disponere, så statistiske tegninger og
notater kan blive stående i venstre side af tavlen, mens den
højre side kan bruges til at tegne og slette kontinuerligt.

Tavler kan anvendes i forsamlinger op til 30 personer, men
man bør tilstræbe at begrænse antallet for ikke at miste
grebet om publikum.

Prismæssigt ligger tavler som de billigste af de her omhand-
lede AV-midler - både i anskaffelse og anvendelse. Eneste
investering er kridt, og produktionen involverer ikke andre
end den, der holder foredraget.

Tavler kan ikke transporteres ud til kunder og er derfor kun
anvendelige i demonstrationslokaler og mødelokaler som fast
inventar.

Vigtigt: Tavledisciplin - skriv tydeligt! Det er sikkert
ikke alle, der kan læse din håndskrift!

2.1 K_r_i_d_t_t_a_v_l_e_

Er jern, masonit eller krydsfiner bestrøget med en mat lak.
Egnet skrive- og tegnemateriale er kun kridt, hvidt og
farvet, og tegneredskaber hertil er linealer, passere med
sugekop, m.m.

2.2 B_u_r_r_e_t_a_v_l_e_ _o_g_ _f_l_o_n_e_l_l_o_g_r_a_f_

Burretavlen virker på den måde, at man har en tavle beklædt
med et nylonstof, hvor overfladen er som små kroge. Herpå
kan man så hæfte filtstykker klippet i facon med en saks,
hæfte-oblater, hæftelister, hæftetråd, og færdige bogstaver
og tal i højde 5 cm. Standardtavlerne fås i størrelserne 590
x 465 mm, 890 x 770 mm og 890 x 124 mm (to-delt) hos A.
Behrend. Floneltavlen har det lige omvendt. Her er burrema-
terialet til at anbringe løst på tavlen.

2.3 M_a_g_n_e_t_t_a_v_l_e_

Er en malet jernplade, hvorpå man kan anbringe magneter m.m.
på samme måde som på burretavlen. Tilbehør er magnet-vinyl-
plader til at skære i ønskede former, magnetbogstaver og tal
i 4 cm's højde, magnetsnor og løse magneter til at anbringe
papir på tavlen (A. Behrened).

På magnet-vinylpladerne kan skrives med de fleste markerpen-
ne på vandbasis til AV-brug. Skriften kan fjernes igen med
en fugtig klud. Hvis der er brugt spritpen, kan skriften
fjernes med en speciel rensevæske (Nobo-spritcleaner eller
lignende).

Standardformater for f.eks. NOBO magnettavler er fra 915 x
610 mm til 1830 x 1220 mm.

Magnettavler kan også fås emaljerede, og så er anvendelses-
mulighederne udvidet med nedenstående.

2.4 E_m_a_l_j_e_t_a_v_l_e_n_

Emaljetavlen har en stor fordel sammenlignet med en almin-
delig kridttavle. Den er totalt støvfri, hvilket er af be-
tydning, hvor tavlen er placeret i et lokale sammen med de-
monstrationsudstyr (disketter o.lign.). Grunden hertil er,
at man bruger filtpenne på vandbasis til at tegne med i ste-
det for kridt. Det skrevne fjernes let igen med en fugtig
klud.

Filtpenne på spritbasis bruges, hvor man ønsker at lade nog-\f

le linier blive stående tilbage, når vandfarverne viskes ud
- f.eks. ved brug af rasternet med søjlediagrammer og lig-
nende.

Emaljetavler fra NOBO fås fra 610 x 305 mm til 2740 x 1220
mm.

En anden type emaljetavler kan fås, hvor man anvender spe-
cielle dry-markers (NOBO), som kan aftørres med en tør klud.
Denne type tavle findes også i en kombination med en magnet-
tavle. Samme mål og anvendelse som ovenfor. Alle emaljetav-
ler er udmærkede at vise overheadfilm og dias på.
\f

F_ 3 FLIP-OVER

Flip-overen består af et stativ, hvorpå der er anbragt en
blok med papir, der bruges som tavlen, men med filtpenne i
stedet for kridt. Den er ikke beregnet til de helt kompli-
cerede tegninger, men har den fordel i forhold til tavlen,
at man kan tilrettelægge og tegne på forhånd, evt. kan man
tegne det ønskede "rough" hjemmefra og så tilføje emner og
forløb foran publikum.

Størrelsen kan variere, alt efter om det er en bordmodel
eller en fritstående model. Desværre findes flere forskel-
lige former for fastgøring af papiret på stativet. Ved
genbestilling af papir, skal der tages hensyn til hulaf-
standen og antallet af huller (4 eller 6).

Flip-overen kan være placeret som fast inventar i et møde-
lokale, men er meget velegnet til at transportere i "mar-
ken". Visse modeller kan slås helt sammen og er da lette at
transportere og opbevare.

Fremstillingen af flip-over-plancher er som regel noget, der
påhviler foredragsholderen; men for en mere professionel ud-
formning og ved massefremstilling kommer informationsafde-
lingen ind og kan bistå med tegning og mangfoldiggørelse.

Ved fremstilling af omkring 5 ens plancher, kan det prismæs-
sigt anbefales, at de alle bliver tegnet. Fra 5 og opefter
anbefales enten serigrafi eller off-set som det mest økono-
miske. Produktionstiden for de sidstnævnte metoder er min.
14 dage fra aflevering af færdige plancher til tryk.

3.1 Bordmodel

Bordmodellen er en speciel plastmappe, som kan slås ud, så
den står fast på et bord (bladformater fra A4, 210 x 297 mm
til 590 x 465 mm). Den kan bruges i meget små forsamlinger,
5-6 mennesker, som kræver en meget personlig forevisning,
f.eks. ved kundebesøg.

3.2 Fritstående model

De fritstående modeller har bladformater op til 1043 x 1173
mm og er velegnede til forsamlinger på op til 15-20 menne-
sker. Papiret (ca. 120 g offset papir) er helt hvidt eller
hvidt med et 20 mm lysegråt kvadratnet, som letter fremstil-
lingen.

Ved fremstilling af flip-over bør man tilstræbe at lave
store, enkle illustrationer med en bred marker, så selv de
der sidder bagest i lokalet kan se tegningerne uden at
anstrenge sig. \f

F_ 4 OVERHEAD

Overheadprojektion er et meget anvendt og fleksibelt system.
Nemt at transportere og fremstille film til. Publikums antal
kan variere fra 10 til 30 uden at det forringer kommunika-
tionen.

Foruden at kunne tilrettelægge i forvejen, detaljeret med
farve og overliggere, kan man ved fremvisningen tegne på en
klar acetatfilm, som man har anbragt ovenpå en allerede teg-
net overheadfilm eller direkte på reflektorpladen. Derved
får overheadprojektoren samme anvendelsesmuligheder som
tavlen.

I stedet for at montere filmen i en papramme, kan den vises
i en speciel klar plastlomme (3M), som beskytter filmen og
samtidig gør det muligt at opbevare den i et ringbind.

Holdbarheden for nogle typer film er ca. 3 år, hvilket man
skal tage hensyn til ved beslutning af hvilken metode, der
skal anvendes ved fremstillingen.

4.1 Udarbejdelse af manuskript

Ved fremstilling af overheadfilm er der visse hensyn at tage
til originalmanuskriptet:

Originalmanuskriptet må ikke indeholde mere end 50
bogstaver pr. film.

Bogstaverne skal være over 5 mm høje (de skal kun-
ne læses, når man holder filmen i 2 meters af-
stand)

Brug ikke fremmedord, lange ord eller lange sæt-
ninger.

Brug så vidt muligt symboler og tegninger i stedet
for ord.

Se også afsnit 6, Generelle råd.
\f

4.2 Fremstilling af overheadfilm

Ved fremstilling af overheadfilm kan man, afhængigt af antal
og ønsket kvalitet, vælge mellem fem metoder: reprokamera,
Cibachrome, silketryk, Termofax (3M) og fotokopieringsmaski-
ne. De tre første involverer arbejdskraft fra flere end den,
der skal holde foredraget og er derved noget dyrere end de
to sidste. Rækkefølgen for den dyreste til den billigste er
følgende: Cibachrome, reprokamera, termofax og fotokopie-
ring. Silketryk kommer først ind ved massefremstilling, men
prisen vil da ligge mellem cibachrome og reprokamera. Frem-
stillingstiden vil afhænge af filmenes detaljerethed og
fremstillingsmetode. (Husk at advisere alle implicerede
parter i fremstillingsfasen i god tid).

4.2.1 R_e_p_r_o_k_a_m_e_r_a_
Giver kun sort streg på klar film eller negativt, og raster-
billeder kan laves. Originalmaterialet skal være sort eller
mørkerød streg på hvid eller lyseblå baggrund, for at den
her anvendte fotografiske film kan registrere det.

Dette er en temmlig dyr og tidskrævende metode, og den kan
kun anbefales, hvor der skal laves få transparenter eller
hvis originalmaterialet skal forstørres.

4.2.2 C_i_b_a_c_h_r_o_m_e_
Cibachrome er en affotografering som et dias, men med tynd-
ere farver, så lystabet ikke er så stort. Originalmaterialet
kan derfor være i alle farver og være farvefotografier etc.
Dette er desværre den dyreste metode, men med et meget
eksklusivt resultat, som kan anvendes til et selektivt
publikum

4.2.3 S_i_l_k_e_t_r_y_k_
Filmen kan blive alle farver på negativ eller positiv, og
groft rastede billeder ser også godt ud med denne metode.
Originalmaterialet skal være sort eller mørkerød streg på
hvid bund. Hvis der skal være flere farver på en film, skal
originalens farver være udskilt med en sort/hvid original
for hver farve. Denne fremgangsmåde er billig ved massefrem-
stilling af ens overheadfilm, over 20 stk., men kan ikke
betale sig ved antal derunder. \f

4.2.4 T_e_r_m_o_f_a_x_ _(_3_M_)_
Negativ og positiv film i 5 forskellige farver og raster-
billeder kan laves på denne maskine, som er den hurtigste,
billigste og mindst arbejdskrævende. Originalmaterialet skal
være kulholdig streg på en hvilken som helst farvet bag-
grund, da denne type film ikke er følsom for farver. Ved en
kulholdig streg forstås, at det enten er en fotokopi eller
et originalt skrivemaskinemanus. Nogle typer 3M film er dog
følsomme overfor reprofotos, hvor det sorte ikke er på kul-
basis, men sølvbasis.

4.2.5 F_o_t_o_k_o_p_i_e_r_i_n_g_s_m_a_s_k_i_n_e_
Brug af fotokopieringsmaskine giver det ringeste billede,
næsten sort streg på klar film, men er til gengæld billigt.
Originaler skal være sort streg på hvidt papir. Papiret i en
fotokopieringsmaskine udskiftes med film og der tages kopier
som ved normalt brug.

4.3 Fremvisning

Ved fremvisning bør man dæmpe lyset en smule, men ikke så
meget, at det virker mørkt, for det er stærkt sløvende på
publikum. Man skal hele tiden tilstræbe at holde publikums
interesse fangen ved at veksle mellem at tale, mens overhead
projektoren er slukket, tænde projektoren og lade publikum
selv læse det, der er blevet fortalt, og så uddybe emnet.
Man kan evt. gøre det mere enkelt ved at overdække dele af
overheadfilmen med papir, eller ved at lave overlæggere
(film), som kan tapes fast i den ønskede rækkefølge på en
papramme.

Flere typer overheadprojektorer findes på markedet; alminde-
lige gennemlysningsprojektorer med billedfelter på 25 x 25
cm og 30,5 x 30,5 cm. Refleks projektorer (3M), der er nemme
at transportere, men til gengæld ikke er så lysstærke, 25 x
25 cm billedfelt. Kombineret overhead/dias-fremvisning (Dia-
Graph 900), hvor man kan vise dias og bruge overheadfilm til
at tegne på samtidig.

Projektionsskærmen bør være af en mat type, hvor den øverste
side kan hældes lidt frem for at korrigere den forvrængning,\f

der opstår, når projektorhovedet er lavere placeret end
midten af skærmen. Perleskærm kan også bruges, men det går
ud over billedets gengivelse for de tilskuere, der ser
skærmen under en spids vinkel (stort lystab). \f

F_ 5 Dias, film og videotape

Dias, film og videotape er specielt egnet til større forsam-
linger og udstillinger. Fremvisningen kræver dog gode loka-
leforhold: der skal være afstand fra projektoren (Kodak Kar-
rusel) til lærredet, god akustik, og lyset skal kunne dæm-
pes, da lysbilledfremviseren ikke er så lysstærk som over-
headprojektoren. Afstanden fra lysbilledapparat til skærm
gør det svært for en foredragsholder at stå både ved frem-
viseren og ved lærredet med front mod publikum. En fjernbe-
tjeningsenhed er da at foretrække fremfor en ekstra medhjæl-
per. Til at pege kan en lyspil bruges.

Men også i mindre forsamlinger er dias uhyre velegnede. Her
anvender man istedet for en Kodak Karrusel, f.eks. en trans-
portabel Bell & Howell bagprojektionsfremviser, hvor billed-
formatet er med mulighed for at forstørre den midterste,
kvadratiske del af billedet. Projektoren kan endvidere let
omstilles til at være en almindelig projektor til en ekstern
skærm. Den indeholder også en kassettebåndoptager, hvor man
kan indtale sit foredrag på et spor og bruge det andet spor
til indlægning af lydimpulser, der får projektoren til at
skifte billede. (Regnecentralen har bl.a. 2 af disse
fremvisere.) Den eksterne projektionsskærm kan være såvel
normalt kendte som sammenklappelige bordmodeller, hvor
bagprojektion i format -x- gør det muligt at vise billeder
for op til 10-15 personer. Sidstnævnte kan anvendes uden
mørklægning.

Det er disse medier, der kommer nærmest til virkeligheden i
billedgengivelse, men også dem, der kræver mest af original-
materialet og produktionen. I denne vejledning er kun med-
taget dias, dels fordi film- og videotapefremstilling kræver
professionel assistence både ved forfatning af drejebog og
optagelse af filmen, og dels fordi de økonomisk ligger højt
over de førnævnte AV-midler.

5.1 Dias

Som originalmateriale til dias kan bruges alt tegnet mate-
riale, modeller og billeder fra virkeligheden. Ved montager
skal man omhyggeligt sørge for at skærekanterne ligger uden-
for billedformatet, da alle kanter og skygger kan ses ved
brug af dias.

Produktionen bør helst foretages af informationsafdelingen,
for tilskuere forventer et mere professionelt show end
f.eks.\f

overhead, men hvis først serien er afprøvet og tilpasset, er
det meget let at holde foredrag uden at glemme noget og gen-
nemgå det i den rigtige rækkefølge. Med Kodak Karrusel
Magasin er det også muligt at vende tilbage til tidligere
viste billeder med et enkelt tryk på fjernkontrollen.

Specielle råd for dias:
Fortæl tilhørerne lidt om indholdet i diasserien
før den vises. Det skærper interessen.

Begræns antallet af dias til det absolut nødvendi-
ge.

Varier indhold og præsentation (tekst - diagrammer
- udskrifter).

Er tekst nødvendig, så gør den k_o_r_t_!

Vis aldrig en diasserie lige efter en frokost, da
sammenstillingen af fuld mave og mørkt lokale til
tider virker søvndyssende.

En meget stor fordel ved dias er den meget prisbillige frem-
stilling af kopier. Dette kan udnyttes ved fremstilling af
identiske serier, der udleveres til sælgere, datterselskaber
m.m. Herved sikres at en kampagne følges op efter modersel-
skabets forskrifter. Endvidere er det også en stor fordel at
en serie dias ikke fylder og vejer ret meget og derfor er
velegnet til at sende pr. post. Det bedste er at sende seri-
en umonteret, godt beskyttet af karton i et brev eller i en
speciel dias emballage.

Produktionstiden for tegninger, modeller m.m. varierer meget
- alt efter opgaven, mens produktionstiden for
affotografering er ca. en uge og det samme ved kopiering af
allerede eksisterende dias.

Ved fremvisning bør man altid bruge en fremviser med fjern-
kontrol for at være nær ved lærredet. Vedrørende lærredets
og fremviserens placering, se afsnit om generelt, side .

De almindeligste formater på dias er 28 x 28 mm, 24 x 36 mm
og 5 x 5 cm, (Kodak Carrousel og Rollei), men andre formater
kan fås. Til billedudsnit fås diagrammer med forskellig
udformning og placering. \f

F_ 6 GENERELLE RÅD

M_a_n_u_s_:_ L_a_v_ _a_l_d_r_i_g_ _e_t_ _f_o_r_e_d_r_a_g_ _i_ _s_i_d_s_t_e_ _ø_j_e_b_l_i_k_!_
Lad der gå et par dage fra manuskriptet
er lavet til man påny gennemlæser det.
Hvis andre er involveret i produktionen,
adviser dem da god tid i forvejen.

De visuelle hjælpemidler er aldrig bedre
end den ide, de repræsenterer. Lav der-
for et velgennemtænkt manuskript med en
hovedlinie som bærende kraft.

Behandl kun eet emne pr. billede eller
planche.

Ved mere vanskelige fremstillinger bør
man altid bygge på og sammenligne med
noget kendt, for ikke at "tabe" tilhø-
reren.

Enkelhed skal man tilstræbe ved enhver
af de nævnte AV-midler, - alle overflø-
dige ting bør sorteres fra allerede ved
manuskriptfremstillingen, men man skal
også ved produktionen og fremvisningen
være på vagt, for at fremmedord og irra-
tionelle vendinger og tegninger ikke
dukker op.

B_i_l_l_e_d_p_l_a_c_e_r_i_n_g_:_ Man bør tilstræbe, at gennemgangen af en
planche går fra øverste venstre hjørne
til nederste højre hjørne for at tilsku-
ernes øje får en naturlig bevægelse.

6.1 Produktion

F_a_r_v_e_r_:_ Ved situationer, hvor de samme emner
gentages flere gange, bør man så vidt
muligt give dem samme farve, således at\f

publikum forbinder farven med emnet og
derved får en meget hurtigere forståelse
på grund af genkendelse. Farver kan også
bruges til at illustrere en tilstand ved
et emne, f.eks. rød = varm, blå = kold
osv.

F_r_e_m_v_i_s_n_i_n_g_:_ Stå aldrig med ryggen til publikum og
hold interessen fangen ved at veksle
mellem at vise billeder og så tale og
tegne. Husk at den fjerneste tilskuer
også skal høre og se; tal derfor højt og
tydeligt og placer lærredet så højt, at
de bageste kan se hele lærredet over
hovederne på de forreste tilskuere.

Ved forevisning på lærred, sørg for god
mørklægning - detaljer og præsentations-
indtryk svækkes ved solbeskinnede dias.

I forevisninger bør lysbilleder, over-
heads m.m. aldrig blandes mellem hin-
anden; derimod kan man godt vise en
serie lysbilleder eller overheads og så
bygge videre på det sete ved hjælp af en
tavle eller flipover.

P_r_i_s_e_r_:_ Med hensyn til økonomi, må man se på
antal publikum, lokaleforhold, manu-
skript og AV-medie.

Ved påtænkning af en AV-serie, kontakt
da altid informationsafdelingen for at
få prisskud og for at blive booked ind
for en eventuel produktionsassistance. \f

RC 3600
System
Architecture

Revison 2
A/S REGNECENTRALEN January 1979
Information Department RCSL 42 - i 1215\f

Author: Henning Christensen
Text editor: David McLeod

KEY WORDS: RC 3600, basic hardware structure, basic software
structure, and user applications.

ABSTRACT: This manual describes the structure of the RC 3600
system, both hardware and software, and gives a brief
explanation of how the RC 3600 can be used and opera-
ted.

Reservation

TABLE OF CONTENTS

1 INTRODUCTION Page 5

2 THE RC 3600 SYSTEM 6
2.1 RC 3600 Hardware 6
2.1.1 The Central Processing Unit 6
2.1.2 The Memory8
2.1.3 The Peripheral Devices9
2.1.4 The Real-Time Clock10
2.1.5 The Hardwareload Feature 11
2.2 RC 3600 Software 13
2.2.1 The Monitor14
2.2.2 The Drivers16
2.2.3 The System Process -S-16
2.2.4 The Autoload Feature18
2.2.5 Basic Systems Software18
2.2.6 Utility Programs19

3 THE RC 3600 USER SOFTWARE20
3.1 User Programming 20
3.1.1 Program Production Packages20
3.1.2 MUSIL20
3.1.3 BASIC/COMAL21
3.2 RC Application programs23

4 OPERATING THE RC 3600 SYSTEM24

5 THE RC 3600 SYSTEM - APPLICATIONS26
5.1 Stand-Alone System26
5.1.1 Data Conversion/Data Collection/Data Entry26
5.1.2 Minicomputer27
5.2 Device Controller27
5.2.1 Front End Processor 27
5.2.2 Remote Device Controller/Remote Job Entry 27
5.2.3 Emulation 28
5.3 Communications Equipment28
5.3.1 Terminal Concentrator 28
5.3.2 RC NET 29\f

1 INTRODUCTION

The RC 3600 is an intel-
ligent s_y_s_t_e_m_, reliable
and flexible. Because of
its intelligence, the
system possesses a great
capability in handling
peripheral devices, as
well as it may operate as
a stand-alone system.

The RC 3600 is a system
composed of hardware and
software. The under-
lying hardware supplies
reliability and simplici-
ty of operation. The su-
perimposed software pro-
vides flexibility and
wide capability.

The division of tasks be-
tween hardware and soft-
ware assures the best
performance for the low-
est cost, each component
contributing those per-
formance elements for
which it is best suited.

This manual describes
the RC 3600 hardware,
systems software, and
user software, and pro-
vides a brief survey of
some typical applica-
tions.

An RC 3600 System\f

F_ 2 THE RC 3600 SYSTEM

2.1 RC 3600 Hardware

The major hardware elements in an RC 3600 System are: a central
processing unit, a memory, a real-time clock and a range of peri-
pheral equipment.

Construction module techniques are applied throughout. Print cir-
cuit boards contain the electronics. The boards fit into chassis,
which again fit into a cabinet.

2.1.1 T_h_e_ _C_e_n_t_r_a_l_ _P_r_o_c_e_s_s_i_n_g_ _U_n_i_t_
The RC 3600 System operates on a 16-bit word basis, extended with
a 2-bit parity feature, checked during memory read cycles, gener-
ated during write cycles. Another feature is the "hardware inter-
rupt", which allows interrupt of internal activities when this is
made necessary by the operation of the peripherals. These feat-
ures relate to the microprogramming of the processor.

The CPU systems of the RC 3600>s are available in two groupings
according to different technologies in manufacturing memories.

The CPU RC 3703 including semiconductor memory\f

The one group contains the
CPU RC 3703, which supports
semiconductor memory and
processes the data in a 4-
bit sectional way. CPU and
memory are incorporated onto
one circuit board, leaving
space for 4 additional
boards in the chassis. Due
to this technology the
processor is available at a
lower price, yet at a high
performance.

The other group contains
the CPU RC 3603, and the CPU
RC 3803. Both they offer a
higher performance, due to
the data word processing in
a 16-bit parallel mode. The
CPU RC 3803 furtherly com-
prises extended microprogram-
med facilities which addi-
tionally increases the per-
formance.

These CPUs support core me-
mory. Depending on the me-
mory size, it will often be
necessary to apply one or
more additionel chassis to
accommodate the controllers
of applied devices.

The CPU RC 3603\f

F_ 2.1.2 T_h_e_ _m_e_m_o_r_y_
The memory is normally
accessed from the central
processor, but there is
also a Direct Memory
Access Channel, which
allows the faster peri-
pherals, such as disc
units, to access the
memory directly. This
allows faster data trans-
fers to and from these
peripherals.

Memories are either manu-
factured as core or semi-
conductor memory.

The semiconductor memory
is available at a fixed
size of 64 Kbytes, sup-
ported by the RC 3703 CPU.

Core memory is available
ranging from 32 Kbytes to
128 Kbytes, the incremen-
tal sizes being 32 or 64
Kbytes-supported by either
the CPU RC 3603 or RC
3803.

Using the CPU RC 3803
allow direct adressing of
128 Kbytes and usage of
all memory for operatio-
nal work.

Using the CPU RC 3603
allow direct adressing of
64 Kbytes and usage of
the 64-128 Kbytes memory
range for data storage.

A Memory Board (core
memory)\f

F_ 2.1.3 T_h_e_ _p_e_r_i_p_h_e_r_a_l_ _d_e_v_i_c_e_s_
The peripheral devices
each interface with the
central unit through a
circuit board. This cir-
cuit board is called a
"controller", for its re-
sponsibility is to con-
trol the flow of data to
and from its peripheral
device.

Certain peripherals can
employ "channels". These
enable more than one de-
vice of the same type to
share a controller, e.g.,
more than one tape unit.

A Controller Board

F_ 2.1.4 T_h_e_ _r_e_a_l_-_t_i_m_e_ _c_l_o_c_k_
The real-time clock
allows interrupts to
be established at
regular intervals,
and this provides
the basis for mul-
tiprogramming (which
is discussed be-
low).

The Real-Time Clock

F_ 2.1.5 T_h_e_ _h_a_r_d_w_a_r_e_ _l_o_a_d_ _f_e_a_t_u_r_e_
The hardware system ex-
plained so far cannot
manage any data processing
on its own. It has got the
ability to perform
instructions due to the
microprograms laid down in
the processor, yet the
"rules" according to which
these instructions have to
be applied are missing -
the software is missing.

To furnish the hardware-
system with software, the
hardware components have
to know where to put it
and from where to get it.

Powering the equipment in-
itially causes the proces-
sor to automatically
carryout a function that
tells it where to locate
a software load in the
memory. The switches of
the front frame of the
CPU allow a preselection
of the peripheral device
from where the software
can be fetched and read
into the memory. The
procedure is initialised
with the autoload button.

Power and Autoload Panel
(upper panel)

Switches, CPU front frame
(lower panel)

Loading specific software directly would - in principle - enable
the system to perform data processing, but subjected to many
complications and limitations. For instance, new software would
have to be loaded all from "the buttom", whenever a different job
had to be run.

To avoid these limitations, the RC 3600 System initially is loa-
ded with basic systems software according to the above proceed-
ure. Once loaded the basic software takes over supervision of the
system, calling for the operators attention via a console device,
simplifying run-procedures.\f

F_ 2.2 RC 3600 Software

The goals of RC 3600 Software are these:

- to allow more than one job to be run at the same time, that is,
to implement "multiprogramming".
- to allow high-level languages to be used on the system.

The purpose of multiprogramming is to make the single central
unit behave as though it were more than one central unit, that
is, multiprogramming simulates multiprocessing. It can do this
because no task requires the constant attention of the central
unit. By switching its attention among the various tasks it must
perform, the central unit can appear to be several central units,
or, as one can call it, a "virtual" multiprocessing system.

In order to perform in this way, the central unit must be able to
regard each job as made up of a number of "processes", so that it
can switch its attention among running jobs by concentrating on
one process at a time, rather than one full job at a time. Thus,
the central unit can use pauses between the processes of one job
to perform a process from another job. Much of the time these
pauses are provided by the I/O processes which often must wait
for other processes to be completed before they can run to com-
pletion.

In order to implement the above-mentioned goals, the RC 3600
Software complements each hardware component by a software
component. The result is a s_y_s_t_e_m_ that can be thought of as a
combined hardware-software "machine".
\f

Up to now only the hardware has been described. It can be
represented as follows:

RC 3600 Hardware

2.2.1 T_h_e_ _M_o_n_i_t_o_r_
The Monitor is the first software element to be discussed. Its
job is to implement multiprogramming, that is, to make the single
central unit look like a number of central units. To do this, the
monitor must collect information of the simultaneous processes,
so that they can be scheduled.

The information the Monitor collects on a process is called the
"process descriptor". Among the information in the process de-
scriptor is the name, priority, and status of the process.

The presence of a clock mechanism allows time intervals to be
allotted to each process in turn so that, for example, Process A
can be performing data conversion while Process B is printing
lines, without Process A having to wait until Process B has prin-
ted all its lines. To the observer the processes, then, appear to
be running in parallel. In order to do this, the monitor must
have control of the hardware interrupts. \f

The Monitor thus overlays the hardware real-time clock and inter-
rupt system with software and replaces the single hardware cen-
tral processor with a number of virtual processors. The system
looks like this so far:

RC 3600 Hardware plus Monitor

where the dashed lines represent software and the solid lines re-
present hardware.

The Monitor can also mediate the exchange of information among
the various processes. Thus, the Monitor is a connecting link
among the virtual central processors.

RC 3600 Hardware plus the Monitor performs like a virtual multi-
processing machine.

In order to handle I/O events and processes in an efficient way,
to standardize I/O programming, and to solve reservation pro-
blems, each peripheral unit is handled by a dedicated process
called a "driver". \f

2.2.2 D_r_i_v_e_r_s_
Drivers are software modules, each of which is dedicated to a
specific physical unit. The driver represents the peripheral unit
to the RC 3600 System. That is, as far as the system is concerned,
the drivers a_r_e_ the peripherals. Since the machine now has to
deal only with drivers, and not with peripheral hardware itself,
a uniform I/O protocol can be used for all peripherals.

The hardware plus the Monitor and the drivers form a virtual mul-
tiprocessing machine with attached virtual peripherals.

RC 3600 Hardware plus Monitor and Drivers

2.2.3 T_h_e_ _S_y_s_t_e_m_ _P_r_o_c_e_s_s_ _-_S_-_
The System Process -S- completes the systems software of the RC
3600 System. It replaces the hardware load feature, which could
only load one program into the memory, and from only one device,
with a software loader that can load processes into the system
dynamically and can allow a variety of program load devices. It
does this by assuming control over the allocation of space in
memory to the various processes. It keeps track of the processes
as they run by creating the process descriptors that the Monitor
can use.\f

-S- also replaces the buttons and switches of a typical hardware
machine by being a system supervisor through which the operator
can communicate with the RC 3600 System, rather than with the
hardware alone.

The addition of -S-, the Monitor, and the drivers to the under-
lying hardware creates an RC 3600 S_y_s_t_e_m_, which is a multiprogram-
ming machine. This was the first goal of the RC 3600 System de-
sign.

The RC 3600 System
\f

2.2.4 T_h_e_ _A_u_t_o_l_o_a_d_ _f_e_a_t_u_r_e_
Systems software occupies space in memory, and it is desirable
that this space is as small as possible. Still, the systems soft-
ware should be able to perform with maximum flexibility, as well
as be easy to operate. With respect to RC 3600 Systems software
these considerations revolve around the systems program module
-S-.

-S- was described as a program loader and a supervisor through
which the operator can communicate with the system.

Furthermore some facts must be kept in mind about -S-:

-S- cannot load itself. The hardwareload feature must
be used to load -S-, which means a load device is
preselected.

-S- is designed to prefer one device above all others
as the load device in order to simplify operation.

-S- communicates with the operator through a console
device, which makes it necessary to associate -S- and
the console device driver very closely.

As a result, it is most convenient to associate -S-, load device
driver and console device driver, and load them together, using
the hardwareload feature.

The system now provides the user with a preferred load device -
the "autoloader" - and a direct communication link which makes
the system easy to operate and allows -S- to guide further
program loads.

To allow the user to choose the autoloader and type of console
best suited to his requirements - and still keep the occupied
space in memory as small as possible - is asking for the systems
software provided in "basic systems" packages.

2.2.5 B_a_s_i_c_ _s_y_s_t_e_m_s_ _s_o_f_t_w_a_r_e_
The basic systems software package is selected according to the
autoload device, which the user regards as his main load device.

MUS (Multiprogramming Utility System) allows four types of
devices to be used as autoload devices: a magnetic tape station,
a paper tape reader, a card reader or a flexible disc unit. One\f

of the four is selected as the autoload device, but once this
device has loaded the drivers of any of the other devices, they
as well may be used to load programs, merely by telling -S- which
load device currently is to be used.

DOMUS (Disc Operating MUS) features a disc unit as an autoload
device. DOMUS only indirectly allows load from other devices;
program loads contained on other data media have to be copied to
discs before loading, which, however, is easily accomplished. The
driver of the non-disc unit considered only has to be loaded from
the disc unit, then the system allows the copy proceedure pre-
required to load.

Both basic systems need a console device, which may be selected
among several keyboard devices with printing or VDU capability.

2.2.6 U_t_i_l_i_t_y_ _p_r_o_g_r_a_m_s_
The utility programs correspond to the level of basic software
and make up software routine facilities of great usability and
effectivness - they might be thought of as "selectable" basic
software (although, one might as well regard the basic software
to be composed of "necessary" utility programs). Whether the user
wants to write his own programs or run RC application programs,
utility programs are involved.

In fact some commonly used utility programs are included in the
basic software packages. Both MUS and DOMUS contain the MUSIL
interpreter, which is necessary in order to run MUSIL high-level
language programs. Furthermore DOMUS has been equipped with a
catalog- and a paging-system.

Briefly mentioned, other utility programs of interest could be:

- MUSIL compiler
- page oriented text editor
- macro assembler
- catalog/file handling routines
- batch processor
\f

F_ 3 THE RC 3600 USER SOFTWARE

To run user>s jobs software is needed beyond the basic system
software. Either in form of application programs delivered by RC
to be run as-is or user written programs in high-level languages,
the second goal of the RC 3600 System software.

3.1 User Programming

User programs are most conveniently written in high-level lang-
uages. The RC 3600 Systems support two such langauges: MUSIL and
BASIC/COMAL.

3.1.1 P_r_o_g_r_a_m_ _P_r_o_d_u_c_t_i_o_n_ _P_a_c_k_a_g_e_s_
For the user writing his own programs, RC provides Program Pro-
duction Packages. Each of these packages contains a Compiler, a
Text Editor, any necessary drivers for the compilation and edi-
ting tasks, and a Run Generator for placing necessary systems and
applications software together on one medium, so that a complete
job run is generated. The Run Generator can also place "Command
Files" on the medium. These are files containing operator com-
mands, so that operator actions are automated. This is particu-
larly useful for runs that involve loading different programs
from different types of devices.

3.1.2 M_U_S_I_L_
MUSIL is an ALGOL-like programming language that is specifically
suited for computer support functions. MUSIL can handle all sorts
of I/O tasks and can operate on character, record or file level.
It is easy to learn and can be learned in stages, for its instruc
tions can be arranged in hierarchy. This means that the novice
programmer can use those instructions that represent complex
procedures and are carried out automatically according to stan-
dard procedures, while the more experienced programmer can use
detailed program instrutions to assume very direct control over
program execution.

For example, a standard procedure is provided for handling excep-
tions, but the programmer may also decide to write his own excep-
tion-handling routines. Buffer control, too, can be handled by
standard procedures, or the programmer can assume more complete
control over I/O by using detailed program instructions.\f

In the case of MUSIL the program Production Package provides the
MUSIL Compiler that takes in MUSIL source code as input and out-
puts MUSIL object code, which is loadable, but not executable.
The compiler provides error diagnostics for program debugging .
It also allows assembler-coded subroutines, called "Code Proce-
dures" to be compiled into a MUSIL program, much the same as
assembler subroutines can be compiled into a COBOL program.
Finally, the MUSIL Compiler allows great flexibility during
compilation, for example, parts of one program can be inserted
into another program.

In order to execute the MUSIL object code, a MUSIL interpreter is
applied. Actually - as mentioned earlier - the interpreter is
incorporated in the basic software package.

Altogether these software elements form one of the RC 3600 Sys-
tems software opportunities, attaining the two design goals.
Similar tools are provided in the high-level language BASIC/
COMAL.

3.1.3 B_A_S_I_C_/_C_O_M_A_L_
RC BASIC/COMAL is a structured educational language; it is simple
and comprehensive, yet sufficiently advanced to permit demonstra-
tion of important programming principles.

The original BASIC has several deficiencies regarding advanced
programming. Recently proposals for new and better educational
languages have been put forth, among them COMAL (Common Algorith-
mic Language). COMAL possesses all the features that made BASIC
popular, in fact COMAL includes almost all the facilitites of
BASIC plus a number of advantageous features.

Incorporating COMAL into RC BASIC/COMAL provides the following
extensions compared to ordinary BASIC:

IF-THEN-ELSE, REPEAT-UNTIL, WHILE-DO and CASE-OF-WHEN statements.
Eight character variable names.
Structured programming without GOTO line number.
Interactive program execution.
Batch mode program execution.
File input/output.
Matrix operations.
String and string array manipulations.
Output formatting.
Desk calculator functions.
\f

With these features RC BASIC/COMAL covers the total educational
range from the most introductory level to advanced production
programming training.

3.2 RC Application Programs

Over 500 applications programs are available from Regnecentralen.
These programs may be used directly for tasks involving data
conversion, data entry and data collection, data processing, and
communications. Standard terminal emulation programs are also
available.

The great advantage of using the RC 3600 as a terminal emulator
is that RC provides a wider range of peripherals than the
corresponding terminals of the mainframe manufacturers, and
enables the user to communicate with a variety of mainframes by
simply reading in the appropriate emulator program. The hardware/
software terminal configurating are specific to one emulation,
but they can be upgraded to a full-scale RC 3600 System.

RC application programs are provided for the user in object code.
They can be run "as is", or they can be customized for special
user requirements. In either cases, the normal practice is to
include them on the same run medium on which the basic systems
software is written in order to simplify system operation.

On request RC also may provide the user with programs specified
by the user.\f

F_ 4 OPERATING THE RC 3600 SYSTEM

The user initiates the RC 3600 System at the Power and Autoload
Panel. A keyboard device used as console is the operators com-
munication-tool to the system during work. The various keyboard
devices can run all of the standard programs and can also be used
for the creation of source code programs.

Some of the more complex operator functions that are easily ac-
complished on a keyboard device, such as changing the program
load device, can also be accomplished by the system, having
"command files" on the program medium. Command files imitate ope-
rator action. They are supplied by RC, or can be developed by the
user.

RC 3600 operation is both simple and flexible. Appropriate pro-
gramming allows a run to proceed almost automatically. One can
write a program in such a way that there are points in it at
which the program asks the operator to perform some action or to
make some decision. Such decisions are made by the operator's
assignment of specific pre-determined values to the "run-time
parameters" presented to him.

System and program loading is accomplished easily in two or three
steps. It is, for example, no more difficult to run an entire mag-
netic tape than it is to select specific files from that tape.
All RC 3600 programs clearly request the actions or information
they require and present the alternatives available when neces-
sary.

Furthermore operating guides are provided to make the operation
of an RC 3600 System easy. Actually most users learn to utilise
the equipment effectively within the first few days.

Certain hardware facilities are also available to simplify opera-
tion. An example:

Normally the initial loading of basic software is completed once
and for all. Yet certain irregularities in power supply may cause
a need for re-load.

Due to technology a semiconductor memory will suffer from power
outages, losing the memory-stored information. To enable a quick
recovery a hardware module (a Read Only Memory module) can\f

be supplied, which contains the basic systems software and from
where the system can fetch what otherwise would have to be loaded
from the hardwareload feature.

The content of a core memory is not erased by power failure, an
automatic power restart feature enables the system to continue
working.

Particularly in the case of the unattended remote applications an
automatic system load feature may be very useful. If the load
device is selected to be the adaptor, which links the system to a
central site computer, then the automatic system load feature
allows a loading to be accomplished from the central site.\f

F_ 5 THE RC 3600 SYSTEM APPLICATIONS

As explained in the previous sections any system is composed of
hardward and software, and - due to the interaction of hardware/
software - the system design may outline certain capacities to
others, thereby offering a large scale of different application
skills.

Only a brief survey of applications is given here. Detailed infor-
mation on topics of interest may be obtained from your RC-contact
person. Please ask.

5.1 Stand-alone Systems

Mostly an RC 3600 System is applied as a help-mate to a larger
computer system. But it well may work as a stand-alone system,
supporting a larger system or truely on its own, due to the fact
that it autonomously controls the attached devices and is given
data treatment capabilities by adding appropriate software.

5.1.1 D_a_t_a_ _c_o_n_v_e_r_s_i_o_n_/_D_a_t_a_ _c_o_l_l_e_c_t_i_o_n_/_D_a_t_a_ _e_n_t_r_y_
The presence of driver programs allow a variety of devices to be
used with the RC 3600 System. Relieving a larger system (offline)
or utilizing devices not attachable to the larger systems, cause
some typical support applications:

- data conversion,
one type of file may be converted into another, magnetic tape
files or other data media files are often printed, proceeding
this way.

- data collection,
data from different device sources may be collected and a file
created (merged, organized), for instance to be processed at a
larger system.

- data entry,
data from local or remote keystations may be entered to the
system, creating a disc file - the system is distinguished by
facilities such as the multi-user feature, record format
control and data management functions.
\f

F_ 5.1.2 M_i_n_i_c_o_m_p_u_t_e_r_
The hardware and basic software made available as the RC 3600
system may be altered into a true stand-alone minicomputer,
adding hardware and furnishing the system with appropriate
software.

Such minicomputers may be configurated to cover various aspects
involved in business affairs, technical work or educational
tasks.

Pre-structured systems - the RC 7000 Systems - are available,
covering the educational and scientific range and are supplied
with the software tools belong to RC BASIC/COMAL.

The RC 7000 Systems and other user specific configurations of the
RC 3600 Minicomputers all offer a number of valuable features:
online support of multiple users, mixed batch and online process-
ing, communication facilities - to mention some.

5.2 Device Controlling

As a help-mate to a larger computer system the skills in device
handling - referred to in describing the stand-alone systems -
are extended with the capability of exchanging information online
with a host computer.

5.2.1 F_r_o_n_t_ _E_n_d_ _P_r_o_c_e_s_s_o_r_
As an integral part of the RC 8000 system, known as the front-end
processor, the hardware and basic software components of the RC
3600 system together with special software, fully utilize its
skills in device handling and in case of remote devices it also
provides the communication-link facilitites.

The concept of a front-end processor integrated into the RC 8000
system gives optimum work conditions both on the central and the
peripheral sides of the system.

5.2.2 R_e_m_o_t_e_ _D_e_v_i_c_e_ _C_o_n_t_r_o_l_l_e_r_/_R_e_m_o_t_e_ _J_o_b_ _E_n_t_r_y_
Not all peripherals are local ones, many applications demand
remote facilitites. Used as a remote device controller, the RC
3600 components applied possess capabilities equal to a front end
processor. Furthermore it is equipped with communications hard-
ware and software, enabling the exchange of information with the
central site computer. \f

Levelled above mere device controlling, the Remote-Job-Entry-
issue facilitates the opportunity to "operate" the mainframe from
a remote site.

Hence, operators of a mainframe system will find little
difference whether working at a local or a remote site.

5.2.3 E_m_u_l_a_t_i_o_n_
Besides communication between RC equipment, it might be desirable
to interface to products of other manufacturers.

As a terminal, the RC 3600 can operate in emulation as some other
terminal, such as IBM 2780/3780, IBM HASP/RES Multileaving
Workstation, CDC 200 UT BCD/ASCII, UNIVAC NTR, ICL 7020 and
others. The emulation programs are software packages
corresponding to the terminal configuration, which means that
just by changing software the system can simulate different
terminals at different times.

Thereby, the RC 3600 System offers independency, optimizing the
configuration possibilities. Emulation jobs are likely to run in
a system as Remote-Job-Entry terminals.

5.3 Communications Equipment

The stand-alone systems were seen to outline capabilities in
device handling, further as "help-mate" systems they gained
capabilities in communications handling. However, as
communications equipment the systems are applied significantly in
order to handle communications.

5.3.1 T_e_r_m_i_n_a_l_ _C_o_n_c_e_n_t_r_a_t_o_r_
Using several terminals often increases cost of running beyond
the acceptable, especially if each terminal is allowed to commu-
nicate on separate lines.

To concentrate the communication-traffic onto one line the RC
3600 System, equipped as Terminal Concentrator, is applied. A
decrease in line-need as well as a better utilization of the
lines in use, is the result, minimizing cost of running. \f

5.3.2 R_C_ _N_E_T_
To automatize communications, making sure that information ex-
changes are carried out properly and most effectively, the RC
3600 System has yielded another major task. It has been adopted
as the fundamental element of the RC NET.

Within the RC NET network concept an installation with data pro-
cessing capacity is termed a "host". Associated to each host is a
"node" and the nodes are interconnected by communication lines to
form a network. RC NET is a packet switching network system by
which the host computers can communicate. A message from one host
to another is split up ino a number of data packets, which are
transmitted by the network. The main function of the nodes is to
keep track of the hosts currently connected and their location in
the network. The data packets are forwarded from node to node
until the node connected to the receiving host is reached.

Thus, performing the node-work, the RC 3600 routes information
according to destination and available line capacity.

In conjunction with the previously mentioned applications, the RC
3600s within the network concept interfaces many kinds of data
processing equipment, providing flexibility as well as opportuni-
ty for extensions.

With the RC 3600 System a vast number of jobs are solved easily,
effectively and reliably - at an optimum in cost and performance.
And, because of the interaction of hardware/softweare, the com-
ponents of any application system may be re-used, if upgrading or
otherwise re-constructing the current data processing facilities.\f

«eof»

DataMuseum.dk

CP/M

⟦dcc18dbec⟧ TextFile

Derivation

TextFile