top - download
⟦fab6eb96e⟧ Wang Wps File
Length: 52188 (0xcbdc)
Types: Wang Wps File
Notes: Message Management
Names: »1092A «
Derivation
└─⟦b3a67856d⟧ Bits:30006040 8" Wang WCS floppy, CR 0065A
└─ ⟦this⟧ »1092A «
WangText
'…0c…' &…0b…&…01…%…08…%…0e…% $…08…$…0e…$ $…06…#…0a…#…0d…#…00…#…05…#…06…"…0d…" "…05…"…06……86…1
…02…
…02…
…02…
…02…CPS/SDS/003
…02…OKH/810801…02……02…
MESSAGE
MANAGEMENT
SYSTEM
…02……02…CAMPS
4.2.1.1.1.2 C̲I̲F̲ ̲S̲t̲o̲r̲a̲g̲e̲ ̲A̲l̲l̲o̲c̲a̲t̲i̲o̲n̲
This section describes management of the blocks which
are allocated to a CIF. The main issue is allocation
of sectors to fields within the CIF.
The blocks allocated to a CIF are described in the
C̲IF B̲LOCK L̲IST of the CIF Control Block. See 4.2.1.4.4
and 4.2.1.4.1. Each allocated block consists of a number
of sectors. A sector in an allocated block may at a
given time either be used or unused. A used sector
is allocated to one of the fields of the CIF. The CIF
Block List contains a Block Sector Map for each allocated
block. The map is a bit array of length NO OF SECTORS
IN BLOCK. The bit corresponding to a sector is set
to one if the sector is used.
A field consists of a number (possibly zero) of sectors.
New sectors may be added to the field, either at field
creation time or when the field must be extended. Sectors
to be allocated to a field are taken from the unused
sectors of blocks allocated to the CIF. If necessary,
the CIF is extended by allocation of one or more new
blocks.
When sectors are allocated to a field, they will be
selected in such a way thay they are physically as
close as possible to each other. A close allocation
can in particular be achieved, if space is "preallocated"
to the fields. This means that it is specified in one
of the commands CREATE CIF, CREATE NEW CIF VERSION,
CREATE VIEW, CREATE FIELDS, that initial space shall
be allocated at creation time. This preallocation does
not exclude possibility of subsequent extension, but
it increases the likelihood of a physically close allocation.
Extension of a field is done automatically as part
of the WRITE VIEW command.
Sectors and blocks are deallocated as part of the REMOVE
VIEW and SAVE commands. Deallocation of a sector will
change its state to unused. When all sectors within
a block have been deallocated, the block is deallocated
from the CIF.
The sectors allocated to a field are described in the
Field Sector Map of the field.
In order to enable read and write operations without
additional disk accesses, the block and sector addressing
information in CIF Block List and Field Sector Map
should be kept in memory. This will, however, not be
entirely possible because of limitations in available
memory and in memory addressing capability. Instead,
it will be possible for CIFs of a size smaller than
a system generation parameter to have all addressing
information in memory. For larger CIFs, the CIF Block
List and Field Sector Maps will be kept on disk. Thus
it will be possible to perform read and write accesses
to a large fraction of CIFs without additional disk
accesses.
4.2.1.1.1.3 D̲i̲s̲k̲ ̲B̲l̲o̲c̲k̲ ̲P̲u̲r̲g̲e̲
Disk blocks containing information of a security profile
higher than a "purge profile" specified at system generation
time shall be purged when deallocated. Purge of a disk
block consists of overwriting the block a specified
number of times with a random pattern.
The security profile of an allocated block is by definition
the profile of the CIF to which the block is allocated.
Non-recoverable CIFs are lost after a system start,
and so is information about security profile of blocks
belonging to those CIFs. For this reason all non-recovered
blocks will be purged after a system start.
Blocks which are subject to purge will be entered into
the Purge Block Map, PBM. When purge of a block has
been performed, the block will be transferred to Free
Block Map, FBM. After a system start and the associated
recovery phase, FBM will be empty while PBM will contain
all non-allocated blocks.
Deallocated sectors will not be purged separately,
as they still belong to the same CIF and may thus only
be reused for information of same security profile.
4.2.1.1.1.4 S̲t̲o̲r̲a̲g̲e̲ ̲A̲c̲c̲o̲u̲n̲t̲i̲n̲g̲ ̲a̲n̲d̲ ̲M̲o̲n̲i̲t̲o̲r̲i̲n̲g̲
Application processes can obtain the number of non-allocated
Short Term Storage blocks by the GET ACCOUNT INFORMATION
command (see section 4.1.6.2).
In addition a threshold warning mechanism is available.
CIF Handling Subpackages maintain three variable for
Short Term Storage threshold monitoring:
a) Warning Threshold
If the number of non-allocated blocks comes
below this limit, a threshold warning is returned.
b) Critical Threshold
If the number of non-allocated blocks comes
below this limit, a critical threshold warning
is returned.
c) Warning Enable Limit
If a threshold warning has been returned, subsequent
warnings will not be returned until the number
of non-allocated blocks has exceeded this limit.
The threshold values are set by the SET THRESHOLDS
command. The warnings are obtained by the GET THRESHOLD
WARNING command. The command will be kept by MMS until
a threshold value is reached, and then returned as
a reply.
The threshold commands are privileged functions.
If number of non-allocated blocks is zero, and a new
block is needed, this is a fatal error. An error report
will then be sent to the parent process of the SFM
process.
4.2.1.1.2 S̲e̲c̲u̲r̲i̲t̲y̲ ̲C̲o̲n̲t̲r̲o̲l̲
The general security functions of MMS are described
in sections 2.2.2.6 and 4.1.1. The present section
only describes those functions which are special for
CIF handling.
4.2.1.1.2.1 S̲e̲c̲u̲r̲i̲t̲y̲ ̲P̲r̲o̲f̲i̲l̲e̲s̲
The security profile in a CAMPS system contains three
compartments:
a) Security Classification, ranging from the value
0 for Unclassified to 4 for CTS.
b) Atomal Designator with values 0 for non-atomal
and 1 for atomal information.
c) Encrypted designator with values for 0 for
non-encrypted and 1 for encrypted information.
There are two purposes of the security profile:
d) To determine if deallocated memory buffers
and disk blocks shall be purged before reuse.
e) To check that the general DAMOS security rules
are followed. As the security and access control
requirements of CAMPS are implemented in CSF
and SSC packages, the DAMOS security rules
are implemented for compatibility reasons with
FMS.
Each CIF has an associated security profile. The profile
is specified in the CREATE CIF command and may be changed
by the CHANGE ATTRIBUTES command.
Each process has an associated security profile. This
profile is inserted by Message Monitor into the Command
Body Standard Part of each command to MMS.
Security profiles can be compared using the following
rule:
Profile (a) is lower than (lower than or equal
to) profile (b) if the value for each compartment
in profile (a) is lower than (lower than or equal
to) the corresponding value in profile (b).
4.2.1.1.2.2 P̲u̲r̲g̲e̲ ̲C̲o̲n̲t̲r̲o̲l̲
a) M̲e̲m̲o̲r̲y̲ ̲B̲u̲f̲f̲e̲r̲s̲
Memory buffers in the Disk Controller are allocated
for each read or write operation. The buffers are
used as a cache memory, so a buffer is normally
only deallocated if it is needed for another operation.
If a requested read operation involves data which
are already in a buffer, no disk read operation
will be needed.
The cache algorithm must, however, only be used
for CIFs with a security profile below a specified
level, so the following rule is used:
A Purge Profile is specified at system generation
time. Whenever an i/o operation is performed
on a CIF having a profile not lower than the
purge profile, all memory buffers used for
the operation shall be deallocated immediately
after termination of the operation and overwritten
with binary zeroes.
b) D̲i̲s̲k̲ ̲B̲l̲o̲c̲k̲s̲
When a disk block is deallocated from a CIF, the
CIF profile is compared with the purge profile.
If the CIF profile is not lower than the purge
profile, the block shall be purged immediately
after deallocation. Cf. section 4.2.1.1.1.3.
According to CAMPS requirements, the purge profile
will be:
- Security Classification = 4 (CTS)
- Atomal Compartment = 1 (Atomal)
- Encryption Compartment = 1 (Encrypted)
The above rules will then assure that purge will be
performed for information of security classification
CTS or special handling designator Atomal or category
Encrypted.
4.2.1.1.2.3 I̲/̲O̲ ̲S̲e̲c̲u̲r̲i̲t̲y̲ ̲C̲o̲n̲t̲r̲o̲l̲
On a Read View command the following check is performed:
The security profile of the requesting process
shall be higher than or equal to the security profile
of the CIF.
On a Write View command the following check is performed:
If the requesting process is untrusted, it shall
have a security profile lower than or equal to
the security profile of the CIF.
4.2.1.1.3 C̲I̲F̲ ̲H̲a̲n̲d̲l̲i̲n̲g̲ ̲C̲o̲m̲m̲a̲n̲d̲s̲
This section describes the execution of the CIF Handling
Commands which can be called by application processes.
4.2.1.1.3.1 C̲r̲e̲a̲t̲e̲ ̲C̲I̲F̲
Input: CIF Attributes.
Output: Completion Code
View Ref.
Completed View Attributes.
The specified CIF Attributes are checked. If OK, a
C̲I̲F̲ C̲ontrol B̲lock is allocated and initialized according
to specified attributes. If at least one field group
is declared permanent, the next CIF ID is obtained
from the CIF Storage and Retrieval Subpackage and assigned
to the CIF. If the CIF is specified as recoverable,
the CIF Checkpoint and Recovery Subpackage is notified.
A Field Group Descriptor and a F̲ield D̲escriptor are
allocated for each field group specified. If any of
the specified allocated lengths are non-zero, the necessary
disk blocks are allocated to the CIF and sectors allocated
to the fields.
A V̲iew C̲ontrol B̲lock is allocated and initialized pointing
to the FDs and CIFCB with read and write access right.
The attributes delivered as command parameters are
updated, and the index of VCB is returned as the View
Ref. output parameter.
4.2.1.1.3.2 C̲r̲e̲a̲t̲e̲ ̲N̲e̲w̲ ̲C̲I̲F̲ ̲V̲e̲r̲s̲i̲o̲n̲
Input: View Ref., previous version
CIF Attributes, new version.
Output: Completion Code
View Ref., new version
View Attributes, new version.
It is checked if referenced CIF is latest version and
if specified attributes (only field information) are
legal. If OK, attributes are transferred from referenced
CIFCB. A new CIFCB is allocated. The CIF ID is set
to same value as in previous version, but version indicator
is increased by one. The Latest Version Indicator is
set in the new CIFCB and reset in the previous one.
Processing is then continued as in Create CIF.
4.2.1.1.3.3 C̲r̲e̲a̲t̲e̲ ̲V̲i̲e̲w̲
Input: View Ref., predecessor view
View Attributes.
Output: Completion Code
View Ref., new view
View Attributes, new view.
The specified View Attributes are checked. A new VCB
is allocated, and initialized according to Field Information
in View Attributes. For each new field which shall
be created, an FD is allocated and initialized. If
any allocated length is non-zero, the necessary sectors
are allocated.
View attributes for the new view are returned, together
with VCB index for the new VCB.
4.2.1.1.3.4 C̲r̲e̲a̲t̲e̲ ̲F̲i̲e̲l̲d̲s̲
Input: View Ref.
Field Information.
Output: Completion Code
Updated Field Information.
The specified Field Information is checked. Inclusion
of fields requires that predecessor view still exists.
If OK, the necessary number of FDs is allocated. If
any allocated length in a created field is non-zero,
the necessary sectors are allocated.
The updated field information is returned.
4.2.1.1.3.5 G̲e̲t̲ ̲V̲i̲e̲w̲ ̲A̲t̲t̲r̲i̲b̲u̲t̲e̲s̲
Input: View Ref.
Output: Completion Code
View Attributes.
Delivers view attributes for referenced View.
4.2.1.1.3.6 C̲h̲a̲n̲g̲e̲ ̲A̲t̲t̲r̲i̲b̲u̲t̲e̲s̲
Input: View Ref.
Security Profile
Application Control Information
Change Mask.
Output: Completion Code.
Changes the CIF attributes specified in Change Mask.
If security profile is changed to a lower value (in
any compartment) it is checked that the requesting
process is trusted.
4.2.1.1.3.7 R̲e̲m̲o̲v̲e̲ ̲V̲i̲e̲w̲
Input: View Ref.
Output: Completion Code.
If the view references a recoverable CIF and has been
checkpointed, the command is rejected. If the view
is subject to storage, it is not removed, but status
is changed to removed. Otherwise the following is done:
a) For each field referenced by the view, the reference
count is decreased by one. If it thereby becomes
zero, the sectors occupied by the field and the
FD are deallocated. If thereby all sectors of a
disk block become deallocated, the block is deallocated
from the CIF, possibly with purge.
b) The VCB is removed from the CIF and deallocated.
If it is the last referencing view, the CIF is
itself removed, by deallocating CIFCB and FGDs.
c) All successor views of this view shall have their
predecessor view pointer set to NIL. Then it is
not possible to include fields from predecessor
view, cf 4.2.1.1.3.4.
4.2.1.1.4 C̲I̲F̲ ̲I̲/̲O̲ ̲c̲o̲m̲m̲a̲n̲d̲s̲
4.2.1.1.4.1 R̲e̲a̲d̲ ̲V̲i̲e̲w̲
Input: View Ref.
Application Data Buffer Size
Field List
Output: Completion code
Updated Field List
Data read from View.
Checks that field list is in accordance with the referenced
view, and that process security profile is higher than
or equal to CIF security profile.
The fields in field list are then associated with sectors,
using the FDs of referenced view. The sectors are then
requested from the SFM subpackage Disk Cache Manager.
See figure 4.1.3-1.
When the sectors have been read, data are moved to
application data buffer as specified in field list.
Finally, field list is updated and response returned.
4.2.1.1.4.2 W̲r̲i̲t̲e̲ ̲V̲i̲e̲w̲
Input: View Ref.
Application Data Buffer Size
Field List.
Output: Completion Code
Updated Field List.
Checks that field list is in accordance with the referenced
view, and that calling process is either trusted or
has a security profile lower than or equal to the CIF
security profile.
The fields in the field list are then associated with
sectors. This may involve extension of some fields.
Then it is determined whether any of the sectors shall
be read before write because the write operation does
not conform with sector boundaries.
The necessary sectors are read in and the remaining
sectors are reserved for write by a request to Disk
Cache Manager. When the response has been returned
from DCM, data are moved from application data buffer
to sector buffers.
Finally, DCM is requested to write the sectors to disk
and when this has been done, field list is updated
and response returned.
4.2.1.2 S̲o̲f̲t̲w̲a̲r̲e̲ ̲S̲t̲r̲u̲c̲t̲u̲r̲e̲
The software structure of CIF Handling Subpackage is
described in section 4.1.2.
4.2.1.3 D̲a̲t̲a̲ ̲F̲l̲o̲w̲ ̲a̲n̲d̲ ̲C̲o̲n̲t̲r̲o̲l̲ ̲L̲o̲g̲i̲c̲
The Data Flow and control Logic of CIF Handling Subpackage
is described in section 4.1.3.
4.2.1.4 S̲u̲b̲p̲a̲c̲k̲a̲g̲e̲ ̲D̲a̲t̲a̲
The CIF Control Blocks and View Control Blocks described
in this section are actually common for the MMS package
as explained in section 4.1.4.
4.2.1.4.1 C̲I̲F̲ ̲C̲o̲n̲t̲r̲o̲l̲ ̲B̲l̲o̲c̲k̲
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
APPLICATION
CONTROL
INFORMATION
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
SECURITY PROFILE
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
VERSION L VIEW REF
INDICATOR V COUNT
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
RECOVERY SAR
INFORMATION INFORMATION
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
STORE TIME
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
CIF BLOCK LIST
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
FIELD GROUP TYPES
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
FIELD GROUP LIST
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
VIEW LIST
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
FIELD GROUP TYPES: One bit per field group:
0 Temporary
1 Permanent
LV: Latest Version Indicator
4.2.1.4.2 F̲i̲e̲l̲d̲ ̲D̲e̲s̲c̲r̲i̲p̲t̲o̲r̲
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
NEXT FIELD
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
FIELD ID S REFERENCE
COUNT
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
FIELD LENGTH
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
ALLOCATED
SECTORS
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
FIELD SECTOR MAP
ELEMENTS (1 or 2)
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
S: STORAGE STATUS
4.2.1.4.3 F̲i̲e̲l̲d̲ ̲G̲r̲o̲u̲p̲ ̲D̲e̲s̲c̲r̲i̲p̲t̲o̲r̲
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
NEXT FIELD GROUP
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
FIELD DESCRIPTOR LIST
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
4.2.1.4.4 C̲I̲F̲ ̲B̲l̲o̲c̲k̲ ̲L̲i̲s̲t̲ ̲E̲l̲e̲m̲e̲n̲t̲
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
BLOCK NUMBER FIRST BLOCK
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
BLOCK NUMBER SECOND BLOCK
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
BLOCK SECTOR MAP BLOCK SECTOR MAP
FIRST BLOCK SECOND BLOCK
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
4.2.1.4.5 F̲i̲e̲l̲d̲ ̲S̲e̲c̲t̲o̲r̲ ̲M̲a̲p̲ ̲E̲l̲e̲m̲e̲n̲t̲
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
BLOCK NUMBER
SECTOR BIT MAP
WITHIN CIF
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
4.2.1.4.6 V̲i̲e̲w̲ ̲C̲o̲n̲t̲r̲o̲l̲ ̲B̲l̲o̲c̲k̲
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
NEXT VIEW
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
VIEW ID
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
FG 1 FG 2
RS FIELD ID RS FIELD ID
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
FG 3
RS FIELD ID RS
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
FG 16
RS FIELD NO
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
CIFCB POINTER
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
PREDECESSOR VIEW POINTER
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
RS: Reference Status 0 Not referenced
1 Included with read access
2 Included with write access
3 Created by this view
FIELD ID = zero means that creation status is not
determined
View Control Block is referenced indirectly by View
Reference used in commands to MMS.
Fig. 4.2.1.4.7 Control Block Relations
4.2.2 C̲I̲F̲ ̲S̲t̲o̲r̲a̲g̲e̲ ̲a̲n̲d̲ ̲R̲e̲t̲r̲i̲e̲v̲a̲l̲ ̲S̲u̲b̲p̲a̲c̲k̲a̲g̲e̲
4.2.2.1 F̲u̲n̲c̲t̲i̲o̲n̲a̲l̲ ̲S̲p̲e̲c̲i̲f̲i̲c̲a̲t̲i̲o̲n̲
The subpackage manages I̲ntermediate S̲torage and L̲ong
T̲erm S̲torage and transfers between the three storage
types. Cf. figure. 2.2.1.1.-2
The functional break down of the subpackage is shown
on figure 4.2.2.1-1.
G̲e̲n̲e̲r̲a̲l̲ ̲D̲e̲s̲c̲r̲i̲p̲t̲i̲o̲n̲
To store a CIF means to retain it in the system in
a way that allows subsequent retrieval. CIFs which
can be subject to storage are those having at least
one permanent field. However, not all those CIFs will
be stored. Only those for which an application process
issues a STORE command will be stored. All other CIFs
will just be deleted from Short Term Storage when they
are no longer in use.
Stored CIFs are identified by a CIF ID consisting of
a 32 bit CIF REFERENCE NUMBER and an 8 bits VERSION
INDICATOR. The CIF ID is allocated when the CIF is
created, cf. section 4.2.1.1. The CIF REF NUMBER is
increased by one each time a new permanent CIF is created.
Different versions of the same CIF carry same reference
number but different version indicators.
For each CIF, a sequence of STORE commands may be issued
by applications. When the first STORE command is issued
for a CIF, its CIF ID is entered into the O̲nline CIF
D̲irectory. The STORE commands for a CIF may be widely
dispersed in time. The Store Time for a CIF is the
latest time at which a STORE command has been issued.
It is represented by the 32 most significant bits of
the KERNEL Real Time Clock. The store Time is used
to determine when a CIF shall be removed from Intermediate
Storage.
The MMS Storage and Retrieval functions assume that
STORE commands are issued in a̲l̲m̲o̲s̲t̲ the same sequence
as that in which the CIFs were created. This assumption
is not a requirement, but large deviations will decrease
the efficiency of the algorithms for directory handling.
The sequence of events for a permanent CIF is as follows,
cf. figure 4.2.2.1-3.
1) The CIF is created in STS by CREATE CIF or
CREATE NEW CIF VERSION command. A CIF ID is
generated.
2) During processing of the CIF, one or more STORE
commands may be issued. At the first one, a
directory entry is created.
The CIF can be retrieved by a RETRIEVE command
from the time the first STORE command has been
issued.
3) CIF Handling Subpackage determines when the
CIF is no longer referenced. At that time,
the CIF shall be u̲n̲l̲o̲a̲d̲e̲d̲ to IS. This shall
be done before generation of the checkpoint
specifying that the CIF is deleted from STS.
4) The CIF is Dumped to Long Term Storage when
it is referenced in a DUMP command. If the
processing of the CIF takes unusually long
time, for instance because of several edit
cycles, step 4 may actually take place before
step 3. In that case, the CIF is dumped directly
from STS as shown on figure 4.2.2.1-2.
In any case, step 3 will always be performed,
and step 4 may possibly be repeated a number
of times.
5) After step 3, the CIF may be removed from IS
by a CLEAR command. This will take place when
the time parameter in CLEAR is greater than
the Store Time of the CIF.
Fig. 4.2.2.1-1 Storage and Retrieval Functions
Fig. 4.2.2.1-1 (contd.) Storage and Retrieval Functions
Fig. 4.2.2.1-1 (contd.) Storage and Retrieval Functions
Fig. 4.2.2.1-1 (contd.) Storage and Retrieval Functions
Fig. 4.2.2.1-2 Transfers between Storage Types
Fig. 4.2.2.1-3 Event Sequence for a CIF
4.2.2.1.1 S̲t̲o̲r̲a̲g̲e̲ ̲M̲a̲n̲a̲g̲e̲m̲e̲n̲t̲
4.2.2.1.1.1 P̲a̲c̲k̲e̲d̲ ̲C̲I̲F̲ ̲R̲e̲p̲r̲e̲s̲e̲n̲t̲a̲t̲i̲o̲n̲
A CIF in IS or LTS is packed into a format taking up
as little space as possible. The packed CIF contains
the data fields together with copies of the control
blocks containing attribute and structure information
for the CIF.
The packed format is shown in figure 4.2.2.1.1-1, and
the parts are explained in the following:
a) Length.
The length in bytes of the packed CIF.
b) CIF Control Block.
A copy of the CIFCB.
The VIEW LIST has been replaced by a pointer
to start of View Control Blocks.
c) Field Descriptors.
An array containing a copy of all Field Descriptors
for the CIF. The FIELD SECTOR MAP has been
replaced by a pointer to the field.
The NEXT FIELD has been replaced by the Field
Group Id. The field descriptors are placed
in sequence of increasing field group id and
increasing field id within same field group.
Only those descriptors referenced by View Control
Blocks are included.
d) View Control Blocks.
An array containing copies of the view control
blocks for the CIF. Only those views for which
at least one STORE command have been issued
are included.
e) Fields.
The fields of the CIF, stored in same sequence
as the field descriptors.
A packed CIF will always start on a sector
boundary.
4.2.2.1.1.2 I̲n̲t̲e̲r̲m̲e̲d̲i̲a̲t̲e̲ ̲S̲t̲o̲r̲a̲g̲e̲ ̲O̲r̲g̲a̲n̲i̲z̲a̲t̲i̲o̲n̲
Intermediate Storage is a contiguous disk area used
as a cyclical buffer for unloaded CIFs, see figure
4.2.2.1.1-2.
Whena CIF is unloaded, it is converted to packed format
and stored in IS from Unload Pointer and onwards, and
Unload Pointer is then moved correspondingly. It will
thus come closer to Clear Pointer.
After a dump of CIFs to Long Term Storage, a CLEAR
command may be issued. It will normally cause a number
of CIFs to be removed from IS, and will probably but
not necessarily cause the Clear Pointer to move upwards
thus freeing storage space in IS. However, it can also
happen that only CIFs between Clear Pointer and Unload
Pointer will be cleared. Consequently holes can exist
in the area between the two pointers, and free space
can then be obtained by reorganizing the storage area.
Reorganization consist of moving CIFs upwards, thus
filling up holes and consequently compressing IS.
The reorganization is controlled by a number of variables:
a) The amount of free storage area in IS.
b) The amount of free storage which can be gained
by a reorganization.
c) The current load on online disk.
In addition, the storage management will keep track
of the "density" of CIFs in various sections of IS.
This information is used to determine the part of IS
which can be reorganized with reasonable benefit.
The storage management will automatically initiate
reorganizations based upon the mentioned control variables.
4.2.2.1.1.3 L̲o̲n̲g̲ ̲T̲e̲r̲m̲ ̲S̲t̲o̲r̲a̲g̲e̲ ̲O̲r̲g̲a̲n̲i̲z̲a̲t̲i̲o̲n̲
Long Term Storage is organized by a 3 level storage
hierarchy:
a) LTS consists of a number of removable disk
volumes.
b) Each volume consists of one or more d̲u̲m̲p̲ ̲f̲i̲l̲e̲s̲.
c) Each dump file consists of a number of d̲u̲m̲p̲
̲s̲e̲g̲m̲e̲n̲t̲s̲.
The concepts are explained below.
By a Dump is meant the process of moving a specified
set of CIFs from Online Storage to Long Term Storage.
The result of a dump is a Dump Segment. It consists
of a CIF storage area containing the dumped CIFs in
packed format, and a CIF directory with an entry for
each dumped CIF. See figure 4.2.2.1.1.3-1. The CIF
directory contains the Date and Time of the dump.
A Dump File is a contiguous file containing sequence
of Dump Segments. A Dump Segment is identified by Dump
Segment Id, which is its sequence number within the
Dump File. A Dump File starts with a Dump File Header
containing the number of Dump Segments and the location
of each segment. See figure 4.2.2.1.1.3-2.
When a Dump File is created, it is initialized to be
empty. Each dump to the file will automatically add
a new Dump Segment. A Dump Segment is created by the
following sequence of commands from an application
process:
1) I̲n̲i̲t̲ ̲D̲u̲m̲p̲
Prepares a new Dump segment and returns its
Id. Reserves the Dump File, thus preventing
concurrent dumps to the file.
2) D̲u̲m̲p̲ ̲C̲I̲F̲ ̲S̲e̲q̲u̲e̲n̲c̲e̲
Specifies a list of CIF IDs for CIFs to be
dumped to the segments. The CIFs are moved
to the CIF Storage Area of the segment while
the corresponding directory entries are temporarily
stored in an area at the top of the Dump File.
See figure 4.2.2.1.1.3-3.
3) T̲e̲r̲m̲i̲n̲a̲t̲e̲ ̲D̲u̲m̲p̲
Closes the Dump Segment. The CIF directory
entries are sorted and moved to the Dump Segment.
Then the Dump File header is updated to reflect
the existence of the new segment. It is not
until this time that the new segment can be
recovered after a system failure.
Fig. 4.2.2.1.1-1 Packed CIF Format
Fig. 4.2.2.1.1-2 Intermediate Storage organisation
Fig. 4.2.2.1.1.3-1 Dump Segment
Fig. 4.2.2.1.1.3-2 Dump File
Fig. 4.2.2.1.1.3-3 Dump Segment Creation
4.2.2.1.1.4 P̲a̲c̲k̲ ̲C̲I̲F̲
The function works on a CIF currently stored in Short
Term Storage. The CIF is converted to packed format
and stored at a specified location in IS or a dump
segment of LTS. Refer figure 4.2.2.1.1-1. The function
will determine the part of the CIF which is currently
subject to storage, cf section 4.2.2.1.1.1 c) and d).
4.2.2.1.1.5 U̲n̲p̲a̲c̲k̲ ̲C̲I̲F̲
The function converts a CIF from packed format and
stores it in an STS in the standard format. Only the
part of the CIF referenced by a specified view is unpacked.
The resulting CIF has the same attributes as the stored
one, except:
a) All fields are temporary.
b) The view references all fields with read and
write access.
4.2.2.1.1.6 R̲e̲m̲o̲v̲e̲ ̲C̲I̲F̲
Removes a CIF from Intermediate Storage. Removal is
done by marking the used area as unused. If the CIF
is pointed at by Clear Pointer, this is updated. Otherwise
the IS control variables mentioned in section 4.2.2.1.1.2
are updated.
4.2.2.1.1.7 R̲e̲o̲r̲g̲a̲n̲i̲z̲a̲t̲i̲o̲n̲
Reorganizes IS by moving the stored CIFs upwards, thus
filling up the holes.
Calls the Update Entry function of Directory Management
in order to update CIF References to moved CIFs.
Reorganization shall be done in such a way that it
can be interrupted by a system failure at any time
and subsequently be resumed without losing data.
4.2.2.1.1.8 I̲n̲i̲t̲i̲a̲l̲i̲z̲a̲t̲i̲o̲n̲ ̲a̲n̲d̲ ̲R̲e̲c̲o̲v̲e̲r̲y̲
a) I̲n̲i̲t̲a̲l̲i̲z̲a̲t̲i̲o̲n̲ ̲o̲f̲ ̲I̲n̲t̲e̲r̲m̲e̲d̲i̲a̲t̲e̲ ̲S̲t̲o̲r̲a̲g̲e̲
Upon a dead start the disk area used for IS shall
be allocated based on system generation parameters.
Upon a dead or cold start IS is initialized to
be empty.
Upon a warm start the IS control variables shall
be restored by scanning the Online CIF Directory.
If a reorganization was in progress at the time
of close down or system failure, it shall be resumed.
If a Clear Command was in progress, the OCD block
which was under update shall be checked, to see
whether a CIF has been removed from IS without
removing the corresponding OCD entry. Refer section
4.2.2.1.2.
b) I̲n̲i̲t̲i̲a̲l̲i̲z̲a̲t̲i̲o̲n̲ ̲o̲f̲ ̲L̲o̲n̲g̲ ̲T̲e̲r̲m̲ ̲S̲t̲o̲r̲a̲g̲e̲
Consists of the following functions:
1) N̲a̲m̲e̲ ̲v̲o̲l̲u̲m̲e̲
Initializes an empty volume. This is done by
a command to FMS.
4.2.2.1.2 D̲i̲r̲e̲c̲t̲o̲r̲y̲ ̲M̲a̲n̲a̲g̲e̲m̲e̲n̲t̲
A CIF Directory is a table of references to retrievable
CIFs, organized directly or sequentially with CIF REFERENCE
NUMBER as key.
There are two kinds of CIF Directories:
a) O̲nline C̲IF D̲irectory.
Contains references to all retrievable CIFs
in STS and IS. All CIFs in IS are referenced
via this directory.
b) L̲ong Term Storage C̲IF D̲irectory.
Each dump segment contains an LCD referencing
the CIFs in the segment. Cf figure 4.2.2.1.1.3-1.
4.2.2.1.2.1 O̲n̲l̲i̲n̲e̲ ̲C̲I̲F̲ ̲D̲i̲r̲e̲c̲t̲o̲r̲y̲
The entry format is shown on figure 4.2.2.1.2.1-1.
OCD is a contiguous area on online disk. It is organized
directly according to CIF REFERENCE NUMBER. The index
of an entry is calculated as:
CIF REFERENCE NUMBER modulo NUMBER OF ENTRIES times
F
where F is the average number of CIF versions per reference
number. This is a system generation parameter which
in CAMPS will have a value between 1 and 1.5 reflecting
the fact that outgoing messages are stored in two versions
while all other items are stored in one version only.
When allocating an entry, the first free one after
calculated index is used. If no free entry can be found
within a specified index range, the directory will
be reorganized.
An entry in OCD is allocated when the first STORE command
is issued for a CIF. The CIF REFERENCE points to CIFCB,
and STORAGE STATUS is set to STS. If the CIFCB has
a "recovered mark" it shall be checked that there is
not already an entry in OCD, before allocation of a
new entry.
The OCD entry is updated when the CIF is unloaded to
IS. It is not until now that the STORE TIME has any
significance for a CLEAR command.
When a CLEAR command is issued, the complete OCD is
scanned, and entries with STORE TIME smaller than the
CLEAR TIME are deleted by setting ENTRY STATUS to free.
The area in IS occupied by the CIF is freed too.
An OCD entry can be updated when IS is reorganized,
cf section 4.2.2.1.1.7. The update consists of changing
the CIF REFERENCE.
Figure 4.2.2.1.2.1-1 Online CIF Directory Entry
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
CIF REFERENCE
NUMBER
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
VERSION ID S E
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
CIF REFERENCE
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
STORE TIME
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
E Entry Status
0: Free Entry
1: Used Entry
S Storage Status
0: CIF residing in STS
1: CIF residing in IS
CIF REFERENCE
CIFCB reference or IS Storage Address depending
upon storage status.
STORE TIME
Time for last STORE command. Only relevant
for CIFs residing in IS.
4.2.2.1.2.2 L̲o̲n̲g̲ ̲T̲e̲r̲m̲ ̲S̲t̲o̲r̲a̲g̲e̲ ̲C̲I̲F̲ ̲D̲i̲r̲e̲c̲t̲o̲r̲i̲e̲s̲
Each dump segment contains its own LCD which is completely
self-contained. The entry format is shown in figure
4.2.2.1.2.2-1.
The LCD is index sequentially organized with CIF ID
as key, as shown on figure 4.2.2.1.2.2-2.
Creation of the LCD is shown on figure 4.2.2.1.1.3-3.
During the dump process directory entries for the dumped
CIFs are taken from OCD and collected in an area at
the top of the dump file. During dump termination,
the entries are sorted, an index table is built up,
and the resulting directory is appended to the dump
segment.
After termination of a dump, the corresponding LCD
can never be changed.
Fig. 4.2.2.1.2.2-2 Long Term Storage Directory Organization
4.2.2.1.2.3 C̲r̲e̲a̲t̲e̲ ̲E̲n̲t̲r̲y̲
Creates a new entry in OCD for a specified CIF. The
entry is allocated as close as possible after the entry
calculated by means of CIF REFERENCE NUMBER. A system
generation paramenter specifies the acceptable distance.
The entry is initialized to reference the CIFCB.
4.2.2.1.2.4 S̲e̲a̲r̲c̲h̲ ̲E̲n̲t̲r̲y̲
Searches an entry in specified directory. The search
key is CIF ID.
4.2.2.1.2.5 U̲p̲d̲a̲t̲e̲ ̲E̲n̲t̲r̲y̲
Updates a specified entry in OCD. The complete contents
are changed.
4.2.2.1.2.6 R̲e̲o̲r̲g̲a̲n̲i̲z̲e̲ ̲D̲i̲r̲e̲c̲t̲o̲r̲y̲
OCD is reorganized by removing all entries with CIF
REF NUMBER smaller than a specified one to an overflow
area.
4.2.2.1.2.7 I̲n̲i̲t̲i̲a̲l̲i̲z̲e̲ ̲O̲C̲D̲
Upon a dead or cold start OCD shall be cleared.
Upon a warm start, the following shall be done:
a) If an OCD reorganization was in progress, it
shall be resumed.
b) If a CLEAR was in progress, the current OCD
block shall be terminated.
4.2.2.1.3 C̲o̲m̲m̲a̲n̲d̲ ̲E̲x̲e̲c̲u̲t̲i̲o̲n̲
Except for the UNLOAD CIF command, the commands described
in this section are all issued by application processes
via CSF package.
The UNLOAD CIF command is called from CIF Handling
Subpackage when a CIF is removed from STS.
4.2.2.1.3.1 S̲t̲o̲r̲e̲
Input: View Ref.
Output: CIF ID
View Id
Completion Code.
The referenced VCB is updated by setting the STORE
REQUEST status. This will cause the view to be included
into subsequent unloads and dumps of the CIF.
The referenced CIFCB is updated by setting STORE REQUEST
status and STORE TIME.
If the STORE REQUEST status was not set before, this
was the first STORE command for the CIF. Thus an OCD
entry will be allocated by create entry function. If
creation was not possible, the directory is reorganized.
A STORE request is only accepted if the CIF security
profile is lower than or equal to the Store Profile,
cf section 2.2.2.6.3.
The STORE request will not be recoverable until the
next checkpoint has been generated for the CIF.
4.2.2.1.3.2 R̲e̲t̲r̲i̲e̲v̲e̲
Input: Type
Dump File Ref
Dump Segment Id
CIF ID
View Id.
Output: View Ref
View Attributes
Completion Code.
Requests retrieval of a CIF specified by CIF ID. Only
part of the CIF is made available namely the fields
referenced by the view identified by View Id. CIF ID
and View Id must have been delivered as output parameters
from a previous STORE command.
The Type parameter specifies whether online or offline
retrieval is requested. In the latter case, Dump File
and Dump Segment shall be specified. Dump File Ref
is the one returned by the I/O system in a LOOKUP command
for the dump file.
The CIF ID is searched in the appropriate CIF Directory.
Then the CIF is brought into STS either by the function
Unpack CIF or by a copying from the version in STS.
4.2.2.1.3.3 D̲u̲m̲p̲
The steps in a dump are described in section 4.2.2.1.1.3.
a) I̲n̲i̲t̲ ̲D̲u̲m̲p̲
Input: Dump File Ref
Output: Completion Code
Prepares the referenced dump file for a dump. The file
must have been looked up by a command to FMS.
b) D̲u̲m̲p̲ ̲C̲I̲F̲ ̲S̲e̲q̲u̲e̲n̲c̲e̲
Input: Dump File ref.
CIF ID List
Output: Completion Code.
The referenced CIFs must have been subject to one or
more STORE commands. The views for which store commands
have been issued will be dumped.
For each CIF ID in the list the following is done:
1) The OCD entry is located by Search Entry and
moved to the dump file.
2) The CIF is packed and stored in dump file by
the Pack CIF function, or it is copied from
IS.
c) T̲e̲r̲m̲i̲n̲a̲t̲e̲ ̲D̲u̲m̲p̲
Input: Dump File Ref.
Output: Completion Code.
Sorts the directory entries at top of dump file. Then
creates an index table and moves the directory to end
of the dump segment.
Finally, the dump file header is updated.
4.2.2.1.3.4 C̲l̲e̲a̲r̲
Input: Clear Time
Output: Completion Code.
The complete OCD directory is scanned. For each entry
having STORAGE STATUS equal to "residing in IS" and
STORE TIME smaller than CLEAR TIME, the entry and the
corresponding CIF shall be removed.
The OCD is read block by block. For each block, the
entries are checked one by one, and the entry is removed
from the block if conditions are fulfilled. Then the
corresponding CIF is removed by calling the Remove
CIF function.
When all entries in a block have been checked, the
block is written back to OCD unless it was not updated
at all.
4.2.2.1.3.5 I̲n̲i̲t̲i̲a̲l̲i̲z̲e̲ ̲S̲A̲R̲ ̲F̲u̲n̲t̲i̲o̲n̲s̲
Input: Startup Type.
Output: Completion Code.
Initializes IS and OCD by calling the appropriate functions.
If an unload has been in progress, it shall be cancelled.
4.2.2.1.3.6 U̲n̲l̲o̲a̲d̲ ̲C̲I̲F̲
Searches the OCD entry. Then saves recovery information
necessary to cancel the unload after a possible system
failure. This information is returned to CIF Handling
Subpackage which shall then delete it when operation
has been finished.
Packs the CIF into IS and updates IS control variables.
A possible threshold condition is signalled back to
CIF Handling Subpackage.
Updates OCD entry.
4.2.2.1.4 S̲t̲o̲r̲a̲g̲e̲ ̲A̲c̲c̲o̲u̲n̲t̲i̲n̲g̲ ̲a̲n̲d̲ ̲M̲o̲n̲i̲t̲o̲r̲i̲n̲g̲
4.2.2.1.4.1 T̲h̲r̲e̲s̲h̲o̲l̲d̲ ̲C̲o̲m̲m̲a̲n̲d̲s̲
Defines threshold values for IS and requests threshold
warnings to be returned.
a) S̲e̲t̲ ̲T̲h̲r̲e̲s̲h̲o̲l̲d̲ ̲V̲a̲l̲u̲e̲s̲
Input: IS Threshold Values.
Output: Completion Code.
Sets the values of: Critical Threshold
Warning Threshold
Enable Warning Threshold
for Intermediate Storage.
b) G̲e̲t̲ ̲W̲a̲r̲n̲i̲n̲g̲
Output: Warning Type.
Requests a response to be returned when a threshold
is exceeded.
Warning type: IS Critical Threshold
IS Warning Threshold
4.2.2.1.4.2 A̲c̲c̲o̲u̲n̲t̲i̲n̲g̲ ̲C̲o̲m̲m̲a̲n̲d̲s̲
G̲e̲t̲ ̲S̲t̲o̲r̲a̲g̲e̲ ̲O̲c̲c̲u̲p̲a̲n̲c̲y̲
Output: Number of free sectors in IS.
4.2.2.2 S̲o̲f̲t̲w̲a̲r̲e̲ ̲S̲t̲r̲u̲c̲t̲u̲r̲e̲
The software structure of Storage and Retrieval Subpackage
is described in section 4.1.2.
4.2.2.3 D̲a̲t̲a̲ ̲F̲l̲o̲w̲ ̲a̲n̲d̲ ̲C̲o̲n̲t̲r̲o̲l̲ ̲L̲o̲g̲i̲c̲
The data flow and control logic of Storage and Retrieval
Subpackage is described in section 4.1.3.
4.2.2.4 S̲u̲b̲p̲a̲c̲k̲a̲g̲e̲ ̲D̲a̲t̲a̲
The memory resident data used by Storage and Retrieval
Subpackage are included in CIFCBs and VCBs, of section
4.2.1.4.
The disk resident subpackage data are described in
section 4.2.2.1.
4.2.3 C̲h̲e̲c̲k̲p̲o̲i̲n̲t̲ ̲a̲n̲d̲ ̲R̲e̲c̲o̲v̲e̲r̲y̲ ̲S̲u̲b̲p̲a̲c̲k̲a̲g̲e̲
4.2.3.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 subpackage performs all functions of MMS which
are related to checkpoint-recovery. In particular it
executes the commands SAVE and RESTORE from application
processes.
4.2.3.1.1 C̲h̲e̲c̲k̲p̲o̲i̲n̲t̲ ̲F̲u̲n̲c̲t̲i̲o̲n̲s̲
4.2.3.1.1.1 C̲h̲e̲c̲k̲p̲o̲i̲n̲t̲
A c̲h̲e̲c̲k̲p̲o̲i̲n̲t̲ is an information block containing all
the control information needed to restore a CIF in
its present context. The major information groups are:
a) CIF Control Block
b) Field Descriptors
c) View Control Blocks
d) Application Process Data
The groups a) and b) together contain the complete
addressing information for the disk resident data of
the CIF, cf. section 4.2.1.4.
The Application Process Data are generated by MMON
and contain the CSF information about queue elements,
views, etc.
The layout of a checkpoint is shown in figure 4.2.3.1.1-1.
Each VCB in the checkpoint shall contain the View Reference
known by Message Monitor. Cf. section 2.2.1.6.
A checkpoint is divided into a number of c̲h̲e̲c̲k̲p̲o̲i̲n̲t̲
r̲e̲c̲o̲r̲d̲s̲, each containing up to 510 bytes of the checkpoints
and a 2 bytes control field.
Checkpoints for most CIFs can be contained in one record,
but for CIFs with many views and fields, one or more
c̲o̲n̲t̲i̲n̲u̲a̲t̲i̲o̲n̲ r̲e̲c̲o̲r̲d̲s̲ may be needed.
The layout of a checkpoint record is shown in figure
4.2.3.1.1-2. The last record in a checkpoint has CONTINUATION
equal to zero.
4.2.3.1.1.2 C̲h̲e̲c̲k̲p̲o̲i̲n̲t̲ ̲A̲r̲r̲a̲y̲
A checkpoint array is a pool of checkpoint records.
Length is called NO OF CHECKPOINT RECORDS.
An array element can be free or used. The free elements
are distinguished by a zero in RN field, cf. figure
4.2.3.1.1-2.
The states of array elements are described in the C̲heckpoint
Array B̲it M̲ap, which is a bit array of length NO OF
CHECKPOINT RECORDS. A bit set means that the corresponding
record is used.
MMS recognizes two checkpoint arrays:
a) D̲isk C̲heckpoint A̲rray
b) S̲tandby C̲heckpoint A̲rray
They have the same length, and the states of corresponding
elements are identical.
The DCA is controlled directly by MMS. The SCA is not
controlled directly, but the index of a checkpoint
record is used to identify checkpoint records in SCA,
when they are transmitted to or received from Standby
PU.
4.2.3.1.1.3 R̲e̲c̲o̲v̲e̲r̲y̲ ̲L̲e̲v̲e̲l̲
During the lifetime of a CIF in Short Term Storage,
a sequence of checkpoints is generated for the CIF.
Each checkpoint in the sequence describes the present
state of the CIF in the processing flow, and thus replaces
the previous one.
There are actually two different checkpoint sequences
for a CIF, one in the DCA and one in SCA. The sequences
are identified by an associated r̲e̲c̲o̲v̲e̲r̲y̲ l̲e̲v̲e̲l̲:
- Recovery level zero identifies the DCA checkpoint
sequence
- Recovery level one identifies the SCA checkpoint
sequence
The level zero sequence for each CIF will be a subsequence
of the level one sequence in the sense that each level
zero checkpoint is also recorded at level one. Figure
4.2.3.1.1-3 illustrates that. As the level one sequence
is updated more frequently, it gives a more precise
picture of the processing flow of a CIF, thus allowing
a more precise recovery.
The final checkpoint in a sequence is empty. It is
generated when the CIF is removed from STS.
MMS allows the level zero sequence for a CIF to be
empty. That means that the CIF is only checkpointed
in Standby. All operational items in CAMPS are, however,
expected to be checkpointed on disk.
The frequency of checkpoints in each sequence is completely
determined by application processes.
4.2.3.1.1.4 C̲h̲e̲c̲k̲p̲o̲i̲n̲t̲ ̲S̲e̲q̲u̲e̲n̲c̲e̲ ̲U̲p̲d̲a̲t̲e̲
This section applies directly to DCA, which is controlled
directly by MMS. The premises are, however, valid for
the SCA too, so similar precautions must be taken.
Each checkpoint in a sequence replaces the previous
one. This is done by letting the checkpoint simply
overwrite the previous one. This has some technical
implications which are described in the following.
The DCA consists of NO OF CHECKPOINT RECORDS consecutive
sectors on disk, each checkpoint record thus occupying
one complete sector. If a checkpoint consists of one
record only it can be safely overwritten in one disk
operation, provided dualized disk equipment is used,
cf. section 2.2.2.4.
If a checkpoint consists of more than one record, consistency
of the checkpoint during update shall be maintained
by writing the checkpoint into a "safety copy area"
before overwriting it in DCA.
4.2.3.1.1.5 C̲h̲e̲c̲k̲p̲o̲i̲n̲t̲ ̲R̲e̲c̲o̲r̲d̲ ̲A̲l̲l̲o̲c̲a̲t̲i̲o̲n̲
When a recoverable CIF is created by CREATE CIF or
CREATE NEXT CIF VERSION commands, a free element is
selected in DCA and SCA by means of the CBM. The index
of the element is recorded in CIFCB.
Each time a checkpoint is generated, the size of the
checkpoint is calculated. If it cannot fit into the
already allocated records, the necessary number of
records is allocated.
The allocated records are freed when final checkpoint
is generated.
4.2.3.1.1.6 S̲a̲v̲e̲ ̲C̲o̲m̲m̲a̲n̲d̲
Input: Recovery level
Checkpoint View Reference List
Application Process Data
Remove View Reference List
Output: Completion Code
A checkpoint is generated based on the Checkpoint View
Reference List and Application Process Data. The referenced
views shall be contained in the same CIF.
The steps in checkpoint generation are:
a) Record the referenced CIFCB
b) Record the field descriptors for those fields referenced
by any to the referenced views.
c) Record the VCBs for the referenced views
d) Record Appliation Process Data
e) Divide into checkpoint records.
If recovery level is one, the generated checkpoint
is transmitted to Standby PU to be written into SCA.
If recovery level is zero, the checkpoint is also recorded
on disk in DCA.
A special case is that the view list is empty. This
means that the checkpoint records allocated to the
CIF shall be deallocated.
When the checkpoint has been recorded in one or both
checkpoint arrays, the Remove View List is processed.
Each of the referenced views is removed, cf. section
4.2.1.1.3.1, a), b), and c).
If the CIF is subject to storage and all views have
been logically removed, the CIF is unloaded, cf. section
4.2.2.1.3.6.
4.2.3.1.2 R̲e̲c̲o̲v̲e̲r̲y̲ ̲F̲u̲n̲c̲t̲i̲o̲n̲s̲
Recovery in MMS means to use the information in DCA
or SCA to restore some previous state of each recoverable
CIF.
During MMS initialization the recovery level is specified.
The recovery level has only significance for a warm
start, cf. section 2.2.2.1.
The first three steps in recovery are:
a) Check the "safety copy area" described in 4.2.3.1.1.4.
If a DCA update was interrupted, it shall be repeated.
b) The complete DCA is checked for equality of the
dual copies of DCA. If any two dual sectors in
DCA are not equal, they are made equal by copying
one incarnation into the other.
c) Initialize FBM to all zeros and PBM to all ones,
cf. section 4.2.1.1.1.
MMS will now await a sequence of RESTORE commands from
Message Monitor.
During processing of this sequence, the appropriate
checkpoint array is read from the beginning with one
record at a time.
All CIFs which have been recovered are distinguished
by a Recovered Mark in The Recovery Information of
CIFCB, cf 4.2.1.4.1.
4.2.3.1.2.1 R̲e̲s̲t̲o̲r̲e̲ ̲C̲o̲m̲m̲a̲n̲d̲
Input: None
Output: Completion Code
Application Process Data
The next record in the appropriate checkpoint array
(selected by recovery level) is read and inspected.
If it is a continuation record, cf. figure 4.2.3.1.1.-2
or it is unused, the search continues until a record
is found which is the first one of a checkpoint.
If the end of checkpoint array is met during the search,
a "recovery terminated" completion code is returned
to Message Monitor, and MMS is then ready for normal
operation.
When a record is met, which is the first one of a checkpoint,
the following is done:
a) Set the corresponding bit in CBM, cf. section 4.2.3.1.1.2.
b) Read all continuation records for this checkpoint
and set corresponding CBM bits.
c) Restore CIFCB from checkpoint. The blocks occupied
by the CIF are removed from PBM, cf. section 4.2.1.1-1.
d) Restore Field Group Descriptors and Field Descriptors
from checkpoint.
e) Restore View Control Blocks from checkpoint, assuring
that they get the previously used View Reference,
cf. section 4.2.3.1.1.1.
f) Return Application Process Data to Message Monitor.
When recovery has been finished, the Purge Coroutine
is activated, cf. section 4.2.1.1.1.3.
4.2.3.2 S̲o̲f̲t̲w̲a̲r̲e̲ ̲S̲t̲r̲u̲c̲t̲u̲r̲e̲
The software structure of Checkpoint-Recovery subpackage
is described in section 4.1.2.
4.2.3.3 D̲a̲t̲a̲ ̲F̲l̲o̲w̲ ̲a̲n̲d̲ ̲C̲o̲n̲t̲r̲o̲l̲ ̲L̲o̲g̲i̲c̲
The Data Flow and Control Logic of Checkpoint-Recovery
subpackage are described in section 4.1.3.
4.2.3.4 S̲u̲b̲p̲a̲c̲k̲a̲g̲e̲ ̲D̲a̲t̲a̲
The Checkpoint-Recovery subpackage works on the following
data.
a) Recovery Information field in CIFCB, cf. 4.2.1.4.1
b) Checkpoint Bit Map, cf. section 4.2.3.1.1.2.
c) Disk Checkpoint Array, cf. section 4.2.3.1.1.2
d) Purge Block Map and Free Block Map, of section
4.2.3.1.2 c), and 4.2.3.1.2.1 c)
e) Checkpoints, cf. figure 4.2.3.1.1-1
f) Checkpoint Records, cf. section 4.2.3.1.1-2
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
RN CONTINUATION
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
CHECKPOINT DATA
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
RN: Record number within checkpoint
CONTINUATION: Identification of next record within
checkpoint
FIGURE 4.2.3.1.1-2
CHECKPOINT RECORD
FIGURE 4.2.3.1.1-3…01…CHECKPOINT SEQUENCES FOR A CIF
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
CIF CONTROL BLOCK
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
NUMBER OF FIELD
DESCRIPTORS
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
FIELD DESCRIPTORS
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
NUMBER OF VIEW
CONTROL BLOCKS
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
VIEW CONTROL BLOCKS
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
LENGTH OF APPLICATION
PROCESS DATA
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
APPLICATION
PROCESS DATA
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
FIGURE 4.2.3.1.1-1…01…CHECKPOINT LAYOUT
4.3 M̲e̲m̲o̲r̲y̲ ̲L̲a̲y̲o̲u̲t̲
See section 2.3.5.
