top - download
⟦99ae0dc37⟧ Wang Wps File
Length: 53266 (0xd012)
Types: Wang Wps File
Notes: CPS/SDS/003 Message Man.
Names: »1091A «
Derivation
└─⟦b3a67856d⟧ Bits:30006040 8" Wang WCS floppy, CR 0065A
└─ ⟦this⟧ »1091A «
WangText
+…00……00……00……00…(…0a……00……00…(…0b……19…
…18……0c……18… …17……0d……17……07……16……0c……16…
…16……06……15……0b……15……02……15……05……15……06……15……07……14……0d……14……01……14……06……14……07……13……0d……86…1 …02… …02… …02…
…02…CPS/SDS/003
…02…OKH/810801…02……02…
MESSAGE MANAGEMENT SYSTEM
…02……02…CAMPS
T̲A̲B̲L̲E̲ ̲O̲F̲ ̲C̲O̲N̲T̲E̲N̲T̲S̲
1 GENERAL .......................................
10
1.1 PURPOSE AND SCOPE .........................
10
1.2 APPLICABLE DOCUMENTS AND PROJECT REFERENCES
10
1.2.1 Applicable Documents ..................
10
1.3 TERMS AND ABBREVIATIONS ...................
11
1.3.1 Terms .................................
11
1.3.2 Abbreviations .........................
11
2 SUMMARY OF REQUIREMENTS .......................
12
2.1 PACKAGE DESCRIPTION .......................
12
2.1.1 Package Interrelations ................
12
2.1.1.1 Application Packages ..............
12
2.1.1.2 Checkpoint Transmission ...........
13
2.1.1.3 DMA Data Transfer .................
13
2.2 PACKAGE FUNCTIONS .........................
16
2.2.1 Main Functions ........................
16
2.2.1.1 Storage Structure .................
16
2.2.1.2 CIF Directories ...................
20
2.2.1.3 CIF and View Structure ............
20
2.2.1.3.1 CIFs, Fields, and Views .......
20
2.2.1.3.1.1 Field .....................
20
2.2.1.3.1.2 Field Group ...............
20
2.2.1.3.1.3 CIF .......................
21
2.2.1.3.1.4 View ......................
23
2.2.1.3.2 Creation and Deletion .........
26
2.2.1.3.2.1 CIF Creation and Deletion .
26
2.2.1.3.2.2 View Creation and
Deletion ..................
26
2.2.1.3.2.3 Field Creation and Deletion
27
2.2.1.3.3 Field Access ..................
28
2.2.1.3.4 Disk Space Allocation .........
29
2.2.1.4 CIF Attributes ....................
32
2.2.1.4.1 Permanent CIF .................
32
2.2.1.4.2 Recoverable CIF ...............
32
2.2.1.4.3 Security Profile ..............
34
2.2.1.4.4 Application Control Information
34
2.2.1.4.5 CIF Versions ..................
34
2.2.1.5 CIF Storage and Retrieval .........
35
2.2.1.5.1 Storage .......................
35
2.2.1.5.2 Retrieval .....................
36
2.2.1.6 CIF and View Referencing ..........
39
2.2.1.7 Commands ..........................
39
2.2.2 Functional Responsibilities ...........
41
2.2.2.1 Initialization, Close Down, and
Restart ...........................
41
2.2.2.2 Checkpointing and Recovery ........
42
2.2.2.2.1 Checkpoints ...................
42
2.2.2.2.1.1 SAVE Command ..............
43
2.2.2.2.1.2 Checkpoint Array ..........
44
2.2.2.2.1.3 Recovery Level ............
44
2.2.2.2.2 Recovery Actions ..............
44
2.2.2.3 Error Detection and Error Handling
47
2.2.2.4 Integrity of Operation ............
47
2.2.2.5 Data Collection ...................
47
2.2.2.6 Security ..........................
48
2.2.2.6.1 Security Profile ..............
48
2.2.2.6.2 Purge of Disk and Memory ......
48
2.2.2.6.3 Storage Control ...............
48
2.3 CHARACTERISTICS ...........................
49
2.3.1 Timing ................................
49
2.3.1.1 CPU Usage .........................
49
2.3.2 Throughput ............................
50
2.3.2.1 Storage Capacity ..................
50
2.3.3 Flexibility ...........................
51
2.3.3.1 MMS Design Constraints ............
51
2.3.4 Accuracy ..............................
52
2.3.5 Memory Consumption ....................
52
3 ENVIRONMENT ...................................
53
3.1 EQUIPMENT .................................
53
3.2 SOFTWARE ..................................
53
3.2.1 System Software .......................
53
3.2.2 Development Support Software ..........
53
3.3 INTERFACES ................................
53
3.3.1 External Interfaces ...................
53
3.3.2 Package Interfaces ....................
53
3.4 FUNCTIONS MAINTAINED BY OTHER PACKAGES ....
54
3.4.1 KERNEL ................................
54
3.4.2 FMS ...................................
54
3.4.3 CSF ...................................
54
3.4.4 SSC ...................................
54
4 PACKAGE DESIGN ................................
55
4.1 PACKAGE OVERVIEW...........................
55
4.1.1 Functional Specification ..............
55
4.1.1.1 CIF Handling Functions ............
55
4.1.1.1.1 Short Term Storage Management .
55
4.1.1.1.2 Security Control ..............
55
4.1.1.1.3 CIF Handling Commands .........
56
4.1.1.1.4 CIF I/O Commands ..............
56
4.1.1.1.5 Initialization Functions ......
56
4.1.1.2 Storage and Retrieval Functions ...
56
4.1.1.2.1 Storage Management ............
57
4.1.1.2.2 Directory Management ..........
57
4.1.1.2.3 Command Execution .............
57
4.1.1.2.4 Storage Accounting and
Monitoring ....................
57
4.1.1.3 Checkpoint and Recovery ...........
57
4.1.2 Software Structure ....................
59
4.1.3 Data Flow and Control Logic ...........
61
4.1.3.1 Update Lockout ....................
61
4.1.4 Package Data ..........................
63
4.1.4.1 Command Operations ................
63
4.1.4.2 CIF Control Blocks ................
63
4.1.4.3 View Control Blocks ...............
63
4.1.5 Common Data ...........................
63
4.1.5.1 Command Parameter Record Formats ..
64
4.1.5.1.1 View Attributes Parameter
Record ........................
64
4.1.5.1.2 Field Information Element .....
65
4.1.5.1.3 Field Information .............
66
4.1.5.1.4 Field List Element ............
66
4.1.5.1.5 Field List ....................
67
4.1.5.1.6 CIF ID List Element ...........
67
4.1.5.1.7 CIF ID List ...................
68
4.1.6 Interfaces ............................
68
4.1.6.1 External Interfaces ...............
68
4.1.6.2 Message Management System Package
Interface .........................
68
4.1.6.2.1 CIF Handling Commands .........
72
4.1.6.2.1.1 Create CIF ................
72
4.1.6.2.1.2 Create New CIF Version ....
73
4.1.6.2.1.3 Create View ...............
73
4.1.6.2.1.4 Create Fields .............
74
4.1.6.2.1.5 Get View Attributes .......
75
4.1.6.2.1.6 Change Attributes .........
75
4.1.6.2.1.7 Remove View ...............
76
4.1.6.2.2 CIF I/O Commands ..............
76
4.1.6.2.2.1 Read View .................
76
4.1.6.2.2.2 Write View ................
78
4.1.6.2.3 Storage and Retrieval Commands
79
4.1.6.2.3.1 Store .....................
79
4.1.6.2.3.2 Retrieve ..................
79
4.1.6.2.3.3 Init. Dump ................
80
4.1.6.2.3.4 Dump CIF Sequence .........
80
4.1.6.2.3.5 Terminate Dump ............
81
4.1.6.2.3.6 Clear .....................
81
4.1.6.2.4 Checkpoint and Recovery Command
81
4.1.6.2.4.1 Save ......................
81
4.1.6.2.4.2 Restore ...................
82
4.1.6.2.5 Storage Accounting and
Monitoring Commands ...........
82
4.1.6.2.5.1 Set Thresholds Values .....
82
4.1.6.2.5.2 Get Thresholds Values .....
82
4.1.6.2.5.3 Get Storage Occupancy .....
83
4.2.1 CIF Handling Subpackage ...............
84
4.2.1.1 Functional Specification ..........
84
4.2.1.1.1 Short Term Storage Management .
84
4.2.1.1.1.1 Short Term Storage
Allocation ................
84
4.2.1.1.1.2 CIF Storage Allocation ....
88
4.2.1.1.1.3 Disk Block Purge ..........
88
4.2.1.1.1.4 Storage Accounting and
Monitoring ................
90
4.2.1.1.2 Security Control ..............
90
4.2.1.1.2.1 Security Profiles .........
91
4.2.1.1.2.2 Purge Control .............
92
4.2.1.1.2.3 I/O Security Control ......
93
4.2.1.1.3 CIF Handling Commands .........
93
4.2.1.1.3.1 Create CIF ................
93
4.2.1.1.3.2 Create New CIF Version ....
94
4.2.1.1.3.3 Create View ...............
94
4.2.1.1.3.4 Create Fields .............
95
4.2.1.1.3.5 Get View Attributes .......
95
4.2.1.1.3.7 Remove View ...............
96
4.2.1.1.4 CIF I/O Commands ..............
96
4.2.1.1.4.1 Read View .................
96
4.2.1.1.4.2 Write View ................
97
4.2.1.2 Software Structure ................
98
4.2.1.3 Data Flow and Control Logic .......
98
4.2.1.4 Subpackage Data ...................
98
4.2.1.4.1 CIF Control Block .............
99
4.2.1.4.2 Field Descriptor ..............
100
4.2.1.4.3 Field Group List Elements .....
100
4.2.1.4.4 CIF Block List Element ........
101
4.2.1.4.5 Field Sector Map Element ......
101
4.2.1.4.6 View Control Block ............
102
4.2.1.4.7 Control Block Relations .......
103
4.2.2 CIF Storage and Retrieval Subpackage ..
104
4.2.2.1 Functional Specification ..........
104
4.2.2.1.1 Storage Management ............
112
4.2.2.1.1.1 Packed CIF Representation .
112
4.2.2.1.1.2 Intermediate Storage
Organization ..............
113
4.2.2.1.1.3 Long Term Storage
Organization ..............
114
4.2.2.1.1.4 Pack CIF ..................
121
4.2.2.1.1.5 Unpack CIF ................
121
4.2.2.1.1.6 Remove CIF ................
121
4.2.2.1.1.7 Reorganization ............
121
4.2.2.1.1.8 Initialization and Recovery
122
4.2.2.1.2 Directory Management ..........
122
4.2.2.1.2.1 Online CIF Directory ......
123
4.2.2.1.2.2 Long Term Storage CIF
Directories ................
126
4.2.2.1.2.3 Create Entry ..............
128
4.2.2.1.2.4 Search Entry ..............
128
4.2.2.1.2.5 Update Entry ..............
128
4.2.2.1.2.6 Reorganize Directory ......
128
4.2.2.1.2.7 Initialize OCD ............
128
4.2.2.1.3 Command Execution .............
129
4.2.2.1.3.1 Store .....................
129
4.2.2.1.3.2 Retrieve...................
129
4.2.2.1.3.3 Dump ......................
130
4.2.2.1.3.4 Clear .....................
131
4.2.2.1.3.5 Initialize SAR Functions ..
132
4.2.2.1.3.6 Unload CIF ................
132
4.2.2.1.4 Storage Accounting and
Monitoring ....................
132
4.2.2.1.4.1 Threshold Commands ........
132
4.2.2.1.4.2 Accounting Commands .......
133
4.2.2.2 Software Structure ................
133
4.2.2.3 Data Flow and Control Logic .......
133
4.2.2.4 Subpackage Data ...................
133
4.2.3 Checkpoint and Recovery Subpackage .....
134
4.2.3.1 Functional Specification ..........
134
4.2.3.1.1 Checkpoint Functions ..........
134
4.2.3.1.1.1 Checkpoint ................
134
4.2.3.1.1.2 Checkpoint Array ..........
135
4.2.3.1.1.3 Recovery Level ............
135
4.2.3.1.1.4 Checkpoint Sequence Update
136
4.2.3.1.1.5 Checkpoint Record
Allocation ................
137
4.2.3.1.1.6 Save Command ..............
137
4.2.3.1.2 Recovery Functions ............
138
4.2.3.1.2.1 Restore Command ...........
139
4.2.3.2 Software Structure ................
140
4.2.3.3 Data Flow and Control Logic .......
140
4.2.3.4 Subpackage Data ...................
140
4.3 MEMORY LAYOUT .............................
144
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/SDS/001
CAMPS System Design Specification
c) CPS/SDS/002
CAMPS System Functions
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̲
CBM Checkpoint Array Bit Map
CIF CAMPS Information File
CIF ID CIF Identification
CIFCB CIF Control Block
CSF CAMPS System Functions
DAMOS CR80D Advanced Multiprocessor Operating
System
DCA Disk Checkpoint Array
DCM Disk Cache Manager
DMA Direct Memory Access
FBM Free Block Map
FD Field Descriptor
FGD Field Group Descriptor
FMS File Management System
ID Identification
IOS I/O System
IS 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
SCA Standby Checkpoint Array
SCD Short Term Storage CIF Directory
SEL Synchronization Element
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
3. 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 Process Command Handler.
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. Volume handling and other
System functions are performed by operating system
using the same interface as application packages.
2.1.1.2 C̲h̲e̲c̲k̲p̲o̲i̲n̲t̲ ̲T̲r̲a̲n̲s̲m̲i̲s̲i̲s̲o̲n̲
Checkpoint records to standby PU are transmitted via
a checkpoint transmission process in SSC package. See
figure 2.1.1-1.
2.1.1.3 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.
Checkpoint data are moved directly to Checkpoint Buffers
which are shared between MMS and Checkpoint Transmission
Process.
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
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
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 5 M BYTES 30 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
directorie 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 exactly 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.
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 section 2.2.1.7.
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 sucessively 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 not 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 command. This
command is generated by MMON and cannot be called directly
by an application. The criteria for calling are defined
by MMON.
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 FMS, 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 FMS 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.
- Update 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 update access.
When a field is created the associated view will automatically
get both read and update 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 field" or "write
field", 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,
continued from 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 1.4 respectively. Access rights
are automatically set to read a̲n̲d̲ update.
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
Storage 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 recoverable CIF can be checkpointed and recovered,
cf. section 2.2.2. This attribute is independent of
the permanency attribute. See figure 2.2.1.4-1. For
a recoverable CIF, CREATE CIF will allocate an entry
in the checkpoint array.
Figure 2.2.1.4-1
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̲p̲p̲l̲i̲c̲a̲t̲i̲o̲n̲ ̲C̲o̲n̲t̲r̲o̲l̲ ̲I̲n̲f̲o̲r̲m̲a̲t̲i̲o̲n̲
This is the Qprofile attached to a CIF. 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 (of current version)
Output: View (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 Intermediate 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 field 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
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
removed, although some may be retained for storage
or checkpoint purposes.
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.
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 Ref.
The Context Specification defines to MMS the directory
which shall be searched for CIF ID. It can be the On-line
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 is referenced by a View Reference, which is
an integer. The View Reference is different from the
View ID used for storage and retrieval purposes.
The CIF ID used for storage and retrieval consists
of a 32 bit CIF REFERENCE NUMBER and an 8 bits VERSION
INDICATOR. A new CIF REF NUMBER is generated each time
a new CIF is created by the CREATE CIF command.
2.2.1.7 C̲o̲m̲m̲a̲n̲d̲s̲
C̲R̲E̲A̲T̲E̲ ̲C̲I̲F̲
Creates a new CIF with specified attributes, cf. section
2.2.1.4. If the CIF is permanent, a new CIF REFERENCE
NUMBER is generated and VERSION INDICATOR is set to
one.
C̲R̲E̲A̲T̲E̲ ̲N̲E̲W̲ ̲C̲I̲F̲ ̲V̲E̲R̲S̲I̲O̲N̲
Creates a new CIF with attributes equal to those of
current version, except for VERSION INDICATOR which
is incremented.
C̲R̲E̲A̲T̲E̲ ̲V̲I̲E̲W̲
Creates a new view of the referenced CIF. Can also
specify some or all of the fields, thus marking call
of CREATE FIELDS superflous.
C̲R̲E̲A̲T̲E̲ ̲F̲I̲E̲L̲D̲S̲
Specifies the fields for a previously created view.
Can also specify preallocation of disk space.
G̲E̲T̲ ̲V̲I̲E̲W̲ ̲A̲T̲T̲R̲I̲B̲U̲T̲E̲S̲
Returns to caller the attributes of the view. They
are the CIF attributes together with information about
the fields referenced by the view.
C̲H̲A̲N̲G̲E̲ ̲V̲I̲E̲W̲ ̲A̲T̲T̲R̲I̲B̲U̲T̲E̲S̲
Changes attributes of referenced view and CIF.
R̲E̲M̲O̲V̲E̲ ̲V̲I̲E̲W̲
Deletes a view. If the view shall be stored it is,
however, only logically deleted.
If the view shall be checkpointed, the request is rejected
as recoverable views must be removed with the SAVE
command.
Physical deletion of a view may cause deletion of referenced
fields.
R̲E̲A̲D̲ ̲V̲I̲E̲W̲
Reads specified parts of the fields referenced by the
view and transfers the data to a buffer in calling
application.
W̲R̲I̲T̲E̲ ̲V̲I̲E̲W̲
Writes data from a buffer in calling application into
specified parts of the fields referenced by the specified
view.
S̲T̲O̲R̲E̲
Requests that the permanent fields of specified view
are stored.
R̲E̲T̲R̲I̲E̲V̲E̲
Requests a previously stored view to be retrieved and
copied into Short Term Storage.
D̲U̲M̲P̲
A set of commands requesting a number of CIFs specified
by CIF ID to be copied from On-line Storage to Long
Term Storage. The CIFs are still retained in On-line
Storage.
C̲L̲E̲A̲R̲
Requests a specified set of CIFs to be removed from
Intermediate Storage. The CIFs are specified by Store
Time, which is the time of the latest Store command
for the CIF.
S̲E̲T̲ ̲T̲H̲R̲E̲S̲H̲O̲L̲D̲ ̲V̲A̲L̲U̲E̲S̲
Specifies threshold values for Short Term Storage and
Intermediate Storage.
G̲E̲T̲ ̲W̲A̲R̲N̲I̲N̲G̲
Requests that the response is returned when a threshold
value is exceeded.
G̲E̲T̲ ̲S̲T̲O̲R̲A̲G̲E̲ ̲O̲C̲C̲U̲P̲A̲N̲C̲Y̲
Returns the amount of free disk space in On-line Storage.
C̲H̲E̲C̲K̲P̲O̲I̲N̲T̲-̲R̲E̲C̲O̲V̲E̲R̲Y̲
See Section 2.2.2.2.
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̲
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.
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 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
disk resident. This includes disk addressing information
for the CIF fields.
b) It shall contain an "application process data"
section where Message Monitor data about queues
etc. shall be kept.
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 a Message Monitor call.
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) An application process data 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.
d) Recovery level, explained in 2.2.2.2.1.3.
2.2.2.2.1.2 C̲h̲e̲c̲k̲p̲o̲i̲n̲t̲ ̲A̲r̲r̲a̲y̲
Checkpoints are recorded as elements of a checkpoint
array.
When a recoverable CIF is created, an entry is allocated
in this array. Subsequent checkpoints for the CIF are
recorded in the entry, each overwriting the previous
one.
The entry in checkpoint array is deallocated when a
SAVE command is issued with an empty list of views.
2.2.2.2.1.3 R̲e̲c̲o̲v̲e̲r̲y̲ ̲L̲e̲v̲e̲l̲
There are two recovery levels, and a checkpoint array
at each level.
Level zero has a checkpoint array on disk.
Level one has a checkpoint array in standby PU.
The recovery level in the SAVE command specifies where
the checkpoint shall be recorded. If level is zero,
the checkpoint is recorded in both arrays. If level
is one, the checkpoint is recorded only in standby
array.
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,
having first specified the recovery level.
Each RESTORE command gives rise to the following actions:
a) Read next used entry in appropriate Checkpoint
Array.
b) Restore the attribute and addressing information
for the CIF.
c) Reserve the disk blocks in Short Term Storage occupied
by the CIF.
d) Return the application process data block to Message
Monitor.
When the complete checkpoint array has been restored,
the Short Term Storage disk blocks which have not been
reserved in c) above shall be purged.
The checkpoint arrays for level zero and one 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
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
Error code defines the error. Serious errors are expected
to result in a retire of the application process by
MMON.
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, On-Line CIF Directories and
Level zero Checkpoint Array shall be recorded on dualized
disk equipment.
2.2.2.5 D̲a̲t̲a̲ ̲C̲o̲l̲l̲e̲c̲t̲i̲o̲n̲
No special responsibilities.
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
For compability 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 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.
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 lower than or equal to the Store
Profile.
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.
2.3.1.1 C̲P̲U̲ ̲U̲s̲a̲g̲e̲
CREATE CIF 6 msec
CREATE VIEW 6 -
READ VIEW 10 -
WRITE VIEW 10 -
SAVE 10 -
STORE 3 - (10 msec for
first storage
of a CIF).
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.
For the purpose of the following calculations a number
of assumptions are stated:
a) An active CIF is a CIF which is in use at the moment,
either by residing in a queue or by being subject
to read and write operations. Examples are incoming
messages and messages which are at the moment subject
to editing.
An inactive CIF is a CIF which is kept in Short
Term Storage in its initial phase, and can be edited
some time in the future.
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 criteria for CIF state transitions between active
and inactive are a detailed design issue.
The average resource requirements for CIFs are assumed
to be:
ACTIVE CIF INACTIVE CIF
Views 3 1
Field Groups 8 5
Fields 12 5
The MMS Short Term Storage Allocation is then:
Active CIFs: 100
Inactive CIFs: 600
The number of active CIFs corresponds to two minutes
of busy traffic plus 40 items which are under editing.
The disk space needed for storage is shown on figure
2.2.1.1-1.
2.3.3 F̲l̲e̲x̲i̲b̲i̲l̲i̲t̲y̲
The storage allocation defined in 2.3.2 can be increased
to:
Active CIFs: 150
Inactive CIFs: 1000
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 a CIF: 255
c) Maximum number of Disk Blocks in
Short Term Storage 64 K
d) Maximum length of one field: 32 K
bytes
e) Maximum number of field groups
in a CIF: 16
f) Maximum number of fields in a field
group 63
g) Maximum number of views referencing
a CIF 128
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 14 words
One VCB per View 12 words
One FGD per Field Group 2 words
One FD per Field 6 words
Using the estimates of section 2.3.2.1, the following
consumption figures are calculated:
a) Fixed Amount
Working variables 1500 words
Checkpoint buffer 1000 words
b) Variable Amount
100 CIFCBs 1400 words
300 VCBs 3600 words
800 FGDs 1600 words
1200 FDs 7200 words
c) Total Memory Consumption
Program 5000 words
Data 16300 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
3.4.4 S̲S̲C̲
SSC transmits chekcpoint records to standby PU.
