top - download
⟦44654ad83⟧ Wang Wps File
Length: 34766 (0x87ce)
Types: Wang Wps File
Notes: Spelunked
Names: »~ORPHAN26.04«
Derivation
└─⟦507b19fd6⟧ Bits:30006135 8" Wang WCS floppy, CR 0282A
└─ ⟦this⟧ »~ORPHAN26.04«
WangText
eferring a local terminal
give the retrieval right to this terminal.
The MRF record for the message is formed of the ex-
tracted information together with the MTF address of
the firs sector of the message, the retrieval time
and the messag length from the MTCB
The in-memory subset of the MRF(which is a part of the critical region SRS ̲CR) is
updated with the record. If the in-memory subset of the MRF hereby gets full, a transfer
to the MRF is performed. (The storage process
awaittermination). (fig. 3.1-3).…86…W …02… …02… …02… …02…
If the retrieval DTG of the message (obtained from the MTCB) is superior to the retrieval
time of the last
stored message, update of the in-memory subset of the DTGF (which resi3̲1̲8̲2̲A̲…00…FIX/1153/PSP/0097
…00…lbe …00…OK …00…SRS Subsystem PSP …00…2̲0̲…00…1̲2̲…00…8̲2̲…00…1̲0̲…00…4̲1̲…00… ̲ ̲ ̲5̲…00…1̲2̲…00…
̲1̲7̲1̲6̲0̲…00…1̲7̲…00…0̲2̲…00…8̲3̲…00…0̲9̲…00…1̲0̲…00… ̲ ̲ ̲ ̲…00…07…00… ̲ ̲ ̲3̲72…00…1̲7̲…00…0̲2̲…00…8̲3̲…00…1̲3̲…00…1̲6̲…00…22…00…02…00…83…00…09…00…13…00…0282A…00… 87…00… ̲ ̲ ̲6̲…00…34…00… 408…00… ̲2̲0̲1̲37…00……11……00……02……00… @…00……10……00……01……10……05…'…10……11……01……80…*̲J̲…15……05……00……00……00……00……00……00……01…B
=̲…00……86……00……00……00……00……19……0a……00……00……19……0b……19… …18……08……18……0a……18……0d……18……00……18……05……18……06……17……0b……17……0d……17……0e……17…
…16……08……16……0b……16……0c……16……01……16……07……15……0b……15……00……15……06……14……08……14……0b……14……0e……14……0f……14……02……14…
…14… …14……06……14……07……13……08……13……0a……13……0b……13……0f……13……00……13……01……12……86…1 …02… …02… …02…
…02…FIX/1153/PSP/0097
…02… OK/830216…02……02…
SRS Subsystem PSP
…02… OK/821216…02…FK 7809
TABLE OF CONTENTS Page
1 Scope .......................................... 1
1.1 Introduction .............................. 1
1.2 ABBREVIATIONS .............................. 1
2 APPLICABLE DOCUMENTS ........................... 2
3 MODULE SPECIFICATION ........................... 3
3.1 Functional capabilities .................... 3
3.2 Interface Description ...................... 19
3.3 Processing ................................. 20
3.3.1 STORAGE (Man module). ................. 22
3.3.2 INIT ̲STORAGE ........................... 25
3.3.3 GET ̲QUEUE ̲ELEM ......................... 28
3.3.4 TEST SPACE ............................. 30
3.3.5 DELETION ............................... 33
3.3.6 PROCESS ̲MESS ........................... 39
3.3.7 U ̲MRF ̲DTGF ............................. 46
3.3.8 UPD ̲PARAM .............................. 52
3.3.9 DEL ̲Q ̲ELEM ............................. 54
3.3.10 READ ̲MRF ̲REC ........................ 56
3.3.11 READ ̲DTGF ̲ENT ........................ 58
3.3.12 CALC ̲REC ̲FRGE ̲ON ̲MRF (Delete utility
Procedure) ........................... 60
3.3.13 CALCULATE ̲MTF ̲SPACE (DELET utility
procedre) ........................... 62
3.3.14 DECODE ̲BIN ̲H (PROCESS MESS utility
procedure) ........................... 64
3.3.15 DECODE ̲SICS (PROCESS Mess utility
procedure) ........................... 66
3.3.16 DECODE ̲AIG ̲M (PROCESS MESS utility
procedure) ........................... 68
3.3.17 GET ̲MEDE ̲NO (PROCESS ̲MESS utility
procedure) ........................... 70
3.3.18 UPD ̲TERM ̲BNIT ̲M (PROCESS ̲MESS tility
procedure) ........................... 70 …86…W …02… …02… …02… …02… …02… …02… …02… …02… …02… …02… …02… …02… …02… …02… …02… …02… …02… …02… …02…
3.4 DATA ORGANIZATION .......................... 72
3.5 Storage Allocation ........................ 80
3.6 Performance Characteristics ................ 80
3.7 Limitations ................................ 80
3.8 Error Codes/Error Locations ................ 80
3.9 Listing References ......................... 83
4 Quality Assrance .............................. 84
4.1 Qualification Tests ........................ 84
4.2 Other Quality Assurance Provisions ......... 84
5 Preparations for Delivery ...................... 85
6 Notes ......................................... 86
7 Appendices ..................................... 86 …86…W …02… …02… …02… …02…
1 S̲c̲o̲p̲e̲
This document contains a detailed product specification of the storage module SRS.
1.1 I̲n̲t̲r̲o̲d̲u̲c̲t̲i̲o̲n̲
The SRS performs long time storage of narrative messages on the Hstorical Data Base, HDB.
Further it maintains the retrieval catalog files DTSF and MRF, which are used by the retrieval
system SRR.
1.2 A̲B̲B̲R̲E̲V̲I̲A̲T̲I̲O̲N̲S̲
Ref DATA I/F MANUAL (ref I)…86…W …02… …02… …02… …02…
2 A̲P̲P̲L̲I̲C̲A̲B̲L̲E̲ ̲D̲O̲C̲U̲M̲E̲N̲T̲S̲
I FIX/0100/MAN/0004 FIKS DATA I/F REFERENCE
II FIX/1256/PSP/0078 QACCESS MONITOR PSP
III FIX/1256/PSP/0066 MTCB MONITOR PSP
I FIX/1256/PSP/0057 LOG ̲JOUR MONITOR PSP
V FIX/1153/PSP/0097 SRS SUBMODULE PSP
VI FIX/1000/EWP/0080 FIKS S/W CONFIGURATION
CONTROL LIB.DESCR.DOC.
VII FIX/1200/PSP/0042 FIKS FILE GENERATOR PSP
VIII FIX/0000/TRP/0085 SYSTEM TEST REPORT 3010
3 M̲O̲D̲U̲L̲E̲ ̲S̲P̲E̲C̲I̲F̲I̲C̲A̲T̲I̲O̲N̲
3.1 F̲u̲n̲c̲t̲i̲o̲n̲a̲l̲ ̲c̲a̲p̲a̲b̲i̲l̲i̲t̲i̲e̲s̲
The SRS is the interface to the HDB. It supports storage on the HDB, deletion of messages
on the HDB and retrieval of message from the HDB.
S̲t̲o̲r̲a̲g̲e̲
All message categories (non control messages) are stored except for Special Handling Category
messages.
D̲e̲l̲e̲t̲i̲o̲n̲
The SRS maintains the HDB by deletion of oldest messages.
Deletion is performed when there is not spac available for storage of next message. At this
event messages are deleted to insure
1) A preset amount of time for storage
2) A preset number of messages
39 A preset amount of space for message text.
S̲u̲b̲s̲y̲s̲t̲e̲m̲ ̲B̲l̲o̲c̲k̲ ̲D̲i̲a̲g̲r̲a̲m̲
In figure 3.1-1 the SRS subsystem block diagram is found.
Main events are marked with numbers
1. Processing of storage requests
2. Eventual updates o retrieval files
3. Retention (deletion of messages)
The subsystem has one input queue: SRS1-queue
The queue is handled in a First in First out manner.
When an element, representing a message to be stored is entered in the SRS1 queue.
The torage Module verifies that space is available for the next message in the Historical
Data Base, if space is not available a prescribed amount of space is obtained by deletion
of oldest messages on the HDB (Retention, 3.). When space is available te in memory subset
of the message retrieval files (DTGF and MRF) are updated with retrieval relevant information
and a transfer of the message text is performed from the Input file to the Message Text File
(1).
The MTCB for the message is updated ith the MTF address and a HDB indicator flag.
Whenever the in-memory subsets of the DTGF and/or MRF are full, a transfer to disc is made
(2).
Fig. 3.1-1, STORAGE MODULE, INTERFACE BLOCK DIAGRAM
H̲D̲B̲ ̲s̲t̲r̲u̲c̲t̲u̲r̲e̲ ̲ ̲(̲f̲i̲g̲.̲ ̲3̲.̲1̲-̲2̲)̲
Message retrieval is performed by reference to two message access files. The DTGF file is
the primary access reference. Each entry in the DTGF file cntains the number of records offset
from the beginning of the MRF file where the first message in or after the specified DTG
is referenced.
The entry number in the DTGF is calculated from the value of the DTG, the DTG corresponding
to the oldest ntry in the file, entry number of oldest entry and number of entries in the
file:
Word offset on
DTGF of DTG:̲ RM ̲ ̲-̲D̲T̲G̲-̲B̲A̲S̲E̲-̲D̲T̲G̲ + word length
No. of entries on DTGF
of control block
(DTG of oldest message on HDB DTG DTG of last stored message).
The entry of this offset is the record number of the first message stored in the interval
DTG to DTG + 1 minute. If no messages were stored in this interval the entry contains the
MRF number of the next store message. (fig. 3.1-2).
The MRF file contains fixed length records of
Retrieval DTG
Text address (sector no. on MTF file)
Message length
Message id.
3 SIC's
Message classificatin
Action and info precedence
Terminal bit mask
Fig. 3.1-2, HDB Logical Structure
H̲D̲B̲ ̲l̲a̲y̲o̲u̲t̲
The HDB is laid out with each of the three files as contiguous files.
Updates of DTGF and MRF are performed as updates in an in memory subset of these files. Whenevr
the in memory subset is full a transfer is made to the disc file.
The DTGF consists of 43776 entries corresponding to 30 days storage. One entry exists for
each minute independent of whether a messagae was stored or not.
One entry in the DTGFis one word long. This
word is the MRF record number of the first
message in this DTG. If no message has re-
trieval time equal to this DTG the DTGF entry is the MRF record number of the first message
after this DTG.
The MRF consists of 44800 ecords correspon- ding to 44800 messages.
One record contains:
MSG - ID
Retrieval DTG
Message security class
Bit mask with one bit per terminal
The bit is true if the corre-
sponding terminal has the
right to retrieve the message.
3 SIC's
Message address on MTF. It is an offset
in sectors from the beginning
of the MTF.
Message length.
Action and info precedence
The MTF file consists of 110309 contiguos sectors (+ 1 sector reserved for control information).
The messages are stored on the MTF starting on a sector boundary. This gives a wanted space
of 25% in average (the space at end of one message until next sector boundary). The capacity
is the 44795 messages of average length (ref. I, chap. 11.2).
A detailed description of the files MTF, MRF and DTGF is found in ref. I, chap. 11.2.
M̲e̲s̲s̲a̲g̲e̲ ̲S̲t̲o̲r̲a̲g̲e̲ ̲a̲n̲d̲ ̲D̲e̲l̲e̲t̲i̲o̲n̲
Message Storage is initiated by placing an entry in the SRS storage quee that points to a
Message Transition
Control Block. Each MTCB is time stamped by the MDS subsystem with the retrieval time (DTGF
entry) and they must be entered sequentially.
The processing is as follows:
The storage process calls QACCESS andthe MTCB
monitor to get the first element in the storage
queue.
The storage process tests if space is available for the message on the HDB. This means
At least the length of the message
free on MTF
One record free on MRF
If the DTG of the message to be stored is
superior to the DTG of the last message stored on the HDB, thestorage process tests
if space is available on the DTGF for DTG
entries from the DTG of the last message to
DTG of current message.
If one or more of the three tests shows, that space
is not available deletion is performed (see below).
Wheever space is available the storage processing
continues as follows:
The message file (the message as referenced by the MTCB) is copied to the MTF starting in
the begin-
ning of the first free sector. See fig. 3.1-3.
Fig 3.1-3, MESSAGE STORAGE
In the copy processing eventually all of the message is in memory (not all at one instant).
While in memory
all information for the MRF is extracted.
This means:
Copy MSG ̲ID Security class
SIC's
from the message
Read address numbers (ANO's) and AIG's together
with originator ID and generate the bit mask in-
dicating terminals with retrieval right:
originator ANO and TO and INFO
ANO's are scanned. Those eferring a local terminal
give the retrieval right to this terminal.
The MRF record for the message is formed of the ex-
tracted information together with the MTF address of
the firs sector of the message, the retrieval time
and the messag length from the MTCB
The in-memory subset of the MRF(which is a part of the critical region SRS ̲CR) is updated
with the record. If the in-memory subset of the MRF hereby gets full, a transfer to the MRF
is performed. (The storage process
awaittermination). (fig. 3.1-3).…86…W …02… …02… …02… …02…
If the retrieval DTG of the message (obtained from the MTCB) is superior to the retrieval
time of the last
stored message, update of the in-memory subset of the DTGF (which resies in the critical
region SRS ̲CR)takes place. This means an update of all entries corresponding to DTG's since
the DTG of the last stored message. All these entries get updated with the MRF record number
of the present message. Whenever in this proess the in-memory subset of the DTGF gets full
transfer is made to the DTGF (fig. 3.1-3).
The MTCB of the message is updated with
o MTF address
o Indicator that the message is on HDB
by call to the MTCB monitor.
The queue element (and the MCB) is released via call
to QACCESS. If the storage process was the last
referencing the input file the MTCB monitor will delete the file.
A system message is sent to the subsystem MDS. The message tells that the narrative message
it had queue to SRS now is stored on HDB and that MDS can continue its processing of the
message.
When SRS has received a system answer from MDS the critical region SRS ̲CR is copied to the
checkpoint file SRS ̲CHECKP on FIXHEAD.
The SRS now calls QACCESS to gt the next element in the storage queue for processing as described
above.
If no queue element was found the storage process goes into a wait for signal that a queue
element has been entered in an empty queue.
Deletion of oldest messages is intitiated whenever no room available as outlined above. Deletion
is performed so that:
a. A given timespan is available for message
storage. his means, that messages shall be
deleted to get a new value for the DTG of
the oldest message. The entries from DTG (oldest) to DTG (newest) are the occupied
entries.
Number of free entries =
Total number if entries - (entries from
DTG (oldest) to DTG (newest).
The number of free entries shall be superior to
the number of entries required to cover the given timespan.
b. A given number of records free on MRF for storage of new messages. Messages shall
be deleted so hat the required number of records are free on the MRF.
c. A given amount of space on the message text file.
Messages shall be deleted so that the given amount of text space is available on
the MTF.
Deletion is performed as follows:
1. Calculate the MRF record number to fulfil condition b. The determined record may
correspond to a message which is not the first for a givenDTG. To obtain this the
MRF record is read to obtain the retrieval DTG of the message. This value + one minute
is defined as the new value for the DTG of the oldest message.
2. A test is performed to see if condition a. is fulfilled. If not the TG of the oldest
message is incremented to fulfil condition a.
3. With the present value for the DTG of the oldest message the offset in the DTGF is
calculated and the corresponding entry is read: The DTGF entry gives the MRF record
number. ThisMRF record is read. From the MTF address of the oldest message as defined
here and the MTF address of the first free part in the MTF the amount of free space
is calculated. If the calculated space does not fulfil condition c. a search is started
unil condition c. is fulfilled.
The search starts by calculating the remaining number of messages to be deleted to
fullfil condition c. (Remaining messages = (space required - space free)/18 sectors).…86…W
…02… …02… …02… …02…
The number of messages is added to the present value 'oldest MRF record number '.
The MRF record is read and the MTF address is extracted. With this value of 'oldest
MTF sector'the space free on MTF is calculated. If condition c. is not fulfilled
the search is repeated.
To get the correct relationship between MRF number and DTG entry the retrieval DTG
in the calculated 'oldest MRF record' is extracted and defined as odest DTG after
deletion. The DTG entry is read from DTSF file and the entry is defined as the MRF
record of oldest message after deletion. The MRF record is read and the MTF address
is extracted and the value defined as first sector of oldest messae on HDB after
deletion.
4. The first sector of DTGF, MRF and MTF (the control sectors) are updated to reflect
deletion.
Deletion completed.
S̲R̲S̲ ̲R̲E̲C̲O̲V̲E̲R̲Y̲
After each storage of a message the critical region SRS ̲CR which contains all necessary pointers
for a restart)
Is copied to the checkpoint file SRS ̲CHECKP.
When the SRS process is loaded and started (at cold start or recovery) the SRS ̲CHECKP. file
is copied to SRS ̲CR and pointers and variables in SRS ̲pocess is reconstructed.
The SRS i now ready to serve its input queue.
At disc initialization time (or at corruption of HDB) the generator PRESET ̲HDB has to be
run.
The generator presets variables and pointers in SRS-CHECKUP to indicate an empty HDB
A detailed product description of PRESET ̲HDB is found in, ref. VII.
3.2 I̲n̲t̲e̲r̲f̲a̲c̲e̲ ̲D̲e̲s̲c̲r̲i̲p̲t̲i̲o̲n̲
Interface data: ref. I, chap. 7.1.1.1.
Input queues: SRS1-queue (first in, first out)
Output queues: None
I̲n̲t̲e̲r̲f̲a̲c̲e̲ ̲t̲o̲ ̲o̲h̲e̲r̲ ̲s̲u̲b̲s̲y̲s̲t̲e̲m̲s̲:̲
SRS ̲MDS: MDS requests storage of a message by
enqueueing a MTCB index in SRS1-queue.
SRS ̲MDS: When a storage of a message is completed an
AMOS message is sent to MDS.
MDS-SRS: An answer is returned to MDS.
Critical egion access:
SRS Read and updates critical region SRS ̲CR
File access:
IMF, PDB: via MTCB monitor (read)
RDF: via RDF monitor (read)
MTF,MRF,DTGF,SRS ̲CHECK P: Via IOS (read, write)
3.3 P̲r̲o̲c̲e̲s̲s̲i̲n̲g̲
This chapter contains a detailed 'as build' description of the subsystem SRS. Each procedure
is presented by a brief description and a HIPO chart. Pointers, variabes, buffers and constants
are described in chapter 3.4.
Figure 3.3-1 shows an overview block diagram of the subsystem.
The STORAGE box represents the main module, from which the procedures are called.
The procedures again call a number of utiity procedures (the smallest boxes) and monitors
(boxes with double sides).
A detailed description the data referenced in the input/output blocks of the HIPO charts
is found in chap. 3.4.
Fig. 3.3-1, Module block diagram of SRS
3.3.1 S̲T̲O̲R̲A̲G̲E̲ ̲(̲M̲a̲i̲n̲ ̲m̲o̲d̲u̲l̲e̲)̲.̲
FUNCTION:
After call of INIT ̲STORAGE an endless loop is entered. The loop is only excited
in case of a fatal error or a removal of the process.
After processing of a message all update pointers are copied to the critical
region SRS ̲CR (which is also accessed by the Retrieval submodule (SRR), and the
entire region (containing DTGF incore part, MRF incore part and pointers) is
stored on disc file SRS ̲CHECKP.
STORAGE Mainmodule, HIPO Chart , Fig. 3.3.1-1
STORAGE Mainmodule, HIPO chart, Fig 3.3.1.-1
3.3.2 I̲N̲I̲T̲ ̲S̲T̲O̲R̲A̲G̲E̲
REGISTERS: R6: LINK
FUNCTION: File discriptions are found for directories
MOVEHEAD and FIXHEAD and files, MRF, DTGF,
MTF, RDF and SRS ̲CHECKP.
The MTCB monitor is initiated and the local mede id found.
SRS ̲CHECKP file is copied into critical region SRS ̲CR and pointers and variables are recovered.
The procedure is called once after start/restart and is then never used.
INIT ̲STORAGE, HIPO Chart, Fig. 3.3.3.2-1
INIT ̲STORAGE, HIPO Chart, Fig, 3.3.2-2
3.3.3 G̲E̲T̲ ̲Q̲U̲E̲U̲E̲ ̲E̲L̲E̲M̲
REGISTERS: R6: LINK
FUNCTION: The SRS1-queue is served by call of MON QACCESS. If the queue is empty the process
waits in 10 sec or until a signa is received and then it tries again.
If a queue element is found, the corresponding MTCB is read and placed in the
buffer MTCBWKSP.
SET ̲QUEUE ̲ELEM, HIPO Chart., Fig. 3.3.3
3.3.4 T̲E̲S̲T̲ ̲S̲P̲A̲C̲E̲
Registers: RG: LINK
Function:
The DTG extracted from the MTCB (which was time stamped by MDS subsystem) is converted
from seconds to minutes. As the messags must arrive to the SRS1-queue in a cronological
order, it is tested if the DTG of the current message is older than the DTG of the previous
stored message, if not, the message cannot be handled by SRS and MON ERROR is called,
requesting a switchoer.
TEST ̲SPACE is always called before processing of a message to determine whether a deletion
is necessary or not beofre storage.
To avoid a deletion. 3 criterias must be fulfilled:
1. at least 256 entries (words) must be free on DTGF file
2. at least 16 records (8 words each) must be free on MRF file
3. at least the number of sectors required to store the current message must be free on
MTF
If all criterias are fulfilled the flag F ̲SPACE is set to true…86…1 …02… …02… …02… …02…
…86…1 …02… …02… …02… …02…
…86…1 …02… …02… …02… …02…
3.3.5 D̲e̲l̲e̲t̲i̲o̲n̲
Registers R6: LINK
Function:
DELETE is called if the TEST ̲SPACE procedure returns with the flag F ̲SPACE as false.
The deletion is done by changing the values f the filepointers (pointers to oldest entries)
Deletion on MRF, DTGF and MTF are done until 3 criterias are fulfilled:
1. at least 300 records free on MRF
2. at least 576 entries free on DTGF
3. at least 568 sectors free on MTF
If the spce left on MRF file is less than specified in criteria 1, a new "oldest record no",
MRF ̲REC is calculated. The DTG corresponding to this record no. is found by extracting the
DTG of the found MRF record. As it is shown in fig. 3.1-2 several MRF rcords can contain
identical DTG…08…s (i.e. messages stores within the same minute). Therefore to get the correct
relationship between the new "OLDEST DTG" and the new "oldest record no" the entry of the
DTG (containing the MRF record no. of the first essage of this DTG) is read from DTGF file.
The result of this is the 2 pointers DTGS and MRF ̲REC (which are the new pointers of oldest
MRF rec and oldest DTG with criterion 1 fulfilled).
If the new DTG does not fulfill criterion 2 a new DTG is alculated and its corresponding
MRF record no. is read in DTGF file.
The MTF sector no. which fulfills criterion 3 is found by iteration:
The MRT ̲REC record is read and MTF address is extracted and stored in MTF ̲SECTOR (which now
is a quess of oldest MTF sector"). The free MTF space is calculated and if less than required
in criterion 3, a new MRF record is calculated. The MTF address is extracted from the new
MTF record and the MTF space free is again calculated. This iteration contiues until criterion
3 is fulfilled.
The new pointers to oldest entries on DTGF, MRF and
MTF are updated and copied to critical region SRS ̲CR.
The same pointers are copied to the control records
on the files MRF, DGF and MTF.
Deletion is now done and the processing of the message
which caused the deletion can continue…86…1 …02…
…02… …02… …02… …86…1
…02… …02… …02… …02…
…86…1 …02… …02… …02… …02…
…86…1 …02… …02… …02… …02…
…86…1 …02… …02… …02… …02…
3.3.6 PROCESS ̲MESS
…0e… ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
…0f…
REGISTERS: R6: LINK
Function:
The message being processed is copied from its temporary
media (PDB or IMF file) into a SRS buffer and from
tere into the next free area on MTF file. While the
message is copied (and parts of it is present in the
incore buffer MTF ̲BUF) retrieval relevant information
i.e. message id and SIC…08…s) is extracted and the MRF
record is generated. Additional infomation is extracted
from MTCB and placed in the MRF record.
A bitmap representing the terminals which were addressed
is generated from the address list and placed in MRF
record.…86…1 …02… …02… …02… …02…
…86…1 …02… …02… …02… …02…
…86…1 …02… …02… …02… …02…
…86…1 …02…
…02… …02… …02…
…86…1 …02… …02… …02… …02…
…86…1 …02… …02… …02… …02…
…86…1 …02… …02… …02… …02…
3.3.7 U ̲MRF ̲DTGF
…0e… ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
…0f…
Registers: R6: LINK
Function:
The MRF record generated in PROCESS ̲MESS is stored
in the incore part of MRF file (the upper part of critical
regon SRS ̲CR).
If the incore MRF buffer (which can contrin 16 records)
is full, or the space free on MRF file is equal to
the present size of MRFincore part, it is copied to
MRF file.
The number of minutes since last stored message is
calculateed nd each corresponding entry in the incore
part of the DTGF file (the lower part of critical region
SRS ̲CR) is updated with the MRF record number of the
message being processed.
Whenever the incore DTGF buffer is full or its size
equals the space ree on disc file, the buffer is copied
to DTGF file…86…1 …02… …02… …02… …02…
…86…1 …02… …02… …02… …02…
…86…1 …02… …02… …02…
…02… …86…1
…02… …02… …02… …02…
…86…1 …02… …02… …02… …02…
…86…1 …02… …02… …02… …02…
3.3.8 UPD ̲PARAM
…0e… ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
…0f…
Registers: R6: LINK
Function:
File pointers and pointers to incore buffers are updated
and copied to critical region SRS ̲C…86…1 …02… …02…
…02… …02… …86…1
…02… …02… …02… …02…
3.3.9 DEL ̲Q ̲ELEM
…0e… ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
…0f…
Registers: R6: LINK
Function:
The MTCB representing the message is updated with MTF
sector address and the HDB indicator flag.
The file is reeased and the queue element is deleted.
A message indicating that the storage is completed
is sent to MDS and an answer from MDS (which have been
waiting since it placed the element in the SRS1-queue)
is awaited…86…1 …02… …02… …02… …02…
…86…1 …02… …02… …02… …02…
3.3.10 READ ̲MRE ̲REC
…0e… ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
…0f…
Registers R4: in: MRF record no
out:Ref. (DTG)
R5: in: None
out: Ref. (MTF sector no.)
R6: LINK
Function:
To xtract the DTG and MTF address from the specified
MRF record.
If the record is in the incore part of MRF the information
is read from SRS ̲CR, else it is read from MRF file.…86…1
…02… …02… …02… …02…
…86…1 …02… …02… …02… …02…
3.3.11 READ ̲DTGF ̲ENT
…0e… ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
…0f…
Registers: R4: in: Ref (DTG)
out: MRF record no.
R6: LINK
Function:
The offset of the specified DTG is found either in
DTF income file (SRS ̲CR) or DTGF file and its entry
(a MRF record no.) is delivered…86…1 …02… …02… …02… …02…
…86…1
…02… …02… …02… …02…
3.3.12 CALC ̲RECS ̲FRGE ̲ON ̲MRF (Delete utility Procedure)
…0e… ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
…0f…
Registers: R0: in: NONE
out: Records free
Function:
Noof records between oldest and newest MRF record on
MRF file is calculated…86…1 …02… …02… …02… …02…
…86…1 …02… …02… …02…
…02…
3.3.13 CALCULATE ̲MTF ̲SPACE (DELET utility procedure)
…0e… ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
…0f…
Registers: R6: LINK
Function:
Number of sectors between MTF ̲SECTOR and frst sector
of oldest message is calculated…86…1 …02… …02… …02… …02…
…86…1
…02… …02… …02… …02…
3.3.14 DECODE ̲BIN ̲H (PROCESS MESS utility procedure)
…0e… ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
…0f…
Registers: R6: LINK
Function:
From binary header (which now is present i MTF ̲BUF)
the address list offset and SIC is extracted.
A SIC offset = 0 indicates that no 316…08…s exists.
As the SIC-offset is not the actual offset of the first
SIC, a correction is added…86…1 …02… …02… …02… …02…
…86…1 …02… …02…
…02… …02…
3.3.15 DECODE ̲SICS (PROCESS MESS utility procedure)
…0e… ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
…0f…
Registers: R6: LINK
Function:
The SIC area of the message has been copied o SIC ̲BUF
by PROCESS ̲MESS.
DECODE ̲SICS extract the delimiters (/) and copy them
to the MRF record of the message…86…1 …02… …02… …02…
…02… …86…1
…02… …02… …02… …02…
3.3.16 DECODE ̲AIG ̲M (PROCESS MESS utility procedure)
…0e… ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
…0f…
Registers: R6: LINK
Function:
The AIG bitmap (in BUFFER 1) is decoded ad bits indicating
local terminals are detected and invoked in BIT ̲MAS…86…1
…02… …02… …02… …02…
…86…1 …02… …02… …02… …02…
3.3.17 GET ̲MEDE ̲NO (PROCESS ̲MESS utility procedure)
…0e… ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
…0f…
Registers: R2: in: Mede id
out: Mask number in AIG Mask
R6: INK
Function:
The mede id is converted to an AIG mask pointer (1-8)
3.3.18 UPD ̲TERM ̲BIT ̲M (PROCESS ̲MESS utility procedure)
…0e… ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
…0f…
Registers: R0: in: terminal number
out: - -
R6: LINK
Function:
The bit in BIT ̲MASK representing the requested terminal
number is set…86…1 …02… …02… …02… …02…
…86…1 …02… …02… …02… …02…
3.4 D̲A̲T̲A̲ ̲O̲R̲G̲A̲N̲I̲Z̲A̲T̲I̲O̲N̲
The file SRS1 ̲EXP.S contains declarations of all variables
buffers and arrays which define the data area (Process)
of the STORAGE subsystem.
The file HDB ̲CNST.S contains all constants used in
the STORAGE subsystem. The same file defines the constants
of the RETRIEVAL subsystem and it is therefore placed
in the directory FIX ̲PREFIX.D in main directory.
Besides the Process area the SRS also access te critical
region SRS ̲CR. (This region is a common data area used
by SRS, SRR and ESP. The region is read and updated
by SRS and inspected by SRR and ESP)
The SRS ̲CR consists of a DTGF buffer (incore part of
DTGF file), MRF buffer (incore part ofMRF file) and
a parameter list. (see fig. 3.4-1)
Each word in the DTGF buffer belongs to a specific
DTG (which can be calculated from the DTG pointers)
and it contains a MRF record number. When the buffer
is full it is copied to DTGF file and DT ̲IND, which
is a pointer to the next free word in the buffer, is
preset.
The MRF buffer contains up to 16 MRF records each of
8 words (see fig. 3.4-2). When the buffer is full it
is copied to MRF file and MRF ̲IND, which is a pointer
to next free ecord in the buffer, is preset…86…1
…02… …02… …02… …02…
…86…1 …02… …02… …02… …02…
…86…1 …02… …02… …02… …02…
…86…1 …02… …02… …02… …02…
…86…1 …02… …02…
…02… …02… …86…1
…02… …02… …02… …02…
…86…1 …02… …02… …02… …02…
3.5. S̲t̲o̲r̲a̲g̲e̲ ̲A̲l̲l̲o̲c̲a̲t̲i̲o̲n̲
Program Size: 2107 words, Page 0
Process Size: 1322 words, Page 1 or 2
3.6 P̲e̲r̲f̲o̲r̲m̲a̲n̲c̲e̲ ̲C̲h̲a̲r̲a̲c̲t̲e̲r̲i̲s̲t̲i̲c̲s̲
N/A
3.7 L̲i̲m̲i̲t̲a̲t̲i̲o̲n̲s̲
The storage cpacity is 30 days of average message traffic.
3.8 E̲r̲r̲o̲r̲ ̲C̲o̲d̲e̲s̲/̲E̲r̲r̲o̲r̲ ̲L̲o̲c̲a̲t̲i̲o̲n̲s̲
see attached lis…86…1 …02… …02… …02… …02…
…86…1 …02… …02… …02… …02…
…86…1 …02…
…02… …02… …02…
3.9 L̲i̲s̲t̲i̲n̲g̲ ̲R̲e̲f̲e̲r̲e̲n̲c̲e̲s̲
Ref. chap. 5
4 Q̲u̲a̲l̲i̲t̲y̲ ̲A̲s̲s̲u̲r̲a̲n̲c̲e̲
4.1 Q̲u̲a̲l̲i̲f̲i̲c̲a̲t̲i̲o̲n̲ ̲T̲e̲s̲t̲s̲
Ref. (S10, test report)
4.2 O̲t̲h̲e̲r̲ ̲Q̲u̲a̲l̲i̲t̲y̲ ̲A̲s̲s̲u̲r̲a̲n̲c̲e̲ ̲P̲r̲o̲v̲i̲s̲i̲o̲n̲s̲
N/A
5 P̲r̲e̲p̲a̲r̲a̲t̲i̲o̲n̲s̲ ̲f̲o̲r̲ ̲D̲e̲l̲i̲v̲e̲r̲y̲
Command files used in generation of the object code
(SRS.CR0,SRS.CR1,SRS.CP,SRS.L0,SRS.L1) can be found
in FIXLIB source directory for SRS (ref.VI)
eneration of object code file:
. Copy the source directory of the actual SRS version
into a work directory.
. Activate the command file SRS.CR0
. - - - - SRS.CP
. - - - - SRS.L0
The object code ready fo installation will then be
found in the file SRS.C
L̲i̲s̲t̲i̲n̲g̲s̲
By activating the command file SRS.PP all source code
and link output file is printed.
6 N̲o̲t̲e̲s̲
N/A
7 A̲p̲p̲e̲n̲d̲i̲c̲e̲s̲
N/
