top - download
⟦f0a101e64⟧ Wang Wps File
Length: 25544 (0x63c8)
Types: Wang Wps File
Notes: TEP VDU USER PACKAGE
Names: »1140A «
Derivation
└─⟦fad1c67d1⟧ Bits:30006043 8" Wang WCS floppy, CR 0069A
└─ ⟦this⟧ »1140A «
WangText
*…08…*…09…*…01…*…07…)…08…)…0a…)…01…)
) (…86…1
…02…
…02…
…02…
…02…CPS/SDS/027
…02…MSN/810801…02……02…
TEP VDU USER PACKAGE
…02……02…CAMPS
4̲ ̲ ̲P̲A̲C̲K̲A̲G̲E̲ ̲D̲E̲S̲I̲G̲N̲
4.1 P̲A̲C̲K̲A̲G̲E̲ ̲O̲V̲E̲R̲V̲I̲E̲W̲
The V̲DU U̲ser P̲ACKAGE (VUP) consists of two processes,
one process containing the software required to support
the VDU handling and one containing the software to
control the Preparation Database.
Overviews of these two processes are shown on fig.
4.1-1 and fig. 4.1-2 (Ref. also figure 4.1.2-1).
a) VDU User Subprocess (VUS)
This consists of four subpackages (coroutines):
VCO (U̲ser V̲DU C̲o̲ntrol ) which reacts upon commands
from TEMCO and controls the other coroutines as
well as maintaining the VDU Header Status Area.
UFCO (U̲ser F̲unction C̲o̲ntrol) which reacts upon
commands from VCO, F/C keys from keyboard and input
from the Answer Queue, the Receive Queue, the Release
Queue and the Response Queue. It also receives
input from RETR and controls VDIA. It contains
all the functions for c̲o̲n̲t̲r̲o̲l̲ of the MMI and interfacing
to other packages as well as command execution.
VDIA (V̲DU D̲i̲a̲logue) which reacts upon commands
from UFCO and performs input and output to and
from the VDU Format Area and validation of input
data.
RETR (R̲e̲t̲r̲ieval) which receives answers from SAR
(messages or error codes) on request sent to SAR
from UFCO. It communicates on-line retrieval results
to UFCO and off-line retrieval results to the Response
Queue.
Communication with other Packages (apart from Monitor
Calls) is done via queues. The VUS has six queues:
Command Queue:
Commands from TEMCO, timer events from Timer Monitor
and flash notification.
Answer Queue:
Answers to requests to other packages.
Receive Queue:
This consists of six subqueues, one for each precedence
level. Messages/comments for presentation at the
User VDU are sent to this queue.
Release Queue:
Messages for release.
Response Queue:
Release Notifications, Off-line Retrieval Results
(placed in the queue by RETR) and Deletion Notifications.
Retrieval Queue:
Retrieval Results received from SAR. (Off-line
retrieval results are sent to the Response queue
and off-line append results are sent to UMAM.
b) User Message Access Monitoring Process (UMAM)
This consists of two subpackages (coroutines):
PAC (P̲reparation A̲ccess C̲ontrol) which reacts upon
SSC commands and controls the other coroutine.
It receives input from the Preparation Queue and
the Request Queue and controls all messages/comments
under preparation and their status changes.
USFM (U̲ser S̲tatus F̲ile M̲aintenance) which reacts
upon commands from PAC and performs the actual
access to the Preparation Database.
UMAM has two queues:
- Preparation Queue:
Messages/comments prepared are sent to this queue
from SVUP, MDOS, MSOS and VUS. Also access state
changes (e.g. "sent for release" changes to "released").
- Request Queue:
The following requests are sent to this queue:
- Outgoing Message Status Request
- Outgoing Service Message Status Request
- Delivery Status Request
- Release Status Request
- Access state changes
Also access keys to messages to be appended are
sent to this queue by VUS.
For an overview of the inter process/subprocess
information flow ref. fig. 4.1-3.
Queues in the system to which VUP sends information
can be found in CPS/ICD/009.
Fig. 4.1-1…01…VUS Structure
Fig. 4.1-2…01…UMAM Structure
Fig. 4.1-3…01…VDU User Package Inter Process/Sub packages
4.1.1 F̲u̲n̲c̲t̲i̲o̲n̲a̲l̲ ̲S̲p̲e̲c̲i̲f̲i̲c̲a̲t̲i̲o̲n̲
This section contains an analysis of the main functions
to be performed by the VDU User PACKAGE (VUP).
The analysis is carried out to a level where subfunctions
with self-contained implementation considerations may
be isolated, thereby reducing the complexity to be
grasped at one time.
Furthermore, the aim of the analysis is to identify
precisely concurrency and priorities of subfunctions.
The analysis does not include the package functions
derivable from the functional responsibilities described
in section 2.2.2. These functions will be analyzed
and described for each identified subfunction in section
4.2 of this document.
In fig. 4.1.1-1 an overview of the VUP functions is
shown. This first level breakdown represents a simple
grouping of the requirements outlined in section 2
and of the requirements stated in ref. 2.
The box marked TEMCO CONTROL FUNCTIONS reflects the
fact that the VUP functions are totally controlled
by the TEMCO part of the SSC Software. Thus VUP shall
contain functions necessary to respond to and execute
such controlling commands.
Fig. 4.1.1-1 Main Functions
The boxes marked User TRANSACTION CONTROL and QUEUE
STATUS MAINTENANCE refer to all the functions to be
performed where a user has signed on, i.e. the activation
/ deactivation of those functions are controlled by
TEMCO, so the TEMCO CONTROL FUNCTIONS are those with
highest priority within VUP.
In the following subsections, each of the functions
shown in the boxes of fig. 4.1.1-1 will be broken down
into subfunctions.
4.1.1.1 T̲E̲M̲C̲O̲ ̲C̲o̲n̲t̲r̲o̲l̲ ̲F̲u̲n̲c̲t̲i̲o̲n̲s̲
In fig. 4.1.1.1-1, an overview of the TEMCO control
functions is depicted.
The first three, Initialization, Close Down and Restart
are used at initialization of the CAMPS system and
in recovery or system switchover situations, so compared
with the other functions in the group, they are seldom
invoked.
The function block terminal is called on by TEMCO after
an unsuccessful security interrogation or warning or
on supervisor command, and indicates that all VDU communication
is stopped immediately.
Fig. 4.1.1.1-1 TEMCO Control Functions
The start session and stop session are called by TEMCO
after user sign-on respectively sign-off has occurred.
The start session command from TEMCO is associated
with a capability list, informing VUP of the access
rights and security rights of the user. VUP is thereby
indirectly informed about which queues etc., it is
allowed to access, and which user transactions it may
execute. The stop session command informs VUP that
those access rights have now been withdrawn.
The release interrogation response is a control function
used at message release. When a releaser requests a
message to be released, VUP will send a request to
TEMCO, asking if the release function may be executed.
TEMCO will then answer yes or no to the request, thereby
activating the release response function.
The nature of the TEMCO control functions, i.e. their
close relationship with system integrity and security,
requires their immediate activation when called upon
by TEMCO. Thus this group of functions shall have the
highest priority within VUP. This implies that where
sequencing of the external events activating VUP functions
is introduced, those events activating TEMCO control
functions shall be taken out of sequence and handled
before all other events.
4.1.1.2 Q̲u̲e̲u̲e̲ ̲S̲t̲a̲t̲u̲s̲ ̲M̲a̲i̲n̲t̲e̲n̲a̲n̲c̲e̲
The headline Queue Status Maintenance covers the requirements
listed below:
- The periodic update of the VDU header queue status
line with a periodicity of one minute.
- The immediate update of FLASH (and superflash)
precedence queues each time an item is placed in
such a queue.
- The constant monitoring of FLASH (and superflash)
precedence levels to stay longer in the queues
than allowed by the supervisor. Such "old" items
shall be queued for the MDCO.
In fig. 4.1.1.2-1, a functional breakdown of the QUEUE
STATUS MAINTENANCE function is depicted.
Relating the figure to the summary of requirement given
in section 2.1, the breakdown should be self evident,
except for a few functions explained below.
The INVERT RELS/DISP TEXT functions are introduced
to satisfy the requirements for a unique indication
of which of the FLASH precedence queues contains elements.
As the number in the FLASH queue (ZZ-field) in the
queue status line is the total amount of items of FLASH
precedence queued in the receive queue and the release
queue, the relevant queue (s) RELS or DISP is displayed
in inverse video.
The INTERPRET FLASH NOTIFICATION function is a consequence
of System Design, where the following requirement was
introduced:
- When a package places an item in a FLASH (or Superflash)
precedence level queue, it shall place a FLASH
NOTIFICATION (indicating the relevant queue) in
the command queue as well.
The real time nature of the QUEUE STATUS MAINTENANCE,
together with the requirements for concurrency with
the User TRANSACTION CONTROL, implies that the QUEUE
STATUS MAINTENANCE functions shall have higher priority
than the User TRANSACTION CONTROL functions.
Fig. 4.1.1.2-1 Queue Status Maintenance
4.1.1.3 U̲s̲e̲r̲ ̲T̲r̲a̲n̲s̲a̲c̲t̲i̲o̲n̲ ̲C̲o̲n̲t̲r̲o̲l̲
The User Transaction Control Function (refer fig. 4.1.1-1)
contains the functions listed below. In the following
subsections, these functions will be analyzed in more
detail:
- TRANSACTION ACCOUNTING
- TRANSACTION INTERRUPTION
- TRANSACTION EXECUTION.
4.1.1.3.1 T̲r̲a̲n̲s̲a̲c̲t̲i̲o̲n̲ ̲A̲c̲c̲o̲u̲n̲t̲i̲n̲g̲
User transaction accounting refers to the collection
of statistical data and of log data and the subsequent
delivery of the data to the packages LOG and STP.
In fig. 4.1.1.3-1, a functional breakdown of the User
Transaction Accounting is depicted and for the case
of reading table 2.2-7 and table 2.2.-8 of section
2.2.2.5, these have been repeated as table 4.1-1 and
table 4.1-2 in this subsection. From the requirement
overview of log records to be reported (refer table
4.1-1), it is seen that a log record for some transaction
shall be sent to LOG both at transaction start and
transaction termination. Furthermore, it is seen from
table 4.1-2 that statistics data contain the duration
of use of a format, which implies that the start time
of transaction shall be kept by VUP until transaction
termination. The user transaction accounting therefore
splits into the two functions TRANSACTION INITIATION
ACCOUNTING and TRANSACTION TERMINATION ACCOUNTING.
An analysis of the statistics requirements shows that
the initial data to be collected are:
- Terminal designator
- Format id
- Start of transaction
and that the termination data to be collected are:
- Termination time
- Classification
- Precedence.
From table 4.1-1 it is seen that the initial statistical
data to be collected are a subset of the log data to
be collected, and that the termination statistical
data to be collected may be derived from the log data
except for precedence.
Log and statistics collection functions are thus related
through the data types to be collected.
The user transaction accounting functions shall be
performed at start and termination of a transaction.
The execution of the functions shall not be interruptable
due to data integrity and thus no other VUP function
shall be executed concurrently with the accounting
functions.
Fig. 4.1.1.3-1 Transaction Accounting
FORMAT I A C1 M O H B E1 D F P1 P2 N Q R DUMMY
G1 G3 E2 G2
Log Re-
cord (type,
control)
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
̲ ̲ ̲ ̲ ̲
Initial X X X X
Final X X X X X X X
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
̲ ̲ ̲ ̲ ̲
Term design X X X X X X X X X X X
Trans.ser.no. X X X X X X X X X X X
Format id X X X X X X X X X X X
Log time X X X X X X X X X X X
Item ref id X X X X X X X X
Exit Cause X X X X X X X X
Classification X X X X X
Spec.hand.cat. X X X X X
Start time of
transaction X X X X X
Item ref id X X X
Month + day X
Decision code X
Table 4.1-1 Log of User Transactions
CONTENTS TYPE 1 TYPE 2
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
Type and Contents Terminal Designator X X
of Statistics Format id X X
Duration of use X
Classification X
Precedence X
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
A X
B X
C1 X
Transactions identi- D X
fied through Format E1 X
ID and the statistics E2 X
to be collected F X
G1 X
G2 X
G3 X
H X
M X
N X
O X
P1 X
P2 X
Q X
R X
Table 4.1-2 Statistics on User Transactions
4.1.1.3.2 T̲r̲a̲n̲s̲a̲c̲t̲i̲o̲n̲ ̲I̲n̲t̲e̲r̲r̲u̲p̲t̲i̲o̲n̲
A functional breakdown of Transaction Interruption
is shown in fig. 4.1.1.3-2.
The EXECUTE FUNCTION KEY FUNCTION does not contain
a unique function to be performed for each function
key defined, as the function to be performed upon reception
of a function key, depends on the mode of operation
(e.g. interactive or receive mode) and the transaction
in progress, but executes the function corresponding
to the function key within the current context.
Fig. 4.1.1.3-2 Transaction Interruption
4.1.1.3.3 C̲o̲m̲m̲a̲n̲d̲ ̲I̲n̲t̲e̲r̲p̲r̲e̲t̲a̲t̲i̲o̲n̲
A functional breakdown of these functions is shown
on fig. 4.1.1.3-3. The functions are performed when
a command is entered in the Command Line of the VDU
Header.
Command Validation is performed to check that the command
is a valid User Command and acceptable in the current
context.
Command Parameter Validation is performed on parameters
entered with the command (if any).
Display Error Message is performed if the command or
parameters are not acceptable.
Fig. 4.1.1.3-3 Command Interpretation
4.1.1.3.4 C̲o̲m̲m̲a̲n̲d̲ ̲E̲x̲e̲c̲u̲t̲i̲o̲n̲
A functional breakdown of these functions is shown
on fig. 4.1.1.3-4
The boxes marked DEFINE VALID COMMANDS reflects that
the normal Command Code Validation shall be ignored
and that only specified command codes are valid during
transaction execution, i.e. the user is not allowed
to terminate a transaction in progress by initiating
another.
The heading OPEN FOR ACCESS TO RELEVANT SUBQUEUE is
just another way of expressing that the VDU shall enter
the receive, response or release mode of operation.
Fig. 4.1.1.3-4 Command Execution
4.1.1.3.5 S̲t̲a̲r̲t̲/̲S̲t̲o̲p̲ ̲T̲r̲a̲n̲s̲a̲c̲t̲i̲o̲n̲ ̲E̲x̲e̲c̲u̲t̲i̲o̲n̲
In fig. 4.1.1.3-5 a functional breakdown of the start/stop
transaction group is depicted. The boxes marked REQUEST
ACCESS TO ITEM contain the functions where VUP via
system software requests access to an item and TEMCO
performs a security interrogation and/or warning. Access
to the item will only be granted if so allowed by TEMCO.
Fig. 4.1.1.3-5 Start/Stop Transaction Execution
4.1.1.3.6 P̲r̲e̲p̲a̲r̲a̲t̲i̲o̲n̲ ̲o̲f̲ ̲M̲e̲s̲s̲a̲g̲e̲s̲/̲C̲o̲m̲m̲e̲n̲t̲s̲
In fig. 4.1.1.3-6, a functional breakdown of Preparation
of Messages/Comments is shown.
The DEFINE ALLOWED FUNCTION KEY INTERRUPTS reflects
that not all function key interrupts are allowed during
execution of the transaction. This function is not
part of the Command Execution as the analogue function
for commands DEFINE VALID COMMANDS, because function
key interrupts allowed are dependent on both the transaction
in progress and the processing state.
Fig. 4.1.1.3-6
Functional Breakdown of Preparation of Messages/Commands
4.1.1.3.7 P̲r̲e̲s̲e̲n̲t̲a̲t̲i̲o̲n̲ ̲o̲f̲ ̲Q̲u̲e̲u̲e̲d̲ ̲I̲n̲f̲o̲r̲m̲a̲t̲i̲o̲n̲
In fig. 4.1.1.3-7, a functional breakdown of Presentation
of Queued Information is depicted.
Fig. 4.1.1.3-7 Presentation of Queued Information
4.1.1.3.8 R̲e̲q̲u̲e̲s̲t̲s̲ ̲t̲o̲ ̲C̲A̲M̲P̲S̲ ̲S̲y̲s̲t̲e̲m̲
In fig. 4.1.1.3-8, a functional breakdown of Requests
to CAMPS System is depicted.
Comment Treatment Request, Message Treatment Request,
Release Decision Treatment and Append Request are all
of the type, where the request is not associated with
a command code, byt may be input as part of a transaction
via an input format. The print request is also associated
with a specific transaction but entered via a function
key, whereas retrieval and status requests are command
requests.
Note that the OUTPUT MESSAGE TEXT function for the
Append Request is shared with Message Preparation.
On fig. 4.1.1.3-9 to fig. 4.1.1.3-15, the next level
of breakdown of the request functions is shown.
Fig. 4.1.1.3-8
Fig. 4.1.1.3-9
Fig. 4.1.1.3-10
Fig. 4.1.1.3-11
Fig. 4.1.1.3-12
Fig. 4.1.1.3-13
Fig. 4.1.1.3-14
Fig. 4.1.1.3-15
4.1.1.3.9 D̲i̲a̲l̲o̲g̲u̲e̲ ̲F̲o̲r̲m̲a̲t̲t̲i̲n̲g̲
Functional breakdown of these functions is shown on
fig. 4.1.1.3-16. The functions all invoke calls upon
the Monitor Procedures of the FORMAT HANDLER in the
IOC Package. Via these procedures, the actual communication
with the VDU Format Area is performed. For details
refer to IOC Package Design Spec.
Fig. 4.1.1.3-16 Dialogue Formatting
4.1.1.3.10 F̲o̲r̲m̲a̲t̲ ̲V̲a̲l̲i̲d̲a̲t̲i̲o̲n̲
Functional breakdown of these functions is shown on
fig. 4.1.1.3-17.
HEADER FORMAT VALIDATION is performed after entry of
message header during Service Message Preparation.
TEXT FORMAT VALIDATION is performed after entry of
message text during service Message Preparation.
REQUEST FORMAT VALIDATION is performed after entry
of a request.
DISPLAY ERROR CODE FORMAT is performed when errors
are made during validation.
Fig. 4.1.1.3-17 Format Validation
4.1.1.4 U̲s̲e̲r̲ ̲M̲e̲s̲s̲a̲g̲e̲ ̲A̲c̲c̲e̲s̲s̲ ̲M̲o̲n̲i̲t̲o̲r̲i̲n̲g̲
This function contains the following two functions:
- Preparation Database Access Control
- Message Status Maintenance
(as shown on fig. 4.1.1.4-1)
These are broken down in greater detail in the next
subsections.
Fig. 4.1.1.4-1
4.1.1.4.1 P̲r̲e̲p̲a̲r̲a̲t̲i̲o̲n̲ ̲D̲a̲t̲a̲b̲a̲s̲e̲ ̲A̲c̲c̲e̲s̲s̲ ̲C̲o̲n̲t̲r̲o̲l̲
During System Design it was decided to assign a preparation
queue to each preparation terminal. This decision was
mainly taken due to the following two requirements:
- A user may only gain access to messages/comments
under preparation originated at the VDU to which
he is associated. (Thus one queue per VDU).
- A security related access control to items shall
be maintained by System Software. (Thus the use
of the queue structure, as access to queues is
controlled by System Software).
The Preparation Database Access Control function is
not concerned with security, but only with the requirements
to access control related to the preparation state
of the item. These requirements have been extracted
from the preparation related transactions described
in ref 2 and are tabulated in table 4.1.-3.
In fig. 4.1.1.4-2, a functional breakdown of the Preparation
Database Access Control is depicted.
The figure shows that the Preparation Database Access
Control Function on the first level of breakdown may
be considered to consist of:
- Access control related to edit requests
- Access control related to delete requests
- System rejection of inserting an element in a queue
- Access state changes.
From the above analysis it may be derived that:
- It shall be possible to access the preparation
queue of a VDU, even if no user is currently signed-on,
as it shall be possible to remove a message awaiting
release from the queue when released by the releaser.
- It shall be possible to change the access state
of a message, even if no user is currently signed-on,
as the state change may be caused by the releaser
or by SAR (on completion of an off-line append).
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
Access states Reported by Editing
access
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
Released Releaser N
M
Release Rejected Releaser Y
E
Release Deferred Releaser Y
S
Deleted Preparer N
S
Awaiting Release Preparer N
A
Awaiting Append Preparer N
G
Sent for Coordination Preparer Y
E
Suspended Preparer Y
S
Deferred Preparer Y
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
C
O Sent Preparer N
M
M Deleted Preparer N
E
N Suspended Preparer Y
T
S Deferred Preparer Y
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
Table 4.1-3 Preparation Database Access
Fig. 4.1.1.4-2 Prepartion Database Access Control
4.1.1.4.2 M̲e̲s̲s̲a̲g̲e̲/̲C̲o̲m̲m̲e̲n̲t̲ ̲S̲t̲a̲t̲u̲s̲ ̲M̲a̲i̲n̲t̲e̲n̲a̲n̲c̲e̲
According to requirements (ref 1 and ref 2) and System
Design (ref 3) the following status shall be maintained
by VUP:
- Outgoing Message/Comment Status
- Delivery Status
- Release Status.
Some of the entries in the status are changed during
the life-period of the status and some are not. This
fact has been extracted from ref 2 and in tables 4.1-4,
4.1-5 and 4.1-6, the entry types of each status have
beeT tabulated.
It has been decided to keep the changeable parts of
status in memory and only keep permanent entries on
disk-files.
The functional breakdown of the message/comment status
maintenance is depicted in fig. 4.1.1.4-3.
A comparison between the Outgoing Message/Comment Status
(refer table 4.1-4) and the access states for messages/comment
under preparation (refer table 4.1-3) gives an impression
of the close relationship between these two functions.
Thus the analogous requirements derived may be derived
for the update requests to the Outgoing Message/Comment
status.
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
Entries Changeable
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
Released N
M
Release Rejected N
E
Release Deferred N
S
Deleted N
S
Awaiting Release Y
A
Awaiting Append Y
G
Sent for Coordination Y
E
Suspended Y
S
Deferred Y
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
C
O Sent N
M
M Deleted N
E
N Suspended Y
T
S Deferred Y
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
Table 4.1-4 Outgoing Message/Comment Status Entries
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
Entries Changeable
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
Incoming Message N
Outgoing Message N
Message for Coordination N
Comment N
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
Table 4.1-5 Delivery Status
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
Entries Changeable
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
Released N
Rejected N
Deferred N
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
Table 4.1-6 Release Status
