top - download
⟦63392c20a⟧ Wang Wps File
Length: 23420 (0x5b7c)
Types: Wang Wps File
Notes: CAMPS SYSTEM FUNCTIONS
Names: »1057A «
Derivation
└─⟦5a07e954e⟧ Bits:30006038 8" Wang WCS floppy, CR 0062A
└─ ⟦this⟧ »1057A «
WangText
-…07…,…08…,…0e…,…01…,…02…,
, ,…05…,…06……86…1
…02…
…02…
…02…
…02…CPS/SDS/002
…02…OKH/810801…02……02…
CAMPS
SYSTEM
FUNCTIONS
…02……02…CAMPS
4.2.2.2 S̲o̲f̲t̲w̲a̲r̲e̲ ̲S̲t̲r̲u̲c̲t̲u̲r̲e̲
Queue Monitor consists of an SCM procedure, a number
of CSF procedures, a number of internal procedures
and a coroutine, ref. section 4.1.2.
The SCM procedure is Receive First QEL. The other external
procedures are CSF procedures. The common functions
described in 4.2.2.1.7 are internal procedures.
The QMON coroutine is used to signal the synchronization
elements associated with queues, ref. section 4.2.2.1.7.5.
4.2.2.3 D̲a̲t̲a̲ ̲F̲l̲o̲w̲ ̲a̲n̲d̲ ̲C̲o̲n̲t̲r̲o̲l̲ ̲L̲o̲g̲i̲c̲
QMON control flow is shown on fig. 4.2.2.3.
The four entry points from System Call Monitor are
shown at the left side.
The entry points are expanded into the functions performed
by QMON and it is shown what QMON common functions
and what CSF function are accessed by each QMON main
function.
FIGURE 4.2.2.2…01…QMON CONTROL LOGIC
4.2.2.4 S̲u̲b̲p̲a̲c̲k̲a̲g̲e̲ ̲D̲a̲t̲a̲
The data maintained by QMON are
- Main Q Description
- Sub Q Description
- Capability array
- QEL
The capability arrays are located in local CSF data
while the other data are located in shared CSF data,
ref. figure 4.1.4-1.
4.2.2.4.1 Q̲ ̲R̲e̲f̲e̲r̲e̲n̲c̲e̲s̲
The Qs are referenced in two ways. The one is by Q
capability which identifies the Q for one subpackage.
The Q capability is related to a main Q. This relation
is specified in the capability array. The second are
to specify the main Q direct. The Q references are.
MainQ ref: MainQ, NIL
SubQ ref: MainQ, SubQ ind.
Q ref.: Main Qref. or Sub Qref.
Abs Qref.: Integer identifying a subQ only used by
QMON.
4.2.2.4.2 C̲a̲p̲a̲b̲i̲l̲i̲t̲y̲ ̲A̲r̲r̲a̲y̲
The capability array gives the relation between Qcap
and MainQ and tells what functions the actual subprocess
is allowed to perform at specified MainQ.
There exists one capability array for each subprocess.
In each capability array exists one entry for each
MainQ known by the subprocess except for the subprocesses
having global rights which only have one entry telling
what functions are allowed at all Qs.
There is also a counter telling whether this subprocess
may receive more QELs.
Capability for one subprocess. See figure 4.2.2.4-1
and 2.
4.2.2.4.3 M̲a̲i̲n̲ ̲Q̲ ̲D̲e̲s̲c̲r̲i̲p̲t̲i̲o̲n̲
There is one main Q description for each main Q.
The main Q description format is shown on figure 4.2.2.4-3.
4.2.2.4.4 S̲u̲b̲ ̲Q̲ ̲D̲e̲s̲c̲r̲i̲p̲t̲i̲o̲n̲
There is one sub Q description for each sub Q.
The sub Q description format is shown on figure 4.2.2.4-4.
4.2.2.4.5 Q̲E̲L̲
The QELs are records held in double linked lists and
used by modules when they are communicating. The free
QELs are maintained by CSF common functions and the
others by QMON. The QELS may carry data direct or refer
indirect to them. The internal record structure is
maintained by QMON.
The QEL format is described in fig. 4.2.2.4.5.
FIGURE 4.2.2.4-3…01…MAIN QUEUE DESCRIPTOR
FIGURE 4.2.2.4-4…01…SUBQUEUE DESCRIPTOR
FIGURE 4.2.2.4-5…01…QEL FORMAT
4.2.2.5 Q̲M̲O̲N̲ ̲I̲n̲t̲e̲r̲f̲a̲c̲e̲
QMON interfaces are described at fig. 4.2.2.5.
FIGURE 4.2.2.5-1…01…QMON SUBPACKAGE INTERFACE
4.2.3 T̲i̲m̲e̲r̲ ̲M̲o̲n̲i̲t̲o̲r̲
4.2.3.1 F̲u̲n̲c̲t̲i̲o̲n̲a̲l̲ ̲S̲p̲e̲c̲i̲f̲i̲c̲a̲t̲i̲o̲n̲
The Timer Monitor performs functions related to time.
The functions here described are derived from the requirements
to the application software.
4.2.3.1.1 R̲e̲a̲d̲ ̲a̲n̲d̲ ̲C̲o̲n̲v̲e̲r̲t̲ ̲T̲i̲m̲e̲
This module supplies using modules with tools to read
current time and convert it to the needed format.
4.2.3.1.1.1 R̲e̲a̲d̲ ̲T̲i̲m̲e̲
Reads the time from DAMOS Real Time Clock Module and
writes specified part of the time in an area specified
by caller.
The written part of time may be a part of the RTC format
read from real time clock or a part of the INTS format
got by letting DAMOS convert RTC to INTM and remove
the milliseconds.
The wanted part is specified by a bit mask where the
6 least significant bits specifies which of the 6 bytes
are wanted and the 2 most significiant bits tell what
format is wanted.
Input: Time Format
Output: Time
CC
4.2.3.1.1.2 C̲o̲n̲v̲e̲r̲t̲ ̲T̲i̲m̲e̲ ̲t̲o̲ ̲A̲S̲C̲I̲I̲
The input is converted to ASCII. The month is converted
to a three letter abbreviation.
Year, day, hour, minute or second are converted to
two figures telling the integer value. Julian day is
converted to three figures telling the integer value.
The output time is written in the area specified by
call.
Input: T̲i̲m̲e̲
T̲y̲p̲e̲
An integer (0-2) telling what type the
input time is.
Output: C̲o̲n̲v̲e̲r̲t̲e̲d̲ ̲T̲i̲m̲e̲
C̲C̲
Complete
4.2.3.1.1.3 C̲o̲n̲v̲e̲r̲t̲ ̲T̲i̲m̲e̲ ̲F̲o̲r̲m̲a̲t̲
Converts one format to another format. The HM format
is converted to the MIN format.
The MIN format is converted to the HM format.
The month and hour from one of the integer formats
is converted to JUL format.
The JUL format is converted to month and day.
The output time is written in an area specified by
call.
Input: T̲i̲m̲e̲
T̲y̲p̲e̲
Specifies type of conversion
Output: C̲o̲n̲v̲e̲r̲t̲e̲d̲ ̲t̲i̲m̲e̲
4.2.3.1.1.4 S̲e̲t̲ ̲T̲i̲m̲e̲
Sets the time maintained by DAMOS Real Time Clock Module.
Checks that calling process is allowed to call the
function. Then sets the DAMOS system time with the
millisecond field set to zero.
Input: T̲i̲m̲e̲
Current time in INTS format
Output: C̲C̲
Complete
Fail
4.2.3.1.2 T̲i̲m̲e̲o̲u̲t̲ ̲F̲u̲n̲c̲t̲i̲o̲n̲
4.2.3.1.2.1 R̲e̲q̲u̲e̲s̲t̲ ̲T̲i̲m̲e̲o̲u̲t̲
Checks the answer queue parameter and converts it to
an absolute queue reference by calling the QMON function
check capability. Then sends the request in an info
block to the CSF process synchronization element.
The Timer Request coroutine receives the request and
checks if the calling subprocess has more T̲imer C̲ontrol
B̲locks available. Then checks if event id already exists
for the subprocess. If any errors, a QEL is sent to
the answer queue indicating the error. Otherwise a
TCB is allocated and initialized according to call
parameters.
The TCB is inserted into the timer queue sorted after
the remaining time until next timeout. If it then becomes
the first element in the queue, timeout must be rescheduled
by cancelling current DAMOS RTC timeout request.
Input: A̲n̲s̲w̲e̲r̲ ̲Q̲
The Q where the time out will be received.
E̲v̲e̲n̲t̲ ̲I̲O̲
A two word information to the time out
receiver. The event IDs must be unique
for the caller.
T̲y̲p̲e̲
Telling if it is a periodic request or
not.
T̲i̲m̲e̲
The time when the time out shall be sent
to the answer Q. The time must be one of
the formats HM, MIN, Hours from now, minutes
from now or seconds from now. HM and MIN
must not be used by a periodic request.
Output: C̲C̲
Complete
Unknown type
Wrong time format
No capability
4.2.3.1.2.2 C̲a̲n̲c̲e̲l̲ ̲T̲i̲m̲e̲o̲u̲t̲
A previously issued timeout request is cancelled. The
cancel request is sent to the CSF process synchronization
element.
The cancel request is received by the Timer Coroutine.
The appropriate TCB is identified by calling subprocess
id and event id. If not found, nothing is done. Otherwise
the TCB is removed from timer queue.
Input: Event ID
Output: Completion Code
4.2.3.1.2.3 T̲i̲m̲e̲r̲ ̲Q̲u̲e̲u̲e̲ ̲C̲o̲r̲o̲u̲t̲i̲n̲e̲ ̲F̲u̲n̲c̲t̲i̲o̲n̲s̲
The Timer Queue coroutine issues timeout requests to
the DAMOS RTC module and waits for timeout signals
from the RTC module. Timeout signals are received in
the CSF Process Synchronization Element.
When the timeout signal is received, the time is read.
Then timer queue is inspected in order to determine
if any TCB's shall be timed out.
For each TCB time out, a timeout QEL is sent to the
answer queue specified in TCB. The QMON function send
timeout is used.
Having processed all TCB's for which timeouts have
occured, the remaining ones are updated and a new timeout
period is calculated and requested from RTC module.
4.2.3.2 S̲o̲f̲t̲w̲a̲r̲e̲ ̲S̲t̲r̲u̲c̲t̲u̲r̲e̲
The structure is shown on figure 4.2.3.2-1 ref. section
4.1.2.
The TIME procedures are shared procedures executed
in user mode.
The CSF procedures are part of the monitor procedure
CSF.
The coroutines are executed in the CSF process.
4.2.3.3 D̲a̲t̲a̲ ̲F̲l̲o̲w̲ ̲a̲n̲d̲ ̲C̲o̲n̲t̲r̲o̲l̲ ̲L̲o̲g̲i̲c̲
Is shown on figure 4.2.3.3-1 for the Read, Convert
and Set Time functions and on figure 4.2.3.3-2 for
the timeout function.
FIGURE 4.2.3.2-1…01…TIMER MONITOR SOFTWARE STRUCTURE
FIGURE 4.2.3.3-1…01…READ, CONVERT AND SET TIME CONTROL FLOW
FIGURE 4.2.3.3-2…01…TIMEOUT REQUEST CONTROL FLOW
4.2.3.4 T̲i̲m̲e̲r̲ ̲M̲o̲n̲i̲t̲o̲r̲ ̲D̲a̲t̲a̲
The data structures maintained by Timer Monitor consists
of the two groups Time Formats and Timer request Data.
4.2.3.4.1 T̲i̲m̲e̲ ̲F̲o̲r̲m̲a̲t̲s̲
Time Formats are the formats Timer Monitor uses when
it in any way refers to a time value.
1) R̲T̲C̲
The 48 bit milliseconds format read by the DAMOS
Real Time Clock Module.
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
…01……01…Milliseconds
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
6 bytes integer giving milliseconds since "specified
time".
2) I̲N̲T̲M̲
A 8 byte integer string specifying year, month,
day, hour, minute, second, millisecond. Millisecond
is specified in two byte, the other each in one
byte. Year is giving the two last figures in the
year.
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
̲ ̲ ̲ ̲ ̲ ̲
Year Month Day Hour Minute Sec. Millisecond
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
̲ ̲ ̲ ̲ ̲ ̲
0-99 1-12 1-31 0-23 0-59 0-59 0-999
3) I̲N̲T̲S̲
A 6 byte integer string identical to INTM except
that millisecond is missing.
…01… ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
…01…Year Month Day Hour Minute sec.
…01… ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
…01…0-99 1-12 1-31 0-23 0-59 0-59
4) R̲Q̲T̲
A 4 byte integer copied from the 4 least significant
bytes in the RTC format.
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
…01……01…Milliseconds
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
0 - 4.10…0e…9…0f… (0 - 45 days)
5) H̲M̲
A 2 byte integer string giving hours and minutes
since midnight.
…01… ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
…01…Hour Minute
…01… ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
0-23 0-59
6) M̲I̲N̲
A 2 byte integer giving minutes since midnight.
…01… ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
…01…Minutes
…01… ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
0-1439
7) J̲U̲L̲
A 2 byte integer giving days since new year.
…01… ̲ ̲ ̲ ̲ ̲ ̲
…01… Days
…01… ̲ ̲ ̲ ̲ ̲ ̲
1-366
4.2.3.4.2 T̲i̲m̲e̲r̲ ̲R̲e̲q̲u̲e̲s̲t̲ ̲C̲o̲n̲t̲r̲o̲l̲ ̲D̲a̲t̲a̲
By maintaining and scheduling the time request Timer
Monitor uses a data structure called Timer Control
Block (TCB).
The TCB is structured as follows:
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
Pointer Integer
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
Time Integer (milliseconds)
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
Period Integer (milliseconds)
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
Event ID Specified by caller
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
Answer Q Main Q, sub Q
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
Pointer: Points to next TCB in list.
Time The time for next time out.
Period: How long time there is between the time
outs if they are periodic. A zero period
means not periodic time out.
Event ID: An information sent to user by time out.
Answer Q: A Q where the time out shall be sent to.
4.2.3.5 I̲n̲t̲e̲r̲f̲a̲c̲e̲s̲
Are shown on figure 4.2.3.5-1
Figure 4.2.3.5-1…01…Timer Monitor Interfaces
4.2.4 M̲e̲s̲s̲a̲g̲e̲ ̲M̲o̲n̲i̲t̲o̲r̲
4.2.4.1 F̲u̲n̲c̲t̲i̲o̲n̲a̲l̲ ̲S̲p̲e̲c̲i̲f̲i̲c̲a̲t̲i̲o̲n̲
4.2.4.1.1 G̲e̲n̲e̲r̲a̲l̲ ̲I̲n̲f̲o̲r̲m̲a̲t̲i̲o̲n̲
Message Monitor is the interface between application
processes and Message Management System. As such it
controls all access to and all manipulation of items
stored by Message Management System. Queue Monitor
and Message Monitor in cooporation form centralized
access control system for stored items. The mechanisms
are briefly described in the following.
a) A̲c̲c̲e̲s̲s̲ ̲C̲o̲n̲t̲r̲o̲l̲ ̲t̲o̲ ̲V̲i̲e̲w̲s̲
Control of access to views is based on the principle
that the only legal reference that an application
process can have to a view is a queue element which
the process has received from a queue, and which
references the view. In the parameter descriptions
for Message Monitor functions the term "View Reference"
always denotes a "Queue Element Reference".
Whenever a view reference occurs as input parameter
to a function, the following check is performed:
- The object type of the queue element must be
"view".
- The calling subprocess must be owner of the
queue element.
For field I/O functions three additional checks
are performed:
- The "open flag" in the queue element must be
set.
- The "allowed as reference" flag of the queue
element must be set. This flag is set by Queue
Monitor in the receive function, if the profile
of receiving subprocess is higher than or equal
to the profile of the view.
- If the operation is Write, the referencing
QEL must have write access set in View Control
Information.
b) A number of Message Monitor functions requires
special privileges for the calling process in order
to be legal. Each process has a Message Monitor
Capability Set describing the set of functions,
which the process is allowed to call.
c) S̲e̲c̲u̲r̲i̲t̲y̲ ̲P̲r̲o̲c̲e̲d̲u̲r̲e̲ ̲C̲o̲n̲t̲r̲o̲l̲
Control of security interrogation and security
warning in connection with VDU access to a stored
item is performed in the Open View function. Message
Monitor has two global parameters:
- Security Interrogation Profile
- Security Warning Profile
The Open View function compares the profile of
the referenced view with each of the above profiles.
If any of them do not contain the profile, an Open
Notification is sent to parent operating system
telling that security interrogation or security
warning or both must be performed. The flow is
shown on figure 4.2.4.3-3.
The check is only done for processes of VDU type.
d) K̲e̲r̲n̲e̲l̲ ̲S̲e̲c̲u̲r̲i̲t̲y̲ ̲P̲r̲o̲f̲i̲l̲e̲
The Kernel Security Profile of a stored item consists
of three fields (compartments):
- Security Classification ranging from 0 to 4.
- Atomal classification ranging from 0 to 1.
- Encryption designation ranging from 0 to 1.
It is used by Message Management System to control
purging of memory buffers and disk areas used for
highly classified information.
The profile is extracted from the Queue Profile
by Message Monitor in the CREATE CIF and CHANGE
PROFILE functions.
e) C̲h̲e̲c̲k̲p̲o̲i̲n̲t̲ ̲M̲e̲c̲h̲a̲n̲i̲s̲m̲
Message Monitor initiates checkpointing, either
on request from an application process or automatically
in case of dismantle. The Message Monitor part
of checkpointing consists mainly of collecting
the View Control Blocks and referencing Queue Elements
shown in section 4.2.4.4.3 and sending the collected
information to Message Management System in a SAVE
request.
A checkpoint is requested by an application process
either directly by calling the SAVE VIEW function
or indirectly by calling DISMANTLE VIEW. The latter
function will only make a checkpoint if it turns
out that the view is about to be deleted because
the last referencing queue element is dismantled.
An overview of the checkpoint mechanism can be
found in section 2.2.2.2.
The following sections describe the functions in detail.
Refer to the control flow chart on figure 4.2.4.3-1.
Figure 4.2.4.1-1a…01…Message Monitor Functions
Figure 4.2.4.1-1b…01…Message Monitor Function (cont.)
Figure 4.2.4.1-1c…01…Message Monitor Functions (cont.)
4.2.4.1.2 V̲i̲e̲w̲ ̲H̲a̲n̲d̲l̲i̲n̲g̲
4.2.4.1.2.1 C̲r̲e̲a̲t̲e̲ ̲C̲I̲F̲
Input: CIF Creation Parameter Block
Destination Queue
Output: View Reference
View Attributes
Completion Code
Waiting point in GENERATE VCB.
Waiting point before function completion.
The parameter "CIF Creation Parameter Block" has the
format of a "View Attributes Parameter Block" with
the following fields filled in by calling application:
- Qprofile
- Recovery Information
- Field Information
The output parameter "View Attributes" is the "CIF
Creation Parameter Block" where the remaining view
attributes have been filled in by Message Monitor and
MMS.
Check input parameter address. Then converts QUEUE
PROFILE to KERNEL SECURITY PROFILE and sends a CREATE
CIF request to MMS by calling GENERATE VCB with a "Predecessor
VCB Pointer" equal to NIL.
Upon return it waits for function completion.
Function completion changes VCB STATUS to ALIVE and
return the VIEW REFERENCE parameter.
4.2.4.1.2.2 C̲r̲e̲a̲t̲e̲ ̲N̲e̲w̲ ̲C̲I̲F̲ ̲V̲e̲r̲s̲i̲o̲n̲
Input: View Reference previous version
Destination Queue
Output: View Reference, new version
View Attributes, new version
Completion Code
Waiting point in GENERATE VCB.
Waiting point before function completion.
The input parameter "View Attributes Parameter Block"
is empty, and used to return View Attributes.
Checks OWNERSHIP and TYPE. Checks input parameter address
and inserts QUEUE PROFILE from previous version into
the attributes. Then sends a "CREATE NEW CIF VERSION"
request to MMS by calling GENERATE VCB with a "Predecessor
VCB Pointer" equal to NIL.
Upon return it waits for function completion.
Function completion changes VCB STATUS to ALIVE and
returns the View Reference parameter.
4.2.4.1.2.3 C̲r̲e̲a̲t̲e̲ ̲V̲i̲e̲w̲
Input: View Reference, Predecessor View
View Attributes
Destination Queue
Output: View Reference, New View
View Attributes
Completion Code
Waiting point in GENERATE VCB.
Waiting point before function completion.
The input parameter "View Attributes" is empty except
for FIELD INFORMATION, which contains a description
of the fields groups to be referenced by the new view.
The complete attributes for the new view are filled
in upon return.
Checks OWNERSHIP and TYPE. Checks input parameter address
and inserts QUEUE PROFILE from previous version into
the attributes. Then sends a CREATE VIEW request to
MMS by calling GENERATE VCB.
Upon return it waits for function completion.
Function Completion changes VCB STATUS to ALIVE and
returns the View Reference parameter.
4.2.4.1.2.4 C̲r̲e̲a̲t̲e̲ ̲F̲i̲e̲l̲d̲s̲
Input: View Reference
Field Information
Output: Completion Code
Waiting point in SEND TO MMS.
Waiting point before function completion.
The input parameter FIELD INFORMATION has the same
format as in VIEW ATTRIBUTES PARAMETER BLOCK.
Checks OWNERSHIP and TYPE.
Sends a CREATE FIELDS request to MMS.
Upon return it waits for function completion.
4.2.4.1.2.6 G̲e̲t̲ ̲V̲i̲e̲w̲ ̲A̲t̲t̲r̲i̲b̲u̲t̲e̲s̲
Input: View Reference
Output: View Attributes
Completion Code
Waiting point in SEND TO MMS.
Waiting point before function completion.
Checks OWNERSHIP and TYPE. Checks input parameter address.
Sends a GET VIEW ATTRIBUTES request to MMS.
Upon return it waits for function completion.
4.2.4.1.2.7 C̲h̲a̲n̲g̲e̲ ̲P̲r̲o̲f̲i̲l̲e̲
Input: View Reference
Queue Profile
Output: Completion Code
Waiting point in SEND TO MMS.
Waiting point before function completion.
Checks OWNERSHIP and TYPE. Checks that there is only
one view with one referencing QEL.
The KERNEL SECURITY PROFILE is derived from Queue Profile.
Then a CHANGE PROFILE request is sent to MMS.
Upon return it waits for function completion.
4.2.4.1.2.8 O̲p̲e̲n̲ ̲V̲i̲e̲w̲
Input: View Reference
Output: Completion Code
Waiting point in SEND TO PARENT.
Waiting point before function completion.
Checks QEL for:
- OWNERSHIP and TYPE
- QEL OPEN STATUS is not set.
- Profile Check Status is not set.
Then compares VIEW QUEUE PROFILE with the global variables
SECURITY INTERROGATION PROFILE and SECURITY WARNING
PROFILE. If either does not contain the profile, an
OPEN REQUEST message is sent to Parent by calling SEND
TO PARENT.
Upon return of answer from Parent, result is checked.
If ok, OPEN STATUS is set in QEL. Otherwise the result
is moved to the completion code, and function completion
is awaited.
Function completion returns the completion code.
4.2.4.1.2.9 C̲l̲o̲s̲e̲ ̲V̲i̲e̲w̲
Input: View Reference
Output: Completion code
Waiting point before function completion.
Checks QEL for:
- OWNERSHIP and TYPE
- QEL OPEN STATUS is set
Resets QEL OPEN STATUS.
Awaits function completion and returns completion code.
4.2.4.1.2.10 D̲i̲s̲m̲a̲n̲t̲l̲e̲ ̲V̲i̲e̲w̲
Input: View Reference
Output: Completion Code
Waiting point in SAVE VIEW and SEND TO MMS.
Waiting point before function completion.
Checks QEL for OWNERSHIP and TYPE. Then removes the
QEL from VCB by calling EXCLUDE QEL. If QEL COUNT becomes
zero the action depends upon the VCB RL field:
- If RL 1, the view has not been checkpointed, and
is thus removed by sending a Remove View Command
to MMS and calling EXCLUDE VCB.
- IF RL = 1, the view has been checkpointed, and
is thus removed by calling SAVE VIEW with recovery
level = RL and dismantle flag set true.
