top - download
⟦f330779d5⟧ Wang Wps File
Length: 28106 (0x6dca)
Types: Wang Wps File
Notes: Damos Standard Software
Names: »0223A «
Derivation
└─⟦83a4a04d1⟧ Bits:30005815 8" Wang WCS floppy, CR 0002A
└─ ⟦this⟧ »0223A «
WangText
…00……00……00……00…-…02……00……00…-
,…08…,…0e……86…1 …02… …02… …02…
…02…CPS/MMO/004
…02…MSN/801001…02……02…#
ANSWERS TO ACTIONS,
DAMOS ADDITIONAL REQUIREMENTS CAMPS
Attached: Updated Action Item List
During the meeting 800917 between GJ and JH[ the following
new action items were identified:
45 page 8 "Data areas of a module shall be contigous"
should be reformulated to "Data areas of
a module shall be logically contigous"
46 page 12
pin 4 The mentioned memory erase feature requirement
shall be deleted.
47 page 15 The requirements to the page manager shall
be incorporated.
48 page 17 A later implementation of purge cannot
be provided.
49 page 19 The TBD in the section online reconfiguration
via THS shall be defined.
50 page 20 No SCC-driver will be supported.
51 page 27 Define where the system consol is placed.
52 page 31 Linker to Pascal and Assembler is not supported.
53 page 35
top pin 2 Delete the word "absolute"
54 page 46 SD was asked to remove "random bit-pattern"
(4.6.6)
55 page 46 para 4.8.5 please clarify.
56 page 54 ED cannot accept QA
57 page 56 Low level documentation is not supported
for support programs
58 page 68 ED cannot accept SD approval of test procedures
59 page 69 The document mentioned will not be supported
(AMOS/DAMOS Compatibility)
A̲n̲s̲w̲e̲r̲s̲ ̲t̲o̲ ̲A̲c̲t̲i̲o̲n̲s̲
Action 1: S̲o̲f̲t̲w̲a̲r̲e̲ ̲I̲n̲t̲e̲g̲r̲i̲t̲y̲ ̲R̲e̲q̲u̲i̲r̲e̲m̲e̲n̲t̲s̲
a) Re-loadable copies of all the software in binary
form shall be held on backing store (e.g. disc,
magnetic tape on-line to the system) to permit
replacement of the software if it is suspected
of being corrupt.
b) Each module should contain credibility check to
contain the effects of corrupt or inaccurate data
to the extent this does not introduce redundant
processing which will decrase the system throughput.
c) All programmes and data files loaded into the system
shall carry block parity check sums to allow the
detection of corrupted data.
d) It shall be a design aim that whereever possible
the consequence of a single software fault incident
will not affect more than one transaction. The
detection of an inconsistency indicating a fault
shall initiate a report and the re-processing from
a validated check-point in an attempt to recover
with a minimum of discontinuity. Only after further
failures should major recovery or operator intervention
action be invoked.
A transaction is defined as: "a set of data in
a data processing system which has to be processed
as an entity.
The integrity requirements as stated above will
be incorporated in CPS/SRS/001.
Action 2: Refer to the answer to action 1a)
Action 3: Device control and interrupt response are defined
in CPS/SRS/001, page 11, pin 13.
The handlers not supported by ED are developed by SD,
but will in CAMPS context be considered system software
anyway. SD therefore needs the outline/strategy/ standard
for designing of handlers used in ED, refer action
22.
Action 4: Recovery, Restart, Reconfiguration.
The problem area of this topic shall be solved in common
by SD and ED. The solution shall make it possible for
the CAMPS System to fullfil the requirements set forth
to the CAMPS System.
A draft report containing an outline for the solution
shall be issued by ED on 810101. A final report shall
be issued 810401.
Below is listed the requirements to be met by the CAMPS
System.
R̲e̲c̲o̲v̲e̲r̲y̲,̲ ̲R̲e̲s̲t̲a̲r̲t̲,̲ ̲R̲e̲c̲o̲n̲f̲i̲g̲u̲r̲a̲t̲i̲o̲n̲ ̲(̲r̲e̲f̲e̲r̲ ̲A̲c̲t̲i̲o̲n̲ ̲2̲1̲)̲
The THS system handling the TDX system is described
in action 49.
DAMOS will be allowed to use 30 seconds to a PU/IOBUS
switchover.
The DAMOS recovery shall include creation of:
- to FMS:
connection to 50 files, whereto in average
two processes are connected
- to THS (IOBUS):
10 communication lines
to THS/TDX BUS
75 communication lines (devices)
D̲i̲s̲k̲ ̲r̲e̲c̲o̲v̲e̲r̲y̲
- DAMOS shall support a dualized disk configuration:
- removal/reinsertion of disk ctr/pack
- initial and on-line selection of which 2 disks
are to constitute the dualized pair.
- Files shall have different scope
- temporary i.e. after a PU switchover or total
system error the file is lost
- permanent i.e. the file is retained in the
above mentioned situations.
- The bitmap must never be lost
- An I/O procedure shall exist which
deletes a file (F1)
renames a file (F2) to have the name F1
in one indivisible operation.
- Recovery of files/file connections is TBD
- Disk performance during recovery is TBD.
P̲U̲ ̲R̲E̲I̲N̲S̲E̲R̲T̲I̲O̲N̲
- Reinsertion of a PU is TBD.
L̲T̲U̲ ̲R̲e̲c̲o̲v̲e̲r̲y̲,̲ ̲R̲e̲s̲t̲a̲r̲t̲,̲ ̲R̲e̲c̲o̲n̲f̲i̲g̲u̲r̲a̲t̲i̲o̲n̲
It shall be possible to remove/reinsert new LTU's and
attached devices.
Recovery/restart of LTU's in case of PU/IOBUS switchover
is TBD.
S̲o̲f̲t̲w̲a̲r̲e̲ ̲R̲e̲c̲o̲n̲f̲i̲g̲u̲r̲a̲t̲i̲o̲n̲
TBD
Action 5 By scratch space is meant all data areas occupied by
the process and which upon termination of the process
is deallocated and returned to some part of the system,
e.g. memory returned to the memory manager, buffers
returned to the buffer pool in the kernel.
This requirement will be incorporated in CPS/SRS/001.
Action 6 Erasure shall be performed at the time of decollation.
Action 7 Facilities as implemented by TOS are sufficient. It
is, however, a requirement that commands for modifying
the environment of devices and volumes are available
only from the operators console (OC) (refer CSS/380/OSM/0026,
page 5). By no means it may be possible from a user
terminal to gain control or access to any part of the
system not specified from the operators console; especially
access or disturbance to the active computer shall
be avoided.
Action 8 This requirement will be withdrawn. CPS/SRS/001, page
10, pin 5, will be deleted.
Action 9 CPS/SRS/001, page 14, pin 6, will be reformulated as
follows:
"A clean architectural design; unassign codes must
cause a trap."
Action 10 CPS/SRS/001, page 11, pin 10, will be deleted.
Action 11 CPS/SRS/001, page 11, pin 11, will be deleted.
Action 12 P̲r̲o̲c̲e̲s̲s̲ ̲C̲o̲m̲m̲u̲n̲i̲c̲a̲t̲i̲o̲n̲
It shall be possible for processes to share a data
area. For the synchronization of the access to such
data areas a
- counter semaphore
shall be supported. (counter semaphores correspond
to the PARENT SIGNAL as defined for AMOS. Shall be
available for all processes in DAMOS.
Synchronization elements as covered in reference 2.1,
section 3.6.3. Besides the functions described in reference
2.1 section 3.6.3.3.1-3 the function change ̲synch ̲el(SIP,
changeagble-attributes) shall be supported
Action 13 Changeable attributes for objects shall be accessrights
and security profile.
Action 14 We await input from ED.
Action 15 Sizing estimate reports for system software shall
be delivered by ED at least together with the following
deliverable items:
- Preliminary design document
- Detailed design document
Further report shall be delivered immediately if significant
deviations from the latest sizing estimate report is
discovered by ED.
This requirement will be incorporated in CPS/SRS/001
Action 16 S̲e̲c̲u̲r̲i̲t̲y̲ ̲R̲e̲q̲u̲i̲r̲e̲m̲e̲n̲t̲s̲ ̲t̲o̲ ̲D̲a̲t̲a̲t̲r̲a̲n̲s̲f̲e̲r̲s̲
The requirements addresses the need for redundant security
checks in order to detect flows in the basic security
system and as far as possible limit their consequenses.
It arose at a time where it was not clear if CAMPS
could afford a process for each terminal. In a multiterminal
process it would have aided the application programmer
in specifying explicitly the security controls to be
reinforced.
The suggested checking feature is the following:
Each time a process requests an input operation,
it supplies to the I/O system the classification
level of the intended output destination for the
data. If this classification is lower than that
of the input source, the transfer should be rejected.
Each time a process requests an output operation,
it supplies to the I/O system the classification
level of the data. If this classification is higher
than that of the destination, the transfer should
be rejected.
Note again that this feature is not expected to give
any absolute security control. But it is expected to
contribute to security in systems like CAMPS by decreasing
the probability of security violations caused by software
faults.
Action 17 S̲e̲c̲u̲r̲i̲t̲y̲ ̲C̲o̲n̲t̲r̲o̲l̲ ̲i̲n̲ ̲T̲D̲X̲ ̲D̲r̲i̲v̲e̲r̲
This is an ED action, here is the input from SD.
The problem seems to be that there is no system wide
knowledge of the ultimate terminal equipment that can
be connected via the TDX bus. This is opposed to the
situation with disc files, where user accessible entities
are specified in a 3 level system of volume, directory,
file and each of those types of entities are subject
to security controls.
The corresponding hierarchy for TDX system may in general
have at least 4 identifiable levels:
1. TDX BUS level
2. TDX DEVICE level, eg. LTUX
3. TDX SUBDEVICE level, eg. a communication line.
Each LTUX may support a number of lines.
4. TERMINAL level.
Each communication line may connect a number
of physical terminals. Examples are polled
terminals such as IBM 3270, and X.25 terminals
accessed via X25 level 3 virtual circuits.
In the CAMPS system, there is only one terminal per
communication line on LTUX.
In order to establish security control on the terminals
and the other TDX entities, the TDX driver must establish
and maintain a directory of information about the TDX
configuration. The following requirements must be fulfilled:
- Subjects can access an entity by symbolic name
only.
- The access path (eg. TDX bus, device number, subdevice
number, terminal poll code) may only be known by
TDX driver as opposed to the current situation
where this information is supplied by the process
in create-log-line.
- The TDX directory must initially be prepared at
system generation time, and can be maintained by
authorized users in a way similar to that used
for disc directories.
- The operations on the TDX directory should include
for each entity type:
- change access rights for an entity
- create/delete an entity; creation includes
information about access path.
- switch over of parts of the TDX network
The TDX is only a special case of a more general need
to have an unified security control system for all
peripheral devices (user interface points) connected
to the system. It is not a satisfactory situation that
each device driver/file management system implements
its own way to control security. The above mentioned
TDX directory should actually be a system wide directory
describing all peripheral devices and subfiles with
associated access path on those devices.This would
allow a centralized and unified security control system
covering all identifiable system resources.
The requirement as stated above will be incorporated
in section 8 CPS/SRS/001.
Action 18 Floppy disk controller is
CR80 47D/010AB/00
Drive is SA800 single side single density
will be incorporated in CPS/SRS/001
Action 19 F̲i̲l̲e̲ ̲S̲y̲s̲t̲e̲m̲ ̲S̲e̲c̲u̲r̲i̲t̲y̲
There is a general concern about the security aspects
of the current file system compared to that of the
proposal where the file system was hidden in its own
computer with only a DMA link to the application system.
It seemed much more obvious that the former solution
did not permit any unauthorized interactions with the
file system. Moreover the file system seemed to be
much more protected against operational mistakes because
it did not need to be bootstrapped together with the
application system. For those reasons a number of safeguards
have been suggested, but SD needs an evaluation of
the security aspects of the current file system compared
to the former one.
Furthermore security marking on sector level was promised
in the CAMPS proposal
Action 20 refer the answer to action 39 and action 40.
Replace "TBD" by "Refer section 8, page 52, for description".
The reference will be incorporated in the CPS/SRS/001.
Action 21 refer to the answer of action 4
Action 22 Refer Minutes of meeting CPS/MIN/001 of the meeting
800811. Page 4 at bottom together with action 22.
Standard Handler Interface.
1. One Handler program code will exist per device/line
type.
2. A data area shall exist per physical device/line
containing status information and work data exclusive
for the device.
3. One incarnation of the Handler (e.g. VDU handler)
shall exist per device controlling the data area
in 2. This incarnation shall gain control on every
transfer for the device to/from the LTU/LTUX of
the device. The incarnation shall have full access
to the transferred data and may modify transfer
lists to incorporate or exclude information from/to
the device.
4. A group of handlers shall be able to share common
tables and work data.
5. The Standard Handler interface shall be identical
for LTU and LTUX connected devices.
Action 23 Error handling
Discussion/meeting took place 1980-09-30
Action 24 Secure
The word secure refers to the items listed below and
to the requirements in CPS/SRS/001, i.e. does not imply
anything new not exactly required in the specifications.
1) All programmes and data files loaded into the system
shall carry block parity check sums to allow the
detection of corrupted data.
2) Access to CAMPS data files shall be made through
system calls which pass through the authorisation
mechanism.
3) Recovery procedures after system failure shall
include checksumming of the operating system software,
reloading if this is necessary.
4) Facilities shall exist to cause a system integrity
check (i.e. checksumming of system software) to
be performed at any time it is seem fit. This shall
be done without disrupting the functioning of the
system.
5) To the extent possible, the operating system shall
run in the non-privileged user state
Action 25 Section 4.2.1 will be reformulated to require the
current version of the Pascal Compiler.
Action 26: Deleted by the answer to action 25.
Action 27 A "pretty printing facility for SWELL is wanted".
Para 4.3.4: "A pretty printing facility for formatting
a SWELL source text into a standard format with
indentations reflecting statement-nesting shall
be supported" will be incorporated in CPS/SRS/001.
Action 28 L̲I̲B̲R̲A̲R̲I̲A̲N̲
The librarian organizes all information pertinent to
systems development and as such it covers the areas
of program development, systems generation and documentation.
It acts as an umbrella over the following development
utilities:
Editor,
Assembler,
Swell compiler,
Pascal compiler,
Linker,
Systems generator,
directing and recording their activities.
1. P̲r̲o̲g̲r̲a̲m̲s̲
- Allow two levels of issue numbering and a version
number within latest issue. Attach date of
latest change
- Recognize the various disguises of the program
as source module, link module, loadable module.
2. S̲y̲s̲t̲e̲m̲s̲
Systems are built up of programs, and the librarian
must include tools to describe how systems are
structured and which programs in which versions
they consist of. The description should be hierarchical
and allow a number of levels such as SYSTEM, SUBSYSTEM,
PACKAGE, MODULE. This description should direct
systems generation. Systems should have a two level
version number.
3. I̲n̲s̲t̲a̲l̲l̲a̲t̲i̲o̲n̲s̲
Installations run systems. The librarian must include
tools to describe the history of each installation
in terms of the systems running at the installation.
A patch history record for each installation may
be needed too.
4. D̲o̲c̲u̲m̲e̲n̲t̲s̲
Documentation key with reference to the systems
covered by the document and a description of document
state.
5. T̲e̲s̲t̲ ̲D̲a̲t̲a̲ ̲S̲e̲t̲s̲
Data sets to be used for mandatory tests of new
versions of programs and systems. Each data set
must contain a reference to the system which will
use the set.
6. U̲s̲e̲r̲s̲ ̲a̲n̲d̲ ̲g̲r̲o̲u̲p̲s̲
Program versions should be organized in a way reflecting
the way of organizing development groups. A program
could exist in three versions: PUBLIC, TEAM, USER.
When the developer refers to one of his own programs,
he gets the USER version, while another member
of the team would get the TEAM version, and a systems
generator would set the PUBLIC version. This organization
facilitates cooperative work with programs in various
stages of development and test. A user should have
capability to lift his program to TEAM, while a
team leader may lift TEAM programs to PUBLIC.
The above mentioned information should as far as
possible be used by system development tools for
checking purposes, and the tools should automatically
generate updates to this information.
Tools must exist to extract the information and
print it out in various formats.
7. C̲r̲o̲s̲s̲ ̲R̲e̲f̲e̲r̲e̲n̲c̲e̲ ̲T̲o̲o̲l̲
Given a Program Name and a version identification
(either a specific version or all versions) together
with a set of systems/installations the cross reference
tool shall identify all programs/systems/installation
wherefrom the program is called/wherein the program
is incorporated. The librarian shall contain sufficient
pertinent information that the information for
one program can be obtained within 1 minute elapsed
time in a single CPU, single disk development configuration.
Action 29 S̲t̲a̲t̲e̲ ̲r̲e̲q̲u̲i̲r̲e̲m̲e̲n̲t̲s̲ ̲f̲o̲r̲ ̲t̲h̲e̲ ̲o̲n̲-̲l̲i̲n̲e̲ ̲t̲e̲s̲t̲ ̲p̲r̲o̲g̲r̲a̲m̲s̲
Refer to CAMPS ADD.REQ's section 4.7.1
For a more specific definition of some of the text
programs refer to:
CRX APPENDIX 3 CR80D S̲T̲A̲N̲D̲A̲R̲D̲ SOFTWARE, section
3.1 and section 1.13.
CPS/TCN/0012 requirements for error handling contain
a description of the overall error detection strategy.
Action 30 C̲l̲a̲r̲i̲f̲y̲ ̲I̲n̲t̲e̲g̲r̲i̲t̲y̲ ̲o̲f̲ ̲O̲p̲e̲r̲a̲t̲i̲o̲n̲
Refer to CPS/TCN/0013 (Mapping of performance requirements
to subsystems) section 3.4. The 10…0e…7…0f… messages/transactions
correspond closely to 60 days operational use of a
CAMPS site.
Action 31 W̲h̲i̲c̲h̲ ̲O̲f̲f̲-̲L̲i̲n̲e̲ ̲T̲e̲s̲t̲ ̲P̲r̲o̲g̲r̲a̲m̲s̲
The off-line software package shall at least contain
programs for test of the following hardware modules:
- CPU + CACHE
- Memory Map
- RAM
- PROM
- Processor Bus
- Channel Bus
- CIA/MIA/TIA
- TDX CTR
- TDX BUS
- LTUX's
- BTMX
- MUX/DEMUX OPTO TR/REC
- Statistical Multiplexer
- Crypto Equipment
- Modem
- I/O BUS
- LTU
- LIA
- DISK CTR
- DCA
- Disk Pack
- PTP
- LP
- Terminal
- Floppy Disk
- Watchdog
- Power Supply (Power interrupt)
For a more specific definition of some of the test
programs refer to:
CRX APPENDIX 3 CR80D STANDARD Software section 3.2
Action 33 Swell compiler and linker should perform not worse
than the present version under AMOS (80-10-01)
in a similar hardware configuration. The editor
shall respond to edit requests (i.e. be ready for
character and line edit) within not more than 10
seconds for source texts of less than 300 lines
in a configuration with one CPU and one CDC SM9
disk drive. Whenever editing is terminated, the
source text shall be updated within another 10
seconds.
Action 34 The requirement in CPS/SRS/001 para 11 concerning
ED test procedures and test data subject to approval
by SD will not be deleted.
Action 35 Delivery Schedule.
Refer contract.
Action 36 Delete "a terminal at the IOBUS" on page 51
Action 37 This section should read: "A process of security
classification equal to or above the classification
of a file shall be able to read or write from/to
the file if the read/write protection so allows.
Action 38 Purging shall take place at the time of deallocation.
Action 39/
40 Each unit shall internally hold a record for containing
a unit identity number and date and time. Inscribing
the unit identity number shall not affect any other
information stored on the unit.
When an unit has been mounted the I/O system shall
either automatically or upon request deliver the unit
identity number, date and time. It shall be impossible
to record on an unit which contains no unit identity
number or an unassigned number but retrieval from such
an unit shall, however, be possible.
It shall be possible to request via the I/O system
an overwrite of the data areas on an unit with a pattern
appropriate to the nature of the device which shall
wipe out previously recorded data and access information.
For the reformulation of page 53:
The requirement is covered in CPS/SRS/001, page 17,
last section and page 18, first section.
Action 41 Subcontract Management Plan.
Refer contract
The para will be deleted, but is part of the contract.
Action 44 We await input from ED. SD has the following requirements:
M̲o̲n̲i̲t̲o̲r̲ ̲P̲r̲o̲c̲e̲d̲u̲r̲e̲s̲
The additional requirements document will be updated
to include monitor procedures as follows:
"M̲o̲n̲i̲t̲o̲r̲ ̲P̲r̲o̲c̲e̲d̲u̲r̲e̲s̲
It shall be possible to extend DAMOS with monitor procedures.
They shall be known to all programs either by inclusion
at system generation or similar to INIMON of AMOS.
The monitor procedures shall be used to share data
areas between processes of different classification
as follows: all processes sharing one or several memory
pages by means of a monitor procedure shall have the
data area mapped-in despite their security classification.
Not to break DAMOS security philosophies the shared
data area shall be fully protected (only accessible
in system mode). Further, in order to be able to administrate
the shared data area a such monitor procedure must
have access to the calling process' security class
and indicator whether trusted or not. For the case
of violation access must be provided to a "kill" function"
Action 45 The requirement is: Data areas of a module shall
be l̲o̲g̲i̲c̲a̲l̲l̲y̲ contigous.......
The CPS/SRS/001 will be updated accordingly.
Action 46 The requirement will be reformulated to:
"A read/write memory erase function shall be provided.
HW/SW techniques must be available to accomplish
this function".
This is a requirement from our customer.
Action 47 The requirements to the page manager is as stated
overleaf and will be incorporated in CPS/SRS/001
3̲.̲2̲.̲5̲ ̲P̲a̲g̲e̲ ̲M̲a̲n̲a̲g̲e̲r̲
Security related requirements are stated in section
8, Program Page Management.
Translation Tables:
Page management should be optimized towards a situation
where many processes share the same relatively small
resident program thus having the same static address
translation table for the program part. For CAMPS there
would typically be 50-100 terminal processes working
with the same program translation table.
Each terminal process would have, say 2 data pages
for user data. So in CAMPS most of the processes would
have address translation tables of less than 20 entries.
So quite much memory space could be saved by a mechanism
not requiring 128 words of memory per process for translation
tables. This might affect context switch too in decreasing
the frequency of changes to the map.
Program Sharing:
A parent operating system must have the capability
to create program segments and make them accessible
to a group of its children without the children being
accounted for the use. Such shared program segments
must still be subject to the normal access control
so that only the children specified can access the
segments.
Demand Paying:
The algorithm for selection of a victim when page fault
occurs may be a simple one such as first in-first out
with the additional capability to lock segments in
memory.
A parent must have the capability of defining the maximum
number of memory pages that a child may allocate.
Demand paging must work for PASCAL programs too, and
procedures LOCK (procedure name), UNLOCK (procedure-name)
should be provided.
Action 48 Replace in text on page 17, 5th subsection:
"The FMS shall perform overwriting of data buffers
having been used for data of higher classification
than CLASS, CLASS to be specified at system generation.
The overwriting shall be performed immediately
after use of the buffer. The use of disk cache
for such data buffers is not allowed. (For the
general requirement see section 8)"
Action 49 O̲n̲-̲l̲i̲n̲e̲ ̲r̲e̲c̲o̲n̲f̲i̲g̲u̲r̲a̲t̲i̲o̲n̲ ̲v̲i̲a̲ ̲T̲H̲S̲
Additional req.:
"The FMS shall access terminals in such a way,
that on-line reconfiguration is supported in a
manner TBD"
It shall be possible to switch to a standby TDX BUS
from the current active PU, so that it is transparent
to the application.
It shall be possible to reinsert a failed TDX BUS/CTR.
It shall be possible to remove/reinstall LUTX's/terminals.
- It is to be considered, if LTUX's shall be referenced
by name, thereby enabling name to physical LTUX
relation to be set dynamically without terminal
intervention.
- DAMOS shall for LTUX/terminal resources (and the
like) contain tables defining the current and the
maximum configuration
Requirements to recovery/restart of the TDX system
in case of a PU switchover is TBD.
For TBD's refer to section 4.
Action 50 S̲S̲C̲ ̲D̲R̲I̲V̲E̲R̲
A SSC driver shall be available.
Action 51 The SS&C driver shall for support and diagnostic
software look as if it is a standard console driver.
Action 52 The requirements for a Pascal linker and an assembler
linker will be deleted in CPS/SRS/001
Action 53 Page 35: 2- Change wording to: "Listing and changing
the content of program and base memory for the
program/process under debugging plus listing of
base memory of min.2 other processes specified
at debug start"
In section 8a general requirement to overwrite RAM
memory and to purge disk memory will be stated.
Action 54 page 42. Replace "storage" by "disk storage" and
replace "i.e." to "pattern be " see. section 8"
Action 55 4.8.5 will be updated as follows:
4.8.5 T̲e̲s̲t̲ ̲D̲r̲i̲v̲e̲ ̲P̲r̲o̲g̲r̲a̲m̲
In order to be able to support test drive programs
DAMOS shall allow read and write of process-relative
data areas, as well as read (and write) of sync-element
data areas and other common data areas by a separate
test drive process created by the application programmer.
Fig. 4.8.5 illustrates the approach. It implies a requirement
for listing of sync-element content without awaiting
them and it implies that a test process may MAP-in
the entire data-area of the process under test plus
shared data areas (i.e. a requirement to TDS).
Furthermore, it could be considered to make debugger
commands available as calls from a test drive program
in order to automatize tests.
This facility would allow an automatized test of branches
in the program under test, which may only be reached
in special error situation. For this purpose the input-output
communication of the debugger should be taken-over
by the test process in such a way that the debugger
allows the test process to await the process under
test being in the next breakpoint.
Fig. 4.8.5
TEST DRIVE PROGRAM
Action 56 QA
The requirement in CPS/SRS/001 cannot be changed. Para
will be deleted, but is included in contract.
Action 57 Low level documentation
Low level documentation is required as stated.
Action 58 Refer action 34
Action 59 AMOS/DAMOS compatibility.
The document(s) as described must be supported by ED.
