top - download
⟦0f6032288⟧ Wang Wps File
Length: 83400 (0x145c8)
Types: Wang Wps File
Notes: DAMOS
Names: »0106A «
Derivation
└─⟦2c0571bd0⟧ Bits:30005816 8" Wang WCS floppy, CR 0005A
└─ ⟦this⟧ »0106A «
WangText
7…0b…7 6…0e…6…07…5…0b…5…0c…5…0e…5…06…4…0d…4 3…0b…3…0f…3 2…09…2…0e…2
1…0a…0…0a…0…00…0…05…/…0b…/…01…/…06….…0b….…0c….…0d….…0e……86…1
…02…
…02… …02…
…02…CPS/SRS/001
…02…810811…02……02…#
CAMPS
ADDITIONAL
REQUIREMENTS
TO
DAMOS
STANDARD
SOFTWARE…02…801010…02…CAMPS
T̲A̲B̲L̲E̲ ̲O̲F̲ ̲C̲O̲N̲T̲E̲N̲T̲S̲
1 SCOPE ........................................
8
2 APPLICABLE DOCUMENTS .........................
9
2.1 DAMOS SYSTEM REQUIREMENT SPECIFICATION ...
9
2.2 PROPOSAL FOR DIGITAL EXCHANGE APPENDIX 3,
CR80D STANDARD SOFTWARE ..................
9
2.3 REQUIREMENTS FOR ERRORHANDLING, DOC.NO.
CPS/TCN/0012 .............................
9
2.4 MAPPING OF PERFORMANCE REQUIREMENTS TO
SUBSYSTEMS, DOC.NO. CPS/TCN/0013 .........
9
2.5 DAMOS PROCESS MANAGEMENT AND DISPATCHER,
PRELIMINARY CSS/2000/PSP/0018 ............
9
3 SYSTEM STANDARD SOFTWARE ...................
10
3.1 OPERATING SYSTEM .........................
11
3.2 DAMOS KERNEL .............................
14
3.2.1 Process Management ...................
14
3.2.2 Interrupt Functions ..................
14
3.2.3 Process Communication ................
15
3.2.4 Process Scheduling ...................
15
3.2.5 Page Manager .........................
15
3.2.6 Monitor Procedures ...................
17
3.2.7 Write Access Check by System
Procedures ...........................
17
3.3 I/O ......................................
18
3.3.1 I/O System ...........................
18
3.3.2 File Management Systems ..............
19
3.3.2.1 Backing Storage Management .......
19
3.3.2.2 Terminal Handling ................
21
3.3.2.3 OFFER-ACCEPT .....................
22
3.3.2.4 Useron - Useroff .................
22
3.3.3 Device Handlers ......................
23
3.3.4 Device Drivers .......................
24
3.3.5 Supplementary requirements derived
from I/O requirement .................
24
3.3.6 Message Handling .....................
24
3.4 ERROR HANDLING ...........................
24
3.4.1 Error Fix Up .........................
25
3.4.2 Standard Erroractions Supplied by
DAMOS ................................
26
3.4.2.1 General Reporting Mechanism ......
26
3.4.2.1.1 Reporting at the Different
Levels .......................
30
3.4.2.2 Hardware Errors ................
30
3.4.2.2.1 Single Terminal Error ......
30
3.4.2.2.1.1 Detected During User
Operation ..............
30
3.4.2.2.1.2 Detected During COPSY
Operation on a System
Connection .............
31
3.4.2.2.2 LTU/LTUX Error ...............
31
3.4.2.2.2.1 Detected During User
Operation ................
31
3.4.2.2.2 Detected During COPSY
Operation ....................
31
3.4.2.2.3 Channel (LTU/LTUX) Error .....
32
3.4.2.2.4 BSM-X Error ..................
32
3.4.2.2.5 TDX BUS (TDX CTR, TDX BUS,
TIAs) Error ..................
32
3.4.2.2.6 PU (Includes STI and IOBUS)
Error ........................
32
3.4.2.2.7 Error Interrupts .............
33
3.4.2.2.7.1 During Retire ............
33
3.4.2.2.7.2 During PU Shut-Down ......
33
3.4.2.2.8 On-Line Diagnostics Reporting
33
3.4.2.2.9 Mirrored Disks (Disk CTA,
Disk Drive, UDLUME) Errors ...
34
3.4.2.2.9.1 Error in a Single Disk ...
34
3.4.2.2.9.2 Error in Both Disks ......
34
3.4.2.2.10 Single Disk Error ..........
34
3.4.2.3 Software Errors ..................
34
3.4.2.3.1 Security Violation ...........
34
3.4.2.3.2 Non Security Violation .......
34
3.4.3 Device Driver/Handler Errorhandling ..
35
3.4.4 Error Information ....................
35
3.4.4.1 Error Report Information .........
35
3.4.4.1.1 HW Error Reports .............
35
3.4.4.1.2 SW Error Reports .............
36
3.4.4.2 Dump of Failed Process ...........
36
3.4.5 Memory Dump ..........................
36
3.4.6 Post Memory Analysis .................
36
3.4.7 Resume ...............................
36
3.4.8 Handling of HW Generated Error
Interrupts (page 3 in IM No. 79) .....
37
3.4.9 Device Driver/Handler Error Handling .
37
3.5 RECOVERY, RESTART, RECONFIGURATION .......
37
3.5.1 PU/IOBUS Switchover ..................
38
3.5.2 Disk Recovery, Reconfiguration,
Restart ..............................
38
3.5.3 THS (IOBUS) Recovery, Reconfiguration
Restart ..............................
41
3.5.4 Software Reconfiguration .............
41
3.5.5 THS (TDX BUS) Recovery, Reconfigura-
tion, Restart ........................
41
4 SYSTEM SUPPORT SOFTWARE ......................
43
4.1 HIGH LEVEL OPERATING SYSTEM ..............
43
4.2 LANGUAGE PROCESSORS ......................
44
4.2.1 Pascal Compiler ......................
44
4.2.2 Swell Compiler .......................
44
4.2.3 Assembler ............................
45
4.3 TEXT PROCESSORS ..........................
45
4.3.1 Editor ...............................
45
4.3.2 Text Formatting Program ..............
45
4.3.3 File Merge Program ...................
46
4.3.4 Pretty Printing Facility .............
46
4.4 PROGRAM DEVELOPMENT AND TEST TOOLS .......
46
4.4.1 Linker ...............................
46
4.4.2 Pascal Cross Reference ...............
47
4.4.3 Swell Cross Reference ................
47
4.4.4 Assembler Cross Reference ............
48
4.4.6 Swell Debugger .......................
48
4.4.7 Assembly Debugger ....................
49
4.4.8 Patch Program ........................
50
4.4.9 Generation of Test Output for Pascal
Programs .............................
50
4.4.10 Generation of Test Output for Swell
Programs .............................
50
4.4.11 Generation of Test Output for Assembly
Programs .............................
50
4.4.12 Change Affect Tool ...................
50
4.4.13 Librarian ............................
51
4.4.14 System Generator .....................
53
4.5 FILE MANIPULATION PROGRAMS ...............
53
4.5.1 Binhex ...............................
53
4.5.2 Compare ..............................
53
4.5.3 Copy .................................
53
4.5.4 Hexbin ...............................
53
4.5.5 Listf ................................
54
4.5.6 Print ................................
54
4.6 DIRECTORY MAINTENANCE UTILITIES ..........
54
4.6.1 Attr .................................
54
4.6.2 Create ...............................
54
4.6.3 Enter ................................
55
4.6.4 List .................................
55
4.6.5 Protect ..............................
55
4.6.6 Remove ...............................
55
4.6.7 Rename ...............................
55
4.6.8 Dcopy ................................
56
4.7 DIAGNOSTIC PROGRAMS ......................
56
4.7.1 On-line Diagnostic Programs ..........
56
4.7.1.1 Integrity of Operation ...........
57
4.7.1.2 Availability .....................
57
4.7.1.3 On-line Test Programs ............
57
4.7.1.4 System Integrity Test Programs ...
58
4.7.2 Off-line Diagnostic Programs .........
58
4.7.2.1 Off-line Testprograms ............
58
4.8 MISCELLANEOUS PROGRAMS ...................
59
4.8.1 Formatting of Disk ...................
59
4.8.2 File Conversion ......................
59
4.8.3 System TimE Setting ..................
59
4.8.4 Time .................................
60
4.8.5 Test Drive Program ...................
60
5 PERFORMANCE ..................................
62
5.1 SIZING ...................................
62
5.2 TIMING ...................................
62
5.3 STARTUP AND SWITCHOVER PERFORMANCE
REQUIREMENTS .............................
62
5.4 ON-LINE DIAGNOSTIC SOFTWARE ..............
62
6 AVAILABILITY AND MAINTAINABILITY .............
63
6.1 AVAILABILITY .............................
63
6.2 MAINTAINABILITY ..........................
63
7 INITIALIZATION ...............................
63
8 SECURITY .....................................
64
8.1 SECURITY POLICY ..........................
66
8.2 COMPARTMENTS .............................
66
8.3 TERMINALS AND COMMUNICATION LINES ........
66
8.4 TDX DEVICES ..............................
67
8.5 CENTRALIZED ACCESS CONTROL ...............
68
8.6 SCHEDULING ...............................
68
8.7 SYSTEM SOFTWARE STRUCTURE ................
68
8.8 PROGRAM PAGE MANAGEMENT ..................
69
8.9 ON-LINE TEST PROGRAMS ....................
70
8.10 DATA SECURITY ............................
70
9 QUALITY ASSURANCE ............................
72
10 SOFTWARE DOCUMENTATION .......................
72
11 CR80D SOFTWARE VERIFICATION ..................
72
12 COMPATIBILITY WITH AMOS AND CR80D STANDARD
SOFTWARE .....................................
72
1̲ ̲ ̲S̲C̲O̲P̲E̲
This document contains additional requirements to the
CR80D advanced multiprogramming operating system (DAMOS)
set forth by the System Division (CRA).
2̲ ̲ ̲A̲P̲P̲L̲I̲C̲A̲B̲L̲E̲ ̲D̲O̲C̲U̲M̲E̲N̲T̲S̲
2.1 D̲A̲M̲O̲S̲ ̲S̲Y̲S̲T̲E̲M̲ ̲R̲E̲Q̲U̲I̲R̲E̲M̲E̲N̲T̲ ̲S̲P̲E̲C̲I̲F̲I̲C̲A̲T̲I̲O̲N̲ ̲C̲S̲S̲/̲0̲0̲6̲/̲S̲P̲C̲/̲0̲0̲0̲1̲
2.2 P̲R̲O̲P̲O̲S̲A̲L̲ ̲F̲O̲R̲ ̲D̲I̲G̲I̲T̲A̲L̲ ̲E̲X̲C̲H̲A̲N̲G̲E̲ ̲A̲P̲P̲E̲N̲D̲I̲X̲ ̲3̲,̲ ̲C̲R̲8̲0̲D̲ ̲S̲T̲A̲N̲D̲A̲R̲D̲
̲S̲O̲F̲T̲W̲A̲R̲E̲
2.3 R̲E̲Q̲U̲I̲R̲E̲M̲E̲N̲T̲S̲ ̲F̲O̲R̲ ̲E̲R̲R̲O̲R̲H̲A̲N̲D̲L̲I̲N̲G̲,̲ ̲D̲O̲C̲.̲N̲O̲ ̲C̲P̲S̲/̲T̲C̲N̲/̲0̲0̲1̲2̲
2.4 M̲A̲P̲P̲I̲N̲G̲ ̲O̲F̲ ̲P̲E̲R̲F̲O̲R̲M̲A̲N̲C̲E̲ ̲R̲E̲Q̲U̲I̲R̲E̲M̲E̲N̲T̲S̲ ̲T̲O̲ ̲S̲U̲B̲S̲Y̲S̲T̲E̲M̲S̲,̲
̲D̲O̲C̲.̲N̲O̲ ̲C̲P̲S̲/̲T̲C̲N̲/̲0̲0̲1̲3̲
2.5 D̲A̲M̲O̲S̲ ̲P̲R̲O̲C̲E̲S̲S̲ ̲M̲A̲N̲A̲G̲E̲M̲E̲N̲T̲ ̲A̲N̲D̲ ̲D̲I̲S̲P̲A̲T̲C̲H̲E̲R̲,̲ ̲P̲R̲E̲L̲I̲M̲I̲N̲A̲R̲Y̲
̲C̲S̲S̲/̲2̲0̲0̲0̲/̲P̲S̲P̲/̲0̲0̲1̲8̲
3̲ ̲ ̲S̲Y̲S̲T̲E̲M̲ ̲S̲T̲A̲N̲D̲A̲R̲D̲ ̲S̲O̲F̲T̲W̲A̲R̲E̲
a) Fundamental properties of the Standard Software
which shall be considered in depth during the design,
development and production are its quality, integrity
and flexibility.
b) The Software shall be structured in a clearly identifiable
hierarchical way. The design shall maintain maximum
isolation and independence between units of all
types during program design and implementation
and during on-line operation of the system.
c) The Software shall be carefully documented in parallel
to the design during the production phase. The
documentation shall form part of each deliverable
software package and conform to the documentation
standard specified elsewhere in this document.
d) In the construction of program code, clarity of
meaning shall be a major consideration. When writing
the program code comments shall be inserted to
aid comprehension and improve the readability.
e) It is mandatory that instructions and constants
of the system standard software shall not be modified
during runtime. Within each software module/program
the program code and constants shall be segregated
from the modifiable data. The data areas of a module
shall be contigous and all exchange of data between
different modules shall take place either through
well-defined shared data areas or by value passing.
f) The System Standard Software shall be implemented
as a well structured suite of code and data modules
incorporating sufficient hardware protection and
software checking to ensure that the System Software
itself can achieve and maintain the status of high
integrity, trusted code with respect to the Applications
Software. Preferably the System Software shall
reside in read-only memory.
g) Sufficient validity checks must be applied at appropriate
points in the System Software/Applications Software
at Compile time and/or run time to ensure that
the integrity requirements (refer section 8) will
be met, attention however, being paid to maintaining
efficiency.
h) Recovery procedures after system failure shall
include the validation of the integrity, i.e checksumming
of software, of the operating system software and
security protection facilities and reloading if
this is necessary.
i) It shall be possible to cause a system integrity
check, i.e. checksumming of software, to be performed
at any time. This shall be done without disrupting
the functioning of the system.
j) The System Standard Software shall further be designed
and implemented in such a way that it is easy to
expand, modify, and maintain.
The System Standard Software shall be provided
as a complete wellstructured system consisting
of two sub-systems.
1) Operating System
2) Support Software
k) All the described software shall be able to run
on the CAMPS hardware configuration with CPU/CACHE,
MAP and TDX system.
Additional Requirements to the DAMOS Operating
System are detailed in chapter 3, whereas Requirements
to the Support Software are specified in chapter
4.
3.1 O̲P̲E̲R̲A̲T̲I̲N̲G̲ ̲S̲Y̲S̲T̲E̲M̲
a) The Operating System shall provide a complete coherent
interface for the applications programs against
the hardware.
b) The Operating System shall include the following
general facilities:
1) Multiprogramming and scheduling at run-time
2) Storage Management
3) Device Control and interrupt response
4) Inter-process interfaces
5) Error handling
6) Deleted
7) Deleted
7) File Management System
8) I/O System
c) In particular the following operating system features
are considered important:
1) The Operating System (OS) alone must be allowed
to run in the privileged mode (only when necessary)
and it must be impossible for an application
program to seize control of the OS or to read
data from the space assigned to the OS.
2) The OS must ensure that program and scratch
space is erased following a job cessation for
either normal or abnormal reasons. 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
bufferpool in the kernel.
3) A clean architectural design; unassigned codes
must cause a trap.
4) Memory bound (page management) mechanisms so
the core storage allocated to one user can
be partitioned so the user cannot read or write
in core occupied by the operating system or
by other users. These bounds must also apply
to all user initiated I/O commands.
5) Two classes of instructions, one for the exclusive
use of the operating system and one for use
by both operating system and application programs.
6) A set of key instructions exclusively reserved
for the operating system. These instructions
must control all I/O, the setting of map registers,
the setting of the system state - privileged
or problem.
7) To the extent possible, the operating system
shall run in the non-privileged processor state.
8) Device control and interrupt response, i.e.
standardized interfaces between hardware devices
(including traffic channels) and applications
software, such that the system software is
wholly responsible for the immediate control
of hardware device interfaces.
d) The following features shall be provided as part
of the hardware of the processing system.
1) Sensitive instructions which could divert,
disrupt or inadvertently change the state shall
not be available for execution unless the processor
is in a "privileged" state.
2) A protection mechanism shall be provided which
shall prevent memory areas from being inadvertently
or illegally overwritten. Any attempt or illegal
access shall (if possible) give raise to a
warning through the erorr reporting facility.
3- Every instruction code shall result in a prescribed
action. The occurrence and/or attempted execution
of any illegal code or bit-pattern shall be
signalled via the error reporting facility
and shall result in an interrupt and abort
procedure or a recovery procedure.
4) A read/write memory erase function at restart
shall be provided. The function shall be optional
at bootload time. Performance shall be at
most 2 microsec/word.
5) It is highly desirable that, whenever practicable,
each segment of applications code or data should
be accessed and protected by appropriate hardware
facilities at run time. The direct use of or
access to absolute store addresses by applications
programs should be reduced to a minimum.
The following subsections, subsection 3.2, 3.3,
and 3.4 are written with reference 2.1 as baseline,
i.e. only additional requirements and/or requirements
in reference 2.1 found unclear, are stated in these
sections.
3.2 D̲A̲M̲O̲S̲ ̲K̲E̲R̲N̲E̲L̲
3.2.1 P̲r̲o̲c̲e̲s̲s̲ ̲M̲a̲n̲a̲g̲e̲m̲e̲n̲t̲
a) Reference 2.1 shall be applicable requirements,
including:
1) 3.6.5.4.1
2) 3.6.5.4.2
3) 3.6.5.4.3
4) 3.6.5.4.4
5) 3.6.5.4.5
6) 3.6.5.4.6
7) 3.6.5.4.7
8) 3.6.5.4.8
3.2.2 I̲n̲t̲e̲r̲r̲u̲p̲t̲ ̲F̲u̲n̲c̲t̲i̲o̲n̲s̲
a) Deleted.
3.2.3 P̲r̲o̲c̲e̲s̲s̲ ̲C̲o̲m̲m̲u̲n̲i̲c̲a̲t̲i̲o̲n̲
a) It shall be possible for processes to share a data
area.
b) Synchronization elements as covered in reference
2.1 section 3.6.3 shall be supported
c) Deleted.
d) Deleted.
3.2.4 P̲r̲o̲c̲e̲s̲s̲ ̲S̲c̲h̲e̲d̲u̲l̲i̲n̲g̲
a) Functions/scheduling as described in reference
2.5 shall be supported.
3.2.5 P̲a̲g̲e̲ ̲M̲a̲n̲a̲g̲e̲r̲
a) Security related requirements are stated in section
8, Program Page management.
b) Translation Tables
1) Deleted
2) Deleted
c) 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 he 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.
d) Demand Paging:
1) 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.
2) A parent must have the capability of defining
the maximum number of memory pages that a child
may allocate.
3) Deleted
e) Backing Storage Management.
1) BS is a contigous area on a single disk unit
(BS unit). The rest of this unit may be used
by FMS. Location and size of BS is defined
at sysgen.
2) The BS unit needs not be connected at times
of boot load and initialization of Page Manager.
3) Memory resident segments may be CREATE'd and
MAKE'd without BS unit being connected.
4) BS unit will not be accessed or required connected
until the first time a non-resident segment
is created.
5) At sysgen time it may be defined that all segments
are resident. In that case, the BS area and
the BS- and PM- process within Page Manager
will not be allocated.
6) ED shall provide a facility that allows preventive
maintenance on the BS-unit without stopping
the system. One solution could be the following:
At sysgen an alternative BS-unit and BS-area
is defined. Page Manager provides a facility
to copy contents of BS to alternative unit
and continue operation without system stop.
3.2.6 M̲o̲n̲i̲t̲o̲r̲ ̲P̲r̲o̲c̲e̲d̲u̲r̲e̲s̲
a) It shall be possible to extend DAMOS with monitor
procedures.
b) They shall be known to all programs by inclusion
at system generation.
c) The monitor procedures shall be used to share dataareas
between processes of different classification as
follows:
1) All processes sharing one or several memory
pages by means of a monitor procedure shall
have the dataareas mapped-in despite their
security classification.
2) Not to break DAMOS security philosophies the
shared dataarea shall be fully protected (only
accessible in System Mode).
d) In order to be able to administrate the shared
data area a such monitor procedure may have access
to the calling process security class and indicator
whether trusted or not.
e) For the case of violation acces must be provided
to a "kill" function.
3.2.7 W̲r̲i̲t̲e̲ ̲A̲c̲c̲e̲s̲s̲ ̲C̲h̲e̲c̲k̲ ̲b̲y̲ ̲S̲y̲s̲t̲e̲m̲ ̲P̲r̲o̲c̲e̲d̲u̲r̲e̲s̲
Any procedure executing in System Mode shall check
write access before writing into a memory area specified
by the user in a call parameter. This applies to Kernel
procedures as well as I/O system.
3.3 I̲/̲O̲
3.3.1 I̲/̲O̲ ̲S̲y̲s̲t̲e̲m̲
a) The I/O system should be implemented such that
all stream commands may be excluded with a corresponding
saving in memory.
b) All I/O commands implying queuing of request should
be implemented as INIT - WAIT
e.g. INIT LOOKUP - WAIT OPERATION.
c) It shall be possible for a process to await termination
of first of a group of IO events and it shall be
possible to await first of a combined group of
IO events and sync-elements.
d) It shall be possible for two or more user processes
in parallel to have the same file open and concurrently
access the file (applies to FMS and terminal handling).
e) Deleted.
f) Deleted
g) Deleted
h) Deleted
i) A priority shall be associated with each I/O request.
The priority shall be selected when a file is opened.
j) The I/O system shall be modified whenever required
to include new commands for control of devices
included at a later stage.
k) Devices identified today to be controlled via the
I/O system are:
1) CDC MMD
2) DISC's SMD
CMD
3) Floppy disk
4) Lineprinter
5) VDU
l) Some of the devices/lines above are interfaced
via the I/O bus.
m) The I/O system shall support control of interface
units to the above devices through transmission
of commands and associated control information
to handlers/drivers.
n) Certain commands may be implemented not passing
the I/O system (initialization type commands).
o) All memory areas used by the system for I/O of
data above a certain security profile shall be
purged immediately after use.
3.3.2 F̲i̲l̲e̲ ̲M̲a̲n̲a̲g̲e̲m̲e̲n̲t̲ ̲S̲y̲s̲t̲e̲m̲s̲
3.3.2.1 B̲a̲c̲k̲i̲n̲g̲ ̲S̲t̲o̲r̲a̲g̲e̲ ̲M̲a̲n̲a̲g̲e̲m̲e̲n̲t̲
a) The backing storage management system (FMS) shall
support CDC disks interfaced via disk handler and
Floppy disk interfaced via Floppy disk handler.
Floppy disk controller is SA800/010AB/00, drive
is CR80D single side single density.
b) All processes consuming a significant part of the
CPU used per access to a diskfile shall execute
with a priority derived from the priority of the
I/O request and the type of the I/O request and
the type of processing requested (TBD). In the
present FMS running under AMOS in a stand-alone
computer, this would typically mean that command
processes should execute with a priority derived
from request priority.
c) All interfaces between processes in the FMS shall
be prioritized. This means that later requests
of higher priority are served before already waiting
requests of lower priority. This priority scheme
shall be applied for the interface from the I/O
system to the FMS, FMS internally and for the interface
FMS to disk handler(s).
d) FMS shall allow inclusion of an SD developed Message
Management System as defined in CPS/SDS/001 section
5.9.
e) The FMS shall support purging of files, part of
files and volumes by overwriting with random data
pattern refer section 8.
f) 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 requirements see section 8).
g) It shall be possible to have the same file open
by several users in parallel, and it shall be possible
for the users to access the file concurrently.
Concurrently means here, the processing for two
requests to access the same file may be processed
concurrently in the FMS.
h) The concurrent use of MODIFYBYTES on non- overlapping
parts of the same sector shall give results with
meaning.
i) No data may be lost by concurrent use of APPENDBYTES.
j) The result of MODIFYBYTES or APPENDBYTES applied
concurrently must be as if one request has been
entirely executed before the other.
k) The FMS shall support read of directories by special
users. The read shall be allowed to the extend
possible, even if the data-structures on the disk
are corrupted.
l) The FMS shall support read of physical sectors
by special users. The read shall be allowed despite
corruption of data-structures on the disk.
m) The FMS shall support formatting and initialization
of a Virgin diskpack.
n) The FMS shall support update of disk volume identification
(Refer section 8.10 a) without disturbing data
stored on volume.
o) Deleted
p) Deleted
q) Deleted
r) It shall be possible to change the security profile
of a file by request from a trusted process.
3.3.2.2 T̲e̲r̲m̲i̲n̲a̲l̲ ̲H̲a̲n̲d̲l̲i̲n̲g̲
a) DAMOS shall via the THS support terminals and low
speed devices attached via LTUX's to the TDX in
a similar way as the THS support devices via the
I/O bus and LTU's.
b) The THS shall support the use of the TDX in a meaningful
manner.
b…0f…1…0e…) TMS shall in addition to the data transfer commands
READ BYTES, APPEND BYTES support combined output
and input (i.e. TMS shall be aware of the relation).
As an alternative, the Read and append functions
could be expanded with a generalized "Position".
b…0f…2…0e…) TMS shall support an independant transfer of control
information to/from Device Handlers (the device
specific part of handlers). The length of such
control information shall not be limited.
b…0f…3…0e…) In cases, where data is actually multiplexed on
a wire (channel), TMS shall support a meaningful
scheme of priority for traffic.
b…0f…4…0e…) TMS shall be transparent to the possible consecutiveness
of transfer requests. Handling of this shall be
left to the protocol handlers.
c) The data structures allocated in THS device handlers
and for devices attached via LTUX in the TDX driver
shall be kept at a minimum-size:
d) Handling of 60 duplex terminals and 15 simplex
printing devices with data and control channels
shall be possible without excessive use of data
area for link descriptions.
e) Deleted
f) Terminals shall be addressed by logical names from
application. The mapping between logical and physical
names can be changed dynamically.
g) It shall be possible to protect a terminal in such
a way that it can only be accessed by I/O calls
from system mode.
h) The OFFER-ACCEPT mechanism shall apply to terminals
as well.
i) It shall be possible to change the security profile
of a terminal by request from a trusted process.
3.3.2.3 O̲F̲F̲E̲R̲-̲A̲C̲C̲E̲P̲T̲
The access rights specified in OFFER shall be the final
ones. ACL shall not be used to modify offered access
rights.
3.3.2.4 U̲s̲e̲r̲o̲n̲ ̲-̲ ̲U̲s̲e̲r̲o̲f̲f̲
Must be protected so that only privileged processes
can issue them.
Useroff of a process can only be done by the process
which issued the Useron.
3.3.3 D̲e̲v̲i̲c̲e̲ ̲H̲a̲n̲d̲l̲e̲r̲s̲
a) Following handlers shall be available for devices
interfaced via I/O crate:
1) LINE-PRINTER
2) VDU for software development
3) CDC disk
4) Floppy disk (hardware IF TBD)
b) Handlers for CAMPS which is 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.
This Standard Handler Interface shall include:
1) One Handler program code will exist per device/line
type.
2) A data area sahll 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 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.
4a) The interface shall include the capability
to transfer control information from/to the
creator of the (protocol) handler to/from the
protocol handler.
4b) The interface shall be such that the protocol
handler is aware of each single application
transfer request.
5) The Standard Handler interface shall provide
similar capabilities for LTU and LTUX connected
devices.
c) Handlers shall be so designed that a later implementation
of data buffer purging in the PU as well as in
the I/O crate can be done with minimum effort.
3.3.4 D̲e̲v̲i̲c̲e̲ ̲D̲r̲i̲v̲e̲r̲s̲
a) The following device drivers shall be available:
1) TDX-driver (host IF)
2) SSC-driver (TTY interface driver)
b) Drivers shall be so designed that purging of databuffers
can be implemented with a minimum of effort.
3.3.5 S̲u̲p̲p̲l̲e̲m̲e̲n̲t̲a̲r̲y̲ ̲r̲e̲q̲u̲i̲r̲e̲m̲e̲n̲t̲s̲ ̲t̲o̲ ̲I̲/̲O̲ ̲r̲e̲q̲u̲i̲r̲e̲m̲e̲n̲t̲s̲
a) It must be possible to bootload the system from
either CDC disk or floppy disk. It must be possible
to bootload a standby PU via an I/O crate shared
with an active PU without disturbing the processing
of the active PU.
b) A facility shall exist for disk-formatting of a
virgin disk (probably by FMS).
3.3.6 M̲e̲s̲s̲a̲g̲e̲ ̲H̲a̲n̲d̲l̲i̲n̲g̲
Deleted
3.4 E̲R̲R̲O̲R̲ ̲H̲A̲N̲D̲L̲I̲N̲G̲
The software, in conjunction with the hardware, shall
be designed to detect and limit the effect of hardware
faults which occur in the system. Upon detection of
the fault, action shall be taken to:
1) Report the fault
2) Contain and minimize the effect of the fault
3) Optimize the remaining system operational capabilities
while the fault condition persists
The following areas are handled:
1. Error Isolation
2. Error Reporting
3. User fix-up
4. Error Information
5. Memory Dump
6. Memory Analysis
7. Retire/Resume
8. Handling of HW generated error interrupts
9. Device driver/handler error handling
3.4.1 I̲s̲o̲l̲a̲t̲i̲o̲n̲
HW errors detected by DAMOS shall be isolated to exactly
one of the following types:
1 - Single terminal
2 - Channel
3 - LTU/LTUX
4 - BSM-X
5 - TDX BUS (TDX CTR, BUS, TIAs)
6 - PU (includes STI, IOBus) implying retire
7 - PU ( ) implying PU-SHUT-DOWN
8 - Mirrored disk incl. (CTR, Drive)
9 - Mirrored disk volume error
10 - Single disk
11 - Single disk volume error
12 - Standby PU, when accessed through the TDX BUS.
The isolation may be direct e.g. due to reporting from
a controller; or indirect e.g. the TMS detects a BSM-error
by:
1 - ensuring that the TDX-bus is
ok (can be done by sending a dummy frame through
the bus)
2 - ensuring that the neighbour LTUX is also erroneous
(can be done by sending a dummy frame to the
neighbour LTUX).
3.4.2 D̲A̲M̲O̲S̲ ̲E̲r̲r̲o̲r̲ ̲R̲e̲p̲o̲r̲t̲i̲n̲g̲
A̲B̲B̲R̲E̲V̲I̲A̲T̲I̲O̲N̲S̲
SDSE: Secondary Device Status Synchronization Element
PSE: Parent Synchronization Element
CESE: Central Error Synchronization Element
COPSY: CAMPS Operating System
PDSE: Primary Device Status Synchronization Element
3.4.2.1 G̲e̲n̲e̲r̲a̲l̲ ̲R̲e̲p̲o̲r̲t̲i̲n̲g̲ ̲M̲e̲c̲h̲a̲n̲i̲s̲m̲
F̲o̲r̲ ̲H̲a̲r̲d̲w̲a̲r̲e̲ ̲E̲r̲r̲o̲r̲s̲:
An irrecoverable error at one level (refer to figure
1, 2, and 3 overleaf) implies:
- one report is sent to the creator of the device
(e.g. terminal, channel, LTUX, BSM, TDX BUS, PU
+ STI)
- all subsequent accesses of the device are returned
with a cc defining: terminal disconnected.
- for TMS devices: the disabling of a user connection
is signalled on the system connection.
F̲o̲r̲ ̲S̲o̲f̲t̲w̲a̲r̲e̲ ̲E̲r̲r̲o̲r̲s̲ ̲(̲S̲e̲c̲u̲r̲i̲t̲y̲ ̲V̲i̲o̲l̲a̲t̲i̲o̲n̲)̲
A serious (e.g. security violation) error in a child
process is reported to the parent of the child. (Refer
figure 4), and the child is retired.
Figure 2…01…T̲D̲X̲-̲B̲U̲S̲ ̲L̲E̲V̲E̲L̲S̲ ̲
Figure 3…01…I̲O̲ ̲B̲U̲S̲ ̲D̲I̲S̲K̲ ̲L̲E̲V̲E̲L̲S̲
Figure 4
3.4.2.1.1 R̲e̲p̲o̲r̲t̲i̲n̲g̲ ̲a̲t̲ ̲t̲h̲e̲ ̲D̲i̲f̲f̲e̲r̲e̲n̲t̲ ̲L̲e̲v̲e̲l̲s̲
The following categories described:
Section 2.1 Single terminal error reporting
Section 2.2 LTU/LTUX error reporting
Section 2.3 Channel error reporting
Section 2.4 BSM-X error reporting
Section 2.5 TDX bus error reporting
Section 2.6 PU error reporting
Section 2.7 Error interrupts reporting
Section 2.8 On-line diagnostics reporting
Section 2.10 Single disk error reporting
Section 3.1 Security violation
Section 3.2 Non-security violation
3.4.2.2 H̲a̲r̲d̲w̲a̲r̲e̲ ̲E̲r̲r̲o̲r̲s̲
3.4.2.2.1 S̲i̲n̲g̲l̲e̲ ̲T̲e̲r̲m̲i̲n̲a̲l̲ ̲E̲r̲r̲o̲r̲
3.4.2.2.1.1 D̲e̲t̲e̲c̲t̲e̲d̲ ̲D̲u̲r̲i̲n̲g̲ ̲U̲s̲e̲r̲ ̲O̲p̲e̲r̲a̲t̲i̲o̲n̲
1) A cc is returned to the user defining:
- irrecoverable terminal error
2) The user connections are disabled
3) A report is sent to SDSE defining:
- irrecoverable terminal error
- a terminal identification
4) A subsequent COPSY call on the system connection
receives a cc defining:
- transition from user to system state
3.4.2.2.1.2 D̲e̲t̲e̲c̲t̲e̲d̲ ̲D̲u̲r̲i̲n̲g̲ ̲C̲O̲P̲S̲Y̲ ̲O̲p̲e̲r̲a̲t̲i̲o̲n̲ ̲o̲n̲ ̲a̲ ̲S̲y̲s̲t̲e̲m̲ ̲C̲o̲n̲n̲e̲c̲t̲i̲o̲n̲
1) A cc is returned defining
- transition from user to system state
2) the user connection is disabled
3) A report is sent to SDSE defining:
- irrecoverable terminal error
- a terminal identification
3.4.2.2.2 L̲T̲U̲/̲L̲T̲U̲X̲ ̲E̲r̲r̲o̲r̲
3.4.2.2.2.1 D̲e̲t̲e̲c̲t̲e̲d̲ ̲D̲u̲r̲i̲n̲g̲ ̲U̲s̲e̲r̲ ̲O̲p̲e̲r̲a̲t̲i̲o̲n̲
1) All user connections to the terminals at the LTU/LTUX
are disabled.
2) The call implying the detection of the error and
all subsequent calls at user connections get the
cc:
- irrecoverable terminal error
3) A report is sent to SDSE defining:
- irrecoverable LTU/LTUX error
- a device identification
4) Subsequent COPSY calls on any of the system connections
imply a cc defining:
- transition from user to system state
3.4.2.2.2 D̲e̲t̲e̲c̲t̲e̲d̲ ̲D̲u̲r̲i̲n̲g̲ ̲C̲O̲P̲S̲Y̲ ̲O̲p̲e̲r̲a̲t̲i̲o̲n̲
As above.
3.4.2.2.3 C̲h̲a̲n̲n̲e̲l̲ ̲(̲L̲T̲U̲/̲L̲T̲U̲X̲)̲ ̲E̲r̲r̲o̲r̲
Handled as LTU/LTUX errors except for the SDSE report,
which defines:
- irrecoverable channel error
- a channel identification
3.4.2.2.4 B̲S̲M̲-̲X̲ ̲E̲r̲r̲o̲r̲
Handled as 2 LTUX errors. However, only reporting
to the creator of the BSM-X, in a SDSE, defining:
- irrecoverable BSM-X error
- BSM-X no.
3.4.2.2.5 T̲D̲X̲ ̲B̲U̲S̲ ̲(̲T̲D̲X̲ ̲C̲T̲R̲,̲ ̲T̲D̲X̲ ̲B̲U̲S̲,̲ ̲T̲I̲A̲s̲)̲ ̲E̲r̲r̲o̲r̲
A switchover is performed. (Maybe COPSY has to command
the watchdog to switch BSM-Xs)
A report is sent to the creator of the TDX BUS in a
SDSE, defining:
- TDX Bus switchover
- failed TDX BUS number
3.4.2.2.6 P̲U̲ ̲(̲I̲n̲c̲l̲u̲d̲e̲s̲ ̲S̲T̲I̲ ̲a̲n̲d̲ ̲I̲O̲B̲U̲S̲)̲ ̲E̲r̲r̲o̲r̲
For some PU errors refer 2.7 a retire of the process,
which detects the error, is performed (hereby a report
is sent to PSE).
For the remaining errors:
- A disabled error print-out routing is called to
sent an error message which is defined at system
generation to the watchdog printer.
- The PU is shut-down via a programmed master clear.
- the MAP is saved
- the MAP PROM is entered
C̲o̲m̲m̲e̲n̲t̲
If a PU includes more than one STI or IOBUS, another
scheme is to be implemented.
3.4.2.2.7 E̲r̲r̲o̲r̲ ̲I̲n̲t̲e̲r̲r̲u̲p̲t̲s̲
Either a
1) retire of the calling process, or
2) PU shut-down
is performed as described in EP-PSP/027
3.4.2.2.7.1 D̲u̲r̲i̲n̲g̲ ̲R̲e̲t̲i̲r̲e̲
A report is sent to PSE defining:
- the cause of the error interrupt
3.4.2.2.7.2 D̲u̲r̲i̲n̲g̲ ̲P̲U̲ ̲S̲h̲u̲t̲-̲D̲o̲w̲n̲
Refer section 2.6.
Error interrupts are not only due to a hardware error.
Also e.g. illegal instructions are detected in this
way.
These software error interrupts are covered in section
3.1 as security violation.
3.4.2.2.8 O̲n̲-̲L̲i̲n̲e̲ ̲D̲i̲a̲g̲n̲o̲s̲t̲i̲c̲s̲ ̲R̲e̲p̲o̲r̲t̲i̲n̲g̲
A built-in self-test program, which is executed periodically,
reports errors to SDSE.
3.4.2.2.9 M̲i̲r̲r̲o̲r̲e̲d̲ ̲D̲i̲s̲k̲s̲ ̲(̲D̲i̲s̲k̲ ̲C̲T̲A̲,̲ ̲D̲i̲s̲k̲ ̲D̲r̲i̲v̲e̲,̲ ̲U̲D̲L̲U̲M̲E̲)̲ ̲E̲r̲r̲o̲r̲s̲
Bad sectors and retries are handled by FMS and handlers,
which build up a statistics area summing the errors.
Warnings are sent to SDSE, when thresholds are exceeded.
3.4.2.2.9.1 E̲r̲r̲o̲r̲ ̲i̲n̲ ̲a̲ ̲S̲i̲n̲g̲l̲e̲ ̲D̲i̲s̲k̲
Is reported to SDSE by FMS. Users are not affected.
3.4.2.2.9.2 E̲r̲r̲o̲r̲ ̲i̲n̲ ̲B̲o̲t̲h̲ ̲D̲i̲s̲k̲s̲
A report is sent to SDSE. Subsequent calls of the
FMS (via IOS) are returned via a cc defining:
- irrecoverable dual disk error
3.4.2.2.10 S̲i̲n̲g̲l̲e̲ ̲D̲i̲s̲k̲ ̲E̲r̲r̲o̲r̲
Handled a 9, except 9.1 is omitted.
3.4.2.3 S̲o̲f̲t̲w̲a̲r̲e̲ ̲E̲r̲r̲o̲r̲s̲
3.4.2.3.1 S̲e̲c̲u̲r̲i̲t̲y̲ ̲V̲i̲o̲l̲a̲t̲i̲o̲n̲
A security violation implies that the calling process
is retired and a report is sent to PSE.
Also, certain parameter errors in Kernel calls may
imply an automatic retire.
3.4.2.3.2 N̲o̲n̲ ̲S̲e̲c̲u̲r̲i̲t̲y̲ ̲V̲i̲o̲l̲a̲t̲i̲o̲n̲
A cc is returned to the caller.
3.4.3 U̲s̲e̲r̲ ̲F̲i̲x̲-̲U̲p̲
In MON calls, R6 shall contain the I/O operation to
be executed.
3.4.4 E̲r̲r̲o̲r̲ ̲I̲n̲f̲o̲r̲m̲a̲t̲i̲o̲n̲ ̲(̲r̲e̲p̲l̲a̲c̲e̲s̲ ̲p̲.̲ ̲9̲,̲ ̲1̲4̲,̲ ̲1̲7̲,̲ ̲2̲5̲ ̲i̲n̲ ̲I̲M̲
̲N̲O̲ ̲7̲9̲)̲
System calls, which are not retired, shall return a
16 bit cc to the caller.
Error reports to SDSE, PSE, shall contain the information
defined in section 3.1. The information may be based
on statistics obtained from device handlers.
SD (CAMPS) requires a separate list, which describes
and defines all CCs.
SD( CAMPS) requires a separate list, which describes
and defines the contents of error reports and to which
synchronization element, it is sent.
3.4.4.1 E̲r̲r̲o̲r̲ ̲R̲e̲p̲o̲r̲t̲ ̲I̲n̲f̲o̲r̲m̲a̲t̲i̲o̲n̲
3.4.4.1.1 H̲W̲ ̲E̲r̲r̲o̲r̲ ̲R̲e̲p̲o̲r̲t̲s̲
A HW error report shall include the following information:
- time of day
- identification of device/program detecting the
error
- detailed device status e.g.
-- erroenous device
-- detailed device status
- identification of current PU and CPU
- error type as specified in section 1
- device positionary information (e.g. head, cylinder
sack)
- type of failing operation (e.g. read, write, sack).
3.4.4.1.2 S̲W̲ ̲E̲r̲r̲o̲r̲ ̲R̲e̲p̲o̲r̲t̲s̲
An SW error (retire) report shall include the following
information:
- time of day
- identification of process detecting the error
- an identification of which statement provoked the
error (e.g. line no. or program counter)
- register contents at point of failure
3.4.4.2 D̲u̲m̲p̲ ̲o̲f̲ ̲F̲a̲i̲l̲e̲d̲ ̲P̲r̲o̲c̲e̲s̲s̲
A parent shall be able to dump memory segments (created
by the parent) of a retired child process.
3.4.5 M̲e̲m̲o̲r̲y̲ ̲D̲u̲m̲p̲
Memory shall be dumped on disk.
3.4.6 P̲o̲s̲t̲ ̲M̲e̲m̲o̲r̲y̲ ̲A̲n̲a̲l̲y̲s̲i̲s̲
A post mortem memory analysis based on dumped information
on disk shall exist.
3.4.7 R̲e̲s̲u̲m̲e̲
A resumed process shall receive restart information
in a register (R6).
3.4.8 H̲a̲n̲d̲l̲i̲n̲g̲ ̲o̲f̲ ̲H̲W̲ ̲G̲e̲n̲e̲r̲a̲t̲e̲d̲ ̲E̲r̲r̲o̲r̲ ̲I̲n̲t̲e̲r̲r̲u̲p̲t̲s̲ ̲(̲p̲a̲g̲e̲ ̲3̲ ̲i̲n̲
̲I̲M̲ ̲N̲O̲ ̲7̲9̲)̲
It shall be possible for a user to take over the handling
of the following error interrupts:
- illegal instruction
- parity error, program
- parity error, date
- parity error, I/O
- timeout error, program
- timeout error, data
- protection, program
- protection, data
- privilege, violation
3.4.9 D̲e̲v̲i̲c̲e̲ ̲D̲r̲i̲v̲e̲r̲/̲H̲a̲n̲d̲l̲e̲r̲ ̲E̲r̲r̲o̲r̲ ̲H̲a̲n̲d̲l̲i̲n̲g̲
a) Device drivers shall repeat erroneous operations
to ensure that sporadic errors are eliminated.
b) Drivers/handlers should contain a statistics area
defining e.g. for disk:
1) no of retries per error type
2) no of bad sectors
3) no of error-corrections
4) no of errors per error type
The statistics area may contain the detailed CC.
3.5 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̲
a) 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 fulfill the
requirements set forth to the CAMPS System.
b) 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.
3.5.1 P̲U̲/̲I̲O̲ ̲B̲U̲S̲ ̲S̲w̲i̲t̲c̲h̲o̲v̲e̲r̲
a) DAMOS will be allowed to use 30 seconds to a PU/IOBUS
switchover.
b) The DAMOS rcovery shall include creation of:
1) to FMS:
connection to 50 files, whereto in average
two processes are connected
2) to THS (IOBUS):
10 communication lines
to THS (TDX BUS):
75 communication lines (devices)
c) Reinsertion of a PU/IOBUS is TBD
3.5.2 D̲i̲s̲k̲ ̲r̲e̲c̲o̲v̲e̲r̲y̲/̲r̲e̲c̲o̲n̲f̲i̲g̲u̲r̲a̲t̲i̲o̲n̲,̲ ̲r̲e̲s̲t̲a̲r̲t̲ ̲
a) DAMOS shall support a dualized disk configuration:
1) removal/reinsertion of disk ctr/pack
2) initial and on-line selection of which 2 disks
are to constitute the dualized pair.
b) Files shall have different scope
1) temporary i.e. after a PU switchover or total
system error the file is lost
2) permanent i.e. the file is retained in the
above mentioned situations.
c) The bitmap must never be lost
d) Deleted.
e) Recovery of files/file connections are TBD
f) Disk performance during recovery is TBD.
g) The FMS shall support dual disks independent of
whether the disks are attached to the same disk
controller or two separate disk controllers. The
support includes handling of bad sectors in a meaningful
way.
By a bad sector is meant one for which it is not
possible to write data and read them again. A
sector with CRC error must not automatically be
considered bad.
h) After a positive acknowledge has been sent to a
user process that update has successfully terminated,
data shall always be recoverable except for physical
corruption of both disks. (No loss of data in
case of total power failure).
This results in the following detailed requirements:
1) After a positive acknowledge has been sent
to a user process that update has accessfully
terminated, data shall always be recoverable
except for physical corruption of both disks.
This means in particular that during update
of a sector, the two mirrored sectors must
in certain cases not be written in parallel,
as this might result in destruction of both
sectors in case of power failure.
2) Referring to the non parallel write in 1. above,
it is acceptable that FMS has a system generation
parameter defining, if writes on mirrored disks
may or may not take place in parallel.
3) Non parallel write must be scheduled in a way
that assures full throughput of each disk,
if other operations are queued for the disks.
It is accepted that response time for write
on mirrored disks is increased by about 20
msec. caused by non parallel write.
4) For a modify operation, the write must be done
first to the sector on the volume which was
not read. This requirement takes into account
that the sector not being read may be corrupted.
5) If for a read operation, the requested data
exist on any disk, they shall be delivered,
even if this may cause a mix of sectors from
the two disks.
6) If a read error is encountered by FMS, it shall
try to read the sector from the other disk
and write it to the one in error. The good
data is delivered to the user together with
a completion code indicating the error.
7) Reads shall be distributed optimally between
the two disks. The disk caches for the two
disks should also be used for optimization.
8) A function shall exist to bring up a disk as
mirrored.
9) A function shall exist to mount 2 disks as
being already mirrored.
10) The status of a volume as member of a mirrored
pair shall be recorded on the volume and checked
when mount is performed.
11) A repair function shall exist, performing the
following on a specified sector.
read from volume A;
if ok, write to volume B else
read from volume B and write to volume A;
read both sectors, checking for bad sector;
i) The FMS shall either keep essential data structures
in the memory located in the disk controller or
check-point essential data in a TBD manner to either
disk or standby FMS.
j) In case of failure of one PU, the FMS of a standby
PU must be able to take over without loss of any
data, except that result of unacknowledged ongoing
transfers maybe lost to an extend TBD. In the
switchover time, time to open files from standby
PU and time to reestablish message links is included
(see 3.3.6).
k) FMS must regularly sense each mounted or reserved
disk unit and detect if the volume is removed physically.
Then the unit shall be treated as if it was demounted
regularly. The same shall be done if an irrecoverable
error happens to IO-bus or disk controller.
l) Each time a disk unit is Released, Demounted, Deassigned,
Discarded or physically removed, the corresponding
disk cache shall be cleared.
3.5.3 T̲H̲S̲(̲I̲O̲B̲U̲S̲)̲ ̲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̲
a) It shall be possible to remove/reinsert new LTU's
and attached devices.
b) Recovery/restart of LTU's in case of PU/IOBUS switchover
is TBD.
3.5.4 S̲o̲f̲t̲w̲a̲r̲e̲ ̲R̲e̲c̲o̲n̲f̲i̲g̲u̲r̲a̲t̲i̲o̲n̲
TBD
3.5.5 T̲H̲S̲(̲T̲D̲X̲ ̲B̲U̲S̲)̲ ̲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̲
a) It shall be possible to switch to a standby TDX
BUS from the current active PU, so that it is transparent
to the application.
b) It shall be possible to reinsert a failed TDX BUS/CTR.
c) It shall be possible to remove/reinstall LTUX's/terminals.
1) LTUX's shall be referenced by name, thereby
enabling name to physical LTUX relation to
be set dynamically without terminal intervention.
2) DAMOS shall for LTUX/terminal rsources (and
the like) contain tables defining the current
and the maximum configuration.
d) In a dualized configuration with an active and
a standby PU the THS and TDX driver in the active
PU, shall checkpoint sufficient data to support
a switchover to the standby PU
4̲ ̲ ̲S̲Y̲S̲T̲E̲M̲ ̲S̲U̲P̲P̲O̲R̲T̲ ̲S̲O̲F̲T̲W̲A̲R̲E̲
a) The system support software must allow the secure
preparation, editing, compilation, linkage, module
testing, integration, realtime testing, system
testing and incorporation into run time operation
of new or modified source code modules. Any disturbance
caused to the operational system by each of these
procedures shall be minimal and well defined. The
support software shall include facilities for maintaining
and accessing any required off-line libraries of
procedures, data declarations, macros, etc.
b) The word secure implies no other requirements than
stated elsewhere in this document.
c) The process of integrating a module into the system
shall not require recompilation of the other elements
of the system.
4.1 H̲I̲G̲H̲ ̲L̲E̲V̲E̲L̲ ̲O̲P̲E̲R̲A̲T̲I̲N̲G̲ ̲S̲Y̲S̲T̲E̲M̲
…02…a) The Terminal Operating System (TOS) or similar shall
be supported.
b) The Terminal Operating System shall support interactive
software development from a terminal. From a terminal
it shall be possible to execute the support programs
identified in section 4.2, 4.3, 4.4, 4.5, 4.6 and
4.7 and user produced programs.
c) The TOS System console will be the SS&C console.
The SS&C driver shall for support and diagnostic
software look as if it is a standard consol driver.
d) The functional capabilities of TOS shall include
those specified in CSS/380/USM/0026.
e) The commands which may be initiated from a terminal
shall include those specified in CSS/381/USM/0037
except that commands for modifying the environemnt
of devices and volumes shall be 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. (e.g. mount,
demount may only be possible from OC).
4.2 L̲A̲N̲G̲U̲A̲G̲E̲ ̲P̲R̲O̲C̲E̲S̲S̲O̲R̲S̲
4.2.1 P̲a̲s̲c̲a̲l̲ ̲C̲o̲m̲p̲i̲l̲e̲r̲
a) The Pascal Compiler as supported for AMOS shall
be supported for DAMOS.
However the following facilities shall be supported:
1) A Pascal Standard Prefix similar to the one
specified in doc. no. CSS/006/RFM/0001 reflecting
the special features of the CR80D computer.
2) The Pascal Standard Prefix shall include:
Procedures making the synchronization mechanism
of parallel processes as defined by Damos available
to the Pascal programmer. Procedures making
the capabilities of the Damos I/O system available
to the Pascal Programmer.
4.2.2 S̲w̲e̲l̲l̲ ̲C̲o̲m̲p̲i̲l̲e̲r̲
a) The Swell Compiler shall compile the source text
into link modules linkable by the CR80D Linker
ref. section 4.4.1
b) Deleted
c) The SWELL Compiler shall allow the compilation
of single SWELL modules without the main program
part.
d) The Swell Compiler shall have the capabilities
as specified in CSS/415/USM/0047.
4.2.3 A̲s̲s̲e̲m̲b̲l̲e̲r̲
An assembler shall be supported with capabilities as
specified in doc.No. CSS/401/USM/0042
4.3 T̲E̲X̲T̲ ̲P̲R̲O̲C̲E̲S̲S̲O̲R̲S̲
a) The CR80D text processors shall include:
1) An interactive editor
2) A general text formatter
3) A text file merge program
4.3.1 E̲d̲i̲t̲o̲r̲
The Editor shall at least support the commands and
facilities as specified/described in doc. no. CSS/102/USM/0021.
4.3.2 T̲e̲x̲t̲ ̲F̲o̲r̲m̲a̲t̲t̲i̲n̲g̲ ̲P̲r̲o̲g̲r̲a̲m̲
a) The formatting shall include:
1) Margin justification
2) Underlining keywords
3) Addition of page headings
The formatting shall have the capabilities as described
in doc. no. CSS/180/USM/0044.
4.3.3 F̲i̲l̲e̲ ̲M̲e̲r̲g̲e̲ ̲P̲r̲o̲g̲r̲a̲m̲
The File Merge Program MERGE currently supported by
AMOS shall be supported by DAMOS and have the capabilities
as described in doc. no. CSS/142/USM/0024.
4.3.4 P̲r̲e̲t̲t̲y̲ ̲P̲r̲i̲n̲t̲i̲n̲g̲ ̲F̲a̲c̲i̲l̲i̲t̲y̲
A pretty printing facility for formatting a SWELL source
text into a standard format with indentations reflecting
statement-nesting shall be supported.
4.4 P̲R̲O̲G̲R̲A̲M̲ ̲D̲E̲V̲E̲L̲O̲P̲M̲E̲N̲T̲ ̲A̲N̲D̲ ̲T̲E̲S̲T̲ ̲T̲O̲O̲L̲S̲
4.4.1 L̲i̲n̲k̲e̲r̲
a) The Linker shall be capable of transforming a number
of link modules to a single final object program.
b) The linkage shall include module linking, final
address resolution within a module, resolution
of references and code assembly. The Linker shall
be capable of linking link modules generated by
Swell Compiler.
c) It shall be possible to control the segmentation
of the object program as follows:
1) Input to LINK consists of a set of compiled
modules as described in CSS/416/RFM/0003.
2) Output from LINK consists of an object module
consisting of a number of program segments
and a number of data segments.
3) Runtime parameters to LINK specify:
- number of program segments and the start
address in logical program space for each
program segment.
- number of data segments and the start address
in logical data space for each data segment.
- for each input module a destination segment
for program and data part respectively.
Those requirements are assumed to give the following
facilities:
- To divide the terminal handling program
into segments according to the functions
reception, release, preparation etc. and
only give a terminal incarnation access
to those functions which the incarnation
is actually allowed to execute.
- To implement an overlay mechanism by letting
two or more segments have the same start
address.
- To implement shared procedures, which are
not MON procedures, by LINK'ing the procedures
and their data into all object modules
but only loading them once into memory.
4.4.2 P̲a̲s̲c̲a̲l̲ ̲P̲r̲o̲g̲r̲a̲m̲ ̲C̲r̲o̲s̲s̲ ̲R̲e̲f̲e̲r̲e̲n̲c̲e̲
a) A Pascal Program Cross Reference tool shall be
available. Preferably the Cross Reference listing
shall be an optional biproduct from the Pascal
Compiler (Compiler directive).
b) The Pascal Cross Reference listing shall be as
specified in doc. no. CSS/133/USM/0038.
4.4.3 S̲w̲e̲l̲l̲ ̲C̲r̲o̲s̲s̲ ̲R̲e̲f̲e̲r̲e̲n̲c̲e̲
a) It shall be possible for the Swell programmer to
obtain a Cross Reference listing by specifying
this to the Swell Compiler. The cross reference
listing shall be as specified in doc. no. CSS/415/USM/0047
with the following exceptions.
b) The list of identifiers in alphabetical order shall
for each identifier contain a list of all linenumbers
in which it occurred.
4.4.4 A̲s̲s̲e̲m̲b̲l̲e̲r̲ ̲C̲r̲o̲s̲s̲ ̲R̲e̲f̲e̲r̲e̲n̲c̲e̲
a) It shall be possible for the Assembly Programmer
to obtain a Cross Reference listing, preferably
by specifying this to the Assembler (Assembler
directive).
b) The Assembly Cross Reference listing shall include:
1) A listing of the source code with linenumbers.
2) The number of user identified identifiers.
4.4.6 S̲w̲e̲l̲l̲ ̲D̲e̲b̲u̲g̲g̲e̲r̲
a) The Swell debugger shall be an aid for detecting
logical errors in a Swell Program interactively.
b) The SWELL debugger shall allow the user via a terminal
to interact with an executing SWELL program (process)
in a vay that permits the SWELL items to be referenced
by their symbolic names.
It shall be possible to debug at least 3 processes
concurrently from the same terminal.
c) The facilities listed below shall be supported
by the SWELL debugger.
1) Insertion, removal and listings of break points.
2) Listing of current values of variables referenced
by their symbolic names.
3) Assigning new values to variables referenced
by their symbolic names.
4) Deleted.
5) Trace all procedures/functions calls.
d) For sparate testing of modules using the synchronization
primitives of DAMOS without having the modules
with which the module under test are going to synchronize
available the following facilities shall be supported:
1) Creation of a buffer to be sent to a synch
element referenced by its symbolic name as
defined in the SWELL program and sending it.
2) Specifying that a buffer is to be removed from
a synch element (referenced aby its symbolic
name as defined in the SWELL program) and display
the content at the terminal (receiving it).
e) The following low level features shall be supported:
1) Access to registers
2) Listing and changing the contents of memory
sections, specified by the user relative to
program and base.
3) Listing of base memory of min 2 other processes
specified at debug start.
4.4.7 A̲s̲s̲e̲m̲b̲l̲y̲ ̲D̲e̲b̲u̲g̲g̲e̲r̲
a) The assembly debugger shall be a tool assisting
in detection of logical errors in an assembly program.
b) The assembly debugger shall be an interactive tool
allowing the assembly programmer to interact with
an executing assembly program. The facilities listed
below shall be supported by the Assembly Debugger:
1) Insertion, deletion and listing of breakpoints
2) Dumping of registers (R0-R7), and memory (program
memory and base memory).
3) Patching in program and base memory
4) Creation and sending of a buffer to a synchronizaton
element.
5) Specifying that a buffer is to be removed from
a synchronization element, and display of the
content at the terminal (receiving it).
4.4.8 P̲a̲t̲c̲h̲ ̲P̲r̲o̲g̲r̲a̲m̲
A Patch Program having the capabilities as described
in CSS/155/USM/030 shall be supported by Damos.
4.4.9 G̲e̲n̲e̲r̲a̲t̲i̲o̲n̲ ̲o̲f̲ ̲T̲e̲s̲t̲ ̲O̲u̲t̲p̲u̲t̲ ̲f̲o̲r̲ ̲P̲a̲s̲c̲a̲l̲ ̲P̲r̲o̲g̲r̲a̲m̲s̲
a) A tool for test output generation from Pascal Programs
shall be supported.
b) The tool shall include the facilities described
in CSS/341/PSP/0015 with the following extension:
Test output shall include relative address of logged
test records.
4.4.10 G̲e̲n̲e̲r̲a̲t̲i̲o̲n̲ ̲o̲f̲ ̲T̲e̲s̲t̲ ̲O̲u̲t̲p̲u̲t̲ ̲f̲o̲r̲ ̲S̲w̲e̲l̲l̲ ̲P̲r̲o̲g̲r̲a̲m̲s̲
Same requirements as for Pascal Program, 4.4.9.
4.4.11 G̲e̲n̲e̲r̲a̲t̲i̲o̲n̲ ̲o̲f̲ ̲T̲e̲s̲t̲ ̲O̲u̲t̲p̲u̲t̲ ̲f̲o̲r̲ ̲A̲s̲s̲e̲m̲b̲l̲y̲ ̲P̲r̲o̲g̲r̲a̲m̲s̲.̲
Same requirements as for Pascal Programs, 4.4.9.
4.4.12 C̲h̲a̲n̲g̲e̲ ̲A̲f̲f̲e̲c̲t̲ ̲T̲o̲o̲l̲
A software tool which allows the determination of which
modules might be affected by a program change shall
be supported.
4.4.13 L̲i̲b̲r̲a̲r̲i̲a̲n̲
a) A program for library maintenance - routines for
the creation updating and logging of the programs
and macro libraries and other libraries as applicable
- shall be supported.
b) The librarian shall organize all information pertinent
to systems development and as such it shall cover
the areas of program development, systems generation
and documentation. It shall act as an umbrella
over the following development utilities:
1) Editor
2) Assembler
3) SWELL compiler
4) Pascal compiler
5) Linker
6) Systems generator
directing and recording their activites
c) Programs
- Allow two levels of issue numbering and version
number within latest issue. Attach date of
latest change.
- Recognize the various diguises of the program
as source module, link module, loadable module
d) Systems
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 shall be hierarchical
and allow a number of levels such as SYSTEM, SUBSYSTEM,
PACKAGE, MODULE. This description shall direct
systems generation. Systems shall have a two level
version number.
e) Installations.
Deleted.
f) Documents
Documenation key with reference to the systems
covered by the document and a descritpion of document
state.
g) Test data sets
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.
h) Users and groups
Program versions shall 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 program,
he gets the USER version, while another member
of the team would get the TEAM version, and a systems
generator would get 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 infomation and print it out in various
formats.
i) Cross Reference Tool
Given a program name and a version identification
(either a specific version or all versions) together
with a set of systems/installation 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.
4.4.14 S̲y̲s̲t̲e̲m̲ ̲G̲e̲n̲e̲r̲a̲t̲o̲r̲
A System Generator shall be supported. A bootfile consisting
of DAMOS and user specified support and applications
programs shall be the result of invoking the System
Generator.
4.5 F̲I̲L̲E̲ ̲M̲A̲N̲I̲P̲U̲L̲A̲T̲I̲O̲N̲ ̲P̲R̲O̲G̲R̲A̲M̲S̲
4.5.1 B̲i̲n̲h̲e̲x̲
The file conversion program Binhex, refer doc. no.
CSS/114/USM/0027 shall be supported.
4.5.2 C̲o̲m̲p̲a̲r̲e̲
The file comparision program Compare shall be supported.
Compare shall compare two files for equality. The result
of the comparision shall be output on a user specified
output file.
4.5.3 C̲o̲p̲y̲
The program Copy, refer to CSS/110/USM/0032, shall
be supported.
4.5.4 H̲e̲x̲b̲i̲n̲
The file conversion program Hexbin, refer CSS/113/USM/0028
shall be supported.
4.5.5 L̲i̲s̲t̲f̲
The file display program Listf shall be supported.
Listf shall display the contents of a specified file
one page at a time. Forward an backward paging shall
be supported.
4.5.6 P̲r̲i̲n̲t̲
The line printer support program PRINT refer to CSS/006/USM/0033
shall be supported.
4.6 D̲I̲R̲E̲C̲T̲O̲R̲Y̲ ̲M̲A̲I̲N̲T̲E̲N̲A̲N̲C̲E̲ ̲U̲T̲I̲L̲I̲T̲I̲E̲S̲
4.6.1 A̲t̲t̲r̲
a) The program Attr shall be supported, refer to doc.
no CSS/932/USM/0036. The attributes displayed shall
besides those stated in the above referenced document
include:
1) Date and time for the creation of the file
2) Security classification of the file.
4.6.2 C̲r̲e̲a̲t̲e̲
a) The program Create shall be supported, refer to
doc. no CSS/932/USM/00036. The set of input parameter
to create as stated in the above referenced document
shall be extended to include:
1) Date and time. By default this parameter shall
be set by Create to the current System date
and time.
2) Security classification. A default value may
be defined. A security check shall be performed
(user classification contra classification
of file) before the creation is actually executed.
4.6.3 E̲n̲t̲e̲r̲
The program Enter, refer to doc. no. CSS/932/USM/0036,
shall be supported.
4.6.4 L̲i̲s̲t̲
a) The program List, refer to doc. no CSS/932/USM/0036
shall be supported. Besides NAME, TYPE, SIZE, ALLOC,
AREA as stated in the above referenced document
the listing shall include:
1) Date and Time for the creation of the file
2) Security classification
4.6.5 P̲r̲o̲t̲e̲c̲t̲
The program Protect, refer to doc. no CSS/932/USM/0036,
shall be supported.
4.6.6 R̲e̲m̲o̲v̲e̲
a) The program Remove, refer to CSS/932/USM/0032,
shall be supported.
b) If the invokation of the program Remove causes
disk storage to be deallocated, all the deallocated
storage shall be purged, pattern to be overwritten
with, see section 8.
4.6.7 R̲e̲n̲a̲m̲e̲
The program Rename, refer to CSS/932/USM/0036 shall
be supported.
4.6.8 D̲c̲o̲p̲y̲
The program Dcopy, refer to doc. no. CSS/111/USM/0050
shall be supported.
4.7 D̲I̲A̲G̲N̲O̲S̲T̲I̲C̲S̲ ̲P̲R̲O̲G̲R̲A̲M̲
a) DAMOS shall support
1) on-line self test diagnostics software programs
2) off-line diagnostics software testprograms
b) which detects
1) firmware, and
2) hardware errors
c) The test program may be based on built-in selftest
program in the CR80D modules.
d) Error conditions in the peripheral equipment shall
be evaluated by the central computer system.
4.7.1 O̲n̲-̲l̲i̲n̲e̲ ̲D̲i̲a̲g̲n̲o̲s̲t̲i̲c̲s̲ ̲p̲r̲o̲g̲r̲a̲m̲
a) Generally the on-line diagnostics selftest programs
shall limit the effect of an error.
b) Specifically the DAMOS shall meet requirements
derived from
1) integrity of operation
2) availability requirements
c) For a more specific definition of some of the test
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.
4.7.1.1 I̲n̲t̲e̲g̲r̲i̲t̲y̲ ̲o̲f̲ ̲o̲p̲e̲r̲a̲t̲i̲o̲n̲
SD and ED shall agree on cumulative tests and error
reporting in order to evaluate the reliability.
4.7.1.2 A̲v̲a̲i̲l̲a̲b̲i̲l̲i̲t̲y̲
a) Detailed CAMPS availability requirements are described
in CPS/210/SYS/0001: CAMPS system requirements,
section 3.4.4. DAMOS derived requirements are:
1) error reports shall isolate an equipment error
to a replaceable module, thereby minimizing
the MTTR
2) print/display of driver and the like statistics
shall be possible to support preventive maintenance
thereby maximizing the MTBF.
4.7.1.3 O̲n̲-̲l̲i̲n̲e̲ ̲t̲e̲s̲t̲ ̲p̲r̲o̲g̲r̲a̲m̲s̲
For all device drivers/handlers delivered by ED, test
functions shall be included. Cf. 8.9 b. The test functions
shall be invoked by test programs with the following
characteristics:
a) The test programs shall be designed to operate
as low priority tasks in timeshared multiprogramming
mode together with the application software. Errors
shall be reported to an error fix up process. The
testprograms shall cover the hardware modules defined
in section 4.7.2.1.
b) Specific test program to verify system integrity
shall be available.
4.7.1.4 S̲y̲n̲t̲a̲x̲ ̲I̲n̲t̲e̲g̲r̲i̲t̲y̲ ̲T̲e̲s̲t̲ ̲P̲r̲o̲g̲r̲a̲m̲s̲
a) A system integrity test program, which
1) on request and
2) periodically
performs a checksumming of system software shall be
available.
4.7.2 O̲f̲f̲-̲l̲i̲n̲e̲ ̲D̲i̲a̲g̲n̲o̲s̲t̲i̲c̲s̲ ̲P̲r̲o̲g̲r̲a̲m̲s̲
a) The off-line diagnostics programs shall fulfil
requirements derived from the CAMPS availability
requirements defined in CPS/210/SYS/0001 section
3.4.4.
b) To fulfil these requirements:
1) diagnostics programs shall isolate an equipment
error to a replaceable module, to meet the
MTTR requirements
2) preventive maintenance programs shall be designed
to maximize MTBF
c) Diagnostics programs shall be executed in the standby
branch in off-line mode without interuption in
the normal message handling function in the active
branch.
4.7.2.1 O̲f̲f̲-̲l̲i̲n̲e̲ ̲t̲e̲s̲t̲p̲r̲o̲g̲r̲a̲m̲s̲
a) The off-line software package shall at least contain
programs for test of the following hardware modules:
1) CPU + CACHE
2) Memory Map, MIA
3) RAM
4) PROM
5) Deleted
6) Deleted
7) CIA
8) TDX I/F, TIA
9) Deleted
10) LTUX's
11) BTMX-Y
12) Deleted
13) Deleted
14) Deleted
15) I/O BUS
16) LTU
17) LIA
18) Disk Controller
19) Disk Drive
20) Disk Pack
21) Line Printer
22) Floppy Disk
23) Deleted
24) Deleted
4.8 M̲I̲S̲C̲E̲L̲L̲A̲N̲E̲O̲U̲S̲ ̲P̲R̲O̲G̲R̲A̲M̲S̲
4.8.1 F̲o̲r̲m̲a̲t̲t̲i̲n̲g̲ ̲o̲f̲ ̲D̲i̲s̲k̲
A tool for initializing a virgin disk shall be supported
(disk and floppy)
4.8.2 F̲i̲l̲e̲ ̲C̲o̲n̲v̲e̲r̲s̲i̲o̲n̲
A tool for copying a file from disk to floppy disk
and viseverse shall be supported.
4.8.3 S̲y̲s̲t̲e̲m̲ ̲T̲i̲m̲e̲ ̲S̲e̲t̲t̲i̲n̲g̲
A tool for setting/resetting the system time and date
shall be supported.
4.8.4 T̲i̲m̲e̲
The system shall maintain a clock with accuracy better
than 10…0e…-5…0f….
4.8.5 T̲e̲s̲t̲ ̲D̲r̲i̲v̲e̲ ̲P̲r̲o̲g̲r̲a̲m̲
a) In order to be able to support test drive programs
DAMOS shall allow read of process-relative data
areas, as well as read of sync-element data areas
and other common data areas by a separate test
drive process created by the application programmer.
b) 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), with a size limit of 62K.
c) Furthermore, debugger commands must be available
as calls from a test drive program in order to
automatize tests.
d) 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
5̲ ̲ ̲P̲E̲R̲F̲O̲R̲M̲A̲N̲C̲E̲
5.1 S̲I̲Z̲I̲N̲G̲
a) Sizing estimate reports for system software shall
be delivered by ED at least together with the following
deliverable items.
1) Preliminary design document
2) Detailed design document
b) Further, report shall be delivered immediately
if significant deviations from the latest sizing
estimate report is discovered by ED
5.2 T̲I̲M̲I̲N̲G̲
Deleted.
5.3 S̲T̲A̲R̲T̲-̲U̲P̲ ̲A̲N̲D̲ ̲S̲W̲I̲T̲C̲H̲O̲V̲E̲R̲ ̲P̲E̲R̲F̲O̲R̲M̲A̲N̲C̲E̲ ̲R̲E̲Q̲U̲I̲R̲E̲M̲E̲N̲T̲S̲
TBD
5.4 O̲N̲-̲L̲I̲N̲E̲ ̲D̲I̲A̲G̲N̲O̲S̲T̲I̲C̲ ̲S̲O̲F̲T̲W̲A̲R̲E̲
a) On-line diagnostic software with a priority higher
than TBD shall utilize less than 5% of the processing
power in any subsystem (Peak second average)
b) On-line diagnostic software not fulfilling the
above requirement must run in a strict background
mode.
6̲ ̲ ̲A̲V̲A̲I̲L̲A̲B̲I̲L̲I̲T̲Y̲ ̲A̲N̲D̲ ̲M̲A̲I̲N̲T̲A̲I̲N̲A̲B̲I̲L̲I̲T̲Y̲
6.1 A̲V̲A̲I̲L̲A̲B̲I̲L̲I̲T̲Y̲
The system software shall be capable of continuous
un-interrupted operation once brought into service.
6.2 M̲A̲I̲N̲T̲A̲N̲A̲B̲I̲L̲I̲T̲Y̲
a) ED shall fulfil the following functions:
1) Design and implement changes and modifications
to the system software at the request of SD
at a time and material cost basis.
2) Provide assistance and expertise to SD when
required.
3) Diagnose and correct all system software faults
that are detected.
4) Be responsible for and maintain the documentation
of the system software in accordance with the
requirements for documentation.
7̲ ̲ ̲I̲N̲I̲T̲I̲A̲L̲I̲Z̲A̲T̲I̲O̲N̲
a) It shall be possible to bootload different software
systems from an operator specified bootfile.
b) The bootloading shall be from:
1) main disk (to be specified if more than one
is available)
2) floppy disk
as specified by the operator.
c) The operator position, which handles the bootloading
shall be:
1) the watchdog console (SSC)
A memory dump facility shall exist so that dump of
P.U. RAM, IO BUS RAM and MAP tables may be dumped to
disk in a masterclear sequence. The dump shall be
to a named file operationally created with maximum
classification. The use of this facility shall be
optional and available from the watchdog console (SSC).
In addition ED supports dump to system console at 9600
baud.
8̲ ̲ ̲S̲E̲C̲U̲R̲I̲T̲Y̲
a) Security shall be a major consideration during
system design and implementation. DAMOS shall ensure:
1) Data Security, i.e. ensuring that protected
data is not disclosed to unauthorized users.
2) Data integrity, i.e. ensuring that protected
data is not modified by unauthorized users
or in a prescribed manner.
b) Further it shall be an aim to ensure that access
to systems is not maliciously denied.
c) The following general requirements apply:
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 seen 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.
d) The software integrity requirements are the three
stated below:
1) Re-loadable copies of all the softwware 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. It shall be
possible to reload application processes individually.
2) 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 decrease the
system throughput.
A transaction is defined as: "A set of data in
a data processing system which has to be processed
as an entity.
8.1 S̲E̲C̲U̲R̲I̲T̲Y̲ ̲P̲O̲L̲I̲C̲Y̲
a) The definition of untrusted processes in DAMOS
SRS is useless in CAMPS context.
b) The minimum requirement is:
1) A subject may read from objects with classification
not higher than that of the subject. An untrusted
subject may write to objects with classification
not lower than that of the subject.
2) A trusted subject may write to objects with
any classification.
8.2 C̲O̲M̲P̲A̲R̲T̲M̲E̲N̲T̲S̲
a) It seems likely that compartments may be used in
CAMPS. In that case one compartment will be used
for security level and can have values 0-5. The
other compartments will be used for Special Handling
Categories and can have values 0-1. The number
of compartments for special handling categories
can be up to 8.
b) The rules in section 1 apply to each compartment
of the security profile.
c) The above points a) and b) apply to FMS and THS
as well.
8.3 T̲E̲R̲M̲I̲N̲A̲L̲S̲ ̲A̲N̲D̲ ̲C̲O̲M̲M̲U̲N̲I̲C̲A̲T̲I̲O̲N̲ ̲L̲I̲N̲E̲S̲
a) THS must apply security and access control to each
terminal on an LTU and not only to the LTU. So
the ASSIGN command must apply to terminals and
the OPEN command should use s̲y̲m̲b̲o̲l̲i̲c̲ ̲l̲i̲n̲e̲ ̲n̲a̲m̲e̲
without knowing the device name or the physical
line id.
b) Terminals must be handled in a special way different
from other communication lines. This is because
a high level oprating system (OS) must have the
opportunity to size control of the terminal when
security related events happen, such as login-logout
etc.
c) For this rason THS must recognize two terminal
states: user state and system state.
d) Transition from user state to system state takes
place when:
1) Terminal goes offline
2) device dependent events such as depressing
an attention key. The terminal may have a
group of function keys denoted as attention
keys
3) OS issues a disable command.
e) Transition from system state to user state takes
place when the OS issues an enable command.
f) OS may open a system channel to the terminal.
A user process may open a user channel to the terminal.
In system state the user channels are blocked,
so all communication with the terminal is done
by OS using system channel.
g) It shall be possible to change the security profile
of a terminal by request from a trusted process.
8.4 T̲D̲X̲ ̲D̲E̲V̲I̲C̲E̲S̲
a) The TDX driver as specified in DAMOS SRS has no
security control and the user process does itself
specify TDX device address and subdevice address
within the TDX device.
b) TDX driver must have exactly the same user and
operating systems interface as the THS, and it
must perform the same logical functions. In that
case it would be acceptable that the TDX driver
remains a separate process, but it is preferred
to include it into THS.
8.5 C̲E̲N̲T̲R̲A̲L̲I̲Z̲E̲D̲ ̲A̲C̲C̲E̲S̲S̲ ̲C̲O̲N̲T̲R̲O̲L̲
Deleted.
8.6 S̲C̲H̲E̲D̲U̲L̲I̲N̲G̲
Deleted.
8.7 S̲Y̲S̲T̲E̲M̲ ̲S̲O̲F̲T̲W̲A̲R̲E̲ ̲S̲T̲R̲U̲C̲T̲U̲R̲E̲
a) It is very important that verification of the security
system is possible by reviewing the design specifications
and inspecting the program modules involved. This
seems to be almost impossible with DAMOS due to
the fact that very large parts run in system state
thus having unlimited privileges. This is even
the fact with the I/O system although it has no
need for accessing data outside the user's own
address space. Nevertheless it will have the potential
capability of addressing any resource in the system.
b) In CAMPS it will be necessary to develop system
modules managing shared data areas which should
not be accessible by user programs. Those system
modules must run in system state too, as this is
the only way to hide data from user programs.
c) It seems that this situation may be improved by
a very limited change in the CPU. This change
would consist of introducing a new CPU state, named
f.ex. supervisor state.
d) The three states would then be characterised by:
1) User state:
Access to addressable memory pages with "read"
or "full access" attributes.
2) Supervisor state:
Access to all addressable memory pages, including
those with "no access" attribute.
3) System State:
Same memory access as supervisor state. Access
to all privileged instructions.
e) The main improvement would be that system programs
like the I/O system and CAMPS Message Monitor could
run in supervisor state, then having much more
limited privileges than the anticipated ones in
system state.
f) The change would further require that capability
and process management date be moved from the process
own context to a "process management context" within
the kernel.
g) Independent of this suggestion it should be considered
whereever possible to separate the data managed
by the kernel into a number of independent or basely
coupled "kernel contexts".
h) The purpose of these suggestions is to limit as
far as possible the effects of software or hardware
failures to the affected module. This will largely
improve security verification compared to the current
situation where all systems software may potentially
interact across the boundaries defined in the DAMOS
structuring. Moreover it will improve software
reliability, as failures may more easily be traced
to the software module containing the error.
8.8 P̲R̲O̲G̲R̲A̲M̲ ̲P̲A̲G̲E̲ ̲M̲A̲N̲A̲G̲E̲M̲E̲N̲T̲
a) This section states some security related requirements
to the handling of program pages by the page manager.
b) Program segments must be initialized by the loader
only. Once the loader has initialized a program
segment, its contents must not be changeable by
a process executing the program.
8.9 O̲N̲L̲I̲N̲E̲ ̲T̲E̲S̲T̲ ̲P̲R̲O̲G̲R̲A̲M̲S̲
a) Security must be considered very carefully when
online test programs are designed. The following
requirements apply:
1) If an online test program must run in parallel
with the system, it should always run with
lowest process priority and lowest security
classification level.
2) Online test programs may never access a device
or a TDX device in parallel with normal operation
of that device. So it is f.ex. not allowed
to test one line on an LTUX while another line
on the same LTUX is operative.
3) Online test programs may never run in system
state.
b) This means that the low level test functions must
be included in device handlers and device drivers,
and that online testprograms must do their job
through drivers or handlers, who can then control
the proper access. Ability to invoke test function
must be priveleged
8.10 D̲A̲T̲A̲ ̲S̲E̲C̲U̲R̲I̲T̲Y̲
a) Each disk volume shall internally hold a record
for a disk volume identify number and date and
time. Inscribing the unit identity number shall
not affect any other information stored on the
unit.
b) When a unit has been mounted the I/O system shall
either automatically or upon rquest deliver the
unit identity number, date and time. It shall
be impossible to write to files on a unit which
contains no unit identity number or an unassigned
number but read from files on such a unit shall,
however, be possible.
c) Deleted.
d) Memory delete, storage purge, overwrite in this
document means for memory types:
1) PU-RAM: Overwrite by zeroes, all ones or any
other sequence uncorrelated to security protected
data
2) IO BUS-RAM (accessible from one or more P.U.'s
and a LTU or device controller):
As for PU-RAM
3) LTU or controller RAM (not shared):
As for PU-RAM
4) TDX Host - IF and TDX controller RAM:
As for PU-RAM
5) LTUX RAM:
As for PU-RAM
6) DISK-MEMORY:
Overwrite 1 to N times with random numbers.
The random number sequence shall for each
time be generated with a different seed. N
to be defined at compile or system generation
time.
e) Data buffers used by software, system software,
firmware and hardware which are used to transfer
data of a classification higher than or equal to
CLASS shall be deleted immediately after use,
CLASS to be defined at sytem generation.
f) Upon deallocation of memory allocated a process
(including virtual storage backing memory) the
memory shall be delted/purged.
g) Deleted.
h) It shall be possible to select that segements allowed
to carry data classified above CLS may not reside
on backing storage (i.e. the backing memory reserved
for virtual storage will in this case never contain
data classified above CLS)
i) DAMOS shall treat security violation in the same
way independently of object type. Thus security
violation against files shall result in a retire
of the user process. IOS must check the completion
code returned by FMS and retire the process in
certain cases.
9̲ ̲ ̲Q̲U̲A̲L̲I̲T̲Y̲ ̲A̲S̲S̲U̲R̲A̲N̲C̲E̲
Deleted.
1̲0̲ ̲ ̲D̲O̲C̲U̲M̲E̲N̲T̲A̲T̲I̲O̲N̲ ̲R̲E̲Q̲U̲I̲R̲E̲M̲E̲N̲T̲S̲
Deleted.
1̲1̲ ̲ ̲C̲R̲8̲0̲D̲ ̲S̲O̲F̲T̲W̲A̲R̲E̲ ̲V̲E̲R̲I̲F̲I̲C̲A̲T̲I̲O̲N̲
Deleted.
1̲2̲ ̲C̲O̲M̲P̲A̲T̲I̲B̲I̲L̲I̲T̲Y̲ ̲W̲I̲T̲H̲ ̲A̲M̲O̲S̲ ̲A̲N̲D̲ ̲C̲R̲ ̲8̲0̲ ̲S̲T̲A̲N̲D̲A̲R̲D̲ ̲S̲U̲P̲P̲O̲R̲T̲ ̲S̲O̲F̲T̲W̲A̲R̲E̲
a) DAMOS and CR80D standard support software shall
be compatible with AMOS and CR80 Standard support
software to a degree that allows programs developed
on the CR80 system to be lifted to the CR80D system
with a minimum of effort.
b) Preferably facilities of the CR80 operating system
AMOS shall be a subset of those of DAMOS. Where
requirements (e.g. security requirements) or improvements/changes
in hardware of the CR80D makes this impossible,
the difference between the two systems shall be
thoroughly documented.
c) A document containing a list of the CR80 Software
(AMOS and support) documents shall be produced
by ED indicating which documents applies and which
do not to the corresponding CR80D program. For
each document in the list indicated as not applicable
the document shall specify the differences between
the CR80 software and the CR80D software. Further
the document shall identify those facilities supported
by the CR80D system which are not supported at
all by the CR80 system.
d) This document shall be issued 1980-11-01.
