top - download
⟦ba35468e5⟧ Wang Wps File
Length: 68661 (0x10c35)
Types: Wang Wps File
Notes: CPS/SDS/025
Names: »1616A «
Derivation
└─⟦c333b847f⟧ Bits:30005811 8" Wang WCS floppy, CR 0118A
└─ ⟦this⟧ »1616A «
WangText
…00……00……00……00…<…0a……00……00…<…0b…<…0f…<
<…06…;…0d…;…0e…;…0f…;…00…;…06…:…0a…:…0f…:…00…:…06…9…09…9…0a…9…01…9…02…9
8…09…8…01…8…07…7…0f…7…02…7
7…07…6…0d…6 5…0b…5…0c…5…0d…5…0e…5…0f…5…05…4…0c…4…01…4…06…4…07……86…1 …02… …02… …02…
…02…CPS/SDS/025
…02…850401…02……02…
MESSAGE MANAGEMENT
DETAILED DESIGN SPECIFICATION …02…ISSUE 1…02…CAMPS
1̲ ̲ ̲G̲E̲N̲E̲R̲A̲L̲
1.1 P̲U̲R̲P̲O̲S̲E̲ ̲A̲N̲D̲ ̲S̲C̲O̲P̲E̲
The package specification for Message Management System
is written to fulfill the following objectives:
a) To provide detailed definition of the package function
and architecture.
b) To provide users with detailed parameter information
for all commands to MMS.
1.2 A̲P̲P̲L̲I̲C̲A̲B̲L̲E̲ ̲D̲O̲C̲U̲M̲E̲N̲T̲S̲ ̲A̲N̲D̲ ̲P̲R̲O̲J̲E̲C̲T̲ ̲R̲E̲F̲E̲R̲E̲N̲C̲E̲S̲
1.2.1 A̲p̲p̲l̲i̲c̲a̲b̲l̲e̲ ̲D̲o̲c̲u̲m̲e̲n̲t̲s̲
a) CPS/210/SYS/001
CAMPS System Requirement Specificaction
b) CPS/ICD/009
Software Interface Control Document
c) CPS/DBD/001
Database Design Document
d) CSS/920/SPS/0001
File Management System
System Product Specification
e) CSS/920/PSP/0046
FMS Command Controller
Product Specification
f) CSS/920/PSP/0047
FMS Disk Cache Manager
Product Specification
g) CSS/3200/PSP/0026
DAMOS Transfer Module
Product Specification
h) CPS/SDS/024
CAMPS SYSTEM FUNCTIONS
Detailed Design Specification
i) CSS/006/PSP/0044
DAMOS System Specification
j) CSS/3900/PSP/0033
DAMOS Coroutine Monitor
Product Specification
1.2.2 P̲r̲o̲j̲e̲c̲t̲ ̲R̲e̲f̲e̲r̲e̲n̲c̲e̲s̲
N/A
1.3 T̲E̲R̲M̲S̲ ̲A̲N̲D̲ ̲A̲B̲B̲R̲E̲V̲I̲A̲T̲I̲O̲N̲S̲
1.3.1 T̲e̲r̲m̲s̲
Retire: A process suspends its own activity by
calling the KERNEL function RETIRE.
Trusted: A KERNEL term.
A trusted process is allowed to decrease
the security level of stored information.
1.3.2 A̲b̲b̲r̲e̲v̲i̲a̲t̲i̲o̲n̲s̲
AHC Active Handle Count
BLE BLOCK LIST ELEMENT
CIF CAMPS Information File
CIF ID CIF Identification
CIFCB CIF Control Block
CKP Checkpoint
CMON Coroutine Monitor
CSF CAMPS System Functions
CTRL Command Controller
DAMOS CR80D Advanced Multiprocessor Operating
System
DC Disc Cache
DCM Disk Cache Manager
DMA Direct Memory Access
FBM Free Block Map
FD Field Descriptor
FDCB File Description Control Block
FM File Manager
FMS File Management System
ID Identification
IOS I/O System
ITS Intermediate Storage
LCD Long Term Storage CIF Directory
LTS Long Term Storage
MMON Message Monitor
MMS Message Management System
OCD On-line CIF Directory
PBM Purge Block Map
PHC Passive Handle Count
PU Processing Unit
SEL Synchronization Element
SSC System Status and Control
STS Short Term Storage
VCB View Control Block
XFER KERNEL Data Transfer Module
2̲ ̲ ̲S̲U̲M̲M̲A̲R̲Y̲ ̲O̲F̲ ̲R̲E̲Q̲U̲I̲R̲E̲M̲E̲N̲T̲S̲
2.1 P̲A̲C̲K̲A̲G̲E̲ ̲D̲E̲S̲C̲R̲I̲P̲T̲I̲O̲N̲
M̲essage M̲anagement S̲ystem contains facilities for storage
of messages and similar items on disk and manipulation
of these messages and items.
Each item is stored in an entity called CAMPS Information
File. The main difference between a CIF and an ordinary
file is that CIFs are relatively small, and that they
are subject to very intense activity during a relatively
short period after their creation. After that period
they will be stored permanently, and will be subject
to very low activity. MMS will optimize storage of
and access to items according to the activity level.
2.1.1 P̲a̲c̲k̲a̲g̲e̲ ̲I̲n̲t̲e̲r̲r̲e̲l̲a̲t̲i̲o̲n̲s̲
2.1.1.1 A̲p̲p̲l̲i̲c̲a̲t̲i̲o̲n̲ ̲P̲a̲c̲k̲a̲g̲e̲s̲
MMS executes in a process separate from the application
processes requesting its service. The application processes
shall access MMS via Message Monitor in CSF, cf. reference
h. The process communication is done via s̲ynchronization
e̲l̲ements. On the appplication side the SEL communication
is performed by Message Monitor. On the MMS side the
commands from IOS and MMON are received in the same
SEL by the File Management System Command Controller.
FMS commands from IOS are then sent to FMS while MMS
commands from MMON are sent to MMS. See figure 2.1.1-1.
CIFs reside on disk volumes which normally contain
a number of files too. The necessary volume handling
is done by commands to FMS. They are issued by SSC
and Supervisor Package. Volume handling and other System
functions are performed by operating system using the
same interface as application packages.
2̲.̲1̲.̲1̲.̲2̲ D̲M̲A̲ ̲D̲a̲t̲a̲ ̲T̲r̲a̲n̲s̲f̲e̲r̲
Data transfers between MMS, application processes and
Disk Controller Memory are done by DMA using the KERNEL
XFER module.
See figure 2.1.1-2.
Figure 2.1.1-1
Figure 2.1.1-2
2.2 P̲A̲C̲K̲A̲G̲E̲ ̲F̲U̲N̲C̲T̲I̲O̲N̲S̲
2.2.1 M̲a̲i̲n̲ ̲F̲u̲n̲c̲t̲i̲o̲n̲s̲
2.2.1.1 S̲t̲o̲r̲a̲g̲e̲ ̲S̲t̲r̲u̲c̲t̲u̲r̲e̲
MMS will recognize three different types of storage:
a) S̲h̲o̲r̲t̲ ̲T̲e̲r̲m̲ ̲S̲t̲o̲r̲a̲g̲e̲
A "fast access" storage area where a CIF can be
kept during the first part of its lifetime.
CIFs in Short Term Storage may be read, updated
or deleted.
CIFs in Short Term Storage will be organized in
a way facilitating fast access and update to individual
fields. This is done by letting each field start
at a sector boundary. In this way fields may be
expanded and updated without implied reading or
copying of other fields. Cf. Section 2.2.1.3.
When a field is extended, storage space will be
allocated in blocks of several sectors in order
to minimize the number of disk operations required
to read and write the entire field or CIF. Block
size is defined during formatting of MMS areas.
b) L̲o̲n̲g̲ ̲T̲e̲r̲m̲ ̲S̲t̲o̲r̲a̲g̲e̲
CIFs which have completed the initial processing
cycle will be put in Long Term Storage.
CIFs in Long Term Storage may be read or deleted.
Deletion can only take place by deleting a complete
volume.
As the CIFs in long term storage will not be updated,
they will be stored in a packed form taking up
as little space as possible.
Long Term Storage will reside on a number of removable
disk volumes.
c) I̲n̲t̲e̲r̲m̲e̲d̲i̲a̲t̲e̲ ̲S̲t̲o̲r̲a̲g̲e̲
Intermediate Storage is always on-line and serves
as a sort of a spooling area between Short Term
and Long Term Storage.
Short Term Storage and Intermediate Storage will
together be called Online Storage.
A CIF is called p̲e̲r̲m̲a̲n̲e̲n̲t̲ if it is subject to storage
in Long Term Storage. CIFs which are not permanent
will be called t̲e̲m̲p̲o̲r̲a̲r̲y̲.
The possible transfers between storage types are shown
on figure 2.2.1.1-2. The transfer functions have the
following meaning:
d) D̲u̲m̲p̲
Makes a copy of a CIF in a Dump File in Long Term
Storage.
e) R̲e̲t̲r̲i̲e̲v̲e̲
Makes a copy of part of a CIF in Short Term Storage.
f) U̲n̲l̲o̲a̲d̲
Makes a copy of a CIF in Intermediate Storage and
deletes the copy held in Short Term Storage.
STORAGE
TYPE SHORT TERM INTERMEDIATE LONG
TERM
CHARAC-
TERISTICS
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
PERMITTED ACCESS CREATE, DELETE RETRIEVE RETRIEVE
READ, WRITE
RETRIEVE
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
PERMITTED CIF TEMPORARY PERMANENT PERMANENT
KINDS PERMANENT
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
RESIDENCE PERIOD HOURS DAYS MONTHS
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
ACCESSABILITY ONLINE ONLINE OFFLINE, MOUNTED
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
OVERHEAD OF ACCESS NO EXTRA DISK EXTRA DISK MOUNTING
OF
VO-
ACCESSES RE- ACCESSES MAY LUME PLUS EXTRA
QUIRED BE REQUIRED DISK ACCESSES MAY BE
REQUIRED
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
APPROXIMATE 6 M BYTES 32 M BYTES EACH VOLUME
STORAGE SIZE 45 M BYTES
IN CAMPS
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
FIGURE 2.2.1.1-1…01…STORAGE TYPE CHARACTERISTICS
figure 2.2.1.1-2
2.2.1.2 C̲I̲F̲ ̲D̲i̲r̲e̲c̲t̲o̲r̲i̲e̲s̲
On-line Storage and Long Term Storage will contain
directories used to retrieve the stored CIFs.
A directory is a table with an entry for each retrievable
CIF in a certain part of the storage. The directory
entry is referenced by CIF ID, cf. section 2.2.1.5,
and contains a reference to stored CIF, enabling MMS
to retrieve the CIF by CIF ID. Only permanent CIFs
can be retrieved, and a CIF can only be retrieved when
MMS has received at least one STORE command for the
CIF, cf. section 2.2.1.5.
2.2.1.3 C̲I̲F̲ ̲a̲n̲d̲ ̲V̲i̲e̲w̲ ̲S̲t̲r̲u̲c̲t̲u̲r̲e̲
2.2.1.3.1 C̲I̲F̲s̲,̲ ̲F̲i̲e̲l̲d̲s̲ ̲a̲n̲d̲ ̲V̲i̲e̲w̲s̲
2.2.1.3.1.1 F̲i̲e̲l̲d̲
A f̲i̲e̲l̲d̲ is an unstructured, variable length byte string.
A field must be member of one and only one f̲i̲e̲l̲d̲ g̲r̲o̲u̲p̲.
2.2.1.3.1.2 F̲i̲e̲l̲d̲ ̲G̲r̲o̲u̲p̲
A field group is a set of fields which are considered
to be different incarnations of the same logical field.
The fields within a field group need not have any other
relationship other than being members of the same group.
The number of fields in a group may be dynamically
changed by creation of new fields or deletion of existing
ones.
The fields within a field group are identified by sequential
numbers. The field number is allocated when the field
is created.
A field group must be member of exactly one CIF.
2.2.1.3.1.3 C̲I̲F̲
A CIF is a set of field groups. The number of field
groups is fixed, and defined at CIF creation time.
The field groups within a CIF are identified by sequential
numbers. Fields are identified by the pair of field
group number and field number within the group.
A field group within a CIF is considered existing even
if it is empty.
Field Numbers and Field Group Numbers are not known
outside MMS. Fields are referenced indirectly via
Views.
FIGURE 2.2.1.3-1
2.2.1.3.1.4 V̲i̲e̲w̲
A view is a subset of the fields within a CIF. A view
consists of at most one field from each field group
of the CIF. A view is represented by a list of field
identifications.
A view is said to r̲e̲f̲e̲r̲e̲n̲c̲e̲ a field if the field is
contained in the view. The same field may be referenced
by several views.
A view is said to reference a field group if it references
a field from the group. A view may then reference all
field groups of the CIF or it may reference a subset
of the field groups.
The views associated with one CIF form a tree structure
by a "successor" relation. A successor of a view is
created by the CREATE VIEW function, which must have
an existing view as parameter. This view will be called
the "predecessor" of the created view.
The first view associated with a CIF is automatically
created together with the CIF. It references all the
field groups of the CIF.
A view can only reference a subset of the f̲i̲e̲l̲d̲ ̲g̲r̲o̲u̲p̲s̲
referenced by its predecessor.
One of the aims of the design presented in the following
is that the successor tree of a CIF should as close
as possible show the processing flow of the CIF through
CAMPS.
Figure 2.2.1.3-2 shows the CIF in figure 2.2.1.3-1
with 2 views. View 2 is succession of view 1.
Figure 2.2.1.3-3 shows a successor tree of views for
the CIF in figure 2.2.1.3-1. The views e and i are
views 1 and 2 respectively on figure 2.2.1.3-2. An
x in a field id indicates that the corresponding field
group is not referenced by the view.
FIGURE 2.2.1.3-2
Figure 2.2.1.3-3
2.2.1.3.2 C̲r̲e̲a̲t̲i̲o̲n̲ ̲a̲n̲d̲ ̲D̲e̲l̲e̲t̲i̲o̲n̲
The commands referred to in this section are further
described in the interface specifications in ref. b.
2.2.1.3.2.1 C̲I̲F̲ ̲C̲r̲e̲a̲t̲i̲o̲n̲ ̲a̲n̲d̲ ̲D̲e̲l̲e̲t̲i̲o̲n̲
CREATE CIF command creates a new, initially empty,
CIF. Parameters specify attributes, such as security,
permanency and number of field groups. A CIF ID is
returned for permanent CIFs.
Each field group will be created with one field of
initial length zero. A view will be created too. It
consists of the first field in each field group. This
view will be the root of the successor tree for the
CIF.
There is no direct way of deleting a CIF. It ceases
to exist when all its fields have been deleted.
2.2.1.3.2.2 V̲i̲e̲w̲ ̲C̲r̲e̲a̲t̲i̲o̲n̲ ̲a̲n̲d̲ ̲D̲e̲l̲e̲t̲i̲o̲n̲
The following description uses fig. 2.2.1.3-3 as example.
The first view of a CIF is automatically created together
with the CIF. It references field no. 1 of each field
group (cf. fig. 2.2.1.3-3, a) and constitutes the root
of the successor tree.
Except from the root view, new views of a CIF are created
by the CREATE VIEW command with the following parameters:
Input: Predecessor
Field Information
The predecessor parameter specifies an existing view,
and "field information" specifies those field groups
which shall be referenced by the new view. The set
of field groups must be a subset of those referenced
by the predecessor view.
For each of the referenced field groups there are two
choices regarding the field to be referenced. It can
either be the corresponding field of the predecessor
view, or it can be a completely new field. In the latter
case the field group is extended with a new field.
Note that the view can only reference existing fields
from its predecessor view. So there is for example
no possibility to create a mixture of two views. Such
a mixture can, however, be obtained by c̲o̲p̲y̲i̲n̲g̲ of fields,
as field contents is not controlled.
The fields of the new view can be defined in "field
information" or can be defined successively by calling
the CREATE FIELDS function. It specifies fields of
the predecessor view to be included and field groups
which shall be extended with new fields. For each field
group it can only be defined once if the field shall
be included or created.
As there may be several active branches in the successor
tree, there is no direct connection between the field
number referenced by the predecessor and the number
allocated by CREATE FIELDS. Figure 2.2.1.3-3 shows
how several branches can intermix creation of new fields.
The letters attached to the views indicate the sequence
in which the views are created.
A view is removed by the REMOVE VIEW or the SAVE command.
These commands are generated by MMON and cannot be
called directly by an application. The criteria for
calling are defined by MMON. Note that each Remove
View command only removes an active handle for the
view. Refer 2.2.1.7.2 c.
2.2.1.3.2.3 F̲i̲e̲l̲d̲ ̲C̲r̲e̲a̲t̲i̲o̲n̲ ̲a̲n̲d̲ ̲D̲e̲l̲e̲t̲i̲o̲n̲
A field is created as a result of one of the following
commands:
- CREATE CIF creates the first field of each field
group
- CREATE VIEW and CREATE FIELDS can extend one or
more field groups with a new field.
The created fields are initially empty, and it is the
responsibility of the application processes to build
the contents of each field.
A field cannot be directly deleted. It will exist as
long as there is at least one view referencing it.
When the last referencing view is deleted, however,
the field is deleted. In figures 2.2.1.3-1, 2, and
3 the fields 3.2, 4.1, and 4.2 have once existed, but
they have been deleted together with the referencing
views. One must thus imagine that in figure 2.2.1.3-2
some more views have been in existence. They might
for example have been used as intermediate drafts for
the CIF in question.
2.2.1.3.3 F̲i̲e̲l̲d̲ ̲A̲c̲c̲e̲s̲s̲
Fields are manipulated and accessed by application
processes. A field can only be accessed via one of
the views referencing the field.
Similar to FM, MMS will impose two types of controls
to field access:
- Security Control consists of comparing the security
profiles of the CIF and the requesting process.
- Access Control consists of checking if the requested
process has been granted permission to perform
the requested access.
While FM uses the User Group concept for Access Control,
MMS relies on MMON for Access Control, except for control
of field access rights associated with views, as described
in the following.
There are two different types of access rights to a
field:
- Read access only allows to read the contents of
the field.
- Write access allows to update the contents of the
field either by changing the current contents or
by appending information to the field.
Each view referencing a field has an attached set of
access rights to the field. It can either have read
access only or it can have both read and write access.
When a field is created the associated view will automatically
get both read and write access to the field. When a
field is included in a view the "field information"
parameter must for each field group specify the access
rights of the view to the field. The access rights
specified must be a subset of the access rights possessed
by the predecessor. Refer to figure 2.2.1.3-4.
When an application process requests an operation to
be performed on a field, e.g. "read" or "write", it
must do so via a view referencing the field. It is
then checked that the view references the field and
has the proper access right to it.
Figure 2.2.1.3-4 shows creation of a successor view
of view1 on figure 2.2.1.3-2. Field group 2 is excluded
in CREATE VIEW. Field 3.3 is included with specified
access rights AR3'. Field groups 1 and 4 are extended
with fields F1.4 and F 4.4 respectively. Access rights
are automatically set to read a̲n̲d̲ write.
2.2.1.3.4 D̲i̲s̲k̲ ̲S̲p̲a̲c̲e̲ ̲A̲l̲l̲o̲c̲a̲t̲i̲o̲n̲
This section describes the allocation for CIFs in STS.
STS consists of a number of fixed length blocks, each
of which consists of a number of sectors. Disk space
is allocated to a CIF in whole blocks. The sectors
within a block are allocated to the fields of the CIF.
A field has two length variables associated with it.
a) Used Length specifies the number of bytes which
have been written into the field. It may be increased
when new information is added to the field.
b) Allocated Length specifies the number of sectors
allocated to the field.
When performing a Write operation on a field, MMS will
automatically adjust Used Length. This may result in
a need for more disk space, and MMS will then automatically
allocate one or more sectors to the field and adjust
Allocated Length.
In addition to the automatic allocation, it is possible
to preallocate disk space to a field when it is created.
This may increase the probability that the sectors
of the field are placed consecutively on disk and can
thereby be read in a single disk access.
Figure 2.2.1.3-4
2.2.1.4 C̲I̲F̲ ̲A̲t̲t̲r̲i̲b̲u̲t̲e̲s̲
2.2.1.4.1 P̲e̲r̲m̲a̲n̲e̲n̲t̲ ̲C̲I̲F̲
A permanent CIF can be stored in Long Term Storage.
A unique CIF Identification is generated and returned
by CREATE CIF, and an entry is allocated in the On-line
CIF Directory.
A CIF is called temporary if it is not permanent.
For a permanent CIF each field group has an attribute
specifying whether fields in that field group shall
be stored. So a permanent CIF may contain "temporary"
fields.
A permanent CIF will not automatically be transferred
to LTS. Two conditions shall be fulfilled:
a) One or more STORE commands shall be issued for
the CIF
b) A DUMP command shall be issued to transfer the
CIF to a Dump File in LTS.
Cf. section 2.2.1.5.
2.2.1.4.2 R̲e̲c̲o̲v̲e̲r̲a̲b̲l̲e̲ ̲C̲I̲F̲
A permanent CIF can be checkpointed and recovered,
cf. section 2.2.2.
2.2.1.4.3 S̲e̲c̲u̲r̲i̲t̲y̲ ̲P̲r̲o̲f̲i̲l̲e̲
Each CIF has a KERNEL security profile, which is maintained
by MMON.
The use of security profile is described in section
2.2.2.6.
2.2.1.4.4 A̲c̲c̲e̲s̲s̲ ̲P̲r̲o̲f̲i̲l̲e̲
This is the Access Profile attached to a CIF by Message
Monitor in CSF. It is not used by MMS, but delivered
to MMON when appropriate.
2.2.1.4.5 C̲I̲F̲ ̲V̲e̲r̲s̲i̲o̲n̲s̲
It is expected that the normal way to handle different
versions of the same CIF will be to have a number of
different views with separate incarnations of some
or all field groups.
In a few cases it would, however, be appropriate to
define a completely new CIF as the new version, namely
if separate versions will be stored as completely independent
entities and at different points in time.
For this purpose the CIF ID will contain a version
indicator. CREATE CIF will generate version number
1. A command CREATE NEW CIF VERSION will create the
next version of a given CIF. The parameters are:
Input: View Reference (of current version)
Output: View Reference (of new version)
Attributes for the new version
The version delivered as input parameter must be the
latest version. The attributes will be inherited from
the old to the new version.
A CIF ID will thus consist of:
a) A 32 bits CIF REFERENCE NUMBER
b) An 8 bits VERSION INDICATOR
2.2.1.5 C̲I̲F̲ ̲S̲t̲o̲r̲a̲g̲e̲ ̲a̲n̲d̲ ̲R̲e̲t̲r̲i̲e̲v̲a̲l̲
As seen from the applications, views are the entities
which are subject to storage and retrieval.
To s̲t̲o̲r̲e̲ a view means to retain it in the system in
such a way that it can later on be made available.
Stored views are eventually dumped to Long Term Storage.
All the stored views of the same CIF are kept together.
To r̲e̲t̲r̲i̲e̲v̲e̲ a view means to generate a t̲e̲m̲p̲o̲r̲a̲r̲y̲ CIF
containing a copy of the view. The generated CIF will
reside in Short Term Storage.
To d̲u̲m̲p̲ a view means to transfer it to some dump file
in Long Term Storage.
Refer to figure 2.2.1.1-2 for the transfer involved.
2.2.1.5.1 S̲t̲o̲r̲a̲g̲e̲
By definition a view is stored when it is copied from
Short Term Storage to Long Term Storage.
For the purpose of storage, the field groups of the
view are divided into permanent field groups and temporary
field groups. For a temporary CIF, all field groups
are temporary.
Fields belonging to a temporary field group cannot
be stored. A field belonging to a permanent fieldgroup
can be stored, but only if a STORE request is issued
for a view referencing the field.
Storage of a view may be requested by call of the STORE
command with the following parameters.
Input: View Reference
Output: CIF Identification
View identification
Each view of a CIF has a unique identification which
is returned by STORE. It may later on be used as input
to RETRIEVE. STORE will be refused if the CIF is temporary.
STORE will not cause an immediate transfer to Long
Term Storage. The view is, however, marked as candidate
for storage, and the so marked views of a CIF will
eventually be u̲n̲l̲o̲a̲d̲e̲d̲ to Intermediate Storage. Unload
will take place when all views of the CIF have been
logically removed. If a View is marked for storage,
it is namely not physically removed until the CIF is
unloaded.
Unload of a CIF consists of the following steps:
- Collect those views for which one or more STORE
requests have been issued.
- Collect the permanent fields of the collected views.
- Copy the collected views and fields to Intermediate
Storage. Access rights of views are not stored.
- Update the On-line CIF Directory entry allocated
for the CIF.
- Delete the CIF from Short Term Storage.
Note that STORE is not accepted until the CIF has been
checkpointed at least once, refer 2.2.2.2.
2.2.1.5.2 R̲e̲t̲r̲i̲e̲v̲a̲l̲
By retrieval is meant the activity of locating a view,
referenced by CIF ID, View ID and making the view accessible
in Short Term Storage.
Retrieval is done by the RETRIEVE command with the
following parameters:
Input: Context Specifications
CIF ID
View ID
Output: View Reference
The Context Specification defines to MMS the directory
which shall be searched for CIF ID. It can be the On-line
CIF Directory or some Long Term Storage Directory.
The view id must have been obtained from a previous
STORE request.
The retrieved view will automatically be furnished
with read and write access right to all its fields,
and the retrieved CIF will automatically be temporary.
figure 2.2.1.5-1
FIGURE 2.2.1.5-2
Figure 2.2.1.5-3
2.2.1.6 C̲I̲F̲ ̲a̲n̲d̲ ̲V̲i̲e̲w̲ ̲R̲e̲f̲e̲r̲e̲n̲c̲i̲n̲g̲
Except for Storage and Retrieval functions, a CIF can
only be accessed when it resides in Short Term Storage.
A CIF in Short Term Storage can only be referenced
via one of its views.
A view of a passive CIF is referenced by a View Id.
Refer 2.2.1.7.
A view of an active CIF is referenced by a View Reference,
which is an integer. The View Reference is different
from the View ID.
The CIF ID used for storage and retrieval consists
of a 32 bit CIF REFERENCE NUMBER and an 8 bit VERSION
INDICATOR. A new CIF REFERENCE NUMBER is generated
each time a new CIF is created by the CREATE CIF command.
2.2.1.7 A̲c̲t̲i̲v̲e̲ ̲a̲n̲d̲ ̲P̲a̲s̲s̲i̲v̲e̲ ̲C̲I̲F̲s̲
A CIF in STS can be active or passive.
An active CIF has a memory resident control structure
describing the structure of the CIF in Views and Fields,
and the disk areas occupied by the fields. It can
be accessed directly without extra disk accesses.
A passive CIF has no memory resident control structure.
The structure and address information for the CIF
resides in a checkpoint on disk. It can not be accessed
directly. Only a permanent CIF can be made passive.
An active CIF is known by MMON in CSF, as MMON will
have one or more Handles representing views of the
CIF.
A passive CIF is not known by MMON. It can however
be made available by the LOOKUP command with the parameters:
Input: CIF Id
View Id
Output: View Reference
This command will make the CIF active and return a
reference to the specified view. This reference can
now be used for accessing the CIF as described previously.
2.2.1.7.1 H̲a̲n̲d̲l̲e̲s̲
The state transitions between active and passive are
controlled by socalled Handles. So is the determination
of when to unload a CIF.
A handle to a CIF may be thought of as a hook, keeping
the CIF in STS. When there are no more handles, the
CIF is unloaded to ITS or deleted depending upon possible
STORE requests, refer 2.2.1.5.1.
There are two kinds of handles, active and passive.
An active handle keeps the CIF active while a passive
handle just keeps it from being unloaded even if there
are no active handles.
Each CIF has an Active Handle Count and a Passive Handle
Count, determining the number of active and passive
handles respectively.
Figure 2.2.1.7-1 shows how CIF states and handle counts
are affected by functions performed upon the CIF. For
each CIF, a pair of values specify active and passive
handle count respectively. X and Y stand for integers
greater than zero. In the following AHC and PHC are
used as abbreviations for active and passive handle
counts respectively.
2.2.1.7.2 C̲o̲m̲m̲a̲n̲d̲s̲ ̲A̲f̲f̲e̲c̲t̲i̲n̲g̲ ̲H̲a̲n̲d̲l̲e̲s̲
a) C̲I̲F̲ ̲C̲r̲e̲a̲t̲i̲o̲n̲
The CIF is created by CREATE CIF or CREATE NEW
CIF VERSION commands. The AHC is set to one and
PHC to zero.
b) V̲i̲e̲w̲ ̲C̲r̲e̲a̲t̲i̲o̲n̲
The CREATE VIEW command creates a new active handle,
thus incrementing AHC.
c) H̲a̲n̲d̲l̲e̲ ̲D̲e̲l̲e̲t̲i̲o̲n̲
The Remove Handle function removes an active handle,
thus decrementing AHC. The function can be invoked
by two different commands:
c1) REMOVE VIEW
Removes one active handle
c2) SAVE
Removes a number of active handles, specified by
a parameter "Remove Handle List". Refer 2.2.2.2.1.1
c.
Those commands are not called directly from application
processes, but called by MMON as a result of the
Dismantle View or Save View commands.
d) L̲o̲c̲k̲
The LOCK VIEW command creates a passive handle,
thus incrementing PHC.
e) U̲n̲l̲o̲c̲k̲
The UNLOCK VIEW command removes a passive handle,
thus decrementing PHC.
f) L̲o̲o̲k̲u̲p̲
The LOOKUP command creates an active handle for
a CIF having at least one passive handle. It thus
increments AHC.
2.2.1.7.3 C̲I̲F̲ ̲S̲t̲a̲t̲e̲ ̲T̲r̲a̲n̲s̲i̲t̲i̲o̲n̲s̲
The state transitions between active, passive and unloaded
are controlled by PHC and AHC as shown on figure 2.2.1.7-1.
a) An active CIF is made passive, if PHC is nonzero,
and AHC changes from one to zero.
b) A passive CIF is made active, if AHC changes from
zero to one.
c) An active CIF is unloaded, if PHC is zero, AHC
changes from one to zero, and there has been at
least one STORE request. If there has been no
STORE requests, it is just deleted.
2.2.1.7.4 H̲a̲n̲d̲l̲e̲s̲ ̲a̲n̲d̲ ̲C̲h̲e̲c̲k̲p̲o̲i̲n̲t̲s̲
Passive Handles do not apply to temporary CIFs. Thus
retrieved CIFs can in particular not have passive handles,
and can thus not move left in the diagram on figure
2.2.1.7-1.
Also a passive handle cannot be created for a CIF until
it has been checkpointed at least once, refer 2.2.2.2.
The LOCK command can thus not be issued until the
first SAVE command has been made.
2.2.1.7.5 R̲e̲l̲a̲t̲i̲o̲n̲ ̲t̲o̲ ̲D̲u̲m̲p̲
Refer to figure 2.2.1.1-2 and 2.2.1.5.
A CIF, for which at least one STORE command has been
issued, can be dumped in any of the states active,
passive or unloaded.
2.2.1.7.6 H̲a̲n̲d̲l̲e̲s̲ ̲a̲n̲d̲ ̲V̲i̲e̲w̲s̲
Handles are actually associated with views. Each view
has an active and a passive Handle Count. This is
of no importance to the previous description, as AHC
and PHC are just the sums of the respective handle
counts for all views of the CIF.
Fig. 2.2.1.7-1
2.2.1.8 F̲i̲l̲e̲ ̲M̲a̲n̲a̲g̲e̲m̲e̲n̲t̲
The disk areas used by MMS are all organized as ordinary
contiguous files. Refer (i) 3.5. There are two kinds
of MMS Files:
a) M̲M̲S̲ ̲O̲n̲l̲i̲n̲e̲ ̲F̲i̲l̲e̲
This is a file on Online Disk holding STS, ITS,
and OCD.
b) D̲u̲m̲p̲ ̲F̲i̲l̲e̲
This is a file on an offline volume holding a set
of dumped CIFs. There may be several dump files
on each volume. Refer 2.2.1.1.
The files shall have the highest security classification
and be protected from access via FMS from any application
process in the active system. They may however be
accessed by privileged support software in standby
system for error analysis etc.
The files shall however, be created, catalogued and
opened (looked up) by application processes using ordinary
IOS commands:
- MMS Online Files shall be created and opened by
SSC Package.
- Dump Files shall be created and opened by SAR Package.
2.2.1.8.1 F̲i̲l̲e̲ ̲R̲e̲f̲e̲r̲e̲n̲c̲e̲s̲
The MMS files must be made available for MMS before
they can be accessed by MMS commands.
An MMS file shall thus be opened by an application
process, and a reference to the file be given to MMS
before any MMS command accessing the file can be issued.
And the file must be kept open during the period in
which it will be used by MMS as described in the following.
a) M̲M̲S̲ ̲O̲n̲l̲i̲n̲e̲ ̲F̲i̲l̲e̲
The file is created and opened by SSC. The file
reference is given to MMS as a parameter in the
START SYSTEM command. The file must be kept open
by SSC during the active state of the PU.
b) D̲u̲m̲p̲ ̲F̲i̲l̲e̲s̲
A Dump File must be created and catalogued by SAR
before it can be used for dumps. It must be kept
open during the dump process. The file reference
is given to MMS as a parameter in each dump command.
The Dump File must be looked up by SAR before dump
to or retrieval from the file can take place.
The file reference is given to MMS as a parameter
in the DUMP commands and in RETRIEVE command in
case of offline retrieval.
The file reference used by application processes is
FDCB Index returned by IOS in Create File or Lookup
File commands, refer (i) 4.2.4.1 and 4.2.5.2.
The FDCB Index is by MMON converted to a File Descriptor
as used on the IOS-FMS interface, refer (i)
4.3.4.
2.2.2 F̲u̲n̲c̲t̲i̲o̲n̲a̲l̲ ̲R̲e̲s̲p̲o̲n̲s̲i̲b̲i̲l̲i̲t̲i̲e̲s̲
2.2.2.1 I̲n̲i̲t̲i̲a̲l̲i̲z̲a̲t̲i̲o̲n̲,̲ ̲C̲l̲o̲s̲e̲ ̲D̲o̲w̲n̲,̲ ̲a̲n̲d̲ ̲R̲e̲s̲t̲a̲r̲t̲
The first command received by MMS must be the START
command. It is sent by MMON when SSC issues the START
SYSTEM command.
Input parameters to the Start Command are:
- Start-up Type, specifying Dead, Cold or Warm Start.
- File Descriptor referencing the MMS Online File
as specified in 2.2.1.8.
a) D̲e̲a̲d̲ ̲o̲r̲ ̲C̲o̲l̲d̲ ̲S̲t̲a̲r̲t̲
MMS shall initialize Short Term Storage and Intermediate
Storage to the empty state, based on system generation
parameters. Short Term Storage shall be purged.
b) W̲a̲r̲m̲ ̲S̲t̲a̲r̲t̲
MMS shall restore the state of On-line CIF Directory
and Intermediate Storage previous to the stop.
If any activity was in progress in MMS, which temporarily
made the storage inconsistent, this activity shall
be terminated in a way that restores a consistent
state. Refer 2.2.2.4.
CIFs in Short Term Storage shall be recovered as
described in section 2.2.2.2.
2.2.2.2 C̲h̲e̲c̲k̲p̲o̲i̲n̲t̲i̲n̲g̲ ̲a̲n̲d̲ ̲R̲e̲c̲o̲v̲e̲r̲y̲
2.2.2.2.1 C̲h̲e̲c̲k̲p̲o̲i̲n̲t̲s̲
Checkpoints are generated for individual CIFs. There
is no relation between checkpoints for two different
CIFs. Only permanent CIFs in Short Term Storage are
checkpointed.
A checkpoint for a CIF is a collection of information
fulfilling the following objectives:
a) It shall make it possible to restore all information
about the CIF, its fields and views, which is not
always disk resident. This includes disk addressing
information for the CIF fields.
b) It shall contain a "Checkpoint Parameter" section
where Message Monitor data about queues etc. shall
be kept.
For a passive CIF the Checkpoint Parameter section
is empty, and the checkpoint contains the information
needed to make the CIF active, refer 2.2.1.7.
A checkpoint will not contain data of the CIF, as all
data reside in fields on disk.
The recovery model for MMS is based on the following
assumptions:
1) The processing flow for a CIF consists of a well
defined set of successive steps, where output from
one step serves as input for one or more succeeding
steps.
2) It is possible to record in a checkpoint the CIF
state resulting from a step in such a way that
the CIF may after a system failure be "rolled back"
to the beginning of latest step initiated before
the failure.
A sufficient but not necessary condition for this to
be true is:
3) A processing step will only modify a CIF by appending
to one or more of its fields. In that case the
state prior to the beginning of the step may be
restored by simply resetting field lengths to their
values at the beginning of the step.
A relaxed condition is that updates of any field does
not overwrite any information which is used as input
to a processing step after the checkpoint which the
CIF can be rolled back to.
It is the responsibility of application module designers
to identify processing steps and to request MMS checkpointing
of appropriate CIFs at appropriate points in processing
flow.
A checkpoint is requested by the Message Monitor call
SAVE VIEW.
2.2.2.2.1.1 S̲A̲V̲E̲ ̲C̲o̲m̲m̲a̲n̲d̲
Generation of a checkpoint is requested by a SAVE command
from MMON to MMS with the following parameters:
a) A list of views of the same CIF. Those views shall
be included in the checkpoint. The list may be
empty.
b) A Checkpoint Parameter block which shall be included
in the checkpoint.
c) A list of views which shall be removed after generation
of the checkpoint. The list may be empty.
2.2.2.2.1.2 C̲h̲e̲c̲k̲p̲o̲i̲n̲t̲ ̲F̲i̲e̲l̲d̲
Checkpoints are recorded as normal data in a Field
Zero of the CIF. This field is not accessible by application
processes.
Subsequent checkpoints for the CIF are recorded in
the field, each overwriting the previous one.
The disk sector containing the start of field zero
is referenced in the OCD entry for the CIF, which is
created when the first SAVE Command is issued for the
CIF.
2.2.2.2.2 R̲e̲c̲o̲v̲e̲r̲y̲ ̲A̲c̲t̲i̲o̲n̲s̲
Recovery action consists of restoring all checkpointed
CIFs in Short Term Storage to the state of the latest
checkpoint, and to delete all other information from
Short Term Storage.
Recovery is performed after MMS initialization when
Message Monitor issues a sequence of RESTORE commands.
Each RESTORE command gives rise to the following actions:
a) Read next used entry in OCD. Continue until an
entry is found which references a CIF in STS.
Read the checkpoint referenced in OCD entry.
b) Reserve the disk blocks in Short Term Storage occupied
by the CIF.
c) Restore the attribute and addressing information
for the CIF, if it was active. Otherwise repeat
steps a) and b).
d) Return the Checkpoint Parameter block to Message
Monitor.
When the complete OCD has been scanned, the Short Term
Storage disk blocks which have not been reserved in
b) above shall be purged.
The checkpoints are not affected by the recovery actions.
Figures 2.2.2.2-1 and 2 illustrate the recovery actions.
Figure 2.2.2.2-1 and 2
2.2.2.3 E̲r̲r̲o̲r̲ ̲D̲e̲t̲e̲c̲t̲i̲o̲n̲ ̲a̲n̲d̲ ̲E̲r̲r̲o̲r̲ ̲H̲a̲n̲d̲l̲i̲n̲g̲
Parameters which are supplied by application processes
shall be checked by both MMS and MMON. Parameters which
shall be checked especially by MMS are:
- Field information
- View Access Rights to fields
- Checkpoint and Handle affecting commands
Errors are signalled by a completion code in response
returned to MMON. The completion code consists of:
- Error classification
- Error code
Error classification has two possible values:
- Serious parameter error
- Nonserious error
Two error classes are serious:
- Security Violations
- Parameter errors which indicate major logical flaws
in calling application. An example is a STORE command
on a non permanent CIF.
Error code defines the error. Serious errors are expected
to result in a retire of the application process by
MMON.
If both online disks fail, it results in a retire of
FMS process. Disk errors on offline volumes are returned
by completion codes.
Section 2.3.3.1 shows a number of design constraints.
Violation of any of them will result in a normal completion
code.
2.2.2.4 I̲n̲t̲e̲g̲r̲i̲t̲y̲ ̲o̲f̲ ̲O̲p̲e̲r̲a̲t̲i̲o̲n̲
Data in On-Line Storage and On-Line CIF Directory shall
be recorded on dualized disk equipment.
In cases where an update of MMS control structures
such as checkpoints and OCD cannot be done in one single
disk access, there may be a risk of inconsistent data
if a system failure occurs during the update. In such
cases MMS shall use update methods enabling a completion
of the update after restart.
The method used is to record in a Recovery Block on
disk the intention to update, and the data needed to
complete the update after restart. Refer 2.2.2.1 b.
2.2.2.5 D̲a̲t̲a̲ ̲C̲o̲l̲l̲e̲c̲t̲i̲o̲n̲
MMS shall collect statistics information which can
be used for Performance Monitoring purposes. The figures
collected are:
- Average number of sectors per read operation.
- Average number of sectors per write operation.
- Average number of sector modifications per write
operation. A sector modification is one requiring
that the sector is read from disk before it is
written again.
- Number of internally generated sector accesses.
This represents the overhead of checkpointing
etc.
- Maximum number of pending commands to MMS.
- Accumulated time in which MMS is idle.
- Accumulated time in which MMS is busy.
This means that if a new command arrives to MMS
it must be queued.
- Number of STORE requests.
- Number of RETRIEVE requests.
The statistics figures are obtained by the STP package
calling the GET MMS STATISTICS function. This will
also cause a reset of the figures.
2.2.2.6 S̲e̲c̲u̲r̲i̲t̲y̲
2.2.2.6.1 S̲e̲c̲u̲r̲i̲t̲y̲ ̲P̲r̲o̲f̲i̲l̲e̲
MMS shall for each CIF maintain a security profile
with 3 compartments:
- Security Classification
- ATOMAL Designator
- ENCRYPTED Designator
Refer (i) 3.2
For compatibility with FMS a security check shall be
performed on each read and write operation to a CIF.
This shall ensure that the normal DAMOS security policy
is followed.
The security profile can be changed by the CHANGE ATTRIBUTES
command.
Only a trusted process can reduce the profile.
2.2.2.6.2 P̲u̲r̲g̲e̲ ̲o̲f̲ ̲D̲i̲s̲k̲ ̲a̲n̲d̲ ̲M̲e̲m̲o̲r̲y̲
A Purge Profile defined at system generation time is
used to control purge of memory buffers and disk blocks.
Deallocated memory buffers and disk blocks shall be
purged if they have been used for certain types of
information.
As part of MMS recovery, non-allocated blocks of STS
shall be purged.
2.2.2.6.3 S̲t̲o̲r̲a̲g̲e̲ ̲C̲o̲n̲t̲r̲o̲l̲
A Store Profile is defined at System Generation Time.
STORE requests will only be accepted for CIFs having
a security profile contained in the Store Profile.
2.2.2.7 S̲t̲o̲r̲a̲g̲e̲ ̲A̲c̲c̲o̲u̲n̲t̲i̲n̲g̲ ̲a̲n̲d̲ ̲M̲o̲n̲i̲t̲o̲r̲i̲n̲g̲
2.2.2.7.1 S̲t̲o̲r̲a̲g̲e̲ ̲O̲c̲c̲u̲p̲a̲n̲c̲y̲
MMS shall maintain figures showing the amount of free
storage area in STS and ITS.
The figures can be obtained by calling the command
GET STORAGE OCCUPANCY.
2.2.2.7.2 T̲h̲r̲e̲s̲h̲o̲l̲d̲ ̲W̲a̲r̲n̲i̲n̲g̲
MMS shall recognize threshold values for the amount
of free storage area in STS and ITS.
The command GET ̲THRESHOLD ̲WARNING shall be returned
by MMS when an threshold is exceeded.
If a warning has been returned, the next one will
not be returned until the storage area has been above
an Enable Threshold.
2.3 C̲H̲A̲R̲A̲C̲T̲E̲R̲I̲S̲T̲I̲C̲S̲
The timing and throughput requirements are based on
the assumption that 95 per cent of all CIFs can be
stored in Short Term Storage with all addressing information
kept in memory.
2.3.1 T̲i̲m̲i̲n̲g̲
The total time used to perform a function is composed
of two parts:
- The CPU time used by MMS, FMS and Disk Handler.
- The time used by the disk system to perform the
physical transfer.
The CPU time includes time for process communication,
DMA transfers and interrupt handling.
Section 2.3.1.1 shows the CPU time used by the major
MMS functions. The total time used to perform a request
can then be calculated by adding the disk transfer
time and the time used by MMON and by FMS Command Controller
and Disk Cache Manager, refer (e) and (f) plus the
time used by the Disk Handler, ref. fig. 2.1.1-1.
2.3.1.1 C̲P̲U̲ ̲U̲s̲a̲g̲e̲
CREATE CIF 4 msec
CREATE VIEW 4 -
READ VIEW 10 -
WRITE VIEW 10 -
SAVE 10 - (+ msec for
STORE 1 - first Save
Command)
…06…1 …02… …02… …02… …02…
2.3.2 T̲h̲r̲o̲u̲g̲h̲p̲u̲t̲
MMS can perform 25 READ VIEW, WRITE VIEW, or RESTORE
commands in a busy second.
2.3.2.1 S̲t̲o̲r̲a̲g̲e̲ ̲C̲a̲p̲a̲c̲i̲t̲y̲
The storage capacity of Short Term Storage is limited
by the need to keep addressing information in memory.
It is assumed that addressing information for active
CIFs is kept in memory, and for inactive CIFs it is
kept on disk. When a CIF becomes active, its addressing
information is transferred to memory.
The average resource requirements for CIFs are assumed
to be:
ACTIVE CIF INACTIVE CIF
Views 3 1
Field Groups 10 5
Fields 13 5
The MMS Short Term Storage Allocation is then:
Active CIFs: 600
Inactive CIFs: 600
The number of active CIFs corresponds to 1 hour of
busy traffic plus 40 items which are under editing.
The Memory Consumption is shown in 2.3.5.
2.3.2.1.1 D̲i̲s̲k̲ ̲C̲o̲n̲s̲u̲m̲p̲t̲i̲o̲n̲
The contents of MMS Online File (refer 2.2.1.8.1) is:
a) S̲h̲o̲r̲t̲ ̲T̲e̲r̲m̲ ̲S̲t̲o̲r̲a̲g̲e̲
800 CIFs of average size 7750 bytes 6.2
MB
b) I̲n̲t̲e̲r̲m̲e̲d̲i̲a̲t̲e̲ ̲S̲t̲o̲r̲a̲g̲e̲
12500 CIFs of average size 2500 bytes 31.3
MB
c) O̲n̲l̲i̲n̲e̲ ̲C̲I̲F̲ ̲D̲i̲r̲e̲c̲t̲o̲r̲y̲
34 Disk Blocks of 4000 bytes 0.2
MB
d) R̲e̲c̲o̲v̲e̲r̲y̲ ̲B̲l̲o̲c̲k̲
1 Disk Block of 4000 bytes
Total size of MMS Online File: 38
MB
2.3.3.1 M̲M̲S̲ ̲D̲e̲s̲i̲g̲n̲ ̲C̲o̲n̲s̲t̲r̲a̲i̲n̲t̲s̲
The flexibility of MMS is limited by the following
design constraints:
a) Maximum size of a Disk block: 4096 bytes
b) Maximum number of Disk Blocks in
Short Term Storage 32 K
c) Maximum length of one field: 32 K
bytes
d) Maximum number of field groups
in a CIF: 12
e) Maximum number of fields in a field
group 31
f) Maximum number of views referencing
a CIF 31
2.3.4 A̲c̲c̲u̲r̲a̲c̲y̲
Not applicable.
2.3.5 M̲e̲m̲o̲r̲y̲ ̲C̲o̲n̲s̲u̲m̲p̲t̲i̲o̲n̲
The memory requirements for control structures are
estimated as follows:
One CIFCB per CIF 13 words
One VCB per View 10 words
Address information per Field 4 words
Using the estimates of section 2.3.2.1, the following
consumption figures are calculated:
a) Fixed Amount
Working variables 3500 words
Checkpoint buffer 500 words
b) Variable Amount
600 CIFCBs 7800 words
1800 VCBs 18000 words
7800 Field Address Information 31200 words
c) Total Memory Consumption
Program 17500 words
Data 61000 words
3̲ ̲ ̲E̲N̲V̲I̲R̲O̲N̲M̲E̲N̲T̲
3.1 E̲Q̲U̲I̲P̲M̲E̲N̲T̲
MMS executes in one PU with at least one CPU.
MMS cannot utilize more than one CPU concurrently.
Short Term and Intermediate storage are residing on
the same disk, which shall be dualized due to integrity
of operation.
Long Term Storage resides on a number of removable
disks.
3.2 S̲O̲F̲T̲W̲A̲R̲E̲
3.2.1 S̲y̲s̲t̲e̲m̲ ̲S̲o̲f̲t̲w̲a̲r̲e̲
MMS uses the KERNEL and the FMS software packages.
3.2.2 D̲e̲v̲e̲l̲o̲p̲m̲e̲n̲t̲ ̲S̲u̲p̲p̲o̲r̲t̲ ̲S̲o̲f̲t̲w̲a̲r̲e̲
The software used for development of this package is
contained in Support Software Package.
3.3 I̲N̲T̲E̲R̲F̲A̲C̲E̲S̲
3.3.1 E̲x̲t̲e̲r̲n̲a̲l̲ ̲I̲n̲t̲e̲r̲f̲a̲c̲e̲s̲
Not applicable.
3.3.2 P̲a̲c̲k̲a̲g̲e̲ ̲I̲n̲t̲e̲r̲f̲a̲c̲e̲s̲
Not applicable.
3.4 F̲U̲N̲C̲T̲I̲O̲N̲S̲ ̲M̲A̲I̲N̲T̲A̲I̲N̲E̲D̲ ̲B̲Y̲ ̲O̲T̲H̲E̲R̲ ̲P̲A̲C̲K̲A̲G̲E̲S̲
3.4.1 K̲E̲R̲N̲E̲L̲
MMS relies on the protection and process communication
facilities supplied by KERNEL.
3.4.2 F̲M̲S̲
MMS uses FMS facilities for interface to application
processes and disk.
3.4.3 C̲S̲F̲
Message Monitor performs the following tasks connected
to CIF handling:
- Security and Access Control
- Address Parameter Check
- Checkpoint Information Collection
- Recovery Assistance
4̲ ̲ ̲P̲A̲C̲K̲A̲G̲E̲ ̲D̲E̲S̲I̲G̲N̲
4.1 P̲A̲C̲K̲A̲G̲E̲ ̲O̲V̲E̲R̲V̲I̲E̲W̲
4.1.1 F̲u̲n̲c̲t̲i̲o̲n̲a̲l̲ ̲S̲p̲e̲c̲i̲f̲i̲c̲a̲t̲i̲o̲n̲
An overview of MMS functions is given in figure 4.1.1-1.
For details refer to subpackage specifications, section
4.2.
4.1.1.1 S̲e̲c̲u̲r̲i̲t̲y̲ ̲P̲r̲o̲f̲i̲l̲e̲s̲
The security profile in a CAMPS system contains three
compartments:
a) Security Classification, ranging from the value
0 for Unclassified to 4 for CTS.
b) Atomal Designator with values 0 for non-atomal
and 1 for atomal information.
c) Encrypted designator with values for 0 for
non-encrypted and 1 for encrypted information.
There are two purposes of the security profile:
d) To determine if deallocated memory buffers
and disk blocks shall be purged before reuse.
e) To check that the general DAMOS security rules
are followed. As the security and access control
requirements of CAMPS are implemented in CSF
and SSC packages, the DAMOS security rules
are implemented for compatibility reasons with
FMS.
Each CIF has an associated security profile. The profile
is specified in the CREATE CIF command and may be changed
by the CHANGE ATTRIBUTES command.
Each process has an associated security profile. This
profile is inserted by Message Monitor into the Command
Body Standard Part of each command to MMS.
Security profiles can be compared using the following
rule:
Profile (a) is contained in
profile (b) if the value for each compartment in
profile (a) is lower than (lower than or equal
to) the corresponding value in profile (b).
M̲e̲m̲o̲r̲y̲ ̲B̲u̲f̲f̲e̲r̲s̲
When a disk block is deallocated from a CIF, the CIF
profile is compared with the purge profile. If the
CIF profile is not contained in the purge profile,
the block shall be purged immediately after deallocation.
According to CAMPS requirements, the purge profile
will be:
- Security Classification = 3 (secret)
- Atomal Compartment = 0 (non-atomal)
- Encryption Compartment = 0 (non-encrypted)
The above rules will then assure that purge will be
performed for information of security classification
CTS or special handling designator Atomal or category
Encrypted.
The Store Profile (refer 2.2.2.6.3) will be the same
as the Purge Profile.
Fig. 4.1.1-1…01…MMS Subpackages
4.1.2 S̲o̲f̲t̲w̲a̲r̲e̲ ̲S̲t̲r̲u̲c̲t̲u̲r̲e̲
MMS is implemented as a set of coroutines within the
File Management Process. Ref. figure 2.1.1-1.
There are two types of coroutines:
a) M̲e̲s̲s̲a̲g̲e̲ ̲H̲a̲n̲d̲l̲e̲r̲ ̲C̲o̲r̲o̲u̲t̲i̲n̲e̲
This type of coroutine executes commands from application
processes. There is a number of incarnations of
the coroutine, so that several commands can be
processed in parallel. Each coroutine can execute
commands associated with any of the subpackages.
b) D̲i̲s̲k̲ ̲P̲u̲r̲g̲e̲ ̲C̲o̲r̲o̲u̲t̲i̲n̲e̲
Purges deallocated disk blocks before they can
be reused. There is one incarnation of this coroutine.
It belongs entirely to CIF Handling subpackage.
The subpackage functions are implemented as a set of
procedures called from the coroutines. The Message
Handler Coroutines execute commands on behalf of all
subpackages.
The number of Message Handler coroutines is 2.
4.1.3 D̲a̲t̲a̲ ̲F̲l̲o̲w̲ ̲a̲n̲d̲ ̲C̲o̲n̲t̲r̲o̲l̲ ̲L̲o̲g̲i̲c̲
4.1.3.1 M̲a̲i̲n̲ ̲F̲l̲o̲w̲
The main flow in MMS is shown on figure 4.1.3-1.
The Command Handler Module executes the main loop of
the Message Handler Coroutines. Refer 4.1.2.
MMS commands from application processes are queued
by FMS Command Controller. Refer (e) and figure 2.1.1-1.
The Command Handler when it is idle, gets the next
command. The Command Code is inspected, and the appropriate
Command Execution Procedure is called. It can be within
the Command Handler itself or within one of the other
subpackages.
All commands requiring disk accesses ultimately call
upon Disk IO which interfaces to FMS Disk Cache Manager.
Command Parameters refer (b) 3.2.7.1 are handled in
the following way:
- The Get MMS Command returns a command operation,
refer (e). A pointer to this operation is stored
in the coroutine variable OPERATION, refer 4.1.4.3.4.2.
- Command Execution procedures must generate reply
parameters in the coroutine variables CC and REPLY.
- Command Handler delivers the reply parameters to
Command Controller in the Reply Command call.
Parameters in Command Trailer and Data Buffer are transferred
by command execution procedures.
Figure 4.1.3-1 does not show detailed interface between
subpackages.
4.1.3.2 R̲e̲s̲e̲r̲v̲a̲t̲i̲o̲n̲ ̲M̲e̲c̲h̲a̲n̲i̲s̲m̲s̲
In order to avoid inconsistencies due to concurrent
access to memory or disk resident data structures,
two reservation mechanisms are used as described in
the following sections.
4.1.3.2.1 C̲I̲F̲ ̲R̲e̲s̲e̲r̲v̲a̲t̲i̲o̲n̲
Each function accessing an active CIF must reserve
the CIF for exclusive access during those phases of
the processing where it is needed. Such phases are
often referred to as critical regions.
For this purpose, a CIF Control Block reservation mechanism
and two CIF Handling Procedures Open and Close are
used. Refer 4.1.5.2.2 and 3. Open shall be called
before any access to the active CIF is attempted.
Close shall be called when the processing is terminated.
4.1.3.2.2 O̲C̲D̲ ̲R̲e̲s̲e̲r̲v̲a̲t̲i̲o̲n̲
All functions requiring access to OCD, ITS or checkpoints
must ensure exclusive access to these interrelated
data structures. This is done by means of two common
procedures Reserve OCD, refer 4.1.5.7 and Release OCD,
refer 4.1.5.8.
Figure 4.1.3-2 gives an overview of functions accessing
OCD and/or checkpoints.
4.1.3.2.3 D̲e̲a̲d̲l̲o̲c̲k̲ ̲P̲r̲e̲v̲e̲n̲t̲i̲o̲n̲
Certain functions need reservation of OCD as well as
CIF. In order to prevent deadlocks such reservations
m̲u̲s̲t̲ ̲a̲l̲w̲a̲y̲s̲ be done in the following sequence:
- Open CIF
…0e….…0e…
…0e….…0f…
…0e….…0e…
- Reserve OCD
…0e….…0f…
…0e….…0f…
…0e….…0f…
- Release OCD
…0e….…0f…
…0e….…0f…
…0e….…0f…
- Close CIF
Note that OCD reservation may be done by Open CIF,
if the boolean call parameter LOCK ̲OCD is true. In
that case Close CIF will release OCD automatically.
The sequence applies however, to cases where CIF and
OCD are not reserved or released at the same time.
4.1.3.3 D̲i̲s̲k̲ ̲I̲O̲
All Disk IO is done via the Disk IO Subpackage procedures.
The caller of such procedures must supply a Disk Buffer
(refer 4.1.4.3.8) which is a data structure used by
Disk IO procedures to manage the IO request, and also
contains certain call and return parameters for the
request.
There are two types of disk buffers:
- I̲O̲ ̲B̲u̲f̲f̲e̲r̲
This is a buffer in each message handler coroutine.
It can be used by command execution procedures
called by the coroutine without particular precaution.
- I̲T̲S̲ ̲B̲u̲f̲f̲e̲r̲
This is a buffer which is shared between coroutines,
and used for special purposes, in particular when
copy of disk areas must be performed, but also
for access to OCD, ITS etc. There is only one
such buffer, and it must only be used while OCD
is reserved, refer 4.1.3.2.2.
Note in particular the use of fields Operation Profile
and Operation Type in Disk Buffer, refer 4.2.5.1.
4.1.3.4 C̲I̲F̲ ̲R̲e̲f̲e̲r̲e̲n̲c̲e̲ ̲L̲o̲g̲i̲c̲
Figure 4.1.3-3 shows the Reference Logic for a permanent
CIF, for which at least one SAVE command has been issued.
The OCD Entry contains the address of the CIF in STS
or in ITS. The STS address is first sector of the
checkpoint.
The packed CIF in ITS contains CIF Id as indirect reference
to OCD Entry.
If CIF is active, the checkpoint references the CIF
Control Block, which again references the Checkpoint
via Address Elements for field zero.
4.1.3.5 C̲I̲F̲ ̲S̲t̲a̲t̲e̲ ̲T̲r̲a̲n̲s̲i̲t̲i̲o̲n̲s̲
The state transitions between Active, Passive and Unloaded
are described in 2.2.1.7.
Fig. 4.1.3-1
OCD CKP
Read Update Read Update
Function
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
Create CIF
Create new CIF version
Create View
Create Fields
Get View Attributes
Lock View
X
Unlock View
X
Lookup X X
X
Stop CIF
X
Change Attributes
X
Read View
Write View
Store
Retrieve (online) X X
Init Dump
Dump CIF Sequence X X
Terminate Dump
Clear X
Save X
X
Remove View X
X
Get Threshold Warning
G̲e̲t̲ ̲S̲t̲o̲r̲a̲g̲e̲ ̲O̲c̲c̲u̲p̲a̲n̲c̲y̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
Fig. 4.1.3-2…01…O̲C̲D̲ ̲a̲n̲d̲ ̲C̲h̲e̲c̲k̲p̲o̲i̲n̲t̲ ̲A̲c̲c̲e̲s̲s̲
Fig. 4.1.3-3…01…Relation between CIFCB, Checkpoint and ITS
4.1.4 C̲o̲m̲m̲o̲n̲ ̲P̲a̲c̲k̲a̲g̲e̲ ̲D̲a̲t̲a̲
4.1.4.1 C̲o̲n̲s̲t̲a̲n̲t̲s̲
Refer MMS ̲PREFIX.S
4.1.4.2 P̲r̲i̲m̲i̲t̲i̲v̲e̲ ̲T̲y̲p̲e̲s̲
Refer MMS ̲PREFIX.S
4.1.4.3 M̲e̲m̲o̲r̲y̲ ̲R̲e̲s̲i̲d̲e̲n̲t̲ ̲D̲a̲t̲a̲
Refer MMS ̲COMVAR.S and figure 4.1.4.3-1 thru 4.1.4.3-14.
FIGURE 4.1.4.3-1…01…CIF Control Block
FIGURE 4.1.4.3-2…01…View Control Block
FIGURE 4.1.4.3-3…01…Field Reference
FIGURE 4.1.4.3-4…01…Block List Element
FIGURE 4.1.4.3-5…01…Short Field Descriptor
FIGURE 4.1.4.3-6…01…Long Field Descriptor
FIGURE 4.1.4.3-7…01…Field Fragment
FIGURE 4.1.4.3-8…01…CIF Address Block
Figure 4.1.4.3-9
Lock Descriptor
FIGURE 4.1.4.3-10…01…Disk Buffer
FIGURE 4.1.4.3-11…01…Cache Buffer
Fig. 4.1.4.3-12…01…Field Buffer
Fig. 4.1.4.3-13…01…Field Sequence
Fig. 4.1.4.3-14
4.1.4.4 D̲i̲s̲k̲ ̲R̲e̲s̲i̲d̲e̲n̲t̲ ̲D̲a̲t̲a̲
MMS Online File contains following data areas:
(Refer figure 4.1.4.4-1)
- Short Term Storage NO ̲OF ̲STS ̲BLOCKS Disk
Blocks
- Intermediate Storage NO ̲OF ̲ITS ̲BLOCKS Disk
Blocks
- Online CIF Directory NO ̲OF ̲OCD ̲BLOCKS + NO
̲OF ̲TERTIARY ̲BLOCKS Disk
Blocks
- Recovery Block 1 Disk Block
Refer 2.2.2.4
- ITS Control Block 1 Sector
Contains current value
of ITS Clear Pointer.
ITS ̲CONTROL ̲BLOCK =
RECORD
ITS ̲CLEAR: NO ̲OF ̲ITS ̲SECTORS
current value of ITS
clear pointer
DUMMY: ARRAY(1..255) OF INTEGER
END
Dump Files are described in section 4.2.3.
FIGURE 4.1.4.4-1
4.1.5 C̲o̲m̲m̲o̲n̲ ̲P̲a̲c̲k̲a̲g̲e̲ ̲P̲r̲o̲c̲e̲d̲u̲r̲e̲s̲
4.1.5.1 G̲e̲t̲ ̲C̲I̲F̲
4.1.5.1.1 F̲u̲n̲c̲t̲i̲o̲n̲a̲l̲ ̲S̲p̲e̲c̲i̲f̲i̲c̲a̲t̲i̲o̲n̲
The REF of OPERATION is used to locate a View Control
Block, and the associated CIF Control Block.
4.1.5.1.2 I̲n̲t̲e̲r̲f̲a̲c̲e̲
GET ̲CIF()( CIFCB: CIF ̲CONTROL ̲BLOCK,
VBC: VIEW ̲CONTROL ̲BLOCK,
CC: COMPLETION ̲CODE):ERROR
̲OK
C̲o̲m̲p̲l̲e̲t̲i̲o̲n̲ ̲C̲o̲d̲e̲s̲
- ILLEGAL ̲VIEW ̲REF
4.1.5.1.3 D̲a̲t̲a̲ ̲D̲e̲s̲c̲r̲i̲p̲t̲i̲o̲n̲
a̲)̲ ̲D̲a̲t̲a̲ ̲R̲e̲f̲e̲r̲e̲n̲c̲e̲s̲
Refer MMS ̲PREFIX.S
b̲)̲ ̲E̲x̲t̲e̲r̲n̲a̲l̲ ̲D̲a̲t̲a̲
OPERATION ̲REF
VIEW ̲CONTROL ̲BLOCK.CIFCB
c̲)̲ ̲L̲o̲c̲a̲l̲ ̲D̲a̲t̲a̲ ̲
None
4.1.5.1.4 P̲r̲o̲c̲e̲d̲u̲r̲e̲ ̲D̲e̲s̲i̲g̲n̲
Refer 4.1.5.1.1
4.1.5.2 O̲p̲e̲n̲ ̲C̲I̲F̲
4.1.5.2.1 F̲u̲n̲c̲t̲i̲o̲n̲a̲l̲ ̲S̲p̲e̲c̲i̲f̲i̲c̲a̲t̲i̲o̲n̲
Makes an active CIF ready to be operated upon by calling
coroutine. The CIF will be reserved for the coroutine.
If specified in the LOCK ̲OCD call parameter, OCD is
reserved as well. The return parameter LOCK must later
on be used in a CLOSE CIF command.
Error return is taken, if the CIF Control Block is
in the state Removing. Then Close CIF must not be called.
4.1.5.2.2 I̲n̲t̲e̲r̲f̲a̲c̲e̲ ̲
OPEN ̲CIF( CIFCB: CIF ̲CONTROL ̲BLOCK,
LOCK ̲OCD: BOOLEAN)
( LOCK: LOCK ̲DESCRIPTOR,
CC: COMPLETION ̲CODE):ERROR
̲OK
C̲o̲m̲p̲l̲e̲t̲i̲o̲n̲ ̲C̲o̲d̲e̲s̲
- NON ̲EXISTING ̲CIF
4.1.5.2.3 D̲a̲t̲a̲ ̲D̲e̲s̲c̲r̲i̲p̲t̲i̲o̲n̲
a) D̲a̲t̲a̲ ̲R̲e̲f̲e̲r̲e̲n̲c̲e̲s̲
Refer MMS ̲PREFIX.S
b) E̲x̲t̲e̲r̲n̲a̲l̲ ̲D̲a̲t̲a̲
b1) LOCK ̲DESCRIPTOR (m)
c) L̲o̲c̲a̲l̲ ̲D̲a̲t̲a̲
None
4.1.5.2.4 P̲r̲o̲c̲e̲d̲u̲r̲e̲ ̲D̲e̲s̲i̲g̲n̲
Flowgram: fig. 4.1.5.2.4-1
OPEN ̲CIF(CIFCB: CIF ̲CONTROL ̲BLOCK,
LOCK ̲OCD: BOOLEAN)
(LOCK: LOCK ̲DESCRIPTOR,
CC: COMP ̲CODE): ERROR ̲OK;
START
CIFCB.CIF ̲LOCK EQ 0?
locate LOCK get free
from CIFCB.CIF ̲LOCK LOCK, put in ref to CIFCB
LOCK.LOCK ̲COUNT = 1
INCREMENT(LOCK.LOCK ̲COUNT) CIFCB.CIF ̲LOCK =
index to LOCK
LOCK.LOCK ̲COUNT GT 1?
WAIT ̲CM(LOCK.SEMAPHORE)
LOCK ̲OCD EQ TRUE?
RESERVE ̲OCD
LOCK.OCD ̲LOCKED ̲STATUS
= TRUE
LOCK.CIFCB EQ NIL? CLOSE ̲CIF(LOCK)
CC = OK CC = none existing CIF
RETURN(CC)
STOP
Fig. 4.1.5.2.4-1
Open CIF Flowgram
4.1.5.3 C̲l̲o̲s̲e̲ ̲C̲I̲F̲
4.1.5.3.1 F̲u̲n̲c̲t̲i̲o̲n̲a̲l̲ ̲S̲p̲e̲c̲i̲f̲i̲c̲a̲t̲i̲o̲n̲
Releases an active CIF which has previously been reserved
by Open CIF. If OCD was reserved, it is released too.
4.1.5.3.2 I̲n̲t̲e̲r̲f̲a̲c̲e̲
CLOSE ̲CIF (LOCK: LOCK ̲DESCRIPTOR)
4.1.5.3.3 D̲a̲t̲a̲ ̲D̲e̲s̲c̲r̲i̲p̲t̲i̲o̲n̲
a) D̲a̲t̲a̲ ̲R̲e̲f̲e̲r̲e̲n̲c̲e̲s̲
Refer MMS ̲PREFIX.S
b) E̲x̲t̲e̲r̲n̲a̲l̲ ̲D̲a̲t̲a̲
b1) CIF ̲CONTROL ̲BLOCK (m)
c) L̲o̲c̲a̲l̲ ̲D̲a̲t̲a̲
None
4.1.5.3.4 P̲r̲o̲c̲e̲d̲u̲r̲e̲ ̲D̲e̲s̲i̲g̲n̲
Flowgram fig. 4.1.5.3.4-1
CLOSE ̲CIF(LOCK: LOCK ̲DESCRIPTOR)
START
LOCK.OCD ̲LOCKED ̲STATUS EQ TRUE?
RELEASE ̲OCD
LOCK.OCD ̲LOCKED ̲STATUS = FALSE
DECREMENT(LOCK.LOCK ̲COUNT)
LOCK.LOCK ̲COUNT LE 0?
SIGNAL ̲CM(LOCK.SEMAPHORE) put LOCK back
into free list
CIFCB.CIF ̲LOCK = NIL
RETURN
FIGURE 4.1.5.3.4-1
Close CIF Flowgram
4.1.5.4 M̲M̲S̲ ̲R̲e̲t̲i̲r̲e̲
4.1.5.4.1 F̲u̲n̲c̲t̲i̲o̲n̲a̲l̲ ̲S̲p̲e̲c̲i̲f̲i̲c̲a̲t̲i̲o̲n̲
Retires FMS process in case of an irreparable error.
The Impossible Entry is used for software errors in
MMS. The IO Error Entry is used for IO Errors on online
disk. The cause and specified completion code is sent
to parent process.
4.1.5.4.2 I̲n̲t̲e̲r̲f̲a̲c̲e̲
IMPOSSIBLE (CC: COMPLETION ̲CODE)
4.1.5.4.3 D̲a̲t̲a̲ ̲S̲p̲e̲c̲i̲f̲i̲c̲a̲t̲i̲o̲n̲
N/A
4.1.5.4.4 P̲r̲o̲c̲e̲d̲u̲r̲e̲ ̲D̲e̲s̲i̲g̲n̲
Call the kernel procedure Retire, refer (i) 4.1.3.6
with primary code = IMPOSSIBLE, secondary code = CC.
4.1.5.5 C̲h̲e̲c̲k̲ ̲S̲e̲c̲u̲r̲i̲t̲y̲
4.1.5.5.1 F̲u̲n̲c̲t̲i̲o̲n̲a̲l̲ ̲S̲p̲e̲c̲i̲f̲i̲c̲a̲t̲i̲o̲n̲
The procedure check if security classification of profile1
is lower than or equal to profile2 or if any lists
in rest of profile1 occur in profile2. Error return
if any of the condition are fulfilled.
4.1.5.5.2 I̲n̲t̲e̲r̲f̲a̲c̲e̲
CHECK ̲SECURITY (PROFILE ̲1,
PROFILE ̲2: SEC ̲PROFILE): ERROR ̲OK
4.1.5.5.3 D̲a̲t̲a̲ ̲D̲e̲s̲c̲r̲i̲p̲t̲i̲o̲n̲
a) D̲a̲t̲a̲ ̲R̲e̲f̲e̲r̲e̲n̲c̲e̲s̲
Refer source list
b) E̲x̲t̲e̲r̲n̲a̲l̲ ̲D̲a̲t̲a̲
None
c) L̲o̲c̲a̲l̲ ̲D̲a̲t̲a̲
None
4.1.5.5.4 P̲r̲o̲c̲e̲d̲u̲r̲e̲ ̲D̲e̲s̲i̲g̲n̲
Refer source list.
4.1.5.6 C̲o̲m̲p̲u̲t̲e̲ ̲O̲b̲j̲e̲c̲t̲ ̲R̲e̲f̲e̲r̲e̲n̲c̲e̲
4.1.5.6.1 F̲u̲n̲c̲t̲i̲o̲n̲a̲l̲ ̲S̲p̲e̲c̲i̲f̲i̲c̲a̲t̲i̲o̲n̲
This procedure converts an object pointer into an object
reference consisting of a segment identification and
an index within the segment.
The object shall be either a CIFCB pointer or a VCB
pointer.
4.1.5.6.2 I̲n̲t̲e̲r̲f̲a̲c̲e̲
COMPUTE ̲OBJECT (POOL: POOL ̲TYPE
OBJECT: POINTER)
(OBJECT: MMS ̲VIEV ̲REFERENCE)
4.1.5.6.3 D̲a̲t̲a̲ ̲D̲e̲s̲c̲r̲i̲p̲t̲i̲o̲n̲
a) D̲a̲t̲a̲ ̲R̲e̲f̲e̲r̲e̲n̲c̲e̲s̲
Refer source list.
b) E̲x̲t̲e̲r̲n̲a̲l̲ ̲D̲a̲t̲a̲
SEGM ̲DESCR
COROUTINES (m)
c) L̲o̲c̲a̲l̲ ̲D̲a̲t̲a̲
None
4.1.5.6.4 P̲r̲o̲c̲e̲d̲u̲r̲e̲ ̲D̲e̲s̲i̲g̲n̲
Refer 4.1.5.6.1
4.1.5.7 C̲o̲n̲v̲e̲r̲t̲ ̲O̲b̲j̲e̲c̲t̲ ̲R̲e̲f̲e̲r̲e̲n̲c̲e̲
4.1.5.7.1 F̲u̲n̲c̲t̲i̲o̲n̲a̲l̲ ̲S̲p̲e̲c̲i̲f̲i̲c̲a̲t̲i̲o̲n̲
This procedure converts an object reference consisting
of a segment identification and a segment index into
a object pointer.
The object reference shall be a reference to either
a VCB or a CIFCB.
4.1.5.7.2 I̲n̲t̲e̲r̲f̲a̲c̲e̲
CONVERT ̲OBJECT (POOL: POOL ̲TYPE
OBJ ̲REF: MMS ̲VIEV ̲REFERENCE)
(OBJECT: POINTER)
4.1.5.7.3 D̲a̲t̲a̲ ̲D̲e̲s̲c̲r̲i̲p̲t̲i̲o̲n̲
a) D̲a̲t̲a̲ ̲R̲e̲f̲e̲r̲e̲n̲c̲e̲s̲
Refer source list.
b) E̲x̲t̲e̲r̲n̲a̲l̲ ̲D̲a̲t̲a̲
SEGM ̲DESCR
COROUTINES
c) L̲o̲c̲a̲l̲ ̲D̲a̲t̲a̲
None
4.1.5.7.4 P̲r̲o̲c̲e̲d̲u̲r̲e̲ ̲D̲e̲s̲i̲g̲n̲
Refer 4.1.5.7.1
4.1.5.8 C̲r̲e̲a̲t̲e̲ ̲S̲e̲g̲m̲e̲n̲t̲
4.1.5.8.1 F̲u̲n̲c̲t̲i̲o̲n̲a̲l̲ ̲S̲p̲e̲c̲i̲f̲i̲c̲a̲t̲i̲o̲n̲
Create a data segment by a call to the page manager.
The handle to the segment is stored in the Segment
Descriptor.
4.1.5.8.2 I̲n̲t̲e̲r̲f̲a̲c̲e̲
MMS ̲CREATE ̲SEGMENT (SEGM ̲DESCR: SEGM ̲CB)
4.1.5.8.3 D̲a̲t̲a̲ ̲D̲e̲s̲c̲r̲i̲p̲t̲i̲o̲n̲
a) D̲a̲t̲a̲ ̲R̲e̲f̲e̲r̲e̲n̲c̲e̲s̲
Refer source list.
b) E̲x̲t̲e̲r̲n̲a̲l̲ ̲D̲a̲t̲a̲
FMS ̲ATTR
USER ̲PARAMETER
SEGM ̲DESCR (m)
c) L̲o̲c̲a̲l̲ ̲D̲a̲t̲a̲
WORK ̲SEG ̲ATTR: SEGMENT ̲ATTR
4.1.5.8.4 P̲r̲o̲c̲e̲d̲u̲r̲e̲ ̲D̲e̲s̲i̲g̲n̲
Refer 4.1.5.8.1
4.1.5.9 M̲a̲p̲ ̲i̲n̲ ̲F̲r̲e̲e̲
4.1.5.9.1 F̲u̲n̲c̲t̲i̲o̲n̲a̲l̲ ̲S̲p̲e̲c̲i̲f̲i̲c̲a̲t̲i̲o̲n̲
The referenced segment is mapped in on the page demanded
by a call to the page manager.
4.1.5.9.2 I̲n̲t̲e̲r̲f̲a̲c̲e̲
MMS ̲MAP IN FREE (PAGE: INTEGER
SEGM ̲DESCR: SEGM ̲CB)
(SIZE: INTEGER)
4.1.5.9.3 D̲a̲t̲a̲ ̲D̲e̲s̲c̲r̲i̲p̲t̲i̲o̲n̲
a) D̲a̲t̲a̲ ̲R̲e̲f̲e̲r̲e̲n̲c̲e̲s̲
Refer source list.
b) E̲x̲t̲e̲r̲n̲a̲l̲ ̲D̲a̲t̲a̲
SEGM ̲DESCR (m)
c) L̲o̲c̲a̲l̲ ̲D̲a̲t̲a̲
None
4.1.5.9.4 P̲r̲o̲c̲e̲d̲u̲r̲e̲ ̲D̲e̲s̲i̲g̲n̲
Refer 4.1.5.9.1
4.1.5.10 E̲n̲s̲u̲r̲e̲ ̲S̲e̲g̲m̲e̲n̲t̲
4.1.5.10.1 F̲u̲n̲c̲t̲i̲o̲n̲a̲l̲ ̲S̲p̲e̲c̲i̲f̲i̲c̲a̲t̲i̲o̲n̲
The referenced segment is mapped in if not already
mapped in.
The coroutine record is updated with segment ID and
segment start position.
4.1.5.10.2 I̲n̲t̲e̲r̲f̲a̲c̲e̲
ENSURE ̲SEGMENT (SEGM ̲ID INDEX)
4.1.5.10.3 D̲a̲t̲a̲ ̲D̲e̲s̲c̲r̲i̲p̲t̲i̲o̲n̲
a) D̲a̲t̲a̲ ̲R̲e̲f̲e̲r̲e̲n̲c̲e̲s̲
Refer source list.
b) E̲x̲t̲e̲r̲n̲a̲l̲ ̲D̲a̲t̲a̲
SEGM ̲DESCR
COROUTINE (m)
c) L̲o̲c̲a̲l̲ ̲D̲a̲t̲a̲
None
4.1.5.10.4 P̲r̲o̲c̲e̲d̲u̲r̲e̲ ̲D̲e̲s̲i̲g̲n̲
Refer 4.1.5.10.1
4.1.5.11 G̲e̲n̲e̲r̲a̲l̲ ̲C̲M̲O̲N̲ ̲a̲n̲d̲ ̲C̲T̲R̲L̲ ̲I̲n̲t̲e̲r̲f̲a̲c̲e̲
4.1.5.11.1 F̲u̲n̲c̲t̲i̲o̲n̲a̲l̲ ̲S̲p̲e̲c̲i̲f̲i̲c̲a̲t̲i̲o̲n̲
The purpose of these procedures are to call a service
procedure within the Coroutine Monitor or the FMS Command
Controller.
Before the call of the service procedure the state
of the MMS memory is stored in the coroutine record.
After return from the service procedure the state of
the MMS memory is restored from the coroutine record.
4.1.5.11.2 I̲n̲t̲e̲r̲f̲a̲c̲e̲
MMS ̲WAIT (SEMAPHORE: POINTER)
MMS ̲WAIT ̲OP (OPERATION,
SEMAPHORE: POINTER)
MMS ̲REPLY ̲CMD ̲LARGE (CMD ̲OPERATION,
DESTINATION: POINTER,
SIZE: INTEGER)
MMS ̲RECEIVE ̲WORDS (CMD ̲OPERATION,
DATA ̲BUFFER: POINTER,
SIZE: INTEGER)
(CC: COMPLETION ̲CODE)
MMS ̲SEND ̲WORDS (CMD ̲OPERATION,
DATA ̲BUFFER: POINTER,
SIZE: INTEGER)
(CC: COMPLETION ̲CODE)
MMS ̲RECEIVE ̲SECTOR (CMD ̲OPERATION,
FIRST ̲SECTOR: POINTER,
BYTE ̲OFFSET,
BYTE ̲SIZE: INTEGER)
(CC: COMPLETION ̲CODE)
MMS ̲SEND ̲SECTOR (CMD ̲OPERATION,
FIRST ̲SECTOR: POINTER,
BYTE ̲OFFSET,
BYTE ̲SIZE: INTEGER)
(CC: COMPLETION ̲CODE)
MMS ̲SKIP SOURCE (CMD ̲OPERATION: POINTER,
NO ̲OF ̲TLES: COUNTER)
(CC: COMPLETION ̲CODE)
4.1.5.11.3 D̲a̲t̲a̲ ̲D̲e̲s̲c̲r̲i̲p̲t̲i̲o̲n̲
a) D̲a̲t̲a̲ ̲R̲e̲f̲e̲r̲e̲n̲c̲e̲s̲
Refer source list.
b) E̲x̲t̲e̲r̲n̲a̲l̲ ̲D̲a̲t̲a̲
COROUTINE (m)
c) L̲o̲c̲a̲l̲ ̲D̲a̲t̲a̲
None
4.1.5.11.4 P̲r̲o̲c̲e̲d̲u̲r̲e̲ ̲D̲e̲s̲i̲g̲n̲
Refer source list.
4.1.6 G̲l̲o̲b̲a̲l̲ ̲D̲a̲t̲a̲
The Type Definitions for data structures exchanged
with application packages are defined in (c), section
4.
Type Definitions for data structure exchanged with
DAMOS Coroutine Monitor are defined in (j)
Type Definitions for data structures exchanged with
FMS are defined in (e) and (f).
