top - download
⟦23e4bc916⟧ Wang Wps File
Length: 66675 (0x10473)
Types: Wang Wps File
Notes: AIR CANADA PROPOSAL
Names: »2087A «
Derivation
└─⟦378e273b7⟧ Bits:30006252 8" Wang WCS floppy, CR 0096K
└─ ⟦this⟧ »2087A «
WangText
<…07…;…0b…;
:…08…:…0c…: :…07…9…0e…9
8…09…8…01…7…0a…7…02…7…06…7…07…6…0a…6…01…6…02…6…07…5…0f…5…06…4…0d…4…06……86…1
…02… …02…
…02… …02…
CHAPTER
6
Page
#
DOCUMENT
III
TECHNICAL
PROPOSAL
Apr.
29, 1982
6. S̲O̲F̲T̲W̲A̲R̲E̲ ̲C̲H̲A̲R̲A̲C̲T̲E̲R̲I̲S̲T̲I̲C̲S̲
This section attempts to present a comprehensive view
of the software structure supporting the proposed ACDN.
To assist in understanding the implied software linkages,
certain typical and relevant data flow descriptions
are presented.
The primary design objectives for the networking software
provided by Christian Rovsing has been:
- a realistic adherence to the proposed architecture
for Open Systems Interconnection
- a well conceived strategy to exploit the inherent
architectural strength of the CR80 environment.
(this is illustrated by software components BTS
& BDS)
- exploitation of the program development environment
supported by PASCAL.
Over and above these considerations, certain aspects
of software structuring have been adopted that facilitates
understanding in terms of mainframe communication architecture
like IBM's SNA and Univac's DCA.
6.1 I̲n̲t̲r̲o̲d̲u̲c̲t̲i̲o̲n̲
The software proposed for the ACDN is anchored on existing
networking solutions from Christian Rovsing,and is
supported by the system software for the CR80,namely
DAMOS.
Section 6.2 introduces the functions and facilities
of DAMOS.
Section 6.3 focuses on a key internal transport mechanisms
designated as Basic Transport Service (BTS) and Basic
Datagram Service (BDS) that is a part of the DAMOS
Kernel.
Section 6.4 introduces data flow aspects and table
structures. This section provides a first level bridge
between concepts introduced in Chapter 3 and functional
software description that follows in 6.5 to 6.11.
Section 6.5 to 6.11 describes the software complexion
and functions of NSS, TAS, HAS, interfaces to other
networks, NCS and Network Management Subsystem.
Section 6.12 presents the Electronic Mail System oriented
software capabilities.
6.2 C̲R̲8̲0̲ ̲S̲t̲a̲n̲d̲a̲r̲d̲ ̲S̲y̲s̲t̲e̲m̲ ̲S̲o̲f̲t̲w̲a̲r̲e̲
o CR80 Standard System Software is divided into
- operational software
- support software
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 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:
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
DAMOS
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
OPERATIONAL SUPPORT
SOFTWARE SOFTWARE
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
̲ ̲
- Kernel
- resource management - terminal operating system
- directory functions - language processors
- process management - system generation software
- memory management - debugging facilities
- process communica- - utilities
tion
- device management - maintenance and diagnostic
programs
- device handling
- error processing
- real time clock
- PU management
- PU service
- transfer module
- Basic transport service
- Input/output system
- File Management
- Magtape Management
- Terminal Management
- Initialization
Fig. III 6.2-1…01…DAMOS Software Overview
- assembler
- SWELL, the CR80 system programing language
- Pascal
- Cobol
The following languages are announced:
- Fortran 77
- Ada
The DAMOS standard operational software is described
in this section. 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
- terminal operating system
- programing languages
- system generation software
- debugging software
- utilities
- maintenance and diagnostics programs
is defined in section 6.2.6.
6.2.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 high level operating
system which intially possesses all resources in its
PU.
6.2.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.
6.2.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
- PU Service Module,
which provides service functions for remote PUs
- Transfer Module
for a hardware based transfer of data in a PU and
between PUs
- Basic Transport Service,
which provides a general mechanism 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
- Basic transport service
6.2.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.
6.2.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.
6.2.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.
6.2.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.
6.2.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.
6.2.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.
6.2.3.7 B̲A̲S̲I̲C̲ ̲T̲r̲a̲n̲s̲p̲o̲r̲t̲ ̲S̲e̲r̲v̲i̲c̲e̲
The Basic Transport Service (BTS) offers DAMOS processes
and device handlers the possibility to communicate
with other remote or local processes and device handlers.
Processes and device handlers - in the following called
Service Users (SU) - may be addressed indirectly via
ports.
A service user can dynamically be tied to a port.
When a service user wants to communicate with another
service user, the former service user requests a connection
to be established between (one of) his own port(s)
and a prt to which the remote service user is tied.
Once such a connection has been established, the two
service users may exchange data and control information
across the connection.
The figure overleaf depicts the possible connections
within a multiple PU node.
(skema med tekst "Gateway process, not part of BTS)
6.2.3.7.1 S̲e̲r̲v̲i̲c̲e̲ ̲T̲y̲p̲e̲s̲
The BTS offers two different types of service:
- stream service and
- message service
In the first type of service data flows as a logically
continuous stream from one SU to the other. The blocking
of data into buffers performed by the transmitting
SU is not seen by the receiving SU.
In the second type of service the buffers are treated
as semantic entities and transmitted as such. I.e.,
a homomorph correspondance between transmit and receive
buffers is enforced.
6.2.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.
Skema under afsnit 6.2.5 DAMOS Input/Output.
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.
6.2.4.1 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
6.2.4.1.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.
6.2.4.1.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.
6.2.4.1.3 F̲i̲l̲e̲s̲
6.2.4.1.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.
6.2.4.1.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.
6.2.4.1.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)
6.2.4.1.5 D̲i̲s̲k̲ ̲I̲n̲t̲e̲g̲r̲i̲t̲y̲
6.2.4.1.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.
6.2.4.1.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.
6.2.4.1.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.
6.2.4.1.6 A̲c̲c̲e̲s̲s̲ ̲M̲e̲t̲h̲o̲d̲s̲
The file management system implements two access methods
to files:
6.2.4.1.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.
6.2.4.1.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 sequentila 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.
6.2.4.2 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
6.2.4.2.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.
6.2.4.2.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.
6.2.4.2.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.
6.2.4.2.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.
6.2.4.3 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
6.2.4.3.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.
6.2.4.3.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.
6.2.4.3.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.
figur inds`ttes
6.2.4.3.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.
6.2.4.3.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.
6.2.4.3.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.
6.2.4.3.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.
6.2.4.3.3.3 U̲n̲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.
6.2.5 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. The
Root creates and intializes a system File Management
System.
6.2.6 S̲t̲a̲n̲d̲a̲r̲d̲ ̲S̲u̲p̲p̲o̲r̲t̲ ̲S̲o̲f̲t̲w̲a̲r̲e̲
O The support software assists in software development
and in hardware maintenance and diagnostics.
The support software consists of:
- terminal operating system
- language processors
- system generation software
- debugging software
- utilities
- maintenance and diagnostics programs
6.2.6.1 T̲e̲r̲m̲i̲n̲a̲l̲ ̲O̲p̲e̲r̲a̲t̲i̲n̲g̲ ̲S̲y̲s̲t̲e̲m̲ ̲(̲T̲O̲S̲)̲
TOS is an operating system which supports interactive
terminal users in a program development environment.
The functions performed by TOS are invoked by two types
of requests:
Operator commands, which are messages typed at terminals
and sent to TOS. The functions which may be performed
in response to these requests are:
- assign/deassign disk devices
- mount/dismount volumes on disk drives
- include terminals in the system/remove terminals
from the system
- log on to the system
- remove processes from the system
- broadcast messages to terminals
- manipulate a "news" message facility
- present status information
- run a task
- close the system
Programmed requests are sent from processes to TOS.
The functions which may be performed in response to
these requests are:
- allocate resources (memory) for a task, load a
program, and create a process to execute the program
- start a process
- stop a process
- restart a process
- logout from the system
- reserve a print queue file semaphore
- release a print queue file semaphore
- start a printer task
6.2.6.2 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:
- 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.
- The CR80 COBOL compiler 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.
- 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 in 1983 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.
6.2.6.3 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 object 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.
6.2.6.4 D̲e̲b̲u̲g̲g̲i̲n̲g̲ ̲S̲o̲f̲t̲w̲a̲r̲e̲
The software debugging facilities include:
- Test Output Facility
- On-Line Interactive Debugger
6.2.6.5 U̲t̲i̲l̲i̲t̲i̲e̲s̲
The CR80 utility software package will include:
- Editor
- File Copy and Compare
- File Merge
- Interactive Proper Patch Facility
- File Maintenance Program
6.2.7 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.
6.2.7.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 May 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
6.2.7.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:
- CPO-CACHE diagnostic
- RAM test
- PROM test
- MAP/MIO 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.
6.2.6 S̲t̲a̲n̲d̲a̲r̲d̲ ̲S̲u̲p̲p̲o̲r̲t̲ ̲S̲o̲f̲t̲w̲a̲r̲e̲
O The support software assists in software development
and in hardware maintenance and diagnostics.
The support software consists of:
- terminal operating system
- language processors
- system generation software
- debugging software
- utilities
- maintenance and diagnostics programs
6.2.6.1 T̲e̲r̲m̲i̲n̲a̲l̲ ̲O̲p̲e̲r̲a̲t̲i̲n̲g̲ ̲S̲y̲s̲t̲e̲m̲ ̲(̲T̲O̲S̲)̲
TOS is an operating system which supports interactive
terminal users in a program development environment.
The functions performed by TOS are invoked by two types
of requests:
Operator commands, which are messages typed at terminals
and sent to TOS. The functions which may be performed
in response to these requests are:
- assign/deassign disk devices
- mount/dismount volumes on disk drives
- include terminals in the system/remove terminals
from the system
- log on to the system
- remove processes from the system
- broadcast messages to terminals
- manipulate a "news" message facility
- present status information
- run a task
- close the system
Programmed requests are sent from processes to TOS.
The functions which may be performed in response to
these requests are:
- allocate resources (memory) for a task, load a
program, and create a process to execute the program
- start a process
- stop a process
- restart a process
- logout from the system
- reserve a print queue file semaphore
- release a print queue file semaphore
- start a printer task
6.2.6.2 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:
- 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.
- The CR80 COBOL compiler 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.
- 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…
6.2.6.3 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 object 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.
6.2.6.4 D̲e̲b̲u̲g̲g̲i̲n̲g̲ ̲S̲o̲f̲t̲w̲a̲r̲e̲
The software debugging facilities include:
- Test Output Facility
- On-Line Interactive Debugger
6.2.6.5 U̲t̲i̲l̲i̲t̲i̲e̲s̲
The CR80 utility software package will include:
- Editor
- File Copy and Compare
- File Merge
- Interactive Proper Patch Facility
- File Maintenance Program
6.2.6.6 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.
6.2.6.6.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
6.2.6.6.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.
6.3 T̲r̲a̲n̲s̲p̲o̲r̲t̲ ̲M̲e̲c̲h̲a̲n̲i̲s̲m̲s
6.3.1 B̲T̲S̲ ̲E̲n̲v̲i̲r̲o̲n̲m̲e̲n̲t̲
Basic Transport Service (BTS) is a module within the
Christian Rovsing operating system DAMOS (Fig. III
6.3.1.1).
It 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.
Fig. III 6.3.1-1…01…BTS Environment
S̲w̲i̲t̲c̲h̲i̲n̲g̲
It is also possible for device handlers to use BTS.
In this way, data may be switched through an intermediate
node, directly from one communication device to another
(Fig. III 6.3.1-2)
Fig. III 6.3.1-2…01…Switching
Fig. III 6.3.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.
Fig. III 6.3.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.
Fig. III 6.3.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.
Fig. III 6.3.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.
29 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.
6.3.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.
Fig. III 6.3.2-1…01…Process Logical Data Space
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.
6.4 D̲a̲t̲a̲ ̲F̲l̲o̲w̲ ̲a̲n̲d̲ ̲N̲e̲t̲w̲o̲r̲k̲ ̲T̲a̲b̲l̲e̲s̲
The scope of this section is to introduce typical data
flows in the ACDN and to present the generic table
structures incorporated in the NCC, NMH and the nodes.
The primary objective is to illustrate the linkages
between session identifiers, transport service identifiers,
virtual connection identifiers and the end users.
The description presented herein is based on a current
implementation for an IBM and Univac host environment.
6.4.1 N̲e̲t̲w̲o̲r̲k̲ ̲T̲a̲b̲l̲e̲s̲
Tables reflecting network configuration and status
are maintained in NMH, NCC and NODES.
Global Network Tables are located in the NMH and the
NCC while Local Network Tables are located in the NODES.
6.4.1.1 G̲l̲o̲b̲a̲l̲ ̲N̲e̲t̲w̲o̲r̲k̲ ̲T̲a̲b̲l̲e̲s̲
The Global Network Tables (GNT in NCC) reflect the
entire network configuration and status.
An entry in the Main Table always corresponds to an
entry in the Quick Reference Table while the entries
in the Session Table are network usage dependent.
NCC initialization routines or NCC operators create
entries in the Main Table by using an identifier transformation
algorithm to find empty table elements.
The entries are created within node specific boundaries
and the corresponding elements in the Quick Reference
Table are also found within node specific boundaries
where the first free entry is chosen.
Global Identifiers (q), which are used to locate elements
in all Network Tables in the network, simply are the
elements numbers in the Quick Reference Table.
Global Data is pointed to by the pointer (d) but the
data entries are not shown.
6.4.1.2 L̲o̲c̲a̲l̲ ̲N̲e̲t̲w̲o̲r̲k̲ ̲T̲a̲b̲l̲e̲s̲
The Local Network Tables (NT in NODE) reflect configuration
and status partially with respect to number of units
and amount of information.
Entries in the Local Main Table are created on basis
of messages from NCC. The Global Identifiers (which
are within a node specific range) are used as Quick
Reference to the obligate corresponding Quick Reference
Table elements. These elements are made pointing to
the created Main Table elements.
HOST and TERMINAL elements may point to Session Table
elements or linked lists of Session Table elements
(Session Control Blocks).
TERMINAL elements may point (t) to Transaction elements
which are not shown.
6.4.2 N̲e̲t̲w̲o̲r̲k̲ ̲T̲a̲b̲l̲e̲s̲ ̲M̲a̲i̲n̲t̲e̲n̲a̲n̲c̲e̲ ̲a̲n̲d̲ ̲U̲s̲a̲g̲e̲
In the NCC the Network Tables are maintained by Network
Configuration and used by both User and Session Services.
In the NODE the tables are maintained by NODE Services
respectively and used by Physical and Logical Services
and by Session Managers.
The host related NODE tables mainly reflect the hosts'
view of the network, while the terminal related NODE
tables mainly reflect the real network, so the LINE
and CLUSTER elements in a given sub-tree in the host
related part may be different from the terminal related
LINE and CLUSTER elements both with respect to information
held and with respect to number of elements.
The number of NODE and TERMINAL elements in the host
related part are equal to the number of NODEs and TERMINALs
in the network.
As a HOST can maintained sessions with many TERMINALS
in the network a HOST element is provided with a pointer
to a linked list of Session Table elements (Session
Control Blocks).
As a TERMINAL can have several sessions involved in
a transaction the TERMINAL element has a pointer to
both a linked list of Session Table elements and a
Transaction element.
The Session Table and Transaction Table are both maintained
by Logical Services and Session Managers.
NETWORK FUNCTIONAL OVERVIEW, NETWORK DATA FLOW EXAMPLES
tegning
tegning
6.4.3 S̲e̲s̲s̲i̲o̲n̲ ̲D̲a̲t̲a̲ ̲F̲l̲o̲w̲
This section describes briefly how a session path between
two end users is established, and of which entities
it is composed.
The framework within which the description is held
is shown below. Furhter details on flow are provided
as part of section 6.7, Host Access Software.
tegning
Legend:
PN : Datagram packet network
TS : Transport Station
UDS: User Data Session
The internal structure of User Data Session (UDS) is
a task structure:
tegning
where
ASI: (Host) Application Session Interface task
CAS: Connection and Allocation Services task
EM : (Terminal) Emulator task
TSU: Transport Station User task
The ASI and EM are Virtual Protocol Units (VPUs)
CAS exists in one incarnation in each UDS and is created
at initialisation time. Having been created CAS connects
to TS.
The remaining tasks exist in principal in one incarnation
per sesson. These tasks are dhnamically created/deleted
during session establishment/terminaton.
Three cases of session path establishment are cover.
1: Terminal initiated session to an Univac host application.
2: Terminal initiated session to an IBM host application.
3: IBM host application initiated session to a termina.
In each case, a path like the one sketched below is
established.
PAS P<: spec. tegn i sidste afsnit af tekst
The resources allocated to a session are composed of:
- the session paths
- NCC session services
- NODE session manager (at host)
- NODE session manager (at terminal)
Session control blocks are used for accounting-control
and recovery purposes. Each triple is given an inernal
global identifier thereby providing a linkage between
the control blocks.
Regarding the established session path, the entities
of which it is composed may be depicted as shown overleaf.
The symbol ?? and ?? each denote a part and its associated
control block. Two associated parts make a connection.
The entity connecting TS and TS is a Virtual Connection.
Thus the resources which are allocated to a session
path are divided into:
- task instances (ASI, TSU, TSU, EM)
- connections, each composed of two associated parts
In IBM and UNIVAC environments no global address defines
the host application and the terminal. The session
path is identified by a series of relative addresses.
On outbound flow - i.e. the flow from host application
to terminal - the driver maps the destination address
into a part to ASI, thereby obtaining a handle to the
session path.
On inbound flow - i.e. the flow from terminal to host
- the driver maps the terminal identification into
a part to EM thereby obtaining a handle to the session
path.
The ASI and the EM communicate with each other by using
the services provided by the transport network. Thus,
these entities identify each other in the address space
of the CRNET transport network.
Below, we outline the various phases in establishing
a session path.
6.4.3.1 T̲e̲r̲m̲i̲n̲a̲l̲ ̲u̲s̲e̲r̲ ̲l̲o̲g̲s̲ ̲o̲n̲
1. User logs on at terminal.
2. The terminal network driver does not have any part
to UDS for the terminal, hence the logon message
is routed to node services.
3. Node TAS service does some preliminary checks,
removes any device dependencies from the logon
message, and passes the logon on to User Services
in NCC.
4. User Service checks user profile, passwords, etc.,
and sends the logon to Node HAS services.
5. In case the user logged on to a Univac host application,
the session path is established at this time.
In case the user logged on to an IBM host application,
the establishmend of the session path is triggered
by the arrival of a BIND from the host applicaton.
6. The Univac case is covered at first.
6.4.3.2 T̲e̲r̲m̲i̲n̲a̲l̲ ̲U̲s̲e̲r̲ ̲l̲o̲g̲s̲ ̲o̲n̲ ̲t̲o̲ ̲U̲n̲i̲v̲a̲c̲ ̲h̲o̲s̲t̲ ̲a̲p̲p̲l̲i̲c̲a̲t̲i̲o̲n̲
tegning
1. Node HAS Service passes the logon to Node session
manager.
2. The session manager asks CAS in UDS to create a
session path.
3. CAS creates an ASI - and a TSU task incarnation.
4. ASI connects to driver and afterwards to TSU tasks.
5. The TSU task connects to TS and asks TS in Node
to connect Node HAS to connect to TS destination
node.
6. TSU in host Node sends a command to CAS in UDS
in terminal node. This command is sent from TS-CAS
connection established during system initialisation.
7. CAS in terminal node creates an EM - and a TSU
task incarnation.
8. EM connects to terminal network driver and afterwards
to TSU task.
9. TSU task connects to TS in node.
10. As session path set up complete message is
sent from CAS in node UDS via CAS in host node
UDS to host node session manager.
11. Host node session manager updates node session
manager and NCC session services.
12. Host node session manager releases the logon
and sends it to the host via CAS, ASI and the
driver.
6.4.3.3 T̲e̲r̲m̲i̲n̲a̲l̲ ̲u̲s̲e̲r̲ ̲l̲o̲g̲s̲ ̲o̲n̲ ̲t̲o̲ ̲I̲B̲M̲ ̲h̲o̲s̲t̲ ̲a̲p̲p̲l̲i̲c̲a̲t̲i̲o̲n̲
1. As in the Univac case, the logon eventually reaches
HAS services.
2. The logon is sent to the host.
3. The host application sends a BIND, which is received
by the driver. The driver does not have any path
to UDS for this BIND, hence it is routed to trip
services.
4. Now the situation is almost similar to the Univac
case. When a session path has been established,
the HAS session manager releass the BIND and sends
it to ASI via CAS. From ASI the BIND is sent along
the session path to its destination, and EM in
the terminal node.
