top - download
⟦b2d64f09c⟧ Wang Wps File
Length: 35602 (0x8b12)
Types: Wang Wps File
Notes: FIX/1153/PSP/0096
Names: »3171A «
Derivation
└─⟦507b19fd6⟧ Bits:30006135 8" Wang WCS floppy, CR 0282A
└─ ⟦this⟧ »3171A «
WangText
…0a……07……09……0b……09……0c……09……0f……09… …09……05……08……08……08……0e……08……00……08……01……08…
…08… …08……06……08……07……07……86…1
…02…
…02…
…02…
…02…FIX/1153/PSP/0096
…02…JJJ/880916
…02……02…#
FIKS
SRR
Subsystem
…02…
OK/821216
…02…
FIKS
…08……06…1 …02… …02… …02… …02… …02…
FIKS SRR Subsystem
Product Specification
FIX/1153/PSP/0096
…0f…AK
FMK
…0e… FMK (6), AK(4)
FIKS Pgm. Mgr
Doc.Conf.Mgr.
1.2
880916
REVISION RECORD
REVISION RECORD
REVISION RECORD
REVISION RECORD
REVISION RECORD
Wang/Disk:
3171A/282A
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲…06…1 …02… …02… …02…
ISSUE DATE PAGES BRIEF
DESCRIPTION
OF
CHANGE
ISSUE DATE PAGES BRIEF
DESCRIPTION
OF
CHANGE
ISSUE DATE PAGES BRIEF
DESCRIPTION
OF
CHANGE
ISSUE DATE PAGES BRIEF
DESCRIPTION
OF
CHANGE
ISSUE DATE PAGES BRIEF
DESCRIPTION
OF
CHANGE
AFFECTED
AFFECTED
AFFECTED
AFFECTED
AFFECTED
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ^ ^
^
1 ^821216 ^ All ^
Original
issue
of
document.
^ ^ ^
1.1 ^870209 ^ DCN 1 ^
Changed
in
accordance
with
Order
No:
23/86
^ ^ ^
1.2 ^880916 ^ DCN 2 ^
Changed
in
accordance
with
Order
No:
10/88
^ ^ ^
^ ^ ^
^ ^ ^
^ ^ ^
^ ^ ^
^ ^ ^
^ ^ ^
^ ^ ^
^ ^ ^
^ ^ ^
^ ^ ^
^ ^ ^
^ ^ ^
^ ^ ^
^ ^ ^
^ ^ ^
^ ^ ^
^ ^ ^
^ ^ ^
^ ^ ^
^ ^ ^
^ ^ ^
^ ^ ^
^ ^ ^
^ ^ ^
^ ^ ^
^ ^ ^
^ ^ ^
^ ^ ^
^ ^ ^
^ ^ ^
^ ^ ^
^ ^ ^
^ ^ ^
^ ^ ^
^ ^ ^
^ ^ ^
^ ^ ^
^ ^ ^
^ ^ ^
^ ^ ^
^ ^ ^
L̲I̲S̲T̲ ̲O̲F̲ ̲C̲O̲N̲T̲E̲N̲T̲S̲
Page
1 SCOPE .......................................... 1
1.1 Introduction ............................... 1
1.2 Abbreviations .............................. 1
2 APPLICABLE DOCUMENTS ........................... 1
3 MODULE SPECIFICATION ........................... 2
3.1 Functional Capabilities .................... 2
3.2 INTERFACE DESCRIPTION ...................... 10
3.3 PROCESSING.................................. 12
3.3.1 SRR ̲INIT ............................... 16
3.3.2 RMAIN: ................................. 18
3.3.3 GET ̲RTR ̲Q ̲ELEM ......................... 20
3.3.4 R ̲MID .................................. 22
3.3.5 RDTGR .................................. 24
3.3.6 RDTDS .................................. 26
3.3.7 RMLOG .................................. 28
3.3.8 QUEUE ̲MTCBS ............................ 30
3.3.9 DEL ̲RTR ̲Q ̲ELEM ......................... 32
3.3.10 RRDTG ................................ 34
3.3.11 RPMRF ................................ 38
3.3.12 TEST ̲TERM ............................ 40
3.3.13 GEN ̲MTCB ............................. 42
3.3.14 GET ̲DTG ̲ENTRY ........................ 44
3.4 DATA ORGANIZATION .......................... 46
3.5 STORAGE ALLOCATION ......................... 51
3.6 Performance Characteristics ................. 51
3.7 Limitations ................................ 51
3.8 Error Codes/Error Locations ................ 52
4 QUALITY ASSURANCE ............................ 58
4.1 Qualification Tests ........................ 58
4.2 Other Quality Assurance Provisions ......... 58
5 PREPARATIONS FOR DELIVERY ...................... 59
1 S̲C̲O̲P̲E̲
This document contains a detailed product specification of the retrieval subsystem SRR.
1.1 I̲n̲t̲r̲o̲d̲u̲c̲t̲i̲o̲n̲
The SRR handles operator requested message retrievals.
Messages which match with the specified retrieval keys are searched by scanning the HDB files
DTGF and MRF.
If one or more messages are found the operator is checked for security classification and
his terminal is checked for retrieval rights, and the message is sent for printout or VDU
display.
The SRR also handles Message log requests.
1.2 A̲b̲b̲r̲e̲v̲i̲a̲t̲i̲o̲n̲s̲
Ref. I
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
IV 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 FXA/SDS/004 RETRANSMISSION PROCEDURE
3 M̲O̲D̲U̲L̲E̲ ̲S̲P̲E̲C̲I̲F̲I̲C̲A̲T̲I̲O̲N̲
This chapter contains in 3.1 a narrative description of the SRR functions. Chapter 3.2 describes
in details the processing in each procedure.
A detailed description of the HDB catalog files MRF and DTGF is found in ref. V chap.3.1
and ref I chap. 11.2.
Monitors mentioned in the description are MTCB monitor (ref. III), QACCESS monitor (ref.
II) and LOG ̲JOUR monitor (ref IV).
3.1 F̲u̲n̲c̲t̲i̲o̲n̲a̲l̲ ̲c̲a̲p̲a̲b̲i̲l̲i̲t̲i̲e̲s̲
In fig. 3.1-1 the block diagram of the retrieval module is shown. Main events are described
below and the numbers in brackets refer to the block diagram.
Retrieval is performed by making an entry in the SRS2 queue with the request parameters and
an identification of the requesting terminal (1).
The requestor generates a pseudo MTCB with the following information. (for detailed information:
ref. I, Chap. 7.1.2.1):
Retrieval case indicator:
1) for addressal or retrieve and distribute (RD-queue)
2) for printout (LP-queue)
3) for display (RT-queue)
4) for retransmission of traffic to NICS/TARE
Retrieval key indicator:
a) MSG-ID + DTG
b) DTG-RANGE
c) DTG-RANGE + SIC
d) DTG-RANGE (if command has been RTT)
Case 1 may request key a only.
Cases 2 and 3 may request key a,b and c.
Case 4 may request key d only.
Retrieval keys
key a DTG
MSG-ID
key b DTG start
DTG end
key c DTG start
DTG end
SIC
key d DTG start
DTG end
Terminal identification
terminal number
Indicator if requestor is supervisor
or supervisor assistant.
The lowest of the terminal security
classification and the operator
security classification, in the
following called the operator/
terminal security class.
The generated pseudo MTCB is queued by the requestor to the SRS2 queue (1).
The retrieval process calls QACCESS (2) and the MTCB monitor (3) to get the first element
in the retrieval queue (a pseudo MTCB as above).
It determines the DTG range (for key a DTG to DTG + 1 minute). It accesses the DTGF to get
the range on the MRF. If the DTGF is (partly) in memory the entries are read from memory
(4) if the DTGF entries are on disc the DTGF is accessed to read the MRF record number(s)
(5) The MRF records in question are found either on disc (6) or in memory (7) and scanned.
For key a the processing is:
Test if MSG ̲ID fits with MRF record MSG-ID.
If no fit continue with next MRF record until end of MRF records in question. If fit test
if the requesting terminal is either a supervisory terminal or represented in the termnal
bit mask (from the MRF record).
Test if the operator/terminal security class is superior or equal to the message security
class (from MRF record). Terminate the search.
If all tests were positive generate an MTCB as described below and save the MTCB index.
If any of the latter two test failed or end of MRF records in question is reached generate
error notification as described below.
For key b the processing is:
Test if the requesting terminal is either a supervisory terminal or represented in the terminal
bit mask (from the MRF record). Test if the operator/terminal security class is superior
or equal to the message security class (from the MRF record). If one of the two tests fails
take next MRF record until end of MRF records in question. If both tests are successful,
generate an MTCB as described below, save the MTCB index and continue with next MRF record
until end of MRF records in question or until 11 messages found.
If no message found or 11 messages found generate error notification as described below.
For key c the processing is:
Test if the given SIC matches with one of the max. 3 SIC's in the MRF record. Test if the
requesting terminal is either a supervisory terminal or represented in the terminal bit mask
(from the MRF record). Test if the operator/terminal security class is superior or equal
to the message security class (from the MRF record). If one of the three test fails take
next MRF record until end of MRF records in question. If all three tests are successful generate
a MTCB as described below, save the MTCB index and continue with next MRF record until end
of MRF records in question or until 11 messages found. If no message found or 11 messages
found generate error message as described below.
For key d processing is:
Refer to VII sec. 3.3.3.
The generation of the MTCB's for located messages is performed as follows:
Call the MTCB monitor to create
(find a free) MTCB (8)
Extract
Action precedence
Classification
Message length
HDB - address
and Retrieval time
from the MRF record,
write this information plus
indication Type = narrative message
Specat = not special handling
to the created MTCB through a call to the MTCB monitor (9).
The queuing to requestor terminal queue is performed as follows:
If 1-10 messages found (key a maximum 1) the indices of the corresponding MTCB(s) is (are)
queued to the requestors queue.
This means
case 1 RD-queue
- 2 LP-queue
- 3 RT-queue
The queuing is performed by access to QACCESS (10).
Perform logging by call to LOG ̲ACTION.
ERROR CASES
If no message found or 11 messages found or a resource error occured the pseudo-MTCB is updated
with an error code and the index of the pseudo-MTCB is queued through a call to QACCESS to
RD queue for case 1
RT queue for case 2 and 3.
Finally all references from the retrieval process to MTCB's are released.
This is performed by
call to QACCESS for release of queue
element and pseudo MTCB queued (11)
call to the MTCB monitor to release
MTCB's created in the retrieval process
(MTCB's of located messages) (12)
The processing in the retrieval process for the actual retrieval request is terminated.
Fig. 3.1-1
SRR Subsyst. Block. Diagr.
A message log request is performed by entering a pseudo MTCB containing message log code
and terminal number in the SRS2-queue (1). The DTGF is scanned (either in memory (13) or
on disc (14)) and the MRF record numbers concerning the last 24 hours stored messages are
found.
The MRF records in question are read from SRS ̲CR (15) or from MRF file (16) and copied to
MLF file (17).
The MTCB is updated with number of records on MLF file (18) and the MTCB is queued to the
original terminal process.
The retrieval process calls the QACCESS to get the next element in the SRS2-queue and if
it is empty it waits until a signal is received from QACCESS.
3.2 I̲N̲T̲E̲R̲F̲A̲C̲E̲ ̲D̲E̲S̲C̲R̲I̲P̲T̲I̲O̲N̲
Interface data: MTCB layouts: see ref. I, chap. 7.1.2.1
Input queues: SRS2-queue
Output queues: Terminal queues
I̲n̲t̲e̲r̲f̲a̲c̲e̲ ̲t̲o̲ ̲o̲t̲h̲e̲r̲ ̲s̲u̲b̲s̲y̲s̲t̲e̲m̲s̲:̲
TEP-SRR : Terminal processes request retrivals, retransmission or message log by enqueuing
a pseudo-MTCB (describing the request) to SRS2-queue.
SRR-TEP : When the requested messages are found MTCB'S are generated and queued to the
requesting terminal process.
When the requested message log is processed the Pseudo MTCB (containing the request)
is updated and sent to the requesting terminal process.
SRR-NSS
SRR-SPM: When a message for retransmission has been found, the routing mask in the MTCB
will be updated to S and Z only and then it will be enqueued and checkpointed
into the local NSS transport queue. Exept for a collocated MEDE where a bit in
the routing mask only will be set for the remote SIP. The MTCB will then be enqueued
and checkpointed into the local SIP queue, too.
C̲r̲i̲t̲i̲c̲a̲l̲ ̲r̲e̲g̲i̲o̲n̲s̲:̲
SRR reads information from SRS ̲CR
F̲i̲l̲e̲ ̲a̲c̲c̲e̲s̲s̲e̲s̲:̲
MRF, DTGF, : via IO-system (Read only)
MLF : via IO-system (Write only)
3.3 P̲R̲O̲C̲E̲S̲S̲I̲N̲G̲
This chapter contains a detailed 'as built' description of the subsystem SRR. Each procedure
is presented by a brief description and a flow chart.
Fig. 3.3-1 shows an overview block diagram of the subsystem.
The SRR subsystem makes use of the overlay technique which reduces the program memory claim.
( A program is devided into small modules. When one module (i.e. a procedure) has been executed
the next module is fetched and placed in the same memory area. The process area is not affected
by a change of overlay).
The SRR subsystem is divided into 8 overlay modules which are grouped in 3 levels:
Level 1: RMAIN (Main module)
Level 2: SRR ̲INIT (initilization procedure)
R ̲MID (processes retrieval requests with
key a)
RDTGR (processes retrieval requests
with
key b)
RDTGS (processes retrieval requests
with
key c)
RMLOG (processes message log requests)
The procedures are called by RMAIN (except SRR ̲INIT)
Level 3: RPMRF (procedure which accesses MRF
file)
RDTGR (procedure which accesses MRF
file)
The procedures are called by level 2 modules.
When a level 1 overlay (RMAIN) calls a level 2 overlay the label RETURN ̲LABEL ̲MAIN is updated
with an identification of the overlay to be loaded. The label informs the level 1 module
(when it has been loaded again by the label 2 overlay) of which overlay procedure it has
returned from and where to continue processing.
When a level 2 overlay calls a level 3 overlay the label RETURN ̲LABEL ̲SUB is updated with
an identification of the overlay to be loaded.
When the level 3 overlay have been executed the overlay identified by RETURN ̲LABEL ̲MAIN is
loaded. The level 2 overlay just loaded now uses RETURN ̲LABEL ̲SUB to determine where to continue
processing.
E̲r̲r̲o̲r̲ ̲h̲a̲n̲d̲l̲i̲n̲g̲:̲
Normal action: When a monitor returns in the error exit MON ERROR (with parameters identifying
error-code and label) is called and the monitor which failed is called again.
In the flow charts monitor error handling is excluded except in cases which differ from 'normal
action'.
The layout of buffers and data areas, which are mentioned in the flow charts, are described
in detail in Chap. 3.4.
RETRIEVAL SUBSYSTEM, BLOCK DIAGRAM
Fig. 3.3
3.3.1 SRR ̲INIT
Registers: R6: LINK
File descriptors for directories and files used in SRR are found. The MTCB monitor is initialized.
The procedure is only called once: at start or recovery of FIKS system.
When the procedure is executed the main overlay RMAIN is loaded.
SRR-INIT, Flow Chart
Fig. 3.3.1
3.3.2 R̲M̲A̲I̲N̲:̲
When the SRR ̲INIT overlay have finished processing the RMAIN overlay is loaded and an endless
loop is entered.
Processing in RMAIN:
1. Read next queue element.
If retrieval request
Then :
2. Branch to actual procedure
3. Queue MTCB's of retrieved messages
Else 4. Call Message Log procedure
5. Dequeue input queue element
6. Return to 1.
RMAIN FLOWCHART
Fig. 3.3.2
3.3.3. GET ̲RTR ̲Q ̲ELEM
…0e… ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
Registers: R6: LINK
The SRS2 ̲Queue is read and if an element is found.
The MTCB is read.
GET ̲RTR ̲Q ̲ELEM, FLOW CHART
fig.3.3.3
3.3.4 R ̲MID
…0e… ̲ ̲ ̲ ̲ ̲
Registers: R6: LINK
This procedure handles retrieval requests with retrieve key a (message id. + DTG)
The number of messages stored from DTG to (DTG + 1) are found by call of RRDTG which updates
the variables RECORDS (= number of messages) and MRF ̲REC (= record number of 1. message).
Each of the specified records are found and its message id is checked with the requested
message id. If match, the requesting user is checked for security and retrieval rights. If
successful test an MTCB is generated and its id is placed in MTCB ̲LIST: The message id is
placed in the buffer MSG ̲ID ̲BUF:
When all records are checked the overlay RMAIN is loaded.
R-MID, FLOW CHART
Fig.3.3.4
3.3.5 R̲D̲T̲G̲R̲
Registers: R6: LINK
The procedure handles retrieve requests with retrieval key b (DTG range)
The number of messages stored in the specified time interval is found by call of RRDTG (which
updates the variables RECORDS (= no. of records) and MRF ̲REC (= record no of 1. message))
From each MRF record the classification and terminal retrival rights are extracted and checked
with the users classification and terminal number. If succesfull test a MTCB is generated
and the MTCB counter MTCB ̲I is incremented.
All indices of generated MTCB'S are placed in the buffer MTCB ̲LIST. Message id of the retrieved
messages are placed in MSG ̲ID ̲BUF.
When all records are checked (or 11 messages are found) the overlay RMAIN is loaded.
ROTSR, FLOW CHART
FIG. 3.3.5
3.3.6 R̲D̲T̲G̲S̲
Registers: R6: LINK
The procedure handles retrieval requests with retrieval key c ( DTG range + SIC).
The number of messages stored in the specified time interval is found by call of RRDTG (
which updates the variables RECORDS (= no. of records) and MRF ̲REC (= rec.no. of 1. message)).
The SIC's of each of the specified records are checked against the requested SIC's and if
one of them matches the requesting user is checked for security and retrieval rights. If
the test is successful a MTCB is generated and the counter is incremented.
All MTCB id's of generated MTCB's are placed in MTCB ̲LIST buffer and the corresponding Message
id's are placed in MSG ̲ID ̲BUF:
When all records are checked (or when 11 messages are found) the overlay RMAIN is loaded.
RDTGS, FLOW CHART
Fig. 3.3.6
3.3.7 R̲M̲L̲O̲G̲
Registers : R6 : LINK
Processing:
1. The MLF file is reset
2. A DTG range of 24 hours is calculated
3. The MRF records of messages which have been stored in the time span are found.
4. The MRF records are copied from MRF file (or incore MRF buffer) to MLF file
5. The Pseudo MTCB is updated with number of records in MLF file
6. The MTCB is returned to the requestor by call of QACCESS
7. If the MLF cannot contain all records a warning is given by call of MON ERROR
8. The overlay RMAIN is loaded.
RMLOG, FLOW CHART
FIG. 3.3.7
3.3.8 QUEUE ̲MTCBS
…0e… ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
Registers: R6: LINK
All generated MTCB's are queued to requestors queue and each event is logged by call of LOG
̲JOURNAL.
The MTCB's are released.
The indices of the generated MTCB's are delivered in the buffer MTCB ̲LIST.
QUEUE-MTCBS, FLOW CHART
Fig. 3.3.8
3.3.9 DEL ̲RTR ̲Q ̲ELEM
…0e… ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
Registers : R6: LINK
If the request being processed is a Message log the input queue element is deleted and the
procedure is exited.
Otherwise:
The variable ERROR ̲CODE (which have been updated in case of errors during the processing)
is checked and if not zero the Pseudo MTCB is updated with the error code and inserted in
the requestors RD-queue.
The input queue element is deleted and the procedure is exited.
DEL-RTR-Q-ELEM, FLOWCHART
Fig. 3.3.9
3.3.10 R̲R̲D̲T̲G̲
Registers : R6: LINK
The input to this procedure is the 2 variables DTG1 and DTG2 which are set up by the calling
process.
As a result the procedure updates the 2 variables:
RECORDS (= number of messages stored in the time span DTG1 to DTG2)
MRF ̲REC (= record no. of 1. message stored in the DTG span).
The record no. corresponding to DTG1 (=record no. of 1. message stored within this minute)
is found either on DTGF file, in DTGF incore part (the critical region SRS ̲ CR) or in the
buffer RTR ̲DTG ̲BUF (which is maintained by the procedure GET ̲DTG ̲ENTRY). The variable REC1
is updated with the record number found.
In a similar way the record number corresponding to DTG2 is found and the variable REC2 is
updated with the value
.
If the searched DTG is older than the DTG of the oldest message then the REC1 (or REC2) is
updated with the record no. of the oldest message.
If the searched DTG is newer than the DTG of the last stored message then the REC1 (or REC2)
is updated with the record no. of the last stored message + 1. Now RECORDS and MRF ̲REC are
updated:
MRF ̲REC:= REC1 (1.record)
RECORDS:= REC2-REC1 (no. of records)
The process is exited by loading the overlay which loaded this overlay (the overlay is defined
by the label RETURN ̲LABEL ̲SUB) .
RRDTS, FLOW CHART
Figure 3.3.10-1
RRDTS, FLOW CHART
Fig. 3.3.10-2
3.3.11 R̲P̲M̲R̲F̲
Registers: R6: LINK
Main variables used by the procedure
MRF ̲REC : record pointer set up by the calling
process ( The purpose of the procedure is to
find this record)
RTR ̲MRF ̲BUF: a buffer of 16 MRF records with 1. and
last record no. defined by RTR ̲REC ̲MIN and RTR ̲REC ̲MAX.
MRF ̲IND: Record offset to the wanted MRF record in
RTR ̲MFR ̲BUF.
If the record defined by MRF ̲REC is not already present in RTR ̲MRF ̲BUF (changed by previous
retrievals) then it is searched either on MRF disk file or in incore buffer (critical region
SRS ̲CR). When found a range of 16 records including the requested is copied to RTR ̲MRF ̲BUF
and the buffer pointers RTR ̲MRF ̲MIN and RTR ̲MFR ̲MAX are updated. MRF ̲IND is updated to indicate
the record offset of the requested record in RTR ̲MRF ̲BUF.
The procedure is exited by loading the overlay which called the procedure (the overlay is
defined by the label RETURN ̲LABEL ̲SUB).
RPMRF, FLOW CHART
Fig. 3.3.11
3.3.12 TEST-̲TERM
…0e… ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
Registers: R6: LINK
A requestor is permitted retrieval if his security classification is greater than or equal
to that of the found message and if the terminal is included in the address list of the message.
If the requestor is a supervisor only his security is checked.
Information concerning the requestor is found in the pseudo-MTCB containing the request.
Information concerning the message is found in its MRF record.
If both tests are successful the flag F ̲TERM is set ot TRUE.
TEST ̲TERM, FLOW CHART
Fig. 3.3.12
3.3.13 GEN ̲MTCB
…0e… ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
Registers: R6: LINK if error,
LINK + 1 else
A Real MTCB is created and its index copied to the buffer MTCB-LIST. (The offset is MTCB
̲I which have been updated by the calling procedure).
The MTCB is updated with contents from the MRF record of the retrieved message (ref.3.3.11).
If no errors occurred at MTCB creation the procedure is exited and returned in LINK + 1.
In case of errors the exit link is LINK + 0.
SEN-MTCB, FLOW CHART
Fig. 3.3.13
3.3.14 SET ̲DTG ̲ENTRY
…0e… ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
Registers: R0: IN: DTG(LSW) OUT: Record no.
R1: IN: DTG(MSW) OUT: destroyed
R6: LINK
The purpose of this procedure is to maintain the buffer RTR ̲DTG ̲BUF. The buffer contains
a range of 256 entries from the DTGF file and first and last entry are defined by the variables
RTR ̲DTG ̲MIN and RTR ̲DTG ̲MAX.
The procedure is called by RRDTG (ref. 3.3.10) when the DTG specified by R0 and R1 is not
found in RTR ̲DTG ̲BU̲F or in the DTGF incore buffer (critical region SRS ̲CR).
SET ̲DTG ̲ENTRY calculates a range of 256 entries on DTGF disk file which includes the wanted
DTG entry. The range is copied from file to RTR ̲DTG ̲BUF and the pointers RTR ̲DTG ̲MIN and
RTR ̲DTG ̲MAX are updated with DTG of first and last entry.
The entry of the wanted DTG is moved to register R0 and the procedure is exited.
SET ̲DTG ̲ENTRY, FLOW CHART
Fig. 3.3.14
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 forms
the data area (process) of the retrieval subsystem.
The file HDB ̲CONSTS.S contains constants and effects used in the subsystem. This file also
define constants used in the storage submodule.
Besides the process area, the SRR also accesses data in the critical region SRS ̲CR which
is maintained by SRS subsystem.
The critical region contains the incore part of DTGF file, the incore part of the MRF file
and a set of file pointers and other variables used by SRR and SRS. see fig. 3.4-1.
(Further information about SRS ̲CR is found in the storage subsystem ref. V - chapter 3.4
and in FIKS data interface ref.I).
Fig. 3.4-2 shows the layout of a MRF record.
Main buffers:
RTR ̲MRF ̲BUF: contains 16 MRF records. When a MRF record have to be read from file, a range
of 16 records including the wanted record is copied to the buffer. If the retrieval request
being processed includes messages with MRF records included in this range, further disk accesses
are saved.
RTR ̲DTG ̲BUF: contains 256 DTG entries. The maintanence of the buffer is similar to that of
RTR ̲MRF ̲BUF.
Fig. 3.4-1
Layout of SRS ̲CR
Fig. 3.4-2
Layout of MRF Record
Inds`t EDB-tekst
Inds`t EDB-tekst
3.5 S̲T̲O̲R̲A̲G̲E̲ ̲A̲L̲L̲O̲C̲A̲T̲I̲O̲N̲
Program size: 736 words = size of biggest overlay
Process size: 1569 words, page 1 or 2
Disk storage: The overlay SRR ̲INIT.XXXX.C (XXXX=version number) is loaded by ESP at initialization
and is therefore placed in directory MD*FIX ̲CONFIG.D.
The remaining overlays are placed in
*FIXHEAD*MD*SRR ̲OVL.XXXX.D (and in
*MOVHEAD*MD*SRR ̲OVL.XXXX.D for use in the 'Simulated FIXHEAD Configuration').
Overlay names are defined at compiliation time and a change of the File names
will cause errors.
3.6 P̲e̲r̲f̲o̲r̲m̲a̲n̲c̲e̲ ̲c̲a̲r̲a̲c̲t̲e̲r̲i̲s̲t̲i̲c̲s̲
The SRR submodule is considered as a non time critical module and it is loaded as a background
process.
Considerable response time must be expected in some retrieval cases, i.e. a retrieval request
using key C (SIC + DTG range) and without specifying DTG range implies a search of the entire
MRF file.
The SRR can be loaded in several incarnations with different Process names.
3.7 L̲i̲m̲i̲t̲a̲t̲i̲o̲n̲s̲
Message log requests: The MLF file has a fixed length of 300 sectors corresponding to 4800
MRF records. If more than 4800 messages have been stored during the last 24 hours only the
4800 are logged and a warning is logged on operators console. (LOCAL FIXUP)
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 list
Inds`t EDB-tekst
Inds`t EDB-tekst
Inds`t EDB-tekst
Inds`t EDB-tekst
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̲
N.A.
4.2 Q̲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 (SRR.CR0, SRR.CR1, SRR.CP, SRR.L0, SRR.L1)
can be found in FIXLIB source directory for SRR. (ref VI)
Generation of object code file:
o Copy the source directory of the actual SRR version into a work directory
o Activate the command file SRR.CR[
o - - - - SRR.CP
o - - - - SRR.LO
The 10 code files (overlays) are now ready for installation.
The overlay SRR ̲INIT.XXXX.C is installed in
*MOVHEAD*MD*FIX ̲CONFIG.D.
The remaining overlays - RMAIN, R ̲MID, RDTGR, RDTGS,
R ̲RTT, D ̲ANO, RMLOG, RRDTG and RPMRF are copied to directory *FIXHEAD*SRR ̲OVL.XXXX.D and
to
*MOVHEAD*MD*SRR ̲OVL.XXXX.D (XXXX= version number)
L̲i̲s̲t̲i̲n̲g̲s̲
By activating the command file SRR.PP all source code is printed.
