⟦01f15b30f⟧

TextFile

F_O_R_E_W_O_R_D_

First edition: RCSL No 31-D191

This manual explains how a BOSS2 system is generated for a
particular installation. The system generation itself is very
simple, but some background information is necessary in order to
utilize the resources fully.

Som maintenance information is also presented, especially
concerning the user catalog, the accounting, and the testoutput.

The manual consists of rather independent chapters written as the
need arose and the time allowed. Thus the manual does not pretend
to be complete, but we expect it to grow as new chapters are
added gradually.

Søren Lauesen
A/S Regnecentralen, July 1972.

Second edition: RCSL No 31-D313

Third edition: RCSL No 31-D421

The manual has now been revised so that it should be possible for
unexperienced people to generate a bossversion for a given
configuration. Furthermore the manual has been divided into an
installation and a maintenance part, each of which has been
extended considerably.

Lars Otto Kjær Nielsen and Bent Bæk Jensen
A/S Regnecentralen, February 1977.
\f

Fourth edition: RCSL No 31-D628

Since the third edition of this manual appeared, five new
releases of BOSS2 have been issued, and the correction list has
grown to 34 pages.

These corrections have been incorporated in the text, which has
also been generally revised.

Chapter 5 concerning the accounting system has been rewritten and
chapter 9 concerning the test output types has been extended.

The present edition of the manual corresponds to BOSS2 release
17.0 (the Software Package SW8101/1/17.0)

John Munkholm Andersen
A/S REGNECENTRALEN af 1979, May 1981.
\f

iii

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

1. SYSTEM GENERATION ..................................... 1
1.1 The Source Text .................................. 1
1.2 Translation of the Source Text ................... 3
1.2.1 Source Text on Magnetic Tape .............. 4
1.2.2 Source Text on Backing Storage ............ 4
1.2.3 Source Text on Diskettes .................. 5
1.3 Options .......................................... 5
1.3.1 Options to Consider ....................... 6
1.3.2 Options Concerning System Disc ............ 8
1.3.3 Other Discs ............................... 10
1.4 Standard Options ................................. 11
1.5 Editing the Options - An Example ................. 21

2. START-UP .............................................. 23
2.1 Warnings During Start Up ......................... 24
2.2 Error Messages During Start Up ................... 25

3. RUNTIME REQUIREMENTS .................................. 28
3.1 Primary Storage Utilisation ...................... 28
3.2 Resource Requirements ............................ 29
3.3 Swopping, spooling ............................... 32
3.4 Other Files Used at Run Time ..................... 33

4. BOSSOLD ............................................... 35
4.1 Bossbin .......................................... 35
4.2 Bossupdate ....................................... 35
4.3 Bosstrans ........................................ 36
4.4 Bossload ......................................... 36

5. ACCOUNTING ............................................ 37
5.1 Account Records .................................. 39
5.2 Accountjob ....................................... 45
5.3 The Standard accountjob .......................... 48
\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_

6. THE USER CATALOG IN BOSS .............................. 52
6.1 Resource Allocation to a Job ..................... 52
6.2 The Structure of the User Catalog ................ 53
6.2.1 Index Segments ............................ 53
6.2.2 Record Types in the Catalog ............... 54
6.3 How to Create and Update the User Catalog ........ 58
6.3.1 Syntax for the Call of >catupdate> ........ 59
6.3.2 Explanation of Parameters to >catupdate> .. 59
6.3.3 Implementation of Subcatalogs ............. 60
6.3.4 Input to Catupdate ........................ 60
6.3.5 Example ................................... 66
6.3.6 Errormessages from >catupdate> ............ 68
6.4 Listing of User Catalog (>userout>) .............. 71
6.5 Balancing Permanent Resources Against Actual Usage 71

7. HOW TO HANDLE A BOSS FAULT SITUATION .................. 73

8. BOSS FAULT ERROR CODES ................................ 74

9. TESTOUTPUT ............................................ 79
9.1 Record Format .................................... 79
9.1.1 Type 1, send .............................. 79
9.1.2 Type 2, lock .............................. 80
9.1.3 Type 3, opch .............................. 80
9.1.4 Type 4, open .............................. 80
9.1.5 Type 5, exit .............................. 80
9.1.6 Type 6, mess .............................. 81
9.1.7 Type 7, answ .............................. 81
9.1.8 Type 8, jd-1 .............................. 81
9.1.9 Type 9, stop .............................. 82
9.1.10 Type 10 ................................... 83
9.1.11 Type 11 ................................... 85
9.1.12 Type 12 ................................... 85
\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_

9.1.12.1 Jobstart ......................... 86
9.1.12.2 Job .............................. 86
9.1.12.3 Procs Testoutput ................. 86
9.1.13 Type 13 ................................... 89
9.1.14 Type 14 ................................... 90
9.1.15 Type 15 ................................... 90
9.1.16 Type 16 ................................... 90
9.1.17 Type 17 ................................... 90
9.1.18 Type 18 ................................... 90
9.1.19 Type 19 ................................... 91
9.1.20 Type 20 ................................... 91
9.1.21 Type 21 ................................... 91
9.1.22 Type 22 ................................... 91
9.2 Codepage Identifications ......................... 91
9.3 Coroutine Identifications ........................ 93
9.4 Selected Testoutput .............................. 94
9.5 Analysis of Testoutput ........................... 95
9.5.1 Last ...................................... 95
9.5.2 Bossout ................................... 97
\f

vi
\f

1_._ _ _ _ _ _ _ _ _S_Y_S_T_E_M_ _G_E_N_E_R_A_T_I_O_N_ 1.

1_._1_ _ _ _ _ _ _ _T_h_e_ _S_o_u_r_c_e_ _T_e_x_t_ 1.1

BOSS is supplied as a magnetic tape, containing a standard label
and 21 textfiles, or as two diskettes containing the 21 text-
files.

The files are:

1, bossold When BOSS is supplied on magnetic tape, this file
generates descriptors to the other files on the
tape and transfers >options> and >jobdescr> to
disc. Bossold always generates some service files
for managing the BOSS files (chapter 4).

2, options This file contains options for some standard
configuration (section 1.3).

3, jobdescr This file describes a set of data formats, used
during translation of some of the BOSS
coroutines.

4, central Translates into >bos>, i.e. this file is
translated by >i bossbin> into the binary
coroutine file >bos>. Contains code for
testoutput, Central Logic, paging, start-up, and
initialization.

5, tterm1 Translates into >bterm1>. Contains code for common
interpretation of on-line commands, for on-line
editing, for printing of error messages, and for a
few commands.

6, tterm2 Translates into >bterm2>. Contains code for most
of the on-line commands, for kit change, for
request output to the operator, and for job output
to the on-line user.
\f

7, tjobstart Translates into >bjobstart>. Contains code for
interpretation of job specification and start-up
of a job. Contains code for the loadspecification.

8, tjob Translates into >bjob>. Contains code for messages
from a job (except mount and load messages) and
for job termination.

9, tmount Translates into >bmount>. Contains all code for
handling of magnetic tapes.

10, tread Translates into >bread>. Contains code for
handling of paper tape reader, card reader, and
other spooled input devices.

11, tprinter Translates into >bprinter>. Contains code for
handling of printers.

12, tprocs Translates into >bprocs>. Contains code for
receipt of messages from unidentified terminals
and processes which are not BOSS jobs. Contains
various large common procedures for accounting,
retrieval of information from the user catalog,
book-keeping concerning backing storage resources,
and creation of links for remote devices.

13, tbanker Translates into >bbanker>. Contains code for
priority scheduling, resource allocation,
swopping, book-keeping of run time. Contains
initialization code for catalog cleaning and
balancing of main catalog against user catalog.

14, taccount When loaded, this file generates a simple
accountjob.

15, tcatupdate Contains the text of the program >catupdate>,
which is used to create and update the user
catalog. Also contains a text which will create a
file >boptions>, containing certain information
from >options>. (chapter 6).
\f

16, tuserout Contains the text of a program >userout>, which
may be used to print the contents of the user
catalog (see 6.4).

17, testout Contains the text of the external algol procedure
>bossout> and the program >last>, which are used
to analyze and print the contents of the test
output file (chapter 9).

18, textxref Contains the text of a program which can produce
cross references of externals used in BOSS. (For
maintenance purposes only).

19, tsaveconv Contains the text of the program >saveconv> which
after a break down can find all the temporary
convertfiles which have been produced but not yet
printed by BOSS. The files will be transferred to
a magnetic tape. The program must be called before
BOSS is restarted. The use of the program is de-
scribed in "BOSS Operator>s Manual".

20, tgetconv Contains the text of the program >getconv> which
is used to print magnetic tapes created by
>saveconv>. The use of the program is described in
"BOSS Operator>s Manual".

21, tusercat Contains a job which creates a simple user cata-
log.

1_._2_ _ _ _ _ _ _ _T_r_a_n_s_l_a_t_i_o_n_ _o_f_ _t_h_e_ _S_o_u_r_c_e_ _T_e_x_t_ 1.2

Notice that backing storage files will be created with scope
>user>. This makes it possible to have more versions of the
system at the same time. It may be convenient to have the normal
version on system scope while changes in options etc. may be
debugged in a local version.
The following three examples show how the system is generated,
depending on the document used for storage of the source text.

1_._2_._1_ _ _ _ _ _S_o_u_r_c_e_ _T_e_x_t_ _o_n_ _M_a_g_n_e_t_i_c_ _T_a_p_e_ 1.2.1

-' bossold=set <modekind' <tapename' 0 1

-' i bossold ; the files >options> and >jobdescr> are trans-
; ferred to disc, file descriptors to the rest of
; the files are created, and the service files are
; generated (see chapter 4).
-' i trf ; modification of standard options (see 1.3.3).

-' i bossbin ; translation of the BOSS coroutines (see 4.1).

* att -'s
-' remove all boss run

-' bosstest=set 200 disc ; creation of testoutput area
-' scope user bosstest

-' i taccount ; creation of an account job (see chapter 5).

-' i tusercat ; creation of an experimental usercatalog with
; contents as shown in the example in chapter 6.

1_._2_._2_ _ _ _ _ _S_o_u_r_c_e_ _T_e_x_t_ _o_n_ _B_a_c_k_i_n_g_ _S_t_o_r_a_g_e_ 1.2.2

-' i bossold ; generation of service files (see chapter 4).
; As (in this case) the file descriptors to
; the rest of the files are already present,
; the following message will appear:

file descriptors left unchanged
-' i trf ; modification of standard options (see 1.3.3).

-' i bossbin ; translation of the BOSS coroutines (see 4.1).

* att -' s
-' remove all boss run
\f

-' bosstest=set 200 disc ; creation of
-' scope user bosstest ; testoutput area

-' i taccount ; creation of an accountjob (see chapter 5)

-' i tusercat ; creation of an experimental usercatalog with the
; contents of the example in chapter 6.

1_._2_._3_ _ _ _ _ _S_o_u_r_c_e_ _T_e_x_t_ _o_n_ _D_i_s_k_e_t_t_e_s_ 1.2.3

-' fdload s18101.1 ; the files 1-13 are loaded to the system disc
; with scope >temp>, i.e. when BOSS is started
; up, they will be removed.
-' fdload s28101.1 ; the files 14-21 are loaded as above.
-' i bossold ; generation of service files (see chapter
; 4).
-' i trf ; modification of standard options (see
; 1.3.3).
-' i bossbin ; translation of the BOSS coroutines (see
; 4.1).

* att -' s
-' remove all boss run
ready

to boss
-' bosstest = set 200 disc ; creation of
-' scope user bosstest ; testoutput area
-' i taccount ; creation of accountjob
-' i tusercat ; creation of an experimental user
; catalog

1_._3_ _ _ _ _ _ _ _O_p_t_i_o_n_s_ 1.3

When translating the BOSS coroutines all information used for
trimming BOSS must be listed in a file, named >options>. To ease
the system generation some standard configuration is described in
file No 2 (options). The trimming is done by editing this file.
\f

1_._3_._1_ _ _ _ _ _O_p_t_i_o_n_s_ _t_o_ _C_o_n_s_i_d_e_r_ 1.3.1

Normally only the first 3 pages of the options need to be con-
sidered:

Page 1 defines the computer configuration on which BOSS is to
run. For instance, various device numbers are stated here.

Page 2 defines the main parameters, for instance, the maximum
number of jobs which may be handled simultaneously, the amount of
login resources to each terminal, the maximum size of an off-line
job file.

Page 3 defines the time classes and the class margin. Further,
standard and maximum values of options. Notice, that the class
margin ought to comprise resources for at least one job with
standard resources. Otherwise, short jobs with standard resources
cannot be guaranteed to bypass longer jobs. For some installa-
tions a class margin corresponding to two standard jobs may be
advantageous.

In the following table the most important options concerning
various elements and possibilities of BOSS are listed.

M_a_i_n_ _c_o_n_s_o_l_e_,_ _t_e_r_m_i_n_a_l_s_

...1... i1, i4
...2... i45, i44, i48, i47, i113, i114
...4... i7, i9, i161, i16, i175, i176
...5... i3, i179, i181
...5a.. i177

O_p_e_r_a_t_o_r_ _d_i_s_p_l_a_y_

...1... i171
...4... i172, i173
...5a.. i174
\f

P_r_i_n_t_e_r_s_,_ _r_e_m_o_t_e_ _p_r_i_n_t_e_r_s_

...1... e23-e17, e35-e36, e58-e59, i190
...2... i67, i104, e40, e47
...3... i135, i147
...4... i115, i191, i192
...5a.. i72, i77, i79, i73, i74, i167, i168,
i169, i170, i180, i75, i185, e38-e39, i68

P_a_p_e_r_ _t_a_p_e_ _r_e_a_d_e_r_,_ _s_p_e_c_i_a_l_ _r_e_a_d_e_r_ _d_e_v_i_c_e_ _(_c_o_n_t_r_o_l_)_,_ _r_e_m_o_t_e_
r_e_a_d_e_r_s_

...1... e51-e55, e55-e52, e53, e23-e17
...2... i41, i117, i119, i162
...3... i146
...4... i32, i193
...5... (i42)

P_u_n_c_h_e_d_ _c_a_r_d_ _r_e_a_d_e_r_,_ _r_e_m_o_t_e_ _c_a_r_d_ _r_e_a_d_e_r_s_

...1... e54, i93, i200, e23-e17
...2... i203, i52, i118, i163, i201
...5... (i53)

M_a_g_n_e_t_i_c_ _t_a_p_e_ _s_t_a_t_i_o_n_s_

...1... e24-e25
...2... i35
...3... i106, i132, i138, i144, i145, i150
...4... i31, i33

S_i_m_u_l_a_t_e_d_ _c_o_n_v_e_r_s_a_t_i_o_n_a_l_ _d_e_v_i_c_e_s_

...1... e18-e19, e20-e21
...4... i9, i16

F_l_e_x_i_b_l_e_ _d_i_s_c_ _d_r_i_v_e_s_ _(_d_i_s_k_e_t_t_e_ _s_t_a_t_i_o_n_s_)_

...1... e25-e28, e60-e61
\f

O_t_h_e_r_ _d_e_v_i_c_e_s_ _n_o_t_ _s_i_m_u_l_a_t_e_d_ _b_y_ _B_O_S_S_

...1... e23-e28

D_e_v_i_c_e_s_ _w_h_i_c_h_ _r_e_q_u_i_r_e_ _o_p_e_r_a_t_o_r_ _a_t_t_e_n_t_i_o_n_ _b_e_f_o_r_e_ _u_s_e_

...1... e25-e17

D_r_u_m_/_d_i_s_c_

(See 1.3.2)

O_t_h_e_r_ _b_a_c_k_i_n_g_ _s_t_o_r_a_g_e_ _d_e_v_i_c_e_s_

(see 1.3.3)

A_c_c_o_u_n_t_i_n_g_

...2... i105
...3... i136, i148
...5... e70, e71, i14

M_i_s_c_e_l_l_a_n_e_o_u_s_

...1... e0, e79, e60-61
...2... i116
...5... i11, i178, (e6, e7, e9), e16
...7... (e99, e100), e101

1_._3_._2_ _ _ _ _ _O_p_t_i_o_n_s_ _C_o_n_c_e_r_n_i_n_g_ _S_y_s_t_e_m_ _D_i_s_c_ 1.3.2

A number of options concern resources on the system disc (i.e.
the disc with the name >disc>). These options (with their
standard values) are:
\f

options page 2:
i47 = 280 ; max. no. of segments in a basis file
i105 = 24 ; no. of segments in account file
i114 = 25 ; login slices for each terminal
i162 = 4 ; max. length of job file for a papertape job
; (slices)
i163 = 4 ; max. length of job file for a cardjob (slices)

options page 3:
i108 = 35 ; temp disc slices in class margin
i121 = 25 ; temp disc slices, std. value for jobs
i137 = 4 ; std. value for output (slices)
i140 = 16384 ; std. value for jobsize (halfwords)

The reason for the inclusion of i140 (jobsize) here, is that it
determines the size of the swoparea for a standard job.

The standard values are reasonable if the slicelength of the
system disc is 8.

The following table gives suggested values of these options for
the slicelengths normally found on RC8000 system discs.

DISC slice- i47 i105 i114 i162 i163 i108 i121 i137 i140
length
(segm)
RC8221 7 210 84 38 4 4 42 30 8 13312
RC8222 14 280 84 24 2 2 26 20 4 13312
RC8223 21 315 84 18 2 2 20 15 3 13312
RC8224 42 420 84 12 1 1 13 10 2 13312
RC8225 84 504 84 7 1 1 10 8 1 13312
RC8226 168 672 168 5 1 1 8 6 1 13312

In connection with these changes you should also change the
options concerning the number of catalog entries for a standard
job (options page 3) to: i107 = 12 and: i126 = 10, as the
standard values given are unnecessarily high.
\f

If you want to use other values of these options, you should
chose them so that:

1. i108 = i121 + i137 + swoparea (slices)

The size of the swoparea may be calculated from
the value of i140. (1 segment = 512 halfwords)

2. i114 = max. basis file (slices) + i137

The values in the table give the following standard values of the job
specifications:

DISC slicelength temp disc output
(segments) (segments) (characters)
RC8221 7 210 43008
RC8222 14 280 43008
RC8223 21 315 48384
RC8224 42 420 64512
RC8225 84 672 64512
RC8226 168 1008 129024

1_._3_._3_ _ _ _ _ _O_t_h_e_r_ _D_i_s_c_s_ 1.3.3

Discpacks (or logical backing storages) on which users are given
permanent resources in the user catalog, may only be mounted on
the disc drives mentioned in the list in options page 1 after
e22. Therefore you should normally include a_l_l_ disc drives,
except the one for the system disc, in this list.

The option i29 (options page 1) stating total number of drum and
disc devices, must be exactly equal to the number of disc drives
(logical backing storages) stated in the monitor. Otherwise BOSS
refuses to start up.

The option i30 (options page 2) stating the maximum number of
private discpacks in one project may as a useful standard be
equal to: (i29 - 1)*2.
\f

1_._4_ _ _ _ _ _ _ _S_t_a_n_d_a_r_d_ _O_p_t_i_o_n_s_ 1.4

The following is a listing of the standard option file.

F_ \f

F_
1_._5_ _ _ _ _ _ _ _E_d_i_t_i_n_g_ _t_h_e_ _O_p_t_i_o_n_s_ _-_ _A_n_ _E_x_a_m_p_l_e_ 1.5

As mentioned in section 1.3 the trimming for the actual
installation is performed by editing the standard options
supplied. In subsections 1.2.1 and 1.2.2 this editing is assumed
to be written on a paper tape (trf = flexomode). The following
example shows how it may look.

NB: If the source text is on disc, the standard options are
removed during this editing.

message edit of standard options
(optt = edit options
if ok. no
end)

l./...1.../,
l./e0:/, r/rialto/RC COMPUTER,1981.02.18/, ; testoutput ident.
l./e80=/, r/=-1/=1/, ; rc8000
l./i15=1014/, r/=1014/=2046/, ; max no of slices
l./i27=/, r/=1/=-1/, ; no drum
l./i29=1, r/=3/=2/, ; backing storage devices
l./e24:/, l1, r/6, 7, 8/10, 11/, ; std stations
l./e26=/, l1, r/10/ /, ; no special stations
l./e35:/, l1, r/5 ;/5, 42, 43 ;/, ; std printers
l./e58:/, l1, d, ; preselected papers:
i/
-1 ; printer 5: all except paper 7 and 8
7 ; printer 42: only paper 7
8 ; printer 43: only paper 8
/,

l./...3.../,
l./i140=/, r/=16384/=13312/, ; std size

l./...7.../,
l./e101:/, d,
i/
e101: <:RC COMPUTER:' 0, 0, 0, 0, 0, 0 ; login message
/, \f

f
scope user optt
if ok.no
end
clear user options
rename optt. options
end
\f

F_ 2_._ _ _ _ _ _ _ _ _S_T_A_R_T_-_U_P_ 2.

After system generation BOSS is started by the following com-
mands:

att s
all boss run ; the BOSS-process must be created with
; system bases

base abs <min' <max' ; if the system to be started is created on
; system scope, this command may be omitted;
; otherwise it is used to set the catalog
; base of BOSS according to the base of the
; system

bos ;

The file named >bos> contains a two-pass loader, which loads the
9 other coroutine files one by one. Each file is entered and
allowed to initialize itself. The files reserve room and define
addresses in the virtual store and in primary storage. The
address definitions are entered in a table of external symbols.

In the second loader pass, the files are loaded and entered again
exactly as in the first pass, but now the external symbols are
finished and addresses become complete. Certain functions which
were dummy in the first pass are active now. For instance, the
files now move code, tables, and variables to the virtual store.

At the end of the second pass, BOSS scans the catalog and tries
to clear all temporary and login files. At the same time, the
actual permanent resources for each user and project are deter-
mined. Finally, the user catalog is scanned and all permanent
rest claims are updated according to the actual resources used.
When a user has run under s, for instance, it may happen that the
actual files exceed the claims stated in the user catalog. In
this case BOSS just leaves a rest claim of zero, so that the user
cannot get more permanent resources under BOSS. This balancing of
\f

user catalog against main catalog involves all bs-devices mounted
for the moment. Entries in the user catalog referring to other
disc packs are left unchanged.

During the initialization, a well defined access to various
devices and files is established. For instance, all magnetic
tapes available for jobs are unloaded.

2_._1_ _ _ _ _ _ _ _W_a_r_n_i_n_g_s_ _D_u_r_i_n_g_ _S_t_a_r_t_ _U_p_ 2.1

At start up BOSS may write some warnings on the main console,
concerning catalog balancing, testoutput, and accounting.

M_m_m_ slices
1. project no: <integer' rest claim: <integer' on <document'
P_p_p_ entries

This message occurs when a project has used more permanent
resources on the specified document than allowed according to the
user catalog.

The message may be caused by:

a) creation of files under >s>
b) decrease of claims in the user catalog
c) overlap of intervals in the user catalog.

2. *** test output inactive

Occurs if no area exists and no tape is mounted with the name
>bosstest>, or if >bosstest> is not created with system scope.

3. <error description'
accountjob not ok

Occurs if no jobfile with the name >accountjob> exists with system
scope, or if it is not a legal job.
\f

2_._2_ _ _ _ _ _ _ _E_r_r_o_r_ _M_e_s_s_a_g_e_s_ _D_u_r_i_n_g_ _S_t_a_r_t_ _U_p_ 2.2

If BOSS gets into serious troubles during startup, it writes an
error message on the main console and then stops (with BOSS fault
5). The possible error messages are:

1. coroutine area missing
one of the binary coroutine files is not visible from BOSS>
catalog base.

2. create disccore error
during start up BOSS creates two areas for its virtual core
(disccore and drumcore). If the creation of disccore is
unsuccessful this message appears.

3. create drumcore error
see 2.

4. dummy answer coroutine
one of the binary coroutine files cannot be used.

5. external outside limits
references are exchanged between files via externals; such an
external is out of range.

6. input error virtual core
a work file could not be read during start up.

7. i116 too small : w0=min value
the number of segment places in core is too small.

8. max coroutine too small
option e3 is too small, there is not room for one of the
coroutine files.

9. output error virtual core
during start up writing in a work file was unsuccessful.
\f

11. table reservation error
one of the tables, which can be seen in section 3.1 is
created with wrong size, possibly because different options
have been used for translating different coroutine files.

12. transfer error coroutine
BOSS cannot get started because of input troubles when
reading a coroutine file.

13. virt core table too small
possibly same cause as for error No 11.

14. too many bs devices
appears if the installation (the monitor) is equipped with
more bs devices than described in BOSS> options (i29).

15. catalog input trouble
the main catalog could not be accessed, probably because of
hardware errors.

16. drum or disc missing
the value of the option i29 is too high.

17. entries do not match usercat
the user catalog is inconsistent, most likely because the
latest translation of it was unsuccesful. Retranslate and
check the output from the translation carefully.

18. usercat incorrect
the user catalog is inconsistent. See 17.

19. user cat input trouble
the user catalog could not be accessed, either because of
hardware errors, because it did not exist, had wrong scope, or
was reserved by another process.

20. virtual storage too big
the total demand on virtual storage exceeds 4095 segments.
Check the values of the options i41, i52, and i67 (options
page 2).
\f

21. time inconsistence accountf1
date and time n_o_w_ (as defined by the system clock) is e_a_r_l_i_e_r_
than date and time when BOSS was last running.
The first part of chapter 5 describes how the situation may
remedied.

During start up the banker is called to investigate whether the
resources promised by the BOSS options and the resources stated
in the user catalog are in accordance with the resources given by
the monitor to the BOSS process. If the comparison of resources
is not ok, one of the following messages may appear:

too few stations
too few temp entries
too few temp disc slices
too few convert operations
too few account operations
too few message bufferws
too few area processes
too few internal processes
too few suspend operations
too few temp drum entries
too few temp drum slices
too few remote readers
too few standard readers
too few protection keys
\f

F_ 3_._ _ _ _ _ _ _ _ _R_U_N_T_I_M_E_ _R_E_Q_U_I_R_E_M_E_N_T_S_ 3.

This chapter is a survey of the organization of BOSS at runtime.
The information is useful for understanding the options (section
1.3).

3_._1_ _ _ _ _ _ _ _P_r_i_m_a_r_y_ _S_t_o_r_a_g_e_ _U_t_i_l_i_s_a_t_i_o_n_ 3.1

At runtime the BOSS-process is organized like this:

testoutput code
central logic
pager
first free core

job process a (variable size)

room for BOSS pages (at least i116 segment places)

job process b (variable size)

last free core

core table
segment table
semaphore table, printer buffers, etc.
terminal buffers
sender table
coroutine table
file access table
testoutput buffer
\f

Most of BOSS> code and variables is placed in the so-called
v_i_r_t_u_a_l_ _s_t_o_r_e_ consisting of two backing store files >drumcore>
and >disccore>. Pages of the virtual store are transferred
to/from the primary storage as the need arises. If only one or no
job is present in core store, the the space thus left free will
be used for pages. A large job may force the minimum room for
pages to move to >last free> (or >first free>), thus also
preventing another job from using the core store.

3_._2_ _ _ _ _ _ _ _R_e_s_o_u_r_c_e_ _R_e_q_u_i_r_e_m_e_n_t_s_ 3.2

The resources required by BOSS depend on options. The
requirements of a special installation may be estimated by means
of the following rules of thumb. Please be aware, that these
formulas only give an approximate result, due to changes and
extensions.

The resource demands primarily depend on the following options:

number of pseudo jobs i45
number of terminals i4
(plus main console and operator display)
number of standard printers i71
number of remote printers i190
number of tape readers e52+e53
number of card readers i93+i200
number of tape stations e25+e26
number of exchangeable disc drives e23
\f

Resources for each item and fixed resources:

primary
storage area message
(halfwords) processes buffers
pseudo job 56 1 1
terminal 82+i3* 1 1
std printer 56+e40** 1 1
remote printer 56+e47*** 1 1
reader 56 1 1
card reader 56 1 1
tape station 32 0 1
exchangeable disc 22 0 1
fixed resources:
resident code 2450 - -
test buffer 512 - -
preoccupied
area processes - 12 -
preoccupied
message buffers - - 8

* terminal buffer size
** standard printer buffer size
*** remote printer buffer size

Besides the demand on primary storage as computed from the table
above, BOSS requires room for the following three tables:

1. f_i_l_e_ _a_c_c_e_s_s_ _t_a_b_l_e_, which describes BOSS> access to any area
process in the monitor.
size = 1 halfword for each area process in monitor.

2. s_e_g_m_e_n_t_t_a_b_l_e_, which describes the segments of BOSS> virtual
store. size = 1 halfword for each segment in drumcore and
disccore (usually 600 - 1000 halfwords).
\f

3. c_o_r_e_t_a_b_l_e_, describing >free core>, (dotted line in 3.1),
which is organized as a number of >segment places>.
coretable size = 4 halfwords for each segment place
= (BOSS> process size
- primary storage from table
- file access table
- segmenttable) / 516

The maximum size of a job will then be:

maxjobarea = BOSS> process size
- primary storage from table
- file access table
- segment table
- coretable size
- 512 * i116 (minimum area for BOSS> segmentation).

Apart from the resources mentioned, the BOSS process demands at
least 4 internal processes (sparse, 8 will be better), plus the
paper tape reader, plus the devices specified in the options,
page 1. The paper tape reader must have the name >reader>, a pos-
sible card reader must have the name >cardreader>.

The monitor constants for input time out from typewriters should
be carefully considered. If BOSS expects input from a typewriter,
all output to the typewriter will pend until the user (or opera-
tor) completes the input line or the monitor completes the ope-
ration because of time out.

Especially, messages from the operator to a terminal must await
completion of input from the terminal, and operator requests from
BOSS must await completion of input from the operator.

Disc slices:
BOSS demands a disc claim corresponding to the total disc
slices as computed in the scheme plus resources to fulfil all
rest claims in the user catalog. Of the total disc slices,
i108*4 are available for jobs (see option i108 on page 3).
Remaining disc slices are available for jobs.
\f

Drum slices: Analogous to disc slices, i112 replacing i108.

Catalog entries: Analogous to disc slices, i107 replacing i108.
The rest claims in the user catalog are defined as:
-first word in user catalog - present number of catalog
entries occupied by users in the user catalog.
This accounts also for disc packs not mounted at present.

Message buffers:
Of the total number of message buffers needed, i109*4 are
available for jobs. Of these, i109 are available for class 3
jobs, 2*109 for class 2 jobs, 3*109 for class 1 jobs, and
4*109 for class 0 jobs. Remaining message buffers are
available for all jobs.

Area processes:
Of the total number of area processes needed, (i110-1)*4 are
available for jobs. Of these, i110-1 are available for class 3
jobs, 2*(i110-1) for class 2 jobs, 3*(i110-1) for class 1
jobs, and 4*(i110-1) for class 0 jobs. Remaining area
processes are available for all jobs.

3_._3_ _ _ _ _ _ _ _S_w_o_p_p_i_n_g_,_ _s_p_o_o_l_i_n_g_ 3.3

A job in core may be s_w_o_p_p_e_d_ _o_u_t_ because it waits for operator or
user action or because a high priority job wants the core. The
swop-out consists of stopping the job process and copying the
core area into a s_w_o_p_ _a_r_e_a_ on disc. A corresponding swop-in takes
place when the core area is free or occupied by a low priority
job. The swop area is created as a separate file at jobstart. The
internal resource demands of the job are increased
correspondingly.

I/O to some devices (terminals, tape reader, card reader, and
printers) is spooled, which means that a backing store area (the
s_p_o_o_l_ _a_r_e_a_) is used to collect the information in case the
producer of the information runs faster than the consumer. Most\f

of the spool areas in BOSS (namely those for primary output from
jobs) are created as separate files at job start, and the
resource demands of the job are adjusted accordingly. Spool areas
for controlled i/o (readers and printers) are a fixed part of the
virtual store (option i41, i52, i67). In case of off-line jobs,
the resources needed to hold the job file cannot be attributed to
a job initially, as the job specification is interpreted later.
Thus, a set of resources is set aside for the purpose (option
i162, i163).

3_._4_ _ _ _ _ _ _ _O_t_h_e_r_ _F_i_l_e_s_ _U_s_e_d_ _a_t_ _R_u_n_ _T_i_m_e_ 3.4

Catalog:
BOSS scans the main catalog at job termination in order to clean
away entries and areas left non-permanent by the job (can be
avoided by an option in the user catalog).

A logout both >temp> and >login>-entries will be removed (this
can not be avoided).

Usercat:
BOSS searches the user catalog at initialization, job start, and
login. The user catalog is modified whenever a user changes his
amount of permanent files. The user catalog is reserved all the
time by BOSS.

Accountjob:
When BOSS is started up, the account job is enrolled automatically
with the job file found in the file named accountjob. The account
job is then suspended until the account file is to be processed
(chapter 5).

Accountfile, accountf1:
BOSS collects account information in the file >accountf1>. When
this file is to be emptied, it is renamed to >accountfile> (if
possible) and the account job is activated. Meanwhile BOSS
continues collecting in a new >accountf1>. Further details in
chapter 5.
\f

Bosstest:
When BOSS starts up, it checks to see whether a magtape with the
name bosstest exists. Then the tape is used for testoutput,
starting at the beginning of the file on which the tape is
positioned.

Otherwise BOSS tries to get access to a bs-file named bosstest.
If it succeeds, testoutput is generated here. Otherwise the
testoutput is just stored cyclically in the core store buffer.

The amount of testoutput is controlled by option e81 to e98 (see
the options page 5).
\f

F_ 4_._ _ _ _ _ _ _ _ _B_O_S_S_O_L_D_ 4.

Bossold is the first of the source text files. This file contains
a variety of programs which may be used in generating,
translating, and updating BOSS.

The command
i bossold
generates the following programs (jobs):
bossbin
bossupdate
bosstrans
bossload
as temporary files (scope temp).

Bossold itself checks if the file descriptors are ok; if they are
the program is terminated with the following message:
file descriptors left unchanged

In case no file descriptors exist for the files, file descriptors
are created and the two files o_p_t_i_o_n_s_ and j_o_b_d_e_s_c_r_ are transfer-
red to the bs device wanted.

4_._1_ _ _ _ _ _ _ _B_o_s_s_b_i_n_ 4.1

Bossbin is a job which translates all the BOSS coroutines, the
>catupdate> program and the test output program.

4_._2_ _ _ _ _ _ _ _B_o_s_s_u_p_d_a_t_e_ 4.2

Bossupdate generates an updated version of all the BOSS files on
a magnetic tape. The following commands may be used:

bossnew=set <mode' <tapename' 0 1
i bossupdate.
\f

As a control of the files written on the magnetic tape the tape
is check read and in the output it is possible to see if the
generation of the tape has succeeded.

If >bossupdate> cannot find a file descriptor named >bossnew> the
errormessage
- bossnew not set
will appear and the program will terminate.

4_._3_ _ _ _ _ _ _ _B_o_s_s_t_r_a_n_s_ 4.3

Bosstrans is much like >bossbin> but only the BOSS coroutines are
translated and stored on disc.

4_._4_ _ _ _ _ _ _ _B_o_s_s_l_o_a_d_ 4.4

Bossload loads all the files from the BOSS magnetic tape and
stores the files as textfiles on the disc. The files get user
scope. If temporary file descriptors exist with names equal to
some of the files to be loaded these temporary entries are
removed.

If bossold does not exist the following errormessage appears
- bossold not set
Bossold must exist because the files to be loaded are assumed to
be loaded from a magnetic tape described by the file descriptor
>bossold>.

If >bossold> exists on another document than a magnetic tape then
the following errormessage will appear
- bossfiles not loaded

In case of an errormessage the program will terminate.

If a file >bossnew> exists on a bs document, all the BOSS files
will be loaded on this document, otherwise they will be loaded on
the system disc.

F_ 5_._ _ _ _ _ _ _ _ _A_C_C_O_U_N_T_I_N_G_ 5.

While BOSS is running, essential information concerning the use
of resources is collected as records in a file with the name
>accountf1>. This file is created and maintained by BOSS as a
permanent file with the size given by the option i105 (options
page 2). The file will be created on >disc> and the entry base
will be (-8388607, -8388607), which is called the >account base>.

When BOSS starts up, >accountf1> will be looked up, and if it
does not exist, BOSS will create an empty file as described
above. If the file exists, BOSS will scan it in order to find out
where output to the file is to be resumed. Normally there will be
a special stop-record, and output will then be resumed so that
this record will be overwritten at the next writing. At the same
time a new stop record will be inserted, except if current
segment is full.

If, during the scan, BOSS finds a record with illegal contents,
BOSS will assume that a crash happened, and resume writing from
that point.

All records contain the system time of their production, and if
the value of system time in the last record found during the scan
is larger than the current value of system time, BOSS will stop
with the message:
time inconsistence accountf1
***boss fault 5.

This is a valuable check on the initialization of system time
during start up. In such cases, check if system time is correct.
If not, autoload and reinitialize system time. Otherwise system
time was not correct when BOSS was last running. In that case do
as follows:

*att -'s
-'proc boss remove all boss run
ready
\f

to boss
-' base 0 0 ; set catalog base = account base
-' rename accountf1.accountfile
-' base ; reset catalog base (to system base)
-' bos ; start boss

BOSS will then make a new >accountf1> and enroll the accountjob
for execution immediately after start up (cf. section 5.2).

You may also use another name than >accountfile> e.g. (instead of
"rename ..."):

-' rename accountf1.badaccount
-' scope user badaccount

and then analyse the file "manually". In that case you should n_o_t_
later rename >badaccount> to >accountfile> if BOSS has been star-
ted in the meantime. You might also use the standard accountjob
(cf. section 5.2) to print the file and then cancel it, like this
(instead of "rename ..."):

-' writeacc = algol message.no accountjob
-' o lp
-' writeacc in.accountf1
-' o c
-' scope temp accountf1
-' clear temp accountf1

Of course you may also make copies of >accountf1>, but apart from
this, and obviously harmless variations of the examples given, it
is not permitted to tamper with >accountf1> or >accountfile>. If
you do, you may experience:
***boss fault 80
while BOSS is running, or:
create accountf1 error
*** boss fault 5
during start up. (Otherwise these errors will be due to errors in
hardware).
\f

5_._1_ _ _ _ _ _ _ _A_c_c_o_u_n_t_ _R_e_c_o_r_d_s_ 5.1

The accountfile contains fixed-length records (recordlength = 32
halfwords), blocked 16 records to a segment.

All records have the following format:

+0 project number (word)
+2 to +6 user name (9 characters) (not always terminated)
+8 user index etc. (word, see below)
+10 record kind (word)
+12 to +14 time (double word)
+16 to +30 parameters depending on record kind.

The contents of the field >user index etc> are controlled by the
option e71 (options page 5). If e71=0, (which is the default
value) the word will always be 0 (providing a convenient
terminator for the text in >username>). If e71=1 the right half
of the word will contain user index, while the contents of the
left half of the word will depend on record kind (see below).

In the following list of existing record kinds, only the fields
+8 and +16 to +30 are mentioned. If some of these fields are not
mentioned, their contents are undefined. Please notice, that the
addresses given here (and above) are relative to record start as
they would be in a slangprogram. The standard account job (cf.
5.2) shows corresponding suitable field variable declarations and
initializations for an ALGOL program.

R_e_c_o_r_d_ _k_i_n_d_ _=_ _1_,_ _j_o_b_f_i_n_i_s_
Produced whenever a job finishes (this also applies to the small
jobs which actually perform on-line converts).
\f

+8 (hw) 0 or finis cause (see below)
+9 (hw) 0 or user index
+16 (word) net run time used (seconds)
+18 (hw) mounts used
+19 (hw) loads used
+20 (word) cpu-time used (unit:08192 secs)
+22 (hw) temp drum (slices demanded)
+23 (hw) temp disc (slices demanded)
+24 (hw) stations demanded
+25 (hw) size (unit: 512 hw)
+26 (word) device word (first 24 bits) (see below)
+28 (word) device word (last 24 bits) (see below)
+30 (hw) deliberate waiting (minutes)
+31 (hw) conversation (no. of lines input)

Finis cause is an integer code specifying how (or why) the job
finished, the coding is:

0 (normal finis)
1 killed by user
2 time exceeded
3 replaced by jobfile: ...
4 job file exhausted
5 job file unreadable
6 killed by operator
7 mode unknown ...
8 output exceeded
9 not special station: ...
10 special station not ordred: ...
11 ring not allowed on tape: ...
12 tape reserved for other project: ...
13 stations exceeded at mount ...
14 suspends exceeded
15 login claims exceeded
16 tape used by other job: ...
17 accounts exceeded
18 convert file unreadable (see below)
19 max waiting time exceeded
\f

20 bad fp
21 size too small for fp
22 no interrupt address
23 mount special after mount ...
24 corelock not allowed
25 corelock exceeded
26 load area in use ...
27 hard error on initial program or swop area ...
28 too few resources on ...
29 job name conflict
30 program does not exist
31 size too small
32 temp exceeded
33 replace file unreadable ...
34 replace file too long ...
35 temp exceeded job file
36 card deck exhausted
37 limited ...
38 option unknown ...
39 param at ...
40 syntax at ...
41 line too long after ...
42 device unknown ...
43 hard error on convert file ... (see below)
44 job creation impossible
45 file is no text file

If the job was an on-line convert, 100 will be added to the codes
shown above, so that (e.g.):
100 means: on-line convert, normal finis
137 means: on-line convert, limited (disc slices).

The codes 18 and 43 will therefore never appear. (They are
replaced by 118 and 143).

The device word (+26 and +28) is a double word with one bit
corresponding to each device mentioned in the device list in
options (options page 1, between e24: and e17=).
\f

The most significant bit always equals 0, the next bit
corresponds to job controlled reader, the next bit to job
controlled printer, and so on backwards (i.e. from e17 and up)
through the list, ending with special tape stations.

Using the standard options as an example, the device word is
interpreted as follows:

0 shift 47 (always zero)
1 shift 46 job controlled reader (tapes ... ordred)
1 shift 45 job controlled printer (device printer)
1 shift 44 job controlled cards (device card)
1 shift 43 device punch
1 shift 42 device plotter
1 shift 41 device 14
1 shift 40 device 0
1 shift 39 device 10

R_e_c_o_r_d_ _k_i_n_d_=_2_,_ _l_o_g_o_u_t_
Produced when a user logs out from a terminal. When the account
job is being started (cf. 5.2) there is a brief period of time
(some tens of milliseconds), during which the production of a
logout record may be skipped.

+8 (hw) 0 or logout cause (see below)
+9 (hw) 0 or userindex
+16 (word) time logged in (minutes)
+18 (word) operations performed (see below)

logout cause is an integer with the meaning:

0 normal logout (requested by user)
1 hard error on terminal
2 operator remove
3 timeout on terminal

>Operations> is an estimate of the amount of work performed by
BOSS during the session.
\f

It is increased by 1 after:
- each command line and edit line read (also in autoline mode),
but not for input lines to conversational jobs.
- each line printed in response to simple commands like
>display>, >list>, >verify>, >lookup>, etc., but not for output
from jobs.
- >get>, >save>, and >transmit>: one for each segment (768
characters) in the file.

R_e_c_o_r_d_ _k_i_n_d_ _=_ _3_,_ _p_r_i_n_t_
Produced when a file has been printed.

+8 (hw) 0 or convert kind (see below)
+9 (hw) 0 or user index
+16 (word) number of lines printed
+18 (word) number of pages printed (see below)
+20 (word) paper type (see below)

>Convert kind> is an integer with the meaning:

0 normal convert, either on-line or from a job
1 primary output from a job
3 jobcontrolled printing

>Pages> is 1 + number of formfeeds in the file. >Paper type> is
the paper type ordered in the convert operation. For primary
output >paper type> will always be 0. For jobcontrolled output,
>paper type> is the last paper type used.

R_e_c_o_r_d_ _k_i_n_d_ _=_ _4_,_ _j_o_b_ _(_j_o_b_s_t_a_r_t_)_
The option e70 (options page 5) controls the production of these
records. If e70=0, which is the default value, they are not
produced. If e70=1 the record will be produced at jobstart.

+8 (hw) 0 +17 (hw) initial priority
+9 (hw) 0 or user index +18 (word) expected net runtime
+16 (hw) 0 +20 (word) expected gross runtime
\f

The record is produced when the job specification has been
checked, and it has been checked that BOSS has resources to
fulfil the claims of the job. This will normally be a few hundred
milliseconds (typically 200-300 msec.) after the command starting
the job was issued (or the paper tape or the card file containing
the job was read). Notice that this is before reservation of
resources, and before load-specifications (if present) are
checked and executed.

The accountrecord is not produced for jobs which are killed or
stopped because of errors before they reach the stage explained
above. The account record is also not produced for the small jobs
which carry out on-line converts.

In such cases a j_o_b_f_i_n_i_s_ accountrecord (kind = 1) may or may not
be produced, depending on why the job finished: if errors occur
before username, userindex, and project number have been checked
(and approved) no jobfinis accountrecord will (or indeed can) be
produced.

When the accountjob is being started (cf. 5.2), because the
operator started it or because the accountfile is full, there is
a short period of time (some tens of milliseconds), during which
accountrecords of kind 4 cannot be produced (cf. accountrecords
of kind 2).

R_e_c_o_r_d_ _k_i_n_d_s_ _b_e_t_w_e_e_n_ _4_ _a_n_d_ _9_9_:_ _i_l_l_e_g_a_l_.

R_e_c_o_r_d_ _k_i_n_d_ _=_ _9_9_,_ _s_t_o_p_
This record signals the end of the accountfile, as already
mentioned. Please notice that a_l_l_ other fields than record kind
are undefined.

R_e_c_o_r_d_ _k_i_n_d_ _'_=_1_0_0_,_ _p_r_i_v_a_t_e_ _a_c_c_o_u_n_t_r_e_c_o_r_d_s_
These records are produced, at the request of jobs, by means of
the parent message >account>, which may be sent by means of the
utility program >account> or by other programs.
\f

+8 (hw) 0
+9 (hw) 0 or user index
+16 (word) word m+14 from the account message.
+18 (word) word m+8 from the account message.
+20 (word) word m+10 from the account message.

The meaning of the information is defined by the user. Notice
that record kind may also carry information.

If you use the utility program >account>, the connection between
parameters and accountrecord will be: param1 = record kind,
param2 = record +16, param3 = record+18, param4 = record+20.

5_._2_ _ _ _ _ _ _ _A_c_c_o_u_n_t_j_o_b_ 5.2

The information collected in >accountf1> may be used to super-
vise computer utilization, for resource planning, customer
changing, etc. In order to take care of this, or at least to empty
the file when it runs full, all installations must include an
a_c_c_o_u_n_t_j_o_b_ with these characteristics:

- The jobfile must be a permanent file with the name
>accountjob>, it must be visible from the account base
(-8388607, -8388607), and it must be present when BOSS is
started.

- The project must be defined in the user catalog with a
project base which includes the account base, and it must (at
least) have permanent resources on the system disc to account
for the accountjob and two accountfiles.

- The user must have >job width>=1, >no. of user indices>=1 and
the user base must be the account base.

- The accountjob must include actions to cancel or ortherwise
dispose of (e.g. by renaming) a file with the name
>accountfile>.
\f

Besides this the accountjob and the accountproject may be handled
as ordinary jobs and projects.

The accountjob is looked up and taken through the first stages of
a normal jobstart each time BOSS starts up, and it is then stop-
ped just a_f_t_e_r_ the point where the jobstart-record (cf. 5.1) is
produced. Then it waits until the account file runs full or the
operator types >start account>. When this happens, BOSS will
rename >accountf1> to >accountfile> and let the execution of the
accountjob continue.

Meanwhile BOSS will create a new >accountf1> and use this file to
collect the accountrecords.

When the accountjob finishes, BOSS checks that >accountfile> has
been removed, and initializes the accountjob as during start-up.

If >accountfile> still exists when the accountjob finishes, BOSS
writes the message
accountjob not ok
and enrolls the accountjob for execution again.

The standard accountjob supplied with BOSS is shown in subsection
5.3 as an example of an accountjob.

If you want to use it or modify it to suit your own needs, please
notice:

- The job may run with a size as small as 13312 hw but
inefficiently.

- The job will remove >accountfile>, even if the printing of the
accountfile is unsuccessful.

- You may want to change the value of lines _on _a _page,
slicelength _on _drum, and slicelength _on _disc.
\f

If you make your own accounting system, you should try to
minimize the runtime of the accountjob, and let an ordinary job
carry out the main part of the work, e.g. as outlined in the
following rough sketch:

The accounting project in the user catalog:

10 4711 0 10 3 -8388607 -8388604
4 perm disc1 50 20 21
5 perm disc1 0 0
11 accouser 4711 0 1 1 -8388607; userbase = account base
; notice, that >boss private base> (-8388606, -8388606)
; is - and m_u_s_t_ be - left free.
11 otheruser 4711 0 1 2 -8388605
; notice, that this user has 2 userindices, one for
; >bigjob> and one for editing etc.

The file >accountjob> contains something like this:

job accouser 4711
mode list.yes
lookup accountfile accountf1 accofile
rename accountfile.accofile
scope project accofile
newjob bigjob
finis

The file >bigjob> contains:

job otheruser 1 4711 time... etc.
...
... this is where the real work is done
...
finis

Finally: if you want to use the jobstart records (kind=4) to keep
track of job turn-around-time, please remember that there is not
a one-to-one correspondence between jobstart records and jobfinis
records, especially not if you only scan the accountrecords in a
single accountfile at a time.
\f

5_._3_ _ _ _ _ _ _ _T_h_e_ _S_t_a_n_d_a_r_d_ _a_c_c_o_u_n_t_j_o_b_ 5.3

The following is a listing of the file >taccount> which contains
the standard accountjob.
\f

F_\f

F_ 6_._ _ _ _ _ _ _ _ _T_H_E_ _U_S_E_R_ _C_A_T_A_L_O_G_ _I_N_ _B_O_S_S_ 6.

G_e_n_e_r_a_l_

At start up the operating system BOSS reserves the file named
>_u_s_e_r_c_a_t_>_ which must be visible from the account catalog base
(see chapter 5). While BOSS is running, >usercat> is used to
identify users and determine their standard resources and
possible maximum resources.

The file >usercat> (the user catalog) is a hierarchical structure
of subcatalogs of variable-length records. Each record describes
a piece of information for a user or a project available in the
user catalog. The sequence of records is as follows with the
sequence shown in more and more detail:

first project project head
project spec.
second project first user user head
. second user user spec.
. .
last project
end record

The project head states the project number, the project catalog
base and the project pool on disc. The user head states the user
name, the user>s catalog base and the number of user indices.
Project specifications and user specifications may be absent, but
if present they specify standard and maximum resources.

6_._1_ _ _ _ _ _ _ _R_e_s_o_u_r_c_e_ _A_l_l_o_c_a_t_i_o_n_ _t_o_ _a_ _J_o_b_ 6.1

The resources available to a job are determined partially from
the information found in the user catalog and partially from
BOSS options. The actual resources for a job are determined by
the following algorithm:
\f

resources:= standard resources from options
modify resources according to project specifications
- - - - user -
- - - - job -

The final resources must be within the maximum resources and
within the resources available to the time class of the job (cf.
User>s Manual, section 4.2)

6_._2_ _ _ _ _ _ _ _T_h_e_ _S_t_r_u_c_t_u_r_e_ _o_f_ _t_h_e_ _U_s_e_r_ _C_a_t_a_l_o_g_ 6.2

The user catalog is sorted so that the projectnumbers appear in
ascending order, and within the projects the user names appear in
ascending order.

6_._2_._1_ _ _ _ _ _I_n_d_e_x_ _S_e_g_m_e_n_t_s_ 6.2.1

The first few segments of the user catalog contain an index table
in which word no. n describes the contents of segment no. n. A
negative number means that the segment is part of the index
table, while a positive number is a project number, which
indicates that the last information on the corresponding segment
concerns this project number.

Unused words in the last part of the index table have the value
8388607 (the maximum positive integer).

Furthermore the first word in the index table is used to store
the total number of entries claimed by users and projects in the
catalog (represented as a negative number).

The end of the user catalog is signalled by a record of type 0
with project = 8388607.
\f

F_ 6_._2_._2_ _ _ _ _ _R_e_c_o_r_d_ _T_y_p_e_s_ _i_n_ _t_h_e_ _C_a_t_a_l_o_g_ 6.2.2

The two first halfwords of each record describe the type and the
length of the record.

Type 0 and type 2 records are special records. Type 0 describes
projects and type 2 users within the projects. All common
information and resources follows a type 0 record and all
information concerning a user follows a type 2 record. Type 0 and
type 2 records are mandatory in the catalog, all other types are
optional.

The following lists all the record types and for each type the
meaning of each field (halfword or word) is described.

Many of the records correspond to options in the job
specification. These records may indicate either a standard value
(if the type is specified as an even integer) or a maximum value
(if the type is incremented by one (odd value)). Such record types
are marked with an asterisk (*).

type 0 project (input: type 1 and 10)
+0 0, 12
+2 project number
+4,6 project interval
+8,9 rest entries, rest slices on disc
+10,11 total entries, total slices on disc

type 2 user (input: type 2 and 11)
+0 2, 16
+2-8 user name (8 halfwords)
+10 user interval start
+12 standard interval length
+14 number of user indices

type 4 priority / late (input: type 7 (no longer used))
+0 4, 6
+2 standard value of priority
+4 minimum value of late
\f

type 6 private disc kits (input: type 4)
+0 6, 16
+2-8 device name (8 halfwords)
+10,11 rest entries, rest slices
+12,13 total entries, total slices
+14 slice length

*type 8 devicemask (input: 5, 6 device)
+0 8*, 6
+2 first word with device bits
+4 second word with device bits

*type 10 accounts (input: 5, 6 accounts)
+0 10*, 4
+2 number of account buffers

*type 12 area processes (input: 5, 6 area)
+0 12*, 4
+2 area claim

*type 14 message buffer (input: 5,6 buf)
+0 14*, 4
+2 buffer claim

*type 16 convert operations (input: 5, 6 cbuf)
+0 16*, 4
+2 internal claim

*type 18 internal processes (input: 5, 6 internals)
+0 18*, 4
+2 internal claim

*type 20 keys (input: 5, 6 key)
+0 20*, 4
+2 number of protection keys

*type 22 mounts (input: 5, 6 mounts)
+0 22*, 4
+2 number of mounts
\f

*type 24 output (input: 5, 6 output)
+0 24*, 4
+2 number of slices in primary output

*type 26 size (input: 5, 6 size)
+0 26*, 4
+2 size of process (in halfwords)

*type 28 stations (input: 5, 6 stations)
+0 28*, 4
+2 number of standard tape stations

*type 30 tapes (input: 5, 6 tapes)
+0 30*, 4
+2 number of job controlled paper tapes

*type 32 time (input: 5, 6 time)
+0 32*, 4
+2 net run time (in units of 0.8192 secs.)

type 34 user with userpool (input: type 9)
+0 34, 10
+2,4 user max interval
+6,7 rest entries, rest slices on disc
+8,9 total entries, total slices on disc

type 36 drum, key 1 (input: 5 temp drum)
+0 36, 4
+2 temp drum entries, slices

type 38 disc, key 1 (input: 5 temp disc)
+0 38, 4
+2,3 temp disc entries, slices

type 40 disc, key 3 (input: 5 perm disc)
+0 40, 4
+2,3 perm disc entries, slices
\f

type 42 output identification (input: type 3)
+0 42, variable length
+2 text, max. 300 characters

type 44 drum, key 3 (input: type 8)
+0 44, 6
+2,3 rest entries, rest slices
+4,5 total entries, total slices

type 46 drum, key 3 (input: 5 perm drum)
+0 46, 4
+2,3 perm drum entries, slices

type 48 private disc kit (input: 5 perm <kitname')
+0 48, 12
+2-8 device name (8 halfwords)
+10,11 perm <kitname' entries, slices

*type 50 max turn-around time (input: 5, 6 latest)
+0 50*, 4
+2 latest (in units of 0.8192 secs.)

type 52 information for accountjob (input: type 12)
+0 52, 16
+2-14 project identification in textform (max. 20 chars).

type 54 program (input: 5 program)
+0 54, 10
+2-8 name of program to be loaded (8 halfwords)

*type 56 available suspend buffers (input: 5, 6 suspends)
+0 56*, 4
+2 suspendings

*type 58 online (input: 5, 6 online)
+0 58*, 4
+2 conversational jobs allowed (1) / not allowed (0)
\f

*type 60 corelock (input: 5, 6 corelock)
+0 60*, 4
+2 corelock time

*type 62 degree of information (input: 5, 6 minimal)
+0 62*, 4
+2 minimal yes (1) / no (0)

*type 64 priority (input: 5, 6 priority)
+0 64*, 4
+2 start priority factor

*type 66 deliberate waiting (input: 5, 6 wait)
+0 66*, 4
+2 maximum wait time swopped out

*type 68 catalog preservation (input: 5, 6 preserve)
+0 68*, 4
+2 preserve yes (1) / no (0)

*type 70 terminal user rights (input: 5, 6 privilege)
+0 70*, 4
+2 privilege bits.

6_._3_ _ _ _ _ _ _ _H_o_w_ _t_o_ _C_r_e_a_t_e_ _a_n_d_ _U_p_d_a_t_e_ _t_h_e_ _U_s_e_r_ _C_a_t_a_l_o_g_ 6.3

This program, >catupdate>, is automatically translated whenever
the coroutine files are translated (by means of the command >i
bossbin>, cf. 1.2 and 4.1). At the same time a small binary file
>boptions> will be created. >boptions> contains information
concerning the installation (device numbers and backing storage
devices), extracted from >options>. This information is read and
used by >catupdate>.

6_._3_._1_ _ _ _ _ _S_y_n_t_a_x_ _f_o_r_ _t_h_e_ _C_a_l_l_ _o_f_ _>_c_a_t_u_p_d_a_t_e_>_ 6.3.1

M_m_m_ 1 1 on 1 1
<leftside'= catupdate cat.yes list. <input file'
P_p_p_ 0 0 off 0 0
<leftside' ' ::= usercat
/ <filename'

<input file' ::= <filename'
/ <mode kind'

<filename' is a name with at most 11 characters.

<modekind' :: = trf
/ tre
/ tro
/ crc
/ crd

6_._3_._2_ _ _ _ _ _E_x_p_l_a_n_a_t_i_o_n_ _o_f_ _P_a_r_a_m_e_t_e_r_s_ _t_o_ _>_c_a_t_u_p_d_a_t_e_>_ 6.3.2

<leftside' ::= usercat
/ <filename'

<leftside' is the resulting user catalog produced by >catupdate>.
BOSS assumes the user catalog to be on the file >usercat> and
reserves this file when it is running. Therefore the user catalog
must either be updated while BOSS is not running or the updating
may take place under BOSS producing a user catalog in a different
file and this other file may later be moved or renamed to
>usercat>.

If >catupdate> is called without <leftside' and without parame-
ters the existing user catalog is listed in a crude form corre-
sponding to the input format to >catupdate>. If this kind of
listing is produced when BOSS has been running, it will show the
current values of rest claims for backing storage resources.
\f

cat.yes
If cat.yes is present it is assumed that the catalog is made from
scratch, otherwise it is assumed that the input specifies changes
to the already existing user catalog in the file >usercat>.

M_m_m_ on
list.
P_p_p_ off
list.on has the effect that the input to >catupdate> is listed
as it is read.
list.off no input is listed, this is used as default.

<input file'
The input file from which the new catalog is created. (The input
format is described in later sections). The input file can for
instance be the final output from an earlier run of >catupdate>.

6_._3_._3_ _ _ _ _ _I_m_p_l_e_m_e_n_t_a_t_i_o_n_ _o_f_ _S_u_b_c_a_t_a_l_o_g_s_ 6.3.3

To be able to make input to >catupdate> (i.e. to be able to make
a user catalog), it is necessary to know how the hierarchy of
subcatalogs are implemented.

Each subcatalog is represented by a pair of integers denoting an
interval. The subcatalog represented by (l,h) is contained in the
subcatalog (l1,h1) if and only if
l1 <_ l <_ h <_ h1.

The biggest subcatalog is (-8388607, 8388605) all other catalogs
are subcatalogs of this catalog. For further explanation see the
Monitor3 manual.

6_._3_._4_ _ _ _ _ _I_n_p_u_t_ _t_o_ _C_a_t_u_p_d_a_t_e_ 6.3.4

The input in most cases consists of lines which specify a new
record in the user catalog, a change of a record, or deletion of
a record. Each line starts with a number specifying the record
type. Spaces or tabulator separate the fields of the line.
\f

Comments may be inserted in parenthesis between the fields, or at
the end of the line after a semicolon.

The input lines must occur in a sequence corresponding to the
records of the user catalog, thus:

project head (type 1 or 10)
project specifications (types 3 to 8, 12 and up)

user head 1 (type 2 or 11)
user specifications (types 3 to 9, 12 and up)

user head 2 (type 2 or 11)
user specifications (.....)

...
end input (type -1)

However, all sorting of projects and users within projects are
done by the program.

Below we show all possible line types. These lines may be
composed into various input forms according to the needs of the
staff. An example is shown later.

If you always make your user catalog up from scratch, it is
recommended n_o_t_ to use line types 1 or 2, because it will cause
you troubles when adding (or removing) projects or users. Instead
you should use line types 10 and 11.

P_r_o_j_e_c_t_ _h_e_a_d_,_ _s_i_m_p_l_e_

Project new=0 permanent disc Project width
number change=1 slices entries (omit at change)
1
\f

This record may specify a new project and its permanent disc
resources. The project number must be greater than 0 and less
than 1000000 and the project catalog base is allocated
automatically so that it does not overlap other projects (except
maintenance projects). The width of the project catalog base is
given in the last field. Normally, this should be 10 times the
maximum number of users ever on this project. The width cannot be
changed later.

The record may also specify a change of the permanent disc
resources of a project (fields contain the changes, + or -),
possibly followed by changes specified by other records.

P_r_o_j_e_c_t_ _h_e_a_d_,_ _a_b_s_ _b_a_s_e_ _o_r_ _d_e_l_e_t_i_o_n_

Project new=0 Permanent disc Project catalog base
number delete=2 slices entries lower upper
10

This record may specify a new project and its permanent disc
resources. The project number must be greater than 0 and less
than 1000000. The project catalog base must be supplied as a pair
of numbers.

The record may also specify deletion of a project and all its
users.

In this case the disc resources are not used. For safety reasons,
the catalog base must be specified.

U_s_e_r_ _h_e_a_d_,_ _s_i_m_p_l_e_

optional
User name Project new=0 job width No of user
number change=1 indices
2
\f

This record may specify a new user under the project. The user
catalog base is allocated automatically so that it does not
overlap other users of the project. The user catalog base will
normally have a width of 10, allowing 10 user indices (10 jobs
simultaneously from that user, independent of project). The
standard base of the job will thus normally have a length of 1,
but a larger width may be specified (job width).

User name must be one small letter followed by at most 8 small
letters or digits. Notice that if the name is longer than these 9
characters, >catupdate> truncates the name.

The record may also announce a change of the user specifications.
The two optional fields may n_o_t_ occur in this case.

U_s_e_r_ _h_e_a_d_,_ _a_b_s_ _b_a_s_e_ _o_r_ _d_e_l_e_t_i_o_n_

User name Project new=0 Job width No. of user First of
number delete=2 indices user base
11

This record may specify a new user under the project. The u_s_e_r_
c_a_t_a_l_o_g_ _b_a_s_e_ is specified by its absolute first point. The last
point will be: first of user base + job width * no of user
indices - 1. The s_t_a_n_d_a_r_d_ _b_a_s_e_ of a job will be: (first of user
base + job width * user index, same + job width - 1).

User name: see type 2 above.

Notice, that when a job terminates, BOSS cancels all temporary
files within the standard base. Thus the abs base should be used
with extreme care, especially if other users have their standard
base in the base specified, or if it includes the private base of
BOSS (-8388606, -8388606).

The record may also specify deletion of a user. For safety, the
first point of the user base must be specified.
\f

O_u_t_p_u_t_ _i_d_e_n_t_i_f_i_c_a_t_i_o_n_

The record specifies a textstring terminated with semicolon. Max.
300 characters. This text will appear on all print files.
Leading spaces on a line are skipped. Leading underlines
(ISO-value 95) may be used as significant spaces.

;

This record and the following types may appear after a project
head (common for all users of the project) or after a user head
(this user only).

P_r_i_v_a_t_e_ _k_i_t_s_

Kit name Slices Entries Segments in a slice
4

A job may only create areas on a kit (even temporary) if allowed
by a private kit record. If this record is used after a user
head, this user will not be able to use the project resources or
change project files. <kit name' may not be >disc> or >drum>.

S_t_a_n_d_a_r_d_ _v_a_l_u_e_ _o_f_ _o_p_t_i_o_n_

Option name Parameters.
(nearly as in job specification, see below)
5

>Device no> clears all previous device options. All device
options in a set of project specifications or user specifications
are combined and replace previous device information in the user
catalog.
\f

For the options >output>, >temp>, >perm> the parameter must be
specified as number of slices. Number of temp entries should be
specified at most once. (i.e. either in >temp drum> or >temp
disc>, but not in both).

It is a good idea always to specify a standard value for
permanent resources, in order to take care of the problem
mentioned in User>s manual for the perm-option.

Standard values for >latest> and >priority> can be specified.

Remember to change possible limit values of the options when a
standard value is increased.

L_i_m_i_t_ _v_a_l_u_e_ _o_f_ _o_p_t_i_o_n_

Option name Parameters. Upper limit.
(nearly as in job specification, see below)
6

Specifies the upper limit for options in the job specification.
>Device no> prevents the user from having any devices. He may be
allowed to use specific devices by means of succeeding device
options. All device options in a set of project specifications or
user specifications are combined and replace previous device
information in the user catalog. Limit value for >output> must be
in slices. Limit value for >temp>, >perm>, and >program> cannot
be specified.

Limit value for >latest> and >priority> can be specified. The
limit value for >latest> is a lower limit, while all other limits
are upper limits.

Notice, that >catupdate> does not check that the limit is
consistent with the standard value or the actually available
resources in the computer.
\f

D_r_u_m_

Permanent drum resources
slices entries
8

U_s_e_r_ _p_o_o_l_,_ _n_o_ _p_r_o_j_e_c_t_ _r_i_g_h_t_

Permanent resources The user will have no right to
on system disc change the project files, and will
slices entries not be able to use the project
9 resources.

Cannot occur in project specifications (i.e. between the project
head and the first user head).

A_c_c_o_u_n_t_i_n_g_ _i_n_f_o_r_m_a_t_i_o_n_

Further information for account job. Max. 20 characters.
Terminate with semicolon. Leading spaces are skipped. Leading
underlines (ISO-value 95) may be used as significant spaces.

12 ;

E_n_d_ _o_f_ _u_s_e_r_ _o_r_ _p_r_o_j_e_c_t_

-1

6_._3_._5_ _ _ _ _ _E_x_a_m_p_l_e_ 6.3.5

Creation of a demonstration user catalog from scratch.

; BOSS demonstration user catalog
10 51 0 3 3 -8388607 -8388607

2 account 51 0 1 1
; a project No 51 is created on the account catalog base
; with the single user account (see chapter 6)
\f

10 1 0 125 50 900 999
5 perm disc 50 5
5 privilege 3
5 time 3 0
6 minimal yes
6 online yes
3 RC8000
demonstration;
11 usera 1 0 1 20 900
11 userb 1 0 1 20 920
11 userc 1 0 1 20 940
; a new project 1 is created, it has 125 slices
; on the system disc and 50 entries in the
; catalog. The project catalog base is 900 to 999

; the project contains three users:
; usera with standard base 900
; userb - - - 920
; userc - - - 940
; The explanation of the options can be found in
; the User>s Manual.

10 2 0 50 10 1000 1020
5 time 5 0
6 online yes
6 corelock 60
5 size 100000
6 preserve yes
11 user d 2 0 1 10 1000
11 user e 2 0 1 10 1010

; a project 2 is created with two users
; who may specify that they
; want temporary files to be
; preserved after a job

-1
; end of input.

6_._3_._6_ _ _ _ _ _E_r_r_o_r_m_e_s_s_a_g_e_s_ _f_r_o_m_ _>_c_a_t_u_p_d_a_t_e_>_ 6.3.6

case out of range in testvalues
can be ignored.

delete not allowed
attempt to delete a userpool record which cannot be deleted

delete wrong interval
a deletion record tries to delete a project or user with
a wrong project/user interval

device unknown
in the device option a name or a number of a device has
been specified which is not present

different slicelength on same kit
a private kit is included with a slicelength which does
not match an elsewhere given slicelength

existing
the record already exists, nothing has been done

illegal abs interval
the interval specified for a user is in conflict with the
project interval

illegal claims
attempt to change claims to an illegal value

illegal devicename
disc and drum are reserved names and must not be used as
a name of a private kit

illegal linetype
the linetype of an input record is greater than 12 or is
less than -1
\f

illegal projno
the projectnumber is out of range (linetype 1 or 10)

illegal parameter
a wrong parameter has been read from an option

illegal update identification
parameter 2 must be 0 or 1

illegal update information
should not appear

max. value not allowed
a maximum value is not allowed for this option

number of params
the number of parameters are out of range in a type 1 record

number out of range
one of the parameters in current record is an illegal number.

option unknown
an option specified in the input cannot be recognized,
most likely because of a spelling error

out of sequence
illegal sequence of input record, most likely because a
project- or user-record (type 1, 10, 2, or 11) was not
accepted.

parameter kind
text where a number was excepted, or vice versa.

privilege illegal
the privilege class must be between 1 and 9

project unknown
the project number stated does not exist.
\f

record unknown
attempt to delete an unknown record

std usercat index too small
the number of segments used as indexsegments is too small.
Catupdate must be changed

temp not allowed on specified device
only >temp disc ...> and >temp drum ...> is allowed

the catupdate program must be corrected and recompiled with a
greater intervaltable size
selfexplanatory

too few parameters on line
a record has too few parameters, the linetype is neither 3 nor
12

too many parameters
an input record has too many parameters

too many priv kits
it is tried to reserve too many private disckits
(option dependent)

updated
the record has been updated

user unknown
attempt to change or delete a non existing user

-1; end of catalog
the input has been transformed to usercatalog records, or if
catupdate cannot find an inputfile this message will appear

6_._4_ _ _ _ _ _ _ _L_i_s_t_i_n_g_ _o_f_ _U_s_e_r_ _C_a_t_a_l_o_g_ _(_>_u_s_e_r_o_u_t_>_)_ 6.4

When file 16 of the BOSS text tape is loaded (by >i tuserout> or
the equivalent), an ALGOL program, >_u_s_e_r_o_u_t_>_, is produced on disc
with user scope. When the program is called, it prints the
current contents of usercat on current output. The program should
be started on the accounting catalog base (see chapter 6).

6_._5_ _ _ _ _ _ _ _B_a_l_a_n_c_i_n_g_ _P_e_r_m_a_n_e_n_t_ _R_e_s_o_u_r_c_e_s_ _A_g_a_i_n_s_t_ _A_c_t_u_a_l_ _U_s_a_g_e_ 6.5

As explained in chapter 3, BOSS during start-up computes the
restclaims for users and projects having claims on the kits
mounted. This computation is repeated for each kit which is later
mounted by means of the >kit>-command, so that BOSS at any time
has full control over the resources: entries and slices on any
kit. If BOSS detects an error in this accounting of resources one
of the bossfaults 12, 17, 21, or 44 will result.

To avoid these errors you should stick to the following rules:

All resources occupied on backing storage should at any time be
accounted for in the user catalog (do not let users make over-
drafts).

If you have processes running in parallel with BOSS, their bases
must not overlap those of a user logged in or a running job. Do
not try to transfer files between such processes and BOSS-jobs or
BOSS-users (and vice versa), i.e. if a file is created under s
while BOSS is running, then do not change its size or scope under
BOSS (and vice versa).

If you have projects or users with overlapping bases, preferably
do not use them simultaneously. If you have to, then make sure to
use >preserve yes>, but notice that >preserve yes> is only a way
to s_u_p_p_r_e_s_s_ a bossfault which ought to occur. And notice that
>preserve yes> does not work for a >login>, so do not log in
under such a user or project.
\f

For reasons of a technical nature you should also observe the
following rules, especially for entries.

The commands finis, logout, save, scope or clear must not cause
the total number of entries available for the job, the user, the
project, or BOSS to pass the number 2047, i.e. either free
entries must always be kept greater than 2047 or it must be kept
lower than 2047.

It is quite simple to fulfil this rule:
Do not give the users many more entries, than they actually use,
and adjust the size of the main catalog once in a while so that
BOSS starts up with a reasonable number of entries, never more
than about 1000.

Changing the size of the main catalog goes like this, when you
have determined the new size wanted, let>s say 197 segments:

autoload the system
* att -' s
clearcat
* att -' s
maincat catalog 197
* att -' s
oldcat

The new size of the catalog must be a few segments greater than
the old size (each new segment holds 15 entries). The old size is
determined by: lookup catalog.

The new size should not be divisible by 2 or 17, and the largest
size allowed is 273.
\f

F_ 7_._ _ _ _ _ _ _ _ _H_O_W_ _T_O_ _H_A_N_D_L_E_ _A_ _B_O_S_S_ _F_A_U_L_T_ _S_I_T_U_A_T_I_O_N_ 7.

If BOSS suddenly breaks down, because of an internal error in
BOSS, a hardware fault, overbooked resources in the user catalog,
or the like, it is important that the testoutput generated by
BOSS, is saved for error documentation and correction.

If the testoutput is generated on disc (the area bosstest) the
fastest way to get restarted is:

att s
remove all boss run
rename bosstest.testcopy
bosstest = set 200 disc
scope user bosstest
bos

Now the testoutput saved in the file >testcopy> may be moved to a
tape or analyzed and printed by the program >last> (see 9.4.1)

If the error is to be reported to RC Computer then please send
the testtape or the printer listing together with the error
report.
\f

8_._ _ _ _ _ _ _ _ _B_O_S_S_ _F_A_U_L_T_ _E_R_R_O_R_ _C_O_D_E_S_ 8.

The alarm message >boss fault> contains an error code giving a
hint to the trouble. Error codes in the interval 1 to 9 originate
from the coroutine file >central>, those in 10 to 19 from
>jobstart>, and so on as specified below.

Central:

1 Program interrupt (break)
2 Access count < 0
3 Hard error, virtual store
4 No room in core for pages (i116)
5 Start-up alarm (always preceded by an explanation, see 2.2)
6 No message buffers
7 Access counter problems
8 - - -
9

Jobstart:

10 Trouble creating swop area
11 Trouble modify internal
12 Trouble term bs, all claims transferred to job
13 - - - , alarm create job
14 Trouble remove entry, load alarms
15 Trouble set cat base, catproc
16 Trouble reserve process, catproc
17 Common trouble, catproc, not done
18 Trouble, catproc, selective clear
19 Trouble, catproc, claim exceeded
\f

Term1 and Term2:

20 BOSS closed normally by operator
21 Trouble after term bs, scope etc.
22 Trouble after prep access, save
23 Hard error termout, next job
24 Hard error termout, block size
25 Trouble term bs-adjust, logout
26 Trouble term bs-adjust, after transmit error
27 Trouble remove entry, at create output
28 Unknown error code, newjob
29

Jobstart:

30 Trouble remove primout
31 Trouble remove jobfile, kill
32 Trouble include user
33
34 Trouble request alarm
35 Trouble in catproc
36
37
38
39

Job:

40 Hard error primout, psjob i/o
41 FP not available, break and dump
42 Hard error catalog, clean catalog
43 Hard error primout, finis
44 Trouble after term bs, finis
45 Trouble after term bs-adjust, finis
46 Trouble after remove or adjust primout
47 Trouble after remove area process, finis
48 Illegal internal operation
49 Trouble adjust primout, finis
\f

Mount:

50 Trouble include/exclude user
51 Illegal state
52 Trouble include user, check action
53 Trouble initialize process, name
54 Request trouble, psjob mount
55 Request trouble, remoter
56 Illegal station table change
57 - - - -
58 Device number trouble
59 Illegal station table change

Read:

60 Trouble reserving reader
61
62
63
64
65 Reader not device 0
66 Card reader error
67
68
69

Print:

70 Hard error in reading usercat
71
72 Primout does not exist or area does not exist
73 Date and time too long
74 Job controlled printing inconsistent
75
76
77
78
79
\f

Procs:

80 Hard error, accountf1
81 Hard error usercat, output bsadjust
82 - - - , input bsadjust
83 - - - , init from usercat
84 Hard error catalog, unknown sender
85 - - - , - -
86 - - - , - -
87 Too many private kits
88 Trouble creating accountf1
89 Action from table outside limits, init from usercat

Banker:

90 Trouble priority queue, lock in core fit
91 Hard error swopout
92 Convert feature, not implemented
93 Trouble priority queue, release
94 Trouble res queue, simulate release
95 Too many free stations
96
97 Reserve reader, not found
98 Release reader, not found
99 Assign resources, reader not found

Term1 and term2:

100 Login attention during run
101 Login attention during logout
102 Trouble general print, integer size
103 - - - , buffer limit
104 - bs-adjust, snapshot
105 Page troubles, kitchange
106 Hard error usercat, kitchange
107
108
109
\f

Mount:

110 Station table inconsistence
111 - - -
112 No station in searched state
113
114
115
116
117
118
119

Banker:

120
121 Job in core semaphore out of range
122
123
124
125
126
127
128
129
\f

F_ 9_._ _ _ _ _ _ _ _ _T_E_S_T_O_U_T_P_U_T_ 9.

The testoutput from BOSS consists of a sequence of variable-
length, binary records stored in blocks of 512 halfwords. Output
on magnetic tape is terminated by a tape mark (generated at close
down). When output on backing store meets the end of the area,
output continues in the first segment after the last type-14
record (see 9.1.14).

The BOSS text tape contains an external ALGOL procedure >bossout>
and a program >last> which are used for analysis of the
testoutput and output. These are described in section 9.4.

9_._1_ _ _ _ _ _ _ _R_e_c_o_r_d_ _F_o_r_m_a_t_ 9.1

Each record consists of a head and a variable length tail. The
head is always 3 words, except for type 0, where the length is
only one word.

head, word1: tail length shift 6 + type
head, word2: time
head, word3: >third> meaning various things.

The tail length is given in halfwords. The time is given in units
of 0.01 second from start-up of BOSS.

T_y_p_e_ _0_,_ _n_e_x_t_ _b_l_o_c_k_

Shows that the remaining part of the block is unused. Tail length
= 0. Notice that the head of this record is only one word.

9_._1_._1_ _ _ _ _ _T_y_p_e_ _1_,_ _s_e_n_d_ 9.1.1

Produced when the following Central Logic entries are called:
send and wait, send and wait fast, send and wait slow, stop and
wait, wait answer.
\f

Third = name table addr of receiver, tail length = 8.
tail: first 4 words of message. Tail makes no sense for the
entries >stop and wait> and >wait answer>.

9_._1_._2_ _ _ _ _ _T_y_p_e_ _2_,_ _l_o_c_k_ 9.1.2

Produced when CL entries lock or lock chained are called.

Third = semaphore addr, tail length = 2
tail: semaphore value (before lock or lock chained).

9_._1_._3_ _ _ _ _ _T_y_p_e_ _3_,_ _o_p_c_h_ 9.1.3

Produced when open chained is called.

Third = semaphore addr, tail length = 8
tail: semaphore value (before open chained), first 3 words of
operation (omitting the chain word).

9_._1_._4_ _ _ _ _ _T_y_p_e_ _4_,_ _o_p_e_n_ 9.1.4

Produced when open is called.

Third = semaphore addr, tail length = 2
tail: semaphore value (before open).

9_._1_._5_ _ _ _ _ _T_y_p_e_ _5_,_ _e_x_i_t_ 9.1.5

Produced when Central Logic exits to a coroutine after all wait
operations, after lock, lock chained, open chained, get pages,
page jump, clear core. But not after open.

Third = coroutine ident (see 9.3), tail length = 18.
tail: core (x1 to x1+4), 5 absolute addresses of the pages,
codepage ident (see 9.2) shift 12 + exit address relative
to page 0.
\f

Core (x1 to x1+4) contain the first 3 words of the answer after a
wait operation, the first 3 words of the operation (including the
chain word) after lock chained.

It is possible to generate a BOSS version where the 5 absolute
addresses are replaced by virtual addresses (option e8).

9_._1_._6_ _ _ _ _ _T_y_p_e_ _6_,_ _m_e_s_s_ 9.1.6

Produced when a message is received from a job or a terminal. The
record is produced when the coroutine is ready to receive the
message, and this may be much later than the first detection of
the message.

Third = coroutine ident, tail length = 8.
tail: sender process description address, first 3 words of
message.

9_._1_._7_ _ _ _ _ _T_y_p_e_ _7_,_ _a_n_s_w_ 9.1.7

The record is produced the first time CL detects the answer.

Third = coroutine ident, tail length = 2.
tail: result of wait answer.

9_._1_._8_ _ _ _ _ _T_y_p_e_ _8_,_ _j_d_-_1_ 9.1.8

Generated whenever a jd-1 is executed.

Third = coroutine ident, tail length = 12.
tail: w0, w1, w2, w3, exception, instruction counter

On RC8000 >exception> is replaced with >status> (see RC8000
Reference Manual, subsection 2.2.1).

9_._1_._9_ _ _ _ _ _T_y_p_e_ _9_,_ _s_t_o_p_ 9.1.9

Generated at close down, which always corresponds to an internal
interrupt (intended or unintended).

Third = coroutine ident, tail length = 24.
tail contains the dumped registers:
RC8000 RC4000
tail (1): w0 -
2 : w1 -
3 : w2 -
4 : w3 -
5 : status exception
6 : ic -
7 : cause -
8 : addr 3440650
9 : 3440648 -
10 : -(bossfault code) -
11 : page 0 address -
12 : ident, rel -

>status> and >exception> are explained in >RC8000 Reference
Manual>, subsect. 2.2.1, where also >cause> is explained
(subsect. 7.1).

Bossfault code: see ch.8. Page 0 address and ident, rel are the
same as in the last >exit> (cf. 9.1.5 and 9.2).
\f

F_ T_y_p_e_s_ _g_r_e_a_t_e_r_ _t_h_a_n_ _9_,_ _p_r_i_v_a_t_e_ _o_u_t_p_u_t_ may be produced by any
coroutine. Present types are shown below.

Third = coroutine ident, tail length = any value.
tail: anything.

9_._1_._1_0_ _ _ _ _T_y_p_e_ _1_0_ 9.1.10

Tail contains banker>s description of a pseudo job.

Four consecutive records are produced to describe a psjob.

F_i_r_s_t_ _r_e_c_o_r_d_,_ _t_a_i_l_ _l_e_n_g_t_h_ _=_ _2_0_
tail(1): chain, chain ;priority or idle, resource or
;deadly. jobs may be in no
;chain.

;REST CLAIMS:
tail(2): all, stations ;all: pattern showing if
;static resources should be
;included: 4: converts
; 2: account
; 1: other
tail(3): entries, slices ;temp disc
tail(4): std, remote ;readers

;STATIC RESOURCES:
tail(5): converts, accounts ;
tail(6): buf, area ;
tail(7): internal, suspends ;
tail(8): entries, slices ;temp drum
tail(9): deviceword 1 ;
tail (10): deviceword 2 ;

S_e_c_o_n_d_ _r_e_c_o_r_d_,_ _t_a_i_l_ _l_e_n_g_t_h_ _=_ _1_2_
;RESERVED RESOURCES:
tail(1): all, stations ;all: see first record
tail(2): entries, slices ;temp disc
tail(3): std, remote ;readers
\f

;WANTED RESOURCES:
tail(4): all, stations ;all: see first record
tail(5): entries, slices ;temp disc
tail(6): std, remote ;readers

T_h_i_r_d_ _r_e_c_o_r_d_,_ _t_a_i_l_ _l_e_n_g_t_h_ _=_ _1_6_ _
tail(1): first segm, top segm ;coreplace
tail(2): 255- pr, priority ;protection, priority factor
tail(3): gross run left ;units of 0.8192 secs.
tail(4): net run left ;- - - -
tail(5): arrival time ;- - - -
tail(6): max. waiting ;- - - -
tail(7): jobname(1) ;3 chars
tail(8): jobname(2) ;3 chars

F_o_u_r_t_h_ _r_e_c_o_r_d_,_ _t_a_i_l_ _l_e_n_g_t_h_ _=_ _1_4_
tail(1): jobname(3) ;3 chars
tail(2): jobname(4) ;3 chars
tail(3): virt. address ;answer or dump name
tail(4): state, jobclass<1+corelock;state:
;0: skip (not in one of below
; states
;1: resources wanted
;2: core wanted (after start
; job operation)
;3: waiting (only account and
; convert)
;4: killed in skip state
;5: in no queue (onlinejob
; between runs)
tail(5): time to time out ;units of 0.8192 secs
tail(6): time to wait swopped out ;- - - -
tail(7): expected finishing time ;- - - -

9_._1_._1_1_ _ _ _ _T_y_p_e_ _1_1_ 9.1.11

Five consecutive records produced by the banker.

F_i_r_s_t_ _r_e_c_o_r_d_,_ _t_a_i_l_ _l_e_n_g_t_h_ _=_ _4_
tail(1): psjob rel. for a-job (0 means no job in that place
tail(2): - - - b-job (0 - - - - - -

N_e_x_t_ _f_o_u_r_ _r_e_c_o_r_d_s_,_ _a_l_l_ _w_i_t_h_ _t_a_i_l_ _l_e_n_g_t_h_ _=_ _3_0_

Currently free resources. All values given are one too high. One
record is produced for each of the four job classes (0-3):

;DYNAMIC RESOURCES:
tail(1) :free stations
tail(2) :free temp disc (maincat) entries
tail(3) :free temp disc slices
tail(4) :free std readers
tail(5) :free remote readers

;STATIC RESOURCES:
tail(6) :free convert operations
tail(7) :free account operations
tail(8) :free mess bufs
tail(9) :free area procs
tail(10) :free intervals
tail(11) :free suspends
tail(12) :free temp drum entries (dummy)
tail(13) :free temp drum slices
tail(14) :free devices 1
tail(15) :free devices 2

9_._1_._1_2_ _ _ _ _T_y_p_e_ _1_2_ 9.1.12

This type is used for various purposes, see below.

9_._1_._1_2_._1_ _ _J_o_b_s_t_a_r_t_ 9.1.12.1

output of job description page, 23 records, tail length = 20
output of job file page, 23 records, tail length = 20

9_._1_._1_2_._2_ _ _J_o_b_ 9.1.12.2

On psjob finis page (page 46a) the part of job description page
containing information about runtime left (d115+0 to d115+10) is
output.

9_._1_._1_2_._3_ _ _P_r_o_c_s_ _T_e_s_t_o_u_t_p_u_t_ 9.1.12.3

2 or 3 records before and 1 or 3 records after all hostmessages.
The format of the records is as shown below.

F_i_r_s_t_ _r_e_c_o_r_d_,_ _t_a_i_l_ _l_e_n_g_t_h_ _=_ _2_2_ _h_w_,_ _c_a_l_l_ _p_a_r_a_m_e_t_e_r_s_:
tail(1): absref message area
tail(2): dev.name(1)
tail(3): dev.name(2)
tail(4): dev.name(3)
tail(5): dev.name(4)
tail(6): host no. ;logical deviceno. of jobhost
tail(7): host id ;devicehost
tail(8): mode<12+kind
tail(9): timeout ;0: don>t wait
;<128: wait up to <value' min
;'=128: wait till you get it
tail(10): catalog base (lower)
tail(11): catalog base (upper)
\f

S_e_c_o_n_d_ _r_e_c_o_r_d_,_ _t_a_i_l_ _l_e_n_g_t_h_ _=_ _1_6_ _h_w_,_ _m_e_s_s_a_g_e_:
tail(1): operation <12+function<1+addr.mode ;operation
tail(1) = 4101: lookup process
tail(1) = 4102: lookup device
tail(1) = 4108: linkup remote
tail(2): first addr. of data
tail(3): last addr of data
tail(4): linkno <12 + hostno. ;logical dev.no. in jobhost
tail(5): hostid ;devicehost
tail(6): dh. homereg<12+dh.netid.
tail(7): (irrelevant)
tail(8): (irrelevant)

T_h_i_r_d_ _r_e_c_o_r_d_,_ _t_a_i_l_ _l_e_n_g_t_h_ _=_ _2_2_ _h_w_,_ _d_a_t_a_:
(third record is not always present)
tail(1) : mode <12 + kind
tail(2) : timeout <12 + buffers
tail(3) : buffersize ;halfwords
tail(4) : devicename(1)
tail(5) : devicename(2)
tail(6) : devicename(3)
tail(7) : devicename(4)
tail(8) : (irrelevant)
tail(9) : (irrelevant)
tail(10): (irrelevant)
tail(11): (irrelevant)

F_o_u_r_t_h_ _r_e_c_o_r_d_,_ _1_6_ _b_y_t_e_s_,_ _a_n_s_w_e_r_: (only produced if monitor result = 1)
tail(1): device status <16 + link descriptor <12 + function result
;device status: bit 0: device unknown
- 1: device closed
- 2:
- 3:
- 4:
- 5: device driver not loaded
- 6: device reserved by another process
- 7: reservation rejected from AP
(only GAC interface)
\f

;link descriptor:
(value) 0: no link (subprocess) present
1: remote link (subprocess) present
2: local link (subprocess) present

;function result:
(value) -1: sender stopped
0: function executed
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 present (see link
descriptor)
8: device host unknown

tail(2): number of bytes in >data>
tail(3): number of chars in >data>
tail(4): dh. linkno <12 + hostno.
tail(5): dh. hostid
tail(6): dh. homereg <12 + dh. net-id
tail(7): not used
tail(8): not used

F_i_f_t_h_ _r_e_c_o_r_d_,_ _2_2_ _b_y_t_e_s_,_ _d_a_t_a_: (only produced if monitor result = 1
and local link is not present)
tail(1) : kind
tail(2) : max. buffers
tail(3) : max. buffersize chars
tail(4) : name(1)
tail(5) : name(2)
tail(6) : name(3)
tail(7) : name(4)
tail(8) : jh. linkno. ;tail(8) - tail(11) are
tail(9) : jh. hostid ; only relevant for
tail(10): jh. homereg <12 + jh.netid ;>linkup remote>
tail(11): process description address (subprocess)
\f

s_i_x_t_h_ _r_e_c_o_r_d_,_ _t_a_i_l_ _l_e_n_g_t_h_ _=_ _4_ _o_r_ _1_0_ _h_w_,_ _r_e_t_u_r_n_ _p_a_r_a_m_e_t_e_r_s_:
tail(1) : name table address
tail(2) : logical device no.
tail(3) : device kind
tail(4) : mode
tail(5) : max. buffersize halfwords

If >function> (cf. second record) was >lookup process> tail
length will be 4 and tail(1) = tail(2) = 0.

Otherwise the length will depend on the result. If everything was
ok (no link was present before the call, and the link was created
as requested), the sixth record will be as shown above.

If something went wrong, tail length will be 4, tail(2) = 0 and
tail(1) will be 0 or >process description address> (if the device
was linked before).

9_._1_._1_3_ _ _ _ _T_y_p_e_ _1_3_ 9.1.13

Produced during start-up when a coroutine file is loaded.

Tail contains:
name of coroutine file (4 words), first of coroutine table, first
of semaphore table, first of sender table, checksum, double sum,
version date, version number.

The record corresponding to >bos> contains BOSS start-up time
instead of first of coroutine table, first of semaphore table and
>load address for coroutine files> instead of >first of sender
table>. The last two words contain first and last address of the
BOSS process.

9_._1_._1_4_ _ _ _ _T_y_p_e_ _1_4_ 9.1.14

Produced during start-up after the first loader pass.

Third=2*external number of first external in the record.
Tail length=100.
Tail contains the corresponding part of the external table.

9_._1_._1_5_ _ _ _ _T_y_p_e_ _1_5_ 9.1.15

Produced when command or jobstart has read a line. Tail contains
the line.

9_._1_._1_6_ _ _ _ _T_y_p_e_ _1_6_ 9.1.16

Testoutput from bs-adjust. One record for each bs-device.

Tail contains:
entry claim (key 0), slice claim (key 0)
...
entry claim (key 3), slice claim (key 3).

9_._1_._1_7_ _ _ _ _T_y_p_e_ _1_7_ 9.1.17

Produced when a catalog entry is removed (i.e. after
jobtermination and after logout) and when a disckit is mounted.

Tail contains the catalog entry.

9_._1_._1_8_ _ _ _ _T_y_p_e_ _1_8_ 9.1.18

Produced each time the mounter is activated.

Tail contains an entry of the station table.
(A closer description of the station table can be found on page 3
in the >mounter>).

9_._1_._1_9_ _ _ _ _T_y_p_e_ _1_9_ 9.1.19

Produced each time the mounter is activated.

Tail contains an entry of the tape table.
(A closer description of the tape table can be found on page 3 in
the >mounter>).

9_._1_._2_0_ _ _ _ _T_y_p_e_ _2_0_ 9.1.20

Generated when Central Logic entries prepare _access or terminate _
access are called.

Tail contains:
nametable address of area process,
1 or -1 (depending on prepare _access or terminate _access), access
count, interval of entry, name of entry.

9_._1_._2_1_ _ _ _ _T_y_p_e_ _2_1_ 9.1.21

Area process description (see the Monitor 3 manual).

9_._1_._2_2_ _ _ _ _T_y_p_e_ _2_2_ 9.1.22

Produced immediately before the stoprecord (9.1.9) at close down.

Tail contains i205 (options page 6, bottom) hw of the code ending
with ic-2 (the instruction causing the interrupt). i205 is
adjusted so that 20<= i205<=120.

9_._2_ _ _ _ _ _ _ _C_o_d_e_p_a_g_e_ _I_d_e_n_t_i_f_i_c_a_t_i_o_n_s_

The codepage identifications used in testoutput records type 5
(see 9.1.5) and type 9 (see 9.1.9) are shown below.
\f

c_e_n_t_r_a_l_
9 : pager

t_j_o_b_s_t_a_r_t_
11: codepage 1 (job birth, online convert)
12: codepage 2 (load commands, set claim)
13: codepage 3 (command reading)
14: codepage 4 (create job, request alarm)
15: codepage 5 (load, rb-comm)

t_t_e_r_m_ _1_
20: command input
21: commandio bulk file
22: command print
23: snapshot, autoline

t_j_o_b_
40: psjob i/o
41: psjob aux
42: psjob break
43: clean catalog
44: psjob finis

t_m_o_u_n_t_
50: psmount
52: remoter
54: rewinder
56: watchdog
58: commandio, name, label

t_r_e_a_d_
60: tape reader
61: card reader
62: start card
63: pstape
64: pscard
65: psload
\f

t_p_r_i_n_t_e_r_
70: paper description
71: central page
72: triangle page
73: main loop

t_p_r_o_c_s_
80: account
81: bsadjust
82: init from usercat
83: unknown sender
84: various procedures for remote devices

t_b_a_n_k_e_r_
90: main banker
91: core allocation
92: resource allocation

t_t_e_r_m_ _2_
100: kill
101: go, run, job, newjob
102: rename, clear, scope
103: login, get, save
104: transmit
105: display
106: kit changer
107: term out
108: request display

9_._3_ _ _ _ _ _ _ _C_o_r_o_u_t_i_n_e_ _I_d_e_n_t_i_f_i_c_a_t_i_o_n_s_ 9.3

The coroutines are identified as follows in the testoutput. We
also show the coroutine file which generates the coroutine.
\f

0 output during start-up (central)
1 timer (banker)
2 banker (banker)
3 unknown sender (procs)
7 watchdog (mount)
8 request display (term2)
9 pager (central)
10 operator display (term2)
20* kit changers (term2)

40* printers (printer)
60* rewinders (mount)
80* remoters (mount)
100* commandios (term1)
200* psjobs (jobstart)
300* termouts (term2)
400* card readers (reader)
450* readers (reader)

* as many as there are incarnations, numbered consecutively.

9_._4_ _ _ _ _ _ _ _S_e_l_e_c_t_e_d_ _T_e_s_t_o_u_t_p_u_t_ 9.4

Testoutput is always produced during the initialization.
Testoutput is not produced during the run if BOSS has been
translated with e9=0. e9 is an option, which is defined in
>options> on page 5, together with other options which may be
used to select testoutput independently for each coroutine type.

The operator may change the selection of testoutput dynamically
by means of the >test> command (see Operator>s Manual).

The value of e9 is regarded by the system as 3 bits. The bit with
value 1 means output from Central Logic and jd-1 (type 1 to 9).
the bit with value 2 selects type 10 and 15 output, the bit value
4 selects type 11 output. Type 13 and 14 output is always
produced.
\f

When e9<'0 but no testoutput medium is available, the records are
still produced in the testoutput buffer.

9_._5_ _ _ _ _ _ _ _A_n_a_l_y_s_i_s_ _o_f_ _T_e_s_t_o_u_t_p_u_t_ 9.5

When file 17 of the BOSS text tape is loaded (by >i testout> or
the equivalent), an external ALGOL procedure, b_o_s_s_o_u_t_, and an
ALGOL program, l_a_s_t_, are produced. They are generated on disc
with user scope.

9_._5_._1_ _ _ _ _ _L_a_s_t_ 9.5.1

The program, last, prints selected parts of a testoutput file in
readable form on current output. The call is:
M_m_m_ 1 1 1
last <doc'.<file' .<blocks' <s'<first'.<last' <s'<anything'
P_p_p_ 0 0 0
<doc' is the name of the magtape or the
backing store file
holding the testoutput.
<file' is the file numer or >bs> meaning
backing store file.
<blocks' is the number of testoutput blocks to
be printed counted from the end of
the testoutput, as the latest blocks
are usually most interesting after a
break down. If <blocks' is omitted,
all blocks are printed.
<first '.<last' selects an interval of coroutine
identifications for printing.
<anything' Anything obeying the syntax for
FP-parameters. The rest of the line
is just copied to the testoutput and
can be used for identification
purposes

The identification records (type 13) are always printed in order
to verify the BOSS version used.
\f

E_x_a_m_p_l_e_: The normal call will be: last bosstest.bs.
The following call prints only testoutput from commandios in the
last 10 blocks.

last bosstest.bs.10 100.150 maintenance manual testoutput

The output may look like the following illustration: \f

F_ 9_._5_._2_ _ _ _ _ _B_o_s_s_o_u_t_ 9.5.2

This procedure assumes that the program has been called in this
way (see 9.5.1):

M_m_m_ 1
<program' <doc'.<file' .<blocks' <possible further parameters'
P_p_p_ 0

The procedure is called like this:

bossout(type, time, coruno, third, record, move, print)

It scans the testoutput in the file specified and in the last
<blocks' blocks. If <blocks' is omitted, the whole file is
scanned.

Each time it gets a record, it assigns the type, time, coroutine
identification, and >third> to the first four parameters
(integers), and assigns the length of the record (in bytes) to
record(0). Then it interrogates the parameter >move> (boolean,
Jensen>s device) to determine if the record should be moved into
the integer array >record> from index 1 and on (moves when true).
Finally the last parameter, >print> (boolean, Jensen device), is
interrogated. When the parameter is true, the record is printed.
(The stop record (type 9) and the identification records (type
13) are always printed).

E_x_a_m_p_l_e_: In order to print all events from time 300 (seconds) to
400 after start-up of BOSS, proceed as follows:

pr = algol
begin integer k,t,c,th; integer array record(0:0);
bossout (k,t,c,th,record,false,
300 00 <= t and t <=400 00);
end
pr bosstest1.bs
\f

E_x_a_m_p_l_e_: If you want to examine the records yourself (e.g. making
statistics on free resources), then make use of the
>move> parameter:

pr = algol
begin integer k,t,c,th;
integer array record (0:256);
boolean procedure statistic;
begin integer field i;
if k=11 and record (0) ' 4 then
begin
for i:=2 step 2 until record (0) do
... statistics ... on record.i
end;
if k=9 then ... terminate statistics ...
statistic:=false;
end;
bossout (k,t,c,th,record,true,statistic);
end;
pr bosstape.3

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

1. GENERAL ............................................... 1

2. LOGIC SPECIFICATION ................................... 2
2.1 Data Formats ..................................... 2
2.2 Memory Addressing ................................ 3
2.3 I/O Addressing ................................... 5
2.4 Interface Control ................................ 5
2.5 Interrupt ........................................ 5
2.5.1 RC3502 Interrupts ......................... 6
2.5.2 MB Interrupts ............................. 7
2.5.3 Interrupt Masks ........................... 7
2.5.4 Bus Vectored Interrupts ................... 7
2.6 Initialization ................................... 8
2.7 Read Switch-Setting .............................. 8
2.8 Bus Reservation .................................. 8

ii
\f

F_ 1_._ _ _ _ _ _ _ _ _G_E_N_E_R_A_L_ 1.

The RC3502 to Multibus interface provides a means for RC3502 as a
master to handle all units that may be installed in an attached
Multibus crate. This may include memory device controllers, other
interfaces, and other masters.

One RC3502 may have only one Multibus (MB hereafter called)
attached, and it regards the MB-address space as a part of its
own. Hence accesses to the MB is made as normal memory accesses.

Yet the accesstime to Multibus memory (or units) will occupy
approximately twice the time for access to privat memory. This
consideration does not apply to the dual port memory provided
with the interface.

Physically the interface as seen on fig. 1 consists of two
printed circuitboards interconnected by means of a flatcable.

Figure 1: Outlines of the interface.

F_ 2_._ _ _ _ _ _ _ _ _L_O_G_I_C_ _S_P_E_C_I_F_I_C_A_T_I_O_N_ 2.

The interface includes the MB as a part of the RC3502 memory
address space.

Contrarily it does not enable access from the MB to the memory
situated in the RC3502 crate.

2_._1_ _ _ _ _ _ _ _D_a_t_a_ _F_o_r_m_a_t_s_ 2.1

Byte- or word-addressing from the RC3502 will correspondingly
result in byte- or word-addressing on the MB.

Caution should be taken that not all units or memory areas
installed in the MB are wordwide; this means that word-addressing
of such units or areas will result in single-byte-accesses
without any indication of this fault.

Also it should be noted that 16 bit numbers in the MB in contrast
to RC3502 are organized as A + 256 * B, where the address of B is
the address of A plus one. In RC3502 the organization is 256 * A
+ B (see fig. 2).

RC3502 p: A p+1: B
Bit: 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15

Multibus q+1: B q: A
Bit: F E D C B A 9 8 4 6 5 4 3 2 1 0

order of increasing significance

p and q are even addresses

Figure 2: Word formats for RC3502 and Multibus.
\f

The bit to bit correspondance between the busses as established
by the interface is shown in fig. 3.

RC3502 p: A p+1: B
Bit 0 - 7 8 - 15

Multibus q: A q+1: B
Bit 7 - 0 F 8

Figure 3: Transfer format.

Single bytes are transferred on buslines 8-15 on RC3502 and on
7-0 on MB.

2_._2_ _ _ _ _ _ _ _M_e_m_o_r_y_ _A_d_d_r_e_s_s_i_n_g_ 2.2

Neither the RC3502 CPU nor its DMA-controllers can see any
difference between memory directly inserted in the RC3502-crate
and memory locations on the MB, so the controlling software has
to be aware of the actual configuration in order to handle the
different areas correctly.

As illustrated in fig. 3 the total addressspace (1M bytes) is
divided into several areas with different characteristics.

The first area ranging from loc. 00000 to P0000-1 is privat
memory to RC3502. This mamory is physically located in the RC3502
crate, and is not accessible from the MB. The hexadecimal digit P
is definable by means of a selector located on the A-board.

The RC3502 CPU has an extended address range of 2M bytes the
upper half of which is intended for ROM-addressing. The interface
does not respond to addressing in this area, so all addresses in
this paper imply a leading zero.

The interface will respond to RC3502 initiated addressing from
loc. P0000 to FFFFF (Hex).
\f

F_ 8 bits

00000:

Privat
area

P0000-1:
P0000:

MM000: Multibus
32K bytes DUAL memory
MMFFF: Access area

F0000:

Multibus
I/O area

FFFF0:
FFFFF: Special area (privat)

Special area:
FFFF0: ITRIE
1 ITROE
2 INTRO
3 INTA
4 INIT
5 RESERVE BUS
6 DERES. BUS
7
8
9
A
B
C
D
E MM Read switch-setting
FFFFF P

Figure 4: Layout of address space. \f

F_ The B-board acts as a master on the MB, and addresses the MB
controlled by the A-board.

The B-board also contains a dual port memory of 32K bytes
accessible directly from both the A-board (not occupying the MB)
and the MB. The only difference between this memory (which is 16
bit wide) and other memory installed on the MB, is that access
from RC3502 to this particular area is faster than access to
other memory on the MB. As seen from fig. 4 the address of this
area is configurable by means of a selector on the B-board. The
number MM places the first dual port memory-byte on a 32K
boundary.

2_._3_ _ _ _ _ _ _ _I_/_O_ _A_d_d_r_e_s_s_i_n_g_ 2.3

The addresses F000 to FFFFF (Hex) are used by RC3502 for I/O
addressing on MB. The I/O address space on MB uses only 16
address bits, and is accessed by "IOREAD" and "IOWRITE" pulses
instead of "MEMREAD" and "MEMWRITE".

2_._4_ _ _ _ _ _ _ _I_n_t_e_r_f_a_c_e_ _C_o_n_t_r_o_l_ 2.4

The addresses from FFFF0 to FFFFF are used for interface control
as shown in fig. 3.

2_._5_ _ _ _ _ _ _ _I_n_t_e_r_r_u_p_t_ 2.5

In this section two classes of interrupt are discussed:

a: Interrupts on the RC3502 bus, directed from the IF
towards the CPU.

b: Interrupts occurring on the MB-INTR-lines.

Class b interrupts imply class a interrupts, if enabling is done
explicitly by the RC3502.
\f

Class b interrupts may be set by the RC3502 to synchronize other
masters on the MB. The clearing of such interrupts by other
masters on the MB may result in a corresponding class a
interrupt, if allowed by a special mask set by the RC3502 CPU.

2_._5_._1_ _ _ _ _ _R_C_3_5_0_2_ _I_n_t_e_r_r_u_p_t_s_ 2.5.1

The eight INTR lines on the MB are connected to eight of the
RC3502 interruptlevels in the following way:

MB INTR-line RC3502 IR level
Highest priority: INTR (0) - IRL (irb+7)
INTR (1) - IRL (irb+6)
INTR (2) - IRL (irb+5)
INTR (3) - IRL (irb+4)
INTR (4) - IRL (irb+3)
INTR (5) - IRL (irb+2)
INTR (6) - IRL (irb+1)
Lowest priority: INTR (7) - IRL (irb+0)
Generally: INTR (irno)- IRL (irb+7-irno)
where irb is an integer multiple of 8, set on a set of switches
on the A-boards and irno is in the range 0-7.

The class a interrupts are controlled by two masks InTerRupt In
Enable and InTerRupt Out Enable. If the ITRIE (irno)-bit is set
then INTR (irno) will set IRL (irb+7-irno).

If the ITROE (irno)-bit is set, IRL (irb+7-irno) is set when
INTRO (irno) - (see next subsection) is cleared. If the IRIM-bit
is set too the IRL is set already when the INTRO is set.

If both ITROE (irno) and ITRIE (irno) are false, IRL (irb+7-irno)
cannot be set as function of any MB-actions.

All ITRIE- and ITROE-bits are initially false.

The class a interrupts can be set and cleared by the RC3502 CPU
using SET interrupt and CLEAR interrupt on the corresponding
device no. (irb+7-irno).
\f

2_._5_._2_ _ _ _ _ _M_B_ _I_n_t_e_r_r_u_p_t_s_ 2.5.2

The class b interrupts set the RC3502 interrupt levels as
described above.

RC3502 is able to set the class b interrupt in order to
communicate with other masters on the Multibus.

The interrupt signal once set by RC3502 is not cleared until so
done by another master or an INIT signal. If the ITROE bit is on,
the clear action will set the corresponding class a interrupt.

The eight signals INTRO (irno) are cleared by other masters by an
I/O-write (devno+irno), where devno is a switch-selectable number
equalling an integer multiple of 8.

The class b interrupt INTRO (irno) is controlled by the RC3502
CPU by writing the value irno in the byte "INTRO" (address
FFFF2).

2_._5_._3_ _ _ _ _ _I_n_t_e_r_r_u_p_t_ _M_a_s_k_s_ 2.5.3

The interrupt masks ITRIE and ITROE are controlled from the
RC3502 CPU by writing into the corresponding bytes (addresses
FFFF0 and FFFF1).

The bits are set and cleared individually.

The value to write into the control byte is 128 * new bit value +
irno.

2_._5_._4_ _ _ _ _ _B_u_s_ _V_e_c_t_o_r_e_d_ _I_n_t_e_r_r_u_p_t_s_ 2.5.4

The interrupts on the MB may be of Bus Vectored or Non Bus
vectored kind. The mixture of BVI and NBI is a matter of
configuration, different devices supply different kinds of
interrupt.
\f

As contrast to the NBI the BVI requires additional information
(interrupt vector) transferred via the bus lines, as response on
INTA from the master. The NBIs are supported directly. The INTAs
necessary for supporting the BVIs are generated by reading the
INTA byte (address FFFF3), and the MB contents as result of the
INTA are transferred to the RC3502 CPU during this read.

2_._6_ _ _ _ _ _ _ _I_n_i_t_i_a_l_i_z_a_t_i_o_n_ 2.6

The MB has an INIT signal, which - when activated - resets the
entire system to a known initial state.

The RC3502 has a RESET signal with almost the same function.

Through the interface, the INIT signal withdraws the RESET
signal, and not reversely.

The RC3502 may generate an INIT on the MB by writing in the INIT
byte (FFFF4). This blocks the depency between INIT and RESET,
until INIT is inactive again, preventing the CPU from resetting
itself.

The generated INIT pulse has a duration of at most 10 milli-
seconds.

2_._7_ _ _ _ _ _ _ _R_e_a_d_ _S_w_i_t_c_h_-_S_e_t_t_i_n_g_ 2.7

The setting of the switches P and MM as described in section 2.2
are readable on the addresses FFFFE and FFFFF respectively.

2_._8_ _ _ _ _ _ _ _B_u_s_ _R_e_s_e_r_v_a_t_i_o_n_ 2.8

The RC3502 CPU may need to reserve the MB (lock other masters
out), for execution of indivisible operations such as test and
set.
\f

This is done by writing location FFFF5. Dereservation is done by
writing location FFFF5.

Reservation periods should be kept as short as possible.

F_
\f

«eof»

DataMuseum.dk

RegneCentralen RC850

⟦01f15b30f⟧ TextFile

Derivation

TextFile