⟦4cf43849b⟧

TextFile

F_O_R_E_W_O_R_D_

First edition: RCSL No 31-D482.

Second edition: RCSL No 31-D512.
This manual describes the operating system SOS, as it appears in
release 2.0, October 1978. The former version was a preliminary
version intended for multiterminal jobs. The present version in-
cludes interactive multiterminal jobs (using TEM), interactive
single terminal jobs (with or without using TEM) and batch jobs.
The present version supports in a primitive form access to de-
vices like tape stations and flexible discs.

This manual is an exhaustive description of SOS and it includes
subjects of interest to users, programmers, operators and instal-
lation staff.

Niels Møller Jørgensen
A/S REGNECENTRALEN, September 1978

Third edition: RCSL No 31-D662.
The changes are indicated by correction lines in the left margin
and concern mainly the description of the new facility for typing
invisible password.

Edith Rosenberg
A/S REGNECENTRALEN af 1979, October 1981

ii
\f

iii

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

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

2. USER'S Guide ........................................... 4
2.1 SOS Illustrated by Means of Examples .............. 4
2.2 SOS User Commands ................................. 13
2.2.1 Job Creation Commands ...................... 14
2.2.2 Multiterminal Commands ..................... 15
2.2.3 Job Intervention Commands .................. 17
2.2.4 Device Handling Commands ................... 18
2.2.5 Password ................................... 19
2.3 Terminal Access ................................... 20
2.4 Resource Allocated to SOS Jobs .................... 21

3. REFERENCE INFORMATION .................................. 22
3.1 Job Scheduling .................................... 22
3.2 Terminal Access ................................... 25
3.3 SOS - Job Intercommunication ...................... 26
3.3.1 Primary Input and Output ................... 27
3.3.2 Transparent Communication to TEM ........... 28
3.3.3 Parent Messages ............................ 30

4. OPERATING GUIDE ........................................ 33
4.1 Start-Up .......................................... 33
4.2 Operator Intervention ............................. 34
4.2.1 System Intervention ........................ 34
4.2.2 Job Intervention ........................... 35
4.2.3 Device Support ............................. 36
4.3 Close Down ........................................ 37
4.4 How to Handle System Failure ...................... 37

5. INSTALLATION NOTES ..................................... 40
5.1 System Distribution ............................... 40
5.2 System Trimming ................................... 41
5.3 User Catalog ...................................... 48
5.3.1 Data per Job (Process) ..................... 49 \f

T_A_B_L_E_ _O_F_ _C_O_N_T_E_N_T_S_ _(_c_o_n_t_i_n_u_e_d_)_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _P_A_G_E_

5.3.2 Creation and Change of the User Catalog .... 50
5.3.2.1 Creation .......................... 51
5.3.2.2 Change ............................ 53
5.3.2.3 Listing ........................... 55
5.3.3 Resources Needed for Creating a Catalog .... 55
5.3.4 Error Messages ............................. 56
5.4 Test Facilities ................................... 59

A_P_P_E_N_D_I_C_E_S_:

A. REFERENCES ............................................. 63

B. SOS COMMANDS ........................................... 64

C. MESSAGES FROM SOS ...................................... 65

D. AN EXAMPLE OF A MULTITERMINAL PROGRAM .................. 71

E. EXAMPLE OF A USER CATALOG .............................. 72

F. THE AUXILIARY FILE "sostrim" ........................... 73

G. THREE VERSIONS OF A MASTER MIND PROGRAM ................ 75
G.1 Simple Single Terminal Version .................... 75
G.2 Single Terminal Version with Input Checking ....... 76
G.3 Multiterminal Version with Input Checking ......... 77

H. INDEX .................................................. 78
H.1 Survey of Examples ................................ 78

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

The main purpose of an operating system is to serve the users by
supervising the execution of their programs. In a multiprogram-
ming environment with a number of users running their programs
simultaneously the main tasks include:

1) facilitate resource sharing
2) control and facilitate the access to common equipment
3) prevent unauthorized access to private information

In the case of RC8000 the supervisory functions are performed by
the monitor (ref. 1). The resources of the computer may be par-
titioned into so-called processes. A process is a set of re-
sources used for program execution. In each process programs may
be executed one at a time. A process may play the role of an
operating system by creating and controlling child processes ac-
cording to some strategy.

SOS is an operating system process and each user logged in is
served by a child process, created by SOS.

In many computer systems the primary store is a key resource. To
obtain a good machine utilization it is important that key re-
sources are released, when they are not actively used.

At interactive program execution there will be long periods du-
ring which the process waits for the terminal operator to type
some input. In case no resources are released during these per-
iods, the machine utilization will become prohibitively poor.

The main purpose of SOS is to make a number of programs (pri-
marily interactive programs) share the same part of primary
store. This is done by supervising the program execution and by
swopping programs (writing the primary store to backing store
during passive periods).

SOS is mainly intended for supporting interactive program exe-
cution. However, SOS includes facilities for executing batch\f

jobs, too, and the resource scheduling is based on the following
elements:

A series of programs executed in the same process one after the
other is called a "job".

a) Any job running under SOS is in one of the following
states:
1) running
2) suspended (ready to run, but the primary store is
occupied by another job)
3) waiting (the job is not ready to run - e.g. waiting for
terminal input)

b) Execution time is allocated in slices (of a few seconds).
In case a job does not suspend itself within a time slice
it will be suspended by SOS.

c) Highly interactive jobs will be favoured by a high prior-
ity, while more CPU-bound jobs will get descreased prior-
ity. The time slices are allocated according to the prior-
ities of all jobs which are ready to run.

d) Batch (or background) jobs are activated only during pe-
riods where no interactive jobs are ready to run, and a
running batch job is stopped immediately when some inter-
active job becomes ready for activation (for instance when
input arrives from a terminal).

In RC8000 any program (utility or user defined program) is ex-
ecuted in a so-called "process", no matter the operating system
controlling the execution. Thus the access to the basic computing
facilities (CPU, primary store and backing store) is not affected
by the actual operating system, and all utility programs like
compilers, editor, catalog handling programs etc. may be used
under SOS exactly as under S or BOSS.

However, SOS does not allow full and direct access to slow de-
vices like printers, paper tape readers etc. This is so because\f

the resources occupied by programs using slow devices are often
poorly utilized - it is extremly inconvenient if interactive pro-
grams are blocked by programs using slow devices.

The use of slow devices is assumed to be undertaken by service
modules like the printing module (PRIMO) or the file router.

F_ 2_._ _ _ _ _ _ _ _ _U_S_E_R_'_S_ _G_U_I_D_E_ 2.

The present chapter illustrates by means of examples some of the
facilities offered by SOS. All facilities of SOS are described in
detail in later sections. According to the intentions of SOS the
examples mainly concern interactive program execution.

2_._1_ _ _ _ _ _ _ _S_O_S_ _I_l_l_u_s_t_r_a_t_e_d_ _b_y_ _M_e_a_n_s_ _o_f_ _E_x_a_m_p_l_e_s_ 2.1

Job creation.

SOS is always accessed from a terminal and a session is initiated
by a "job creation". At job creation SOS consults the user cata-
log to check that the user is allowed to use the system and to
know how much resources shall be allocated to him. The job crea-
tion is initiated by pushing the attention key. The user is then
asked for the name of the system, he is going to use. In case of
SOS the user will be answered by a ">" and then he may type his
command. (In the examples all output written on the terminal is
printed with capital letters while terminal input is printed with
small letters. @ denotes a push on the attention key).

@
ATT sos
> go rc pass nn
02.06 SOS: RC ENROLLED

Example 1: Job creation.

The command (go) creates a set of resources (a process) with the
name "rc" and initiates this process by loading the file proces-
sor FP (see ref. 3). In this example a password ("nn") is de-
manded to create the job "rc".

When a user has started a session by creating a job as explained
in the former, his next command(s) will be interpreted by FP and
he will be able to run the utility programs interactively.
\f

M_ claim

AREA 24 BUF 25 SIZE 60416 FIRST CORE 65268

DISC: 21 SEGM/SLICE
TEMP 504 SEGM 18 ENTR
LOGIN 315 SEGM 5 ENTR
P_ PERM 315 SEGM 5 ENTR

Example 2: Executing utility program.

Simple program development.
The present part of the chapter primarily deals with interactive
program development (typing and debugging), and readers who are
not familiar with or not interested in program development, may
skip this section and continue at "execution of interactive
programs".

Assume that some user wants to exercise his mind by playing the
"master mind" game. Then he needs someone to set up random com-
binations and to answer his guesses. He realizes that in case he
could write a program enabling the computer to do the job, he
would have the fastest, most reliable and most patient player
ever seen.

After some thinking the user has created a program in his mind
(and on a piece of paper) and he wants to debug it. First of all
he must type in the program text. This is done by using the
utility program "edit".
\f

M_ mastertxt=edit
EDIT BEGIN.
i/
begin
integer array solution,guess(1:4);
integer i,j,x,digitok,digitincluded;

setcombination:
for i:=1 step 1 until 4 do
begin
random(x);
solution(i):=x mod 10;
for j:=1 step 1 until i do
if solution(i) = solytion(j) and i <> j then i:=i-1;
end;
write(out,<:master mind program ready<10>:>);

next:
setposition(out,0,0);
write(out,<: :>);
for i:=1step 1 until 4 do read(in;guess(i));
digitok:=digitincluded:=0;
for i:=1 step 1 until 4 do
begin
for j:=1 step 1 until 4 do
if guess(i) = solution(j) then
begin
if i=j then digitok:=digitok+1
else digitincluded:=digitincluded+1;
end;
write(out,<<dd>,guess(i));
end;
write(out,<: => :>,false add 43,digitok,
false add 32,4-digitok,
false add 45,digitincluded,
false add 10,1);
if digitok <4 then goto next else
begin
write (out,<:you got it !!<10>:>);
goto setcombination;
end;
/,
f
P_ EDIT END.

Example 3: Creating a text file.
\f

Now the program text has been created and stored in the file
"mastertxt". To save the text for later use it may be permanented
by means of the utility program "scope":

M_ scope user mastertxt
lookup mastertxt
MASTERTXT =SET 2 DISC D.780930.0207 0 0 0 0 ; USER
P_ ; 1886 135 3 810 819

Example 4: Executing utility programs.

After this the program may be translated by calling the ALGOL
compiler.

M_ masterprog = algol mastertxt

MASTERTXT D.780930.0207
1:BEGIN

37:END;
6. LINE 10 . 3 UNDECLARED
LINE 16 . 6 TERMINATION
LINE 16 . 8 DELIMITER
P_ ALGOL END 22

Example 5: Program translation.

The errors detected by the compiler may be corrected by means of
the editor, like this:

M_ newmaster = edit mastertxt
EDIT BEGIN.
1./solytion/, r/solyt/solut/
IF SOLUTION(I) = SOLUTION(J) AND I <> J THEN I:=I-1;
1./read(in;/
FOR I:=1 STEP 1 UNTIL 4 DO READ(IN;GUESS(I));
r/in;/in,/
FOR I:=1 STEP 1 UNTIL 4 DO READ(IN,GUESS(I));
f
EDIT END.
mastertxt=move newmaster
masterprog = algol mastertxt

MASTERTXT D.780930.0217
1:BEGIN

37:END;
P_ ALGOL END 25

Example 6: Text editing.
\f

The corrected version of the program is translated and in case
the translation was successful the next step will be to run the
program.

Execution of interactive programs.
All programs (utility or user defined) are activated by the file
processor which reads the job control commands (program calls)
loads the actual programs and hands over eventual parameters. The
master mind program just created uses no parameters and it may be
executed like this:

M_ masterprog
MASTER MIND PROGRAM READY
0 1 2 3
0 1 2 3 => --
4 5 6 7
4 5 6 7 => -
1 0 7 8
1 0 7 8 => ---
7 9 1 0
7 9 1 0 => + -
7 8 0 2
7 8 0 2 => ---
6 2 8 0
6 2 8 0 => ++
3 7 8 0
3 7 8 0 => ++++
YOU GOT IT !!
P_ MASTER MIND PROGRAM READY

Example 7: Execution of interactive program.

The master mind program is by its nature an interactive program
as it would not be possible to prepare the input (guesses) in
advance - each new input will depend on all answers written by
the program.
\f

The program developed will never terminate. When the user reaches
the solution the program will generate a new one and try again.
The only way to escape is to make a job intervention. To remove
the job the user may proceed like this:

M_ @
ATT sos

>kill
02.23 SOS: READY
P_ 02.23 SOS: RC REMOVED AFTER USER KILL

Example 8: Job intervention.

Job termination.
However, most programs will terminate, and the usual way to close
a terminal session is by calling the utility program "finis".
This program tells SOS that the job has finished and the re-
sources allocated may be released.

M_ finis
P_ 02.24 SOS: RC REMOVED AFTER FINIS

Example 9: Job termination.

The master mind program may be changed in different ways. In ap-
pendix G is shown two new versions. One of them is a single ter-
minal version performing input check. The other one is a multi-
terminal version based on the context facility of ALGOL and ac-
cessing the terminals via TEM.

Accessing a Multiterminal Program.
A Multiterminal version of the mastermind program (as shown in
appendix G) may be accessed from a terminal by using the multi-\f

terminal "login" and "logout" facilities of SOS. The session may
look like this (the program is executed in the job "team"):

M_ @
ATT sos

>in team usera pass a1
02.52 SOS: TERMINAL CONNECTED

FROM TEM
MASTER MIND PROGRAM READY
0 1 2 3
0 1 2 3 = > -
4 5 6 7
4 5 6 7 => -
8 9 1 5
8 9 1 5 => + --
9 8 2 5
9 8 2 5 => ++ -
9 3 8 5
9 3 8 5 => ++++
YOU GOT IT !!
P_ MASTER MIND PROGRAM READY

Example 10: Running a multiterminal program.

Automatic Program Activation.
In the examples shown so far the user has controlled his activ-
ities by calling the programs one by one. In case a user from
time to time runs exactly the same set of programs exactly the
same way, he may get his programs activated automatically. This
may be done by stating in the user catalog a set of commands that
will be interpreted at login.
\f

Some service functions may be implemented by executing automati-
cally activated programs. A program, listing the jobs currently
enrolled, might be run this way:

M_ @
ATT sos

>run display

FROM TEM
02.25 SOS: DISPLAY ENROLLED

DISPLAY AF SOS DEN 78 09 30 KL. 2.25
CLAIM:
NAVN START RØRT CPU SIZE BUF AREA
RCSAVE 02.24 02.24 0.0 75264 3 6
TEAM 02.25 02.25 0.0 75264 3 6
DISPLAY 02.25 02.25 0.1 12800 3 5

END 21
P_ 02.25 SOS: DISPLAY REMOVED AFTER FINIS

Example 11: Automatic program activation.

Running batch jobs
A number of activities are not suited for interactive execution.
Often these activities are running for a long time without any
communication with the user. Programs generating safety copies,
translation of large systems or large database reorganizations
are all examples of typical batch programs. Under SOS, batch
programs may be executed, too. However, batch programs will never
be activated when interactive programs are ready for running.
\f

A user who wants to "save" his files on a magnetic tape may do
like this:

M_ @
ATT sos

>batch rcsave
02.27 SOS: RCSAVE ENROLLED
save mtlk0001.1.label.private tsos ttem

NO DUMPLABEL ON FILE 1
WRITTEN: DUMP MTLK0001 001 VERS. 300978.02 S=1 PRIVATE

TSOS 144 PROJECT.DISC D.780929.2137
TTEM 67 PROJECT.DISC D.780926.2015
2 ENTR., 211 SEGM.

WRITTEN: DUMP MTLK0001 002 EMPTY 300978.02 PRIVATE

END 75
finis
P_ 02.29 SOS: RCSAVE REMOVED AFTER FINIS

Example 12: Running a batch job from a terminal.

In case many interactive users are active in the system or in
case the user saves many large files he will have to spend rather
a long time between the "save-command" and the "finis command".

Instead he might prepare the whole job by creating a jobfile with
the same contents:

M_ savejob=edit
EDIT BEGIN
i/
save mtlk0001.1.label.private tsos ttem
finis
/,f
EDIT END.
P_ scope project savejob

Example 13: Creating a job file.

The whole job may now be executed using this jobfile. By doing
so, the user does not have to stay at the terminal during the
run.
\f

M_ @
ATT sos

>batch rc jobfile savejob pass nn
02.32 SOS: RC ENROLLED

READ : DUMP MTLK0001 001 VERS. 300978.02 S=1 PRIVATE

WRITTEN: DUMP MTLK0001 001 VERS. 300978.02 S=1 PRIVATE

TSOS 147 USER.DISC D.780930.0137
TTEM 67 PROJEKT.DISC D.780926.2015
2 ENTR., 214 SEGM.

WRITTEN: DUMP MTLK0001 002 EMPTY 300978.02 PRIVATE

END 75
P_ 02.34 SOS: RC REMOVED AFTER FINIS

Example 14: Running a job using a job file.

Often it would be more convenient if output from batch jobs were
printed on a line printer. This may be done by using the service
module PRIMO (see ref. 5). The output is currently written into
a backing storage file and at job termination, PRIMO is asked to
print the file.

M_ savejob=edit
EDIT BEGIN
i/
o outfile
save mtlk0001.1.label.private tsos ttem
o c
scope user outfile
filexfer outfile lp queue.paper.a4
finis
/,f
P_ EDIT END

Example 15: Job file routing job output to printer.

2_._2_ _ _ _ _ _ _ _S_O_S_ _U_s_e_r_ _C_o_m_m_a_n_d_s_ 2.2

In this section all SOS user commands are described, their syntax
and their semantics. The commands are grouped according to their
functions. In chapter 4 of this manual (the Operating Guide) the
SOS commands used at operator intervention are described. In case\f

the system is run by the users themselves at least some of the
users will have to know how to use these operator intervention
commands.

2_._2_._1_ _ _ _ _ _J_o_b_ _C_r_e_a_t_i_o_n_ _C_o_m_m_a_n_d_s_ 2.2.1

SOS has three different job creation commands: "go", "run" and
"batch". The syntax for the job creation commands is:

M_m_m_ go 1
run <jobname> jobfile <filename>
P_p_p_ batch 0

M_m_m_ 1 1
pass <password> newpass <password>
P_p_p_ 0 0

See examples 1, 11, 12 and 14.

Each of these commands will create a job (a process) with a set
of resources as described in the user catalog. A job started by
the "go" or the "run"-command will be scheduled as an interactive
job while a "batch" job will be scheduled as a background job
(i.e. a "batch" job may only be active during periods where no
"go" or "run" jobs are ready for activation).

The difference between the "go" and the "run" commands concerns
the handling of the terminal only. In case of a "run" command the
terminal is connected via TEM (see ref. 4), offering output
spooling. In case of a "go" command, the terminal is accessed by
SOS directly - and no spooling is offered. At "batch" jobs, the
terminal is always accessed by SOS directly (as at "go").

The "jobfile" option enables the user to prepare his job by
creating a (permanent) file containing all program calls etc.
necessary for the execution of his job. The jobfile is said to be
the primary input document of the job. At jobs not using the job-
file option, the terminal is the primary input document. In all
cases the terminal is the primary output document of the job.
\f

To avoid confusion, SOS will not accept that a given terminal is
the primary input document of more than one job at a time. How-
ever, the same terminal may be the primary output document of
several jobs.

In other words, several jobs may be started from the same termi-
nal (and run simultaneously), but at most one of these jobs may
be created without using the jobfile option.

In the description of a process (a job) in the user catalog a
field defining a password is included. In case this password is
nonempty, the job creation will not be accepted unless the com-
mand includes: pass <password>. This facility is included to
check the authorization of the user and to grant privacy. An im-
proved security may be obtained by redefining the password. This
may be done by using the "newpass" option. By means of this op-
tion, the password may be changed at startup like this:

... pass hobo newpass hifi

(if the password of a process has become empty, it is not pos-
sible by the newpass option to create a password - thus "public"
jobs using no password cannot be blocked by a user defining a new
password).

2_._2_._2_ _ _ _ _ _M_u_l_t_i_t_e_r_m_i_n_a_l_ _C_o_m_m_a_n_d_s_ 2.2.2

Jobs running multiterminal programs may use TEM (see ref. 4)
directly (i.e. transparently via SOS). In any case the job must
ask TEM to create a terminal group (pool) and then the terminals
may be connected to the group (i.e. links are created to the ter-
minals). The terminal connections may be established or removed
by the program explicitly asking TEM to create or remove the
links. Principally the same job may be performed by SOS using the
multiterminal commands "in" and "out".
\f

A user who wants to be serviced by a multiterminal job may get
connected by using the "in" command:

M_m_m_ 1 1
in <jobname> <username> pass <password> newpass <password>
P_p_p_ 0 0

See example 10.

SOS then consults the user catalog to check that the jobdescrip-
tion according to <jobname> includes a user description with the
name <username>.

The password and newpass options may be used here exactly as at
the job creation commands.

After having connected the terminal, SOS generates a special in-
put line and hands it to the multiterminal job. This input line
is generated to tell the job that a new terminal has "logged in".

When the terminal user wants to leave the job, he may use the
"out" command:

out

This command causes SOS to generate a special input line (as at
"in") to tell the multiterminal job that the terminal "logs out".
The exact contents of the input lines generated at "in" and
"out" may be found in chapter 3 (the Reference Part).

2_._2_._3_ _ _ _ _ _J_o_b_ _I_n_t_e_r_v_e_n_t_i_o_n_ _C_o_m_m_a_n_d_s_ 2.2.3

SOS includes a set of job intervention commands enabling the user
to control his job fully. The commands are:

stop
M_m_m_ start 1
<jobname>
P_p_p_ break 0
kill

See example 8.

The <jobname> must be stated in case the actual job is created
using the "jobfile" option. In other words: if the terminal is
the primary input document of the job, the <jobname> is not
necessary.

In any case the job intervened must be created from the terminal
that is used for the job intervention.

The "stop" command is used to suspend a job during execution. SOS
will suspend the job in such a way that it will be possible to
resume the job execution later on (in case input/output to or via
SOS is programmed in a nonstandard way, data may be lost because
of the intervention, but programs using standard I/O should con-
tinue unaffectedly).

The "start" command is used to activate suspended jobs. The
suspension may be caused by a "stop" command, a "pause" parent
message (see chapter 3) or the like.

The "break" command is used to interrupt a (possibly defective)
program. SOS restarts the program in its interrupt routine,
allowing it to run for at most one time slice. (Standard programs
will use this piece of time to make some cleaning like: empty
buffers, write error message etc.) After this period SOS aborts
the job.
\f

However, SOS may be trimmed in such a way that the break command
merely works as "stop load start" when the job is enrolled with-
out a jobfile. So the user will not lose his temporary files if
he breaks a program.

The "kill" command is used to abort jobs. The actual job will be
stopped immediately and there will be no time for the job to re-
port errors or the like.

It should be mentioned here that the job intervention commands
described in this subsection also exist in a special version as
"operator commands". (The operator version of the commands is
described in chapter 4).

2_._2_._4_ _ _ _ _ _D_e_v_i_c_e_ _H_a_n_d_l_i_n_g_ _C_o_m_m_a_n_d_s_ 2.2.4

As SOS is primarily intended for interactive processing, the use
of devices (apart from backing store) must be limited to a mini-
mum. However, batch jobs will never block interactive jobs so it
is acceptable to allow batch jobs to use some kinds of devices.

The most obvious need for device access concern printing (on line
printer) and generation of safety copies on magnetic tape or
flexible disc. Printer handling is supposed to be performed by a
service module like PRIMO (printing module). Generation of back
up, however, may be done by batch jobs.

The use of magnetic tape, flexible disc and other devices with
exchangeable documents is supported by a "call" command and an
"include" command.

The "call" command looks like this:

call <deviceno> <documentname>

The function performed by the "call" command is to name a device
(specified by the device number: <devno>). After having named the
device, all jobs enrolled to SOS at present will be included as\f

users of the device. At magnetic tapes and flexible discs the de-
vice (station or drive) is usually given the name of the document
currently mounted.

In case of direct access to devices with fixed names (paper tape
punch for instance), the job will have to be included as a user
of the device. This may be done by using the "include" command:

include <deviceno>

All jobs enrolled to SOS at the moment of the inclusion will get
access to the device - but still the device may only be used
(reserved) by one job at a time.

It should be mentioned here that direct access to slow devices
like a paper tape punch may cause a poor resource utilization,
and only batch jobs should use this facility. Direct access to
slow input devices like paper tape readers will not do neither at
batch nor at online jobs.

2_._2_._5_ _ _ _ _ _P_a_s_s_w_o_r_d_ 2.2.5

Instead of typing the password as described in subsections 2.2.1
and 2.2.2, the password may be typed invisible in a separate
line.

If the password information in the login command is omitted, and
the password defined for the job in the user catalog is non-
empty, then SOS will answer by writing on the terminal:

>password

Now the password can be typed without echo on the screen, but a
possible typing error cannot be corrected by means of backspace
or rubout. The answer is delayed until a timer interrupt has
occured (about 5 seconds).

In this case the password cannot be changed by a newpass-command.
\f

So the syntax for job creation commands using invisible password
is:

go
M_m_m_ 1
run <jobname> jobfile <filename> 'nl'
P_p_p_ 0
batch

">password" <password>

where the text in " " is written by SOS.

The syntax for the "in" command becomes:

in <jobname> <username> 'nl'
">password" <password>

Note! When the terminal is the main console, the password will
n_o_t_ be invisible, neither when the console is a screen.

2_._3_ _ _ _ _ _ _ _T_e_r_m_i_n_a_l_ _A_c_c_e_s_s_ 2.3

A program executed under SOS may perform terminal access in dif-
ferent ways depending on job creation and program behaviour.

Jobs created by the "run" command will access the creating ter-
minal via SOS and TEM, using the spooling facilities of TEM. Jobs
created by "go" or "batch" commands will access the creating ter-
minal via SOS only.

Any job (created by "run", "go" or "batch" command) using the
"jobfile" option will use the creating terminal for output only.

In any case the creating terminal is usually accessed by using
the standard zones "in" and "out".

Any job may access one or more terminals via TEM by using the TEM
facilities directly (see ref. 4). However, all TEM operations\f

will be communicated via SOS, but they are handled almost trans-
parently so that the user will normally feel no change. (The dif-
ferences are described in chapter 3).

2_._4_ _ _ _ _ _ _ _R_e_s_o_u_r_c_e_s_ _A_l_l_o_c_a_t_e_d_ _t_o_ _S_O_S_ _J_o_b_s_ 2.4

According to the main intentions of SOS, the jobs should not be
slowed down by accessing slow devices (and thereby block the pri-
mary store for considerable amounts of time).

A reasonable rule for resource allocation may look like this:

A: interactive jobs ("go" or "run" jobs) should never access
peripherals slower than backing storage.
B: batch jobs should never access peripherals slower than
flexible discs or magnetic tape.
C: access to slow peripherals like printers should always be
done via a service module like "PRIMO".

As a consequence the resources described in the user catalog only
concern:

1) message buffers
2) area processes
3) backing storage entries
4) Backing storage segments

The direct use of devices (apart from backing storage) is not
supported by the job creation (or the user catalog) - the user
himself (or the operator) must use the "call" or "include" com-
mands for this purpose.

F_ 3_._ _ _ _ _ _ _ _ _R_E_F_E_R_E_N_C_E_ _I_N_F_O_R_M_A_T_I_O_N_ 3.

The present chapter contains exact descriptions of subjects and
details that most users do not have to consider. However, it may
be necessary to go into some details to understand the system
behaviour fully.

3_._1_ _ _ _ _ _ _ _J_o_b_ _S_c_h_e_d_u_l_i_n_g_ 3.1

SOS handles two kinds of jobs: interactive jobs and batch (or
background) jobs. As a consequence the job scheduling is based on
two main queues: a queue of interactive jobs and a queue of batch
jobs. These two queues contain only jobs which are ready to run.
Jobs waiting for external events like terminal input are queued
up in a waiting queue.

Only one job may be active at a time and this job is found like
this:

- If the interactive queue is not empty, then find the
"best" job and activate it.
- If the interactive queue is empty and the batch queue is
not empty, then take the first job in the batch queue and
activate it.
- If both queues are empty, then wait for an event making
some job ready for execution.

When started, a job will be allowed to run for a period that de-
pends on the kind of job.

1. An interactive job will be stopped
1) when it asks for input,
2) when its terminal output exceeds the spooling capacity,
3) when the time slice expires or
4) when the job ends - whatever happens first.
\f

2. A batch job will be stopped
1) when it asks for input,
2) when its terminal output exceeds the spooling capacity,
3) when the job ends or
4) when some event arrives that will make an interactive
job ready to run - whatever happens first.

When a batch job is stopped because of an interactive job, it
will remain the first job in the batch queue. When a batch job is
created it is put back on the batch queue. Thus the strategy of
the batch job scheduling is a pure first in first out strategy.

However, this strategy may be overwritten by users or operators
using the job intervention commands "stop" and "start". "Stop"
will move the job from the batch queue to the waiting queue.
"Start" will move the job to the batch queue but in different
ways depending on circumstances:

operator start moves the job to the head of the queue
user start puts the job back on the queue.

Interactive jobs are scheduled according to dynamically changing
priorities. Each interactive job is equipped with a "priority
class" and an actual "priority".

The priorities (and -classes) change according to the behaviour
of a job and the main rules are:

1. interaction (= terminal input) implies increasing priority

2. heavy cpu-load (= using entire time slices) implies de-
creasing priority.

An interactive job starts at the max. priority of the system
(= 0). No job will ever exceed the max. priority.
\f

In the following the main algorithms used at job scheduling are
listed:

A. An interactive job is suspended because it asks for
terminal input:

if priority _class + classgain > 0
then priority _class: = 0
else priority _class:=priority _class + classgain;
priority: = priority _class;

B. An interactive job is suspended because the time slice had
expired:

if priority _class - classloss < minprio
then abort _job
else priority _class: = priority _class-classloss;
priority: = priority _class;

C. When the "best" job is to be found in the interactive
queue, SOS proceeds like this:

job: = queue.first;
while job.priority < max _priority do
begin
job.priority: = job.priority + priogain;
put _back _on _queue (job);
job: = queue.first;
end;

thus all interactive jobs stay in the same queue no matter the
priority. However, a low priority will imply that the job will be
bypassed by other jobs a number of times before activation. Dur-
ing a cpu-bound period an interactive job will thus spend in-
creasing periods of time between its active time slices (in case
the whole system has a steady load).

3_._2_ _ _ _ _ _ _ _T_e_r_m_i_n_a_l_ _A_c_c_e_s_s_ 3.2

Terminals accessed by SOS jobs may be:

1) The primary input/output terminal from which the job was
created.

2) A number of terminals connected to a terminal group in TEM.
This terminal group must be created by the job itself.

The message flow controlling the access is described in subsec-
tions 3.3.1 and 3.3.2. In this section some conventions and li-
mitations concerning terminal access shall be mentioned.

A. Programs using terminal access under SOS must follow the stan-
dard conventions for transfer checking. The most important
rule is that input or output messages answered by an empty
answer (no data transferred) are repeated.

B. SOS jobs will never see hard errors on terminals because SOS
will automatically disconnect such a terminal. In case the
terminal was primary input terminal of a job, the job is
aborted. In case the terminal was connected to a multitermi-
nal group, it will become disconnected and the job will re-
ceive a special input telling that the terminal is discon-
nected.

C. SOS jobs may create at most one terminal group for multitermi-
nal access. This group must have the name of the terminal ac-
cess module (usually TEM). Jobs may connect a number of ter-
minals to this pool (by creating TEM-links). In case the ter-
minals are connected by the job itself, SOS is not directly
involved and there will be no possibility for SOS to check the
authorization of the terminal users. This facility may for in-
stance be used for accessing F8000 terminals.

D. When an SOS job has created a terminal group, SOS may connect
terminals to this group. This is done in case a terminal user
"logs in" by using the "in" command. If the user is allowd to\f

be connected to the job (according to the user catalog), SOS
will do so and to inform the job of the arrival of a new user,
SOS generates a special input line. In a similar way SOS may
disconnect terminals using the "out" command. The contents of
these special input lines are:

login: <localid.><1><1><32>att<32><32><32><process name><NL>
logout: <localid.><2><2><32>out<32><32><32><NL>
hard er-
ror: <localid.><2><2><32>hard<32>error<NL>

Only TTY-compatible terminals may use the "in" and "out" faci-
lities of SOS.

3_._3_ _ _ _ _ _ _ _S_O_S_ _-_ _J_o_b_ _I_n_t_e_r_c_o_m_m_u_n_i_c_a_t_i_o_n_ 3.3

An SOS job may access terminals, backing storage and eventually a
few other kinds of devices. All kinds of access are on the basic
level performed by using the "send message-wait answer" func-
tions. The communication with backing storage, for instance, will
never be affected by SOS. However, SOS intervenes all communica-
tion between an SOS job and its terminal(s), to know precisely
the current state of the job.

Thus even though a job "believes" that it communicates with its
primary input/output terminal (and eventually TEM) it really com-
municates with SOS.

Apart from the terminal communication there is a "parent commu-
nication" (i.e. jobs send messages to their parent, SOS, when
they finish, in case they want documents mounted, if they detect
severe internal errors or the like).

3_._3_._1_ _ _ _ _ _P_r_i_m_a_r_y_ _I_n_p_u_t_ _a_n_d_ _O_u_t_p_u_t_ 3.3.1

The primary input and output communication performed by a job may
be visualized like this:

J_o_b_ S_O_S_ T_e_r_m_i_n_a_l_ _(_o_r_ _T_E_M_)_

input message -> stop process
input message ->
-
(other jobs may run)
-
put job into <- input answer
active queue
-
copy input
<- input answer
activate job
-
-
output message -> copy output
output message ->
<- output answer
-
-
<- output answer

Only two message operations are involved:

input: _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
message: + 0 _3_ _ _ _ _ _m_o_d_e_ _ _ _ _
+ 2 _f_i_r_s_t_ _a_d_d_r_e_s_s_ _
+ 4 _l_a_s_t_ _a_d_d_r_e_s_s_ _ _
+ 6
+ 8
+10
+12
+14 _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
\f

The input messages may for instance be sent when using the read
procedures of ALGOL. The zone used for terminal communication
should be opened exactly as to a "real" terminal:

open (z, mode shift 12 + 8, <name of SOS system>, give up)

output: _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
message: + 0 _5_ _ _ _ _ _m_o_d_e_ _ _ _ _
+ 2 _f_i_r_s_t_ _a_d_d_r_e_s_s_ _
+ 4 _l_a_s_t_ _a_d_d_r_e_s_s_ _ _
+ 6
+ 8
+10
+12
+14 _ _ _ _ _ _ _ _ _ _ _ _ _ _ _

The output messages may for instance be sent, when using the
write procedures of ALGOL. The zones used for output should be
opened exactly as for input.

3_._3_._2_ _ _ _ _ _T_r_a_n_s_p_a_r_e_n_t_ _C_o_m_m_u_n_i_c_a_t_i_o_n_ _t_o_ _T_E_M_ 3.3.2

SOS jobs may use TEM by sending messages to the TEM process as
described in the TEM manual (ref. 4). All messages to TEM will
be sent via SOS and SOS imposes a set of limitations.

1. An SOS job may only create one terminal group.
2. The terminal group created by a job must use the name of the
TEM process (usually TEM).
3. The buffer length of SOS will be the max block length of data
transfers.
4. No dummy message will be returned to the job after pool
creation.
\f

As TEM may spool input and output, the communication job-SOS-TEM
looks slightly different from the primary input/output communica-
tion:

J_o_b_ S_O_S_ T_E_M_

output message -> output message ->
send timer
wait first answer
(output or timer)
-
regret timer <- output answer
<- output answer
-
input message -> input message ->
send timer
wait first answer
(input or timer)
-
if timer answer first
then stop job
-
(other jobs may run)
-
put job into <- input answer
active queue
-
copy input
<- input answer
activate job

The reason for using a timer period (of 50-100 m.sec.) is to
avoid swopping a job in case TEM is able to answer within this
period (often TEM will need a little time for transferring
spooled data).

In the communication between a job and TEM, SOS will offer a
special feature. The usual convention is that each block of out-
put sent to TEM must include address information (in case of TTY\f

compatible terminals, the first 24 bits of a block is interpreted
as an address). When communicating via SOS, it is possible to use
an implicit addressing mode for output. In this mode no address
information is needed in the block. Instead the output block is
routed to the terminal from which the job has received its latest
input block. (This way of addressing may often be convenient as
most terminal communication looks like terminal commands immedi-
ately followed by an answer).

To use this facility the outputzone must be opened like this:

open (z, 1 shift 18 + mode shift 12 + 8,<name of TEM>,0);

3_._3_._3_ _ _ _ _ _P_a_r_e_n_t_ _M_e_s_s_a_g_e_s_ 3.3.3

Jobs may send parent messages to inform the system of job termi-
nation, severe errors or to request operator action.

Parent messages all use the following format:
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
message: + 0 _f_u_n_c_t_i_o_n_ _ _ _p_a_t_t_e_r_n_ _<_5_ _+_ _w_a_i_t_ _
+ 2 _i_n_t_e_g_e_r_ _o_r_ _t_e_x_t_ _p_o_r_t_i_o_n_ _ _ _ _ _ _
+ 4 _ _ _ _ _ _ _ _ _ _ _-_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
+ 6 _ _ _ _ _ _ _ _ _ _ _-_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
+ 8 _ _ _ _ _ _ _ _ _ _ _-_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
+10 _ _ _ _ _ _ _ _ _ _ _-_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
+12 _ _ _ _ _ _ _ _ _ _ _-_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
+14 _ _ _ _ _ _ _ _ _ _ _-_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _

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

"pattern" specifies how the parent (SOS) is to display the mes-
sage (on the system terminal). The "pattern" contains seven bits,
one to each of the last seven words of the message (+2,+4......
+14).
\f

When a bit equals one it means that the corresponding word should
be displayed as an integer, otherwise the word is displayed as a
text portion of 3 characters. Thus bit 1<11 means that the second
word of the message is an integer and 1<5 means that the last
word of the message is an integer.

"wait" may be zero or one. A zero means that the job wants an
answer immediately, one means that the job should not be answered
(restarted) until some operation (operator action) is completed.

When receiving a parent message, SOS will perform the following
actions depending on the function of the message:

function = 2: finis

The job is aborted. Temporary files are cleared, eventual
TEM pools and links are removed. The job process is re-
moved and a finis message is written on the start-up ter-
minal of the job.

function = 4: break

The actions are exactly as for finis. However, the mes-
sage written on the terminal is different.

function = 14: mount

If the document is already mounted and accessible, the
job will become a user of the device and SOS returns the
answer immediately. If the document is not mounted, SOS
displays the message and stops the job. When the operator
has mounted the job he may activate it by using the
"start" command.

function = 16: print

Displays the contents of the message according to the
general rules. Is the wait bit zero the job will be an-
swered at once, otherwise it is stopped and the operator
may reactivate it by using the "start" command.
\f

function = 32: mount special

Treated exactly as "mount" (function = 14)

All other functions are treated exactly like a "print" message
(function = 16).

F_ 4_._ _ _ _ _ _ _ _ _O_P_E_R_A_T_I_N_G_ _G_U_I_D_E_ 4.

The operators tasks in the day to day running of the system com-
prise the following major points:

a. start-up
b. system and job intervention
c. device support
d. close down
e. system failure.

4_._1_ _ _ _ _ _ _ _S_t_a_r_t_-_U_p_ 4.1

During the start-up the system calculates a set of minimum re-
sources on the basis of the trimmed values. This set of resources
must be present in order that the run can be succesful, otherwise
the run is immediately terminated with a message specifying the
minimum set of resources. When started with sufficient resources
the resources available for jobs are listed.

M_ @
ATT sos
new sos internal 3 size 50000 buf 30 area 30 perm disc 1000 40
READY

@
ATT s
function 1,2,3,4,5 prog bsos base -8388607 8388605 run
READY

FROM SOS
02.58 SOS: MESSAGE SOS VERSION: 780929 0
02.58 SOS: MESSAGE SOS CHILD RESOURCES
02.58 SOS: MESSAGE SOS INTERNAL 3
02.58 SOS: MESSAGE SOS BUF 16
02.58 SOS: MESSAGE SOS AREA 24
02.58 SOS: MESSAGE SOS SIZE 45568
P_ 02.58 SOS: MESSAGE SOS STARTED

Example 16: SOS started as a child of "s".
\f

M_ @
ATT s
replace prologue

@
ATT
READY
PROCESS NAME = sos

FROM SOS
PROGRAM NAME = bsos
09.02 SOS: MESSAGE SOS VERSION: 780901 0
09.02 SOS: MESSAGE SOS CHILD RESOURCES
09.02 SOS: MESSAGE SOS INTERNAL 3
09.02 SOS: MESSAGE SOS BUF 147
09.02 SOS: MESSAGE SOS AREA 134
09.02 SOS: MESSAGE SOS SIZE 50688
P_ 09.02 SOS: MESSAGE SOS STARTED

Example 17: SOS started using "S-replacement".

It should be mentioned here that even though all examples use the
system name "SOS", any name of up to 8 characters may be used.

4_._2_ _ _ _ _ _ _ _O_p_e_r_a_t_o_r_ _I_n_t_e_r_v_e_n_t_i_o_n_ 4.2

At system trimming an operator key (an operator password) is de-
fined which may be used at operator intervention. Operator inter-
ventions are accepted only when initiated from the system terminal
of SOS (the terminal used at SOS start-up).

The operator interventions concern the SOS system (= system inter-
vention) or one or more jobs (= job intervention).

4_._2_._1_ _ _ _ _ _S_y_s_t_e_m_ _I_n_t_e_r_v_e_n_t_i_o_n_ 4.2.1

By using the system intervention commands the operator will be
able to change the state of the system. The possible commands
are:

M_m_m_ lock
<operator key>
P_p_p_ open

(These commands are only accepted when typed on the system ter-
minal of SOS).
\f

The "lock" command will make SOS refuse all attempts to create
jobs or to connect terminals to multiterminal jobs. The command
may be used for draining the system. As a consequence SOS will
write a message on the system terminal when the last job leaves,
telling the operator that the system is empty.

M_ @
ATT sos
>lock opr
P_ 16.56 SOS: READY

Example 18: Operator intervention.

The "open" command is the opposite of the "lock" command. After
"open" job creation and terminal connection will be accepted.

4_._2_._2_ _ _ _ _ _J_o_b_ _I_n_t_e_r_v_e_n_t_i_o_n_ 4.2.2

The job intervention commands (described in chapter 2) may in a
changed version be used as operator commands.

In this version the syntax is:

stop
M_m_m_ start <jobname>
<operator key>
P_p_p_ break all
kill

In case the "all" option is used, all jobs enrolled will be sub-
ject to the action stated.

The "stop" command will suspend the job(s) in question in such a
way that the execution may be resumed.

The "start" command will activate suspended jobs. The suspnesion
may for instance be a "pause" message requesting an operator
action.
\f

The "break" and "kill" commands abort the job(s) in question. At
"break" the job will be allowed to write an error message before
removal.

M_ @
ATT sos

>kill opr all
P_ 16.59 SOS: READY

Example 19: Clear system.

4_._2_._3_ _ _ _ _ _D_e_v_i_c_e_ _S_u_p_p_o_r_t_ 4.2.3

Usually SOS jobs will not use equipment that requires operator
support. There will be a need, however, for users to make safety
copies on flexible disc, magnetic tape or the like. Jobs using
that kind of equipment may request documents to get mounted.
These requests will be displayed on the system terminal of SOS.
When the document is mounted, the operator must name the device
(with the name of the document mounted) and then restart the job.
The naming is performed by the "call" command:

call <device number> <document name>

(the "call" command may be immediately followed by the "start"
command).

M_ 16.58 SOS: PAUSE RC MOUNT MT

@
ATT sos

>call 10 mt start opr rc
P_ 16.59 SOS: READY

Example 20: Tape mounting.

4_._3_ _ _ _ _ _ _ _C_l_o_s_e_ _D_o_w_n_ 4.3

The SOS system is closed by using the "halt" command:

halt <operator key>

The run will terminate immediately without removing active jobs
(remember that the system may be drained before closing). In case
the system generates testoutput "halt" will close the testoutput
file. After closing SOS, the system (the SOS process) may be
removed.

M_ @
ATT sos

>lock opr
16.54 SOS: MESSAGE SOS SYSTEM EMPTY
16.54 SOS: READY

@
ATT sos
>halt opr
P_ 16.55 SOS: PAUSE SOS SYSTEM CLOSED:

Example 21: Drain system and close down.

4_._4_ _ _ _ _ _ _ _H_o_w_ _t_o_ _H_a_n_d_l_e_ _S_y_s_t_e_m_ _F_a_i_l_u_r_e_ 4.4

During the run the system may break down in one of the following
two ways:

1. An internal program error or a transport error from the
program area "bsos" may cause the system to break down and
the following error message will be printed on the system
terminal of SOS.

pause sos ***fault

(Please notice that if this terminal is reserved by other proces-
ses (e.g. by login to BOSS) it will not be possible for SOS to
print these messages).
\f

2. A hard error in the swop area makes continued running im-
possible and the system stops after having printed the
message:

message sos status <statusword> swpsos

In all error situations one should, if the system has been trim-
med with 'testoutput', move this from the test area (e.g. TSTSOS)
to a work area, from which the TRACE-program can print it for a
further analysis.

The TRACE program is automatically generated at the installation
of the system. The program is called as follows:

trace <testarea>.<segments>

<testarea> is the name of the area, from which the test output is
to be printed (the work area the test output has been moved to,
or the test area itself).

<segments> are the maximum number of segments to be analyzed.
TRACE always finds the latest generated segment, and counts the
number of segments backwards from there. <segments> are automa-
tically cut to the size of the area, if something larger has been
specified.

M_ @
ATT s

proc sos remove prog fp run

READY
TO SOS
o lp

trace tstsos.10000

o c
@
ATT s

P_ proc sos remove

Example 22: Printing testoutput.
\f

(Once again, please notice that the names used (SOS, TSTSOS and
SWPSOS) are only examples, as other names, consisting of up to 8
characters, as well might be used, allowing identical systems
each with its own name to run simultaneously.

F_ 5_._ _ _ _ _ _ _ _ _I_N_S_T_A_L_L_A_T_I_O_N_ _N_O_T_E_S_ 5.

This chapter concerns the subjects that are relevant for persons
who administers the resources of an installation and for persons
who are actually going to install an SOS system on a computer of
the RC4000 or RC8000 series.

5_._1_ _ _ _ _ _ _ _S_y_s_t_e_m_ _D_i_s_t_r_i_b_u_t_i_o_n_ 5.1

The SOS system is usually distributed as a magnetic tape contain-
ing the files below:

0: label
1: soshelp (is used as an auxiliary file when generating
an SOS system; contains the files "sostrim",
"sossave" and "sosload")
2: trcmol (compiler for generating "bsos", "cleartemp"
and "prologue")
3: tsoscat (a simple user catalog)
4: tsos (system program text)
5: tcleartemp (program for clearing temporary files when a
job terminates)
6: tupsoscat (program for generating, updating and listing
the user catalog)
7: ttrace (program for analyzing test output)
8: tsostest (multiterminal program for simple system
testing)
9: tprologue (program used for starting a system as
"S-replacement")
10: tdisplay (program displaying all jobs actually running
under SOS)
11: tnews (test file to be written on terminals running
the "hotnews" job defined in "tsoscat")
\f

All files of a system tape may be automatically loaded to backing
storage like this:

sosdoc = set 1 disc3
soshelp = set mto sostape 0 1
i soshelp
i sosload

In case no "sosdoc" is specified the files will be loaded pri-
marily on the system disc.

On the other hand a system tape may be generated from an SOS
system on disc by:

sosdoc = set mto sostape
i soshelp
i sossave

and a standard system may be generated from tape or disc by using
this set of commands:

soshelp = set mto sostape 0 1 ; only for tape
i soshelp
i sostrim

5_._2_ _ _ _ _ _ _ _S_y_s_t_e_m_ _T_r_i_m_m_i_n_g_ 5.2

The quantities to be defined when the system is trimmed, fall in-
to two groups:

a. System constants concerning the strategy of execution, time
slice, test output, the type of machine and the buffer
length for the applications terminal I/O.

b. The minimum of resources available for the applications and
the terminal users. E.g. 1) the minimal core size for ap-
plications, 2) the minimal number of simultaneous applica-
tions etc.
\f

Regarding job resources, the system has been designed to calcu-
late on the basis of its start up resources, how many jobs it
will be able to process simultaneously. If this number is smaller
than the minimum specified in the trimming, or if the remaining
pool of resources (buffers, areas etc.) is smaller than what is
specified in the trimming, the system will stop after the init-
ialization with an error message.

In the following all constants that may be changed in the trim-
ming are mentioned.

"optionid"
At start-up a constant showing the date of the SOS version
will be listed together with this constant. At each trimming
this constant should be changed to show the date of the
trimming (e.g. 780901). The standard value is 0 indicating
that "standard trimming" is used.

"rc"
This constant defines the target machine to which the system
is trimmed. The only values accepted are 8000 or 4000.

"minusers"
The minimal number of jobs that may be enrolled simultaneously
(i.e. the number of internal processes allocated to SOS).

"comndusers"
Even when the maximal number of jobs are running there will be
a need for handling terminals, performing operator commands,
login commands or the like. "comndusers" defines the minimum
of terminals that will be able to communicate with SOS without
having created any job.

"minbufs"
Defines the minimal set of message buffers in the pool of re-
sources that may be allocated to jobs.
\f

"minareas"
Defines the minimal set of area processes in the pool of re-
sources that may be allocated to jobs.

"minsize"
The free size of primary store in an SOS system depends on
the size of the SOS process as defined at start-up. During
initialization SOS will check that the "free size" will be
equal to or exceed "minsize". The standard value (12800) is
sufficient for running most of the utility programs and com-
pilers.

"buf1"
Defines the size of the I/O buffer used for communicating
data between terminals and jobs. (Communication via TEM will
pass the same buffer - and use the same buffer limit). The
standard value (104) matches the terminal buffer size as de-
fined in the standard I/O system.

"timeslice"
SOS allocates computing time in time slices. When a job is
swopped into primary store and activated, it will at the
latest be suspended after the expiration of a time slice.
Then the state and priority of all jobs enrolled will be
evaluated and the "winner" will get the next time slice. A
"large" time slice will decrease overhead and increase re-
sponse time variations. The standard value (3 seconds) will
often do.

"cpulimit"
Interactive jobs running under SOS will not be allowed to
cycle indefinitely. At most it will be allocated "cpulimit"/
"classloss" timeslices before being removed from the system.
In case the priority of the job was lower than the maximum
priority when the cycle started, then it will be allocated
less than "cpulimit"/"classloss" timeslices before removal.
(For further investigations see chapter 3).
Please notice: 0 < ("cpulimit" + "classloss") < 2048.
\f

"classloss", "classgain", "priogain".
These three constants all concern the scheduling strategy of
SOS. This strategy is explained in detail in chapter 3. Here
some rules of thumb shall be stated:

a. 1 < <constant> < 2048
b. when "classloss" is large, jobs will rapidly be removed by
"time exceeded";
c. when "classgain" is large, jobs will quickly forget that
they have had a cpu-bound period (a period of low prior-
ity);
d. when "priogain" is large, the response time will (statisti-
cally) be proportional to the computing time, while a small
value of "priogain" will give response times that increase
more than proportional to the computing time.

"testsegmnts"
The SOS system may currently generate testoutput for mainten-
ance purposes. The testoutput is cyclically written into a
testoutput file. "testsegmnts" defines the size of this area.
Obviously the size of the testoutput area is proportional to
the period of time that may be "traced". If "testsegmnts"
equals "0" no testoutput will be generated. It is recommended
that testoutput is generated at least during some period after
the first installation of the system. (The testoutput is
necessary in case you want the RC maintenance staff to analyze
and solve your problems. However, you should not waste your
time trying to analyze the testoutput yourself).

"conditions"
This constant is a bitpattern defining the reaction on time
exceeded (see "cpulimit") and break. The standard value is
2'000000. The bits used are:
2'000001 = abort job at time exceeded. When this bit is
zero, an online job may run for ever.
2'000010 = abort job after break command. When this bit is
zero, a user break or operator break will work
as "stop load start" when the terminal is run-
ning a job without jobfile.
\f

"oprkey"
Defines a text used as operator password. Default is "opr".
This text must be nonempty.

"swopdoc", "testdoc"
In case these two texts are empty, the swop area and the test-
output area are usually placed on the system disc (they are
actually placed on the first disc on which the SOS process has
got backing storage resources). To smooth disc load it may be
reasonable to place two areas on some other disc than the sys-
tem disc.

The system trimming is actually done by means of the file
"sostrim" (see appendix F) which contains the standard trimming
plus commands for generating the trimmed program version together
with some utility and test programs.

The individual trimming consists of changing some values in
"sostrim" in case standard values do not apply. This is done by
simple editing e.g.:

xtrim = edit sostrim
EDIT BEGIN
1./optionid:=/, r/0/780901/,
1./minsize:=/, r/12800/20000/,
1./timeslice:=/,r/3/5/,
1./testsegmnts:=/,r/42/168/,
f
EDIT END.

Example 23: Individual trimming.

The commands stated in the file "sostrim" (and here "xtrim") will
generate an SOS system like this:

a. load a compiler for translating SOS system
b. generate SOS system program: "bsos"
c. generate catalog cleaning program: "cleartemp"
d. generate user catalog program: "upsoscat" \f

e. generate testoutput analyzing program: "trace"
f. generate S-replacement loader: "prologue"

In case a file with the name "soscat" already exists, the system
generation will stop here. If no "soscat" exists, it is assumed
that SOS has not been running on the installation before and
therefore a set of testprograms and testfiles is generated to
facilitate a system test. The generation proceeds like this:

g. generate a simple user catalog:"soscat"
h. generate a multiterminal program:"sostest"
i. generate a display program:"bdisplay"
j. generate a news-file:"tnews".
\f

M_ @
ATT s
all sos run
READY

TO SOS
soshelp = set mto sostape 0 1
i soshelp

FROM S
PAUSE SOS MOUNT SOSTAPE
@
ATT s
call 10 sostape start
READY

FROM SOS
xtrim = edit sostrim
EDIT BEGIN.
1./optionid/, r/0/780901/,
1./minsize/, r/12800/20000/,
f
EDIT END.
i xtrim

EDIT BEGIN.
EDIT END.

TRCMOL
1:(RCMOL=SET 1 DISC
1:RCMOL=ALGOL
1:SCOPE USER RCMOL
1:END
1:BEGIN

3068:END

ALGOL END 168

XSOS D.781003.1610

RCMOL/011 D.781003.1616
TRANSLATION TIME = 199.85 SEC
CORE AREA CLAIM = 12246 BYTES
DISC AREA CLAIM = 24 SEGMENTS

TCLEARTEMP D.781003.1615

RCMOL/011 D.781003.1616
TRANSLATION TIME = 8.34 SEC
CORE AREA CLAIM = 504 BYTES
DISC AREA CLAIM = 1 SEGMENTS

END 125
(to be continued) \f

(continued)

TUPSOSCAT

1:BEGIN

2013:END;
ALGOL END 97

TTRACE
1:; TRACE
1:;
1:;
1:; PROGRAM FOR ANALYZING TESTOUTPUT
1:
1:
1:BEGIN

174:END

ALGOL END 34

TPROLOGUE

RCMOL/011 D.781003.1617
TRANSLATION TIME = 14.26 SEC
CORE AREA CLAIM = 996 BYTES
DISC AREA CLAIM = 2 SEGMENTS

END 122

END 59

TDISPLAY
1:BEGIN

53:END
ALGOL END 29
P_ SYSTEM GENERATION COMPLETED

Example 24: System installing and trimming.

5_._3_ _ _ _ _ _ _ _U_s_e_r_ _C_a_t_a_l_o_g_ 5.3

Any job executed under SOS must be described in the user catalog.
The user catalog contains information about resource demands,
scope (file access), password, start-up commands and in case of a
multiterminal job, descriptions of terminal users who are allowed
to login to this job.

The user catalog is created and updated by the program
"upsoscat". This program may list the actual contents of a user\f

catalog in such a way that the listing may be used as input for
generating a new catalog. As users may change their passwords, it
is not convenient to generate a changed catalog from an edited
version of the original catalog text. Instead a new catalog may
be generated without destroying actual passwords, by using an
edited version of an actual catalog listing.

The user catalog consists of a set of job (process) descriptions.

5_._3_._1_ _ _ _ _ _D_a_t_a_ _p_e_r_ _J_o_b_ _(_P_r_o_c_e_s_s_)_ 5.3.1

The user catalog must contain the following information per
process:

process name : max. 8 characters
buffers : the process' demands on buffers and
areas : areas
bases : the standard-, user- and max (project)
base of the process

password : max. 11 characters
minsize : the minimum size acceptable for the process
maxsize : the max size used for the job (even though
SOS may have room for more)
FP-commands : max. 59 characters
are executed when the job is created.
Can be used to start-up an application.
bs-claims : device-name (max. 11 characters) plus
entries and segments for key0, key1, key2
and key3.
Max. 12 units.

terminals : external identification (max. 11 charcters),
local identification (max. 3 characters),
password (max. 11 characters),
\f

input buffering (max.no of input buffers
spooled by TEM)
timercount (max.no of timeout periods
expired before TEM returns an answer).

The process name must identify the job unambiguously.

An arbitrary number of terminals can be registered under a pro-
cess. The external id. and the local id. must be unambiguous for
terminals under the same process.

Parts of the descriptions may be omittted. The "upsoscat" program
will then generate default values. In the following all default
values that are not 0 (or nonempty) are listed.

buffers : 4
areas : 7
maxsize : 8388608
bs-claims : disc key0 6 0 key1 0 0 key2 0 0 key3 0 0
terminal input
buffering : 1
terminal timer
count : 40

At catalog generation it is checked that process names, buffers
and areas are given values different from 0.

5_._3_._2_ _ _ _ _ _C_r_e_a_t_i_o_n_ _a_n_d_ _C_h_a_n_g_e_ _o_f_ _t_h_e_ _U_s_e_r_ _C_a_t_a_l_o_g_ 5.3.2

The program "upsoscat", which is used for generating the user
catalog, is called as follows:

M_m_m_ 1 1 <cat> 1
<newcat> = upsoscat <input> oldcat
P_p_p_ 0 0 no 0
M_m_m_ <outfile> 1
list.
P_p_p_ no 0
\f

<newcat> : the name of the new user catalog
<input> : the name of the file containing the
input. If this is omitted, input is
taken from the lines following the
program call
<cat> : the name of the user catalog to be
updated
<outfile> : the name of the file in which the
contents of the catalog is to be
printed.

If the parameter oldcat is omitted or oldcat.no is stated, a new
user catalog is created in <newcat>; otherwise <newcat> will
contain an updated version of <cat>.

If list is omitted or list.no is stated, the new contents of the
catalog are not printed; otherwise the contents will be printed
in the <outfile> in a manner making it possible to use it as in-
put for upsoscat.

<newcat>: is reserved by the program throughout the run, whereas
<cat> is only reserved during the period of copying (this is done
at the beginning of the run).

<newcat>: is extended by the program if necessary. If this is not
possible, the program stops with the message 'lookup <i>' or
'ch.entr <i>'. In case of an error in the input, the OK-bit is
set to 'no'. (The program ends by writing 'errors 0').

5_._3_._2_._1_ _ _ _C_r_e_a_t_i_o_n_ 5.3.2.1

For each process to be created, the data described in subsection
5.3.1 may be stated.

The syntax for input:
\f

M_m_m_F_ 1
maxprocess <number>
P_p_p_ 0

process <proc-name> max.
M_m_m_ 1
buf <buf>
P_ 0
M_ 1
area <area>
P_p_p_ 0
stdbase <number> <number>
userbase <number> <number>
maxbase <number> <number>
M_m_m_ 1 1
password " <key> "
P_ 0 0
M_ 1
minsize <number>
P_ 0
M_ 1
maxsize <number>
P_p_p_ 0

M_m_m_ 1 1
fp " <text> "
0 0

12
P_p_p_ bs <name> key0 <entr> <segm>
key1 <entr> <segm>
key2 <entr> <segm>
M_m_m_ key3 <entr> <segm>
0

1 1
term <name> " <local id.> " " <key> "
0 0
1 1
<bufs> <timeouts>
0 0 0 0

1
end
P_p_p_ 0

<proc-name> : max. 8 characters, letters or digits.
<name> : max. 11 characters, letters or digits.
<buf>, <area>, <entr>, <segm>: non-negative integers.
<text> : max. 59 characters, all characters
except " are allowed.

<local.id> : max. 3 characters, all characters
except " are allowed.
<key> : max. 11 characters, all characters
except " are allowed.
\f

F_ Note! The "term" option must not be followed by any other
option within a process description. (When used, the ter-
minal should be the last part of the process description).

On the basis of <number> after maxprocess it is calculated how
many processes <max>, there must be room for in the user catalog.
Max is the smallest number, which is a multiple of 50 and which
is bigger than or equals <number>.

Is maxprocess omitted max is set to 50.

The catalog bases are defined by right and left limits for the
base intervals.

The parameter 'end' need not be included if input is specified in
the program call.

If the demands described in subsection 5.3.1 are not met, the
process is not registered. Errors in the terminal parameters will
only effect that the terminal is not registered.

The catalog is created directly in <newcat>. After being created,
<newcat> will always contain a correct user catalog, but if there
have been errors in the input, the catalog will not correspond to
what was wanted. By errors it is recommended to make a rerun
instead of updating <newcat>.

5_._3_._2_._2_ _ _ _C_h_a_n_g_e_ 5.3.2.2

There are three types of updating which concern a process:
correction (cprocess), creation (iprocess) and deletion
(dprocess).

When correcting, the information to be changed plus its new value
must be stated. If all the entries and segments of a unit are
zero, the unit is deleted. The terminal can be created and de-
leted (with the parameters term and dterm). The terminal correc-
tions must be the last changes, which are specified for a pro-
cess.
\f

F_ The syntax for input is:

cprocess <proc-name>
M_m_m_ 1
buf <buf>
P_p_p_ 0
M_m_m_ 1
area <area>
P_p_p_ 0
M_m_m_ 1
stdbase <number> <number>
P_p_p_ 0
M_m_m_ 1
userbase <number> <number>
P_p_p_ 0
M_m_m_ 1
maxbase <number> <number>
P_p_p_ 0
M_m_m_ 1 1
password " <key> "
P_p_p_ 0 0
M_m_m_ 1
minsize <number>
P_p_p_ 0
M_m_m_ 1
maxsize <number>
P_p_p_ 0

M_m_m_ 1 1
fp " <text> "
P_p_p_ 0 0
12
bs <name> key0 <entr> <segm>
key1 <entr> <segm>
key2 <entr> <segm>
key3 <entr> <segm>
0

M_m_m_ 1 1 1
term <name> " <local id.> " " <key> " <number>
P_p_p_ 0 0 0
M_m_m_ 1
<number>
P_p_p_ 0 0
M_m_m_ 1
dterm <name> " <local id.> "
P_p_p_ 0 0
iprocess <proc-name> max
buf <buf>
.
.
. (as for catalog creation) 0
.
.

dprocess <proc-name>
0

M_m_m_ 1
end
P_p_p_ 0
See the note about "term" in subsection 5.3.2.1.
\f

F_ The changes of <cat> are made in a temporary file.

After the updating is finished, this file is copied to <newcat>.

As when created, <newcat> will contain a correct user catalog,
but in case of errors it is recommended to make a rerun instead
of updating newcat.

5_._3_._2_._3_ _ _ _L_i_s_t_i_n_g_ 5.3.2.3

When the creating/change processes are completed, the contents of
<newcat> are listed as described for the input syntax. If this
listing is used as input in a catalog creation, the new catalog
will become identical with the one listed from <newcat>.

If a listing, without updating, of an already existing catalog
is wanted, the program call below is used:

upsoscat oldcat. <cat> list.<outfile>
end

5_._3_._3_ _ _ _ _ _R_e_s_o_u_r_c_e_s_ _N_e_e_d_e_d_ _f_o_r_ _C_r_e_a_t_i_n_g_ _a_ _C_a_t_a_l_o_g_ 5.3.3

After creation the user catalog will contain index segments and
process segments. There will be 1 index segment for each 50 pro-
cesses in the catalog. Each process will occupy one segment con-
taining the process description and up to 5 terminal descrip-
tions. Processes with more than 5 terminal descriptions will
occupy one more segment per 19 terminals (exceeding the first
5).

At updating, the size of the user catalog may increase. The ca-
talog can be compressed by making a printout of the catalog and
use this in a re-creation process.
\f

upsoscat oldcat.soscat list.out
end
END 59
clear project soscat
soscat = set 1
soscat = upsoscat out
END 55
scope project soscat

Example 25: Compressing user catalog.

When creating a user catalog by means of listing, at least 5 buf-
fers will have to be used, and by updating at least 6 buffers.

5_._3_._4_ _ _ _ _ _E_r_r_o_r_ _M_e_s_s_a_g_e_s_ 5.3.4

In case of an error, an error message plus the input line with
the error is printed.

Below the word "parameter" is used covering the input keywords:
end, maxprocess, process, dprocess, cprocess, iprocess, buf,
area, stdbase, userbase, maxbase, maxsize, minsize, password, fp,
bs, key0, key1, key2, key3, term, dterm. The word transaction is
used for the 6 first words mentioned above:

E_r_r_o_r_ _t_e_x_t_ E_x_p_l_a_n_a_t_i_o_n_

line too long more than 120 characters in an input line.
The line is not processed and is not
printed.
illegal char illegal character in an input line.
The rest of the line is processed.
buf illegal buf-value.
The processing is continued with the next
parameter.
area illegal area-value.
The processing is continued with the next
parameter.
\f

stdbase illegal base-value
userbase The processing is continued with the next
maxbase parameter.

password illegal password. The processing is
continued with the next parameter.

minsize illegal size value.
maxsize The processing is continued with the next
parameter.

fp an error in the text.
The processing is continued with the next
parameter.
device name as for "name"
bs illegal bs value.
The processing is continued with the next
parameter.
bsfull more than four bs units.
The unit is not registered.
The processing is continued with the next
parameter.
proc-params incomplete process description.
missing The process is not registered/detected.
base error the values of the bases are inconsistent.
The process is not registered/detected.
claim error the internal relationship of entries and
segments from key0 - key3 is not correct.
The process is not registered/updated.
abnormal end input ends where further input was expect-
ed.
The process, which was last processed, is
not registered/updated.
trans an illegal parameter was read where a
transaction was expected.
The processing continues with the next
parameter. \f

name illegal name.
The processing is continued with the next
transaction or parameter dependent on the
situation.
proc in cat the process already exists in the catalog.
The processing is continued with the next
transaction.
loc id illegal local identification.
The terminal is not registered.
The processing is continued with the next
parameter.
term-key illegal user-key.
The terminal is not registered.
The processing is continued with the next
parameter.
cat full an insertion of a process exceeding the
maximum allowed is attempted.
By creation the processing is terminated
and by updating the processing is continued
with the next parameter.
term in cat a terminal with the same local id already
exists at this process.

Apart from these error messages, the errors below may occur, all
causing the termination of the program.

lookup i an error in one of the data areas.
Ought not appear.
ch.entry i the catalog cannot be extended; too few
resources or an error in the catalog.
Ought not appear.
call 0 an error in the call of the program.
temp cre work areas cannot be created (too few
resources).
newcat i an error in the <cat> specified in the
program call.
oldcat i an error in the <outfile> specified in the
program call. \f

remove i an error in connection with the removal of
a work area.
Ought not appear.
errors 0 is printed after a completed creation,
updating, if there has been any errors in
the input.

5_._4_ _ _ _ _ _ _ _T_e_s_t_ _F_a_c_i_l_i_t_i_e_s_ 5.4

After the installation of an SOS system (at least including SOS
and TEM) it may be checked that the system installed really
works. As explained in section 5.2 a set of test programs and
test files will be loaded in case no "soscat" existed before the
generation. A simple system test using a variety of the facil-
ities offered by SOS and TEM is shown below.

This example consists of three terminal logs as it includes a
multiterminal test (using the tesprogram "tsostest").
\f

M_ @
ATT sos

>go team pass hobo
16.53 SOS: TEAM ENROLLED
o pp
b=algol tsostest
o c
b

16 53 43: LOGIN: 2, ATT SUB010
16 53 59: LOGIN: 9, ATT SUB011
16 54 09: LOGOUT: 9,OUT
16 54 12: LOGOUT: 2,OUT

END 23

The log of two terminals serviced by the multiterminal job
"team" may look like:

@
ATT sos

>in team nn
16.54 SOS: TERMINAL CONNECTED

FROM TEM
SOS TESTPROGRAM READY
qwaqwaqwaqwaqwaqwaqwaqwaqwaq
TERM = 9 LINE = 1: QWAQWAQWAQWAQWAQWAQWAQWAQWAQ
1234567890
TERM = 9 LINE = 2: 1234567890
0987654321
TERM = 9 LINE = 3: 0987654321
@
ATT sos
>out

TO TEM

FROM SOS
16.54 SOS: TERMINAL DISCONNECTED

@
ATT sos

>in term userb pass b2
16.54 SOS: TERMINAL CONNECTED

FROM TEM
SOS TESTPROGRAM READY
abnsjdgehbsgfa

TERM = 2 LINE = 1: ABNSJDGEHBSGFA
qverthj
TERM = 2 LINE = 2: QWERTHJ
dftyuiop
TERM = 2 LINE = 3: DFTYUIOP
(to be continued) \f

P_ (continued)
M_ ATT sos

>out
TO TEM

FROM SOS
P_ 16.54 SOS: TERMINAL DISCONNECTED

Example 26: System test after installation.

It is obvious that an operating system is not really tested by
running some test programs. The only way to make a realistic test
is to use the system for normal routine duties. As a consequence,
faults may appear from time to time, especially during the first
period after installing the system. To be able to remove the
errors causing system failure, SOS may produce testoutput (as
explained in section 5.2). The RC maintenance staff will have
almost no chances of detecting the errors unless the system
failure is documented by means of testoutput, so during the first
period after the installation the testoutput facility should be
switched on.

5_._5_ _ _ _ _ _ _ _R_e_s_o_u_r_c_e_ _D_e_m_a_n_d_s_ 5.5

W_h_e_n_ _i_n_s_t_a_l_l_i_n_g_ the SOS system (or generating a new version) a
process with the following set of resources will do:

area 6
buf 6
size 60000
work 20 20 300 disc

W_h_e_n_ _r_u_n_n_i_n_g_, the SOS system will need a set of resources for its
private use (apart from the resources set aside for SOS jobs).\f

The resource demands may be computed like this:

Primary store: (halfwords)
resident code app = 4000
test buffer (optional) = 512
descriptions and I/O buffers
= (users + command users) * (bufsize + 36)

Message buffers:
constant consumption: = 4
varying consumption
= (users + command users) * 2

Area processes:
constant consumption 6

Backing storage segments:
testoutput = (as defined in trimming)
swop area =
(size of a user process)/512 * (users + command users)

The standard trimming of SOS (as defined in the file "sostrim")
will have the following demands:

Primary store:
Code: 4000
testbuffer: 512
descriptions and buffers:(3+2)*
(104+36)7_0_0_
4_3_0_2_
message buffers: 4 + (3+2)*2 _ _1_4_
area processes: _ _ _6_

It should also be mentioned here that each job created by the
"run" command uses one pool and one link in TEM. Apart from this,
jobs using multiterminal access via TEM, will need one more pool
plus a number of terminal links depending on the max. number of
terminals simultaneously "logged in" to the job.
\f

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

1 RCSL No 31-D476:
RC8000 Monitor, Part 1

2 RCSL No 31-D477:
RC8000 Monitor, Part 2

3 RCSL No 31-D364, 31-D607 and 31D379:
System 3, Utility Programs, Part 1, 2 and 3

4 RCSL No 31-D513:
Terminal Access Module (TEM)

5 RCSL No 31-D571:
PRIMO (2. edition)

F_ B_._ _ _ _ _ _ _ _ _S_O_S_ _C_O_M_M_A_N_D_S_ B.
\f

F_ C_._ _ _ _ _ _ _ _ _M_E_S_S_A_G_E_S_ _F_R_O_M_ _S_O_S_ C.

SOS may write messages of the following kinds:

1) System messages
2) User messages
3) Parent messages from jobs

In class 1 and 2 there will be normal messages and error messages.

The layout of SOS messages is:

<hour> . <minute> SOS: <message> (normal)
<hour> . <minute> *** SOS: <message> (error)

The system messages may concern start-up or system failure:

S_y_s_t_e_m_ _m_e_s_s_a_g_e_s_ _a_t_ _s_t_a_r_t_-_u_p_:

area <number>
normal: number of areas in job resource pool
error : min. number of areas requested

buf <number>
normal: number of buffers in job resource pool
error : min. number of buffers requested

buflength <size>
error: the buffer length must at least be <size>

function 1,2,3,4,5
error: min. function requested

init troubles
error: system initialization not ok, run terminated

internal <number>
normal: max. number of jobs enrolled
\f

key <number>
error: at least 1 free protection key must be available
(appears only at RC4000)

size <number>
normal: max. size available for jobs
error : min. size requested

started
normal: telling that the initialization was successful

version: <date of system> <date of options>
normal: indicating the version of the SOS system.

<area name> <integer>
error: written because SOS is not able to read one of its
areas; the following messages may appear:

swpsos <size>
the swoparea could not be created with the size
specified (too few resources on "swopdoc" - see
section 5.2),

tstsos <size>
the testoutput area could not be created with the
size specified (too few resources on "testdoc" -
see section 5.2),

fp <result>
SOS could not read the file processor
(should never occur),

cleartemp <result>
SOS could not read the catalog cleaning program
"cleartemp"; maybe because it does not exist
(result = 3),

soscat <result>
SOS could not read the SOS catalog "soscat";
maybe because it does not exist (result = 3).
\f

S_y_s_t_e_m_ _m_e_s_s_a_g_e_s_ _a_t_ _r_u_n_t_i_m_e_:

fault
error: caused by an internal error in SOS, monitor or
hardware (most likely: SOS)

fault 8' <octal status> <program area>
error: transport error concerning program area
(disc failure)

status <decimal status> <area name>
error: transport error concerning swop area or testoutput
area (disc failure)

U_s_e_r_ _m_e_s_s_a_g_e_s_:

bad password
error: password not correct (or missing).

bs claims exceeded
error: SOS has not sufficient backing storage resources for
creating the job.

call not ok
error: the "calling" of a device has been rejected (cause:
the device is reserved, the device does not exist or
the like).

command unknown
error: the command typed is not an SOS command.

disconnection not ok
error: the disconnection of a terminal (at "out") has been
refused by TEM (should never occur).

forbidden
error: the user is not authorized for using the command in
question.
\f

forbidden - system locked
error: a job creation command or an "in" command has been
refused because the system is locked (by the oper-
ator).

identification illegal
error: the jobname of a job creation command is not in-
cluded in the user catalog, or the username of an
"in" command does not belong to the jobname spec-
ified.

include not ok
error: the device inclusion has been rejected (cause: the
device does not exist).

jobfile does not exist
error: the jobfile started in a job creation command is
not visible from the catalog bases of the job.

no room in primary store
error: the min. size of the job exceeded the max. size
available for SOS jobs. (The min. size may be
stated in the user catalog).

process creation not ok
error: a job creation has been refused due to resource
limitation in SOS.

process unknown
error: a job intervention command has been rejected
because the job stated was not found.

ready
normal: indicates that a command has been sucessfully
interpreted.

syntax
error: the command was rejected because of a syntax error
(illegal character, missing parameter or the like).
\f

terminal busy
error: a job creation connecting the terminal via TEM was
refused, because the terminal was already connected
to some pool in TEM.

terminal connected
normal: a message telling that an "in" command has been
successfully interpreted.

terminal connection not ok
error: an "in" command has been rejected because TEM
refused connecting the terminal (maybe because the
actual job has not created a terminal pool).

terminal not connected
error: an "out" command or a job intervention command has
been rejected because the terminal was not connected
to the actual job.

user conflict
error: a job creation command has been rejected because the
job existed in advance or because an existing job
was using the same standard base as the new one.

<jobname> enrolled
normal: a message telling that a job creation has
succeeded.

<jobname> removed after <cause>
normal: a message telling that the job has been removed
from the system. The cause may be:

finis: normal finis message from job
break: abnormal termination caused by an
internal job error (a "break")
terminal failure: a hard error has occured on the
primary input terminal
operator break: the operator has provoked a
"parent break" (break 8) \f

user break: the user has provoked a "parent
break" (break 8)
operator kill: the operator has killed the job
userkill: the user has killed the job
time exceeded: an interactive job has been too
cpu-bound (i.e. the priority has
decreased and reached the min.
priority accepted by the system).

P_a_r_e_n_t_ _m_e_s_s_a_g_e_s_ _f_r_o_m_ _j_o_b_s_

Jobs using devices like magnetic tape stations or jobs running
into severe errors may send "parent messages" to SOS. SOS handles
parent messages as described in subsection 3.3.3. Some parent
messages are printed on the system terminal. This is done with
the following format:

M_m_m_ message
<hour> . <minute> SOS: <jobname> <contents>
P_p_p_ pause

The <contents> is totally specified by the job as explained in
subsection 3.3.3.

F_ D_._ _ _ _ _ _ _ _ _A_N_ _E_X_A_M_P_L_E_ _O_F_ _A_ _M_U_L_T_I_T_E_R_M_I_N_A_L_ _P_R_O_G_R_A_M_ D.
\f

F_ E_._ _ _ _ _ _ _ _ _A_N_ _E_X_A_M_P_L_E_ _O_F_ _A_ _U_S_E_R_ _C_A_T_A_L_O_G_ E.
\f

F_ F_._ _ _ _ _ _ _ _ _T_H_E_ _A_U_X_I_L_I_A_R_Y_ _F_I_L_E_ _"_s_o_s_t_r_i_m_"_ F.
\f

F_
\f

F_G_._ _ _ _ _ _ _ _ _T_H_R_E_E_ _V_E_R_S_I_O_N_S_ _O_F_ _A_ _M_A_S_T_E_R_ _M_I_N_D_ _P_R_O_G_R_A_M_ G.

G_._1_ _ _ _ _ _ _ _S_i_m_p_l_e_ _S_i_n_g_l_e_ _T_e_r_m_i_n_a_l_ _V_e_r_s_i_o_n_ G.1
\f

F_ G_._2_ _ _ _ _ _ _ _S_i_n_g_l_e_ _T_e_r_m_i_n_a_l_ _V_e_r_s_i_o_n_ _w_i_t_h_ _I_n_p_u_t_ _C_h_e_c_k_i_n_g_ G.2

F_ G_._3_ _ _ _ _ _ _ _M_u_l_t_i_t_e_r_m_i_n_a_l_ _V_e_r_s_i_o_n_ _w_i_t_h_ _I_n_p_u_t_ _C_h_e_c_k_i_n_g_ G.3

F_ H_._ _ _ _ _ _ _ _ _I_N_D_E_X_ H.

H_._1_ _ _ _ _ _ _ _S_u_r_v_e_y_ _o_f_ _E_x_a_m_p_l_e_s_ H.1

Example 1: Job creation .................................... 4
Example 2: Executing utility program ...................... 5
Example 3: Creating a text file ............................ 6
Example 4: Executing utility programs ...................... 7
Example 5: Program translation ............................. 7
Example 6: Text editing .................................... 7
Example 7: Execution of interactive program ................ 8
Example 8: Job intervention ................................ 9
Example 9: Job termination ................................. 9
Example 10: Running a multiterminal program ................. 10
Example 11: Automatic program activation .................... 11
Example 12: Running a batch job from a terminal ............. 12
Example 13: Creating a job file ............................. 12
Example 14: Running a job using a job file .................. 13
Example 15: Job file routing job output to printer .......... 13
Example 16: SOS started as a child of "s" ................... 33
Example 17: SOS started using "S-replacement" ............... 34
Example 18: Operator intervention ........................... 35
Example 19: Clear system .................................... 36
Example 20: Tape mounting ................................... 36
Example 21: Drain system and close down ..................... 37
Example 22: Printing testoutput ............................. 38
Example 23: Individual trimming ............................. 45
Example 24: System installing and trimming .................. 47
Example 25: Compressing user catalog ........................ 56
Example 26: System test after installation .................. 60

«eof»

DataMuseum.dk

CP/M

⟦4cf43849b⟧ TextFile

Derivation

TextFile