top - download
⟦07b69a23f⟧ Wang Wps File
Length: 18838 (0x4996)
Types: Wang Wps File
Notes: FIX/1000/PSP/0038
Names: »5295A «
Derivation
└─⟦c5670ecfe⟧ Bits:30006140 8" Wang WCS floppy, CR 0516A
└─ ⟦this⟧ »5295A «
WangText
…0e……0e… 5295A/aml…02…FIX/1000/PSP/0038
…02…OK/850529…0f……02……02…
FIKS SYSTEM SPECIFICATION
…02……02…FK 7809…0f…
4.3 E̲X̲E̲C̲U̲T̲I̲V̲E̲ ̲S̲O̲F̲T̲W̲A̲R̲E̲
The standard CR80 Kernel executive has been extended
by designing monitor and processes. Monitors execute
on behalf of application processes that call them;
a monitor assumes the identify of the calling process
that is under Kernel Control.
This section summarizes the design of those extensions
that were listed in figure 3.4.1-1, but not referenced
in the bibliography of section 2. Excluded also are
device drivers that interface to the Input Output System
(monitor). They essentially make each device look like
one or more logical volumes and files.
The queue management monitor, QACCESS, is described
in this section. Processes that request access to their
input queues, or that make entries in other process's
queues, execute this monitor.
The MTCB Monitor is described also here. It is executed
by processes that affect the status and storage of
a message as it flows through system interfaces. The
MTCB Monitor also is designed to provide temporary
memory buffers for interprocess messages.
The QACCESS and MTCB monitors are designed to interact
on behalf of an application process. A message's MTCB
index can be retrieved from a queue and its transition
status (MTCB use count) updated in response to one
monitor call. For this reason, the QACCESS and MTCB
monitors may be combined into a single monitor, when
their designs are implemented.
The design of the Watchdog subsystem (WDS) is summarized
here. It interfaces in the Node/MEDE system to the
Error Switchover Process (ESP). The ESP sends periodically
status data to the Watchdog to ensure its awareness
of the operational state of each half of the redundant
Node/MEDE system. It also receive checkpoints records
standby system only of selected segment of the active
system's memory. These data can be used subsequently
to recover from malfunction of the active system and
resume operation, using the standby as the replacement.
The startup/restart process also is described. It initializes
tables and parameters that describe to the application
software, the hardware configuration and performance
value to be ued at a specific Nopde/MEDE or SSC site.
4.3.1 Q̲A̲C̲C̲E̲S̲S̲ ̲M̲o̲n̲i̲t̲o̲r̲
The monitor provides a common access method for processes
which interface to one of three types of queues:
o Subsystem queues
o terminal display queues
o terminal print queues
4.3.1.1 F̲u̲n̲c̲t̲i̲o̲n̲a̲l̲ ̲C̲a̲p̲a̲b̲i̲l̲i̲t̲i̲e̲s̲
Entries in queues are index numbers to a MTCB pool.
The queue elements are timetagged at queue insertion.
Threshold values are specified for each queue. An
option in each request is to specify wait for a free
element (wait access to a queue).
Precedence queues are grouped and in some cases logically
handled as one queue. The dequeueing of the first
element in the queue of highest priority is considered
to be "First in queue" outqueueing.
For each defined queue or group, a "receiver process"
is defined. It is for some processes invoked when
the first element is inserted into a previously enpty
queue, or group of queues.
The queue elements are taken from a common pool of
a fixed size.
4.3.1.1.1 Q̲u̲e̲u̲e̲ ̲P̲r̲o̲c̲e̲d̲u̲r̲e̲s̲
o R̲e̲t̲u̲r̲n̲ ̲l̲e̲n̲g̲t̲h̲ of queue.
The function returns the actual length of a specified
queue.
o R̲e̲t̲u̲r̲n̲ ̲l̲e̲n̲g̲t̲h̲ of terminal queues.
The function returns the actual length of all the
terminal queues (display and print). The length
is given for each queue individually. A bit map
indicates, for each queue, if a change has occured
since the last call to the monitor.
o R̲e̲a̲d̲ ̲e̲l̲e̲m̲e̲n̲t̲, non destructive.
The function will read a specified element from
a specified queue, without removing the element
from the queue. In addition the actual length
is returned.
If first element is specified, then as an option,
the queue entry is marked as active.
This implies that the active element cannot be
deleted or removed.
o R̲e̲l̲e̲a̲s̲e̲ ̲a̲c̲t̲i̲v̲e̲ flag.
This procedure removes the active flag from an
element which is marked as active.
o R̲e̲a̲d̲ ̲e̲l̲e̲m̲e̲n̲t̲, destructive.
The function will read a specified element from
a specified queue, and remove the element from
that queue. In addition the actual queue length
is returned after removal. The MTCB-USE-COUNT
in the MTCB is not updated.
o D̲e̲l̲e̲t̲e̲ ̲e̲l̲e̲m̲e̲n̲t̲
The function is used to delete the first element
from a specified queue. The function shall be
executed after a "non destructive read". For synchronization
with the MTCB monitor the "MTCB-USE-COUNT" in the
MTCB is decremented (-1). The length after delete
is returned.
o R̲e̲a̲d̲ ̲g̲r̲o̲u̲p̲ ̲e̲l̲e̲m̲e̲n̲t̲, non destructive.
The function is to read the active queue element
with the highest priority in the specified group
of queues, i.e. the first element in the queue
with highest precedence. The element is not removed
from the queue.
In addition the identification of the queue from
where the element has been read and the total length
of the "group queue" is returned.
The entry element is released by performing a "delete
element" to the queue referenced via the id received
as above.
o W̲r̲i̲t̲e̲ ̲e̲l̲e̲m̲e̲n̲t̲
The function will insert a queue element into a
specified queue. The function supports insertion
of an entry into first or last position of the
queue.
In case: "Write to first entry in queue" is ordered,
it is checked if the entry is already active (non
destructive read performed). If this is the case,
the entry is inserted as second element. Before
writing to the queue the queue element is time
tagged.
For synchronization with MTCB monitor the "MTCB-USE-COUNT"
in the MTCB is incremented (+1). If the queue
element is written into an empty queue or empty
group, the process which has this queue/group of
queues as input will be awoked via a "SIGNAL".
The queue length is returned.
o A̲p̲p̲e̲n̲d̲ ̲q̲u̲e̲u̲e̲
The function supports the move of a specified queue
(subject) to another specified queue (object).
The number of elements to be moved from the subject
queus is from a given entry number and to the last
element.
The moved entries are appended to the object queue.
In case the ordered move implies an entry marked
active (non destructive read pending on First element)
this element is left back in the queue.
The length of the object queue after operation
is returned.
A notification is given in case the threshold is
exceeded; remaining elements are left in the subject
queue, in this case.
o R̲e̲o̲r̲g̲a̲n̲i̲z̲e̲ ̲q̲u̲e̲u̲e̲
The function supports reorganization of elements
inside one specified queue.
A specified entry is moved to the first or last
position in queue according to the request. In
case the first element is involved, and marked
as active (i.e. non destructive read pending) the
following takes place:
- move first element to last position:
no action except a notification to caller.
- move specified element to first position:
element moved to second entry in the queue.
o I̲n̲t̲e̲r̲f̲a̲c̲e̲ ̲d̲e̲s̲c̲r̲i̲p̲t̲i̲o̲n̲
QACCESS is invoked by a monitor call. A completion
code is returned to the calling application giving
the result of the action.
A working area is used for transfer of input and
output parameters.
A parameter transfer block is used in functions
"length of group queues".
4.3.1.1.2 Q̲U̲E̲U̲E̲ ̲S̲t̲r̲u̲c̲t̲u̲r̲e̲
A common pool of queue elements is used to support
the interfacing between the defined subsystems. Inside
the queue pool a logical partition is made to support
the different queue types:
o terminal print queues
o terminal display queues
o subsystem I/F queues
The different queues are handled identical as terminal
queues, i.e. each queue is referenced via a terminal
number and a serial queue number inside the terminal.
This concept implies that the subsystems are considered
to be pseudo terminals with a dedicated number for
queue identification.
Precedence queues which are logically related to each
other are defined to constitute a "group" to be processed
according to the defined functions. The group queues
are referenced by giving the "terminal no" for the
group. Access to a specific queue inside a group can
be performed by giving both the terminal number and
the defined queue serial number.
The different queues are linked elements from entries
in the common pool of queue entries and contains references
to the MTCB's for the related messages/remarks queued
up to the subsystem or terminal, see illustration on
the next page:
Figure 4.3.1.1.2-1…01…Queue Status
4.3.1.2 Q̲A̲C̲C̲E̲S̲S̲ ̲E̲n̲v̲i̲r̲o̲n̲m̲e̲n̲t̲ ̲(̲B̲l̲o̲c̲k̲ ̲D̲i̲a̲g̲r̲a̲m̲)̲
C̲o̲m̲m̲e̲n̲t̲ ̲t̲o̲ ̲b̲l̲o̲c̲k̲ ̲d̲i̲a̲g̲r̲a̲m̲ ̲4̲.̲3̲.̲1̲.̲2̲
1. The queue procedures are called by application
programs concurrently.
2. The QACCESS decodes the given input and branches
to the requested queue access procedure.
3. The queue entry to access is calculated from the
terminal number and relative queue number given,
and the description given in the Q ̲header. The
entry is accessed for the requested function.
4. In case an entry is made in a previous empty queue
the defined process related to that queue, if any,
is activated.
5. In case the performed function requires synchronization
with the MTCB monitor,
the MTCB ̲USE ̲COUNT is updated.
6. Changes in the terminal queues imply an update
at the terminal queue status line, this is supported
by the ITM every 60 seconds.
Figure 4.3.1.2…01…QACCESS Block Diagram
4.3.1.3 D̲e̲s̲i̲g̲n̲ ̲O̲v̲e̲r̲v̲i̲e̲w̲
The functions necessary to support the queue access
operations are implemented inside a common monitor
procedure, QACCESS.
There is one code block for each of the defined functions
described previously (in 4.3.1.1.1). The application
program calls the QACCESS procedure with an operation
code, and other I/F parameters appropriate for the
function to be performed.
The QACCESS branches to the requested function and
access the queue area accordingly.
The queue pools are located in a reserved memory area.
This area is layed out by an initialization program.
An option in the I/F to QACCESS is to specify wait/no
wait for entering the region, this means that the application
caller can request to be suspended with a wait for
access to the queue area in case that another process
currently is working on a queue element, or to get
control back immediately.
The QACCESS processing is synchronized with the MTCB
monitor in the way that the MTCB's inqueued are released
when the "last user" outqueues the corresponding indexes.
The MTCB ̲USE ̲COUNT indicates (=0) when the MTCB shall
be released and is incremented when a queue entry is
made, and decremented when a queue element is released.
N̲O̲D̲E̲/̲M̲E̲D̲E̲ ̲i̲m̲p̲l̲e̲m̲e̲n̲t̲a̲t̲i̲o̲n̲ ̲(̲N̲/̲M̲)̲
The functions described above are implemented. The
queues defined as dedicated SCC queues are excluded.
S̲C̲C̲ ̲I̲m̲p̲l̲e̲m̲e̲n̲t̲a̲t̲i̲o̲n̲
The SCC queue support is different from the N/M in
the following areas:
- Only the queues defined as dedicated SCC queues
are supported.
The identified differences between the NODE/MEDE and
the SCC version of QACCESS are items used at compilation
time to generate the appropriate version.
4.3.1.3.1 Q̲u̲e̲u̲e̲ ̲D̲a̲t̲a̲ ̲A̲r̲e̲a̲
The queue data area is a set of tables required to
support the processing.
Q̲u̲e̲u̲e̲ ̲t̲a̲b̲l̲e̲s̲ ̲d̲e̲f̲i̲n̲e̲d̲:
Q̲u̲e̲u̲e̲ ̲P̲o̲o̲l̲ (Q ̲POOL)
The pool is a common data area containing the queue
elements linked together according to the current access
requests.
The free queue elements are linked togehter to constitute
the empty queue.
Q̲u̲e̲u̲e̲ ̲H̲e̲a̲d̲e̲r̲ (Q ̲HEAD)
The table contains for each defined queue the references
to the elements in the queue pool, for describing the
actual queue. In addition it contains queue characteristica
and reference to a process identified giving the "queue
receiver".
G̲r̲o̲u̲p̲ ̲H̲e̲a̲d̲e̲r̲ (GR ̲HEAD)
The table contains for each defined group of queues,
a reference to the queue (via Q ̲HEAD) with the highest
precedence inside the group; in addition it contains
reference to a process identifier giving the "queue
receiver".
Q̲u̲e̲u̲e̲ ̲R̲e̲c̲e̲i̲v̲e̲r̲ ̲P̲r̲o̲c̲e̲s̲s̲ (Q ̲PROC)
The table contains for each defined queue/group a process
identification of the queue receiver process which
shall be activated when an element is entered into
a previously empty queue.
Q̲u̲e̲u̲e̲ ̲S̲t̲a̲t̲u̲s̲ ̲C̲h̲a̲n̲g̲e̲ (Q ̲STATUS)
The table contains for the terminal queues a 'change
map' indicating if a change has occured since the last
status display request.
Figure 4.3.1.3.1-1…01…General Queue Structure Overview
4.3.2 M̲T̲C̲B̲ ̲M̲o̲n̲i̲t̲o̲r̲
4.3.2.1 F̲u̲n̲c̲t̲i̲o̲n̲a̲l̲ ̲C̲a̲p̲a̲b̲i̲l̲i̲t̲i̲e̲s̲
The MTCB monitor supports the communication between
NODE/MEDE subsystems. An MTCB may reference a message
(control or narrative), a disk file or nothing. The
MTCB may contain data to be communicated from one subsystem
to other subsystems.
MTCB's referencing messages are called Real MTCB's.
MTCB's not referencing messages, but used for communication
in general are called Pseudo-MTCB's.
Real MTCB's may point to either a named file or the
Historical Data Base. Pseudo-MTCB's refer to naked
files, if they have reference to disk space.
The MTCB monitor provides syncronization of file deletion
(named files).
Files referenced by Real MTCB's are deleted.
When a message is on the Historical Data Base, the
named file which was input ot the HDB is deleted at
the moment the last reference is released (call
RELEASE ̲FILE - see below).
When a message is not on the Historical Data Base (e.g.
Special Handling messages) the file deletion is performed
when the last reference to the MTCB is released.
For Pseudo MTCB's the file (if a file was referenced)
is deleted when the last reference to the MTCB is released.
4.3.2.2 M̲T̲C̲B̲ ̲P̲r̲o̲c̲e̲d̲u̲r̲e̲s̲
10 calls have been defined:
Init: INIT ̲MTCB
MTCB: CREATE ̲MTCB
RESERVE ̲MTCB
RELEASE ̲MTCB
WRITE ̲MTCB
READ ̲MTCB…06…1 …02… …02… …02… …02…
File: CREATE ̲FILE
GET ̲FILE
RELEASE ̲FILE
RESERVE ̲FILE…06…1 …02… …02… …02… …02…
I̲n̲i̲t̲ ̲M̲T̲C̲B̲
This function initializes the process to the MTCB monitor.
The INIT ̲MTCB procedure should be called once by processes before any other access to the
MTCB monitor.
C̲r̲e̲a̲t̲e̲ ̲M̲T̲C̲B̲
Allocates a free MTCB from the pool of MTCB's. If no MTCB could be allocated, the Monitor
returns with error (return specified) or waits until a free MTCB can be allocated (wait specified).
Initializes the MTCB.
R̲e̲s̲e̲r̲v̲e̲ ̲M̲T̲C̲B̲
Notifies the MTCB monitor that one additional reference
exists to the MTCB.
This procedure is called by QACCESS when an element
is entered into a queue. It may be used by processes
not communicating via QACCESS directly, e.g. handing
the MTCB index via a pseudo MTCB.
For each RESERVE or CREATE one RELEASE must eventually
be issued.
R̲e̲l̲e̲a̲s̲e̲ ̲M̲T̲C̲B̲
Gives up one reference to a MTCB (opposite CREATE or
RESERVE).
This procedure is called by QACCESS when a queue element
is deleted.
It must be called by a process having received a MTCB
reference for which RESERVE was specifically called:
e.g. using a saved MTCB index
or
having received the MTCB index not from a queue
but from a pseudo ̲MTCB or equivalent.
For each RESERVE or CREATE one release must eventually
be issued.
Note: If a queue element has been obtained by requesting
destructive dequing to QACCESS, the MTCB must
be released by an explicit call of RELEASE
̲MTCB.
W̲r̲i̲t̲e̲ ̲M̲T̲C̲B̲
Update of the MTCB content.
The update of fields in MTCB's is controlled by the
requestor giving an update code. This code describes
those parameters in the MTCB, which are requested to
be updated.
R̲e̲a̲d̲ ̲M̲T̲C̲B̲
Read of the MTCB content. The MTCB is unpacked from
the MTCB in the MTCB Pool and moved to the application
specified record. All parameters are read at a call
to READ ̲MTCB.
C̲r̲e̲a̲t̲e̲ ̲F̲I̲L̲E̲
Creation of a named file on either the fixed-head disk
(PDB) or the moving-head disk (IMF). The organization
of the file is either consecutive or random. For consecutive
files the size is specified. In random files the area
size is one sector.
The file is created to be referenced from the MTCB
specified.
A file can only be created if the requester holds a
reference to the MTCB and this is the only existing
reference.
G̲e̲t̲ ̲f̲i̲l̲e̲
Get a reference to an already existing file (message
or file for pseudo MTCB).
Messages may be on the Historical Data Base and/or
on a named file. Files referenced from pseudo MTCB's
are always named files.
For messages on the HDB, the HDB reference is always
given. Otherwise the named file reference is given.
R̲e̲l̲e̲a̲s̲e̲ ̲F̲i̲l̲e̲
Releases the process's reference to the file being
used. If the file used was the HDB, the release implies
only that this MTCB has no more reference to the HDB
for this request of the MTCB. Reference to a file
may be reestablished via GET ̲FILE.
I̲n̲t̲e̲r̲f̲a̲c̲e̲ ̲D̲e̲s̲c̲r̲i̲p̲t̲i̲o̲n̲
The MTCB monitor is invoked by a Monitor call.
For Create, Reserve, release of MTCB's the MTCB index
is specified.
For Read and Write, a record, local to the caller and
the MTCB index, is specified.
For Create, Get and Release file, the MTCB index and
a record of file parameters are specified.