top - download
⟦f5388bbd8⟧ Wang Wps File
Length: 23686 (0x5c86)
Types: Wang Wps File
Notes: Spelunked
Names: »~ORPHAN72.08«
Derivation
└─⟦2c0571bd0⟧ Bits:30005816 8" Wang WCS floppy, CR 0005A
└─ ⟦this⟧ »~ORPHAN72.08«
WangText
G…0d…G…05…F…08…F…09…F…0b…F
E…0a…E…01…D…08…D…0c…D…01…C…08…C…0e…?…05…>…0c…7
6…09…6…0f…6…05…5…0c…5…02…4…08…4…0f……86…1
…02…
…02…
…02…
…02…CPS/SRS/001
…02…801010…02……02…#
CAMPS
ADDITIONAL
REQUIREMENTS
TO
DAMOS
STANDARD
SOFTWARE…02…800801…02…CAMPS
T̲A̲B̲L̲E̲ ̲O̲F̲ ̲C̲O̲N̲T̲E̲N̲T̲S̲
1 SCOPE ........................................
6
2 APPLICABLE DOCUMENTS .........................
7
2.1 DAMOS SYSTEM REQUIREMENT SPECIFICATIO ...
7
2.2 PROPOSAL FOR DIGITAL EXCHANGE APPENDIX 3,
CR80D STANDARD SOFTWARE ..................
7
3 SYSTEM STANDARD SOFTWARE ....................
8
3.1 OPERATING SYSTEM .........................
10
3.2 DAMOS KERNEL ............................
13
3.2.1 Process Management ...................
13
3.2.2 Interrupt Functions ..................
13
3.2.3 Process Communication ................
13
3.2.4 Process Scheduling ...................
14
3.2.5 Page Manager ......................... 15
3.2.6 Monitor Procedures ...................
3.3 I/O ......................................
15
3.3.1 I/O System ...........................
15
3.3.2 File Management Systems..............
16
3.3.2.1 Backing Storage Management .......
16
3.3.2.2 Terminal Handling ................
19
3.3.3 Device Handlers ......................
19
3.3.4 Device Drivers .......................
20
3.3.5 Suplementary requirements derived
from I/O requirement .................
21
3.3.6 Message Handling .....................
21
3.4 ERRORHANDLING ............................
23
3.5 RECOVERY, RESTART, RECONFIGURATION ......
3.5.1 PU/IOBUS Switchover ..................
3.5.2 Disk Recovery, Reconfiguration,
Restart ..............................
3.5.3 THS (IOBUS) Recovery, Reconfiguration
Restart .............................
3.5.4 Software Reconfiguration .............
3.5.5 THS (TDX BUS) Recovery, Reconfigura-
tion, Restart ........................
4 SYSTEM SUPPORT SOFTWARE ......................
27
4.1 HIGH LEVEL OPERATING SYSTEM ..............
27
4.2 LANGUAGE PROCESSORS ......................
28
4.2.1 Pasal Compiler ......................
28
4.2.2 Swell Compiler .......................
30
4.2.3 Assembler ............................
30
4.3 TEXT PROCESSORS ..........................
30
4.3.1 Editor ..............................
31
4.3.2 Text Formatting Program ..............
31
4.3.3 File Merge Program ...................
31
4.4 PROGRAM DEVELOPMENT AND TEST TOOLS .......
31
4.4.1 Linker ...............................
31
4.4.2 Pascal Cros Reference ...............
32
4.4.3 Swell Cross Reference ................
32
4.4.4 Assembler Cross Reference ............
33
4.4.5 Pascal Debugger ......................
33
4.4.6 Swell Debugger .......................
34
4.4.7 Assembly Debugger .................... 35
4.4.8 Patch Program ........................
35
4.4.9 Generation of Test Output for Pascal
Programs .............................
35
4.4.10 Generation of Test Output for Swel
Programs .............................
36
4.4.11 Generation of Test Output for Assembly
Programs .............................
37
4.4.12 Change Affect Tool ...................
39
4.4.13 Librarian ...........................
39
4.4.14 System Generator .....................
39
4.5 FILE MANIPULATION PROGRAMS ...............
39
4.5.1 Binhex ...............................
39
4.5.2 Compare ..............................
39
4.5.3 Copy ................................
40
4.5.4 Hexbin ...............................
40
4.5.5 Listf ................................
40
4.5.6 Print ................................
40
4.6 DIRECTORY MAINTENANCE UTILITIES ..........
40
4.6.1 Attr .................................
40
4.6.2 Create ...............................
41
4.6.3 Enter ................................
41
4.6.4 List .................................
41
4.6.5 Protect .............................
41
4.6.6 Remove ...............................
42
4.6.7 Rename ...............................
42
5.6.8 Dcopy ................................
42
4.7 DIAGNOSTIC PROGRAMS ......................
42
4.7.1 On-line Diagnostic Programs ..........
43
4.7.1.1 Integrity of Operation ...........
43
4.7.1.2 Availbility .....................
43
4.7.1.3 On-line Test Programs ............
44
4.7.1.4 System Integrity Test Programs ...
44
4.7.2 Off-line Diagnostic Programs .........
44
4.7.2.1 Off-line Testprograms ............
45
4.8 MISCELLANEOUS PROGRAMS ...................
45
4.8.1 Formatting of Disk ...................
45
4.8.2 File Conversion ......................
45
4.8.3 System TiME Setting ..................
46
4.8.4 Time ................................
46
4.8.5 Test Drive Program ...................
46
5 PERFORMANCE ..................................
47
5.1 SIZING ...................................
47
5.2 TIMING ...................................
48
5. STARTUP AND SWITCHOVER PERFORMANCE
REQUIREMENTS .............................
49
5.4 ON-LINE DIAGNOSTIC SOFTWARE ..............
49
6 AVAILABILITY AND MAINTAINABILITY .............
50
6.1 AVAILABILITY ............................
50
6.2 MAINTAINABILITY ..........................
50
7 INITIALIZATION ...............................
51
8 SECURITY .....................................
52
8.1 SECURITY POLICY ..........................
8.2 COMPARTMNTS .............................
8.3 TERMINALS AND COMMUNICATION LINES ........
8.4 TDX DESIGNS ..............................
8.5 CENTRALIZED ACCESS CONTROL ...............
8.6 SCHEDULING ..............................
8.7 SYSTEM SOFTWARE STRUCTURE ................
8.8 PROGRAM PAGE MANAGEMENT ..................
8.9 ON-LINE TEST PROGRAMS ....................
8.10 DATA SECURITY ............................
9 QUALITY ASSURANCE ............................
54
10 SOFTWARE DOCUMENTATION .......................
55
10.1 DOCUMENTS TO BE DELIVERED ...............
55
10.2 DOCUENTATION STRUCTURE .................
55
10.3 ORGANIZATION OF DOCUMENTATION ...........
57
10.4 SOFTWARE UNIT DOCUMENTATION .............
58
10.5 FIELD MODIFICATION DOCUMENTS ............
67
11 CR80D SOFTWARE VERIFICATION .................
68
12 COMPATIBILITY WITH AMOS AND CR80 STANDARD
SOFTWARE .....................................
69…86…1 …02… …02… …02… …02…
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 durin 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
standar 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 i 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 moule
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 nd 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 te 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, integration time and/or run time
to ensure that te integrity requirements 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 softwar 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 he 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
oftwo 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 etailed 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) Th 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) Recovery nd restart procedures
7) Reconfiguration
8) File Management System
9) 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 privilegd 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 cessaton 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, as must illegal combinations
of legal operation codes and legal instruction
modifiers.
4) Memory bound (page management) echanisms 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 o 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 rate 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 channes) 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) Sensitie 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 eing 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 attmpted 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 shall be
probided. HW/SW echniques must be available
to accomplish this function.
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. Te 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 nd/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..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) Reference 2.1 shall be applicable requirements,
including:
1) 3.6.9.1
2) 3.6.9.2
3) 3.6.9.3
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. For the synchronization of the access to
such data areas
- Counter Semaphore
Shall b supported. (Counter semaphores correspond
to PARENT SIGNAL as defined for AMOS. Shall be
available for all Processes in DAMOS)
b) Synchronization element as covered in reference
2.1 section 3.6.3 shall be supported
c) Besides the functions decribed in reference 2.1
section 3.6.3.3.1 - 3 the functions Change ̲sync
̲el (SIP, changeable-attributes) shall be supported.
d) Changeable attributes for objects shall be accessing
bits and security profile.
3.2.4 P̲r̲o̲c̲e̲s̲s̲ ̲S̲c̲h̲e̲d̲u̲l̲i̲n̲g̲
a) Functins/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,
Program Page management.
b) Translation Tables
1) Page Management should be optimized towards
a siuation 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.
2) 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 muc 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 forequeing of changes to
the map
c) A parent operating system must have the cpability
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 speciied 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 hae the capability of defining
the maximum number of memory pages that a child
may allocate.
3) Demand paging must work for PASCAL programs
too, and procedures LOCK (procedure name),
UNLOCK (procedurename) should be provided
3.2.6 M̲o̲n̲i̲t̲o̲r̲ ̲P̲r̲o̲c̲e̲u̲r̲e̲s̲
a) It shall be possible to extend DAMOS with monitor
procedures.
b) They shall be known to all programs either by inclusion
at system generation or similar to IMINON of AMOS.
c) The monitor procedures shall be used to share dataareas
beteen 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 AMOS 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 ad indicator
whether trusted or not.
e) For the case of violation acces must be provided
to a "kill" function.
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 corresponing
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 vents 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 trminal handling).
e) The length of the data-area allocated by the I/O
system in the user process should per file open
not exceed 10 words.
f) The length of the data-area allocated by the I/O
system in the user process should per message-link
open not exceed 5 words (see 3.3.6).
g) The length of the data-area allocaed by the I/O
system in the user-process should per terminal-link
not exceed 5 words (see 3.3.2.2).
h) The length of the data-area (IOCB) allocated for
out-standing reads/writes in the user process should
not exceed 10 words. This applies for alltypes
of I/O.
i) A priority shall be associated with each I/O request.
The priority shall be generated from the process
priority and an explicitly specified priority in
a TBD manner.
j) The I/O system shall support commands to device
drivers an to handlers. It 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 (details TBD):
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 to handlers/drivrs.
n) Certain commands (TBD) may be implemented not passing
the I/O system (initialization type commands).
o) The I/O system shall be so designed, that later
implementation of a purging facility can be done
with minimum of effort. The purging ere is purging
of I/O system controlled data areas containing
sensitive data after data has been transmitted.…86…1
…02… …02… …02… …02…
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 isk interfaced via Happy disk handler. Floppy
disk controller is CR8047D/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 derved 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 wih 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
hall 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) The FMS shall support message handling as described
in 3.3.6.
e) The FMS shall support purging of files, part of
fles and messages by overwriting with random data
pattern refer section 8 (for messages see 3.3.6).
f) The FMS shall perform overwriting of data buffers
having been used for data of higher classification
than CLASS, CLASS to be specified at systemgeneration.
The overwriting shall be performed immediately
after use of the buffer. The use of disk cache
for suct 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, te 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 concurrnt 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 alloed 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
