top - download
⟦d93ab7f1f⟧ Wang Wps File
Length: 54008 (0xd2f8)
Types: Wang Wps File
Notes: FIX/1155/PSP/0093
Names: »4905A «
Derivation
└─⟦1f5010eea⟧ Bits:30006143 8" Wang WCS floppy, CR 0473A
└─ ⟦this⟧ »4905A «
WangText
…00……00……00……00……00……15……02……00……00……15…
…15……05……14……08……12……02……11……08……11……0e……10……09……10……0b……10……01……10……07……0f……0e……0f……02……0e……08……86…1 …02… …02… …02…
4905A/jjj…02…FIX/1155/PSP/0093
…02…JJJ/880627…02……02… #
FIKS SFS SUBSYSTEM PSP
…02…OK/840511…02… FK 7809
FIKS SFS SUBSYSTEM PSP
FIX/1155/PSP/0093
J. J. Jensen
Gottlob Borup
FMK (6), CR (4)
…0e… FIKS S/W Mgr. 880627
1.1
880627
4905A/jjj…02… FIX/1155/PSP/0093
…02… JJJ/880627…02……02… ii
FIKS SFS SUBSYSTEM PSP
…02……02… FK 7809
840511 All Issue one of Document
880627 DCN1 Changed in accordance
with Contract No. 7Y5010
FIKS-FOD CCIS LINK and.
Order No. 12/88
4905A/jjj…02… FIX/1155/PSP/0093
…02… JJJ/840511…02……02… iii
FIKS SFS SUBSYSTEM PSP
…02……02… FK 7809
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 .........................
3
2.1 SYSTEM SOFTWARE ...........................
3
2.2 FIKS DOCUMENTATION ........................
3
3 MODULE SPECIFICATION .........................
5
3.1 FUNCTIONAL CAPABILITIES ...................
5
3.1.1 Distribution Commands ..................
5
3.1.2 Supervision Commands ..................
6
3.1.3 Control Commands ......................
10
3.1.4 Online Table Handling Commands ........
13
3.2 INTERFACE DESCRIPTIONS ....................
15
3.2.1 Man Machine Interface .................
15
3.2.2 Subsystem Interfaces ..................
16
3.2.3 Interfaces To Files ...................
17
3.2.4 Interfaces To Critical Regions ........
17
3.3 PROCESSING ................................
18
3.3.1 Procedure DISTRIBUTE Processing .......
19
3.3.2 Procedure SUPERVISION Processing ......
22
3.3.3 Procedure CONTROL Processing ..........
26
3.3.4 Procedure NPDN ̲CONNECTION Processing ..
29
3.3.5 Procedure TABLE ̲HANDLING Processing ...
29
3.3.6 Procedure USP ̲TABLE ̲HANDLING
Processing ............................
32
3.3.7 Procedure DSP ̲Q ̲ST Processing .........
33
3.3.8 Procedure INT ̲TERM Processing .........
34
3.3.9 Procedure INVOKE ̲SAF ̲WAIT Processing ..
35
3.4 DATA ORGANIZATION .........................
35
3.5 STORAGE ALLOCATION ........................
35
3.6 PERFORMANCE CHARACTERISTICS ...............
35
3.7 LIMITATIONS ...............................
36
3.8 ERROR CODES/ERROR LABELS ..................
36
4 QUALITY ASSURANCE ............................
36
5 PREPARATION FOR DELIVERY .....................
36
6 DRAWINGS .....................................
36
1 S̲C̲O̲P̲E̲
This document contains an as-built product specification
of the Supervisory Functions Subsystem module (the
SFS).
The SFS is a module within the terminal process, and
its functions are to support the interactive supervisory
functions of the terminal process.
This module makes use of several procedures and data
areas belonging to other modules. It is therefore a
prerequisite that the reader is familiar with the structuring
of the terminal process, and the various functions
of it. Detailed descriptions can be found in ref. 7
and 8.
Some supervisory commands require processing in the
subsystems DTS and SAF. For the full understanding
of the processing behind these commands, the reader
should have the product specifications of DTS (ref.
9) and SAF (ref. 10) within reach. Please note that
all drawings are placed in chapter 6.
1.1 I̲N̲T̲R̲O̲D̲U̲C̲T̲I̲O̲N̲
The supervisory functions supported by this module
are a subset of the set of terminal functions available
on a N/M.
Common for these functions are, that they are only
available for operators of the type "SUPERVISOR" or
"SUPERVISOR ASSISTANT". Operators of lower classification
than these are not allowed to use the functions. (An
attempt to use them will cause a display of the error
code: "UNKNOWN COMMAND".)
Further the supervisory commands are only available
on a subset of the terminals. A flag in the terminal
control block of a terminal determines, whether the
terminal must be used for supervisory functions or
not.
For further information about user classifications
and terminal capability profiles: please refer to ref.
7.
The commands supported by SFS are in short:
D̲i̲s̲t̲r̲i̲b̲u̲t̲i̲o̲n̲ ̲c̲o̲m̲m̲a̲n̲d̲s̲:
DDT Local distribution of DT-messages
REE Reenter DT-messages to network.
S̲u̲p̲e̲r̲v̲i̲s̲i̲o̲n̲ ̲c̲o̲m̲m̲a̲n̲d̲s̲:
DAL Display alarm
DQS Display queue status
PMJ Print message journal
PML Print message log
PST Print 24 hour statistics
OPC Open FIKS-FODCCIS Link
CLC Close FIKS-FODCCIS Link
C̲o̲n̲t̲r̲o̲l̲ ̲c̲o̲m̲m̲a̲n̲d̲s̲:
BLT Block terminal
UBT Unblock terminal
INT Interrogate terminal
ROQ Reorganize a terminal queue
REQ Relocate queue elements at a terminal
RRT Reroute terminal traffic
RET Reestablish terminal traffic
NPD NPDN dial-up
NPC NPDN close-down
OPT Open trunk
CLT Close trunk
O̲n̲-̲l̲i̲n̲e̲ ̲t̲a̲b̲l̲e̲ ̲h̲a̲n̲d̲l̲i̲n̲g̲ ̲c̲o̲m̲m̲a̲n̲d̲s̲:
DOI: Display ANO table
DOT: Update ANO table
DUR: Data user reconfiguration
DRT: Routing table update
ESM: Security interrogation
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 I/O SYSTEM PRODUCT SPECIFICATION
CSS/006/PSP/0006
3) CR80 AMOS FILE MANAGEMENT SYSTEM
SYSTEM PRODUCT SPECIFICATION
4) CSS/920/SPS/0001
5) CR80 MINI COMPUTER HANDBOOK
2.2 F̲I̲K̲S̲ ̲D̲O̲C̲U̲M̲E̲N̲T̲A̲T̲I̲O̲N̲
6) FIKS DATA INTERFACE REFERENCE
FIX/0100/MAN/0004
7) TEP SUBSYSTEM PSP
FIX/1151/PSP/0099
8) MES SUBSYSTEM PSP
FIX/1164/PSP/0060
9) DTS SUBSYSTEM PSP
FIX/1200/PSP/107
10) SAF SUBSYSTEM PSP
FIX/1155/PSP/0088
11) FIKS FILE GENERATORS PSP
FIX/1200/PSP/0042
12) REQUIREMENTS SPECIFICATIONS
FIX/000/SPC/0002
13) RDF MONITOR PSP
FIX/1256/PSP/0081
14) SRR SUBSYSTEM PSP
FIX/1153/PSP/0096
15) JOURNAL SUBSYSTEM PSP
FIX/1256 /PSP/0057
16) PSM PROCEDURE PSP
FIX/1200/PSP/0076
17) System Design Specification for the
FIKS/FOD-CCIS Link, FXA/SDS/001
18) DOI SUBSYSTEM PSP
FIX/1155/PSP/0115
3 M̲O̲D̲U̲L̲E̲ ̲S̲P̲E̲C̲I̲F̲I̲C̲A̲T̲I̲O̲N̲S̲
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 this section a short description of each command
is given. A detailed description of how the commands
are executed is given in section 3.3.
3.1.1 D̲i̲s̲t̲r̲i̲b̲u̲t̲i̲o̲n̲ ̲C̲o̲m̲m̲a̲n̲d̲s̲
Concerns the operation of narrative messages, which
have been queued into the DT-queue, due to an error
in the delivery of the message. Messages in the DT-queue
are handled by the operator by the commands DDT and
REE.
D̲D̲T̲: This command is entered if the operator wants
to distribute the DT-message to one or more
terminals local to the N/M, (or if he wants
to delete the message). When the command is
entered the operator will be prompted with
"DT ENTRY NO ̲". The number attached to the
actual DT-message (the number on the hard-copy
of the DT-message) is typed in, and the terminal
will then response by displaying the message
ID of the message (if it is found) and then
prompt the operator with "DIST TO ̲". Operator
inputs terminal ID and optionally no of copies
for each of the terminals which are going to
receive the message. The command is now executed.
If the operator answers to DIST ̲
TO by a carriage return, he will be prompted
with "DELETE ̲". If a "Y" is entered, the message
will be deleted, otherwise the situation is
the same as before the DDT command was entered.
R̲E̲E̲: This command is entered if the operator wants
to reenter the message into the FIKS network
again. The command is only allowed if the DT-message
in question was delivered to the DT-queue due
to failed delivery to other FIKS N/M's or SCC.
(ex. a Nodal error). When the command is entered,
the operator will be prompted for "DT ENTRY
NO ̲". The number of the DT-message to be reentered
is typed in, and if found, the terminal displays
the message ID of the message and issues the
prompt "REENTER ̲". If the operator answers
with "Y", the message is reentered to the network
with a routing mask equal to the one it had,
when the message was queued to the DT-queue
(meaning, that the message by the NSS subsystem
is routed to the N/M's, which have not yet
received the message). If the operator answers
by a carriage return, he will be prompted with
"DELETE ̲". If a "Y" is entered, the message
will be deleted. Otherwise the situation will
be the same as before the REE command was entered.
For further details about DT-messages:
please refer to ref.9.
The processing of DDT and REE commands takes
place in the DISTRIBUTION procedure, ref. chapter
3.3.1
3.1.2 S̲u̲p̲e̲r̲v̲i̲s̲i̲o̲n̲ ̲C̲o̲m̲m̲a̲n̲d̲s̲
The supervision commands are tools to retrieve information
and statistics on different parts of the operational
N/M.
a) D̲i̲s̲p̲l̲a̲y̲ ̲a̲l̲a̲r̲m̲
The DAL procedure display on the supervisory terminal,
alarms from the alarm/alert queue (AL). Each time
the DAL command is entered, the oldest alarm in
the queue is displayed. (The queue is able to hold
50 alarms. If alarms are inserted in a full queue,
the oldest alarms are deleted).
Alarms are enqueued to the AL-queue from different
subsystems when one of the following events occur:
1. Unsuccessfully logon/logoff
2. Wrong password in USP ̲UPDATE
3. Unsuccessfull security interrogation
4. Failed delivery of SH-message to terminal due
to wrong password
5. SH message enqueued to terminal without SH-authorization
6. SH message timeout
7. User classification too low
8. No is answered on password
9. Print queue overflow
10. Flash message to not logged on terminal
11. MTCB use count overflow
12. Long line detected at terminal
13. NPDN setup failure
14. NPDN closedown failure
15. NPDN setup established
16. NPDN closedown established
17. Orbiting control message deleted
18. Control message, destination not available
19. FIKS-FODCCIS Link open/close ok/not ok
20. FIKS-FODCCIS Link failure
The displayed alarm text contains the following information
when available:
1. Alarm event text
2. Terminal ID
3. Trunk ID
4. User ID
5. Print queue ID
6. DTG
The exact layout of the alarm text is defined in the
file ATT (alarm text table) ref. 11.
b) D̲i̲s̲p̲l̲a̲y̲ ̲q̲u̲e̲u̲e̲ ̲s̲t̲a̲t̲u̲s̲
The DQS procedure displays on the supervisory terminal
the queue status on any existing terminal at the
same N/M. The format of the display follows the
format of the permanent queue status lines on a
terminal:
- Display queues
- AX Auxiliary
- CO Coordination
- RL Release
- RT Retrieve
- SH SH-message delivery
- Print queues
- Z
- Y
- O Message delivery queues
- P
- M
- R
- LP Other printouts
- Supervisory queues
- AL Alarm
- DT Distribution
The queue status of the terminal is obtained by
entering the command DQS. The operator will then
be prompted with "TERMINAL ID ̲". When the 3-letter
ID is entered, the above described queue status
is displayed. (The terminal to be monitored can
have any status: logged on, logged off, blocked,
etc.)
c) P̲r̲i̲n̲t̲ ̲m̲e̲s̲s̲a̲g̲e̲ ̲j̲o̲u̲r̲n̲a̲l̲
Different actions performed on messages are logged
by activating the JOURNAL process which writes
the log onto the PMJ-file. By the command PMJ,
a printout of this file is initiated. After printout,
the pointers to the PMJ-file are preset, meaning
that next log printout will contain logs from this
moment. The message journal file may contain transactions
corresponding to 10 busy hours. (If the PMJ is
getting full, an error message of the type "WARNING"
will be printed on the operator console).
The parametres logged by the message journal are:
Time of event, DTG
Message identification, MSG ID
Type of event
Terminal ID
d) P̲r̲i̲n̲t̲ ̲m̲e̲s̲s̲a̲g̲e̲ ̲l̲o̲g̲
The PML procedure supports the printout from any
of the supervisory terminals of the message log.
The message log is queued for printout in the SRR
input queue upon operator request.
The message log gives information about the messages
on the HDB for the last 24 hours.
The log information consists of the following items:
- Retrival time
- Message identification, MSG ID
- Subject indicator codes, SIC
- Classification, CLASS
- Precedence.
The PRINT MESSAGE LOG is entered by the command
PML.
e) P̲r̲i̲n̲t̲ ̲s̲t̲a̲t̲i̲s̲t̲i̲c̲s̲
The PST procedure supports the printout, at the
N/M supervisor, of the 24 hours N/M statistics
generated at the SCC.
The statistical output is delivered to the N/M
supervisor's AX queue as soon as it is generated
at the SCC.
The statistics contain information about the released
and received messages for the actual N/M.
The information is
- M̲e̲s̲s̲a̲g̲e̲ ̲r̲e̲l̲e̲a̲s̲e̲d̲
class/precedence/No. of messages/No. of ANOs/No.
of characters
- M̲e̲s̲s̲a̲g̲e̲ ̲r̲e̲c̲e̲i̲v̲e̲d̲ (from the trunks)
class/precedence/No. of messages/No. of characters.
The PRINT 24 HOURS STATISTICS are entered by the
command PST.
f) O̲p̲e̲n̲/̲C̲l̲o̲s̲e̲ ̲F̲I̲K̲S̲-̲F̲O̲D̲C̲C̲I̲S̲ ̲L̲i̲n̲k̲
The OPC/CLC commands enable the supervisor, in
case a FIKS-FODCCIS Link is connected to the local
Node/MEDE, to open/close this one.
3.1.3 C̲o̲n̲t̲r̲o̲l̲ ̲C̲o̲m̲m̲a̲n̲d̲s̲
The control commands enables the supervisor/assistant
to control the terminals, and the trunk lines of a
N/M.
a) B̲l̲o̲c̲k̲/̲U̲n̲b̲l̲o̲c̲k̲
The BLT/UBT commands enables the supervisory operators
to disconnect (block) terminals logically and to
connect (unblock) terminals logically.
"BLOCKING" implies an automatic log-off of the
terminal, and subsequent log-on is not possible
(as long as the terminal has the status "BLOCKED").
"UNBLOCKING" implies that a blocked terminal is
still logged off, but log-on is now allowed.
b) S̲e̲c̲u̲r̲i̲t̲y̲ ̲i̲n̲t̲e̲r̲r̲o̲g̲a̲t̲i̲o̲n̲
The ISI function gives the supervisory operators
the possibility of initiating security interrogation
of one specific terminal. The command can only
be performed on terminals which are not blocked
and not in "RECEIVE ONLY" mode.
The security interrogation of a terminal implies
that when the terminal is logged on or when the
operator have finished a command session and again
enters the "PROMPT ̲" mode, the operator is security
interrogated: The text "SECURITY INTERROGATION"
is displayed and the operator is prompted for user-ID
and password. If the operator gives the correct
answers he is allowed to continue operation. Otherwise
the terminal is blocked and an alarm is issued
(to the supervisory terminals AL-queue). Further,
the event is logged on the journal log (ref. PMJ
command).
c) R̲e̲o̲r̲g̲a̲n̲i̲z̲e̲ ̲q̲u̲e̲u̲e̲
The ROQ Procedure helps the supervisory operators
to move a specified queue element from its present
position to the first or last position within the
queue specified.
The terminal queues in question are:
- Display queues
- CO Coordination queue
- RL Release queue
- RT Retrieve queue
- AX Auxiliary queue (print out of 24 hours
statistics)
- SH Special Handling
- Print queues
- Z
- Y
- O
- P Message delivery
- M
- R
- LP Log print
d) R̲e̲l̲o̲c̲a̲t̲e̲ ̲q̲u̲e̲u̲e̲ ̲e̲l̲e̲m̲e̲n̲t̲s̲
The REQ procedure supports the supervisory operators
in appending the queue elements starting with n
in a terminal queue at terminal A to corresponding
queue at terminal B
The terminal queues in question are the same as
for ROQ.
e) R̲e̲r̲o̲u̲t̲e̲ ̲t̲e̲r̲m̲i̲n̲a̲l̲ ̲t̲r̲a̲f̲f̲i̲c̲
The RRT procedure helps the supervisory operators
in rerouting terminal traffic. It appends all present
and future messages to terminal A to corresponding
queues at terminal B.
The terminal queues in operation are the same as
for ROQ.
The queue control procedures only act upon queue
elements, which are not active.
Only one terminal at a time is able to operate
on a given queue item.
In the ROQ and REQ commands this is assured by
the …02…Q ̲ACCESS procedure.
In the RRT command the SAF process handles the
rerouting as an entity for each terminal and thereby
assures the synchronization.
f) R̲e̲e̲s̲t̲a̲b̲l̲i̲s̲h̲ ̲T̲e̲r̲m̲i̲n̲a̲l̲ ̲T̲r̲a̲f̲f̲i̲c̲
The RET procedure helps the supervisory operators
in reestablishing terminal traffic. It redirects
future terminal traffic back to original terminal,
i.e. the procedure cancels the RRT.
No transfer of earlier rerouted messages takes
place.
g) N̲P̲D̲N̲ ̲d̲i̲a̲l̲-̲u̲p̲/̲c̲l̲o̲s̲e̲-̲d̲o̲w̲n̲
The NPD procedure enables the supervisors to connect
two Nodes with an NPDN line. The connection may
be reaction to a trunk that is out of order. The
NPC procedure allowes the supervisors to close
down an already established NPDN connection.
The dial up/close down requests are sent to the
Nodal Switch Subsystem, which communicates to the
LTUs handling the NPDN lines.
As an acknowledgement to the dial up/close sown
request the NSS sends an alarm, defining the result
of the request.
h) O̲p̲e̲n̲/̲c̲l̲o̲s̲e̲ ̲t̲r̲u̲n̲k̲s̲
The OPT/CLT commands enables the supervisory operators
to open and close the trunk lines connected to
a N/M. These commands are the same as the corresponding
SCC commands, except that the N/M operator only
is allowed to operate on trunk lines connected
to that N/M.
3.1.4 O̲n̲-̲l̲i̲n̲e̲ ̲T̲a̲b̲l̲e̲ ̲H̲a̲n̲d̲l̲i̲n̲g̲ ̲C̲o̲m̲m̲a̲n̲d̲s̲
This set of commands enables the supervisory operator
to inspect and make online updates on addressing, routing
tables, and user profile tables. Further, a command
for reconfiguration of data user traffic is supported.
a) D̲i̲s̲p̲l̲a̲y̲ ̲A̲N̲O̲ ̲t̲a̲b̲l̲e̲ (DOI)
A table containing 100 entries in a 10x10 matrix
is displayed. The table shows the relationship
between ANO-numbers (of this N/M) and terminal
IDs. Each entry in the table identifies a terminal
ID (3 characters). (Ex.: the terminal ID corresponding
to ANO number 035 is found in the entry described
by row number 5 and line number 30).
b) U̲p̲d̲a̲t̲e̲ ̲A̲N̲O̲ ̲t̲a̲b̲l̲e̲ (DOT)
Replaces the terminal ID of a specified ANO with
a new terminal ID.
The operator is asked to enter the ANO-number.
The corresponding terminal-ID is displayed and
the operator is finally asked to enter a new terminal-ID.
The update implies, that future messages containing
the specified ANO will be distributed to the new
terminal.
c) D̲a̲t̲a̲ ̲U̲s̲e̲r̲ ̲R̲e̲c̲o̲n̲f̲i̲g̲u̲r̲a̲t̲i̲o̲n̲ (DUR)
Each N/M has 3 data user routing tables, one primary
and 2 secondary. The tables are down-line loaded
from the SCC and into the black TDX-system.
Switching from the primary to the secondary route
is done automatically when a hard trunk failure
occurs on the primary route. Further, the DUR-command
enables the supervisory operator to manually reload
one of the alternative tables. Before this is done,
it should be controlled, that all N/Ms reload their
black TDX system with the defined table, because
the syncronization between N/M implies that they
all must use corresponding tables.
During the time it takes to reconfigurate all N/Ms,
data may be lost.
d) D̲i̲s̲p̲l̲a̲y̲/̲u̲p̲d̲a̲t̲e̲ ̲r̲o̲u̲t̲i̲n̲g̲ ̲t̲a̲b̲l̲e̲
The nodal switch subsystem (NSS) routes messages
to other N/Ms and SCCs according to 3 routing tables:
the primary, secondary, and the tertiary.
The DRT command implies, that the routing table,
describing the 3 alternative routes from this N/M
- to all other N/Ms and SCCs, are displayed. Further,
the operator is requested to type in a new set
of routing tables. If a new table is entered, the
NSS will route future messages according to this
table (until a new routing table is generated and
issued from the SCC).
e) U̲s̲e̲r̲ ̲s̲e̲c̲u̲r̲i̲t̲y̲ ̲p̲r̲o̲f̲i̲l̲e̲ ̲c̲o̲m̲m̲a̲n̲d̲s̲ (ESM)
Before updates on security profiles can be performed,
the supervisory operator must enter the security
mode. This is done by typing in the command ESM
(Enter Security Mode). The operator is now requested
to enter his SH-password. If he succeeds, he is
now allowed to use the commands DSI, DSS and XIT.
D̲i̲s̲p̲l̲a̲y̲ ̲S̲e̲c̲u̲r̲i̲t̲y̲ ̲p̲r̲o̲f̲i̲l̲e̲ ̲I̲n̲d̲e̲x̲ ̲c̲o̲m̲m̲a̲n̲d̲ (DSI):
Displays all the User-ID names attached to this
N/M in a matrix. Each entry identifies a User-ID
of max 4 characters.
D̲i̲s̲p̲l̲a̲y̲ ̲S̲p̲e̲c̲i̲f̲i̲c̲ ̲S̲e̲c̲u̲r̲i̲t̲y̲ ̲p̲r̲o̲f̲i̲l̲e̲ ̲c̲o̲m̲m̲a̲n̲d̲ (DSS):
Displays a specified profile and allows correction,
deletion and insertion of the displayed profile.
The insertion is facilitated by displaying a dummy
profile containing an "X" on each place, the operator
shall insert a character. A user profile contains
the entries: user type, classification, password,
SH-password.
E̲x̲i̲t̲ ̲S̲e̲c̲u̲r̲i̲t̲y̲ ̲m̲o̲d̲e̲ ̲c̲o̲m̲m̲a̲n̲d̲ (XIT):
The command implies, that the security mode is
exited and the normal "PROC ̲" mode is reentered.
(Now, the commands DSI, DSS and XIT are no longer
allowed).
3.2 I̲N̲T̲E̲R̲F̲A̲C̲E̲ ̲D̲E̲S̲C̲R̲I̲P̲T̲I̲O̲N̲S̲
3.2.1 M̲a̲n̲ ̲M̲a̲c̲h̲i̲n̲e̲ ̲I̲n̲t̲e̲r̲f̲a̲c̲e̲
A detailed description of the man machine interface
(Syntax and Semantic roules, command mnemonics, screen
display formats etc.) are given in the requirements
specifications (ref. 12) and in the operators handbook.
They are therefore not repeated in this document.
3.2.2 S̲u̲b̲s̲y̲s̲t̲e̲m̲ ̲I̲n̲t̲e̲r̲f̲a̲c̲e̲s̲
Figure 3.2.2-1 shows the interfaces between the SFS
part of the terminal process and other FIKS subsystems.
Data descriptions of the interfaces are given in ref.
6.
a) S̲F̲S̲ ̲-̲ ̲o̲t̲h̲e̲r̲ ̲t̲e̲r̲m̲i̲n̲a̲l̲ ̲p̲r̲o̲c̲e̲s̲s̲e̲s̲
1. Alarms from other terminal processes. Pseudo
MTCB in AL-queue.
b) S̲F̲S̲ ̲-̲ ̲P̲I̲P̲
1. Alarms from PIP. Pseudo MTCB in AL-queue.
2. Non-deliverable message from PIP. Pseudo MTCB
in DT-queue.
3. 24 hours statistics messages from SFS. A pseudo
MTCB in a LP-queue.
c) S̲F̲S̲-̲S̲R̲R̲
1. Print Message Log requests from SFS. Pseudo
MTCB in SRS2-queue.
d) S̲F̲S̲-̲J̲O̲U̲R̲N̲A̲L̲
1. Print Message Journal request from SFS. Pseudo
MTCB in LJP-queue.
e) S̲F̲S̲-̲D̲T̲S̲
1. Requests concerning DT-messages. An AMOS system
message is sent from SFS to DTS.
2. Answers from DTS. An AMOS system answer is
sent from DTS to SFS. (The interfaces are described
in ref. 9).
f) S̲F̲S̲-̲S̲A̲F̲
1. Table handling commands, queue manipulation
commands, trunk manipulation commands, Data
User commands. A pseudo MTCB in SF-queue. The
answer from SAF is a Pseudo MTCB in the RD-queue.
(In a single case, (the DRT command) data are
copied directly into the process area of SFS
from the SAF process).
2. 24 hours statistics messages. A pseudo MTCB
in the AX-queue
3. Alarms from SAF. A pseudo MTCB in the AL-queue.
g) S̲F̲S̲-̲M̲D̲S̲
1. Non-deliverable messages from MDS. Pseudo MTCB
in DT-queue.
2. Alarms from MDS. Pseudo MTCB in AL-queue.
3. Local distribution of non-deliverable messages.
A pseudo MTCB in MDS-queue.
h) S̲F̲S̲-̲P̲S̲M̲
1. Blocking, unblocking, security interrogation.
An AMOS system message is sent from SFS to
PSM.
An AMOS system answer is received by SFS.
i) S̲F̲S̲-̲N̲S̲S̲
1. Alarms from NSS. A pseudo MTCB in AL-queue.
j) S̲F̲S̲-̲C̲T̲E̲R̲M̲/̲C̲P̲I̲P̲
1. Alarms concerning FIKS-FODCCIS Link status
change. Send via the SEND ̲REPORT-monitor.
2. Open/Close FIKS-FODCCIS Link commands. An AMOS
message sent to the CTERM-process.
3.2.3 I̲n̲t̲e̲r̲f̲a̲c̲e̲ ̲t̲o̲ ̲f̲i̲l̲e̲s̲
SFS reads data from the ATT file (Alarm Text File)
when alarms are displayed.
3.2.4 I̲n̲t̲e̲r̲f̲a̲c̲e̲s̲ ̲t̲o̲ ̲c̲r̲i̲t̲i̲c̲a̲l̲ ̲r̲e̲g̲i̲o̲n̲s̲
SFS accesses the critical regions CONFIG and XTCBCR.
3.3 M̲O̲D̲U̲L̲E̲ ̲S̲P̲E̲C̲I̲F̲I̲C̲A̲T̲I̲O̲N̲S̲
The SFS is considered as one module consisting of a
number of procedures. The functionalities of the SFS
submodule are grouped in a number of procedures each
performing a related set of tasks. Further these procedures
make use of a set of support procedures.
All procedures (except the support procedures) are
invoked from the mainmodule of the terminal process
TEP ̲MAIN, (ref. 7) when a command has been entered
by a terminal operator and recognized as a supervisory
command. The TEP ̲MAIN determines by inspecting the
output parametres from the command purser (the parametres
COMMAND ̲NO, MODULE ̲NO and SUBMODULE ̲NO) which group
of supervisory commandes the entered command belongs
to. The SFS procedure handling this group of commands
is then called.
As mentioned above, each procedure handles a set of
related supervisory commands and functions:
Procedure DISTRIBUTE : DDT, REE
Procedure TABLE ̲HANDLING : DOI, DOT, DUR,
DRT,
Procedure USP ̲TABLE ̲HANDLING : DSI, DSS, (ESM)
Procedure NPDN ̲CONNECTION : NPD, NPC
Procedure INT ̲TERM : INT
Procedure CONTROL : BLT, UBT, ISI,
ROQ, REQ, RRT,
RET
Procedure SUPERVISION : DAL, DQS, PMJ,
PMS, PST, OPC,
CLC
Figure 3-1 shows the block diagramme of the SFS module.
Procedures inported from other modules are not shown.
In the chapters 3.3.1-6, the processing in the procedure
(shown in figure 3-1, as the 1. level under TEP ̲MAIN)
is described in detail.
For some special types of commands, most of the processing
takes place in external subsystems, such as the DTS
process and SAF process. The processings of these are
only described in short, and references are given to
the appropriate documents.
3.3.1 P̲r̲o̲c̲e̲d̲u̲r̲e̲ ̲D̲I̲S̲T̲R̲I̲B̲U̲T̲E̲ ̲P̲r̲o̲c̲e̲s̲s̲i̲n̲g̲
When one the supervisory commands DDT and REE is entered
on a terminal, the procedure DISTRIBUTE is called from
the TEP ̲MAIN module. The parametres describing the
entered command are COMMAND ̲NO, MODULE ̲NO
and SUBMODULE ̲NO.
The processing in DISTRIBUTE concerns messages which
have been entered in the DT-queue, mainly due to distribution
errors. The entries in the DT-queue are pseudo MTCB's
containing informations about the error. (CATEGORY
and SUBCATEGORY). The various types of errors and their
interpretation can be found in the prefix-file AL ̲DT
̲PARAMS.S. Further, the pseudo MTCB contains a reference
(MTCB ID) to the message in question.
When elements are inserted in the DT-queue, they are
automaticly handled by the DTS-process, which allocates
a DT-number to the message and prints a part of the
message (down to the first 2 text lines) together with
an error text and the allocated DT-number on a predefined
ROP. The automatic handling of DT-messages are described
in detail in ref. 9. When DTS has finished the automatic
processing, the queue elements are still in the DT-queue,
and they can now be handled by the commands DDT and
REE. The key to the DT-message is the DT-number, and
the operator can chose which message he wants by entering
the corresponding DT-number. (The operator is informed
about the DT-numbers via the printout).
The processing in DISTRIBUTE is as follows:
1. Procedure KBD ̲DATA is called in order to issue
the command "DT ENTRY NO ̲" and to get the operators
response.
2. An AMOS system message is sent to the DTS process.
The contents of the message are the DT-
number and a code, which tells DTS that it
is requested to check if the DT-number is legal.
DTS checks if the number corresponds to one
of the entries in the DT-queue. Further, it
checks if the DT-number is reserved (already
accessed by another supervisor). If both checks
are succesfull, the DT-element is marked as
reserved (protected against access from other
operators) and the message ID of the message
is returned in an AMOS system answer.
3. The answer is received by the DISTRIBUTE procedure.
If the completion code is negative, an error
is issued and a jump is made to step 1.
In case the answer is OK, the message ID returned
by DTS is displayed on screen.
4. In the answer from DTS, the index of the pseudo
MTCB is delivered. The pseudo MTCB is read.
From the MTCB block is extracted the index
of the real MTCB (the message reference).
Finally the real MTCB is read.
If the command entered by the operator was
DDT, then the steps 5-11 are executed, otherwise
continue in step 12.
5. KBD ̲DATA is called in order to issue the prompt
"DIST TO ̲" and receive the answer.
6. If the answer was a carriage return, processing
continues in step 9. Otherwise, the characters
entered by the operator is examined.
7. The buffer returned by KBD ̲DATA contains a
number of entries, where the upper byte contains
the number of copies, and the lower byte contains
the number of the terminal. The total number
of copies are summarized in the variable COUNT.
If the value of COUNT exceeds 63 (which is
the maximum number of the "use-count" of a
MTCB, an error is issued, the last entries
are deleted, and the operator is prompted again
(step 5)). The limit of 63 copies of each message
is set in order to avoid errors in the MDS
process, when the copies are queued to the
terminals. (Each enqueueing increments the
"use-count" of the message MTCB).
8. For each of the entries in the buffer returned
from KBD ̲DATA, the terminal number is converted
to the logical terminal number by call of MON
RDF. (In case a "reroute" has been performed,
the actual terminal number differs from the
logical, ref. 13, chapter 3.2.4).
9. The steps 5-8 are repeated, until the operator
answers with a carriage return to the prompt
"DIST TO". All entries with the converted terminal
number, and number of copies are accumulated
in the buffer BUFF ̲1.
10. For each 5 entries in BUFF ̲1, a pseudo MTCB
is created. The five entries are copied to
the MTCB together with the MTCB index of the
message, and the pseudo MTCB is queued to the
MDS input queue. (The checkpointing of the
enqueueing is done in advance).
11. An AMOS system message is now generated and
sent to the DTS process. DTS is requested to
delete the pseudo MTCB received in step 4,
and to release the DT-number of the message.
Processing (of the DDT command) is continued
in step 13.
12. (The entered command was REE).
KBD ̲DATA is called in order to issue the prompt
"REENTER ̲" and to receive the operator's answer.
If the answer was yes ("Y"), an AMOS system
message is sent to DTS. DTS is requested to
reenter the message and delete the DT-queue
element, MTCB and DT-number.
The rest of the processing now concerns both
commands.
13. If the message was not requested distributed
or reentered, KBD ̲DATA is called in order to
issue the prompt "DELETE ̲". If he answers "Y",
an AMOS message is sent to DTS. (DTS is requested
to discard the message, delete the DT-queue
element and the DT-number). Otherwise an AMOS
message is sent to DTS in order to release
the DT-number. (The message gets the same status
as it had before the DISTRIBUTE procedure was
entered).
3.3.2 P̲r̲o̲c̲e̲d̲u̲r̲e̲ ̲S̲U̲P̲E̲R̲V̲I̲S̲I̲O̲N̲ ̲P̲r̲o̲c̲e̲s̲s̲i̲n̲g̲
When one of the supervision commands DAL, DQS, PMJ,
PML or PST are entered, the SUPERVISION procedure is
called from TEP ̲MAIN.
The procedure functions are organized in a CASE statement,
where each case performs the processing of a specific
command.
T̲h̲e̲ ̲p̲r̲o̲c̲e̲s̲s̲i̲n̲g̲ ̲i̲n̲ ̲S̲U̲P̲E̲R̲V̲I̲S̲I̲O̲N̲ ̲i̲s̲ ̲a̲s̲ ̲f̲o̲l̲l̲o̲w̲s̲:
C̲o̲m̲m̲a̲n̲d̲ ̲=̲ ̲D̲A̲L̲:
Alarms are sent from other subsystems (and also
from the terminal process itself) to the SFS module
by enqueueing a pseudo MTCB describing the alarm
into the AL-queue of the terminal process. The
interpretation of the codes describing the alarm
is given in the prefix file AL ̲DT ̲PARAMS.S.
When the DAL command is entered, a number of alarms
are displayed, by repeating the steps 1-6. (The
number of alarms displayed are currently 18).
1. The first element in the AL-queue is read (destructively)
by call of MON QACCESS. If the queue is empty,
an error is issued and the procedure is exited.
2. The pseudo MTCB (referenced by the queue element)
is read.
3. The file AAT (which contains the alarm texts
to be displayed, ref. 11) is opened. The offset
to the actual alarm text is calculated from
the alarm codes given in the pseudo MTCB, and
the text string is read.
4. Before the alarm text is displayed some additional
parametres given in the pseudo MTCB must be
inserted in reserved fields in the alarm text
string.
The parametres inserted depends on the type
of alarm:
NM ̲ALARM ̲MSG:
If alarm = PQ ̲OVERFLOW: the ID of the queue
(Z, Y, O, LP, P, M, R, SH) is calculated
and inserted.
If alarm = MTCB ̲USE ̲COUNT ̲OVERFLOW: the
message ID is copied from the pseudo MTCB
to the alarm text string. Otherwise the
parametres with offset 6 and 7 in the pseudo
MTCB are inserted.
NM ̲ALARM ̲NPDN:
The node ID is copied from pseudo MTCB
to alarm text string.
NM ̲ALARM ̲TRUNK:
If the alarm concerns a trunk or soft fail
of/off, the node ID is inserted in the
text string. If the alarm is a ORBIT ̲CTRL
̲MSG ̲DEL or DEST ̲NON ̲AVAILABLE:
The 2 node IDs given in the pseudo MTCB
are converted to ASCII characters and inserted
in text string. Further the DTG is extracted,
converted and inserted. Further, in case
of the alarm ORBIT ̲CTRL ̲MSG ̲DEL, the routing
mask (2 words) is extracted from the pseudo
MTCB, and all bits set are converted to
ASCII characters and inserted in the text
string.
5. The alarm text is displayed by call of ITRANSFER
6. The pseudo MTCB is released.
7. The procedure is exited.
C̲o̲m̲m̲a̲n̲d̲ ̲=̲ ̲D̲Q̲S̲:
The queue status of a specified terminal is displayed:
1. KBD ̲DATA is called in order to issue the prompt
"TERM ID ̲" and to receive the operators response.
2. The procedure DSP ̲Q ̲ST is called. (ref. chapter
3.3.7) (This procedure displays the queue status
lines).
3. The procedure is exited.
C̲o̲m̲m̲a̲n̲d̲ ̲=̲ ̲P̲M̲J̲ ̲o̲r̲ ̲P̲M̲L̲:
A request concerning printout of the message journal
file, or the printout of the last 24 hours message
storage is issued:
1. If command = PML, then a semaphore bit located
in the critical region CONFIG is reserved.
Due to constraints in the SRR process (ref.
14), the PML command is not allowed as long
as the printout from the last issued PML command
has not finished. The semaphore bit is released
by the PIP process when the printout of the
PML file has finished.
If the reservation failed, (printout of the
PML file not finished) an error is issued and
the procedure is exited.
2. A pseudo MTCB is created and the actual command
code together with the number of the terminal
process is written into the MTCB.
3. If the command = PML, the MTCB is enqueued
into the input queue of the SRR process. (SRR
generates the PML file and requests the PIP
process to print it on the ROP attached to
the specified terminal.)
If the command = PMJ, the MTCB is enqueued
into the input queue of the JOURNAL process
(ref.15) (JOURNAL calculates the start offset
and the end offset in the PMJ-file, and then
requests the PIP process to print the specified
piece of the file on the ROP attached to the
specified terminal).
4. The pseudo MTCB is released.
5. The procedure is exited.
C̲o̲m̲m̲a̲n̲d̲ ̲=̲ ̲P̲S̲T̲:
The 24 hours statistics message received from the
SCC (and inserted in the AX-queue) is printed:
1. Read the first element (destructive) in the
AX-queue by call of MON QACCESS.
2. The queue element (an MTCB index) is inserted
in the LP-queue of the terminal process by
call of MON QACCESS.
3. The MTCB index is released.
4. The procedure is exited.
C̲o̲m̲m̲a̲n̲d̲ ̲=̲ ̲O̲P̲C̲ ̲o̲r̲ ̲C̲L̲C̲:
An AMOS message with layout as specified in ref.
17, sec. 3.3.2.2 is sent to the CTERM-process.
The AMOS answer is awaited endless. If the completion
code in the answer indicates 'Unexpected command',
then the supervisor is informed via the 'INVALID
FODCCIS CMD'-command completion code at the operator
display.
3.3.3 P̲r̲o̲c̲e̲d̲u̲r̲e̲ ̲C̲O̲N̲T̲R̲O̲L̲ ̲P̲r̲o̲c̲e̲s̲s̲i̲n̲g̲
When one of the control commands BLT, UBT, ISI, ROQ,
REQ, RRT or RET are entered, the CONTROL procedure
is called from TEP ̲MAIN. (Other control commands are
described in the succeeding chapters).
The functions of the procedure are organized in a CASE
statement, where each branch contains the processing
of a specific command.
T̲h̲e̲ ̲p̲r̲o̲c̲e̲s̲s̲i̲n̲g̲ ̲i̲n̲ ̲C̲O̲N̲T̲R̲O̲L̲ ̲i̲s̲ ̲a̲s̲ ̲f̲o̲l̲l̲o̲w̲s̲:
Before the CASE statement is entered, the KBD ̲DATA
procedure is called a number of times in order to issue
prompts to the operator and receive the answer. The
answers are kept in a buffer and used in the CASE statements.
The issued prompts are:
BLT, UBT, ISI : TERM ID ̲
ROQ : TERM ID ̲, QUEUE ID ̲, INDEX
̲,
FIRST/LAST ̲.
REQ : TERM ID ̲, QUEUE ID ̲, INDEX
̲,
TO TERM ID ̲.
RRT : FROM ̲, TO ̲.
RET : TERM ID ̲.
The entries in the CASE statement are:
C̲o̲m̲m̲a̲n̲d̲ ̲=̲ ̲B̲L̲T̲:
The procedure PSM ̲MESS is called (with input parametre
= BM ̲BLOCK). The PSM ̲MESS procedure generates an
AMOS system message and sends it to the PSM process
(ref. 16). The message tells the PSM process to
block the specified terminal. (A bit in the terminal
control block located in the critical region XTCBCR
is set). As the terminal control block is checked
each time a new command is entered, the operator
on that terminal will from now on be blocked.
C̲o̲m̲m̲a̲n̲d̲ ̲=̲ ̲U̲B̲T̲:
The processing is the same as for BLT. PSM is now
requested to unblock the specified terminal. After
the unblocking, the terminal has the status "LOGGED
OFF".
C̲o̲m̲m̲a̲n̲d̲ ̲=̲ ̲I̲S̲I̲:
From the critical region XTCBCR, the M ̲STAT control
word of the terminal control block (belonging to
the specified terminal) is read. If the control
word indicates a blocked terminal or a terminal
which is not in the mode RX ̲TX, an error message
is issued and the procedure is exited. Otherwise
PSM ̲
MESS is called. (PSM ̲MESS sends an AMOS system
message to PSM. PSM enters the XTCBCR critical
region and sets the "INTERROGATE" bit in the control
block of the specified terminal). Next time a command
is entered on the specified terminal, the "INTERROGATE"
bit will be detected and the procedure INT ̲TERM
will be called. This procedure performs the interactive
interrogation, ref. chapter 3.3.8.
C̲o̲m̲m̲a̲n̲d̲ ̲=̲ ̲R̲O̲Q̲:
The monitor procedure MON QACCESS, REORG is called
with the parametres given by the operator (terminal
number, queue number, entry number, destination).
The call implies, that the specified element (entry
number) in the specified queue (queue no) belonging
to the specified terminal (terminal no) is moved
to either the first or the last position in the
queue (specified by FIRST/LAST). An attempt to
move the first element in a queue will cause an
error if the first element is marked as active.
An attempt to move an element to the first position
in the queue will imply an error if the first element
is active. The specified element will in that case
be inserted in the second position in the queue.
C̲o̲m̲m̲a̲n̲d̲ ̲=̲ ̲R̲E̲Q̲:
The parametres entered by the operator (terminal
ID, queue ID, index, to ̲terminal ̲id) are packed
in the array MTCB ̲BLOCK. The subcategory is set
to RELOCATE ̲MSGS. The procedure INVOKE ̲SAF ̲WAIT
is called with a reference to MTCB ̲BLOCK. The INVOKE
̲
SAF ̲WAIT procedure (ref. chapter 3.3.9) creates
a pseudo MTCB and enqueues it to the SF-queue of
the SAF subsystem. The procedure waits until an
element has arrived in the RD-queue (inserted by
the SAF process). The completion code returned
by SAF (in the MTCB) is returned to the CONTROL
procedure. This means that the actual relocation
of the queue elements is performed by the SAF process
(ref. 10).
C̲o̲m̲m̲a̲n̲d̲ ̲=̲ ̲R̲R̲T̲:
The processing of this command is identical to
that of the REQ command. The actual rerouting of
the traffic is performed by the SAF process (ref.
10).
C̲o̲m̲m̲a̲n̲d̲ ̲=̲ ̲R̲E̲T̲:
The monitor procedure MON RDF, REROUTE is called.
Input to the procedure is the terminal ID entered
by the operator and converted to the actual terminal
number. The command thereby cancels the command
RRT. The RDF update (performed by the RDF monitor
in its incore table) is checkpointed.
3.3.4 P̲r̲o̲c̲e̲d̲u̲r̲e̲ ̲N̲P̲D̲N̲ ̲C̲O̲N̲N̲E̲C̲T̲I̲O̲N̲ ̲P̲r̲o̲c̲e̲s̲s̲i̲n̲g̲
When one of the control commands NPD, NPC, OPT, CLT
are entered, the procedure NPDN ̲CONNECTION is called
from TEP ̲MAIN.
T̲h̲e̲ ̲p̲r̲o̲c̲e̲s̲s̲i̲n̲g̲ ̲i̲s̲ ̲a̲s̲ ̲f̲o̲l̲l̲o̲w̲s̲:̲
Procedure KBD ̲DATA is called in order to issue the
prompt "TRUNK ID ̲" and receive the answer. The op-code
for the command and the entered trunk ID are inserted
in the array MTCB ̲BLOCK. Procedure INVOKE ̲SAF ̲WAIT
is called with a reference to MTCB ̲BLOCK. This procedure
hands over the command to the SAF process (ref. 10)
via a pseudo MTCB inserted in the SF-queue. The response
is awaited in the RD-queue, and when received, the
completion code is transferred to NPDN ̲CONNECTION.
This means, that the actual processing of the command
takes place in the SAF process.
3.3.5 P̲r̲o̲c̲e̲d̲u̲r̲e̲ ̲T̲A̲B̲L̲E̲ ̲H̲A̲N̲D̲L̲I̲N̲G̲ ̲P̲r̲o̲c̲e̲s̲s̲i̲n̲g̲
When one of the on-line table handling commands DUR,
DRT, DOI, DOT are entered, the procedure TABLE ̲HANDLING
is called from TEP ̲MAIN. The procedure is structured
as a CASE statement. Each branch processes one command:
C̲o̲m̲m̲a̲n̲d̲ ̲=̲ ̲D̲U̲R̲:
KBD ̲DATA is called in order to issue the prompt
"TABLE ID ̲", and to receive the operators answer
(0, 1 or 2, for primary, secondary or tertiary).
In the array WORK ̲BUFFER an MTCB block is built,
containing the op-code for the command and the
table ID. The procedure INVOKE ̲SAF ̲WAIT is called
with a reference to the MTCB block. This procedure
hands over the command to the SAF process via a
pseudo MTCB enqueued to the SF-queue. The answer
is awaited in the RD-queue and transferred to
TABLE ̲HANDLING. This means that the actual processing
of the command takes place in the SAF process (ref.
10).
C̲o̲m̲m̲a̲n̲d̲ ̲=̲ ̲D̲R̲T̲:
A MTCB block is built in the array WORK ̲BUFFER
. The parametres are: op-code of the command, the
PSW word, the BASE register, the relative address
of BUFF ̲2. The procedure INVOKE ̲SAF ̲WAIT is called
with a reference to the MTCB block. This procedure
transfers the data to SAF via the pseudo MTCB,
which is queued to the SF-queue. The SAF-process
retrieves the routing table to be displayed in
the NDF-file. The table is copied directly into
the BUFF-2 in the terminal process by the SAF process.
An answer is returned to INVOKE ̲SAF ̲WAIT, which
transfers it to TABLE ̲HANDLING.
ITRANSFER is called in order to display the table,
which was delivered by SAF. KBD ̲DATA is called
in order to issue the prompt " ̲" (the operator
is requested to enter a new routing table) and
receive the answer.
Each character in the response is compared with
the table describing all possible neighbours (which
was also delivered by SAF) in order to check if
the new table is legal. If an unknown neighbour
is found, an error is issued, and the operator
is requested to try again. Otherwise the entered
table is moved to the top of BUFF ̲2.KBD ̲DATA is
called in order to issue the prompt "ACCEPT ̲" and
receivce the answer. If the operator answered "Y",
the procedure INVOKE ̲
SAF ̲WAIT is called.
This procedure requests SAF to perform the table
update by enqueueing a pseudo MTCB into the SF-queue.
SAF reads the new table directly from the BUFF
̲2 in the terminal process, performs the update
and returns an answer to INVOKE ̲SAF ̲WAIT, which
transfers it to TABLE ̲HANDLING.
C̲o̲m̲m̲a̲n̲d̲ ̲=̲ ̲D̲O̲I̲:
An AMOS message is sent to the DOI process containing
the number of the originating process. DOI will
then display the first page of the ANO-table at
the originating terminal and then return an AMOS
answer.
IF NEXT PAGE is entered then a new AMOS message
is sent to the DOI and the last page of the ANO-table
is displayed.
For further details, ref. 18.
C̲o̲m̲m̲a̲n̲d̲ ̲=̲ ̲D̲O̲T̲:
(Update of ANO table)
KBD ̲DATA is called in order to issue the prompt
"ENTRY NO ̲" and receive the operators answer. The
MEDE-ID of the local N/M is extracted from the
terminal control block (TCB ̲SAVE). (The first letter
in the terminal ID is used). From the Mede-ID and
the entered ANO number, the ANO word is generated.
MON RDF, GANOTRM is called in order to get the
actual terminal number corresponding to the ANO.
MON RDF, GTRMID is called (with number as input)
in order to get the terminal ID of the entered
ANO. The terminal ID is displayed by call of ITRANSFER.
KBD ̲DATA is called in order to issue the prompt
" ̲" and to receive the operator's answer (which
is a terminal ID or a *). The prompt returned from
KBD ̲DATA is a terminal number (the input is converted
by KBD ̲DATA).
KBD ̲DATA is called in order to issue the prompt
"ACCEPT ̲" and to receive the answer. If the answer
was "Y" and the previous answer was "*" (meaning
a delete of the ANO), then MON RDF, SANOEX is called
in order to delete the ANO from the ANO-existance
table. If the last entry was a "Y", then MON, RDF,
SANOTRM is called in order to change the terminal
number corresponding to the specified ANO to the
terminal number entered by the operator. The update
of the ANO entry is checkpointed by sending the
checkpoint in an AMOS system message to the CHECKP
process and receive the returned answer.
3.3.6 P̲r̲o̲c̲e̲d̲u̲r̲e̲ ̲U̲S̲P̲ ̲T̲A̲B̲L̲E̲ ̲H̲A̲N̲D̲L̲I̲N̲G̲ ̲P̲r̲o̲c̲e̲s̲s̲i̲n̲g̲
When the supervisory command ESM is entered on a terminal,
the procedure USP ̲TABLE ̲HANDLING is called from TEP
̲MAIN. In order to use the USP-commands, the operator
is requested to enter his password. KBD ̲DATA is called
in order to issue the prompt "PASSWORD ̲" and to receive
the answer. The operator has three attempts to enter
his password. The third time a wrong password is entered,
an error message is issued, and an alarm message is
sent (by call of SEND ̲REPORT, which makes and entry
into the AL-queue), and the procedure is exited. If
a correct answer is received, KBD ̲DATA is called in
order to issue the prompt "CMND ̲" and to receive the
answer. 3 answers are allowed: DSI, DSS and XIT.
D̲S̲I̲:
A pseudo MTCB containing a request to display
a user index table is sent to SAF (by call
of INVOKE ̲SAF ̲WAIT). The SAF-process receives
the MTCB in the SF-queue, generates the USP
table (containing all user -IDs on the N/M),
creates a logical line to the terminal and
displays the table. An answer is generated
and sent back in a pseudo MTCB to the terminal
process. The INVOKE ̲SAF ̲WAIT gets the queue
element and transfers the completion code to
USP ̲TABLE ̲HANDLING. The next USP command is
awaited.
D̲S̲S̲:
KBD ̲DATA is called in order to issue the prompt
"USER ID ̲" and to receive the answer. In the
variable MTCB ̲BLOCK a pseudo MTCB containing
a request to SAF of retrieving the profile
of the specified user. Further it contains
parametres to identify the buffer, in which
the answer shall be copied into. INVOKE ̲SAF
̲WAIT is called in order to send the pseudo
MTCB to SAF and await the answer. The SAF process
retrieves the USP-profile and copies it directly
into the specified buffer in the terminal process.
The retrieved profile is examined and if it
identifies a supervisor, an error is issued
(Supervisory profiles can only be changed from
the SCC). Otherwise the profile is displayed.
KBD ̲DATA is called in order to issue the prompt
" ̲" and to get the answer. (The operator is
requested to enter a new profile). If a carriage
return is received and the retrieved profile
was empty ("X" on all fields of the profile)
an error is issued. (It is not allowed to delete
an empty profile). If a carriage return was
received and the profile was not empty, then
a DELETE flag is set . Otherwise an UPDATE
flag is set. KBD ̲DATA is called in order to
issue the prompt "ACCEPT ̲". If a "Y" is returned,
INVOKE ̲SAF ̲WAIT is called in order to send
a request to SAF concerning a deletion/correction
of the user profile.
X̲I̲T̲:
The USP ̲TABLE ̲HANDLING procedure is exited.
3.3.7 P̲r̲o̲c̲e̲d̲u̲r̲e̲ ̲D̲S̲P̲ ̲Q̲ ̲S̲T̲ ̲P̲r̲o̲c̲e̲s̲s̲i̲n̲g̲
When a DQS command is entered from a terminal, the
SUPERVISION procedure is invoked from TEP ̲MAIN. This
procedure requests the operator to enter a terminal
ID. DSP ̲Q ̲ST is then called with the terminal number
as parametre. The terminal control block (TCB) of the
specified terminal is accessed in order to determine
whether the terminal is of type supervisory/supervisory
assistant or not. (In the last case, the supervisory
queues (AL and DT) are not displayed).
MON QACCESS, LENGTH is called in order to get the number
of elements in each of the queues of the specified
terminal.
GET ̲CRITICAL ̲REGION is called in order to get the skeleton
format of the queue status picture (the queue names).
If the terminal is not of the type supervisory, the
2 last fields in the table are deleted (AL - and DT
queues). The number of elements in each queue is converted
to ASCII and inserted in the table. The date-time group
is received by calling MON GETDTG. The DTG is inserted
in the table. The table is displayed by call of ITRANSFER
3.3.8 P̲r̲o̲c̲e̲d̲u̲r̲e̲ ̲I̲N̲T̲ ̲T̲E̲R̲M̲ ̲P̲r̲o̲c̲e̲s̲s̲i̲n̲g̲
This procedure is called from TEP ̲MAIN when a command
is entered and a test of the terminal control block
has discovered, that the INTERROGATE flag was set.
The purpose of this procedure is to perform the interrogation
of the user.
Procedure ITRANSFER is called in order to issue the
text "SECURITY INTERROGATION". The procedure ID ̲PASSWORD
is called in order to issue the prompt "USER ID ̲" and
to receive and validate the answer. If the answer was
illegal, the terminal is blocked, the event is logged
and an alarm is issued. If successful answer received,
then ID ̲PASSWORD is called in order to issue the prompt
"PASSWORD ̲" and to receive and validate the answer.
If the answer was illegal, the terminal is blocked,
the event is reported and an alarm is issued. If successfull,
then PSM ̲MESS is called in order to request the PSM
process to reset the interrogation flag in the control
block of the specified terminal.
3.3.9 P̲r̲o̲c̲e̲d̲u̲r̲e̲ ̲I̲N̲V̲O̲K̲E̲ ̲S̲A̲F̲ ̲W̲A̲I̲T̲ ̲P̲r̲o̲c̲e̲s̲s̲i̲n̲g̲
This procedure constitutes the interface to the SAF
process. Each time another procedure interfaces to
SAF, this procedure is called with a MTCB block as
parametre. Communication between SAF and the terminal
process takes place via the SF-queue of SAF and the
RD-queue of the terminal process.
Old elements in the RD-queue are deleted by subsequent
calls of QACCESS, READ ̲DEST until the queue is empty.
The MTCB block is updated and inserted in the SF-queue
by call of QACCESS, INS. The MTCB is released and a
signal which tells that an element has arrived in the
RD-queue is awaited. When the signal arrives, the RD-queue
is accessed and the element is read. The corresponding
MTCB is read, and then the queue element is deleted
(QACCESS, DEL). The completion code from the MTCB is
returned to the calling process.
3.4 D̲A̲T̲A̲ ̲O̲R̲G̲A̲N̲I̲Z̲A̲T̲I̲O̲N̲
Almost all variables and data structures used by SAF
are also used by the other modules in the terminal
process. Please refer to ref. 8, chapter 3.4.
3.5 S̲T̲O̲R̲A̲G̲E̲ ̲A̲L̲L̲O̲C̲A̲T̲I̲O̲N̲
Please refer to the compiler printout listings.
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̲
Some of the supervisory commands are performed by transferring
the command to SAF, SRR, PSM or DTS, and then await
the answer. As those processes all are run as background
processes with overlays, the processing may take some
time.
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̲
Error codes and labels are listed in the file ERROR
̲
PREFIX.S.
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̲
The compilation and linking of the SFS is an integrated
part of the entire terminal process. Please refer to
ref. 8
6 D̲R̲A̲W̲I̲N̲G̲S̲
Figure 3-1
Block Diagramme of the SFS Module
Figure 3.2.2-1
Subsystem Interfaces
