top - download
⟦095684443⟧ Wang Wps File
Length: 43791 (0xab0f)
Types: Wang Wps File
Notes: FIX/1161/PSP/0103
Names: »5270A «
Derivation
└─⟦c5670ecfe⟧ Bits:30006140 8" Wang WCS floppy, CR 0516A
└─ ⟦this⟧ »5270A «
WangText
5270A/516A…86…1
…02… …02… …02…
…02…FIX/1161/PSP/0103
…02…OK/840820…02……02…ii
FIKS TABLE UPDATE PROCESS (TUP)
PRODUCT SPECIFICATION…02…APE/890609…02……02…FIKS
…06…1 …02… …02… …02… …02… …02…
FIKS TABLE UPDATE PROCESS (TUP)
PRODUCT SPECIFICATION
FIX/1161/PSP/0103
AK
FMK
…0e…FMK (5), AK (4)
FIKS
Prgrm.Mgr.
…0e…1.1…0f…
890609
REVISION RECORD
REVISION RECORD
REVISION RECORD
REVISION RECORD
REVISION RECORD
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲…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 ^840820 ^ All ^
First
issue
of
document.
^ ^ ^
1.1 ^890609 ^ DCN 1 ^
Changed
in
accordance
with
Order
no:
15/88
^ ^ ^
^ ^ ^
^ ^ ^
^ ^ ^
^ ^ ^
^ ^ ^
^ ^ ^
^ ^ ^
^ ^ ^
^ ^ ^
^ ^ ^
^ ^ ^
^ ^ ^
^ ^ ^
^ ^ ^
^ ^ ^
^ ^ ^
^ ^ ^
^ ^ ^
^ ^ ^
^ ^ ^
^ ^ ^
^ ^ ^
^ ^ ^
^ ^ ^
^ ^ ^
^ ^ ^
^ ^ ^
^ ^ ^
^ ^ ^
^ ^ ^
^ ^ ^
^ ^ ^
^ ^ ^
^ ^ ^
^ ^ ^
^ ^ ^
^ ^ ^
^ ^ ^
^ ^ ^
T̲A̲B̲L̲E̲ ̲O̲F̲ ̲C̲O̲N̲T̲E̲N̲T̲S̲
1 SCOPE .......................................
1
1.1 INTRODUCTION ...............................
1
2 APPLICABLE DOCUMENTS ........................
2
2.1 SYSTEM SOFTWARE ..........................
2
2.2 FIKS DOCUMENTATION .......................
2
3 MODULE SPECIFICATION ........................
3
3.1 FUNCTIONAL CAPABILITIES ..................
3
3.2 INTERFACE DESCRIPTION ....................
5
3.3 PROCESSING ...............................
8
3.3.1 TUP ̲INIT Overlay .....................
8
3.3.2 TUP Main Overlay ..................... 10
3.3.3 RDFU Overlay ......................... 12
3.3.3.1 Procedure
SET ̲AIG ̲EXIST Processing ......... 14
3.3.3.2 Procedure
SET ̲ANO ̲ADDR Processing .......... 15
3.3.3.3 Procedure
RDF ̲ANO ̲UPDATE Processing ........ 16
3.3.3.4 Procedure
RDF ̲AIG ̲UPDATE Processing ........ 17
3.3.3.5 Procedure CHANGE Processing ...... 18
3.3.4 USPU Overlay ......................... 18
3.3.4.1 Procedure UPDATE ̲USP Processing .. 19
3.3.4.2 Procedure READ ̲PROFILES .......... 22
3.3.4.3 Procedure WRITE ̲USPCOPY .......... 22
3.3.4.4 Procedure FIND ̲USP Processing .... 23
3.4 DATA ORGANIZATION ........................ 24
3.5 STORAGE ALLOCATION ....................... 25
3.6 PERFORMANCE CHARACTERISTICS .............. 25
3.7 LIMITATIONS .............................. 25
3.8 ERROR CODES AND ERROR LABELS ............. 26
4 QUALITY ASSURANCE ........................... 27
5 PREPARATIONS FOR DELIVERY ................... 27
APPENDIX A: DRAWINGS .......................... 28
1 S̲C̲O̲P̲E̲
This document contains an as-built product specification
of the Table Update Process (TUP), which is a process
running on the SCC-sites of the FIKS system.
The document is mainly meant as an aid to persons,
who are going to maintain or extend the TUP-process,
or to persons, who wants detailed insight in it.
1.1 I̲N̲T̲R̲O̲D̲U̲C̲T̲I̲O̲N̲
The TUP process is run on both the SCC sites (in identical
versions). It takes care of updates on the RDF file
and the USP files.
The updates concerns insertions, deletions and corrections
of ANO's and AIG's, (the RDF file) and insertions,
deletions, and corrections of supervisory user security
profiles (the USP files).
The updates are performed on request from other processes
(control messages initiated by local or remote TUPINT
process).
Similar functions are on the N/M's carried out by the
SAF process, and therefore some of the procedures in
the two processes are identical.
2 A̲P̲P̲L̲I̲C̲A̲B̲L̲E̲ ̲D̲O̲C̲U̲M̲E̲N̲T̲S̲
2.1 S̲Y̲S̲T̲E̲M̲ ̲S̲O̲F̲T̲W̲A̲R̲E̲
1. CR80 AMOS KERNEL
Product Specification
CSS/302/PSP/0008
2. CR80 AMOS, FILE MANAGEMENT SYSTEM
System Product Specifications
CSS/920/SPS/0001
3. CR80 AMOS I/O SYSTEM
Product Specification
CSS/006/PSP/0006
4. CR80 COMPUTER HANDBOOK
2.2 F̲I̲K̲S̲ ̲D̲O̲C̲U̲M̲E̲N̲T̲A̲T̲I̲O̲N̲
5. REQUIREMENTS SPECIFICATION
FIX/0000/SPC/0002
Vol I-III, issue 5, 800310
6. FIKS DATA INTERFACE REFERENCE
FIX/0100/MAN/0004
7. MTCB MONITOR PSP
FIX/1256/PSP/0006
8. QACCESS MONITOR PSP
FIX/1256/PSP/0078
9. RDF MONITOR PSP
FIX/1256/PSP/0081
10. SAF PSP
FIX/1155/PSP/0088
11. NODAL SWITCH SUBSYSTEM PSP
FIX/1154/PSP/0107
12. NOP PSP
FIX/1161/0071
13. SPU PSP
FIX/1161/0095
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 functions of the TUP process is to perform updates
of the USP files and the RDF file.
The updates are performed when a request for a specific
update is received in a control message in the TUP
input queue. The requests for updates are initiated
by either the local SCC operator or by an operator
on the other SCC.
The types of updates concerning the USP files can be
a deletion, correction, or insertion of a user security
profile. One USP file exists for each N/M in the system
and one USP file exists for the local SCC. On receipt
of a USP update request, the USP-file of the N/M, on
which the user to be updated belongs to, is accessed
and the profile is updated.
The types of updates concerning the RDF file can be
a correction, deletion, or insertion of an AIG or of
an ANO.
In case of an AIG update, the new AIG mask will be
contained in the received control message. This mask
is copied into the RDF file at the correct offset.
In addition the AIG existence bit map (which is a
table containing one bit for all possible AIG's in
the FIKS system) is accessed, and the bit describing
the existence of the AIG in question is set (if it
is an update or correction) or reset (if it is a deletion).
In case of an ANO update, the ANO existence table (the
bit map describing the existence of ANO's), the terminal
table (a table describing which terminal number is
attached to the ANO) and the Danish and English plain
addresses are updated in the RDF file. In case the
update is of type deletion, the existence bit is reset
and space characters are inserted as Danish and English
plain addresses.
When an update has been performed, the TUP process
will do nothing but wait for another update request
message to appear in the TUP input queue.
As mentioned above, the requests for updates are initiated
by a SCC operator, and then handled by the TEP ̲INT
process which is the terminal process of the SCC.
In case of a USP update, the request is by TEP ̲INT
transferred to the SPU process (ref. 13). SPU transfers
the request to the NOP process, ref. 12, which generates
the control message (as it is received by TUP). NOP
queues the control message to NSS and the NSS will
(according to the routing mask set up by NOP) send
one copy to the local TUP process and (via the NSS
of the remote SCC) one copy to the TUP process on the
other SCC. Furthermore it will send one copy to the
SAF process of the N/M on which the updated user belongs
to.
In case the SCC operator initiates a RDF update, the
TEP ̲INT process will deliver the request to NOP. NOP
will generate a control message (as it is received
by TUP) and queue it to the NSS. The NSS will (according
to the routing mask set up by NOP) send one copy to
the local SCC, one copy to the remote TUP (via the
NSS of the other SCC) and one copy to each of the SAF
processes on the N/M's (via the local NSS of the N/M).
3.2 I̲N̲T̲E̲R̲F̲A̲C̲E̲ ̲D̲E̲S̲C̲R̲I̲P̲T̲I̲O̲N̲
Figure 3.2-1 in Appendix A shows the interfaces of
the TUP process, and below is listed the types of interfaces
used.
The format of the data exchanged between TUP and other
processes are given in the Data Interface Reference,
ref. 6.
The letters below refer to Figure 3.2-1.
a. N̲C̲S̲
TUP receives control messages from the NSS process.
These messages are initiated either on the remote
or on the local SCC and concerns requests for update
of RDF and USP files.
The communication is one directional: No messages
are sent from TUP to the NSS and no acknowledgements
are given for messages received by TUP. The communications
between NCS and TUP takes place via the QACCESS
and MTCB monitor. A real MTCB with a file attached
to it (the control message) is transferred to the
TUP by entering the index of the MTCB into the
TUP input queue. QACCESS will send an AMOS signal
(ref. 1.) to the TUP process. This signal triggers
the TUP process to read the queue element and the
MTCB block.
b. R̲D̲F̲ ̲f̲i̲l̲e̲
The Routing Directory File (RDF), which is located
on the FIXHEAD disk volume, is accessed by TUP.
TUP reads and writes from/to the RDF file when
the operator requests for updates of ANO's and
AIG's.
The layout of the RDF file is shown in the Data
Interface Reference, ref. 6. The reading and writing
take place by calls of monitor procedures in the
IO system, ref. 3, which transfers the requests
to the File Management System, FMS, ref. 2.
c. U̲S̲P̲ ̲f̲i̲l̲e̲s̲
Nine USP files are accessed by the TUP process.
One for each N/M in the FIKS system (USPA, USPB,
....USPN) and one for the SCC (USP). The files
contain the user id's and user security profiles
for all supervisors on a specified site.
The files are located on the MOVHEAD disk volume
in the main directory and they are accessed, when
requests concerning USP updates are received.
(One USP update request implies update on one USP-file).
The files are accessed (reading and writing) by
calls of monitor procedures in the IO system as
described in b.
d. R̲D̲F̲ ̲d̲a̲t̲a̲ ̲a̲r̲e̲a̲
In the RDF data area a piece of the RDF file is
located (and normally used by the RDF monitor in
order to save disk accesses), and when RDF file
updates are performed, the affected data in the
RDF data area are modified. The data area is accessed
directly by the TUP process or by call of the RDF
monitor procedures.
e. Q̲A̲C̲C̲E̲S̲S̲ ̲d̲a̲t̲a̲ ̲a̲r̲e̲a̲
The QACCESS data area contains all queues (and
queue elements) on the SCC. When an AMOS signal
is sent from the QACCESS monitor to TUP, the TUP
input queue is accessed by call of QACCESS, READ
̲GR ̲ELEM. When the element in the queue has been
processed, it is deleted by TUP by call of QACCESS,
DEL. The elements in the TUP input queue (which
is a precedence queue, ref. 8) are inserted by
NSS.
f. M̲T̲C̲B̲ ̲m̲o̲n̲i̲t̲o̲r̲ ̲d̲a̲t̲a̲ ̲a̲r̲e̲a̲
The MTCB monitor is called, when a queue element
has been read in the TUP queue. The MTCB block
is delivered to the TUP process and the file attached
to the MTCB is opened by call of MTCB, GET ̲FILE.
Later on, when the message is processed, the MTCB
element and the file is released by calls of MTCB
monitor procedures.
g. C̲O̲N̲F̲I̲G̲ ̲c̲r̲i̲t̲i̲c̲a̲l̲ ̲r̲e̲g̲i̲o̲n̲
Data in the CONFIG critical region concerning the
RDF data area are read by TUP. These data are
needed in order to access the RDF data area, ref.
d.
The CONFIG data are read directly (without using
critical region monitor procedures).
3.3 P̲R̲O̲C̲E̲S̲S̲I̲N̲G̲
This chapter describes in details the TUP modules.
Each module is described in a separate chapter, and
if any procedures are used by the module, these are
described in sub-chapters.
The TUP process is implemented as an overlay program,
where the program area is overlayed, and the process
area, which remains in memory, is common for all overlay
modules.
Figure 3.3-1 in Appendix A shows a block diagram of
the TUP process.
The TUP overlay is the main (or master) overlay of
the program. This overlay is the one, which resides
in the memory in idle situations, and it receives messages
from the outside world and takes action on them. If
the processing of a received message requires processing
by one of the overlays USPU or RDFU, the appropriate
overlay is entered. When the task is finished, the
TUP overlay is again entered, and the next event is
awaited.
No exchange of data is made between the "slave" overlays
TUP ̲INIT, RDFU, and USPU. Communication only exists
between the "master" overlay and the "slave" overlay.
3.3.1 T̲U̲P̲ ̲I̲N̲I̲T̲ ̲O̲v̲e̲r̲l̲a̲y̲
TUP ̲INIT is the first TUP overlay running after a start-up
of the SCC. The overlay program is loaded (as a normal
program) by the ESP process.
Its functions are to initialize the TUP (open files
etc.) and when it has finished executing, the main
overlay TUP is entered.
T̲h̲e̲ ̲p̲r̲o̲c̲e̲s̲s̲i̲n̲g̲ ̲i̲s̲ ̲a̲s̲ ̲f̲o̲l̲l̲o̲w̲s̲:
- The disk volume MOVHEAD is opened by call of MON
IO, GETROOT.
- The disk volume FIXHEAD is opened by call of MON
IO, GETROOT.
- A "log on" is made to the MTCB monitor by call
of MON MTCB, INITE.
(A data area in the MTCB ̲DATA area of the monitor
is allocated for the TUP process, and file descriptors
to MOVHEAD and FIXHEAD are stored in order to be
used at future calls of the MTCB monitor from TUP).
- The FIXHEAD volume is closed by call of MON IO,
DESCENT. (The only purpose of opening the volume
is that the file description of the volume is a
parameter used in the "log on" of the MTCB monitor).
- The directory FIX ̲CONFIG.D on MOVHEAD volume is
opened by call of MON IO, LOOKUP.
- The directory TUP ̲OVL.XXXX.D (residing in the directory
FIX ̲CONFIG.D) is opened by call of MON IO, LOOKUP.
(XXXX is the current version number of the TUP
program). In this directory, the code files for
all overlays (except TUP ̲INIT reside. The file
descriptor of the directory must be used each time
a new overlay is entered.
- The main overlay TUP is entered. (The overlay
file is opened and the monitor procedure OVERLAY
is called).
3.3.2 T̲U̲P̲ ̲M̲a̲i̲n̲ ̲O̲v̲e̲r̲l̲a̲y̲
TUP is the main overlay program of the TUP process.
All overlays except TUP ̲INIT are entered by this program
and when they have finished execution, the TUP overlay
is entered again.
The first time TUP is entered, is when TUP ̲INIT (which
was loaded by the ESP process at startup of the SCC)
has finished processing.
The TUP overlay will remain in memory until a queue
element arrives in the TUP input queue, and the element
indicates an event, which must be handled by one of
the overlays.
T̲h̲e̲ ̲p̲r̲o̲c̲e̲s̲s̲i̲n̲g̲ ̲i̲n̲ ̲T̲U̲P̲ ̲i̲s̲ ̲a̲s̲ ̲f̲o̲l̲l̲o̲w̲s̲:
1. The buffer FILE ̲NAME is reset. (Used later on
for constructing name of overlay file).
2. The variable RETURN is inspected. The value tells
TUP whether it is the first time, the overlay is
entered after startup (RETURN = 0) or not.
If the value is zero it is set to one and a jump
is made to step 4.
3. If the value of RETURN is one, the first element
in the TUP input queue is deleted. (The element
was processed by the overlay which entered the
TUP overlay, and is now deleted).
4. The TUP overlay enters a wait state, by call of
MON WAITEVENT. The event awaited is a "signal"
from the QACCESS monitor, which indicates, that
an element has arrived in the TUP input queue.
5. The first queue lement in the TUP queue is read
(nondestructively). If the queue is empty, a jump
is made to step 4.
6. The MTCB block of the queue element is read (by
call of MON MTCB, GETFILE).
7. The parameter defining the length of the file is
extracted from the MTCB block. The file is read
and copied to the IOBUFFER by call of MON IO, READBYTES.
8. The contents of the file will always be a control
message. The parameters CAT and SUBCAT which defines
the type of control message, are extracted from
IOBUFFER and inspected. The file is closed again
by call of MON MTCB, RELEASEFILE.
9. The only legal value of CAT is TABLE ̲UPDATE. If
another value is detected, the control message
is ignored and a jump is made to step 1.
10. If the value of SUBCAT is AIGCOR, AIGINS, AIGDEL,
ANOCOR, ANOINS, or ANODEL (indicating a request
for correction, insertion or deletion of a specified
AIG or ANO) the overlay file name RDFU is built
in the FILE ̲NAME buffer.
If the value of SUBCAT is USPCOR, USPINS, or USPDEL
(indicating a request for correction, insertion,
or deletion of a terminal user profile) the overlay
file name USPU is built in the FIlE ̲NAME buffer.
If SUBCAT does not contain any of the above-mentioned
values, the control message is ignored and a jump
is made to step 1.
11. The overlay, the name of which is given by
FILE ̲NAME is entered.
3.3.3 R̲D̲F̲U̲ ̲O̲v̲e̲r̲l̲a̲y̲
The RDFU overlay is activated when a control message
containing a RDF update request is received in the
TUP input queue. The type of updates are:…06…W
…02… …02… …02… …02…
Correction of an AIG
Insertion of an AIG
Deletion of an AIG
Correction of an ANO
Insertion of an ANO
Deletion of an ANO
The updates are performed both in the RDF file and
in the incore data area of the RDF monitor.
The updates are initiated by a SCC operator. If the
SCC operator is local, a copy of the control message
is sent to the remote SCC (the TUP) and to all N/M's
in the FIKS system. On the N/M's the control messages
are received by the SAF processes, which performs the
updates exactly as in the TUP. Therefore, some of
the procedures used by the RDFU overlay are identical
to the ones used by the RDFU overlay of the SAF process.
T̲h̲e̲ ̲p̲r̲o̲c̲e̲s̲s̲i̲n̲g̲ ̲i̲n̲ ̲R̲D̲F̲U̲ ̲i̲s̲ ̲a̲s̲ ̲f̲o̲l̲l̲o̲w̲s̲:
1. The FIXHEAD disk volume is opened by call of MON
IO, GETROOT.
2. The RDF file on the FIXHEAD volume is opened by
call of MON IO, LOOKUP.
3. The semaphore bit of the RDF monitor (located in
the RDF data area) is reserved by call of MON RDF,
RESERVE ̲RDF ̲SEMAPHORE. This reservation prevents
other users of the RDF monitor from accessing data
which are being updated (and therefore may be inconsistent).
4. The control message which was received by the TUP
overlay and copied into the IOBUFFER is accessed
and the SUBCAT parameter is inspected.
5. If subjects to be handled is an AIG the following
steps are performed.:
- The AIG is extracted from IOBUFFER.
- If type of update is AIGINS or AIGDEL, the
AIG is copied to a work area for later use.
The procedure SET ̲AIG ̲EXIST is called (with
a parameter telling whether the AIG should
be deleted or inserted). This procedure sets
or resets the bit in the AIG existence map
corresponding to the AIG in question, ref.
chapter 3.3.3.1.
- For both deletion, insertion, or correction,
the procedure RDF ̲AIG ̲UPDATE is called. This
procedure updates the RDF file, ref. 3.3.3.4.
6. If the SUBCAT parameter in the control message
identifies a correction, insertion, or deletion
of an ANO, the following steps are performed:
- The ANO is extracted from IOBUFFER.
- If the type of update is ANOINS or ANODEL,
the ANO is copied to a work area used by the
RDF monitors. The monitor procedure MON RDF,
SANOEX is called with a reference to the work
area and a parameter describing whether the
update is deletion or insertion. The procedure
will update the ANO existence map in the RDF
data area. (The bit corresponding to the specified
ANO, will be set if it is an insertion. Otherwise
it will be reset).
- The terminal number (corresponding to the ANO)
is extracted from IOBUFFER.
- The procedure RDF ̲ANO ̲UPDATE is called (ref.
3.3.3.3). The parameters given in the call
are: a parameter telling whether it is a deletion
or not, the type of update (insert, correct,
delete) the terminal number. (The procedure
makes the update on the RDF file in the same
way as it was done in the incore RDF area,
see above).
- The Danish plain address of the ANO is extracted
from the IOBUFFER and copied to a work area.
- The procedure SET ̲AND ̲ADDR is called with a
reference to the plain address and a flag,
which indicates that a Danish update is requested.
Furthermore, a parameter telling whether it
is a deletion or not is transferred. The procedure
performs the update on the RDF file, ref. 3.3.3.2.
- The 2 steps above is now performed with the
English plain address.
7. The RDF semaphore bit (ref. step 3) is released
by call of MON RDF, RELEASE ̲RDF ̲SEMAPHORE. The
RDF data are now available for other processes
again.
8. The TUP overlay program is entered.
3.3.3.1 P̲r̲o̲c̲e̲d̲u̲r̲e̲ ̲S̲E̲T̲ ̲A̲I̲G̲ ̲E̲X̲I̲S̲T̲ ̲P̲r̲o̲c̲e̲s̲s̲i̲n̲g̲
This procedure is called from the RDFU overlay in case
that an AIG is requested to be updated.
Input to the procedure is the AIG word and the type
of update (insert, correct, or delete).
The purpose of the procedure is to change the bit in
the AIG existence map, which identifies the AIG as
existing or not existing (bit is zero).
The bitmap resides in the data areas of the RDF monitor.
The procedure CHANGE (ref. 3.3.3.5) is called and the
offset in the incore RDF data area to the AIG existence
table is calculated. The bit in the existence table
describing the actual AIG is accessed and if the type
of update is AIGCOR or AIGINS, the bit is set. Otherwise
(type = AIGDEL) the bit is reset.
The SET ̲AIG ̲EXIST procedure is identical to the procedure
of the same name in the SAF Process.
3.3.3.2 P̲r̲o̲c̲e̲d̲u̲r̲e̲ ̲S̲E̲T̲ ̲A̲N̲O̲ ̲A̲D̲D̲R̲ ̲P̲r̲o̲c̲e̲s̲s̲i̲n̲g̲
This procedure is called from the RDFU overlay with
the input parameters: ANO, update type (insert, correct,
or delete), plain address and address type (Danish
or English).
The purpose of the procedure is to insert or delete
the specified plain address for the specified ANO in
the RDF file. The function is performed without using
the RDF monitor procedures.
T̲h̲e̲ ̲p̲r̲o̲c̲e̲s̲s̲i̲n̲g̲ ̲i̲s̲ ̲a̲s̲ ̲f̲o̲l̲l̲o̲w̲s̲:
1. The RDF data area is accessed (Procedure CHANGE)
and the file offset to the address table of the
N/M in question is calculated. (Please note that
the size of the N/M address table of a normal N/M
is different from that of a NATO destination).
2. If the text is to be updated in the English version,
an extra offset is added (the size of the Danish
text string).
3. If the type of update is "delete", space characters
are filled into the buffer, which is going to be
copied to file.
4. The plain text is copied to the RDF file at the
calculated offset.
The SET ̲ANO ̲ADDR procedure is identical to the procedure
of the same name in the SAF process.
3.3.3.3 P̲r̲o̲c̲e̲d̲u̲r̲e̲ ̲R̲D̲F̲ ̲A̲N̲O̲ ̲U̲P̲D̲A̲T̲E̲ ̲P̲r̲o̲c̲e̲s̲s̲i̲n̲g̲
This procedure is called from the RDFU overlay with
the input parameters: ANO to be updated, corresponding
terminal number, update type (insert, correct or delete).
The procedure updates the relationship between ANO
and terminal number, and the ANO existence map on the
RDF file.
T̲h̲e̲ ̲p̲r̲o̲c̲e̲s̲s̲i̲n̲g̲ ̲i̲s̲ ̲a̲s̲ ̲f̲o̲l̲l̲o̲w̲s̲:
1. The RDF file offset to the ANOTAP table of the
N/M in question is calculated. (This table contains
the relationship between ANO number and terminal
ID). (Please note, that the offset to a ANOTAB
table is calculated in another way than that of
a NATO destination (due to the different sizes
of the tables).
2. The input parameter Terminal No. is returned and
copied to the ANO entry in the RDF file. (If the
type of update is ANODEL, a zero is copied to the
file).
3. The offset to the ANO existence table corresponding
to the N/M in question is calculated.
4. The word in the existence map holding the bit of
the specified ANO is read from file.
5. If the type of update is ANOCOR or ANOINS the bit
is set. If the type of update is ANODEL, the bit
is reset.
6. The word is copied back to the RDF file.
The RDF ̲ANO ̲UPDATE procedure is identical to the procedure
with the same name in the SAF process.
3.3.3.4 P̲r̲o̲c̲e̲d̲u̲r̲e̲ ̲R̲D̲F̲ ̲A̲I̲G̲ ̲U̲P̲D̲A̲T̲E̲ ̲P̲r̲o̲c̲e̲s̲s̲i̲n̲g̲
The procedure is called from the RDFU overlay with
the input parameters: AIG, AIG-bitmask, type of update
(insert/correct or delete). The procedure will copy
the new AIG mask into the RDF file and update the AIG
existence table. (For "insert/correct", the AIG bit
is set and for "delete", the bit is reset).
T̲h̲e̲ ̲p̲r̲o̲c̲e̲s̲s̲i̲n̲g̲ ̲i̲s̲ ̲a̲s̲ ̲f̲o̲l̲l̲o̲w̲s̲:
1. The offset in the RDF file to the mask of the specified
AIG is calculated (using the parameters in the
RDF data area).
2. The AIG mask (in the IOBUFFER) is copied into the
RDF file at the calculated offset.
3. The offset in the RDF file to the AIG existence
table (a table holding a bit for each AIG) is calculated.
4. The word in the existence map holding the bit of
the specified AIG is read from file.
5. If the type of update is "insert/correct" the bit
is set. Otherwise (type = "delete") the bit is
reset.
6. The word is copied back to the RDF file.
The RDF ̲AIG ̲UPDATE procedure is identical to the procedure
with the same name in the SAF process.
3.3.3.5 P̲r̲o̲c̲e̲d̲u̲r̲e̲ ̲C̲H̲A̲N̲G̲E̲ ̲P̲r̲o̲c̲e̲s̲s̲i̲n̲g̲
This procedure is used by all procedures belonging
to the RDFU overlay,
The purpose of it is to set up the parameters to be
used, when the RDF data area and the RDF file tables
are to be accessed without using the normal RDF monitor
procedures.
The procedures reads the RDF configuration parameters
in the critical region CONFIG (defining the location
of the incore data area of the RDF monitor) and sets
up the pointers to be used when the RDF data area is
accessed.
3.3.4 U̲S̲P̲U̲ ̲O̲v̲e̲r̲l̲a̲y̲
This overlay performs updates of the user profile table
on request from either the local SCC operator or from
the remote SCC. For each N/M in the FIKS system, the
SCC has a disk file containing the user security profiles
of all the supervisors on the actual N/M. The names
of the files are USPA, USPB, USPE, USPF, USPH, USPK,
USPL, USPN. The file USP contains the profiles for
the operators on the local SCC.
The supervisory profiles of the N/M's can only be updated
by a SCC operator, while the normal operator profiles
of the N/M's can only be updated by the local N/M supervisor.
When a SCC supervisor performs an update of a N/M supervisor
the control message which was received by TUP is sent
in a copy to the N/M in question and to the remote
SCC.
The USPU overlay is entered when a control message
has been received by the TUP overlay and recognized
as a request for a USP update. Before the USPU overlay
is entered, the control message is copied to the IOBUFFER.
The user ID, security profile and the kind of update
is extracted from IOBUFFER and transferred to the procedure
UPDATE ̲USP (ref. 3.3.4.1) which performs the update.
When the update has been performed, the TUP overlay
is entered again.
3.3.4.1 P̲r̲o̲c̲e̲d̲u̲r̲e̲ ̲U̲P̲D̲A̲T̲E̲ ̲U̲S̲P̲ ̲P̲r̲o̲c̲e̲s̲s̲i̲n̲g̲
This procedure is called from the USPU overlay and
it performs updates on a specified USP file.
Two internal procedures READ ̲PROFILES (ref. chapter
3.3.4.2) and WRITE ̲USPCOPY (ref. chapter 3.3.4.3) are
used. In addition the external procedure FIND ̲USP
(ref. chapter 3.3.4.4) is used.
The type of update to be performed is defined by the
parameter OPCODE ̲ADDR which holds a pointer to the
parameter defining the type of update (insert, correct
or delete).
T̲h̲e̲ ̲p̲r̲o̲c̲e̲s̲s̲i̲n̲g̲ ̲i̲n̲ ̲U̲P̲D̲A̲T̲E̲ ̲U̲S̲P̲ ̲i̲s̲ ̲a̲s̲ ̲f̲o̲l̲l̲o̲w̲s̲:
1. The USP file is opened by call of FIND ̲USP. This
procedure checks on which site the user belongs
to and opens the USP file of that site.
2. The table containing user Id's is read from USP-file.
3. If the requested type of update is INSERT and the
last entry in the user Id table is occupied (not
zero) the completion code (no insertions allowed,
file is full) is set up and the procedure is exited.
4. The file USP ̲COPY in which the updates takes place
is opened. If the USP ̲COPY file does not exist,
the USP ̲OLD file is opened and then renamed to
USP ̲COPY. (The reason for this file name confusion
is given en chapter 3.3.4.4).
5. The USP ̲COPY file is reset.
6. The type of update is determined, and if INSERT,
the following steps are performed:
- The user ID, which is going to be inserted
is fetched and checked against the entries
in the user ID table. (The ID's in the table
are in alphabetical order and the new ID must
be inserted in accordance with this sequence).
The first 2 characters of the new ID are checked
against the first 2 characters of all user
ID's in the table. If a match is found, the
two last characters of each ID are compared.
If match, the ID must be inserted right after
the current ID in the table. Otherwise, if
the value of the new ID is less than the value
of the current ID, it must be inserted in front
of the current ID.
If no match is found in comparison of the 2
first characters, the new ID must be inserted
in front of the first ID in the table of which
the 2 first characters have a bigger value
than the 2 first characters of the ID to be
inserted.
- When the correct entry for the new ID is found,
all succeeding entries in the table are moved
one entry and the new entry is then inserted.
7. If the type of update is DELETE or CORRECT, the
following steps are performed:
- The ID to be updated is searched in the table.
(A check is made on the first 2 characters,
and if a match is found, the last 2 characters
are checked).
- If no match is found and update type is DELETE,
the file USP and USP ̲COPY are closed and the
procedure is exited (with completion code =
OK).
- If no match is found and the update type is
CORRECT, the update type is changed to INSERT
and a jump is made to step. 6. (If the ID
to be corrected is not found, an insertion
of the ID is performed).
8. If the type of update is DELETE, all ID's following
are to be deleted or moved one entry backwards,
and the last entry in the table is reset.
9. The update concerning user ID is now complete and
the user ID table is copied to the USP ̲COPY file.
10. The entry number of the current user ID is calculated.
The profile table is devided into sections and
the section number to which the current ID belongs
is calculated.
The steps 11-15 are repeated until all 4 sections
of the profile table are treated.
Current section is set to one.
11. If current section contains the section to be
updated and the update type is INSERT the following
steps are performed:
- The profiles laying in the area from start
of current section until the profile number
to be updated is copied into IO ̲BUFF by call
of READ ̲PROFILES (chapter 3.3.4.2). The profile
to be inserted is appended to the profiles
in IO ̲BUFF. The profiles (including the inserted
profile) are copied to USP ̲COPY file by call
of WRITE ̲USPCOPY.
- The remaining part of current section is read
from USP and appended to the USP ̲COPY-file.
12. If current section does n̲o̲t̲ contain the profile
to be updated and the update type is INSERT the
following steps are performed:
- The profiles of current section are read.
- The same profiles are appended to the USP
̲COPY file.
13. If current section is the section to be updated
and type of update is DELETE, the following steps
are performed:
- The profile from the beginning of the section
and until the entry to be deleted are read
from USP and appended to USP ̲COPY.
- The rest of the profiles in current section,
except the one to be deleted are read from
USP and appended to USP ̲COPY.
14. If current section does n̲o̲t̲ contain the section
to be deleted the profiles are read and then appended
to USP ̲COPY.
15. If update mode is CORRECT the current section
is read into IO ̲BUFF.
If current section contains the profile to be
corrected the actual profile is copied into IO
̲BUFF.
The IO ̲BUFF is appended to USP ̲COPY file.
16. The update of user ID and profile is now complete
and the remaining processing concerns renaming
and closing of files.
17. The file USP is renamed to USP ̲OLD.
18. The file USP ̲COPY is renamed to USP.
19. The file USP ̲OLD is renamed to USP ̲COPY.
20. The files USP and USP ̲COPY are closed (dismantled).
The steps 16-19 ensures that the updated file is not
lost, even if a system crash takes place when renaming
the files.
3.3.4.2 P̲r̲o̲c̲e̲d̲u̲r̲e̲ ̲R̲E̲A̲D̲ ̲P̲R̲O̲F̲I̲L̲E̲S̲
The profiles specified by input parameters (from profile
No. to profile No.) are read from USP file into IO
̲BUFF.
3.3.4.3 P̲r̲o̲c̲e̲d̲u̲r̲e̲ ̲W̲R̲I̲T̲E̲ ̲U̲S̲P̲C̲O̲P̲Y̲
The profiles specified by input parameters (from profile
No. to profile No.) are appended to the file USP ̲COPY.
3.3.4.4 P̲r̲o̲c̲e̲d̲u̲r̲e̲ ̲F̲I̲N̲D̲ ̲U̲S̲P̲ ̲P̲r̲o̲c̲e̲s̲s̲i̲n̲g̲
FIND ̲USP is a utility procedure used in connection
with the USPU overlay. (The procedure is called from
procedure UPDATE ̲USP).
The purpose of this procedure is to calculate the name
of a USP file and then open it.
The name of the file is a four letter word with the
3 first letters being USP. The 4th letter which is
the letter of the N/M in question is extracted from
the input control message (IOBUFFER) and appended to
the name. If the N/M ID is either "P" or "Q" (identifying
a SCC) the 4th letter is zero. The possible file names
are then: USPA, USPB, USPE, USPF, USPH, USPK, USPL,
USPN, USP.
The USP files are located on the MOVHEAD disk volume
in the main directory. If the file is not found the
file USP ̲OLD is opened and renamed to the actual name
(USPA/USPB etc.). In normal cases the file will exit.
When updating the contents of a USP-file (USPX) the
file is copied to the file USP ̲COPY in which the updates
takes place. When the updates are performed, the USPX
file is renamed to USP ̲OLD and the USP ̲COPY file is
renamed to USPX (where X is the N/M ID or zero). If
the system goes down in the timespan between the renaming
of USPX and the renaming of USP ̲COPY the name of the
file after a recovery will be USP ̲OLD.
When the FIND ̲USP procedure has been executed this
situation is recovered.
T̲h̲e̲ ̲p̲r̲o̲c̲e̲s̲s̲i̲n̲g̲ ̲i̲s̲ ̲a̲s̲ ̲f̲o̲l̲l̲o̲w̲s̲:
1. The IOBUFFER (in which the control message is located)
is accessed and the letter identifying the N/M
of which the update concerns is extracted. The
letter is appended to the file name USP. If the
letter is either a "P" or a "Q" (one of the SCC's)
the 4th letter is set to zero. The possible file
names are then USPA, USPB, USPE, USPF, USPH, USPK,
USPL, USPN, USP. (The generated file name is in
the following called USPX).
2. The USPX file is opened.
3. If the USPX file does not exist the USP ̲OLD file
is opened and then renamed to USP.
4. The parameters returned to the calling procedure
are:
- File description of the USPX file.
- Completion code 1 = the USPX file was found
and opened.
Completion code 2 = neither USPX or USP ̲OLD
was found.
Completion code 3 = the USP ̲OLD file was found,
opened, and renamed to USPX.
3.4 D̲A̲T̲A̲ ̲O̲R̲G̲A̲N̲I̲Z̲A̲T̲I̲O̲N̲
Most of the data of the TUP process are contained in
one big array: DATA. Pointers to specific entries
in the array are set up. The interpretion of the different
entries are defined by record type declarations, and
the data are accessed using indirect addressing with
the pointers.
The variables and pointers are defined in the source
file TUP ̲VAR.S. The type declarations etc. are defined
in the source file TUP ̲PREFIX.S.
3.5 S̲T̲O̲R̲A̲G̲E̲ ̲A̲L̲L̲O̲C̲A̲T̲I̲O̲N̲
The memory claim for the TUP program corresponds to
the size of the program area of the biggest of the
overlays. The process area memory claim corresponds
to the size of the TUP process area.
The exact figures may be obtained by inspecting the
linker printout of the overlays. The size of the process
area will here be found in the link printout of the
TUP ̲INIT overlay. The size required to the program
area is found as the biggest of the program sizes given
in the link printout.
Please note that the program area reserved in memory
is defined by linker input parameter "OVERLAY". This
parameter should be as small as possible but larger
than or equal to the largest overlay.
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̲
As the TUP process is run as an overlay process and
in addition requires many (time consuming) disk accesses,
the processing may seem slow. However, the TUP process
is seldom active and therefore does not decrease the
overall performance of the SCC.
3.7 L̲I̲M̲I̲T̲A̲T̲I̲O̲N̲S̲
N/A
3.8 E̲R̲R̲O̲R̲ ̲C̲O̲D̲E̲S̲ ̲A̲N̲D̲ ̲E̲R̲R̲O̲R̲ ̲L̲A̲B̲E̲L̲S̲
Most of the error codes are completion codes returned
when external procedures (I/O procedures, FIKS monitor
procedures etc.) have been called.
L̲a̲b̲e̲l̲ ̲ ̲ ̲ ̲M̲o̲d̲u̲l̲e̲/̲P̲r̲o̲c̲e̲d̲u̲r̲e̲ ̲ ̲ ̲R̲a̲i̲s̲e̲d̲ ̲b̲y̲ ̲c̲a̲l̲l̲ ̲o̲f̲
31 RDFU RDF ̲AIG ̲UPDATE
32 RDFU IO, GETROOT (FIXHEAD)
33 RDFU IO, DESCENT (RDF file)
34 RDFU RDF ̲ANO ̲UPDATE
35 RDFU SET ̲ANO ̲ADDR (Danish addr.)
36 RDFU SET ̲ANO ̲ADDR (English addr.)
37 RDFU IO, DISMANTLE (RDF file)
41 USPU UPDATE ̲USP
99 All overlays IO, LOOKUP (TUP)
101 TUP ̲INIT IO, GETROOT (MOVHEAD)
102 TUP ̲INIT IO, GETROOT (FIXHEAD)
103 TUP ̲INIT MTCB, INITE
104 TUP ̲INIT IO, DISMANTLE (FIXHEAD)
105 TUP ̲INIT IO, LOOKUP (FIX ̲CONFIG.D)
106 TUP ̲INIT IO,
201 TUP QACCESS, DEL (TUP-queue)
202 TUP QACCESS, READ ̲GR ̲EL (TUP-queue)
203 TUP MTCB, READ
206 TUP MTCB, GETFILE (CTRL msg.)
207 TUP IO, READBYTES (CTRL msg.)
211 TUP MTCB, RELEASEFILE (CTRL msg.)
212 TUP IO, LOOKUP (overlay file)
4 Q̲U̲A̲L̲I̲T̲Y̲ ̲A̲S̲S̲U̲R̲A̲N̲C̲E̲
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̲
When installing the TUP module, the following procedure
is followed:
1. Copy the TUP directory to a work directory.
2. Activate the command file TUP.CR[
3. - - - - TUP.CP
4. - - - - TUP.L[
5. Copy the file TUP ̲INIT.C into the directory FIX
̲CONFIG.D on the SCC and rename it to TUP ̲INIT.XXXX.C,
where XXXX = version number.
6. Edit all ESP command files (SCC, SCC ̲COLD etc.)
(Version number of TUP ̲INIT is updated).
7. Create the directory TUP ̲OVL.XXXX.D in the directory
FIX ̲CONFIG.D
8. The files TUP.C, RDFU, USPU are copied from the
work directory into the directory created in step
7.
A̲P̲P̲E̲N̲D̲I̲X̲ ̲A̲
DRAWINGS
