top - download
⟦35a84cb20⟧ Wang Wps File
Length: 29677 (0x73ed)
Types: Wang Wps File
Notes: IMPROVED MAN MACHINE INT.
Names: »0301A «
Derivation
└─⟦303071de8⟧ Bits:30006071 8" Wang WCS floppy, CR 0027A
└─ ⟦this⟧ »0301A «
WangText
*…08…*…0f…* )…0a…)…0e…)…00…)…07…'…86…H
…02…
…02…
…02…
…02…CPS/ECP/001
…02…JPR801114…02……02…#
IMPROVED
MAN MACHINE
INTERFACE
…02……02…CAMPS
T̲A̲B̲L̲E̲ ̲O̲F̲ ̲C̲O̲N̲T̲E̲N̲T̲S̲
1 INTRODUCTION .................................
4
2 PRICE QUOTATION ..............................
4 to 5
2.1 OVERALL REQUIREMENTS .....................
4
2.1.1 Baseline Update Costs ................
5
2.1.2 Schedule Extension Cost ..............
5
2.1.3 Cost of Implementing More Complex
Features .............................
5
3 SCHEDULE IMPACT ..............................
6
4 BIDDING PROVISIONS ...........................
6 to 7
4.1 VALIDITY .................................
6
4.2 DELIVERY .................................
7
4.3 ACCEPTANCE CRITERIA ......................
7
4.4 TYPE OF PROPOSAL .........................
7
4.5 PAYMENT PLAN .............................
7
5 ENGINEERING CHANGE DESCRIPTION ...............
8
5.1 PROPOSED SOLUTION ........................
8
5.2 CURRENT BASELINE .........................
8
5.3 DESCRIPTION OF CHANGE ....................
8
A̲N̲N̲E̲X̲ ̲1̲
1 INTRODUCTION .................................
9
2 THE BASIC CONCEPT ............................
9 to 12
2.1 ALTERNATE FORMATS ........................ 11
2.1.1 Supervisor Requirements .............. 12
2.1.2 Inexperienced Users .................. 12
2.2 ADDITIONAL REQUIREMENTS .................. 12
3 THE FULL CONCEPT ............................. 13
3.1 VALIDATION ............................... 14
3.2 ERROR MESSAGES ........................... 15
3.3 VDU HEADER ............................... 15
3.4 COMMANDS ................................. 16
3.5 PAGING AND SCROLLING ..................... 17
3.6 EXAMPLES ................................. 17
3.7 FORMAT GENERATION ........................ 17
4 IMPLEMENTATION ............................... 18
4.1 VDU-TO-HOST COMMUNICATIONS ............... 18
4.2 HOST-TO-VDU COMMUNICATIONS ............... 18
4.3 RECOVERY ................................. 18
4.4 RESPONSE ................................. 18
4.5 SECURITY ................................. 19
A̲P̲P̲E̲N̲D̲I̲X̲ ̲A̲
1 INTRODUCTION ................................. 20
2 INITIAL DIALOGUE ............................. 20
3 MESSAGE HEADER ............................... 23
to 30
3.1 VALIDATION ............................... 26
4 MESSAGE TEXT ................................. 30
5 MESSAGE DISTRIBUTION ......................... 30
to 32
6 FINAL EDITING ................................ 32
7 END OF TRANSACTION ........................... 32
E̲C̲P̲ ̲O̲N̲ ̲I̲M̲P̲R̲O̲V̲E̲D̲ ̲M̲A̲N̲ ̲M̲A̲C̲H̲I̲N̲E̲ ̲I̲N̲T̲E̲R̲F̲A̲C̲E̲
1̲ ̲ ̲I̲N̲T̲R̲O̲D̲U̲C̲T̲I̲O̲N̲
This Engineering Change Proposal covers the technical
and financial impacts for a proposed change of the
Man Machine Interface.
The present baseline is described in CPS/230/ICD/0001
and provides a teletype compatible man machine dialogue
with prompt/reply sequences.
The proposed change offers a VDU based dialogue based
on a formatted screen approached. This approach minimizes
the interaction between the VDU and the main computer
during input of data and consequently provides a faster
data input and a more convenient user interface.
2̲ ̲ ̲P̲R̲I̲C̲E̲ ̲Q̲U̲O̲T̲A̲T̲I̲O̲N̲
2.1 O̲V̲E̲R̲A̲L̲L̲ ̲R̲E̲Q̲U̲I̲R̲E̲M̲E̲N̲T̲S̲
The cost related to the change is a non-recurring cost.
The cost can be divided into three items:
a) update of existing baseline documents to reflect
the change
b) cost related to extension of the critical path
of the project.
c) Implementation of additional or more complex features.
The total cost of the change is D. Kr. 1.073.349,-.
2.1.1 B̲a̲s̲e̲l̲i̲n̲e̲ ̲U̲p̲d̲a̲t̲e̲ ̲C̲o̲s̲t̲s̲
a) update of System Requirements Specification CPS/210/SYS/0001 3
MM
b) development of new user procedures and
associated formats CPS/230/ICD/0001 7 MM
c) update of supervisor procedures
CPS/230/ICD/0002 4 MM
d) update to the system design specification
in production CPS/SDS/0001 3 ̲M̲M̲
Total ........................................ 17 MM
The cost of this effort is D. Kr. 848.849,-.
2.1.2 S̲c̲h̲e̲d̲u̲l̲e̲ ̲E̲x̲t̲e̲n̲s̲i̲o̲n̲ ̲C̲o̲s̲t̲
On the assumption that SHAPE gives approval not later
than the 20/11-1980 the program delay will be 1 month,
resulting in a cost increase of 1% of the contract
value for Main Line Items 4.2 SW Specifications, 4.4
Application SW Package Development, 4.5 DSMT SW Development
and 4.6 SW Test and Integration. Contract value of
these items is D. kr. 22.450.089,- and the Schedule
Extension Cost is thus D. Kr. 224.500,-
2.1.3 C̲o̲s̲t̲ ̲o̲f̲ ̲I̲m̲p̲l̲e̲m̲e̲n̲t̲i̲n̲g̲ ̲M̲o̲r̲e̲ ̲C̲o̲m̲p̲l̲e̲x̲ ̲F̲e̲a̲t̲u̲r̲e̲s̲
The following elements have impact on the development
cost:
a) VDU based syntax checking with development of VDU
format masks.
b) More complex correction and editing procedures,
resulting in a more complex terminal handling system.
c) Removal of teleprinter dialogue including formats
for status printout.
The development of the VDU dialogue is more complex
than the present baseline. However, in the interest
of providing a more modern VDU based dialogue, CR is
willing to undertake the extra development work at
no extra cost.
3̲ ̲ ̲S̲C̲H̲E̲D̲U̲L̲E̲ ̲I̲M̲P̲A̲C̲T̲
The development of a new VDU Man Machine Interface
will impact on the system/subsystem design specifications,
which are all on the critical path.
The overall schedule delay will amount to 1 month.
4̲ ̲ ̲B̲I̲D̲D̲I̲N̲G̲ ̲P̲R̲O̲V̲I̲S̲I̲O̲N̲S̲
4.1 V̲A̲L̲I̲D̲I̲T̲Y̲
The cost and schedule implications stated in 2 and
3 above are under the assumption that the go ahead
is given before the 20 of November 1980.
The price of the ECP assumes that SHAPE withdraws the
requirements for interactive use of the teleprinters,
i.e. teleprinters are only used for hardcopy printout.
4.2 D̲E̲L̲I̲V̲E̲R̲Y̲
The change will be delivered as part of the CAMPS software
package.
4.3 A̲C̲C̲E̲P̲T̲A̲N̲C̲E̲ ̲C̲R̲I̲T̲E̲R̲I̲A̲
The change has no impact on the present acceptance
baseline.
4.4 T̲Y̲P̲E̲ ̲O̲F̲ ̲P̲R̲O̲P̲O̲S̲A̲L̲
Firm fixed price proposal.
4.5 P̲A̲Y̲M̲E̲N̲T̲ ̲P̲L̲A̲N̲
30% at approval
60% at completion of Requirements
10% at completion of subsystem Design
5̲ ̲ ̲E̲N̲G̲I̲N̲E̲E̲R̲I̲N̲G̲ ̲C̲H̲A̲N̲G̲E̲ ̲D̲E̲S̲C̲R̲I̲P̲T̲I̲O̲N̲
5.1 P̲R̲O̲P̲O̲S̲E̲D̲ ̲S̲O̲L̲U̲T̲I̲O̲N̲
The proposed solution is presented in Annex 1.
5.2 C̲U̲R̲R̲E̲N̲T̲ ̲B̲A̲S̲E̲L̲I̲N̲E̲
The current baseline is presented in CPS/230/ICD/0001.
5.3 D̲E̲S̲C̲R̲I̲P̲T̲I̲O̲N̲ ̲O̲F̲ ̲C̲H̲A̲N̲G̲E̲
The Man Machine Interface (MMI) currently proposed
for CAMPS is to be implemented on Teletyper and VDU's,
and consists of prompt/reply sequences during which,
for every line of input, the user must first await
a prompt and then input data. This concept of prompt/reply
sequences is appropriate for a teletype MMI; but if
the requirements for teletype data-input is withdrawn,
a very much more useable VDU-based MMI could be substituted.
This proposal recommends a "Formatted Screen" approach,
in which the user is presented with a VDU screen which
looks like the familiar Message Form. The user fills
in the necessary header and text lines and can make
corrections by overwriting previously entered fields.
No prompts are needed as it is self-evident where data
should be entered and the user can move rapidly from
line to line inserting the necessary fields. In the
interests of speed of response, validation at this
stage of message-preparation is kept to the minimum.
Only when preparation is complete will CAMPS refer
to SIC lists, PLA tables etc. to check for errors.
The message is then re-displayed with error notations
in the margin.
During retrieval, messages are presented in exactly
the same format, though in this case the user cannot
make amendments.
The interactive teleprinter dialogue is removed.
A̲N̲N̲E̲X̲ ̲1̲
1̲ ̲ ̲I̲N̲T̲R̲O̲D̲U̲C̲T̲I̲O̲N̲
a) The CAMPS system as currently defined requires
both VDUs and Teletypes as Man-Machine interfaces
(MMIs). The VDUs will operate in a teletype mode
with roll up and page mode. This approach, based
as it is on the teletype concept of line-by-line
prompt/reply sequences, fails to exploit the full
potential that a MMI based only on a VDU could
offer.
b) This proposal describes a specific concept for
a VDU MMI, and examines the implications in system
and contractual terms.
2̲ ̲ ̲T̲H̲E̲ ̲B̲A̲S̲I̲C̲ ̲C̲O̲N̲C̲E̲P̲T̲
a) Under existing manual methods, originators are
used to drafting signals using a message form.
This form gives a skeleton layout so that it is
self-evident to the user, without any need for
specialised training, how to complete the form.
b) In the same way, a VDU-screen can be formatted
to resemble the layout of a message form. Furthermore
the cursor can be positioned at the first data-entry
field, and be moved automatically to the next field
when data-entry at the first field is
complete. If the user wishes to make an amendment
to any field he has already completed, he is subsequently
able to move the cursor back to a previous field
and overwrite it. Thus a simple message-entry format
might appear as:
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ = Data-entry field
Transaction ID
Classification Precedence
From
To
Info
Sic
Text
c) This concept can be further refined by giving each
field a descriptor, specifying whether the user
should input alpha, numeric or alphanumeric data,
and whether entry of data to the field is optional
or mandatory. (This descriptor could be visible
to the user in the form of a symbol preceding each
field, as a reminder of the type of data required)
d) Data-entry fields are the only part of the screen
where characters can be written; if the user tries
to move the cursor to the "protected" area of the
screen and input a character, an audible warning
will sound and the character-input with be ignored.
e) In summary, the basic VDU concept provides:
- A screen layout which resembles the familiar
signal-form.
- A brief "prompt" alongside each data entry
field
- Rapid sequencing through the fields during
data-entry (plus overwriting if the user wishes
to make changes); this contrasts with the teletype
system which requires the user to await output
of a prompt before he can input the next line,
and requires complicated editing commands.
- Character validation: the user cannot enter
too many characters; if he by-passes a mandatory
field or enters an incorrect type of character
he will be warned.
2.1 A̲L̲T̲E̲R̲N̲A̲T̲E̲ ̲F̲O̲R̲M̲A̲T̲S̲
A further important advantage of the concept of formats
is that data can be presented to different users in
different formats. For example:
2.1.1 S̲u̲p̲e̲r̲v̲i̲s̲o̲r̲ ̲R̲e̲q̲u̲i̲r̲e̲m̲e̲n̲t̲s̲
During Routing Assistance, an outgoing message must
be presented in a form which prevents alteration of
the message text, but allows certain lines to be amended
or added into the message header. This can be conveniently
achieved by presenting the message within the envelope
of a special Supervisor format, with different protected/unprotected
areas.
2.1.2 I̲n̲e̲x̲p̲e̲r̲i̲e̲n̲c̲e̲d̲ ̲U̲s̲e̲r̲s̲
A possible future enhancement to CAMPS would be special
formats for inexperienced users. The protected area
of the format could give detailed instructions as to
what type of data should be entered; the unprotected
data-entry fields would be identical to those of the
ordinary format.
2.2 A̲D̲D̲I̲T̲I̲O̲N̲A̲L̲ ̲R̲E̲Q̲U̲I̲R̲E̲M̲E̲N̲T̲S̲
The basic concept described above is suitable for straightforward
data-capture applications; but in military message-preparation,
the formats displayed on the VDU must be given an extra
degree of flexibility. Unlike the simplistic format
shown in Fig. 1, the real-life format must be easily
expanded to provide the user with a variable number
of Addressee and Text lines. For ADat P-3 message preparation
the degree of flexibility required is even greater
since the user may wish to repeat fields, sets or segments.Thus
the basic VDU concept must be expanded to give the
user a more flexible formatting system.
3̲ ̲ ̲T̲H̲E̲ ̲F̲U̲L̲L̲ ̲C̲O̲N̲C̲E̲P̲T̲
a) To meet the full CAMPS requirements, it is proposed
that the CAMPS user will be presented with a basic
format (as described above) which includes as many
repetitions of a line as are normally needed. In
addition, he will have the facilities to repeat
or insert a line or group of lines.
b) R̲e̲p̲e̲a̲t̲ A repeat command will have the effect of
repeating the current (as denoted by the present
cursor position) format line as an insert on the
next line. The cursor will be automatically repositioned
on this new line. Depending on the final choice
of VDU, this command will probably be achieved
by a single keystroke of a function key, since
it requires no parameters. Also VDU-dependent will
be the exact manner of the line insertion (i.e.
whether the lines below the insert move down or
those above it move up to accomodate the new line)
c) I̲n̲s̲e̲r̲t̲ To cater for insertion of lines not currently
on the screen (and therefore not "repeatable" as
in para 3b), for segments (i.e. groups of lines),
and for several insertions of the same line, an
"insert" command is envisaged. This will, like
the "Repeat" command, operate on the current cursor
position. It will also require the name of a line
or segnent to be given. An optional parameter will
be the number of repetitions.
d) D̲e̲l̲e̲t̲e̲ A delete command will allow the removal
of any optional or repeatable line. Like the Repeat
command, it will probably be implemented by function
key, and will delete the line currently occupied
by the cursor.
e) L̲i̲n̲e̲ ̲D̲e̲s̲c̲r̲i̲p̲t̲o̲r̲ So that the user and the system
will know whether a line is mandatory, optional
or repeatable, a Line Descriptor (similar to the
field descriptor proposed in para. 2 c) will be
given in the VDU margin, alongside each line.
f) C̲o̲m̲m̲a̲n̲d̲ ̲I̲m̲p̲l̲e̲m̲e̲n̲t̲a̲t̲i̲o̲n̲ Basic editing commands
(e.g. cursor left/right, character delete/insert)
will probably be implemented by VDU firmware and
be invisible to the Host machine (i.e. the CR80D)
until the revised text is transmitted back by the
VDU. However, Host involvement will be necessary
in commands involving re-organisation of the textlines
(such as the Repeat/Insert/Delete commands described
previously).
3.1 V̲A̲L̲I̲D̲A̲T̲I̲O̲N̲
a) In the original CAMPS teletype-based MMI, Validation
is specified as taking place line-by-line. Though
this gives the user the advantage of immediate
indication of an error, it is at the cost of wasting
one of the main assets of the modern VDU: its ability
to assemble data with the minimum of intervention
by the Host and hence very rapidly. The average
user will doubtless input error-free lines in most
cases, and hence is more likely to benefit from
very rapid system-response than from full line-by-line
validation.
b) Hence it is proposed that full semantic validation
takes place only after data-entry is complete (or
has reached a convenient break-point such as the
end of the message-header). Semantic validation
will be activated by a user command. During actual
data-entry, validation will be restricted to simple
syntax-checking such as can be achieved without
reference to system tables (e.g. SIC, PLA lists)
and if possible within the VDU itself. This approach
will allow the user to prepare a message very rapidly
and yet with full confidence that it will be thoroughly
validated later, before being sent for release.
3.2 E̲R̲R̲O̲R̲ ̲M̲E̲S̲S̲A̲G̲E̲S̲
a) During the syntax validation associated with data-entry,
error notification will be by the terminal "bell".
This will need no further amplification, since
the validation will be limited to checking mandatory/optional
and alpha/numeric/any-character fields, and the
error will be self-evident.
b) After Semantic validation by the Host, the message
will be represented at the user's VDU, with error
numbers in the left-hand margin. The fields in
error will be highlighted. If the user wants amplification
of the error-number, he can issue a command which
will result in an explicit error message being
displayed clear of the main format, in a "Response"
line at the top of the screen.
3.3 V̲D̲U̲ ̲H̲E̲A̲D̲E̲R̲
a) The use of a "Response" line has been described
above. More generally, split-screen working is
envisaged, so that a VDU screen-header will always
be present giving the following information:
- Terminal Function
- Classification of current screen contents
- Time
- Queue status
- Response Line)
) (see paras 3.4.c and 3.4.d
below)
- Command Line )
The frequency of update of this information would
be to some extent VDU-dependent, but would occur
sufficiently often to avoid being misleading.
3.4 C̲O̲M̲M̲A̲N̲D̲S̲
a) The need for "REPEAT", "INSERT" and "DELETE" commands
has already been described. Additional functions
that could be implemented by command are:
PRINT SUBMIT FOR RELEASE
SUSPEND END-OF-MESSAGE
CANCEL DISPLAY ERROR-MESSAGE
VALIDATE PAGE-BACK
CO-ORDINATE PAGE-ON
b) Commands not requiring parameters could be implemented
by function-key (depending on the precise facilities
of the VDU selected)
c) C̲o̲m̲m̲a̲n̲d̲ ̲L̲i̲n̲e̲ Commands requiring parameters will
be entered by pressing a "Command" function key
which will cause the cursor to jump to the Command
Line in the header. The user will then enter the
command on this line. On pressing the Return key,
the command will be executed, the command line
cleared, and the cursor repositioned back within
the main format area.
d) R̲e̲s̲p̲o̲n̲s̲e̲ ̲L̲i̲n̲e̲ Error-messages, and replies to Commands
(where appropriate) will be displayed on a Response
Line.
e) L̲a̲y̲o̲u̲t̲ The VDU-header will occupy the top four
lines of the VDU and appear as follows:
TERMINAL FUNCTION CLASSIFICATION TIME
QUEUE INFORMATION
COMMAND LINE
RESPONSE LINE
3.5 P̲A̲G̲I̲N̲G̲ ̲A̲N̲D̲ ̲S̲C̲R̲O̲L̲L̲I̲N̲G̲
a) During non-interactive functions (e.g. message
retrieval) the user will page through a message/comment;
this will be more convenient than making repeated
key-depressions to scroll through the text.
b) During initial preparation scrolling might at first
sight appear attractive. However because of the
ease with which the user can change from preparation
to editing (and during editing he may wish to move
rapidly through the text) paging is also needed:
c) In the interests of a straightforward user-interface,
it is proposed that only paging be provided, since
this satisfies the interactive and non-interactive
functions.
3.6 E̲X̲A̲M̲P̲L̲E̲S̲
Appendix A gives an example of message preparation
using the proposed VDU concept.
3.7 F̲O̲R̲M̲A̲T̲ ̲G̲E̲N̲E̲R̲A̲T̲I̲O̲N̲
a) VDU formats will be held as Data records in the
System Tables.
b) The message and comment preparation formats will
be provided with the system. Other formats will
be provided by the user.
c) A format-specification form will be provided for
SHAPE. An off-line format generation program will
be provided to allow entry of the data from the
completed forms to the system tables.
4̲ ̲ ̲I̲M̲P̲L̲E̲M̲E̲N̲T̲A̲T̲I̲O̲N̲
a) The detailed method of implementation will obviously
depend on the final choice of VDU for CAMPS: Factors
affecting the overall System design are discussed
below.
4.1 V̲D̲U̲-̲T̲O̲-̲H̲O̲S̲T̲ ̲C̲O̲M̲M̲U̲N̲I̲C̲A̲T̲I̲O̲N̲S̲
The VDU selected is likely to be able to buffer the
data-input from the user, passing it back to the Host
in blocks which are large enough to make efficient
use of the communications facilities. Transfers may
be initiated by the user or may (depending on the type
of VDU) be transparent. A block is always larger than
a line.
4.2 H̲O̲S̲T̲-̲T̲O̲-̲V̲D̲U̲ ̲C̲O̲M̲M̲U̲N̲I̲C̲A̲T̲I̲O̲N̲S̲
The normal unit of transmission to the VDU will depend
on the size of the VDU buffer; it is likely to be at
least a full screen of text.
4.3 R̲E̲C̲O̲V̲E̲R̲Y̲
The CAMPS system will store messages under preparation
in Segments which are related to the size of blocks
passed back from the VDUs (see para 4.1 above) and
which make efficient use of backing store. The system's
unit of recovery will be these Segments, which will
in any case never comprise more than one message.
4.4 R̲E̲S̲P̲O̲N̲S̲E̲
a) Cursor movement from field to field within a VDU
page will be extremely rapid; this is in contrast
to the delays of the prompt/reply teletype sequences
which the experienced user would find irritating.
b) The response time on paging will depend on how
much of the current page must be passed back to
the Host before the next page can be displayed,
and whether the next page is held within the VDU
buffer. In a worst case, there would be a pause
of approx. 6 seconds before the first line of the
next page was visible. Hardware changes to the
VDU/HOST communications would be required to improve
on this response-time.
4.5 S̲E̲C̲U̲R̲I̲T̲Y̲
a) From a security point of view, the proposed VDU
solution differs from the original VDU concept
only in that more of a message may be held within
the VDU buffer. In either case, CAMPS will provide
an environment in which transmission of data to
and from the VDU is closely controlled by the system,
and the VDU-memory is purged on sign-off.
b) Specific VDU Security features will include:
VDU Software in PROM.
Physical security-lock to prevent unauthorised
access.
A̲P̲P̲E̲N̲D̲I̲X̲ ̲A̲…01…T̲O̲ ̲V̲D̲U̲ ̲P̲R̲O̲P̲O̲S̲A̲L̲…01…E̲X̲A̲M̲P̲L̲E̲ ̲M̲E̲S̲S̲A̲G̲E̲ ̲P̲R̲E̲P̲A̲R̲A̲T̲I̲O̲N̲
1̲ ̲ ̲I̲N̲T̲R̲O̲D̲U̲C̲T̲I̲O̲N̲
a) The sequence that follows illustrates the type
of User/CAMPS dialoque that will take place if
this VDU proposal is implemented. The exact details
are of course implementation dependent.
b) The sequences are illustrated by VDU Layout diagrams
(Figs. 2 - 7). Fig. 1 shows the symbology used.
2̲ ̲ ̲I̲N̲I̲T̲I̲A̲L̲ ̲D̲I̲A̲L̲O̲G̲U̲E̲
a) After the user has signed on, he will be presented
with a VDU Header as in Fig. 2. From this he can
determine the current queue state and decide whether
to deal with incoming traffic, or to invoke the
message preparation format. The cursor is positioned
on the Command Line awaiting the function-selection
command.
b) Assuming that the user wishes to prepare a message,
he types the appropriate command. The system responds
with the Message Header format.
( = reverse field)
Unprotected data-entry
field
O INFO X
Line descriptor Field descriptor
(Note: a field without a field-descriptor indicates
a protected-field, the data for which will be supplied
by the system - e.g. DTG ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲)
L̲i̲n̲e̲ ̲d̲e̲s̲c̲r̲i̲p̲t̲o̲r̲s̲ Field descriptor
M = Mandatory
O = Optional
R = Repeating
F̲i̲e̲l̲d̲ ̲D̲e̲s̲c̲r̲i̲p̲t̲o̲r̲s̲
N = Mandatory numeric
n = Optional numeric
A = Mandatory alpha
a = Optional alpha
X = Optional any-character
x = Optional any-character
Fig. 1…01……01…S̲Y̲M̲B̲O̲L̲O̲G̲Y̲ ̲U̲S̲E̲D̲ ̲O̲N̲ ̲V̲D̲U̲ ̲L̲A̲Y̲O̲U̲T̲ ̲F̲O̲R̲M̲S̲
Fig. 2…01……01…VDU HEADER
3̲ ̲ ̲M̲E̲S̲S̲A̲G̲E̲ ̲H̲E̲A̲D̲E̲R̲ ̲(̲S̲e̲e̲ ̲F̲i̲g̲.̲ ̲3̲)̲
a) T̲r̲a̲n̲s̲a̲c̲t̲i̲o̲n̲ ̲N̲o̲ This protected field will have
already been filled in by the system.
b) C̲l̲a̲s̲s̲i̲f̲i̲c̲a̲t̲i̲o̲n̲ This is the first unprotected field:
the cursor will already be positioned there. The
user inputs the requisite two characters. The cursor
jumps automatically to the next unprotected field.
c) S̲p̲e̲c̲i̲a̲l̲ ̲H̲a̲n̲d̲l̲i̲n̲g̲ )
)
d) A̲c̲t̲i̲o̲n̲ ̲P̲r̲e̲c̲e̲d̲e̲n̲c̲e̲ ) The user inputs the
) requisite two characters
e) I̲n̲f̲o̲ ̲P̲r̲e̲c̲e̲d̲e̲n̲c̲e̲ )
f) D̲T̲G̲ This field will be completed by the system
when the message is released.
g) F̲r̲o̲m̲ This field will already have been completed
by the system (based on the user profile).
h) T̲o̲ Assuming that the user requires 2 action
addressees, he inputs PLAs or collective
addresses into the first two fields. He
then Tabs past the third field (there is
no need to delete it; unfilled optional
fields will be deleted during semantic
Validation).
i) I̲n̲f̲o̲ Assuming that the user requires 5 addressees,
he inputs the first 4 addresses and at
the end of the 4th field, instead of hitting
the Tab Key, he presses the Repeat Key.
A further "info" line is generated and
the cursor is positioned in the unprotected
area, ready for data-input (See Fig. 4)
Note that the SIC line of the format has
been displaced off the page.
Fig. 3…01……01… MESSAGE HEADER
Fig. 4…01……01… EXPANDED HEADER
j) X̲M̲T̲ Assuming the user has no exempt addressees,
he has now reached the end of this page:
C̲l̲a̲s̲s̲i̲f̲i̲c̲a̲t̲i̲o̲n̲ is a protected field which
will be completed by the system during
semantic Validation, in accordance with
the 2 letter classification indicator (input
at field b) above). The SIC line has been
displaced to page 2 (see i) above).
k) N̲E̲W̲ ̲P̲A̲G̲E̲ The user now hits the "Page-on" Key, since
the message header now extends onto the
second page.
Fig. 5 gives the format for the second
page.
l) S̲I̲C̲ At least l SIC is required; hence the first
SIC field is mandatory. The remainder are
optional.
3.1 V̲A̲L̲I̲D̲A̲T̲I̲O̲N̲
a) The user can now tab on to the first text field,
or choose to have the header validated. It is assumed
that he decides to select validation: he issues
the "Semantic Validate" command by hitting a Function
Key.
Fig. 5…01……01… Page 2 of Message
b) The results of the semantic validation are presented
in the same format as before, but with error numbers
in the margin (max. 3) (See Fig. 6). Fields where
errors occur are highlighted. If the user is unsure
of the meaning of an error code, he can issue a
command which will result in an explicit error-messages
being displayed on the Reply line of the VDU header.
Fig. 6…01……01… ERROR MESSAGES
c) The user now sequences through pages l and 2 of
the message and corrects all apparent errors. He
then issues the "Semantic Validate" command again.
This time there are no errors. A "No Errors" message
appears on the VDU-header reply line.
4̲ ̲ ̲M̲E̲S̲S̲A̲G̲E̲ ̲T̲E̲X̲T̲
a) The user now Tabs down to the Text section of the
message.This consists of 18 lines each consisting
of a 69 character field. The user can enter any
character from the approved character set.
b) Note that the first line has mandatory field and
line descriptors, since it is not possible to have
a text-less message, and hence at least one line
must be completed.
c) The user requires a further page of text. He hits
the Page-on Key and is given a page consisting
entirely of text fields.
5̲ ̲ ̲M̲E̲S̲S̲A̲G̲E̲ ̲D̲I̲S̲T̲R̲I̲B̲U̲T̲I̲O̲N̲
a) Once the user has finished entering text, he hits
the "End-of-message" function key. The text-page
is replaced by the Message Distribution format
shown in Fig. 7.
Fig. 7…01……01…DISTRIBUTION FORMAT…86…1 …02… …02… …02… …02…
b) C̲o̲-̲o̲r̲d̲i̲n̲a̲t̲i̲o̲n̲ Here the user enters the Staff Cell-Designators
for co-ordination.
c) D̲i̲s̲t̲r̲i̲b̲u̲t̲i̲o̲n̲ Here the user enters the Staff Cell
Designators for internal distribution.
6̲ ̲ ̲F̲I̲N̲A̲L̲ ̲E̲D̲I̲T̲I̲N̲G̲
The user may now page through the message again to
check it and make any modifications necessary (by overwriting
the previous field-contents). If he makes any changes
to the messages-header, he must re-submit it for semantic
Validation.
7̲ ̲ ̲E̲N̲D̲ ̲O̲F̲ ̲T̲R̲A̲N̲S̲A̲C̲T̲I̲O̲N̲
The transaction is completed by pressing one of 3 function
keys:
a) C̲o̲-̲o̲r̲d̲i̲n̲a̲t̲e̲ The message is sent for co-ordination.
b) R̲e̲l̲e̲a̲s̲e̲ The message is sent for release (it
must have been successfully validated,
otherwise the command is rejected).
c) S̲u̲s̲p̲e̲n̲d̲ The message is placed in abeyance.
