⟦59eb16111⟧

TextFile

T_A_B_L_E_ _O_F_ _C_O_N_T_E_N_T_S_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _P_A_G_E_

1. INTRODUCTION ........................................... 1

2. GENERAL INFORMATION .................................... 2
2.1 Message Format .................................... 2
2.2 Answer Format ..................................... 3
2.3 Operating System Actions .......................... 3
2.4 How to Send Parent Messages ....................... 4

3. PARENT MESSAGES ........................................ 5
3.2 Finis ............................................. 5
3.4 Break ............................................. 6
3.6 Hard error ........................................ 8
3.8 Account ........................................... 9
3.10 Replace ........................................... 10
3.12 New job ........................................... 12
3.14 Mount tape ........................................ 14
3.16 Print ............................................. 16
3.18 Mount ring ........................................ 18
3.20 Suspend tape ...................................... 20
3.22 Release tape ...................................... 22
3.24 Load .............................................. 24
3.26 Change paper ...................................... 26
3.28 Timer ............................................. 28
3.30 Convert ........................................... 30
3.32 Mount special ..................................... 32
3.34 Mount kit ......................................... 34
3.36 Corelock .......................................... 36
3.38 Coreopen .......................................... 37
3.40 Remove ............................................ 38
3.42 Wait .............................................. 39
3.44 Function 44 ....................................... 40
3.46 Function 46 ....................................... 40
3.48 Function 48 ....................................... 40
3.50 Create link ....................................... 41

A_P_P_E_N_D_I_X_:

A. REFERENCES ......................................... 45
\f

ii
\f

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

In a multiprogramming environment there has to be an operating
system to control (or at least facilitate) the sharing of re-
sources between jobs. This again calls for the definition of a
language for communication between the jobs and the operating
system.

In the RC8000 Multiprogramming System (see ref. 11), a common
language has been defined for all operating systems. It is im-
plemented by means of m_e_s_s_a_g_e_s_ sent from the jobs (internal pro-
cesses) to the operating system (the p_a_r_e_n_t_).

Ref. 11 contains an introduction to the concept of messages as
a means of communication.

This manual describes the parent messages used. Chapter 2 con-
tains general information, and chapter 3 describes each of the
parent messages separately.

Please notice that the section numbering in chapter 3 follows the
numbering of the parent message functions (see 2.1), i.e. only
even numbers occur.
\f

F_ 2_._ _ _ _ _ _ _ _ _G_E_N_E_R_A_L_ _I_N_F_O_R_M_A_T_I_O_N_ 2.

2_._1_ _ _ _ _ _ _ _M_e_s_s_a_g_e_ _F_o_r_m_a_t_ 2.1

All parent messages consist of 8 words, like this:

m+0: function < 12 + pattern < 5 + wait
m+2: integer or text portion
m+4: integer or text portion
... until m+14

function specifies the operation to be performed. Only
even values are allowed.

pattern specifies how the message is to be displayed to
the operator. The pattern contains seven bits,
one to each of the words m+2 to m+14. A bit being
one means that the corresponding word contains an
integer, otherwise the word contains a text por-
tion of 3 characters (3 NULs denote a blind
word). Thus, e.g., bit 1 < 11 means that m+2 is
an integer, 1 < 5 that m+14 is an integer.

wait may be zero or one. A zero means that the job
wants the answer immediately, a one means that
the job wants the answer when the operation is
complete, (or when the operator answers the
message displayed.)

The notation used will be familiar to assembler programmers.
ALGOL programmers will need to know that m+0 is the first word of
the message, m+2 the second etc., and that, e.g. 1<5 means: 1
shift 5. Ref. 5 2.149 (system, example 5) contains an instruc-
tive example.

2_._2_ _ _ _ _ _ _ _A_n_s_w_e_r_ _F_o_r_m_a_t_ 2.2

The answer to a parent message is also 8 words but the format
depends on the operating system as well as on the message:

The operating system "s" unconditionally delivers an answer
containing an exact copy of the message sent.

The operating system system BOSS gives an answer as described for
each message in chapter 3. Where nothing is stated, the first 3
words of the answer will contain zeroes, and the last 5 words are
undefined.

2_._3_ _ _ _ _ _ _ _O_p_e_r_a_t_i_n_g_ _S_y_s_t_e_m_ _A_c_t_i_o_n_s_ 2.3

The Operating System s: The following description is adapted from
ref. 10 2.2:

When the operating system s receives a message from one of its
childs, the following is done:

a) If wait (see 2.1) equals 1, the child process is stopped, an
answer (see 2.2) is sent to the process and a message is
printed on the console, from which the process was created:

pause <processname><contents of message>

The operator can now start, break or remove the process,
depending on the function in the message.

b) If wait equals zero, the answer is sent to the process, and a
message is printed on the console from which the process was
created:

message <processname><contents of message>

These are the only actions taken for all parent messages
except 'finis' and 'replace', see 3.2 and 3.10.
\f

The Operating System BOSS: The actions of the operating system
BOSS are described separately for each parent message in chapter
3, but some common principles may be stated here:

Undefined parent messages are treated as described in 3.16.

The guiding texts, like <:finis:> etc. and actual value of
<pattern> (cf. 2.1) are ignored, except for 3.16, where they
are used to format the message displayed to the operator (very
much like the message displayed by s (see above).

BOSS always uses the main console as display, in contrast to
s, which uses the console from which the job was started.

BOSS often ignores the actual value of wait, but the values
shown should be used anyway. They have been carefully chosen
to ensure that a job may be executed under different operating
systems with as little change as possible.

2_._4_ _ _ _ _ _ _ _H_o_w_ _t_o_ _S_e_n_d_ _P_a_r_e_n_t_ _M_e_s_s_a_g_e_ 2.4

Most user's needs for sending parent messages are covered by the
IMPLITIC USE and the dedicated 'job control' UTILITY PROGRAMS
mentioned separately for each parent message in chapter 3.

If you have more specialized needs you may send any parent mes-
sage from a high-level program by means of the standard procedure
'system', see ref. 5 2.149, where example 5 contains an in-
structive example.

F_ 3_._ _ _ _ _ _ _ _ _P_A_R_E_N_T_ _M_E_S_S_A_G_E_S_ 3.

3_._2_ _ _ _ _ _ _ _F_i_n_i_s_ 3.2

m+0 2<12 + 16<5 + 1
M_m_m_ +2
<:finis _:>
P_p_p_ +4
+6 <param>

The job reports that it has finished in the normal way.
The operating system will terminate the job.

<param> is a bit pattern specifying special actions.
At present the following values are used:

<param> extract 1 = 0: print primary output
<param> extract 1 = 1: do not print primary output.

UTILITY PROGRAM: finis (see ref. 7) sends the message with wait
= 1 and pattern = 0. <param> is extended with the text <:fp:>
(left justified).

OPERATING SYSTEM ACTIONS:
s (only MONITOR release 7.0 and later): if WAIT=1 the job process
will be removed. See ref. 10 2.2.

BOSS: terminates the job like this:
remove links used by the job,
remove job process (cf. ref. 12 2.64),
terminate the use of jobcontrolled printer,
clean catalog (i.e. remove temporary entries left over by the
job),
terminate the use of jobcontrolled cardreader and tapereader,
release magnetic tapes and stations used by the job; make
scratch tapes public,
release operator requests concerning the job,
release unused resources,
maybe initiate the printing of primary output,
perform accounting for the job,
maybe start a 'replace'-job.

3_._4_ _ _ _ _ _ _ _ _ _ _B_r_e_a_k_ 3.4

m+0 4<12 + 0<5 + 0
M_m_m_ +2
<:break _:>
P_p_p_ +4

The job asks the operating system to perform the "dump and re-
start"-action (see below).

UTILITY PROGRAM: None.

IMPLICIT USE: This message is sent by all utility programs and by
all programs written in high-level languages as the last action
taken in response to an internal interrupt (a 'break'). High-
level language programs running without fp terminate by sending
this message, containing the end program text or an alarm text,
see ref. 4 10.3.2.2 and 10.3.6.2.

OPERATING SYSTEM ACTIONS:
BOSS handles the message, according to the previous history of
the job, as follows:

1) The interrupt was a parent break (break cause = 8) forced by
BOSS itself in order to a_b_o_r_t_ the job, e.g. as an error re-
action to one of the other parent messages, or because the job
had exceeded its run time, or because the job was killed by
the user or the operator.

2) The interrupt was a parent break (break cause = 8) forced by
BOSS but at the explicit request of the job (by means of the
parent message 3.28 "timer").

3) The interrupt was not a parent break.

4) No interrupt occurred at all.

In case (1) BOSS will terminate the job as described in subsec-
tion 3.2 (above).
\f

In case (2), (3) and (4) BOSS will perform the
"_d_u_m_p_ _a_n_d_ _r_e_s_t_a_r_t_"_-_a_c_t_i_o_n_:

The job process is stopped. If a backing storage file by the name
<:image:> is visible from the stdbase of the job and is within
the maxbase of the job, the job process will be dumped in the
file, and 'contents' in the file descriptor will be changed to 7
("dumped process"). Then the job process will be removed and
created again with claims and user rights (to peripherals) exact-
ly as before the removal. Next, <:fp:> is loaded (from system
base) and initalized to continue reading/writing at the current
position of the jobfile/primary output file.

FURTHER INFORMATION: Internal interrupts are described in ref.
11 8.1 and in ref. 12 1.2.

The actions of the standard interrupt handling routine are de-
scribed in ref. 6 3.5 (together with an explanation of the
break causes possible), and in ref. 8 4.2.

In ALGOL (release 8.0 and later releases) you may program your
own non-standard interrupt handling actions by means of the
standard identifiers 'alarmcause' and 'trapmode' and the standard
procedure 'trap'. This is described in ref. 5 2.5, 2.153
(especially notice example 2) and 2.154.

3_._6_ _ _ _ _ _ _ _H_a_r_d_ _e_r_r_o_r_ 3.6

m+0 6<12 + 16<5 + 0
M_m_m_ +2
<:status:>
P_p_p_ +4
+6 <logical status word>
+8
M_m_m_ +10
<name of device or area>
P_p_p_ +12
+14

The job reports that it has detected a hard error on a peripheral
device or a backing storage area.

ANSWER: See 3.16.

UTILITY PROGRAM: None

IMPLICIT USE: This message is sent by all utility programs if
they terminate because of hard error on a file. See ref. 6 6.4
and 4.5.

OPERATING SYSTEM ACTIONS: Handled as 3.16.

FURTHER INFORMATION: The format of the <logical status word> is
described in ref. 6 6.4.

3_._8_ _ _ _ _ _ _ _A_c_c_o_u_n_t_ 3.8

m+0 8<12 + 15<5 + 0
+2
+4 <:account _:>
+6
+8 <param 3>
+10 <param 4>
+12 <param 1> (account kind, must be > = 100)
+14 <param 2>

The job wants to generate a special record on the system account
file.

UTILITY PROGRAM: account (ref. 7). The numbering of the para-
meters follows the natural numbering of the parameters for the
utility program 'account'.

PREREQUISITES:
BOSS: Each use of this message costs an 'account', which must be
ordered when the job is started; see ref. 3 3.3.

ERROR REACTIONS:
BOSS: If the job has no more accounts left, the job will be
aborted.

FURTHER INFORMATION: ref. 1 chapter 6 is a detailed description
of the accounting system in BOSS2.

3_._1_0_ _ _ _ _ _ _R_e_p_l_a_c_e_ 3.10

m+0 10<12 + 16<5 + 1
M_m_m_ +2
<:finis _:>
P_p_p_ +4
+6 <param>
+8
M_m_m_ +10
<name of replacement job file>
P_p_p_ +12
+14

The job specifies a replacement job.

ANSWER (BOSS): The value of the first word of the answer signals
the result:
0: ok
1: not ok (replace not accepted from online job)

UTILITY PROGRAM: replace (ref. 7).

PREREQUISITES (BOSS): The file containing the replacement job
must be permanent. The sending job must not be an online job (go
or run).
\f

OPERATING SYSTEM ACTIONS:
s (only MONITOR release 7.0 and later): if WAIT = 1, s will re-
move the sending process immediately and start reading from the
replacement job file (which is thus supposed to contain s-com-
mands). See further ref. 10 2.2 and the 'read'-command, ref.
10 1.6.

BOSS: The information from the message is stored to be used when
the sending job eventually finishes. A replace message cancels
previously sent replace messages. The existence and the contents
of the replace job file is not checked before the replacement is
actually carried out. The replacement will be carried out even if
the sending job is aborted (e.g. because of 'time exceeded), ex-
cept if the job is killed by the operator.

If <param> = -1 (all ones) the message cancels any previously
sent replace-message (without specifying a new replacement job).

Otherwise <param> is treated as a bitpattern with the meaning:
<param> extract 1 = 0: take username, userindex and project
number from the sending job.
<param> extract 1 = 1: take username, userindex and project
number from the replacement job file.

ERROR REACTIONS: see ANSWER.

FURTHER INFORMATION: Notice the difference between how s and BOSS
handle the message.

3_._1_2_ _ _ _ _ _ _N_e_w_ _j_o_b_ 3.12

m+0 12<12 + 0<5 + 0
+2 <:job:>
M_m_m_ +4
<printerspec>
P_p_p_ +6
+8
M_m_m_ +10
<name of the job file>
P_p_p_ +12
+14

The job specifies a jobfile to be enrolled for execution.

ANSWER (BOSS): the first word of the answer signals the result:
0: ok (job file accepted, new job enrolled)
1: job queue full
2: file not permanent
3: file does not exist
5: file unreadable
7: user index too large
8: illegal identification
9: user index conflict
11: file too long
19: attention status at remote terminal
20: device unknown
21: device not printer
22: parent device disconnected
38: option unknown
39: param at job
40: syntax at job
41: line too long

UTILITY PROGRAM: newjob (ref. 7), bossjob (ref. 7), remotejob
(ref. 13). Concerning bossjob and remotejob, see FURTHER IN-
FORMATION (below).

PREREQUISITES (BOSS): The job file of the new job must be perma-
nent, and it must be visible from the standard base of the sen-
ding job.
\f

OPERATING SYSTEM ACTIONS:
BOSS: The job file, the printer, and the job specification in the
job file is checked and the result is signalled in the answer. If
the result is 'ok', the new job is enrolled for execution and
will continue independently of (and maybe in parallel with) the
sending job.

<printerspec> specifies where primary output from the job is to
be printed, and is used as default value for printer specifica-
tion in converts from the new job. The interpretation is:

0, 0: printer specification is taken from the job which sends
the newjob message. If this job is a process running in
parallel with Boss, printerspec = 0, 0 works as
<:std:>, 0 (see below).
<:std:>, 0: standard printer is used.
anything else: <printerspec> is taken to be the name of a file
descriptor or the name of a device in a device con-
troller, and is interpreted as shown in ref. 3, sec-
tion 7.2. The text in <printerspec> need not be termi-
nated by the usual NULL-character, so a maximum length
of 6 characters is possible.

ERROR REACTIONS: see ANSWER (above).

FURTHER INFORMATION: This message may not only be used as a pa-
rent message. BOSS accepts such messages from any internal pro-
cess. If you want to enroll a job for execution under BOSS from a
process running in parallel with BOSS, use the utility program
'bossjob'. 'bossjob' works like 'newjob' except that the message
is sent explicitly to <:boss:> (instead of "the parent").

The utility program 'remotejob' even makes it possible to enroll
a job for execution under a boss-process running in another
RC8000 jobhost, but this presupposes that the job hosts are in-
terconnected via a Disc to Disc File Router Interface (a DDFR-
FDLC link), see ref. 13.

3_._1_4_ _ _ _ _ _ _M_o_u_n_t_ _t_a_p_e_ 3.14

m+0: 14<12 + 0<5 + wait
+2
+4 <:mount _:>
+6
+8
M_m_m_ +10
<tapename>
P_p_p_ +12
+14

The job requests a magnetic tape to be mounted. The message may
be used both with and without wait indication:
wait = 0 means that the job does not want to wait,
wait = 1 means that the job wants to wait until the tape has
been mounted.

ANSWER (BOSS): If wait = 1 and tapename = <::>, the job asks for
a 'work tape' (see ref. 5 2.130 (setposition, start position-
ing)). In this case, the name of the tape actually used is re-
turned in the first 4 words of the answer. This name must be used
in future references to the tape.

UTILITY PROGRAM: mount (ref. 7).

IMPLICIT USE: This message may be sent by all data handling uti-
lity programs when input or output is on magnetic tape. Where
magnetic tapes are handled in high-level languages, the message
may be sent (with wait = 0) by 'open' and (with wait = 1) by
'setposition' or when a data transfer is checked. In all cases
the rule is that the message is only sent if the tape is not
already available.

PREREQUISITES (BOSS): The first mount-message concerning a cer-
tain tape costs a 'mount', which must be ordered when the job is
started, see ref. 3 3.1. Subsequent mount-messages concerning
the same tape are free, as long as the tape has not been 're-
leased' (see 3.22) or 'suspended' (see 3.20) by the job. Further-
more you have to order a 'station' or a 'special tape station'
(by means of 'stat' or 'device', respectively) for each simul-
taneously mounted tape, see ref. 3 3.1.
\f

OPERATING SYSTEM ACTIONS:
BOSS: It is first checked, that the job has ordered a 'station'
or a 'special station' for the tape. If the tape is not already
mounted, and the operator has not already been asked to mount the
tape, a request for the tape is issued.

If wait = 1, the job will be stopped and swapped out until the
tape is mounted, possibly on a specific station (if this was
previously ordered with 'mount special' (see 3.32)).

Next the job is included as a user of that device (peripheral
process), where the tape is actually mounted, swapped in and
started again.

The tape is now registered as being presently used by ('assigned
to') the job, until the job either finishes, suspends the tape
(3.20) or releases the tape (3.22). If the tape was not previ-
ously registered with connection to a special station (see 3.22)
it will be registered as "standard".

ERROR REACTIONS (BOSS): The job will be aborted if:
the tape is reserved for another project
'stations' would be exceeded, or
the tape is being used by another job.

FURTHER INFORMATION: Use of magnetic tapes in BOSS is described
in ref. 3 6.1, and in ref. 14 chapter 5. The handling of mag-
netic tape mounting in utility programs is described under the
heading "kind = 18" in ref. 6 6.2 and 6.5. The handling of mag-
netic tape mounting in high-level languages are described in ref.
4 2.3.3.1 (Details of Handling of Device Status, Magnetic tape,
Does not exist), ref. 5 2.95 (Open, Initialization of a Docu-
ment, Magnetic Tape and example 2) and in ref. 5 2.130 (Setpo-
sition, Start Positioning and example 3).

3_._1_6_ _ _ _ _ _ _P_r_i_n_t_ 3.16

m+0 16<12 + pattern <5 + wait

This message provides for flexible communication with the ope-
rator for purposes which are not covered by the other parent
messages.

Pattern may be anything and the message may be sent with or
without wait-indication.

ANSWER (BOSS): If wait = 1, the first 4 words of the answer will
contain the textword from the operator answer and the last word
will contain the integer from the operator answer. If one (or
both) is missing in the operator answer, it (they) will be re-
placed by NULL's.

UTILITY PROGRAM:
opmess sends the message with wait = 0.
opcomm sends the message with wait = 1.
Both are described in ref. 7.

IMPLICIT USE: The standard procedure 'open' (and all data hand-
ling utility programs) will send a 'print'-message with the
text:
wait for <name of document>
and wait = 0, during the initialization of a reader or card-
reader if the device is reserved by another job. Open then waits
(busy waiting) until the device is free. See ref. 5 2.95 (Open,
Initialization of a document), and ref. 6 6.2 (Connection of a
file, kind 10 and 12).
\f

OPERATING SYSTEM ACTIONS:
s: handles the message in the standard way. Notice: this implies
that the operator can not supply an answer.
BOSS: displays the message to the operator. If wait = 1, the job
will be stopped and swapped out until the operator answers the
message displayed. The operator may add a textword (max. 11
chars) and/or an integer to the answer-command. (see ref. 4
chapter 3 ('answer'-command)).

These will be returned in the answer to the message, see ANSWER
(above).

FURTHER INFORMATION: Notice, that there is a version of the stan-
dard procedure 'system', especially designed to send this message
with pure text as contents (see ref. 5 2.149 system(10, i,s)).

3_._1_8_ _ _ _ _ _ _M_o_u_n_t_ _r_i_n_g_ 3.18

m+0 18<12 + 0<5 + 1
+2
+4 <:ring _:>
+6
+8
M_m_m_ +10
<tape name>
P_p_p_ +12
+14

The job demands a write-enable ring on the tape.

ANSWER (BOSS): If the tape is already "known" to BOSS one way or
another, the first 4 words of the answer contain the tapename and
the last 4 words are undefined. Otherwise the answer is unde-
fined.

UTILITY PROGRAM: Ring (ref. 7).

IMPLICIT USE: This message may be sent by all data handling
utility programs making output to magnetic tape. Where magnetic
tapes are handled in high-level languages, the message may be
sent when a data transfer (output) is checked, see ref. 4
2.3.3.1 (Details of Handling of Device Status, Magnetic tape,
Stopped).

PREREQUISITES (BOSS): If the message is to have any effect, the
tape must previously have been requested by means of 'mount tape'
or 'mount special' (with wait = 1, see 3.14 and 3.32), and not
later suspended (see 3.20) or released (see 3.22).
\f

OPERATING SYSTEM ACTIONS:
BOSS: The message may have no effect, as described above. The
message also has no effect if the tape is actually already
mounted and h_a_s_ a write-enable ring.

Otherwise, the job is first excluded as a user of the device
(peripheral process), where the tape is mounted. Then the job
process is stopped and swapped out, the tape is unloaded and the
operator is asked to mount the tape again, w_i_t_h_ a write-enable
ring, possibly on a specific station (if this was previously
ordered by means of 'mount special (see 3.22)).

When the operator has mounted the tape again the job will be
included as a user of that device where the tape is actually
mounted, swapped in and started again.

Please notice that BOSS does n_o_t_ check whether the operator
actually did mount the ring when he remounted the tape.

BOSS ignores the value of wait.

ERROR REACTIONS (BOSS): The job will be aborted if the tape is
presently being used by ('assigned to', see 3.14) another job, or
if the sending job is not permitted to use that particular tape
with a ring, see ref. 3 6.1.2 (access code).

FURTHER INFORMATION: See the other messages concerning magnetic
tapes: 3.14, 3.20, 3.22 and 3.32.

3_._2_0_ _ _ _ _ _ _S_u_s_p_e_n_d_ _t_a_p_e_ 3.20

m+0 20<12 + 0<5 + 0
+2
+4 <:suspend _:>
+6
+8
M_m_m_ +10
<tape name>
P_p_p_ +12
+14

The job releases the s_t_a_t_i_o_n_ on which the tape is mounted, but
warns that the tape may be needed again later.

ANSWER (BOSS): As for 3.18 'mount ring'.

UTILITY PROGRAM: suspend (see ref. 7).

IMPLICIT USE: Where magnetic tapes and flexible discs are handled
in high-level languages, this message will be sent when the stan-
dard procedure 'close' is called like this: close(z,true), see
ref. 5 2.25 (close) and ref. 15 3.6 (Releasing a Flexible
Disc).

PREREQUISITES (BOSS): A suspend message concerning a 'work tape'
(see ref. 5 2.130 (setposition, start positioning)) costs a
'suspend', which must be ordred when the job is started, see ref.
3 3.3.
\f

OPERATING SYSTEM ACTIONS (BOSS): The message has no effect if the
tape is not registered as being used by ('assigned to') the job.

Otherwise BOSS will do as follows (if relevant):
exclude job as user of the tape station,
std.station: becomes a "free" station,
std.station: decrease 'stations' used by one,
cancel operator requests concerning the tape,
work tape: increase 'suspends' used by one,
rewind the tape.

Notice, that the assignment of the tape to the job is not can-
celled, neither is the station connection ('std' or 'special').

The tape may later be unloaded by BOSS or by the operator if the
station is needed for another tape.

ERROR REACTIONS (BOSS): The job will be aborted if the tape is a
work tape, and the job has no 'suspends' left.

FURTHER INFORMATION: Please notice that utility programs general-
ly do n_o_t_ suspend or release tapes (see ref. 6 6.3). The ad-
vantage is that a tape may be left correctly positioned for the
next program, but then, if the tape is actually no longer needed,
or the station is to be used for another tape, you have to call
one of the programs 'suspend' or 'release' (ref. 7).

3_._2_2_ _ _ _ _ _ _R_e_l_e_a_s_e_ _t_a_p_e_ 3.22

m+0 22<12 + 0<5 + 0
+2
+4 <:release _:>
+6
+8
M_m_m_ +10
<tape name>
P_p_p_ +12
+14

The job releases the tape and the station on which it is mounted.
If the tape is a work tape, it becomes public.

ANSWER (BOSS): As for 3.18 'mount ring'.

UTILITY PROGRAM: release (see ref. 7).

IMPLICIT USE: As for 3.20 'suspend tape' except that the call of
'close' must be:
close (z, false add 1).

PREREQUISITES: None.
\f

OPERATING SYSTEM ACTIONS (BOSS): The message has no effect if the
tape is not registered as being used by (assigned to) the job.
Otherwise BOSS will do as follows (if relevant):
If the tape was not already suspended (see 3.20):
exclude job as user of the tape station,
std. station: becomes a "free" station,
std.station: decrease 'stations' used by one,
cancel operator requests concerning the tape.
Suspended work tape:
decrease 'suspends' used by one
In all cases:
cancel the assignment of the tape to the job (this makes a
work tape public) and the station connection (std/special),
rewind the tape.

The tape may later be unloaded by BOSS or by the operator if the
station is needed for another tape.

ERROR REACTIONS: None.

FURTHER INFORMATION: As for 3.20, except that the utility pro-
grams 'save' and 'load', and the utility programs for flexible
disc handling may send 'release' messages, see ref. 7 and ref.
15.

3_._2_4_ _ _ _ _ _ _L_o_a_d_ 3.24

m+0 24<12 + 0<5 + 0
M_m_m_ +2
<:load _:>
P_p_p_ +4

+8
M_m_m_ +10
<reader name>
P_p_p_ +12
+14

The job requests the loading of a new tape in a paper tape reader
or a new deck of cards in a card reader.

UTILITY PROGRAM: None.

IMPLICIT USE: The standard procedure 'open' (and all data hand-
ling utility programs) will send this message during the initi-
alization of a paper tape reader or cardreader, and then wait
(busy waiting) until the first non-empty data block is received
from the device. See ref. 5 2.95 (Open, Initialization of a
Document) and ref. 6 6.2 (connection of a file, kind 10 and
12).

PREREQUISITES (BOSS): The use of paper tape reader and card
reader from a BOSS job is usually handled as 'job controlled
reading', and permission to use this facility must be ordered
when the job is started. A full description is given in ref. 3
6.3 (Tape Reader) and 6.4 (Card Reader).
\f

OPERATING SYSTEM ACTIONS:

s: notice that the normal implicit use has the effect that the
job continues by itself as soon as the operator loads the reader
in question.

BOSS: If <reader name> is not the name of a 'job controlled
reader' (cf. PREREQUISITES), the message will be handled as
described for 3.16.

Otherwise, the job will be stopped and swapped out while BOSS
initializes the reading and instructs the operator. When the
reader becomes ready the job will again be swapped in and allowed
to continue.

3_._2_6_ _ _ _ _ _ _C_h_a_n_g_e_ _p_a_p_e_r_ 3.26

m+0 26<12 + 16<5 + 1
M_m_m_ +2
<:change:>
P_p_p_ +4
+6 <paper type>
+8
M_m_m_ +10
<device name>
P_p_p_ +12
+14

The job demands new paper in a device, usually a printer or a
punch.

ANSWER (BOSS): If <device name> = <:printer:>, the first word of
the answer signals the result:
0 : ok, message accepted.
2 : message rejected, job controlled printing not ordered (cf.
PREREQUISITES).

Otherwise the answer is as described for 3.16.

UTILITY PROGRAM: change (see ref. 7).

IMPLICIT USE: This message may be sent by all data handling uti-
lity programs and by programs written in high-level languages
when printer or punch is used, see ref. 6 6.5 (Standard Re-
covery Actions, kind 12 and 14) and ref. 5 2.3.3.1 (Details of
Handling of Device Status, kind 12 and 14).

PREREQUISITES (BOSS): The use of a printer from a BOSS job is
called job controlled printing, and permission to use this fa-
cility must be ordered when the job is started. A full descrip-
tion is given in ref. 3 6.2 (Printer). The use of a punch must
be ordered by means of 'device', see ref. 3 3.1.
\f

OPERATING SYSTEM ACTIONS (BOSS): If <device name> = <:printer,
the job will be stopped and swapped out until the operator has
changed the paper. Then the job is swapped in again and allowed
to proceed.

Otherwise, the message is handled as described for 3.16.

ERROR REACTIONS (BOSS): See ANSWER.

3_._2_8_ _ _ _ _ _ _T_i_m_e_r_ 3.28

m+0 28<12 + 3<5 + 0
M_m_m_ +2
<:timer _:>
P_p_p_ +4

+12 <time1>: seconds to the interrupt
+14 <time2>: seconds allowed the job to respond to the
interrupt.

The job requests a 'parent break' when <time1> seconds have
elapsed, and then to be given a respite of a further period of
<time2> seconds to respond to the break.

The message may be used to make sure that a program does not use
an unreasonable amount of computer time. It is especially useful
during debugging, where a program may enter an endless loop.

A new 'timer' message cancels previously sent 'timer' messages.

UTILITY PROGRAM: timer (see ref. 7).
\f

OPERATING SYSTEM ACTIONS (BOSS): When <time1> seconds have
elapsed, BOSS executes the 'parent break':
stop job,
store registers and instruction counter at the interrupt
address of the job,
set 'break cause' = 8 (parent break),
restart the job in its 'interrupt handling routine'.
The job is now expected to respond by sending a 'break' message
(see 3.4), which will cause BOSS to perform the 'dump and re-
start' action as described in 3.4. The job may also respond by
sending a new 'timer' message, which will then cancel the present
'timer' message.

If, however, the job does not respond to the 'parent break' be-
fore <time2> seconds have elapsed, BOSS will perform the 'dump
and restart' action described in 3.4 as if the 'break' message
had been received - with one minor addition: when the process has
been stopped, BOSS will store the present values of registers and
instruction counter to replace the values stored by the 'parent
break' (because there is obviously an error in the interrupt
handling routine of the job, and the new values may help to find
it).

ERROR REACTIONS (BOSS): The job will be aborted if its interrupt
address is undefined.

FURTHER INFORMATION: See 3.4. BOSS: The elapsed time will be
measured in 'real', physical time as on your own grandfather
clock, except that time spent swapped out is not counted.

3_._3_0_ _ _ _ _ _ _C_o_n_v_e_r_t_ 3.30

m+0 30<12 + 16<5 + 0
M_m_m_ +2
<printerspec>
P_p_p_ +4
+6 <paper type>
+8
M_m_m_ +10
<file name>
P_p_p_ +12
+14

The job reports that it wants to have a file printed on a certain
line printer.

The interpretation of <printerspec> is the same as for 'newjob'
(see 3.12), except that 0, 0 must be replaced with the text
<:conv:>. This text is inserted by the utility program 'convert'
(see ref. 7), if it is called without a printer-parameter.

ANSWER (BOSS): The first word of the answer signals the result:
0: ok, convert accepted
1: cbufs exceeded
2: file does not exist
3: file has wrong scope
4: temporary resources insufficient
5: file in use
6: file is not a backing storage area
7: file is no text file (contents key is not 0)
19: attention status at remote terminal
20: device unknown
21: device not printer
22: parent device disconnected

UTILITY PROGRAM: convert (see ref. 7).
\f

PREREQUISITES (BOSS): Each convert costs a 'cbuf' which must be
ordered when the job is started, see ref. 3 3.3. As the default
value is rather high (8), there is normally no need to bother
about this.

The file must either be a permanent file (on any backing storage
device) or a temporary file on the system disc (the backing
storage named <:disc:>).

OPERATING SYSTEM ACTIONS (BOSS): If the message is accepted (see
ANSWER), the request will queued up for execution when its turn
comes. If the file is temporary it will be taken over by BOSS,
i.e. the job will no longer be able to see the file, and the re-
sources (the segments and the catalog entry) used to create the
file will not be given back to the job.

ERROR REACTIONS (BOSS): The job will be aborted if it has no
'cbufs' left (cf. PREREQUISITES). See also ANSWER.

FURTHER INFORMATION: As BOSS prints directly from the file if it
is permanent, you should avoid using, changing or removing it
before your are positively certain that BOSS has finished the
printing. Please notice the contrast between this, and the online
command 'convert' which always makes a copy of the file and
prints from the copy. Please also notice, that you can not use
this message to convert a 'login' file.

There is a detailed example on how to send this message from an
ALGOL program, in ref. 5 2.149 (system, example 5).

3_._3_2_ _ _ _ _ _ _M_o_u_n_t_ _s_p_e_c_i_a_l_ 3.32

m+0 32<12 + 16<5 + wait
M_m_m_ +2
<:mount _:>
P_p_p_ +4
+6 <device number>
+8
M_m_m_ +10
<tape name>
P_p_p_ +12
+14

The job wants a magnetic tape to be mounted on a specific tape
station. The message may be used with or without wait-indication,
but it is normally used without.

ANSWER: As for 'mount tape' (see 3.14).

UTILITY PROGRAM: 'mountspec' (sends the message with wait = 0
see ref. 7).

IMPLICIT USE: The utility programs 'save' and 'load' will send
this message as required, if they are called with the parameter
'mountspec'.

PREREQUISITES (BOSS): The tape station in question must have been
ordered when the job was started. This is done by means of 'de-
vice', see ref. 3 3.1. The tape must not be registered as being
used by (assigned to) another job, or by the sending job on a
standard station or a different device. The message may cost a
'mount' as described in the prerequisites for 3.14.
\f

OPERATING SYSTEM ACTIONS (BOSS): As for 3.14 (mount tape), except
that the tape will be registered with connection to the special
tape station in question. This has the effect, that operator re-
quests concerning the tape will automatically include the device
number, even if you later on use 'mount tape' messages instead of
'mount special' messages. This connection will be cancelled by
'release' (see 3.22) but not by 'suspend' (see 3.20).

ERROR REACTIONS (BOSS): The job will be aborted if the prere-
quisites are not fulfilled:
not special station
station not ordered
tape used by other job
mount special after mount (the tape was already connected as
'std').

FURTHER INFORMATION: See the other messages concerning magnetic
tape (3.18, 3.20, 3.22 and especially 3.14).

The usual use of this message is, that if you want to have a tape
mounted on a special station, you only call the utility program
'mountspec' before the first mounting of the tape, and then again
each time the tape has been 'released'. But notice that utility
programs generally do not 'release' tapes, see 3.20.

3_._3_4_ _ _ _ _ _ _M_o_u_n_t_ _k_i_t_ 3.34

m+0 34<12 + 16<5 + wait
M_m_m_ +2
<:kit:>
P_p_p_ +4
+6 <device number> (logical backing storage device)
+8
M_m_m_ +10
<disc pack name> (logical backing storage)
P_p_p_ +12
+14

The job wants to have the disc pack mentioned mounted on the disc
drive specified. The message may be used with or without wait-
indication, but it is normally used with wait = 1.

ANSWER (BOSS): If wait = 0, the first word of the answer signals
the result like this:
0: ok (message printed)
1: job is not a user of the disc pack
2: device was not ordered at jobstart
3: device unknown or not a logical backing storage device.

If wait = 1, first look at the first word of the answer. If it is
1, 2 or 3, the meaning is as above. Otherwise look at the second
word: if the value is 11, the request has been fulfilled. If the
second word is not 11, the job was started before the request was
carried through, and the answer must be interpreted as an opera-
tor answer (see 3.16).

UTILITY PROGRAM: kit (see ref. 7).

IMPLITIC USE: None.
\f

PREREQUISITES (BOSS): The device in question must be a logical
backing storage device, and it must have been ordered (by means
of 'device', see ref. 3 3.1) when the job started. This im-
plies, that the disc pack in question must be formatted as a
logical backing storage, and it must be stated in the user cata-
log, that the job may use it as a private kit (usercat input type
= 4, see ref. a 6.3.4 Private kits). Furthermore, if the job
wants to be given resources on the logical backing storage in
question when it becomes available, this must also be ordered
when the job is started (by means of 'perm', see ref. 3 3.1).

OPERATING SYSTEM ACTIONS (BOSS): When it has been checked, that
the prerequisites are fulfilled, the message will be passed on
and handled as exactly as if it were a 'print' message (see
3.16), i.e. the message will be displayed on the operator console
and if wait = 1, the job will be stopped and swapped out.

If the operator knows that the disc pack is already mounted and
ready, he may just send an operator answer to the job (see 3.16).
Otherwise he is expected to carry out the mounting as described
in ref. 14 chapter 4.

When this mounting is completed, BOSS will include the job as a
user of the device, give it resources (according to what was
ordered at jobstart), allow it to proceed and send an answer
(with second word = 11, see ANSWER).

Incidentally, if there are other active jobs which have ordered
resources on the backing storage in question, they will at the
same time be given the resources ordered.

ERROR REACTIONS (BOSS): see ANSWER.

FURTHER INFORMATION: See ref. 3 5.3 and ref. 14 chapter 4.

3_._3_6_ _ _ _ _ _ _C_o_r_e_l_o_c_k_ 3.36

m+0 36<12 + 2<5 + 0
+2
+4 <:corelock _:>
+6

+12 <number of seconds in the period>

The job requests not to be interrupted, stopped or swapped out
for a certain period of time.

UTILITY PROGRAM: corelock (see ref. 7).

IMPLICIT USE: None.

PREREQUISITES (BOSS): The permission to use this facility, and
the maximum duration of the period must be ordered at jobstart,
and the permission must also be stated in the user catalog.

OPERATING SYSTEM ACTIONS (BOSS): If the request fulfils the pre-
requisites, the job will be locked in core, as if the job had
infinitely high priority, for as many seconds as stated in the
message. BOSS now expects to receive a 'coreopen' message (see
3.38) from the job before the stated period of time is over. When
the message is received, the job resumes normal priority and
proceeds.

If, however, no such message is received the job will be aborted.

ERROR REACTIONS (BOSS): The job will be aborted if:
corelock is not allowed,
corelock time is exceeded (coreopen not received).

FURTHER INFORMATION: See ref. 3 6.7.3.

3_._3_8_ _ _ _ _ _ _C_o_r_e_o_p_e_n_ 3.38

m+0 38<12 + 0<5 + 0
+2
+4 <:coreopen:>
+6

This message is only used in connection with 'corelock', see the
description in 3.36.

UTILITY PROGRAM: coreopen (see ref. 7).

IMPLICIT USE: None.

PREREQUISITES: None.

ERROR REACTIONS: None.

OPERATING SYSTEM ACTIONS (BOSS): The message has no effect,
except when used in connection with 'corelock', see 3.36.

3_._4_0_ _ _ _ _ _ _R_e_m_o_v_e_ 3.40

m+0 40<12 + 0<5 + 0
+2
+4 <:remove _:>
+6
+8
M_m_m_ +10
<file name>
P_p_p_ +12
+14

This message is not used as a parent message.

It may be used to transfer backing storage resources to BOSS from
a job running in parallel with BOSS.

ANSWER (BOSS): The message will be rejected (result = 2) if the
prerequisites are not fulfilled.

UTILITY PROGRAM: None.

IMPLICIT USE: None.

PREREQUISITES (BOSS): The file must be either a non-area entry or
a temporary file on the system disc (the logical backing storage
with the name <:disc:>), and it must be visible from the standard
base of the sending job.

OPERATING SYSTEM ACTIONS (BOSS): BOSS will remove the entry, and
thus, of course, increase its own claims. The resources gained
will be made available to jobs.

ERROR REACTIONS (BOSS): See ANSWER.

3_._4_2_ _ _ _ _ _ _W_a_i_t_ 3.42

m+0 42<12 + 16<5 + 1
M_m_m_ +2
<:wait _:>
P_p_p_ +4
+6 <number of seconds in the period>

The job wants to be stopped for some time.

UTILITY PROGRAM: None.

IMPLICIT USE: None.

PREREQUISITES (BOSS): The permission to use this facility, and
the maximum duration of the period must be ordred at jobstart. If
you want to be able to wait for more than one hour (3600 secs.),
this must also be stated in the user catalog.

OPERATING SYSTEM ACTIONS (BOSS): If the request fulfils the pre-
requisites, the job will be stopped and swapped out.

When the waiting time expires, the job will be swapped in again
and allowed to run with a very high (virtually infinite) priority
for the next few seconds. After that normal priority is resumed.

The operator may terminate the waiting at any time by means of
the 'answer' command (cf. 3.16).

ERROR REACTIONS (BOSS): The job will be aborted, if the prere-
quisites are not fulfilled.

FURTHER INFORMATION: This facility may be used to execute a task
with regular intervals, f.ex. like this: first the job sends a
wait-message. Then it executes its task, sends a message request-
ing to be replaced by the same job (see 3.10) and finishes. See
also ref. 3 6.7.4.

3_._4_4_ _ _ _ _ _ _F_u_n_c_t_i_o_n_ _4_4_ 3.44

Not used at present. Will be treated as 3.16.

3_._4_6_ _ _ _ _ _ _F_u_n_c_t_i_o_n_ _4_6_ 3.46

Not used at present. Will be treated as 3.16.

3_._4_8_ _ _ _ _ _ _F_u_n_c_t_i_o_n_ _4_8_ 3.48

Not used at present. Will be treated as 3.16.

3_._5_0_ _ _ _ _ _ _C_r_e_a_t_e_ _l_i_n_k_ 3.50

m+0 50<12 + 7<5 + 1
+2
M_m_m_ +4
<devname> (in devicehost)
P_p_p_ +6
+8
+10 <kind> < 12 + <subhostno> (at jobhost)
+12 <hostid> (devicehost)
+14 <homereg> < 12 + <netid>

The job requests the creation of a temporary (remote) link.

A special version of this message is used for TELEX devices (see
ref. 2 3.5)

<devname> is the name of the device (in the devicehost), which
the link is to connect.

<subhostno> and <hostid> identify the endpoints of the link.

<homereg> and <netid> are not used at present, but both should be
zero.
\f

ANSWER (BOSS): The result of the operation is returned in the
first word of the answer:
bit 0-7 : device status (8 single bits)
bit 8-11: link description (4-bit number)
bit 12-23: function result (12-bit signed number).

function result:
-1 : sender stopped.
0 : o_k_,_ _w_o_r_d_ _2_-_5_ _o_f_ _a_n_s_w_e_r_ _c_o_n_t_a_i_n_s_ _t_h_e_ _n_a_m_e_ _o_f_ _t_h_e_ _l_i_n_k_
p_r_o_c_e_s_s_ _c_r_e_a_t_e_d_.
1 : device troubles (see 'device status').
2 : device reserved by other host.
3 : no resources at jobhost.
4 : no resources at devicehost.
5 : timeout.
6 : device requested with higher priority.
7 : some link was already present (see 'link description').
8 : device host unknown.

The following function results originate from BOSS:
9 : job cannot be included as user of the device.
10 : links exceeded.

link description:
0 : no link present.
1 : remote link present.
2 : local link present.

device status (relevant only if function result = 1):
bit 0 : device unknown.
- 1 : device closed.
- 2 :
- 3 :
- 4 :
- 5 : device driver not loaded.
- 6 : device reserved by another process.
- 7 : reservation rejected.
\f

UTILITY PROGRAM: None.

IMPLICIT USE: None.

PREREQUISITES (BOSS): Each message costs a 'link' which must be
ordered when the job is started, see ref. 3 3.3.

OPERATING SYSTEM ACTIONS (BOSS): The sending process will be
stopped and swapped out while BOSS tries to create the link. Then
the job is swapped in again, allowed to proceed and given the
answer.

If the link creation was succesful, 'links' available for the job
will be decreased by one.

ERROR REACTIONS (BOSS): The job will be aborted, if it has no
more 'links' left.

FURTHER INFORMATION: The description given here presupposes a
knowledge of the concept of links corresponding to that given in
ref. 17 chapters 1 and 2. See also ref. 3 6.7.1.1, and con-
cerning telex links, ref. 2 (especially section 3.5).

F_
\f

F_ A_._ _ _ _ _ _ _ _ _R_E_F_E_R_E_N_C_E_S_ A.

1 RCSL No 31-D628:
BOSS2 Installation and Maintenance Manual

2 RCSL No 31-D474:
The TELEX facilities at MOT

3 RCSL No 42-i1265:
BOSS2 User's Manual

4 RCLS No 42-i0781:
ALGOL7 User's Manual, Part 1

5 RCSL No 42-i1278:
ALGOL8 User's Guide, Part 2

6 RCSL No 31-D364:
SYSTEM 3 UTILITY PROGRAMS, Part One

7 RCSL No 31-D590:
SYSTEM 3 UTILITY PROGRAMS, Part Two

8 RCSL No 31-D379:
SYSTEM 3 UTILITY PROGRAMS, Part Three

9 RCSL No 31-D552:
RC8000 OPERATING SYSTEMS: INTRODUCTION

10 RCSL No 31-D643:
OPERATING SYSTEM s, Reference Manual

11 RCSL No 31-D476:
RC8000 MONITOR, Part 1, System Design

12 RCSL No 31-D477:
RC8000 MONITOR, Part 2, Reference Manual
\f

13 RCSL No 31-D625:
Remotejob Utility Program

14 RCSL No 31-D498:
BOSS2 Operator's Manual

15 RCSL No 31-D459:
Flexible Disc Handling within the ALGOL System,
User's Manual

16 RCSL No 31-D596:
Utility Programs for Flexible Disc Handling

17 RCSL No 31-D557:
CREATELINK, RELEASELINK, LOOKUPLINK, LOOKUPDEV
Utility programs
\f

F_ INDHOLDSFORTEGNELSE

1 INTRODUKTIONpage 5

2 RC 8000 MASKINEL6
2.1 Centralenhed7
2.2 System-Bus10
2.3 Internt Lager11
2.4 Magnetpladelager12
2.5 Styreenhed til ydre I/O enheder 13
2.6 Basis-Modeller14

3 RC 8000 SYSTEM-PROGRAMMEL16
3.1 Monitor17
3.2 System-proces "s"19
3.3 BOSS Operativsystem 20
3.4 MIPS/TS Operativsystem 22
3.5 I/O Systemet24

4 RC 8000 PROGRAMMERINGSSPROG26
4.1 ALGOL26
4.2 FORTRAN 27
4.3 BASIC/COMAL 28
4.4 SLANG29

5 RC 8000 OPERATIONELT PROGRAMMEL30
5.1 File-Processor30
5.2 Hjælpeprogrammer 31
5.3 Data-Management-Systemer 31
5.4 Forskellige andreProgrammelpakker 33

6 RC 8000 APPLIKATIONSPROGRAMMEL 35
6.1 RC Økonomi-Styringssystem 36
6.2 RC Lønningssystem 36
6.3 RC Produktions- og Lagerstyringssystem37
6.4 RC System 8037
6.5 RC NET 38

7 NOGLE TYPISKE RC 8000 APPLIKATIONER40
7.1 Et mindre Regnskabs- og Produktionsstyringssystem40
7.2 Et Servicecentersystem42
7.3 Telefonoplysningssystem45\f

F_ 1 INTRODUKTION

RC 8000 er et pålideligt og driftsikkert edb-system. På grund af
den modulære opbygning kan RC 8000 konfigureres til at omfatte en
lang række datamatsystemer; lige fra en minidatamat med kun få
ydre enheder til en mellemstor centraldatamat, der betjener et om-
fattende antal terminaler og satellitsystemer. Et RC 8000 System
kan udvides uden omfattende udskiftninger af maskinel og program-
mel, ligesom allerede eksisterende RC udstyr fortsat kan anvendes
i et udbygget system. For eksempel kan en RC 3600 eller en RC
6000 opgraderes til et RC 8000 System.

EN TYPISK RC 8000 INSTALLATION

Et RC 8000 System er sammensat af både maskinel og programmel.
Maskinellet, baseret på MSI og LSI teknologi, er driftsikkert og
enkelt at betjene. Programmellet giver systemet fleksibilitet og
stor spændvidde - og udbygger således systemmulighederne.

Opdelingen af opgaver mellem maskinel og programmel sikrer stør-
ste ydeevne til laveste pris, idet hver komponent bidrager til
løsningen med de elementer, der er bedst egnede i relation til
opgaven.

I dette skrift beskrives, hvorledes maskinel og programmel indgår
i RC 8000 Systemet.\f

F_2 RC 8000 MASKINEL

Et RC 8000 System består af 4 maskinelle hovedkomponenter: cen-
tralenhed, internt lager, styreenhed til ydre ind-/udlæse enheder
samt magnetpladelagerkanal. Et givet system vil omfatte en eller
flere af disse komponenter. Enhederne er gensidigt forbundet ved
hjælp af en databus, RC 8000 System-Bus, som udfører al overfør-
sel af data mellem de sammenkoblede enheder. Databussen kan op-
fattes som en selvstændig systemkomponent, da ingen af enhederne
forbundet til bussen har speciel prioritet til at benytte denne.

Alle rutineopgaver i forbindelse med ydre enheder varetages af
tilhørende styrefunktioner. Centralenheden frigøres således for
trivielle opgaver og kan koncentrere sig om databehandling. Denne
struktur medfører da også, at RC 8000 Systemets totale ydelse er
væsenlig større, end de nominelle data for centralenheden umiddel-
bart lader formode.

Opbygningen omkring en databus giver en generel og fleksibel\f

struktur, med indbygget mulighed for senere udvidelser af syste-
met. F.eks. med flere centralenheder eller flere styreenheder, -
alle koblet til samme databus.

I de følgende afsnit beskrives de enkelte maskinelle komponenter
mere detaljeret, sluttende med en orientering om produktionstruk-
turering indenfor RC 8000 Datamatsystemerne.

T_ 2.1 Centralenhed

RC 8000 Centralenhederne udfører programinstruktioner som hentes
fra det interne lager under behandlingen. Enheden indeholder re-
gistre og kredsløb til aritmetisk logik, almen og interrupt-sty-
&_ring.

Kombinationen af generel mikroprogrammering og specielle maski-
nelle funktioner resulterer i en optimal fleksibilitet og hurtig-
hed. Således f.eks. instruktions-prefetch, hvilket vil sige, at
den følgende instruktion "maskinelt" hentes fra det interne la-
ger, mens den øjeblikkelige instruktion bliver udført. Behand-
lingsfunktionerne er ensartede for alle centralenheder, hvorimod\f

hastigheden for udførelsen af den enkelte instruktion afhænger af
forholdet mellem det antal funktioner, der er implementeret ved
mikroprogrammering, og det antal funktioner der er implementeret
maskinelt.

En gruppe centralenheder er primært udviklet på grundlag af mi-
kroprogrammering. Typiske udførelsestider ligger fra 3 til 20
usek. for almindeligt forekomne instruktioner. Disse enheder har
muliggjort de kompakte modeller blandt RC 8000 Datamaterne.

En anden gruppe centralenheder er udviklet med flere maskinelt
implementerede funktioner. Typiske instruktionsudførelsestider
ligger her fra 1 til 3 usek. Disse enheder ligger til grund for
de større modeller blandt RC 8000 Datamaterne.

Alle enhederne arbejder med et 24-bit-ord enkeltadresse instruk-
tionsformat med 64 basis-instruktioner. Hver instruktion optager
12 bit og har 16 mulige adresseringsformer, herunder: relativt,
indekseret og indirekte. 12-bit-halvord er det mindste direkte
adresserbare dataformat.

RC 8000 Centralenhederne benytter 4 arbejdsregistre, hvoraf 3
også virker som indeksregistre. Dette betyder, at hele instruk-
tionssættet umiddelbart er til rådighed for adressemodifikatio-
ner, hvorved antallet af tomme registeroverførsler til det in-
terne lager reduceres væsentligt.

Dataformat for talbehandling omfatter 12-bit halvord og 24-bit
helord til reelle tal, samt 48-bit dobbeltord til udvidede reel-
tal og flydende-kommatal beregninger.

Instruktionssættet er meget alsidigt og omfatter bl.a. halvord-
ordre og ord-sammenligningsordre, hvilket muliggør ordbehandling
i lighed med de logiske ordrer, der tillader test og ændring på
bitniveau. Yderligere er der indbygget en facilitet til aktive-
ring af et programmeret handlingsforløb, der kan startes af for-
udvalgte instruktionstyper. Et værdifuldt værktøj til fejlretning
af programmer, til simulering af specialinstruktioner og lignen-
de. De forskellige adresseringsformer tillader dynamiske omflyt-
ninger af programmer. Det vil sige, at programmer kan udføres
hvorsomhelst i det interne lager, således også flyttes rundt, når
det er påkrævet.

Et programbeskyttelsessytem med et realtidsur og et yderst virk-
ningsfuldt interruptsystem giver mulighed for multiprogrammering
(jvf. kapitel 3). \f

Programbeskyttelse opnås ved hjælp af grænseregistre og privili-
gerede instruktioner. Når udførelsen af en instruktion indebærer
lagertilgang, bliver lageradressen kontrolleret mod grænseregi-
stret for at forhindre, at de forskellige programmer blandes.
Yderligere er nogle priviligerede instruktioner reserveret for
operativsystemer. Hvis et almindeligt brugerprogram forsøger at
udføre en priviligeret instruktion, vil programmet blive afbrudt.

Interruptsystemet kan ligeledes afbryde programudførslen. Interne
afbrydelser, d.v.s. afbrydelser forårsaget indenfor centralenhe-
den, har 8 niveauer, hvorimod externe afbrydelser (fra de ydre
enheder) har op til 248 niveauer på de større modeller.

Realtidsuret, der har en findeling på 0,1 msek., styrer tidsde-
lingen, der muliggør regelmæssige skift mellem programmer med
henblik på behandling af parallelle programmer.

CENTRALENHED OG INTERNT LAGER - MODULOPBYGGET \f

2.2System-Bus

Systembussen er rygraden i RC 8000 Systemet. Alle komponenter i
et system er forbundet til den samme bus og kommunikerer efter en
ensartet kommunikationsprotokol. Dette forenkler forbindelsen
mellem de forskellige komponenter, idet den enkelte komponent kun
skal forbindes til databussen. Kodekonversioner for specifikke
ydre enheder bliver udført af en til disse enheder hørende styre-
eller kanalenhed.

Der anvendes en asynkron, fuldt sammenhængende forespørgsel/be-
kræftelse - håndtryk - kommunikation (request/acknowledge). En
databusoverførsel består af et dataord parallelt med et adresse-
ord og udføres på 0,3 usek., hvilket medfører en overførselska-
pacitet på 3,3 Mord pr. sek.

Systembussen er en selvstændig del af systemet med en autonom
busstyreenhed. Ingen af enhederne, der er forbundet til databus-
sen, end ikke centralenheden, har særlig prioritet. Hvis en af de
tilsluttede enheder skal bruge databussen, sender den en anmod-
ning om brug af databus. Når databussen er klar, får den ansøgende
enhed kontrol over bussen. Den næste enhed til at benytte databus-
sen bliver valgt umiddelbart derefter, således at en ny enhed er
klar, når den foregående bliver færdig. \f

Den asynkrone overførselsform betyder, at dataoverførslen mellem
to enheder vil foregå så hurtigt som muligt uafhængigt af kombi-
nationen af enheder. Den faktiske overførselshastighed bestemmes
af den maximale overførelseshastighed for den langsomste af de to
enheder. Dette indebærer, at også interne lagermoduler med for-
skellige cyklustider kan anvendes i det samme RC 8000 System.

En opbygning med den ovenfor beskrevne RC 8000 System-Bus sikrer
en effektiv udnyttelse af de maskinelle ressourcer og giver en
fleksibel og modulbaseret opbygning, der garanterer brugeren et
"åbent" fremtidsorienteret system, der kan tilpasses næsten en
hvilken som helst forudsigelig applikation. F.eks. kan adskillige
uafhængige centralenheder kobles til n system bus og være fælles
om de ydre enheder.

2.3Internt lager

RC 8000 Interne Lager er opbygget modulært. Størrelsen kan varie-
res mellem 64 Kord og 4 Mord afhængigt af modellen, idet lageret
kan udbygges med moduler af halvledertypen eller ferrit-kernetype
- eller kombinationer af begge typer.

Tilgang til lageret sker på 1-ords-basis omfattende 24-bit data
og en 3-bit paritetskode (eller en 6-bit fejlkorrigeringskode),
der genereres og kontrolleres af en tilhørende lagerstyreenhed.
Et enkelt ord kan læses på 0,55 (0,6) usek., til læsning eller
skrivning af en ordsekvens bruges 0,9 (0,7) usek. pr. ord sva-
rende til 1,1 (1,4) mill. ord pr. sek. - værdier i parantes gæl-
der for halvlederlager.

2.4 Magnetpladelager

RC 8000 bruger magnetpladelager som baggrundslager. Pladelagermo-
duler tilkobles systembussen ved hjælp af en magnetpladelagerka-
nal. På denne måde er det muligt at overføre data til og fra bag-
grundslageret uden at benytte centralenheden under hele overførs-
len. Centralenheden starter blot et kanalprogram; dette udføres
så selvstændigt af kanalenheden.

Pladelagermoduler fås med en kapacitet på henholdsvis 10, 21, 33,
66, 124 eller 248 Mbytes. En kanal kan betjene 4 pladelagermodu-
ler, og ialt 4 kanaler kan tilsluttes systembussen (afhængig af
model). Fuldt udbygget giver dette pladelagret en total kapacitet
på næsten 4000 Mbytes. \f

Overførselsraten til/fra pladelagret er 1,2 Mbytes pr. sek. Den
gennemsnitlige tilgangstid varierer med pladelagertypen, men er
typisk 30-40 msek. Data kan læses/skrives på en magnetplade per
kanal ad gangen; positionerinbg af læse-/skrivehoved og tilsva-
rende kan udføres samtidigt på flere magnetplader.

2.5Styreenhed til ydre I/O enheder

Alle "langsomme" ydre enheder såsom linieskrivere, kortlæsere og
kommunikationsudstyr tilsluttes via en styreenhed for ydre ind-/
udlæse enheder (i det følgende kaldet: I/O styreenhed - I/O for
input/output). Den styrer selvstændigt alle tilknyttede ydre en-
heder. F.eks. bliver en overførsel af data fra en stabel af hul-
kort til baggrundslageret startet af centralenheden, hvorefter
I/O styreenhed overtager arbejdet og tilendebringer overførslen
via systembussen uden videre medvirken fra centralenheden.

Faktisk er I/O styreenheden en RC 3600 Minidatamat, der er for-
synet med sit eget programmelsystem, så den kan udføre kodekon-
versioner, styre de ydre enheder, foretage terminal-polling og så\f

videre. Selvom den er en "rigtig" datamat, kan I/O styreenheden
ikke bruges til databehandling af brugerens programmer. Den er
specielt forbeholdt varetagelsen af kommunikationen til og fra de
ydre enheder. En enkelt I/O styreenhed er i stand til at betjene
et omfattende udvalg af ydre enheder. Yderligere kan flere styre-
enheder tilsluttes RC 8000 Systemet om nødvendigt (afhængig af
model).

&_ RC 8000 I/O Styreenheden kan sende og modtage data via systembus-
sen med en hastighed af 600 Kbytes pr. sek. En undtagelse fra den
generelle struktur er RC 8000/15 (den mindste model), der har sin
I/O styreenhed tilkoblet på en måde, der medfører en transmis-
sionshastighed på 10 Kbytes pr. sek.
T_
I/O styreenheden, der altså er en specielt udstyret RC 3600 Mini-
datamat, fås enten med halvleder- eller ferritkernelager.

2.6Basis-Modeller

De muligheder, der tilbydes med det maskinelle udstyr, er blevet
struktureret i basismodeller. Disse tjener som en bekvem indgang
til beslutningstagning, medfører en naturlig rækkedeling af mu-
lighederne og bevarer samtidig fleksibiliteten i konfigureringen.

Baismodellerne er i sig selv sammenbygninger af moduler og til-
godeser som sådan den "åbne" fremtidsorienterede struktur, der
blev omtalt i forbindelse med beskrivelsen af systembussen. Ho-
vedårsagen til at konfigurere basismodeller skal ses i bestræ-
belserne for at sikre systemkonfigurationer, der arbejder som en
helhed samt lever op til forventet udeevne. Hvis man nemlig ukri-
tisk kræver specifikke aspekter uden iøvrigt at tilpasse og ba-
lancere systemhelheden i overensstemmelse hermed, så risikerer
man at opnå en dårlig systemudnyttelse.

Som konsekvens indeholder hver af basismodellerne en række mulig-
heder, der alle tilgodeser systemhelheden. Skillelinierne følger
i al væsentlighed forskelligheder i centralenhederne, som igen
medfører forskellige størrelsesområder for det interne lager, an-
tal magnetpladelagerkanaler og antal I/O styreenheder.

Men stadig tillader basismodellernes modulære struktur altså, at
der kan tilsluttes en række supplerende moduler, hvorved der
åbner sig et bredt spektrum af muligheder.
\f

Udfra de foregående beskrivelser kan sammenstilles følgende ka-
rakteristika for basismodellerne:

RC 8000 Model 15 35 35S 45 45S 55 55S

CENTRAL RC 8002 8004 8005 8006
ENHED instruks.tid
usec.-gens. 6,22,3 1,2

INTERNT halvleder+ 0 + 0 + 0 +
LAGERkerne + 0 + 0 + 0
størrelse
K ord 64 64 - 512 64 - 4096

MAG.PLADE
KANAL antal 11 - 4

I/O antal11 - 8
STYRE- trans.rate
ENHED K bytes/sec. 10600

"+" = inkluderet; "0" = option

Med det ovenfor beskrevne maskinel er det muligt at udføre for-
skellige databehandlingsopgaver, men med maskinel alene ville
disse opgaver blive komplicerede og genstand for mange begræns-
ninger. Den høje grad af fleksibilitet og formåen, der karakteri-
serer RC 8000 Systemerne, er opnået, idet maskinellet suppleres
med systemprogrammel.
\f

F_ 3 RC 8000 SYSTEM-PROGRAMMEL

Hovedformålet med RC 8000 System-Programmellet er, at opnå den
mest effektive udnyttelse af datamatressourcerne uafhængigt af
kørselsformen, samt at lette betjeningen.

Med hensyn til effektivitet, er en af de primære faktorer udnyt-
telsen af centralenheden. Normalt er centralenhedens opmærksomhed
kun påkrævet i en fraktion af den totale udførselstid for et al-
mindeligt programjob. Det meste af tiden afventer centralenheden
færdiggørelsen af nogle I/O operationer.
T_

Dette er helt klart en dårlig udnyttelse af centralenhedens kapa-
citet.

En løsning på dette problem er, at lade centralenhedens opmærk-
somhed skifte mellem et antal job. Medens nogle job afventer fær-
digbehandling af en I/O operation, kan centralenheden udføre data-
behandling for andre job.
T_

For at kunne arbejde på denne måde kræves det, at der på samme
tid er flere job tilstede i det interne lager (respektive, at
flere job er til rådighed på baggrundslager med henblik på løben-
de ind-/udlæsning). Centralenheden vil så kunne opfattes som et
antal behandlingsenheder. Brugere, der alle behandler opgaver
samtidigt, vil opleve dette, som om de hver især har deres egen
behandlingsenhed. Denne virtuelle multibehandling er princippet
bag RC Multiprogrammeringssystemet. \f

T_3.1 Monitor

Monitor udgør det programmelelement, der implementerer RC 8000
Multiprogrammeringssystemet. Systemets basisbegreb er "proces-
sen". En proces er her defineret som det område i det interne
&_lager, hvor alle behandlingsaktiviteterne, der angår et bestemt
job, bliver udført. I multiprogrammeringsystemet er cen-
tralenhedens opmærksomhed ligeligt fordelt mellem alle de tilste-
deværende (respektive tilrådighedværende) processer og disse
bliver derfor kaldt "parallelle processer". I dette miljø styrer
operativsystemet Monitor følgende funktioner:

- Fordeling af maskintid mellem parallelle processer.
- Påbegyndelse, udførelse og afslutning af processer.
- Kommunikation mellem processer.
- Reservering og påbegyndelse af sekventielle I/O dataoverførs-
ler.
- Administration af baggrundslagerkataloget.

Monitorprogrammet er permanent placeret i det interne lager. Når
det er igang med at udføre en funktion, kan det ikke afbrydes af
noget andet program. Det kan betragtes som en udvidelse af de
maskinelle faciliteter.

Ved hjælp af interval-timeren og interruptsystemet tildeler Mo-\f

nitor processerne 25,6 msek. behandlingstid efter tur. Hvis i-
midlertid en proces afbrydes efter f.eks. 10 msek. for at vente
på en ydre enhed, bliver den næste proces i køen startet.

Hver proces har en procesbeskrivelse, der indeholder et symbolsk
navn, relationer til andre processer, grænser for procesområdet i
det interne lager, status og anden information, der er nødvendig
for administrationen af datamatressourcerne. Ialt 21 processer
kan eksistere samtidigt, og ved hjælp af et beskyttelsessystem er
det garanteret, at ingen proces af vanvare opererer udenfor sine
grænser.

Hvis to parallelle processer ønsker at kommunikere, er Monitor i
stand til at formidle kontakten ved hjælp af fem procedurer, kal-
det: send meddelelse, afvent svar, afvent meddelelse, send svar
og afvent hændelse. Hver proces har en kø hos Monitor, hvor den
kan modtage meddelelser fra andre processer. Ved at bruge kommu-
nikationsprocedurerne er det muligt at overføre data fra en
proces til en anden.

Ydre enheder bliver også betragtet som en slags processer, idet
maskinellet i forhold til centralenheden repræsenteres af en
"driver", d.v.s. et styreprogram, - og disse bliver ligeledes
identificeret ved et symbolsk navn. Kommunikationsprocedurerne
kan så bruges til at påbegynde sekventielle dataoverførsler mel-
lem processer og ydre I/O enheder, eller til at etablere en kon-
versation med en terminal.

Brugere kan opbevare programmer og data permanent på baggrundsla-
geret, der er organiseret som en samling navngivne dataområder.
En bestemt del af hvert lager er reserveret til et katalog, der
beskriver navnene og placeringerne af dataområderne. Kataloget
kan underopdeles i et ubegrænset antal delkataloger, med samme
struktur som hovedkataloget, og hver med sin specifike tilgangs-
begrænsning.

Denne hierarkiske struktur, kombineret med et system til program-
beskyttelse, sikrer, at dataområderne er utilgængelige for uved-
kommende, men tillader derimod brugerne at nyde godt af fælles
programbiblioteker o.s.v. Dataområder bliver tildelt efter en
strategi, der tillader, at der foretages udvidelser eller ind-
skrænkninger, når det er nødvendigt, og således gør reorganise-
ring overflødig.\f

T_ 3.2 System-Proces >s>

Systemproces >s> er nøglen til RC 8000 Systemets dynamiske aspek-
ter med hensyn til operativsystemer.

Et operativsystem er et program, der kontrollerer udførelsen af
andre programmer, f.eks. et gruppebehandlingssystem, der organi-
serer en sekventiel udførsel af programmer, et tidsdelingsystem
til samtidig programmering fra en række terminaler eller et real-
tidssystem til opdatering af en database. Normalt er et operativ-
system lavet til n, og kun n slags funktion.

I modsætning hertil har RC 8000 Monitor ikke nogen indbyggede
forestillinger om programplanlægning og ressourcetildeling; den
tillader et hvilket som helst program at starte andre programmer
i en hierarkisk struktur og at udføre disse efter egen strategi.
Monitors funktioner, som beskrevet i forrige afsnit, udgør en
bred ramme for forskellige planlægningsstrategier.

Efter den første indlæsning af systemprogrammellet "ejer" system-
proces >s> alle datamatressourcerne. Brugere kan så, fra en til-
fældig terminal, reservere et lagerområde for at begynde et pro-
gram. >s> vil straks lave procesbeskrivelsen til Monitor og pro-
cessen er etableret.

En sådan brugerproces vil så løbe parallelt med >s>, der virker
som et primitivt operativsystem for de parallelle processer A, B
og C, det selv har startet.
\f

De tre processer A, B og C kan kaldes børneprocesser i forhold
til >s>, og de kan igen skabe deres egne børneprocesser D, E, F,
G og H. Børneprocesserne kan kun tildeles en delmængde af de res-
sourcer, der er reserveret af forældreprocessen. Forældreproces-
sen virker som operativsystem for sine børneprocesser; den kan
påbegynde, modificere, stoppe og fjerne sine børneprocesser alt
efter den ønskede strategi.

Proceshierarkiet kan udvides både i dybden og i bredden. I det
familietræ der opstår, har "forældrene" uindskrænket råderet over
deres "børn". Således bliver begrebet "operativsystem" meget
varieret og dynamisk i sammenhæng med RC 8000 Systemer. Operativ-
systemer kan skrives i et passende høj-niveau sprog, som ALGOL 7,
og implementeres som et hvilket som helst andet program; de kan
ligeledes udskiftes dynamisk, hvilket sætter systemet i stand til
at skifte mellem forskellige operationsformer, ligesom adskillige
operativsystemer kan være aktive på en gang.

T_3.3 BOSS Operativsystem

Med systemproces >s> kan man generelt indlæse operativsystemer -
f.eks BOSS, der er et avanceret operativsystem beregnet for grup-
pekørsel. Boss sørger for hurtige og pålidelige sekventielle
udførsler af job og tillader brugere samtidigt at redigere og
indlæse job fra indtil 50 terminaler ialt. Alle brugere er regi-
streret i et brugerkatalog, der også omfatter et bogholderisys-
tem, desuden har hver bruger sit eget filkatalog, der sikrer, at
brugerens data er utilgængelige for uvedkommende. Jobs kan ind-
læses fra terminaler såvel som fra hulstrimmel- og hulkortlæsere.
Output til terminalerne og linieskriverne bliver "spoolede" på
baggrundslagret, d.v.s. data opsamles i en kø, hvorfra output til
de ydre enheder overføres.

BOSS administrerer også jobkøen på baggrundslageret. Udførelses-
rækkefølgen vælges ved hjælp af en prioritetsalgoritme, således
at forholdet mellem den forventede kørselstid og ventetiden er
den samme for alle job i køen. Op til 20 job kan være under udfø-
relse samtidig, men kun de to højest prioriterede job er tilstede
i BOSS-området i det interne lager. Resten af jobbene er midler-
tidigt suspenderet og "swappet" til baggrundslageret, d.v.s. op-
samlet i "swap"-området - tilsvarende output i "spool"-området.
Herfra kan de så senere hentes til videre behandling i relation
til prioriteringen. Dette dynamiske system sikrer, at små job
bliver udført hurtigt, og at store job er garanteret udførelse,
men må påregne længere ventetid. Output til terminaler og linie-
skrivere samles i segmenter på baggrundslageret og overført som
en helhed, når jobbet er færdigt.

T_Nedenfor er vist en typisk terminalkonversation mellem en bruger
og BOSS med LOGIN-procedure, programgenerering, etc.

F_ 3.4 MIPS/TS Operativsystem

Som en anden mulighed kan vælges operativsystemet MIPS/TS. Et
yderst virkningsfuldt operativsystem til konverserende terminal-
arbejde i flerbrug on-line systemer.

Operativsystemet udfører overflytninger af brugerprogrammer til
og fra baggrundslager (swap-området) efter behov, hvilket gør det
muligt for forskellige brugerprogrammer at udnytte samme arbejds-
område i datamatens interne lager. Som konsekvens øges antallet
af programmer, der er tilgængelige for brugerne, uden at øge
størrelsen af det interne lager.

Strategien for opgaveudførelsen er indeholdt i en prioritetsalgo-
ritme, der løbende beregnes for alle brugerprogrammer, systemet
administrerer. Programmer, der hyppigt er i brug, og som formår
at svare hurtigt, prioriteres forud for programmer, der bruges
knap så tit og som har længere behandlingstider. Et enkelt pro-
gram med karakter af gruppekørsel-databehandling vil samtidig
kunne behandles i de tidsperioder, der ikke udnyttes af den
konverserende databehandling. Denne prioritering af opgaverne
sikre brugerne den bedst mulige service, samtidig med at data-
maten udnyttes optimalt.

Terminalforbindelser oprettes gruppevis i relation til de pro-
grammer, der ønskes benyttet. Forbindelserne til grupperne kan
oprettes/slettes dynamisk. Denne struktur sikrer, at programaf-
viklingen ikke hæmmes, idet hastighedsforskellen mellem selve
databehandlingen og betjeningen af ydre enheder derved kan ud-
lignes.

Tilsvarende bevirker spool-funktionen, at programmerne hurtigt
kan skrive resultaterne fra databehandlingen på baggrundslageret
og umiddelbart fortsætte med andre opgaver i henhold til priori-
tetsfølgen. De resultater, der således opsamles på baggrundsla-
geret, sendes derefter under kontrol af MIPS/TS til modtageren i
et tempo, der svarer til den pågældende ydre enheds modtagekapa-
citet.

På større anlæg kan flere MIPS/TS operativsystemer oprettes pa-
rallet om ønsket.

Nedenfor er vist en terminalkonversation med MIPS/TS:

T_
TERMINAL
Input by user
H_A_N_D_L_I_N_G_ Output by system K_O_M_M_E_N_T_A_R_

Oprettelse afForbindelse
brugerproces etableret

Redigering afC_O_M_P_O_S_E_R_T_E_X_T_ AProgrammering
programtekstfra interaktiv
(konverserende)
terminal

Output fra ALGOL
oversættelse
Oversættelse
af programOutput fra OBJECT
program

Afslutning af
Fjernelse af program - forbin-
&_ brugerproces delse brydes
\f

3.5I/O Systemet

I/O systemet er en af årsagerne til RC 8000 Systemets høje ydel-
se. Strukturen med intelligente styreenheder og databus danner
basis for et standardiseret I/O programmeringssystem med en ef-
fektiv fordeling af de ydre ressourcer.

For en jobproces er en I/O operation et spørgsmål om at sende en
I/O anmodning til Monitor med ønske om en ydre enhed og en adresse,
hvor data skal læses eller skrives. Monitor administrerer en I/O
anmodningskø, og når den ønskede enhed bliver klar, indleder Mo-
nitor en dataoverførsel til databussen ved at aktivere et kanal-
program. Kanalprogrammerne er permanent indlæst i det interne
lager og bliver udført af den I/O styreenhed, der styrer den øn-
skede ydre enhed. Når kanalprogrammet først er startet, udfører
I/O styreenheden programmet uden yderligere medvirken fra central-
enheden. Den fysiske styring af de ydre enheder og de nødvendige
kodekonversioner bliver selvstændigt udført af I/O styreenheden.
\f

Denne struktur, med en central styreenhed og autonome ydre styre-
enheder, kan betragtes som et lille net og bliver også implemen-
teret som et sådant. I/O styreenhedens programmel inkluderer et
Net-Styrings-Program, hvilket betyder, at et RC 8000 System lige
fra starten er forberedt for tilslutning til et databehandlings-
net, hvor I/O styreenheden vil være et knudepunkt. Terminal-pol-
ling, styring af de ydre enheder, dataoverførsler til/fra syste-
met og alle I/O styreenhedens øvrige opgaver, bliver udført af et
programmelsystem lig selve RC 8000 Systemets - med egen Monitor
og egne operativsystemer. Trods denne lighed kan I/O styreenheden
dog ikke bruges til behandling af brugerprogrammer, men er forbe-
holdt styringen af de ydre enheder.

Dette systemprogrammel, der er beskrevet såvidt, skaber det mul-
tiprogrammeringsmiljø, i hvilket adskillige brugere kan arbejde
uafhængigt. I de følgende kapitler vil vi se nærmere på de pro-
grammelsystemer, der er til rådighed for brugere til databehand-
ling af opgaver.
&_

F_ 4 RC 8000 PROGRAMMERINGSSPROG

Det er selvfølgelig mest bekvemt at foretage programmeringen til
RC 8000 Systemet i et høj-niveau programmeringssprog. En række
programmeringssprog, der passer til forskellige formål, er til
rådighed for RC 8000 Systemer. De er alle velkendte, men udvidede
for bedre at kunne udnytte de muligheder, der er beskrevet i de
foregående kapitler.

T_4.1 ALGOL

Det primære høj-niveau sprog for RC 8000 er ALGOL 7, der er en RC
&_udvidelse af det alment anvendelige ALGOL 60 sprog.

Den væsentligste udvidelse ligger i implementeringen af et alment
input/output system. Brugere kan frit vælge, om de vil anvende
standard høj-niveau I/O procedurer, eller om de ønsker at gribe
ind i dataadministrationen på det mest basale plan. ALGOL 7 I/O
systemet tilbyder et filsystem på baggrundslageret med sekventiel
tilgang. Der er inkluderet en dynamisk feltbeskrivelse i sproget
som et effektivt værktøj til styring af forskellige individtyper
i en enkelt fil. En "context" facilitet gør det muligt at pro-
grammere flerbruger on-line terminalsystemer i ALGOL 7.\f

Også corutiner underbygges med denne koncept.

Andre udvidelser omfatter instruktioner til multibetinget udflet-
ning, til operationer på bit-niveau og til effektiv pakning af
information. Biblioteksprocedurerne sørger for faciliteter til
udførsel af alle Monitors funktioner. Dette, kombineret med I/O
systemet, gør det muligt at programmere operativsystemer i ALGOL
7.

ALGOL 7 kildeteksten kan indlæses fra terminaler, hulstrimmel,
hulkort, magnetbånd eller pladelager. Også kombinationer af enhe-
der er mulige. Input fra magnetbånd og pladelager skal være i ISO
7-bit tegnkode med 3 tegn pr. ord. Procedurer kan oversættes se-
perat og inkluderes i det fælles programbibliotek. En sådan pro-
cedure kan kaldes direkte, og en kopi af procedurekoden bliver
kopieret til objekt programmet under oversættelsen.

Oversætteren kræver 7 Kord i det interne lager og et baggrunds-
lagerområde stort nok til at kunne indeholde objektprogrammet.
Der udføres en omfattende syntaks- og indtastningskontrol, og
alle fejl kan findes i n oversættelse. Efter en basistid på 2
sek., er oversættelseshastigheden omkring 75 "statements" pr.
sek. (statement = sætning i et program). Adskillige programmer
kan oversættes samtidigt, idet kopier af oversætteren kan ind-
læses i forskellige dele af det interne lager.

Objektprogrammet bliver overført til baggrundslageret som en se-
kvens af relokerbare segmenter, hver på 256 ord. Programmet om-
fatter en automatisk administration af overførsler af segmenter
til det interne lager under kørslen. Udførelsestiden for et pro-
gram afhænger af størrelsen på det lagerområde, der er til rådig-
hed. Programmer af tilfældig størrelse kan udføres i et lagerom-
råde på 3500 ord plus plads til variable, dog anbefales et område
på 6000 ord plus plads til variable. Testoutput kan genereres un-
der programudførelsen. Programmer med fejl udføres, til fejlen
nås.

T_ 4.2 FORTRAN

RC FORTRAN er baseret på ISO anbefaling R 1539 (FORTRAN IV), men
er udvidet til at omfatte brug af det basale ALGOL 7 I/O system,
og som følge deraf er nogle af de udtryk, der er defineret i ISO
anbefalingen, ikke nødvendige. Der eksisterer en "for-oversæt-
ter" til at oversætte disse ikke-eksisterende udtryk til RC FOR-
TRAN. Andre udvidelser omfatter aritmetik af "blandet type", bag-\f

tælling i DO sætninger, bit-mønster operationer, DATA-initialise-
ring af almindelige variable hvor som helst og multi-indgange til
procedurer.

Forudoversatte FORTRAN og ALGOL procedurer kan indsættes under
oversættelsen. Kontrol af parametre i procedurekald og af eti-
ketter på tildelte GOTO sætninger er standard, hvorimod kontrol
af indexgrænser er en valgfri mulighed.

Alle FORTRAN oversætterens karakteristika er de samme, som dem
der er beskrevet i afsnit 4.1 for ALGOL oversætteren.

T_ 4.3 BASIC/COMAL

RC BASIC/COMAL er et struktureret undervisningssprog, - det er
enkelt, men samtidig omfattende og avanceret, egnet til at demon-
&_strere og træne vigtige programmeringsprincipper.

Det oprindelige BASIC har adskillige mangler med hensyn til avan-
ceret programmering. Nyligt er fremkommet forslag til nye og bed-
re undervisningssprog, bl.a. COMAL (C_o_m_mon A_lgorithmic L_anguage).
COMAL har alle de egenskaber, der har gjort BASIC populært, fak-
tisk indeholder COMAL det oprindelige BASIC, hvortil kommer yder-
ligere en række fordelagtige træk.

T_Ved at samarbejde COMAL og BASIC til RC BASIC/COMAL er opnået
følgende udvidelser i forhold til almen BASIC:

IF-THEN-ELSE, REPEAT-UNTIL, WHILE-DO og CASE-OF-WHEN instrukti-
oner.
8-tegn variabelnavne.
Struktureret programmering uden GOTO linienummer.
Interaktiv programudførsel.
Gruppeudførsel af programmer.
Fil input/output.
Matrix operationer.
Manipulationer med tekststrenge, incl. dimensionerede strenge.
Formattering af output.
&_Bordkalkulator funktione.

Med disse faciliteter dækker RC BASIC/COMAL hele det uddannelses-
mæssige område fra det grundlæggende introduktionsniveau til træ-
ning i avanceret produktionsprogrammering. \f

T_4.4 SLANG

RC SLANG er det symbolske maskinsprog til RC 8000, det har samme
blokstruktur som ALGOL. SLANG bruges af RC til kodning af basis-
&_programmel og lejlighedsvis til kodning af kritiske procedurer.
SLANG programmering giver en marginal forøgelse af behandlings-
hastigheden og en mindre reduktion i programstørrelsen på bekost-
ning af læsbarhed og programmeringstid. Procedurer, der bryder
høj-niveau sprogenes konventioner, kan også kodes i SLANG. SLANG
programkildeteksten kan indlæses fra terminaler, baggrundslager,
hulstrimmel, hulkort, magnetbånd eller en kombination af disse.
Input fra magnetbånd og baggrundslager skal være i ISO 7-bit
tegnkode med 3 tegn pr. ord.

Uafhængigt af programmeringssproget er et antal opgaver standard-
procedurer, der alment vedrører udførslen af databehandling. Dis-
se kan være komplicerede og tidskrævende at kode. Derfor findes
der en række programpakker, der er til brugerens rådighed som en
bekvem løsning af opgaver som: jobstyring, dataadministration,
terminalkommunikation etc. Denne slags programmel kaldes opera-
tionelt programmel og behandles i det følgende kapitel. \f

F_5 RC 8000 OPERATIONELT PROGRAMMEL

5.1 File-Processor

Når en proces skal oprettes, indlæser operativsystemet et lille
styreprogram, kaldet File-Processor, til jobområdet. Dette pro-
gram er i stand til at indlæse og aktivere udførslen af program-
mer i henhold til de jobfil specifikationer, brugeren har opstil-
let. Disse programmer kan være brugerprogrammer, oversættere,
redigerings- eller andre specielle hjælpeprogrammer. Når et
program er udført, bliver styringen returneret til File-Processor
programmet, som så indlæser det næste program. Når jobfilen er
udtømt, bliver styringen returneret til operativsystemet. Ek-
semplet fra afsnit 3.3 ses nedenfor, her blot kommenteret med
hensyn til programstyring.

Hjælpeprogrammer til jobstyring, såsom betinget udførsel af job-
trin, eller job-operation til kommunikation, er inkluderet i bib-
lioteket med hjælpeprogrammer.

T_5.2 Hjælpeprogrammer

Disse programmer, som generelt kan benyttes i databehandlingen,
&_dækker en række opgaver. Ifølge deres funktion kan de opdeles i
tre hovedgrupper: katalog-administration, data-administration og
jobstyring.

Programmer til administration af kataloger bruges til at oprette,
ændre eller slette katalogindgange på baggrundslageret, såvel som
til at opsøge, sortere eller udskrive tilgange til brugerfilkata-
log.

Data-administrationsprogrammer dækker følgende opgaver: kopiering
af data fra et opbevaringsmedie til et andet, simpel formattering
(overskrifter og identifikation) af udskriftsdata og redigering
af tekststrenge, f.eks. i programfiler.

Jobstyringsprogrammer giver mulighed for: at afslutte job, at
gentage et eller flere jobtrin, betinget at udføre et eller flere
jobtrin, at kommunikere mellem job og operatør, f.eks. advisering
om montering af magnetbånd, samt at styre linieskrivere.

Andre hjælpeprogrammer til specialformål kan kodes af brugeren og
indføjes i biblioteket.

T_5.3 Data-Management-Systemer

Administrationen af filer på magnetpladelageret kan implementeres
&_på tre niveauer. Det første niveau er ALGOL/FORTRAN standard in-
put/output-systemet (se afsnit 4.1). Det andet niveau opnås ved
hjælp af en baggrundslager-programpakke, der indeholder et in-
deks-sekventielt filsystem. På det tredie niveau udvider databa-
se-programpakken faciliteterne fra baggrundslager-programpakken
med et forbundet-fil-database-system.

For data på magnetbånd indeholder magnetbånd-programpakken et sæt
procedurer til administration af etiketterede magnetbåndfiler i
ALGOL og FORTRAN programmer. Etiketterne følger ISO standard.
\f

Baggrundslager-programpakken sørger for et indeks-sekventielt fil-
system med direkte tilgang til lagermediet. Ved hjælp af index-
tabeller i to niveauer er det muligt at foretage hurtig inspek-
tion, opdatering eller sletning af specifikke individer.
T_

Hvert enkelt individ er unikt identificeret af en nøgle. Når et
bestemt individ skal findes, vil systemet lede efter nøglen i
"hoved"-tabellen. Denne opgiver en sektion af filen, et hoved,
hvor man kan søge videre. Søgning i dette hoveds bloktabel giver
den blok, hvor individet kan findes. Systemet, som kan bruges til
individer af variabel længde, såvel som til individer af tilfæl-
dig type, omfatter også sorteringsprocedurer.

Det forbundne-fil-database-system er baseret på to filtyper -
masterfiler og listefiler. Masterfil-individerne indeholder data
om helheder, såsom: produkter, produktionsudstyr, ordrer etc.
Listefilerne indeholder supplerende data, der vedrører helheder-
ne og kan endvidere udtrykke forhold mellem helhederne.

En situation, hvor tre maskiner bliver brugt til at producere to
forskellige produkter, kan således repræsenteres i en database
ved to masterfiler og en listefil.

Masterfilerne er ordnet indeks-sekventielt. Der er direkte adgang
ved hjælp af nøgler eller sekventielt. Et masterfil-individ kan
T_være "mor" til en liste.

Listefilerne har sekventiel tilgang, og individerne er organise-
ret i kæder. Individerne i en listefil vil altid være "døtre" af
et individ i en anden fil, som enten kan være en masterfil eller
en listefil. Som følge heraf må der altid forud for tilgang til
T_ en kæde af listefil-individer være foretaget tilgang til et mo-
derindivid i en masterfil eller en listefil.

5.4Forskellige andre programpakker

Terminal-programpakken indeholder kommunikationsprocedurer til
on-line input/output til terminaler, der kører under ALGOL
programmer.

Matematik/statistik-programpakken dækker en række opgaver, såsom:
løsning af differential ligninger, lineære ligninger og matricer,
Fourier transformationer, beskrivende statistik og mange andre
matematiske standardproblemer. \f

F_ 6 RC 8000 APPLIKATIONSPROGRAMMEL

Med det operationelle programmel og programmeringssprogene, der
er beskrevet i de foregående kapitler, kan brugere selv program-
mere og sammensætte applikationsprogrammer. Det vil dog ofte være
et belastende og tidskrævende arbejde.

RC Applikationsprogrammel tilbydes derfor som systemer, der dæk-
ker et vidt område af administrative problemer indenfor handel og
industri.

På grundlag af mange års erfaring med servicebureau virksomhed
har RC udviklet en samling pålidelige og fleksible applikations-
programmer. De tre hovedsystemer er:

RC Økonomi-Styringssystem
RC Lønningssystem
RC Produktions- og Lagerstyringssystem

Alle tre systemer er opbygget af moduler og kan afstemmes til at
imødekomme individuelle ønsker. Opdatering, forespørgsler og min-
dre rapporter udføres tidstro fra on-line terminaler, hvorimod
større beregnings- eller dokumentationsopgaver udføres i gruppe-
kørsler. Systemfunktionerne kan også deles mellem egen installa-
tion og et servicebureau.

RC System 80 integrerer de tre ovennævnte systemer i et komplet
administrativt edb-system. En række af funktionsmodulernekan
udvælges, passende til organisationens nuværende behov, uden at\f

dette er nogen begrænsning senere. Systemet kan altidudbygges
eller ændres efter behov.

RC NET er et data-kommunikationssystem, der gør det muligt at bru-
ge en RC 8000 som centraldatamat i et større udbredt edb-net. Ved
at benytte RC NET kan organisationens system således tilsluttes
andre systemer, - og omvendt.

I de følgende afsnit beskrives systemernes muligheder mere udfør-
ligt. Og stadigvæk: inden for rammerne af hvert system kan struk-
turen og indholdet af ind-/uddata tilpasses organisationens nu-
værende behov, såvel som fremtidige ændringer i behov.

T_6.1 RC Økonomi-Styringssystem

RC Økonomi-Styringssystem omfatter moduler til hurtig og sikker
behandling af følgende daglige forretningstransaktioner: ordre-
registrering, fakturering, debet/kredit-bogholderi, regnskabsbog-
&_holderi og lagerstyring.

Kun basis-bilag bruges til at opdatere systemet, de manuelle for-
beredelser er således skåret ned til blot at anføre kontonumre.
Firmaets kontoplan er registeret i regnskabsmodulet; kontoplaner
for specifikke grupper, opgørelser og budgetanalyser udskrives
periodisk eller efter anmodning. Hvert modul sørger for en række
statistikker, oversigter og analyser, hvilket gør RC Økonomi-Sty-
ringssystem til et værdifuldt værktøj i finansadministrationen.
Debitormodulet kan f.eks. udarbejde kundeanalyser og salgsstati-
stikker for forskellige kombinationer af produkter og kundegrup-
per.

T_6.2 RC Lønningssystem

RC Lønningssystem er løsningen på problemer som: lønberegninger,
styring af kontrakt- og bonussystemer, opgørelse af indirekte om-
kostninger, dokumentation til skattemyndigheder, fraværsstati-
&_stik, feriepenge- og årsopgørelser.

Systemet omfatter følgende moduler: registrering, beregning, ad-
ministration og udskrift. Denne struktur giver mulighed for at
køre en række registreringskørsler med associeret styringsoutput
forud for den afsluttende beregnings- og administrationskørsel. \f

T_ 6.3 RC Produktions- og Lagerstyringssystem

RC Produktions- og Lagerstyringssystem er en hurtig og effektiv
måde at gribe administrationsproblemer an på. F.eks. planlægning
af indkøb, optimering af lager, analyse af produktionsbelastning,
&_såvel som beregning og styring af produktionsomkostninger.

I et produkt-netværkmodul bliver produkterne og deres sammensæt-
ning registreret, d.v.s. alle sammensætninger af råmaterialer og
halvfabrikata frem til slutproduktet indgår i en logisk beskri-
velse. I et lagermodul bliver alle bevægelserne på lageret regi-
streret. Et priskalkulationsmodul sørger for hurtige og præcise
beregninger af produkternes profitevne, og sluttelig holder or-
dremodulet styr på de forskellige ordrestrømme til og fra virk-
somheden.

Alle disse moduler er i stand til at lave forskellige lister,
oversigter, analyser og statistikker efter anmodning. Strukturen
og indholdet af disse output-muligheder kan ændres, når applika-
tion kræver det.

T_6.4 RC System 80

Hvert af de ovenfor nævnte systemer arbejder med sin egen databa-
se, og hvert system giver mulighed for regnskabsbogføring. Dette
&_indebærer, at arbejder samme firma med to eller alle tre system-
er, vil der oplagres en vis mængde overlappende information i de
enkelte databaser. Som følge deraf kræver nogle hændelsesforløb
opdatering i mere end n database.

RC System 80 integrerer alle tre systemer til et system med en
enkelt avanceret database, som alle delsystemerne refererer til.

RC System 80 er struktureret som et meget fleksibelt rammeprogram
sammensat af basismoduler og funktionsmoduler. Basismodulerne
bruges til input, opdatering af fil-register og output, og er
fælles for alle delsystemerne. Hvert applikationsdelsystem er
bygget af funktionsmoduler, som også kan være fælles for flere
delsystemer. F.eks. bliver regnskabsbogholderimodulet benyttet af
såvel lønningssystemet som af debitorbogholderisystemet. Databa-
sen, som alle delsystemerne refererer til, er uafhængig af appli-
kationerne. Derfor er det nemt at udvide systemet med nye delsy-
stemer og funktionsmoduler, efterhånden som der opstår behov for
dette. Ændringer kan udføres ved hjælp af ALGOL programmerings-
sproget.\f

T_ 6.5 RC NET

Introduktionen af de store centrale datamater gjorde det muligt
at udføre edb-opgaver for flere uafhængige brugere samtidigt. Til
fjernt placerede brugere blev der udviklet terminal-kommunikati-
&_onsfaciliteter. Resultatet af dette, blev en række forskellige
kommunikationsprotokoller (overenskomster om måden at udveksle
data på), som alle havde det til fælles, at den centrale datamat
var alene om at overvåge systemet. Denne hierarkiske struktur har
flere ulemper:

Den centrale datamat belastes hårdt af de mange kommunikationsme-
toder, transmissionslinierne udnyttes dårligt og brugere skal of-
te anvende forskellige typer af terminaler til forskellige cen-
trale datamater.

Måden at løse disse problemer på, og samtidig få indbygget en
række fordelagtige faciliteter i det nuværende system, inklusive
indbygget sikkerhed med hensyn til fremtidig fleksibilitet, er at
bruge RC NET data-netværksystemet.
T_

I RC NET sammenhæng bliver en installation med databehandlingska-
pacitet benævnt en >central>. Der er koblet et knudepunkt til
hver central, og knudepunkterne er indbyrdes forbundet med kommu-
nikationslinier, der udgør et netværk.
\f

RC NET er et system til udveksling af information mellem central-
datamaterne. En meddelelse fra en central til en anden bliver op-
delt i en række "pakker", som bliver sendt via nettet. En af knu-
depunkternes hovedfunktioner er at holde øje med, hvilke central-
datamater der er tilkoblet for øjeblikket og deres placering i
nettet. Datapakkerne sendes fra knudepunkt til knudepunkt, indtil
det knudepunkt nås, hvor den centraldatamat, som skal modtage da-
tapakken, er tilkoblet.

X 25 level 2 HDLC (Høj-niveau-data-forbindelsesstyring) protokol-
len bruges for kommunikationslinierne, der forbinder knudepunkt-
erne, men man kan anvende andre protokoller til særlige linier,
hvis det er ønskeligt.

En central i et RC NET kan f.eks. være et RC 8000 System, et IBM
system eller en RC 3600 Terminal Koncentrator. I RC systemer er
I/O styreenheden naturligt implementeret som et knudepunkt ved
hjælp af net-styre-programmet (NCP). Dette program befinder sig
dels i RC 8000>s interne lager og dels i I/O styreenheden. Når et
IBM datamatsystem eller et terminalsystem forbindes med RC NET,
bruges RC 3600 Minidatamaten som forbindelsesled til nettet.\f

F_ 7 NOGLE TYPISKE RC 8000 APPLIKATIONER

Indtil videre er der blevet gjort rede for basisstrukturen, og de
vidtrækkende muligheder RC 8000 Systemet indeholder. For at vende
tilbage til det, det virkelig drejer sig om - at få tingene ud-
ført hurtigt og pålideligt - vil dette skrift blive afsluttet med
en beskrivelse af nogle typiske brugersystemer af forskellig
størrelse, med forskellige formål og kapacitet, - alle baseret på
RC 8000 Systemet. Det vil forhåbentlig gøre de måske noget vage
beskrivelser i de foregående kapitler mere konkrete.

Selvom de er typiske, viser de tre nedenfor nævnte eksempler kun
en lille del af RC 8000 Systemets mange applikationsmuligheder *).
RC 8000 er f.eks. også blevet brugt med succes til on-line pro-
duktionsstyring, tekniske beregninger og som front-end-system for
store datamatcentre.

7.1 Et mindre Regnskabs- og Produktionsstyringssystem

En mellemstor produktionsvirksomhed ekspanderer hastigt, og som
følge deraf står firmaet over for voksende administrative proble-
mer. Salget er meget sæsonbetonet, hvilket kræver en omhyggelig
salgs- og produktionsplanlægning.

Et RC 8000 System overtager gradvist regnskabsstyringen, budget-
planlægningen, lønadministrationen samt produktions- og lagersty-
ringen. Alle applikationsprogrammer er leveret af RC og baseret
på standardsystemerne (beskrevet i kapitel 6).

En vigtig del af regnskabssystemet er ordrekontrollen. 150-200
telefonordrer bliver dagligt registreret via terminaler. Leve-
ringstidspunktet bestemmes udfra et slutprodukt-lager-system med
4 forskellige lagertyper. Fabrikslageret opererer med en 13 ugers
horisont med hensyn til produktionsplaner, reservationer og aktu-
elle lagerbeholdninger. Ordrebekræftelser og følgesedler udskri-
ves automatisk. Faktureringssystemet registrerer de faktiske le-
veringer og udskriver restordrer, hvis det er nødvendigt - og de
tilhørende konto- og lagerlister bliver opdateret. De 2300 kun-
der er registreret i debitorsystemet. Der bruges et bogholderi-
system med åbne posteringer (open-item) for hver debitor. Regn-
skabssystemet har en tredimensionel kontoregistrering, der opere-
rer med kontonummer, organisationsenhed og projektnummer som pa-
rametre.

*) Produktudviklingen medfører løbende forbedringer, nogle af pro-
dukteksemplerne vil således idag være substitueret med nye produkter.\f

Budgetsystemet omfatter rullende budgetter med en horisont på fem
kvartaler og langtids årsbudgetter. Budgetterne indgår i regn-
skabssystemet og danner basis for salgs-styringssystemet.

De ca. 100 ansatte i firmaet er registreret i lønningssystemet.
Foruden de almindelige lønningsberegninger tager systemet sig af
kontrakt- og bonussystemer, dokumentation til brug for skatte-
myndighederne og beregning af indirekte lønningsomkostninger.

Det avancerede ordre-registreringssystem giver en yderst effektiv
produktionsstyring. Dette opnås ved hjælp af RC Produktions- og
Lagerstyringssystem. Alle råmaterialer og halvfabrikata, der sam-
les til 300 forskellige slutprodukter, bliver registreret her.
Systemet bruges til planlægning af produktindkøb, optimering af
lagre, mand-maskin belastningsanalyser for produktionen, samt
beregning og styring af produktionsomkostninger.
T_

Alle disse funktioner udføres af den ovenfor viste konfiguration.
Systemet omfatter en RC 8000 Centralenhed model 25, 64 Kord in-
ternt lager, to RC 8223 33 Mbyte Pladelagermoduler og en RC 8301
I/O Styreenhed. Der er forbundet en RC 830 Operatørkonsol, 4 RC\f

822 Dataskærme og en RC 3641 300 lpm Linieskriver til I/O styre-
enheden.
T_

7.2Et Servicecentersystem

Det næste eksempel viser et RC 8000 System, hvor adskillige bru-
gere arbejder uafhængigt af hinanden. Det kunne være et stort
selskab med mange afdelinger, eller, som i dette tilfælde, et
servicecenter, der sælger edb-service til en række uafhængige
&_selskaber.

Den service, der her tilbydes, er en del af det økonomiske sty-
ringssystem, nemlig on-line debitorfakturering, kreditor-, ordre-
og lagerstyring. Input til systemet bliver indlæst fra terminaler
hos brugerne. Fakturaer bliver så umiddelbart genereret, og der
foretages automatisk opdatering af lager, ligesom kreditgrænse
kontrolleres etc. Faktureringer såvel som forespørgsler angående
lager, debitorer, ordre-reserveringer og lignende foretages tids-
tro i løbet af dagen, hvorimod de daglige fakturajournaler og
andre oversigter bliver kørt om aftenen, gruppevis.

Størrelsen og kompleksiteten af terminalsystemerne afhænger af
kundernes behov. Den mest enkle konfiguration er en enkelt data-
skærmterminal, som f.eks. RC 822, hvorfra input indtastes til
systemet. Udskrifter samles i servicecentret og sendes pr. post.

Det næste trin vil være en RC 822 Dataskærm og en RC 866 Matrix
Skriver på et enkelt modem. For at opnå større transmissions ka-
pacitet kan de to enheder forbindes til et modem hver. Output kan
så modtages til stadighed, uafhængigt af input-aktiviteterne,
hvilket selvfølgelig ikke er muligt med dataskærm og skriver på
samme linie.

En kunde har to dataskærmterminaler og en skriver. En terminal er
placeret på ordrekontoret og den anden terminal og skriveren i
lagerbygningen. Fakturaer bliver genereret fra begge terminaler
og udskrevet på skriveren.

Disse simple terminalsystemer er forbundet til servicecentret via
modemer; sendehastigheden er normalt 300 bps (bit pr. sek.) for
terminalerne og 1200 bps for skriverne. Figuren nedenfor viser de
i teksten omtalte terminalfigurationer.\f

Nogle kunder har brug for adskillige terminaler og skrivere til
at klare deres aktiviteter. En af disse kunder har 2 RC 822 Ter-
minaler og en RC 3637 Matrix Skriver forbundet til en RC 800/2
Terminalkoncentrator. En anden kunde har en RC 800/3 Koncentrator
med 4 terminaler og en skriver. Begge systemer er tilsluttet ser-
vicecentret via 2400 bps linier.

En meget stor kunde har brug for 10 terminaler og 4 linieskrive-
re. Disse enheder er forbundet til en RC 800/22 Koncentrator, der
er tilsluttet servicecentret via en 9600 bps linie.

Sidst men ikke mindst, er en RC 3600 Minidatamat indsat som knude-
punkt i et RC NET, hvor den bruges som koncentrator for 5 forskel-
lige kunder med hver en terminal og en skriver.

Alt i alt er der 24 kunder med 41 terminaler og 25 linieskrivere
tilsluttet RC 8000 Systemet. Hele systemet omfatter en RC 8000\f

Centralenhed model 45, 128 Kord internt lager, en pladelagerka-
nalenhed med 4 RC 8224 66 Mbyte Pladelagermoduler og 2 8301 I/O
Styreenheder.
T_

Der er brugt en I/O Styreenhed til 16 synkrone transmissionslini-
er og de ydre enheder i servicecentret. De ydre enheder er: 1 RC
830 Operatørkonsol, 2 RC 3616 Magnetbånds stationer til registre-
rings formål og 1 RC 3642 600 lpm Linieskriver, der bruges til
udskrivning af kundeformularer.

Den anden RC 8301 I/O Styreenhed har 1 RC 830 Operatørkonsol og
tager sig af 8 asynkrone og 4 synkrone transmissionslinier. Denne
enhed er samtidig knudepunkt i den omtalte RC NET-struktur og gør
det dermed muligt for kunderne at udnytte de andre servicesy-
stemer, der kører på andre datamater i servicecentret. \f

T_7.3 Telefonoplysningssystem

Dette sidste eksempel viser, hvordan et RC 8000 System til speci-
al formål kan integreres i en større edb-sammenhæng. Ved hjælp af
det selvstyrende net - RC NET - kan flere hoveddatamater forbin-
des, således at de enkelte opgaver kan løses med et minimum af
samspil med andre systemer og med et maximum af sikkerhed.
&_
Et telefonselskab, der nu dækker 700.000 abonnenter, indførte i
1967 elektronisk databehandling med købet af 2 RC-GIER Datamater.
De udskrev regninger til abonnenter, lønningssedler til de an-
satte etc. i gruppekørsel. Omkring 1970 begyndte planlægningen af
et udvidet datamatcenter, som kunne tage sig af selskabets hele
administrative databehandling, dels on-line, dels ved gruppekør-
sel. Der blev bestilt et større system hos en af de større edb-
producenter. Man forventede, at systemet også havde kapacitet nok
til at klare et oplysningssystem, OP-system.

Det administrative on-line system krævede, at der var grupper af
dataskærmterminaler og serielt koblede skrivere i hver af de 4
administrative regioner. Disse skulle forbindes til det centrale
samlingssted via et højhastighed stjerneformet net, som også
skulle kunne klare OP-systemer og andre fremtidige systemer.

Nettet og terminalsystemet blev betragtet som hvilende i sig
selv, logisk adskilt fra hovedsystemerne. RC NET blev valgt til
denne del af systemet.

Oplysningssystemet blev udviklet parallelt med det administrative
system. I 1974 blev resultaterne fra et forundersøgelsesprojekt
vurderet. 12-13% af forespørgslerne blev besvaret forkert, eller
slet ikke besvaret, og den gennemsnitlige svartid var på ca. 7
sek.

Man indså at en fuldt gennemført implementering af OP-systemet,
hvis det overhovedet var muligt, ville kræve hele hoveddatamatens
kapacitet. Denne hoveddatamat, som også skulle tage sig af det
administrative system, egnede sig simpelthen ikke til et OP-sy-
stem.

Selskabet reagerede ved at opstille nogle specifikationer for et
separat OP-system og opfordrede en lang række leverandører til at
afgive tilbud. De bedste testresultater blandt de tilbudsgivende
blev opnået af RC, og der blev skrevet kontrakt med RC. I 1977
kørte systemet med to RC 8000 Datamater, som kostede 1/5 af den
oprindeligt indkøbte hoveddatamat.\f

Et af de traditionelle krav i telefonbranchen er en høj grad af
pålidelighed, og skønt RC 8000 er en meget pålidelig datamat,
blev der lavet et tvillingesystem for at sikre, at systemet kunne
være i drift 99% af tiden. Under normale forhold kører den ene RC
8000 OP-systemet, mens den anden opdaterer databaserne. I til-
fælde af svigt i den enhed der kører OP-systemet, vil den enhed,
der opdaterer, blive frigjort, og OP-systemet genstartet på den
indenfor 5 minutter.

Hver RC 8000 har 3 66 Mbyte pladelagermoduler. Det ene modul
bruges til programmelsystemer og registreringsformål, det andet
modul til en komplet abonnentdatabase og det tredie modul til en
række "omvendte" databaser, hvor abonnenterne er arrangeret i
overensstemmelse med søgeparametre, som f.eks. navn, erhverv,
o.s.v.\f

Hoveddatabasen for abonnenter indeholder yderst detaillerede op-
lysninger om de 700.000 abonnenter. Den indeholder ikke alene op-
lysninger om telefonnummer, men også oplysninger om åbningstider,
privatadresse, postadresse, etc. Databasen er derfor velegnet som
input til datamatstyret sætning af telefonbøger.

RC 8000 OP-Systemet kan søge ud fra en kombination af fornavn,
efternavn, stilling og nøjagtig eller omtrentlig adresse for de
700.000 abonnenter. Forskellige måder at stave på bliver der også
taget hensyn til, når udvalget af abonnenter, der passer til be-
skrivelsen, præsenteres for operatøren på terminalen. Systemet
har en arbejdskapacitet på 12.000 forespørgsler i timen; den gen-
nemsnitlige responstid er 0,7 sek., kun 2% overstiger 3 sek., og
max. responstid er 4,5 sek.

De to RC 8000 Systemer har to I/O styreenheder; den ene er forbe-
holdt nettet og fungerer som et knudepunkt, der dirigerer data
indenfor nettet, såvel som mellem de to RC 8000 Systemer. Den an-
den I/O styreenhed bruges til de ydre faciliteter såsom magnet-
båndstation, linieskriver, strimmel-/hulkortlæser og konsol. Det
samlede system indeholder faktisk en tredie RC 8000 parallelt med
de to andre; den tredie enhed bruges til programudvikling, bereg-
ninger, etc.

Nettet er opbygget med RC 3600 Minidatamater, der fungerer som
terminalkoncentratorer, netknudepunkter og hoveddatamat-forbin-
delser. På det centrale behandlingssted er knudepunkterne direkte
forbundet med I/O kanaler, der har en transmissionsrate på 5
Mbps. De fire fjernt beliggende administrative centre er koblet
til det centrale behandlingssted via et stjerneformet net, der
består af 5 48 Kbps transmissionslinier, der alle drives af en
enkelt RC 3600.

Århus er det største beboelsesområde, og derfor bruges der to 48
Kbps linier til dette kontor. Den direkte forbindelse mellem dis-
se to RC 3600>er er etableret som ekstra sikkerhed; hvis den ene
af de to transmissionslinier er ude af drift, kan al trafik om-
dirigeres til den anden linie. Åbenråkontoret tilhører i virke-
ligheden et andet selskab, men de to selskaber har i nogen ud-
strækning fælles administration. Åbenråkontoret er derfor for-
bundet via en 48 Kbps linie til Koldingkontoret, der fungerer som
knudepunkt i nettet og dirigerer data til det centrale behand-
lingssted.\f

F_ Tegning (side 44)\f

F_ Tegning (Det Centrale Behandlingssted)

De to datamatsystemer, OP- og administrationssystemet, bliver via
nettet betjent fra næsten 200 terminaler. "OP" og "Adm" termina-
lerne er dataskærmterminaler med specielt udviklet tastatur til
disse applikationer. 160 af disse terminaler, leveret af RC, er
fordelt på de 5 distriktskontorer og hovedkontoret. 7 OP termina-
ler på hovedkontoret bruges midlertidigt til konversion fra det
hidtidige manuelle system til de nye edb terminalsystemer. Resten
af terminalerne, kaldet "Prog", er almindelige dataskærmtermina-
ler, der bruges til andre applikationer under tidsdelingssystemet\f

på den administrative systemdatamat og den tredie RC 8000. Disse
applikationer omfatter programudvikling og vedligeholdelse, tek-
T_niske beregninger, budgetsimulering og lignende.

Applikationsrapporter udsendes løbende af Regnecentralen med in-
formation om forskellige brugeres applikationer og udstyr. Har De
interesse i bestemte emneområder, kan Deres RC-kontaktperson sik-
&_kert hjælpe Dem, - spørg venligst. \f

F_ TERMINAL

H_A_N_D_L_I_N_G_Input fra brugerK_O_M_M_E_N_T_A_R_
"Output" fra systemet

Login att - boss BOSS anerkender
procedure"type user name and projectLOGIN ved at re-
number"turnere tid og
btj 308sted. Vi er nu
"in: 1977.08.21 15.46"tilsluttet.

Sammensætning 10 p = algol ALGOL kilde-
af job, redige- 20 begin real a,b; tekst.
ring.30 write(out,a b); Hver linie be-
40 end gynder med et
50 p identifika-
60 2 10 tionsnummer.
1000 finis

25 read(in,a,b); En manglende
linie bliver
indsat efter
identifika-
tionsnummer.

Jobtilmelding go BOSS returnerer
"finis btj0 at 15.52"formodet slut-
tid.

Joboutput "begin" Output fra
"algol end 16" ALGOL oversæt-
"10.2400'2" ter.
"end 16"Output fra Ob-
ject-program.

Jobslut "end job btj 4 sec log ms BOSS returnerer
date 1977.08.21kørselstid og
15.51.00" sluttid.

«eof»

DataMuseum.dk

CP/M

⟦59eb16111⟧ TextFile

Derivation

TextFile