top - download
⟦2ea207fc6⟧ Wang Wps File
Length: 58905 (0xe619)
Types: Wang Wps File
Notes: CPS/SDS/026
Names: »1588A «
Derivation
└─⟦7985b6947⟧ Bits:30005810 8" Wang WCS floppy, CR 0117A
└─ ⟦this⟧ »1588A «
WangText
/…00……00……00……00……1b……0a……00……00……1b……0b……1b……00……1b…
…1b……05……1b……06……1a……0b……1a……0f……1a… …19……09……19……0b……19……0e……19……00……19……06……18……0d……18……05……18……06……18……07……17……08……17……09……17……0a……17……00……17……06……16……0c……16……0e……16……0f……16…
…16……07……15……0b……15……00……15……05……15……06……14……0d……14……0f……14……00……86…1 …02… …02… …02…
…02…CPS/SDS/026
…02…BMN/840105
TABLE MANAGEMENT
DETAILED DESIGN SPECIFICATION…02…ISSUE 1…02…CAMPS
1̲ ̲ ̲G̲E̲N̲E̲R̲A̲L̲
1.1 P̲U̲R̲P̲O̲S̲E̲ ̲A̲N̲D̲ ̲S̲C̲O̲P̲E̲
The purpose of Table Management Package (TMP) is to
provide search and update tools to the packages which
want to access the data base containing tables, system
parameters and global number series.
Furthermore, TMP will control that no package accesses
other data than it is allowed to access.
This document describes TMP down to a level where all
functions performed by TMP and all components to be
implemented inside TMP are defined.
This description is a further detailed description
of TMP functions than the one in CPS/SDS/001
In this specification is given a description of general
interfaces and general data structures.
For more detailed data and interface description refer
CPS/DBD/001 and CAMPS SW Interface Control Document.
1.2 A̲P̲P̲L̲I̲C̲A̲B̲L̲E̲ ̲D̲O̲C̲U̲M̲E̲N̲T̲S̲ ̲A̲N̲D̲ ̲P̲R̲O̲J̲E̲C̲T̲ ̲R̲E̲F̲E̲R̲E̲N̲C̲E̲S̲
1.2.1 A̲p̲p̲l̲i̲c̲a̲b̲l̲e̲ ̲D̲o̲c̲u̲m̲e̲n̲t̲s̲
- CPS/DBD/001 reference (a) see also
sec. 4.1.6
- CPS/ICD/009 reference (b)
- CSS/006/PSP/0044 reference (c)
- CPS/210/SYS/0001 reference (d)
- CPS/ICD/002 reference (e)
- CPS/SDS/001 reference (f)
- CSS/2100/PSP/0019
1.2.2 P̲r̲o̲j̲e̲c̲t̲ ̲R̲e̲f̲e̲r̲e̲n̲c̲e̲s̲
N/A.
1.3 T̲E̲R̲M̲S̲ ̲A̲N̲D̲ ̲A̲B̲B̲R̲E̲V̲I̲A̲T̲I̲O̲N̲S̲
1.3.1 T̲e̲r̲m̲s̲
S̲u̲b̲p̲r̲o̲c̲e̲s̲s̲
Group of modules having the same access rights.
K̲e̲y̲
Field value used to identify a record.
T̲a̲b̲l̲e̲
List of same type records.
1.3.2 A̲b̲b̲r̲e̲v̲i̲a̲t̲i̲o̲n̲s̲
CSF CAMPS System Functions
GSN Global Serial Number
ID Identification
MDP Message Distribution Package
FMS Storage and File Management
SSC System Status and Control
SyncEl Synchronization Element
TEP Terminal Package
THP Traffic Handling Package
TMP Table Management Package
2̲ ̲ ̲S̲U̲M̲M̲A̲R̲Y̲ ̲O̲F̲ ̲R̲E̲Q̲U̲I̲R̲E̲M̲E̲N̲T̲S̲
2.1 T̲M̲P̲ ̲D̲E̲S̲C̲R̲I̲P̲T̲I̲O̲N̲
TMP receives function requests from application packages
and SSC and returns answers by means of system call
monitor in CSF package.
TMP reads from disk and writes to disk via FMS.
Ref. fig. 2.1-1.
Fig. 2.1-1…01…Package Interrelationship
2.2 T̲M̲P̲ ̲F̲U̲N̲C̲T̲I̲O̲N̲S̲
2.2.1 T̲M̲P̲ ̲N̲o̲r̲m̲a̲l̲ ̲F̲u̲n̲c̲t̲i̲o̲n̲s̲
The normal TMP functions are:
- Search In Tables
- Update Of Tables
- Reorganization Of Tables
- Back-up/Reload Of TMP Data
- Global Serial Number Management
- System Parameter Management
2.2.1.1 S̲e̲a̲r̲c̲h̲ ̲I̲n̲ ̲T̲a̲b̲l̲e̲s̲
One or more records from a table are identified after
a key value and delivered to caller. More than one
key to the same table may be specified at a time.
Only the record fields requested by caller are delivered.
2.2.1.2 U̲p̲d̲a̲t̲e̲ ̲O̲f̲ ̲T̲a̲b̲l̲e̲
One record is inserted in a table or removed from a
table.
One or more records is changed.
2.2.1.3 R̲e̲o̲r̲g̲a̲n̲i̲z̲a̲t̲i̲o̲n̲ ̲O̲f̲ ̲T̲a̲b̲l̲e̲s̲
All tables are reorganized so unused records are removed
and records in overflow area are put in their appropriate
place.
2.2.1.4 B̲a̲c̲k̲-̲u̲p̲/̲R̲e̲l̲o̲a̲d̲ ̲O̲f̲ ̲T̲M̲P̲ ̲D̲a̲t̲a̲
Tables are backed up by copying them to an offline
volume, or they are reloaded by copying them back in
their appropriate position at the on-line volume.
2.2.1.5 G̲l̲o̲b̲a̲l̲ ̲S̲e̲r̲i̲a̲l̲ ̲N̲u̲m̲b̲e̲r̲ ̲M̲a̲n̲a̲g̲e̲m̲e̲n̲t̲
The GSN is maintained in a way, so that they may be
read or updated by other packages.
The read may cause the GSN being read to be increased
by one.
2.2.1.6 S̲y̲s̲t̲e̲m̲ ̲P̲a̲r̲a̲m̲e̲t̲e̲r̲ ̲M̲a̲n̲a̲g̲e̲m̲e̲n̲t̲
A system parameter may be read or updated.
2.2.2 F̲u̲n̲c̲t̲i̲o̲n̲a̲l̲ ̲R̲e̲s̲p̲o̲n̲s̲i̲b̲i̲l̲i̲t̲i̲e̲s̲
2.2.2.1 I̲n̲i̲t̲i̲a̲l̲i̲z̲a̲t̲i̲o̲n̲,̲ ̲C̲l̲o̲s̲e̲ ̲D̲o̲w̲n̲,̲ ̲a̲n̲d̲ ̲R̲e̲s̲t̲a̲r̲t̲
2.2.2.1.1 I̲n̲i̲t̲i̲a̲l̲i̲z̲a̲t̲i̲o̲n̲
In initialization TMP reloads all TMP data and copies
the memory resident data into memory. Then coroutines
are initialized and TMP will then wait for further
requests.
2.2.2.1.2 C̲l̲o̲s̲e̲ ̲D̲o̲w̲n̲
TMP has no responsibility of its own by close down.
2.2.2.1.3 R̲e̲s̲t̲a̲r̲t̲
By restart TMP will read memory resident data into
memory and initialize coroutines.
Then a consistency check of disk resistent data is
made and TMP will then wait for further requests.
2.2.2.2 C̲h̲e̲c̲k̲ ̲P̲o̲i̲n̲t̲i̲n̲g̲ ̲a̲n̲d̲ ̲R̲e̲c̲o̲v̲e̲r̲y̲
TMP performs no check pointing.
All data except global number series will be copied
to disk each time they are updated so they will always
be recoverable.
All requests to TMP where TMP has not yet returned
an answer may be lost by system failure.
2.2.2.3 E̲r̲r̲o̲r̲ ̲D̲e̲t̲e̲c̲t̲i̲o̲n̲ ̲a̲n̲d̲ ̲E̲r̲r̲o̲r̲ ̲H̲a̲n̲d̲l̲i̲n̲g̲
If input data in a TMP request are syntactically illegal
or inconsistent, the requesting process is retired
by using a Kernel call.
2.2.2.4 I̲n̲t̲e̲g̲r̲i̲t̲y̲ ̲o̲f̲ ̲O̲p̲e̲r̲a̲t̲i̲o̲n̲
When no system failure occur TMP ensures that all requests
will return an answer to the calling process. TMP also
ensures that no request may cause damage in the TMP
process.
Inconsistence in TMP data caused by update may result
in no more output to processes requesting search than
a completion code.
Inconsistence in TMP data may only be coursed by a
misused update function.
The updated part of a table is written in a safety
copy at disk before the original table is updated.
2.2.2.5 D̲a̲t̲a̲ ̲C̲o̲l̲l̲e̲c̲t̲i̲o̲n̲
TMP is collecting statistics on table level.…86…1
…02… …02… …02… …02… …02…
2.2.2.6 S̲e̲c̲u̲r̲i̲t̲y̲
TMP ensures that no subprocess reads or updates data
not defined at system generation time.
2.3 C̲H̲A̲R̲A̲C̲T̲E̲R̲I̲S̲T̲I̲C̲S̲
2.3.1 T̲i̲m̲i̲n̲g̲
The access times specified here are maximum time per
key.
When more than one key is given by one request, the
mean time per key will be less than access time by
one key.
The total access time is the sum of the time used by
FMS and the time used by TMP.
The disk accesses and access times are:
NO OF FMS TMP
PROCES-
DISK
ACCESSES
SING
TIME
- Parameter read or GNS access 0 0,5
ms
- Search in memory resident tables 0
30 ms
- Update of memory tables 4
40 ms
- Search in disk tables 1
40 ms
- Search in disk tables via reference 2
50 ms
- Update of disk tables 5
50 ms
2.3.2 T̲h̲r̲o̲u̲g̲h̲p̲u̲t̲
The throughput may be increased by having the disk
search coroutine in two incarnations.
The throughput will increase about 50%.
2.3.3 F̲l̲e̲x̲i̲b̲i̲l̲i̲t̲y̲
The number of data groups or the number of entries
in one data group may increase without affecting the
TMP Software.
The only difference is that more storage is needed.
2.3.4 A̲c̲c̲u̲r̲a̲c̲y̲
Any deviation from defined parameters will result in
the calling process being retired.
3̲ ̲ ̲E̲N̲V̲I̲R̲O̲N̲M̲E̲N̲T̲
3.1 E̲Q̲U̲I̲P̲M̲E̲N̲T̲
TMP executes in one processing unit consisting of more
than one CPU.
3.2 S̲O̲F̲T̲W̲A̲R̲E̲
3.2.1 S̲y̲s̲t̲e̲m̲ ̲S̲o̲f̲t̲w̲a̲r̲e̲
TMP uses the KERNEL, FMS, and CSF system software packages.
TMP must be controlled by an operating system, for
instance COPSY within SSC, defining the control parameters
used by TMP.
3.2.2 D̲e̲v̲e̲l̲o̲p̲m̲e̲n̲t̲ ̲S̲u̲p̲p̲o̲r̲t̲ ̲S̲o̲f̲t̲w̲a̲r̲e̲
The software used for development of this package is
contained in Support Software Package.
3.3 I̲N̲T̲E̲R̲F̲A̲C̲E̲S̲
3.3.1 E̲x̲t̲e̲r̲n̲a̲l̲ ̲I̲n̲t̲e̲r̲f̲a̲c̲e̲s̲
N/A
3.3.2 P̲a̲c̲k̲a̲g̲e̲ ̲I̲n̲t̲e̲r̲f̲a̲c̲e̲s̲
SSC, TEP, THP, STP, and MDP interfaces to TMP by requesting
search and update functions.
3.4 F̲U̲N̲C̲T̲I̲O̲N̲S̲ ̲M̲A̲I̲N̲T̲A̲I̲N̲E̲D̲ ̲B̲Y̲ ̲O̲T̲H̲E̲R̲ ̲P̲A̲C̲K̲A̲G̲E̲S̲
TMP is supported by Coroutine Monitor and System Call
Monitor in the CSF package.
4̲ ̲ ̲T̲M̲P̲ ̲D̲E̲S̲I̲G̲N̲
4.1 T̲M̲P̲ ̲O̲V̲E̲R̲V̲I̲E̲W̲
Table Management Package performs search and update
functions at tables, system parameters, and GSN.
The functions in TMP will be as general as possible
so it may be possible to add further tables to the
TMP data without the processing modules should be changed.
4.1.1 F̲u̲n̲c̲t̲i̲o̲n̲a̲l̲ ̲D̲e̲s̲c̲r̲i̲p̲t̲i̲o̲n̲
TMP functional description starts with a description
of data organization and access methods used by TMP.
This is followed by a general description of the functions
performed by TMP.
Finally, the functions are split into subpackages which
again is split into modules.
4.1.1.1 T̲a̲b̲l̲e̲ ̲O̲r̲g̲a̲n̲i̲z̲a̲t̲i̲o̲n̲ ̲a̲n̲d̲ ̲A̲c̲c̲e̲s̲s̲ ̲M̲e̲t̲h̲o̲d̲s̲
4.1.1.1.1 T̲a̲b̲l̲e̲ ̲O̲r̲g̲a̲n̲i̲z̲a̲t̲i̲o̲n̲
All tables consist of a list of similar type records.
Ref. fig. 4.1.1.1-1. A table may be organized direct
or sequential.
Direct organization means that the records are identified
alone by their position in the table.
Sequential organization means that the records are
sorted in accordance with a primary key which also
identifies the record. The primary key field in a
record must be unique in one table. The records may
also be searched by a secondary key, but a secondary
key may identify more than one record in one table.
Refer fig. 4.1.1.1-2. Sequential organization may
be expanded to index sequential organization which
means that the table is split into a number of same
length blocks which are referred in another sequential
table containing a reference to last primary key in
each block. Ref. fig. 4.1.1.1-3.
Sequential organization has also an incarnation called
Secondary Key Organization. This type may be used
if a table is often accessed using a unique secondary
key. The secondary keys are put in sorted order in
a reference table where each secondary key has a reference
to the physical position of the record (ref. figure
4.1.1.1-4).
In the following the reference table will be called
the Inverse Table.
4.1.1.1.2 R̲e̲c̲o̲r̲d̲ ̲S̲t̲r̲u̲c̲t̲u̲r̲e̲
Each record in a table consists of one or more fields.
The first field in some record types is reserved for
TMP control data. The second field will contain the
primary key if the record has any.
The rest of the fields may contain data of various
kind.
All records known by TMP have from one to sixteen fields
of various length and are defined by a record description.
(Ref. figure 4.1.1.-5).
4.1.1.1.3 F̲i̲e̲l̲d̲ ̲S̲t̲r̲u̲c̲t̲u̲r̲e̲
There exist two field types. Simple fields and repeated
fields.
The simple field consists of one information field.
The repeated field consists of a defined number of
identical subfields. The first byte in a repeated field
will tell how many of the subfields are used. (Ref.
figure 4.1.1.1-5).
4.1.1.1.4 T̲a̲b̲l̲e̲ ̲D̲e̲s̲c̲r̲i̲p̲t̲i̲o̲n̲
For each logical table one TABLE ̲DESCRIPTION are defined.
Logical Table means a table accessed by other processes
than TMP.
All Logical Tables are defined in CPS/DBD reference
(a).
TABLE ̲DESCRIPTION defines all parameters nessecary
by performing a search or an update access, and further
it contains an part used when collecting TMP statistics.
One Physical Table may be referenced from more than
one TABLE ̲DESCRIPTION. This makes it possible that
two applications searching in same physical table may
get different output because they are accessing two
different Logical Tables.
The two Logical Tables may have defined that the same
parameters should be formattet in two ways or they
may have defined different subsets of the maximum available
output as output from actual table.
By secondary Key Organized Tables, the TABLE ̲DESCRIPTION
defining the Inverse Table will have a reference to
associated normal Logical Table.
This means that searching in Inverse Table are consisting
of two parts.
First a physical reference to Normal Table entry is
found in the Inverse Table and then the output is delivered
in accordance with the definitions in TABLE ̲DESCRIPTION
of the Normal Table.
In special cases an connection between two different
tables may be defined, so the output from the one table
is automatically used as input for a search in the
other table.
In this case the first level table has a reference
to the second level table in its TABLE ̲DESCRIPTION.
A search will then start searching in first level table
and generate an intermediate output in TMPS own data
area.
This output is then used as input for a search generating
the final output in accordance with the conventions
of second level table.…86…1 …02… …02… …02… …02…
Fig. 4.1.1.1-1…01…Functional Description
Fig. 4.1.1.1-2…01…Functional Description
Fig. 4.1.1.1-3…01…Functional Description
Fig. 4.1.1.1-4…01…Functional Description
Fig. 4.1.1.1-5…01…Functional Description
4.1.1.2 T̲a̲b̲l̲e̲ ̲S̲e̲a̲r̲c̲h̲
When TMP performs a search, it gets its input from
a data structure in the data area of the requesting
application process.
The segments containing this structure and the area
where output shall be delivered are mapped into TMP
process during the search.
The data structure contains the following information.
- Table ID.
- Output Address
- Output Buffer Length
- Search Mask
- Read Mask
- Number of Keys
- List of Keys
Table ID. is a reference to the table description containing
information necessary for this search.
Output address is a reference to the area where output
shall be delivered.
Output buffer length tells how much the output data
may fill.
Search Mask specifies which fields to be searched for.
Read Mask specifies which fields shall be delivered
by output.
Number of keys specifies how many input key values
are specified in key list.
List of keys is a list of field values used by search.
Before search TMP checks the input keys for inconsistency
and perhaps sorts them via a pointer ARRAY in TMP data
area.
The output is delivered in the same order as input
Keys were sorted. Each Key has a pointer referencing
its associated output.
An application process may by request specify if the
first level output shall be used as input for search
of a second level output.
The input parameters for a one level search and a two
level search differs in the way that two different
table IDs are used.
The table ID for a two level search will contain a
reference to the table where the second level information
is held.
4.1.1.3 T̲a̲b̲l̲e̲ ̲U̲p̲d̲a̲t̲e̲
Table update will update one record specified by a
primary key or it may update one or more fields of
the same value to one new value in a table.
The single record update may remove a record, insert
a record or change the data fields.
The data fields to be changed may be all, or some specified
fields of same type which shall be set to the same
value or it may be all fields of a special value set
to another value.
The data field update may update the specified fields
in all records in a table to a specified value, or
update only the specified fields having a special value
to a new value.
4.1.1.4 T̲M̲P̲ ̲I̲n̲t̲e̲r̲f̲a̲c̲e̲ ̲F̲u̲n̲c̲t̲i̲o̲n̲s̲
The interface functions receive requests from application
processes and pass them on to TMP process which performs
the real processing.
The interface functions will also ensure that the application
processes get the responses sent by TMP process each
time a request is completed.
The interface functions will ensure that no unknown
request is passed on to TMP process.
4.1.1.5 S̲y̲s̲t̲e̲m̲ ̲P̲a̲r̲a̲m̲e̲t̲e̲r̲s̲ ̲a̲n̲d̲ ̲G̲l̲o̲b̲a̲l̲ ̲N̲u̲m̲b̲e̲r̲ ̲S̲e̲r̲i̲e̲s̲
System parameters and GSN can be read and updated.
A GSN may be read in the special way that it is increased
by one just before read. If maximum value is exceeded
by the increase, the GSN value becomes one.
All accesses are performed by the application processes
by using monitor procedure calls.
Parameter update and GSN indicator update are performed
by TMP process as a normal table update.
4.1.1.6 B̲a̲c̲k̲-̲u̲p̲ ̲a̲n̲d̲ ̲R̲e̲l̲o̲a̲d̲
Back-up copies a TMP file from the on-line to SYS ̲GEN
volume.
Reload copies a TMP file from SYS ̲GEN to the on-line
volume.
After reload, the new copied file is read into memory,
if it normally resides here.
4.1.1.7 R̲e̲o̲r̲g̲a̲n̲i̲z̲e̲
Reorganize removes unused records from a table and
puts records from an overflow area in their appropriate
position. Reorganize may be stopped by a request from
the Supervisor.
4.1.1.8 F̲u̲n̲c̲t̲i̲o̲n̲a̲l̲ ̲B̲r̲e̲a̲k̲d̲o̲w̲n̲
To break this package down in subpackages, the functions
described in this chapter are split into three main
groups.
Each group is a subpackage containing functions with
common characteristics. The functions mapped on each
subpackage is shown at fig. 4.1.1.8-1.
The three subpackages are at the second level.…86…1
…02… …02… …02… …02…
In the following all TMP modules are grouped in subpackages
and listed.
Search Subpackage
- Search Communication
- Sort Key
- General Search
- Memory Table Search
- Disk Table Search
- Special Search
Update Subpackage
- Update Communication
- Search
- Update Record
- Update Disk
- Support
- Start Up
TMP Monitor
- Process Functions
- Monitor Functions
- Main Functions
Fig. 4.1.1.7-1…01…Functional Breakdown
4.1.1.8.1 T̲a̲b̲l̲e̲ ̲S̲e̲a̲r̲c̲h̲ ̲F̲u̲n̲c̲t̲i̲o̲n̲s̲
This subpackage receives search requests from a SyncEl.
and generates the output which contains the wanted
information.
4.1.1.8.1.1 S̲e̲a̲r̲c̲h̲ ̲C̲o̲m̲m̲u̲n̲i̲c̲a̲t̲i̲o̲n̲
This function receives one request from a SyncEl and
passes it on to processing.
The request may be so simple that it is performed by
the communication module itself e.g., "get TMP statistics"
or "get table attributes".
4.1.1.8.1.2 S̲o̲r̲t̲ ̲K̲e̲y̲s̲
First, the access rights of calling subprocess are
checked.
Then, this function checks input parameters and perhaps
sorts the input keys.
4.1.1.8.1.3 G̲e̲n̲e̲r̲a̲l̲ ̲S̲e̲a̲r̲c̲h̲
Performs basic search functions.
4.1.1.8.1.4 M̲e̲m̲o̲r̲y̲ ̲T̲a̲b̲l̲e̲ ̲S̲e̲a̲r̲c̲h̲
A record in a table residing in memory is found and
compressed to the information wanted on output.
During the compression, the output is delivered in
the area specified by input parameters.
4.1.1.8.1.5 D̲i̲s̲k̲ ̲T̲a̲b̲l̲e̲ ̲S̲e̲a̲r̲c̲h̲
Performs search in disk resident tables.
4.1.1.8.1.6 S̲p̲e̲c̲i̲a̲l̲ ̲S̲e̲a̲r̲c̲h̲
Performs search requests not supported by the general
search functions.
4.1.1.8.2 T̲a̲b̲l̲e̲ ̲U̲p̲d̲a̲t̲e̲ ̲F̲u̲n̲c̲t̲i̲o̲n̲s̲
The table update functions will receive an update request,
perform it and return a response when the requested
function is completed.
By update request is meant:
- Table update request
- GSN indicator update
- Parameter update request
- Reorganize request
- Back-up/Reload request
- Table Lock/Unlock
4.1.1.8.2.1 U̲p̲d̲a̲t̲e̲ ̲C̲o̲m̲m̲u̲n̲i̲c̲a̲t̲i̲o̲n̲
This function receives an update request from a SyncEl
and passes it on to processing.
4.1.1.8.2.2 S̲e̲a̲r̲c̲h̲
This function uses the table search functions in such
a way so that the output is not only the record value,
but also its address.
For disk resident tables, the actual disk block will
be read into memory in the update functions working
area.
4.1.1.8.2.3 U̲p̲d̲a̲t̲e̲ ̲R̲e̲c̲o̲r̲d̲
One or more records are updated as specified.
If the update is a remove record or insert record current
table block may be reorganized.
4.1.1.8.2.4 U̲p̲d̲a̲t̲e̲ ̲D̲i̲s̲k̲
Diskversion of an updated table is updated in a way
so the table will always be recoverable.
4.1.1.8.2.5 S̲u̲p̲p̲o̲r̲t̲
This function may perform one of three independent
subfunctions. The three functions are:
- Reorganize
- Back-up
- Reload
4.1.1.8.2.6 S̲t̲a̲r̲t̲ ̲U̲p̲
TMP process is initialized and TMP data is reloaded
and read into memory.
4.1.1.8.3 T̲M̲P̲ ̲M̲o̲n̲i̲t̲o̲r̲
TMP monitor maintains communication between application
processes and the TMP process.
TMP monitor also performs simple accesses to TMP data
which do not require many resources.
4.1.1.8.3.1 P̲r̲o̲c̲e̲s̲s̲ ̲F̲u̲n̲c̲t̲i̲o̲n̲s̲
This module passes functions on to TMP Process.
For each function the corresponding parameters are
sent to the TMP process via a SYNCEL, an answer is
awaited and possible parameters are returned to the
calling application.
4.1.1.8.3.2 M̲o̲n̲i̲t̲o̲r̲ ̲F̲u̲n̲c̲t̲i̲o̲n̲s̲
This module consists of the functions related to Global
Serial numbers and system parameters, which require
fast access and therefore are performed by the monitor
itself.
4.1.1.8.3.3 M̲a̲i̲n̲ ̲F̲u̲n̲c̲t̲i̲o̲n̲s̲
This module consists of the functions used in System
Call Monitor interface.
4.1.2 T̲M̲P̲ ̲S̲o̲f̲t̲w̲a̲r̲e̲ ̲S̲t̲r̲u̲c̲t̲u̲r̲e̲
TMP Software consists of two parts.
First part is the TMP process performing the most TMP
processing such as sorting, searching, and updating.
All TMP disk accesses are made by this process.
Second part is the TMP Monitor which is a set of procedures
maintaining the interface between application processes
and TMP process.
These procedures also perform simple processing which
do not require many resources.
Fig. 4.1.2-1 shows the TMP software components and
environment.
4.1.2.1 T̲M̲P̲ ̲P̲r̲o̲c̲e̲s̲s̲
The TMP process consists of four coroutines.
The search communication coroutine handles the search
requests requiring no disk accesses and maintains read
of table attributes and TMP-STATISTICS.
The disk search coroutine handles the search requests
requiring one or more disk accesses.
The update communication coroutine handles the update
requests.
The support coroutine handles the reorganize and back
up/re-load requests and start up.
The requests are received from two SyncEls and answers
are directed to SynchEls associated to the requesting
modules.
The search coroutines have their own working area while
the update and support coroutines share one working
area. This means that support coroutine must go in
a waiting state when an update request is made. This
synchronization is managed by using semaphores.
4.1.2.2 T̲M̲P̲ ̲M̲o̲n̲i̲t̲o̲r̲
The TMP monitor is a set of procedures executed in
system mode by calling process.
4.1.2.3 C̲o̲r̲o̲u̲t̲i̲n̲e̲ ̲M̲o̲n̲i̲t̲o̲r̲
TMP uses the Coroutine Monitor for maintaining internal
task scheduling.
4.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̲
4.1.3.1 C̲o̲n̲t̲r̲o̲l̲ ̲L̲o̲g̲i̲c̲
Fig. 4.1.3.1-1 shows how TMP monitor is connected to
the application process by system call monitor.
The process communication sends the requests to SyncEls
and receives the associated answers from the answer
SyncEl by means of system call monitor.
System parameter and GSN management perform the processing
themselves and return the answer directly through system
call monitor.
During manipulation, the data being accessed can be
locked by means of a hardware semaphores.
Figure 4.1.3.1-2 shows how the control logic of TMP
process works.
A request is received from SEARCH-SYNCEL or UPDATE
̲SYNCEL.
The request may be processed by the coroutine having
received it or it may be passed on to another coroutine
via an OPERATION ̲SEMAPHORE.
The coroutine having processed a request sends response
to ANSWER ̲SYNCEL.
Support coroutine may request search by disk search
coroutine and receive response at SUPPORT ̲RS ̲SEM.
If search shall be stopped during an update, update
coroutine or support coroutine will wait for DISABLE
̲LOCK semaphore and then wait twice for DISABLE ̲SEM
before the update is performed.
Search is started again by signalling DISABLE ̲SEM twice,
and then signal DISABLE ̲LOCK semaphore.
Update coroutine and support coroutine shares working
area by waiting at BUFFER ̲SEM before they access the
common working area.
An abandon reorganize request may be sent to support
coroutine via BUFFER ̲SEM.
In addition to the here shown semaphores there exist
a POOL ̲SEM which holds all the free coroutine operation
of TMP.
When a COROUTINE shall use a TMP ̲OPERATION it will
wait for POOL ̲SEM.
When A COROUTINE will not use a TMP ̲OPERATION any longer
it signals it to POOL ̲SEM.
Fig. 4.1.3.1-1 TMP Monitor Control Logic
Fig. 4.1.3.1-2
4.1.4 T̲M̲P̲ ̲P̲a̲c̲k̲a̲g̲e̲ ̲D̲a̲t̲a̲
This section describes data which are used by more
than one subpackage.
4.1.4.1 T̲M̲P̲ ̲P̲a̲c̲k̲a̲g̲e̲ ̲T̲y̲p̲e̲s̲
Refer TMP.D*PRF.D*USERPRF which descripes the types
used by TMP process
and TMP.D*PRF.D*SYSTEMPRF wich descripes the types
used by both TMP process and TMP ̲MONITOR
4.1.4.2 T̲M̲P̲ ̲P̲a̲c̲k̲a̲g̲e̲ ̲V̲a̲r̲i̲a̲b̲l̲e̲s̲
Refer TMP.D*VAR.D*VAR.S
4.1.4.3 T̲M̲P̲ ̲P̲a̲c̲k̲a̲g̲e̲ ̲D̲i̲s̲k̲ ̲F̲i̲l̲e̲s̲
Refer (a)
4.1.4.4 T̲a̲b̲l̲e̲s̲
The tables are organized as directly organized tables
or sequentially organized tables. The sequentially
organized tables are supplied with index reference
and/or secondary search key reference as described.
The tables are stored at disk in TMP files cf. (a)
11
To meet the requirements to table search and table
update TMP must maintain the following physical tables.
4.1.4.4.1 R̲o̲u̲t̲i̲n̲g̲ ̲T̲a̲b̲l̲e̲s̲
The Routing Tables repides in the TMP file ROUTING
̲TABLES and includes following tables
- AIG table with memory index
- PLA table with memory index and secondary search
key PLA#
- RI table with memory index.
4.1.4.4.2 D̲i̲s̲t̲r̲i̲b̲u̲t̲i̲o̲n̲ ̲T̲a̲b̲l̲e̲s̲
The Distribution Tables resides in the TMP file DISTRIB
̲TABLES and includes following tables
- SIC table with memory index
- SCD table with memory index
- SDL table.
4.1.4.4.3 P̲r̲o̲f̲i̲l̲e̲ ̲T̲a̲b̲l̲e̲s̲
The Profile Tables resides in the TMP file PROFILE
̲TABLES and includes following tables
- PASSWORD table
- USER ̲PROFILE table with memory index.
4.1.4.4.4 M̲e̲m̲o̲r̲y̲ ̲T̲a̲b̲l̲e̲s̲
The Memory Tables resides in the TMP file MEMORY ̲SAVE
and in memory, and includes following tables
- TERMINAL table
- DEVICE table
- CHANNEL ̲PROFILE table
- ACP ̲127 ̲CHANNEL table
- CIRCUIT ̲CONECTIVITY table
- CIRCUIT ̲TABLE table
- LTUX ̲LINE table
- LTU ̲LINE table
- LTUX table
- LTU table
- BSM ̲X table
- PU table
- DISK table.
4.1.4.4.5 O̲t̲h̲e̲r̲ ̲T̲a̲b̲l̲e̲s̲
The Other Tables resides in the TMP file OTHER ̲TABLES
and include following tables
- SUPERVISOR ̲COMMAND table
- USER ̲COMMAND table with memory index
- MSO ̲COMMAND table with memory index
- MDCO ̲COMMAND table with memory index
- RESPONSE ̲TEXT table with memory index
- VUS ̲SEQUENCE table with memory index
- MSA ̲SEQUENCE table with memory index
- SVUP ̲SYSTEM ̲SEQUENCE table with memory index
- DISPLAY table with memory index
- MMI ̲CONTROL table with memory index
- OPERATING ̲SIGNAL table with memory index
- SPECIAL ̲HANDLING table
- PRINT ̲ACCOUNTING table.
4.1.4.5 S̲y̲s̲t̲e̲m̲ ̲P̲a̲r̲a̲m̲e̲t̲e̲r̲s̲
The system parameters are held in a set of variable
length records, each containing one parameter, the
internal structure of which is maintained by TMP.
For format of system parameters refer:
(a) 5.1
Each parameter is referenced by a system parameter
pointer contained in the parameter specifier array.
Each Element in the parameter specifier array contains
a pointer to actual system parameter and the length
of actual system parameter. See figure 4.1.4.5-1.
The elements in parameter specifier array are referenced
by PARAMETER ̲ID ̲TYPE refer (a) 5.1
VAR
PARAMETER ̲SPECIFIER ̲ARRAY:
ARRAY (PARAMETER ̲ID ̲TYPE)
OF PARAMETER ̲SPECIFIER ;
TYPE
PARAMETER ̲SPECIFIER =
RECORD
PARAMETER: POINTER LENGTH:
INTEGER
END;
I̲n̲i̲t̲i̲a̲l̲i̲z̲a̲t̲i̲o̲n̲
The structures are initialized as part of the TMP initialization.
Figure 4.1.4.5-1 System parameter referencing
4.1.4.6 G̲l̲o̲b̲a̲l̲ ̲S̲e̲r̲i̲a̲l̲ ̲N̲u̲m̲b̲e̲r̲
The Global serial numbers are held in the GSN array,
the internal structure of which is maintained by TMP.
VAR
GSN ̲ARRAY : ARRAY (1..MAX ̲GSN) OF GSN ̲ELEMENT;
TYPE
GSN ̲ELEMENT =
RECORD
THREE ̲DIGIT : BOOLEAN ;
DAILY ̲RESET : BOOLEAN ;
GSN : INTEGER ;
END;
For physical layout refer figure 4.1.4.6-1
The GSN ̲ARRAY is divided between groups of GSNs and
the start of each group is referenced in GSN group
array.
VAR
GSN ̲GROUP ̲ARRAY : (1..MAX ̲GSN ̲GROUPS) OF
BASIS ̲INDEX ;
BASIS ̲INDEX = 1..MAX ̲GSN
When using a GSN reference of type GSN ̲ID ̲TYPE (refer
(a) 5.4) a GSN is then referenced by adding the basis
index, identified by specified GSN ̲GROUP to the GSN
̲INDEX specified.
See figure 4.1.4.6-2
I̲n̲i̲t̲i̲a̲l̲i̲z̲a̲t̲i̲o̲n̲
The GSN ̲ARRAY and the GSN ̲GROUP ̲ARRAY are initialized
as part of TMP initialization.
Figure 4.1.4.6-1 Physical Layout of GSN
Figure 4.1.4.6-2 GSN referencing
4.1.5 T̲M̲P̲ ̲C̲o̲m̲m̲o̲n̲ ̲P̲a̲c̲k̲a̲g̲e̲ ̲P̲r̲o̲c̲e̲d̲u̲r̲e̲s̲
4.1.5.1 T̲M̲P̲ ̲R̲e̲t̲i̲r̲e̲
4.1.5.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̲
This procedure retires the TMP process and performs
required clean up.
4.1.5.1.2 I̲n̲t̲e̲r̲f̲a̲c̲e̲
C̲a̲l̲l̲ ̲S̲p̲e̲c̲i̲f̲i̲c̲a̲t̲i̲o̲n̲
a) TMP ̲RETIRE(TMP ̲CC : CC; SYSTEM ̲CC : CC) : OK
b) TMP ̲RETIRE (R5, R7, R6)
C̲a̲l̲l̲ ̲R̲e̲g̲i̲s̲t̲e̲r̲s̲
R5 TMP ̲CC (destr)
R7 SYSTEM ̲CC (destr)
R6 LINK (destr)
R̲e̲t̲u̲r̲n̲ ̲R̲e̲g̲i̲s̲t̲e̲r̲s̲
R0 - R4 (destr)
4.1.5.1.3 D̲a̲t̲a̲
N.A
4.1.5.1.4 T̲M̲P̲ ̲R̲e̲t̲i̲r̲e̲ ̲P̲r̲o̲c̲e̲d̲u̲r̲e̲ ̲D̲e̲s̲i̲g̲n̲
E̲x̲t̲e̲r̲n̲a̲l̲ ̲P̲r̲o̲c̲e̲d̲u̲r̲e̲s̲
RETIRE
N̲a̲r̲r̲a̲t̲i̲v̲e̲ ̲D̲e̲s̲c̲r̲i̲p̲t̲i̲o̲n̲
The DAMOS procedure RETIRE is called.
F̲l̲o̲w̲g̲r̲a̲m̲
N.A
4.1.5.2 M̲a̲p̲ ̲P̲a̲r̲a̲m̲s̲ ̲I̲n̲
4.1.5.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 procedure maps an application data segment into
TMP process.
It accesses data in a SUBPROCESS ̲DESCRIPTION in SUBPROCESS
̲ARRAY identified by TMP ̲COROUTINE ̲RECORD.INPUT%TMP
̲OPERATION.INFO.SUBPROCESS. The actual TMP ̲COROUTINE
̲RECORD is identified as a pointer at input.
The segment to be mapped in is identified by SUBPROCESS
̲DESCRIPTION.TMP ̲LOAD ̲INFO.DS ̲INIT ̲NO.
The segment is mapped in starting at the address specified
by TMP ̲COROUTINE ̲RECORD.MAP ̲PAGE.
TMP ̲COROUTINE ̲RECORD.ADDRESS ̲OFFSET is updated to the
value of (TMP ̲COROUTINE ̲RECORD.MAP ̲ADDRESS - SUBPROCESS
̲DESCRIPTION.OFFSET).
TMP ̲COROUTINE ̲RECORD.INPUT%TMP ̲OPERATION.INFO.PARAMS
is incrementet by TMP ̲COROUTINE ̲RACORD.MAP ̲ADDRESS.
Size of the data area starting at the address TMP ̲COROUTINE
̲RECORD.INPUT%TMP ̲OPERATION.INFO.PARAMS and ending at
application segment end, is determined and delivered
at output. If PARAMS is out of range ERROR ̲EXIT is
used.
TMP ̲COROUTINE ̲RECORD.MAX ̲ADDRESS is updated to MAP
̲ADDRESS + SUBPROCESS ̲DESCRIPTION.LOAD ̲INFO.DS ̲SIZE
of current subprocess.
If an error occur the TMP process is retired.
A special case is if SUBPROCESS specifies TMP itself
the PARAMS ̲SIZE is set to SIZE(TMP ̲PARAMS), TMP ̲COROUTINE
̲RECORD.ADDRESS ̲OFFSET is updated to zero and an OK
return is made without any further processing.
Note that this procedure contains a waiting point,
in the case that specified segment is already mapped
in.
4.1.5.2.2 I̲n̲t̲e̲r̲f̲a̲c̲e̲
C̲a̲l̲l̲ ̲S̲p̲e̲c̲i̲f̲i̲c̲a̲t̲i̲o̲n̲
a) MAP ̲PARAMS ̲IN(COREC:TMP ̲COROUTINE ̲RECORD)
(PARAMS ̲SIZE:INTEGER):ERROR ̲OK
b) MAP ̲PARAMS ̲IN (R0, R5, R6):ERROR ̲OK
R̲e̲g̲i̲s̲t̲e̲r̲ ̲C̲o̲n̲v̲e̲n̲t̲i̲o̲n̲s̲
C̲a̲l̲l̲ ̲R̲e̲g̲i̲s̲t̲e̲r̲s̲
R5 Pointer to TMP ̲COROUTINE ̲RECORD
(kept)
R6 LINK (destr)
R̲e̲t̲u̲r̲n̲ ̲R̲e̲g̲i̲s̲t̲e̲r̲s̲
R0 PARAMS ̲SIZE
R7 CC
R1 - R4 (kept)
F̲a̲t̲a̲l̲ ̲E̲r̲r̲o̲r̲s̲
None
4.1.5.2.3 D̲a̲t̲a̲
D̲a̲t̲a̲ ̲R̲e̲f̲e̲r̲e̲n̲c̲e̲s̲
TMP ̲COROUTINE ̲RECORD 4.1.4.1.17
SUBPROCESS ̲ARRAY 4.1.4.2.6
TMP ̲OPERATION 4.1.4
LAST ̲TMP VAR 4.1.4
E̲x̲t̲e̲r̲n̲a̲l̲ ̲D̲a̲t̲a̲
SUBPROCESS ̲ARRAY
LAST ̲TMP ̲VAR
L̲o̲c̲a̲l̲ ̲D̲a̲t̲a̲
N.A
4.1.5.2.4 M̲a̲p̲ ̲P̲a̲r̲a̲m̲s̲ ̲I̲n̲ ̲P̲r̲o̲c̲e̲d̲u̲r̲e̲ ̲D̲e̲s̲i̲g̲n̲
E̲x̲t̲e̲r̲n̲a̲l̲ ̲P̲r̲o̲c̲e̲d̲u̲r̲e̲s̲
MAP ̲IN ̲SEGMENT (g) 3.1.2.1.8
TMP ̲RETIRE cf 4.1.5.2
N̲a̲r̲r̲a̲t̲i̲v̲e̲ ̲D̲e̲s̲c̲r̲i̲p̲t̲i̲o̲n̲
N.A
F̲l̲o̲w̲g̲r̲a̲m̲
N.A
4.1.5.3 M̲a̲p̲ ̲P̲a̲r̲a̲m̲s̲ ̲O̲u̲t̲
4.1.5.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̲
This procedure reads subprocess ID in specified TMP
̲COROUTINE ̲RECORD.INPUT%TMP ̲OPERATION.INFO.SUBPROCESS.
If subprocess ID references TMP process itself nothing
is done. Otherwise the data segment associated to actual
subprocess is mapped out of the TNP process.
If an error occur when mapping the segment out, the
TMP process is retired.
4.1.5.3.2 I̲n̲t̲e̲r̲f̲a̲c̲e̲
C̲a̲l̲l̲ ̲S̲p̲e̲c̲i̲f̲i̲c̲a̲t̲i̲o̲n̲
a) MAP ̲PARAMS ̲OUT (COREC:TMP ̲COROUTINE ̲RECORD):OK
b) MAP ̲PARAMS ̲OUT (r5, R6):OK
R̲e̲g̲i̲s̲t̲e̲r̲ ̲C̲o̲n̲v̲e̲n̲t̲i̲o̲n̲s̲
C̲a̲l̲l̲ ̲R̲e̲g̲i̲s̲t̲e̲r̲s̲
R5 Pointer to TMP ̲COROUTINE ̲RECORD
(kept)
R6 LINK (destr)
R̲e̲t̲u̲r̲n̲ ̲R̲e̲g̲i̲s̲t̲e̲r̲s̲
R0 - R4, R7 (kept)
4.1.5.3.3 D̲a̲t̲a̲
R̲e̲f̲e̲r̲e̲n̲c̲e̲d̲ ̲D̲a̲t̲a̲
SUBPROCESS ̲ARRAY
TMP ̲COROUTINE ̲RECORD
E̲x̲t̲e̲r̲n̲a̲l̲ ̲D̲a̲t̲a̲
SUBPROCESS ̲ARRAY
L̲o̲c̲a̲l̲ ̲D̲a̲t̲a̲
None
4.1.5.3.4 M̲a̲p̲ ̲P̲a̲r̲a̲m̲s̲ ̲O̲u̲t̲ ̲P̲r̲o̲c̲e̲d̲u̲r̲e̲ ̲D̲e̲s̲i̲g̲n̲
E̲x̲t̲e̲r̲n̲a̲l̲ ̲P̲r̲o̲c̲e̲d̲u̲r̲e̲s̲
MAP ̲OUT ̲SEGMENT (g) 3.1.2.1.9
TMP ̲RETIRE cf 4.1.5.1
N̲a̲r̲r̲a̲t̲i̲v̲e̲ ̲D̲e̲s̲c̲r̲i̲p̲t̲i̲o̲n̲
N.A.
F̲l̲o̲w̲g̲r̲a̲m̲
N.A
4.1.5.4 C̲h̲e̲c̲k̲ ̲A̲d̲d̲r̲e̲s̲s̲
4.1.5.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̲
This procedure adds TMP ̲COROUTINE ̲RECORD.ADDRESS ̲OFFSET
from specified TMP ̲COROUTINE ̲RECORD to the APP ̲ADDRESS.
Then it is checked that the updated APP ̲ADDRESS is
inside the address area starting at TMP ̲COROUTINE ̲REVORD.MAP
̲ADDRESS and ending at TMP ̲COROUTINE ̲RECORD.MAX ̲ADDRESS
- MAP ̲ADDRESS.
If one of these checks fails ERROR ̲EXIT is used.
4.1.5.4.2 I̲n̲t̲e̲r̲f̲a̲c̲e̲
C̲a̲l̲l̲ ̲S̲p̲e̲c̲i̲f̲i̲c̲a̲t̲i̲o̲n̲
a) CHECK ̲ADDRESS - (SIZE:INTEGER,
APP ̲ADDRESS:POINTER
COREC:TMP ̲COROUTINE ̲RECORD
(APP ̲ADDRESS:POINTER):ERROR ̲OK
b) CHECK ̲ADDRESS (R0, R4, R5, R6):ERROR ̲OK
R̲e̲g̲i̲s̲t̲e̲r̲ ̲C̲o̲n̲v̲e̲n̲t̲i̲o̲n̲s̲
C̲a̲l̲l̲ ̲R̲e̲g̲i̲s̲t̲e̲r̲s̲
R0 SIZE (kept)
R4 Pointer to APP ̲ADDRESS (kept)
R5 Pointer to TMP ̲COROUTINE ̲
RECORD (kept)
R6 LINK (dest)
R̲e̲t̲u̲r̲n̲ ̲R̲e̲g̲i̲s̲t̲e̲r̲s̲
R4 Pointer to TMP ̲COROUTINE ̲RECORD
R1 - R3, R7 (kept)
4.1.5.4.3 D̲a̲t̲a̲
R̲e̲f̲e̲r̲e̲n̲c̲e̲d̲ ̲D̲a̲t̲a̲
TMP ̲COROUTINE ̲RECORD
E̲x̲t̲e̲r̲n̲a̲l̲ ̲D̲a̲t̲a̲
N.A
L̲o̲c̲a̲l̲ ̲D̲a̲t̲a̲
N.A
4.1.5.4.4 P̲r̲o̲c̲e̲d̲u̲r̲e̲ ̲D̲e̲s̲i̲g̲n̲
N.A
4.1.5.5 S̲e̲n̲d̲ ̲R̲e̲s̲p̲o̲n̲s̲e̲
4.1.5.5.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 procedure copies TMP ̲COROUTINE ̲RECORD.INPUT%T/MP
̲OPERATION.CC into TMP ̲COROUTINE ̲RECORD.INPUT.%TMP ̲OPERATION.RESPONSE
̲INFO.CC.
Note that this procedure uses the EQUIVALENCE (TMP
̲OPERATION.INFO, RESPONSE ̲INFO).
Then RESPONSE ̲INFO is sent to the ANSWER SYNCRONIZATION
ELEMENT associated to the subprocess specified by TMP
̲OPERATION.SUBPROCESS, and the TMP ̲OPERATION is returned
to POOL ̲SEM.
A special case is when subprocess references TMP process
itself then the TMP ̲OPERATION is sent to SUPORT ̲RS
̲SEM whitout copying the completion code.
4.1.5.5.2 I̲n̲t̲e̲r̲f̲a̲c̲e̲
C̲a̲l̲l̲ ̲S̲p̲e̲c̲i̲f̲i̲c̲a̲t̲i̲o̲n̲
a) SEND ̲RESPONSE(COREC:TMP ̲COROUTINE ̲RECORD): OK
b) SEND ̲RESPONSE(R5, R6):OK
R̲e̲g̲i̲s̲t̲e̲r̲ ̲C̲o̲n̲v̲e̲n̲t̲i̲o̲n̲s̲
C̲a̲l̲l̲ ̲R̲e̲g̲i̲s̲t̲e̲r̲s̲
R5 Pointer to TMP ̲COROUTINE ̲RECORD(kept)
R6 LINK (destr)
R̲e̲t̲u̲r̲n̲ ̲R̲e̲g̲i̲s̲t̲e̲r̲s̲
R0 - R4, R7 (destr)
4.1.5.5.3 D̲a̲t̲a̲
R̲e̲f̲e̲r̲e̲n̲c̲e̲d̲ ̲D̲a̲t̲a̲
TMP ̲OPERATION
TMP ̲COROUTINE ̲RECORD 4.1.4.17
SUBPROCESS ̲ARRAY 4.1.4.2.6
RESPONSE
E̲x̲t̲e̲r̲n̲a̲l̲ ̲D̲a̲t̲a̲
TMP ̲COROUTINE ̲RECORD.INPUT%TMP ̲OPERATION (M)
SUBPROCESS ̲ARRAY
L̲o̲c̲a̲l̲ ̲D̲a̲t̲a̲
TMP ̲COROUTINE ̲OPERATION.INFO is redefined so that its
type becomes RESPONSE ̲INFO.
4.1.5.5.4 S̲e̲n̲d̲ ̲R̲e̲s̲p̲o̲n̲s̲e̲ ̲P̲r̲o̲c̲e̲d̲u̲r̲e̲ ̲D̲e̲s̲i̲g̲n̲
E̲x̲t̲e̲r̲n̲a̲l̲ ̲P̲r̲o̲c̲e̲d̲u̲r̲e̲s̲
TMP ̲RETIRE CF 4.1.5.1
SEND (c) 4.1.6.2
SIGNAL ̲OP ̲SEM
N̲a̲r̲r̲a̲t̲i̲v̲e̲ ̲D̲e̲s̲c̲r̲i̲p̲t̲i̲o̲n̲
None
F̲l̲o̲w̲g̲r̲a̲m̲
N.A
4.1.5.6 M̲o̲d̲i̲f̲y̲ ̲R̲e̲c̲o̲r̲d̲
4.1.5.6.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 procedure modifies a RECORD ̲DESCRIPTION so that
all fields not specified by MODIFY ̲MASK are removed.
If MODIFY ̲MASK has all 16 bits set, INITIAL ̲FORMAT
is just copied into COMPRESSED ̲FORMAT as it is.
COMPRESSED ̲FORMAT must be a RECORD ̲DESCRIPTION of maximum
size, that means contain as many FIELD ̲DESCRIPTIONs
as defined in the largest RECORD known by TMP.
If CHECK is TRUE it is checked that the FIELD ̲DESCRIPTION.LENGT
fields included in COMPRESSED ̲FORMAT are identical.
Error EXIT is used if they a are not identical.
The FIELD ̲DESCRIPTIONs in COMPRESSED ̲FORMAT not used
will be undefined at return.
4.1.5.6.2 I̲n̲t̲e̲r̲f̲a̲c̲e̲
C̲a̲l̲l̲ ̲S̲p̲e̲c̲i̲f̲i̲c̲a̲t̲i̲o̲n̲
a) MODIFY ̲RECORD(MODIFY ̲MASK:BIT ̲MASK,
INITIAL ̲FORMAT:RECORD ̲DESCRIPTION
,
CHECK : BOOLEAN)
COMPRESSED ̲FORMAT:RECORD ̲DESCRIPTION):
ERROR ̲OK
b) MODIFY ̲RECORD (R1, R2, R3, R4, R6) : ERROR ̲OK
R̲e̲g̲i̲s̲t̲e̲r̲ ̲C̲o̲n̲v̲e̲n̲t̲i̲o̲n̲
C̲a̲l̲l̲ ̲R̲e̲g̲i̲s̲t̲e̲r̲s̲
R1 MODIFY ̲MASK (kept)
R2 CHECK (kept)
R3 Pointer to INITIAL ̲FORMAT (kept)
R4 Pointer to COMPRESSED ̲FORMAT (kept)
R6 LINK (kept)
R̲e̲t̲u̲r̲n̲ ̲R̲e̲g̲i̲s̲t̲e̲r̲s̲
R0, R5, R7 (kept)
4.1.5.6.3 D̲a̲t̲a̲
R̲e̲f̲e̲r̲e̲n̲c̲e̲d̲ ̲D̲a̲t̲a̲
RECORD ̲DESCRIPTION 4.1.4.1.6
FIELD ̲DESCRIPTION 4.1.4
BIT ̲MASK (a) 4.2
E̲x̲t̲e̲r̲n̲a̲l̲ ̲D̲a̲t̲a̲
N.A
L̲o̲c̲a̲l̲ ̲D̲a̲t̲a̲
N.A
4.1.5.6.4 I̲n̲s̲e̲r̲t̲ ̲P̲r̲o̲c̲e̲d̲u̲r̲e̲ ̲D̲e̲s̲i̲g̲n̲
E̲x̲t̲e̲r̲n̲a̲l̲ ̲P̲r̲o̲c̲e̲d̲u̲r̲e̲s̲
None
N̲a̲r̲r̲a̲t̲i̲v̲e̲ ̲D̲e̲s̲c̲r̲i̲p̲t̲i̲o̲n̲
For each bit set in MODIFY ̲MASK representing on excisting
field associated FIELD DESCRIPTION is included in new
RECORD ̲DESCRIPTION:
If CHECK is TRUE all LENGTH fields in FIELD ̲DESCRIPTION
must be identical. This is checked when the COMPRESED
format has been created.
F̲l̲o̲w̲g̲r̲a̲m̲
N.A
4.1.5.7 R̲e̲a̲d̲ ̲D̲i̲s̲k̲ ̲B̲l̲o̲c̲k̲
4.1.5.7.1 F̲u̲n̲c̲t̲i̲o̲n̲a̲l̲ ̲S̲p̲e̲c̲i̲f̲i̲c̲a̲t̲i̲o̲n̲
If specified block already is in specified buffer a
return is made without any processing.
Otherwise this procedure reads specified disk block
into specified buffer.
If specified buffer is the SEARCH ̲BUFFER, and the subprocess
in TMP ̲COROUTINE ̲RECORD.INPUT ̲%TMP OPERATION.INFO.SUBPROCESS
does not specify TMP process itself statistics of the
TABLE ̲DESCRIPTION referenced by TMP ̲COROUTINE ̲RECORD.TD
are updated.
4.1.5.7.2 I̲n̲t̲e̲r̲f̲a̲c̲e̲
C̲a̲l̲l̲ ̲S̲p̲e̲c̲i̲f̲i̲c̲a̲t̲i̲o̲n̲
a) READ ̲DISK ̲BLOCK (BLOCK:INTEGER,BUFFER:TMP ̲BUFFER,
COREC:TMP ̲COROUTINE ̲RECORD)
(BUFFER:TMP ̲BUFFER):OK
b) READ ̲DISK ̲BLOCK (R0, R4, R5, R6):OK
R̲e̲g̲i̲s̲t̲e̲r̲ ̲C̲o̲n̲v̲e̲n̲t̲i̲o̲n̲s̲
C̲a̲l̲l̲ ̲R̲e̲g̲i̲s̲t̲e̲r̲s̲
R0 BLOCK (kept)
R4 Pointer to TMP ̲BUFFER (kept)
R5 Pointer to TMP ̲COROUTINE ̲
RECORD (kept)
R6 LINK (dest)
R̲e̲t̲u̲r̲n̲ ̲R̲e̲g̲i̲s̲t̲e̲r̲s̲
R4 Pointer to TMP ̲BUFFER
R1 - R3, R7 (kept)
F̲a̲t̲a̲l̲ ̲E̲r̲r̲o̲r̲s̲
File Access Error
4.1.5.7.3 D̲a̲t̲a̲
R̲e̲f̲e̲r̲e̲n̲c̲e̲d̲ ̲D̲a̲t̲a̲
FILE ̲DESCRIPTION 4.1.4.1.1
TMP ̲BUFFER 4.1.4.1.1.18
TABLE ̲DESCRIPTION 4.1.4.12
TMP ̲BLOCK 4.1.4.14
E̲x̲t̲e̲r̲n̲a̲l̲ ̲D̲a̲t̲a̲
TABLE ̲DESCRIPTION
TABLE ̲DESCRIPTION.STATISTICS (M)
L̲o̲c̲a̲l̲ ̲D̲a̲t̲a̲
N.A
4.1.5.7.4 R̲e̲a̲d̲ ̲D̲i̲s̲k̲ ̲B̲l̲o̲c̲k̲ ̲P̲r̲o̲c̲e̲d̲u̲r̲e̲ ̲D̲e̲s̲i̲g̲n̲
E̲x̲t̲e̲r̲n̲a̲l̲ ̲P̲r̲o̲c̲e̲d̲u̲r̲e̲s̲
READ ̲BYTES
TMP ̲RETIRE
N̲a̲r̲r̲a̲t̲i̲v̲e̲ ̲D̲e̲s̲c̲r̲i̲p̲t̲i̲o̲n̲
N.A
F̲l̲o̲w̲g̲r̲a̲m̲
N.A
4.1.5.8 M̲o̲v̲e̲ ̲W̲o̲r̲d̲s̲
4.1.5.8.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 procedure copies COUNT words from the area specified
by INPUT to the area specified by OUTPUT.
4.1.5.8.2 I̲n̲t̲e̲r̲f̲a̲c̲e̲
C̲a̲l̲l̲ ̲S̲p̲e̲c̲i̲f̲i̲c̲a̲t̲i̲o̲n̲
a) MOVE ̲WORDS (COUNT:INTEGER
INPUT:ARRAY (1..COUNT OF INTEGER)
OUTPUT:ARRAY (1..COUNT) OF INTEGER)
:OK
b) MOVE ̲WORDS (R0, R1, R2, R6)
C̲a̲l̲l̲ ̲R̲e̲g̲i̲s̲t̲e̲r̲s̲
R0 COUNT (kept)
R1 Pointer to INPUT
R2 Pointer to OUTPUT
R6 LINK (destr)
R̲e̲t̲u̲r̲n̲ ̲R̲e̲g̲i̲s̲t̲e̲r̲s̲
R4, R5, R7 (kept)
4.1.5.8.3 D̲a̲t̲a̲
N.A
4.1.5.8.4 M̲o̲v̲e̲ ̲W̲o̲r̲d̲s̲ ̲P̲r̲o̲c̲e̲d̲u̲r̲e̲ ̲D̲e̲s̲i̲g̲n̲
E̲x̲t̲e̲r̲n̲a̲l̲ ̲P̲r̲o̲c̲e̲d̲u̲r̲e̲s̲
None
N̲a̲r̲r̲a̲t̲i̲v̲e̲ ̲D̲e̲s̲c̲r̲i̲p̲t̲i̲o̲n̲
Blocks of 16 words are moved until less than 16 words
are left, then the remaining words are moved and return
to calling module is made.
F̲l̲o̲w̲g̲r̲a̲m̲
N.A
4.1.5.9 I̲n̲s̲e̲r̲t̲
4.1.5.9.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 procedure inserts NEW ̲ELEM at the position specified
by PLACE. For a simple array the element itself is
inserted.
For an indirect array the pointer to NEW ̲ELEM is inserted.
4.1.5.9.2 I̲n̲t̲e̲r̲f̲a̲c̲e̲
C̲a̲l̲l̲ ̲S̲p̲e̲c̲i̲f̲i̲c̲a̲t̲i̲o̲n̲
a) INSERT (NEW ̲ELEM:RECORD, AD:ARRAY ̲DESCRIPTION,
PLACE:POINTER):OK
b) INSERT (R3, R4, R7, R6):OK
C̲a̲l̲l̲ ̲R̲e̲g̲i̲s̲t̲e̲r̲s̲
R3 Pointer to NEW ̲ELEM (kept)
R4 Pointer to ARRAY ̲DESCRIPTION (kept)
R7 PLACE specifies the address where
NEW ̲ELEM shall be inserted (kept)
R6 LINK
R̲e̲t̲u̲r̲n̲ ̲R̲e̲g̲i̲s̲t̲e̲r̲
R0 - R2, R5 (kept)
4.1.5.9.3 D̲a̲t̲a̲
R̲e̲f̲e̲r̲e̲n̲c̲e̲d̲ ̲D̲a̲t̲a̲
ARRAY ̲DESCRIPTION
E̲x̲t̲e̲r̲n̲a̲l̲ ̲D̲a̲t̲a̲
N.A
L̲o̲c̲a̲l̲ ̲D̲a̲t̲a̲
N.A.
4.1.5.9.4 I̲n̲s̲e̲r̲t̲ ̲P̲r̲o̲c̲e̲d̲u̲r̲e̲ ̲D̲e̲s̲i̲g̲n̲
E̲x̲t̲e̲r̲n̲a̲l̲ ̲P̲r̲o̲c̲e̲d̲u̲r̲e̲s̲
MOVE ̲WORDS cf 4.1.5.8
N̲a̲r̲r̲a̲t̲i̲v̲e̲ ̲D̲e̲s̲c̲r̲i̲p̲t̲i̲o̲n̲
a) F̲o̲r̲ ̲S̲i̲m̲p̲l̲e̲ ̲A̲r̲r̲a̲y̲
All elements located after PLACE are moved SIZE
(NEW ̲ELEM) up in address area.
Then NEW ̲ELEM is written, starting at the address
specified by PLACE.
F̲l̲o̲w̲g̲r̲a̲m̲
N.A
4.1.5.10 C̲o̲m̲p̲a̲r̲e̲ ̲L̲o̲n̲g̲
4.1.5.10.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 procedure compares two operands of type LONG and
the exit value specifies result of the comparison.
The exit value will be one of following:
- LOWER whitch means that OP1 has a lower value than
OP2.
- SAME whitch means that OP1 has same value as OP2.
- HIGHER which means that OP1 has a higher value
than OP2.
4.1.5.10.2 I̲n̲t̲e̲r̲f̲a̲c̲e̲
C̲a̲l̲l̲ ̲S̲p̲e̲c̲i̲f̲i̲c̲a̲t̲i̲o̲n̲
a) COMPARE ̲LONG(OP1:POINTER, OP2:POINTER):
COMPARE ̲RESULT
b) COMPARE ̲LONG (R4, R7, R6):COMPARE ̲RESULT
C̲a̲l̲l̲ ̲R̲e̲g̲i̲s̲t̲e̲r̲s̲
R4 Pointer to OP1 (kept)
R7 Pointer to OP2 (kept)
R6 LINK (dest)
R̲e̲t̲u̲r̲n̲ ̲R̲e̲g̲i̲s̲t̲e̲r̲s̲
R0 - R3, R5 (kept)
4.1.5.10.3 D̲a̲t̲a̲
E̲x̲t̲e̲r̲n̲a̲l̲ ̲D̲a̲t̲a̲
N.A
L̲o̲c̲a̲l̲ ̲D̲a̲t̲a̲
N.A
4.1.5.10.4 C̲o̲m̲p̲a̲r̲e̲ ̲L̲o̲n̲g̲ ̲P̲r̲o̲c̲e̲d̲u̲r̲e̲ ̲D̲e̲s̲i̲g̲n̲
E̲x̲t̲e̲r̲n̲a̲l̲ ̲P̲r̲o̲c̲e̲d̲u̲r̲e̲
None
N̲a̲r̲r̲a̲t̲i̲v̲e̲ ̲D̲e̲s̲c̲r̲i̲p̲t̲i̲o̲n̲
N.A
F̲l̲o̲w̲g̲r̲a̲m̲
N.A
4.1.6 C̲o̲m̲m̲o̲n̲ ̲D̲a̲t̲a̲
TMP Global types are split into groups in accordance
to the data they are related to.
The groups are:
- General refer (a) 4.5.4
- Table Related Types refer (a) 4.5.3
- System Parameter Related Types refer (a) 4.5.1
- Global Serial Number Related Types refer (a) 4.5.2
4.1.7 T̲M̲P̲ ̲I̲n̲t̲e̲r̲f̲a̲c̲e̲s̲
Application packages interface to TMP by requesting
a function and later on receiving an answer.
4.1.7.1 E̲x̲t̲e̲r̲n̲a̲l̲ ̲I̲n̲t̲e̲r̲f̲a̲c̲e̲s̲
NA.
4.1.7.2 P̲a̲c̲k̲a̲g̲e̲ ̲I̲n̲t̲e̲r̲f̲a̲c̲e̲
Application packages have the following interfaces:
- Request (b) 4.1.1
- Get TMP Statistics (b) 4.1.2
- Get Table Attributes (b) 4.1.3
- Lock Table (b) 4.1.4
- Unlock Table (b) 4.1.5
- Reorganize (b) 4.1.6
- Abandon Reorganize (b) 4.1.7
- Backup (b) 4.1.8
- System Start Up (b) 4.1.9
- Set Global Serial Number (b) 4.1.10
- Daily Global Serial
Number Reset (b) 4.1.11
- Set Global Serial Number (b) 4.1.12
- Set Global Serial Number
Flags (b) 4.1.13
- Set System Parameters (b) 4.1.14
- Get System Parameters (b) 4.1.15
The data types used in the package Interface specification
are defined in section 4.1.6.
CSF has via System Call monitor the following interfaces:
- TMP init
- TMP answer received
- TMP cancel
- TMP complete
refer 4.2.3.4.3.2.
4.1.7.3 S̲u̲b̲p̲a̲c̲k̲a̲g̲e̲ ̲I̲n̲t̲e̲r̲f̲a̲c̲e̲
The TMP Monitor sends function requests to search and
update subpackages.
Search and update subpackages request TMP monitor to
return output to the calling process.
The update subpackage requests search functions from
the search subpackage and the search subpackage sends
the output back to update subpackage.
The update subpackage executes some of the search subpackages
procedures and will, after execution, have determined
the output itself.
Refer figure 4.1.7.3-1.
Figure 4.1.7.3-1 Subpackage Interface
4.2 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 S̲e̲a̲r̲c̲h̲ ̲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.1 F̲u̲n̲c̲t̲i̲o̲n̲a̲l̲ ̲S̲p̲e̲c̲i̲f̲i̲c̲a̲t̲i̲o̲n̲
In the following the functions of each module are identified.
4.2.1.1.1 S̲e̲a̲r̲c̲h̲ ̲C̲o̲m̲m̲u̲n̲i̲c̲a̲t̲i̲o̲n̲
Search Communication has the following functions:
- Receive Requests
- Get Table Attributes
- Get TMP Statistics
- Invocate Search
4.2.1.1.2 S̲o̲r̲t̲ ̲K̲e̲y̲s̲
Sort Keys module have following functions:
- Sort Primary Keys
- Check Input Parameters
4.2.1.1.3 G̲e̲n̲e̲r̲a̲l̲ ̲S̲e̲a̲r̲c̲h̲
General Search module has following functions:
- Search Secondary Key
- Search Primary Key In Memory Table
- Binary Search In Array
- Search In One Table Record
4.2.1.1.4 M̲e̲m̲o̲r̲y̲ ̲S̲e̲a̲r̲c̲h̲
Memory Search module performs search in memory tables
4.2.1.1.5 D̲i̲s̲k̲ ̲S̲e̲a̲r̲c̲h̲
Disk Search module performs search in disk tables
4.2.1.1.6 S̲p̲e̲c̲i̲a̲l̲ ̲S̲e̲a̲r̲c̲h̲
Special Search module performs search in SIC ̲SCD table
4.2.1.2 S̲e̲a̲r̲c̲h̲ ̲S̲u̲b̲p̲a̲c̲k̲a̲g̲e̲ ̲S̲o̲f̲t̲w̲a̲r̲e̲ ̲S̲t̲r̲u̲c̲t̲u̲r̲e̲
In the following the software components of each module
are identified.
Figure 4.2.1.2-1 shows a hierarchical overview of the
software structure.
4.2.1.2.1 S̲e̲a̲r̲c̲h̲ ̲C̲o̲m̲m̲u̲n̲i̲c̲a̲t̲i̲o̲n̲
Search Communication module consists of the coroutine
SEARCH ̲COMMUNICATION
4.2.1.2.2 S̲o̲r̲t̲ ̲K̲e̲y̲s̲
Sort Keys module consists of the three procedures:
- SORT ̲KEYS
- SORT
- CHECK ̲ARRAY
4.2.1.2.3 G̲e̲n̲e̲r̲a̲l̲ ̲S̲e̲a̲r̲c̲h̲
General Search module consists of five procedures:
- FIND ̲SECONDARY
- FIND ̲KEY
- BINARY ̲SEARCH
- COMPARE
4.2.1.2.4 M̲e̲m̲o̲r̲y̲ ̲S̲e̲a̲r̲c̲h̲
Memory Search module consists of the procedure MEMORY
̲SEARCH
4.2.1.2.5 D̲i̲s̲k̲ ̲S̲e̲a̲r̲c̲h̲
Disk Search module consists of one coroutine:
- DISK ̲SEARCH
and two procedure :
- DISK ̲PRIMARY
- FIND ̲DISK ̲KEY
4.2.1.2.6 S̲p̲e̲c̲i̲a̲l̲ ̲S̲e̲a̲r̲c̲h̲
Special Search module consists of two procedures:
- SPECIAL ̲SEARCH
- SIC ̲SCD ̲SEARCH
4.2.1.2.7 C̲o̲m̲m̲o̲n̲ ̲S̲u̲b̲p̲a̲c̲k̲a̲g̲e̲ ̲P̲r̲o̲c̲e̲d̲u̲r̲e̲s̲
The Common Subpackage procedures are:
- COMPARE ̲FIELDS
- DELIVER ̲OUTPUT
Figure 4.2.1.2-1 Software Structure
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̲
Figure 4.2.1.3-1 shows the control logic of search
subpackage.
A request is received from SEARCH ̲SYNCEL.
It is performed by SEARCH ̲COMMUNICATION possible by
means of MEMORY ̲SEARCH and response is sent to ANSWER
̲SYNCEL. Or it is sent to DISK ̲SEARCH ̲SEM in an OPERATION
received from POOL ̲SEM.
DISK ̲SEARCH receives a request from DISK ̲SEARCH ̲SEM,
performs a disk search possible by means of SPECIAL
̲SEARCH. Response is sent to SUPPORT ̲RQ ̲SEM or ANSWER
̲SYNCEL.
Used OPERATIONS are returned to POOL ̲SEM.
Before DISK ̲SEARCH or SEARCH ̲COMMUNICATION awaits a
new request they will wait for DISABLE ̲SEM and when
response is sent DISABLE ̲SEM is signalled.
Figure 4.2.1.3-1 Control Logic
4.2.1.4 S̲e̲a̲r̲c̲h̲ ̲S̲u̲b̲p̲a̲c̲k̲a̲g̲e̲ ̲M̲o̲d̲u̲l̲e̲ ̲S̲p̲e̲c̲i̲f̲i̲c̲a̲t̲i̲o̲n̲
4.2.1.4.1 S̲e̲a̲r̲c̲h̲ ̲C̲o̲m̲m̲u̲n̲i̲c̲a̲t̲i̲o̲n̲ ̲M̲o̲d̲u̲l̲e̲ ̲S̲p̲e̲c̲i̲f̲i̲c̲a̲t̲i̲o̲n̲
4.2.1.4.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̲
This procedure is the body of the SEARCH ̲COMMUNICATION
coroutine it receives all search functions and perform
delivery of table atributes and TMP statistics.
If the request is not a disk search request, this module
returns the response to requesting application when
function is completed.
If the request is a search request the search request
statistics are updated.
4.2.1.4.1.2 S̲e̲a̲r̲c̲h̲ ̲C̲o̲m̲m̲u̲n̲i̲c̲a̲t̲i̲o̲n̲ ̲M̲o̲d̲u̲l̲e̲ ̲I̲n̲t̲e̲r̲f̲a̲c̲e̲
a) R̲e̲c̲e̲i̲v̲e̲ ̲R̲e̲q̲u̲e̲s̲t̲
Requests are received from TMP Monitor via SEARCH
̲SYNCEL cf. 4.2.3.7.1.
b) R̲e̲t̲u̲r̲n̲ ̲R̲e̲s̲p̲o̲n̲s̲e̲
Responses are returned to TMP Monitor via Synchronization
Elements cf. 4.2.3.7.2
c) I̲n̲v̲o̲c̲a̲t̲e̲ ̲M̲e̲m̲o̲r̲y̲ ̲S̲e̲a̲r̲c̲h̲
The procedure MEMORY ̲SEARCH is called cf. 4.2.1.4.4.2.
d) P̲a̲s̲s̲ ̲O̲n̲ ̲D̲i̲s̲k̲ ̲S̲e̲a̲r̲c̲h̲
Disk search requests are passed on to DISK ̲SEARCH
coroutine by sending a copy of received Info Block
to DISK ̲SEARCH ̲SEM OPERATION ̲SEMAPHORE.
4.2.1.4.1.3 S̲e̲a̲r̲c̲h̲ ̲C̲o̲m̲m̲u̲n̲i̲c̲a̲t̲i̲o̲n̲ ̲M̲o̲d̲u̲l̲e̲ ̲C̲o̲m̲p̲o̲n̲e̲n̲t̲s̲
This module consists of the coroutine SEARCH ̲COMMUNICATION.
4.2.1.4.1.4 S̲e̲a̲r̲c̲h̲ ̲C̲o̲m̲m̲u̲n̲i̲c̲a̲t̲i̲o̲n̲ ̲M̲o̲d̲u̲l̲e̲ ̲D̲a̲t̲a̲
a) D̲a̲t̲a̲ ̲R̲e̲f̲e̲r̲e̲n̲c̲e̲s̲
TMP ̲COROUTINE ̲RECORD 4.1.4.1
TABLE ̲DESCRIPTION ̲ARRAY 4.1.4.2
TMP ̲OPERATION 4.1.4.1
DISABLE ̲SEM 4.1.4.2
POOL ̲SEM 4.1.4.2
DISK ̲SEARCH ̲SEM 4.1.4.2
SUBPROCESS ̲ARRAY 4.1.4.2
GET ̲TMP ̲STATISTICS ̲INFO 4.2.3.7.1
GET ̲TABLE ̲ATTRIBUTES ̲INFO 4.2.3.7.1
NORMAL ̲RESPONSE 4.2.3.7.2
GET ̲TMP ̲STATISTICS ̲RESPONSE 4.2.3.7.2
b) E̲x̲t̲e̲r̲n̲a̲l̲ ̲D̲a̲t̲a̲
TABLE ̲DESCRIPTION ̲ARRAY (M)
DISABLE ̲SEM (M)
DISK ̲SEARCH ̲SEM (M)
POOL ̲SEM (M)
SUBPROCESS ̲ARRAY
c) L̲o̲c̲a̲l̲ ̲D̲a̲t̲a̲
None
4.2.1.4.1.5 S̲e̲a̲r̲c̲h̲ ̲C̲o̲m̲m̲u̲n̲i̲c̲a̲t̲i̲o̲n̲ ̲M̲o̲d̲u̲l̲e̲ ̲D̲e̲s̲i̲g̲n̲
E̲x̲t̲e̲r̲n̲a̲l̲ ̲P̲r̲o̲c̲e̲d̲u̲r̲e̲s̲
AWAIT ̲SYNCEL (b) 3.2.6.7
AP ̲PARAMS ̲IN cf. 4.1.5.2
MAP ̲PARAMS ̲OUT cf. 4.1.5.3
SIGNAL ̲SEM (b) 3.2.5.6
SEND ̲RESPONSE cf. 4.1.5.5
WAIT ̲OPSEM (b) 3.2.5.7
SIGNAL ̲OPSEM (b) 3.2.5.8
MEMORY ̲SEARCH cf 4.2.1.4.4.2
N̲a̲r̲r̲a̲t̲i̲v̲e̲ ̲D̲e̲s̲c̲r̲i̲p̲t̲i̲o̲n̲
The two functions GET ̲TMP ̲STATISTICS and GET ̲TABLE
̲
ATTRIBUTES are performed by this procedure itself while
SEARCH ̲REQUESTS are passed on to other modules.
Memory search requests are performed by invocating
the procedure MEMORY ̲SEARCH.
Disk search requests are send to DISK ̲SEARCH ̲SEM in
a TMP ̲OPERATION.
F̲l̲o̲w̲g̲r̲a̲m̲
Cf. figure 4.2.1.4.1.5 - (1 to 4)
COROUTINE SEARCH ̲COMMUNICATION
I̲N̲I̲T̲I̲A̲L̲I̲Z̲E̲ ̲D̲A̲T̲A̲
I̲N̲I̲T̲I̲A̲L̲I̲Z̲E̲ ̲P̲C̲F̲ ̲S̲E̲R̲V̲I̲C̲E̲ ̲S̲Y̲S̲T̲E̲M̲
EQUIVALENCE(RUNNING ̲COROUTINE, C: TMP ̲COROUTINE ̲RECORD)
VALIDATE TABLE ̲ID
FOREVER LOOP
WAIT ̲OPSEM (POOL ̲SEM)
AWAIT ̲SYNCEL(SEARCH ̲SYNCEL)(C.INPUT, COUNT,CC):
OK
WAIT ̲SEM (DISABLE ̲SEM)
CASE C.INPUT.FUNCTION
- GET ̲TABLE ̲ATTRIBUTES? D̲E̲L̲I̲V̲E̲R̲ ̲
A̲T̲T̲R̲I̲B̲U̲T̲E̲S̲
of fig 4.2.1.4.1.5-2
- GET ̲TMP ̲STATISTICS? D̲E̲L̲I̲V̲E̲R̲ ̲
S̲T̲A̲T̲I̲S̲T̲I̲C̲S̲
of fig 4.2.1.4.1.5-3
- OTHERWISE? S̲E̲L̲E̲C̲T̲ ̲S̲E̲A̲R̲C̲H̲
of fig 4.2.1.4.1.5-4
END CASE C.INPUT.FUNCTION
SIGNAL ̲SEM(DISABLE ̲SEM)
END FOREVER LOOP
Figure 4.2.1.4.1.5-1
DELIVER ATTRIBUTES
CASE MAP ̲PARAMS ̲IN: ERROR ̲OK
- ERROR? - C.RESPONSE.CC=PARAMETER ̲ADDRESS ̲ERROR
End case MAP ̲PARAMS ̲IN
Check ̲Output ̲Buffer ̲Length
Copy ̲Attributes ̲to ̲callers ̲area
MAP ̲PARAMS ̲OUT
SEND.RESPONSE
Stop
Figure 4.2.1.4.1.5-2
D̲e̲l̲i̲v̲e̲r̲ ̲S̲t̲a̲t̲i̲s̲t̲i̲c̲s̲
Case MAP ̲PARAMS ̲IN: ERROR ̲OK:
- ERROR? - C.RESPONSE.CC=PARAMETER ̲ADDRESS ̲ERROR
End case MAP ̲PARAMS ̲IN
Check output buffer length
WHILE ̲C.COUNT LOOP
C.COUNT EQ 0 EXIT
Copy TABLE ̲DESCRIPTION ̲ARRAY(TABLE ̲ID).STATISTICS
to callers area
Reset Statistics Counters
DECREMENT C.COUNT
INCREMENT TABLE ̲ID
End WHILE ̲C.COUNT LOOP
MAP ̲PARAMS ̲OUT
SEND RESPONSE
Figure 4.2.1.4.1.5-3
S̲e̲l̲e̲c̲t̲ ̲S̲e̲a̲r̲c̲h̲
Update TMP statistics
WAIT ̲OPSEM (POOL ̲SEM)(REQUEST ̲OPERATION)
Copy TMP ̲REQUEST record into
REQUEST ̲OPERATION.DATA
Table Type EQ Memory Table? - MEMORY ̲SEARCH
SIGNAL ̲OPSEM(DISK ̲SEARCH ̲SEM,REQUEST ̲OPERATION)
Stop
Figure 4.2.1.4.1.5-4
4.2.1.4.2 S̲o̲r̲t̲ ̲K̲e̲y̲s̲ ̲M̲o̲d̲u̲l̲e̲ ̲S̲p̲e̲c̲i̲f̲i̲c̲a̲t̲i̲o̲n̲
4.2.1.4.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̲
a) S̲o̲r̲t̲ ̲K̲e̲y̲s̲
This procedure checks the input parameters specified
by one searchrequest.
If an illegal parameter is detected TMP ̲OPERATION.CC
is updated to the completion code describing actual
parameter error, and error exit is made.
If all parameters are accepted okay exit is made.
b) S̲o̲r̲t̲
This procedure sorts the records descriped by ARRAY
̲DESCRIPTION in accordance to their key values,
the key being used by sorting is described by KEY
̲DESCRIPTION.
Elements in a SIMPLE ARRAY must not have size greater
than MAX ̲ELEM ̲SIZE.
4.2.1.4.2.2 S̲o̲r̲t̲ ̲K̲e̲y̲s̲ ̲M̲o̲d̲u̲l̲e̲ ̲I̲n̲t̲e̲r̲f̲a̲c̲e̲
a) S̲o̲r̲t̲ ̲K̲e̲y̲
C̲a̲l̲l̲ ̲S̲p̲e̲c̲i̲f̲i̲c̲a̲t̲i̲o̲n̲
SORT ̲KEY
(R4 ; " c k Pointer to TMP ̲OPERATION
R5 ; " c k Pointer to TMP ̲COROUTINERECORD
R6 ; " c d LINK
ERROR ̲OK ;
R0 - R3 -d
R7 -d
b) S̲o̲r̲t̲
C̲a̲l̲l̲ ̲S̲p̲e̲c̲i̲f̲i̲c̲a̲t̲i̲o̲n̲
SORT
(R4 ; " c k Pointer to ARRAY ̲DESCRIPTION
R5 ; " c k Pointer to KEY ̲DESCRIPTION
R6); " c d LINK
R7 -d
4.2.1.4.2.3 S̲o̲r̲t̲ ̲K̲e̲y̲s̲ ̲M̲o̲d̲u̲l̲e̲ ̲C̲o̲m̲p̲o̲n̲e̲n̲t̲s̲
This module consists of seven procedures
- SORT ̲KEYS
- SORT
- CHECK ̲ARRAY
This procedure checks that SINGLE ̲KEY.INFO is 0
and SINGLE ̲KEY.LINK is NIL in the KEY ̲LIST specified
by BUFFER1.
If all checks is OK,OKAY exit is used, otherwise
ERROR exit is used.
- PRIMARY ̲CHECK
This procedure checks the input parameters used
by a primary key search.
If an illegal parameter is detected TMP ̲OPERATION.CC
is updated to the completion code describing actual
parameter error.
If just one illegal parameter has been detected
a return is made without further checks.
- NEXT ̲PRIMARY ̲CHECK
This procedure checks the input parameters used
when searching for next primary key.
If an illegal parameter is detected TMP ̲OPERATION.CC
is updated to the completion code describing actual
parameter error.
If just one illegal parameter has been detected
a return is made without further checks.
- IN ̲RECORD ̲CHECK
This procedure checks the input parameters used
by searching secondary keys in one record.
If an illegal parameter is detected TMP ̲OPERATION.CC
is updated to the completion code describing actual
parameter error.
If just one illegal parameter has been detected
a return is made without further checks.
- SECONDARY ̲CHECK
This procedure checks the input parameters used
by searching secondary keys in a table.
If an illegal parameter is detected TMP ̲OPERATION.CC
is updated to the completion code describing actual
parameter error.
If just one illegal parameter has been detected
a return is made without further checks.
4.2.1.4.2.4 S̲o̲r̲t̲ ̲K̲e̲y̲s̲ ̲M̲o̲d̲u̲l̲e̲ ̲D̲a̲t̲a̲
TMP ̲COROUTINE ̲RECORD cf.4.1.4.1.17
KEY ̲DESCRIPTION cf.4.1.4.1.9
ARRAY ̲DESCRIPTION cf.4.1.4.1.8
E̲x̲t̲e̲r̲n̲a̲l̲ ̲D̲a̲t̲a̲
TMP ̲COROUTINE ̲RECORD (M)
L̲o̲c̲a̲l̲ ̲D̲a̲t̲a̲
a) S̲o̲r̲t̲ ̲A̲r̲r̲a̲y̲ ̲D̲e̲s̲c̲r̲i̲p̲t̲i̲o̲n̲
Used to describe the sorted part of the
ARRAY
VAR
SORT ̲ARRAY: ARRAY ̲DESCRIPTION;
b) A̲c̲t̲u̲a̲l̲ ̲E̲l̲e̲m̲e̲n̲t̲ ̲P̲o̲i̲n̲t̲e̲r̲
Used to point at the element to be sorted
VAR
ACTUAL ̲ELEMENT: POINTER;
c) S̲a̲v̲e̲ ̲E̲l̲e̲m̲e̲n̲t̲
Save area to hold the element to be inserted in
sorted ARRAY
VAR
SAVE ̲ELEMENT: ARRAY (1..MAX ̲KEY ̲LENGTH) OF INTEGER;
d) M̲a̲x̲i̲m̲u̲m̲ ̲E̲l̲e̲m̲e̲n̲t̲ ̲S̲i̲z̲e̲
Defines maximum number of words to be sorted
CONST MAX ̲ELEM ̲SIZE=5;
4.2.1.4.2.5 S̲o̲r̲t̲ ̲K̲e̲y̲s̲ ̲M̲o̲d̲u̲l̲e̲ ̲D̲e̲s̲i̲g̲n̲
E̲x̲t̲e̲r̲n̲a̲l̲ ̲P̲r̲o̲c̲e̲d̲u̲r̲e̲s̲
BINARY ̲SEARCH cf. 4.2.1.4.3
MODIFY ̲RECORD cf. 4.1.5.1
CHECK ̲ADDRESSES cf. 4.1.5.4
INSERT cf. 4.1.5.6
a) S̲o̲r̲t̲ ̲K̲e̲y̲s̲
N̲a̲r̲r̲a̲t̲i̲v̲e̲ ̲D̲e̲s̲c̲r̲i̲p̲t̲i̲o̲n̲
This procedure contains the high level logic of
Sort Keys module. The low level logic is in the
invocated procedures.
For each SINGLE ̲KEY the checks are performed by
comparing register R6 to INFO and R1 to LINK, R6
is initialized to 0 and R1 to NIL.
F̲l̲o̲w̲g̲r̲a̲m̲
4.2.1.4.2.5-1
b) S̲o̲r̲t̲
N̲a̲r̲r̲a̲t̲i̲v̲e̲ ̲D̲e̲s̲c̲r̲i̲p̲t̲i̲o̲n̲
This procedure sorts one element after another
into a sorted ARRAY.
F̲l̲o̲w̲g̲r̲a̲m̲
Cf. figure 4.2.1.4.2.5-2
Procedure SORT ̲KEYS()(SORTED ̲ARRAY,CC): ERROR ̲OK
EQUIVALENCE(RUNNING ̲COROUTINE, C: TMP ̲COROUTINE ̲RECORD)
TD = TD ARRAY (TABLE ̲ID)
MODIFY WRITE FORMAT
Case C.INPUT.FUNCTION
- SEARCH ̲PRIMARY ̲KEY? P̲r̲i̲m̲a̲r̲y̲ ̲C̲h̲e̲c̲k̲
- SEARCH ̲NEXT ̲PRIMARY ̲KEY? N̲e̲x̲t̲ ̲P̲r̲i̲m̲a̲r̲y̲ ̲C̲h̲e̲c̲k̲
- SEARCH ̲IN ̲RECORD? I̲n̲ ̲R̲e̲c̲o̲r̲d̲ ̲C̲h̲e̲c̲k̲
- OTHERWISE? S̲e̲c̲o̲n̲d̲a̲r̲y̲ ̲C̲h̲e̲c̲k̲
End case C.INPUT.FUNCTION
check Table Search Access
CC NE OK? EXIT = ERROR
EXIT = OK
Stop
Figure 4.2.1.4.2.5-1
Procedure SORT: OK
SORT ̲ARRAY.START = ELEMENTS.START
SORT ̲ARRAY.SIZE = ELEMENTS.SIZE
SORT ̲ARRAY.COUNT = 1
SORT ̲ARRAY.ARRAY ̲TYPE = ELEMENTS.ARRAY ̲TYPE
N = ELEMENTS.COUNT
P = 2
OFFSET = SORT ̲KEY.OFFSET
SORTING loop
P GT N EXIT
ELEMENTS.ARRAY ̲TYPE EQ INDIRECT?
PO = ADDRESSS(ELEMENTS(P)) PO = ELEMENTS (P)
SORT ̲KEY.KEY = PO + OFFSET
Case BINARY ̲SEARCH (SORT ̲KEY, SORT ̲ARRAY)
(PLACE): ERROR ̲OK:
- ERROR?
- OK?
End case BINARY ̲SEARCH
SAVE ̲ELEMENT = ELEMENTS (P)
SORT ̲ARRAY.COUNT = P
INSERT (SAVE ̲AREA, SORT ̲ARRAY, PLACE): OK
INCREMENT P
End SORTING Loop
ELEMENTS = SORT ̲ARRAY
Stop
Figure 4.2.1.4.2.5-2
