top - download
⟦6cbe0c3ab⟧ Wang Wps File
Length: 51990 (0xcb16)
Types: Wang Wps File
Notes: CAMPS SYSTEM FUNCTIONS
Names: »1055A «
Derivation
└─⟦5a07e954e⟧ Bits:30006038 8" Wang WCS floppy, CR 0062A
└─ ⟦this⟧ »1055A «
WangText
…0e……00……00……00……00…C…0a……00……00…C…0b…C…0f…C…00…C…06…B…0d… …0a… …0f… …05……1f……0a……1f……0f……1f……00……1f……01……1f……02……1e……0a……1e……0d……1e……0e……1e… …1e……05……1e……06……1e……07……1d……0c……1d……0f……1d……00……1d……01……1d……02……1d……86…1 …02… …02… …02…
…02…CPS/SDS/002
…02…OKH/810801…02……02…
CAMPS SYSTEM FUNCTIONS
…02……02…CAMPS
4̲ ̲ ̲P̲A̲C̲K̲A̲G̲E̲ ̲D̲E̲S̲I̲G̲N̲
4.1 P̲A̲C̲K̲A̲G̲E̲ ̲O̲V̲E̲R̲V̲I̲E̲W̲
4.1.1 F̲u̲n̲c̲t̲i̲o̲n̲a̲l̲ ̲S̲p̲e̲c̲i̲f̲i̲c̲a̲t̲i̲o̲n̲
Figure 4.1-1 shows the division of CSF into subpackages.
4.1.1.1 C̲o̲m̲m̲o̲n̲ ̲F̲u̲n̲c̲t̲i̲o̲n̲s̲ ̲O̲v̲e̲r̲v̲i̲e̲w̲
The Common Functions subpackage is mostly a service
subpackage for the other CSF subpackages. There are
however two function groups directly used by other
packages:
a) S̲h̲a̲r̲e̲d̲ ̲B̲u̲f̲f̲e̲r̲ ̲M̲a̲n̲a̲g̲e̲m̲e̲n̲t̲
Contains functions for reserving and releasing
shared buffers and reading and writing their contents.
b) S̲u̲b̲p̲r̲o̲c̲e̲s̲s̲ ̲M̲a̲n̲a̲g̲e̲m̲e̲n̲t̲
Application processes can define current subprocess
and by a privileged function change access rights
of a subprocess.
The two other function groups contain internal functions
only. They are:
c) List and Chain Manipulation
d) Control Block Management.
e) Report and Log Generation.
Fig. 4.1-1…01…CSF SUBPACKAGES AND COMMON FUNCTIONS
4.1.1.2 Q̲u̲e̲u̲e̲ ̲M̲o̲n̲i̲t̲o̲r̲ ̲O̲v̲e̲r̲v̲i̲e̲w̲
4.1.1.2.1 Q̲u̲e̲u̲e̲ ̲S̲t̲r̲u̲c̲t̲u̲r̲e̲
A queue is a doubly linked list of queue elements.
A queue always belongs to one main queue and is then
called a subqueue within the main queue.
The bunching of queues into a main queue has the following
purposes:
a) The main queue is a priority queue with respect
to the Receive First function. Subqueues are assigned
different priorities within the main queue, as
shown on figure 4.1.1.2-1.
b) Queue Length Threshold is assigned to main queue
and is thus compared with the sum of subqueue lengths.
c) Subprocesses are assigned access rights to main
queues, and have thus the same rights to all subqueues
within a main queue.
d) Queue profiles are assigned to main queues. Thus
all subqueues within a main queue have the same
queue profile.
4.1.1.2.2 Q̲u̲e̲u̲e̲ ̲R̲e̲f̲e̲r̲e̲n̲c̲i̲n̲g̲
The term Queue will be used in the following to denote
a Main Queue or a Subqueue.
A queue is referenced by a LONG integer:
MSP: Main Queue Reference
LSP: Subqueue index
Subqueue index is the relative number of the subqueue
within the main queue. Index value one denotes the
highest priority subqueue. Index value zero is used
to denote the main queue itself.
Main queues are numbered by Main Queue Index from one
to NUMBER OF MAIN QUEUES.
4.1.1.2.2.1 Q̲u̲e̲u̲e̲ ̲C̲a̲p̲a̲b̲i̲l̲i̲t̲i̲e̲s̲
Queue Capabilities are used to control access by subprocesses
to queues.
A queue capability consists of a main queue index and
a function mask. The function mask contains a bit for
each of the QMON functions which shall be controlled
by the capability mechanism. The capability allows
the specified functions to be performed on the specified
main queue and its subqueues.
A subprocess can be g̲l̲o̲b̲a̲l̲l̲y̲ ̲c̲o̲n̲t̲r̲o̲l̲l̲e̲d̲ or c̲a̲p̲a̲b̲i̲l̲i̲t̲y̲
̲c̲o̲n̲t̲r̲o̲l̲l̲e̲d̲.
A globally controlled subprocess has access to all
queues, and possesses a global function mask determining
the functions which it may perform on those queues.
A globally controlled subprocess uses main queue references
in the form of Main Queue Index.
A capability controlled subprocess possesses a c̲a̲p̲a̲b̲i̲l̲i̲t̲y̲
̲a̲r̲r̲a̲y̲ containing one or more queue capabilties. The
subprocess has only access to a queue if it is represented
by a capability in the capability arrayt of the subprocess.
A capability controlled subprocess uses main queue
references in the form of Capability Index, which is
the index of a capability in its own capability array.
Figure 4.1.1.2-2 illustrates the capability mechanism.
4.1.1.2.3 Q̲u̲e̲u̲e̲ ̲E̲l̲e̲m̲e̲n̲t̲s̲
A QEL serves as a reference to a piece of information
and allows that information to be inserted into one
queue, or in certain cases into several queues.
The information referenced by the QEL may either be
contained in the QEL itself, or it may be contained
in an o̲b̲j̲e̲c̲t̲ referenced by the QEL.
There are two types of objects:
- Views, managed by MMON
- Shared Buffers, managed by CSF Common Functions.
The subpackage managing an object referenced by a QEL
is called the o̲b̲j̲e̲c̲t̲ ̲m̲a̲n̲a̲g̲e̲r̲ associated with the QEL.
The o̲b̲j̲e̲c̲t̲ ̲t̲y̲p̲e̲ of the QEL specifies the type of information
referenced. There are four different types:
- View
- Shared Buffer
- Timeout
- Information Element.
The two latter types are s̲e̲l̲f̲-̲c̲o̲n̲t̲a̲i̲n̲e̲d̲, as the QEL
contains all referenced information.
4.1.1.2.3.1 Q̲E̲L̲ ̲C̲r̲e̲a̲t̲i̲o̲n̲ ̲a̲n̲d̲ ̲D̲e̲l̲e̲t̲i̲o̲n̲
A QEL will always be in one of three different states:
- Free.
The QEL is not in use. It is then in the pool of
free QELs.
- Queued.
The QEL is in some queue and has not been received
yet.
- Owned.
The QEL has been received from a queue and is then
available for the receiving subprocess.
Figure 4.1.1.2-5 shows the states and the transitions
between them.
A QEL comes into use either by object creation or by
the QMON send function:
a) Object Creation.
Whenever MMON creates a new view, or CSF Common
Function reserves a shared buffer, a QEL is
used to reference the new object. The QEL is
set in the owned state, as if it was received
from a queue specified in the object creation
function call.
b) Send.
The QMON send function creates a QEL and puts
it into a specified queue. The input parameters
to send depend upon object type:
1) A QEL referencing a view or a shared buffer
is sent by specifying another QEL referencing
the same object.
2) A timeout is sent by means of Send Timeout,
which is only available to CSF Timer Monitor.
3) An Information Element is sent when no
QEL of type view or shared buffer is specified.
A QEL becomes free again when dismantled by call of
an object type dependent function:
- A view is dismantled by the MMON function Dismantle
View.
- A shared buffer is dismantled by the CSF Common
Function call Release Buffer.
- A self-contained QEL is dismantled by the QMON
function Dismantle.
4.1.1.2.3.2 Q̲u̲e̲u̲e̲ ̲E̲l̲e̲m̲e̲n̲t̲ ̲O̲w̲n̲e̲r̲s̲h̲i̲p̲
A used queue element will always be in exactly one
queue. When it is "received" from a queue, it is not
taken out of the queue, but merely marked as currently
reserved by the subprocess having received the element.
This mark is done in the o̲w̲n̲e̲r̲ field of the queue
element, and the subprocess is said to be the current
owner of the element.
When a subprocess has ownership of a queue element,
it may use it for the following purposes:
- Use it as a reference to the object (e.g. view)
that the queue element references.
- R̲e̲t̲u̲r̲n̲ it to the queue
- S̲e̲n̲d̲ it to another queue
- D̲i̲s̲m̲a̲n̲t̲l̲e̲ it, meaning that the queue element and
possibly the corresponding object is destroyed.
When a queue element has been received, the queue length
is reduced by one.
If a queue element has a profile higher than that of
the subprocess executing Receive (ref. figure 2.2.2.6-3),
this subprocess is still considered o̲w̲n̲e̲r̲ of the queue
element. It may however not use the element as a reference,
though it can still perform the functions Return, Send
or Dismantle.
The PC field of QEL contains the result of the profile
check.
4.1.1.2.3.3 V̲i̲e̲w̲ ̲C̲o̲n̲t̲r̲o̲l̲ ̲I̲n̲f̲o̲r̲m̲a̲t̲i̲o̲n̲
QELs referencing views contain a field called View
Control Information. The contents of the field are
specified as a parameter to the Send function. It contains
the following subfields:
- Application Profile
Bits 30-31 of the view queue profile, cf 2.2.2.6.2.
- Checkpoint Status.
Specifies whether the QEL shall be included in
checkpoint of the view.
- Write Access.
Specifies whether the QEL allows write access to
the referenced view.
The View Control Information is used by MMON.
4.1.1.2.4 F̲u̲n̲c̲t̲i̲o̲n̲ ̲R̲e̲q̲u̲e̲s̲t̲
The function request mechanism allows a subprocess
to send a request QEL to some queue and specify an
answer queue to which a reply can be sent.
QMON will check that the sender of the function request
has receive capability to the answer queue.
The request QEL is marked specially as such and the
answer queue will be recorded in the QEL. The Send
Reply function will automatically send the reply to
the answer queue.
The mechanism is shown on figure 4.1.1.2-3.
4.1.1.2.5 Q̲u̲e̲u̲e̲ ̲B̲l̲o̲c̲k̲i̲n̲g̲
Blocking of a queue means that it is no longer allowed
to send to the queue while it is still possible to
receive from it.
Blocking can be done on a subqueue or a main queue.
Blocking a main queue results in blocking all its
subqueues.
4.1.1.2.6 W̲a̲i̲t̲i̲n̲g̲ ̲o̲n̲ ̲Q̲u̲e̲u̲e̲s̲
The Queue Monitor function Receive First QEL may cause
the calling process to be suspended, if the referenced
queue (main queue or subqueue) is empty. The wait
parameter in the Receive First function call specifies
QMON shall wait until a QEL is available or whether
it shall return with an indication that the referenced
queue was empty.
If wait parameter has the value true and the referenced
queue is empty, the calling process will eventually
be suspended in System Call Monitor by waiting for
the QMON synchronization element associated with the
process. (Ref. section 2.2.1.6).
The Receive First QEL is the only QMON function which
can cause the calling process to be suspended.
Each time QMON sends or returns a QEL to an empty queue,
it may signal a number of synchronization elements
in order to activate processes waiting for the queue.
Each main queue has a Process Count specifying the
number of processes which are allowed to wait for elements
in the queue. If process count is zero, it is not
possible for any process to wait for the queue. Thus,
a Receive First QEL with wait parameter equal to true
is not allowed.
Fig. 4.1.1.2-1…01…QUEUE STRUCTURE
Fig. 4.1.1.2-2…01…QMON REFERENCE AND CHECK MECHANISM
Fig. 4.1.1.2-3…01…QUEUE MONITOR REQUEST-REPLY MECHANISM
4.1.1.3 T̲i̲m̲e̲r̲ ̲M̲o̲n̲i̲t̲o̲r̲ ̲O̲v̲e̲r̲v̲i̲e̲w̲
Timer Monitor has two groups of functions:
a) Manipulate Current Time
b) Manage Timeout Events
Manipulation of current time consists of reading the
time in required formats and converting between different
formats. The available formats are listed in section
4.1.6.2.3.
Setting current time is a privileged function. It
changes the value of system time maintained by the
KERNEL RTC module.
Timer driven events are generated by means of the function
call Request Timeout to Timer Monitor. When the timeout
occurs, it is signalled to the requesting process by
sending a queue element to an answer queue specified
in the Request Timeout call. The mechanism is somewhat
similar to a QMON function request. It is shown on
figure 4.1.1.3-1.
There are two kinds of timeout, single timeout and
periodic timeout. A single timeout will be delivered
only once, while a periodic timeout will be delivered
at regular intervals.
The Timeout Specification defines when the timeout
shall occur. For both timeout kinds it can either
be specified as an absolute time of day or it can be
an elapsed time between 0 and 24 hours from the time
of calling the request timeout function. The specified
time interval can not be smaller than a second.
Timer Monitor can only manage a limited number of pending
timeout requests. They are distributed among processes
so that each process has a predefined timeout request
claim. If a process has at a given time used up all
its available timeout requests, further requests will
be rejected. For technical reasons this is not done
by a return parameter in the Request Timeout function
call. Instead a QEL is sent to the answer queue with
an indication of the error.
A timeout request can be cancelled by calling the function
Cancel Timeout, identifying a previously issued timeout
request. If the timeout has already been sent to the
answer queue, Cancel Timeout will have no effect.
4.1.1.4 M̲e̲s̲s̲a̲g̲e̲ ̲M̲o̲n̲i̲t̲o̲r̲ ̲O̲v̲e̲r̲v̲i̲e̲w̲
An overview of Message Monitor Functions can be found
in the sections 2.2.1.4, 2.2.2.2, and 2.2.6.
4.1.1.5 C̲o̲r̲o̲u̲t̲i̲n̲e̲ ̲M̲o̲n̲i̲t̲o̲r̲ ̲O̲v̲e̲r̲v̲i̲e̲w̲
An overview of Coroutine Monitor can be found in section
2.2.1.5.
4.1.1.6 S̲y̲s̲t̲e̲m̲ ̲C̲a̲l̲l̲ ̲M̲o̲n̲i̲t̲o̲r̲ ̲O̲v̲e̲r̲v̲i̲e̲w̲
An overview of System Call Monitor can be found in
section 2.2.1.6.
Fig. 4.1.1.3-1…01…TIMER MONITOR OVERVIEW
4.1.2 S̲o̲f̲t̲w̲a̲r̲e̲ ̲S̲t̲r̲u̲c̲t̲u̲r̲e̲
CSF is implemented using the following software components:
a) Two shared procedures CMON and TIME executed in
user mode. They contain the coroutine monitor
functions and the Read Time and Convert Time function
respectively.
b) A monitor procedure CSF, executed at System Level
8. It contains those CSF functions which do not
contain waiting points.
c) A monitor procedure SCM, executed at system level
8. It contains the System Call Monitor functions
and those CSF functions containing waiting points
for the calling process.
d) A process CSFPROC. It contains those functions
which are most conveniently executed by a service
process. It is subdivided into a number of coroutines.
In the diagram on figure 4.1.2-1, the following terms
are used:
- CSF procedure means a procedure called by the monitor
procedure CSF, mentioned in b) above.
- SCM procedure means a procedure called by the monitor
procedure SCM, mentioned in c) above.
- Internal procedure means a procedure which may
be called from a CSF procedure or an SCM procedure.
- Coroutine means a coroutine within the process
CSFPROC.
This general structure is shown on figure 4.1.2-1.
The allocation of functions to software components
is shown in figure 4.1.2-2.
CSF is subdivided into the following subpackages:
- COMMON FUNCTIONS
- QUEUE MONITOR
- TIMER MONITOR
- MESSAGE MONITOR
- SYSTEM CALL MONITOR
- COROUTINE MONITOR
Fig. 4.1.2-1…01…GENERAL CSF SOFTWARE STRUCTURE
Fig. 4.1.2-2…01…FUNCTION ALLOCATION TO SOFTWARE COMPONENTS
4.1.3 D̲a̲t̲a̲ ̲F̲l̲o̲w̲ ̲a̲n̲d̲ ̲C̲o̲n̲t̲r̲o̲l̲ ̲L̲o̲g̲i̲c̲
Figures 4.1.3-1, -2 and -3 show the control flow within
CSF.
Each of the monitor procedures CSF and SCM are called
with a Function Code parameter. This function code
consists of two parts:
- Subpackage Identification
- Subpackage Function
The CSF and SCM monitor procedures use Subpackage Identification
to select the subpackage, while Subpackage Function
is used by the Subpackage itself.
4.1.3.1 E̲x̲c̲l̲u̲s̲i̲v̲e̲ ̲A̲c̲c̲e̲s̲s̲ ̲t̲o̲ ̲C̲o̲n̲t̲r̲o̲l̲ ̲D̲a̲t̲a̲
The CSF Data consists of two parts. One part is shared
between all processes while the other part has a separate
incarnation for each process. Those CSF and SCM procedures
accessing the shared data part shall ensure exclusive
access by disabling interrupts and locking a hardware
semaphore.
The functions requiring exclusive access to the shared
data part are:
- Subprocess Management functions, see 4.2.1.1.1.
- Buffer and Control Block Management functions,
see 4.2.1.1.2.
- Queue Monitor functions, see 4.2.2.
- Message Monitor functions, see 4.2.4.
4.1.3.2 D̲e̲a̲d̲l̲o̲c̲k̲ ̲P̲r̲e̲v̲e̲n̲t̲i̲o̲n̲
Figure 4.1.3-3 shows that the communication scheme
between monitor procedures and CSF process contain
potential deadlocks. These shall be avoided in the
following way:
a) CSF process shall be given a process priority higher
than all other processes calling CSF monitor procedures.
b) CSF process shall supply the necessary number of
communication resources for the communication to
its synchronization elements.
c) There shall be defined a maximum number of communications
to CSF process which may take place in one CSF
or SCM procedure. The necessary upper limit in
b) can then be determined.
Fig. 4.1.3.-1…01…MONITOR PROCEDURE CSF CONTROL FLOW
Fig. 4.1.3-2…01…MONITOR PROCEDURE SCM CONTROL FLOW
Fig. 4.1.3-3…01…CSF PROCESS CONTROL FLOW
4.1.4 P̲a̲c̲k̲a̲g̲e̲ ̲D̲a̲t̲a̲
CSF Data are divided into two parts as shown on figure
4.1.4-1:
a) Data shared among processes.
b) Local Data existing in an incarnation for each
process.
The CSF package data are allocated as follows:
a) Package Data in Shared Area.
- Queue Element Array
b) Package Date in Local Area.
- System Operation Control Block Array
- Subprocess Record.
Fig. 4.1.4-1…01…LOGICAL DATA SPACE LAYOUT FOR CAMPS APPLICATION PROCESSES
4.1.5 C̲o̲m̲m̲o̲n̲ ̲D̲a̲t̲a̲
CSF has two kinds of data common with other packages:
a) Parameter Blocks used by applications in calls
of CSF functions.
b) Information Blocks exchanged with Message Management
System and SSC.
The data formats are described in subpackage specifications.
4.1.6 I̲n̲t̲e̲r̲f̲a̲c̲e̲s̲
4.1.6.1 E̲x̲t̲e̲r̲n̲a̲l̲ ̲I̲n̲t̲e̲r̲f̲a̲c̲e̲s̲
Not Applicable.
4.1.6.2 P̲a̲c̲k̲a̲g̲e̲ ̲I̲n̲t̲e̲r̲f̲a̲c̲e̲s̲
4.1.6.2.1 C̲o̲m̲m̲o̲n̲ ̲F̲u̲n̲c̲t̲i̲o̲n̲s̲ ̲I̲n̲t̲e̲r̲f̲a̲c̲e̲s̲
Table 4.1.6.2.1-1 shows the interface specification
for those common functions which can be called by application
processes. They are all CSF procedures (ref. section
4.1.2).
The function Change Subprocess Attributes is privileged.
Table 4.1.6.2.1-1…01…COMMON FUNCTION INTERFACES
4.1.6.2.2 Q̲M̲O̲N̲
QMON does not access other packages but all application
packages access QMON. The functions performed by QMON
are:
- Receive First QEL
- Receive Next QEL
- Return
- Dismantle
- Send
- Send Request
- Send Reply
- Send Timeout
- Set Profile
- Block Queue
- Unblock Queue
- Set Capability
- Set Queue Threshold
- Get Queue Attributes
- Get Queue Length
- Get QEL Attributes
- Initialize Queues
- Initiate Capability Array
The functions listed here are the functions relevant
to other packages. Receive First QEL is an SCM procedure
while the others are CSF procedures, cf section 4.1.2.
Application modules are divided into groups characterized
by having the same access rights and having permission
to use the same functions. These groups are called
Subprocesses.
To control access rights to Qs and QELs is used a profile;
there exists a profile for each subprocess, queue and
View. A little part of the profile is contained in
QEL and may be changed by "Send" function.
A queue is identified by the reference to it. The reference
must be one of these types.
- Main Queue Reference (Main Q, NIL)
- Subqueue Reference (Main Q, Sub queue index)
A Queue Reference is a Main Queue Reference or a Subqueue
Reference.
Queue referencing is described in section 4.1.1.2.2.
If the view referenced by a QEL is to be checkpointed
it must be specified in the input parameters for "Send".
Then it is automatically checkpointed by the next "Save"
command where the QEL generated by "Send" is involved.
The QELs contain a three word info field. This field
is updated by "Send" with the info specified by input
parameters. The info field may be read by using the
"Get QEL Attributes" function.
The QELs are time stamped when they are sent to a queue.
The time stamp is current time read from Real Time
Clock Module in a 2 word millisecond format.
A QEL may be received from a Main queue or a Sub queue.
When it is received from a queue it is marked as owned
by the subprocess which performed the "Receive". When
a Subprocess owns a QEL it may perform Send, Return,
Dismantle or Get QEL attributes functions on it or
it may use it as reference to the object referenced
by the QEL. Only the subprocess permitted functions
may be performed.
There exists a facility which allows a subprocess to
send a QEL to a queue, requesting an answer to be sent
to another queue. This facility is started by using
the "Send Function Request" function. This function
requires an answer queue as input parameter in addition
to the normal send input parameters. The answer subprocess
will then later on receive the QEL, perform requested
function and return the answer to requesting subprocess
by using the function "Send Reply" which must have
the received QEL as input instead of a destination
queue.
In order to minimize the effect of a failure in one
process, each subprocess is only allowed to be owner
of a specified number of QELs at a given time. This
is a system generation parameter.
4.1.6.2.2.1 R̲e̲c̲e̲i̲v̲e̲ ̲F̲i̲r̲s̲t̲ ̲Q̲E̲L̲
The first QEL in a sub queue or a main queue is marked
as owned by calling subprocess and queue length is
decremented. If the queue is empty caller may wait
until a QEL arrives. If Wait is true the caller waits,
otherwise a completion code telling that the queue
is empty is returned.
The caller may receive QELs with all profiles but if
the QEL profile exceeds subprocess profile it may have
influence on the functions the caller is permitted
to perform at QELs received from actual Q, e.g. a right
to use a QEL as reference to an object is withdrawn.
This function may be used on Main Qs and Sub Qs.
Input: Q̲I̲D̲
- Q reference
W̲a̲i̲t̲
- Boolean
Output: Q̲E̲L̲
- QEL reference
S̲u̲b̲q̲u̲e̲u̲e̲ ̲I̲n̲d̲e̲x̲
C̲C̲
-Function Complete
-QEL has higher profile
-No capability
-Queue is empty
-QEL claim exceeded
4.1.6.2.2.2 R̲e̲c̲e̲i̲v̲e̲ ̲N̲e̲x̲t̲ ̲Q̲E̲L̲
The QEL next to a QEL owned by caller is marked as
owned by caller and the queue length is decreased.
If there are no more QELs in the queue the completion
code tells it.
The caller may receive QELs with all profiles but if
the QEL profile exceeds subprocess profile it may have
influence on the functions the caller is permitted
to perform at QELs received from actual queue. e.g.
a right to use a QEL as reference to an object is withdrawn.
Input: Q̲E̲L̲
- Reference to a QEL owned by calling subprocess.
Output: QEL
- Q̲E̲L̲ reference
C̲C̲
- Function Complete
- QEL has higher profile
- Input QEL not owned by caller
- Queue is empty
- QEL claim exceeded
4.1.6.2.2.3 R̲e̲t̲u̲r̲n̲
Owner reference in a QEL owned by calling Subprocess
is cleared and Qlength is incremented.
The QEL is put back at the same place in the same queue
where it was received from.
Input: Q̲E̲L̲
- Reference to a QEL owned by caller
Output: C̲C̲
- Function Complete
- QEL not owned by caller
- Function not allowed
4.1.6.2.2.4 D̲i̲s̲m̲a̲n̲t̲l̲e̲
A QEL owned by calling Subprocess is returned to the
list of free QELs. A QEL referring to an object can
not be dismantled by QMON but must be dismantled by
calling the server of the object referred, e.g. MMON
or Shared Buffer Management.
The dismantled QEL reference must not be used after
dismantle thus it may be cleared or used to reference
an other object.
Input: QEL
- Reference to a QEL owned by caller
Output:CC
- Function Complete
- QEL not owned by caller
- Function not allowed
4.1.6.2.2.5 S̲e̲n̲d̲
Sends a QEL to destination queue. If a QEL owned by
caller is specified a copy of this is sent.If no QEL
is specified a new QEL is generated and sent. Before
the QEL is sent the following input parameters are
filled in. The input parameters filled in are
- View Control Information
- Info
View Control Information is only relevant for QEL's
referencing views.
Input: Q̲E̲L̲
Reference to an owned QEL or Nil reference
D̲e̲s̲t̲.̲ ̲Q̲I̲D̲
Destination QID of the type Sub queue ref.
V̲i̲e̲w̲ ̲C̲o̲n̲t̲r̲o̲l̲ ̲I̲n̲f̲o̲r̲m̲a̲t̲i̲o̲n̲
I̲n̲f̲o̲
Three word information specified by caller
Output: C̲C̲
- Function Complete
- QEL has higher profile than dest. queue.
- Q not owned by caller
- No capability
- Function not allowed
P̲r̲o̲f̲i̲l̲e̲ ̲M̲a̲s̲k̲
If the send was rejected because of a profile
check, this mask shows which profile fields
did not pass the check.
4.1.6.2.2.6 S̲e̲n̲d̲ ̲R̲e̲q̲u̲e̲s̲t̲
Sends a QEL to destination queue. If a QEL owned by
caller is specified a copy of this is sent. If no QEL
is specified a new QEL is generated and sent. Before
the QEL is sent the following input parameters are
filled in. The input parameters filled in are
- View Control Information
- Info
- Answer Queue
The answer Queue is used when an other module performs
"Send Reply" function to send an answer to the requesting
module.
Input: Q̲E̲L̲
Reference to an owned QEL or Nil reference
D̲e̲s̲t̲.̲Q̲ ̲I̲D̲
Destination QID of the type Sub queue ref.
V̲i̲e̲w̲ ̲C̲o̲n̲t̲r̲o̲l̲ ̲I̲n̲f̲o̲r̲m̲a̲t̲i̲o̲n̲
I̲n̲f̲o̲
Three word information specified by caller
A̲n̲s̲w̲e̲r̲ ̲Q̲I̲D̲
The Queue where answer at the request is to
be sent to. QID of the type Subqueue ref.
Output: CC
- Function Complete
- QEL has higher profile than dest.Q
- QEL not owned by caller
- No capability
- Function not allowed
P̲r̲o̲f̲i̲l̲e̲ ̲M̲a̲s̲k̲
As for send.
4.1.6.2.2.7 S̲e̲n̲d̲ ̲R̲e̲p̲l̲y̲
Sends a QEL to answer queue in the reply QEL.
If the QEL to be sent is owned by caller a copy of
it is sent. The fields containing the answer queue
is not copied.
If no QEL is specified a new QEL is generated and sent.
Before the QEL is sent some of the input parameters
are filled in. The input parameters filled in are
- View Control Information
- Info
Input: Q̲E̲L̲
Reference to QEL owned or Nil. An owned QEL
may be the same as dest. QEL.
D̲e̲s̲t̲.̲Q̲E̲L̲
The QEL by which the request was received.
The dest. QEL must be owned by caller
V̲i̲e̲w̲ ̲C̲o̲n̲t̲r̲o̲l̲ ̲I̲n̲f̲o̲r̲m̲a̲t̲i̲o̲n̲
I̲n̲f̲o̲
Three word information specified by caller
Output: C̲C̲
- Function Complete
- QEL profile not contained in destination
queue profile
- QEL not owned by caller
- No answer queue in QEL
- Function not allowed
P̲r̲o̲f̲i̲l̲e̲ ̲M̲a̲s̲k̲
As for send.
4.1.6.2.2.8 S̲e̲n̲d̲ ̲T̲i̲m̲e̲o̲u̲t̲
This function differs from Send only in two respects:
a) Only CSF process is allowed to use the function
b) The QEL object type is set to "timeout".
4.1.6.2.2.10 S̲e̲t̲ ̲P̲r̲o̲f̲i̲l̲e̲
The profile of a Main queue is set. If the new profile
does not contain the old profile, the profiles of all
QELs in the queue are compared with the new value and
the QELs with a profile not contained are moved to
an alternative Sub queue specified by caller.
Only SSC is allowed to use this function.
Input: Q̲I̲D̲
Main queue reference
P̲r̲o̲f̲i̲l̲e̲
The new profile value
A̲l̲t̲.̲Q̲I̲D̲
Sub queue reference to the alternative queue
where QELs with too high profile are moved.
Output: C̲C̲
- Function Complete
- Alternative queue profile error
- Function not allowed
4.1.6.2.2.11 B̲l̲o̲c̲k̲ ̲Q̲u̲e̲u̲e̲
Blocks the specified queue. If it is a main queue,
all subqueues are blocked.
The function is privileged.
Input: Queue ID
Output: Completion Code
4.1.6.2.2.12 U̲n̲b̲l̲o̲c̲k̲ ̲Q̲u̲e̲u̲e̲
Cancels a previous blocking. If a main queue is specified,
all subqueues are unblocked.
The function is privileged.
Input: Queue ID
Output: Completion Code
4.1.6.2.2.13 S̲e̲t̲ ̲C̲a̲p̲a̲b̲i̲l̲i̲t̲i̲e̲s̲
The Main queue referred by a queue capability is changed.
Only SSC is allowed to use this function.
Input: S̲u̲b̲p̲r̲o̲c̲e̲s̲s̲ ̲I̲D̲
The identification of the Subprocess using
actual capability array.
Q̲ ̲C̲a̲p̲.̲
Capability index
M̲a̲i̲n̲ ̲Q̲
New Main queue reference
F̲u̲n̲c̲t̲i̲o̲n̲s̲
New functions the Subprocess is allowed to
perform on this queue.
Output: C̲C̲
- Function Complete
- Capability Index Error
4.1.6.2.2.14 G̲e̲t̲ ̲Q̲u̲e̲u̲e̲ ̲A̲t̲t̲r̲i̲b̲u̲t̲e̲s̲
The attributes of a queue are delivered to caller
Input: QID
- Queue reference
Output addr.
- Address to output buffer
Output: Queue attributes
- Profile
- Threshold
CC
- Function Complete
- No Capability
- Output addr. unavailable
4.1.6.2.2.15 G̲e̲t̲ ̲Q̲u̲e̲u̲e̲ ̲L̲e̲n̲g̲t̲h̲
Counts the number of QELs fulfilling a specified profile
condition.
The condition is specified by a Profile Mask. A QEL
is included in the count if its qprofile contains any
of the bits in Profile Mask.
Input Queue Reference
Profile Mask
Output Q length
CC
- Function Complete
- No Capability
- Output address unavailable
4.1.6.2.2.16 G̲e̲t̲ ̲Q̲E̲L̲ ̲A̲t̲t̲r̲i̲b̲u̲t̲e̲s̲
The attributes of a QEL are delivered to caller
Input: QEL
- Reference to a QEL
Output addr.
- Address of output buffer
Output: QEL Attributes
- Time Stamp
- View Control Information
- Profile Check Status
- Object type
- Owner
- Information field
CC
- Function Complete
4.1.6.2.2.17 I̲n̲i̲t̲i̲a̲l̲i̲z̲e̲ ̲Q̲u̲e̲u̲e̲s̲
The queue descriptions are initiated. Only SSC is allowed
to use this function.
Input: Init data
Output: CC
- Function Complete
4.1.6.2.2.18 S̲e̲t̲ ̲Q̲u̲e̲u̲e̲ ̲T̲h̲r̲e̲s̲h̲o̲l̲d̲
Defines the threshold values for a main queue.
Input: Main Queue Reference
Threshold values
Output: Completion Code.
4.1.6.2.3 T̲i̲m̲e̲r̲ ̲M̲o̲n̲i̲t̲o̲r̲
Timer Monitor interfaces to all packages by supplying
them with tools to send and convert time and by maintaining
Time Requests.
The Read Time and Convert Time functions are part of
the TIME procedures, while Request Timeout, Cancel
Timeout and Set Time are CSF procedures, cf section
4.1.2. Set Time is privileged.
The time formats known by Timer Monitor are
RTC.: The 48 Bit milliseconds format read by
the DAMOS Real Time Clock Module
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
̲ ̲ ̲ ̲
Milliseconds
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
̲ ̲ ̲ ̲ ̲
6 bytes integer giving milliseconds since
"specified time"
INTM: An 8 byte integer string specifying year,
month, day, hour, minute, second, millisecond.
Millisecond is specified in two bytes,
the others in one byte each . Year is giving
the two last figures in the year.
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
̲ ̲ ̲ ̲ ̲ ̲
Year Month Day Hour Minute Second Millisecond
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
̲ ̲ ̲ ̲ ̲ ̲
0-99 1-12 1-31 0-23 0-59 0-59 0-999
INTS:
A 6 byte integer string identical to INTM except that
milliseconds are missing.
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
Year Month Day Hour Minute Second
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
0-99 1-12 1-31 0-23 0-59 0-59
RQT:
A 4 byte integer copied from the 4 least significant
bytes in the RTC format.
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
Milliseconds
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
0- 4.10…0e…9…0f… (0-45 days)
HM:
A 2 byte integer string giving hours and minutes since
midnight.
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
Hour Minute
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
0-23 0-59
MIN:
A 2 byte integer giving minutes since midnight.
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
Minutes
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
0 - 1439
JUL:
A 2 byte integer giving days since new year.
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
Days
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
1-366
4.1.6.2.3.1 R̲e̲a̲d̲ ̲T̲i̲m̲e̲
The time is read and delivered to caller in specified
format. If the whole time format is not wanted this
is specified by a read mask. The output is written
at the location specified by caller.
Input: Time Format
Output: Time
Time is written as a part of RIC or INTM formats
or in RTC, INTM or RQT formats as a whole.
CC
- Complete
- Fail
4.1.6.2.3.2 C̲o̲n̲v̲e̲r̲t̲ ̲T̲i̲m̲e̲ ̲t̲o̲ ̲A̲S̲C̲I̲I̲
One or two bytes are converted to ASCII and written
at the location specified by caller:
Input: T̲i̲m̲e̲
One byte specifying Year, Month, Day, Hour,
Minute, or Second. Two bytes specifying Julian
Day.
T̲y̲p̲e̲
One byte specifying conversion type
Output: T̲i̲m̲e̲
Two or three ASCII characters
CC
- Complete
- Input out of range
- Unknown type
If input is year, day, hour, minute, or second the
input must not exceed 99. The associated output is
two ASCII characters defining the two figures in input.
If input is month it must not exceed 12. The associated
output is three ASCII characters defining the three
letter abbreviation for the month.
If input is Julian day it must not exceed 366.
The associated output is three ASCII characters defining
the three figures in input.
4.1.6.2.3.3 C̲o̲n̲v̲e̲r̲t̲ ̲T̲i̲m̲e̲ ̲F̲o̲r̲m̲a̲t̲
One time format is converted to another. The possible
conversions are
HM to MIN
MIN to HM
(Month, Day) to JUL
JUL to (month, day)
Input: T̲i̲m̲e̲
One word time format of format MIN, HM, JUL,
or (Month, Day)
T̲y̲p̲e̲
Specifying format type
Output: T̲i̲m̲e̲
In format MIN, HM, JUL, or (Month, Day)
C̲C̲
- Complete
- Input out of range
- Unknown fomat
The allowed values for input are specified by the formats.
4.1.6.2.3.4 S̲e̲t̲ ̲T̲i̲m̲e̲
Sets the time in DAMOS Real Time Clock Module to the
time specified by SSC. The time must be in the INTS
format.
The function is privileged.
Input: T̲i̲m̲e̲
Current time in INTS format
Output: C̲C̲
- Complete
- Unknown Time Format
4.1.6.2.3.5 R̲e̲q̲u̲e̲s̲t̲ ̲T̲i̲m̲e̲ ̲O̲u̲t̲
A time out is requested by calling the procedure "Request
Time Out" with the actual input parameter.
When the time specified has passed a QEL is sent to
specified queue.
The QEL contains the current time and event ID in info
field.
The time out may be requested to be sent once or periodic.
If caller has no more requests left or if event ID
is used by another request a QEL is returned to answer
queue immediately. In this QEL current time is set
to a value out of HM format range.
Input: T̲i̲m̲e̲
The time when time out shall be sent. The time
must be in one of these formats
Hours from now
Minutes from now
Seconds from now
Or if the time out is requested only once
HM format
MIN format
T̲y̲p̲e̲
Telling whether the time out is periodic or
not and what format is used by input time.
A̲n̲s̲w̲e̲r̲ ̲q̲u̲e̲u̲e̲
Identifying the sub queue to which the time
out shall be sent. Caller must have receive
capability to the queue.
E̲v̲e̲n̲t̲ ̲I̲D̲
Callers own information (2 words). Must be
unique for calling sub-process.
Output: C̲C̲
- Complete
- Unknown time format
- Wrong time format
- No capability
Output when time out time is present:
Q̲E̲L̲
Reference to a QEL containing event ID in the
first two words of information field and current
time in HM format in the last info word. The
QEL has object type TIME OUT.
4.1.6.2.3.6 C̲a̲n̲c̲e̲l̲ ̲T̲i̲m̲e̲ ̲O̲u̲t̲
A previous time request is cancelled.
If a time out QEL has already been sent, then the call
has no effect.
4.1.6.2.4 M̲e̲s̲s̲a̲g̲e̲ ̲M̲o̲n̲i̲t̲o̲r̲ ̲I̲n̲t̲e̲r̲f̲a̲c̲e̲s̲
The general environment for Message Monitor is shown
in figure 4.1.6.2.4-1. Message Monitor is an interface
module between application processes and Message Management
System. In a few cases the parent process COPSY is
involved in security procedures.
Message Monitor and Message Management System form
together a Service System in the sense described in
section 2.2.1.6.
All Message Monitor functions available to application
processes are called via System Call Monitor as described
in section 2.2.1.6 and 4.1.6.2.6. All functions may
be called as Init-Wait functions.
The SAVE VIEW function is called by application processes
requesting a checkpoint. The request is sent to CSF
process which in turn calls the SAVE function. This
mechanism is used in order to ensure that only one
SAVE is in progress at a time and that SAVE requests
can be synchronized without risk of deadlock.
As all Message Management System functions are executed
within a short time, it makes no sense to cancel any
of those functions while in progress. Thus while CANCEL
is a legal function, it has no effect on MMS functions.
The parameter conventions for Message Monitor functions
are summarized in table 4.1.6.2.4-1. The input parameters
apply to the Init part of the function while the output
parameters are delivered by the Wait part.
The View Attributes parameter always has the format
of a "View-Attributes Parameter Block" as shown in
section 4.2.4.4.
The view Reference parameter is always a Queue Element
Reference as defined by Queue Monitor in 4.1.1.2.3.
The Destination Queue parameter is a queue reference
as defined by Queue Monitor in section 4.1.6.2.2.
FIGURE 4.1.6.2.4-1…01…MESSAGE MONITOR ENVIRONMENT
Input Output
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
Create CIF CIF Creation
View
Reference
Parameter Block View Attributes
Destination Queue Completion
Code
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
Create New CIF View Reference, View
Reference,
new
version
previous version View Attributes,
new version
Completion
Code
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
Create View View Reference, View
Reference,
new
version
Predecessor View
View Attributes View Attributes
Destination Queue Completion
Code
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
Create Fields View Reference Completion
Code
Field Information
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
Get View View Reference View
Attributes
Attributes Completion
Code
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
Change Profile View Reference Completion
Code
Qprofile
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
- Dismantle View View Reference Completion
Code
- Open View
- Close View
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
Save View View Reference Completion
Code
Recovery Level
Dismantle Flag
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
Save VCB Id Completion
Code
Recovery Level
Dismantle Flag
Buffer Address
Buffer Length
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
Table 4.1.6.2.4-1 Message Monitor Functions Interface Summary…86…1…02… …02… …02…
…02… …02…
Input Output
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
Store View Reference CIF Id,
View Id
Completion
Code
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
Retrieve Type View
Reference
Dump File Reference View Attributes
Dump Segment Id Completion
Codes
View Attributes
Destination Queue
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
Dump CIF Dump File
Reference Number
of
Dumped
CIFs
Sequence CIF Id
List Updated
CIF
Id
List
Completion
Code
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
Clear Clear Time Completion
Code
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
Init Dump Dump File
Reference Dump
Segment
Id
Completion
Code
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
Terminate Dump Dump File
Reference Completion
Code
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
Set Security Security
Interrogation Completion
Code
Parameters Profile
Security Warning
Profile
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
Start System Recovery
Level Completion
Code
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
Set Threshold Threshold
Values Completion
Code
Values
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
Table 4.1.6.2.4-1 (contd.)
Get Threshold None Warning
Type
Warning Completion
Code
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
Get Storage None Occupancy
Figures
Occupancy
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
- Read View View Reference Updated
Field
List
- Write View Buffer
Address Completion
Code
Buffer Size
Field List
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
Table 4.1.6.2.4-1 (contd.)
4.1.6.2.5 C̲o̲r̲o̲u̲t̲i̲n̲e̲ ̲M̲o̲n̲i̲t̲o̲r̲ ̲I̲n̲t̲e̲r̲f̲a̲c̲e̲s̲
Coroutine Monitor is a set of shared
procedures. An overview of parameters
for the functions is shown in table
4.1.6.2.5-1/2.
TABLE 4.1.6.2.5-1
PARAMETERS FOR COROUTINE SYSTEM CALL FUNCTIONS
TABLE 4.1.6.2.5-2…01…PARAMETERS FOR SEMAPHORE FUNCTIONS
4.1.6.2.6 S̲y̲s̲t̲e̲m̲ ̲C̲a̲l̲l̲ ̲M̲o̲n̲i̲t̲o̲r̲ ̲I̲n̲t̲e̲r̲f̲a̲c̲e̲s̲
System Call Monitor is largely a transparent interface
between applications and service systems.
A global view of the System Call Monitor interfaces
and their logical connection is shown in figure 4.1.6.2.6-1.
Service System Interface is in this section in short
called Service System.
4.1.6.2.6.1 G̲e̲n̲e̲r̲a̲l̲ ̲S̲y̲s̲t̲e̲m̲ ̲C̲a̲l̲l̲ ̲C̲o̲n̲v̲e̲n̲t̲i̲o̲n̲s̲
As seen in table 4.1.6.2.6-1, Init System Call and
System Call have each two parameter groups:
- Function
- Service System Parameters
These two parameter groups are by Init System Call
sent unchanged to the appropriate Service System in
the Init Function call, as shown in table 4.1.6.2.6-2.
The general conventions for the two parameter groups
are:
a) F̲u̲n̲c̲t̲i̲o̲n̲
Consists of two bytes:
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
SERVICE SYSTEM ID SERVICE SYSTEM FCT
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
SERVICE SYSTEM ID:
Identification of the Service System to be called,
e.g.
IOS
QMON
MMON
TMP
FORMAT I/O
SERVICE SYSTEM FCT:
The function requested from Service System, e.g.
RECEIVE
READBYTES
The SERVICE SYSTEM part of function is delivered
to SERVICE SYSTEM in Register R7.
The complete function is delivered by the application
as a register R6 parameter in the MONITOR call
to System Call Monitor.
b) S̲e̲r̲v̲i̲c̲e̲ ̲S̲y̲s̲t̲e̲m̲ ̲P̲a̲r̲a̲m̲e̲t̲e̲r̲s̲
These are the five registers RO-R4 in Init System
Call and they are passed unchanged to Init Function.
4.1.6.2.6.2 G̲e̲n̲e̲r̲a̲l̲ ̲W̲a̲i̲t̲-̲C̲o̲m̲p̲l̲e̲t̲e̲ ̲F̲u̲n̲c̲t̲i̲o̲n̲ ̲C̲o̲n̲v̲e̲n̲t̲i̲o̲n̲s̲
The call of System Call Monitor function WAIT will
eventually result in a call of COMPLETE FUNCTION in
the Service System responsible for the operation in
question.
The return parameters from COMPLETE FUNCTION are:
a) Service System Return Parameters:
Registers R0 - R4
b) Completion Code:
Register R7
c) Exit Condition:
Exit 0: Error Exit
Exit 1: Normal Exit
These return parameters will by WAIT be returned directly
to the calling application.
4.1.6.2.6.3 I̲n̲t̲e̲r̲f̲a̲c̲e̲ ̲t̲o̲ ̲S̲e̲r̲v̲i̲c̲e̲ ̲S̲y̲s̲t̲e̲m̲
a) G̲e̲n̲e̲r̲a̲l̲ ̲I̲n̲f̲o̲r̲m̲a̲t̲i̲o̲n̲
There are two types of Service Systems. One type
uses the I/O system. The other type uses synchronization
elements to receive external events. System Call
Monitor includes one Service System of each type:
- I/O Interface
- PCF Interface
A Service System of type 2 shall have exactly one
synchronization element associated with it, and
all "awaits" on the synchronization element must
be performed by System Call Monitor.
Each Service System is described in System Call
Monitor by a Service System Control Block, shown
in 4.2.6.4.6. Each initiated operation is described
by a System Operation Control Block, shown in 4.2.6.4.5.
An operation is pending if it is not yet terminated
by an external event. The SOCBs for pending operations
are chained to the SSCB.
An operation is done when it has been terminated
by an external event. It is the responsibility
of the Service system to determine when an operation
changes status from pending to done, and to change
the System Call Status in SOCB. This change must
take place in the "answer received" procedure or
the "init function" procedure of the Service System.
Some Service Systems work on data shared by several
processes. In that case exclusive access to shared
data can be assured by locking a hardware semaphore
before manipulating the data. System Call Monitor
can disable interrupts and lock a semaphore before
entry to a Service System and unlock semaphore
and enable interrupts after return. The SSCB contains
information describing if this action shall be
performed.
The following sections describe the rules which
must be followed by the four Service System procedures.
b) I̲n̲i̲t̲ ̲F̲u̲n̲c̲t̲i̲o̲n̲
The Function and Service System parameters are
transferred unchanged from the calling application.
The operation to be initiated will be described
by the SOCB, the address of which is delivered
as a parameter.
The Service System shall initiate the operation
and save in SOCB the information necessary to recognize
the answer later on in "answer received" function.
If the Service System is of the first type using
the I/O system, it shall initiate the function
by calling an init- function of the I/O system.
The "user operation reference" parameter to the
init call shall be the SOCB Pointer.
The operation may already be terminated in the
Init Function. This may for example happen in case
of a parameter error. In that case the Service
System must change the SOCB System Call Status.
The status may be changed to:
1) Done
Then the Service System will eventually be
called in the Complete Function entry point
with the SOCB as parameter.
2) Error
Then the return parameters and exit condition
will be transferred to the application and
the SOCB released.
Upon return from Init Function, System Call Monitor
will chain the SOCB to a list depending upon System
Call Status:
3) Pending
Chain to pending operations list in SOCB
4) Done
Chain to the ready operations list
5) Error
Release SOCB
c) A̲n̲s̲w̲e̲r̲ ̲R̲e̲c̲e̲i̲v̲e̲d̲
For a type 1 Service System this procedure is entered
when I/O system has returned the SOCB pointer as
"user operation reference" in a General Await function
call. The Service System may now determine if the
function is terminated or if yet another I/O Operation
shall be initiated. In the latter case it shall
just return to System Call Monitor without changing
the System Call Status of SOCB. If the operation
is terminated, the following shall be done by Service
System:
1) Change SOCB System Call Status to DONE
2) Call the I/O function WAITOPERATION and save
the return parameters in SOCB. These shall
later on be used in Complete Function.
For a type 2 Service System the Answer Received
procedure is entered whenever info is received
in the associated synchronization element.
Answer Received is called with two parameters:
3) A pointer to the received Info.
4) A pointer to first SOCB in the list of pending
SOCBs.
The Service System shall now inspect the list of
SOCBs and determine if one or more of the operations
are terminated. It shall then change System Call
Status of the terminated SOCBs to DONE and return
two parameters to System Call Monitor:
5) Number of terminated operations (may be zero)
6) A pointer to the first terminated operation
if any
For each of the terminated operations complete
function will eventually be called.
d) C̲o̲m̲p̲l̲e̲t̲e̲ ̲F̲u̲n̲c̲t̲i̲o̲n̲
This Service System procedure is called when the
application has called the System Call Monitor
function WAIT and the referenced SOCB is DONE.
The Service System shall now complete the processing
of the operation and return parameters and exit
condition.
e) C̲a̲n̲c̲e̲l̲ ̲F̲u̲n̲c̲t̲i̲o̲n̲
This procedure will only be called if the operation
is still pending. The Service System may change
System Call Status to DONE or may leave it unchanged
awaiting an answer eventually.
FIGURE 4.1.6.2.6-1…01…SYSTEM CALL MONITOR INTERFACES
TABLE 4.1.6.2.6-1…01…APPLICATION INTERFACE TO SYSTEM CALL MONITOR
TABLE 4.1.6.2.6-2…01…SYSTEM CALL MONITOR INTERFACE TO SERVICE SYSTEM
4.2 S̲u̲b̲p̲a̲c̲k̲a̲g̲e̲ ̲S̲p̲e̲c̲i̲f̲i̲c̲a̲t̲i̲o̲n̲s̲
4.2.1 C̲S̲F̲ ̲C̲o̲m̲m̲o̲n̲ ̲F̲u̲n̲c̲t̲i̲o̲n̲s̲
4.2.1.1 F̲u̲n̲c̲t̲i̲o̲n̲a̲l̲ ̲S̲p̲e̲c̲i̲f̲i̲c̲a̲t̲i̲o̲n̲
The CSF Common Function Subpackage covers functional
areas which are utilized by other CSF subpackages as
well as application processes. They are shown on figure
4.2.1.1-1.
FIGURE 4.2.1.1-1…01…CSF SHARED FUNCTIONS
