top - download
⟦726852b89⟧ Wang Wps File
Length: 88351 (0x1591f)
Types: Wang Wps File
Notes: ACCESS
Names: »3245A «
Derivation
└─⟦563d5c4e7⟧ Bits:30006220 8" Wang WCS floppy, CR 0275A
└─ ⟦this⟧ »3245A «
WangText
REV. 1 1983-03-18
3245A
ACCESS - PART II TECHNICAL PROPOSAL SYS/1983-01-25
SUBPART B - SYSTEM CHARACTERISTICS Page #
A C C E S S
AUTOMATED COMMAND AND CONTROL
EXECUTIVE SUPPORT SYSTEM
PART II
TECHNICAL PROPOSAL
SUBPART B
SYSTEM CHARACTERISTICS
DOC. NO. ACC/8004/PRP/001 ISSUE 1
SUBMITTED TO: AIR FORCE COMPUTER AQUISITION CENTER (AFCC)
DIRECTORATE OF CONTRACTING/PK
HANSCOM AFB
MA 01731
U S A
IN RESPONSE TO: SOLICITATION NO. F19630-82-R-001
AFCAC PROJECT 211-81
PREPARED BY: CHRISTIAN ROVSING A/S
SYSTEMS DIVISION
LAUTRUPVANG 2
2750 BALLERUP
DENMARK
…0e…c…0f… Christian Rovsing A/S - 1982
This document contains information proprietary to Christian
Rovsing A/S. The information, whether in the form of text,
schematics, tables, drawings or illustrations, must not be duplicated
or used for purposes other than evaluation, or disclosed outside
the recipient company or organisation without the prior, written
permission of Christian Rovsing A/S.
This restriction does not limit the recipient's right to use
information contained in the document if such information is
received from another source without restriction provided such
source is not in breach of an obligation of confidentiality
towards Christian Rovsing A/S.
T̲A̲B̲L̲E̲ ̲O̲F̲ ̲C̲O̲N̲T̲E̲N̲T̲S̲
2. SUBPART B - SYSTEM CHARACTERISTICS
2.1 SYSTEM OVERVIEW
2.2 CONFIGURATION
2.3 SYSTEM QUESTIONNAIRE RESPONSE
2.1 S̲Y̲S̲T̲E̲M̲ ̲O̲V̲E̲R̲V̲I̲E̲W̲
2.1.1 H̲a̲r̲d̲w̲a̲r̲e̲
2.1.1.1 I̲n̲t̲r̲o̲d̲u̲c̲t̲i̲o̲n̲
In this section is provided a general overview of the
H/W included in the proposed system.
In subpart C of PART II, specifications and characteristics
are given for each component of the proposed equipment.
2.1.1.2 G̲e̲n̲e̲r̲a̲l̲
The two main elements of the system are the local area
network and the central processors with the databasesystem,
see FIG. 2.1.1-1.
The local area network interfaces the system to the
remote terminals.
2.1.1.3 X̲-̲N̲E̲T̲,̲ ̲L̲o̲c̲a̲l̲ ̲A̲r̲e̲a̲ ̲N̲e̲t̲w̲o̲r̲k̲
The local area network is implemented using CR's unique
X-NET concept.
In the following the features and characteristics of
the X-NET will be highlighted in order to show how
perfect the net fits this application.
The X-NET bus is a serial bus. Data travels on the
X-NET bus at a max. rate of 0.8192 Mbits per second.
FIG. 2.1.1-1…01……01…HARDWARE SYSTEM OVERVIEW
In order to handle the required number of remote terminals,
the network is divided into 8 branches. Each of these
branches has a maximum data transfer rate of 0.8192
Mbps adding up to 8 x 0.8192 = 6.5536 Mbps.
In order to meet the required functional availability,
each branch is dualized, i.e. the branch contains 2
buses.
Physically each bus in a non-dualized X-NET consists
of a pair of cables running through the site. Thus
a dualized X-Net bus uses 2 pairs of cables.
The units and elements included in one dualized X-NET
branch are shown on FIG. 2.1.1-2.
In the proposed system, data is transferred between
each remote terminal and one Processor Unit (PU) within
a Front-End Processor by the one X-Net bus which is
active. The other X-Net bus is connecting the remote
terminal to the other PU within the same Front-End
Processor. This bus is in stand-by mode. Only one
bus is actively transmitting at a time. Two dualized
Front-end Processors are in this application hosts
for all remote terminals.
The remote terminals are connected to the X-NET buses
by X-NET Terminal Adapters (XTA's). The XTA is a microprocessor-controlled
unit. The application S/W is down-line loaded from
the Front-End Processors through the X-Net bus.
FIG. 2.1.1-2…01……01…X-NET STRUCTURE AND UNITS
Data is transferred serially between the remote terminal
and the XTA. The transfer rate is up to
9.6 Kbps.
The XTA is connected to both X-NET buses but as explained
above it is only communicating on one bus at a time.
The traffic on the X-NET buses is controlled by the
X-NET controller (XCT).
The X-NET Amplifier and Branching Unit (XAB) are used
for extending the bus-length and for creation of subbranches.
When remote terminals are placed so far from the Front-End
Processors that a modem connection is required, this
modem connection is established using an X-NET Communication
Port link (XCP-link). The X-NET behind the XCP-link
has its own controllers but is in fact considered a
subbranch of the X-NET branch to which it is attached.
The dualized buses are connected to the Front-End Processors
through the Interface Adapter modules (TIA's).
All modules described above are connected to the X-NET
buses by an X-NET wall outlet (XWO). This XWO provides
galvanic isolation from the bus and features protection
to the bus for component failures in the attached modules,
thus allowing the bus-communication to continue independent
of single-point-failures.
If communication on an X-NET bus is made impossible
due to H/W failure, communication is handed over to
the dual X-NET bus.
2.1.1.4 C̲e̲n̲t̲r̲a̲l̲ ̲P̲r̲o̲c̲e̲s̲s̲o̲r̲s̲
The Central Processors include 3 processing elements
(PE's):
a) Two Front-End Processors. These are mainly supporting
the remote terminals connected through the X-NET
and the terminals placed in the main computer room.
b) One Back-End Processor, which mainly supports the
database.
The 3 PE's are structured as a CR80 FATOM configuration
specially modelled to meet the ACCESS requirements.
Each PE is completely dualized in order to create a
Processor with a very high reliability.
FIG's 2.1.1-3 and 2.1.1-4 are showing the structure
of the two types of PE's.
When a Front-End Processor is in normal operation,
Processor Unit #1 (PU #1) and Channel Unit #1 (CU #1)
are operating as one processor serving traffic on two
X-NET branches. PU #2/CU #2 are operating as another
processor serving traffic on two other X-NET branches.
Each of the two processors has the capacity to handle
all 4 X-NET branches, and in normal operation the one
is stand-by for the other.
In the Back-End Processor the dualization concept is
a little different.
In normal operation PU #1 in conjunction with CU #1
is the active Processor, while PU #0 in conjunction
with CU #1 is the stand-by Processor
The CU #1 is constructed to be a dualized unit, contained
within one physical crate. Each I/O controller module
is supported by the two independent data buses A and
B.
Each I/O controller module can be accessed through
both bus A and bus B, though it is only accessed through
one bus at a time from the PU which has claimed access
most recently.
In the CU the power supply is completely dualized as
well.
FIG. 2.1.1-3…01……01…FRONT END PROCESSOR STRUCTURE
FIG. 2.1.1-4…01……01…BACK-END AND DATABASE PROCESSOR STRUCTURE
2.2 C̲O̲N̲F̲I̲G̲U̲R̲A̲T̲I̲O̲N̲
A specific list of all items included in the HW configuration
is provided in this section.
Table 2.2-1 lists the equipment proposed for the first
increment. The table reflects the equipment items
requested in the RFP, Table C-1.
Table 2.2-2 lists the equipment proposed for augmentation
as requested in the RFP, Table C-2
Table 2.2.-3 lists the equipment posposed for augmentation
as requested in the RFP, Table C-3
The equipment manufactured by Christian Rovsing A/S,
i.e. the Processors and the X-Net, is described in
subpart C of this Part of the Proposal (Part II)
Characteristics for all the equipment proposed can
be found in the appended technical literature, which
is listed in subpart A of this part of the proposal
(Part II).…86…1 …02… …02… …02… …02…
1̲.̲ ̲C̲R̲ ̲A̲C̲C̲E̲S̲S̲ ̲1̲/̲C̲P̲U̲
E̲Q̲U̲I̲P̲M̲E̲N̲T̲
I̲T̲E̲M̲ D̲E̲S̲C̲R̲I̲P̲T̲I̲O̲N̲ Q̲T̲Y̲
1 CR80 WATCHDOG MODULE
12 CR8066M/010AB/00 LTU,WD 3
13 CR8076M/010--/00 WCA 3
14 CR8089M/010--/00 CCA 6
15 CR8091M/000--/00 CCBA 3
2 CR80 PROCESSOR UNIT MODULES
21 CR8003M/040PC/00 CPU/CACHE 12
22 CR8016M/512C/00 512K RAM 12
25 CR8020M/000PC/00 MAP 6
26 CR8071M/010--/00 MIA 6
27 CR8021M/010-C/01 STI 20
28 CR8073M/010--/00 TIA 16
29 CR8072M/010--/00 SBA 24
3 CR80 CHANNEL UNIT MODULES
31 CR8081M/010A-/00 CIA-A 5
32 CR8081M/010-B/00 CIA-B 5
33 CR8044M/041AB/02 DISC CTL/32K 10
34 CR8084M/010--/00 DCA 10
37 CR8066M/010AB/00 LTU,SYNC/16K 6
38 CR8082M/010--/00 LIA-N 6
39 CR8046M/040AB/00 PAR CTRL 3
3A CR8086M/010--/00 PCA 3
3C CR----M/-----/00 IEEE CTRL 2
3D CR----M/-----/00 IEEE CTRL AD 2
3B CR8045M/040AB/00 TAPE CTRL 3
TABLE 2.2-1 (1 of 5 Pages)
EQUIPMENT LIST
ACCESS, FIRST INCREMENT…86…1 …02… …02…
…02…
3E CR8085M/010--//00 TCA 3
4 DATA BASE PROCESSOR
41 IDM 500 BASE SYSTEM 2
42 DATABASE ACCET 2
43 1 MBYTE MEMORY 2
44 DISK CONTROLLER 2
45 RACK MOUNT SLIDES 2
7 CR80 RACK, CRATES, ACCESSORIE
72 CR8101-/036--/00 RACK 36U 11
73 CR8102-/000--/00 RACK 18U 2
74 CR8106-/110-/00 MAINS FILTER 13
7D CR8107-/010--/00 PWR DIST PNL 22
7E CR8050M/010--/00 PWR SUPPLY 22
7G CR8125M/225PC/00 POU CRATE 6
7H CR8125M/425AB/00 CU CRATE 5
7J CR8105M/020--/00 FAN UNIT 11
7K CR8055M/020--/00 MBT 34
7L CR8211M/738--/00 DATA CH TERM 6
8 CR80 CABLES
81 CR8211M/030--/00 DATA CH. CAB 10
8H CR8201M/015--/00POWER CABLE 44
8J CR8215M/030--/00 SUPRABUS CAB 24
8K CR8215M/778--/00 SUPRABUS TER 8
TABLE 2.2-1 (2 of 5 Pages)
EQUIPMENT LIST
ACCESS, FIRST INCREMENT…86…1 …02… …02…
…02…
2̲.̲ ̲C̲R̲ ̲A̲C̲C̲E̲S̲S̲ ̲1̲/̲I̲A̲S̲
I̲T̲E̲M̲ D̲E̲S̲C̲R̲I̲P̲T̲I̲O̲N̲ Q̲T̲Y̲
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
̲ ̲ ̲
8 CR80 CABLES
8L CR8221M/010--/00 CABLE A DISK 10
8M CR8221M/020--/00 CABLE B DISK 10
J MASS STORAGES
J3 CR-----/600 DISK DRIVE, FMD 14
J7 CR8302-/080 DISK DRIVE,MMD 10
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
̲ ̲ ̲
3. CR ACCESS 1/OPERATOR CONSOLE
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
I̲T̲E̲M̲ D̲E̲S̲C̲R̲I̲P̲T̲I̲O̲N̲ Q̲T̲Y̲
H PERIPHERAL EQUIPMENT
HA DELTA726OT VDU TEMPEST 1
HF CR8333-/064 PRINTER TI810 1
HG CR8391-/820 PRINTER TI820 2
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
̲
4̲.̲ ̲C̲R̲ ̲A̲C̲C̲E̲S̲S̲ ̲1̲/̲T̲A̲P̲E̲ ̲D̲R̲I̲V̲E̲S̲
I̲T̲E̲M̲ D̲E̲S̲C̲R̲I̲P̲T̲I̲O̲N̲ Q̲T̲Y̲
8 CR80 CABLES
8N CR8223M/050--/00 MAG.TAPE CAB 3
J MASS STORAGAES
J8 CR8320-/002--/00 TAPE STATION 3
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
̲ ̲
5̲.̲ ̲C̲R̲ ̲A̲C̲C̲E̲S̲S̲ ̲1̲/̲G̲R̲A̲P̲H̲I̲C̲ ̲D̲I̲G̲I̲T̲I̲Z̲E̲R̲ ̲A̲N̲D̲ ̲C̲O̲L̲O̲R̲ ̲C̲A̲M̲E̲R̲A̲
I̲T̲E̲M̲ D̲E̲S̲C̲R̲I̲P̲T̲I̲O̲N̲ Q̲T̲Y̲
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
̲ ̲
H PERIPHERAL EQUIPMENT
H7 DUNN 631 COLOR CAMERA 1
HE COMPULSLIDE SYSTEM 1000 1
TABLE 2.2-1 (3 of 5 pages)
EQUIPMENT LIST
ACCESS, FIRST INCREMENT…86…1 …02… …02…
…02…
6̲.̲ ̲C̲R̲ ̲A̲C̲C̲E̲S̲S̲ ̲1̲/̲H̲I̲G̲H̲ ̲S̲P̲E̲E̲D̲ ̲N̲O̲N̲ ̲I̲M̲P̲A̲C̲T̲ ̲P̲R̲I̲N̲T̲E̲R̲
I̲T̲E̲M̲ D̲E̲S̲C̲R̲I̲P̲T̲I̲O̲N̲ Q̲T̲Y̲
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
̲ ̲
H PERIPHERAL EQUIPMENT
H2 XEROX 8700 PRINTER, N-INP 1
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
̲ ̲
7̲.̲ ̲C̲R̲ ̲A̲C̲C̲E̲S̲S̲ ̲1̲/̲L̲I̲N̲E̲ ̲P̲R̲I̲N̲T̲E̲R̲
I̲T̲E̲M̲ D̲E̲S̲C̲R̲I̲P̲T̲I̲O̲N̲ Q̲T̲Y̲
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
̲ ̲
H PERIPHERAL EQUIPMET
H1 BP 1500 LINE PRINTER 2
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
̲ ̲
8̲.̲ ̲C̲R̲ ̲A̲C̲C̲E̲S̲S̲ ̲1̲/̲L̲E̲T̲T̲E̲R̲ ̲Q̲U̲A̲L̲I̲T̲Y̲ ̲P̲R̲I̲N̲T̲E̲R̲
I̲T̲E̲M̲ D̲E̲S̲C̲R̲I̲P̲T̲I̲O̲N̲ Q̲T̲Y̲
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
̲ ̲
H PERIPHERAL EQUIPMENT
HD XEROX 860T PRINTER 113
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
̲ ̲
9̲.̲ ̲C̲R̲ ̲A̲C̲C̲E̲S̲S̲ ̲1̲/̲C̲O̲L̲O̲U̲R̲ ̲G̲R̲A̲P̲H̲I̲C̲ ̲D̲I̲S̲P̲L̲A̲Y̲ ̲U̲N̲I̲T̲
I̲T̲E̲M̲ D̲E̲S̲C̲R̲I̲P̲T̲I̲O̲N̲ Q̲T̲Y̲
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
̲ ̲
H PERIPHERAL EQUIPMENT
HB AYDIN 5216 CGDU TEMPEST 43
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
̲ ̲
1̲0̲.̲ ̲C̲R̲ ̲A̲C̲C̲E̲S̲S̲ ̲1̲/̲V̲I̲D̲E̲O̲ ̲D̲I̲S̲P̲L̲A̲Y̲ ̲U̲N̲I̲T̲
I̲T̲E̲M̲ ̲ D̲E̲S̲C̲R̲I̲P̲T̲I̲O̲N̲ Q̲T̲Y̲
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
̲ ̲ ̲
H PERIPHERAL EQUIPMENT
HA DELTA 7260T VDU TEMPEST 137
TABLE 2.2-1(4 of 5 pages)
EQUIPMENT LIST
ACCESS, FIRST INCERMENT
1̲1̲.̲ ̲C̲R̲ ̲A̲C̲C̲E̲S̲S̲ ̲1̲/̲O̲P̲T̲I̲C̲A̲L̲ ̲C̲H̲A̲R̲A̲C̲T̲E̲R̲ ̲R̲E̲C̲O̲G̲N̲I̲T̲I̲O̲N̲ ̲D̲E̲V̲I̲C̲E̲
I̲T̲E̲M̲ D̲E̲S̲C̲R̲I̲P̲T̲I̲O̲N̲ Q̲T̲Y̲
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
̲ ̲
H PERIPHERAL EQUIPMENT
H6 ITC ULTRA-INPUT 202 OCR 1
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
̲ ̲
1̲2̲.̲ ̲C̲R̲ ̲A̲C̲C̲E̲S̲S̲ ̲1̲/̲C̲O̲L̲O̲U̲R̲ ̲G̲R̲P̲H̲I̲C̲ ̲C̲O̲P̲I̲E̲R̲
I̲T̲E̲M̲ D̲E̲S̲C̲R̲I̲P̲T̲I̲O̲N̲ Q̲T̲Y̲
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
̲ ̲
H PERIPHERAL EQUIPMENT
H8 XEROX 6500 GRAPHIC COPIER 1
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
̲ ̲
1̲3̲.̲C̲R̲ ̲A̲C̲C̲E̲S̲S̲ ̲1̲/̲V̲I̲D̲E̲O̲ ̲C̲O̲P̲I̲E̲R̲
I̲T̲E̲M̲ D̲E̲S̲C̲R̲I̲P̲T̲I̲O̲N̲ Q̲T̲Y̲
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
̲ ̲
H PERIPHERAL EQUIPMENT
HC SGC T5121 VIDEO COPIER 10
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
̲
1̲4̲.̲ ̲C̲R̲ ̲A̲C̲C̲E̲S̲S̲ ̲1̲/̲C̲O̲M̲M̲U̲N̲I̲C̲A̲T̲I̲O̲N̲S̲ ̲S̲U̲B̲S̲Y̲S̲T̲E̲M̲
I̲T̲E̲M̲ D̲E̲S̲C̲R̲I̲P̲T̲I̲O̲N̲ Q̲T̲Y̲
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
̲ ̲
5 TDX SYSTEM MODULES
51 CR1070S/000--/00 TDX CTRL 16
54 CR2510-/000--/00 X-NET OUTLET 32
5D CR8022S/000--/00 POWER SUPPLY 4
5E CR8105S/010--/00 FAN UNIT 2
5O CR1081 /="=--/00 LTUX-CRATE 4
5P XTA UNIT, TEMPEST 293
5Q XAB UNIT, TEMPEST 34
5R XCP UNIT, TEMPEST 3
5s XCP+CTRL UNIT, TEMPEST 3
8 CR80 CABLES
84 CABLE, tdx ctrl7x-NET OUTLET 16
85 X-NET BUS CABLE (1000M) 39
86 CABLE, TIA/X-NET OUTLET 16
8C CR201s/015--/00 POWER CABLE 4
TABLE 2.2-1 (5 of 5 pages)
EQUIPMENT LIST
ACCESS, FIRST INCREMENT…86…1 …02… …02…
…02…
1̲.̲ ̲C̲R̲ ̲A̲C̲C̲E̲S̲S̲ ̲2̲/̲C̲O̲M̲M̲U̲N̲I̲C̲A̲T̲I̲O̲N̲S̲ ̲S̲U̲B̲S̲Y̲S̲T̲E̲M̲
I̲T̲E̲M̲ D̲E̲S̲C̲R̲I̲P̲T̲I̲O̲N̲ Q̲T̲Y̲
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
̲ ̲
5 TDX SYSTEM MODULES
5P XTA UNIT, TEMPEST 41
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
̲ ̲ ̲
2̲.̲ ̲C̲R̲ ̲A̲C̲C̲E̲S̲S̲ ̲2̲/̲L̲E̲T̲T̲E̲R̲ ̲Q̲U̲A̲L̲I̲T̲Y̲ ̲P̲R̲I̲N̲T̲E̲R̲S̲
I̲T̲E̲M̲ D̲E̲S̲C̲R̲I̲P̲T̲I̲O̲N̲ Q̲T̲Y̲
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
̲ ̲ ̲
h PERIPHERAL EQUIPMENT
HD XEROX 860T PRINTER 14
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
̲ ̲ ̲
3̲.̲ ̲C̲R̲ ̲A̲C̲C̲E̲S̲S̲ ̲2̲/̲C̲O̲L̲O̲R̲ ̲G̲R̲A̲P̲H̲I̲C̲ ̲C̲O̲P̲I̲E̲R̲
I̲T̲E̲M̲ D̲E̲S̲C̲R̲I̲P̲T̲I̲O̲N̲ Q̲T̲Y̲
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
̲ ̲ ̲
H PERIPHERAL EQUIPMENT
H8 XEROX 6500 GRAPHIC COPIER 1
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
̲ ̲ ̲
4̲.̲ ̲C̲R̲ ̲A̲C̲C̲E̲S̲S̲ ̲"̲/̲C̲O̲L̲O̲R̲ ̲G̲R̲A̲P̲H̲I̲C̲ ̲U̲N̲I̲T̲
I̲T̲E̲M̲ D̲E̲S̲C̲R̲I̲P̲T̲I̲O̲N̲ Q̲T̲Y̲
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
̲ ̲
H PERIPHERAL EQUIPMENT
HB AYDIN 5216 CGDU TEMPEST 3
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
̲ ̲
5̲.̲ ̲C̲R̲ ̲A̲C̲C̲E̲S̲S̲ ̲2̲/̲V̲I̲D̲E̲O̲ ̲D̲I̲S̲P̲L̲A̲Y̲ ̲U̲N̲I̲T̲
I̲T̲E̲M̲ D̲E̲S̲C̲R̲I̲P̲T̲I̲O̲N̲ Q̲T̲Y̲
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
̲ ̲
H PERIPHERAL EQUIPMENT
HA DELTA 726OT VDU TEMPEST 24
TABLE 2.2-2 (1 of 2 pages)
EQUIPMENT LIST
ACCESS, SECOND INCREMENT…86…1 …02… …02…
…02…
6̲.̲ ̲C̲R̲ ̲A̲C̲C̲E̲S̲S̲ ̲2̲/̲V̲I̲D̲E̲O̲ ̲C̲O̲P̲I̲E̲R̲
I̲T̲E̲M̲ D̲E̲S̲C̲R̲I̲P̲T̲I̲O̲N̲ Q̲T̲Y̲
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
̲ ̲ ̲
H PERIPHERAL EQUIPMENT
HC SGC T5121 VIDO COPIER 36
TABLE 2.2-2 (2 of 2 pages)
EQUIPMENT LIST
ACCESS, SECOND INCREMENT…86…1 …02… …02…
…02…
1̲.̲ ̲C̲R̲ ̲A̲C̲C̲E̲S̲S̲ ̲3̲/̲C̲O̲M̲M̲U̲N̲I̲C̲A̲T̲I̲O̲N̲S̲ ̲S̲U̲B̲S̲Y̲S̲T̲E̲M̲
I̲T̲E̲M̲ D̲E̲S̲C̲R̲I̲P̲T̲I̲O̲N̲ Q̲T̲Y̲
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
̲ ̲ ̲
5 TDX SYSTEM MODULES
5P XTA UNIT, TEMPEST 380
8 CR80 CABLES
85 X-NET BUS CABLE (1000M) 18
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
̲ ̲
2̲.̲ ̲C̲R̲ ̲A̲C̲C̲E̲S̲S̲ ̲3̲/̲L̲E̲T̲T̲E̲R̲ ̲Q̲U̲A̲L̲I̲T̲Y̲ ̲P̲R̲I̲N̲T̲E̲R̲
I̲T̲E̲M̲ D̲E̲S̲C̲R̲I̲P̲T̲I̲O̲N̲ Q̲T̲Y̲
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
̲ ̲
H PERIPHERAL EQUIPMENT
HD XEROX 860T PRINTER 140
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
̲ ̲
3̲.̲ ̲C̲R̲ ̲A̲C̲C̲E̲S̲S̲ ̲3̲/̲C̲O̲L̲O̲R̲ ̲G̲R̲A̲P̲H̲I̲C̲ ̲D̲I̲S̲P̲L̲A̲Y̲ ̲U̲N̲I̲T̲
I̲T̲E̲M̲ D̲E̲S̲C̲R̲I̲P̲T̲I̲O̲N̲ Q̲T̲Y̲
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
̲ ̲
H PERIPHERAL EQUIPMENT
HB AYDIN 5216 CGDU TEMPEST 140
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
̲ ̲
4̲.̲ ̲C̲R̲ ̲A̲C̲C̲E̲S̲S̲ ̲3̲/̲V̲I̲D̲E̲O̲ ̲D̲I̲S̲P̲L̲A̲Y̲ ̲U̲N̲I̲T̲S̲
I̲T̲E̲M̲ D̲E̲S̲C̲R̲I̲P̲T̲I̲O̲N̲ Q̲T̲Y̲
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
̲ ̲
H PERIPHERAL EQUIPMENT
HA DELTA 7260T VDU TEMPEST 100
TABLE 2.2-3 (1 of 2 pages)
EQUIPMENT LIST
ACCESS, AUGMENTATION…86…1 …02… …02… …02…
5̲.̲ ̲C̲R̲ ̲A̲C̲C̲E̲S̲S̲ ̲3̲/̲I̲A̲S̲
I̲T̲E̲M̲ D̲E̲S̲C̲R̲I̲P̲T̲I̲O̲N̲ Q̲T̲Y̲
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
̲ ̲
4 DATA BASE PROCESSOR
41 IDM 500 BASE SYSTEM 4
42 DATABASE ACCET 4
43 1 MBYTE MEMORY 4
44 DISK CONTROLLER 7
45 RACK MOUNT SLIDES 4
7 CR80 RACK, CRATES, ACCESSORIE
73 CR8102-/000--/00 RACK 18U 4
74 CR8106-/110--/00 MAINS FILTER 4
J MASS STORAGES
J3 CR-----/600 DISK DRIVE, FMD 52
TABLE 2.2-3 (2 of 2 pages)
EQUIPMENT LIST
ACCESS; AUGMENTATION
2.3 S̲Y̲S̲T̲E̲M̲ ̲Q̲U̲E̲S̲T̲I̲O̲N̲A̲I̲R̲E̲ ̲R̲E̲S̲P̲O̲N̲S̲E̲
a. S̲y̲s̲t̲e̲m̲s̲
1. How does the system proposed meet the Human
Factor Guideline in Section M, Paragraph M5.b.(2)?
Please address each numbered paragraph in the
guideline.
Extensive human factors considerations (ergonomic)
is laid down in the design of the Interactive System
Language, ISL which functions as a shell to all application.
The ISL supports all users from the very most experienced
one to the most inexperience, by allowing bypass of
intermediate menus and providing optional HELP menus.
Ref, Part II Subpart D.
Security features are provided by the DAMOS operating
system and the hardware architecture.
Flexibility in software is provided by the flexible
Interactive System Language, which allows the System
Administrator to easily modify the user interface.
Operations and Maintenance is eased by the extensive
use of Maintenance and Diagnostic Software, which can
quickly locate errors.
Implementation ease is assured by the use of the flexible
Interactive System Language (Ref. Part II, Subpart
D).
Human Factor considerations has been imperative in
the design of the hardware of Christian Rovsing A/S.
Our CR80 is very flexible, allowing the same hardware
to be used in a wide range of applications. It is
very reliable, providing maximum availability. The
capability to maintain the system while part of the
system is active provides even higher availability.
The software of ACCESS will be integrated under a common
shell provided by the Interactive System Language,
which is used throughout the system to standardize
all menus and prompts and allowing HELP functions to
be called by the inexperienced user.
(a) Command Structure will be unified throughout
the system. The following highlights are provided.
1. Menus and prompting may be bypassed.
2. Bypass methods are totally free without limitations.
3. Simple mnemonic commands.
4. Compound commands are separated by colon while
parameters are separeted by commas.
5. Commands are normally limited to one word.
6. Commands are interactively validated.
7. Parameters are interactively syntax checked.
8. Default values are provided in most cases.
9. Parameter names will be consistent.
10. Default parameters are always shown on screen.
11. A truncated form of a command will be accepted
by the system if it is within the current subsystem
and if it is unique within that substem.
b. Menu Structure will be changeable by the System
Aministrator, but the following is proposed as
initial guidelines.
1. A separate title area.
2. The Title area will always contain the name
of the current subsystem.
3. A sub-title will link menus logically.
4. Menus are set up in a hierarichal way, subsystem
with system and features within subsystem.
5. The user can perform all imagineable jumps
between the menus.
6. Menus will always contain direction and mnemonic
code plus numeric choices.
7. Command will be entered on the command line.
8. Mnemonic code and Numbers can be used optionally.
9. Menus will be well structured.
10. Menu number choices are numbered beginning
with 1.
11. Maximum choices per screen will be 9.
12. Choices will be listed according to most frequent
use.
13. A default of the first choice is provided.
14. Mutually exclusive choices are grouped on one
menu when possible.
15. Condition are stated by 'if then'.
16. The system will allow backward scroll of menus
to a certain extent.
c. Prompting is also provided by the Interactive System
Language.
1. Default values insertion will be available
for system generated data.
2. Prompt menus will be titled with the subsystem
name.
3. Prompt menus may contain one screen of data
before entered, validated and subsequently
removed.
4. If more screens are needed for one prompt,
a scroll back feature is available.
5. The user may exist a prompt at any point.
6. Prompts will be limited to the extent possible.
7. The input field will be just after the last
direction text (same time).
8. Any default value may be skipped or changed
during data entry.
9. The instruction precedes the input field.
10. A color or another special character will separate
an instruction from an input field.
11. All instructions will be protected area and
the cursor will go directly from one input
field to the next.
12. A complete screen is normally shown for each
prompt.
13. Numerous prompts may be set up to facilitate
user work.
d. HELP Facilities are provided by the Interactive
System Language and can be maintained by the System
Adminstrator
1. HELP's are available in all subsystems.
2. The default HELP is always related to last
state of the last displayed screen.
3. The menu structure allows the user to find
specific HELP in all subsystems.
4. A unique function key can be used to call the
present HELP function.
5. HELP functions can be provided to any desired
level.
6. A unique function key will return the user
from the HELP function to the point he left.
e. Screen Interaction is standardized throughout the
system.
1. Scrolling, Paging, call HELP, return from HELP
will be implemented identically in each subsystem.
2. An Explisit way to leave a screen can be provided.
3. Initiation of function with long response times
will always provide a system acceptance of
the command without delay.
4. A summary of actions are available to a certain
extent.
5. The screen dialogue is always one screen at
a time allowing the user to maintain the overview.
6. The user may change line data entries as long
as the input is still only in the screen.
7. Display screens will always contain an location
identifier.
8. Logical grouping will be provided when extended
data entries are coped with.
9. Responses will always be placed on a new screen
or on the next line.
10. Information displayed will always be meaningsful.
f. Screen layouts are established by the Interactive
System Language and can hence be as standardized as
requested.
1. A unified screen layout will be provided.
2. Command entries, responses etc., are always
placed in the same area.
3. Screen layouts will be concise and simple.
4. Fields are displayed in a unified manner.
5. Titles and subtitles will be provided.
6. Various highlighting features will be used.
7. Blinking and audible alarms will be used only
for urgent matters.
8. Common information will be shown in the same
area.
9. Application and query responses will be labelled
if necessary.
10. Labels and data will be easily distinguishable.
11. Standard characters will be used for labels.
12. Upper case words will be used to call attention
to important items like commands and labels.
13. Margines will be available wherever possible.
g. Feedback to users.
1. Changed input default values are shown immediately
and can be changed before initiating the processing.
2. A system accept indication is provided immediately
after data entry.
3. Error conditions or other system action termination
will always be displayed to the user.
4. Special characters will separate message labels
from data.
h. System Message Display
1. A unique system response line will provide
easy segregation of system status response
and normal application response.
2. Feedback will be made as user friendly as possible.
3. Messages will be self explanatory to the extent
possible.
4. Messages will be kept as simple and standardized
as possible.
i. Error Message
1. Error Messages will be self explanatory, but
may contain references.
2. Error Messages will consider multiple reasons
for causing the problem.
3. Error Messages will be timely.
4. Messages will include unique reference to the
erroneous point.
5. Messages will be short.
6. Error Messages will be self explanatory to
the extent possible.
7. The user can correct the error immediately
and resume his work.
8. Complex recovery will be imbedded in self explantory
menus and prompts.
9. A HELP function is available to be called immediately.
j. Presentation of Displayed Information
1. A standard, consistent manner is used to present
information.
2. Listing of data is done in an ergonomical manner.
3. Numerical data will be displayed with punctuation
allignment and with supression of leading zeros.
4. Text and alphabetic information is left justified
when displayed.
5. Vertical alignment and left justification is
used when listed information is displayed.
6. Text paragraphs will be separated by at least
one line.
7. Formats for common use can be retained.
8. Legibility of character strings of codes will
be provided by break insertion.
9. Short response sentences are preferred.
10. No easy understandable abbreviations are avoided.
11. Mnemonic and acronyms will not include embedded
punctuation.
h. Aesthetics
1. Tempest certified equipment is also designed
with aethetic considerations.
2. Tempest certified equipment will have similar
ergonomic features as non tempest equipment.…86…1
…02… …02… …02… …02…
2. Describe the proposed system topology. Show how
the fault tolerant capabilities of the system architecture
avoid single point failure.
Please refer to FIG. 2.1.1-2, X-Net Local Area
Network.
Regarding the Local Area Network Front-End System
it is seen that every terminal connection point
has a dualized X-Net bus for communication with
a Processing Element (PE).
Each PE contains 2 dualized Processor Units (PU's)
Each PU has an I/O-bus to a channel unit (CU) containing
the PU's interface to a pair of mirrored (dualized)
discs. Further, all 4 PU's within the Front-End
System are interconnected through a pair of dualized
SUPRA-buses.
The Database System (Back-End System) consists
of a PE with 2 dualized PU's. Each PU has a I/O-bus
to a dualized CU. Each CU has a dualized interface
to a pair of mirrored discs and a dualized Intelligent
Database Machine (IDM).
The described system topology ensures that no single
point failure exists, which can cause system failure.
3. Describe the architecture including how multiple
processors and the I/O network are linked.
The architecture and configuration is described
in details in this proposal, Part II, in sections
2.1 and 2.2 of subpart B and the Hardware is described
in details in sections 3.1 and 3.2 of subpart C.
The processor is constructed of 3 processing elements.
Two of these are host processors for the local
area network and interfaces all connected terminals,
directly or through the local area network. The
third is managing the dualized database. Each Processing
Element is dualized and includes several multi-CPU
Processor Units.
Data Transfer between the Processing Elements is
routed through high speed data transfer buses,
providing DMA-transfer between Processor Unit Main
Memories.
The local area network is completely dualized and
the configuration of the system as proposed will
insure a extremely high operational availability
for all users and interfaces to the system.…86…1
…02… …02… …02… …02…
b. H̲a̲r̲d̲w̲a̲r̲e̲
1. How did you determine the amount of memory that
was necessary to meet the system workload requirements?
The estimate of the requirement for memory is based
on a case where 50 different user processes are
being served by each fron end. Of these 200 processes
ony 50 are expected to have an associated process
running in the back end system. If more processes
are in fact initiated, then DAMOS will roll some
of these processes out on disc for later execution.
Back End
DAMOS : 100 K words
IDM handler: 10 K words
IDM Parser: 75 K words
Query system: 75 K words
Report Writer 75 K words
Mirrored IDM Sync: 20 K words
Work area (10 KW per process) 50 x 10 KW
Total Backend 855 K words
Total available 1000 K words
Spare 145 K words
Front end:
DAMOS 100 K words
ISL 20 K words
Electronic Mail 30 K words
CINSAC 20 K words
PMS 30 K words
Personell 30 K words
Budget 30 K words
PMS 10 K words
Routine Exec. 30 K words
Work Area (10KW per Process 50 x 10 words
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
Total Front end 800 K words
Total available 1000 K words
Spare 200 K. words
2. Describe how peripherals are shared or switched
on the system.
All peripherals and terminals are connected to
the system so that they can be accessed by 2 PU'S.
The system will decide which PU has the control
at a given point of time, and the switching will
be performed by the system automatically.
The total traffic load created by terminals and
peripherals are shared between the 5 active PU's
placed in the 3 Processing elements to minimize
the impact to users created by peak-load effects.
The details on how the peripherals are shared between
the PU's are bound in this proposal, Part II subpart
B section 3.2.…86…1 …02… …02… …02… …02…
3. Describe the steps necessary to add additional
processors to the system?
The architecture of the proposed system configuration
is described in sections 2.1 and 2.2 of this subpart
of the proposal (Part II, subpart B).
The Processor is constructed by multi-CPU Processor
Units(PUs). The Processor Units are placed in a
dualized configuration within 3 Processing Elements
(PEs).
Two Processing Elements are host-processors for
all terminals directly connected to the main computer
room or through the local area network.
The third Processing Element is managing the dualized
Database.
3.1 Addition of CPUs.
In the proposed configuration each PU contains
2 CPUs in order to meet the Access requirements
of the RFP.
If future applications of the Access System calls
for more processing power, up to 5 CPUs can be
placed in each of the proposed PUs.
The steps necessary are:
a) Procurement of additional CPUs.
b) Place CPUs in PUs.
c) System generation with the updated configuration
table including the new quantity of CPUs.
3.2 Addition of PUs.
In the above referenced sections of this proposal
is described that if the workload on the database
is increased above the requirements of the RFP,
the database management can be shared by adding
more PUs to the database management PE.
This expansion requires the addition of more racks
with equipment. This proposal describes the option
of adding upto 2 more PUs.
The impact on the installation is described in
PART I, subpart C section 3.3.
3.3 Addition of PEs.
If future expansions includes addition of a number
of peripherals and terminals exceeding the increments
described in the RFQ to a degree, where the connections
of the two Host PEs are exceeded, additional PEs
with identical configuration can be added.
Each bus of the highspeed data transfer network
has a maximum capacity of 16 PUs.
4. How did you determine the amount fo IAS that was
necessary to meet the system data storage requirements?
The RFP asks for an initial data base capacity
of 2490 millions of characters. The database capacity
shall be expandable with up to 500 percent increase
in data storage.
The data base memory size has been calculated using
the following rules for systems overhead calculation.
(i) 75 percent ititially
(ii) 60 percent average at 100 percent expansion.
(iii)25 percent for the expansion capacity between
100 and 500 percent.…86…1 …02… …02… …02… …02…
5. What is the average access time of the IAS? What
is the formatted amount of data capacity of each
IAS device proposed?
a) 2 types of IAS devices are included in the
proposal:
1. 9730-80 MMD
2. 9775 FMD
Both types are disc drive units manufactured
by CDC (Control Data Corp.).
b) Average access time is calculated by adding
2 figures
1 average positioning time, i.e. the time
taken to make all possible head moves divided
by the number of all possible moves.
2 average latency time. Latency time is the
time taken to reach a particular address
on a track after position is complete
c) Average access time for 9730-80 MMD: 48.33ms
- average positioning time: 40ms
- average latency time : 8.33ms
d) Average access time for 9775 FMD: 33.33ms
- average positioning time: 25ms
- average latency time: 8.33 ms
e) Capacity of 9730-80 MMD:
1 unformatted capacity: 80MB
2 formatted capacity: 67.420MB
f) Capacity of 9775 FMD:
1) unformatted capacity: 679.795MB
2) formatted capacity: 621.527MB
6. What is the page (8 1/2 x 11 in) print speed of
the High Speed Non-Impact Printer?
The print speed is up to 70 pages per minute (up
to 9.240 lines per minute depending on data format).
7. What is the print speed of the Letter Quality Printer?
How do the TEMPEST modifications to the Letter
Quality Printer effect the physical appearance
and use in an office environment.
The Letter Quality printer prints 35 CPS, and it
is Christian Rovsing A/S's experience that the
Tempest Modification to the LQP will only modify
the physical appearance. Our experience stems from
VDU's and Line Printers.
8. What is the display area of the VDU in square inches?
The VDU uses a 14 inch tube (diagnoally). The
useable area is 7 times 10 inches, 70 square inches.
9. How are the VDU and CGDU similar in appearance
operation, keyboard and screen size?
The VDU and the CGDU are made by different manufacturers,
and are hence different. However, software residing
in the host system will make them similar in operational
use.
10. What are the terminal refresh rate and presistance
quality of the phosphor on the CGDU? Is the display
screen interlaced or non-interlaced?
The model 5807(v3) refresh rate is 30 hz interlaced
with a long persistence phosphor. There is no apparent
flicker. The monitor and video generation electronics
are identical to that accepted by afcac for the
wwmccs standard graphics terminal (aydin model
5807) (contract no. f19630-81-d-0010).
11. What is the display area in square inches? Can
you display a standard typewritten page of 80 characters
per line, 66 lines per page? What is the display
area of this standard typewritten page in square
inches?
12. What is the horizontal and vertical resolution
of the display screen in pixels?
640 x 480 Pixel Resolution
13. How does the TEMPEST modification to the CGDU effect
the physical display screen and use in an office
environment?
14. What are the sizes and weights of paper that can
be read by the OCR? What are the different types
of character fonts and sizes that can be read by
the OCR.
7 different type styles may be recognized.
15. How do the TEMPEST modifications to the video Copier
afffect the physical appearance and use in an office
environment?
The in TEMPEST modification will not degrade the
use in an office environment in any major area.
16. What is the print speed of the Color Graphics Copier
on pages (8 1/2 x 11 in) per minute?…86…1 …02…
…02… …02… …02…
17. What is the length of time necessary to obtain
TEMPEST accreditation on the proposed equipment?
How do you plan to TEMPEST accredit the proposed
equipment? Has any equipment you manufacture been
TEMPEST accredited? What type of equipment was
TEMPEST accredited?
a) TEMPEST accredition is required for the following
equipment types:
1 Video Display Unit (VDU)
2 Color Graphic Display Unit (CGDU)
3 Video Copier
4 Letter Quality Printer (DIABLO 630)
5 Boxes for Local Area Network (X-Net) units:
- XTA
- XAB
- XCP
- XCP/CT
b) The VDU, the CGDU and the Video Copier have
already been proven to meet the TEMPEST requirements
by testing and by use.
c) The Letter Quality Printer needs to be formally
tested.
This test includes the following 5 Plans/Reports:
- TEMPEST Test Plan
- TEMPEST Test Evaluation Report
- TEMPEST Test Facility Certification Report
- TEMPEST Test Set-up Ampient Signal Control
Certification Report.
Assuming that each document is approved within
15 days after transmission the testing effort
is estimated to be accomplished within 12 months
after contract.
d) The local area network units needs a modification
to be adapted to TEMPEST requirements. No major
problems are anticipated for the network to
meet TEMPEST requirements, provided that proper
tubing is used for the bus cables, as recommended.
REV. 1 1983-03-10
The four X-net Units will be tested.
This test includes the following 5 Plans/Reports:
- TEMPEST Test Plan
- TEMPEST Test Evaluation Report
- TEMPEST Test Facility Certification Report
- TEMPEST TEMPEST Detection System Certification
Report.
- TEMPEST Test Set-up Ampient Signal Control
Certification Report.
Assuming that each document is approved with
15 days after submission, the testing effort
is estimated to be accomplished within 12 months
after contract.
18. Does your terminal(s) have any type of touch adjustment
control on the keyboard?
VDU: The keyboard is of the easy-touch type.
The delay and the repeat rate of the keys is adjustable
by menu.
The impact pressure required for activating a key
is not adjustable.
CGDU: The keyboard does not have touch adjustment.
The proposed keyboard does have a good tactile
feel and is the same keyboard as used on the model
5807 wsgt.
19. What is the pitch of the keyboard(s)?
VDU and CGDU have a keyboard pitch of 10 degrees.
20. What type of cable is used to connect the keyboard(s)
to the terminal(s). What is the length of the cable?
VDU: The keyboard is a stand-alone-item connected
to the VDU by a screened multicable
Length of cable: approx. 700 mm (27 inches).
Thickness of cable: approx. 9mm (.318 inch).
CGDU: A flat ribbon cable, with wire mesh shield,
encased in a plastic protective case is used to
connect the keyboard to the adp enclosure. The
cable length is 2 feet.
The keyboard is not attached to the desk top, but
sits on it. A cable length up to approximately
ten feet can be supported.
21. Will tilt and swivel capabilities exist on the
TEMPEST version(s) of your proposed terminal(s)?
Describe.
No
22. Will the TEMPEST version(s) of your proposed terminal(s)
screen(s) be height adjustable?
The TEMPEST version of the proposed terminals does
not include height adjusting whithin itself.
23.Will the TEMPEST version of your proposed Letter
Quality Printer support local alignment printing?
c. C̲o̲m̲m̲u̲n̲i̲c̲a̲t̲i̲o̲n̲s̲
1. Describe the proposed network topology. Show
how the communication network avoids single
point failure.
Please refer to FIG. 2.1.1-2. X-Net Local Area Network.
Regarding the Local Area Network Front-End System it
is seen that every terminal connection point has a
dualized X-Net bus for communication with one of the
two Processing Elements (PE's) of the front end system.
Each PE includes a dualized set of Processing Units
(PU's). Each PU has an I/O-bus to a channel unit (CU).
contains the PU's interface to a pair of mirrored (dualized)
discs. Furthermore, all 4 PU's of the 2 Front End PE's
are interconnected through a pair of dualized SUPRA-buses.
The Database System (Back-End System) consists of a
dualized PE. Each PU of the PE has an I/O-bus to a
dualized CU. Each CU has a dualized interface to a
pair of mirrored discs and a dualized Intelligent Database
Machine (IDM).
The discribed system topology ensures that no single
failure point exists, will create a total system failure
2. What is the available bandwidth? What media will
be used? Does the network allow voice communications?
How many simultaneously? Does the network video
communications? How many simultaneously?
The available bandwith one X-Net bus is 0.819 Mbit/sec.
The transmission media is a double twisted pair
screened cable.
The X-Net is a packet-switched network which is
not designed for voice communication. However,
video displays can be transmitted.
3. What is the aggregate data rate for terminal to
processor communications?
The aggregate data rate for terminal to processor
communication is 6.5 Mbit/sec.…86…1 …02… …02… …02…
…02…
4. What are the communication configuration procedures
governing the movement of CGDUs, VDUs, Letter Quality
Printers and Video Copiers from one communication
network outlet to another?
A reconfiguration from the operators console affecting
only the related terminal devices is required.
5. What size conduit is required by the network? How
much conduit is required? Provide a proposed layout
of the network signal cable for each building.
A layout showing the Local Area Network bus cable
distribution within each building is included in
this proposal, Part I, Subpart C, section 3.3.
The cables are run mainly in a 2 inch metallic
pipe. The position of Junction boxes are identified
on the drawings included in section 3.3. From the
junction box to the various X-net boxes (i.e. XTA,
XAB, XCP, XCT/CP) the bus cables are run in 5/4
inch metallic pipes. See FIG. I.3.3.2-13 for details.
The exact amount of piping required can be defined,
when the exact routing of the pipe is known.
6. Are modems, terminal concentrators, multiplexors,
on-line drivers required? How much space do they
require? Can they be located above the suspended
ceiling or do they have to be located on the floor?
What is the maximum distance allowed between line
drivers?
a) In the local area network (X-net) the follwoing
Units are distributed:
1 XTA-unit
2 XAB-unit
3 XCP-unit
4 XCP/CT-unit
In this proposal, PART I, subpart C, section
3.3.2.1 is shown the proposed network topology
(FIG. I 3.3.2-1 and I 3.3.2.2) identifying
the proposed location of these units.
The XTA- and the XAB-units are in the same
size box. The size of this box is approx. 12
x 8.5 x 4.5 inches (H x W x D). The XCP- and
the XCP/CT-units are in the same size box.
The size of this box is approx. 20 x 15 x 4.5
inches. The junction box inserted on the pipe
at the branch-off-point had the following dimensions
(approx.): 14 x 6 x 4 inches. (see FIG. I.3.3.2-13).
b) The XTA (X-net Terminal Adapter)-unit is placed
one for each terminal output (FIG. I.3.3.2-13).
c) The XAB (X-Net Amplifier and Branching)-units
are located to provide branching or amplification
on the bus.
When the cable distance on the X-net bus exceeds
800 m (approx. 2,000 ft) or the quantity of
attached XTAs exceeds 64, an XAB-unit is required
to support the next section. The next section
has the same limitations in length and quantity
of XTAs. Maximum 2 XABs are the X-net. A branch
ends in the main computer room.
d) The Boxes are designed for being mounted on
a wall, and the size allows placement above
suspended ceiling, if maintenance and security
requirements are met.…86…1 …02… …02… …02… …02…
7. How much space is required to connect terminals
to the network? What size junction box is required?
How many junction boxes are required? How do terminals
connect to the network? How far away can the terminal
be separated from the junction box? How are additional
junction boxes connected to the network?
In Part I, subpart C, section 3.3 is provided a
detailed description of the requirements and the
equipment involved in connection of a terminal.
The answer to question 6 above provides dimensions
of involved boxes. The cable distance from the
XTA-box (junction box) to the terminal must be
less than 50 ft.…86…1 …02… …02… …02… …02…
8. How will you implement the TCP and IP requirement?
When will it be available for delivery? Do you
currently have the TCP and IP implemented?
TCP and IP will be developed by Christian Rovsing
A/S for implementation on the CR80 computer. Christian
Rovsing A/S has extensive experience in protocol
development.
The TCP and IP will be available for delivery within
1 year from contract award.
Christian Rovsing A/S does not currently have the
TCP and IP implemented.
9. How does the communication network resolve resource
sharing (carrier sense multiple access/collision
detection (CSMA/CD), token, passing, etc.)?
Resources sharing between devices connected to
the X-Net is controlled and synchronized by the
X-Net controller.…86…1 …02… …02… …02… …02…
10. How many terminal devices will the proposed local
area computer network system (processors, software,
and communication network) support for each unique
configuration proposed, while fulfilling the requirements
specified in Section C (response time, availability,
workload, etc.)?
The proposed Local Area Network will support up
to 1024 connected devices while fulfilling the
response time, availability and workload requirements
specified in section C.
11. If processors are added to the system, how many
additional terminals could be supported (per processor)
and still maintain the system requirement in Section
C).
The DAMOS Kernel can control up to 16 PUs which
set the limit for expansion of the proposed configuration.
Thus the proposed system can be expanded with an
additional 10 PUs. If out of these 10 PUs the 8
are used for expansion of the Front-End System
it would allow for and additional 2048 terminal
devices to be connected to the system. The remaining
2 PUs shall be used for expansion of the Back-End
System. With an addition of CUs and IDMs corresponding
to the ratio in the proposed configuration the
expanded system will still meet the requirements
in section C.…86…1 …02… …02… …02… …02…
d. S̲o̲f̲t̲w̲a̲r̲e̲
1. What software capabilities will be provided through
hardware or firmware (DBMS, graphics, text editor,
etc.)?
The IDM stand-alone system comprises of a complete
relational database machine fully programmed for
this job. Though part of the processing is performed
by specialized hardware including:
o a general-purpose processor
o disc controllers
o 3 MB ram cache mamory
o front end I/O processors
o a high speed bus
(Ref. IDM Product Description page 1 right column
second paragraph).
2. Describe any priority control available for batch
versus interactive processing. Do either interactive
or batch programs have automatic priority? How
are priorities adjusted?
The user priority level is set by the System Administrator.
Interactive and batch programs that automatically
get a priority assigned determined by user priority
and job type. The priority assignment algoritm
can be changed by the System Administrator.
3. How many priority levels are available to the system
users?
Eight priority levels are available for the system
users.…86…1 …02… …02… …02… …02…
4. Describe how the recovery/restore and restart will
function. Identify any special coding required
in the application programs to support any recovery/restore
and restart software, and explain all required
operator interaction in the recovery process.
The proposed Highlevel Operating System (HIOS)
contains a checkpointing function which logs the
execution context at well defined points of execution
for all transactions.
At recovery the execution context is re-established
based on the last checkpoints stored prior to the
occured system failure.
Restart with a subsequent recovery can be initiated
either automatically or by means of a System Operator
command.
Checkpoints are generated by the individual application
programs. Checkpoint of user entries are generated
by the Terminal Package (TEP) providing the user
interface.
Checkpoints are logged and stored by HIOS.
5. Describe how the management reports (especially
response time reports and workload measurement
report statistics) are developed and what information
is provided in their ports. Show how the type and
number of transaction are tracked.
Management reports are established based on the
logged checkpoints. All checkpoints are timetagged
to facilitiate calculation of response time and
workload. At time intervals defined by the system
Administrator, all checkpoints from the previous
time interval are processed to provide intermediate
data for the specified report types. For instance
per command is calculated the number of transactions
and the response time-distribution expressed as
minimum, 25, 50, 75 - percent fractiles and maximum
response time.
6. Describe how user profiles are assigned and interactively
changed.
User profiles are kept in a User Catalogue.
Only the System Administrator has capabilities
to interactively make changes in the User Catalogue.…86…1
…02… …02… …02… …02…
7. Give an example of creating and sending an electronic
mail message. Show both prompts and user inputs.
A creation of a simplified electronic mail message
may contain the following prompt:
ELECTRONIC MAIL MESSAGES
TO:
ACTION:
INFO:
FROM:
SUBJECT:
TEXT
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
8. What compilers and assemblers are proposed?
With reference to section C7 item d the following
compilers and assemblers are proposed:
- COBOL
- PASCAL
- SWELL
- Assembler
- ADA (completion ultimo 83)
9. Will there be any problem in you making future
required changes to any of the delivered software
to run on the delivered hardware?
All proposed software is of modular design and
is documented in a way that any future required
change can be implemented with a minimum of effort.
10. Describe the method(s) of initiation and test capabilities
of the test and diagnostic procedures provided.
To what component level is fault isolation accomplished,
and what notifications of malfunctions are provided
to the operator?
By means of the on-line diagnostics programs it
is possible for the Watchdog-System to take recovery/switchover
decisions in the case of failures.
Subsequent to an automatic switchover the System
Operator can initiate troubleshooting on the off-lined
part of the hardware.
The troubleshooting is based on the error-message
printed on the Operator's printer subsequent to
switchover.
Tools for troubleshooting are provided by means
of a set of Maintenance and Diagnostics (M & D)
programs which each perform extensive tests of
a limited part of the hardware.
The M & D programs provide tools for fault isolation
to individual Printed Circuit Boards.
e. O̲p̲e̲r̲a̲t̲i̲o̲n̲ ̲S̲y̲s̲t̲e̲m̲
1. Explain how the operating system concurrently supports
interactive processing and batch processing.
Two separate ready-queues are established for execution
of interactive- and batch jobs.
2. In addition to the description provided in response
to Section C, paragraph C7b(17)(d), describe your
recommendations for providing other analysis software
and reporting facilities (based upon the configuration
proposed) required to support the most effective
utilization management of the system.
Tracking of user- and job priority in relation
to response time and workload could be a useful
parameter for utillization management.…86…1
…02… …02… …02… …02…
f. E̲l̲e̲c̲t̲r̲o̲n̲i̲c̲ ̲M̲a̲i̲l̲
1. Describe, if proposed, your informal mail/memo
facility or capability.
The input format for informal mail/memo is partly
in fixed format and a free format. The fixed format
portion is provided to ease input validation (syntax,
semantic) of addresses, originators etc., while
the actual text is in free format.
2. Describe your approaches to formal and informal
communications.
Formal communication as opposed to informed communication
will contain more required input fields.
3. Describe, if proposed, the electronic mail subsystem's
facility or options allowing the creation of letterhead
copies or correspondence.
An input prompt may be created by the user to provide
printing of letterhead field in a standerdized
way.
4. Describe the editor used for electronic mail.
The editor used in the electronic mail will be
a general editor used every in the system. It
inclused standard featrues like insert/delete characters
and lines. The VDU itself also includes an off-line
character string search and replace feature.…86…1
…02… …02… …02… …02…
g D̲B̲M̲S̲
1. What data management facilities (Database Management
System (DBMS), dictionary, query system, etc.)
are you proposing?
The proposal includes the following DBMS facilities:
a) A general-purpose query language (IDL) used
as a programming tool for application programs,
which controls the user interface for on-line
and batch processing (ref. IDM page 5-8 part
5.5).
b) A relational database management system (IDM),
which is a complete non-procedural stand-alone
DBMS. The configuration includes two IDM systems
updated in parallel (ref. IDM page 1 first
paragraph).
c) A file support (IDM facility) for traditional
data storage for sequential and random access
(ref. IDM Software Reference Manual page 5-11
part 5.7).
d) A report writer especially designed for relational
database concept on IDM for the ACCESS system.
2. Please illustrate how the following queries would
be coded in the system that you are proposing.
Include simulation of any necessary file or data
specification statements and assume that the response
will be directed back to the inquirer's Video Display
Unit (VDU).
a. List all non-high school graduates in Division
123 showing name, rank, serial number, years
of service, and unit.
It is assumed that airman and officer data are
all placed in one relation named "PERSONNEL" with
the data elements shown in RFP figure c-11, and
C-12 and that
o non-high school graduates means ED-LVL B
o division 123 means ORG-DET-NO = 123
o name means NAME
o rank means the abbreviation from nomenclature
table in RFP FIG. C-23 identified by GR-CURR
o serial number means SSAN
o years of service means 82-(year of ADSCD (named
ADSCY))
o unit means ORG-NR
The conversion from GR-CURR TO RANK is made by
a table look-up in the relation NOMENCLATURE with
GR-CURR as key and RANK as target data.
The query will then be phrased
RANGE OF N IS NOMENCLATURE
RANGE OF P IS PERSONNEL
SHOW ( P. NAME, N.RACK, P. SSAN, AGE = (82-P.ADSCY),
P.ORG-NR)
ORDER BY P.GR-CURR, P.NAME
WHERE P.ORG-DET-NO = "123"
AND P.ED-LVL B
AND P.GR-CURR = N.GR-CURR
The "ORDER BY"-clause is not necessary but usually
the presentation has to be ordered so a general
view can be made. Any response will automatically
be sorted in ascending order by the first referred
attribute if not order by clause is input.
The table look-up for RANK may be replaced with
a reference to a permanent view (named RANK) to
avoid explicit definition of the case in which
the query may be phrased with RANK replacing N.RANK
and the last AND-clause ommitted.
b. Show the cost and budget for civilian pay at
all bases (by base) for the last twelve months
and totals for each month plus a crossfoot
total.
It is assumed that the relation "BUDGET" holds
data as shown in RFP FIG. C-30 and that
o cost means major procurement delivery (named
MPDEL)
o budget means major procurement (named MPPRO)
o civilian pay means cost element code 30001XXXX,
5239XXX and 5541XXXX from RFP FIG. C-26A (named
CEC)
Information about fiscal period (year and month
named FYYMM) and base name (named BASE) is assumed
included in the BUDGET-relation.
The query will then be phrased in four commands.
The first command extracts the relevant data from
the BUDGET-relation, computes and stores the minor
totals and identifications in a separate relation
"TEMP-BUDGET". The three last commands extracts
from the TEMP-BUDGET relation totals per base,
totals per month and crossfoot totals. All commands
are part of the same transaction, so they will
be executed together and the result presented as
one response containing three tables.
RANGE OF B IS BUDGET
RANGE OF TB IS BUDGET
RETRIEVE INTO TEMP.BUDGET
(B.BASE, B.FYYMM, TOT.COST = SUM UNIQUE
(B.MPDEL BY B.BASE, B.FYYMM),
TOT.BUDG = SUM UNIQUE
(B.MPPRO BY B.BASE, B.FYYMM)
WHERE B.FYYMM 8112 AND
B.CEC = "3001 " OR
B.CEC = "5239 " OR
B.CEC = "5541 "
SHOW (TB.BASE; COST = SUM UNIQUE (TB.TOT ̲COST
BY TB.BASE), BUDG = SUM UNIQUE (TB.TOT ̲BUDG BY
TB.BASE)) ORDER BY TB.BASE
SHOW (TB.FYYMM, COST = SUM UNIQUE (TB.TOT ̲COST
BY TB.FYYMM), BUDG = SUM UNIQUE (TB.TOT ̲BUDG
BY TB.FYYMM)) ORDER BY TB.
FYYMM
SHOW (CROSS ̲COST = SUM (TB.TOT ̲COST), CROSS ̲SUDB
= SUM (TB.TOT ̲BUDG))
3. Describe and give an example of the interface between
your DBMS and the graphic subsystem.
Two interfaces between DBMS and the graphics subsystem
are available, one to transform a table into a
graphic presentation and another to deal with stored
graphics (the latter as a function of the graphic
subsystem).
To transform a table into a graphic presentation,
the table is to be placed in the VDU working file.
This is done by issuing a query through the application
screen formatter program in the usual…86…1
…02… …02… …02… …02…
way. When the response is received (shown on the
screen or not), the graphic subsystem is invoked
by menu driven request. In the menu of the graphic
subsystem, the specifications for graphic display
is chosen referring to the table stored in the
terminal working file.
Example: Make a curve showing the number of seating
capacity at the table as a function of the total
seating capacity of conference rooms and other
facilities.
Query to load the table into the VDU working file:
RANGE F IS FACILITIES
RETRIEVE (F.SEAT ̲AT ̲TABLE, F.SEAT ̲TOTAL)
ORDER BY F.SEAT TOTAl,
F.SEAT ̲AT ̲TABLE
Response example:
F.SEAT ̲AT ̲TABLE F.SEAT ̲TOTAL
5 8
7 8
10 15
12 25
Invoking the graphic subsystem by menu request
and selecting "curve"-display, the following graphic
display is shown on the screen:
F.SEAT ̲AT ̲TABLE
FIGUR
4. Describe how your DBMS maintains the integrity
of the structure and contents of the data base.
Identify and describe the functions of any utility
programs that are used in integrity processing.
Integrity maintenance of the DBMS is a main function
of the IDM system, known as transaction management.
All accesses to the database is performed in groups
of commands, called transactions. A transaction
is defined by the user as all the commands necessary
to carry out a consistent database operation. Each
transaction is given exclusive access to all datablocks
involved by the transaction as a whole, though
datablocks only used for reading may be shared
by several transactions. Conflicts between transactions
trying to access the same datablock with non-matching
operations between transactions trying to access
the same datablock with non-matching operations
(not all are reads) is solved by putting the latter
arriving transactions in a waiting queue to be
started again later. Thus transactions will appear
to be executed in sequence, though they are in
fact usually executed simultaneously. (Ref. IDM
Product Description, page 8, 1st para, left COL.).
The database is not effectively updated until all
commands in a transaction are completed. So if
for any reason, i.e. break down or abort from user,
the transaction is not completed, the database
is not affected by the transaction at all. (ref.
IDM, page 1-5 part 1.2.2). The database structure
is logically defined by the user dynamically relating
data items while accessing the database. No internal
structure has to be maintained by the system apart
from the attributes belonging to a relation, which
is defined by the database administrator or by
the user (for private relations or views only).
As the transaction management is under full control
by the IDM, no utility programs are involved to
secure data integrity.
5. Describe how you implement protection against simultaneous
update. What happens to impacted applications programs?
The databases are effectively protected against
simultaneous update operations by the transaction
management concept, see 4. above. Any two or more
transactions, which tries to access the same datablock
with non-matching operations (not all are reads)
will be executed serially instead of the usual
parallel execution. In fact even reading transactions
carefully consistent as they are queued if a writing
transaction on the same datablock is in progress.
In the same way an updating transaction will be
queued if a reading transaction on the same datablock
is in progress.
The application programs are in no way impacted
by the transaction management as they are not even
informed of any possible simultaneous update situation.
6. Describe the logic and technique used to resolve
deadlock conditions. What happens to impacted programs?
When two or more transactions deadlock, the situation
is discovered by the IDM system and all but one
of the transactions are placed in the queue to
be started again later. As no transaction effectively
impact the datablock until end of transaction is
reached due to the back-out procedure, no inconsistency
rise from this. Though in few complex situations,
the IDM will not be able to restart a transaction
and return an abort message to the back-end computer
giving the reason for the abortion. The back-end
computer will then reissue the transaction.
7. Describe how the system would be recovered from
a condition where one database disc becomes unuseable.
Describe how availability standards would be met.
After recovery is accomplished, how current is
the data base?
During normal operation, the back-end computer
logs each transaction issued to the IDM systems
on its own disc storage together with IDM transaction
number (from each IDM) and marks each transaction
for completion in each IDM system when signalled.…86…1
…02… …02… …02… …02…
In case of break down of one IDM system, this procedure
continues, as the other IDM system continues normal
operation, though no IDM transaction number and
completion signal is returned from the IDM system
which broke down. As soon as the break down is
discovered by the control process, it stops issuing
transactions to the downed IDM system for the data
bases affected. Issued read transactions waiting
for completion from the downed IDM system is then
reissued to the running IDM system. Recovery of
the data bases affected by the break down is first
performed as a standard IDM procedure which goes
like this. At first the database dumps are loaded
from backup copies. Then transaction logs are loaded
for each database in question and applied to the
database by the rollforward command inclusive as
much of the active transaction log as possible.
The affected data bases have now been brought to
the same status as at time of the break down except
for started transactions not completed by then.
From here the control process continues in order
to synchronize the two IDM systems. From the running
IDM system, the relevant transaction logs covering
the period from before the point of break down
or the last recoverable transaction until this
time is copied into the backup transaction log
for the recovering IDM system and applied to the
data bases. For each transaction recovered this
way the completion markd for the recovering IDM
system is applied to the transaction log with transaction
number from the running IDM system. When this phase
is completed, the issuing of all transactions for
the affected data bases to both IDM systems is
interrupted and after completion of the running
transactions on the running IDM system, the remainder
transaction logs are copied and applied to the
data bases on the recovering IDM system as described
above including completion signals to the host
computer systems. During this phase, the back-end
computer queues the relevant transactions for later
issue. When this phase is completed, full recovery
with no loss of data is accomplished and the back-end
computer checks that all transactions issued so
far have had completion signalled for both IDM
systems and resumes normal operations, thus starting
to issue queued transactions.
If transactions during the checking procedure proves
incomplete for both IDM systems, they have to be
reissued while transactions with completion for
only one IDM system indicates a system error to
be output and dealt with by the database administrator.
Apart from the prolongation of response time during
the last phase of recovery the end-user will experience
no impact from the whole operation.
8. Describe the database structure used.
The IDM system runs a relational database concept,
which implies that no prearranged structure is
defined, thus any structured view on the data is
usable if it is relevant for the actual user.
Data is logically arranged in two dimensional tables
(like files) called relations containing a number
of tuples (like records) with identical formats.
Each relation or tuple is characterized by the
attributes (like datafields) it holds. As data
is accessed only by the names of relations and
attributes, they are related to each other only
by value (when asked for).
Each database contains a number of system-relations,
which describe the database and its use both for
internal data management and as information to
the user. One of these is the "relation"-relation,
which is a catalogue of all objects in the data
base. An object is a relation, view, file (non-database
data), stored command or stored program. The "attribute"-relation
is another system relation, which describes format,
sequence (in tuple) and name of the relation to
which it belongs (ref. IDM Software Reference Manual
page 3-3 part 3.2). The tuples of a relation are
arranged in random order by choice of the IDM system.
Though to facilitate predefined access to data
ordered index's may be built on request by the
user. An index may refer to any one or more attributes
of a relation and is ordered by value (or concatenated
values) actually existing for the attribute(s).
The index contains a pointer to the physical datablock,
where the value (-combination) is stored, and is
maintained by the system when the relation is updated.
Up to 250 index's may be created per relation one
of which at the same time can force the tuples
in the relation itself into the same order (clustered
index).
The index's are automatically used for data access
when appropriate without concern of the user or
application program (ref. IDM Software Reference
Manual page 3-15 part 3.6.1).
9. Describe the information available from the data
dictionary.
The relational database is in itself one big dictionary,
thus the distinction between data dictionary and
database which is used for data access or as user
information. The user may read nearly any information
stored, if permission is granted by the database
administrator. Some information may equally be
input by the user for his own convenience, and
interrogation of this data is subject to user defined
queries as the rest of database.
As available data dictionary information in this
respect is as follows (ref. IDM Software Reference
Manual appendix A).
From the system database:
1. relation "databases" containing per database:
o database name
o database administrator (uiser-id)
o time stamp for last dump or load
o id of last check point
2. relation "disc" containing per disc:
o disc name
3. relation "lock" per transaction holding lock
(exclusive operation):
o transaction number
o lock range
o type of lock
o internal relation id
4. relation "configure" per host computer system:
o interface type and configuration or checkpoint
time interval (per system)
For each database the following information is
available (in respect to above).
1. relation "relation" per relation, view, file,
stored command or stored program:
o name of relation (object)
o user id of relation's owner (creator)
o internal relation id-number
o number of tuples
o user defined maximum size
o tuple maximum length
o type code for the relation (object)
o number of attributes
o user defined expiration date
o creation date
2. relation "attribute" per attribute per relation:
o sequence number (in tuple)
o type
o maximum length
o relation-id (internal number)
o name of attribute
3. relation "index's" per index:
o index id-number
o relation id-number
o attributes included
4. relation "protect" per type of access and user-id:
o type of access
o relation id-number
o user id
o bit-map of permissions per attributes
5. relation "query" per line of stored command
or view:
o line sequence number
o command id-number (relation id)
o command text
6. relation "crossref" per dependency among relations,
views and stored commands:
o type of dependency
o relation id-number
o relation id of dependant object
7. relation "transact" per updating transaction
against relations marked for logging:
o type of record
o transaction id-number
o relation id-number
o tuple id-number
o before and after values (for audit and
recovery only)
8. relation "batch" per transaction (temporary)
per transaction against non-logged relations
(as 7. above).
9. relation "descriptions" per attribute:
o attribute id-number
o relation id-number
o user setable key
o user setable attribute description
10. relation "users" per user/database:
o attribute for user status
o user id-number
o group id-number
o user name
o user programmable attribute
11. relation "host-users" per user/host computer
system:
o id-number of host computer system
o user id-number on host computer system
o IDM user id-number
12. relation "blockalloc" per disc block:
o block number
o mode for usage
o error statistics
o relation id-number
13. relation "disc-usage" shows disc usage per
relation.…86…1 …02… …02… …02… …02…
10. Describe all interfaces between the data dictionary,
application subsystems and the database itself.
Interface to the data dictionary, as defined in
paragraph 9 above, is merely a matter of data usage
on the part of the database administrator, the
user, the application program and the IDM system
itself.
The database administrator created the database
by setting up the physical specifications of the
database for the IDM system. This includes storage
of user/host-id conversion tables and user access
permissions.
The users may directly interrogate the data dictionary
so far as permission is granted by the database
administrator, inclusive the output of an audit
report generation from the transactions logged
by IDM.
Furthermore, the users maintain stored commands
and views for data to which they have access permission.
The application subsystem programs use the data
directory information for conversion of external
user-id into IDM user/host-id. A control process
reads the transaction-log to check that the IDM
systems are both running, and uses it for sysnchronization
of the two IDM systems after breakdown; see 7.
above.
The IDM system maintains the data dictionary automatically
as changes are made in contents of tuples, relations,
index's and in the physical position of data.
Any reference to data is checked for user access
permission and the data dictionary is used to reach
the data. For recovery and audit purposes, the
transaction log, the check points and the database
dumps are established if so requested. (Ref. IDM
Software Reference Manual page 3-3, part 3.2).…86…1
…02… …02… …02… …02…
11. Describe the capabilities and techniques used to
expand/contract records, create/delete relationships,
and any other dynamic restructuring functions available
in your DBMS. Describe the physical and logical
restructuring capabilities.
The capability to expand/contract "records" is
provided by the "retrieve into" command. The data
from the "old" relation is hereby copied into the
"new" relation with respect to all deferences between
the definitions of contents (attribute formats)
in the two relations. The "new" relation does not
have to exist in advance as attribute specifications
can be explicitly stated where it differs from
the "old" relation, though the index's, if any,
will have to be defined separately. After the data
has been copied, the "old" relation is destroyed
and the "new" relation is renamed to the proper
name (of the "old" relation). Views and stored
commands may need recreation depending on the actual
change in attribute format. (Ref. IDM Software
Reference Manual page 2-7, part 2.1.8).
Except for attributes belonging to relations, no
predefined relationships exists between data in
the database. Thus all relevant relationships are
dynamically forced upon the data as defined by
the actual phrasing of each command in the database
transactions. Means of restructuring the database
is not required but logical rearrangement of ordered
data (records) may be applied by use of index.
Ordered relations may physically accumulate unused
space inside datablocks, which may be freed by
simply recreating the clustered index. (Ref. IDM
Software Reference Manual page 3-16, part 3.6.2).…86…1
…02… …02… …02… …02…
12. Will a request for a logical record that is in
primary storage sometimes result in secondary storage
retrievals? If so, explain.
No request for a logical record (tuple) that is
in primary storage of the IDM will never result
in secondary storage retrieval.
13. Do you support encrypting/decrypting/decrypting
of data files?
No, presented by the IDM system stores and delivers
all data exactly as communicated by the back end
computer. Encryptions/decryptions of data files
can be provided if requested.
14. Do you support encrypting /decrypting as an integral
of your DBMS?
No, presented by the IDM system stores and delivers
all data exactly as communicated by the back end
computer. Encryption/decryption of all data can
be integrated into the IDM if requested.
15. Do you support audit logs in your DBMS?
Audit logs are supported for updating transactions,
when the subject relations are defined with request
for transaction logging. The command "audit (into)"
transforms the transaction log providing the following
information per subject relation/transaction:
o date and time of update
o user id number
o relation id number
o transaction number
o type of update
o changed data values
Extended audit information may be derived from the
transaction log on the back end computer. (Ref. part
4.2.2 C3.3 below).…86…1 …02… …02… …02… …02…
16. Describe the database access mode available.
The IDM system can store data either as a relational
database or as files.
The file support offers the ability to write and
read whole files sequentially and to access single
records at random by record number. All structuring
of data as known from traditional file organization
as hierarchical and network structures is the responsibility
of the application programs as is the identification
and position of data. However, the present system
concept is not using this facility though use of
it might prove valuable later on. (Ref. IDM Software
Reference Manual page 5-11, part 5.7).
The relational database offers all the same access
modes as do traditonal file access methods, i.e.
sequential, indexed sequential and random access
and so on. There are, however, several crucial
differencies where the IDM relational approach
exceeds the general idea of data access modes.
The most striking one is the thorough identification
of data by names and values alone, leaving no problem
of navigation or data positioning to be attended
by the application programs. Data is stored in
logical two dimensional tables called relations.
Each relation is defined to contain up to 250 unique
data element fields (called attributes), which
each may hold a value (called attribute value)
which complies to the defined format of the attribute
(i.e. character, binary integer). For each appended
unique combination of attribute values in a relation,
one record (called tuple) is stored.
Access to data now actually means to identify one
or more target tuples, which is done simply by
stating the minimum number of combined attribute
values, which is unique for the tuple or the group
of tuples to be reached from each up to 15 different
relations. Some relations may hold an attribute,
which contains unique key-values for the tuples,
i.e. part number, thus any attrubute may participate
alone or combined with others in the identification
of tuples.…86…1 …02… …02… …02… …02…
Attribute values for identification need not be
known explicitly but may be stated by evaluation
of expressions or by reference to another attribute
even in another relation. Using a reference to
an attribute in an other relation actually describes
relationship dynamically invoked by the user and
it does not have to be defined prior to the user.
Any such relationship which the user finds relevant
may be implemented any time. (Ref. IDM Software
Reference Manual page 1-1, part 1.1.1).
To find in a relation the group of tuples matching
some combination of attribute values demands a
scan through all tuples as they are not ordered
IDM. In order for increase performance and decrease
response time ordered index's should be created
from the most frequently used identifying attributes,
yet the ordering of response data is freely chosen
by user stated by the "order by" clause in each
query. (Ref. IDM Software Reference Manual 3-15,
part 3.6.1).
17. Describe the capability of accessing by multiple
users for interactive and batch processing for
both updates and retrieval of information.
The IDM system handles user accesses in groups
of commands (called transactions) in order to preserve
database consistency. Each transaction is identified
by a transaction id. Number issued by the IDM system
to be used in all communication between the IDM
system and the host computer systems. To The IDM
system, the unique host- and user identification
is attached to each transaction thereby giving
the ability to serve a number of users from each
of up to eight different host computer systems.
Actually only the back end computer is declared
as an IDM host computer. Now all transaction starts
issued to the IDM system will be enrolled immediately
and transaction id. Number returned due to the
separate function of the IDM front end I/O processors.…86…1
…02… …02… …02… …02…
The IDM allows an arbitrary number of transactions
to be served simultaneously, scheduling among them
in a priority given by IDM, which depends on various
parameter. As the commands belonging to one transaction
may be communicated interactively, a transaction
sometimes has no command to be executed. In this
case and in case of insufficient main storage,
transaction processes may be moved to temporary
storage on disc.
A function called Transaction Management secures
every transaction to be handled with exclusive
access to all data blocks. Concurrent access from
a number of transactions is solved by queuing
the transctions to be continued, one at a time.
Dead lock situations are solved by queuing transactions
in the same way but the transactions queued are
backed out from updates completed and restarted
from the beginning. (Ref. IDM Software Reference
Manual page 3-9, part 3.3.2). As the IDM system
is not informed about the program mode in the host
computer system being on-line or batch, no difference
in performance or access control flexibility occurs
from mixing these modes by the application subsystems.
18. Describe the queuing path.
The queuing path is composed of command and data
communication through:
1 Host computer systems, which interact with
the users through screen formatter programs
due to the application subsystem chosen and
output formatted response data.
2 Back end computer, which communicates with
the host computer systems, passing user query
commands into IDM communication language, communicates
IDM commands to the IDM systems and response
data from the IDM systems to the host computer
systems. The IDM communication includes control
of parallel updates in the two IDM systems,
flip-flop selection of IDM system for strict
data retrieval, transaction logging for short
term recovery and extended audit functions
as well as functions for check and control
procedures for IDM dump and recovery situations.
3 IDM systems, which individually communicate
with the back end computer on transaction grouped
commands, accesses the databases, and communicate
response data for each command. The multiple
transaction process for the IDM system is described
in question 17. above.
19. State the response time requirements for execution
of complex commands resulting in extensive file
searches or graphic outputs, i.e. the proposed
response times for the time between entry of a
complex search command and (a) the appearance of
the first line of results on the user's display
terminal and (b) the initiation of a graphic display
on the user's display terminal.
Due to the queuing path described above (18) response
time requirements depends on several steps of data
communication, data computation and data access.
However, the hardware and software of each step
have been carefully selected and designed especially
to undertake each single process involved. So the
response time requirements are minimized efficiently
to provide a high capacity for the over all system
performance and a fast reaction upon every user
input. A general statement about response times
on the IDM will be that in average response times
will be approximately only 10 to 50 per cent of
response times on conventional DBMS systems.
h. L̲a̲n̲g̲u̲a̲g̲e̲ ̲P̲r̲o̲c̲e̲s̲s̲o̲r̲s̲
1. What fourth generation languages are available?
PASCAL, SWELL and ADA.
2. What application generator aids are available?
Query Language and Report Writer.
3. What programming tools are available?
An interactive editor and source text formatting
programs.
i. G̲e̲n̲e̲r̲a̲l̲ ̲U̲t̲i̲l̲i̲t̲i̲e̲s̲ ̲(̲F̲i̲l̲e̲ ̲M̲a̲n̲a̲g̲e̲m̲e̲n̲t̲ ̲S̲y̲s̲t̲e̲m̲)̲
1. Explain your method of expanding and reducing
space allocated for catalogued files.
Required file space is specified at file
creation.
A system parameter specifies the number
of file generations that shall be retained.
A command exists to delete a specified
number of retained file generations.
2. Is space available from deleted records
able to be reused?
Yes.
j. T̲e̲x̲t̲ ̲E̲d̲i̲t̲o̲r̲
1. Describe your text editing to add, delete,
replace, search and modify lines, characters
and strings of characters in files with
cursor motion (screen-oriented editor).
The text editing in screen-oriented mode
allows easy add, delete, replace of characters
and lines by placing the cursor in the
appropriate place and put the terminal
in the required mode, i.e. insert character/line
or delete character/line etc.
The VDU also allows search and modification
of strings to be performed locally in the
VDU.
2. Does your system support function keys
for use in text editing? If so, what are
they?
Yes, the standard editing keys, like insert/delete
character/line are available.
The standard VDU also have user programmable
functions keys, where the user can retain
any character or command key sequence he
wants to reuse.
