top - download
⟦21564f5b0⟧ Wang Wps File
Length: 71301 (0x11685)
Types: Wang Wps File
Notes: CPS/SDS/002
Names: »1048A «
Derivation
└─⟦5a07e954e⟧ Bits:30006038 8" Wang WCS floppy, CR 0062A
└─ ⟦this⟧ »1048A «
WangText
A…0b…A @…0c…@…06…?…0f…<…08…<…02……14…
…13……0c……13……00……13… …12……09……12……0f……12……06……11……0b……11……0f……11……05……10……0a……10……00……10……05……0f……0a……0f……01……86…1
…02…
…02…
…02…
…02…CPS/SDS/002
…02…OKH/810801…02……02…
CAMPS
SYSTEM
FUNCTIONS
…02……02…CAMPS
T̲A̲B̲L̲E̲ ̲O̲F̲ ̲C̲O̲N̲T̲E̲N̲T̲S̲
1 GENERAL ......................................
13
1.1 PURPOSE AND SCOPE ........................
13
1.2 APPLICABLE DOCUMENTS AND PROJECT
REFERENCES ...............................
13
1.2.1 Applicable Documents .................
13
1.3 TERMS AND ABBREVIATIONS ..................
13
1.3.1 Terms ................................
13
1.3.2 Abbreviations ........................
14
2 SUMMARY OF REQUIREMENTS ......................
15
2.1 PACKAGE DESCRIPTION ......................
15
2.2 CSF FUNCTIONS ............................
15
2.2.1 CSF Main Functions ...................
15
2.2.1.1 Shared Buffer Management .........
15
2.2.1.2 Queue Monitor ....................
16
2.2.1.2.1 Queue Attributes .............
17
2.2.1.2.2 Queue Elements ...............
17
2.2.1.2.2.1 QEL Fields ...............
18
2.2.1.2.2.2 Function Requests ........
18
2.2.1.2.3 Queue Monitor Functions ......
19
2.2.1.2.3.1 Send Functions ...........
19
2.2.1.2.3.2 Receive Functions ........
20
2.2.1.2.3.3 Return ...................
21
2.2.1.2.3.4 Dismantle ................
21
2.2.1.2.3.5 Queue Control Functions ..
21
2.2.1.2.3.6 Queue Monitor
Initialization ...........
22
2.2.1.3 Timer Monitor ....................
22
2.2.1.3.1 Current Time ................
22
2.2.1.2.2 Timer Driven Events ..........
23
2.2.1.3.2.1 Timer Event Claim .........
23
2.2.1.4 Message Monitor ..................
23
2.2.1.4.1 Parameter Check and Conversion
24
2.2.1.4.2 Active MMON Functions ........
25
2.2.1.5 Coroutine Monitor Functions ......
25
2.2.1.5.1 Coroutine States .............
28
2.2.1.5.2 Semaphores and Operations ....
30
2.2.1.5.3 Coroutine System Calls .......
32
2.2.1.5.4 Priority .....................
32
2.2.1.5.5 Sub-Process Concept ..........
32
2.2.1.6 System Call Monitor Functions ....
32
2.2.1.6.1 Functional Description .......
38
2.2.1.6.1.1 Initiate System Call .....
38
2.2.1.6.1.2 Wait for Next System Call
Completion ...............
41
2.2.1.6.1.3 Wait for Completion of a
System Call ..............
41
2.2.1.6.1.4 Cancel a System Call .....
41
2.2.1.6.1.5 Combined Init-Wait .......
41
2.2.1.6.2 Special Cases ................
42
2.2.1.6.2.1 Queue Monitor ............
42
2.2.1.6.2.2 I/O System ...............
42
2.2.1.6.2.3 Process Communication
Interface ................
42
2.2.2 Functional Responsibilities ..........
43
2.2.2.1 Initialization, Close Down, and
Restart ..........................
43
2.2.2.2 Checkpointing and Recovery .......
43
2.2.2.3 Error Detection and Error Handling
44
2.2.2.4 Integrity of Operation ...........
45
2.2.2.5 Data Collection ..................
45
2.2.2.6 Security .........................
46
2.2.2.6.1 Sub-Process Concept ..........
47
2.2.2.6.2 Qprofiles ....................
47
2.2.2.6.2.1 Comparison of Qprofile ...
49
2.2.2.6.2.2 Assignment of Qprofile ...
49
2.2.2.6.3 Access Control Mechanism .....
53
2.2.2.6.4 Automatic Deletion ...........
54
2.3 CHARACTERISTICS ..........................
57
2.3.1 Timing ...............................
57
2.3.1.1 QMON Timing ......................
57
2.3.1.2 MMON Timing ......................
57
2.3.1.3 TMON Timing ......................
57
2.3.2 Throughput ...........................
58
2.3.3 Flexibility ..........................
58
2.3.4 Accuracy .............................
58
2.3.5 Memory Consumption ...................
58
2.3.5.1 Basic Assumptions ................
59
2.3.5.2 Program Size .....................
60
2.3.5.3 Data Size ........................
60
3 ENVIRONMENTS .................................
61
3.1 EQUIPMENT ................................
61
3.2 SOFTWARE .................................
61
3.2.1 System Software ......................
61
3.2.2 Development Support Software .........
61
3.3 INTERFACES ...............................
61
3.3.1 External Interfaces ..................
61
3.3.2 Package Interfaces ...................
61
3.4 Functions Maintained by Other Packages ...
62
3.4.1 Functions Maintained by KERNEL .......
62
3.4.2 Functions Maintained by MMS ..........
62
3.4.3 Functions Maintained by SSC ..........
62
4 PACKAGE DESIGN ..............................
63
4.1 PACKAGE OVERVIEW ..........................
63
4.1.1 Functional Specification ..............
63
4.1.1.1 Common Function Overview ..........
63
4.1.1.2 Queue Monitor Overview ............
65
4.1.1.2.1 Queue Structure ...............
65
4.1.1.2.2 Queue Referencing .............
65
4.1.1.2.2.1 Queue Capabilities .......
66
4.1.1.2.3 Queue Elements ................
66
4.1.1.2.3.1 QEL Creation and Deletion .
67
4.1.1.2.3.2 Queue Element Ownership ..
69
4.1.1.2.3.3 View Control Information .
69
4.1.1.2.4 Function Request ..............
70
4.1.1.2.5 Queue Blocking ................
70
4.1.1.2.6 Waiting in Queues .............
71
4.1.1.3 Timer Monitor Overview ............
76
4.1.1.4 Message Monitor Overview ..........
77
4.1.1.5 Coroutine Monitor Overview ........
77
4.1.1.6 System Call Monitor Overview ......
77
4.1.2 Software Structure ....................
79
4.1.3 Data Flow and Control Logic ...........
83
4.1.3.1 Exclusive Access to Control Data ..
83
4.1.3.2 Deadlock Prevention ...............
84
4.1.4 Package Data ..........................
88
4.1.5 Common Data ...........................
90
4.1.6 Interfaces ............................
90
4.1.6.1 External Interfaces ...............
90
4.1.6.2 Package Interfaces ................
90
4.1.6.2.1 Common Functions Interfaces ...
90
4.1.6.2.2 QMON ..........................
92
4.1.6.2.2.1 Receive First QEL .........
94
4.1.6.2.2.2 Receive Next QEL ..........
95
4.1.6.2.2.3 Return ....................
96
4.1.6.2.2.4 Dismantle .................
96
4.1.6.2.2.5 Send ......................
97
4.1.6.2.2.6 Send Request ..............
98
4.1.6.2.2.7 Send Reply ................
99
4.1.6.2.2.8 Send Timeout ..............
100
4.1.6.2.2.10 Set Profile .............
100
4.1.6.2.2.11 Block Queue .............
101
4.1.6.2.2.12 Unblock Queue ...........
101
4.1.6.2.2.13 Set Capability ..........
101
4.1.6.2.2.14 Get Q Attributes ........
102
4.1.6.2.2.15 Get Q Length ............
102
4.1.6.2.2.16 Get QEL Attributes ......
103
4.1.6.2.2.17 Initialize Queues .......
103
4.1.6.2.2.18 Set Queue Threshold .....
104
4.1.6.2.3 Timer Monitor (Interface) .....
104
4.1.6.2.3.1 Read Time .................
106
4.1.6.2.3.2 Convert Time to ASCII .....
107
4.1.6.2.3.3 Convert Time Format .......
108
4.1.6.2.3.4 Set Time ..................
109
4.1.6.2.3.5 Request Time Out ..........
109
4.1.6.2.3.6 Cancel Time Out ...........
110
4.1.6.2.4 Message Monitor Interfaces ....
111
4.1.6.2.5 Coroutine Monitor Interfaces ..
116
4.1.6.2.6 System Call Monitor Interfaces
119
4.1.6.2.6.1 General System Call
Conventions ...............
119
4.1.6.2.6.2 General Wait-Complete
Function Conventions .....
120
4.1.6.2.6.3 Interface to Service
System ....................
121
4.2 SUB-PACKAGE SPECIFICATIONS ...............
128
4.2.1 CSF Common Functions .................
128
4.2.1.1 Functional Specification .........
128
4.2.1.1.1 Subprocess Management ........
130
4.2.1.1.1.1 Get Subprocess ............
130
4.2.1.1.1.2 Change Subprocess Id .....
130
4.2.1.1.1.3 Change Subprocess
Attributes ...............
131
4.2.1.1.1.4 Check Page Access Rights .
131
4.2.1.1.2 Buffer and Control Block
Management ...................
131
4.2.1.1.2.1 Reserve Buffer ...........
132
4.2.1.1.2.2 Dismantle Buffer .........
132
4.2.1.1.2.3 Write Buffer .............
132
4.2.1.1.2.4 Read Buffer ..............
133
4.2.1.1.2.5 Allocate Control Block ...
133
4.2.1.1.2.6 Release Control Block ....
133
4.2.1.1.3 List and Chain Manipulation ..
134
4.2.1.1.4 Log and Report Generation ....
134
4.2.1.2 Software Structure ...............
134
4.2.1.3 Data Flow and Control Logic ......
134
4.2.1.4 Subpackage Data ..................
134
4.2.1.4.1 Subprocess Record ............
136
4.2.1.4.2 Buffer Pool ..................
137
4.2.1.5 Common Functions Interface .......
138
4.2.2 Queue Monitor ........................
139
4.2.2.1 Functional Specification .........
139
4.2.2.1.1 Receive ......................
142
4.2.2.1.1.1 Receive First QEL ........
142
4.2.2.1.1.2 Inspect Receive ..........
143
4.2.2.1.1.3 Cancel Receive ...........
144
4.2.2.1.1.4 Receive Next QEL .........
144
4.2.2.1.2 Clearing .....................
147
4.2.2.1.2.1 Return ...................
147
4.2.2.1.2.2 Dismantle ................
148
4.2.2.1.3 Send .........................
150
4.2.2.1.3.1 Send QEL .................
151
4.2.2.1.3.2 Send Request .............
151
4.2.2.1.3.3 Send Reply ...............
152
4.2.2.1.4 Profiles and Blocking ........
155
4.2.2.1.4.2 Set Profile ..............
155
4.2.2.1.4.3 Block Queue ..............
156
4.2.2.1.4.4 Unblock Queue ............
156
4.2.2.1.5 Get Attributes ...............
158
4.2.2.1.5.1 Get Queue Attributes .....
158
4.2.2.1.5.2 Get Queue Length .........
158
4.2.2.1.5.3 Get QEL Attributes .......
159
4.2.2.1.6 Initialize ...................
161
4.2.2.1.6.1 Initialize Queue .........
161
4.2.2.1.6.2 Set Capabilities .........
161
4.2.2.1.6.3 Set Queue Threshold ......
162
4.2.2.1.7 Internal QMON Functions ......
164
4.2.2.1.7.1 Check Capability .........
164
4.2.2.1.7.2 Inspect Queue ............
164
4.2.2.1.7.3 Remove QEL ...............
165
4.2.2.1.7.4 Put QEL ..................
165
4.2.2.1.7.5 Signal Synch Element .....
165
4.2.2.1.7.6 Compare Profile ..........
165
4.2.2.1.7.7 Copy QEL .................
166
4.2.2.1.7.8 Create QEL ...............
166
4.2.2.1.7.9 Reinsert in Queue ........
167
4.2.2.2 Software Structure ...............
168
4.2.2.3 Data Flow and Control Logic ......
168
4.2.2.4 Subpackage Data ..................
170
4.2.2.4.1 Queue References .............
170
4.2.2.4.2 Capability Array .............
170
4.2.2.4.3 Main Queue Description .......
171
4.2.2.4.4 Subqueue Description .........
171
4.2.2.4.5 QEL ..........................
171
4.2.2.5 QMON Interface ...................
175
4.2.3 Timer Monitor ........................
177
4.2.3.1 Functional Specification .........
177
4.2.3.1.1 Read and Convert Time ........
177
4.2.3.1.1.1 Read Time ................
177
4.2.3.1.1.2 Convert Time to ASCII ....
178
4.2.3.1.1.3 Convert Time Format ......
178
4.2.3.1.1.4 Set Time .................
179
4.2.3.1.2 Time-out Function ............
180
4.2.3.1.2.1 Request Time-out .........
180
4.2.3.1.2.2 Cancel Time-out ..........
181
4.2.3.1.2.3 Timer Queue Coroutine
Functions ................
181
4.2.3.2 Software Structure ...............
182
4.2.3.3 Data Flow and Control Logic ......
182
4.2.3.4 Timer Monitor Data ...............
186
4.2.3.4.1 Time Formats .................
186
4.2.3.4.2 Timer Request Control Data ...
188
4.2.3.5 Interfaces .......................
189
4.2.4 Message Monitor ......................
191
4.2.4.1 Functional Specification .........
191
4.2.4.1.1 General Information ..........
191
4.2.4.1.2 View Handling ................
197
4.2.4.1.2.1 Create CIF ...............
197
4.2.4.1.2.2 Create New CIF Version ...
198
4.2.4.1.2.3 Create View ..............
198
4.2.4.1.2.4 Create Fields ............
199
4.2.4.1.2.6 Get View Attributes ......
200
4.2.4.1.2.7 Change Profile ...........
200
4.2.4.1.2.8 Open View ................
201
4.2.4.1.2.9 Close View ...............
201
4.2.4.1.2.10 Dismantle View ...........
202
4.2.4.1.2.11 Save View ................
203
4.2.4.1.2.12 Save .....................
203
4.2.4.1.3 Storage and Retrieval ........
204
4.2.4.1.3.1 Store ....................
204
4.2.4.1.3.2 Retrieve .................
205
4.2.4.1.3.3 Dump CIF Sequence ........
205
4.2.4.1.3.4 Clear ....................
206
4.2.4.1.3.5 Init Dump ................
206
4.2.4.1.3.6 Terminate Dump ...........
207
4.2.4.1.4 Initialization and Control ...
207
4.2.4.1.4.1 Set Security Parameters ..
207
4.2.4.1.4.2 Start System .............
207
4.2.4.1.4.3 Set Threshold Values .....
208
4.2.4.1.4.4 Get Threshold Warning ....
208
4.2.4.1.4.5 Get Storage Occupancy ....
208
4.2.4.1.5 View I/O Function ............
208
4.2.4.1.5.1 Read View ................
209
4.2.4.1.5.2 Write View ...............
209
4.2.4.1.6 Internal Functions ...........
210
4.2.4.1.6.1 Generate VCB .............
210
4.2.4.1.6.2 Exclude VCB ..............
211
4.2.4.1.6.3 Include QEL ..............
211
4.2.4.1.6.4 Check Ownership ..........
211
4.2.4.1.6.5 QEL Copied ...............
211
4.2.4.1.6.6 Exclude QEL ..............
212
4.2.4.1.6.7 Send to MMS ..............
212
4.2.4.1.6.8 Send to CSF Process ......
212
4.2.4.1.6.9 Send to Parent ...........
212
4.2.4.2 Software Specification ...........
212
4.2.4.3 Data Flow and Control Logic ......
214
4.2.4.3.1 Locking and Synchronization
Mechanisms ...................
214
4.2.4.3.2 Control Flow .................
214
4.2.4.3.3 Security Procedure Control
Flow .........................
215
4.2.4.4 Message Monitor Data .............
219
4.2.4.4.1 View Control Block Format ....
220
4.2.4.4.2 Queue Element Format .........
221
4.2.4.4.3 VCB and QEL List Structures ..
222
4.2.4.4.4 Constants and Variables ......
223
4.2.4.4.4.1 Global Constants and
Variables ................
223
4.2.4.4.4.2 Local Constants and
Variables ................
224
4.2.4.4.5 Interface Parameter Blocks ...
225
4.2.4.4.5.1 View Attributes Parameter
Block ....................
225
4.2.4.5 Subpackage Interface .............
227
4.2.5 Coroutine Monitor ....................
229
4.2.5.1 Functional Specification .........
229
4.2.5.1.1 Coroutine System Call ........
229
4.2.5.1.1.1 Coroutine Init System Call
231
4.2.5.1.1.2 Coroutine Wait ...........
231
4.2.5.1.1.3 Coroutine Cancel .........
232
4.2.5.1.2 Wait Semaphore ...............
233
4.2.5.1.3 Wait Operation Semaphore .....
233
4.2.5.1.4 Signal Semaphore .............
233
4.2.5.1.5 Signal Operation Semphore ....
234
4.2.5.1.6 Associate ....................
234
4.2.5.1.7 Initialize Functions .........
235
4.2.5.1.7.1 Initialize Coroutine .....
235
4.2.5.1.7.2 Initialize Semphore ......
236
4.2.5.1.7.3 Initialize Coroutine
Monitor ..................
236
4.2.5.1.8 Remove From Semaphore ........
236
4.2.5.1.9 Pause ........................
237
4.2.5.1.10 Ready ........................
238
4.2.5.1.11 Get Running Coroutine ........
238
4.2.5.2 Software Structure ...............
238
4.2.5.3 Data Flow and Control Logic ......
238
4.2.5.4 Coroutine Monitor Data ...........
242
4.2.5.4.1 Internal Variables ...........
242
4.2.5.4.1.1 List of Ready Coroutines .
242
4.2.5.4.1.2 Running Coroutine ........
242
4.2.5.4.1.3 Current Subprocess Id ....
243
4.2.5.4.2 Record Formats ...............
243
4.2.5.4.2.1 Coroutine Record .........
244
4.2.5.4.2.2 Internal Operation Format
245
4.2.5.4.2.3 External Operation Format
245
4.2.5.4.2.4 Semaphore Record Format ..
247
4.2.5.5 Interfaces .......................
248
4.2.6 System Call Monitor ..................
249
4.2.6.1 Functional Specification .........
249
4.2.6.1.1 Init System Call .............
251
4.2.6.1.2 Wait .........................
251
4.2.6.1.3 System Call ..................
252
4.2.6.1.4 Cancel .......................
252
4.2.6.1.5 Wait Next Operation ..........
253
4.2.6.1.6 Wait event ...................
253
4.2.6.1.7 Allocate SOCB ................
254
4.2.6.1.8 Release SOCB .................
254
4.2.6.1.9 Define Synchronization Element
254
4.2.6.1.10 I/O System Interface .........
254
4.2.6.1.11 PCF Interface ................
255
4.2.6.2 Software Structure ...............
255
4.2.6.3 Data Flow and Control Logic ......
255
4.2.6.4 System Call Monitor Data .........
257
4.2.6.4.1 List of Service System Control
Blocks .......................
257
4.2.6.4.2 List of Ready Operations .....
257
4.2.6.4.3 List of Free Operation Control
Block ........................
257
4.2.6.4.4 Work Locations ...............
258
4.2.6.4.5 System Operation Control Block
Array ........................
258
4.2.6.4.6 Service System Control Block
Array ........................
259
4.2.6.4.7 Access Rights and Logical
Addressing ...................
260
4.2.6.5 Interfaces .......................
261
4.3 MEMORY LAYOUT ............................
263
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 CAMPS SYSTEM FUNCTIONS,
4040-201 is written to fulfil the following objectives:
a) To provide detailed definition of the package functions
and architecture.
b) To provide users with detailed parameter information
for all system calls within CSF.
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/0001
CAMPS System Requirements Specification
b) CPS/SDS/001
CAMPS System Design Specification
c) CPS/SDS/003
Message Management Package Design Specification
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̲
Caller The process calling a CSF function
Parent The operating system having created
the process in question
System Level A level defining the access rights
of a process when executing in
system mode
System Mode A CPU state entered when a Monitor
Procedure is called
User Mode The CPU state for normal execution
of application processes.
1.3.2 A̲b̲b̲r̲e̲v̲i̲a̲t̲i̲o̲n̲s̲
CC Completion Code
CIF CAMPS Information File
CMON Coroutine Monitor
COPSY CAMPS Operating System
CSF CAMPS System Functions
HM Hour-Minute Time Format
ID Identification
INTM Integer-Milisecond Time Format
INTS Integer-Second Time Format
IOS Input-Output System
JUL Julian Day Time Format
LSP Least Significant Part
MIN Minutes
MMON Message Monitor
MMS Message Management System
MSP Most Significant Part
PCF Process Communication Facility
Q Queue
QEL Queue Element
QID Queue Identification
QMON Queue Monitor
RQT Request Time Format
RTC Real Time Clock Time Format
SCM System Call Monitor
SEL Synchronization Element
SOCB System Operation Control Block
SSCB Service System Control Block
TCB Timer Control Block
TMP Table Management Package
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̲
CSF is a system software package which on top of KERNEL
supplies a set of support tools for application packages.
The main groups of functions are:
a) Shared Buffer Management
b) Timer Facilities
c) Queue Handling
d) Message Management System Interface Facilities
e) General System Call and Multi-Programming Facilities
Imbedded in those function groups are tools for security
and access control, whereby a large part of the CAMPS
requirements in this area are centralized in CSF.
The CSF functions may be utilized by all CAMPS packages.
Some of the functions are, however, used to specify
control and access right parameters and alike. Those
functions are privileged, as they require particular
access rights of the calling process. These functions
are mainly used by the CAMPS Operating System within
SSC, which may, however, choose to delegate some of
those functional capabilities to other processes.
2.2 C̲S̲F̲ ̲F̲U̲N̲C̲T̲I̲O̲N̲S̲
2.2.1 C̲S̲F̲ ̲M̲a̲i̲n̲ ̲F̲u̲n̲c̲t̲i̲o̲n̲s̲
2.2.1.1 S̲h̲a̲r̲e̲d̲ ̲B̲u̲f̲f̲e̲r̲ ̲M̲a̲n̲a̲g̲e̲m̲e̲n̲t̲
Manages pools of memory buffers. The buffers within
a pool are of the same size. The buffers are in protected
memory and can thus only be accessed via the CSF functions
Read Buffer and Write Buffer.
A buffer is allocated from a pool by call of the CSF
function Reserve Buffer. The application process having
thus reserved a buffer can share it with other processes
by sending it to one or more queues.
Buffers are released by calling the Dismantle Buffer
function. When the last using process has released
the buffer, it is returned to the buffer pool.
The handling of resource shortage is specified separately
for each buffer pool. There are two possible reactions
when a buffer is requested from an empty pool.
a) The Reserve Buffer function returns an error code
indicating that pool is empty. The calling process
must then decide what to do.
b) The calling process is suspended until some other
process releases a buffer to the pool. This facility
must be used with care, as it can lead to a deadlock
situation.
The reaction is specified by a system generation parameter
for each pool.
Shared buffers are mainly used by application processes
for sending of log records, reports, etc.
Shared buffers are totally memory resident and thus
not recoverable after a system start or switch over.
2.2.1.2 Q̲u̲e̲u̲e̲ ̲M̲o̲n̲i̲t̲o̲r̲
The CSF Tool for communication between application
processes is a queue.
A queue is basically a double chained list of elements
called Queue Elements, QEL. A number of queues may
be bunched together into a so-called Main Queue. The
queues within a main queue are then called sub-queues.
The sub-queues within a main queue are assigned different
priorities. Thereby a main queue is a priority queue.
2.2.1.2.1 Q̲u̲e̲u̲e̲ ̲A̲t̲t̲r̲i̲b̲u̲t̲e̲s̲
Q̲u̲e̲u̲e̲ ̲L̲e̲n̲g̲t̲h̲
The length of a sub-queue is the number of elements
in the queue. The length of a main queue is the sum
of the sub-queue lengths.
Q̲u̲e̲u̲e̲ ̲T̲h̲r̲e̲s̲h̲o̲l̲d̲
A main queue has an associated threshold, indicating
the maximum expected length of the main queue. If the
length exceeds this threshold, a warning report is
sent to supervisor report queue.
Q̲u̲e̲u̲e̲ ̲P̲r̲o̲f̲i̲l̲e̲
The maximum Qprofile for QELs which can be sent to
the queue. The function of the profile is further described
in section 2.2.2.6. All sub-queues within a main queue
have the same profile.
2.2.1.2.2 Q̲u̲e̲u̲e̲ ̲E̲l̲e̲m̲e̲n̲t̲s̲
The normal purpose of a queue element is to contain
a reference to a real object, which is then made available
for the process receiving the QEL. There are two kinds
of such objects:
- Shared Buffers, cf. section 2.2.1.1
- Views, cf. section 2.2.1.4
In addition a QEL may serve as a self-contained information
carrier and as a time-out event from Timer Monitor.
The object type field of a QEL describes the type.
As several QELs may reference the same object, this
object may thus at a given time be in several queues.
2.2.1.2.2.1 Q̲E̲L̲ ̲F̲i̲e̲l̲d̲s̲
A QEL is a record. The most important fields of the
QEL are:
O̲b̲j̲e̲c̲t̲ ̲T̲y̲p̲e̲
Described above.
A̲p̲p̲l̲i̲c̲a̲t̲i̲o̲n̲ ̲P̲r̲o̲f̲i̲l̲e̲
Part of the Qprofile associated with the QEL. See 2.2.2.6.2.
O̲b̲j̲e̲c̲t̲ ̲R̲e̲f̲e̲r̲e̲n̲c̲e̲
A reference to a view or a shared buffer.
T̲i̲m̲e̲ ̲S̲t̲a̲m̲p̲
The time when the QEL was inserted in the queue.
O̲w̲n̲e̲r̲ ̲R̲e̲f̲e̲r̲e̲n̲c̲e̲
Sub-process id of a sub-process having received the
QEL. Cf. section 2.2.2.6.
I̲n̲f̲o̲r̲m̲a̲t̲i̲o̲n̲ ̲F̲i̲e̲l̲d̲
A 3 word field where the sender of a QEL may put various
control information to the receiver.
O̲b̲j̲e̲c̲t̲ ̲C̲o̲n̲t̲r̲o̲l̲ ̲I̲n̲f̲o̲r̲m̲a̲t̲i̲o̲n̲
Checkpoint information and similar control information
used by Message Monitor or Shared Buffer Manager.
2.2.1.2.2.2 F̲u̲n̲c̲t̲i̲o̲n̲ ̲R̲e̲q̲u̲e̲s̲t̲s̲
The Function Request mechanism allows an application
to send a QEL to a specified queue and to specify an
answer queue where the receiver of the QEL can send
a reply. See 2.2.1.2.3.1 b).
2.2.1.2.3 Q̲u̲e̲u̲e̲ ̲M̲o̲n̲i̲t̲o̲r̲ ̲F̲u̲n̲c̲t̲i̲o̲n̲s̲
2.2.1.2.3.1 S̲e̲n̲d̲ ̲F̲u̲n̲c̲t̲i̲o̲n̲s̲
The general function of SEND is to generate a new QEL
and send it to a specified sub-queue. The new QEL may
be a copy of an existing one referenced by caller.
This is the only possibility for object referencing
QELs. A self-contained QEL may, however, also be generated
as a result of SEND. Then it will only receference
its own information field.
There are three variations of SEND:
a) S̲e̲n̲d̲
Sends a QEL to a specified queue.
b) S̲e̲n̲d̲ ̲R̲e̲q̲u̲e̲s̲t̲
Sends a QEL as a function request to a specified
queue. Another queue is specified as answer queue.
c) S̲e̲n̲d̲ ̲R̲e̲p̲l̲y̲
Sends a QEL as a reply to a function request. The
QEL containing the function request must be specified
by caller. Then QMON will send to the answer queue
as specified in function request.
SEND performs the following steps:
1) Compare the object profile with profile of
the destination queue in order to check if
the QEL may be sent to the queue. Cf. section
2.2.2.6.
2) Generate a new QEL and insert it as the last
element in the destination queue.
3) Update queue length of destination queue and
compare with threshold. If exceeded, a warning
is sent to supervisor.
4) If queue was empty, then signal an associated
synchronization element in order to activate
a possible waiting process.
d) S̲e̲n̲d̲ ̲P̲a̲r̲a̲m̲e̲t̲e̲r̲s̲
In order to send a QEL to another queue, the following
additional parameters are required:
1) Application Profile
See section 2.2.2.6 for further details.
2) Checkpoint Information
Specifies for a CIF referencing QEL if it shall
be checkpointed.
3) Info
The contents of the QEL information field.
2.2.1.2.3.2 R̲e̲c̲e̲i̲v̲e̲ ̲F̲u̲n̲c̲t̲i̲o̲n̲s̲
The receive function is used to receive a QEL from
a specified queue, possibly waiting until a QEL becomes
available.
There are two variations of the receive function.
a) R̲e̲c̲e̲i̲v̲e̲ ̲F̲i̲r̲s̲t̲ ̲Q̲E̲L̲
Receives the first QEL available from the specified
queue. If it is a main queue, and more than one
sub-queue is non-empty, the highest priority sub-queue
is selected. The caller may specify if it wants
to wait for the QEL if the queue is empty.
b) R̲e̲c̲e̲i̲v̲e̲ ̲N̲e̲x̲t̲ ̲Q̲E̲L̲
Receives the QEL which is next to one specified
at call, which must be owned by the caller. If
there are no more QELs in the sub-queue, it is
indicated in the completion code.
When a QEL is received from a queue it is not removed
from the queue list. It is just marked as "received",
and the queue length is decreased by one. In addition
the receiving sub-process is inserted as owner of the
QEL.
A sub-process may be owner of more than one QEL at
a time. Each sub-process has, however, a QEL claim,
specifying how many QELs the sub-process is still allowed
to receive.
The sub-process ownership to a QEL is withdrawn if
the QEL is "returned" or "dismantled".
2.2.1.2.3.3 R̲e̲t̲u̲r̲n̲
A sub-process may return a QEL owned by itself. The
ownership is then withdrawn, and the QEL is re-inserted
in the queue at the previously occupied place. If another
process is waiting for the queue, it will receive the
QEL.
The length of the queue and the QEL claim of the calling
sub-processes are incremented.
2.2.1.2.3.4 D̲i̲s̲m̲a̲n̲t̲l̲e̲
When a QEL is dismantled, it ceases to exist. A QEL
referencing a CIF or a shared buffer can only be dismantled
via Message Monitor or Shared Buffer Manager respectively.
The QEL Claim of the calling process is incremented.
2.2.1.2.3.5 Q̲u̲e̲u̲e̲ ̲C̲o̲n̲t̲r̲o̲l̲ ̲F̲u̲n̲c̲t̲i̲o̲n̲s̲
a) G̲e̲t̲ ̲A̲t̲t̲r̲i̲b̲u̲t̲e̲s̲
Queue attributes and QEL attributes can be obtained.
In addition QMON can count the number of QELs in
a queue based on specified profile criteria.
b) S̲e̲t̲ ̲A̲t̲t̲r̲i̲b̲u̲t̲e̲s̲
Queue thresholds and profiles can be changed. Sub-process
access rights versus queues can be changed. These
functions are privileged.
c) Q̲u̲e̲u̲e̲ ̲B̲l̲o̲c̲k̲i̲n̲g̲
A queue can be blocked. It is not possible to send
to a blocked queue whereas it is still possible
to receive from it. This function is privileged.
2.2.1.2.3.6 Q̲u̲e̲u̲e̲ ̲M̲o̲n̲i̲t̲o̲r̲ ̲I̲n̲i̲t̲i̲a̲l̲i̲z̲a̲t̲i̲o̲n̲
QMON initialization consists of initializing all queues
with initial attributes and set all QELs free. As part
of recovery Message Monitor will then restore a number
of QELs and insert them into the appropriate queues.
2.2.1.3 T̲i̲m̲e̲r̲ ̲M̲o̲n̲i̲t̲o̲r̲
Timer Monitor contains two groups of functions:
a) Manipulate current time and date.
b) Timer driven event facilities.
2.2.1.3.1 C̲u̲r̲r̲e̲n̲t̲ ̲T̲i̲m̲e̲
The current time and date can be read in a number of
different formats.
A time and date in one format can be converted to another
format.
The current time and date can be set. This function
is privileged.
2.2.1.3.2 T̲i̲m̲e̲r̲ ̲D̲r̲i̲v̲e̲n̲ ̲E̲v̲e̲n̲t̲s̲
There are two functions available:
a) R̲e̲q̲u̲e̲s̲t̲ ̲T̲i̲m̲e̲-̲O̲u̲t̲
Requests Timer Monitor to start a time-out period.
When the specified time has elapsed, a time-out
QEL is sent to a specified answer queue.
The QEL contains in the first two words of information
field an event id specified at call. The event
id must be unique for calling sub-process.
A time-out request may be repeated if so specified.
Then a time-out QEL is returned at regular intervals.
Otherwise a QEL is only returned once.
b) C̲a̲n̲c̲e̲l̲ ̲T̲i̲m̲e̲-̲O̲u̲t̲
A previously requested time-out, specified by event
id is cancelled.
2.2.1.3.2.1 T̲i̲m̲e̲r̲ ̲E̲v̲e̲n̲t̲ ̲C̲l̲a̲i̲m̲
Each sub-process has a maximum number of time-out requests
which it is allowed to have active concurrently. If
this number is exceeded, a QEL is returned with info
field indicating the cause.
This claim is a system generation parameter.
2.2.1.4 M̲e̲s̲s̲a̲g̲e̲ ̲M̲o̲n̲i̲t̲o̲r̲
MMON is the interface between application packages
and the Message Management System. The Message Management
tasks are divided between MMON and MMS.
The MMS concepts are explained in CPS/SDS/003.
2.2.1.4.1 P̲a̲r̲a̲m̲e̲t̲e̲r̲ ̲C̲h̲e̲c̲k̲ ̲a̲n̲d̲ ̲C̲o̲n̲v̲e̲r̲s̲i̲o̲n̲
Each command from an application process to MMS is
implemented as a system call to MMON. Before sending
the command forth to MMS, MMON performs a command dependent
parameter check as follows:
a) A̲d̲d̲r̲e̲s̲s̲ ̲C̲h̲e̲c̲k̲ ̲a̲n̲d̲ ̲C̲o̲n̲v̲e̲r̲s̲i̲o̲n̲
Some MMS commands involve a transfer of data between
MMS and memory areas within the requesting process.
For all such commands MMON checks that the addresses
are legal, locks the addressed pages in memory
and converts the logical addresses to physical
ones.
b) P̲r̲i̲v̲i̲l̲e̲g̲e̲d̲ ̲C̲o̲m̲m̲a̲n̲d̲ ̲C̲o̲n̲t̲r̲o̲l̲
For each privileged MMS command, MMON checks that
the requesting process has the right to call the
function.
c) A̲c̲c̲e̲s̲s̲ ̲C̲o̲n̲t̲r̲o̲l̲
MMON controls that an application can only reference
CIFs by means of QELs owned by the application,
except for the Retrieve command. MMON converts
a QEL reference to a MMS View Reference. For this
purpose MMON is notified by QMON each time a new
QEL referencing a view is created by the Send function.
Similarly MMON requests QMON to create a referencing
QEL each time a new view is created.
In addition the following three conditions are
checked:
1) Profile Check. In order that a QEL may be used
as reference to a View, the Receive Profile
Check described in 2.2.2.6 must have been passed.
2) For any I/O operation to a view it is checked
that the view has been opened, and thus passed
the Security Procedure Check described in 2.2.2.6.
3) For any write operation to a view it is checked
that the referencing QEL has write access to
the view. The write access flag of QEL is specified
by sending subprocess.
2.2.1.4.2 A̲c̲t̲i̲v̲e̲ ̲M̲M̲O̲N̲ ̲F̲u̲n̲c̲t̲i̲o̲n̲s̲
In addition to the above mentioned parameter checks,
MMON has 3 more active functional responsibilities.
a) S̲e̲c̲u̲r̲i̲t̲y̲ ̲P̲r̲o̲c̲e̲d̲u̲r̲e̲ ̲I̲n̲i̲t̲i̲a̲l̲i̲z̲a̲t̲i̲o̲n̲
Before a VDU sub-process is allowed to perform
I/O operations on a view, it must call the MMON
function Open View. This function will compare
the view profile with the security warning and
security interrogation profiles. If this comparison
indicates that a security procedure must be carried
out, MMON sends an open notification message to
the parent synchronization element and awaits the
answer from the parent, telling if the open request
shall be accepted. (Cf. 2.2.2.6.3).
b) C̲h̲e̲c̲k̲p̲o̲i̲n̲t̲ ̲I̲n̲f̲o̲r̲m̲a̲t̲i̲o̲n̲ ̲C̲o̲l̲l̲e̲c̲t̲i̲o̲n̲
When a checkpoint for a CIF is requested by an
application process calling the Save View function,
MMON will collect QELs referencing views of the
CIF and send them to MMS in a Save command, as
described in 2.2.2.2.
c) V̲i̲e̲w̲ ̲a̲n̲d̲ ̲C̲I̲F̲ ̲R̲e̲m̲o̲v̲a̲l̲
MMON keeps track of the number of QELs referencing
each view. When this number becomes zero, a Remove
View command is sent to MMS. If the view is the
last one referencing the CIF, this will cause MMS
to remove the CIF. If the CIF is then deleted because
of CTS, Encrypted or Atomal, MMON will generate
a log record.
2.2.1.5 C̲o̲r̲o̲u̲t̲i̲n̲e̲ ̲M̲o̲n̲i̲t̲o̲r̲ ̲F̲u̲n̲c̲t̲i̲o̲n̲s̲
The C̲oroutine M̲o̲n̲itor is a tool for implementing a
set of semi-parallel co-operating activities within
a single process. The activities are called coroutines.
The Coroutine Monitor contains functions for:
- Scheduling of coroutines within a process
- Communication between coroutines via semaphores.
- Communication between coroutines and Service Systems
via System Call Monitor (cf. 2.2.1.6).
G̲e̲n̲e̲r̲a̲l̲ ̲C̲o̲n̲c̲e̲p̲t̲s̲
a) R̲e̲l̲a̲t̲i̲o̲n̲ ̲t̲o̲ ̲P̲r̲o̲c̲e̲s̲s̲ ̲C̲o̲n̲c̲e̲p̲t̲
The coroutine concept is implemented within the
process concept. This fact has a number of implications
which are important to consider when allocating
tasks to processes and coroutines:
- Within a process only one coroutine can be
active at a time. It is called the c̲u̲r̲r̲e̲n̲t̲
coroutine of the process
- Coroutines in different processes are not related
in any way
- The current coroutine of a process has all
the access rights of the process. It can access
all data of the process and request all system
functions which are available to the process.
There is no protection whatsoever between coroutines
in a process.
- While two processes in a PU can execute concurrently
on two different CPUs, two coroutines within
the same process cannot execute concurrently,
as one process can only use one CPU at a time.
- While a process can be preempted at virtually
any time, a coroutine within a process cannot
be preempted in favour of another coroutine
within the process. The current coroutine remains
in charge until it reaches a w̲a̲i̲t̲i̲n̲g̲ p̲o̲i̲n̲t̲
by calling some CMON procedure which can wait
for events. So the current coroutine decides
by itself when it will give up control and
let other coroutines execute.
b) S̲e̲m̲a̲p̲h̲o̲r̲e̲s̲
Coroutines w̲i̲t̲h̲i̲n̲ a process can communicate with
each other and thereby synchronize their activities
by means of s̲e̲m̲a̲p̲h̲o̲r̲e̲s̲. A semaphore is an accumulator
of s̲i̲g̲n̲a̲l̲s̲ between coroutines. Coroutines may w̲a̲i̲t̲
for signals at a semaphore.
A semaphore can be in one of three states:
1) Neutral
The number of signals equals the number of
waits. The semaphore is initially in this state
2) Open
There have been more signals than waits. Thus
a coroutine is not delayed when executing a
wait on the semaphore.
3) Closed
There have been more waits than signals. Thus
a signal will cause that one waiting coroutine
becomes ready to execute.
There are two types of semaphores:
4) Simple Semaphore
The semaphore only counts the number of signals
and waits
5) Operation Semaphore
Each signal has a data buffer (an operation)
associated with it. The operation is delivered
to the coroutine waiting at the semaphore.
c) E̲v̲e̲n̲t̲s̲
A coroutine is event driven in the sense that it
waits for some event and then performs the tasks
associated with the received event.
CMON distinguishes between i̲n̲t̲e̲r̲n̲a̲l̲ and e̲x̲t̲e̲r̲n̲a̲l̲
events relative to the process.
Internal events are semaphore signals. They are
originated by coroutines in the process and are
generated and awaited by the CMON functions Signal
Semaphore and Wait Semaphore respectively.
External events are those originated by other processes,
possibly as answers to system calls issued by coroutines
in the process.
External events are awaited by coroutine system
calls via System Call Monitor, see 2.2.1.6.
External events may be signalled to semaphores.
They may thereby be awaited concurrently with internal
ones.
In the coroutine scheduling, internal events have
highest priority. As long as there are coroutines
ready for execution, pending external events are
not considered. When no more coroutines are ready,
CMON will await external events via SCM.
2.2.1.5.1 C̲o̲r̲o̲u̲t̲i̲n̲e̲ ̲S̲t̲a̲t̲e̲s̲
A coroutine is always in one of 3 possible states:
a) Ready
The coroutine is ready to run. It is then in the
list of ready coroutines.
b) Waiting
The coroutine is waiting in a semaphore or waiting
for completion of a system call.
c) Running
At one given time only one coroutine within a process
can be running.
FIGURE 2.2.1.5.1-1…01…COROUTINE STATE TRANSITIONS
FIGURE 2.2.1.5.2-1…01…STATES OF OPERATION SEMAPHORE
Figure 2.2.1.5.1-1 shows the state transitions:
1) The running coroutine calls a coroutine monitor
procedure in order to wait for some event. If the
event has not yet happened, the first coroutine
in ready list is selected as the running coroutine.
2) The running coroutine calls a coroutine monitor
procedure in order to wait for some event that
has not yet happened.
3) The awaited event happens, thus the coroutine is
inserted into ready list.
It is important to note that the running coroutine
has access to all memory and other resources of the
process, and it can only be transferred to waiting
state "at its own will", that is by calling a Coroutine
Monitor procedure which contains a "waiting point".
There are two groups of waiting procedures:
- Waiting for a semaphore
- Waiting for an external event
2.2.1.5.2 S̲e̲m̲a̲p̲h̲o̲r̲e̲s̲ ̲a̲n̲d̲ ̲O̲p̲e̲r̲a̲t̲i̲o̲n̲s̲
There are two types of semaphores:
- Simple semaphore
- Operation Semaphore
A simple semaphore is a counter and a list of coroutines
waiting for the semaphore. The list is non-empty if
the counter is negative.
There are two functions that can be performed on a
simple semaphore, signal and wait.
Signal increments the counter. If it was negative the
first waiting coroutine is removed from the list and
set into ready state.
Wait decrements the counter. If it is then negative,
the calling coroutine is set into waiting state and
inserted into the list of waiting coroutines at the
semaphore.
The semaphore is said to be
- neutral if the counter is zero
- open if the counter is positive, and
- closed if the counter is negative
An operation semaphore has the same features as a simple
semaphore, but in addition it serves as a means to
communicate data elements (buffers) between coroutines.
Such data elements are called operations.
When a coroutine signals an operation semaphore, it
shall deliver an operation as a parameter. If the semaphore
is closed, the operation is delivered to the first
waiting coroutine. Otherwise the operation is chained
to the semaphore list.
The states of an operation semaphore are shown in figure
2.2.1.5.2-1.
An operation is a memory area. The first few locations
are used by the coroutine monitor. The rest of the
operation is defined by the calling process. The length
and contents of the user part is not known by coroutine
monitor.
There are two types of operations:
- Internal operations are only used to signal operation
semaphores
- External operations are in addition used for system
calls (cf. 2.2.1.5.3).
Both kinds of operations are entirely managed and formatted
by the application.
2.2.1.5.3 C̲o̲r̲o̲u̲t̲i̲n̲e̲ ̲S̲y̲s̲t̲e̲m̲ ̲C̲a̲l̲l̲s̲
The coroutine monitor contains a set of interface procedures
to System Call Monitor. This allows coroutines to
- Initiate system calls
- Wait for completion of a specified system call
- Issue a combined Init-Wait, that is a Coroutine
System Call
- Cancel a system call
- Associate a system call with an operation semaphore.
Completion will then be signalled to the semaphore,
where the coroutine may await completion of any
number of initiated system calls.
Each pending system call is described by an external
operation supplied as parameter in Init System Call.
2.2.1.5.4 P̲r̲i̲o̲r̲i̲t̲y̲
Each coroutine and each operation has a priority. The
list of ready coroutines and each semaphore list of
waiting coroutines or operations are sorted according
to priority.
2.2.1.5.5 S̲u̲b̲-̲P̲r̲o̲c̲e̲s̲s̲ ̲C̲o̲n̲c̲e̲p̲t̲
The coroutines within a process are grouped into sub-processes.
The sub-process concept is not used by Coroutine Monitor,
but it maintains a "Current Subprocess Id", which is
used by CSF security procedures for security and access
rights checking.
2.2.1.6 S̲y̲s̲t̲e̲m̲ ̲C̲a̲l̲l̲ ̲M̲o̲n̲i̲t̲o̲r̲ ̲F̲u̲n̲c̲t̲i̲o̲n̲s̲
The System Call Monitor is a general mechanism used
by those system functions that require interprocess
communication as part of their task. Examples of such
system functions are file or terminal access, table
access etc., as shown on figure 2.2.1.6-1.
The functions are generally performed by system processes,
and application processes interface to system processes
by means of synchronization elements.
Figure 2.2.1.6-2 shows a general model of a Service
System and its relation to a using application process.
The Service System Interface is a set of MONITOR procedure
entries, which are called upon by the application program
requesting service. The Service System Interface sends
the request to a Service Process via a synchronization
element and waits for a reply in another synchronization
element. The Service System Interface may in addition
perform some security related parameter checking before
sending the request.
For security reasons it is normally important that
the Service System Interface executes in System Mode,
so that it can maintain some control data which are
not accessible by the application program.
FIGURE 2.2.1.6-1…01…SERVICE SYSTEMS AND SYSTEM PROCESSES
FIGURE 2.2.1.6-2
GENERAL MODEL OF A SERVICE SYSTEM
FIGURE 2.2.1.6-2a…01…LOGICAL POSITION OF SYSTEM CALL MONITOR
Figure 2.2.1.6-3 shows the typical sequences of actions
in performing a system call. The most important fact
to notice is that the application process is inactive
from the time when the service system interface has
sent a request until the time when it receives the
reply.
As seen from figure 2.2.1.6-1 an application process
will typically need to call upon service from several
Service Systems. In many cases the requested function
is a lengthy one. For performance reasons it is thus
often necessary for an application process to be able
to issue several System Calls in parallel and then
process the replies in the sequence where they arrive
to the application process.
The purpose of System Call Monitor is to allow each
of a number of Service System Interfaces in an application
process to have a number of pending requests to the
corresponding service process(es), and to proces the
answers in the sequence of arrival.
The main function of System Call Monitor is to serve
as a central waiting facility for the Service System
Interfaces. Whenever the application process has nothing
to do, it must wait for the next external event. This
waiting is done in the System Call Monitor by waiting
on all the "reply synchronization elements" shown in
figure 2.2.1.6-1.
The logical position of System Call Monitor is shown
in figure 2.2.1.6-2a.
FIGURE 2.2.1.6-3…01…TYPICAL SEQUENCE FOR A SYSTEM CALL
2.2.1.6.1 F̲u̲n̲c̲t̲i̲o̲n̲a̲l̲ ̲D̲e̲s̲c̲r̲i̲p̲t̲i̲o̲n̲
The term System Operation will be used to denote a
specific execution of a system call.
As several system operations may be active in parallel,
the application program and the System Call Monitor
must have a way to specify a System Operation for each
other. This is done by Operation References.
The aplication program specifies an operation to System
Call Monitor by a "System Operation Reference".
The System Call Monitor specifies an operation to the
application program by a "User Operation Reference".
The main functions of System Call Monitors are shown
on figure 2.2.1.6.1-1.
2.2.1.6.1.1 I̲n̲i̲t̲ ̲S̲y̲s̲t̲e̲m̲ ̲C̲a̲l̲l̲
The calling application requests a System Call to be
initiated. Parameters supplied are:
a) Function Code
Specifies the requested function and then indirectly
the Service System which shall perform the function.
b) Function Parameters
The parameters for the specific function as required
by Service System.
c) User Operation Reference
The application program reference to this operation.
The System Call Monitor will call the appropriate Service
System and supply it with parameters a) and b) above.
It will also allocate a working area for this operation
which may be used by the Service System during the
subsequent steps of execution.
Upon return from Service System, System Call Monitor
will return a System Operation Reference which shall
be used by the application program to specify this
operation.
FIGURE 2.2.1.6.1-1…01…SYSTEM CALL MONITOR FUNCTIONS
2.2.1.6.1.2 W̲a̲i̲t̲ ̲f̲o̲r̲ ̲N̲e̲x̲t̲ ̲S̲y̲s̲t̲e̲m̲ ̲C̲a̲l̲l̲ ̲C̲o̲m̲p̲l̲e̲t̲i̲o̲n̲
The application requests System Call Monitor to await
the completion of any of the pending operations. System
Call Monitor will await external events until some
operation is completed, and return the User Operation
Reference of this operation.
2.2.1.6.1.3 W̲a̲i̲t̲ ̲f̲o̲r̲ ̲C̲o̲m̲p̲l̲e̲t̲i̲o̲n̲ ̲o̲f̲ ̲a̲ ̲S̲y̲s̲t̲e̲m̲ ̲C̲a̲l̲l̲
The application requests System Call Monitor to await
the completion of a specific operation, specified by
System Operation Reference.
When the operation has been completed, System Call
Monitor will return the parameters received from Service
System.
2.2.1.6.1.4 C̲a̲n̲c̲e̲l̲ ̲a̲ ̲S̲y̲s̲t̲e̲m̲ ̲C̲a̲l̲l̲
The application requests a previously initiated system
call, specified by System Operation Reference, to be
cancelled. System Call Monitor sends the request to
the Service System and awaits a reply. Then it returns
to the application. The application must then wait
for system call completion as described in 2.2.1.6.1.3.
Only a system call requested by the Init System Call
function may be cancelled.
2.2.1.6.1.5 C̲o̲m̲b̲i̲n̲e̲d̲ ̲I̲n̲i̲t̲-̲W̲a̲i̲t̲
If the application wants to initiate a System Call
and immediately afterwards await its completion, it
can use the System Call entry of System Call Monitor.
This entry is simply the combination of the function
Initiate System Call and Wait for Completion of a System
Call.
2.2.1.6.2 S̲p̲e̲c̲i̲a̲l̲ ̲C̲a̲s̲e̲s̲
There are 3 special cases of service system which differ
from the general model of figure 2.2.1.6-2/2a. They
are described in this section.
2.2.1.6.2.1 Q̲u̲e̲u̲e̲ ̲M̲o̲n̲i̲t̲o̲r̲
The Queue Monitor has no associated Service Process.
But it has a synchronization element associated with
each application process. This synchronization element
may be signalled by the Queue Monitor from some other
process sending to a queue.
The application may initiate a RECEIVE FIRST QEL from
a queue by the Init System Call, and may await the
completion of the receive operation as described previously.
The other Queue Monitor functions can be executed immediately
by the Queue Monitor without awaiting a reply.
2.2.1.6.2.2 I̲/̲O̲ ̲S̲y̲s̲t̲e̲m̲
The I/O System is special in the sense that it awaits
its own synchronization element. So the System Call
Monitor's waiting for the whole group of synchronization
elements is actually a call to I/O System procedure
General Await. The application program needs not be
aware of this fact. If, however, a Service system uses
the I/O system for its task, it will have a slightly
different interface to System Call Monitor.
2.2.1.6.2.3 P̲r̲o̲c̲e̲s̲s̲ ̲C̲o̲m̲m̲u̲n̲i̲c̲a̲t̲i̲o̲n̲ ̲I̲n̲t̲e̲r̲f̲a̲c̲e̲
The application process may need to use the low level
process communication by means of synchronization elements.
This means that for some synchronization elements the
application shall itself process the info block received
from the synchronization element.
For this reason System Call Monitor will contain a
special P̲rocess C̲ommunication F̲acility Service System
which will support an Await function on synchronization
elements.
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̲
As part of system start, Message Monitor will assist
MMS in restoring the CIFs, Views, and QELs referencing
views. QMON has the responsibility of inserting the
restored QELs in the queues, sequencing them according
to the time stamp.
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̲
Message Monitor and Queue Monitor have major responsibilities
for checkpointing and recovery. They are implemented
as part of the following functions.
- Send (QMON)
- Save View (MMON)
- Dismantle View (MMON)
A basis for the checkpoint mechanism is that MMON can:
a) Collect all Views referencing a CIF
b) Collect all QELs referencing a View
and that QMON can use the information in a QEL to find
the queue containing the QEL, and to re-insert QELs
in their original sequence.
The main principle used by MMON when generating a checkpoint
for a view is to collect all other views referencing
the same CIF, and the QELs referencing those views.
This collected information is then sent to MMS in a
save command. During recovery this information can
then be used to regenerate the structure of views and
QELs.
There are a number of refinements to this scheme:
a) Recovery Level
Recovery level zero stores checkpoints on disk
and in standby, while level one stores checkpoints
in standby. Level one contains more frequent checkpoints,
thus resulting in a more precise recovery. In the
Save View command a Recovery Level parameter specifies
if the view shall be checkpointed only in standby.
b) Checkpoint Parameter in Send
The QMON send function has a checkpoint parameter
specifying if the generated QEL shall be contained
in subsequent checkpoints for the referenced CIF.
c) Delayed Removal of View
When a view is to be removed because the last referencing
QEL is dismantled, the removal is postponed until
next checkpoint for the referenced CIF, if the
view has been checkpointed.
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̲
CSF performs a thorough parameter checking in all function
calls, except in the Coroutine Monitor functions.
Most parameter errors are considered serious, as they
indicate that the calling process goes beyond its access
rights. The CSF error handling in those cases is to
stop the calling process and send an error message
to the parent synchronization element. This is done
by calling the KERNEL function Retire with the appropriate
error information.
Requested functions may be rejected for reasons which
are not considered to be errors. An example is a Send
which may be rejected because of a profile check. Rejections
of this type are indicated in a completion code returned
as output parameter from the function call.
2.2.2.4 I̲n̲t̲e̲g̲r̲i̲t̲y̲ ̲o̲f̲ ̲O̲p̲e̲r̲a̲t̲i̲o̲n̲
Most CSF data are of importance for security or for
overall system integrity. They must consequently be
kept in protected memory, only accessible in system
mode.
CSF objects such as Queues, Queue Elements, View Control
Blocks, etc. are only referenced indirectly by application
processes, thus avoiding the possibility of a CSF function
destroying CSF data because of addressing errors.
All pointer parameters delivered by application processes
are checked, thus assuring that the calling process
has appropriate access right to the referenced memory
area.
The objective of the above mentioned measures is to
prevent application processes from corrupting CSF data
or data within other processes.
Some additional measures such as QEL claims and time-out
claims are aimed at detecting some of the more obvious
software errors in application processes. CSF can,
however, not prevent system corruption caused by resource
shortage, such as too few QELs etc. It can only report
threshold overflows and then rely on operator assistance
to remedy the shortage.
2.2.2.5 D̲a̲t̲a̲ ̲C̲o̲l̲l̲e̲c̲t̲i̲o̲n̲
Not applicable.
2.2.2.6 S̲e̲c̲u̲r̲i̲t̲y̲
The CSF security mechanisms have the objective of controlling
information sent on lines, that is on terminals, devices
and channels. The factors considered when determining
if a stored item may be sent on a line are:
a) Attributes of the item, such as
- Security classification
- Special handling designators
- Exercise indication
- Item type
b) Attributes of the line, such as
- Security classification
- Special handling designators
- Exercise indication
- Functional Capabilities (release, reception,
etc.)
For a terminal the line attributes are a combination
of terminal and user attributes.
The CSF security mechanisms shall implement the required
security controls on information flow based on the
above mentioned attributes.
In addition CSF shall assist other packages in performing
the following security functions:
c) Invoke appropriate security procedure(s) on VDUs
before display of certain classification or special
handling designators.
d) Delete information of classification CTS and/or
categories Atomal or Encrypted when the information
has been transmitted on the appropriate lines.
CSF uses two basic concepts to implement the required
security functions:
e) Sub-Process
A sub-process is the entity which from the CSF
point of view represents a line.
f) Q̲p̲r̲o̲f̲i̲l̲e̲
A Qprofile is a data structure used to encode the
attributes of lines and items.
2.2.2.6.1 S̲u̲b̲-̲P̲r̲o̲c̲e̲s̲s̲ ̲C̲o̲n̲c̲e̲p̲t̲
A sub-process is an artificial entity without any physical
reality. It is used to facilitate security control
for processes administrating more than one line, e.g.
a VDU process responsible for 8 VDUs.
Figure 2.2.2.6-1 shows the logical relations between
processes, sub-processes and coroutines. Those coroutines
responsible for a single line constitute the sub-process
representing the line.
At each point in time one coroutine, the "current coroutine"
is in control of the process, meaning that the current
coroutine uses the CPU time. The sub-process associated
with current coroutine is called the current subprocess.
The coroutine monitor notifies CSF Subprocess Management
each time the current subprocess is changed
CSF does not protect between subprocesses and coroutines
within a process. A VDU process must for example itself
maintaing the correct relationship between subprocess
and VDU. CSF shall, however, control the relationship
between subprocess and process. So one VDU process
cannot interfere with any other application process
in an uncontrolled way.
2.2.2.6.2 Q̲p̲r̲o̲f̲i̲l̲e̲s̲
A Qprofile is a 32 bits data structure used to encode
the attributes of lines and items.
The encoding is done as follows, where bits are numbered
from 0-31:
0 - 2 Security Classification
The following values are used:
0: Unclassified
1: Restricted
2: Confidential
3: Secret
4: Cosmic Top Secret
3 Encryption Indicator
Bit 3 is set for an encrypted item.
4 - 23 Special Handling Designators
One bit for each of the possible 20 special
handling designators. A bit set means that
the item has the corresponding designator set.
Bit 4 is used for ATOMAL designator.
24 Exercise Indication
The values are:
0: Exercise
1: Non-exercise
The exercise indication of a message shall
be derived from the header. For all other kinds
of items the exercise indication is set to
zero.
25 - 27 Item Type
There is one bit allocated to each of the following
groups of types:
25: Message
26: Comment
27: Release Notification, Retrieved Item
28-29: Spare
30-31 Application Fields
This part of the profile can be specified as
a parameter in Send.
30: Message for coordination
31: Message for release
2.2.2.6.2.1 C̲o̲m̲p̲a̲r̲i̲s̲o̲n̲ ̲o̲f̲ ̲Q̲p̲r̲o̲f̲i̲l̲e̲
Two qprofiles can be compared using the following rule:
Profile A is contained in profile B if and only if:
1) The security classification of profile A is lower
than or equal to the security classification of
profile B, and
2) If any of the bits 3-31 are set in profile A, it
is also set in profile B.
2.2.2.6.2.2 A̲s̲s̲i̲g̲n̲m̲e̲n̲t̲ ̲o̲f̲ ̲Q̲p̲r̲o̲f̲i̲l̲e̲
A Qprofile is assigned to each of the following entities:
- Main queues
- Views (only bit 0 - 29)
- Subprocesses
- Queue Elements (only bit 30 - 31)
In the following it is described how qprofiles are
assigned.
a) A̲s̲s̲i̲g̲n̲m̲e̲n̲t̲ ̲t̲o̲ ̲Q̲u̲e̲u̲e̲ ̲E̲l̲e̲m̲e̲n̲t̲s̲
Each QEL has an associated qprofile. For a QEL
referencing a view the profile is the view qprofile
bits 0-29 and the QEL profile bits 30-31. For other
QELs the qprofile is zero.
Bits 30-31 are specified as parameters in Send function.
b) A̲s̲s̲i̲g̲n̲m̲e̲n̲t̲ ̲t̲o̲ ̲Q̲u̲e̲u̲e̲s̲
Each main queue has an associated qprofile, determining
which QELs can be sent to its sub-queues. The rule
is that a QEL can only be sent to a queue if the
profile of the QEL is lower than the profile of
the queue, cf. figure 2.2.2.6-2.
For channel, device, and terminal queues the qprofiles
shall thus be derived from the channel, device,
and terminal profiles. Assignment is done by SSC.
c) A̲s̲s̲i̲g̲n̲m̲e̲n̲t̲ ̲t̲o̲ ̲S̲u̲b̲-̲P̲r̲o̲c̲e̲s̲s̲e̲s̲
Each subprocess has an associated qprofile, determining
which information the subprocess is allowed to
access at the moment. When a subprocess receives
a QEL from a queue, the QEL profile and the subprocess
profile are compared. The subprocess will only
be allowed to access the view referenced by the
QEL, if QEL profile is lower than subprocess profile.
For channel and device subprocesses the subprocess
profile will be the same as the queue profile.
For a VDU subprocess the qprofile is derived from
a combination of the terminal profile and the user
profile. Assignment is done by SSC.
d) A̲s̲s̲i̲g̲n̲m̲e̲n̲t̲ ̲t̲o̲ ̲V̲i̲e̲w̲s̲
Each view has an associated qprofile (bits 0 -
29). All views referencing the same CIF have identical
profiles. The profile is specified as a parameter
when the CIF is created, and it may later on be
changed by the Change Profile Function.
FIGURE 2.2.2.6-1…01…SUBPROCESS AND COROUTINES WITHIN PROCESS
FIGURE 2.2.2.6-2…01…PROFILE CHECK AT SEND
FIGURE 2.2.2.6-3…01…PROFILE CHECK AT RECEIVE
2.2.2.6.3 A̲c̲c̲e̲s̲s̲ ̲C̲o̲n̲t̲r̲o̲l̲ ̲M̲e̲c̲h̲a̲n̲i̲s̲m̲
Figure 2.2.2.6-4 shows the access path between a subprocess
and a CIF. This access path is the basis for the access
control implemented by CSF.
a) View Referencing a CIF
A view references a specific part of a CIF. For
a message each view will normally reference one
of the formats that the message can have concurrently.
As the access path goes through a view, a subprocess
is given access right to a specific format only.
b) QEL Referencing a View
A subprocess can only reference a view via a QEL
owned by the subprocess.
c) QEL Ownership
There are only two ways for a subprocess to become
owner of a QEL:
1) The subprocess has received the QEL from a
queue
2) The subprocess has itself created the view.
This is again only possible if the subprocess
has created the CIF or it has received a QEL
referencing another view of the CIF.
d) Subprocess Access to Queues
A subprocess can only send to or receive from
a queue via a queue capability. This capability
is an indirect reference to the queue, describing
the functions which the subprocess can use
on the queue.
As seen from the explanation above, it is possible
for an operating system to control effectively the
subprocess access to CIFs by:
1) Assigning proper qprofiles to queues and subprocesses
2) Assigning proper queue capabilities to subprocesses
For VDU-processes access control based on profiles
is supplied with security procedure invocation before
access is allowed to CIFs of profile above a certain
level. A view shall be opened by a subprocess before
the subprocess can read it. And the open request triggers
the security procedure as shown in figure 2.2.2.6-5.
2.2.2.6.4 A̲u̲t̲o̲m̲a̲t̲i̲c̲ ̲D̲e̲l̲e̲t̲i̲o̲n̲
CIFs having a qprofile satisfying one of the following
requirements will be automatically deleted and a log
record generated, when last referencing QEL has been
dismantled.
a) Security classification is CTS
b) Atomal designator is set
c) Encryption indicator is set
FIGURE 2.2.2.6-4…01…ACCESS PATH TO CIF
FIGURE 2.2.2.6-5…01…SECURITY PROCEDURE INTERFACE CHART
2.3 C̲H̲A̲R̲A̲C̲T̲E̲R̲I̲S̲T̲I̲C̲S̲
2.3.1 T̲i̲m̲i̲n̲g̲
2.3.1.1 Q̲M̲O̲N̲ ̲T̲i̲m̲i̲n̲g̲
a) S̲e̲n̲d̲
Send to a non-empty queue 0.3 msec
Send to an empty queue 3.4 msec
b) R̲e̲c̲e̲i̲v̲e̲
Receive from a non-empty queue 0.2 msec
Receive with wait for an empty queue 1.5 msec
c) D̲i̲s̲m̲a̲n̲t̲l̲e̲
Dismantle of QEL not referencing view
or shared buffer 0.1 msec
2.3.1.2 M̲M̲O̲N̲ ̲T̲i̲m̲i̲n̲g̲
The figures include the time used for process communication
and page lock- unlock.
Save View 9 msec
Other MMON functions 6 msec
2.3.1.3 T̲M̲O̲N̲ ̲T̲i̲m̲i̲n̲g̲
Request timeout 2.5 msec
Cancel Timeout 2.5 msec
Timeout occurred 1.0 msec
2.3.1.4 S̲e̲q̲u̲e̲n̲c̲i̲n̲g̲
Queue Monitor and Message Monitor both access the common
CSF data area. This area is locked by each QMON and
MMON function. Thus only one process at a time can
execute a QMON or MMON function.
Queue Monitor and Message Monitor are called via System
Call Monitor. This allows a process to wait for several
queues at a time and have several concurrent commands
sent to MMS, and the process is not suspended until
it decides by itself. The only exception is the checkpoint
command Save View. MMON will sequence those commands
such that only one is sent to MMS at a time.
2.3.2 T̲h̲r̲o̲u̲g̲h̲p̲u̲t̲
Can be derived directly from timing figures, taking
into account the fact that the major CSF functions
cannot be executed in parallele on more than one CPU.
2.3.3 F̲l̲e̲x̲i̲b̲i̲l̲i̲t̲y̲
The security and access control functions of CSF are
parameter controlled. The parameters are either system
generation parameters or they can be dynamically changed.
2.3.4 A̲c̲c̲u̲r̲a̲c̲y̲
Any deviation from parameter specification will cause
a function call to be rejected.
2.3.5 M̲e̲m̲o̲r̲y̲ ̲C̲o̲n̲s̲u̲m̲p̲t̲i̲o̲n̲
2.3.5.1 B̲a̲s̲i̲c̲ ̲A̲s̲s̲u̲m̲p̲t̲i̲o̲n̲s̲
Most of the data needed by CSF are resources used by
application packages, and a number of the resource
requirements are not available until detailed design.
The following figures are the best estimates available.
The maximum number of active CIFs is 100, cf. CPS/SDS/003,
section 2.3.2.1.
The average number of views referencing a CIF is 3.
Each view is on average queued in 3 queues.
Commands and other requests require at most 100 QELs.
The required number of queues required for lines and
channels are:
Number of Main Queues Subqueues
instances per instance per instance
VDU 32 5 10
Printer 16 3 8
Circuit 26 1 6
Channel 32 1 1
+ Release VDUs 10 1 6
For other purposes are reguired 30 main queues and
100 subqueues.
The required number of subprocesses is 100.
The average number of pending system calls per subprocess
is 5.
The average number of queue capabilities per subprocess
is 15.
The average number of pending timeouts per subprocess
is 2.
2.3.5.2 P̲r̲o̲g̲r̲a̲m̲ ̲S̲i̲z̲e̲
CSF Common Functions 500 words
Queue Monitor 2000 words
Timer Monitor 500 words
Message Monitor 2000 words
Coroutine Monitor 500 words
System Call Monitor 500 words
Total program size 6000 words
2.3.5.3 D̲a̲t̲a̲ ̲S̲i̲z̲e̲
The memory requirements for the various types of CSF
data items are:
ITEM TYPE ITEM SIZE REQUIRED TOTAL
IN WORDS NUMBER OF REQUIREMENT
ITEMS
Main Queue 6 306 1836
Subqueue 4 796 3184
QEL 12 1000 12000
Queue Capability 2 1500 3000
TCB 8 200 1600
VCB 7 300 2100
SOCB 10 500 5000
Subprocess Record 5 100 500
Additional CSF Data Requirements 2000
Total CSF Date Requirement 29220
3̲ ̲ ̲E̲N̲V̲I̲R̲O̲N̲M̲E̲N̲T̲
3.1 E̲Q̲U̲I̲P̲M̲E̲N̲T̲
CSF executes in a PU with one or more CPUs.
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̲
CSF uses the KERNEL and MMS system software packages.
CSF must be controlled by an operating system, e.g.
COPSY within SSC, defining the control parameters used
by CSF.
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 F̲u̲n̲c̲t̲i̲o̲n̲s̲ ̲M̲a̲i̲n̲t̲a̲i̲n̲e̲d̲ ̲b̲y̲ ̲K̲E̲R̲N̲E̲L̲
CSF relies on the protection and process communication
facilities supplied by KERNEL. The basic system time
is maintained by KERNEL.
3.4.2 F̲u̲n̲c̲t̲i̲o̲n̲s̲ ̲M̲a̲i̲n̲t̲a̲i̲n̲e̲d̲ ̲b̲y̲ ̲M̲M̲S̲
The checkpoint-recovery functions of CSF are actually
assistance to the MMS checkpoint-recovery mechanism.
3.4.3 F̲u̲n̲c̲t̲i̲o̲n̲s̲ ̲M̲a̲i̲n̲t̲a̲i̲n̲e̲d̲ ̲b̲y̲ ̲S̲S̲C̲
The proper operation of the CSF security and access
control functions are only possible if SSC maintains
the parameters used by CSF to perform those functions.
Examples are queue profiles, subprocess functional
capabilites, ect.
