top - download
⟦93e5046da⟧ Wang Wps File
Length: 24032 (0x5de0)
Types: Wang Wps File
Notes: CPS/SDS/002
Names: »1056A «
Derivation
└─⟦5a07e954e⟧ Bits:30006038 8" Wang WCS floppy, CR 0062A
└─ ⟦this⟧ »1056A «
WangText
&…09…&…0e…&
&…07…%…0b…%…0c…%…0d…%…0e…%…0f…%
%…86…1
…02…
…02…
…02…
…02…CPS/SDS/002
…02…OKH/810801…02……02…
CAMPS
SYSTEM
FUNCTIONS
…02……02…CAMPS
4.2.1.1.1 S̲u̲b̲p̲r̲o̲c̲e̲s̲s̲ ̲M̲a̲n̲a̲g̲e̲m̲e̲n̲t̲
A subprocess is an entity within a process to which
separate functional capabilities and access rights
shall be assigned. The most typical example is a VDU
subprocess. A VDU Process manages and communicates
with a number of VDUs. Each VDU is then assigned a
subprocess within the process, and this subprocess
is the carrier of the access rights assigned to that
VDU.
The rights and capabilities of a subprocess are described
in the associated subprocess record, shown on figure
4.2.1.4.1.
FUNCTIONAL CAPABILITIES are a function mask with a
bit for each privileged CSF function.
Subprocesses within CAMPS are identified by a unique
SUBPROCESS ID, which is a BYTE.
For each process there is a variable CURRENT SUBPROCESS
holding the subprocess id of the subprocess in control
at the moment. The value is maintained by the function
Change Subprocess Id.
For processes structured into coroutines, each coroutine
belongs to one subprocess. The coroutine monitor will
then maintain the current subprocess id.
4.2.1.1.1.1 G̲e̲t̲ ̲S̲u̲b̲p̲r̲o̲c̲e̲s̲s̲
Output: Subprocess Record Pointer
Internal CSF function returning a pointer to the subprocess
record of current subprocess within the process.
4.2.1.1.1.2 C̲h̲a̲n̲g̲e̲ ̲S̲u̲b̲p̲r̲o̲c̲e̲s̲s̲ ̲I̲d̲
Input:…02…New Subprocess Id
Output:…02…Completion Code.
Checks that the specified subprocess belongs to calling
process. Then changes the value of current subprocess
in the process.
4.2.1.1.1.3 C̲h̲a̲n̲g̲e̲ ̲S̲u̲b̲p̲r̲o̲c̲e̲s̲s̲ ̲A̲t̲t̲r̲i̲b̲u̲t̲e̲s̲
Input: Subprocess Id
New Attributes
Output: Completion Code.
Privileged function used to change the fields FUNCTIONAL
CAPABILITIES through QUEUE ELEMENT CLAIM of the subprocess
record. The QUEUE MONITOR CAPABILITY ARRAY is updated
by the QMON function Set Capabilities.
Checks that calling process has the right to call this
function. Then inserts the new attributes into the
subprocess record.
4.2.1.1.1.4 C̲h̲e̲c̲k̲ ̲P̲a̲g̲e̲ ̲A̲c̲c̲e̲s̲s̲ ̲R̲i̲g̲h̲t̲s̲
Input: Buffer Address
Buffer Length
Required Access
Output: Physical Address
Completion Code
Internal function checking if pages corresponding to
specified buffer are mapped in by the process with
required access rights, e.g. read or write access.
4.2.1.1.2 B̲u̲f̲f̲e̲r̲ ̲a̲n̲d̲ ̲C̲o̲n̲t̲r̲o̲l̲ ̲B̲l̲o̲c̲k̲ ̲P̲o̲o̲l̲ ̲M̲a̲n̲a̲g̲e̲m̲e̲n̲t̲
Shared buffers are used by application processes to
communicate data which are not stored on disk. Examples
are log records and reports.
Shared buffers are held in buffer pools. The buffers
in a pool are of equal size.
Shared buffers are kept in protected data area and
can only be referenced via queue elements.
Control Blocks used by other CSF subpackages are kept
in similar pools. They are allocated and released by
calling a common function.
4.2.1.1.2.1 R̲e̲s̲e̲r̲v̲e̲ ̲B̲u̲f̲f̲e̲r̲
Input: Buffer Size
Destination Queue
Output: Buffer Reference (Queue Element)
Completion Code
Reserves a buffer of specified size. If there are no
free buffers, this will be signalled in Completion
Code.
4.2.1.1.2.2 D̲i̲s̲m̲a̲n̲t̲l̲e̲ ̲B̲u̲f̲f̲e̲r̲
Input: Buffer Reference
Output: Completion Code
Releases a buffer from the calling subprocess. If it
is the last QEL referencing the buffer, it is returned
to its pool.
4.2.1.1.2.3 W̲r̲i̲t̲e̲ ̲B̲u̲f̲f̲e̲r̲
Input: Buffer Reference
Buffer Offset
Record Length
Record Address (Even Byte address)
Output: No. of bytes written
Completion Code.
A record of "Record Length" bytes starting at "Record
Address" is written into the referenced buffer, starting
at "Buffer Offset".
The QEL used as reference must be owned by calling
subprocess. If the record length is too large, a smaller
number of bytes may be moved.
4.2.1.1.2.4 R̲e̲a̲d̲ ̲B̲u̲f̲f̲e̲r̲
Input: Buffer Reference
Buffer Offset
Record Length
Record Address
Output: No. of bytes read
Completion Code
A record of "Record Length" bytes starting at "Buffer
Offset" is read into the memory area starting at "Record
Address". The QEL used as reference must be owned by
calling subprocess.
If buffer is shorter than specified, a smaller number
of bytes may be read.
4.2.1.1.2.5 A̲l̲l̲o̲c̲a̲t̲e̲ ̲C̲o̲n̲t̲r̲o̲l̲ ̲B̲l̲o̲c̲k̲
Input: Pool Pointer
Output: Control Block Pointer.
Internal function allocating a free control block.
If pool is empty, the returned pointer is NIL.
4.2.1.1.2.4 R̲e̲l̲e̲a̲s̲e̲ ̲C̲o̲n̲t̲r̲o̲l̲ ̲B̲l̲o̲c̲k̲
Input: Pool Pointer
Control Block Pointer
Internal Function.
Returns a Control Block to its pool.
4.2.1.1.3 L̲i̲s̲t̲ ̲a̲n̲d̲ ̲C̲h̲a̲i̲n̲ ̲M̲a̲n̲i̲p̲u̲l̲a̲t̲i̲o̲n̲
Contains internal functions for inserting and removing
elements from single and double chained lists.
4.2.1.1.4 L̲o̲g̲ ̲a̲n̲d̲ ̲R̲e̲p̲o̲r̲t̲ ̲G̲e̲n̲e̲r̲a̲t̲i̲o̲n̲
Contains internal functions for generating error or
warning reports and log records.
4.2.1.2 S̲o̲f̲t̲w̲a̲r̲e̲ ̲S̲t̲r̲u̲c̲t̲u̲r̲e̲
The external functions are CSF procedures as described
in section 4.1.2.
The internal functions are internal procedures and
a coroutine in CSF process as described in 4.1.2.
4.2.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̲
See Figures 4.1.3-1 and 4.1-3-3.
4.2.1.4 S̲u̲b̲p̲a̲c̲k̲a̲g̲e̲ ̲D̲a̲t̲a̲
Consists of the following 3 data types:
a) Subprocess Record, shown in 4.2.1.4.1.
There is one for each subprocess containing the
access control information for the subprocess.
b) Buffer Pool, shown in 4.2.1.4.2.
A buffer pool is an array of equal sized buffer
elements and a pool descriptor describing the state
of the pool.
c) Control Block Pool Descriptor, shown in 4.2.1.4.2.
A pool descriptor for each type of control block
used by other subpackages.
Figure 4.2.1.4.1-1
Figure 4.2.1.4.2-1
Figure4.2.1.5-1
4.2.2 Q̲u̲e̲u̲e̲ ̲M̲o̲n̲i̲t̲o̲r̲
The Queue Monitor (QMON) manipulates QELs. The QELs
are a record type which normally is held in a double
linked list, a Queue (Q). The main purpose of the QELs
is that they are used as reference to objects which
are sent from one application module to another.
4.2.2.1 F̲u̲n̲c̲t̲i̲o̲n̲a̲l̲ ̲S̲p̲e̲c̲i̲f̲i̲c̲a̲t̲i̲o̲n̲
This functional breakdown shows which functions QMON
must contain to fulfil its functional requirement.
QMON will be implemented as 7 modules. The first 6
modules (4.2.2.1.1-6) contain the functions called
by other subpackage while the last module 4.2.2.1.7
contains simple functions called by more than one of
the main functions in the other 6 modules or by other
CSF subpackage.
In the following each module will be broken down so
each main function and the common functions used by
it can be identified.
Figure
Figure 4.2.2.1-1
4.2.2.1.1 R̲e̲c̲e̲i̲v̲e̲
Receive identifies and reserves a QEL and delivers
it to caller. The QEL is selected according to criteria
specified by caller.
All QELs may be received if caller has capability to
the queue where they reside, but if the QEL profile
exceeds the calling subprocess profile, the QEL will
be marked by setting Profile Check Status and can thus
not be used as a view reference.
Every time a QEL is received by a subprocess the number
of remaining QELs in the capability array of the subprocess
is decreased by one.
Receive module is broken down as shown in figure 4.2.2.1.1.
The Receive functions are called via System Call Monitor,
cf 4.2.6.
4.2.2.1.1.1 R̲e̲c̲e̲i̲v̲e̲ ̲F̲i̲r̲s̲t̲ ̲Q̲E̲L̲
If caller has capability to the queue it is inspected.
If queue is empty and wait is false, a nil QEL reference
is put into SOCB and SOCB Call Status is set to "done".
If queue is empty and wait is true, the absolute queue
reference and owner reference are put into SOCB.
If queue is not empty, the first QEL is marked as owned
by calling subprocess and queue length is decreased
by one. The QEL is put into SOCB and SOCB Call status
is set to "done".
The queue may be a main queue or a subqueue.
Input QID
- Queue reference
Wait
- Boolean…86…1 …02… …02… …02… …02…
…02…
Output in SOCB
QEL
- QEL reference may be nil
Subqueue Index
CC
- Complete
- QEL has higher prof.
- No capability
- Q is empty
- QEL claim exceeded
- Cancelled
4.2.2.1.1.2 I̲n̲s̲p̲e̲c̲t̲ ̲R̲e̲c̲e̲i̲v̲e̲
This is the "answer received" entry point from System
Call Monitor.
The list of pending SOCBs is scanned. For each SOCB,
an inspection is made as to whether a QEL has been
sent to the referenced queue.
If the queue is still empty nothing is done. If the
queue is not empty, the first QEL is reserved and its
reference is put into the SOCB which is then marked
as "done".
When all SOCBs have been inspected, QMON returns to
System Call Monitor with parameters telling how many
SOCBs have been marked as "done" indicating the first
in the list.
The queue referred to in the SOCB may be a main queue
or a sub queue.
Input: SOCB list
Output: n
- Number of affected SOCBs
SOCB ref
- Pointer to first affected SOCB
CC
- Complete
- Fail
4.2.2.1.1.3 C̲a̲n̲c̲e̲l̲ ̲R̲e̲c̲e̲i̲v̲e̲
Cancel terminates the waiting on an empty queue. The
SOCB status is set to done, QEL reference to nil and
completion code to cancelled.
Input: SOCB
- References to a SOCB
Output: CC
- Cancel complete
- Fail
4.2.2.1.1.4 R̲e̲c̲e̲i̲v̲e̲ ̲N̲e̲x̲t̲ ̲Q̲E̲L̲
If caller owns the referred QEL, the next QEL in same
queue is reserved for caller and QEL reference is returned.
If there are no more QELs in the same queue, only completion
code is returned.
Input: QEL
- Reference to an owned QEL
Output: QEL
- QEL ref may be nil
CC
Figure 4.2.2.1-2
4.2.2.1.2 C̲l̲e̲a̲r̲i̲n̲g̲
The clearing functions are used when the owner of a
QEL no longer wants to use it. The clearing module
has been broken down under figure 4.2.2.1.2.
4.2.2.1.2.1 R̲e̲t̲u̲r̲n̲
If caller owns the QEL, the owner reference in the
QEL is cleared and queue length is increased by one.
If the queue was empty before return, the Sync. Element
associated with the queue is signalled if Sync. Element
ref. is not nil.
The QEL claim of calling suprocess is incremented.
Input: QEL
- Reference to a QEL owned by caller
Output: CC
- Complete
- QEL not owned
4.2.2.1.2.2 D̲i̲s̲m̲a̲n̲t̲l̲e̲
The QEL is removed from the list where it resides and
returned to CSF shared data functions if the following
conditions are fulfilled:
- The caller is owner of the QEL.
- The QEL does not refer to a view.
A view must be dismantled by the MMON Dismantle
View
- The QEL does not refer to a buffer.
A buffer must be dismantled by the Shared Buffer
Management Function Release Buffer.
The QEL claim of calling subprocess is incremented.
Input: QEL
- Reference to a QEL owned by caller.
Output: CC
- Complete
- QEL not owned
- QEL refers to an object
Figure 4.2.2.1-3
4.2.2.1.3 S̲e̲n̲d̲
Send sends a QEL to specified sub queue.
The QEL may be a copy of a QEL owned by caller or a
new QEL generated by QMON.
QMON generates a new QEL if caller specifies a nil
reference instead of a reference by input parameters
for send.
Caller may specify View Control Information and 3 word
information as input parameters by send.
Caller may only send to the queues to which he has
send capability.
A QEL can not be sent to a queue with lower profile
than the QEL. If this check is not passed, a profile
mask is returned to caller, specifying the profile
fields which are too high.
If a QEL is sent to an empty queue, the Sync. Elements
associated with the queue is signalled if this is not
nil.
If a QEL referring to an object, e.g. a view or a shared
buffer, is copied, the object server is activated.
Send is broken down in fig. 4.2.2.1.3.
A QEL may not be sent to a blocked queue.
If the threshold of destination queue is exceeded,
a warning report is sent to supervisor.
4.2.2.1.3.1 S̲e̲n̲d̲ ̲Q̲E̲L̲
A QEL is sent to destination queue if the following
conditions are fulfilled:
- QEL is a nil reference or owned by caller.
- Destination queue has a higher profile than QEL.
- Caller has capability to destination queue.
Input: QEL
- Reference to an owned QEL or nil reference
Dest QID
- Sub queue reference
View Control Information
Info.
- Three word information specified by caller.
Output: CC
- Complete
- QEL has higher prof. than dest. queue
- No capability
- QEL not owned by caller
- Function not allowed
- Queue blocked
Profile Mask.
4.2.2.1.3.2 S̲e̲n̲d̲ ̲R̲e̲q̲u̲e̲s̲t̲
This function is special in so far as an answer queue
must be specified by input parameter. The answer queue
specifies which queue the receiving module shall send
to, after the requested function has been performed.
A QEL is sent to destination queue if the following
conditions are fulfilled.
- QEL is a nil ref or owned by caller.
- Destination queue has higher profile than QEL.
- Caller has capability to send to destination queue.
- Caller has capability to use answer queue as such.
- Before send, function request flag is set.
Input: QEL
- Reference to a QEL owned by caller or a
nil reference.
Dest QID
- Destination QID of the type sub queue ref.
View Control Information
Info
- Three word information specified by caller.
Answ QID
- The Q where first answer to the request
is to be sent to. QID of the type sub queue
ref.
Output: CC
- Function complete
- QEL has higher prof. than destination queue
- QEL not owned by caller
- No capability
- Function not allowed
- Queue blocked
Profile Mask
4.2.2.1.3.3 S̲e̲n̲d̲ ̲R̲e̲p̲l̲y̲
This function is special in so far as destination queue
is specified by means of a QEL which has been sent
as a function request.
A QEL is sent to destination queue if the following
conditions are fulfilled:
- QEL is a nil reference or owned by caller
- Answer queue has a higher profile than QEL
- Destination QEL contains an answer QID
Input: QEL
- Reference to QEL owned or nil. An owned
QEL may be the same as Dest QEL
Dest QEL
- The QEL by which the request was received.
The Dest QEL must be owned by caller.
View Control Information
Info
- Three word information specified by caller
Output: CC
- Function complete
- QEL has higher prof that destination queue
- QEL not owned by caller
- No answer Q in QEL
- Function not allowed
- Queue blocked
Profile Mask
Figure 4.2.2.1.4
4.2.2.1.4 P̲r̲o̲f̲i̲l̲e̲s̲ ̲a̲n̲d̲ ̲B̲l̲o̲c̲k̲i̲n̲g̲
The profile module manipulates data related to profiles.
The only output from these functions is the completion
code.
The profile module is broken down in figure 4.2.2.1.4.
4.2.2.1.4.2 S̲e̲t̲ ̲P̲r̲o̲f̲i̲l̲e̲
The profile of a main queue is set
If the new profile is higher than the old profile,
the profiles of all QELs in the Q are compared with
the new value and the QELs with too high a profile
are moved to an alternative queue specified by caller.
Only SSC is allowed to use this function
Input: QID
- Main queue reference
Alt QID
- Sub queue reference to the alternative
queue where QELs with too high a profile
are moved
Output: CC
- Function complete
- Alternative queue has too low a profile
- Function not allowed
4.2.2.1.4.3 B̲l̲o̲c̲k̲ ̲Q̲u̲e̲u̲e̲
The specified queue is blocked by setting the blocked
flag to true. If a main queue is referenced, all its
sub queues are blocked.
Input: Queue ID
Output: Completion code
4.2.2.1.4.4 U̲n̲b̲l̲o̲c̲k̲ ̲Q̲u̲e̲u̲e̲
The specified queue is unblocked by setting the blocked
flag to false. If a main queue is referenced, all its
sub queues are unblocked.
Input: Queue ID
Output: Completion code
Figure 4.2.2.1.5
4.2.2.1.5 G̲e̲t̲ ̲A̲t̲t̲r̲i̲b̲u̲t̲e̲s̲
This function reads or determines the wanted attributes
and delivers them to caller by writing the attributes
at a location specified by caller.
Get attributes are broken down in fig. 4.2.2.1.5-1.
4.2.2.1.5.1 G̲e̲t̲ ̲Q̲u̲e̲u̲e̲ ̲A̲t̲t̲r̲i̲b̲u̲t̲e̲s̲
The attributes of a queue are read from queue description
and delivered to caller.
Input: QID
- Queue reference
Output address
- Pointer to output buffer
Output: Queue Attributes
- Profile
- Length
- Threshold
Output: CC
- Function complete
- No capability
- Output buffer unavailable
4.2.2.1.5.2 G̲e̲t̲ ̲Q̲u̲e̲u̲e̲ ̲L̲e̲n̲g̲t̲h̲
The length of a sub queue or a main queue is determined.
The profile of each unreserved QEL in queue is compared
with a Profile Mask specified by caller.
Only QELs, the qprofile of which contains at least
one bit from Profile Mask are counted in the queue
length.
Input: Queue reference
Profile Mask
Output: Queue length
- Integer
CC
- Function complete
- No capability
- Output buffer unavailable
4.2.2.1.5.3 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
Output address
- Pointer to output buffer
Output: QEL Attributes
- Time Stamp
- View Control Information
- Profile Check Status
- Object type
- Owner
- Information field
CC
- Complete
- Output buffer unavailable
FIGURE 4.2.2.1-6
4.2.2.1.6 I̲n̲i̲t̲i̲a̲l̲i̲z̲e̲
Initialize module consists of functions to initialize
and maintain data structures.
The only output from this function is completion code.
Initialize is broken down in figure 4.2.2.1-6.
4.2.2.1.6.1 I̲n̲i̲t̲i̲t̲i̲a̲l̲i̲z̲e̲ ̲Q̲u̲e̲u̲e̲
The queue descriptions are initiated. Only SSC is allowed
to use this function.
Input: Initialize data
Output: CC
- Function Complete
4.2.2.1.6.2 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: Subprocess ID
- The identification of the Subprocess using
actual capability array.
- Queue Capability
- Capability index
Main queue
New Main Queue reference
Functions
- New functions the subprocess is allowed
to perform on this queue.
Output: CC
- Function complete
- Unknown capability
4.2.2.1.6.3 S̲e̲t̲ ̲Q̲u̲e̲u̲e̲ ̲T̲h̲r̲e̲s̲h̲o̲l̲d̲
The threshold values of a main queue are changed as
specified.
Input: Main Queue Reference
Threshold Values
Output: CC
Figure 4.2.2.1-7
4.2.2.1.7 I̲n̲t̲e̲r̲n̲a̲l̲ ̲Q̲M̲O̲N̲ ̲F̲u̲n̲c̲t̲i̲o̲n̲s̲
The internal functions are only called by QMON or other
CSF functions. They are not called directly from the
applications.
4.2.2.1.7.1 C̲h̲e̲c̲k̲ ̲C̲a̲p̲a̲b̲i̲l̲i̲t̲y̲
A callers capability is checked. If capability is accepted
capability index is converted to main queue index.
From the capability array the functions are read, which
the caller may use at this queue.
Input: Cap ind, Sub queue ind
Output: Main queue, Sub queue
Functions
- The functions which the caller is allowed
to use on this queue.
4.2.2.1.7.2 I̲n̲s̲p̲e̲c̲t̲ ̲Q̲u̲e̲u̲e̲
If inspected queue is empty nothing is done.
If the queue is not empty the first QEL in it is marked
as owned by caller and the QEL reference is put into
a SOCB.
The queue length is decreased by one and SOCB is set
to "done".
Input: Main queue, Subqueue
- Queue reference
Output in SOCB:
QEL
4.2.2.1.7.3 R̲e̲m̲o̲v̲e̲ ̲Q̲E̲L̲
The QEL is chained out of the queue where it resides
and QID is cleared.
4.2.2.1.7.4 P̲u̲t̲ ̲Q̲E̲L̲
The QEL is chained in the tail of specified queue and
queue length is increased by one.
QID in QEL is updated and time stamp is set to current
time.
4.2.2.1.7.5 S̲i̲g̲n̲a̲l̲ ̲S̲y̲n̲c̲h̲ ̲E̲l̲e̲m̲e̲n̲t̲
This function is used to signal synchronization element
associated with queues. Cf. section 4.1.1.2.6.
When the Send and Return functions discover that the
destination queue is empty, they send an info element
to the CSF Process QMON Synchronization Element. The
info block identifies a main queue.
The QMON coroutine receives the info. It uses an internal
table to identify one or more synchronization elements
associated with the main queue. These synchronization
elements are signalled.
4.2.2.1.7.6 C̲o̲m̲p̲a̲r̲e̲ ̲P̲r̲o̲f̲i̲l̲e̲
Two profiles are compared and the result tells whether
the first profile is higher than the second or not:
Input: First Profile
Second Profile
Output: Boolean
4.2.2.1.7.7 C̲o̲p̲y̲ ̲Q̲E̲L̲
A free buffer of the type used as QEL is allocated
and the relevant attributes are copied into it from
another QEL.
The other QEL may be an existing QEL or a record of
the same structure as a QEL.
If the object referred by an existing QEL was a CIF
or a buffer object server is activated.
Input: QEL
reference to QEL or a record of QEL structure
Output: QEL
reference to the new QEL.
4.2.2.1.7.8 C̲r̲e̲a̲t̲e̲ ̲Q̲E̲L̲
All input parameters are read from a record of the
same type as a QEL Owners Capability to the destination
queue read from QID field is checked. QID field is
updated with converted QID.
If the QEL profile allows the QEL to be sent to destination
queue a QEL is allocated and the QEL record is copied
into it.
It is checked whether owner has a profile which allows
him to use the QEL as a reference to an object and
function field is updated. The QEL is put into the
destination without queue length being changed. The
QEL is time stamped and delivered to caller.
Input: QEL
Reference to a record of QEL type
Output: QEL
Reference to a QEL
CC
- Complete
- No capability
- QEL must not be sent to queue
- QEL has higher priority than caller
4.2.2.1.7.9 R̲e̲-̲I̲n̲s̲e̲r̲t̲ ̲I̲n̲ ̲Q̲u̲e̲u̲e̲
A QEL is generated and inserted in the queue specified
in input data. The input is a complete copy of the
data contained in a QEL when it resides in a queue.
The QEL is put back in the queue in the position according
to its time stamp. The function is called by Message
Monitor during recovery.
Input: QEL
A copy of the data in a QEL
Output: CC
- Function Complete
