top - download
⟦9bb3e2842⟧ Wang Wps File
Length: 25666 (0x6442)
Types: Wang Wps File
Notes: CPS/SDS/001 ISSUE 1
Names: »0671A «
Derivation
└─⟦f9d7301d0⟧ Bits:30006008 8" Wang WCS floppy, CR 0043A
└─ ⟦this⟧ »0671A «
WangText
…0a… …0f… …06……1f……09……1f……0e……1f……0f……1f……00……1f……01……86…1
…02…
…02… …02…
…02…CPS/SDS/001
…02…OKH/810227…02……02…
CAMPS
SYSTEM
DESIGN
SPECIFICATION
…02……02…CAMPS
T̲A̲B̲L̲E̲ ̲O̲F̲ ̲C̲O̲N̲T̲E̲N̲T̲S̲
4.8 DATA BASES ........................... 280
4.8.1 Introduction ....................... 280
4.8.1.1 Online and Offline Data ........ 280
4.8.1.2 Basic Storage Organization ..... 282
4.8.1.3 Data Base Overview ............. 282
4.8.2 Message Storage .................... 288
4.8.3 Accountability and Auditing Data ... 290
4.8.3.1 Log Files ...................... 290
4.8.3.1.1 General Concept ............ 290
4.8.3.1.2 Log File Stages ............ 290
4.8.3.1.3 Log File Areas ............. 290
4.8.3.1.3.1…02…Main Memory .............. 290
4.8.3.1.3.2 Log Item Area ............ 291
4.8.3.1.3.3 Online Log Item Area ..... 291
4.8.3.1.3.4 Offline Log Item Area .... 291
4.8.3.2 Statistics Files ............... 291
4.8.3.3 Test- and Trace Output Files ... 291
4.8.4 Catalogues ......................... 291
4.8.4.1 Message Retrieval Catalogues ... 291
4.8.4.2 Log Retrieval Catalogues ....... 292
4.8.4.2.2.1 General Concept ...........292
4.8.4.2.2.2 Log Catalogue ............ 292
4.8.5 System Control Data ................ 292
4.8.5.1 System Parameters .............. 292
4.8.5.1.1 Configuration Tables ....... 292
4.8.5.1.2 Supervisor Control Data .... 293
4.8.5.1.2.1 Supervisor Tables ...... 293
4.8.5.1.2.2 Supervisor Parameters .. 293
4.8.5.2 Software Load Modules .......... 293
4.8.5.3 Virtual Memory ................. 293
4.8.5.4 Checkpoint Data ................ 293
4.8.6 Offline Initialization Data ........ 294
4.8.7 Access Mechanisms and Support
Functions .......................... 294
4.8.7.1 Access Methods ................. 298
4.8.8 CAMPS Internal Message Format ...... 299
4.8.8.1 General Description ............ 299
4.8.8.1.1 Purpose .................... 299
4.8.8.1.2 Design Considerations ...... 299
4.8.8.1.3 Message Formats Flow ....... 299
4.8.8.1.4 Internal Message Model ..... 301
4.8.8.2 Detailed Description ........... 303
4.8.8.2.1 Field Description .......... 303
4.8.8.2.1.1 Information Field ...... 305
4.8.8.2.1.2 Header Field ........... 308
4.8.8.2.1.3 Text Field ............. 308
4.8.8.2.1.4 Address Field .......... 308
4.8.8.2.1.5 Operating Signals Field 309
4.8.8.2.1.6 Notification Field ..... 309
4.8.8.2.1.7 Routing Field .......... 309
4.8.8.2.1.8 Distribution Field ..... 310
4.8.8.2.2 Record Description ........... 310
4.8 D̲A̲T̲A̲ ̲B̲A̲S̲E̲S̲
4.8.1 I̲n̲t̲r̲o̲d̲u̲c̲t̲i̲o̲n̲
This section describes general aspects about the data
processed by CAMPS. The three main issues are:
a) Principles for organization and structuring of
data
b) General access mechanisms
c) Support functions
For the description it is convenient to divide CAMPS
data into two different functional types:
1) Operational data, which are data "flowing through"
CAMPS, such as messages, comments etc. Some types
of operational data must be kept by the system
for a period of time as h̲i̲s̲t̲o̲r̲i̲c̲ ̲d̲a̲t̲a̲.
2) System control data, which are tables, system parameters,
programs etc., which are mainly used to control
the processing of operational data. System control
data may occasionally be backed up.
4.8.1.1 O̲n̲l̲i̲n̲e̲ ̲a̲n̲d̲ ̲O̲f̲f̲l̲i̲n̲e̲ ̲D̲a̲t̲a̲
The CAMPS data will be stored partly on permanently
mounted disk volumes, called o̲n̲l̲i̲n̲e̲ ̲s̲t̲o̲r̲a̲g̲e̲ and partly
on a number of removable disk volumes, called o̲f̲f̲l̲i̲n̲e̲
s̲t̲o̲r̲a̲g̲e̲.
Online storage contains system control data and that
part of operational data which is still being processed
or has most recently been processed by the system.
Offline storage contains the Historic Data Base, which
consists of selected operational data having been processed
by the system. Moreover, it contains initial and back-up
versions of system control data.
The relations between the storage types are as shown
in Figure 4.8.1.1-1.
During CAMPS operation, operational data continuously
flow into the online operational storage area. Occasionally,
the data which have been completely
processed are offloaded to historic data base.
The system control data may be updated by the supervisor,
editing tables etc. Occasionally, a back-up of the
current version may take place.
In order to re-use a data unit currently in offline
storage, the unit must be transferred back to online
storage. There are two main cases of that:
1) Operational data may be brought back by the RETRIEVAL
function.
2) System control data may be brought back by a FULL
INITIALIZATION, which is supposed to be a very
rare event.
Figure 4.8.1.1-1…01…O̲N̲L̲I̲N̲E̲ ̲A̲N̲D̲ ̲O̲F̲F̲L̲I̲N̲E̲ ̲S̲T̲O̲R̲A̲G̲E̲
4.8.1.2 B̲a̲s̲i̲c̲ ̲S̲t̲o̲r̲a̲g̲e̲ ̲O̲r̲g̲a̲n̲i̲z̲a̲t̲i̲o̲n̲s̲
Storage of data within CAMPS will make use of the following
three types of organization:
a) F̲i̲l̲e̲
A file is an unstructured variable length string
of bytes which can be manipulated by reading or
modifying substrings within the string.
b) I̲t̲e̲m̲
An item is a record with a fixed number of variable
length fields. Items are particularly suited for
manipulation of very dynamic data types like messages.
It is expected that there will be a point in time
from which an item is not going to be updated.
c) T̲a̲b̲l̲e̲
A table is an array with a variable number of fixed
length elements, called table entries. Table entries
are addressed by index, search key or table interrelationship.
The storage types are shown overleaf.
4.8.1.3 D̲a̲t̲a̲ ̲B̲a̲s̲e̲ ̲O̲v̲e̲r̲v̲i̲e̲w̲
The following diagrams show a break down of the data
base according to the online-offline criteria and the
major responsibility areas of software packages.
Figure 4.8.1.2-3…01…S̲T̲O̲R̲A̲G̲E̲ ̲O̲R̲G̲A̲N̲I̲Z̲A̲T̲I̲O̲N̲S̲
4.8.2 M̲e̲s̲s̲a̲g̲e̲ ̲S̲t̲o̲r̲a̲g̲e̲
Operational data will be stored in items. The life
cycle of an item is reflected in the way it is stored:
1) S̲h̲o̲r̲t̲ ̲T̲e̲r̲m̲ ̲S̲t̲o̲r̲a̲g̲e̲
This is the way items are stored while they are
still being processed. The short term storage
of items is optimized against efficient update
of individual fields and reading for transmission
and printout. Operational data are kept in short
term item storage until they have been completely
processed.
2) L̲o̲n̲g̲ ̲T̲e̲r̲m̲ ̲S̲t̲o̲r̲a̲g̲e̲
This is the way items are residing in offline historic
data base. They are dumped occasionally, say once
a day, to long term storage.
Items are not transferred directly from short term
to long term storage during dumps. Instead online
storage contains a spool file called I̲n̲t̲e̲r̲m̲e̲d̲i̲a̲t̲e̲ ̲S̲t̲o̲r̲a̲g̲e̲.
As soon as feasible after completion of processing,
items are transferred from short term to intermediate
storage. The dump procedure then empties part of intermediate
storage, transferring it to long term storage.
The relations between short term, intermediate and
long term storage are shown overleaf:
Figure 4.8.2-1…01…R̲E̲L̲A̲T̲I̲O̲N̲S̲ ̲B̲E̲T̲W̲E̲E̲N̲ ̲I̲T̲E̲M̲ ̲S̲T̲O̲R̲A̲G̲E̲ ̲T̲Y̲P̲E̲S̲
4.8.3 A̲c̲c̲o̲u̲n̲t̲a̲b̲i̲l̲i̲t̲y̲ ̲a̲n̲d̲ ̲A̲u̲d̲i̲t̲i̲n̲g̲ ̲D̲a̲t̲a̲
4.8.3.1 L̲o̲g̲ ̲F̲i̲l̲e̲s̲
4.8.3.1.1 G̲e̲n̲e̲r̲a̲l̲ ̲C̲o̲n̲c̲e̲p̲t̲
The system maintains a log record for all transactions
within the CAMPS system.
Both online and offline storage are supported by CAMPS
system.
4.8.3.1.2 L̲o̲g̲ ̲F̲i̲l̲e̲ ̲S̲t̲a̲g̲e̲s̲
Collection of system log records are supported by CAMPS
System Function Log Generator. The records are collected
in m̲a̲i̲n̲ ̲m̲e̲m̲o̲r̲y̲.
These lumps of at most 5 log records are transferred
to the log package, which collect them within a certain
time interval. The collected record from each time
interval forms a l̲o̲g̲ ̲i̲t̲e̲m̲.
The log items are handled to SAR who carry out the
o̲n̲l̲i̲n̲e̲ ̲s̲t̲o̲r̲a̲g̲e̲ just like other items.
Log items are subject for o̲f̲f̲-̲l̲i̲n̲e̲ ̲s̲t̲o̲r̲a̲g̲e̲ as other
items.
4.8.3.1.3 L̲o̲g̲ ̲F̲i̲l̲e̲ ̲A̲r̲e̲a̲s̲
The different areas, where the log records are stored
through the previous mentioned stages, are described
next.
4.8.3.1.3.1 M̲a̲i̲n̲ ̲M̲e̲m̲o̲r̲y̲
This area is administrated by CAMPS System Function
and will be described under the regime of Shared System
Data in section 4.5.
4.8.3.1.3.2 L̲o̲g̲ ̲I̲t̲e̲m̲ ̲A̲r̲e̲a̲
This area is controlled by the log package via SFM.
By creation of log item, an area is allocated. When
log item is completed, it is stored online and log
item area released. Log item area is short term storage
resident.
4.8.3.1.3.3 O̲n̲l̲i̲n̲e̲ ̲L̲o̲g̲ ̲I̲t̲e̲m̲ ̲A̲r̲e̲a̲
Before online storage of the log item, the superfluous
area not occupied by any log record is cut off. Details
about the log item area are described under item storage.
4.8.3.1.3.4 O̲f̲f̲l̲i̲n̲e̲ ̲L̲o̲g̲ ̲I̲t̲e̲m̲ ̲A̲r̲e̲a̲
As above the offline log items are treated as offline
messages and will be described under the historic data
chapter.
4.8.3.2 S̲t̲a̲t̲i̲s̲t̲i̲c̲s̲ ̲F̲i̲l̲e̲s̲
Contain collected statistical information.
4.8.3.3 T̲e̲s̲t̲-̲ ̲a̲n̲d̲ ̲T̲r̲a̲c̲e̲ ̲O̲u̲t̲p̲u̲t̲ ̲F̲i̲l̲e̲s̲
Files with test- and trace information for subsequent
analysis.
4.8.4 C̲a̲t̲a̲l̲o̲g̲u̲e̲s̲
4.8.4.1 M̲e̲s̲s̲a̲g̲e̲ ̲R̲e̲t̲r̲i̲e̲v̲a̲l̲ ̲C̲a̲t̲a̲l̲o̲g̲u̲e̲s̲
Contains the catalogues used during retrieval of messages
etc.
4.8.4.2 L̲o̲g̲ ̲R̲e̲t̲r̲i̲e̲v̲a̲l̲ ̲C̲a̲t̲a̲l̲o̲g̲u̲e̲s̲
4.8.4.2.1 G̲e̲n̲e̲r̲a̲l̲ ̲C̲o̲n̲c̲e̲p̲t̲
Log catalogues will be necessary for keeping track
of the log information. The catalogue will be updated
upon each storage of log item and consulted when a
retrieval process is invoked.
4.8.4.2.2 L̲o̲g̲ ̲C̲a̲t̲a̲l̲o̲g̲u̲e̲
As described in the log package, the log records are
collected to log items which are treated as ordinary
messages. Therefore, the log items are stored by SAR
which again keep track of the message retrieval catalogues
as described in section 4.8.4.1.
4.8.5 S̲y̲s̲t̲e̲m̲ ̲C̲o̲n̲t̲r̲o̲l̲ ̲D̲a̲t̲a̲
4.8.5.1 S̲y̲s̲t̲e̲m̲ ̲P̲a̲r̲a̲m̲e̲t̲e̲r̲s̲
These are the tables and simple parameters, the setting
of which control CAMPS execution.
4.8.5.1.1 C̲o̲n̲f̲i̲g̲u̲r̲a̲t̲i̲o̲n̲ ̲T̲a̲b̲l̲e̲s̲
These tables define the configuration of a CAMPS site
in terms of the following groups of data:
1) External channel definitions
2) Terminal configuration
3) Other peripheral equipment
4) Memory administration parameters
5) Disk storage administration parameters
These data are mainly used during initialization and
switch over.
4.8.5.1.2 S̲u̲p̲e̲r̲v̲i̲s̲o̲r̲ ̲C̲o̲n̲t̲r̲o̲l̲ ̲D̲a̲t̲a̲
Contains all tables and simple parameters available
to the supervisor for controlling CAMPS operation.
4.8.5.1.2.1 S̲u̲p̲e̲r̲v̲i̲s̲o̲r̲ ̲T̲a̲b̲l̲e̲s̲
Contains the following tables:
1) PLA table
2) AIG and AG tables
3) RI table
4) SIC table
5) SDL table
6) SCD table
7) Profiles, e.g., Terminal, Operator, and Channel
Profiles.
4.8.5.1.2.2 S̲u̲p̲e̲r̲v̲i̲s̲o̲r̲ ̲P̲a̲r̲a̲m̲e̲t̲e̲r̲s̲
Contains single parameters such as security control
parameters, number series etc.
4.8.5.2 S̲o̲f̲t̲w̲a̲r̲e̲ ̲L̲o̲a̲d̲ ̲M̲o̲d̲u̲l̲e̲s̲
Contains load modules for systems- and application
software subsystems and for LTU software. Mainly used
during system initialization.
4.8.5.3 V̲i̲r̲t̲u̲a̲l̲ ̲M̲e̲m̲o̲r̲y̲
Disk storage area used by the paging system for virtual
memory pages.
4.8.5.4 C̲h̲e̲c̲k̲p̲o̲i̲n̲t̲ ̲D̲a̲t̲a̲
A disk storage area used to store disk checkpoints
to be used for recovery.
4.8.6 O̲f̲f̲l̲i̲n̲e̲ ̲I̲n̲i̲t̲i̲a̲l̲i̲z̲a̲t̲i̲o̲n̲ ̲D̲a̲t̲a̲
This is a disk volume containing the data needed for
a full system initialization. It contains the following
groups of data:
1) Firmware and software load modules.
2) Initial system parameters.
3) System parameter back-up.
During a full initialization, the initialization data
are copied to the online storage before start-up.
System parameter back-up contains the version of the
system parameters which were on online disk at back-up
time.
4.8.7 A̲c̲c̲e̲s̲s̲ ̲M̲e̲c̲h̲a̲n̲i̲s̲m̲s̲ ̲a̲n̲d̲ ̲S̲u̲p̲p̲o̲r̲t̲ ̲F̲u̲n̲c̲t̲i̲o̲n̲s̲
The table overleaf shows the storage organizations
used for the various types of data.
Figure 4.8.7-1…01…D̲A̲T̲A̲ ̲T̲Y̲P̲E̲S̲ ̲A̲N̲D̲ ̲S̲T̲O̲R̲A̲G̲E̲ ̲O̲R̲G̲A̲N̲I̲Z̲A̲T̲I̲O̲N̲S̲
The control of the four storage organizations is carried
out by the following four modules in corporation:
1) File Management System
Storage and
2) Message Management System File Management
3) Message Monitor
4) Table Management
The relations between those modules and the application
requesting service are shown on the figure overleaf.
Figure 4.8.7-2…01…M̲O̲D̲U̲L̲E̲S̲ ̲C̲O̲N̲T̲R̲O̲L̲L̲I̲N̲G̲ ̲D̲A̲T̲A̲ ̲B̲A̲S̲E̲
4.8.7.1 A̲c̲c̲e̲s̲s̲ ̲M̲e̲t̲h̲o̲d̲s̲
The access paths from application modules shown on
figure 4.8.7-2 are implemented as a set of system functions
explained in more detail in the following packages:
1) DAMOS IO-system for direct file access
2) CSF for item access
3) TMP for table- and memory resident parameter access
The reason why data base access is distributed between
that many modules is, that some of the modules are
standard DAMOS modules while others are developed specifically
for CAMPS. This is explained more detailed in the
following list.
a) F̲i̲l̲e̲ ̲M̲a̲n̲a̲g̲e̲m̲e̲n̲t̲ ̲S̲y̲s̲t̲e̲m̲
This is a standard DAMOS module implementing the
most basic features of file- and volume handling.
The basic files are unstructured byte strings
with sequential and relative access methods.
b) M̲e̲s̲s̲a̲g̲e̲ ̲M̲a̲n̲a̲g̲e̲m̲e̲n̲t̲ ̲S̲y̲s̲t̲e̲m̲
A standard extension of file management system
to be used in message processing environments.
It implements a file type called items, which
are specifically suited for messages in transition.
c) T̲a̲b̲l̲e̲ ̲M̲a̲n̲a̲g̲e̲m̲e̲n̲t̲
This is a specific CAMPS package supplying the
index sequential and similar access methods needed
for table access.
d) M̲e̲s̲s̲a̲g̲e̲ ̲M̲o̲n̲i̲t̲o̲r̲
Supports Message Management System by implementing
the CAMPS specific aspects of message handling.
4.8.8 C̲A̲M̲P̲S̲ ̲I̲n̲t̲e̲r̲n̲a̲l̲ ̲M̲e̲s̲s̲a̲g̲e̲ ̲F̲o̲r̲m̲a̲t̲
4.8.8.1 G̲e̲n̲e̲r̲a̲l̲ ̲D̲e̲s̲c̲r̲i̲p̲t̲i̲o̲n̲
4.8.8.1.1 P̲u̲r̲p̲o̲s̲e̲
The purpose of this sub-section is to describe how
data inside a CAMPS can be collected reasonably in
order to produce a various number of message formats
in an efficient manner.
4.8.8.1.2 D̲e̲s̲i̲g̲n̲ ̲C̲o̲n̲s̲i̲d̲e̲r̲a̲t̲i̲o̲n̲s̲
It has been considered whether there should exist a
version of each given message format during its lifetime
in CAMPS.
- This solution would create a great amount of redundant
data and would simply be waste of disc space.
The opposite solution is to create all message formats
from one basic message file.
- This solution gives other problems as synchronization
of updates and a method to determine the status
of the message.
Compared with each other, the last described solution
seems most attractive and the following description
will concentrate on this.
4.8.8.1.3 M̲e̲s̲s̲a̲g̲e̲ ̲F̲o̲r̲m̲a̲t̲s̲ ̲F̲l̲o̲w̲
The chart of message formats flow Figure 4.8.8.1.3-1
shows how a message is circulating in the system.
The various format types do not express a separate
message type, but a format in which the message shall
be presented/manipulated. The storage section indicates
where data are appended to a message.
MESSAGE FORMATS FLOW
Figure 4.8.8.1.3-1
4.8.8.1.4 I̲n̲t̲e̲r̲n̲a̲l̲ ̲M̲e̲s̲s̲a̲g̲e̲ ̲M̲o̲d̲e̲l̲
A model that fulfils the requirement of "one basic
message file" is shown in figure 4.8.8.1.4-1 CAMPS
Internal Message Format.
- From this model, it should be possible to construct
all internal message formats except the temporary
protocol depending formats.
The model contains the following fields:
I = Information Field
H = Header Field
T = Text Field
A = Address Field
O = Operating Signals Field
N = Notification Field
R = Routing Field
D = Distribution Field
CAMPS INTERNAL MESSAGE FORMAT
Figure 4.8.8.1.4-1
4.8.8.2 D̲e̲t̲a̲i̲l̲e̲d̲ ̲D̲e̲s̲c̲r̲i̲p̲t̲i̲o̲n̲
4.8.8.2.1 F̲i̲e̲l̲d̲ ̲D̲e̲s̲c̲r̲i̲p̲t̲i̲o̲n̲
The number of suggested fields of CAMPS Internal Message
Format depends on:
- Message Route
- Message Type
- Message Status
Also it may depend on optional informations.
Refer to table of field parameters.
The upper part illustrates the conditions for the message,
(route, type, and status). The lower part illustrates
the present fields under that condition.
When following the steps in the states of the message,
it is possible to see, which fields a specific process
is appending to the message. (ex. the routing process
is appending a routing field to the message).
FIELD RELATIONSHIP
4.8.8.2.1.1 I̲n̲f̲o̲r̲m̲a̲t̲i̲o̲n̲ ̲F̲i̲e̲l̲d̲
The Information Field of the message is always present
in any message format. During the active part of the
message life, it is present in form of the MCB. All
updates are performed there.
When the life of the message is over (nobody is using
it), it is transferred into intermediate storage.
During that process, the information part of the MCB
is written down as the information field. It will
contain all unique data and data where a max. limit
is defined. It will also contain pointers to other
fields of variable length.
The pointers are here described as "number of lines"
in the specific field, but it can be anything else.
However, this method will satisfy calculations for
"paging" and also point out the presence of a field.
The idea behind the information field is to collect
all "key data" in a relative small area. The field
should be transferred with one disc access into an
application buffer and kept there until all operations
are finished.
The following groups of elements are thought to be
contained in a standard information field:
1) Message Information
2) Operation Information
3) Routing Information
4) Distribution Information
5) Address Information
6) Release Information
7) Other Information
8) Header Information
9) Text Information
When the word "standard" is used, it is to indicate
that some of the group elements may be redefined depending
on the message type or status. Example:
Errors related to an incoming message could be collected
in the groups of routing information, (or another convenient
group that is not in use at that stage) after generating
reports to supervisor and corrections by message service,
the group used can be cleared and set available for
its original purpose.
M̲e̲s̲s̲a̲g̲e̲ ̲I̲n̲f̲o̲r̲m̲a̲t̲i̲o̲n̲ ̲G̲r̲o̲u̲p̲
The elements of this group are the basic elements of
any message.
- Message Type
- Classification
- Special Handling (max. ?)
- Precedence Action
- Precedence Info.
- Message Status
This group of elements are thought of as the most significant
group, containing the basic information necessary to
build up a new MCB from scratch in case of retrieval,
rerun or redistribution.
O̲p̲e̲r̲a̲t̲i̲n̲g̲ ̲I̲n̲f̲o̲r̲m̲a̲t̲i̲o̲n̲ ̲G̲r̲o̲u̲p̲
The elements of this group are the secondary information
related to any message:
- Designator of originator
- Last used sequence number
- DTG
- Format type
- Operating Signals (pointer)
R̲o̲u̲t̲i̲n̲g̲ ̲I̲n̲f̲o̲r̲m̲a̲t̲i̲o̲n̲ ̲G̲r̲o̲u̲p̲
Used in connection with routing of a message.
- Number of RI's (pointer)
- Number of Routes
- Number of separate transmissions
D̲i̲s̲t̲r̲i̲b̲u̲t̲i̲o̲n̲ ̲I̲n̲f̲o̲r̲m̲a̲t̲i̲o̲n̲ ̲G̲r̲o̲u̲p̲
To be used in connection with distribution of a message.
The elements of this group could differ depending on
message/format type.
- Coordination (max. 20)
- Local Distribution (max. 10)
- SIC's (max. 3)
- ACT SIC's
- INFO SIC's
- Distribution list (pointer)
A̲d̲d̲r̲e̲s̲s̲ ̲I̲n̲f̲o̲r̲m̲a̲t̲i̲o̲n̲ ̲G̲r̲o̲u̲p̲
This group will contain or point to all address information:
- FM (pointer)
- TO (pointer)
- TO-AIG (max. 3)
- INFO (pointer)
- INFO-AIG (max. 3)
- XMT (pointer)
R̲e̲l̲e̲a̲s̲e̲ ̲I̲n̲f̲o̲r̲m̲a̲t̲i̲o̲n̲ ̲G̲r̲o̲u̲p̲
This information is related to release of a message;
- Release DTG
- Station Serial Number
- Notification (pointer)
- Release code
i.e. released
deferred
refused
O̲t̲h̲e̲r̲ ̲I̲n̲f̲o̲r̲m̲a̲t̲i̲o̲n̲ ̲G̲r̲o̲u̲p̲s̲
Information that cannot be grouped elsewhere:
- Group Count
- Message Service Count
- Byte Count
head + text?
- Line Count
- Transaction status
i.e. cancelled
suspended
preemptied etc.
H̲e̲a̲d̲e̲r̲ ̲I̲n̲f̲o̲r̲m̲a̲t̲i̲o̲n̲ ̲G̲r̲o̲u̲p̲
Contains pointers to format lines of an ACP127 formatted
message header. The need of this group is to fulfil
the requirements for distribution of an incoming message
in format E1, (FL5 to FL11).
- FL5 (pointer)
- etc.
T̲e̲x̲t̲ ̲I̲n̲f̲o̲r̲m̲a̲t̲i̲o̲n̲ ̲G̲r̲o̲u̲p̲
This field contains pointers to special lines of the
text/objects that are related to the text.
- Exercise (pointer)
- Internal Handling (pointer)
- Subject (pointer)
- Number of text lines
H̲e̲a̲d̲e̲r̲ ̲F̲i̲e̲l̲d̲
Contains the header of a message in ACP127-format.
The specific format lines are referenced by a pointer
from the header information group.
The relevance of this field can be discussed because
all elements can be reconstructed from other fields.
4.8.8.2.1.3 T̲e̲x̲t̲ ̲F̲i̲e̲l̲d̲
Together with the Header Field this field forms the
complete message in ACP127-format.
From the Text Information group are pointers to Exercise
Nickname (if any), Internal Handling Instructions (if
any) and the text itself. The pointers are thought
of as a count containing number of lines. This method
indicates the presence of a particular text part, that
might be of interest for Message Distribution (whether
they exist or not) and besides from this can be considered
as part of a variable text.
4.8.8.2.1.4 A̲d̲d̲r̲e̲s̲s̲ ̲F̲i̲e̲l̲d̲
Each record of this field will contain PLA-REF, RI,
and PLA.
There will be pointers to records from the Address
Information Group. The pointers are suggested to be,
- number of lines "FM"
- number of lines "TO"
- number of lines "INFO"
- number of lines "XMT"
This organization will satisfy a sequential read and
a following display of PLA's without any table involvement.
4.8.8.2.1.5 O̲p̲e̲r̲a̲t̲i̲n̲g̲ ̲S̲i̲g̲n̲a̲l̲s̲ ̲F̲i̲e̲l̲d̲
This field is optional and each record will contain
Ref. no., operating signal and some text related to
this operating signal.
There will be a pointer to this field from the Operating
Information Group telling the number of records/lines.
This organization will satisfy a sequential read and
a subsequent display of either operating signals or
the related texts.
If only the text has been entered, then the possibility
exists to assign the operating signal by Message Service
at any stage.
4.8.8.2.1.6 N̲o̲t̲i̲f̲i̲c̲a̲t̲i̲o̲n̲ ̲F̲i̲e̲l̲d̲
As a notification of release can be commented, this
field is intended to contain the comment and nothing
else. All other relevant data for an uncommented notification
of release is to be found in the Release Information
Group.
Pointer = number of lines in Notification Field.
4.8.8.2.1.7 R̲o̲u̲t̲i̲n̲g̲ ̲F̲i̲e̲l̲d̲
This field will contain records of ACP127-format line
2's.
The records will be pointed out from the Routing Information
Field.
The field is also described as the routing list.
4.8.8.2.1.8 D̲i̲s̲t̲r̲i̲b̲u̲t̲i̲o̲n̲ ̲F̲i̲e̲l̲d̲
The records of this field will be pointed out from
the Distribution Information Group.
The field is also described as the Distribution List.
4.8.8.2.2 R̲e̲c̲o̲r̲d̲ ̲D̲e̲s̲c̲r̲i̲p̲t̲i̲o̲n̲
TYPE SIZE IN
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲W̲O̲R̲D̲S̲ ̲ ̲ ̲
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
Information Field Fixed 100-128
Header Field Variable -
Text Field Variable -
Address Field Fixed ? 80 ?
Operating Signals Field Fixed ? 80 ?
Notification Field Variable -
Routing List
Distribution List
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
̲ ̲ ̲ ̲ ̲ ̲
