top - download
⟦4972debf8⟧ Wang Wps File
Length: 25265 (0x62b1)
Types: Wang Wps File
Notes: FIX/1200/PSP/107
Names: »4051A «
Derivation
└─⟦074b80a9e⟧ Bits:30006146 8" Wang WCS floppy, CR 0345A
└─ ⟦this⟧ »4051A «
WangText
0…05…0…07…/…0f…/ /…86…1
…02…
…02…
…02…
4051A
…02…FIX/1200/PSP/107
…02…OK/830920…02…
#
DTS SUBSYSTEM
PRODUCT
SPECIFICATION
FIKS
DTS SUBSYSTEM PRODUCT SPECIFICATION
FIX/1200/PSP/107
Ove Kaastrup
1
830920
…0e… 4051A …02…FIX/1200/PSP/107
…02…OK/830920…02… ii
DTS SUBSYSTEM PRODUCT SPECIFICATION
FIKS …0f…
1 830920 All First issue of document
4051A …02…FIX/1200/PSP/107
…02…OK/830920…02… iii
DTS SUBSYSTEM PRODUCT SPECIFICATION
FIKS
T̲A̲B̲L̲E̲ ̲O̲F̲ ̲C̲O̲N̲T̲E̲N̲T̲S̲
1 SCOPE ........................................ 1
1.1 INTRODUCTION ............................. 1
1.2 ABBREVIATIONS ............................ 2
2 APPLICABLE DOCUMENTS ......................... 2
3 MODULE SPECIFICATIONS ........................ 3
3.1 FUNCTIONAL CAPABILITIES .................. 3
3.2 INTERFACE DESCRIPTION .................... 6
3.2.1 Interface To TEP ..................... 6
3.2.2 Interface To Other Processes ......... 9
3.2.3 Other Interfaces ..................... 9
3.3 PROCESSING ...............................10
3.3.1 DTS ̲INIT .............................11
3.3.2 DTS ̲MAIN .............................11
3.3.3 REENTER ̲MSG ..........................14
3.3.4 FORMAT ̲DT ̲MSG ........................15
3.3.5 ACCESS ̲BITMAP ........................17
3.3.6 SCANN ̲DT ̲QUEUE .......................19
3.3.7 Utility Procedures ...................20
3.4 DATA ORGANIZATION ........................20
3.5 STORAGE ALLOCATION .......................21
3.6 PERFORMANCE CHARACTERISTICS ..............21
3.7 LIMITATIONS ..............................21
3.8 ERROR CODES/ERROR LOCATIONS ..............21
3.9 PREPARATIONS FOR DELIVERY ................22
APPENDIX 1: MODIFICATIONS OUTSIDE DTS
1 S̲C̲O̲P̲E̲
This document contains a function description and an
As-Built product specification of the DT-subsystem,
DTS.
1.1 I̲N̲T̲R̲O̲D̲U̲C̲T̲I̲O̲N̲
The functions of the DTS subsystem are meant as an
extension to the set of services offered to the supervisor/assistant
when handling messages which are delivered in the DT-queue.
Changes from existing supervisory procedures:
- The command DSM is removed
- The command DDT is slightly modified (the message
is not automatically deleted when no distribution
is requested)
- A new command REE is added which makes it possible
to reenter a message (delivered to DT-queue due
to orbit error, no trunks, SIP-timeout, or SIP-congestion)
into the network.
- All messages delivered to DT-queue are automatically
printed on a predefined ROP. The printed text includes
the allocated DT number
a reason text
the signal header
the 2 first text lines
acceptance time, retrieval time (if present)
the word 'ACTION:'
the message is printed in A4 format and surrounded
by classification type.
The implementation of the DTS subsystem emplies some
modifications in the surrounding S/W complex. A complete
list of the modules affected is given in Appendix 1
together with a brief description of the changes made.
1.2 A̲B̲B̲R̲E̲V̲I̲A̲T̲I̲O̲N̲S̲
Please refer to Ref. 1, Chapt. 1.2.
2 A̲P̲P̲L̲I̲C̲A̲B̲L̲E̲ ̲D̲O̲C̲U̲M̲E̲N̲T̲S̲
I: FIX/0100/MAN/0004, FIKS DATA I/F REFERENCE.
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̲
P̲R̲I̲N̲T̲O̲U̲T̲:̲
Each time an element is placed in the DT-queue, the
DTS process allocates a DT-number (between 1 and 480)
to the message connected to the queue element.
A PDB-message (containing the DT-number, a reason text,
the signal header and 2 text lines, acceptance and
retrieval time, and the word ACTION) is generated and
enqueued to PIP, which prints the messages on a predefined
ROP (the terminal number of the ROP is defined in the
critical region CONFIG).
If several elements are enqueued to DT-queue, the queue
is scanned and the element indicating the oldest message
of highest precedence is processed first.
The queue elements remain in the DT-queue after printout
and will not be removed until they are processed by
the supervisor (the upper screen on the terminal will
display the actual number of elements in the queue).
Queue elements, whose messages have already been printed
on ROP, are distinguished from new elements via the
pseudo MTCB, when an element has been processed, the
pseudo MTCB is updated with the allocated DT-number
in word 7.
L̲O̲C̲A̲L̲ ̲D̲I̲S̲T̲R̲I̲B̲U̲T̲I̲O̲N̲
Local distribution of messages in DT-queue is initiated
by entering the DDT-command. The operator is now requested
to enter the DT-number of the message (which can be
found in the first line of the printout). The DT-queue
is scanned, and if a match is found between the requested
DT-number and the DT-number in a queue element's pseudo
MTCB, the message id of the attached message is displayed.
If no match, an error notification is displayed and
the operator is prompted for a new DT-number.
Local distribution is performed by answering the prompt
DIST ̲TO ̲ as in previous versions (^terminal id^ or
^terminal id/no. of copies^). After local distribution,
the message (and the DT-queue element) is deleted and
the DT-number is released.
If no local distribution is wanted (DIST ̲TO ̲ prompt
is answered by carriage return), the prompt DELETE
̲ is issued. If 'Y' is answered, the message, queue
entry, and DT-number are deleted, otherwise the message
will remain in the DT-queue.
All types of messages, which have been entered in the
DT-queue, can be locally distributed.
R̲E̲M̲O̲T̲E̲ ̲D̲I̲S̲T̲R̲I̲B̲U̲T̲I̲O̲N̲
Remote distribution is initiated by entering the command
REE. The operator is prompted for DT-entry number,
and if the requested DT-number is found among the DT-queue
elements, the id of the message in question is displayed.
The prompt REENTER ̲ is now displayed and if the answer
is 'Y', the following actions are taken:
o a Real MTCB is created.
o a PDB file connected to the MTCB is created.
o the message is copied to the PDB-file.
o the routing mask in the message header is extracted.
o if the message is an orbiting message the routing
mask will contain those mede numbers which
did not receive the message. This routing
mask is inserted in the MTCB.
o if the message is placed in DT-queue due to
no trunks available, the pseudo MTCB will contain
the mede id, which trunk failed. A routing
mask containing this mede no. is generated
and inserted in the Real MTCB.
o if the message is placed in DT-queue due to
'SIP-congestion' or 'SIP-timeout' the Real
MTCB is enqueued to SIP. Otherwise the updated
MTCB is enqueued to NSS.
The DT-element, the message and the DT-entry
number are deleted.
If the answer to the REENTER ̲ proc is negative (carriage
return), the prompt DELETE ̲ is issued. The same actions
as in local distribution are then taken.
Only messages which have been placed in the DT-queue
due to either 'ORBIT ERROR', 'NO TRUNKS', 'SIP-TIMEOUT'
or 'SIP CONGESTION' can be processed by the command
REE. Attempts to reenter other types of DT-messages
will be rejected and and error notification is issued.
G̲E̲N̲E̲R̲A̲L̲
When a DT-entry number have been entered by the operator
and a match have been found, the number is marked as
occupied. The number remains in this state until the
processing of the DT-element is finished or the ongoing
operation is cancelled by the operator.
While the DT-entry number is marked as occupied, it
cannot be processed by other supervisors/assistants.
Attempts to enter an already occupied DT-number will
be rejected.
The DT-messages are numbered from 1 to 480. When 480
have been allocated, the next number used will be 1.
If this number is not released, the next free DT-number
is used, etc.
Each allocation of a DT-number is checkpointed which
means that the numbering sequence will not be disturbed
by a switchover/cold start.
3.2 I̲N̲T̲E̲R̲F̲A̲C̲E̲ ̲D̲E̲S̲C̲R̲I̲P̲T̲I̲O̲N̲
3.2.1 I̲n̲t̲e̲r̲f̲a̲c̲e̲ ̲t̲o̲ ̲T̲E̲P̲
Communication between terminal processes and DTS process
is performed by means of AMOS messages:
TEP sends requests to perform an inquiry or a task.
DTS answers by sending an AMOS answer containing a
completion code and eventually additional information.
R̲e̲q̲u̲e̲s̲t̲ ̲t̲y̲p̲e̲s̲ ̲c̲a̲n̲ ̲b̲e̲:
o REQ ̲CHECK ̲DT ̲NO: DTS scanes the DT-queue.
If a match is found, the
corresponding bit in ACTIVE
̲MAP is set (indicates that
the specific DT-number
is reserved by the operator
for further processing).
DTS returns a completion
flag. If true, the message
id is returned.
o REQ ̲DELETE ̲DT ̲NO: If the bit corresponding
to the DT-number is set
in ACTIVE ̲MAP (the DT-number
have been reserved by this
operator for further processing)
the message is deleted,
which means that:
the message MTCB is
released
the DT-queue element
is deleted
the bit in BIT ̲MAP
and ACTIVE ̲MAP are
reset
a completion code
is returned to TEP
in an AMOS answer
o REQ ̲REENTER ̲DT ̲NO: If the bit corresponding
to the DT-number is set
in ACTIVE ̲MAP, the message
is reentered, which means
that:
the message is copied
to a PDB file
a routing mask is
generated
the new message is
enqueued to NSS
the MTCB of the old
message is released
the DT-queue element
is deleted
the corresponding
bit in ACTIVE ̲MAP
and BIT ̲MAP is reset
a completion code
is returned as an
AMOS answer to TEP
o REQ ̲RELEASE ̲DT ̲NO: The bit corresponding to
the DT-number is reset
in ACTIVE ̲MAP. An AMOS
answer is sent to TEP.
(This request is used
when the operator cancels
the processing of a DT-number).
o REQ ̲DELETE ̲QUEUE ̲ELEM: Same actions as REQ ̲DELETE
̲DT ̲NO except that the message
MTDB is not released.
DTS ̲TEP ̲INTERFACE
3.2.2 I̲n̲t̲e̲r̲f̲a̲c̲e̲ ̲t̲o̲ ̲O̲t̲h̲e̲r̲ ̲P̲r̲o̲c̲e̲s̲s̲e̲s̲
MDS/TEP/PIP …0e… ̲ ̲ ̲…0f… DTS: Messages which cannot be
delivered (either locally
or external) are enqueued
to DT-queue. A pseudo
MTCB identifying the error
type and message id is
enqueued. The DT-queue
is served by DTS in precedence
order.
DTS …0e… ̲ ̲ ̲…0f… NSS: Messages to be reentered
are enqueued to NSS queue
as if it was a locally
released message. (Real
MTCB).
DTS …0e… ̲ ̲ ̲…0f… PURGE: The message MTCB is enqueued
to PURGE process if purging
is needed.
DTS …0e… ̲ ̲ ̲…0f… CHECKPOINT: When a DT-number is allocated.
This means that the CHECKP
̲FILE always holds the last
used DT-entry number.
This number is retrieved
by DTS at recevery/cold
start.
DTS …0e… ̲ ̲ ̲…0f… SIP: Messages with the error
types 'SIP CONGESTION'
or 'SIP-TIMEOUT' are reentered
by enqueuing them to SIP
PROCESS
3.2.3 O̲t̲h̲e̲r̲ ̲I̲n̲t̲e̲r̲f̲a̲c̲e̲s̲
Critical regions: CONFIG is accessed to determine
which ROP is going to be
used when printing out
DT-messages. (site dependent).
Files: PDB and HDB files are accessed
via MTCB monitor.
CHECKP ̲FILE is accessed
via CHECKPOINT process.
3.3 P̲R̲O̲C̲E̲S̲S̲I̲N̲G̲
This chapter contains a description of the internal
structure of DTS, and a brief description of the functionallity
of important procedures in the DTS subsystem.
Figure 3.3 shows the DTS subsystem block diagram.
Data structures and variables referred to in this chapter
are explained in details in chapter 3.4.
The DTS subsystem is built as an overlay program.
The program part is split into 4 overlays:
DTS ̲INIT.C: initialization (is only called once)
DTS ̲MAIN: main overlay (all overlay programs
enter this overlay when they have
finished execution).
REENTER ̲MSG: called by DTS ̲MAIN
FORMAT ̲DT ̲MSG: called by DTS ̲MAIN
Common procedures which are called by an overlay procedure
are merged together with the overlay procedure.
The process part of DTS is not in overlay.
The variable OVL ̲RETURN keeps track of which overlay
was the previously used overlay.
3.3.1 DTS ̲INIT (overlay procedure)
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
The procedure performs:
o initialization of MTCB monitor.
o LOOKUP on file RTT which contains the reason
texts, used when printing the DT-message.
o LOOKUP on the DTS overlay directory. The file
descriptor is used whenever an overlay procedure
returns to the main overlay.
o The local mede id is found and its number stored
in LOCAL ̲MEDE ̲ID.
o The procedure returns to DTS ̲MAIN overlay.
When once called, the overlay is not used again. This
overlay is initially loaded by ESP.
3.3.2 DTS ̲MAIN (Main overlay)
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
The initial processing in this module performs a recovery
of the DT-queue and local parameters (after recovery
or cold start):
o the BIT ̲MAP is recovered by scanning the DT-queue,
and setting a bit for each of the queue elements
(pseudo-MTCBs) which are marked with a DT-number.
o the last used DT-number is determined by retrieving
it via the CHECKPOINT process.
o the DT-queue is scaned and elements which are not
yet marked with DT-number are processed.
After initialization the module enters an infinite
loop containing a waiting point and a case construction
the branched of which take care of the set of events
which are foreseen.
Figure 3.3…01…DTS Subsystem Block Diagram
2 events are expected:
o a signal: indicates that an element has been
inserted in DT-queue. (Each time QACCESS
enters an element in DT-queue, a signal
is sent to DTS).
The event implies that the DT-queue is scaned and
the oldest element with highest precedence is fetched.
The pseudo MTCB is marked with DT-number (= DT
̲NO ̲LAST+1) and the corresponding bit is set in
BIT ̲MAP. The overlay procedure FORMAT ̲DT ̲MSG is
called, which takes care of the formatting of the
message to be printed. At last the new formatted
message is enqueued to PIP and the waiting point
is entered again.
o a message: indicates that a request is received
by
a terminal process. The request types
and the actions taken on them are
described in chapter 3.2.
3.3.3 REENTER ̲MSG (overlay procedure)
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
P̲r̲e̲r̲e̲q̲u̲i̲s̲i̲t̲e̲s̲:
The records P ̲MTCB ̲BLOCK and R ̲MTCB ̲BLOCK must contain
the pseudo MTCB of the DT-queue element and the Real
MTCB of the attached message respectively.
M̲a̲i̲n̲ ̲e̲v̲e̲n̲t̲s̲ ̲i̲n̲ ̲t̲h̲e̲ ̲p̲r̲o̲c̲e̲s̲s̲i̲n̲g̲:
o A Real MTCB and a PDB file attached to it is created.
o The message to be reentered is copied to the new
file.
o During the first transfer to the new file, the
routing mask is extracted from message header.
o A new routing mask is generated:
If the error type of the message is 'NO TRUNKS',
the mede id the trunks of which failed is fetched
from the pseudo MTCB (the index of which is the
queue element). the ROUTING ̲MASK is cleared and
the bit representing the failed mede id is set.
If the error type is 'ORBIT ERROR' the ROUTING
̲MASK fetched from message header will contain the
bits representing those medes which have not yet
received the message.
o The MTCB of the new message is updated with ROUTING
̲MASK.
o The new message is enqueued to NSS or in case of
SIP-error to SIP and the old message is released
(MTCB, RELEASEFILE, MTCB, RELEAS).
o The main overlay DTS ̲MAIN is entered.
3.3.4 FORMAT ̲AT ̲MSG
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
Prerequisites: The records P ̲MTCB ̲BLOCK
and R ̲MTCB ̲BLOCK must be
updated with the pseudo
MTCB of the queue element
and the attached Real MTCB.
M̲a̲i̲n̲ ̲e̲v̲e̲n̲t̲s̲ ̲i̲n̲ ̲t̲h̲e̲ ̲p̲r̲o̲c̲e̲s̲s̲i̲n̲g̲:
(The numbers refer to Figure 3.3.4).
o A pseudo MTCB and an associated PDB file is created.
o The first part of the DT-message is copied into
WORK ̲BUFFER (1) (see Figure 3.3.4).
o From binary header
is extracted: length of signal header,
address list offset,
acceptance DTG.
o The DT entry number (TEXT 1) is inserted in the
top of WORK ̲BUFFER (2).
o The reason text (corresponding to the message error
type given by SUBCAT in the pseudo MTCB) is fetched
from the RTT file and appended to TEXT 1 (3).
o If WORK ̲BUFFER contains parts of the message text,
the size of the 2 first text lines (if available)
is calculated.
o WORK ̲BUFFER is copied to the new PDB file (excluding
the text following the 2 first text lines) (4).
o If the 2 first text lines are not included in WORK
̲BUFFER, the next part of the message is fetched
and scaned until 2 text lines are found.
o The acceptance time and retrieval time (if it exists)
are converted to ASCII and inserted in 'TEXT 2'
(ref. source listing).
Figure 3.3.4…01…FORMAT ̲DT ̲MSG…01…Data Flow
o TEXT 2 and TEXT 3 (which contain the word: 'ACTION')
are appended to the PDB file.
o The pseudo MTCB is updated with byte length of
the new PDB file and with classification. The
words CAT and SUBCAT in the MTCB are updated as
if the attached message was of type 'REMAINS file'.
o The pseudo MTCB is enqueued to a predefined terminal
queue (DT-printout queue, ref. 3.3.1).
3.3.5 ACCESS ̲BITMAP
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
Common procedure called from several places. The procedure
operates on the arrays BIT ̲MAP and ACTIVE ̲MAP:
The process is divided into a set of cases. Each case
performs the command given at call of the procedure.
Interface description:
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲i̲n̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲o̲u̲t̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
̲ ̲ ̲ ̲ ̲ ̲
^
Register [ ^ Command # Completion
flag
" 1 ^ DT # DT#
" 7 ^ Completion
code
" 6 ^ LINK
The commands available are:
CMD ̲FIND ̲NEXT ̲DT ̲NO: It is checked that (DT
̲NO ̲LAST + 1) is free (the
corresponding bit in BIT
̲MAP is zero), if not, the
next bit is checked, etc.
If a free Dt-number is
found, the bit is set in
BIT ̲MAP and DT ̲NO ̲LAST
is updated. Otherwise
the completion code 'NO
̲VACANT ̲DT ̲NO' is inserted
in register 7.
CMD ̲CHECK ̲DT ̲NO ̲BIT: It is checked that the
specified DT# is set in
BIT ̲MAP (if not, the compeltion
code 'DT ̲NON ̲EXISTANT'is
set up). If the bit in
ACTIVE ̲MAP is zero, the
bit is set (DT# is marked
as occupied). Otherwise
the completion code 'DT
̲IN ̲USE' is set up.
CMD ̲CLEAR ̲DT ̲NO ̲BIT: The bit corresponding to
the specified DT# is reset
in BIT ̲MAP and ACTIVE ̲MAP.
CMD ̲CANCEL ̲IN ̲USE ̲BIT: The bit corresponding to
the specified DT# is cleared
in ACTIVE ̲MAP.
CMD ̲SET ̲DT ̲NO ̲BIT: The bit corresponding to
the specified DT# is set
in BIT ̲MAP.
3.3.6 SCAN ̲DT ̲QUEUE
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
Common procedure called from several places. The procedure
handles the access to the DT-queue. The processing
depends on the input command given at call in register
R[.
The commands are:
CMD ̲GET ̲NEW ̲ELEM: The 1. element of the DT-queue
is read. If its pseudo
MTCB is not opdated with
DT-number (word 7 = [ indicating
that this element has not
yet been processed), the
attached Real MTCB (that
of the DT-message) is read
and its precedence is extracted.
All elements in the DT-queue
are accessed in the same
manner. The one with the
highest precedence is the
wanted element. When found,
P ̲MTCB ̲BLOCK and R ̲MTCB
̲BLOCK are updated with
actual pseudo MTCB and
Real MTCB.
CMD ̲SEARCH ̲DT ̲NO: The DT-queue elements are
accessed ony by one until
a pseudo MTCB which contains
a DT-number matching the
requested DT-number is
found. P ̲MTCB ̲BLOCK and
R ̲MTCB ̲BLOCK are updated
with actual pseudo MTCB
and Real MTCB.
CMD ̲RECOVER ̲BITMAP: The DT-queue elements are
accessed one by one until
end of queue. When a pseudo
MTCB which holds a DT-number
is found, the procedure
ACCESS ̲BITMAP is requested
to update the corresponding
bit in BIT ̲MAP. (This
command is only used at
initialization).
3.3.7 U̲t̲i̲l̲i̲t̲y̲ ̲p̲r̲o̲c̲e̲d̲u̲r̲e̲s̲
Besides the procedures described in chapter 3.3.1 -3.3.6
the DTS subsystem contains a set of small utility procedures
as shown in Figure 3.3. For further description please
refer to the source listings.
3.4 D̲A̲T̲A̲ ̲O̲R̲G̲A̲N̲I̲Z̲A̲T̲I̲O̲N̲
A list of variables, arrays, and constants can be obtained
by printing the file DTS ̲VAR.S.
I̲m̲p̲o̲r̲t̲a̲n̲t̲ ̲d̲a̲t̲a̲ ̲a̲r̲e̲a̲s̲ ̲a̲r̲e̲:
BITMAP: An array of 30 words.
Each bit in the array represents
a DT-number. If set, the
DT-number can be found
among the elements in the
DT-queue.
ACTIVE ̲MAP: An array of 30 words.
If a bit is set, the corresponding
DT-message is being processed
by a supervisor/assistant.
DT ̲NO ̲LAST: The last allocated DT#.
The variable is checkpointed
each time it is updated.
At start/recovery the
variable is updated with
the retrieved checkpoint.
TEXT 1, TEXT 2, TEXT 3: Test strings used when
generating the DT-printout
message.
3.5 S̲T̲O̲R̲A̲G̲E̲ ̲A̲L̲L̲O̲C̲A̲T̲I̲O̲N̲
Program size: the size of lthe biggest overlay module
= ? (Ref. ESP printout).
Process size: = ?
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 subsystem is a background process using overlay
technique and having many disk accesses, the processing
of a DT-message may take a long time (up to 25 seconds).
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̲/̲E̲R̲R̲O̲R̲ ̲L̲O̲C̲A̲T̲I̲O̲N̲S̲
Error codes issued to the operator:
931: DT NON EXISTANT
932: DT IN USE (by other supervisor)
933: NO VACANT DT NO (480 elements in DT-queue)
934: MSG NOT MEANT FOR REE
936: SYSTEM ERROR (Resource error or
S/W error in DTS)
(The operation is aborted)
Error locations: #XY:
X denotes the procedure
number
Y denotes the error location
within procedure X
For details: please refer
to source listings.
3.9 P̲R̲E̲P̲A̲R̲A̲T̲I̲O̲N̲S̲ ̲F̲O̲R̲ ̲D̲E̲L̲I̲V̲E̲R̲Y̲
o Copy the source directory into a work directory
o Activate the command file DTS.CR[
o Activate the command file DTS.CP
o Activate the command file DTS.L[
I̲N̲S̲T̲A̲L̲L̲A̲T̲I̲O̲N̲
DTS ̲INIT.C is updated with version number and installed
in FIX ̲CONFIG.D.
The files DTS ̲MAIN, FORMAT ̲DT ̲MSG and REENTER ̲MSG is
installed in FIX ̲CONFIG.D * DTS ̲OVL.XXXX.D where XXXX
is the new version number. (Remenber to update the
variable DTS ̲OVL in the file DTS ̲VAN.S with this version
number before compilation).
A̲P̲P̲E̲N̲D̲I̲X̲ ̲1̲: MODIFICATIONS OUTSIDE DTS
The implementation of the DTS subsystem has caused
that some other S/W modules have to be modified. The
affected modules are:
1) Critical regions:
o CONF: in order to support the facility of
having different DT-printout terminal
numbers on each site, the constant
DT ̲PRINTOUT ̲TERMINAL has been included
in CONF.
o CRT: the Command Reference Table has been
updated with the new command REE (the
insertion of REE has implied that
the ESM command number is changed).
o PTT: the Prompt Text Table has been updated
in accordance with the new prompt
sequences.
o SYNR,
o SYNT: the Syntax Referende Table and the
Syntax Table have been updated in
order to meet the requirements of
the new syntax checks.
2) Other changes:
o MEDE ̲QACCESS: the QACCESS monitor has been
modified so that a signal is
send to DTS each time an element
is placed in DT ̲queue.
o M ̲Q ̲INIT: the process name DTS has been
included in the process name
table in QACCESS data area.
o TEP: changes in the supervisory distribution
module and some other modifications.
