top - download
⟦df3afd301⟧ Wang Wps File
Length: 48674 (0xbe22)
Types: Wang Wps File
Notes: CPS/SDS/001 ISSUE 1
Names: »0684A «
Derivation
└─⟦6472223e8⟧ Bits:30006010 8" Wang WCS floppy, CR 0045A
└─ ⟦this⟧ »0684A «
WangText
"…08…"…0d…"…0f…"…00…"…01…"…05…"…06…"…07…!…08…!…0e…!
…09…
…0e…
…02…
…07……1f……0b……1f……01……1f……02……1f……07……1e……08……1e……0a……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̲
5.9 STORAGE AND FILE MANAGEMENT PACKAGE ......
388
5.9.1 Summary of Requirements ..............
388
5.9.1.1 General Description ..............
388
5.9.1.1.1 Function Overview ............
388
5.9.1.1.2 Interfaces ...................
388
5.9.1.2 Functions ........................
392
5.9.1.2.1 Devices .......................
392
5.9.1.2.1.1 Disk Controller and Disk
Drive ....................
392
5.9.1.2.1.2 Mirrored Disks and Their
Management ...............
395
5.9.1.2.1.3 Bad Sectors ..............
396
5.9.1.2.1.4 Naming of Devices ........
396
5.9.1.2.2 Volumes ......................
397
5.9.1.2.2.1 Volume Label .............
397
5.9.1.2.2.2 Volume Handling ..........
397
5.9.1.2.2.3 Volume Threshold .........
397
5.9.1.2.2.4 Volume Initialization ....
398
5.9.1.2.3 Files ........................
399
5.9.1.2.3.1 File Types and Their
Characteristics ..........
399
5.9.1.2.3.2 File Handling ............
401
5.9.1.2.3.3 File Catalogues and Naming
402
5.9.1.2.3.4 Data Transfer Commands ...
411
5.9.1.2.3.5 Examples in File Manipula-
tions ....................
412
5.9.1.2.4 Messages .....................
413
5.9.1.2.4.1 General Description ......
413
5.9.1.2.4.2 Message Management System
Functions .................
424
5.9.1.2.5 Security and Access Control ..
430
5.9.1.2.5.1 Security and Access
Control on Files .........
430
5.9.1.2.5.2 Security and Access
Control on Messages ......
432
5.9.1.2.6 Recovery .....................
433
5.9.1.2.6.1 File Management System
Recovery .................
433
5.9.1.2.6.2 Message Management System
Recovery .................
433
5.9.1.3 SFM Control ......................
438
5.9.1.3.1 Parameter Control ............
438
5.9.1.3.2 Initialization ...............
438
5.9.1.3.3 Error Handling ...............
438
5.9.1.4 Characteristics ..................
439
5.9.1.4.1 File Management System
Characteristics ..............
439
5.9.1.4.2 Message Management System
Characteristics ..............
439
5.9.1.4.2.1 Memory and Disk Layout ...
439
5.9.1.4.2.2 Sizing Estimates ..........
443
5.9.1.5 Design and Construction ..........
443
5.9.1.6 Documentation ....................
443
5.9.2 Environment ..........................
443
5.9.2.1 Standard Hardware, Firmware, and
Software .........................
443
5.9.2.2 External Interfaces ..............
444
5.9.2.3 Package Interfaces ...............
444
5.9 S̲T̲O̲R̲A̲G̲E̲ ̲A̲N̲D̲ ̲F̲I̲L̲E̲ ̲M̲A̲N̲A̲G̲E̲M̲E̲N̲T̲
5.9.1 S̲u̲m̲m̲a̲r̲y̲ ̲o̲f̲ ̲R̲e̲q̲u̲i̲r̲e̲m̲e̲n̲t̲s̲
5.9.1.1 G̲e̲n̲e̲r̲a̲l̲ ̲D̲e̲s̲c̲r̲i̲p̲t̲i̲o̲n̲
5.9.1.1.1 F̲u̲n̲c̲t̲i̲o̲n̲ ̲O̲v̲e̲r̲v̲i̲e̲w̲
Manages all disk and floppy disk storage except the
areas used for virtual memory.
Controls directly the use of disk controller RAM for
tables and buffers.
Disk space is subdivided into named files and messages,
controlled via hierarchies of catalogues. Security
and access control information for messages and files
is included in the catalogues.
Read and write operations use relative addresses within
files or messages, but direct addressing of physical
disk sectors by special privileged users is supported
too.
Mount of disk volumes with check of volume label is
supported. Formatting, purging and labelling of disk
volumes are not performed directly by SFM.
Implements the concept of mirrored disks.
5.9.1.1.2 I̲n̲t̲e̲r̲f̲a̲c̲e̲s̲
SFM is implemented as a DAMOS process and a set of
disk and floppy disk handlers. The process contains
a File Management System and a Message Management System.
Each disk handler controls one disk controller.
User process requests are sent to a SFM REQUEST SYNCHRONIZATION
ELEMENT common to all user processes. Requests can
only be sent by means of the I/O System (together with
Message Monitor in case of message requests).
Responses are by SFM sent to a RESPONSE SYNCHRONIZATION
ELEMENT specific to the user issuing the request.
Responses must also be handled in the first hand by
I/O System and Message Monitor.
Fig. 5.9.1.1.2-1 SFM Command-Response Interface
Figure 5.9.1.1.2-2 SFM Interface Chart in CAMPS environment
5.9.1.2 F̲u̲n̲c̲t̲i̲o̲n̲s̲
5.9.1.2.1 D̲e̲v̲i̲c̲e̲s̲
5.9.1.2.1.1 D̲i̲s̲k̲ ̲C̲o̲n̲t̲r̲o̲l̲l̲e̲r̲ ̲a̲n̲d̲ ̲D̲i̲s̲k̲ ̲D̲r̲i̲v̲e̲ ̲C̲o̲n̲c̲e̲p̲t̲
a1) G̲e̲n̲e̲r̲a̲l̲ ̲C̲o̲n̲c̲e̲p̲t̲
As seen on the interface chart figure 5.9.1.1.2-1
the disk handler is a part of SFM. The disk handler
is a software module which controls the disk drive
via a disk controller.
a2) D̲i̲s̲k̲ ̲C̲o̲n̲t̲r̲o̲l̲l̲e̲r̲
The disk controller consists of an I/O module and
a memory module. The disk controller relationship
to other modules is as described on figure 5.9.1.2.1.1.b.
a3) D̲i̲s̲k̲ ̲C̲o̲n̲t̲r̲o̲l̲l̲e̲r̲ ̲I̲n̲t̲e̲r̲f̲a̲c̲e̲
The dual-ported disk controller provides the interface
between the CR80D I/O busses and the disk device
as shown on figure 5.9.1.2.1.1.c.
a4) C̲A̲M̲P̲S̲ ̲D̲i̲s̲k̲ ̲C̲o̲n̲f̲i̲g̲u̲r̲a̲t̲i̲o̲n̲
The disk configuration related to CAMPS system
is depicted in figure 5.9.1.2.1.1.d and consists
of three disk drives and disk adaptors (DCA) each
connected to a disk controller with memory.
Figure 5.9.1.2.1.1.b…01…Disk Controller Connection
Figure 5.9.1.2.1.1.c
figure 5.9.1.2.1.1.d
b) D̲i̲s̲k̲ ̲C̲o̲n̲t̲r̲o̲l̲l̲e̲r̲ ̲O̲p̲e̲r̲a̲t̲i̲o̲n̲ ̲a̲n̲d̲ ̲S̲t̲a̲t̲u̲s̲
The disk controller receives commands and delivers
status via the I/O busses.
Main operations are:
Seek, Read, Write, Seek and Read, Seek and Write,
Format, Read Address Field.
The data used in conjunction with the above mentioned
commands are:
Cylinder-, head-, and sector numbers.
Status information returned from the controller
can be as follows:
Write protected drive, Unexpected drive status,
Data field check or sync. error, Address field
check or sync. error, Sector marked as bad, Sector
is write protected, Illegal sector, Timing error,
Subbus overruns and parity error in controller
memory.
5.9.1.2.1.2 M̲i̲r̲r̲o̲r̲e̲d̲ ̲D̲i̲s̲k̲s̲ ̲a̲n̲d̲ ̲T̲h̲e̲i̲r̲ ̲M̲a̲n̲a̲g̲e̲m̲e̲n̲t̲
FMS support management of mirrored disk packs, which
are updated concurrently, to assure that data will
not be lost in case of a hard error on one disk.
Updating of mirrored disk pair thinking of power failure
is achieved by first updating the sectors on the first
volume. The same sectors on the other disk is updated
in a succeeding process. FMS shall allow exclusion
of one of the two identical volumes while normal service
goes on, on the other. After repair one volume shall
be brought to the state of the running volume while
normal service continues.
5.9.1.2.1.3 B̲a̲d̲ ̲S̲e̲c̲t̲o̲r̲s̲
FMS is able to handle bad sectors on each volume unless
it is sector 0 which will mean that the volume is useless.
Bad sectors are handled by keeping a translation table
on each volume, from each bad sector to an alternative
sector. Using mirrored disks the translation table
of the two disks shall be kept identical to assure
that all disk addresses can be interpreted in the same
way.
If bad sectors are detected while bringing a disk up,
they are marked as such on both disks and both translation
tables must be updated accordingly.
5.9.1.2.1.4 N̲a̲m̲i̲n̲g̲ ̲o̲f̲ ̲D̲e̲v̲i̲c̲e̲s̲
a) D̲e̲v̲i̲c̲e̲ ̲N̲a̲m̲e̲s̲
Each device, which is used by the system or will
be used, is referenced by a device name. A device
name is an array of 4 bytes.
b) D̲e̲v̲i̲c̲e̲ ̲H̲a̲n̲d̲l̲i̲n̲g̲
Commands for handling devices are administrated
by SFM. Introduction of a device to SFM is done
by the command ASSIGN. Input in conjunction with
the command is device name and description. DEASSIGN
command removes the specified device from the regime
of SFM.
c) D̲e̲v̲i̲c̲e̲ ̲D̲e̲s̲c̲r̲i̲p̲t̲i̲o̲n̲
When the device is introduced to SFM a description
of its attributes must be given as well. The attributes
are device, kind, size, physical address and device
name. Introduction is done by:
ASSIGN
Input: Device attributes
Device name
Removing a specified device from the regime of
SFM is done by
DEASSIGN
Input: Device name
5.9.1.2.2 V̲o̲l̲u̲m̲e̲s̲
5.9.1.2.2.1 V̲o̲l̲u̲m̲e̲ ̲L̲a̲b̲e̲l̲
Each volume administrated by SFM shall be recognized
by a volume name. The volume name is an array of 16
bytes. Volume name can be changed by a command to SFM.
5.9.1.2.2.2 V̲o̲l̲u̲m̲e̲ ̲H̲a̲n̲d̲l̲i̲n̲g̲
SFM is able to logically mount and dismount volumes
i.e. create the connection between the volume and SFM.
The MOUNT command checks the volume name against the
recorded volume name and open a number of system files.
Hereafter the volume is identified by the volume name.
DISMOUNT of volume has the effect that the specified
volume is excluded from SFM and the system files are
closed. The system files will be described in chapter
5.9.1.2.3.
5.9.1.2.2.3 V̲o̲l̲u̲m̲e̲ ̲T̲h̲r̲e̲s̲h̲o̲l̲d̲
A number of commands exists to control the filling
rate of the volumes. The maximum number of sector-allocation
on the volume is controlled by
SET VOLUME THRESHOLD
Input: Volume name
Threshold
Returning of current value of volume threshold is done
by:
GET VOLUME THRESHOLD
Input: Volume name
Output: Threshold
5.9.1.2.2.4 V̲o̲l̲u̲m̲e̲ ̲I̲n̲i̲t̲i̲a̲l̲i̲z̲a̲t̲i̲o̲n̲
a) G̲e̲n̲e̲r̲a̲l̲ ̲C̲o̲n̲c̲e̲p̲t̲
When a complete new volume is mounted on a disk
drive it must be prepared for receiving data. This
process is carried out by a utility initialization
program with the following steps:
- formatting of volume
- handling of bad sectors
- creation of an initial empty volume
b) V̲o̲l̲u̲m̲e̲ ̲F̲o̲r̲m̲a̲t̲t̲i̲n̲g̲
During the formatting process all sectors are marked
with an address information which only will be
used by the controller.
c) H̲a̲n̲d̲l̲i̲n̲g̲ ̲o̲f̲ ̲B̲a̲d̲ ̲S̲e̲c̲t̲o̲r̲s̲
All bad sectors will be marked and index table
updated accordingly. Handling of bad sectors during
start up of dualized disks has previously been
described.
d) C̲r̲e̲a̲t̲i̲o̲n̲ ̲o̲f̲ ̲a̲n̲ ̲I̲n̲i̲t̲i̲a̲l̲ ̲E̲m̲p̲t̲y̲ ̲V̲o̲l̲u̲m̲e̲
This process creates the system Files on the volume.
e) I̲n̲i̲t̲i̲a̲l̲i̲z̲a̲t̲i̲o̲n̲ ̲I̲n̲p̲u̲t̲ ̲P̲a̲r̲a̲m̲e̲t̲e̲r̲s̲
The parameters needed during the initialization
process are as follows:
Device name
Volume name
Number of sectors
System Files area size
Initial entries in the system files
5.9.1.2.3 F̲i̲l̲e̲s̲
5.9.1.2.3.1 F̲i̲l̲e̲ ̲T̲y̲p̲e̲s̲ ̲a̲n̲d̲ ̲t̲h̲e̲i̲r̲ ̲C̲h̲a̲r̲a̲c̲t̲e̲r̲i̲s̲t̲i̲c̲s̲
a) G̲e̲n̲e̲r̲a̲l̲ ̲C̲o̲n̲c̲e̲p̲t̲
A file is a logical sequence of blocks. Blocks
are identified by relative block number within
the file.
b) C̲o̲n̲t̲i̲g̲u̲o̲u̲s̲ ̲F̲i̲l̲e̲s̲
SFM supports two different mechanisms for transforming
a block number in a file to a sector number on
a volume. The block of a contiguous file is mapped
onto a sequence of contiguous sectors on a volume.
Figure 5.9.1.2.3.1-1…01…CONTIGUOUS FILE ON A VOLUME
Shaded sectors form a contiguous file consisting
of a number of blocks. Contiguous files will be
used for information where maximum length is known
in advance, as they cannot be extended.
c) R̲a̲n̲d̲o̲m̲ ̲F̲i̲l̲e̲s̲
The blocks of a random file are mapped onto sectors
which are scattered across a volume. The mapping
is based on an index which for each block number
in the file contains the number of the corresponding
sector on the volume. The index itself is also
stored on the volume. Index blocks can be linked
together to make the size of the file unlimited.
The random file will be used for information which
may change i.e. information under editing.
Figure 5.9.1.2.3.1-2
A random file on a volume
2 index blocks and 4 data blocks
d) F̲i̲l̲e̲ ̲C̲h̲a̲r̲a̲c̲t̲e̲r̲i̲s̲t̲i̲c̲s̲
1) F̲i̲l̲e̲ ̲N̲a̲m̲e̲
A file is referenced by a file name.
2) F̲i̲l̲e̲ ̲A̲t̲t̲r̲i̲b̲u̲t̲e̲s̲
File attributes is a record defining the characteristics
of a file.
It consists of four fields:
- volume name
- file organization see 5.9.1.2.3.1
- allocation size
- area size
Volume name has previously been described.
File organization may be contiguous or random
or a third structure called directories, which
will be described later.
Allocation size is how much space reserved upon
the creation of the file. Area size is the amount
of blocks allocated to a random file by an extension
of the file.
3) F̲i̲l̲e̲ ̲D̲e̲s̲c̲r̲i̲p̲t̲o̲r̲
An index identifying the file when it is open.
The file descriptor identifies a control block
which contains information such as address on volume,
file size, file users, etc. All access to a file
uses a file descriptor as reference.
5.9.1.2.3.2 F̲i̲l̲e̲ ̲H̲a̲n̲d̲l̲i̲n̲g̲
Some of the file handling functions include a user
identification. For details refer to section 5.9.1.2.5.
Before use of files, they must be created by the command:
CREATE
Input: User-id
Attributes
Output: File descriptor
Disconnection of a caller from a file can be controlled
by
DISMANTLE
Input: File descriptor
Defining the maximum number of sectors for a file is
done by the command:
SET FILE THRESHOLD
Input: File descriptor
Threshold
5.9.1.2.3.3 F̲i̲l̲e̲ ̲C̲a̲t̲a̲l̲o̲g̲u̲e̲s̲ ̲a̲n̲d̲ ̲N̲a̲m̲i̲n̲g̲
a) G̲e̲n̲e̲r̲a̲l̲ ̲C̲o̲n̲c̲e̲p̲t̲
To keep track of the information on the volume
there exists a number of system files called directories.
The contents are f.inst. symbolic names on files
and their physical address. Furthermore, the user
file information such as user(s), file attributes,
access and security control are recorded.
b) D̲i̲r̲e̲c̲t̲o̲r̲i̲e̲s̲ ̲D̲e̲s̲c̲r̲i̲p̲t̲i̲o̲n̲
1) B̲a̲s̲i̲c̲ ̲F̲i̲l̲e̲ ̲D̲i̲r̲e̲c̲t̲o̲r̲y̲
A volume can contain several files. Therefore,
each volume contains a Basic File Directory
(BFD) which acts as a table of contents for
the volume. Figure 5.9.1.2.3.3-1. Each file
on the volume is described by an entry in the
BFD. Such an entry contains the information
which is necessary to describe the file. Included
is information which makes it possible to retrieve
the blocks of the file, the size of the file,
a list of the users who are authorized to access
the file, etc.
Since the BFD contains an entry for each file
on the volume, a file is uniquely identified
by the sequence number of its entry in the
BFD. This form of file identification is used
in the file system.
To facilitate access to the BFD of a volume,
the BFD is also implemented as a file. The
BFD should always exist on the volume.
Figure 5.9.1.2.3.3-1
Basic File Directory and four files on a volume. (The
sector structure of the volume is abstracted away).
2) S̲y̲m̲b̲o̲l̲i̲c̲ ̲F̲i̲l̲e̲ ̲D̲i̲r̲e̲c̲t̲o̲r̲y̲
Whereas the BFD is concerned with maintaining
descriptions of the files on a volume, a Symbolic
File Directory (SFD) is concerned with the
naming of these files. Naming a file is thus
a function which is distinct from describing
its attributes. A SFD function as a table.
Each entry transforms a user defined name into
a sequence number of a BFD entry (which is
a unique identification of a file). If a SFD
is used it is therefore possible to refer to
a file by a symbolic name. Figure 5.9.1.2.3.3-2.
By implementing an SFD as a file and by allowing
several SFDs on a volume, this scheme has been
generalized into a multilevel naming structure.
Figure 5.9.1.2.3.3-3. Since an SFD is itself
a file it can now be given a name in another
SFD etc. This process can continue to any depths,
and thus a hierarchical naming structure for
files exists.
Each volume contains a special SFD. This SFD
is considered the root of the naming hierarchy
for files. This means that a search for a named
file in principle must start in this SFD and
then possibly continue through lower level
SFDs. This special SFD should always exist
on the volume
Figure 5.9.1.2.3.3-2
Transformation of symbolic names into file references
via a SFD.
Figure 5.9.1.2.3.3-3
Transformation of symbolic names into a file reference
via several levels of SFD. (Starting with file no.
2 in the BFD (which is an SFD) the name 'mysfd' can
be transformed into a reference to file no. 4, which
transforms the name 'myfile' into a reference to file
no 0).
3) H̲o̲m̲e̲ ̲B̲l̲o̲c̲k̲
Each volume contains three special files:
- The Basic File Directory (BFD) which contains
a description of the files on the volume
- The Bit Map which contains information
on the allocation status of each sector
on the volume
- The Root Symbolic File Directory which
in principle is the starting point for
a search of a named file.
These files contain the information which makes
it possible to access the rest of the files
on the volume. Therefore, they should always
exist on the volume. Access to these files
can be gained through the Home Block (HB) of
the volume. Apart from the name of the volume
the HB contains the sector address of the description
of the BFD (which is actually contained in
the BFD).
The HB is the only information on the volume
which is not part of a file. Since the HB is
always stored on a known address on the volume
it can be used to bootstrap the entire file
structure.
Figure 5.9.1.2.3.3-4
The Home Block and the special files on a volume.
c) D̲i̲r̲e̲c̲t̲o̲r̲y̲ ̲H̲a̲n̲d̲l̲i̲n̲g̲
SFM include commands to insert, search for, change
and delete names in directories:
GETROOT
Input: Volume name
Output: File descriptor
The function of this command is that a file descriptor
(reference to) to root directory file is returned.
ENTER
Input: File name
File description
A new entry is put into the SFD file referenced
by the file descriptor
LOOK UP
Input: SFD file descriptor
File name
Output: File descriptor
The command searches through the SFD file and returns
a file descriptor corresponding to the file name.
UPDATE
Input: Volume name
The function is that the main memory resident volume
information is copied to the disk.
DESCENT
Input: SFD file descriptor
File name
Output: File descriptor
The command is analog to achieve both a lookup
and a dismantle command.
Figure 5.9.1.2.3.3-5
Descent (Fd1, myfile)(fd2) analog to
Lookup (Fd1, myfile)(fd2) and Dismantle (fd1)
d) U̲s̲e̲r̲ ̲F̲i̲l̲e̲s̲
The above mentioned commands were specially meant
for use on directory files. The following commands
can be used as well on user files.
DESCENT (see previous chapter)
RENAME
Input: SFD file descriptor
Old file name
New file name
Changes the name of a file in the SPD file directory
REMOVE
Input: SFD file descriptor
File name
Deletes the symbolic name of the file from the
SFD file.
5.9.1.2.3.4 D̲a̲t̲a̲ ̲T̲r̲a̲n̲s̲f̲e̲r̲ ̲C̲o̲m̲m̲a̲n̲d̲s̲
a) G̲e̲n̲e̲r̲a̲l̲ ̲C̲o̲n̲c̲e̲p̲t̲
The transfer commands are used to bring about the
actual transfer of data between external storage
media and the users data buffers.
b) D̲a̲t̲a̲ ̲T̲r̲a̲n̲s̲f̲e̲r̲ ̲M̲o̲d̲e̲s̲
1) D̲a̲t̲a̲ ̲B̲u̲f̲f̲e̲r̲ ̲t̲o̲ ̲S̲e̲c̲t̲o̲r̲s̲ ̲o̲r̲ ̲R̲e̲v̲e̲r̲s̲e̲
This transfer modes consider the external storage
media as volumes made up of sectors.
These modes are only available for privileged
system processes.
2) D̲a̲t̲a̲ ̲B̲u̲f̲f̲e̲r̲ ̲t̲o̲ ̲F̲i̲l̲e̲s̲ ̲o̲r̲ ̲R̲e̲v̲e̲r̲s̲e̲
This set of transfer commands is used to transfer
information between files and user data buffers.
Files are considered consisting of a sequence
of bytes.
c) T̲r̲a̲n̲s̲f̲e̲r̲ ̲C̲o̲m̲m̲a̲n̲d̲s̲
1) S̲e̲c̲t̲o̲r̲ ̲T̲r̲a̲n̲s̲f̲e̲r̲
The following two commands are only available
to privileged system processes.
Sectors can be transferred from external storage
media to user by issuing the command.
READ SECTORS
Input: File descriptor
File address
Output: Sectors
The disk sector is left unchanged. Transferring
sectors from user buffer to the external storage
media is achieved by the command.
WRITE SECTOR
Input: File descriptor
File address
Sectors
2) F̲i̲l̲e̲ ̲T̲r̲a̲n̲s̲f̲e̲r̲
By use of the following commands it is possible
to read and write any number of bytes at any
position on the file. Reading bytes are achieved
by
READ BYTES
Input: File descriptor
File address
Output: Byte string
Changing the content of a file is achieved
by:
MODIFY BYTES
Input: File descriptor
File address
Byte string
Adding additional data to the tailing edge
of a file is achieved by:
APPEND BYTES
Input: File descriptor
File address
Byte string
5.9.1.2.3.5 E̲x̲a̲m̲p̲l̲e̲s̲ ̲i̲n̲ ̲F̲i̲l̲e̲ ̲M̲a̲n̲i̲p̲u̲l̲a̲t̲i̲o̲n̲s̲
a) F̲i̲l̲e̲ ̲C̲r̲e̲a̲t̲i̲o̲n̲
The create command allocates space for the file
and returns a file descriptor.
File name may be inserted in SFD for later reference,
by the enter command.
A look up command searches for a specified file
in SFD and returns the corresponding file descriptor
when file is found.
b) U̲s̲e̲ ̲o̲f̲ ̲F̲i̲l̲e̲s̲
Searching of a user file with a specified file
name on a volume is carried out through the following
sequence of commands:
Getroot (vol. name)(fd1) command returns the file
descriptor fd1 for the root directory.
Descent (fd1,mycatl.)(fd2) returns a file descriptor
fd2 referencing the symbolic file directory mycatl.
Descent (fd2, myfile)(fd3) returns a file descriptor
fd3 referencing the actual user file.
After having used the transfer commands or after
having completed operations on the file a dismantle
command can be issued.
A dismantle command will have the effect that the
file will be inaccessible to the user. If it is
no longer accessible to anybody, it is deallocated
from the volume.
5.9.1.2.4 M̲e̲s̲s̲a̲g̲e̲s̲
5.9.1.2.4.1 G̲e̲n̲e̲r̲a̲l̲ ̲D̲e̲s̲c̲r̲i̲p̲t̲i̲o̲n̲
The M̲essage M̲anagement S̲ystem part of SFM controls
storage of and access to areas on disk, mainly used
for messages in various stages of processing.
The objects managed by MMS will be called items. The
main differences between items and ordinary files are
that items are relatively small, and that they are
subject to very intense activity during a relatively
short period after their creation. After that period
they may be stored away permanently, but will then
normally be subject to very low activity if any at
all.
MMS will optimize storage of and access to items according
to this activity profile.
The message management functions within CAMPS will
be carried out by MMS in cooperation with the Message
Monitor within CAMPS System Functions.
a) I̲t̲e̲m̲ ̲S̲t̲r̲u̲c̲t̲u̲r̲e̲
Each item is structured as a record with variable
length fields. Each field can be expanded, modified
and reset dynamically. The maximum number of fields
must be defined at item creation time.
The structure is shown in the following figure.
Figure 5.9.1.2.4.1-1 Item Structure
The notion of allocated but unused space has no
user significance, but is used by the internal
MMS space allocation algorithm.
Addressing of data within an item is done by addresses
of the form:
field index, relative byte address within field
The use and interpretation of each field is application
dependent and not within the scope of MMS. In CAMPS
most of these aspects are taken care of by Message
Monitor.
b) I̲t̲e̲m̲ ̲K̲i̲n̲d̲
1) T̲e̲m̲p̲o̲r̲a̲r̲y̲ ̲i̲t̲e̲m̲
A temporary item is a sort of working space
which may possibly be shared by a number of
users. The item will cease to exist when the
last using module indicates that it has terminated
the use of the item.
A temporary item may only be referenced via
a memory resident item control block.
2) P̲e̲r̲m̲a̲n̲e̲n̲t̲ ̲I̲t̲e̲m̲
A permanent item is intended for purposes where
the item contents must be kept by the system
for later use. A permanent item may be filed
permanently when its use is terminated.
A permanent item will be identified by a unique
item identification, IID, and may be referenced
either by IID or by a memory resident item
control block.
Note that the item kind is not directly related
to the recoverability of the item. An item
may be recovered to an extent specified by
the user system independent of the item kind.
Figure 5.9.1.2.4.1-2 Item Referencing Depending on Item Kind
c) I̲t̲e̲m̲ ̲R̲e̲f̲e̲r̲e̲n̲c̲i̲n̲g̲
Items may be referenced by item identification
or by item control block. Reference by item id
does not apply to temporary items.
1) I̲t̲e̲m̲ ̲I̲d̲e̲n̲t̲i̲f̲i̲c̲a̲t̲i̲o̲n̲
An item id consists of:
1.1) A unique 32 bits integer
1.2) A one byte version indicator
The item id is generated by MMS when a new
item or item version is created. It is the
basic reference to the item, and MMS will maintain
an Item Directory for each on-line or off-line
volume, whereby all permanent items on the
volume may be located, using item id as the
key.
The item id will be unique for the whole lifetime
of a CAMPS system.
2) I̲t̲e̲m̲ ̲C̲o̲n̲t̲r̲o̲l̲ ̲B̲l̲o̲c̲k̲
Whenever an item is in use by one or more user
processes, it may be referenced via a memory
resident Item Control Block.
The ICB contains key information about the
item, such as:
2.1) Item attributes, as described in section
5.9.1.2.4.2.a.1
2.2) Storage address, which is the disk
address of the first item field
2.3) User list, which is a list of user
processes currently using the item.
Figure 5.9.1.2.4.1-3…01…Directory for Intermediate Storage…01…Same Principle used for each Long
Term Storage Volume
An ICB reference is an integer used as
index into the array of ICBs.
The functions LOOKUP and RETRIEVE reference
items by item id. All other functions use
ICB reference.
ICBs may not be accessed directly by user
processes. Most of the contents may however
be obtained by the GET ATTRIBUTES function,
of section 5.9.1.2.4.2.a.2.
3) I̲t̲e̲m̲ ̲V̲e̲r̲s̲i̲o̲n̲s̲
A permanent item may exist in different versions
at a given time. The version concept has no
meaning for temporary items.
The first version of an item is generated by
the CREATE ITEM function. The version number
for this one is 1.
Subsequent versions are generated by the CREATE
NEXT VERSION function.
The different versions of an item will have
the same number of fields. Otherwise they are
completely independent objects as far as MMS
is concerned.
d) S̲t̲o̲r̲a̲g̲e̲ ̲T̲y̲p̲e̲s̲
MMS will recognize three different types of storage:
1) S̲h̲o̲r̲t̲ ̲T̲e̲r̲m̲ ̲S̲t̲o̲r̲a̲g̲e̲
A "fast access" storage area where an item
can be kept during the first busy part of its
lifetime.
Items in short term storage may be read, updated
or deleted.
Items in short term storage will be organized
in a way facilitating fast access and update
to individual fields. This is done by letting
each field start at a sector boundary. In this
way fields may be expanded and updated without
implied reading or copying of other fields.
When a field is extended, storage space will
be allocated in blocks of several sectors in
order to minimize the number of disk operations
required to read and write the entire field
or item. Block size is defined during formatting
of MMS areas.
2) L̲o̲n̲g̲ ̲T̲e̲r̲m̲ ̲S̲t̲o̲r̲a̲g̲e̲
Serves as long term storage for items which
have terminated the initial processing cycle.
Items in long term storage may be read or deleted.
As the items in long term storage need not
be updated, they can be stored in a packed
form taking up as little space as possible.
Long Term Storage resides on a number of removable
disk volumes.
3) I̲n̲t̲e̲r̲m̲e̲d̲i̲a̲t̲e̲ ̲S̲t̲o̲r̲a̲g̲e̲
Intermediate storage is always on-line and
serves as sort of spooling area between short
term and long term storage.
Figure 5.9.1.2.4.1-4…01…Storage Type Characteristics
Figure 5.9.1.2.4.1-5
Transfers Between Storage Types
e) I̲t̲e̲m̲ ̲D̲i̲r̲e̲c̲t̲o̲r̲i̲e̲s̲
Intermediate - and Long Term Storage will include
directories for control and retrieval of storage
contents.
A directory contains an entry for each item in
the corresponding storage. The entry is mainly
an extract of the item control block described
in section 5.9.1.2.4.1.c.2. It contains the control
information needed to rebuild the item in short
term storage on retrieval.
A directory entry and thus the corresponding item
may be retrieved using item identification as key.
Intermediate storage has its own directory and
in addition there is a directory on each Long Term
Storage volume.
In order that MMS can locate an item in Long Term
Storage, the appropriate volume must be mounted
by a user process before the retrieve request is
sent to MMS.
5.9.1.2.4.2 M̲e̲s̲s̲a̲g̲e̲ ̲M̲a̲n̲a̲g̲e̲m̲e̲n̲t̲ ̲S̲y̲s̲t̲e̲m̲ ̲F̲u̲n̲c̲t̲i̲o̲n̲s̲
This section describes functions for item manipulation
and use of intermediate and long term storage.
a) I̲t̲e̲m̲ ̲M̲a̲n̲i̲p̲u̲l̲a̲t̲i̲o̲n̲
1) A̲t̲t̲r̲i̲b̲u̲t̲e̲ ̲M̲a̲n̲i̲p̲u̲l̲a̲t̲i̲o̲n̲
The attributes of an item are the following:
1.1) Item identification
1.2) Item kind
1.3) Storage status (Describing current
storage type)
1.4) No. of fields
1.5) Used and allocated length of each field
1.6) Security profile
1.7) No. of users
Attributes b, d, and f are specified in CREATE
ITEM commands. There are two functions for
directly accessing attributes.
2) G̲e̲t̲ ̲A̲t̲t̲r̲i̲b̲u̲t̲e̲s̲
Reads the current attribute values.
3) C̲h̲a̲n̲g̲e̲ ̲A̲t̲t̲r̲i̲b̲u̲t̲e̲s̲
The only changeable attribute is security profile.
b) I̲t̲e̲m̲ ̲H̲a̲n̲d̲l̲i̲n̲g̲
1) CREATE ITEM
Creates a new item in short term storage. No
storage is allocated at creation time, but
an ICB is generated. For a permanent item a
new item id is generated.
Input: Item attributes b, d, f of section
5.9.1.2.4.2.a.1
Output: ICB reference
Item id, if permanent item
2) CREATE NEXT VERSION
Creates a new version in short term storage
of an existing permanent item.
Input: ICB reference for currently latest
version
Output: ICB reference for next version.
Item id of next version
3) DELETE ITEM
Removes an item version
Input: ICB reference
4) OPEN ITEM
Requests access to an item referenced by ICB
Input: ICB reference
5) LOOK UP ITEM
Requests access to an item referenced by item
id. Generates an ICB if not already existing.
Input: Item Id
Output: ICB reference
6) CLOSE ITEM
Terminates the callers use of an item
Input: ICB reference
c) I̲t̲e̲m̲ ̲M̲a̲n̲i̲p̲u̲l̲a̲t̲i̲o̲n̲
Most item manipulation functions work on fields,
using field addresses of the form
field index, byte address within field
A few functions operate on groups of fields.
1) READ BYTES IN FIELD
Reads a byte string from the specified field
address
Input: ICB reference
Field address
Byte count
Output: Byte string
2) MODIFY BYTES IN FIELD
Overwrites part of a field with a new byte
string. May cause extension of the field.
Input: ICB reference
Field address
Byte string
3) APPEND BYTES IN FIELD
Extends a field with a new byte string
Input: ICB reference field index
4) READ FIELD GROUP
Reads a group of fields from specified field
address and onwards. The fields read will be
appended to each other into a single byte string.
The structure of the obtained byte string may
be seen from the item attributes.
Input: ICB reference
Field address
Field count
Byte count
Output: Byte string
5) RESET FIELDS
Clears contents of the specified field(s) and
sets used length = allocated length = 0.
Input: ICB reference
Field list
6) COPY FIELDS
Copies field(s) from one item into another.
The parameter field list consists of pairs:
source field, destination field. The entire
source field is copied into the specified destination
field.
Input: ICB reference for source item
ICB reference for destination item
Field list
7) PURGE ITEM
Overwrites item a specified no of times and
deletes it.
Input: ICB reference
d) S̲t̲o̲r̲a̲g̲e̲ ̲a̲n̲d̲ ̲R̲e̲t̲r̲i̲e̲v̲a̲l̲ ̲F̲u̲n̲c̲t̲i̲o̲n̲s̲
Perform the transfers between the three storage
types. The transfers are shown in figure 5.9.1.2.4.1-2.
Monitors the storage occupancy of intermediate
storage.
1) STORE ITEM
Requests that the referenced item be transferred
from Short Term to Intermediate Storage. A
field list parameter specifies the fields to
be transferred. The request implies that the
specified fields may no longer be updated.
The item with specified fields is marked for
transfer to intermediate storage, and at some
convenient time the specified fields will be
packed together and copied to intermediate
storage. The original copy will however be
kept in short Term Storage as long as there
are users of the item.
During storage the Intermediate Storage Directory
must be updated with entries corresponding
to the stored items.
Input: ICB reference
Field list
2) DUMP ITEMS
Requests that the items specified be moved
from Intermediate Storage to the Long Term
Storage volume specified. The dump includes
the items as well as the directory entries
which are inserted into the Long Term Storage
Directory of the volume in question.
Input: Item id list
Volume
Output: Free storage in Intermediate storage
Free storage in Long Term Storage
3) RETRIEVE ITEM
Requests that the specified item be located
on the specified volume (Intermediate or a
mounted Long Term Storage Volume) and copied
into short Term Storage as a temporary item.
Input: Item id.
Volume
Output: ICB reference for generated temporary
item
4) SET INTERMEDIATE STORAGE THRESHOLD
Defines a minimum free space threshold for
intermediate storage. When the threshold is
reached, a warning is sent to the calling user
process.
Input: Sector count
Return Synch Element
5) ITEM THRESHOLD WARNING
Indicates to a user process that a previously
specified threshold has been reached. The warning
is sent to a synch element specified in a previous
SET INTERMEDIATE STORAGE THRESHOLD command.
6) GET LOAD FIGURES
Returns the no. of free sectors in Short Term
and Intermediate Storage.
7) GET MMS CATALOGUE
Requests MMS to open its directory and item
areas on a Long Term Storage volume, preparing
for a subsequent dump or retrieval.
Input: Volume id.
5.9.1.2.5 S̲e̲c̲u̲r̲i̲t̲y̲ ̲a̲n̲d̲ ̲A̲c̲c̲e̲s̲s̲ ̲C̲o̲n̲t̲r̲o̲l̲
5.9.1.2.5.1 S̲e̲c̲u̲r̲i̲t̲y̲ ̲a̲n̲d̲ ̲A̲c̲c̲e̲s̲s̲ ̲C̲o̲n̲t̲r̲o̲l̲ ̲o̲n̲ ̲F̲i̲l̲e̲s̲
a) U̲s̲e̲r̲ ̲a̲n̲d̲ ̲U̲s̲e̲r̲ ̲G̲r̲o̲u̲p̲s̲
A user is a process running under DAMOS. User may
be collected into user groups, which are the basis
for access control. An active process in the system
is identified by a user-id consisting of:
- user group identification
- process identification
b) U̲s̲e̲r̲ ̲C̲o̲m̲m̲a̲n̲d̲s̲
A user must be known to SFM before he is able to
execute commands. This is done by the command:
USER ON
Input: User-id.
Classification
The classification consist of a security profile.
To exclude a user from being able to execute commands
following command can be used.
USER OFF
Input: User-id.
The user-on and user-off commands may only be executed
by the parent of the user.
GET FILE INFORMATION
Input: File descriptor
File information type
Output: File information
This command returns the file information described
in the file information type the command can be
used during the security and access control.
c) A̲c̲c̲e̲s̲s̲ ̲C̲o̲n̲t̲r̲o̲l̲ ̲L̲i̲s̲t̲ ̲a̲n̲d̲ ̲C̲a̲p̲a̲b̲i̲l̲i̲t̲i̲e̲s̲
To each file on a volume there is connected an
Access Control List (ACL). The ACL for a file describes
the access rights of each user who is authorized
to use the file. By access rights are meant the
set of operations which a user may perform on a
file. When a file is initially created the creator
is given the rights to access the file any way
he might choose.
Each time a file is accessed by a user it must
be verified that the user has the rights to do
so. Instead of consulting the volume resident ACL,
there exists an internal data structure called
Capabilities which show the access rights of user
groups to files which have been opened. Therefore,
the access to files can be controlled without accessing
external storage.
d) S̲e̲c̲u̲r̲i̲t̲y̲ ̲C̲o̲n̲t̲r̲o̲l̲ ̲o̲n̲ ̲F̲i̲l̲e̲ ̲A̲c̲c̲e̲s̲s̲
Each file and user has a security profile, which
is set by CREATE and USERON commands respectively.
At file access the general DAMOS security check
of a process accessing an object is performed.
e) P̲r̲i̲v̲i̲l̲e̲g̲e̲d̲ ̲F̲u̲n̲c̲t̲i̲o̲n̲s̲
A privileged function related to SFM is invoking
of certain commands by system user.
f) P̲r̲o̲t̲e̲c̲t̲
The above listed commands exist in conjunction
with the previously described security and access
rights. In order to protect a file it is possible
to change the access rights, the content of the
ACL, for a specified file by the command:
PROTECT
Input: File descriptor
User group id
Rights
The access rights are specified as rights to call
the following functions:
Enter
Lookup
Rename
Remove
Reset
Protect
Offer
Read bytes
Modify bytes
Append bytes
5.9.1.2.5.2 S̲e̲c̲u̲r̲i̲t̲y̲ ̲a̲n̲d̲ ̲A̲c̲c̲e̲s̲s̲ ̲C̲o̲n̲t̲r̲o̲l̲ ̲o̲n̲ ̲M̲e̲s̲s̲a̲g̲e̲s̲
a) S̲e̲c̲u̲r̲i̲t̲y̲ ̲C̲o̲n̲t̲r̲o̲l̲
MMS will impose a similar security control on items
as FMS does on files.
The security profile for a user process is included
in the attributes defined in the USERON command,
while the security profile for an item is defined
by CREATE ITEM or CHANGE ITEM ATTRIBUTES commands.
The actual security control is carried out in connection
with the OPEN MESSAGE and LOOKUP commands. If the
security control is passed, subsequent accesses
are allowed without explicitly checking security
on each request.
Security profile for an item is kept in the item
control block as long as the item resides in Short
Term Storage. When residing in Intermediate or
Long Term Storage, the security profile is part
of the item control block copy held in the item
directory for that particular storage.
Items of high classification levels may require
special attention in that they must be automatically
purged after use. This may require that all space
allocations to those items must be check-pointed
so that they can be purged as part of recovery.
Another possible mechanism would be that a background
process purges all free space in Short Term Storage
after recovery.
b) A̲c̲c̲e̲s̲s̲ ̲C̲o̲n̲t̲r̲o̲l̲
The concept of user group used in controlling access
to files is not suited for messages and items,
and will not be used by MMS.
So MMS will have no mechanism for access control
to items. It must rely on Message Monitor, as all
OPEN ITEM and LOOKUP commands must be executed
via MMON.
5.9.1.2.6 R̲e̲c̲o̲v̲e̲r̲y̲
5.9.1.2.6.1 F̲i̲l̲e̲ ̲M̲a̲n̲a̲g̲e̲m̲e̲n̲t̲ ̲S̲y̲s̲t̲e̲m̲ ̲R̲e̲c̲o̲v̲e̲r̲y̲
Permanent files can be recovered. Data appended to
a file since last UPDATE command may, however, be lost.
5.9.1.2.6.2 M̲e̲s̲s̲a̲g̲e̲ ̲M̲a̲n̲a̲g̲e̲m̲e̲n̲t̲ ̲S̲y̲s̲t̲e̲m̲ ̲R̲e̲c̲o̲v̲e̲r̲y̲
a) The recovery model for MMS is based on the following
assumptions:
1) The processing flow for a item consists of
a well defined set of successive steps, where
output from one step serves as input for one
or more succeeding steps.
2) It is possible to record in a checkpoint the
item state resulting from a step in such a
way that the item may after a system failure
be "rolled back" to the beginning of latest
step initiated before the failure.
A sufficient but not necessary condition for this to
be true is:
3) A processing step will only modify an item by appending
to one or more of its fields. In that case the
state prior to the beginning of the step may be
restored by simply resetting field lengths to their
values at the beginning of the step.
It is the responsibility of application module designers
to identify processing steps and to request MMS checkpointing
of appropriate items at appropriate points in processing
flow.
MMS contains two functions for recovery purposes:
4) SAVE, which checkpoints an item
5) RESTORE, which restores the item state from last
checkpoint
b) Check Point Actions
A checkpoint record consists of three fields:
1) ICB copy
2) ITEM block address list, which is a list of
block addresses within Short Term Storage for
the blocks constituting the item
3) User data, which is a data block supplied with
the SAVE command. It will presumably be the
MCB from Message Monitor
Check point records are of 512 bytes length. They
are saved on disk in the ICB Check Point Array
and/or sent to standby PU.
The first checkpoint of an item requires that a
free entry will be found. Subsequent checkpoints
for the same item will overwrite the previous ones,
and when the item is finally deleted from Short
Term Storage, the checkpoint entry is free.
The SAVE command has the parameters:
Input: ICB reference
User data
Note that checkpoint information only consists
of ICB and Item block address list, while the actual
item data are assumed to remain unmodified between
checkpoints, except for possible append operations.
c) R̲e̲c̲o̲v̲e̲r̲y̲ ̲A̲c̲t̲i̲o̲n̲s̲
Recovery action consists of restoring all checkpointed
items in Short Term Storage to the state of latest
checkpoint, and to delete all other information
from Short Term Storage.
Recovery action is performed after MMS initialization
when Message Monitor issues a sequence of RESTORE
commands, each of which performs the following:
1) Read next used entry in ICB CHECKPOINT ARRAY,
either from disk or from memory if collected
in standby
2) Restore ICB COPY into the ICB that it has previously
occupied
3) Restore part of CHAIN TABLE by means of ITEM
BLOCK ADDRESS LIST
4) Return USER DATA
RESTORE Parameters:
Output: User Data
Completion Code indicating, if this was last
entry
…05……01……01……01……01……01…
Figure 5.9.1.2.6.2-1…01…Checkpoint Record Layout
Figure 5.2.1.2.6.2-3…01…Item Processing Flow with 2 Checkpoints and Recovery
in between
5.9.1.3 S̲F̲M̲ ̲C̲o̲n̲t̲r̲o̲l̲
5.9.1.3.1 P̲a̲r̲a̲m̲e̲t̲e̲r̲ ̲C̲o̲n̲t̲r̲o̲l̲
SFM is controlled by parameters defining sizing values
for the following resources:
a) Available sectors on each volume
b) Use of Disk Controller Memory
c) Memory - and disk resident tables
d) Checkpoint on disk and/or standby PU
5.9.1.3.2 I̲n̲i̲t̲i̲a̲l̲i̲z̲a̲t̲i̲o̲n̲
SFM is initialized by SSC.
5.9.1.3.3 E̲r̲r̲o̲r̲ ̲H̲a̲n̲d̲l̲i̲n̲g̲
SFM has internal error handling of the following types:
a) Retry disk operation a few times
b) Replace Bad Sectors by translation table on each
volume
c) Use the good one of a mirrored disk pair
Errors that cannot be resolved internally are either
reported back to callers or sent to SSC.
5.9.1.4 C̲h̲a̲r̲a̲c̲t̲e̲r̲i̲s̲t̲i̲c̲s̲
5.9.1.4.1 F̲i̲l̲e̲ ̲M̲a̲n̲a̲g̲e̲m̲e̲n̲t̲ ̲S̲y̲s̲t̲e̲m̲ ̲C̲h̲a̲r̲a̲t̲c̲t̲e̲r̲i̲s̲t̲i̲c̲s̲
a) D̲i̲s̲k̲ ̲C̲a̲p̲a̲c̲i̲t̲y̲
The capacity of formatted disk is about 80 per
cent of the nominal disk capacity.
5.9.1.4.2 M̲e̲s̲s̲a̲g̲e̲ ̲M̲a̲n̲a̲g̲e̲m̲e̲n̲t̲ ̲S̲y̲s̲t̲e̲m̲ ̲C̲h̲a̲r̲a̲c̲t̲e̲r̲i̲s̲t̲i̲c̲s̲
5.9.1.4.2.1 M̲e̲m̲o̲r̲y̲ ̲a̲n̲d̲ ̲D̲i̲s̲k̲ ̲L̲a̲y̲o̲u̲t̲
This section lists the major memory and disk resources
used by MMS.
a) Memory Layout
1) ICB array
A pool from where ICBs are allocated
2) Chain Table
A memory area used to keep the list information
describing how blocks of Short Term Storage
are linked together into items.
3) MMS Tables
Various control information such as pointers,
etc.
b) On-line Disk Layout
1) ICB checkpoint array
Storage of checkpointed ICBs
2) Memory Save Area
Area where all memory resident information
may be stored at a System Close Down
3) Short Term Storage Area
4) Intermediate Storage Area
5) Intermediate Storage Directory
c) Long Term Storage Volume Layout
The MMS part of those volumes contains:
1) Long Term Storage area
2) Long Term Storage directory
The information areas are shown on the following
figures.
Figure 5.9.1.4.2.1-1…01…MMS Memory Layout
Figure 5.9.1.4.2.1-2…01…MMS On-Line Disk Layout
Figure 5.2.1.4.1.1-3…01…MMS Long Term Storage Volume Layout
5.9.1.4.2.2 S̲i̲z̲i̲n̲g̲ ̲E̲s̲t̲i̲m̲a̲t̲e̲
a) Memory
1) ICB: 15 words including item descriptions
2) CHAIN TABLE: 2000 words
3) MMS TABLES: 100 words
b) On-line Disk
1) ICB checkpoint area: One sector per item
2) Memory save area: 4000 words
3) Short Term Storage area: 5 M bytes
4) Intermediate Storage Directory: 1 M byte
5) Intermediate Storage area: 30 M bytes
5.9.1.5 D̲e̲s̲i̲g̲n̲ ̲a̲n̲d̲ ̲C̲o̲n̲s̲t̲r̲u̲c̲t̲i̲o̲n̲
Refer to section 2.5.
5.9.1.6 D̲o̲c̲u̲m̲e̲n̲t̲a̲t̲i̲o̲n̲
Refer to section 2.6.
5.9.2 E̲n̲v̲i̲r̲o̲n̲m̲e̲n̲t̲
5.9.2.1 S̲t̲a̲n̲d̲a̲r̲d̲ ̲H̲a̲r̲d̲w̲a̲r̲e̲,̲ ̲F̲i̲r̲m̲w̲a̲r̲e̲,̲ ̲a̲n̲d̲ ̲S̲o̲f̲t̲w̲a̲r̲e̲
SFM executes completely within active and standby PU.
It makes use of Disk Controller memory for tables and
disk cache.
5.9.2.2 E̲x̲t̲e̲r̲n̲a̲l̲ ̲I̲n̲t̲e̲r̲f̲a̲c̲e̲s̲
Not applicable.
5.9.2.3 P̲a̲c̲k̲a̲g̲e̲ ̲I̲n̲t̲e̲r̲f̲a̲c̲e̲s̲
Not applicable
