top - download
⟦3deb8c640⟧ Wang Wps File
Length: 37525 (0x9295)
Types: Wang Wps File
Notes: CPS/SDS/001 ISSUE 1
Names: »0683A «
Derivation
└─⟦6472223e8⟧ Bits:30006010 8" Wang WCS floppy, CR 0045A
└─ ⟦this⟧ »0683A «
WangText
…13……0b……13……00……13……05……12……09……12……0a……12……0c……12……0e……12……00……12…
…12… …12……86…1
…02…
…02…
…02…
…02…CPS/SDS/001
…02…OKH/810227…02……02…
CAMPS
SYSTEM
DESIGN
SPECIFICATION
…02……02…CAMPS
T̲A̲B̲L̲E̲ ̲O̲F̲ ̲C̲O̲N̲T̲E̲N̲T̲S̲
5.8 CAMPS System Functions ................ 349
5.8.1 Summary of Requirements ............. 349
5.8.1.1 General Description ............. 349
5.8.1.1.1 Purpose ..................... 349
5.8.1.1.2 Package Interfaces .......... 350
5.8.1.1.3 External Interfaces ......... 351
5.8.1.2 Functions ....................... 361
5.8.1.2.1 Shared Data Functions ....... 361
5.8.1.2.2 Audit Collection Functions .. 362
5.8.1.2.3 Monitor Functions ........... 363
5.8.1.2.3.1 Queues .................. 363
5.8.1.2.3.2 Queue Elements .......... 366
5.8.1.2.3.3 Queue Monitor Functions . 369
5.8.1.2.3.4 Queue Monitor Design
Considerations .......... 371
5.8.1.2.3.5 Message Monitor ......... 372
5.8.1.2.3.6 Message Monitor Functions 373
5.8.1.2.3.7 Security and Access
Control ................. 377
5.8.1.2.3.8 Message Monitor Recovery 379
5.8.1.2.3.9 Message Monitor Design
Considerations .......... 380
5.8.1.2.3.10 Timer Monitor ......... 380
5.8.1.2.4 Trace Function .............. 382
5.8.1.3 CSF Control ..................... 383
5.8.1.3.1 Parameter Control ........... 383
5.8.1.3.2 Initialization .............. 383
5.8.1.3.3 Error Handling .............. 383
5.8.1.4 Characteristics ................. 384
5.8.1.4.1 Availability ................ 384
5.8.1.4.2 Security .................... 384
5.8.1.5 Design and Construction ......... 384
5.8.1.6 Documentation ................... 384
5.8.2 Environment ......................... 384
5.8.2.1 Standard Hardware, Firmware and
Software ........................ 384
5.8.2.2 External Interfaces ............. 385
5.8.2.3 Sub-system Interfaces ........... 385
5.8 C̲A̲M̲P̲S̲ ̲S̲Y̲S̲T̲E̲M̲ ̲F̲U̲N̲C̲T̲I̲O̲N̲S̲
5.8.1 S̲u̲m̲m̲a̲r̲y̲ ̲o̲f̲ ̲R̲e̲q̲u̲i̲r̲e̲m̲e̲n̲t̲s̲
5.8.1.1 G̲e̲n̲e̲r̲a̲l̲ ̲D̲e̲s̲c̲r̲i̲p̲t̲i̲o̲n̲
5.8.1.1.1 P̲u̲r̲p̲o̲s̲e̲
CSF is a package of support functions, which together
with KER, IOC, and TMP form the software environment
for CAMPS packages.
CSF contains four groups of functions:
1) S̲h̲a̲r̲e̲d̲ ̲D̲a̲t̲a̲ ̲S̲u̲p̲p̲o̲r̲t̲
Tools for synchronizing access to shared variables
and for management of shared buffer pools.
2) A̲u̲d̲i̲t̲ ̲C̲o̲l̲l̲e̲c̲t̲i̲o̲n̲ ̲S̲u̲p̲p̲o̲r̲t̲
Tools for collection of statistics, log, and report
records on behalf of the packages handling those
auditing data.
3) M̲o̲n̲i̲t̲o̲r̲ ̲F̲u̲n̲c̲t̲i̲o̲n̲s̲
a) Timer Monitor supplying various timer facilities.
b) Queue Monitor with tools for queuing of messages
and other events between CAMPS modules.
c) Message Monitor, which together with SFM package
supplies a set of tools for message management
and control of message flow. It performs the
following tasks:
1) M̲e̲s̲s̲a̲g̲e̲ ̲R̲e̲f̲e̲r̲e̲n̲c̲i̲n̲g̲
Tools for referencing messages via queue
elements or message identification.
2) M̲e̲s̲s̲a̲g̲e̲ ̲V̲i̲e̲w̲
Transformation between the stored structure
of a message and the structure needed by
application modules.
3) S̲e̲c̲u̲r̲i̲t̲y̲ ̲a̲n̲d̲ ̲A̲c̲c̲e̲s̲s̲ ̲C̲o̲n̲t̲r̲o̲l̲
Message Monitor is the central point for
the CAMPS specific high level security
and access control functions.
4) M̲e̲s̲s̲a̲g̲e̲ ̲T̲r̲a̲n̲s̲i̲t̲i̲o̲n̲ ̲C̲o̲n̲t̲r̲o̲l̲
Tools by which application modules can
cooperate in controlling the state and
processing flow of messages.
5) C̲h̲e̲c̲k̲p̲o̲i̲n̲t̲ ̲a̲n̲d̲ ̲R̲e̲c̲o̲v̲e̲r̲y̲
6) S̲F̲M̲ ̲I̲n̲t̲e̲r̲f̲a̲c̲e̲ ̲F̲u̲n̲c̲t̲i̲o̲n̲s̲
Functions for access to items containing
messages.
4) T̲r̲a̲c̲e̲ ̲F̲u̲n̲c̲t̲i̲o̲n̲
A system testing tool enabling a trace of CAMPS
module activities.
5.8.1.1.2 P̲a̲c̲k̲a̲g̲e̲ ̲I̲n̲t̲e̲r̲f̲a̲c̲e̲s̲
a) I̲n̲t̲e̲r̲f̲a̲c̲e̲ ̲t̲o̲ ̲K̲E̲R̲
CSF makes use of KER facilities to perform its
functions. Especially important are the following
KER functions:
1) P̲a̲g̲e̲ ̲M̲a̲n̲a̲g̲e̲m̲e̲n̲t̲
Used to implement data sharing and protect
shared data against illegal access in user
mode, when needed.
2) P̲r̲o̲c̲e̲s̲s̲ ̲C̲o̲m̲m̲u̲n̲i̲c̲a̲t̲i̲o̲n̲
Used to synchronize access to shared data and
to implement queuing functions.
3) R̲e̲a̲l̲ ̲T̲i̲m̲e̲ ̲C̲l̲o̲c̲k̲
Used to implement timer management.
As CSF manages shared, but protected data, it will
mostly execute in system mode, invoked by MON calls.
b) I̲n̲t̲e̲r̲f̲a̲c̲e̲ ̲t̲o̲ ̲S̲F̲M̲
Message Monitor within CSF is the interface mechanism
to the M̲essage M̲anagement S̲ystem (MMS) component
of SFM. This means that all access from CAMPS
application modules to MMS will go through Message
Monitor.
In addition, CSF makes use of SFM to save all data
in case of a CLOSE DOWN.
c) O̲t̲h̲e̲r̲ ̲I̲n̲t̲e̲r̲f̲a̲c̲e̲s̲
As a support package, CSF is used by all CAMPS
packages as shown on the interface charts. The
interfaces to KER are not specifically shown on
those charts.
5.8.1.1.3 E̲x̲t̲e̲r̲n̲a̲l̲ ̲I̲n̲t̲e̲r̲f̲a̲c̲e̲s̲
CSF has no external interfaces.
Fig. 5.8.1.1.2-1
SHARED DATA SUPPORT INTERFACES
1) Set Time
2) Get Time
3) Request Time-out
4) Regret Time-out
5) Send to Queue
6) Receive from Queue
Fig. 5.8.1.1.2-…01…TIMER MONITOR INTERFACE CHART
1) Save
2) Restore
3) Send Multiple
4) Initialize
5) Stop
6) Initialize
7) Dismantle
Fig. 5.8.1.1.2-2, 3, 4, 5, 6, 7 og 8
MESSAGE MONITOR RECOVERY INTERFACE CHART
1) Open message
2) Open notification
3) Security interrogation and/or security warning
4) Open confirmation
5) Return from open call
6) Terminal may now access message and write it out.
Fig. 5.8.1.1.2-…01…SECURITY INTERROGATION INTERFACE CHART
1) Initialize 10) Read Bytes/Field Group
2) Open Interrogation 11) Modify Bytes
3) Open Confirmation 12) Append Bytes
4) Dump 13) Message Monitor uses
all
5) Retrieve Message Management
System
6) Create Message Functions
7) Create next version 14) Check Security
8) Open Message 15) Access Message Control
Block
9) Close Message 16) Error Report
17) Send Multiple
18) Get/Put MCB Fields
Fig. ?…01…MESSAGE MONITOR INTERFACE CHART
Fig. 5.8.1.1.2-
QUEUE MONITOR REQUEST - REPLY INTERFACE CHART
1) Initialize
2) Send
3) Receive
4) Return
5) Dismantle
6) Error Report
Fig. ?…01…QUEUE MONITOR INTERFACE CHART
1) Collect Statistics 6) Log Area Full
2) Collect Log 7) Update Variable
3) Collect Report 8) Read Variable
4) Reserve Variable 9) Send to Queue
5) Release Variable 10) Receive from Queue
Fig. 5.8.1.1.2-2…01…AUDIT COLLECTION INTERFACE CHART
1) Reserve Buffer
2) Release Buffer
3) Reserve Variable
4) Release Variable
5) Any other CSF function request
Fig. 5.8.1.1.2-1…01…SHARED DATA SUPPORT INTERFACES
5.8.1.2 F̲u̲n̲c̲t̲i̲o̲n̲s̲
5.8.1.2.1 S̲h̲a̲r̲e̲d̲ ̲D̲a̲t̲a̲ ̲F̲u̲n̲c̲t̲i̲o̲n̲s̲
Refer to figure 5.8.1.1.2-1.
Shared data are divided into two data types, shared
variables and shared buffers.
a) S̲h̲a̲r̲e̲d̲ ̲V̲a̲r̲i̲a̲b̲l̲e̲s̲
Permanent data which may be updated and read by
CAMPS modules either directly or via CSF functions.
Most cases of reading and all cases of updating
a shared variable require synchronization in order
that several modules do not access the variable
at the same time. This is done by means of the
following two functions:
1) R̲E̲S̲E̲R̲V̲E̲ ̲V̲A̲R̲I̲A̲B̲L̲E̲
Gives the caller exclusive access to the shared
variable. If another module has already gained
exclusive access, the caller will be suspended,
waiting for the other module to release the
variable. Input: Variable Name.
2) R̲E̲L̲E̲A̲S̲E̲ ̲V̲A̲R̲I̲A̲B̲L̲E̲
Releases a previously reserved variable.
Input: Variable Name.
b) S̲h̲a̲r̲e̲d̲ ̲B̲u̲f̲f̲e̲r̲s̲
CSF manages a number of buffer pools which are
partly used for internal CSF purposes, such as
queue elements, message control blocks, timer control
blocks etc. and may partly be used by other packages
as dynamic working space. Dynamic buffers have
different lengths and the requestor must specify
the required buffer length when allocating a buffer.
Two functions are used for allocation and deallocation
of dynamic buffers:
1) R̲E̲S̲E̲R̲V̲E̲ ̲B̲U̲F̲F̲E̲R̲
Allocates a dynamic buffer of the length specified
and maps it into the caller's address space
at the specified logical address. If no buffer
is currently available, the caller will be
suspended, waiting for another module to release
a buffer of the appropriate length.
Input: Buffer Length
Logical Address
2) R̲E̲L̲E̲A̲S̲E̲ ̲B̲U̲F̲F̲E̲R̲
Returns a previously allocated buffer.
Input: Logical Address.
c) D̲e̲s̲i̲g̲n̲ ̲C̲o̲n̲s̲i̲d̲e̲r̲a̲t̲i̲o̲n̲s̲
1) The reserve functions may require a time-out
limit, so that a module will not wait indefinitely
for a variable or a buffer.
2) It is assumed that shared variables are independent,
so that they are reserved and released one
at a time. Otherwise, a deadlock may occur.
If the assumption is invalid, some measure
for deadlock prevention must be considered.
3) The need for shared buffers as dynamic working
storage is still considered.
5.8.1.2.2 A̲u̲d̲i̲t̲ ̲C̲o̲l̲l̲e̲c̲t̲i̲o̲n̲ ̲F̲u̲n̲c̲t̲i̲o̲n̲s̲
The audit collection functions act as interfaces between
CAMPS modules and the appropriate audit processing
packages shown to the right on figure 5.8.1.1.2-2.
There are two main purposes of introducing the audit
collection functions:
1) To make it as easy and uniform as possible for
application modules to generate audit data. In
particular it should be possible to introduce new
types of for example statistics without extensive
changes in existing statistics generation mechanisms.
2) To protect audit data from direct access by application
modules.
5.8.1.2.3 M̲o̲n̲i̲t̲o̲r̲ ̲F̲u̲n̲c̲t̲i̲o̲n̲s̲
5.8.1.2.3.1 Q̲u̲e̲u̲e̲s̲
The queue is the major intermodule communication
tool within CAMPS. In special cases such as interface
to SFM and to IOC, the lower level Kernel interprocess
communication tool is used. This is also the basis
for the queue concepts of CSF.
The CSF monitor functions are using queues as a
basic tool for various purposes, so the following
description of queues and queue elements applies
to all monitor functions.
a) Q̲u̲e̲u̲e̲ ̲S̲t̲r̲u̲c̲t̲u̲r̲e̲
A queue is basically a linked list of information
elements, called q̲u̲e̲u̲e̲ ̲e̲l̲e̲m̲e̲n̲t̲s̲, sorted according
to a priority. The number of priorities associated
with each queue is predefined. So each queue
is structured into a predefined number of s̲u̲b̲-̲q̲u̲e̲u̲e̲s̲,
with one sub-queue per priority level.
Each sub-queue is handled as an FIFO list.
The sub-queue priority is not directly related
to the CAMPS precedence levels, but it will
be used to implement generalized precedence
queues.
The queue structure is visualized overleaf
in figure 5.8.1.2.3.1.1-1.
Fig. 5.8.1.2.3.1.1-1
QUEUE STRUCTURE. TWO PRIORITY 1 and ONE PRIORITY 3 ELEMENTS
WAITING.
2) Q̲u̲e̲u̲e̲ ̲R̲e̲f̲e̲r̲e̲n̲c̲i̲n̲g̲
A Queue Monitor function may reference a main
queue or a sub-queue within a main queue.
A m̲a̲i̲n̲ ̲q̲u̲e̲u̲e̲ id is an integer.
A s̲u̲b̲-̲q̲u̲e̲u̲e̲ ̲i̲n̲d̲e̲x̲ is an integer, defining the
sub-queue number within the main queue.
A s̲u̲b̲-̲q̲u̲e̲u̲e̲ ̲i̲d̲ is a pair: main queue id, sub-queue
index.
A q̲u̲e̲u̲e̲ ̲i̲d̲ is a main queue id or a sub-queue
id.
A sub-queue id with index = 0 specifies the
main queue.
3) Q̲u̲e̲u̲e̲ ̲L̲e̲n̲g̲t̲h̲
The l̲e̲n̲g̲t̲h̲ of a sub-queue is the number of
elements in it. The length of a main queue
is the sum of the lengths of its sub-queues.
A queue may have a t̲h̲r̲e̲s̲h̲o̲l̲d̲ length associated
with it. If the queue length exceeds the threshold,
a warning report is sent to a report queue,
and the queue may be moved to disk. It is
still possible to send elements to the queue,
but at the cost of one or more disk accesses
per queue operation.
4) Q̲u̲e̲u̲e̲ ̲T̲i̲m̲e̲-̲o̲u̲t̲
A sub-queue may have an optional time-out limit
associated with it. The Queue Monitor will
then assure that no elements remain in the
queue for longer than the specified period.
If an element is timed out, it will automatically
be sent to a specified disposal queue.
5.8.1.2.3.2 Q̲u̲e̲u̲e̲ ̲E̲l̲e̲m̲e̲n̲t̲s̲
The objects which may be put into queues are called
q̲u̲e̲u̲e̲ elements, abbreviated to QEL.
A QEL will normally contain a reference to the "real"
object queued, e.g. a message. This means that an
object may at the same time reside in several queues.
In case of a message queued in more than one queue,
it is then the task of Message Monitor to keep track
of the concurrent use of the message by more than one
CAMPS module.
a) Q̲u̲e̲u̲e̲ ̲E̲l̲e̲m̲e̲n̲t̲ ̲F̲i̲e̲l̲d̲s̲
1) O̲b̲j̲e̲c̲t̲ ̲T̲y̲p̲e̲
Describes the type of object referenced by
the QEL, e.g.:
1.1) Message
1.2) Shared Buffer
1.3) Time-out Event from Timer Monitor
1.4) Function Request or Reply (ref. section
5.8.1.2.3.3.b)
2) O̲b̲j̲e̲c̲t̲ ̲R̲e̲f̲e̲r̲e̲n̲c̲e̲
The way of referencing the object depends upon
object type. For messages, the reference identifies
the message control block. For time-out events
it contains the event id.
3) P̲r̲e̲c̲e̲d̲e̲n̲c̲e̲
Where applicable, this field specifies object
precedence to be used when queuing an object.
4) T̲i̲m̲e̲ ̲S̲t̲a̲m̲p̲
Date and Time group of insertion into the queue.
As this field may be used for performance
monitoring, the precision is 0.1 sec.
5) O̲w̲n̲e̲r̲ ̲R̲e̲f̲e̲r̲e̲n̲c̲e̲
When a QEL has been "received" from a queue,
this field identifies the CAMPS module having
received the QEL. The field is used for access
control purposes.
6) I̲n̲f̲o̲r̲m̲a̲t̲i̲o̲n̲ ̲F̲i̲e̲l̲d̲
For some object types, the information referenced
will be contained in the QEL itself. This
is for example the case with function requests.
b) C̲r̲e̲a̲t̲i̲o̲n̲ ̲a̲n̲d̲ ̲D̲e̲l̲e̲t̲i̲o̲n̲ ̲o̲f̲ ̲Q̲u̲e̲u̲e̲ ̲E̲l̲e̲m̲e̲n̲t̲s̲
A QEL is basically an object reference, and an
object, e.g. a message, may at a given time be
referenced by a number of QEL's. Thus the events
causing creation and removal of QEL's are not the
same as the events causing creation and removal
of the referenced objects.
The following example describes the situation for
message referencing QEL's.
1) C̲r̲e̲a̲t̲i̲o̲n̲ ̲o̲f̲ ̲a̲ ̲Q̲E̲L̲
When a message is created by the Message Monitor
function Create Message, a QEL is created.
This QEL will subsequently be used by the
caller for all references to the message.
When a message is sent to another queue, a
new queue element is created and inserted into
the destination queue. Thus the original QEL
still exists and can be used by the caller
for subsequent message access or for additional
send calls.
2) D̲e̲l̲e̲t̲i̲o̲n̲ ̲o̲f̲ ̲a̲ ̲Q̲E̲L̲
When a CAMPS module has used a QEL, and has
terminated the use, it must indicate that the
QEL can be deleted. This is done by the Dismantle
function. Some Message Monitor functions may
implicitly dismantle the corresponding QEL.
This will be indicated specifically under
each function.
5.8.1.2.3.3 Q̲u̲e̲u̲e̲ ̲M̲o̲n̲i̲t̲o̲r̲ ̲F̲u̲n̲c̲t̲i̲o̲n̲s̲
This section describes the "pure" queue handling functions.
There is a number of additional functions especially
concerned with messages and recovery of message queues.
These functions are described under Message Monitor.
a) S̲e̲n̲d̲ ̲-̲ ̲R̲e̲c̲e̲i̲v̲e̲ ̲F̲u̲n̲c̲t̲i̲o̲n̲s̲
1) S̲e̲n̲d̲
Sends an object to a specified sub-queue.
The function creates a new QEL and inserts
it into the specified destination queue. The
QEL used as input parameter is still available
to the caller.
Input: QEL
Subqueue Id.
2) R̲e̲c̲e̲i̲v̲e̲
The caller receives the n'th free element in
the queue, and the element is reserved for
the caller. If the queue is empty or delay
o, the caller will be suspended until either
an element is sent to the queue or delay expires.
A zero delay indicates that an immediate return
must be made if the queue is empty. If n is
greater than the queue length, an error code
is returned.
The queue element is reserved by the caller
until it is either "dismantled" or "returned".
Input: Queue id
n
Delay
Output: QEL
3) R̲e̲t̲u̲r̲n̲
The queue element is inserted into the queue
at the position previously occupied. The reservation
caused by a previous receive is cancelled.
Input: QEL
4) D̲i̲s̲m̲a̲n̲t̲l̲e̲
Indicates that the caller will not use the
specified QEL any more. After the call, the
QEL will no longer exist. The call may also
have the effect that the object referenced
by the QEL is destroyed.
Input: QEL
b) F̲u̲n̲c̲t̲i̲o̲n̲ ̲R̲e̲q̲u̲e̲s̲t̲s̲
Are used to send short request strings to service
modules and await the completion of the request.
A function request contains the identification
of an answer queue to which a completion notification
must be sent.
The user of this feature should distinguish between
synchronous and asynchronous requests:
1) A request is synchronous if the caller wants
to wait until completion of the requested function.
In this case the caller must have a specific
queue which is only used for completion notifications.
2) A request is asynchronous if the caller wants
to do other jobs concurrently with function
execution. In this case, the completion notification
should be sent to the queue where the caller
receives its "normal" information.
The request-reply interface mechanism is shown
on figure 5.8.1.1.2-8.
3) S̲e̲n̲d̲ ̲R̲e̲q̲u̲e̲s̲t̲
Sends a function request to the specified destination
queue.
Input: Destination queue id.
Answer (sub) queue id.
Parameter string
4) S̲e̲n̲d̲ ̲R̲e̲p̲l̲y̲
Sends a completion notification corresponding
to a previously received request. The notification
may contain a text string.
Input: Queue element
Text string
c) A̲u̲x̲i̲l̲i̲a̲r̲y̲ ̲F̲u̲n̲c̲t̲i̲o̲n̲s̲
1) G̲e̲t̲ ̲Q̲u̲e̲u̲e̲ ̲L̲e̲n̲g̲t̲h̲
Returns the number of elements in a queue.
2) I̲n̲i̲t̲i̲a̲l̲i̲z̲e̲
Initializes the queues and queue elements.
5.8.1.2.3.4 Q̲u̲e̲u̲e̲ ̲M̲o̲n̲i̲t̲o̲r̲ ̲D̲e̲s̲i̲g̲n̲ ̲C̲o̲n̲s̲i̲d̲e̲r̲a̲t̲i̲o̲n̲s̲
A number of queue function issues are still considered,
as the requirements from using modules are still not
fully identified. They are briefly described in the
following.
a) M̲u̲l̲t̲i̲p̲l̲e̲ ̲R̲e̲c̲e̲i̲v̲e̲
This function would make it possible to receive
from several queues in one call, and to wait for
an element to be put into one of several empty
queues.
b) P̲e̲r̲f̲o̲r̲m̲a̲n̲c̲e̲ ̲M̲o̲n̲i̲t̲o̲r̲i̲n̲g̲
Gives tools for monitoring maximum, minimum and
average queue lengths and queue waiting times for
selected queues.
c) C̲l̲o̲s̲e̲ ̲Q̲u̲e̲u̲e̲
Makes it possible to stop subsequent insertions
into a sub-queue.
d) C̲o̲m̲b̲i̲n̲e̲d̲ ̲W̲a̲i̲t̲
Makes it possible to combine I/O wait with wait
on queues.
5.8.1.2.3.5 M̲e̲s̲s̲a̲g̲e̲ ̲M̲o̲n̲i̲t̲o̲r̲
MMON is the interface between CAMPS application modules
and the SFM M̲essage M̲anagement S̲ystem (MMS). It implements
the more CAMPS dependent aspects of message management.
Together with SFM it forms a CAMPS Message Manager.
Messages are created, manipulated, stored in Historic
Data Base and retrieved under control of MMON.
a) M̲e̲s̲s̲a̲g̲e̲ ̲R̲e̲f̲e̲r̲e̲n̲c̲i̲n̲g̲
For security reasons, applications never have a
direct reference to a message. Any reference to
a message must be done either via a QEL (queue
element) or via a unique MID (message identification).
1) R̲e̲f̲e̲r̲e̲n̲c̲e̲ ̲b̲y̲ ̲Q̲E̲L̲
Messages in process are stored in items under
MMS. An application can only access a message
which it has either received from a queue or
created itself. In the latter case, the message
belongs to a queue specified by creator at
creation time. So in any case, a message in
process belongs to one or more queues, which
are the basis for reference to the message.
All message handling functions except Retrieve
use QEL as message reference.
2) R̲e̲f̲e̲r̲e̲n̲c̲e̲ ̲b̲y̲ ̲M̲I̲D̲
Each message is at creation time supplied with
a unique message identification, namely the
item id generated by MMS. Messages in Historic
Data Base can only be referenced by MID, and
only by SAR package in the Retrieve function.
b) M̲e̲s̲s̲a̲g̲e̲ ̲V̲i̲e̲w̲
A message consists of a number of fields, and for
each application module normally only a subset
of the fields is of interest when reading and/or
updating the message. Certain applications may
also for ease of use be interested in presenting
the message fields in a sequence different from
the stored one.
For reasons of security and ease of use, each application
may then have an associated m̲e̲s̲s̲a̲g̲e̲ v̲i̲e̲w̲, defining:
1) The fields of a message which may be read by
the application.
2) The fields of a message which may be updated
by the application.
3) Optionally, a transformation between stored
and delivered field sequence.
Message view may either be associated directly
with the application or with a queue. In the latter
case, the view will then depend upon the queue
from which the message was received.
c) M̲e̲s̲s̲a̲g̲e̲ ̲C̲o̲n̲t̲r̲o̲l̲ ̲B̲l̲o̲c̲k̲
The M̲essage C̲ontrol B̲lock (MCB) is logically a
field of the message, containing key information
about the message, such as:
1) Message Type.
2) Security Profile
3) Time Stamp (TS) Creation
4) Message Originator
5) Message Transition State, e.g. current application
modules having access to the message
6) Message Structure Description
7) Message Trace Record describing the previous
history of the message in terms of statistical
information, queues passed etc.
For efficiency reasons, MCB is kept memory resident
as long as the message is in process. So MCB information
can be obtained and updated by applications without
disk accesses though still controlled by MMON,
as the message view includes the fields of MCB
which may be accessed by an application.
5.8.1.2.3.6 M̲e̲s̲s̲a̲g̲e̲ ̲M̲o̲n̲i̲t̲o̲r̲ ̲F̲u̲n̲c̲t̲i̲o̲n̲s̲
The functions of MMON will to a large extent be counterparts
to functions of Message Management System, because
an MMS function must be invoked by calling a MMON routine.
It is seen by the function descriptions, that all message
referencing is done via QEL except for the obvious
cases. This implies that the module creating a new
message or a new version, or retrieving an existing
message, must identify a local queue where the generated
QEL can be placed.
a) M̲e̲s̲s̲a̲g̲e̲ ̲H̲a̲n̲d̲l̲i̲n̲g̲ ̲F̲u̲n̲c̲t̲i̲o̲n̲s̲
1) C̲r̲e̲a̲t̲e̲ ̲M̲e̲s̲s̲a̲g̲e̲
Allocates an item for a new message with item
attributes as defined. A QEL is generated
and set to a state as if received from specified
queue.
Input: Message Attributes
Sub-queue Id
Output: MID
QEL
2) C̲r̲e̲a̲t̲e̲ ̲N̲e̲x̲t̲ ̲V̲e̲r̲s̲i̲o̲n̲
Generates a new version of an existing message
by allocating a new item. The generated QEL
is set in a state as if received from the same
queue as the one used as input parameter.
Input: QEL Referencing Current Version
Output: QEL Referencing New Version
3) D̲i̲s̲m̲a̲n̲t̲l̲e̲ ̲M̲e̲s̲s̲a̲g̲e̲
Terminates all use of a message by the caller.
May cause the message to be deleted or moved
to Intermediate Storage. If the message has
been checkpointed, the checkpoint may be removed.
Calls finally the QMON function Dismantle.
Input: QEL
4) S̲e̲n̲d̲ ̲M̲e̲s̲s̲a̲g̲e̲
This function sends a message to a number of
destination queues and changes message state
at the same time. The send and the new state
are checkpointed. The function may include
a dismantle.
Input: QEL
Destination Queue List
New Message State
Dismantle (boolean)
5) C̲h̲e̲c̲k̲ ̲S̲e̲c̲u̲r̲i̲t̲y̲
Check, if the specified application module
would be allowed to access the specified message.
Input: QEL
Application Module Id
Output: Confirmation Code
6) G̲e̲t̲ ̲M̲C̲B̲
Requests a copy of some fields within MCB.
Input: QEL
MCB View
Output: MCB Fields
7) P̲u̲t̲ ̲M̲C̲B̲
Supplies an updated version of some fields
within MCB. May include change of some attributes
such as security.
Input: QEL
MCB View
8) O̲p̲e̲n̲ ̲M̲e̲s̲s̲a̲g̲e̲
Includes calling module as a user of the message,
thus allowing subsequent message manipulating
functions. A check on security and access
rights will be performed before return. Moreover,
a parent notification may take place.
Input: QEL
9) C̲l̲o̲s̲e̲ ̲M̲e̲s̲s̲a̲g̲e̲
Terminates temporarily the use of a message
by caller. Used instead of dismantle if the
caller expects to access the message again
later on.
Input: QEL
10) S̲a̲v̲e̲ ̲M̲e̲s̲s̲a̲g̲e̲
Generates a checkpoint containing the current
state of the message.
b) M̲e̲s̲s̲a̲g̲e̲ ̲M̲a̲n̲i̲p̲u̲l̲a̲t̲i̲o̲n̲ ̲F̲u̲n̲c̲t̲i̲o̲n̲s̲
1) B̲y̲t̲e̲ ̲S̲t̲r̲i̲n̲g̲s̲ ̲i̲n̲ ̲F̲i̲e̲l̲d̲s̲
Read Bytes in Field
Modify Bytes in Field
Append Bytes in Field
Require that the message has been "opened".
Input: QEL
Field Address (Field, Address within
field)
Buffer List
2) R̲e̲a̲d̲ ̲F̲i̲e̲l̲d̲ ̲G̲r̲o̲u̲p̲
Reads a group of fields from a message.
Input: QEL
Field List
Buffer List
c) S̲t̲o̲r̲a̲g̲e̲ ̲a̲n̲d̲ ̲R̲e̲t̲r̲i̲e̲v̲a̲l̲ ̲F̲u̲n̲c̲t̲i̲o̲n̲s̲
Called by Storage and Retrieval Package for transfer
of messages between storage types.
1) S̲t̲o̲r̲e̲ ̲M̲e̲s̲s̲a̲g̲e̲
Causes a message to be transferred from Short
Term Storage to Intermediate Storage. The
request may be rejected if security profile
for message is higher than a preset level.
Input: QEL
2) D̲u̲m̲p̲ ̲M̲e̲s̲s̲a̲g̲e̲s̲
Transfers a message or a sequence of messages
from Intermediate Storage to Long Term Storage.
Input: MID sequence description
Volume id
3) R̲e̲t̲r̲i̲e̲v̲e̲ ̲M̲e̲s̲s̲a̲g̲e̲
Generates a temporary item in Short Term Storage
and copies the message into that item. Generates
a queue element and sets it into a state as
if received from specified queue.
Input: MID
Volume Id
Sub-queue Id
Output: QEL
5.8.1.2.3.7 S̲e̲c̲u̲r̲i̲t̲y̲ ̲a̲n̲d̲ ̲A̲c̲c̲e̲s̲s̲ ̲C̲o̲n̲t̲r̲o̲l̲
The functional level of security and access control
to messages as described in section 4.9 is performed
by Queue Monitor and Message Monitor of CSF.
There are four different mechanisms involved:
- Security control on message access
- Security interrogation and security warning control
- Queue access control
- Message view control
a) S̲e̲c̲u̲r̲i̲t̲y̲ ̲C̲o̲n̲t̲r̲o̲l̲
Each CAMPS application module will have a s̲e̲c̲u̲r̲i̲t̲y̲
p̲r̲o̲f̲i̲l̲e̲ associated with it. The profile is set
by SSC.
Also each message will have a security profile,
set by message originator at message creation time.
An application module cannot access any part of
a message, except from certain MCB fields, without
opening it before accessing. When the open function
is called, MMON performs the following check within
each compartment of security profile:
Security level of caller …0f…=…0e… security level of message.
The open call will only be accepted if this check
is passed together with the one described under
b) below.
b) S̲e̲c̲u̲r̲i̲t̲y̲ ̲I̲n̲t̲e̲r̲r̲o̲g̲a̲t̲i̲o̲n̲ ̲a̲n̲d̲ ̲S̲e̲c̲u̲r̲i̲t̲y̲ ̲W̲a̲r̲n̲i̲n̲g̲
VDU applications must pass a second check before
access to a message is granted, namely the security
interrogation or security warning carried out by
SSC. Refer to figure 5.8.1.1.2-6.
When the terminal process calls the open function
and the security check in a) is passed, MMON will
check the message security profile for a possibly
required security interrogation or security warning.
If required, a notification will be queued to
SSC and the reply is awaited. The reply from SSC
may be positive or negative and access to the message
thus granted accordingly.
c) Q̲u̲e̲u̲e̲ ̲A̲c̲c̲e̲s̲s̲ ̲C̲o̲n̲t̲r̲o̲l̲
If the checks under a) and b) allow it, an application
module may access any message in a queue from which
the application module can receive. In order to
control "who" may see which messages, one can thus
enforce two controls on queue access:
1) Specify for each application module from which
queues it may receive.
2) Specify for each application module to which
queues it may send and for which purposes.
By these two controls one can effectively limit
message flow channels within CAMPS to the authorized
ones, and one can centralize message distribution
decisions to certain modules such as MDP and THP.
d) M̲e̲s̲s̲a̲g̲e̲ ̲V̲i̲e̲w̲ ̲C̲o̲n̲t̲r̲o̲l̲
Even when an application module has been granted
access to a message by passing the checks a) -
c), the message view may be used to limit application
module capabilities to certain operations on certain
fields of the message.
e) M̲e̲s̲s̲a̲g̲e̲ ̲D̲i̲s̲t̲r̲i̲b̲u̲t̲i̲o̲n̲ ̲S̲e̲c̲u̲r̲i̲t̲y̲ ̲C̲h̲e̲c̲k̲
Application modules such as MDP and THP may want
to know, if a destination application would be
allowed to access a particular message, before
placing the message in a destination queue. This
check can be invoked by calling the Check Security
function of 5.8.1.2.3.6.a.5).
5.8.1.2.3.8 M̲e̲s̲s̲a̲g̲e̲ ̲M̲o̲n̲i̲t̲o̲r̲ ̲R̲e̲c̲o̲v̲e̲r̲y̲
Refer to figure 5.8.1.1.2-7
a) M̲e̲s̲s̲a̲g̲e̲ ̲C̲h̲e̲c̲k̲p̲o̲i̲n̲t̲s̲
When an application module issues the Send Multiple
function, MMON generates a checkpoint by the following
actions:
1) Insert new queue information into MCB
2) Insert new message state into MCB
3) Insert associated message view into MCB
4) Issue Save command to SFM
5) Issue Send functions to the specified queues
The Dismantle function may cause a checkpoint to
be removed.
b) R̲e̲c̲o̲v̲e̲r̲y̲ ̲o̲f̲ ̲M̲e̲s̲s̲a̲g̲e̲s̲
During system start-up SSC issues initialize command
to CSF. The command defines if message recovery
should be performed. If so, Message Monitor issues
a sequence of Restore commands to SFM. Each Restore
command returns a checkpointed MCB. The MCB is
regenerated in the MCB-area and the queue information
in MCB is used to insert the message in the appropriate
queues.
c) S̲y̲s̲t̲e̲m̲ ̲C̲l̲o̲s̲e̲
A Stop command from SSC causes Message Monitor
to write the total CAMPS system state to disk.
From now on CSF will not accept a̲n̲y̲ other command
than initialize. If the initialize command specifies
a warm start, the system state will be restored
from the disk copy.
5.8.1.2.3.9 M̲e̲s̲s̲a̲g̲e̲ ̲M̲o̲n̲i̲t̲o̲r̲ ̲D̲e̲s̲i̲g̲n̲ ̲C̲o̲n̲s̲i̲d̲e̲r̲a̲t̲i̲o̲n̲s̲
A number of Message Monitor functions are still considered,
such as:
a) Copy parts of a message into another without reading
it into application module buffers.
b) Relations to I/O system.
c) The effect of Message Deletion.
d) Integrate the Check Security function into Send
Message in order to avoid racing conditions.
e) Save MCB on disk when Message Monitor can foresee
that it will not be used for some time.
f) Clean up after terminal processes when logical
or physical access state changes.
5.8.1.2.3.10 T̲i̲m̲e̲r̲ ̲M̲o̲n̲i̲t̲o̲r̲
Timer Monitor contains two groups of functions, namely
timer event assistance and tools for manipulating current
time and date.
a) T̲i̲m̲e̲r̲ ̲D̲r̲i̲v̲e̲n̲ ̲E̲v̲e̲n̲t̲s̲
Timer Monitor has a timer facility whereby application
modules are assisted in scheduling timer driven
events, that is events that must occur at regular
intervals or at specific points in time. This
is carried out by requesting Timer Monitor to send
a QEL to a specified queue at the time where the
event should occur.
There are two functions available:
1) 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 period has elapsed, an answer
is sent back to a specified answer queue.
Refer to figure 5.8.1.1.2-4
Input: Time-out, either in the form of a time
period or an absolute time.
Answer queue.
Event id, which may be used by the
application to identify the
event waited for.
2) C̲a̲n̲c̲e̲l̲ ̲T̲i̲m̲e̲-̲O̲u̲t̲
Called if the application regrets a previously
requested time-out.
Input: Event id, which must uniquely identify
the event among those referring
to a specific answer queue.
b) C̲u̲r̲r̲e̲n̲t̲ ̲T̲i̲m̲e̲
1) G̲e̲t̲ ̲T̲i̲m̲e̲
Obtains the current date and time with the
precision of one second. The time may be in
various formats specified by format parameters.
Input: Format parameter
Output: Date and time in specified format
2) S̲e̲t̲ ̲T̲i̲m̲e̲
Sets current time to a new value.
5.8.1.2.4 T̲r̲a̲c̲e̲ ̲F̲u̲n̲c̲t̲i̲o̲n̲
Consists of two major parts:
a) Trace Procedure used to generate trace records
during normal processing.
b) Trace Print-out used to analyze the stored trace
records and print results in a readable format.
c) T̲r̲a̲c̲e̲ ̲P̲r̲o̲c̲e̲d̲u̲r̲e̲
TP will be invoked by CAMPS system functions in
order to produce a trace record of each major event
in the system. Examples of such events are:
1) Creation of a new message
2) Insertion of an element into a queue
3) Removal of an element from a queue
In addition, application modules may want to produce
trace records at certain points during processing
of a message. This may be done by direct invocation
of TP.
d) A trace record will contain the following information:
1) Time of occurrence of the traced event
2) Identification of the calling subsystem/module
3) Function code identifying the system function
call producing the trace record, such as "send
to queue".
4) System function call parameters, such as "destination
queue", "queue element" and call location.
A direct call of TP from a subsystem may in addition
to 1 - 3 above simply dump register contents and
perhaps the first N words referenced by a specific
register, which could for instance point to a message
control block.
The trace records produced will be written cyclically
onto a file on disk.
As trace recording may result in a considerable
CPU and disk overhead, the amount of tracing should
be adjustable. This is carried out in the following
way:
The system functions producing trace records are
divided into a number of trace groups. For each
application module, it is dynamically defined which
trace groups should be active for that module.
In addition one or more trace groups may be declared
inactive on a global level meaning that they will
never produce trace records, even if an application
module has declared them active. This mechanism
is implemented by a bit mask technique. Each trace
group corresponds to a bit in the mask. Each application
module has a mask defining its active trace groups
and finally this is a global trace mask.
e) T̲r̲a̲c̲e̲ ̲P̲r̲i̲n̲t̲-̲O̲u̲t̲
An offline utility is available for formatting
and print out of the trace record file.
5.8.1.3 C̲S̲F̲ ̲C̲o̲n̲t̲r̲o̲l̲
5.8.1.3.1 P̲a̲r̲a̲m̲e̲t̲e̲r̲ ̲C̲o̲n̲t̲r̲o̲l̲
CSF is controlled by parameters supplied by SSC during
initialization or set dynamically.
5.8.1.3.2 I̲n̲i̲t̲i̲a̲l̲i̲z̲a̲t̲i̲o̲n̲
At initialization SSC specifies the start-up situation
and the associated recovery level.
5.8.1.3.3 E̲r̲r̲o̲r̲ ̲H̲a̲n̲d̲l̲i̲n̲g̲
CSF has no internal error handling. Errors are either
returned to caller or reported to SSC.
5.8.1.4 C̲h̲a̲r̲a̲c̲t̲e̲r̲i̲s̲t̲i̲c̲s̲
5.8.1.4.1 A̲v̲a̲i̲l̲a̲b̲i̲l̲i̲t̲y̲
Not applicable.
5.8.1.4.2 S̲e̲c̲u̲r̲i̲t̲y̲
All security relevant CSF data reside in protected
memory, which is not accessible by application modules
in user mode. All CSF functions execute as MON functions
on the lower system levels. So they have no access
to the high level privileged instructions.
CSF parameter check assures that only authorized CAMPS
modules are allowed to invoke CSF functions and that
call parameters fullfil call specifications.
5.8.1.5 D̲e̲s̲i̲g̲n̲ ̲a̲n̲d̲ ̲C̲o̲n̲s̲t̲r̲u̲c̲t̲i̲o̲n̲
Refer to section 2.5.
5.8.1.6 D̲o̲c̲u̲m̲e̲n̲t̲a̲t̲i̲o̲n̲
Refer to section 2.6.
5.8.2 E̲n̲v̲i̲r̲o̲n̲m̲e̲n̲t̲
5.8.2.1 S̲t̲a̲n̲d̲a̲r̲d̲ ̲H̲a̲r̲d̲w̲a̲r̲e̲,̲ ̲F̲i̲r̲m̲w̲a̲r̲e̲ ̲a̲n̲d̲ ̲S̲o̲f̲t̲w̲a̲r̲e̲
CSF executes completely within the active PU.
5.8.2.2 E̲x̲t̲e̲r̲n̲a̲l̲ ̲I̲n̲t̲e̲r̲f̲a̲c̲e̲s̲
CSF has no external interfaces.
5.8.2.3 P̲a̲c̲k̲a̲g̲e̲ ̲I̲n̲t̲e̲r̲f̲a̲c̲e̲s̲
Not applicable
