top - download
⟦061dccebc⟧ Wang Wps File
Length: 33317 (0x8225)
Types: Wang Wps File
Notes: CPS/SDS/005
Names: »1059A «
Derivation
└─⟦b282628ca⟧ Bits:30006035 8" Wang WCS floppy, CR 0059A
└─ ⟦this⟧ »1059A «
WangText
.…00……00……00……00…2…0a……00……00…2…0b…2…01…2…06…2…07…1…0c…1…0f…1
1 1…07…0…0b…0…0e…0…01…0…02…0…05…/…0a…/…0d…/…0e…/…0f…/…00……86…1 …02… …02… …02…
…02…CPS/SDS/005
…02…BMN/810801…02……02…
TABLE MANAGEMENT
…02……02…CAMPS
4.2 T̲M̲P̲ ̲S̲u̲b̲p̲a̲c̲k̲a̲g̲e̲ ̲S̲p̲e̲c̲i̲f̲i̲c̲a̲t̲i̲o̲n̲
4.2.1 T̲a̲b̲l̲e̲ ̲S̲e̲a̲r̲c̲h̲ ̲F̲u̲n̲c̲t̲i̲o̲n̲s̲
Table search functions perform search on the table
data maintained by TMP.
The functions will fulfil the requirements searching
and updating subprocesses have to table search.
The functions are designed generally so that they are
not dependent on the data in a table but only on the
data structure. This means that the search functions
contain no specific information about the actual table.
This information must be read in the table description
in each case.
The advantage of the above design is that a new table
is implemented just by increasing the data base and
declaring a new table description.
4.2.1.1 F̲u̲n̲c̲t̲i̲o̲n̲a̲l̲ ̲S̲p̲e̲c̲i̲f̲i̲c̲a̲t̲i̲o̲n̲
Table search functions find and read one or more records
in the tables maintained by TMP.
The input parameters for search are:
- Table identification
- Search key address
- Number of keys
- Search mask
- Read Mask
- Output address.
- Buffer Length
Table identification is the number of the table description
which describes the table in which search is to be
carried out.
Search key address is the address where search key
can be read. Search key may be one key or a list of
same key type.
Number of keys specifies how many keys there are in
list.
Search mask specifies which field to be used as key.
Read mask is a bit mask telling which fields in output
record are of interest.
Output address is the address where the output shall
be written. The output is one record or one list of
records for each input key.
Buffer length specifies length of output buffer.
Table description contains information about the table
to be searched in. There exists one table description
for each access method used at an existing table. This
means that each table has a description for each way
it may be accessed.
The table description may show that first output contains
only the search key to another table.
Table search functions consist of five modules.
The main module controlling and executing the functions
in the other modules and the other four modules maintaining
the necessary tasks. The last four modules are described
at the second level in this functional description.
Figure 4.2.1.1 Table Search
4.2.1.1.1 C̲o̲m̲m̲u̲n̲i̲c̲a̲t̲i̲o̲n̲
The communication functions receive requests from a
SyncEl, send responses to SyncEls and perform read
and update of table attributes.
4.2.1.1.1.1 R̲e̲c̲e̲i̲v̲e̲ ̲R̲e̲q̲u̲e̲s̲t̲
Receives a request from the SyncEl where the memory
search coroutine normally waits when it is inactive.
If the request does not require disk accesses, the
memory search functions are activated otherwise it
is posted onto the disk search functions.
4.2.1.1.1.2 S̲e̲n̲d̲ ̲R̲e̲s̲p̲o̲n̲s̲e̲
An answer is sent to the process which originally requested
the function now completed.
4.2.1.1.1.3 S̲e̲t̲ ̲T̲a̲b̲l̲e̲ ̲A̲t̲t̲r̲i̲b̲u̲t̲e̲s̲
Table attributes are set to specified value. Only supervisor
word in the table description may be updated by this
function.
4.2.1.1.1.4 G̲e̲t̲ ̲T̲a̲b̲l̲e̲ ̲A̲t̲t̲r̲i̲b̲u̲t̲e̲s̲
The table attributes in table description are read
and sent to calling process.
The table attributes are table ID, table load status,
time stamp and supervisor word.
4.2.1.1.2 S̲o̲r̲t̲ ̲K̲e̲y̲s̲
Calling Subprocess access rights are checked.
The keys in input parameters are linked in a single
chained list in sorted order after they are syntax
and consistence checked.
Input: Data Start Addr
No. of Keys
Key Type
Record Type.
Output: List of Sorted Keys
CC
- Complete
- Syntax error
- Inconsistent data.
4.2.1.1.2.1 C̲o̲m̲p̲a̲r̲e̲ ̲S̲t̲r̲i̲n̲g̲
Two data strings are compared and the result tells
whether the first of them is the first in sorted order
or not.
Input: Text String One
Text String Two
Output: Posistion
- First
- Same
- Last
CC
- Complete
- Syntax error.
4.2.1.1.3 M̲e̲m̲o̲r̲y̲ ̲T̲a̲b̲l̲e̲ ̲S̲e̲a̲r̲c̲h̲
A record in a table or table part in memory is found
and the wanted information is read and compressed to
the required information specified by a read mask.
Finally, the masked data are written in an area specified
by caller.
The memory table search main function requests one
search by one of its support functions and receives
an answer when the searched record is found or it is
determined that it is non-existent.
If a record is found, the main function calls the mask
function. After return from mask function, a check
is made as to whether the search is complete or whether
it must be continued.
Figure 4.2.1.1.3 Memory Table Search
4.2.1.1.3.1 B̲i̲n̲a̲r̲y̲ ̲S̲e̲a̲r̲c̲h̲
Binary search will either find the record specified
by input key or if it was non-existent, find where
it should have been placed.
Input: Search Key
- Search key to table
Table Body
- Start address of table
Output: Address
- Address of searched record or the address
of where it should have been.
CC
- Complete
- Not found
- Fail
4.2.1.1.3.2 D̲i̲r̲e̲c̲t̲ ̲S̲e̲a̲r̲c̲h̲
A key to a table is converted to the address of the
searched record.
Input: Search Key
- Key to searched record
Table Body
- Start address of table
Output: Address
- Address of searched record
CC
- Complete
- Fail
4.2.1.1.3.3 S̲e̲q̲u̲e̲n̲t̲i̲a̲l̲ ̲S̲e̲a̲r̲c̲h̲
Sequential search reads the records in a table from
a specified start address.
For each record, a primary or secondary search key
is compared with a specified simple field or with all
subfields in a repeated field of specified type. If
the key is primary, a return is made when the record
is found or it is determined where it should have been.
If the key is secondary, a return is made when the
first record with a key identical to search key is
found. It may be specified that a secondary key shall
only be searched in first record after start address.
Input: Search Key
- Search key to table
Table Body
- Start address of table
One Record
- Boolean
Output: Address
- Address of searched record or the address
of where it should have been.
CC
- Complete
- Not found
- Fail
4.2.1.1.3.4 M̲a̲s̲k̲ ̲D̲a̲t̲a̲
A data record is compressed to the required information
by using the input read mask.
If corresponding bit in read mask is set, the record
field is kept, otherwise it is removed.
Input: Record
- The record to be compressed
Read Mask
- The input read mask
Output: Record
- The compressed record
CC
- Complete
- Fail
4.2.1.1.4 D̲i̲s̲k̲ ̲T̲a̲b̲l̲e̲ ̲S̲e̲a̲r̲c̲h̲
Disk table search functions perform search in tables
residing on disk.
The searched block may be identified by means of search
key, table identification and an index table or it
may be identified only by the search key and table
identification.
When the block is identified and read into memory,
the rest of the search will be almost identical to
memory search. The only difference is when the key
next to the last key at a block is to be found. In
this case a new block may have to be read into the
memory if it is not the last block in the table.
Figure 4.2.1.1.4 Disk Table Search
4.2.1.1.4.1 I̲n̲d̲e̲x̲ ̲B̲l̲o̲c̲k̲
The block where a given record should be found, if
it exists, is identified by means of an index table.
Input: Search Key
- The search key to be found
Output: Block number
CC
- Complete
- Fail
4.2.1.1.4.2 D̲i̲r̲e̲c̲t̲ ̲B̲l̲o̲c̲k̲
The block where a given record is residing is identified
by means of an arithmetic determination.
Input: Key
- The search key to be found
Output: Block number
CC
- Complete
- Fail
4.2.1.1.4.3 R̲e̲a̲d̲ ̲D̲i̲s̲k̲ ̲B̲l̲o̲c̲k̲
The specified block is read into memory.
Before the I/O system is accessed, the number of the
block in memory is compared with the input block number.
If the numbers are identical, a return is made, otherwise
the block number is converted to a byte address within
a file and read request is made to the I/O system.
Input: Block number
Output: Disk block read into memory
CC
- Complete.
- Fail
4.2.1.2 S̲o̲f̲t̲w̲a̲r̲e̲ ̲S̲t̲r̲u̲c̲t̲u̲r̲e̲
Table search functions are implemented as a set of
procedures executed in user mode by a coroutine.
The coroutine is created in two incarnations using
the same code.
The two coroutines differ in the way that it is always
the memory search coroutine which receives the requests
from the SyncEl via an operation semaphore and because
the memory search coroutine has no buffer into which
it can read disk blocks, it must pass the disk search
requests on to the operation semaphore where the disk
search coroutine waits when it is inactive.
Each module is implemented as a set of procedures calling
procedures in their own module and in other modules.
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̲
The data flow is shown in figures 4.2.1.3-1 to 3. Only
the main flows are described as the simpler ones can
easily be identified by reading the functional description.
The control logic is shown in figure 4.2.1.3-4 and
5. The procedure on the left controls the processing
of the next four procedures which again control the
lower level procedures.
Every search may consist of several calls of the lower
level procedures.
Figure 4.2.1.3-1 Table Search
Figure 4.2.1.3-2 Memory Table Search
Figure 4.2.1.3-3 Disk Table Search
Figure 4.2.1.3-4 Control Logic
Figure 4.2.1.3-5 Control Logic
4.2.1.4 S̲u̲b̲p̲a̲c̲k̲a̲g̲e̲ ̲D̲a̲t̲a̲
Table search functions operate only on TMP common data
structures.
4.2.1.5 S̲u̲b̲p̲a̲c̲k̲a̲g̲e̲ ̲I̲n̲t̲e̲r̲f̲a̲c̲e̲
Table search functions interface to table update subpackage
and TMP monitor subpackage.
The update subpackage requests table search functions
via one operation semaphore and receives answers via
another.
TMP monitor sends requests to the SyncEl where the
search subpackage receives them and receives the response
from the SyncEl where search subpackage has sent them
and then passes on the response to the applications.
Ref. figure 4.2.1.5-1.
Figure 4.2.1.5 Subpackage Interface
4.2.2 T̲a̲b̲l̲e̲ ̲U̲p̲d̲a̲t̲e̲
Table update subpackage performs update at the tables
maintained by TMP.
Some Updates may require suspension of the search coroutines
during the final stage where the update is made effective.
When a table update is complete, the associated table
description is time stamped.
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̲
Table update is broken down into six modules, one module
scheduling tasks to the other five.
(Ref. fig. 4.2.2.1-1).
The scheduling module is the one at highest level and
the other five are shown at second level.
The scheduling module requests funtions by the other
modules and receives return parameters making it able
to decide what is to happen next.
The communication module receives requests from a SyncEl
and returns response to the requesting processes via
another SyncEl.
Figure 4.2.2.1-1 Functional Breakdown
4.2.2.1.1 S̲e̲a̲r̲c̲h̲
The search module identifies start address of next
record to be updated by using the memory search and
disk search modules from the search package.
4.2.2.1.1.1 M̲e̲m̲o̲r̲y̲ ̲S̲e̲a̲r̲c̲h̲
Has same functions as memory search described in search
subpackage. (Ref. 4.2.1.1.3).
4.2.2.1.1.2 D̲i̲s̲k̲ ̲S̲e̲a̲r̲c̲h̲
Has same function as disk search described in search
subpackage. (Ref. 4.2.1.1.4).
4.2.2.1.2 U̲p̲d̲a̲t̲e̲ ̲R̲e̲c̲o̲r̲d̲
A specified record is removed from a block, inserted
into a block or updated with one or more new fields.
If a remove or insert involves a record in an overflow
area the disk block in overflow is updated as well
as the overflow block.
4.2.2.1.2.1 U̲p̲d̲a̲t̲e̲ ̲D̲a̲t̲a̲
The data in an existing record are updated.
The fields to be updated may be one or more fields
updated to the specified value. The fields are specified
by a bit mask or the whole record may be overwritten
with an identical data structure.
If the record contains repeated fields, one subfield
may be removed and another may be inserted. After each
remove or insert, the repeated field is reorganized.
Input: Address
- Address of a record
New value
- Record or field value
Write mask
Old value
- Field value only used by
changing repeated field.
Record Type
Output: CC
- Complete
- Fail
4.2.2.1.2.2 R̲e̲m̲o̲v̲e̲ ̲R̲e̲c̲o̲r̲d̲
The record at specified address is removed by marking
it as unused.
Input: Address
- Address of a record
Output: CC
- Complete
- Fail
4.2.2.1.2.3 I̲n̲s̲e̲r̲t̲ ̲R̲e̲c̲o̲r̲d̲
A new record is inserted at the specified position.
If there are no more free places in current block the
record is not inserted, but the record with primary
key next to it is marked with overflow indicator. The
new record is then put in an overflow block.
Insert may cause a block re-organization. This is performed
by this function for itself.
Input: Record
- The new record
Address
- Address of the record next to the new position
Output: CC
- Complete
- Fail
4.2.2.1.3 U̲p̲d̲a̲t̲e̲ ̲D̲i̲s̲k̲
An updated block is written on disk in two copies to
ensure that a table is always recoverable.
First, a safety copy is written at a defined place
on disk. The start and end of this block are identical
so it can be seen whether it is complete, by reading
it.
On the safety copy, it can also be read which block
it shall replace.
After the safety copy is written, the original disk
block is overwritten with the new version.
Input: Block Number
- Original block number
Address
- The address of block in memory
Length
- The length of memory block
Output: CC
- Complete
- Fail
4.2.2.1.4 S̲u̲p̲p̲o̲r̲t̲
The support functions are functions used on special
occasions. They all require a lot of resources.
4.2.2.1.4.1 R̲e̲o̲r̲g̲a̲n̲i̲z̲e̲
A table is re-organized by copying the whole table
entry by entry. Entries marked as removed are not copied
and entries from overflow area are written at their
correct positions in the table.
For each re-organized memory block, the corresponding
memory index is updated.
If the table is organized with a secondary search key,
the relation between secondary search key and table
is also updated. If a system failure happens during
a re-organization, the re-organization must start from
the beginning after a restart.
The re-organization may be stopped by a command from
supervisor.
4.2.2.1.4.2 B̲a̲c̲k̲u̲p̲
A backup copy of a file is made by copying it to an
off-line volume where it will be catalogued under same
name as in the on-line volume.
4.2.2.1.4.3 R̲e̲-̲l̲o̲a̲d̲
A backup copy of a file is copied from an off-line
volume to the on-line volume.
The file is copied into the file of same name as it
is catalogued under at the off-line volume.
4.2.2.1.5 C̲o̲m̲m̲u̲n̲i̲c̲a̲t̲i̲o̲n̲
The communication functions receive requests and send
responses to requesting processes.
4.2.2.1.5.1 R̲e̲c̲e̲i̲v̲e̲ ̲R̲e̲q̲u̲e̲s̲t̲
Receives a request from the SyncEl where the update
coroutine waits when it is inactive.
4.2.2.1.5.2 S̲e̲n̲d̲ ̲R̲e̲s̲p̲o̲n̲s̲e̲
An answer is sent to the process which requested the
function now completed.
4.2.2.2 S̲o̲f̲t̲w̲a̲r̲e̲ ̲S̲t̲r̲u̲c̲t̲u̲r̲e̲
Table update functions are performed by two coroutines
executing a set of procedures in user mode. The procedures
are implemented in update and search sub-packages.
The procedures are executed in various sequences and
each sequence may be repeated several times.
If the request is reorganize or backup/reload, the
request is passed on to the support coroutine via an
operation semaphore.
The update and support coroutines use the same working
area. This shared area is reserved by means of a simple
semaphore.
The update coroutine has first priority to the working
area and the two semaphores previously described as
well as two flags are used to control this synchronization.
After completing a function, the coroutine returns
a response to requesting process via a SyncEl by executing
the "send response" function.
The table update module and the support module are
the coroutines and the other four modules are procedure
sets executed by the coroutines.
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̲
Fig. 4.2.2.3-1 shows the data flow for the update module.
The other modules have such a simple data flow that
it can be easily identified in the functional breakdown
description
Fig. 4.2.2.3-3 shows the control logic of table update
coroutine and its nearest environments. It is shown
how the coroutines receive their requests and sends
their responses to applications when an update is completed.
Furthermore, it can also be seen how a search request
may be sent to the table search subpackage and where
the answer to this request is received.
Fig. 4.2.2.3-4 shows the control logic inside the coroutine
such as which procedures call other procedures and
which procedures communicate with other subpackages.
Fig. 4.2.2.3-1…01…Table Update
Fig. 4.2.2.3-2
Fig. 4.2.2.3-3
4.2.2.4 T̲a̲b̲l̲e̲ ̲U̲p̲d̲a̲t̲e̲ ̲D̲a̲t̲a̲
Table Update subpackage manipulates only TMP common
data.
4.2.2.5 S̲u̲b̲p̲a̲c̲k̲a̲g̲e̲ ̲I̲n̲t̲e̲r̲f̲a̲c̲e̲
Table Update subpackage interfaces TMP monitor by receiving
requests and sending responses.
Table Update subpackage interfaces table search functions
by using procedures in this subpackage and by requesting
a normal search via operation semaphores. Ref. fig.
4.2.2.5-1.
Fig. 4.2.2.5-1
4.2.3 T̲M̲P̲ ̲M̲o̲n̲i̲t̲o̲r̲
TMP Monitor is a subpackage maintaining all interfaces
to application processes.
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 TMP Monitor subpackage is used by application packages
by all accesses to TMP.
Most requests are passed on to the TMP process but
"system parameter read" and all global number series
accesses which require fast access are performed by
TMP Monitor itself.
All accesses to TMP Monitor except GNS access are passed
through System Call Monitor and must thus follow the
general System Call Monitor interface.
TMP Monitor is split into four modules. The first
maintaining GNS.
The second maintaining system parameter read.
The third maintaining interface to TMP process.
The fourth maintaining function detection and scheduling
tasks to the other three modules.
Fig. 4.2.3.1-1
4.2.3.1.1 D̲e̲t̲e̲c̲t̲ ̲F̲u̲n̲c̲t̲i̲o̲n̲
When a request is received the function code is evaluated
to decide what function shall be activated.
4.2.3.1.2 P̲r̲o̲c̲e̲s̲s̲ ̲I̲n̲t̲e̲r̲f̲a̲c̲e̲
The process interface passes function requests on to
TMP process and delivers output from the TMP process
to the application processes.
Input: Function Code
Input Parameters
Output: CC
4.2.3.1.2.1 R̲e̲q̲u̲e̲s̲t̲ ̲F̲u̲n̲c̲t̲i̲o̲n̲
A function request is passed on to the TMP process
by sending it to one of the SyncEls. where the TMP
process receives its requests. The SyncEl. is selected
in accordance with the requested function type. The
input parameters are supplied with additional information
telling what process has made the request.
4.2.3.1.2.2 D̲e̲l̲i̲v̲e̲r̲ ̲O̲u̲t̲p̲u̲t̲
The output sent from TMP process to a Sync. El is delivered
to the application process associated to the Sync.
El.
4.2.3.1.3 G̲e̲t̲ ̲S̲y̲s̲t̲e̲m̲ ̲P̲a̲r̲a̲m̲e̲t̲e̲r̲
Reads and delivers a specified system parameter to
caller. System call monitor ensures that parameters
are locked under read.
Input: Parameter #
Output: Parameter value
CC
4.2.3.1.3.1 F̲i̲n̲d̲ ̲P̲a̲r̲a̲m̲e̲t̲e̲r̲
The specified system parameter start address and length
are found.
Input: Parameter #
Output: Start Address
Length
CC
4.2.3.1.3.2 D̲e̲l̲i̲v̲e̲r̲ ̲P̲a̲r̲a̲m̲e̲t̲e̲r̲
The parameter specified by start address and length
is delivered to caller.
If the length exceeds two words, it is delivered by
writing it at a caller specified address, otherwise
it is delivered in two registers.
Input: Start Address
Length
Output Address
Output: Parameter Value
CC
4.2.3.1.4 G̲e̲t̲ ̲G̲l̲o̲b̲a̲l̲ ̲N̲u̲m̲b̲e̲r̲ ̲S̲e̲r̲i̲e̲s̲
Reads specified global no. series and delivers the
value to caller in two registers. The value is increased
before read if it is specified by caller.
The output is delivered in decimal ASCII representation.
If it is a three digit number, the first byte will
be the ASCII representing a space.
A three digit number will always wrap around to 1 after
999 and a four digit number will always wrap around
to 1 after 9999.
While GNS values are increased and read, the number
series are locked for all other access.
Input: GNS ID.
Increase
- Boolean telling if next
no is wanted
Output: GNS value
- Specified as decimal ASCIII
CC
4.2.3.1.4.1 F̲i̲n̲d̲ ̲G̲l̲o̲b̲a̲l̲ ̲N̲u̲m̲b̲e̲r̲ ̲S̲e̲r̲i̲e̲s̲
Determines the address of the specified GNS.
Input: GNS ID.
Output: Address
- Address of the word containing the GNS
CC
4.2.3.1.4.2 I̲n̲c̲r̲e̲a̲s̲e̲ ̲G̲l̲o̲b̲a̲l̲ ̲N̲u̲m̲b̲e̲r̲ ̲S̲e̲r̲i̲e̲s̲
The specified GNS is increased by one if it is less
than wrap around value Otherwise it is set to value
"one".
Input: Address
- Address of the word containing the GNS
Output: CC
4.2.3.1.4.3 D̲e̲l̲i̲v̲e̲r̲ ̲G̲l̲o̲b̲a̲l̲ ̲N̲u̲m̲b̲e̲r̲ ̲S̲e̲r̲i̲e̲s̲
The GNS is delivered to caller in a register.
Before delivery, the GNS value is converted to ASCIII.
Input: Address
- Address of the word containing the GNS.
Output: GNS.
- GNS value in two registers in digital ASCII
- CC
4.2.3.1.5 S̲e̲t̲ ̲G̲l̲o̲b̲a̲l̲ ̲N̲u̲m̲b̲e̲r̲ ̲S̲e̲r̲i̲e̲s̲
The input serial no. is converted to integer and the
specified serial no. is set to specified value. Both
the serial no. value and the first bit telling how
many digits the serial no. shall be represented by
are set to the specified value. If first byte in input
was "ASCII space" the serial no. is specified to have
three digits.
Input: GNS ID.
GNS Value
- Digital ASCII
Output: CC
4.2.3.1.5.1 F̲i̲n̲d̲ ̲G̲l̲o̲b̲a̲l̲ ̲N̲u̲m̲b̲e̲r̲ ̲S̲e̲r̲i̲e̲s̲
Ref. 4.2.3.1.3.1.
4.2.3.1.5.2 W̲r̲i̲t̲e̲ ̲G̲l̲o̲b̲a̲l̲ ̲N̲u̲m̲b̲e̲r̲ ̲S̲e̲r̲i̲e̲s̲
Writes the new GNS value at specified address.
Before write, the GNS value is converted to integer.
During the write operation, the number series is locked
for all other access.
Input: GNS value
Address
Output: CC
4.2.3.2 S̲o̲f̲t̲w̲a̲r̲e̲ ̲S̲t̲r̲u̲c̲t̲u̲r̲e̲
TMP monitor consists of two independent software parts.
The one is a procedure with an entry for each function
callled by System Call Monitor. This procedure executes
in system mode under System Call Monitor. The other
is a monitor procedure with two entries - one for get
no. series and one for set no series.
4.2.3.2.1 D̲e̲t̲e̲c̲t̲ ̲F̲u̲n̲c̲t̲i̲o̲n̲
Detect Function is a procedure used to detect the function
called from system call monitor. After detection, the
requested function is performed by the procedure selected
by the detection.
4.2.3.2.2 P̲r̲o̲c̲e̲s̲s̲ ̲I̲n̲t̲e̲r̲f̲a̲c̲e̲
Process interface has the normal entries for a service
system under System Call Monitor. Each entry is implemented
as a procedure.
4.2.3.2.2.1 I̲n̲i̲t̲
The init procedure sends input parameters and SOCB
reference to a Sync. Element. The Sync. Element is
selected in accordance with the requested function.
After init, the SOCB will always be pending.
4.2.3.2.2.2 A̲n̲s̲w̲e̲r̲ ̲R̲e̲c̲e̲i̲v̲e̲d̲
The answer received procedure is called with an Information
Element from a SyncEl and a list of pending SOCBs as
input parameters. The SOCB referred in the Info. Element
is found in the SOCB list. The completion code from
the Information Element is put into the SOCB and SOCB
Cs is set to done. Finally the SOCB ref. is delivered
to System Call Monitor.
4.2.3.2.3 C̲o̲m̲p̲l̲e̲t̲e̲
The complete procedure is called with a SOCB ref. as
input parameter. The completion code in the SOCB is
delivered to caller in a register.
4.2.3.2.2.4 C̲a̲n̲c̲e̲l̲
A cancel request is not passed on to TMP process and
has thus no effect.
4.2.3.2.3 G̲e̲t̲ ̲S̲y̲s̲t̲e̲m̲ ̲P̲a̲r̲a̲m̲e̲t̲e̲r̲s̲
The system parameters are read by TMP monitor itself.
The read request is made through System Call Monitor
and must thus follow the general System Call Monitor
interface.
4.2.3.2.3.1 I̲n̲i̲t̲ ̲G̲e̲t̲ ̲P̲a̲r̲a̲m̲e̲t̲e̲r̲
The init procedure determines where the parameter start
address is and how long the parameter is. These two
facts are put into the SOCB specified by call together
with caller information parameters necessary for completion.
Finally, the SOCB Cs is set to done.
4.2.3.2.3.2 A̲n̲s̲w̲e̲r̲ ̲R̲e̲c̲e̲i̲v̲e̲d̲ ̲G̲e̲t̲ ̲P̲a̲r̲a̲m̲e̲t̲e̲r̲
Because SOCB is never pending after init, the answer
received has no meaning and will thus be an empty entry.
4.2.3.2.3.3 C̲o̲m̲p̲l̲e̲t̲e̲ ̲G̲e̲t̲ ̲P̲a̲r̲a̲m̲e̲t̲e̲r̲s̲
The complete procedure delivers the parameter specified
in the SOCB to the caller.
If the parameter length exceeds two words, it is written
at an address specified by caller and stored in the
SOCB by init, otherwise the parameter is delivered
in two registers. The completion code will always be
delivered in a register.
4.2.3.2.3.4 C̲a̲n̲c̲e̲l̲ ̲G̲e̲t̲ ̲P̲a̲r̲a̲m̲e̲t̲e̲r̲
Because the SOCB is never pending after init, cancel
has no meaning and will thus be an empty entry.
4.2.3.2.4 G̲l̲o̲b̲a̲l̲ ̲N̲u̲m̲b̲e̲r̲ ̲S̲e̲r̲i̲e̲s̲
GNS is implemented as a monitor procedure with two
entries, one for "get GNS" series and one for "set
GNS".
All communications are made via three registers. For
input used for function code, serial no. id. and serial
no. value. For output used for serial no. value and
completion code. This monitor procedure is called directly
by the applications
The procedures are identical to the functions described
in 4.2.3.1.4 and 5.
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̲
The Control Logic is shown in figure 4.2.3.3-1.
The blocks are identical to the software component
and the references in the blocks refer to the functional
description (ref. 4.2.3.1).
Figure 5.2.3.3-1 Control Logic
4.2.3.4 S̲u̲b̲p̲a̲c̲k̲a̲g̲e̲ ̲D̲a̲t̲a̲
The subpackage data may be split into two groups. The
data used by GNS management and the data used by TMP
process interface.
4.2.3.4.1 G̲l̲o̲b̲a̲l̲ ̲N̲u̲m̲b̲e̲r̲ ̲S̲e̲r̲i̲e̲s̲ ̲D̲a̲t̲a̲
The GNS is stored in an integer array indexed by "GNS
ID".
Each number series is contained in one word where the
14 least significant bits show the GNS value and the
most significant bit indicates whether the no. has
three or four digits.
4.2.3.4.2 I̲n̲t̲e̲r̲f̲a̲c̲e̲ ̲D̲a̲t̲a̲
The only data structure maintained by the interface
part of this package is the structure in the SOCBs
used by interface to System Call Monitor.
There are two structures: the one used by requests
to TMP process and the other used by parameter read.
In the case of requests to TMP process the SOCB contains
only a completion code, ref. fig. 4.2.3.4.2-1.
In the case of parameter read, the SOCB contains a
parameter address, a parameter length and a completion
code, ref. fig. 4.2.3.4.2-2.
Figure 4.2.3.4.1 Global No. Series Array
4.2.3.5 S̲u̲b̲p̲a̲c̲k̲a̲g̲e̲ ̲I̲n̲t̲e̲r̲f̲a̲c̲e̲
TMP Monitor interfaces to table search and table update
subpackages via SyncEls. The interface is always such
that a user request is passed on to another subpackage
by sending input parameters, requesting process identification
and SOCB reference to the SyncEl associated with the
other subpackage.
Answers to the requests are received via the System
Call Monitor, ref. fig. 4.2.3.5-1
Figure 4.2.3.5-1 TMP Monitor Subpackage Interface
4.3 M̲E̲M̲O̲R̲Y̲ ̲L̲A̲Y̲O̲U̲T̲
The storage needed for TMP is split into three different
parts:
- Table Storage
- Working Storage
- Code Storage.
The sizes of these three parts are described in sections
4.3.1-3.
The common storage size is as follows:
Memory Disk
Table Storage 9.9 kbytes 900 kbytes
Working Storage 10.1 kbytes 400 kbytes
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
̲ ̲
20.0 kbytes 1300 kbytes
…0f… =========== ===========…0e…
Code Storage 12.0 kbytes
…0f… ===========
4.3.1 T̲a̲b̲l̲e̲ ̲S̲t̲o̲r̲a̲g̲e̲
Fig. 4.3.1-1 overleaf shows how much disk storage and
memory storage each table group requires.
The values indicating the amount of storage used for
memory index and secondary search key are include in
columns 1 and 2.
The sums in columns 1 and 2 thus indicate the total
amount of disk storage and memory storage required
by TMP data.
Storage Type Disk Memory Memory Secondary
Table Index Search
Key
(kbytes) (bytes) (bytes) (kbytes)
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
AIG table 105 68 68
1.6
PLA tables 378 3738 2410
15
RI tables 36 492 130
Circuit tables 192
SIC tables 270 360 360
SDL tables 36
SCD table 3
Command table 18 30 30
Operating table 3
Technical Error table 3
Terminal Profile 3
Device Profile 3
Channel Profile 3
User Profile 15 20 20
Configuration tables 12 3000
System Parameters
and GNS 3 2000
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
All Tables 891 9900
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
Fig. 4.3.1-1 Table Storage
4.3.2 W̲o̲r̲k̲i̲n̲g̲ ̲S̲t̲o̲r̲a̲g̲e̲
The total working storage is a sum of the storage needed
for TMP Monitor and the three coroutines.
These three parts require storage as follows:
Memory Disk
(bytes) (kbytes)
TMP Monitor 100 0
Memory Search 1000 0
Disc Search 4000 0
Update 5000 400
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
̲
10100 bytes 400 kbytes
…0f… =========== ==========…0e…
4.3.3 C̲o̲d̲e̲ ̲S̲t̲o̲r̲a̲g̲e̲
The TMP code consists of 15 modules, each including
200 statements on average.
One swell statement is on average 4 bytes.
Required storage: 15 x 200 x 4 = 12 kbytes
…0f…=========…0e…
The code resides in memory.
