top - download
⟦1e409c524⟧ Wang Wps File
Length: 45843 (0xb313)
Types: Wang Wps File
Notes: FIX/0100/MAN/0004
Names: »3932A «
Derivation
└─⟦4d5d1ede7⟧ Bits:30006147 8" Wang WCS floppy, CR 0342A
└─ ⟦this⟧ »3932A «
WangText
E…00……00……00……00…(…02……00……00…(
'…08…'…0f…'…06…&…0a…&…0f…&
&…05…&…06…%…08…%…0f…%…00…%…05…$…0a…$…0e…$…02…$…06…#…0b…#…0f…#…02…#…06…"…0b…"…0d…"…00…"…02…" "…07…!…0a…!…0e…!…02…!…06… …86…1 …02…
…02… …02…
3932A…02…FIX/0100/MAN/0004
…02…JJJ/880906…02……02…#
FIKS DATA I/F REFERENCE
…02…APE/830815…02……02…FIKS
11 F̲I̲L̲E̲S̲
11.1 T̲e̲m̲p̲o̲r̲a̲r̲y̲ ̲F̲i̲l̲e̲s̲
11.1.1 I̲n̲b̲o̲u̲n̲d̲ ̲M̲e̲s̲s̲a̲g̲e̲ ̲F̲i̲l̲e̲
The Inbound Message File (IMF) is a p̲e̲r̲m̲a̲n̲e̲n̲t̲ file
on the "fixed head" disc of a Node/MEDE.
The file is used for t̲e̲m̲p̲o̲r̲a̲r̲y̲ (appendix 40 seconds)
s̲t̲o̲r̲a̲g̲e̲ of messages inbound from the network.
Regarding the fixed size of the file and the necessity
of fast access during heavy load, the file organization
is so called contiguous.
T̲h̲e̲ ̲I̲M̲F̲ ̲i̲s̲ ̲a̲c̲c̲e̲s̲s̲e̲d̲ from several processes in parallel.
(NSS, MDS, SIP).
The file is divided into message areas of 9216 bytes
( = 18 segments) big enough for a message a maximum
length, including the binary header.
The b̲l̲o̲c̲k̲s̲i̲z̲e̲ equals the m̲a̲x̲i̲m̲u̲m̲ ̲p̲a̲c̲k̲e̲t̲ ̲s̲i̲z̲e̲: 5̲1̲2̲ ̲b̲y̲t̲e̲s̲.̲
Inbound packets are written in the file in a d̲i̲r̲e̲c̲t̲
manner: Packets from several messages are mixed
on the input trunks, but written message-wise in the
file; the messages are read from the file according
to precedence.
At f̲i̲l̲e̲ ̲c̲r̲e̲a̲t̲i̲o̲n̲ the IMF is entirely filled with pseudo
data just to fix its size.
The IMF contains all inbound messages (relay as well
as local) and all NSS generated messages (for the network
as well as for the local MEDE and a possible collocated
SCC).
T̲H̲E̲ ̲S̲I̲Z̲E̲ ̲O̲F̲ ̲T̲H̲E̲ ̲I̲N̲B̲O̲U̲N̲D̲ ̲M̲E̲S̲S̲A̲G̲E̲ ̲F̲I̲L̲E̲
A message area of the IMF for a relay message is reserved
from the time when the first packet is well received
by the Transport Station until the receipt of an ACK
from the next Node for the entire message.
Taking a relay message as a typical example this period
of time may be divided into:
a. Receipt of first packet - receipt of last packet.
b. Receipt of last packet - message put into Transport
Queue
c. Message in Transport Queue.
d. Removal from Transport Queue - Insertion into Trunk
Queue
e. Insertion into Trunk Queue - first packet out of
Trunk Queue
f. First packet out of Trunk Queue - last packet sent
g. Last packet sent - receipt of acknowledge for message
The periods of time are calculated in this way:
a. Without priority of messages the transmission time
during busy hours is 1/0.15 = 6.7 seconds for narrative
messages; assuming that the transmission time is
independent of precedence level, the ti`me is set
to 9̲ ̲s̲e̲c̲o̲n̲d̲s̲.̲
b. The time is much less that 1 second, so it is set
to 0̲ ̲s̲e̲c̲o̲n̲d̲.
c. The average waiting time in the Transport Queue
is 0̲ ̲s̲e̲c̲o̲n̲d̲.
d. The time is much less than 1 seconds, so it is
set to 0̲ ̲s̲e̲c̲o̲n̲d̲.
e. The average waiting time in the Trunk Queue is
2̲0̲ ̲s̲e̲c̲o̲n̲d̲s̲.
f. 9̲ ̲s̲e̲c̲o̲n̲d̲s̲, cfr. item a.
g. The time is set to 3̲ ̲s̲e̲c̲o̲n̲d̲s̲.
So the message are of the IMF is reserved 4̲1̲ ̲s̲e̲c̲o̲n̲d̲s̲
on average.
Each second the average number of messages written
in the IMF is:
IN…0f…n…0e…/8 = 1.992/8 = 0.25 msgs/sec.
all nodes
The average size of the reserved part of the IMF is:
0.25 * 41 = 10 messages of 18 segments.
Using a safety factor of 4, the size of a typical IMF
is:
0.25 * 41 = 10 messages of 18 segments.
Using a safety factor of 4, the size of a typical IMF
is:
10*18*4 = 720 segments = 0.360 Mbytes
However, another dimensioning criterion is very important:
to avoid "̲r̲e̲a̲s̲s̲e̲m̲b̲l̲y̲ ̲l̲o̲c̲k̲u̲p̲"̲. This dangerous lockup
could occur if the IMF is so small that it can not
contain one messgae per logical channel. Supposing
that a message of lowest precedence level is being
received on each input trunk of a node, but before
transmission of the last packet the transmissions are
all aborted by messages of a precedence level next
to the lowest; the transmissions of these messages
are also aborted etc., and sooner or later the entire
IMF is reserved by unfinished messages, and the node
is congested. Therefore the minimum size of the IMF
is:
NODE: A B E F H K L N
P Q
NO.OF TRUNKS: 3 3 5+1 4 4 6+1 6 5
1 1
NO.OF LOG.CHANNELS: 21 21 42 28 28 49 42 35
7 7
IMF,NO.OF SEGMENTS: 378 378 756 504 504 882 756 630 360
360
-, - - MBYTES: .194 .194 .387.258 .258 .452 .387 .323 .184
.184
For the SSC's: P and Q the maximum number of messages
is guaranteed to be 20.
11.1.2 T̲e̲m̲p̲o̲r̲a̲r̲y̲ ̲M̲e̲s̲s̲a̲g̲e̲ ̲F̲i̲l̲e̲s̲:̲ ̲P̲D̲S̲,̲ ̲T̲E̲F̲,̲ ̲T̲S̲F̲,̲ ̲T̲R̲F̲
N̲a̲m̲e̲: PDB Files
The individual names are 'PDB123', where '123' is a
3 digit file number. The files are placed in the directory
'PDB' on the disk volume 'MOVHEAD'.
D̲e̲s̲c̲r̲i̲p̲t̲i̲o̲n̲
The temporary message files is a pool of random files,
allocated to the application programs via the MTCB
Monitor.
This pool serves as a common resource for the following
"files":
PDB - Preparation Data Base
TEF - Temporary Edit File
TSF - Temporary Storage File
TRF - Temporary Remarks File
The files are created as random files (empty) at site
generation time, and they are reserved and released
(reset) via the MTCB Monitor.
S̲i̲z̲e̲ ̲a̲n̲d̲ ̲O̲r̲g̲a̲n̲i̲s̲a̲t̲i̲o̲n̲ ̲=̲
Random files with up to 126 blocks of 1 sector (= 512
bytes), thus maximum file size is:
126 x 512 bytes
(Note that a narrative message file is limited to 9000
characters = 9000 bytes).
11.1.2.1 P̲r̲e̲p̲a̲r̲a̲t̲i̲o̲n̲ ̲D̲a̲t̲a̲ ̲B̲a̲s̲e̲ (PDB)
F̲i̲l̲e̲ ̲L̲a̲y̲-̲o̲u̲t̲:̲
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
^ ^
^ ^ Binary header
^ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲^
^ ^
^ PREC ^
^ MSG ̲ID ^ Signal header
^ FM ... ^
^ TO ... ^
^ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲^
^ ^
^ CLASS ^
^ SIC ^
^ ^
^ TEXT ^ Signal text
^ ^
^ ^
^ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲^
^ ^
^ ^ Address list
^ ^
^ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲^
Binary header: contains routing information,
and message description.
Signal header/text: message contents, as SMF
Address list: extracted address information
from the message heder (FM,
TO, INFO, AIG, XMT)
The records in the signal are on line basis = one record
per line.
The records contain the record length and the formatted
line of the signal.
ST BC text NL
ST : Start line indication
BC : byte count, length of text
text: formatted text line
NL : new line, termination of line
11.1.2.2 T̲e̲m̲p̲o̲r̲a̲r̲y̲ ̲E̲d̲i̲t̲ ̲F̲i̲l̲e̲ (TEF)
The files contain messages during an editing sequence
of a PDB message.
The TEF is updated with the edited version of the PDB
message and becomes logically a "new" PDB message,
on request.
The TEF is identical to the PDB in structure, access
method, and the data are stored in the same format.
11.1.2.3 T̲e̲m̲p̲o̲r̲a̲r̲y̲ ̲S̲t̲o̲r̲a̲g̲e̲ ̲F̲i̲l̲e̲ (TSF)
File lay-out as for PDB.
- Used by the SCC Interface Process for temporary
storage of incoming messages to the collocated
SCC, in case the SCC is not active.
11.1.2.4 T̲e̲m̲p̲o̲r̲a̲r̲y̲ ̲R̲e̲m̲a̲r̲k̲s̲ ̲F̲i̲l̲e̲ (TRF)
F̲o̲r̲m̲a̲t̲ ̲o̲f̲ ̲t̲h̲e̲ ̲T̲R̲F̲
…0c…insert table…0c…
Start character : indicates start of line
Line length : length of line in characters.
Line characters : characters which constitute
the line.
A̲c̲c̲e̲s̲s̲ ̲t̲o̲ ̲T̲R̲F̲
The general method for file creation and release applies
i.e. via MTCB monitor.
R̲e̲l̲e̲a̲s̲e̲ ̲o̲f̲ ̲m̲e̲s̲s̲a̲g̲e̲
o Releaser comments to originator terminal
R̲E̲l̲e̲a̲s̲e̲ ̲r̲e̲m̲a̲r̲k̲s̲
…0c…insert tegning…0c…
The file contains:
- Notification for release or releaser remarks
The pseudo MTCB references the file:
…0c…insert tegning…0c…
For detail MTCB Structure see section 7.1
C̲o̲o̲r̲d̲i̲n̲a̲t̲i̲o̲n̲ ̲o̲f̲ ̲a̲ ̲M̲e̲s̲s̲a̲g̲e̲
C̲o̲o̲r̲d̲i̲n̲a̲t̲e̲ ̲R̲e̲m̲a̲r̲k̲s̲
…0c…insert tegning…0c…
11.1.2.5 M̲e̲s̲s̲a̲g̲e̲ ̲L̲o̲g̲ ̲F̲i̲l̲e̲ (MLF)
File lay-out: A contiguous string of
MRF-records
Lay-out of MRF-records: See chapter 11.2
File length: Variable
Contents: MRF-records of messages stored on the HDB
in a time span of 24 hours.
Access method: The same as for PDB files.
11.2 H̲D̲B̲ ̲L̲a̲y̲o̲u̲t̲
The HDB is laid out with the three contiguous files:
DTGF DTG File
MRF Message Retrieval File
MTF Message Text File, Refer to figure 11.2.1
Updates of DTGF and MRF are performed as updates in
an in-memory subset of these files. Whenever the inmemory
subset is full a transfer is made to the disc file.
The DTGF consists of 43200 entries corresponding to
30 days storage. One entry exists for each minute independent
of whether a message was stored or not.
One entry in the DTGF is one word long. This word is
the MRF record number of the first message in this
DTG. If no message has retrieval time equal to this
DTG the DTGF. If no message has retrieval time equal
to this DTG the DTGF entry is the MRF record number
of the first message after this DTG.
The MRF consists of 44500 records corresponding to
44500 messages.
One record contains:
MRF - ID
Retrieval DTG
Message security class
Bit mask with one bit per terminal
The bit is true if the corresponding terminal
has the right to retrieve the message.
3 SIC's
Message address on MTF. It is an offset
in sectors from the beginning of the MTF.
Message length.
ACATION- and INFO precedence
The MTF consists of contiguous space for storage of
44500 average messages (1000 bytes each). The messages
are stored on the MTF starting on a sector boundary.
This gives a wasted space of about 25% in average (the
space at end of one message until next sector boundary).
In the following blocksize = 512 bytes.
Figure 11.2-1
HDB Logical Structure
D̲T̲G̲F̲ ̲L̲a̲y̲-̲o̲u̲t̲
One control block and 171 data blocks.
The control block contains basic information about
the file. The control block is updated every time deletion
of messages is performed.
C̲o̲n̲t̲r̲o̲l̲ ̲b̲l̲o̲c̲k̲
Word Content
0-1 "DTGF" in ASCII
2 Year of creation
3 Date of creation
4-5 Number of blocks including control
block
6 Block size (bytes)
7-8 Number of entries in data part
9 Entry size (bytes)
10-11 Basic DTG corresponding to entry
#1
12-15 Spare
16-17 DTG of last deletion
18-19 DTG oldest message last deletion
20-21 DTG last message last deletion
22-255 Spare
D̲a̲t̲a̲ ̲B̲l̲o̲c̲k̲s̲
Each block contains 256 entries each one word long.
One entry is the MRF record number of the first message
in the DTG.
Totally 43.776 entries corresponding to 30 days 9 hours
36 minutes are contained.
N̲o̲t̲e̲:̲ Requirements ask for a least 30 days.
…0c…tegn…0c… Test space available will have an offset
of 4 hours 16 minutes or 256 entries.
Space required after deletion will be set to
at least 9 hours 36 minutes.
M̲R̲F̲ ̲L̲a̲y̲o̲u̲t̲
One control block and 2800 data blocks.
The control block contains basic information about
the file. The control block is updated every time deletion
of messages if performed.
C̲o̲n̲t̲r̲o̲l̲ ̲b̲l̲o̲c̲k̲
Word Content
0-1 "MRF"
2 Year of creation
3 Date of creation
4-5 Number of blocks
including control block
6 Block size (bytes)
7-8 Number of records in data part
9 Record size (bytes)
10-15 Spare
16-17 DTG last deletion
18-19 Record # oldest message last
deletion
20-21 Record # last message last deletion
22-255 Spare
D̲a̲t̲a̲ ̲b̲l̲o̲c̲k̲s̲
The 2800 data blocks consists of each 16 records with
each 32 bytes. Totally 44.800 records.
R̲e̲c̲o̲r̲d̲s̲
Byte Content
0-3 Retrieval DTG of message
4-7 MTF address*
8-9 Message length (bytes)
10-15 Message-ID
16-18 SIC1
19-21 SIC2
22-24 SIC3
25 Security class
26 APREC
27 IPREC
28-31 Termi`nal bit mask
*MTF data block (sector) # of first sector in message
N̲o̲t̲e̲:̲ Requirements ask for at least 44.500 messages.
As the layout of the MRF gives 44.800 records
or 18.75 blocks extra. Test Space Tests if
at least one block (16 records) free, and deletion
deletes so that at least 300 records free.
M̲T̲F̲ ̲L̲a̲y̲o̲u̲t̲
One control block and 108.649 data blocks.
The control block contains basic information about
the file. The control block is updated every time deletion
of messages if performed.
C̲o̲n̲t̲r̲o̲l̲ ̲b̲l̲o̲c̲k̲
Word Content
0-1 "MTF" in ASCII
2 Year of creation
3 Date of creation
4-5 Num`er of blocks including control
block
6 Block size (bytes)
7-8 Number of sectors data part
Sector size (bytes)
10-15 Spare
16-17 DTG last deletion
18-19 Sector # first sector oldest
message last deletion
20-21 Sector # last sector last message
last deletion
21-255 Spare
D̲a̲t̲a̲ ̲B̲l̲o̲c̲k̲s̲
110.269 data blocks contain narrative messages. A given
message is stored on consecutive blocks with first
part of message starting on the first byte of the block
with lowest number.
Block size = 1 sector = 512 bytes
A message fills 1-18 blocks.
N̲o̲t̲e̲
Requirements ask for 44.500 average messages.
Approximately 1/2 sector is wasted in average. The
figure next page gives with MIN = 75 MAX = 9.000 the
value 2.4652 sectors per message so that the MTF total
size is:
44.500 * 2.4652 = 109701.4 blocks.
Having the chance of wasting up to 17 sectors at the
end of the file a size 109719 data blocks is required
at least.
Using 110269 data blocks we may require a minimum space
to be free after message deletion of 550 blocks + maximum
size one message = 568 blocks.
11.3 R̲o̲u̲t̲i̲n̲g̲ ̲D̲i̲r̲e̲c̲t̲o̲r̲y̲ ̲F̲i̲l̲e̲ ̲R̲D̲F̲
11.3.1…02…R̲D̲F̲ ̲L̲a̲y̲o̲u̲t̲
The RDF contains information to be used in routing
and distributing of messages. The RDF is organized
as one file with the following layout:
ON DISK: INCORE:
…02…RDF HEADER…02……02… RDF AREA
…02…ANO EXISTENCE…02… NMI TABLE
…02…TABLE
…02……02……02……02……02… ANO EXISTENCE
…02…ANO TABLE…02……02… TABLE area to
…02……02……02……02……02… be check
…02……02……02……02……02… -pointed
…02…AIG EXISTENCE…02… LOCAL
…02…TABLE…02……02……02… ANO TABLE
…02…AIG TABLE…02……02… AIG EXISTENCE
…02……02……02……02……02… TABLE
…02…TNO TABLE
…02……02……02……02……02… ALT TABLE
…02…PLAIN ADDRESS
…02…TABLE
…02…ALT TABLE
…02…TERMINAL ID
…02…TABLE
…02…TAA TABLE
11.3.2…02…D̲e̲s̲c̲r̲i̲p̲t̲i̲o̲n̲ ̲o̲f̲ ̲t̲h̲e̲ ̲t̲a̲b̲l̲e̲s̲
…02…RDF HEADER:
This part contains the date when the RDF was created
and the version of the RDF layout.
…02…RDF ̲AREA:
This part contain pointers to the different incore
tables and the Node/MEDE ID table.
…02…ANO EXISTENCE TABLE:
This table contains information about all existing
ANO's for all MEDE's in the system.
A copy of this table is placed in the in-core RDF
at initialization of the MEDE/SCC.
…02…ANO TABLE:
Information about the relation between the ANO
number and the logical terminal number for each
MEDE are stored in this file.
A copy of the part for the current MEDE is placed
in the in-core RDF at initialization of the MEDE.
…02…AIG EXISTENCE TABLE:
This table contains information about the existence
of all the AIG's and the relation between logical
and physical aig numbers.
…02…AIG TABLE:
The table contains information about the grouping
of ANO's for each AIG.
…02…TERMINAL NUMBER TABLE:
This table contains information about the relation
between terminal ID number and the logical terminal
number.
…02…PLAIN ADDRESS TABLE:
this table contains the correspondance between
ANO and the Danish and English plain address text.
…02…ALT TABLE:
The table gives relation between the 'logical terminal
number' and the 'actual terminal number'. This
table is copied to the in-core RDF at initialization
time.
…02…TERMINAL ID TABLE:
This table contains information about the relation
between an area identifier (Node/MEDE), a logical
terminal number and its terminal identification.
…02…TAA TABLE:
this table gives the relation between the original
ANO destination and the current ANO destination
- rerouting.
…02…NMI TABLE:
This table contains information about the MEDE
numbers for each MEDE and the ID letter for the
current MEDE/SCC.
The in-core RDF is generated at initialization time
for the MEDE/SCC. The in-core RDF is accessed via monitor
procedures.
11.3.3…02…C̲r̲e̲a̲t̲i̲o̲n̲ ̲o̲f̲ ̲t̲h̲e̲ ̲R̲D̲F̲
The RDF is created and stored on disc at the SCC by
use of a special offline generation program - RDFGEN.
The RDF is created as sequential tables with fixed
size. To support Supervisor Functions for insert of
new entries, blank entries must be made in the generation
phase.
A copy of the RDF is moved to two floppy discs for
transfer to the Node/MEDE where the RDF is loaded to
the main disc (see figure below).
11.3.4…02…U̲p̲d̲a̲t̲e̲ ̲o̲f̲ ̲t̲h̲e̲ ̲R̲D̲F̲
11.3.4.1…02…F̲r̲o̲m̲ ̲S̲C̲C̲
The RDF can be updated at the SCC. A complete reorganization
of the RDF requires a new creation (ref. 11.3.3), whereas
table entry insert, correction and deletion can be
made from the supervisor console and will be transferred
to the Node/MEDE as single table updates. A change
to the RDF is transferred to each active Node/MEDE
via the local SAF module which updates the RDF on disc
and the related local tables in-core if these are affected
by the change.
11.3.4.2…02…L̲o̲c̲a̲l̲ ̲o̲n̲ ̲M̲E̲D̲E̲
The MEDE Supervisor has the possibility to change the
l̲o̲c̲a̲l̲ relation between ANO and terminal number which
is part of the local MEDE tables. The change is performed
only on the in-core RDF and not related to the RDF
on disc. The local update of this relation is overruled
if the SCC makes an update of that specific ANO.
11.3.5…02…R̲D̲F̲ ̲T̲a̲b̲l̲e̲ ̲L̲a̲y̲o̲u̲t̲ ̲D̲e̲s̲c̲r̲i̲p̲t̲i̲o̲n̲
In the following description, the terms used is the
same as defined in RDF ̲PARAMS:S .
11.3.5.1…02…N̲M̲I̲ ̲T̲a̲b̲l̲e̲
This table is initiated by the RDF ̲INIT program at
initialization time, and is only stored in the in-core
RDF, to be used to get an index to a specific MEDE
part of a table, i.e. ANO table, Terminal table, Plain
address table and Node/trunk table.
…02…The table has the following layout:
…02……02…BYTE…02…CONTENTS…02……02…MEDE ID
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
…02……02…0…02……02…Current
…02……02……02……02…MEDE LETTER
…02……02…1…02……02…1…02……02…A
…02……02…2…02……02…2…02……02…B
…02……02…3…02……02…0…02……02…C
…02……02…4…02……02…0…02……02…D
…02……02…5…02……02…3…02……02…E
…02……02…6…02……02…4…02……02…F
…02……02…7…02……02…0…02……02…G
…02……02…8…02……02…5…02……02…H
…02……02…9…02……02…0…02……02…I
…02……02…10…02……02…0…02……02…J
…02……02…11…02……02…6…02……02…K
…02……02…12…02……02…7…02……02…L
…02……02…13…02……02…0…02……02…M
…02……02…14…02……02…8…02……02…N
…02……02…15…02……02…0…02……02…O
…02……02…16…02……02…0…02……02…P
…02……02…17…02……02…0…02……02…Q
…02……02…18…02……02…0…02……02…R
…02……02…19…02……02…0…02……02…S
…02……02…20…02……02…9…02……02…T
…02……02…21…02……02…10…02……02…U
…02……02…22…02……02…11…02……02…V
…02……02…23…02……02…12…02……02…W
…02……02…24…02……02…13…02……02…X
…02……02…25…02……02…0…02……02…Y
…02……02…26…02……02…0…02……02…Z
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
The index table is addressed by converting the area
identifier and use the converted value as index:
…02……02…index = ASCII value of MEDE id - 64
As the MEDE id does not cover the complete alphabet
A to Z, the NMI table contains zeroes for nonexisting
MEDE's.
The contents of the table are used in calculation of
the offset for the actual table entry.
The first byte in the table contains the ASCII value
of the current MEDE id.
11.3.5.2…02…A̲N̲O̲ ̲E̲X̲I̲S̲T̲E̲N̲C̲E̲ ̲T̲A̲B̲L̲E̲
This table contains the bitmask for each ANO existing
for each MEDE or NATO identifier. The table has the
following layout:
…02……02……02…MEDE A…02……02…S ̲ANO ̲EX
…02……02……02…MEDE B
…02……02……02…MEDE E
…02……02……02……02……02……02…L ̲ANO ̲EX
…02……02……02…MEDE X
…02…The layout for each MEDE entry is as follows:
…02……02……02… bit no
…02……02…15…02……02……02…0 word
…02……02……02……02……02… 0
…02……02……02……02……02… 1
…02……02……02……02……02… 2
…02……02……02……02……02……02… S ̲ANO ̲EX/2
…02……02……02……02……02… 15
An ANO is defined as existing when its corresponding
bit is set.
11.3.5.3…02…A̲N̲O̲ ̲T̲a̲b̲l̲e̲
The table contains the relation between ANO and logical
terminal numbers.
The format of an ANO is:
…02……02……02……02……02… AXYZ
…02……02…MEDE or NATO identifier
…02……02…Number part
For each MEDE entry the number part is used directly
in the byte addressing.
…02…The ANO table has the following layout:
…02……02……02……02…MEDE A…02……02… S ̲ANO ̲TABLE
…02……02……02……02…MEDE B
…02……02……02……02…MEDE E
…02……02……02……02……02……02… L ̲ANO ̲TABLE
…02……02……02……02…MEDE X
…02…Each S ̲ANO ̲TABLE entry has the following format:
…02……02…ANO
…02… NUMBER…02……02……02…BYTE
…02……02… 1…02……02…term no term no 0
…02……02… 3…02……02…term no term no 2
…02……02…255…02……02…term no term no 254
Only this part of the ANO table - corresponding to
the current MEDE - is stored in the in-core RDF.
The term no has the value 1 to 30. If the value is
zero the ANO is nonexisting.
The values used for NATO identifiers are dummy values,
exept for zero.
11.3.5.4…02…A̲I̲G̲ ̲E̲X̲I̲S̲T̲E̲N̲C̲E̲ ̲T̲A̲B̲L̲E̲
The AIG Existence Table has one entry for each of the
256 possible AIG's. Each entry contains the 'Physical
AIG Number', which is the one known by the User. The
index to this table is named 'Logical AIG Number'.
The logical number is used internally by the S/W system.
…02…The table has the following layout:
…02……02……02……02……02……02… LOGICAL
…02……02……02……02……02……02… NO
…02……02……02……02…AIG Number…02……02… 0
…02……02……02……02…AIG Number…02……02… 1
…02……02……02……02…AIG Number…02……02… 2
…02……02……02……02……02……02… L ̲AIG ̲EX
…02……02……02……02…AIG Number…02……02… 255
AIG Number is in the range from 1600 to 13999. If the
value is zero the AIG is nonexisting.
The table is used as a lookup table to the AIG table.
11.3.5.5…02…A̲I̲G̲ ̲T̲A̲B̲L̲E̲
This table is used to indicate the ANO's contained
in the AIG's. Each AIG entry has a bitmask for each
MEDE (S ̲AIG ̲SUB) to indicate the ANO's contained in
the AIG.
…02…The AIG Table has the following layout:
…02……02……02……02……02……02… LOGICAL
…02……02……02……02……02……02… WORD NO.
…02……02……02……02… AIG NUMBER # X 0 S ̲AIG ̲TABLE
…02……02……02……02… AIG NUMBER # Y 1
…02……02……02……02… AIG NUMBER # Z 2 L ̲AIG ̲TABLE
…02……02……02… AIG NUMBER # XX 255
Each S ̲AIG ̲TABLE entry has the following layout:
…02……02……02……02… MEDE A…02……02… S ̲AIG ̲SUB
…02……02……02……02… MEDE B
…02……02……02……02… MEDE E
…02……02……02……02……02……02… S ̲AIG ̲TABLE
…02……02……02……02… MEDE X
Each S ̲AIG ̲SUB entry has the following layout:
…02……02……02……02……02……02…Bit No.
…02……02……02… 15…02……02……02… 0
…02……02……02……02……02……02… 16
…02……02……02……02……02……02… 32
…02……02……02……02……02……02… 48
…02……02……02……02……02……02… S ̲ANO ̲EX/2
…02……02……02…255…02……02……02… 240
where the bit for the corresponding ANO shall be set
to include the ANO in the AIG
There must only be 275 ANO's included in one AIG.
11.3.5.6…02…T̲N̲O̲ ̲T̲A̲B̲L̲E̲
The TNO Table contains logical terminal numbers. The
table is used to convert a terminal id into a logical
terminal number. For each Node/MEDE the table has 26*26
entry points to relate the logical terminal number
to the terminal id, which consist of the Node/MEDE
id (1.st letter followed by 2 letters for Comcenter:
…02……02…Terminal Id: X Y Z
…02… …02…MEDE/SCC
…02……02…MEDE/Comcenter Id
…02……02…MEDE/Term Id
The Comcenter Id is 'M' when Comcenter is not present.
…02……02…Example:
…02……02……02…E…02……02…D…02… Term A
…02……02……02……02……02……02… Term B
…02……02……02……02……02……02… Term C
…02…Id of Term A: EDA
…02……02……02… B: EDB
…02……02……02… C: EMC
11.3.5.7…02…P̲L̲A̲I̲N̲ ̲A̲D̲D̲R̲E̲S̲S̲ ̲T̲A̲B̲L̲E̲
The Table contains the plain language addressees for
the ANO's. For nonexisting ANO's the table contain
space characters.
The layout of the address table is as follows:
…02……02…MEDE
…02……02…A…02……02……02……02… S ̲ADDR ̲TABLE
…02……02…B
…02……02……02……02……02……02… L ̲ADDR ̲TABLE
…02……02…X
The layout of each S ̲ADDR ̲TABLE is:
…02……02…ANO
…02……02……02……02…Danish Text
…02……02…0…02……02……02……02… S ̲PLAIN ̲TEXT
…02……02……02……02…English Text
…02……02……02……02…Danish Text
…02……02…1
…02……02……02……02…English Text
…02……02……02……02……02……02… S ̲ADDR ̲TABLE
…02……02……02……02…Danish Text
…02……02…255
…02……02……02……02…English Text
When the ANO is an NATO ANO the contents of the Danish
Text field is a Routing Indicator.
The MEDE Id and the ANO number is used to address the
correct address field in the Plain Address Table.
The length of each plain text is 40 characters
11.3.5.8…02…A̲L̲T̲ ̲T̲A̲B̲L̲E̲
The ALT Table is used for rerouting of messages from
one terminal to another, withing the same MEDE
The table is located on disc and in-core, but only
the in-core table is maintained during operational
use.
The table contain the numbers from 1 to 30 equals the
maximum number of terminals connected to one MEDE.
There is dedicated one byte per number.
At initialization time the 'actual logical number'
equals the 'logical terminal number'.
When a rerouting has to take place from the terminal
with the logical number 15 to terminal number 25, the
contents of the logical terminal number field 15 changes
to 25. Now the 'actual logical terminal number' for
terminal number 15 is 25.
11.3.5.9…02…T̲E̲R̲M̲I̲N̲A̲L̲ ̲I̲D̲ ̲T̲A̲B̲L̲E̲
The Terminal Id Table (TID ̲TABLE) gives the relation
between the MEDE id, Logical Terminal Number and Terminal
Id.
This table is the opposite of the TNO Table.
The layout of the table is :
…02……02…MEDE
…02……02…A…02……02……02……02… S ̲TID ̲TABLE
…02……02…B
…02……02……02……02……02……02… L ̲TID ̲TABLE
…02……02…X
Each S ̲TID ̲TABLE has the following layout:
…02…TERMINAL NUMBER
…02……02…0…02……02……02……02… S ̲TERM ̲ID
…02……02…1
…02……02……02……02……02……02… S ̲TID ̲TABLE
…02……02…30
The contents of S ̲TERM ̲ID is the two last characters
of the Terminal Id.
Ex.: The contents of S ̲TERM ̲ID for a terminal with
logical number 19 and id KMC will be MC. The
first letter (K) is the MEDE id and is used
to get to the right table entry and the logical
number is used to get to the right field in
the table
11.3.5.10…02…T̲A̲A̲ ̲T̲A̲B̲L̲E̲
The TAA Table (Transfer to Alternative Ano) is used
for rerouting from one ANO to another ANO.
The table covers the FIKS ANO's.
The layout of the table is:
…02……02…MEDE
…02……02…A…02……02……02……02… 2*N ̲ANO
…02……02…B
…02……02……02……02……02……02… L ̲TAA ̲TABLE
…02……02…N
Each MEDE entry in the table has the following layout:
…02……02…ANO (word number)
…02……02…0…02…MEDE No ] ANO No
…02……02…1…02…MEDE No ] ANO No
…02……02……02……02……02……02… 2*N ̲ANO
…02… 255…02…MEDE No ] ANO No
The field for each ANO contains the MEDE number and
the ANO number of the alternative ANO. At initialization
time the contents of the table is the MEDE number and
ANO number of the ANO, e.g. the ANO F200 contains the
hex value 04C8. MEDE F has the value 4 and ANO number
200 = hex C8.
If a rerouting has to take place from F200 to A003
then the contents of the field for ANO F200 will change
to 0103 for ANO A003.
…02…THIS PAGE IS INTENTIONALLY LEFT BLANK
…02…THIS PAGE IS INTENTIONALLY LEFT BLANK
…02…THIS PAGE IS INTENTIONALLY LEFT BLANK
…02…THIS PAGE IS INTENTIONALLY LEFT BLANK
…02…THIS PAGE IS INTENTIONALLY LEFT BLANK
…02…THIS PAGE IS INTENTIONALLY LEFT BLANK
…02…THIS PAGE IS INTENTIONALLY LEFT BLANK
…02…THIS PAGE IS INTENTIONALLY LEFT BLANK
…02…THIS PAGE IS INTENTIONALLY LEFT BLANK
…02…THIS PAGE IS INTENTIONALLY LEFT BLANK
…02…THIS PAGE IS INTENTIONALLY LEFT BLANK
11.4 T̲e̲x̲t̲ ̲m̲a̲s̲k̲ ̲f̲i̲l̲e̲,̲ ̲T̲M̲F̲
The TMF contains the textmasks to be used in the preparation
procedure. The TMF is configured to be a directory
database containing one file only:
TMF
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
^ ̲ ̲d̲i̲r̲e̲c̲t̲o̲r̲y̲ ̲ ̲^
^
^
^ ̲ ̲ ̲ ̲ ̲ ̲ ̲
^ ^ index ^
^ ̲^ ̲ ̲ ̲ ̲ ̲ ̲ ̲^
^ text ^
^ ̲m̲a̲s̲k̲s̲ ̲^
Index: Contains information that describes the
content in the text mask pool.
Text masks: common pool of text masks, accessed via
index table.
F̲o̲r̲m̲a̲t̲ ̲o̲f̲ ̲t̲h̲e̲ ̲t̲e̲x̲t̲ ̲m̲a̲s̲k̲.̲
Two types of masks are possible:
1) line oriented
2) field oriented
In 1) the mask is fully formatted on a line by line
basis, with possible "fields" inside the lines incorporated
into the lines as blanks.
In 2) the mask is formatted on a line by line basis
with possible "fields" inside the lines controlled
by the "TAB control character.
When output the TAB option supported by the VDU is
used, i.e. positioning of the cursor to the "next"
8 character field is possible.
On a TP the TAB control characters are converted to
a "new line".
T̲e̲x̲t̲ ̲m̲a̲s̲k̲ ̲f̲i̲l̲e̲,̲ ̲T̲M̲F̲
…0c…insert tegning…0c…
F̲o̲r̲m̲a̲t̲ ̲o̲f̲ ̲t̲h̲e̲ ̲F̲i̲l̲e̲ ̲H̲e̲a̲d̲e̲r̲
The description of the file is given in the file header
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
^ ̲ ̲Record type ̲ ̲^
^ ̲ ̲R̲e̲c̲o̲r̲d̲ ̲l̲e̲n̲g̲t̲h̲ ̲ ̲ ̲^
^ Fole infor- ^
^ mation ^
^ o ^
^ o ^
^ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲o̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲^
Record type = 0 : file header
Record length = 25 :
File information
0 - 2 : name TMF in ASCII
3 - 4 : year of creation ASCII
5 - 6 : month of creation "
7 - 8 : date of creation "
9 - 10 : version number
11 - 12 : reference to index list
13 - 14 : reference to mask. pool
15 - 16 : number of masks
17 - 18 : length of mask pool
19 - 24 : spare
F̲o̲r̲m̲a̲t̲ ̲o̲f̲ ̲t̲h̲e̲ ̲m̲a̲s̲k̲.̲ ̲i̲n̲d̲e̲x̲ ̲l̲i̲s̲t̲
The table contains references to the text masks in
the mask. pool, and gives the type and the length of
the masks.
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
mask. 1 ^ mask. reference ^ one entry
^ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲^
^ length ^type^
^ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲^̲ ̲ ̲ ̲ ̲^
mask. 2 ^ ^
^ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲^
^ o ^
^ o ^
^ o ^
^ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲^
mask. n ^ ^
^ ^
^ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲^
mask. reference : offset to first byte in
mask.
type : type of mask.
= 0, line formatted
= 1, field formatted
length : length in bytes of characters
in the mask. pool for that
mask.
The index list is addressed using the mask. no. as
entry no., and calculation of the exact offset.
F̲o̲r̲m̲a̲t̲ ̲o̲f̲ ̲t̲h̲e̲ ̲m̲a̲s̲k̲.̲ ̲p̲o̲o̲l̲
The pool contains the text masks
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
^ ^ ^
^ text ^ ^
^ mask 1 ^ ^ one
^ ^ ^ entry
^ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲^ ^
^ ^
^ text ^
^ mask 2 ^
^ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲^
^ ^
^ text ^
^ mask 3 ^
^ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲^
^ o ^
^ o ^
^ o ^
^ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲^
^ ^
^ text ^
^ mask n ^
^ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲^
The entry for a mask is addressed via the index list.
F̲o̲r̲m̲a̲t̲ ̲o̲f̲ ̲t̲h̲e̲ ̲m̲a̲s̲k̲.̲ ̲e̲n̲t̲r̲y̲
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
^ ̲start character ̲^
^ line length ^
^ o ^
^ o ^
^ line character ^
^ o ^
^ o ^
^ ^
^ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲^
^ ̲start character ̲^
^ line length ^
^ o ^
^ o ^
^ line character ^
^ o ^
^ o ^
^ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲^
^ ^
^ ^
^ ^
^ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲^
^ ̲start character ̲^
^ line length ^
^ o ^
^ Line character ^
^ o ^
^ o ^
^ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲^
Start character : indicates start of line
Line length : length of line in characters,
inclusive control.
Line characters : characters which constitutes
the line
C̲o̲m̲m̲e̲n̲t̲ : The line characters contain
the 'TBD' control if mask
is
of field type.
A̲c̲c̲e̲s̲s̲ ̲t̲o̲ ̲T̲M̲F̲
The addressed text mask is accessed via the index table
with the mask id as key.
…0c…insert tegning…0c…
11.5 T̲e̲r̲m̲i̲n̲a̲l̲ ̲H̲a̲n̲d̲l̲i̲n̲g̲ ̲F̲i̲l̲e̲ ̲(̲T̲H̲F̲)̲
The TMF contains information to be used in interactive
terminal handling. The THF includes the following files:
^ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
^ ^ ^
^ ^ User security ^
^ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲^ profile ^ File 11.5.1
^ ^ ^
^ ^ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲^
^
^
^
^ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
^ ^ ^
^ ^ Command ^
^ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲^ Reference ^ File 11.5.3
^ ^ Table ^
^ ^ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲^
^
^
^
^ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
^ ^ ^
^ ^ Prompt ^
^ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲^ Text ^ File 11.5.4
^ ^ Table ^
^ ^ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲^
^
^
^
^ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
^ ^ ^
^ ^ Skeleton ^
^ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲^ Status ^ File 11.5.5
^ ^ Line ^
^ ^ ̲ ̲ ̲P̲i̲c̲t̲u̲r̲e̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲^
^
The following files are identified:
U̲s̲e̲r̲ ̲S̲e̲c̲u̲r̲i̲t̲y̲ ̲P̲r̲o̲f̲i̲l̲e̲ ̲(̲U̲S̲P̲)̲
The USP contains information about the user type, the
classification and the passwords related to each terminal
operator (user-id).
The USP is accessed by ITM, when a terminal logs on,
and by SFS when the supervisor updates the USP.
C̲o̲m̲m̲a̲n̲d̲ ̲R̲e̲f̲e̲r̲e̲n̲c̲e̲ ̲T̲a̲b̲l̲e̲ ̲(̲C̲R̲T̲)̲
The CRT contains the relation between the operator
command in ASCII and the actual command number, module
number and submodule number.
The CRT is accessed by ITM at initialization time and
after a restart.
P̲r̲o̲m̲p̲t̲ ̲T̲e̲x̲t̲ ̲T̲a̲b̲l̲e̲ ̲(̲P̲T̲T̲)̲
The PTT contains the relations between the command/sequence
number and the actual prompt text in ASCII code.
The PTT is accessed by ITM at initialization time and
after a restart.
S̲k̲e̲l̲e̲t̲o̲n̲ ̲S̲t̲a̲t̲u̲s̲ ̲L̲i̲n̲e̲ ̲P̲i̲c̲t̲u̲r̲e̲ ̲(̲S̲S̲L̲P̲)̲
The SSLP contains a skeleton picture of the queue status
line on VDU upper screen.
The SSLP is accessed by ITM at initialization time
and after a restart.
F̲i̲l̲e̲ ̲1̲ ̲U̲s̲e̲r̲ ̲s̲e̲c̲u̲r̲i̲t̲y̲ ̲p̲r̲o̲f̲i̲l̲e̲ ̲(̲U̲S̲P̲)̲
The file contains the security profile for each terminal
operator on the MEDE. At log ̲on time the terminal operator
gives an user ̲id, which is used to find his security
profile.
U̲S̲P̲ ̲S̲t̲r̲u̲c̲t̲u̲r̲e̲
User Security Profile
…0c…insert tegning…0c…
U̲s̲e̲r̲-̲I̲D̲ ̲T̲a̲b̲l̲e̲
The User-ID table is addressed by means of the user-ID
Table offset in the file header.
…0c…insert tegning…0c…
USER-ID : User identification (ASCII 4 bytes.
n : Number of user-id's defined at the MEDE.
m : Maximum number of user-id's allowed at
the MEDE.
P̲r̲o̲f̲i̲l̲e̲ ̲T̲a̲b̲l̲e̲
The Profile Table contains a number of identical profiles.
The profiles are addressed by means of the profile
table offset in the file header and the user index:
profile offset = profile ̲table ̲offset + user ̲index
* bytes ̲per ̲profile
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
0 ^ ̲ ̲u̲s̲e̲r̲ ̲t̲y̲p̲e̲ ̲ ̲ ̲ ̲ ̲^
1 ^ ̲ ̲C̲l̲a̲s̲s̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲^
^ ^
^ PASSWORD ^
^ (Encrypted) ^
^ ^
^ ^
^ ^
^ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲^
9 ^ ^
^ SH ^ N.B. If first
byte
^ ^ equal 0 then
^ PASSWORD ^ the user
has
^ (Encrypted) ^ no SH-password
^ ^
^ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲^
User type: 1 byte (INTEGER)
Message preparation operator = 1
Assistant supervisor = 2
Supervisor = 4
Classification: 1 byte (INTEGER)
The classification of the operators:
0: 14
Password: 8 bytes (ASCII)
SH Password: 8 bytes special handling password (ASCII)
Bytes ̲per ̲profile = 18
Re. Encrypted Passwords, ref
SDS for Minor FIKS Updates, FXA/SDS/008, sec.3
U̲S̲P̲ ̲I̲m̲p̲l̲e̲m̲e̲n̲t̲a̲t̲i̲o̲n̲
…0c…insert tegning…0c…
F̲o̲r̲m̲a̲t̲ ̲o̲f̲ ̲t̲h̲e̲ ̲F̲i̲l̲e̲ ̲H̲e̲a̲d̲e̲r̲
The description of the file is given in the file header
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
^ ̲ ̲Record type ̲ ̲^
^ ̲ ̲R̲e̲c̲o̲r̲d̲ ̲l̲e̲n̲g̲t̲h̲ ̲ ̲^
^ ^
^ File ^
^ information ^
^ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲^
Record type = 0 : file (INTEGER) 1 byte
Record length = 20 (INTEGER) 1 byte
File information
0 - 2 : name (USP in ASCII code) 3 bytes
3 - 4 : year of creation (ASCII) 2 bytes
5 - 6 : month of creation (ASCII) 2 bytes
7 - 8 : date of creation (ASCII) 2 bytes
9 - 10 : version number (ASCII) 2 bytes
11 - 12 : file size (INTEGER) 2 bytes
13 - 14 : user-id table offset (INTEGER) 2 bytes
15 - 16 : user-id table size(m) (INTEGER)2 bytes
17 - 18 : profile table offset (INTEGER)2 bytes
19 : spare 1 byte
F̲i̲l̲e̲ ̲3̲ C̲o̲m̲m̲a̲n̲d̲ ̲R̲e̲f̲e̲r̲e̲n̲c̲e̲ ̲T̲a̲b̲l̲e̲ ̲(̲C̲R̲T̲)̲
The file contains the Command Reference Table
(CRT), which is loaded to core at initialization/restart
tiem. The CRT contains a binary command number
and submodule number to each opertional procedure
command.
The CRT is organized with a header part, a command
part and a reference part
C̲R̲T̲ ̲S̲t̲r̲u̲c̲t̲u̲r̲e̲
…0c…insert tegning…0c…
T̲h̲e̲ ̲H̲e̲a̲d̲e̲r̲ ̲P̲a̲r̲t̲
The Header Part contains a command threshold to each
user type
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
^ ^
^ MPO ^
^ threshold ^
^ ^
^ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲^
^ ^
^ SA ^
^ threshold ^
^ ^
^ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲^
^ ^
^ S ^
^ threshold ^
^ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲^
MPO = Message Preparation Operator
SA = Supervisor Assistant
S = Supervisor
The threshold gives the maximum command number which
is allowed for the actual user type. (The actual value
is shown in figure 11.5.3-1 CRT overview).
The values are loaded at initialization time.
T̲h̲e̲ ̲C̲o̲m̲m̲a̲n̲d̲ ̲P̲a̲r̲t̲
The Command Parts consits for each command of a two
word area (CMD) containing the command in ASCII and
the command number.
…0c…insert tegning…0c…
The command part is loaded at initialisation time.
Reference Part
The Reference Part contains the module and submodule
number (one for each command)
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ Command number
^ ̲ ̲ ̲ ̲ ̲ ̲M̲O̲D̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲^ 1
^ ̲ ̲ ̲ ̲ ̲ ̲M̲O̲D̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲^ 2
^ ^ .
.
^ ^ .
.
^ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲^ .
^ ̲ ̲ ̲ ̲ ̲ ̲M̲O̲D̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲^ n
MOD:
Byte 0 : This is the submodule number
Byte 1 : This is the module number
The Reference Part is loaded at initialization time.
Figure 11.5.3-1
C̲R̲T̲ ̲I̲m̲p̲l̲e̲m̲e̲n̲t̲a̲t̲i̲o̲n̲
…0c…insert tegning…0c…
F̲i̲l̲e̲ ̲4̲
P̲r̲o̲m̲p̲t̲ ̲T̲e̲x̲t̲ ̲T̲a̲b̲l̲e̲ ̲(̲P̲T̲T̲)̲
The file contains the Prompt Text Table (PTT), which
is loaded to core at initialization/restart time.
The PTT contains all the prompt texts used in the interactive
procedures.
The PTT is organized with a Prompt Group Reference,
a Prompt Text Reference and the Prompt Table.
P̲T̲T̲ ̲S̲t̲r̲u̲c̲t̲u̲r̲e̲
…0c…insert tegning…0c…
P̲r̲o̲m̲p̲t̲ ̲G̲r̲o̲u̲p̲ ̲R̲e̲f̲e̲r̲e̲n̲c̲e̲s̲
This table contains a reference to each prompt group.
A prompt group is the group of prompt texts used by
an interactive command.
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
^ ̲o̲f̲f̲s̲e̲t̲ ̲t̲o̲ ̲p̲r̲o̲m̲p̲t̲ ̲g̲r̲o̲u̲p̲ ̲^
^ ̲ ̲ ̲ ̲"̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲"̲ ̲ ̲ ̲ ̲ ̲ ̲"̲ ̲ ̲ ̲^
^ ̲ ̲ ̲ ̲"̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲"̲ ̲ ̲ ̲ ̲ ̲ ̲"̲ ̲ ̲ ̲^
^ ̲ ̲ ̲ ̲"̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲"̲ ̲ ̲ ̲ ̲ ̲ ̲"̲ ̲ ̲ ̲^
^ ^
prompt group reference
^ ^
^ ^
^ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲^
^ ̲o̲f̲f̲s̲e̲t̲ ̲t̲o̲ ̲p̲r̲o̲m̲p̲t̲ ̲g̲r̲o̲u̲p̲ ̲^
Offset to prompt group (2 bytes)
The offset is related to the beginning of the prompt
text reference.
P̲r̲o̲m̲p̲t̲ ̲T̲e̲x̲t̲ ̲R̲e̲f̲e̲r̲e̲n̲c̲e̲
This table is organized with a prompt group for each
interactive command used from the terminal. A prompt
group contains a reference and length of each prompt
text used in the actual interactive command.
…0c…insert tegning…0c…
Offset to prompt text (2 bytes)
The offset is related to the beginning of the
prompt table
Length of prompt text (2 bytes)
This is the number of bytes in the prompt text.
P̲r̲o̲m̲p̲t̲ ̲T̲a̲b̲l̲e̲
This table contains all the prompt texts used in the
interactive procedures.
…0c…insert tegning…0c…
The prompt texts are stored in ASCII Code.
P̲T̲T̲ ̲I̲m̲p̲l̲e̲m̲e̲n̲t̲a̲t̲i̲o̲n̲
…0c…insert tegning…0c…
F̲o̲r̲m̲a̲t̲ ̲o̲f̲ ̲t̲h̲e̲ ̲F̲i̲l̲e̲ ̲H̲e̲a̲d̲e̲r̲
The description of the file is given in the File Header
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
^ ̲ ̲Record type ̲ ̲^
^ ̲ ̲R̲e̲c̲o̲r̲d̲ ̲l̲e̲n̲g̲t̲h̲ ̲ ̲^
^ ^
^ File ^
^ information ^
^ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲^
Record type = 0 : file header (INTEGER) 1 byte
Record length = 20 (INTEGER) 1 byte
File information
0 - 2 : name (PTT in ASCII code) 3 bytes
3 - 4 : year of creation (ASCII) 2 bytes
5 - 6 : month of creation (ASCII) 2 bytes
7 - 8 : date of creation (ASCII) 2 bytes
9 - 10 : version number (ASCII) 2 bytes
11 - 12 : file size (INTEGER) 2 bytes
13 - 14 : offset to prompt
group references (INTEGER) 2 bytes
15 - 16 : offset to prompt
text references (INTEGER) 2 bytes
17 - 18 : offset to prompt table (INTEGER) 2 bytes
19 : spare
F̲i̲l̲e̲
S̲k̲e̲l̲e̲t̲o̲n̲ ̲S̲t̲a̲t̲u̲s̲ ̲L̲i̲n̲e̲ ̲P̲i̲c̲t̲u̲r̲e̲ ̲(̲S̲S̲L̲)̲
The file contains the Skeleton Status Line Pictrue
(SSL), which is loaded to core at initialization/restart
time. The SSLP contains a picture of the three status
lines of a VDU upper screen. The first line contains
the abbreviated queue names, and line two and three
only contains spaces
S̲S̲L̲ ̲S̲t̲r̲u̲c̲t̲u̲r̲e̲
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
^ ^
^ Skeleton ^
^ ^
^ Status ^
^ ^
^ Line ^
^ ^
^ Picture ^
^ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲^
The picture is shown overleaf.
…0c…insert tegning…0c…
S̲S̲L̲ ̲I̲m̲p̲l̲e̲m̲e̲n̲t̲a̲t̲i̲o̲n̲
…0c…insert tegning…0c…
F̲o̲r̲m̲a̲t̲ ̲o̲f̲ ̲t̲h̲e̲ ̲F̲i̲l̲e̲ ̲H̲e̲a̲d̲e̲r̲
The descripton of the file is given in the file header
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
^ ̲ ̲Record type ̲ ̲^
^ ̲ ̲R̲e̲c̲o̲r̲d̲ ̲l̲e̲n̲g̲t̲h̲ ̲ ̲^
^ ^
^ File ^
^ information ^
^ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲^
Record type = 0 : file header (INTEGER) 1 byte
Record length = 20 (INTEGER) 1 byte
File information
0 - 2 : name (SSL in ASCII code) 3 bytes
3 - 4 : year of creation (ASCII) 2 bytes
5 - 6 : month of creation (ASCII) 2 bytes
7 - 8 : date of creation (ASCII) 2 bytes
9 - 10 : version number (ASCII) 2 bytes
11 - 12 : file size (INTEGER) 2 bytes
13 - 14 : offset to SSL (INTEGER) 2 bytes
15 - 19 : spares
