top - download
⟦bb6aaedd4⟧ Wang Wps File
Length: 57457 (0xe071)
Types: Wang Wps File
Notes: ACCESS, TECHNICAL PROP.
Names: »3216A «
Derivation
└─⟦550b0bab9⟧ Bits:30006219 8" Wang WCS floppy, CR 0276A
└─ ⟦this⟧ »3216A «
WangText
*…05…)…08…)…0a…)…0d…)…01…)
)…86…1 …02…
…02… …02… …02…
1. SUBPART A - TECHNICAL LITERATURE ............
2. SUBPART B - SYSTEM CHARACTERISTICS ..........
2.1 SYSTEM OVERVIEW ...........................
2.2 CONFIGURATION .............................
2.3 SYSTEM QUESTIONNAIRE RESPONSE .............
3. SUBPART C - HARDWARE CHARACTERISTICS ........
3.1 HARDWARE OVERVIEW .........................
3.2 HARDWARE COMPONENTS .......................
4. SUBPART D - SOFTWARE CHARACTERISTICS ........
4.1 SOFTWARE OVERVIEW .........................
4.2 SOFTWARE PACKAGES .........................
4.2.1 Communication Software ................
4.2.2 System Software .......................
4.2.3 Applications Software .................
5. SUBPART E - FUNCTIONAL LIVE TEST
DEMONSTRATION (FLTD) CHARACTERISTICS ........
5.1 FLTD PERFORMANCE STEPS ....................
5.2 FLTD DOCUMENTATION OUTLINE ................
6. SUBPART F - PROPOSED SYSTEM FACILITY ........
6.1 PROPOSED SYSTEM FACILITY REQUIREMENTS .....
6.2 TOTAL REQUIREMENTS ........................
6.3 SYSTEM RELIABILITY, SHUTDOWN AND RECOVERY .
7. SUBPART G - CONTRACTOR SUPPORT ..............
7.1 CONTRACTOR SUPPORT QUESTIONNAIRE ..........
7.1.1 Maintenance ...........................
7.1.2 Training ..............................
7.2 ADDITIONAL SUPPORT ITEMS ..................
7.2.1 Installation ..........................
…0c……0c……0c… sections 4. - 4.2.3. are to be found in Doc 3181A…0c……0c…
1. S̲U̲B̲P̲A̲R̲T̲ ̲A̲ ̲-̲ ̲T̲E̲C̲H̲N̲I̲C̲A̲L̲ ̲L̲I̲T̲E̲R̲A̲T̲U̲R̲E̲
This subpart contains a complete list of the technical
literature which is provided with the proposal. Each
item of technical literature is identified by a unique
list number and title. For each document listed, a
sublist of components (software, hardware, etc.) described
in the document is given, including the order number
and common name of the proposed component(s) as used
in the price tables, section B.
2. S̲U̲B̲P̲A̲R̲T̲ ̲B̲ ̲-̲ ̲S̲Y̲S̲T̲E̲M̲ ̲C̲H̲A̲R̲A̲C̲T̲E̲R̲I̲S̲T̲I̲C̲S̲
2.1 S̲Y̲S̲T̲E̲M̲ ̲O̲V̲E̲R̲V̲I̲E̲W̲
TBS.
2.2 C̲O̲N̲F̲I̲G̲U̲R̲A̲T̲I̲O̲N̲
a. Human Factor Considerations
b. Configuration Requirements
c. Functional Availability
d. Architecture
e. TEMPEST Requirement
f. Workload Specifications
g. Augmentation
2.3 S̲Y̲S̲T̲E̲M̲ ̲Q̲U̲E̲S̲T̲I̲O̲N̲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.
2. Describe the proposed system topology. Show
how the fault tolerant capabilities of the
system architecture avoid single point failure.
3. Describe the architecture including how multiple
processors and the I/O network are linked.
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?
2. Describe how peripherals are shared or switched
on the system.
3. Describe the steps necessary to add additional
processors to the system?
4. How did you determine the amount of IAS that
was necessary to meet the system data storage
requirements?
5. What is the average access time of the IAS?
What is the formatted amount of data capacity
of each IAS device proposed?
6. What is the page (8 1/2 x 11 in) print speed
of the High Speed Non-Impact Printer?
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?
8. What is the display area of the VDU in square
inches?
9. How are the VDU and CGDU similar in appearance,
operation, keyboard and screen size?
10. What are the terminal refresh rate and presistance
quality of the phosphor on the CGDU? Is the
display screen interlaced or non-interlaced?
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?
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?
15. How do the TEMPEST modifications to the Video
Copier affect the physical appearance and use
in an office environment?
16. What is print speed of the Color Graphics Copier
in pages (8 1/2 x 11 in) per minute?
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?
18. Does you terminal(s) have any type of touch
adjustment control on the keyboard?
19. What is the pitch of the keyboard(s)?
20. What type of cable is used to connect the keyboard(s)
to the terminal(s). What is the length of the
cable?
21. Will tilt and swivel capabilities exist on
the TEMPEST version(s) of your proposed terminal(s)?
Describe.
22. Will the TEMPEST version(s) of your proposed
terminal(s) screen(s) be height adjustable?
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.
2. What is the available bandwidth? What media
will be used? Does the network allow voice
communications? How many simultaneously? Does
the network allow video communications? How
many simultaneously?
3. What is the aggregate data rate for terminal
to processor communications?
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?
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.
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?
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?
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?
9. How does the communication network resolve
resource sharing (carrier sense multiple access/collision
detection (CSMA/CD), token, passing, etc.)?
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.)?
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)
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 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 memory
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?
3. How many priority levels are available to the
system users?
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.
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 transactions are tracked.
6. Describe how user profiles are assigned and
interactively changed.
7. Give an example of creating and sending an
electronic mail message. Show both prompts
and user inputs.
8. What compilers and assemblers are proposed?
9. Will there be any problem in you making future
required changes to any of the delivered software
to run on the delivered hardware?
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?
e. O̲p̲e̲r̲a̲t̲i̲n̲g̲ ̲S̲y̲s̲t̲e̲m̲
1. Explain how the operating system concurrently
supports interactive processing and batch processing.
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.
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.
2. Describe your approaches to formal and informal
communication.
3. Describe, if proposed, the electronic mail
subsystem's facility or options allowing the
creation of letterhead copies or correspondence.
4. Describe the editor used for electronic mail.
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 conduct the user interface
for on-line and batch processing (ref.
IDL page ?????).
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 page 5-11 part 5.7).
d) A report writer (ACE) especially designed
for relational database concept on IDM
(ref. ACE page ????).
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 gruduates in Division
123 showing name, rank, serial number,
years of service, and unit.
It is assumed that airman and officer data
all are 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 figure C-23 identified by
GR-CURR
o serial number means SSAN
o years of service means 82-(year of ADSCD
(name of ADSCY))
o unit means ORG-NR
The conversion from GR-CURR to RANK is made
by a table lookup 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 no order
by clause is input.
The table lookup 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 omitted.
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 figure 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 5541XXX from RFP figure 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 ND
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
TB.FYYMM)
ORDER BY TB. FYYMM
SHOW (CROSS ̲COST = SUM (TB.TOT ̲COST), CROSS
̲BUDG = 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, see ???).
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 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.
(Ref. ???).
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 access 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 (not all are reads) is solved by
putting the later arriving transactions in
a waiting queue to be started again later.
Thus transactions will appear to be executed
in sequence, though
they in fact are 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 effectly protected against
simultaneous update operations by the transaction
management concept, see 4. above. Any two or
more transactions, which proves 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 are fully consistent
as they are queued if a writing transaction
upon the same datablock is in progress. In
the same way an updating transaction will be
queued if a reading transaction upon 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 returns 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 disk 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.
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 the
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 mark for the recovering
IDM system is applied to the transaction log
with transaction number from the running IDM
system. When this phase is completed ?????
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 are 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 are 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 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
indices 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 indices
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 indices are automatically used for data
access when appropriate without concern of
the user or application program (ref. IDM 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 is arbitrary indeed.
Anyway, the IDM system offers some information
about the 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 appendix
A).
From the system database:
1. relation "databases" containing per database:
o database name
o database administrator (user-id)
o time stamp for last dump or load
o id of last check point
2. relation "disk" 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 as 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 "indices" 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.
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 creates 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 synchronization 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, indices 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
page 3-3, part 3.2).
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 differences 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 indices, if
any, will have to be defined separately. After
the data have 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 page 2-7, part 2.1.8).
Except for attributes belonging to relations,
no predefined relationships exist 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. By 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 page 3-16, part
3.6.2).
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 of data
files?
No, the IDM system stores and delivers all
data exactly as communicated by the back end
computer.
14. Do you support audit logs in your DBMS?
No, the IDM system stores and delivers all
data exactly as communicated by the back end
computer.
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 ???).
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 in random by record number.
All structuring of data as known from traditional
file organization as hierarchcal and network
structures is the responsibility of the application
programs as in 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 page
5-11, part 5.7).
The ralational database offers all the same
access mode as do traditional 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 if navigation of
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
attribute may participate alone or combined
with others in the identification of tuples.
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 use. Any such relationship which
the user finds relevant may be implemented
any time. (Ref. IDM page 1-1, part 1.1.1).
To find in a relation the group of tuples matching
some combination of attribute values demand
a scan through all tuples as they are not ordered
by IDM. Increasing performance and decreasing
response time ordered indices 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 page 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 transactions start 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.
The IDM allows an arbitrary number of transactions
to be served simultaneously, scheduling among
them in s priority given by IDM, which depends
on various parameters. 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 disk.
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 transactions 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 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.
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?
2. What application generator aids are available?
3. What programming tools are available?
i. G̲e̲n̲e̲r̲a̲l̲ ̲U̲t̲i̲l̲i̲t̲i̲e̲s̲ ̲(̲F̲i̲l̲e̲s̲ ̲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.
2. Is space available from deleted records able
to be reused?
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).
2. Does your system support function keys for
use in text editing? If so, what are they?
3. S̲U̲B̲P̲A̲R̲T̲ ̲C̲ ̲-̲ ̲H̲A̲R̲D̲W̲A̲R̲E̲ ̲C̲H̲A̲R̲A̲C̲T̲E̲R̲I̲S̲T̲I̲C̲S̲
3.1 H̲A̲R̲D̲W̲A̲R̲E̲ ̲O̲V̲E̲R̲V̲I̲E̲W̲
3.2 H̲A̲R̲D̲W̲A̲R̲E̲ ̲C̲O̲M̲P̲O̲N̲E̲N̲T̲S̲
(Provide a detailed description to include the type,
model/feature number, and the technical characteristics
for each component of the proposed equipment. The information
provided shall only relate to the equipment proposed).
a. Central Processing Units (CPU's)
b. Main Memory
c. Immediate Access Storage (IAS)
d. Operator Console
e. Magnetic Tape
f. Graphic Digitizer
g. High Speed Non-impact Printer
h. Line Printers
i. Letter Quality Printer
j. Remote Terminals
k. Optical Character Reader (OCR)
l. Color Graphics Camara
m. Video Copier
n. Color Graphic Copier
5. S̲U̲B̲P̲A̲R̲T̲ ̲E̲ ̲-̲ ̲F̲U̲N̲C̲T̲I̲O̲N̲A̲L̲ ̲L̲I̲V̲E̲ ̲T̲E̲S̲T̲ ̲D̲E̲M̲O̲N̲S̲T̲R̲A̲T̲E̲D̲ ̲(̲F̲L̲T̲D̲)̲
̲C̲H̲A̲R̲A̲C̲T̲E̲R̲I̲S̲T̲I̲C̲S̲
5.1 F̲L̲T̲D̲ ̲P̲E̲R̲F̲O̲R̲M̲A̲N̲C̲E̲ ̲S̲T̲E̲P̲S̲
(Describe the steps that you intend to perform in accomplishing
the FLTD. The description must include those FLTD procedures
specified in paragraph L66).
5.2 F̲L̲T̲D̲ ̲D̲O̲C̲U̲M̲E̲N̲T̲A̲T̲I̲O̲N̲ ̲O̲U̲T̲L̲I̲N̲E̲
Provide the documentation below at the pre-FLTD conference
(reference para L67).
a. Source program compilation listings of the program
to be used during the conduct of the FLTD.
b. A list of all changes made to the Air Force supplied
source programs and accompanying rationale for
the end need for each change.
c. All output products from the execution of the demonstration
programs.
d. A functional schematic drawing of each configuration
to be employed at the FLTD (see figure L-3 and
L-4). This schematic diagram should show each device
identified by a distinct and separate identification
code (e.g. model number, part number); and each
interconnection. The devices employed during the
FLTD must be identical to those proposed and must
be connected in a manner identical to that proposed.
e. A list of the software packages to be used at the
FLTD with applicable release date and version number.
f. The location of the FLTD site including street
address, local phone number and point of contact.
6. S̲U̲B̲P̲A̲R̲T̲ ̲F̲ ̲-̲ ̲P̲R̲O̲P̲O̲S̲E̲D̲ ̲S̲Y̲S̲T̲E̲M̲ ̲F̲A̲C̲I̲L̲I̲T̲Y̲
6.1 P̲R̲O̲P̲O̲S̲E̲D̲ ̲S̲Y̲S̲T̲E̲M̲ ̲F̲A̲C̲I̲L̲I̲T̲Y̲ ̲R̲E̲Q̲U̲I̲R̲E̲M̲E̲N̲T̲S̲
(Provide in tabular form (see figure L-2) the following
detailed information for each unique configuration:
a. The model number, description and quantity for
each type of component.
b. Electrical power requirements per unit.
c. Air cooling requirements per unit.
d. Humidity range (%).
e. Temperature range (…0e…o…0f…F).
f. Floor weight in pounds.
g. Operational area per unit in square feet.
(Including maintenance access).
6.2 T̲O̲T̲A̲L̲ ̲R̲E̲Q̲U̲I̲R̲E̲M̲E̲N̲T̲S̲
(Extend the KVA, KW, cooling and operational floor
space requirements to show the total requirements for
the quantity of each type component proposed with overall
totals for each proposed configuration).
6.3 S̲Y̲S̲T̲E̲M̲ ̲R̲E̲L̲I̲A̲B̲I̲L̲I̲T̲Y̲,̲ ̲S̲H̲U̲T̲D̲O̲W̲N̲ ̲A̲N̲D̲ ̲R̲E̲C̲O̲V̲E̲R̲Y̲
(Describe the procedure for protective shutdown and
subsequent recovery of the proposed system in the event
of power fluctuation or cooling system failure, including
pertinent time parameters. Describe the pertinent reliability
features of the proposed system.)
7. S̲U̲B̲P̲A̲R̲T̲ ̲G̲ ̲-̲ ̲C̲O̲N̲T̲R̲A̲C̲T̲O̲R̲ ̲S̲U̲P̲P̲O̲R̲T̲
7.1 C̲O̲N̲T̲R̲A̲C̲T̲O̲R̲ ̲S̲U̲P̲P̲O̲R̲T̲ ̲Q̲U̲E̲S̲T̲I̲O̲N̲N̲A̲I̲R̲E̲
7.1.1 M̲a̲i̲n̲t̲e̲n̲a̲n̲c̲e̲
1. Describe your plan for performing the required
maintenance, including the number and types of
maintenance personnel supporting the plan and service
points where maintenance personnel will be located.
2. Describe the preventive maintenance requirements
for each component proposed in terms of frequency
and duration.
3. Describe any procedures which utilize "mail-in"
in lieu of "on-site" methods to repair small portable
components.
7.1.2 T̲r̲a̲i̲n̲i̲n̲g̲
1. Outline each course required in paragraph C10 including
prerequisite courses proposed.
2. State the length of each course in classroom hours
and number of days.
3. Identify the Contractor training location.
4. State which training courses, if any, cover more
than one training requirement as described in Section
C.
5. State the method you will use to measure student
progress.
6. Describe in detail the qualification and experience
of the training staff for each course.
7.2 A̲D̲D̲I̲T̲I̲O̲N̲A̲L̲ ̲S̲U̲P̲P̲O̲R̲T̲ ̲I̲T̲E̲M̲S̲
7.2.1 I̲n̲s̲t̲a̲l̲l̲a̲t̲i̲o̲n̲
7.2.1.1 R̲e̲q̲u̲i̲r̲e̲m̲e̲n̲t̲ ̲A̲n̲a̲l̲y̲s̲i̲s̲
a) Christian Rovsing A/S shall make the following
major deliveries to AFCC:
o Site Preparation Requirement
o Transportation and Installation Plan
o Equipment Installation Drawings
o Delivery and Installation of Equipment
b) Site Preparation Requirements ?? shall specify
the extent of site preparation AFCC must undertake
before equipment is installed. In order to generate
the SPR, Christian Rovsing A/S will conduct a Site
Survey at each site.
c) The "Transportation and Installation Plan" shall
contain Christian Rovsing's procedures for transportation
and installation. Furthermore, the plan specifies
division of responsibilities between American Airlines
and Christian Rovsing A/S regarding transportation
and installation. Packaging of central equipment
and peripherals will correspond to the requirements
for air and truck transport to the sites.
d) The equipment installation drawings shall show
how the proposed equipment is installed and integrated.
e) Delivery and installation of equipment will be
performed in accordance with the master schedule
after Christian Rovsing A/S has verified that the
site has been prepared in accordance with the Site
Preparation Requirements. The equipment is delivered
C.I.F. Site. In addition, each container is clearly
labelled with the identification and number of
pieces in the shipment and with precautionary labelling
applicable to handling.
7.2.1.1.1 S̲i̲t̲e̲ ̲I̲n̲s̲t̲a̲l̲l̲a̲t̲i̲o̲n̲
a) Christian Rovsing A/S will prepare internal wite
installation procedures based on the site preparation
requirements and the site installation drawings.
These procedures will detail the installation sequence
and the installation check-out procedures.
b) Christian Rovsing A/S will set up an installation
team to perform the installation. The team will
be working in accordance with the detailed installation
procedures.
c) The team will install the equipment in accordance
with the AFCC approved installation drawings. Any
changes during installation will be marked on the
drawings. Corrected drawings will be submitted
to AFCC after completion of site installation.
d) Installation check-out encompassing hardware verification
will be performed in accordance with an installation
check-out procedure. This task will complete the
installation and indicate the start of acceptance
test.
FIG II 7.2.1.8-1…01……01…PACKING OF A MODULE
FIG II 7.2.1.8-2…01……01…PACKING OF A CRATE
FIG II 7.2.1.8-3…01……01…PACKING OF A RACK
7.2.1.8 I̲n̲s̲t̲a̲l̲l̲a̲t̲i̲o̲n̲ ̲A̲c̲t̲i̲v̲i̲t̲i̲e̲s̲
7.2.1.8.1 T̲r̲a̲n̲s̲p̲o̲r̲t̲a̲t̲i̲o̲n̲
a) The delivery of equipment will follow the master
schedule. Actual shipping dates are selected to
be in accordance with the readiness of site and
time for transportation.
b) The equipment will be shipped by air or truck and
packed accordingly. Christian Rovsing A/S will
arrange the transportation so that its installation
team will be present at site for receipt and unpacking
of the equipment.
c) The packing and marking are proposed to be in accordance
with Christian Rovsing's standard procedures for
CR80 equipment. The following is a brief discussion
of the method:
d) The computer equipment is constructed in a modular
fashion, i.e. 19" racks containing crate assemblies
with plug-in modules. This is reflected in the
packaging as follows:
1) Modules are packed in styrofoam containers
designed to fit each module size. A number
of modules are put into a cardboard box or
similar of Europe pallet standard size (see
figure II 7.2.1.8-1).
2) Crates are packed with styrofoam corners so
that they fit into a cardboard box of Europe
pallet standard size (see figure II 9.4.3.1-2).
3) Each rack or cabinet bay is separately packed
on a wodden pallet, protected with styrofoam
corners, and wrapped in plastic sheets. A skeleton
of timber protects the five free surfaces (see
figure II 7.2.1.8-2).
e) Packing lists are forwarded with every shipping
container. One copy of the packing list is enclosed
in the container; one copy will be attached to
the exterior of the container in an envelope clearly
marked "packing list".
f) Each container is to be clearly marked on the exterior
surface with at least:
o purchaser identification
o manufacturer's name and address
o shipping address
7.2.1.6 E̲q̲u̲i̲p̲m̲e̲n̲t̲ ̲I̲n̲s̲t̲a̲l̲l̲a̲t̲i̲o̲n̲ ̲D̲r̲a̲w̲i̲n̲g̲s̲
a) Christian Rovsing A/S will deliver equipment installation
drawings to AFCC for approval 1 month prior to
start of installation.
b) The approved installation drawings will be used
for the installation of the proposed equipment
on each site.
c) The equipment installation drawings will be based
on the approved site preparation requirements,
the hardware configuration and the equipment characteristics.
d) The drawings will show how the proposed equipment
is to be installed and integrated.
7.2.1.7 S̲i̲t̲e̲ ̲R̲e̲a̲d̲i̲n̲e̲s̲s̲ ̲V̲e̲r̲i̲f̲i̲c̲a̲t̲i̲o̲n̲
a) Prior to start on on-site installation, Christian
Rovsing A/S and AFCC will jointly perform a site
verification.
b) The purpose is to verify that the site is ready
for installation, i.e. that the site is prepared
in accordance with the preparation requirements.
c) Final arrangements concerning transportation to
site and Christian Rovsing's presence at site during
installation and test are also to be made at time
of site verification.
7.2.1.4 T̲r̲a̲n̲s̲p̲o̲r̲t̲a̲t̲i̲o̲n̲ ̲a̲n̲d̲ ̲I̲n̲s̲t̲a̲l̲l̲a̲t̲i̲o̲n̲ ̲P̲l̲a̲n̲
a) Christian Rovsing A/S will prepare a transportation
and installation plan, which will specify the activities
to be performed during phases 1 and 2. The plan
will be submitted to AFCC one month after completion
of site survey.
b) The plan will cover the following areas:
1) Delivery of site preparation requirements (SPR)
and equipment installation drawings.
2) Site readiness verification.
3) Packing, shipment, customs clearance and transportation
to site.
4) A specification of the division of responsibilities
between AFCC and Christian Rovsing A/S concerning
transportation and installation.
5) On-site integration and installation.
7.2.1.5 S̲i̲t̲e̲ ̲P̲r̲e̲p̲a̲r̲a̲t̲i̲o̲n̲ ̲R̲e̲q̲u̲i̲r̲e̲m̲e̲n̲t̲s̲
a) Christian Rovsing A/S will prepare site preparation
requirements (SPR) concerning the preparation of
each site for installation for the proposed equipment.
SPR will be submitted to AFCC for approval four
months after completion of the Site Survey.
b) The SPR will be used on the site data collected
during the site survey, i.e. EMT routing, location
of technical devices, construction details and
option pertinent data, the equipment rooms layouts
and the physical characteristics of the proposed
equipment.
c) The SPR will contain requirements to access, space,
power, power distribution, quantity and location
of power outlets, heat dissipation, cable duction,
etc.
d) AFCC will prepare the site for equipment installation
in accordance with these requirements.
7.2.1.2 I̲n̲s̲t̲a̲l̲l̲a̲t̲i̲o̲n̲ ̲P̲l̲a̲n̲n̲i̲n̲g̲
a) The planning of the installation will start immediately
after contract award. The time span from contract
award to completion of installation will be divided
in two major phases:
1) Site Preparation
2) Site Installation
b) The main activities in phase 1 are:
1. Site survey within two months after contract
award.
2. A transportation and installation plan specifying
the activities to be performed during phases
1 and 2. The plan will be delivered one month
after completion of the site survey.
3. Preparation and delivery of site preparation
requirements four months after completion of
the site survey.
4. Preparation and delivery of equipment installation
drawings one month prior to on-site installation.
5. Site readiness verification prior to start
of equipment installation.
The main activities in phase 2 are:
6. Transportation to site.
7. On-site installation
c) A more detailed description of the phase 1 and
2 activities is presented in the following sections.
7.2.1.3 S̲i̲t̲e̲ ̲S̲u̲r̲v̲e̲y̲
a) Within the first two months after contract award,
Christian Rovsing A/S will perform site survey
with AFCC participation. The purpose of the survey
will be to gather information for the preparation
of site preparation requirements and plans for
on-site integration and installation.
b) An important task to be performed in conjunction
with AFCC during the survey meetings is to determine
the layout of the equipment rooms, the routing
of the electrical metallic tubing (EMT) including
the location of the technical devices.
c) Scales blue prints of the building schematics and
civil engineering drawings are to be used for the
survey and should be handed over to contractor
at start of the survey.
