top - download
⟦702bf3344⟧ Wang Wps File
Length: 63401 (0xf7a9)
Types: Wang Wps File
Notes: ACCESS, TECHNICAL DATA
Names: »3198A «
Derivation
└─⟦550b0bab9⟧ Bits:30006219 8" Wang WCS floppy, CR 0276A
└─ ⟦this⟧ »3198A «
WangText
…05……00……00……00……00…>…0a……00……00…>…0b…> =…0e…=
<…0a…<…0b…<
<…07…;…0d…;…0e…;…06…:…0a…:…0b…:…0e…:…06…9…0a…9…0f…9…07…8…86…1 …02… …02… …02…
3198A
ACCESS SYS/1983-01-25
PART II - TECHNICAL DATA Page #
T̲A̲B̲L̲E̲ ̲O̲F̲ ̲C̲O̲N̲T̲E̲N̲T̲S̲
4.2.1 Communication Software .................
4.2.1.1 Local Area Network .................
4.2.1.1.1 Network Topology ...............
4.2.1.1.2 Network Configuration ..........
4.2.1.1.3 Functional Description .........
4.2.1.1.4 TDX Bus Data Transfer ..........
4.2.1.1.5 TDX Bus Host Interface (STI/TIA)
4.2.1.1.6 TDX Bus Terminal Adapter .......
4.2.1.2 Long-Haul Communication Network
Interface ..........................
4.2.2.1 Operating System ...................
4.2.2.1.1 Overview of DAMOS Operational
Software .......................
4.2.2.1.2 Security .......................
4.2.2.1.3 Kernel .........................
4.2.2.1.3.1 Resource Management ........
4.2.2.1.3.2 Process Management
4.2.2.1.3.3 Memory Management
4.2.2.1.3.4 Process Communication ......
4.2.2.1.3.5 CPU Management .............
4.2.2.1.3.6 Processing Unit Management .
4.2.2.3.7 Transport Mechanisms ...........
4.2.2.3.7.1 Basic Transport Service ....
4.2.2.3.7.2 Basic Datagram Service .....
4.2.2.1.4 DAMOS Input/Output .............
4.2.2.1.5 File Management System .........
4.2.2.1.5.1 Device and Volume Handling .
4.2.2.1.5.2 Directories ................
4.2.2.1.5.3 Files ......................
4.2.2.1.5.3.1 File Types .............
4.2.2.1.5.3.2 File Commands ..........
4.2.2.1.5.4 User Handling ..............
4.2.2.1.5.5 Disk Integrity .............
4.2.2.1.5.5.1 Security ...............
4.2.2.1.5.5.2 Redundant Disks ........
4.2.2.1.5.5.3 Bad Sectors ............
4.2.2.1.5.6 Access Methods .............
4.2.2.1.5.6.1 Unstructured Access ....
4.2.2.1.5.6.2 Indexed Sequential
Access .................
4.2.2.1.6 Magnetic Tape File Management
System .........................
4.2.2.1.6.1 Device functions ...........
4.2.2.1.6.2 Volume functions ...........
4.2.2.1.6.3 File functions .............
4.2.2.1.6.4 Record functions ...........
4.2.2.1.7 Terminal Management System .....
4.2.2.1.7.1 Transfer of I/O Data .......
4.2.2.1.7.1.1 File Mode ..............
4.2.2.1.7.1.2 Communication Mode .....
4.2.2.1.7.2 User Handling ..............
4.2.2.1.7.3 Hardware Categories ........
4.2.2.1.7.3.1 Terminal Controllers ...
4.2.2.1.7.3.2 Lines ..................
4.2.2.1.7.3.3 Units ..................
4.2.2.1.8 System Initialization ..........
4.2.2.1.9 Highlevel Operating System
(HIOS) .......................
4.2.2.1.10 System Generation Software ...
4.2.2.1.11 Diagnostic Programs ..........
4.2.2.1.11.1 Off-line Diagnostic
Programs ..................
4.2.2.1.11.2 On-Line Diagnostic
Programs ..................
4.2.2.3 Language Processors ................
4.2.2.4 General Utilities ..................
4.2.2.10 Statistics ........................
4.2.2.11 Optical Character Reader .........
4.2.1 C̲o̲m̲m̲u̲n̲i̲c̲a̲t̲i̲o̲n̲ ̲s̲o̲f̲t̲w̲a̲r̲e̲
4.2.1.1 L̲o̲c̲a̲l̲ ̲A̲r̲e̲a̲ ̲N̲e̲t̲w̲o̲r̲k̲
4.2.1.1.1 N̲e̲t̲w̲o̲r̲k̲ ̲T̲o̲p̲o̲l̲o̲g̲y̲
The Local Area Network topology is based on a star
mesk of individually dualized, time division multiplexed
TDX buses. Each TDX bus is via a front-end processor
(STI) connected to a dualized CR80 host computer. Communica-
tion between individual TDX buses is established through
the connected CR80 host computer.
The TDX local network design complies with the International
Standards Organization's seven-level Open Systems Interconnection
Reference Model. This facilitates the integration of
the TDX-net with networks supplied by other manufacturers.
4.2.1.1.2 N̲e̲t̲w̲o̲r̲k̲ ̲C̲o̲n̲f̲i̲g̲u̲r̲a̲t̲i̲o̲n̲
Each TDX bus configuration consists of:
- a double twisted pair cable (bus)
- a TDX-Controller
- up to 140 I/O devices
The I/O devices can be divided into:
- CR80 host interfaces (up to 12)
- serial link interfaces (up to 122)
Individual TDX buses are interconnected either through
mutual host computers or through CR80 host-to-host
suprabus.
4.2.1.1.3 F̲u̲n̲c̲t̲i̲o̲n̲a̲l̲ ̲D̲e̲s̲c̲r̲i̲p̲t̲i̲o̲n̲
A single or dualized TDX bus is monitored and controlled
by the TDX Controller which performs the following
tasks:
- Synchronize communication on the upper bus by inserting
a MUX-No. in the HDLC frame on the lower bus.
- Answer a bandwidth request and allocate bandwidth
according to the request.
- Poll and appended devices to collect diagnostic
information.
- Communicate with a Watchdog (in a dualized TDX
Controller Configuration).
- Select one of two upper buses to optimize performance
in a dualized bus system.
The TDX Controller outputs a continous bitstream of
1.8432 Mbit/Sec. on the lower bus. This stream is organized
in frames of 288 bits each, 6400 per second.
All frames received from the "upper" bus are transmitted
on the "lower" bus delayed one frame. Only if the CRC
of a received frame is not correct or if the frame
is destined to Host No. 0 (the Controller itself),
the frame will not be swapped to the transmitter buffer.
When a received frame is distined to host No. 0, it
is loaded to the controller processor which is managing
the Mux table. The received frame may contain a request
for a changed bandwidth to a given TDX device (BW-request).
The synchronization is achieved by inserting as second
byte in the HDLC frame on the lower bus, a Device No.
taken from a Mux table that is scanned according to
the speed level assigned to each device of the TDX
system.
Figure 4.2.1.1.3-1 TDX-Frame
All devices with their unique Device No. on the TDX-BUS
look at the Mux byte, and if it is identical to its
Device No., this device has the use of the upper bus,
to transmit data at the end of the frame on the lower
bus, provided that the lower bus CRC check shows no
errors. This ensures that only one device will transmit
on the upper bus at any time.
The bandwidth allocation is determined by the Mux table
which is changeable (dynamic). A request for a changed
bandwidth to a specified device received on the upper
bus is accepted if the system bandwidth is large enough
or reflected if the system bandwidth is too small.
The answer (ACK, NACK) is sent to the requesting device,
when a free time slice occurs on the lower bus. The
dummy Device No.FF (which is inserted in the MUX table,
to allow the Controller access to the lower bus in
the following frame) has a minimum bandwidth on 100
bit/sec. giving a free time slot to answers at least
every 1.28 sec.
The diagnostic information is collected by polling
each device connected to the system. If an answer is
not received within 4 scans in the Mux table, a retransmission
is executed. After three requests not answered, the
device is perceived as not connected to the system.
The upper bus switch-over feature is achieved by counting
errorfree received frames from the upper bus (both
frames destined to the controller and frames swapped
to the lower bus) each time the Mux table has been
read completely. If this count is less than 1:4 of
the previous count, the bus is switched. This implies
that one device may be removed every 1.28 sec. without
changing buses, but removing a number of devices instantly
causes a switch of upper buses.
FIG. 4.2.1.1.2-1
TDX FRAME LAYOUT…86…1 …02… …02… …02… …02…
4.2.1.1.4 T̲D̲X̲ ̲B̲u̲s̲ ̲D̲a̲t̲a̲ ̲T̲r̲a̲n̲s̲f̲e̲r̲
In the following is given an example of a data transfer
between devices on a TDX bus shown in figure 4.2.1.1.4-1.
Figure 4.2.1.1.4-1 TDX-bus
Let us suppose that device 3 wants to send some data
to device 1. The sequence of events is as follows.
T̲i̲m̲e̲ ̲X̲.̲ The controller inserts a '3' into the MUX
field of the frame currently passing through it.
T̲i̲m̲e̲ ̲X̲ ̲+̲ ̲1̲ ̲s̲l̲o̲t̲.̲ Device 3 notices its own address
(3) as a MUX number on the lower bus, so it prepares
itself for transmission of a frame.
T̲i̲m̲e̲ ̲X̲ ̲+̲ ̲2̲ ̲s̲l̲o̲t̲s̲.̲ Device 3 generates and transmits
a frame containing 128 bits of useful data and a '1'
in the destination address field. This frame is transmitted
on the upper bus. Meanwhile, as always, one frame is
being processed by the controller and another frame
is transmitted on the lower bus and is accepted by
the device that it is addressed to.
T̲i̲m̲e̲ ̲X̲ ̲+̲ ̲3̲ ̲s̲l̲o̲t̲s̲.̲ Data from device 3 has arrived at
the controller. The controller adds a MUX number to
the frame. This is a message to some other device that
means "you may transmit in 2 slots' time". The destination
address (in this case: 1) remains in the frame. Timing
signals are also added.
T̲i̲m̲e̲ ̲X̲ ̲+̲ ̲4̲ ̲s̲l̲o̲t̲s̲.̲ All the devices look at the destination
field of the current frame on the lower bus. In this
example, device 1 realises that this frame is for itself,
and accepts it. Various error checks are performed
by the device and if all is well it extracts the useful
data bits. If all is not well, it issues a special
frame (when it gets a chance via the MUX number mechanism)
to the controller. This frame requests device 3 to
re-transmit the data.
This sequence is illustrated in figure 4.2.1.1.4-2.
Note that the lower bus has continous transmission.
If no device has recently taken up its option to transmit,
then the controller "invents" a frame and sends it
along to a bogus device. Conversely, if a device tries
to send out frames more frequently than the MUX table
currently allows, it just has to wait. However, the
MUX table may be altered by the controller if the device
makes a habit of trying to flood the bus. This mechanism
is the Dynamic Bandwidth Allocation mentioned previously.
DATA TRANSFER ON THE TDX BUS
Figure 4.2.1.1.4-2
4.2.1.1.5 T̲D̲X̲ ̲B̲u̲s̲ ̲H̲o̲s̲t̲ ̲I̲n̲t̲e̲r̲f̲a̲c̲e̲ ̲(̲S̲T̲I̲/̲T̲I̲A̲)̲
In the range of TDX-devices the STI makes the high
performance end interfacing of a CR80 minicomputer
to the TDX-bus system.
The STI is a high bandwidth device which is able to
interface to other devices connected to the TDX-bus.
It may address 4096 logical lines through the TDX-system,
and each line may have bandwidth allocated individually.
The current implementation of STI-handler and STI serve
up to 140 channels running actively in parallel. Through
the STI the CR80 minicomputer is able, dynamically,
to establish and dismantle all logical channels originating
from and belonging to the Domain of the STI. The CR80
is also able to make dynamically change of the bandwidth-assignment
on the TDX-bus.
By connecting to a STI several TIAs and SBAs it is
possible to interface the CR80 with both TDX-buses
and SUPRA-buses via the same STI. The maximum total
number of TDX-buses and/or SUPRA-buses connected to
a single STI is limited to 8. The STI will be addressed
with the same HOST-number on each bus in a given configuration.
The STI serves the TDX-packet protocol, which guaranties
errorfree transmission of data.
The STI is based on 2 processors:
- The Ingoing processor, which moves data from the
front end (TIA or SBA) to the CR80 memory. The
data-traffic is controlled by the TDX-packet protocol.
As the data is divided into many logical channels
this processor also demultiplexes traffic coming
from the TDX-bus. Data delivered to the CR80-computer
is by the TDX packet protocol ensured errorfree.
When a complete packet is received it is reported
to the STI-handler by chaining the ralated data-buffer
descriptor (DBD) into the ingoing completion queue.
Transmission-errors, which are unrecoverable by
the protocol are reported as completion codes in
the DBDs.
- The Outgoing processor, which moves data from the
CR80 memory to the Front end. Data sent to the
TDX-bus is controlled by the outputter-part of
the TDX packet protocol. Beside data transfer and
protocol, this processor also scans all the logical
channels set up by the CR80 computer, and multiplexes
their data into one single stream delivered in
the outgoing front end ringbuffers. When a packet
is correctly transmitted, it is reported in the
outgoing completion queue. Transmission-errors,
which are unrecoverable by the protocol are reported
as completion codes in the DBDs.
Overleaf (figure 4.2.1.1.5-1) is shown the dataflow
through the STI and the datastructures in the central-RAM,
which is shared between Ingoing Processor, Outgoing
processor and the STI-handler.
DATAFLOW OVERVIEW IN THE STI
Figure 4.2.1.1.5-1
4.2.1.1.6 T̲D̲X̲ ̲B̲u̲s̲ ̲T̲e̲r̲m̲i̲n̲a̲l̲ ̲A̲d̲a̲p̲t̲e̲r̲
The intelligent Terminal Adapter (XTA) facilitates
a uniform interface to all terminals supporting the
minimal ANSII X3-25 standard capabilities, which the
majority of terminals on the market do. This includes
for example the emulation of protected fields on the
screen where required, by using a map in memory of
the VDU screen, see figure 4.2.1.1.6-1.
TERMINAL EMULATION
Figure 4.2.1.1.6-1
4.2.1.2 L̲o̲n̲g̲-̲H̲a̲u̲l̲ ̲C̲o̲m̲m̲u̲n̲i̲c̲a̲t̲i̲o̲n̲ ̲N̲e̲t̲w̲o̲r̲k̲ ̲I̲n̲t̲e̲r̲f̲a̲c̲e̲
The ARPANET interface with the TCP/IP protocols, will
be implemented in the CR80 host computer which constitutes
the center of the Local Area Network star mesh.
Users in the Local Area Network will communicate with
the ARPANET by means of calls to the IP module as outlined
in para 3.4 of the Internet Protocol Specification.
4.2.2.1 O̲p̲e̲r̲a̲t̲i̲n̲g̲ ̲S̲y̲s̲t̲e̲m̲
The CR80 Advanced Multi Processor Operating system
DAMOS is the standard operating system for memory mapped
CR80 systems.
DAMOS is divided into operational and support software
as defined overleaf.
DAMOS includes a virtual memory operating system kernel
for the mapped CR80 series of computers.
DAMOS fully supports the CR80 architecture which facilitates
fault tolerant computing based on hardware redundancy.
DAMOS supports a wide range of machines from a single
Processing Unit (PU) with 1 CPU and 128 K words of
main memory, and up to a maximum configuration with
16 PU's where each PU has 5 CPU's and 16 M words of
virtual memory and a virtually unlimited amount of
peripheral equipment including backing storage.
DAMOS is particularly suited for use in real time systems
but supports also other environments like software
development and batch. The main objectives fulfilled
in DAMOS are: high efficiency, flexibility, and secure
processing.
DAMOS is built as a hierarchy of modules, each performing
its own special task. The services offered by DAMOS
include CPU, PU, and memory management. Demand paging
is the basic memory scheduling mechanism, but process
swapping is also supported. Other levels of DAMOS
provide process management and interprocess communication,
basic device handling and higher level device handling
including handling of interactive terminals, communication
lines, and file structured backing storage devices.
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
DAMOS
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
OPERATIONAL SUPPORT
SOFTWARE SOFTWARE
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
̲ ̲
- Kernel
- resource management - highlevel operating
system
- directory functions - system generation software
- process management - maintenance and diagnostic
- memory management programs
- process communica-
tion
- device management
- device handling
- error processing
- real time clock
- PU management
- Transport Mechanisms
- Input/output system
- File Management
- Magtape Management
- Terminal Management
- Initialization
Figure 4.2.2.1-1…01…DAMOS Software Overview
DAMOS provides an operating system kernel which integrates
supervisory services for real time, interactive and
batchsystems. A comprehensive set of software development
tools is available under DAMOS. The following languages
are presently available:
- Cobol
- Assembler
- SWELL, the CR80 system programing language
- Pascal
The following languages are announced:
- Fortran 77
- Ada
The DAMOS standard operational software is described
in sections 4.2.2.1.1-8. The description is divided
into the following areas:
- Overview of DAMOS
- Security,
which describes the general DAMOS approach to data
security
- Kernel,
which describes the DAMOS operating system kernel
components
- DAMOS Input/Output,
which describes the DAMOS standard interfaces to
peripheral I/O equipment, the DAMOS disk file management,
magnetic tape file management and terminal and
communication line management systems
- System initialization
The DAMOS standard support software
- high level operating system
- programing languages
- maintenance and diagnostics programs
is described in sections 4.2.1.1.9-11
4.2.2.1.1 O̲v̲e̲r̲v̲i̲e̲w̲ ̲o̲f̲ ̲D̲A̲M̲O̲S̲ ̲O̲p̲e̲r̲a̲t̲i̲o̲n̲a̲l̲ ̲S̲o̲f̲t̲w̲a̲r̲e̲
DAMOS may be visualized as the implementation of a
set of abstract data types and a corresponding set
of tools for creating and manupulating instantiations
(objects) of these types.
The major components in DAMOS are the Kernel, the File
Management System, the Magnetic Tape File Management
System, the Terminal Management System and the Root
Operating System.
The DAMOS Kernel exists in one incarnation for each
processing unit (PU). The data types and functions
implemented by the Kernel are:
D̲a̲t̲a̲ ̲T̲y̲p̲e̲ F̲u̲n̲c̲t̲i̲o̲n̲
CPUs CPU management and scheduling
processes process management
virtual memory segments memory management
PU's PU management
synchronization elements inter process communication
device device management and
basic device access
methods
ports basic transport service
The Kernel also provides facilities for
- processing of errors
- centralized error reporting
- a data transfer mechanism
- a PU service module
The File Management System (FMS) implements files on
disks. The FMS provides functions for manipulating
and accessing files and acts as an operating system
for a group of disks units. The FMS may exist in several
incarnations in each PU where each incarnation controls
its own devices.
The Terminal Management System (TMS) is similar to
the FMS. It provides functions for manipulating and
accessing communication lines and terminals including
line printers. The objects accessed via the TMS are
called units. A unit may be an interactive terminal,
a line printer or a virtual circuit. The TMS acts
as an operating system for a group of communication
devices attached via LTUs, LTUXs or a parallel controller.
The TMS may exist in several incarnations in each PU,
each incarnation controlling its own devices.
The Magnetic Tape File Management System handles files
on magnetic tape units.
A common security policy and hiearachical resource
management strategy is used by the Kernel, the FMS
and the TMS. These strategies have been designed with
the objective of allowing multiple concurrent higher
level operating systems to coexist in a PU in a secure
and independent manner.
The Root operating system is a basic low level operating
system which intially possesses all resources in its
PU.
4.2.2.1.2 S̲e̲c̲u̲r̲i̲t̲y̲
DAMOS offers comprehensive data security features.
A multilevel security system ensures that protected
data is not disclosed to unauthorized users and that
protected data is not modified by unauthorized users.
All memory allocatable for multiple users is erased
prior to allocation in case of reload, change of mode,
etc. The erase facility is controlled during system
generation.
The security system is based on the following facilities:
- Hardware supported user mode/privileged mode with
16 privilege levels. Priviliged instructions can
be executed only when processing under DAMOS control.
- Hardware protected addressing boundaries for each
process.
- Non-assigned instructions will cause a trap.
- Primary memory is parity protected.
- Memory bound violation, non-assigned instructions,
or illegal use of privileged instructions cause
an interrupt of highest priority.
- The hierarchical structure of DAMOS ensures a controlled
use of DAMOS functions.
- A general centralized addressing mechanism is used
whenever objects external to a user process are
referred to.
- A general centralized access authorization mechanism
is employed.
Centralized addressing capabilities and access authorization
are integral parts of the security implementation.
User processes are capable of addressing Kernel objects
only via the associated object descriptor table. The
following types of DAMOS objects are known only via
object descriptors:
- Processes
- Synchronization elements
- Segments
- Devices
- PUs
- CPUs
- Ports
The object forms the user level representation of a
DAMOS Kernel object. It includes the following information:
- A capability vector specifying the operations which
may be performed on the object by the process which
has the object descriptor.
- A security classification
The access right information concerning the various
DAMOS objects is retained in a PU directory of object
control blocks. Each control is associated with a
single object.
When the access right of a process to a segment is
verified and the segment is included in the logical
memory space of the process, the contents of that segment
may be accessed on a 16-bit word basis at the hardware
level subject to hardware access checks.
Authorization of access to an object is based on
- security classification check
- functional capability check for the object
versus the process
The security policy is based on a multilevel -multicompartment
security system.
4.2.2.1.3 K̲e̲r̲n̲e̲l̲
The DAMOS Kernel is a set of reentrant program modules
which provide the lowest level of system service above
the CR80 hardware and firmware level.
The Kernel consists of the following components:
- Resource Management,
which administers resources in a coherent way
- Directory Functions,
which provide a common directory service function
for the other Kernel components
- Process Manager,
which provides tools for CPU management, process
management and scheduling
- Page Manager,
which provides memory management tools and implements
a segmented virtual memory
- Process Communication Facility,
which provides a mechanism for exchange of control
information between processes
- Device Manager
which provides a common set of device related functions
for device handlers and a standard interface to
device handlers
- Device Handlers,
which control and interface to peripheral devices
- Error Processor,
which handles errors detected at the hardware and
Kernel level and provides a general central error
reporting mechanism
- Real Time Clock
for synchronization with real time
- PU Manager,
which provides functions for coupling and decoupling
PUs
- Transport Mechanisms
which provides general mechanisms for exchange
of bulk data between processes and device handlers.
The following subsections describe the main Kernel
functions:
- resource management
- process management
- memory management
- process communication
- CPU management
- PU management
- Transport Mechanisms
4.2.2.1.3.1 R̲e̲s̲o̲u̲r̲c̲e̲ ̲M̲a̲n̲a̲g̲e̲m̲e̲n̲t̲
The goal of DAMOS Resource Management is to implement
a set of tools which enables the individual DAMOS modules
to handle resources in a coherent way. This again,
will make it possible for separate operating systems
to implement their own resource policies without interference.
Further built-in deadlock situations will be avoided.
The resource management module governs anonymous resources,
such as control blocks. Examples of resource types
are:
- process control blocks
- segment control blocks
- synchronization elements
- PU directory entries
Each type of resource is managed independently from
all other types.
The resources are managed in a way that corresponds
to the hierarchical relationships among processes.
Two operating systems which have initially got disjoint
sets of resources, may delegate these resources to
their subordinate processes according to separate and
non-interfering strategies. For example, one operating
sytem may give all its ubordinate processes distinct
resource pools, i.e. there will not be any risk of
one process disturbing another. On the contrary, the
other operating system may let all its subordinate
processes share a common pool, i.e there may be a much
better resource utilization at the cost of the risk
for deadlock among these processes.
4.2.2.1.3.2 P̲r̲o̲c̲e̲s̲s̲ ̲M̲a̲n̲a̲g̲e̲m̲e̲n̲t̲
In the CR80 system, a clear distinction is made between
programs and their executions, called processes. This
distinction is made logically as well as physically
be applying two different base registers: one for program
code and one for process data. This distinction makes
reentrant, unmodifiable code inevitable.
The process is the fundamental concept in CR80 terminology.
The process is an execution of a program module in
a given memory area. The process is identified to
the remaining software by a unique name. Thus, other
processes need not to be aware of the actual location
of a process in memory but must refer to it by name.
4.2.2.1.3.3 M̲e̲m̲o̲r̲y̲ ̲M̲a̲n̲a̲g̲e̲m̲e̲n̲t̲
The addressing mechanism of the CR80 limits the address
space seen by a process at any one time to a window
of 2 x 64K words. Due to the virtual memory concept
of DAMOS a process may, however, change the "position"
of the window, thus leading to a practically unlimited
addressing capability.
The finest granularity of the virtual memory known
to a process is a segment. Segments can be created
and deleted. They have unique identifiers and may
have different sizes. A process which has created
a segment may allow others to share the segment by
explicitly identifying them and stating their access
rights to the segment.
The Page Manager implements virtual memory. The actual
space allocated in a Processing Unit to a process may
be only a few segments, while the logical address space
is the full 2 x 64k words. Whenever addressing of
a segment, that is not in physical memory, is attempted,
the Page Manager will bring in the addressed segment.
4.2.2.1.3.4 P̲r̲o̲c̲e̲s̲s̲ ̲C̲o̲m̲m̲u̲n̲i̲c̲a̲t̲i̲o̲n̲
Synchronization of processes and communication between
them is supported in DAMOS by objects called Synchronization
Elements (synch elements) which are referred to by
symbolic names and may thus be known by processes system-wide.
In DAMOS a process cannot "send" a block of data directly
to another process identified by name. The exchange
must be done using a synch element.
4.2.2.1.3.5 C̲P̲U̲ ̲M̲a̲n̲a̲g̲e̲m̲e̲n̲t̲
The CPUs in a processing unit may be pooled and a given
process is allocated processing power from one such
pool. In this way CPUs can be dedicated processes.
4.2.2.1.3.6 P̲r̲o̲c̲e̲s̲s̲i̲n̲g̲ ̲U̲n̲i̲t̲ ̲M̲a̲n̲a̲g̲e̲m̲e̲n̲t̲
The DAMOS Kernel provides facilities for managing the
logical connections between the individual Processing
Units attached to a Supra Bus.
PUs may be connected logically into groups. The number
of PUs in a group may vary from 1 to 16. Two groups
may be merged, the result being a new PU-group.
Objects are identified by symbolic names having either
local or global scope. They are accessible from all
PUs in the group where they reside.
PU Management provides functions for inclusion of a
PU in a PU-group.
A logical connection between two PUs is not established
until both have received an include request from the
opposite. When trying to connect two PU-groups, conflicts
between the use of global names may arise. Therefore,
a connection is only established if the scope of all
names can be maintained.
The PU Management is designed to allow graceful degradation
when purposely closing a PU or isolating a faulty PU.
It is possible from a PU to force a member out of
its common group. All PUs in the group are informed
to break their logical connection to the designated
PU. As a consequence all global objects residing in
the isolated PU are thereafter unknown to the group.
If not faulty, the isolated PU continues executing
its local processes and is ready to receive new include
requests.
4.2.2.1.3.7 T̲r̲a̲n̲s̲p̲o̲r̲t̲ ̲M̲e̲c̲h̲a̲n̲i̲s̲m̲s̲
4.2.2.1.3.7.1 B̲a̲s̲i̲c̲ ̲T̲r̲a̲n̲s̲p̲o̲r̲t̲ ̲S̲e̲r̲v̲i̲c̲e̲
Basic Transport Service (BTS) is a module within DAMOS
which enables processes to communicate in a uniform
manner, whether they are located:
1) in the same CR80 processor unit
2) in computers connected via a supra bus, running
the same operating system
3) in computers connected via a communication line,
running independent operating systems.
Figure 4.2.2.1.3.7.1-1
BTS Environment
BTS can also be used for communication between device
handlers. In this way, data may be switched through
an intermediate node, directly from one communication
device to another (Figure 4.2.2.1.3.7.1-2).
Figure 4.2.2.1.3.7.1-2
Switching
Figure 4.2.2.1.3.7.1-3 Connection Establishment
When a user process A wants to communicate with user
process B, it:
1) issues a "connect", specifying the global identification
of the other process BTS, then
2) notifies process B, that it has been called
from A
User process B may then either:
3a) accept to communicate with A
or
3b) reject to communicate with A and BTS notifies
process A either:
4a) that the communication has been established
or
4b) that the communication could not be established.
Figure 4.2.2.1.3.7.1-4 Data Transport
When user process wants to send data via the connection,
it:
1) issues a "send request" giving BTS a pointer to
the data, specifying the address and the length
of data.
When user process B is ready to receive data via the
connecition, it
2) issues a "receiving request" giving BTS a pointer
to an empty data buffer, specifying the address
and length.
BTS then initiates the data transfer, and when the
transfer is completed, it:
3) notifies A that data has been sent
4) notifies B that data has been received.
User process B may simultaneously send data to user
process A via the connection (it is fully duplex).
The "receive request" from B may be issued before the
"send request" from A.
Any number of "send request" and "receive requests"
may be outstanding on a connecition, they will be served
by BTS as soon as a match occurs.
Figure 4.2.2.1.3.7.1-5 Deferred Buffering
If user process B has many connections on which it
may receive data, it may not be able to allocate an
input buffer for each.
It may then:
1) give a data area to BTS to be used as a common
buffer pool for several connections
2) specify that buffers from the pool shall be used
for input on the connection
when user process A
3) issues a "send request"
BTS tries to allocate buffers from the buffer pool.
When they become acailable, BTS initiates the data
transfer, and when it is complete:
4) notifies A that data has been setn
5) notifies B that data has been received, specifying
the buffers containing the input data.
Figure 4.2.2.1.3.7.1-6 The DAMOS Implementation
BTS is an integrated part of the DAMOS kernel.
1) within one CR80 computer, the DMA device in the
MAP is used to move data.
2) On connection between computers connected by a
supra bus, data is to/from the CR80 memory by the
Supra Terminal Interface (STI), interfacing to
the supra bus.
3) On connections via communication lines, data is
first moved from the user process to the memory
of the Line Termination Unit (LTU) by the DMA device
in the MAP.
When it has been transmitted to the memory of the
receiving LTU, it is moved into the memory of the
user processes by the DMA device in the MAP.
The CPU is thus never loaded with movement of data.
4.2.2.1.3.7.2 B̲a̲s̲i̲c̲ ̲D̲a̲t̲a̲g̲r̲a̲m̲ ̲S̲e̲r̲v̲i̲c̲e̲
The Basic Datagram Service (BDS) is a DAMOS system
component for manipulation and exchange of main memory
resident data buffers. The BDS operates within the
BTS environment of the BTS by exploiting the mapping
mechanisms offered by the CR80 hardware. BDS enables
processes within a single PU to exchange large amounts
of data by reference, and processes in different PUs
to exchange data by copying from buffer to buffer.
The BDS provides functions for allocation, release
and mapping of buffers. Exchange of buffers within
a PU is based on communication of buffer identifiers
via interprocess communication for example by means
of the DAMOS PCF.
The BDS supports buffers of fixed length. It is possible
to configure the BDS with several types of buffers
corresponding to different sizes. In the present system
two types of buffers with sizes 64 and 512 bytes are
envisaged.
Buffers are grouped in pools which are DAMOS objects.
The buffers in a pool have the same size.
Before a process can access a buffer, the buffer must
become part of the logical address space of the process.
This is accomplished by a map-in function which changes
the composition of the translation table of the process.
A special kind of pseudo segment is used for this
purpose. These segments are called buffer-windows.
The buffer-windows must be 'mapped' into the logical
address space of the process before buffers can be
mapped into the buffer-window.
The BDS provides the following functions:
a̲l̲l̲o̲c̲a̲t̲e̲ ̲b̲u̲f̲ (pool)(buf ̲id)
This function allocates a buffer from the specified
pool.
A PU-wide identification - buf ̲id - of the buffer
is returned. This identification must be used
to release and map in the buffer. The identification
of the buffer can be passed to and used by another
process.
r̲e̲l̲e̲a̲s̲e̲ ̲b̲u̲f̲ (buf ̲id)
This function deallocates the buffer identified
by buf ̲id.
M̲a̲p̲ ̲i̲n̲ (buf ̲id, approx-loc)(actual-loc)
This function maps in a specified buffer at the
specified location. It is checked that the affected
logical page(s) is part of a buffer-window. The
location specified at call is only accurate to
1 k; the actual location is defined at exit from
the function.
The function changes the contents of the translation
table for the process.
B̲u̲f̲ ̲a̲d̲d̲r̲ (buf ̲id)(addr)
This function returns the physical address of the
buffer. The address is delivered in a format compatible
with the format required by XFER.
This function is used as a prerequisite for transfer
of buffer contents between PUs.
4.2.2.1.4 D̲A̲M̲O̲S̲ ̲I̲n̲p̲u̲t̲/̲O̲u̲t̲p̲u̲t̲
DAMOS supports input/output (I/O) from user programs
at different levels.
At the lowest level user programs can interact with
device handlers directly and transfer blocks of data
by means of the Basic Transport Service modulel. This
interface is illustrated in the figure on next page.
Device control is exercised via the Device Manager
functions. Data is transfered between the user process
and the device handler using a port in the user process
and a port in the device handler.
At a higher level DAMOS offers a more structured I/O
facility under the DAMOS I/O System (IOS).
The IOS provides a uniform, device independent interface
for user processes to
- disk files
- magnetic tape files
- interactive terminals
- communication lines
- line printers
The IOS is a set of standard interface procedures through
which a user communicates with a class of DAMOS service
processes known as General File Management Systems.
General File Management Systems include:
- the File Management System which implements disk
files
- the Magnetic Tape File Management System for magnetic
tape files
- the Terminal Management System for communication
lines, interactive terminals and printers.
The General File Management Systems provide functions
which are classified as:
- device handling
- user handling
- file handling
- file access
The common file access functions provided by the IOS
are readbytes for input and appendbyte and modifybytes
for output.
Figure 4.2.2.1.4-1
DAMOS I/O SYSTEM
Data and Control Flow
These basic functions are used for transfer of blocks
of data.
On top of these functions the IOS provides a stream
I/O facility where the IOS handles the blocking and
buffering of data.
4.2.2.1.5 F̲i̲l̲e̲ ̲M̲a̲n̲a̲g̲e̲m̲e̲n̲t̲ ̲S̲y̲s̲t̲e̲m̲
The File Management System (FMS) is responsible for
storing, maintaining, and retrieving information on
secondary storage devices (disks).
The number and kind of devices attached to the FMS
is dynamically reconfigurable.
The following subjects are handled:
- devices and volumes
…02…- directories
- files
- users
- integrity
- access methods
4.2.2.1.5.1 D̲e̲v̲i̲c̲e̲ ̲a̲n̲d̲ ̲V̲o̲l̲u̲m̲e̲ ̲H̲a̲n̲d̲l̲i̲n̲g̲
The file system may be given commands concerning:
- Management of peripheral devices.
Devices may be assigned to and deassigned from
the file system dynamically. Instances of device
handlers are at the same time created or deleted.
- Management of volumes.
Volumes may be mounted on and dismounted from specific
devices.
4.2.2.1.5.2 D̲i̲r̲e̲c̲t̲o̲r̲i̲e̲s̲
The file system uses directories to implement symbolic
naming of files. If a file has been entered into a
directory under a name specified by the user, it is
possible to locate and use it later on. Temporary
files does not need to be named. A file may be entered
into several directories, perhaps under different names.
Since a directory is also considered a file, it can
itself be given a name and entered into another directory.
This process may continue to any depth, thus enabling
a hierarchical structure of file names.
4.2.2.1.5.3 F̲i̲l̲e̲s̲
4.2.2.1.5.3.1 F̲i̲l̲e̲ ̲T̲y̲p̲e̲s̲
The file system supports two different organizations
of files on disk. Al contiguous file consists of a
sequence of consecutive sectors on the disk. The size
of a contiguous file is fixed at the time the file
is created and cannot be extended later on. A random
file consists of a chain of indices giving the addresses
of areas scattered on the volume. Each area consists
of a number of consecutive sectors. The number of
sectors per area is determined at creation time, whereas
the number of areas may increase during the lifetime
of the file.
4.2.2.1.5.3.2 F̲i̲l̲e̲ ̲C̲o̲m̲m̲a̲n̲d̲s̲
The commands given to the file system concerning files
may be grouped as:
- Creation and removal of files.
A user may request that a file is created with
a given set of attributes and put on a named volume.
- Naming of files in directories.
A file may be entered into a directory under a
symbolic name. Using that name it is possible
to locate the file later on. The file may also
be renamed or removed from the directory again.
- Change of access rights for a specfic user group
(or the public) vis a vis a file. The right to
change the access rights is itself delegatable.
4.2.2.1.5.4 U̲s̲e̲r̲ ̲H̲a̲n̲d̲l̲i̲n̲g̲
The file management system may be given commands concerning:
- Creation and Removal of users (processes)
4.2.2.1.5.5 D̲i̲s̲k̲ ̲I̲n̲t̲e̲g̲r̲i̲t̲y̲
4.2.2.1.5.5.1 S̲e̲c̲u̲r̲i̲t̲y̲
The protection of data entrusted to the file management
system is handled by two mechanisms:
The first mechanism for access control is based on
the use of Access Control Lists (ACL). There is an
ACL connected to each file. The ACL is a table which
describes the access rights of each individual user
group (one being the public) to the corresponding file.
Whenever a user tries to access a file, the ACL is
used to verify that he is indeed allowed to perform
this access.
The second mechanism for access control is based on
a security classificatio system. Each user and each
file is assigned a classification. The user classification
is recorded in the user control block and the file
classification is recorded on the volume. An access
to a file is only allowed if the classification levels
of the user and the file match to each other.
4.2.2.1.5.5.2 R̲e̲d̲u̲n̲d̲a̲n̲t̲ ̲D̲i̲s̲k̲s̲
The FMS allows use of redundant disk packs, which are
updated concurrently to assure that data will not be
lost in case of a hard error on one disk.
The FMS allows exclusion of one of the two identical
volumes, while normal service goes on on the other
one. After repair it is possible to bring up one volume
to the state of the running volume, while normal service
continues (perhaps with degraded performance).
The bringing up is done by marking a raw copy of the
good disk to that which should be brought up. While
the copying takes place all read operations are directed
to both disks.
4.2.2.1.5.5.3 B̲a̲d̲ ̲S̲e̲c̲t̲o̲r̲s̲
The FMS is able to use a disk pack with bad sectors,
unless it is sector 0.
The bad sectors are handled by keeping a translation
table on each volume from each bad sector to an alternative
sector.
While using redundant disks the translation tables
of the two disks must be kept identical to assure that
all disk addresses can bve interpreted in the same
way. If bad sectors are detected while bringing up
a disk, they are marked as such on both disks and both
translation tables are updated accordingly.
4.2.2.1.5.6 A̲c̲c̲e̲s̲s̲ ̲M̲e̲t̲h̲o̲d̲s̲
The file management system implements two access methods
to files:
4.2.2.1.5.6.1 U̲n̲s̲t̲r̲u̲c̲t̲u̲r̲e̲d̲ ̲A̲c̲c̲e̲s̲s̲
For transfer purposes a file is considered simply as
a string of bytes. It is, therefore, a byte string
which is transferred between a file and a user buffer.
The user can directly access any byte string in a file.
The commands which are implemented by this access methods
are:
READBYTES - Read a specified byte string
MODIFYBYTES - Change a specified byte string
APPENDBYTES - Append a byte string to the end of
the file.
4.2.2.1.5.6.2 I̲n̲d̲e̲x̲e̲d̲ ̲S̲e̲q̲u̲e̲n̲t̲i̲a̲l̲ ̲A̲c̲c̲e̲s̲s̲
CRAM is a multi-level-index indexed sequential file
access method. It features random or sequential (forward
or reverse) access to records of 0 to n bytes, n depending
on the selected block size, based on keys of 0-126
bytes. The collating sequence is using the binary value
of the bytes so e.g. character strings are sorted alphabetically.
CRAM is working on normal contiguous FMS files which
are initialized for CRAM use by means of a special
CRAM operation.
The CRAM updating philosophy is based on the execution
of a batch of related updatings, which all together
forms a consistent status change of the CRAM file,
being physically updated as a single update by means
of a LOCK operation. That is, after such a batch of
updates, all these updated may either be forgotten
(by means of the FORGET operation) or locked (by means
of the LOCK OPERATION). Both operations are performed
without critical regions, i.e. without periods of CRAM
data base inconsistency.
For convenience, CRAM supports subdivision of the CRAM
file in up to 255 subfiles, each identified by a subfile
identifier of 0-126 byte (as a key).
CRAM keeps track of the different versions of the CRAM
data base by means of a 32 bit version number, which
is incremented every time CRAMNEWLOCK (the locking
operation) is called. This version number can only
be changed by CRAMNEWLOCK (and CRAMINIT), but if the
user intends to use it for some sort of unique update
version stamping, it is delivered by the operations
CRAMNEWOPEN, CRAMNEWLOCK, CRAMFORGET and CRAMNEWVERSION.
4.2.2.1.6 M̲a̲g̲n̲e̲t̲i̲c̲ ̲T̲a̲p̲e̲ ̲F̲i̲l̲e̲ ̲M̲a̲n̲a̲g̲e̲m̲e̲n̲t̲ ̲S̲y̲s̲t̲e̲m̲
The Magnetic Tape File Management System (MTFMS) is
responsible for storing and retrieving information
on megnetic tapes. It is able to handle one magnetic
tape controller with a maximum of 8 tape transports
in daisy-chain. The driver is logically split into
3 parts:
- I/O-SYSTEM interface
- Main Processing
- Magnetic tape controller interface
Commands for the MTFMS are received by the I/O-System
interface while the controller interface implements
a number of (low level) commands for handling a tape
transport.
Symbolic volume names and file names are implemented
through use of label records which comply with the
ISO 1001 standard.
The functions of the file system can be separated into
four groups:
- Device functions
- Volume functions
- File functions
- Record functions
4.2.2.1.6.1 D̲e̲v̲i̲c̲e̲ ̲f̲u̲n̲c̲t̲i̲o̲n̲s̲
The following functions are defined:
- Assign a given name to a given unit of the
controller.
- Deassign a given device.
4.2.2.1.6.2 V̲o̲l̲u̲m̲e̲ ̲f̲u̲n̲c̲t̲i̲o̲n̲s̲
- Initiate the tape on a given device assigning a
name to it by writing a volume label.
- Mount a given volume on a given device.
- Dismount a given volume.
- Rewind a given volume.
4.2.2.1.6.3 F̲i̲l̲e̲ ̲f̲u̲n̲c̲t̲i̲o̲n̲s̲
- Create a file on a given volume. The following
information must be supplied by the caller and
will be written onto the tape in a file header
label records:
- File name
- Fixed/variable length record specification
- Record size.
The file is opened for output and the given volume
is reserved for the caller.
- Find a file with a given name on a given volume.
The file is opened for input and the given volume
is reserved.
- Skip a given number of files (backwards or forwards)
on a given volume. The file at the resulting tape
position is opened for input and the volume is
reserved.
- Get information about the currently open file on
a given volume. Information like file sequence
number, record size and type (fixed/variable length)
can be retrieved.
- Close currently open file on a given volume. Volume
reservation is released.
4.2.2.1.6.4 R̲e̲c̲o̲r̲d̲ ̲f̲u̲n̲c̲t̲i̲o̲n̲s̲
- Skip a given number of records (forwards or backwards)
in a given file.
- Read a record in a given file.
- Write a record in a given file. The MTFMS performs
recovery from writing errors by
- backspacing over the record in error
- erasing a fixed length of about 3.7 inches
(thus increasing the record gap).
- attempting the writing once more.
This procedure will be repeated maximally 10 times.
4.2.2.1.7 T̲e̲r̲m̲i̲n̲a̲l̲ ̲M̲a̲n̲a̲g̲e̲m̲e̲n̲t̲ ̲S̲y̲s̲t̲e̲m̲ ̲
The TMS is a service process which manages devices
characterized by serial blockwise access. Examples
of such devices are:
- interactive terminals (screen or hardcopy)
- data communication equipment (modems)
- line printers
- card readers
In the following, the phrase "terminal" is used as
a common term for any device of this category.
Terminals may be attached to LTUs, LTUXs (via TDX)
and parallel interfaces.
The TMS performs the following main functions:
- terminal related security validation
- access control for terminals
- collecting of statistical information
- management of terminals
- transfer of I/O data between terminal device
handlers and user processes.
The following subsections define:
- transfer of I/O data
- user handling
- hardware categories
4.2.2.1.7.1 T̲r̲a̲n̲s̲f̲e̲r̲ ̲o̲f̲ ̲I̲/̲O̲ ̲D̲a̲t̲a̲
The TMS enables user processes to perform I/O communication
with terminals.
The I/O communication can be performed in two modes:
file mode and communication mode.
4.2.2.1.7.1.1 F̲i̲l̲e̲ ̲M̲o̲d̲e̲
In this mode I/O to terminals is identical to I/O to
backing store files from the point of view of the user
process.
The same IOS basic procedures are used (appendbytes,
modifybytes, readbytes) and direct as well as stream
I/O can be used.
This mode provides the greatest flexibility for the
user process. This flexibility is obtained at the expense
of an additional overhead, as all I/O requests from
the user process will have to pass the TMS.
File mode I/O is aimed at terminals which will be connected
to varying processes with different security profiles.
The terminals in question will normally be local or
remote interactive hardcopy or screen terminals.
4.2.2.1.7.1.2 C̲o̲m̲m̲u̲n̲i̲c̲a̲t̲i̲o̲n̲ ̲M̲o̲d̲e̲
In this mode I/O requests from the user process are
sent directly to the terminal handler. The I/O interface
between the user process and the terminal device handler
is that of the BTS and therefore inherently different
from backing store I/O.
Communication mode I/O is aimed at - but not limited
to - terminals which are connected to a single user
process throughout its lifetime.
The terminals in question are primarily communication
lines like e.g. trunk lines in a message swtiching
network.
4.2.2.1.7.2 U̲s̲e̲r̲ ̲H̲a̲n̲d̲l̲i̲n̲g̲
Before a user process can make use of the TMS functions,
it must be logged on to the TMS by means of th Useron
command. This command must be invoked by a process
which is already known by the TMS, either through another
Useron command or because it is the parent process
for the TMS.
In the Useron command the calling process grants some
of its TMS resources to the process which is logged
on to the TMS in the Useron command.
When a user process seizes to use the TMS, its TMS
resources must be released by a call of Useroff.
4.2.2.1.7.3 H̲a̲r̲d̲w̲a̲r̲e̲ ̲C̲a̲t̲e̲g̲o̲r̲i̲e̲s̲
The TMS recognizes the following categories of equipment:
- T̲e̲r̲m̲i̲n̲a̲l̲ ̲C̲o̲n̲t̲r̲o̲l̲l̲e̲r̲ which is a line controller
interfacing one or more lines.
- L̲i̲n̲e̲, which is a group of physical signals
capable of sustaining one simplex or duplex
data stream.
- U̲n̲i̲t̲, which is a terminal device connected
to a line.
If more than one unit is connected to a given line,
the line is called multiplexed line.
4.2.2.1.7.3.1 T̲e̲r̲m̲i̲n̲a̲l̲ ̲C̲o̲n̲t̲r̲o̲l̲l̲e̲r̲s̲
Terminal controllers may dynamically be assigned and
deassigned by the parent process for the TMS.
A controller can either be assigned as an active or
as a stand-by controller.
A stand-by controller is a device which normally is
not active, but which may take over in case of a failure
in an active controller.
When an active controller is assigned for which a stand-by
is available, this must be defined in the assignment
command.
The process which assigned a controller is its initial
owner.
Ownership of a controller may be transfered to another
user process which is logged on to the TMS.
When a controller is assigned, the TMS creates a corresponding
device handler.
4.2.2.1.7.3.2 L̲i̲n̲e̲s̲
The owner of a controller may assign lines to the controller.
When a line is assigned the TMS calls the device handler
for the controller to that effect.
4.2.2.1.7.3.3 Un̲i̲t̲s̲
The owner of a controller with lines assigned to it
may create units on the lines.
Units can be created for file mode I/O or communication
mode I/O.
A unit created for file I/O may be a multiple or single
access unit.
Single access units can only be accessed by the owner
whereas multiple access units may be accessed by a
number of user processes.
When the owner creates a unit, an access path to the
unit is established. The owner may from now on access
the unit by the IOS functions readbytes for input -
and appendbytes, and modifybytes for output.
Other users may obtain access to a multiple access
unit in different ways as described in the following.
The creator of a unit may offer it to another user
by means of the TMS OFFER function. The user to which
the unit is offered obtains access to the unit by the
ACCEPT function.
The creator of a unit may define a symbolic name -
a unit name - for the unit. A unit name is syntactically
identical to an FMS file name.
Other users may obtain access to the named unit by
the LOOKUP ̲UNIT command which corresponds to the FMS
commands getroot, lookup and descent.
4.2.2.1.8 S̲y̲s̲t̲e̲m̲ ̲I̲n̲i̲t̲i̲a̲l̲i̲z̲a̲t̲i̲o̲n̲
When a CR80 memory mapped PU is master cleared, a boot
strap loader is given control.
The boot strap loader is contained in a programmed
read-only memory which is part of the MAP module. Having
initialized the translation tables of the MAP module,
the boot strap loader is able to fetch a system load
module from a disk connected to the PU.
An initialization module which is part of the load
module initalizes the DAMOS kernel and the DAMOS Root
process.
The Root process possesses all the PU resources. Root
creates and intializes a File Management System, a
Terminal Management System and a Highlevel Operating
System.
4.2.2.1.9 H̲i̲g̲h̲l̲e̲v̲e̲l̲ ̲O̲p̲e̲r̲a̲t̲i̲n̲g̲ ̲S̲y̲s̲t̲e̲m̲ ̲(̲H̲I̲O̲S̲)̲
HIOS is an operating system, which provides the online
user interface for interactive and batch processing
on the CR80 computer.
The functions performed by HIOS are the following:
- define system volume and directory
- define system device(s)
- assign/deassign terminal device(s)
- create/delete terminal subdevices
- assign/deassign of disk
- reserve/release of disk
- mount/dismount of volume
- update bitmap and basic file directory
- display name of user directory
- change user directory
- listing of current status of system
- redefine current input/output
- reopen original outputfile
- maintain a user catalog
- redefine filesystem dependant I/O resources
- control online log facility
- broadcast messages between terminals
- maintain a hotnews facility
- maintain a number of batch queues
- define spool files for later output
- login/logout of terminals
- load of program
- execute task
- stop and start task
- remove task
- display current date and time
- submit batch task
HIOS is activated by the ROOT process when the system
is bootloaded. After a short initialization phase the
production phase can be entered.
In the production phase, two kinds of users can log
in on the system:
- privileged users
- non privileged users
The privilege of the user is checked at login-time
by means of the user catalog, and the privilege determines
which functions the user can execute.
All functions contained in HIOS are executed under
the constraints of the security access control mechanisms
implemented in the DAMOS kernel. This means that unauthorized
acces to any DAMOS, FMS or TMS object is impossible.
HIOS contains facilities for logging and timetagging
of all user commands and related system responses.
These facilities are used for:
- system recovery
- system performance
and load monitoring
- user assistance
4.2.2.1.10 S̲y̲s̲t̲e̲m̲ ̲G̲e̲n̲e̲r̲a̲t̲i̲o̲n̲ ̲S̲o̲f̲t̲w̲a̲r̲e̲
The utility SYSGEN-EDIT generates ogject files - based
upon a set of directives, a system source, and command
files - for subsequent compiling and linking. A BINDER
then binds the system object together with the application
object based upon a command file from SYSGEN-EDIT.
All the external references of the object modules are
resolved in the Binder output, which is a load module
ready for execution. The BINDER produces a listing
giving memory layout, module size, etc.
4.2.2.1.11 D̲i̲a̲g̲n̲o̲s̲t̲i̲c̲ ̲P̲r̲o̲g̲r̲a̲m̲s̲
The Maintenance and Diagnostic (M&D) package is a
collection of standard test programs which is used
to verify proper operation of the CR80 system and to
detect and isolate faults to replaceable modules.
4.2.2.1.11.1 O̲f̲f̲-̲l̲i̲n̲e̲ ̲D̲i̲a̲g̲n̲o̲s̲t̲i̲c̲ ̲P̲r̲o̲g̲r̲a̲m̲s̲
The off-line M&D software package contains the following
programs:
- CPU Test Program
- CPU CACHE Test Program
- Memory Map Test Program
- RAM Test Program
- PROM Test Program
- Supra Bus I/F Test Program
- CIA Test Program
- LTU Test Program
- Disk System Test Program
- Magtape System Test Program
- Floppy Disk Test Program
- TDX-HOST I/F Test Program
- Card Reader and Line Printer Test Program
4.2.2.1.11.2 O̲n̲-̲L̲i̲n̲e̲ ̲D̲i̲a̲g̲n̲o̲s̲t̲i̲c̲ ̲P̲r̲o̲g̲r̲a̲m̲s̲
On-line Diagnostic programs will execute periodically
as part of the exchange survailance system. On-line
diagnostics consists of a mixture of hardware module
built-in test and reporting, and diagnostic software
routines. The following on-line diagnostic capability
exists:
- CPU-CACHE diagnostic
- RAM test
- PROM test
- MAP/MIA test
- STI test
- Disk Controller/DCA test
- Tape Controller/TCA test
- LTU/LIA test
On-line diagnostics will report errors to higher level
processing to take recovery/switchover decision in
the case of failures.
4.2.2.3 L̲a̲n̲g̲u̲a̲g̲e̲ ̲P̲r̲o̲c̲e̲s̲s̲o̲r̲s̲
The CR80 language processors include the following:
- CR80 COBOL is an efficient industry-compatible
two-pass compiler, fulfilling American National
Standard X3.23-1974 level 1 as well as most of
the level 2 features.
- PASCAL is a high level block-orientated language
that offers structured and complex data and enforces
well structured programs. The CR80 implementation
is based on standard Pascal as defined by Kathleen
Jensen & Niklaus Wirth, with only minor deviations.
The CR80 implementation provides for bit mask
operations in addition to standard PASCAL data
structures. Furthermore, the CR80 implementation
provides the following powerful additions:
- Compile time option enables merging assembly
object directly into the Pascal module.
- Overlay technique is supported.
- Built-in Trace of program execution may optionally
be switched in/out for debugging purposes.
- Sequential and random file access is available
from run time library.
- SWELL 80 is a S̲oftW̲are E̲ngineering L̲ow level
L̲anguage for the CR80 minicomputer. SWELL
offers most of the data and program structures
of PASCAL, and, by enabling register control,
is without the efficiency penalties experienced
in true high-level languages. The main purpose
of SWELL is to combine efficient program execution
with efficient program development and maintenance.
- The Assembler is a machine-orientated language
for the CR80. The language has a direct correspondence
between instructions read and code generated.
- ADA compiler. A project has been launched for
implementation of the new DOD standard programming
language ADA on the CR80 machine. The project
is planned for completion early 1984 and includes
development of an ADA compiler hosted on and targeted
for the CR80 as well as of an ADA programming support
environment. The programming support environment
is based on the Stoneman report.…86…1 …02… …02…
…02… …02…
4.2.2.4 G̲e̲n̲e̲r̲a̲l̲ ̲U̲t̲i̲l̲i̲t̲i̲e̲s̲
The CR80 utility software package includes:
- Editor
- File Copy, including media conversion
- File Compare
- File Merge
- Interactive Patch Facility
- Memory Dump
- On-line Test Output Facility (Trace)
- On-line Interactive Debugger
- File Maintenance Program
- Magnetic Tape Maintenance Program
4.2.2.10 S̲t̲a̲t̲i̲s̲t̲i̲c̲s̲
The Statistics Package will provide capabilities for
the users to interactivity perform basic mathematical
operations and statistical analysis on available data.
Available mathematical operations are:
- additions, subtractions
- multiplication, division
- square, squareroot
- percentage
On specified sets of data calculation of the following
statistical measures are provided:
- median
- mode
- geometric mean
- standard deviation
- regression coefficient
- correlation coefficient
- confidence coefficient
4.2.2.11 O̲p̲t̲i̲c̲a̲l̲ ̲C̲h̲a̲r̲a̲c̲t̲e̲r̲ ̲R̲e̲a̲d̲e̲r̲
The OCR software package will provide a user interface
to the OCR with the following capabilities:
- specify input format
characteristics
- specify file and directory
for OCR output
- correct changes flagged by the OCR
