@V7 54 2 -5
@L7 PRES0637
160
@L5 HIUK1047
0
85  85  85  85  85  85  85  85
85  85  85  85  85  85  85  85
85  85  85  85  85  85  85  85
85  85  85  85  85  85  85  85
85  58  78  85  85  127 90  60
85  85  90  85  85  85  85  85
85  85  85  85  85  85  85  85
85  85  85  85  85  85  85  85
100 91  99  107 109 93  90  109
111 50  82  93  78  127 112 109
90  109 100 89  90  115 95  127
86  83  87  55  72  55  80  91
60  84  87  82  87  84  50  87
83  46  46  74  46  125 83  85
87  87  61  76  45  83  65  100
63  65  65  55  50  55  85  127
@D10
@7
@MMUSS
@
@
@MUSER MANUAL
@0
@D28
UNIVERSITY OF MANCHESTER                             ISSUE 11@
@V9 -1
@P
@V9 0
@YCHAPTER 1 - MUSS USER MANUAL
@G@RCHAPTER 1 - INTRODUCTION TO THE SYSTEM@G
@V10 1 9 1
@T% 10
@BThe MU6 network has a general-purpose operating system (known as MUSS) which
has evolved from the design of the MU5 operating system. Its
development has been characterised by a strong emphasis on
producing an efficient and compact system,
suitable for both a single computer and network operation.
At the same time, ease
of modification and adaptability has been an important objective, and it is expe
cted
that individual users and installations will modify and extend the
system to suit their own needs.
@BThe central part of MUSS which would be common to all installations
is known as the MUSS Basic System.  It is designed primarily for use in
an interactive computing environment although it also allows for the
specification and input of complete jobs as in a batch system.
@BThe rest of this chapter is a short description of the
organisation of the MUSS system, in order to introduce
background information and terminology.
@S21.1 PROCESSES
@BFrom the user point of view
the software in the machine can be regarded as consisting of a number of
concurrent activities, or processes, for example@
@Q 4
@
@Mcontrol of the lineprinter
@Nmanagement of the system accounts
@Nexecution of a user job.
@BIn principle each of these processes can be thought
of as executing within its own dedicated
computer, but having some means of communicating with the other
processes.  However, it is a characteristic of many operating system activities,
and user jobs,
that they require the use of a processor for only relatively small amounts
of time.  The rest of the time is spent waiting for something to happen.  For
example, waiting for the lineprinter to finish printing the current line,
for a user process to supply more output for printing, or for an on-line
user to type his next line of input.  Consequently, it
is possible for all of the processes to share the use of a single processor.
A part of the operating system known as the "kernel" allocates the
processor to processes as required, giving each process the
impression that it has a complete machine to itself.
@S21.2 VIRTUAL MACHINES
@BThe kernel of the MUSS operating system provides each process
with a "virtual machine" in which to execute.  The virtual machine
consists of@
@
(i)@IA share of the available processor time.  As far as the process
is concerned, it appears to have a complete processor to itself
and need not be concerned with the fact that it is shared with
other processes.@
@
(ii)@IA share of the available store.  In MUSS each process has a large
virtual store which is divided up into logical units of
information called segments, each of which can be up to 256K bytes
long.  Some of the segments are private to the process, and cannot
be accessed at all by other processes.  Others are common to all
processes, and contain all of the system software; generally,
processes are prevented from modifying the information in these
common segments.@
@
(iii)@IA library of procedures which the process may call.  These reside
in the common segments and so are available to all processes.  They
can be thought of as built-in operations, extending the instruction
set provided by the actual processor.@
@BAn important feature of the virtual machine is that each process
appears to have an entire machine to itself, with complete
freedom to organise itself within this machine.  Thus, processes
need not be written in the knowledge that they will be sharing
the computer with other processes.  Input/output is dealt
with by calling library procedures, which give each process the
appearance of having its own set of input/output devices.
@S21.3 MESSAGES
@BThe processes of an operating system are not in general
independent of one another, but need to communicate.  In MUSS,
processes communicate with one another by sending and receiving
@5messages@0 (using built-in library procedures to do this).
@BEvery process in the system has a unique name, by which the
other processes (and users) may refer to it, and any process
can send a message to any other by specifying its name.  (In fact,
an internal process identification consisting of a System
Process Number (SPN) and a Process Identifier (PID) is used, but
these can be found from the process name).  A single message may
contain any amount of information from a few bytes to 256K bytes.
@BThe message system also forms the only means of communication
between the process in a virtual machine and the outside world.
Peripheral devices are controlled by special processes called
@5device@0 @5controllers@0, which communicate with other processes
via the message system.  Thus for example, information to be
printed on a lineprinter must be sent as a message to "LPT", the
device controller in charge of the lineprinters.
@S21.4 SUPERVISORS
@BUser jobs are introduced into the system by processes called
supervisors.  A supervisor is a process which services requests (in the form
of messages) from users to start jobs.  Its main function is to create and
start new processes to execute these user jobs, but it can also exert some contr
ol over
the execution of any process which it has created by use
of the appropriate operating system procedures.
@BThere is a basic
supervisor permanently resident in the system called JOB.
In addition, any other process may act as a
supervisor to provide alternatives to the basic system facilities.  It was antic
ipated originally that
this facility would be used to provide several alternative
supervisors, each with its own job control
language, specialised towards the needs of different user groups.
In practice this has not been necessary because the basic
system has proved to have sufficient flexibility for all users.
@BThe role of the basic
supervisor is simply to create a virtual machine to run a process.
This process then interprets its own job control commands.
In fact, the job control commands take the form of calls on
library procedures which are to be made within the virtual machine running the p
rocess.
Differing user needs are met by the variety of procedures available.
Some procedures might in practice be interpreters of other job
control languages.  However, even this facility has not been
exploited because job control procedures, like other library
procedures, can be called from programs written in the high-level
languages and complicated job control sequences involving
conditional and repeated actions can be written in the standard
high-level languages.
@S21.5 THE SYSTEM LIBRARY
@BPre-loaded into every virtual machine created by MUSS (except as stated below)
 is a set of compiled (executable)
library procedures.  These provide the process with access to all of the
facilities of the system, and include@
@Q 9
@
@Mmathematical functions
@Nbasic input/output procedures
@Ncompilers
@Neditors
@Njob control procedures
@NJCL interpreters
@Noperating system interface procedures
@N   ('SEND.MESSAGE', for example).
@BThe remaining chapters in this Manual are mainly concerned
with specification and use of these procedures.
@BThe average user would not normally have contact
with the operating system interface procedures.  They are
used by the supervisors, the basic input/output procedures which
interface the users read and print commands into the message system,
and the job control procedures.
The job control procedures are mainly concerned with defining
the environment in which programs are to run.  This usually means
defining the 'documents' which form the inputs and outputs of a
program.
@BConsistency exists between user programs and
users typing commands on terminals, hence either may access any of the preloaded
 set of procedures,
either may use any library
procedure, either can extend this set of procedures
by introducing private libraries.
@BSome implementations of MUSS on small machines may not have
all of the above facilities in the system library.  In this case
the omitted facilities are normally available as private libraries
(Chapter 21) under the username UTIL. To aid in recognition, these
libraries usually have the name of the principal procedure which they
contain.  If an unexpected error message "Command Name Unknown" (type 7/2) is
received, users are advised to check if the required command
is implemented as private library under UTIL.  Users are warned
that there may be local additions under this username which
may not be documented in this Manual.
@S21.6 ACCOUNTING
@BThe accounting system on MUSS is designed to ensure that all
users get a fair share of the facilities available.  Each object in
the system that can be consumed or borrowed from a central pool is
called a resource.  An example of a resource which is consumed is
line-printer output.  Space in the filestore is a reusable resource;
it is borrowed from the system when a new file is created and
returned when the file is deleted.
@BFor each consumable resource that he is allowed to use a user has
a balance which records how much more he can use before he becomes
overdrawn.  The units which indicate the balance are a kind of money
used to control the allocation of system resources.  Within each
resource, charges may be made at different rates depending on the
quality of service provided.  Thus one second of CPU time at Priority
8 will deplete a user's balance more than one second at Priority 9.
@BSimilarly, for each reusable resource, there is a value
indicating the maximum number of objects of that type that he can
borrow at any instant (the maximum number of files in his directory
for example).
@BAt regular intervals (usually every day) users will have a fixed
amount added to their balances of consumable resources.  These
"regular intervals" are termed accounting periods and the fixed
amount, an income.  If a user doesn't consume all of his income in an
accounting period, then his credit in that resource will accumulate
up to a limit set by the System Manager.
@BOne resource a user may be given by the System Manager is that of
having subordinates: that is, other users to whom he gives a
portion of his allocation of resources.  He becomes, in effect, a
"local System Manager" creating and deleting users and controlling
their use of resources.
@F
