top - download
⟦b95b0be39⟧ Wang Wps File
Length: 130278 (0x1fce6)
Types: Wang Wps File
Notes: AIR CANADA PROPOSAL
Names: »2054A «
Derivation
└─⟦45f76d1eb⟧ Bits:30006260 8" Wang WCS floppy, CR 1005V
└─ ⟦this⟧ »2054A «
WangText
B…00……00……00……00…=…02……00……00…=
=…07…<…0b…<
;…08…;…0c…; ;…07…:…0e…:
9…09…9…01…8…0a…8…02…8…06…8…07…7…0a…7…01…7…02…7…07…6…0f…6…06…5…0d…5…06…4…0d…4
3…08…3…09…3…0e…3 2…08…2…0b…2…02…1…0b…1…0f…1…05…0…0c…0…05…/…09…/…0f…/…02…/ /…07….…0b….…0f….
-…0a…-…0b…-…00…-…07……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.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.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.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:
- 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.Connection
Establishment
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 (NT 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.
6.5 N̲o̲d̲a̲l̲ ̲S̲w̲i̲t̲c̲h̲ ̲S̲o̲f̲t̲w̲a̲r̲e̲
The ACON software is built using layered concepts.
The NSS constitutes the lowest three environments:
CUE, DTrE and DLE. Each "horizontal" layer consists
of software schedulable tasks which provide similar
services. The packaging of these tasks is done by "vertical"
partitioning such that a group of tasks providing the
total NSS capability can be included in in functional
CR80-processes.
In the following description, we concentrate on the
functions of the NSS without regard to its packaging.
Figure 6.5-1 illustrates this environment.
6.5.1 C̲o̲m̲m̲u̲n̲i̲c̲a̲t̲i̲o̲n̲ ̲U̲s̲e̲r̲ ̲E̲n̲v̲i̲r̲o̲n̲m̲e̲n̲t̲ ̲(̲C̲U̲E̲)̲
This environment is primarily concerned with providing
an orderly data exchange between two entities in the
higher level software. This orderly exchange is provided
by establishing session-conversations.
This environment is not concerned with the idiosynchrocies
of the individual user. The Network Interface Environment
handles these by providing emulator functions or with
implementation of virtual terminals.
The session-conversations are built on the services
provided by the Data Transmission Environment.
Figure III 6.5-1 …01…Communication Environment
6.5.1.1 S̲e̲s̲s̲i̲o̲n̲-̲C̲o̲n̲v̲e̲r̲s̲a̲t̲i̲o̲n̲ ̲M̲a̲n̲a̲g̲e̲m̲e̲n̲t̲
6.5.1.1.1. S̲e̲s̲s̲i̲o̲n̲-̲C̲o̲n̲v̲e̲r̲s̲a̲t̲i̲o̲n̲ ̲E̲s̲t̲a̲b̲l̲i̲s̲h̲m̲e̲n̲t̲
The purpose of the session-conversation establishment
phase is to tie two Session Service Users (SSU) into
a cooperative relationship. To do this the CUE includes
the means to:
- request a session-conversation to another SSU
- receive a request for session-conversation from
another SSU, which it can accept, reject or negotiate
- be notified of the session-conversation establishment
or the rejection of the request
- enable the two SSUs cooperatively to determine
the values of the session-conversation parameters.
These parameters determine:
- type of service (stream or datagram)
- grade of service (reliability, priority etc.)
- throughput (blocksize, degree of flow control)
6.5.1.1.2 S̲e̲s̲s̲i̲o̲n̲-̲C̲o̲n̲v̲e̲r̲s̲a̲t̲i̲o̲n̲ ̲D̲a̲t̲a̲ ̲T̲r̲a̲n̲s̲f̲e̲r̲
This phase of the interaction serves for a controlled
exchange of data during the lifetime of the conversation.
Local flow control is provided by CUE so as not to
overload the transport network. This is done by limiting
the size of the outbound queue for each conversation.
When CUE detects that the queue length for a particular
conversation exceeds a predetermined number, it indicates
this to the Session Service User. The latter is expected
to limit the generated output if the ordely exchange
is to be maintained.
Other services for recovering from a possible failures
are provided on request.
6.5.1.1.3 S̲e̲s̲s̲i̲o̲n̲-̲C̲o̲n̲v̲e̲r̲s̲a̲t̲i̲o̲n̲ ̲T̲e̲r̲m̲i̲n̲a̲t̲i̲o̲n̲
This allows the SSU to terminate the conversation without
loss of data. Either SSU may at any time request the
forced termination of the conversation, in which case
data may be lost.
The CUE, optionally, gatheres charging data which is
forwarded to the NSE on termination of a conversation.
6.5.2 D̲a̲t̲a̲ ̲T̲r̲a̲n̲s̲m̲i̲s̲s̲i̲o̲n̲ ̲E̲n̲v̲i̲r̲o̲n̲m̲e̲n̲t̲ ̲
This environment provides standard interfaces and services
which form the basic transport facilities in the ACDN.
The Transport Service Users (TSU) get access to this
facilities by acquiring a Transport Access Port (TAP).
The request for a TAP is processed by the Network Services
Environment. Once a TSU has acquired a TAP, it can
communicate with other TSUs and vice versa.
Chapter 6.5.2.2.1 expands on the addressing aspects.
Notice that TSUs may be identified either e̲x̲p̲l̲i̲c̲i̲t̲l̲y̲
or i̲m̲p̲l̲i̲c̲i̲t̲l̲y̲ in the addressing structure. When a C-PORT-NO
is used the TSU is identified implicitly via the TAP
corresponding to the C-PORT-NO. When the generic name
of the TSU is used, the NSE at the destination is requested
to identify the TSU. If the explicitly named TSU is
known to the destination system (confirmed by directory-lookup),
then it, or an incarnation of it, is activated and
informed of the incoming information. The activated
TSU will then respond to the incoming indication of
a session-conversation by contacting the CUE.
6.5.2.1 D̲T̲r̲E̲ ̲S̲e̲r̲v̲i̲c̲e̲s̲
The underlining mechanism by which DTrE communicates
is based on datagram technology.
The higher level software is provided with basically
two types of services. T̲h̲e̲ ̲D̲a̲t̲a̲g̲r̲a̲m̲ ̲S̲e̲r̲v̲i̲c̲e̲ (DGS) is
based directly on the underlining datagram technology.
This provides a vechicle to base higher level transaction
oriented services.
The V̲i̲r̲t̲u̲a̲l̲ ̲T̲r̲a̲n̲s̲p̲o̲r̲t̲ ̲C̲o̲n̲n̲e̲c̲t̲i̲o̲n̲ ̲(̲V̲T̲C̲)̲ service provides
enhanced stream oriented services again based on the
underlining datagram technology. This provides a means
for trasporting bulk data.
Figure III 6.5.2.1-1 illustrates this.
Figure III 6.5.2.1-1…01…DTrE Structure
6.5.2.2 D̲a̲t̲a̲g̲r̲a̲m̲ ̲S̲e̲r̲v̲i̲c̲e̲s̲ ̲(̲D̲G̲S̲)̲
This service provides a one-to-one mapping on the underlining
datagram implementation of the DTrE.
The information entities exchanged within the network
are d̲a̲t̲a̲g̲r̲a̲m̲s̲. A datagram is a data structure of a
defined maximum size consisting of a Datagram Header
(DH) and Datagram Text (DT). The datagram header contains
the source and destination addresses of the datagram.
The datagram text is the actual data to be transported
through the network. This textual data is transparent
to the datagram service.
The DGS only accepts data in the form of Datagram Texts.
Because of the limited size of the datagrams, the service
user is expected to split longer data structures into
a number of DTs. For ACDN a maximum size of 512 bytes
for a DT is suggested. This maximum size will enable
the ACDN to transport the majority of its transactions
in a single datagram.
The DGS provides a fast but not completely reliable
service. If for some reason the datagram cannot be
delivered the transport network will destroy them.
An option is provided whereby the user may request
the delivery confirmation of the datagram. In this
case, the destination DTrE will automatically "echo"
the datagram back to the user - the Datagram Text of
the echo-datagram is shorten to the first ten bytes
of the original datagram. It is expected that the source-user
will have enough information within the echo-datagram-text
to recognize the returned echo-datagram as being the
delivery confirmation on a particular datagram sent
previously.
DGS will provide eight priority levels. The designated
priority is noted in the packet header to ensure that
all transit nodes will respect the priority level of
the datagram. The priority assigned to a datagram affects
the order in which it is transmitted and also the order
in which it is processed in the individual nodes. However,
the algorithms employed ensure that the low priorty
traffic does not get completely blocked.
DGS provides a test mode services. When in this mode,
all datagrams are marked with a user provided mode-indicator.
The interpretation and special processing is in the
users domain.
6.5.2.2.1 A̲d̲d̲r̲e̲s̲s̲i̲n̲g̲ ̲S̲t̲r̲u̲c̲t̲u̲r̲e̲
The transport network of CRNET provides a number of
Transport Access Ports (TAP) through which the network
users can communicate with one another. The addressing
form reflects the heirarchical structure of the topology.
Figure III 6.5.2.2.1-1 illustrate the various address
formats used.
1) C̲C̲-̲f̲o̲r̲m̲a̲t̲: This format is the normal address format
used to identify another C-NET user who is known to
be attached to a specific TAP.
2) C̲N̲-̲f̲o̲r̲m̲a̲t̲: This is an optional address format used
by a C-NET user to identify another C-NET user, who
is known by a generic name but his specific address
(TAP) is unknown to the source user. The format does
not limit the size of this generic name - however,
it is not expected to be greater than 8 bytes.
3) X̲-̲f̲o̲r̲m̲a̲t̲: This is the normal format used by a C-NET
user to identify a X-NET user. This format is similar
to the CC-format, but has less addressing capability.
(̲a̲)̲,̲ ̲ ̲C̲C̲-̲f̲o̲r̲m̲a̲t̲ (̲b̲)̲,̲ ̲C̲N̲-̲f̲o̲r̲m̲a̲t̲ (̲c̲)̲,̲ ̲C̲X̲-̲f̲o̲r̲m̲a̲t̲
Figure III 6.5.2.2.1-1…01…Addressing Formats
where, AFI: address format identifies
= 0, CC-format or CN-format
= 1, CX-format
level: identifies the C-port-level in the OSI
architecture.
The aim is to facilitate future developments
towards layer level resources management and
con-
trol.
= 0, C-port is at layer 4/5 boundary.
= 1, C-port is at layer 5/6 boundary.
= 2, C-port is at layer 6/7 boundary.
C-NET-NO: identifies the C-NET within the addressed
C-NODE.
= value: from 0 to 15
C-REGION-NO.)
) : identifies the addressed region.
X-REGION-NO.)
- value: from 0 to 255.
C-NODE-NO. : identifies the addressed C-Node.
- value: from 0 to 255.
C-PORT-NO. : identifies the transport access port
(TAP) at the addressed C-NET.
- value: fram 0 to 4095
n̲o̲t̲e̲:̲ this range is extended to three
times the value (12,287), when
supplemented with the use of "level".
C-NAME-LENGTH: the length of the alpha-nummeric generic
name (CNAME)
C-NAME-OFFSET: offset to the actual CNAME string
X-PORT-NO: identifies the TAP at the addressed
X-NET
- value: from 0 to 255
6.5.2.2.2 D̲a̲t̲a̲g̲r̲a̲m̲ ̲F̲o̲r̲m̲a̲t̲
Figure III 6.5.2.2.2-1 shows the datagram format while
figure III 6.5.2.2.2-2 details the optional header-appendix.
o HAL: length of the header appendix/2
o TF: indicates presence of Test Mode (TM) in the
header appendix
.EC. 0, outline datagram
.NE. 0, test datagram
o DFI: datagram format identifier
.EC. 0, the present format
.NE. 0, reserved
o SR: shortest route indicator
.EC. 0, take the shortest route
.NE. 0, split routing
o SD: stream/datagram indicator
.EC. 0, datagram
.NE. 0, stream datagram
o REL: reliability requirement
= 3, highest
= 2, high
= 1, low
= 0, lowest
Figure III 6.5.2.2.2-1…01…Datagram Format
o D: delivery configuration indicator
.EC: 0, no configuration required
.NE. 0, configuration required
o PR: datagram priority
values: from 0 to 7 (7=highest)
o RC datagram rebound count
- incremented every time the datagram passes
through a transit node.
- when this count exceeds a predefined value,
the datagram is considered non-deliverable
and therefore destroyed.
o PS: identifies the protocol used by the higher
level software.
o DA: Destination address
o SA: Source address
o HAP: Optional header-appendix, described below
o DT: Datagram text
- contains transparent user data
Figure III 6.5.2.2.2-2…01…Header Appendix
The following describes the optional header-appendix:
o SI - this area is only present if SD.NE.0.
The area contains necessary stream
information to maintain the Virtual
Transport Connection service.
o TM - this is only present if TF.NE.0. The
value of the byte is used by the user
to specify the test operation.
o DC-NAME/ - alphanumeric text-strings identifying
SC-NAME the users by their generic name.
o Options - specify the various optional facilities
provided by DGS.
For the time being, the following options
are defined:
a) network-time stamp
b) error report
c) return routing information
6.5.2.2.3 D̲a̲t̲a̲g̲r̲a̲m̲ ̲P̲r̲i̲m̲i̲t̲i̲v̲e̲s̲
The DGS provides the following interface primitives:
a) SET ̲TOS
…0e… ̲ ̲ ̲ ̲ ̲ ̲ ̲…0f…
This primitive is used to set the various parameters
which together define the Type-Of-Service provided
at a DGS-port (TAP).
b) SET ̲MODE
…0e… ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲…0f…
This sets the DGS-port either in TEST mode
or ON ̲LINE mode.
c) DG ̲DATA ̲REQUEST
…0e… ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲…0f…
This primitive transfers the user data over
to the DGS.
d) DG ̲DATA ̲INDICATION
…0e… ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲…0f…
This primitive is used by the DGS to handover
the received data to the user.
6.5.2.2.4 D̲a̲t̲a̲g̲r̲a̲m̲ ̲R̲o̲u̲t̲i̲n̲g̲
Based on the address information contained in the datagram
header, the datagram is transported across the ACDN
network to the receiving user. The datagram is forwarded
from node to node, following a path through the network
as indicated by the routing tables in the traversed
nodes until the received is reached.
These routing tables are maintained by a routing algorithm.
The routing tables indicate an ordered list of possible
paths a datagram can take to reach a specified destination
from the present location of the datagram. The list
is ordered by increasing costs. In the ACDN, the principal
factor affecting the cost will be the estimated datagram
transit time.
In most of the present day networks, the routing strategy
is based on the shortest-path (least cost) principle.
In ACDN, the technique known as split-routing will
be implemented. This technique uses both the least
cost paths as well as the non-least cost paths, thus
exploiting all possible paths through the network.
By spreading the traffic in this way, the use of the
total bandwidth available between two nodes is optimized.
Split routing disperses the datagrams at a node, sending
them to one of the possible candidate paths on a probabilistic
basis. The user has the choice of overriding this
mechanism by specifying an appropriate DGS-service.
The ACDN routing strategy is characterised as a c̲e̲n̲t̲r̲a̲l̲i̲z̲e̲d̲
̲a̲d̲a̲p̲t̲i̲v̲e̲ ̲r̲o̲u̲t̲i̲n̲g̲ ̲s̲c̲h̲e̲m̲e̲. The Network Services Environment
in each node will report topological changes to the
NCC. A control algorithm at the NCC uses this information
in conjunction with the knowledge of the total topology
of ACDN to work out a set of new routing tables for
each node. The updated routing tables are then sent
out to the relevant nodes.
The routing algorithm works in the following way.
For each link terminating at a node, the algorithm
maintains both a path length (PL) and a performance
measure (COST) to each destination node within the
same region and to each destination region if the destination
node lies in another region. On the basis of this
the algorithm prepares two routing tables for each
node: a regional routing table and a internodal routing
table.
a) R̲e̲g̲i̲o̲n̲a̲l̲ ̲R̲o̲u̲t̲i̲n̲g̲
This is the first level routing. When the destination
region number is not identical with the local region
number, the routing is performed solely on the
basis of the destination region number.
Figure 6.5.2.2.4-1 shows the format of this table.
The table consists of upto 256 entries. Each
entry contains the information necessary for routing
to the destination region. The entry specifies
upto four possible paths to the destination region.
Each path is specified by a logical path number,
the local C-NET-NO. to which the path is attached
and a Split Count Reset Value (SCRV). This last
parameter reflects the share of the traffic to
be sent on the particular path performing split
routing.
At any given time, the Current Path Offset (CPO)
points to the preferred link for routing. For
every datagram routed via the preferred path, the
Current Split Count (CSC) is reduced by one until
it reaches a value of zero. At this point, the
CSC is reset by copying the reset value into it
and the CPO is changed to point to the next preferred
path in the list. In this way, all the paths are
used to transport the traffic. However, there
are exceptions to this rule: if the datagram has
the highest priority (PR=7) or the explicit request
to take the path with the least cost (SR/0), then
the optimal path is taken unconditionally.
A path in this context represents a group of logical
links. Each link, in iturn, is a group of trunks.
The datagram sublayer of DTrE provides for increased
reliability and capacity of paths by spreading
the path traffic on a number of logical links.
The DLE provides similar facilities at the link
level by spreading the link traffic on multiple
physical trunks.
where,
PN : Logical path number
C ̲NET ̲NO: the local C-NET to which the trunk is attached
SCRV : a reset value for CSC
- reflects the share of split-traffic
to be directed on the path
CSC : counts the number of datagrams routed via
the path during the current cycle.
Figure III 6.5.2.2.4-1…01…Regional Routing Table
b) I̲n̲t̲e̲r̲-̲n̲o̲d̲a̲l̲ ̲R̲o̲u̲t̲i̲n̲g̲
When the destination region is the same as the
local region number, the routing procedure makes
routing decision on the basis of the inter-nodal
routing table.
The format and the use of this table is similar
to that described for Regional routing.
c) I̲n̲t̲r̲a̲-̲n̲o̲d̲a̲l̲ ̲R̲o̲u̲t̲i̲n̲g̲
This form of routing is performed within the environment
of a common operating system. This form of routing
is necessary in the following two cases:
c1) The datagram is destined for another C-NET
within the same C-NODE.
c2) The datagram is to be routed out via a path
attached to another C-NET with the same C-NODE.
The DAMOS operating system provides facilities
for such routing.
6.5.2.2.5 F̲l̲o̲w̲ ̲a̲n̲d̲ ̲C̲o̲n̲g̲e̲s̲t̲i̲o̲n̲ ̲C̲o̲n̲t̲r̲o̲l̲
The purpose of flow and congestion control is to ensure
an optimal orderly flow of traffic through the transport
network.
Congestion in the network may create a loss of traffic.
This controlled loss of traffic is the price paid for
steering the network out of any deadlock situation.
Logically, the best traffic to lose is the traffic
with the highest probability of being lost in the first
place - low reliability traffic. At low degree of congestion,
the network will exercise discretion as to which datagrams
are to be sacrificed. But, if the situation gets worse,
the network will take more drastic actions.
The principle used in congestion control is to prioritize
the traffic that is already in the network over new
traffic entering into the network. Thus, when DTrE
detects that the local buffer resources are running
low, it will block the outgoing (locally generated)
traffic at the Transport Access Port (TAP) and concentrate
on servicing the incoming (transit) traffic. This will
result in the outgoing queues at each TAP getting longer.
Flow control is provided by CUE monitoring the outgoing
queue length at each TAP. When this queue exceeds a
given maximum length, the CUE will notify the Session
Service User (SSU) to stop generating data. Conversely,
when the queue reduces to a given minimum length, the
CUE will notify the SSU to continue generating data.
The actual values of these queue lengths are determined
per TAP basis, depending on the grade of service offered.
The above mechanism is accentuated in more serious
cases of congestion, such that outgoing traffic is
dropped and the associated buffers are confisticated
to support the transit traffic.
6.5.2.3 V̲i̲r̲t̲u̲a̲l̲ ̲T̲r̲a̲n̲s̲p̲o̲r̲t̲ ̲C̲o̲n̲n̲e̲c̲t̲i̲o̲n̲ ̲S̲e̲r̲v̲i̲c̲e̲ ̲(̲V̲T̲C̲S̲)̲
The VTCS provides an enhanced service based on the
Datagram Service (DGS) described above. The primary
purpose of VTCS is to provide the higher level users
with a reliable end-to-end controlled stream oriented
data transfer.
The services provided are divided into three main groups:
- connection establishment
- data transfer
- connection termination
a) C̲o̲n̲n̲e̲c̲t̲i̲o̲n̲ ̲E̲s̲t̲a̲b̲l̲i̲s̲h̲m̲e̲n̲t̲ ̲p̲h̲a̲s̲e̲
The users are provided with facilities to dynamically
create transport connections. At this time the
users may request different types of services such
as:
- the reliability of the connection, i.e. whether
the VTCS must retain copies of messages for
retransmission.
- the priority of the data transfer
- the throughput rate, which will influence the
end-to-end flow control window-size and the
degree of multiplexing with other data streams.
- maximum size of messages
The same addressing scheme as described in 6.5.2.2.1
is used to identify users in this service.
The type of service parameters are defined in cooperation
between VTCS and both the service users.
On the successful completion of this phase, the
two relevant users are provided with a two-way
simultaneous path for data transfer and, optionally,
a similar path of control purposes (expedited data
path).
b) D̲a̲t̲a̲ ̲t̲r̲a̲n̲s̲f̲e̲r̲ ̲p̲h̲a̲s̲e̲
This phase controls the orderly transmission of
stream oriented traffic. The messages received
from the source user are segmented into smaller
units. These segments are sent to the destination
VTCS via the Datagram Service. The destination
VTCS reassembles these units in the correct sequence
before relaying the message to the destination
user.
An end-to-end window mechanism is used to control
the flow of data through the network. For normal
data flow this window size is negotiated at connection
establishment time. For expedited data, if selected,
the window-size is fixed to one.
c) C̲o̲n̲n̲e̲c̲t̲i̲o̲n̲ ̲t̲e̲r̲m̲i̲n̲a̲t̲i̲o̲n̲ ̲p̲h̲a̲s̲e̲
Both users of a connection may, regardless of the
current activity, request that the connection be
terminated. To terminate properly it is assumed
that the users have ended their conversation prior
to this request.
When a request for termination is issued, all data,
both normal and expedited, not yet delivered to
the users are discarded.
Should the VTCS not be able to maintain the service
requested at establishment time, the VTCS may terminate
the connection and notify the involved users.
6.5.2.3.1 V̲T̲C̲S̲ ̲S̲t̲a̲n̲d̲a̲r̲d̲s̲
The services provided and the protocols used to provide
these services are very much influenced by the current
work being carried out in the international standards
bodies.
The following documents are particularly relevant:
a) Draft connection-oriented transport service definition
ISO TC97/SC16 N860
b) ECMA-72, Transport protocol
c) Draft connection-oriented basic transport protocol
specification ISO TC97/SC16 N861
6.5.2.4 D̲a̲t̲a̲ ̲L̲i̲n̲k̲ ̲E̲n̲v̲i̲r̲o̲n̲m̲e̲n̲t̲
The Data Link Environment (DLE) supports the Balanced
Link Access Protocol (LAPB) which is specified in CCITT
recommendations X.25 and X.75.
This protocol ensures error free full duplex transmission
of frames on a single link, from one C-NODE to another,
except for the very rare case where bit errors are
not detected by the frame sequence check.
The protocol is implemented in firmware on the Line
Termination Unit (LTU) board, which connect trunks
to the CR80 computer.
To increase the reliability of the links, Multilink
Link Procedures (MLP) will be implemented.
6.8 I̲n̲t̲e̲r̲n̲a̲l̲ ̲N̲e̲t̲w̲o̲r̲k̲ ̲A̲c̲c̲e̲s̲s̲ ̲S̲o̲f̲t̲w̲a̲r̲e̲
The main task of the gateway (GWY) is to act as the
physical and logical link between the ACNC and the
ACDN, see Figure III 6.5.5-1.
As seen from the ACNC the gateway must look like several
ICC'S with CRT's and printers.
As seen from the Nodal Switch Software of the collocated
node the Gateway must look like any other subsystem
interfacing the network.
Therefore the Gateway is a protocol converter between
the ICC- and the NSS-protocols.
It also acts as a multiplexer or speed converter of
several ICC subsystems (of 9.6 Mbps each) and one CCI
subsystem (Communication Control Interface).
Finally the Gateway is a converter because messages
must be converted to and from the Virtual Terminal
Protocol entirely used inside the ACDN.
Fig. III 6.8-1…01…The Gateway (GWY) and its Surroundings
6.8.1 A̲C̲D̲N̲ ̲I̲n̲t̲e̲r̲f̲a̲c̲e̲s̲
o The interface between the Gateway and the old ACNC
is characterized by:
- several 9.6 Mbps lines
- ICC protocol (AC200) on each line incl. IMA.
- entire messages are stored and forwarded
- in case of error the entire message is retransmitted
- messages are divided into segments.
6.8.2 N̲e̲t̲w̲o̲r̲k̲ ̲I̲n̲t̲e̲r̲f̲a̲c̲e̲
o The interface between the Gateway and the new ACDN
Packet Switched Network is characterized by:
- S-net Connection
- Message level protocol
- A number of logical channels will be established
for virtual calls as well as possible permanent
virtual circuits through the network
- Virtual Terminal Protocol
The interface is shown on figure III 6.8-2.
Fig. III 6.8-2…01…The ACNC and the Network Interface of the Gateway
6.8.3 M̲o̲d̲u̲l̲e̲s̲ ̲o̲f̲ ̲t̲h̲e̲ ̲I̲n̲t̲e̲r̲n̲a̲l̲ ̲N̲e̲t̲w̲o̲r̲k̲ ̲A̲c̲c̲e̲s̲s̲ ̲S̲o̲f̲t̲w̲a̲r̲e̲
6.8.3.1 T̲h̲e̲ ̲I̲C̲C̲ ̲M̲o̲d̲u̲l̲e̲
The ICC Module is divided into a number of co-routines
each performing the task of acting like an intelligent
Communications Concentrator as seen from the ACNC.
Messages are exchanged with the CCI Module by means
of Message Queues.
a). T̲h̲e̲ ̲C̲o̲m̲m̲u̲n̲i̲c̲a̲t̲i̲o̲n̲s̲ ̲C̲o̲n̲t̲r̲o̲l̲ ̲I̲n̲t̲e̲r̲f̲a̲c̲e̲ ̲M̲o̲d̲u̲l̲e̲
The Communications Control Interface Module (CCI)
interfaces the Nodal Switch Software.
Virtual Circuits to hosts, terminals and printers
are created and dismantled when necessary initiated
from this module.
Messages are exchanged with the ICC co-routines
by means of Message Queues.
b). T̲h̲e̲ ̲H̲i̲g̲h̲ ̲L̲e̲v̲e̲l̲ ̲S̲e̲r̲v̲i̲c̲e̲ ̲M̲o̲d̲u̲l̲e̲
The conversion to and from the Virtual Terminal
Protocol entirely used inside the ACDN is done
by the High Level Service Module.
c). T̲h̲e̲ ̲S̲u̲p̲e̲r̲v̲i̲s̲o̲r̲y̲ ̲M̲o̲d̲u̲l̲e̲
The Gateway is monitored from this module which
generates Statistics (host-, terminal-, and printer
connections) and error reports. Possible controlling
information too is received by the module.
d). T̲h̲e̲ ̲R̲e̲c̲o̲v̲e̲r̲y̲ ̲M̲o̲d̲u̲l̲e̲
This module will perform all recovery necessary
for the GWY to be restarted after a Gateway-failure.
The recovery will be done from appropriate checkpoint
information.
6.9 E̲x̲t̲e̲r̲n̲a̲l̲ ̲N̲e̲t̲w̲o̲r̲k̲ ̲A̲c̲c̲e̲s̲s̲ ̲S̲o̲f̲t̲w̲a̲r̲e̲,̲ ̲E̲N̲A̲S̲
The system and application software for supporting
external network access is implemented in different
subsystems. The high level procedures are implemented
in the NCPs partly in the EMH, whereas the lower level
software for link control etc. is implemented in the
NSPs in order to provide external network access to
the most appropriate node.
6.9.1 A̲R̲I̲N̲C̲ ̲a̲n̲d̲ ̲S̲I̲T̲A̲ ̲P̲r̲o̲c̲e̲d̲u̲r̲e̲s̲
Christian Rovsing has extensive experience in implementing
communication procedures like those defined by ATA/IATA
and used on ARINC and SITA networks. This experience
has been gained in military programs like FIKS and
CAMPS, where the NATO defined ACP127 communications
procedures have been implemented. The ACP127 is many
similarities to the ATA/IATA procedures, but it is
more complex, e.g. the ACP127 procedures includes 16
different format lines with different optional and
mandatory parameters per line.
The utilization of both 5-bit and 7-bit coded character
set and the conversion between these is also well known
from the military environment.
The validation of an ATA/IATA message is performed
by the ENAS at the EMH. An ATA/IATA message has the
following gour mandatory sections:
- Address
- Communications reference
- Text
- Ending
The elements of the Address section are
- Start ̲of ̲Address (Mandatory)
- Priority Indicator (Optional)
- Addressee Indicator(s) (Mandatory)
- Alignment Function (Mandatory)
- End-of-Address (Mandatory)
The elements of the Communications reference section
are
- Message Origin (Mandatory)
- Message Identity (Mandatory)
- Special Service Address (Optional)
The elements of the Text section are
- Start ̲of ̲Text (Mandatory)
- Text (Mandatory)
- Alignment (Mandatory)
- End-of-Text (Mandatory)
- Communication Control Information (Optional)
The elements of the Ending section are
- Spacing signal (Mandatory)
- End-of-Message signal (Mandatory)
- Message Separation signal (Mandatory in some cases)
In addition to the above mentioned elements, supplementary
optional information might be required in special cases.
The definition of all elements are different depending
on which alphabet has been used. Both the asynchronous
and the synchronous link control procedures can be
applied.
Asynchronous link control is performed by use of the
following control codes
- VA, Validate Action Code
- IA, Invalidate Action Code
- SA, Suspend Transmission Code
Synchronous link control utilizes a more extensive
set of control information and procedures to ensure
error free transmission.
The link level control software will be installed in
the NSP in other to connect the external networks.
6.9.2 C̲N̲T̲ ̲a̲n̲d̲ ̲S̲i̲m̲i̲l̲a̲r̲ ̲C̲o̲n̲n̲e̲c̲t̲i̲o̲n̲s̲
Messages received from the CNT network are also checked
when interfaced to the ACDN. The structure of a CNT
message is however very simple, i.e. an envelope defined
the start-of-message, the recipient followed by a free
format text and ended by a end-of-message designator.
ENAS located in the NSP controls polling and calling
of selectorised teletype terminals connected to multi-drops
full-duplex or half-duplex low-speed asynchronous lines.
ENAS supports 81D1, 83B3 and similar teletype protocols.
Global line and terminal control is exercised by the
active NCC similar to the control exercised on other
node terminations. ENAS recognizes and initiates appropriate
controlling action for open circuit, mark hold, or
terminal response failure. Line and terminal status
is dynamically maintained in both ENAS and NCC.
Terminal transmission of ATA/IATA formatted traffic
is assembled by ENAS and transferred, upon receipt
of EOM, to the EMH for validation, routing and mass
storage retention. An input message acknowledgement
is generated by the EMH and transferred via NSS for
relay to the originating terminal.
Under control of a poll-call ratio structure, ENAS
solicits the EMH to transfer, via the supra-bus, complete
messages for delivery on the teletype terminal network.
ENAS selects addressed terminals, initiates character
transmission and if required, returns requeue status
to the EMH in accordance with protected message philosophy.
In order to establish a network compatibility at the
low level between ACDN and the CNCP Telex network,
on intelligent micro telecontroller is proposed.
The Model 2000 Micro Telecontroller, a general purpose
programmable controller "GPPC", is programmed to interface
Air Canada's new data network ACDN to the CNCP-Telex
Network.
The GPPC provides for the "Incoming" and "Outgoing"
telex connections and converts the internal ACDN data
codes to 5-level Baudot and vice versa, as well as
changing the transmission speeds automatically.
The GPPC can interface to EIA/V24 lines and DC-Loops,
and is capable to receive telex calls as well as establishing
automatically outbound calls, providing also for "answerback"
verifications.
The GPPC, upon receiving a call request from ACDN for
an outgoing call, automatically sets up the telex connection
in the following manner:
a) AC-Data Network Call Request - ESC, Dial Nbr.,
STX
- Called Answerback,
ETX
b) GPPC stores Call Request - EOT, NACK, DC3
and acknowledges with
c) GPPC sets up call - Seizes Telex Line
- Transmits selection
format
- Waits for call
con-
firmation
- Compares received
answerback
- Transmits its own
answerback
d) GPPC switches the Telex - DC 1
connection to originator
e) AC Data Network transmits - SOH, Block Nbr.
1
- Block N
- ETC
f) AC Data Network disconnects - DC 3
call
g) GPPC disconnects call - clears telex line
and returns to
idle
A number of safeguards are built into the GPPC-program
to prevent false telex connections, to detect busy
conditions and time-outs, and to provide reports to
the AC-Data Network concerning correct delivery of
messages.
The GPPC has inherent buffer storage of 2048 bytes
for message storage, and the data flow is controlled
with X-ON X-OFF transmitted towards the originator
in the ACDN.
While the GPPC is in the "outbound" call mode, incoming
calls can not be accepted.
The GPPC continuously monitors the telex line. Upon
an Incoming Call Request, the GPPC will inhibit any
outbound calls, and accept the incoming call as follows:
a) GPPC accepts call - sets EIA/V24 control
leads
- X-OFF, DC3, transmitted
to the AC Data Network
to inhibit outbound
calls
b) GPPC requests and validates
Calling Party Answerback - transmits Fig. D towards
telex network.
- stores the Answerback
- compresses the Answer-
back to alpha/numerics
space character
c) GPPC connects call to
AC Data Network, sends - SOH, CR LF, Calling
Answerback, STX
d) GPPC sents its I.D. - transmits its own
Answerback
e) GPPC converts text - message characters
received from Telex
are converted from
Bau-
dot to ASC II towards
the AC Data Network
in
transparent mode.
f) GPPC disconnects call - upon receipt of type
B
disconnect
- upon time out after
60
sec. delay
- EOT, DC1 towards the
AC
Data Network
The GPPC returns to its "idle" mode and is ready to
receive or originate new calls.
6.9.3 P̲u̲b̲l̲i̲c̲ ̲P̲a̲c̲k̲e̲t̲ ̲S̲w̲i̲t̲c̲h̲i̲n̲g̲ ̲D̲a̲t̲a̲ ̲N̲e̲t̲w̲o̲r̲k̲ ̲A̲c̲c̲e̲s̲s̲
Christian Rovsing will provide to Air Canada the access
capability to interface to any public or private packet
switching network which can be interfaced through X.75.
This standard, which has been issued by CCITT, is the
internationally recommended interface between different
packet switching network.
The X.75 gateway software is equipped with Multi link
Procedures (MLP) which enable the traffic over the
connection to be diversified on more than one connection.
This provides higher throughput capability and better
reliability.
The X.75 protocol might have to be customized by Air
Canada, if billing and statistical data has to be transferred
from the external network to ACDN or vice versa.
6.9.4 I̲n̲t̲e̲r̲p̲r̲e̲t̲e̲r̲ ̲f̲o̲r̲ ̲S̲t̲a̲n̲d̲a̲r̲d̲ ̲M̲e̲s̲s̲a̲g̲e̲ ̲T̲e̲x̲t̲ ̲(̲S̲M̲T̲)̲
Christian Rovsing can optionally offer to implement
a syntactical interpreter for SMT, when these are received
in the ACDN. From military projects Christian Rovsing
has achieved great experience in implementing advanced
man machine interfaces comprising also utilization
of predefined formats, where the structure of a predefined
format can be defined in a way to both satisfy actual
differences and similarities in applied messages.
Christian Rovsing suggest to implement an interpreter
as part of ENAS which will validate SMT according to
tables defined by the following symbols.
a represents a single alphabetic character
f represents a single numeric character
m represents mixed alpha (A through Z) and figures
(numerics 0 through 9); excludes other characters
t represent any characters, numeral of special
value
() brackets frame indicate optionality
(*N*) indicates an upper limit of a duplication factor
(*M..N*) indicates lower and upper limit of
duplication factor
*F indicates a figure shift (in alphabet No. 2)
*L indicates a letter shift (in alphabet No. 2)
*S indicates a space
*LR indicates a carriage return
*LF indicates a line feed
Where a keyboard is to be spelt the format is specified
in upper case characters, numerals, a slash or period.
6.11 N̲e̲t̲w̲o̲r̲k̲ ̲M̲a̲n̲a̲g̲e̲m̲e̲n̲t̲ ̲H̲o̲s̲t̲ ̲S̲o̲f̲t̲w̲a̲r̲e̲
The Network Management Host (NMH) is a general purpose
computer connected to the backbone network as an ordinary
host processor.
The services offered by the NMH are to a great extend
standard software products as language processors and
software maintenance utilities. All services are controlled
by the DAMOS multiuser system which can provide service
for an unlimited number of concurrent users.
6.11.1 N̲M̲H̲ ̲I̲n̲t̲e̲r̲f̲a̲c̲e̲s̲ ̲a̲n̲d̲ ̲F̲u̲n̲c̲t̲i̲o̲n̲a̲l̲ ̲O̲v̲e̲r̲v̲i̲e̲w̲
o The services of the NMH are offered to any user
at any terminal connected to the backbone network.
The basic services offered are:
- Software development and maintenance facilities
- Network modelling software
The NMH is connected to the backbone network via a
supra bus link. Softwarewise the NMH contains support
for the "File Transfer Protocol" and "Virtual Terminal
Protocol".
Thus the NMH is able to service any user at any terminal
in the backbone network. The access to the NMH is controlled
by a session control layer.
Directly connected to the NMH there is the following
standard peripheral equipment:
- Disc unit with 80 Mbyte moving head and 2 Mbyte
fixed head capacity
- Disc unit with 80 Mbyte exchangeable disc pack
- Line printer for 600 LPM
- Magtape unit
- Floppy Disk
- 3 Visual Display Units
The functional areas of the NMH application are the
following:
- Software development, maintenance and configuration
control
- Maintenance of the data bases for: Network Configuration
and Network Inventory List
- Downline loading of software and configuration
data
- Processing of data for statistics and for cost
and billing.
- Network modelling functions and automated test
and emulation functions for real-life tests.
6.11.2 S̲o̲f̲t̲w̲a̲r̲e̲ ̲D̲e̲v̲e̲l̲o̲p̲m̲e̲n̲t̲ ̲a̲n̲d̲ ̲M̲a̲i̲n̲t̲e̲n̲a̲n̲c̲e̲ ̲F̲u̲n̲c̲t̲i̲o̲n̲s̲
The NMH provides all the tools necessary for software
development and maintenance.
The following programming languages are available for
the CR80M computers:
- SWELL, which is an intermediate level systems programming
language
- PASCAL, which is a general purpose high level programming
language
- COBOL, which is a high level language for administrative
application programming.
Furthermore, the new DOD standard programming language
ADA will be available for the CR80M computers from
1984.
The NMH software development and maintenance package
comprises the following functions:
- Source test editor
- Language processors for: SWELL, PASCAL, COBOL
- A comprehensive set of file-handling utilities
(copying, moving, patching, comparing, backup,
etc.)
- All the libraries necessary for software development
and maintenance.
An extensive description of all standard software available
for the CR80 computer is found in the CR80 Minicomputer
Handbook section 4.
6.11.3 M̲a̲i̲n̲t̲e̲n̲a̲n̲c̲e̲ ̲o̲f̲ ̲t̲h̲e̲ ̲D̲a̲t̲a̲ ̲B̲a̲s̲e̲
The Data Base (DB) implemented in ACDN is a set of
data structures giving the physical and logical relations
between items in the ACDN. The key items in the DB
are as follows:
C̲o̲n̲f̲i̲g̲u̲r̲a̲t̲i̲o̲n̲ ̲a̲n̲d̲ ̲i̲n̲v̲e̲n̲t̲o̲r̲y̲ ̲d̲a̲t̲a̲
- End user devices (e.g. terminals, printers, host
channels) - each device has associated a logical
identification, a physical path (relates to inventory
items attributes) and an attribute list (e.g. type,
priviledges, protocol).
- Inventory Items - a list of all "line replaceable
units" in the access networks and, the backbone
network ordered per equipment type. Each unit has
a record defining all external logical and physical
connections with cross reference to the device
path definitions for consistency checking.
- User catalogue - each user allowed access to the
network is identified by a user profile, i.e. a
user ID, password, user attributes (e.g. type,
priviledges, priority).
S̲t̲a̲t̲i̲s̲t̲i̲c̲a̲l̲ ̲a̲n̲d̲ ̲b̲i̲l̲l̲i̲n̲g̲ ̲D̲a̲t̲a̲
- For each transaction type, there will be statistical
and billing information including host terminal,
user identification plus time information.
M̲o̲d̲e̲l̲l̲i̲n̲g̲ ̲D̲a̲t̲a̲
- Test configuration (e.g. terminals, concentrators,
nodes and host) including their interconnection.
- Traffic profiles for terminals and hosts including
time and length distribution.
Subsets of the data base exist in three versions at
the NMH. The previous version, the current version,
and the version under update - only the latter is subject
to any changes or updates. The data base is based on
the index sequential access method: CRAM. Updates may
be performed interactively or in batch mode.
6.11.4 D̲a̲t̲a̲ ̲B̲a̲s̲e̲ ̲M̲a̲n̲a̲g̲e̲m̲e̲n̲t̲ ̲S̲y̲s̲t̲e̲m̲ ̲U̲s̲e̲r̲ ̲G̲r̲o̲u̲p̲s̲
Two different user groups of the DBMS are foreseen.
The first group comprises the experienced programmers
and the DB administrator who are responsible for the
integrity of the DB. The other group consist of technicians
who are interested in the configuration subset of the
DB.
D̲e̲v̲e̲l̲o̲p̲m̲e̲n̲t̲ ̲U̲s̲e̲r̲s̲
The experienced users of the DB, has a detailed knowledge
of the structure of the DB. Their requirements to a
DBMS are:
- Query language facilities which can also be used
for DB modifications
- Optimization capability which allows the experienced
user to utilize his detailed knowledge of the DB
structure to the full extend.
M̲a̲i̲n̲t̲e̲n̲a̲n̲c̲e̲ ̲U̲s̲e̲r̲s̲
The technicians who are responsible for the hardware
components of the ADCN, i.e. the configuration have
a different requirement to the DBMS:
- Specific retrieval capabilities to the configuration
DB.
- Specific and limited change capability to the configuration
DB
- Optimal access capabilities with small response
times
- Guarantee for DB integrity during exercise of the
above capabilities.
The DBMS offered by Christian Rovsing will serve both
user groups. The maintenance user will have specific
and special tailored access capabilities, which can
be expanded by AC is required in the future. The development
users, i.e. programmers will get the total tool set,
developed and used by Christian Rovsing during implementation.
6.11.5 D̲a̲t̲a̲ ̲B̲a̲s̲e̲ ̲M̲a̲n̲a̲g̲e̲m̲e̲n̲t̲ ̲T̲o̲o̲l̲s̲
Instead of a standard and general purpose DBMS, Christian
Rovsing will offer to Air Canada an extensive set of
versatile tools, which when used by experienced users
will provide great flexibility in many different aspect,
e.g. query situations with complex dicision parameters
followed by data base modifications. Also optimization
situations where the experienced users detailed knowledge
of the DB can be performed due to the high flexibility
of DBMS.
It is Christian Rovsing's experience, that modern software
development strategies like structured programming
combined with good documentation techniques is more
beneficial to an experienced programming organization
like Air Canadas, than the application of a more or
less rigid DBMS which tend to obscure the actual data
organization and which might only have limited optimization
capabilities.
The set of tools which Christian Rovsing will offer
as a DBMS are aimed specifically at Air Canadas use.
They include:
o Processing of the total DB is a sequential fashion
to provide
- selection of subsets of the DB for downline
loading to other subsystems
- printout of the total database for manual inspection.
- foundation for user written query statements.
- optimization of DB in connection with reorganization.
o Optimal processing of any subset of the total DB,
like
- configuration DB
- inventory DB
- statistical DB
- billing DB
All the tools of the DBMS will be programmed in the
high level language Pascal, and all the capabilities
inherent in this language will be available for the
user.
Christian Rovsing will provide a source code library
of all the components necessary for performing the
above mentioned tasks. This includes definition of
all record types and print modules for each type of
record. The following example written in pseudo code
will demonstrate how the tools can be applied.
QUERY:
DEFINE ICC ̲RECORD,
Module 1 ICC ̲FIELD1,
retrie- ICC ̲FIELD2;
ve
DEFINE TERMINAL ̲RECORD,
from TERM ̲ID,
libra- TERM ̲TYPE,
ry TERM ̲TEST ̲MODE ̲INDICATOR;
LOOP:
READ NEXT ̲RECORD INTO RECORD
- - - - - - - - - - - - - - - - - - - - - - - - - - - - -
User IF RECORD = TERMINAL ̲RECORD THEN
written IF TERM ̲TEST ̲MODE ̲INDICATOR = MODE1 THEN
state- CALL PRINT ̲TERMINAL ̲RECORD;
ments
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
- - -
ELSE GOTO LOOP;
Module 2 PRINT ̲TERMINAL ̲RECORD:
retrieved PRINT(TERM ̲LID, TERM ̲TYPE, TERM ̲TEST ̲MODE
̲
from li- INDICATOR),
brary END PRINT ̲TERMINAL ̲RECORD;
PRINT ̲ICC ̲RECORD;
PRINT(FIELD1, FIELD2);
END PRINT ̲ICC ̲RECORD;
END QUERY;
Fig. III 6.11.5-1
In order to make a printout of all terminals with a
specific test mode indicator, all the programmer has
to do is to retrieve two modules from the source library
and insert the requested selection criteria before
submission for compilation and executing. This can
be controlled interactively from a CRT.
The software development tools including on line library
functions and source code editing will minimize the
extra effort required by the programmer, when using
this query facility and will be a small expense compared
to the great flexibility provided. As an example it
will only require a few statements to perform a bulk
update of all terminal with some specific characteristics.
If Air Canada express any concern over giving to much
flexibility to the programmers, Christian Rovsing is
also willing to deliver a query language version where
the library modules are totally hidden from the user
and where the compilation and execution is performed
automatically. This will provide a more traditional
interface to the user.
In order to provide initial query language facilities
to the maintenance user, Christian Rovsing will provide
retrieval capabilities of any individual record type
within the configuration DB. The terminal user only
has to enter the record type, i.e. terminal, concentrators
etc. and the identification key of that record.
Future enhancement, which might give the maintenance
user capabilities like simple updates in specific areas
can be implemented by Air Canada, when requirements
are identified.
6.11.6 R̲e̲p̲o̲r̲t̲ ̲G̲e̲n̲e̲r̲a̲t̲i̲o̲n̲
Report generation capabilities are really enhancements
to the query facilities. In addition to the sequential
processing of the data base and the selection criteria,
you might have to collect all printout information
for sorting before further processing including accumulation,
counting etc. followed by the final printout.
Modern structured programming techniques have shown
how this can be done in a straight forward way in normal
high level languages without relaxation of any of the
capabilities found in high level languages. Specialized
report generators normally either contain output format
limitations or they are so complicated to use that
no time saving is obtained.
Christian Rovsing will develop data base printout programs
showing how this technique works.
6.11.7 N̲e̲t̲w̲o̲r̲k̲ ̲M̲o̲d̲e̲l̲l̲i̲n̲g̲ ̲S̲o̲f̲t̲w̲a̲r̲e̲ ̲a̲n̲d̲ ̲S̲u̲p̲p̲o̲r̲t̲ ̲f̲o̲r̲ ̲A̲u̲t̲o̲m̲a̲t̲i̲c̲
̲N̲e̲t̲w̲o̲r̲k̲ ̲T̲e̲s̲t̲s̲
o Network modelling and real life network tests are
addressed in this section.
Testing the consequences of network topology changes
can be performed by means of the "Network Model" which
is mathematical model of network or by means of the
"Automated Test & Emulation System" - ATES.
6.11.7.1 N̲e̲t̲w̲o̲r̲k̲ ̲M̲o̲d̲e̲l̲
The Network Modelling Software Package is a mathematical
model of the entire network including submodels for
all types of equipment.
The model is used for consequence calculation of network
topology changes. The model includes the entire backbone
network, the entire terminal access network and the
entire host access network.
Input to the network model is the following data structures:
- The test configuration data base defining the entire
network including terminal access net and host
access net.
- A library of submodels for each type of equipment
(terminal, mux, ICC, node, host). The submodels
are complex queue models which can be updated by
library update procedures.
- Per terminal connected to the network there shall
be defined a traffic profile selected from a predefined
library of traffic profiles. The traffic profile
defines type of traffic, variation within a 24
hour period, traffic volume in terms of number
of transactions and number of input and output
characters per transaction, destination/source
of traffic. The traffic profiles may be updated
by library update procedures.
Initial values for all network parameters may be specified
before a simulation.
A simulation for a specified time-period is performed
by the model and output is produced in forms of a log
data file.
A special data reduction S/W package is provided for
output of log data from the model.
The model is able to provide the following set of data:
- Mean value, standard deviation, and maximum value
over the simulation period of the following parameters:
- Queue lengths for all queues in the model
- Terminal response times
- Line utilization
- The parameter sensitivity to an increase/decrease
of the network throughput is given for each
of the above parameters.
- A histogram over a specified time period of above
parameters may be output.
6.11.8 N̲e̲t̲w̲o̲r̲k̲ ̲T̲e̲s̲t̲i̲n̲g̲ ̲b̲y̲ ̲M̲e̲a̲n̲s̲ ̲o̲f̲ ̲A̲T̲E̲S̲
The "Automated Test & Emulation System" (ATES) is a
general test drive system developed by Christian Rovsing
for the real-life test of major military communication
systems.
The software driving this system may be downline loaded
via the NMH and executed on redundant eqipment in the
nodes, the front-ends or the EMH.
The functional capabilities of the ATES is described
in Appendix F.
The NMH contains all the software necessary for running
a real-life test using the ATES:
- Transaction Volume Generator
- Online Test Controller
- Log File Editor (data reduction program)
6.12 E̲l̲e̲c̲t̲r̲o̲n̲i̲c̲ ̲M̲a̲i̲l̲ ̲S̲o̲f̲t̲w̲a̲r̲e̲ ̲P̲a̲c̲k̲a̲g̲e̲
The Electronic Mail Software Package implements the
protected message switching service for Type B-TDP
traffic and Type B - PMS traffic in the ACDN. These
services can be summarized as follows:
o Direct delivery traffic handling (Type B-TDP)
o Protected Message Switching
- Guaranteed automatic delivery of ATA/IATA messages
and automatic routing
- Longterm storage of messages for retrieval
- Message entry handling
- Message intercept, repair handling
- Logging, journalization, statistics
o Supervision of PMS traffic
- Table Handling
- Delivery Control
- Alarm Supervision
- Storage Maintenance
o Provisions for electronic mail applications
o Adaption to external networks and hosts.
The EMH Services are provided to the following terminals,
hosts and external networks:
Terminals:
- Direct connected teleprinters (TTY)
- Concentrator Switched terminals (CRT's printers).
Hosts:
- RES
- VIA
- SUPPH
External Networks
- SITA
- ARINC
- CNT
- TELEX
The operational specification of these services is
given in section 4.9, and the functional interfaces
against terminals, hosts and external networks are
given in section 6.6, 6.7, 6.9.
6.12.1 I̲n̲t̲e̲r̲f̲a̲c̲e̲s̲ ̲t̲o̲ ̲t̲h̲e̲ ̲E̲M̲H̲
The EMH connects to the network as a general purpose
host. This means tht the transport network services
are used for transport of the messages.
The interface to the terminals is a HAS-Transport net
- TAS connection, although the terminal characteristics
(TTY, CRT, Printer) are mapped on the EMH applications.
The interface to the hosts is a HAS-Transport net -
HAS connection.
The host protocol characteristics are mapped via Host
Protocol Emulators.
The interface to the external networks is provided
by the external Network Access Software (ENAS).
Interfaces to standard peripherals as supervisor VDU's,
discs, line printers tape unit is provided in order
to perform the functions on the EMH.
6.12.2 F̲u̲n̲c̲t̲i̲o̲n̲a̲l̲ ̲D̲e̲s̲c̲r̲i̲p̲t̲i̲o̲n̲ ̲o̲f̲ ̲t̲h̲e̲ ̲E̲M̲H̲
An overview of the EMH S/W package is given in fig.
6.12.2-1.
The EMH S/W package will mainly be based on modifications
of S/W developed for the FIKS and CAMPS projets which
provide services similar to those required for EMH.
The functions of the EMH is distributed on the following
subsystems:
o T̲D̲P̲ ̲T̲r̲a̲f̲f̲i̲c̲ ̲H̲a̲n̲d̲l̲i̲n̲g̲ ̲S̲u̲b̲s̲y̲s̲t̲e̲m̲ ̲(̲T̲D̲P̲)̲
- TDP transfer session setup (HOST-EMH)
- Storage of message
- Enqueuing for printout
- Acknowledgement to Host.
o M̲e̲s̲s̲a̲g̲e̲ ̲A̲n̲a̲l̲y̲s̲i̲s̲ ̲S̲u̲b̲s̲y̲s̲t̲e̲m̲
- Incoming message analysis (PMS)
ATA/IATA Messages and Telex are accepted
- Address look up
- Incoming message statistics Journalization
- Reporting in case of exceptions
- Release incoming messages for delivery
- Assignment of input serial number
- Acknowledgement to originator
- Enqueuing of distribution and storage
o M̲e̲s̲s̲a̲g̲e̲ ̲O̲u̲t̲p̲u̲t̲ ̲S̲u̲b̲s̲y̲s̲t̲e̲m̲
- Output of all kinds of messages to printer
devices and to hosts and external networks.
- Output queue handling, delivery according to
priority.
- Outgoing statistics, reporting, journalization
- Message burn in case of burn limit excess
- Assignment of serial output no.
- Output to "drain device" (disc, tape)
o M̲e̲s̲s̲a̲g̲e̲ ̲E̲n̲t̲r̲y̲ ̲S̲u̲b̲s̲y̲s̲t̲e̲m̲ ̲(̲M̲E̲S̲)̲
- Interactive message entry/message edit
- Interactive retrieval
- Release of entered/retrieval/edited messages.
o M̲e̲s̲s̲a̲g̲e̲ ̲D̲i̲s̲t̲r̲i̲b̲u̲t̲i̲o̲n̲ ̲S̲u̲b̲s̲y̲s̲t̲e̲m̲ ̲(̲M̲D̲S̲)̲
- Distribution according to
1. address list (tx.no)
2. alternate/duplicate delivery
- For distribution to SITA/ARINC:
1. check message length and address
multiplicity (intercept if overrun)
2. Strip addresses already delivered.
- Enqueuing for delivery according to message
priority
- Enqueuing for drain
o S̲t̲o̲r̲a̲g̲e̲ ̲a̲n̲d̲ ̲R̲e̲t̲r̲i̲e̲v̲a̲l̲ ̲S̲u̲b̲s̲y̲s̲t̲e̲m̲ ̲(̲S̲R̲S̲)̲
- Storage of accepted messages
- Retrieval catalog
- Retrieval of messages and log/journal
o S̲u̲p̲e̲r̲v̲i̲s̲o̲r̲y̲ ̲F̲u̲n̲c̲t̲i̲o̲n̲s̲ ̲S̲u̲b̲s̲y̲s̲t̲e̲m̲ ̲(̲S̲F̲S̲)̲
- Monitoring (alarms, event logging)
- Control (table handling, device control, storage
control)
- Message Repair functions
o E̲l̲e̲c̲t̲r̲o̲n̲i̲c̲ ̲M̲a̲i̲l̲ ̲S̲e̲r̲v̲i̲c̲e̲ ̲S̲u̲b̲s̲y̲s̲t̲e̲m̲ ̲(̲E̲M̲S̲)̲
- Resource Management
- Allocation of queues, discfiles, controlblocks
- Storage/Retrieval
- Access of queues, files, controlblocksd
S̲t̲a̲n̲d̲a̲r̲d̲ ̲S̲o̲f̲t̲w̲a̲r̲e̲
- Ref. CR80 handbook.
Figure 6.12.2-1
T B D
6.12.2.1 T̲D̲P̲ ̲T̲R̲A̲F̲F̲I̲C̲ ̲H̲A̲N̲D̲L̲I̲N̲G̲ ̲S̲U̲B̲S̲Y̲S̲T̲E̲M̲
The TDP Subsystem handles the tranfer of non-ATA/IATA
messages and non-telex messages (tickets, airway bills
etc.). The transfer session is initiated from the originating
host. The host has to provide the following informations:
- Destination printer address (mandatory)
- Delivery priority level (optional)
- Message burn time (optional)
The message is stored on a TDP message file. This file
is a wrap-around file. Accountability check for delivery
is provided on the file, but no retrieval features
are provided. In case of TDP message non-delivery (no
burn time specified) on wrap-around the message is
copied to a background garbage collection file for
TDP traffic and an alarm is generated to the EMH supervisor.
The TDP message is enqueued to the output device according
to priority. Output is performed by the MOS. The TDP
message stays in the queue until it is delivered to
the output device or burnt. When successfully stored
on disc the message is acknowledged to the originating
host and the session is closed.
6.12.2.2 M̲e̲s̲s̲a̲g̲e̲ ̲A̲n̲a̲l̲y̲s̲i̲s̲ ̲S̲u̲b̲s̲y̲s̲t̲e̲m̲
The MAS handles the analysis and validation of ATA/IATA
messages and telex. Messages entered from terminals,
hosts or external networks are stored on temporary
storage and analyzed by the MAS.
The ATA/IATA messages are syntactically checked as
described in section 6.9.1. The addresses are looked
up and stored on binary form in controlblocks for the
MDS. Telex messages are recognized on the 2 first letters:
'TX'. TX-Number or mne monic addresses are looked up
and stored on binary form as for ATA/IATA messages.
In case of any format error or invalid address the
message is rejected back to the originating terminal
or sent for repair in case of origination from hosts
or external networks.
When checked the message is released for delivery by
the MDS and enqueued for storage by the SRS. Serial
input no. is assigned to the message and acknowledgement
to the originator is returned.
6.12.2.3 M̲e̲s̲s̲a̲g̲e̲ ̲O̲u̲t̲p̲u̲t̲ ̲S̲u̲b̲s̲y̲s̲t̲e̲m̲
The MOS is the server process of all output queues.
For each EMH Subscribing device there is a priority
output queue (6 priority levels are recognized including
the levels of ATA/IATA messages).
The output queues are the only queues of significant
lengths. No hard limits are put on the queue size,
but queue thresholds may be specified by the EMH supervisor.
System queue capacity is only limited by the disc capacity.
The output queues are served in priority order per
device. The messages stay in the queues until the device
is ready to receive.
If a "burn time" is specified (TDP traffic) the message
is burnt, i.e. discarded, in case of burntime excess.
When successfully output the output serial number is
added to the retrieval catalog.
Output to a device depends on the device status. This
status is currently maintained by automatic supervisory
functions and the interactive supervisory function.
The status of a device may be one of the following:
- Device online/offline/failed-open circuit
- Hold traffic
- Alternative/duplicate route specified
- Drain file specified.
Note that MOS serves as well printers as hosts and
external networks.
6.12.2.4 M̲e̲s̲s̲a̲g̲e̲ ̲E̲n̲t̲r̲y̲ ̲S̲u̲b̲s̲y̲s̲t̲e̲m̲ ̲(̲M̲E̲S̲)̲
The MES handles the interactive procedures for EMH
users specified in section 4.9.5.2.3 "Message Entry
Handling". The following procedures are supported:
- Enter message (ENT)
- Retrieve Message for hardcopy output (RTR)
- Retrieve for display (RTD)
- Edit message (EDI)
- Release edited message for delivery (REL)
After release/entry of message the message is enqueued
for analysis by the MAS.
6.12.2.5 M̲e̲s̲s̲a̲g̲e̲ ̲D̲i̲s̲t̲r̲i̲b̲u̲t̲i̲o̲n̲ ̲S̲u̲b̲s̲y̲s̲t̲e̲m̲
The MDS is responsible for the automatic distribution
of the messages to the output queues.
The distributioon is performed on basis of the binary
addressed looked up by MAS or TDP. Based on the output
addresses the MDS distributes so that:
- the message is enqueued once per output device
- no message is enqueued to the originating printer,
host of external network
- alternate or duplicate delivery is handled
- for delivery to SITA/ARINC the message is checked
for length and address multiplicity.
Furthermore address stripping is performed.
6.12.2.6 S̲t̲o̲r̲a̲g̲e̲ ̲a̲n̲d̲ ̲R̲e̲t̲r̲i̲e̲v̲a̲l̲ ̲S̲u̲b̲s̲y̲s̲t̲e̲m̲
The SRS is the access subsystem to the long term storage.
Long term storage is provided for at least 8 busy hours
traffic, ref. section 3.5.3. The messages are stored
sequentially and accessed via a retrieval catalog with
the retrieval keys:
- Time, time range
- Originating & destination terminals
- Input serial no.
- Output serial no.
The message file is a wrap-around file. Space for storage
is provided by deletion of old messages corresponding
to 1 busy hour. During deletion it is checked in the
catalog whether the message has been delivered or not
(serial output no. added for each destination). In
case of non-delivery the message is copied to a background
garbage collection file for PMS traffic and a report
is generated to the EMH supervisor. All open queue
references are removed.
As mentioned the retrieval catalog acts as a journal
file which provides for message accountability and
as a checkpoint carrier to be used during recovery
after switchover.
The following events are journalized:
- When the message has been stored
- When the message has been transmitted to an output
device
- When the message is cancelled from a queue
Retrieval takes place using the above specified retrieval
keys. The following keys must at least be specified:
o Time, time range and terminal id
or o Terminal id and input ser.no.
or o Terminal id and output ser.no.
or o a combination of the above keys.
The time used for retrieval will of course depend on
how specific the retrieval keys are. If more than 5
matches are found the operator is requested for more
specific keys - ref. section 4.9.5.2.3.
6.12.2.7 S̲u̲p̲e̲r̲v̲i̲s̲o̲r̲y̲ ̲F̲u̲n̲c̲t̲i̲o̲n̲s̲ ̲S̲u̲b̲s̲y̲s̲t̲e̲m̲ ̲
The SFS handles the interactive procedures for EMH
supervisors as specified in section 4.9.5.2.4 "Message
Repair Function" and 4.9.5.3 "EMH Supervisory Functions".
Furthermore the SFS handles the control messages to
and from the NCC automatically. The messages comprises
the following functions:
- On-line table updates
- Device control
- Statistics, reporting
- Delivery control.
6.12.2.8 E̲l̲e̲c̲t̲r̲o̲n̲i̲c̲ ̲M̲a̲i̲l̲ ̲S̲e̲r̲v̲i̲c̲e̲ ̲S̲u̲b̲s̲y̲s̲t̲e̲m̲ ̲a̲n̲d̲ ̲S̲t̲a̲n̲d̲a̲r̲d̲ ̲S̲o̲f̲t̲w̲a̲r̲e̲
Means for development of electronic mail applications
are provided as specified in section 4.9.5.4 "Electronic
Mail Services".
