top - download
⟦a99b13641⟧ Wang Wps File
Length: 32275 (0x7e13)
Types: Wang Wps File
Notes: ACCESS
Names: »3227A «
Derivation
└─⟦c33acb2c5⟧ Bits:30006217 8" Wang WCS floppy, CR 0278A
└─ ⟦this⟧ »3227A «
WangText
…00……00……1c… …1b……09……1b……0f……09… …08……0c……08……0f……08……86…1
…02…
…02…
…02…
…02…
Rev.
3 1983-06-10
DOC NO 3227A
ACCESS PART II - TECHNICAL DATA SYS/1983-01-25
SUBPART E - FLTD - CHARACTERISTICS Page #
…01…A C C E S S
AUTOMATED COMMAND AND CONTROL
EXECUTIVE SUPPORT SYSTEM
DOC NO ACC/8004/PRP/001 ISSUE 1
PART II
TECHNICAL PROPOSAL
SUBPART E
FLTD CHARACTERISTICS
SUBMITTED TO: AIR FORCE COMPUTER AQUISITION CENTER (AFCC)
Directorate of Contracting/PK
Hanscom AFB
MA. 01731
USA
IN RESPONSE TO:Solicitation No F19630-82-R-0001
AFCAC Project 211-81
PREPARED BY: CHRISTIAN ROVSING A/S
SYSTEM DIVISION
LAUTRUPVANG 2
2750 BALLERUP
DENMARK
…0e…c…0f… Christian Rovsing A/S - 1983
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̲S̲ ̲O̲F̲ ̲C̲O̲N̲T̲E̲N̲T̲S̲
5. SUBPART E - FUNCTIONAL LIVE TEST DEMONSTRA-
TION (FLTD) CHARACTERISTICS ................
5.1 FLTD DOCUMENTATION OUTLINE ...............
5.2 SCENARIO 2 SYSTEM PERMISSIONS ............
5.3 SCENARIO 3 DBMS ACCESS PERMISSIONS
5.4 SCENARIO 4 RESTRICTED DBMS ACCESS PERMIS-
SIONS ....................................
5.5 SCENARIO 5 CHANGE PASSWORD ...............
5.6 ACENARIO 6 DATA BASE DICTIONARY ..........
5.7 SCENARIO 7 LOAD PERSONNEL DATA ...........
5.8 SCENARIO 8 QUERY TEST .................... .
5.9 SCENARIO 9 QUERY TEST ....................
5.10 SCENARIO 10 REPORT WRITER TEST ..........
5.11 SCENARIO 11 SYSTEM ACCESS PROTECTION
FEATURES ................................
5.12 SCENARIO 12 CPU FAILURE - QUERY DEVELOP-
MENT ....................................
5.13 SCENARIO 13 CPU failure - QUERY EXECU-
TION ....................................
5.14 SCENARIO 14 CPU FAILURE - REPORT WRITER
EXECUTION ...............................
5.15 SCENARIO 15 PRIMARY SYSTEMS DISC PACK
FAILURE QUERY DEVELOPMENT ...............
5.16 SCENARIO 16 PERSONNEL DATA FILE FAILURE
QUERY EXECUTION .........................
5.17 SCENARIO 17 PERSONNEL DATA FILE FAILUTE
REPORT WRITER EXECUTION .................
5.18 SCENARIO 18 GRAPHICS - BAR CHART ........
5.18a SCENARIO 18a SUBDIVIDED BAR CHART ......
5.19 SCENARIO 19 SLOPE-CURVE CHART ...........
5.19a SCENARIO A MULTIPLE SLOP-CURVE CHART ...
5.20 SCENARIO 20 PIE CHART ...................
5.21 SCENARIO 21 RECONFIGURE PIE CHART .......
5.22 SCENARIO 22 ON-LINE COBOL PROGRAMMING ...
5.23 SCENARIO 23 EVALUATION ..................
5.24 SCENARIO 24 ELECTRONIC MAIL - MESSAGE
CREATION ...................................
5.25 SCENARIO 25 TEXT FILE CREATION AND EDIT .
5.26 SCENARIO 26 ELECTRONIC MAIL - MESSAGE/
TEXT FILES ..............................
5.27 SCENARIO 27 ELECTRONIC MAIL - DIRECTORY
INFORMATION .............................
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̲i̲o̲n̲ ̲(̲F̲L̲T̲D̲)̲
̲C̲h̲a̲r̲a̲c̲t̲e̲r̲i̲s̲t̲i̲c̲s̲
Christian Rovsing A/S will set up a Functional Live
Test that will demonstrate to the Government that the
solution proposed by Christian Rovsing A/S will be
in accordance with the Access requirements.
Christian Rovsing A/S 's experience in system delivery
is within providing special customer tailored solutions
to specific customer needs. This is as an example
accomplished by using our flexible module CR80 computer
family. The configuration to be used for the FLTD
will be set up in a way which contains all the essential
elements needed to show the unique characteristics
of our solution.
This subpart contains a description of Christian Rovsing
A/S's strategy to perform the FLTD. The activities
requested to initiate FLTD preparation has been taken
and Christian Rovsing A/S will provide AFCC with a
detailed status report before the FLTD, i.e. scenario
step modifications etc. The final FLTD plan will be
discussed with AFCC and any suggested changes included,
if possible.
5.1 F̲L̲T̲D̲ ̲D̲o̲c̲u̲m̲e̲n̲t̲a̲t̲i̲o̲n̲ ̲O̲u̲t̲l̲i̲n̲e̲
Christian Rovsing A/S will provide the following documentation
before the FLTD.
a. Source program compilation listings of the applications
programs 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. This schematic diagram
will show each device identified by a distinct
and separate identification code (e.g. model number,
part number); and each interconnection.
e. A list of the relevant software packages to
be used at the FLTD with applicable release
data and version number.
f. The location of the FLTD site including street
address, local phone number and point of contact.
The FLTD configuration is shown in FIG. 5.1. It is
fully dualized by two Processor Unit (PU) Crates and
a double bused Channel Unit (CU). Within each PU are
three CPU's.
One IDM is attached to the CU in order to perform all
database functions. This one IDM is sufficient to
simulate all FLTD requirements including IDM failure
because of our mirrored concept.…86…1 …02… …02… …02…
…02…
FIG. 5-1
FLTD - HARDWARE CONFIGURATION…86…1 …02… …02… …02… …02…
The local area network to be set up for the FLTD will
be a minimal and not tempest proved in the same way
as the final ACCESS configuraton. It is based on the
same bus concept and interfaces to the two processors
with the same interface as in the final proposal. The
terminal adapters to be used in the FLTD are used in
a tempest secure installation which Christian Rovsing
A/S is implemented in European Nato countries for SHAPE.
The final Access network will be much more distributed
and the installation of it will benefit from the latest
and most advanced technology regarding efficiency an
miniaturisation.
The strategy Christian Rovsing A/S would prefer to
follow for the FLTD is one where most resources are
devoted to demonstrating all or most resources on the
'mandatory/evaluation' attributed scenarios whereas
all 'evaluation' attributed scenarios are covered to
some extend, as described in the individual scenarios.
Christian Rovsing A/S will keep Hanscom informed on
our progress for preparation of the FLTD in accordance
with the above mentioned strategy. The amount of work
to be laid down in the FLTD as outlined is quite extensive
and the time frame is very tight.
The reason for the above described approach is that
although almost all hardware entities, and many software
entities are available from off the shelf, other entities
will be specially tailored to meet the Access requirements
and hence will also have to be specially prepared for
the FLTD. By doing this we will show to the Government
our capability to custom tailor systems. This will
be of great benefit to the user, because it will ensure
that the final Access system proposed by Christian
Rovsing A/S will be the most user friendly system.
In the following the individual scenaries will be treated
one by one.
S̲C̲E̲N̲A̲R̲I̲O̲ ̲1̲ ̲S̲Y̲S̲T̲E̲M̲ ̲S̲T̲A̲R̲T̲
Mandatory/Evaluation
Upon notificatin from the FLTD Team Chief, the offeror
will commence with this Scenario by turning on the
System from a cold start.
5.2 S̲C̲E̲N̲A̲R̲I̲O̲ ̲2̲ ̲S̲Y̲S̲T̲E̲M̲ ̲P̲E̲R̲M̲I̲S̲S̲I̲O̲N̲S̲
Mandatory/Evaluation
The following Users will be established:
TERMINAL
OPERATOR DIRECTORY PASSWORD
ONE ACCESS.ONE OUTPUT
TWO ACCESS.TWO TACKLE
THREEE ACCESS.THREE TOPPLE
FOUR ACCESS.FOUR FUTURE
The implementation of directories on the IDM is done
by providing individual databases with individual access
priviliges or passwords. The relational database concept
allow separation or concurrent access to more than
one database.
5.3 S̲C̲E̲N̲A̲R̲I̲O̲ ̲3̲ ̲D̲B̲M̲S̲ ̲A̲C̲C̲E̲S̲S̲ ̲P̲E̲R̲M̲I̲S̲S̲I̲O̲N̲S̲
Mandatory/Evaluation
Access permissions will be established for user/operator,
ONE, TWO, THREE and FOUR to view all or selected records
in the personnel DBMS.
This will be performed in accordance with Scenario
2.
5.4 S̲C̲E̲N̲A̲R̲I̲O̲ ̲4̲ ̲R̲E̲S̲T̲R̲I̲C̲T̲E̲D̲ ̲D̲B̲M̲S̲ ̲A̲C̲C̲E̲S̲S̲ ̲P̲E̲R̲M̲I̲S̲S̲I̲O̲N̲S̲
Mandatory/Evaluation
Restricted access permissions will be established for
user THREE that will prevent viewing of the CR (Current
Grade) field in the personnel DBMS.
This will be performed in accordance with Scenario
2.
5.5 S̲C̲E̲N̲A̲R̲I̲O̲ ̲5̲ ̲C̲H̲A̲N̲G̲E̲ ̲P̲A̲S̲S̲W̲O̲R̲D̲
Mandatory/Evaluation
Change the password for user FOUR from "FUTURE" to
"THROUGH".
This will be done in accordance with Scenario 2.
5.6 S̲C̲E̲N̲A̲R̲I̲O̲ ̲6̲ ̲D̲A̲T̲A̲ ̲B̲A̲S̲E̲ ̲D̲I̲C̲T̲I̲O̲N̲A̲R̲Y̲
Evaluation
In accordance with Christian Rovsing A/S strategy for
the FLTD, this scenario may not be totally demonstratable.
1) The data dictionary capability will be tested using
the on-line dictionary interface and with results
of the test being returned to the terminal and
subsequently printed on the line printer.
2) For test purposes, the definitions for the personnel
file as previously established will be used. All
test data definitions required are provided and
will be performed by user ONE.
3) The following functions will be performed:
a. Add Data Element Definitions:
(1) Add definitions for two data elements to the
dictionary file as follows:
(a) Record position 3-5, assign data element
COUNTY-CODE.
(b) Record position 137, assign data element
HIGH-SCH-CODE.
(2) The dictionary will be updated upon command
from the dictionary file. The results of this
update will be displayed on the terminal and sent
to the line printer and printed on one part paper.
b. Modify Data Element Definition:
(1) Modify record position 137 to read COLLEGE-CODE.
(2) The dictionary will be updated upon command
from the dictionary file. The results of this update
will be displayed on the terminal and sent to the
printer and printed.
c. Delete Data Element Definitions:
(1) Delete data element definitions COUNTY-CODE
(Record Position 3-5) and COLLEGE-CODE (Record
position 137). The record positions 3-5 and 137
will remain and reflect a filler area.
(2) The dictionary will be updated upon command
from the dictionary file. The results of this update
will be displayed on the terminal and sent to the
line printer and printed on one part paper.
5.7 S̲C̲E̲N̲A̲R̲I̲O̲ ̲7̲ ̲L̲O̲A̲D̲ ̲P̲E̲R̲S̲O̲N̲N̲E̲L̲ ̲D̲A̲T̲A̲
Mandatory/Evaluation
Christian Rovsing A/S will read the Personnel Data
File from tape and create a DBMS File.
5.8 S̲C̲E̲N̲A̲R̲I̲O̲ ̲8̲ ̲Q̲U̲E̲R̲Y̲ ̲T̲E̲S̲T̲
Mandatory/Evaluation
1. Construct a query which will select all DAFSC (Duty
AFSC - Record Position 64-70) which is equal to
X43171X and GR (Current Grade - Record Position
135-136) is equal to 35 or 36. The personnel DBMS
file will be accessed.
2. This function will be generated by User TWO.
3. Other Data Elements to be selected are:
NAME (Name Person 1st Eighteen (L, F, MI)) - Record
Position 854-871
DOR (Current Date of Rank) - Record Position 138-143
DUTY-LOC (Duty Location Current) - Record Position
1584-1600…86…1 …02… …02… …02… …02…
4. Output format for screen display and for printing
on Printer will be shown as follows:
DATE OF DUTY DUTY
NAME GRADE RANK AFSC LOCATION
NOTE: At least five spaces will be generated between each
output data element.
a. Construct query and output format.
b. Store query.
c. Execute query.
d. View query results.
e. Store query results for printing on Printer.
f. Recall stored query.
g. Change query selection by removing GR equal to
35.
h. Execute change query.
i. Store query results for printing on Printer.
5.9 S̲C̲E̲N̲A̲R̲I̲O̲ ̲9̲ ̲Q̲U̲E̲R̲Y̲ ̲T̲E̲S̲T̲
Mandatory/Evaluation
1. Construct a query that will count all records that
have an APR-RATE (APR Rating Last - Reocrd Position
26) which is less than 9. Individual counters
will be established to count records that have
an APR rating in each number from 0 through 8.
Print results of each counter. DBMS file will
be accessed.
2. This function will be generated by User ONE.
3. The following functions in the order specified
will be performed:
a. Construct query
b. Execute query
c. View results
d. Store constructed query and results for printing
on Printer.
5.10 S̲C̲E̲N̲A̲R̲I̲O̲ ̲1̲0̲ ̲R̲E̲P̲O̲R̲T̲ ̲W̲R̲I̲T̲E̲R̲ ̲T̲E̲S̲T̲
Mandatory/Evaluation
1. Construct a report through the use of the Report
Writer facility. The report will retrieve multiple
records using the personnel DBMS file.
2. Selection procudure is as follows: Select all GR
(Current Grade - Record Position 135-136) equal
to 37 through 39 with DOR (Date of Rank - Record
Position 138-141) between the dates of 8005 and
8205.
3. This function will be generated by User TWO.
4. Other data elements to be selected are:
DAFSC ( Duty AFSC - Record Position 64-70).
NAME (Name Person 1st Eighteen (L, F, MI) - Record
Position 854-871).
SSAN (Social Security Account Number - Record Position
1567-1575).
DUTY-LOC (Duty Location Current - Record Position
1584-1600).
5. Output format for printing on Printer will be shown
as follows:
DUTY
SSAN GRADE NAME DAFSC DOR LOCATION
NOTE: Output Format: At least five spaces will be
generated between each data element.
6. The following functions in the order specified
will be performed.
a. Construct Report Writer procedure interactively
at terminal.
b. Store constructed procedure.
c. Execute procedure.
d. Send output to Printer.
e. The report will reflect Page Count on bottom
of each page and also will reflect a final
total of number of personnel listed as a result
of the selection criteria two spaces below
last record printed.
5.11 S̲C̲E̲N̲A̲R̲I̲O̲ ̲1̲1̲ ̲S̲Y̲S̲T̲E̲M̲ ̲A̲C̲C̲E̲S̲S̲ ̲P̲R̲O̲T̲E̲C̲T̲I̲O̲N̲ ̲F̲E̲A̲T̲U̲R̲E̲S̲
Evaluation
In accordance with the Christian Rovsing A/S strategy
for the FLTD this scenario may not be totally demonstratable
1. Requirements of this scenario are as follows:
a. Deny access to system.
b. Limit access to files, records, and fields,
and fields within records through use of passwords/protection
features in the IDM.
2. This function will require all directories previously
defined.
3. The following functions in the order specified
will be performed.
a. User ONE will log-of the system.
b. User ONE will attempt to log-on and gain access
to the system three times using password DENIAL.
c. Store terminal displays for printing on one
part paper on the Line Printer.
d. User THREE will log-on to the system using
terminal two.
e. Retrieve the stored Report Writer procedure
generated in Scenario 10.
f. Attempt to execute procedure.
g. Store terminal display for printing on the
Printer.
h. Retrieve the stored Report Writer procedure
generated in Scenario 10.
j. Execute procedure.
k. Print results on Line Printer.
5.12 S̲C̲E̲N̲A̲R̲I̲O̲ ̲1̲2̲ ̲C̲P̲U̲ ̲F̲A̲I̲L̲U̲R̲E̲ ̲-̲ ̲Q̲U̲E̲R̲Y̲ ̲D̲E̲V̲E̲L̲O̲P̲M̲E̲N̲T̲
Mandatory/Evaluation
Christian Rovsing A/S has build more fault tolerant
system, and we will be able to demonstrate live operational
systems which has this capability. Establishing a true
fault tolerant system with specific application software
requires specific programming in order to be efficient.
This is the reason why it may be difficult to ensure
a 100% succesful FLTD scenario with a subset of the
application system requested by Hanscom.
1. During the construction of a query, the system
should recover the position of the user with the
loss of no more than the line of instruction currently
being entered. The user should be able to continue
and complete the query development session from
the point of interruption.
2. This function will be performed by User ONE.
3. Reference Scenario 8, paragraphs 1, 3, and 4 for
query development.
4. The DBMS File will be used in this test.
5. Commence construction of the query.
6. During construction of the query, the primary CPU
will be turned off.
7. Continue construction of the query to completion.
8. Store constructed query.
9. View results on display terminal. Print results
of query on a Printer.
5.13 S̲C̲N̲E̲N̲A̲R̲I̲O̲ ̲1̲3̲ ̲-̲ ̲C̲P̲U̲ ̲F̲A̲I̲L̲U̲R̲E̲ ̲-̲ ̲Q̲U̲E̲R̲Y̲ ̲E̲X̲E̲C̲U̲T̲I̲O̲N̲
Mandatory/Evaluation
Christian Rovsing A/S has build more fault tolerant
system, and we will be able to demonstrate live operational
systems which has this capability. Establishing a true
fault tolerant system with specific application software
requires specific programming in order to be efficient.
This is the reason why it may be difficult to ensure
a 100% succesful FLTD scenario with a subset of the
application system requested by Hanscom.
1. During the execution of the query, the query should
either continue to be returned to the screen or
the query should automatically restart the display
from the beginning of the response with no operator
intervention required.
2. This function will be performed by User TWO.
3. The personnel DBMS file will be used in this test.
4. Restart primary CPU.
5. Retrieve query stored in Scenario 12.
6. Execute query using primary CPU.
7. Turn off primary CPU during execution.
8. Upon termination of query, send results to Printer
and print.
5.14 S̲C̲E̲N̲A̲R̲I̲O̲ ̲1̲4̲ ̲C̲P̲U̲ ̲F̲A̲I̲L̲U̲R̲E̲ ̲-̲ ̲R̲E̲P̲O̲R̲T̲ ̲W̲R̲I̲T̲E̲R̲ ̲E̲X̲E̲C̲U̲T̲I̲O̲N̲
Mandatory/Evaluation
Christian Rovsing A/S has build more fault tolerant
system, and we will be able to demonstrate live operational
systems which has this capability. Establishing a true
fault tolerant system with specific application software
requires specific programming in order to be efficient.
This is the reason why it may be difficult to ensure
a 100% succesful FLTD scenario with a subset of the
application system requested by Hanscom.
1. During the execution of the Report Writer facility,
there should be no system interruption and the
report should continue execution or the report
should restart automaticslly with no operator intervention.
2. This function will be performed by User ONE.
3. The primary and alternate personnel DBMS File will
be used in this test.
4. Restart Primary CPU.
5. Retrieve Report Writer procedure stored in Scenario
10.
6. Execute Report Writer procedure using primary CPU.
7. Turn-off primary CPU during execution.
8. Upon termination of Report Writer procedure, store
terminal display results and print the results
on one part paper on the Line Printer.
9. Print report on Line Printer on one part paper.
10. Restart Primary CPU.
5.15 S̲C̲E̲N̲A̲R̲I̲O̲ ̲1̲5̲ ̲P̲R̲I̲M̲A̲R̲Y̲ ̲S̲Y̲S̲T̲E̲M̲S̲ ̲D̲I̲S̲C̲ ̲P̲A̲C̲K̲ ̲F̲A̲I̲L̲U̲R̲E̲ ̲Q̲U̲E̲R̲Y̲
̲D̲E̲V̲E̲L̲O̲P̲M̲E̲N̲T̲
Mandatory/Evaluation
1. During the construction of the query, the system
should recover the position of the user with the
loss of no more than the line of instruction currently
being entered. The user should be able to continue
and complete the query development session from
the point of interruption.
2. This function will be performed by User ONE.
3. Reference Attahcment 7, Scenario 8, paragraphs
1, 3 and 4 for query development.
4. The personnel DBMS File will be used.
5. Commence construction of the query.
6. During construction of the query, the primary systems
disc pack wil be turned off.
7. Continue construction of the query to completion.
8. Store constructed query.
9. View results on display terminal. Store results
and print the results on one part paper on the
Line Printer.
5.16 S̲C̲E̲N̲A̲R̲I̲O̲ ̲1̲6̲ ̲-̲ ̲P̲E̲R̲S̲O̲N̲N̲E̲L̲ ̲D̲A̲T̲A̲ ̲F̲I̲L̲E̲ ̲F̲A̲I̲L̲U̲R̲E̲ ̲Q̲U̲E̲R̲Y̲ ̲E̲X̲E̲C̲U̲T̲I̲O̲N̲
Mandatory/Evaluation
Christian Rovsing A/S has build more fault more fault
tolerant system, and we will be able to demonstrate
live operational systems which has this capability.
Establishing a true fault tolerant system with specific
application software requires specific programming
in order to be efficient. This is the reason why it
may be difficult to ensure a 100% succesful FLTD scenario
with a subset of the application system requested by
Hanscom.
1. During the execution of the query, the query should
either continue to be returned to the screen or
the query should automatically restart the display
from the beginning of the response with no operator
intervention required.
2. This function will be performed by User TWO.
3. The personnel DBMS File will be used in this test.
4. Restart primary systems disc pack.
5. Retrieve query stored in Scenario 15.
6. Execute query using personnel data file.
7. Turn off disc drive containing personnel data file
during execution.
7a. Turn on again the disc drive containing the personnel
data files. Due to the mirrored disc pack concept,
the turning off and on of a disc pack is a good
simulation of disc pack failures.
8. Upon termination of query, send results to a Printer.
5.17 S̲C̲E̲N̲A̲R̲I̲O̲ ̲1̲7̲ ̲-̲ ̲P̲E̲R̲S̲O̲N̲N̲E̲L̲ ̲D̲A̲T̲A̲ ̲F̲I̲L̲E̲ ̲F̲A̲I̲L̲U̲R̲E̲ ̲R̲E̲P̲O̲R̲T̲ ̲W̲R̲I̲T̲E̲R̲
̲E̲X̲E̲C̲U̲T̲I̲O̲N̲
Mandatory/Evaluation
Christian Rovsing A/S has build more fault more fault
tolerant system, and we will be able to demonstrate
live operational systems which has this capability.
Establishing a true fault tolerant system with specific
application software requires specific programming
in order to be efficient. This is the reason why it
may be difficult to ensure a 100% succesful FLTD scenario
with a subset of the application system requested by
Hanscom.
1. During the execution of the Report Writer facility,
there should be no system interruption and the
report should continue execution or the report
should restart automatically with no operator intervention.
2. This function will be performed by User ONE.
3. The personel DBMS File will be used in this test.
4. Reserved.
5. Retrieve Report Writer procedure stored in Scenario
10.
6. Execute Report Writer procedure using the disc
drive containing the personnel data file.
7. Turn-off the disc drive containing the personnel
data file during execution.
7a. Turn on agian the disc drive containing the personnel
data filed. Due to the mirrored disc pack concept,
the turning off and on of a disc pack is a good
simulation of disc pack failures.
8. Upon termination of Report Writer procedure, store
terminal display results and print results on one
part paper on the Line Printer.
9. Print report on Printer.
10. Reserved.
5.18 S̲C̲E̲N̲A̲R̲I̲O̲ ̲1̲8̲ ̲G̲R̲A̲P̲H̲I̲C̲S̲ ̲-̲ ̲B̲A̲R̲ ̲C̲H̲A̲R̲T̲
Evaluation
A waiver will be asked for this scenario in accordance
with Christian Rovsing A/S's prioriterising of fullfilling
FLTD scenarios.
5.18A S̲C̲E̲N̲A̲R̲I̲O̲ ̲1̲8̲a̲ ̲S̲U̲B̲D̲I̲V̲I̲D̲E̲D̲ ̲B̲A̲R̲ ̲C̲H̲A̲R̲T̲
Evaluation
A waiver will be asked for this scenario is accordance
with Christian Rovsing A/S's priorities for fullfilling
the FLTD requirements.
5.19 S̲C̲E̲N̲A̲R̲I̲O̲ ̲1̲9̲ ̲S̲L̲O̲P̲E̲-̲C̲U̲R̲V̲E̲ ̲C̲H̲A̲R̲T̲
Evaluation
A waiver will be asked for this scenario is accordance
with Christian Rovsing A/S's priorities for fullfilling
the FLTD requirements.
5.19a S̲C̲E̲N̲A̲R̲I̲O̲ ̲1̲9̲a̲ ̲M̲U̲L̲T̲I̲P̲L̲E̲ ̲S̲L̲O̲P̲-̲C̲U̲R̲V̲E̲ ̲C̲H̲A̲R̲T̲
Evaluation
A waiver will be asked for this scenario is accordance
with Christian Rovsing A/S's priorities for fullfilling
the FLTD requirements.
5.20 S̲C̲E̲N̲A̲R̲I̲O̲ ̲2̲0̲ ̲P̲I̲E̲ ̲C̲H̲A̲R̲T̲
Evaluation
A waiver will be asked for this scenario is accordance
with Christian Rovsing A/S's priorities for fullfilling
the FLTD requirements.
5.21 S̲C̲E̲N̲A̲R̲I̲O̲ ̲2̲1̲ ̲R̲E̲C̲O̲N̲F̲I̲G̲U̲R̲E̲ ̲P̲I̲E̲ ̲C̲H̲A̲R̲T̲
Evaluation
A waiver will be asked for this scenario is accordance
with Christian Rovsing A/S's priorities for fullfilling
the FLTD requirements.
5.22 S̲C̲E̲N̲A̲R̲I̲O̲ ̲2̲2̲ ̲O̲N̲-̲L̲I̲N̲E̲ ̲C̲O̲B̲O̲L̲ ̲P̲R̲O̲G̲R̲A̲M̲M̲I̲N̲G̲
Evaluation
1. The offeror will call up the source code of program
BM1A00 for display and editing on the terminal.
2. This function will be generated by User THREE.
3. The following functions in the order specified
will be performed.
a. Through the use of the Text Editor, modify
or delete the following instructions:
(1) In the Data Division, delete the line "02
Player-Number Pic 9(4)."
(2) In the Procedure Division, Best-Batter
Section, delete the line "Display " *******BEST
BATTER ********" Upon Rem".
(3) In the Procedure Division, Generate-Player-List
Section, Paragraph Writer-Listing, modify the
line "Add 1 to Line-Cnt" to read "Add 3 to
Line-Cnt".
(4) In the Procedure Division, Delete-Player-Record
Section, Paragraph Display-Info-IF, change
the line "Display" "Enter Record Data" upon
Rem "to read Display "Ignore this Change" upon
the Rem.
b. After above changes are made, direct the system
to compile the modified source code and print
a compilation list on a Printer.
c. Store the modified source program under a new
name.
d. Retrieve from the source program library a
list of the names of all programs stored and
view on the display terminal and store the
results and print the results on a Printer.
5.23 S̲C̲E̲N̲A̲R̲I̲O̲ ̲2̲3̲
Evaluation
1. Scenario's 23a, 23b and 23c will be used during
the FLTD. These scenario's will execute the government-supplied
programs.
2. Instructions for each scenario are in detail and
will be followed.
3. The instructions for this scenario are to compile
each program and store them in executable form
in the object library. These programs will be
compiled once in scenario 23 and executed in scenario's
23a, 23b and 23c.
4. During execution of scenario 23c, a number of steps
will be timed and measured. Instructions will
be provided by a government FLTD team member.
5. Print the final source listing of each program
compiled on a printer.
6. Proceed to either scenario 23a, 23b or 23c per
instructions.
5.24 S̲C̲E̲N̲A̲R̲I̲O̲ ̲2̲4̲ ̲E̲L̲E̲C̲T̲R̲O̲N̲I̲C̲ ̲M̲A̲I̲L̲ ̲-̲ ̲M̲E̲S̲S̲A̲G̲E̲ ̲C̲R̲E̲A̲T̲I̲O̲N̲
Evaluation
The baseline for the electronic mail system proposed
by Christian Rovsing will be a system developed for
NATO and being installed in European NATO countries.
The VDU User Package is an electronic mail system for
handling both ACP 127 messages and free format messages.
Christian Rovsing proposes to modify this electronic
mail system to meet the ACCESS requirements. The following
functions will be demonstrable on the baseline system.
1. Create, forward and reply to messages. Create a
text file.
2. This function will be generated by three different
users.
3. The following functions in the order specified
will be performed:
a. User "FOUR": Create the following text file
and stores for later use:
A good way to reasonably assure the best system
is designed is to consult with experienced
technical systems hardware and software personnel
when deciding the limitations and boundaries
of a proposed computer system.
b. User "TWO": Create the following message and
send it to User "THREE" and have an information
copy for User "TWO", User "THREE" -
What can be done to guard against superficial
studies and insure that a proposed computer
system is workable?
THANKS,
User "TWO"
c. User, "THREE": Reply back to the message sent
by User "TWO" and forward this reply and User
"TWO's" message to User "FOUR". The reply
will be as follows:
User "TWO" -
The best insurance for designing a workable
system is to insure that experienced systems
and computer programming people are among the
personnel assigned to deisgn the system.
SINCERELY,
User "THREE".
d. User "FOUR": Reply back to User "THREE" and
create information copies for yourself and
User "TWO". In addition, include the text file
created in 3a above in the body of the message.
The reply will be as follows:
User "THREE" -
This will not guarantee the validity of the
conclusions reached but will go a long way
toward avoiding gross over-simplifications.
In addition, suggest you consider the following:
NOTE: Insert text file previously created here.
-------------------------------------
HAVE A GOOD DAY,
User, "FOUR"
e. Print all messages on a Printer.
N̲o̲t̲e̲: The user identifiers have been put in
quotation mark, because actual identifiers
may differ.
5.25 S̲C̲E̲N̲A̲R̲I̲O̲ ̲2̲5̲ ̲T̲E̲X̲T̲ ̲F̲I̲L̲E̲ ̲C̲R̲E̲A̲T̲I̲O̲N̲ ̲A̲N̲D̲ ̲E̲D̲I̲T̲
Evaluation
Christian Rovsing A/S will ask for a waive of this
scenario, but will demonstrate editing features as
part of scenario 24. The formatting capabilities of
the VDU itself will also be demonstrated.
5.26 S̲C̲E̲N̲A̲R̲I̲O̲ ̲2̲6̲ ̲E̲L̲E̲C̲T̲R̲O̲N̲I̲C̲ ̲M̲A̲I̲L̲ ̲-̲ ̲M̲E̲S̲S̲A̲G̲E̲/̲T̲E̲X̲T̲ ̲F̲I̲L̲E̲S̲
Evaluation
A waiver is asked for in this scenario. The scenario
24 will cover some of these points.
5.27 S̲C̲E̲N̲A̲R̲I̲O̲ ̲2̲7̲ ̲E̲L̲E̲C̲T̲R̲O̲N̲I̲C̲ ̲M̲A̲I̲L̲ ̲-̲ ̲D̲I̲R̲E̲C̲T̲O̲R̲Y̲ ̲I̲N̲F̲O̲R̲M̲A̲T̲I̲O̲N̲
Evaluation
A waiver is asked for in this scenario. The scenario
24 will show some of these feature.
5.28 S̲C̲E̲N̲A̲R̲I̲O̲ ̲2̲8̲ ̲A̲D̲M̲I̲N̲I̲S̲T̲R̲A̲T̲I̲V̲E̲ ̲O̲P̲E̲R̲A̲T̲I̲O̲N̲S̲ ̲T̲E̲S̲T̲
Evaluation
Christian Rovsing will demonstrate various admini-
strative tasks to meet this scenario.
5.29 S̲C̲E̲N̲A̲R̲I̲O̲ ̲2̲9̲ ̲T̲E̲R̲M̲I̲N̲A̲L̲ ̲F̲A̲I̲L̲U̲R̲E̲ ̲-̲ ̲Q̲U̲E̲R̲Y̲ ̲D̲E̲V̲E̲L̲O̲P̲M̲E̲N̲T̲
Mandatory/Evaluation
1. During construction of this query, the system should
recover the position of the user with the loss
of no more than the line of instruction currently
being entered. The user should be able to continue
and complete the query development session from
the point of interruption.
2. This function will be performed by Directory ACCESS
ONE.
3. Reference Attachment 7, Scenario 8, paragraphs
1, 3, and 4 for query development.
4. The primary personnel DBMS file will be used in
this test.
5. Commence construction of the query.
6. During construction of the query, turn off the
VDU where this query is being constructed.
7. Log on to another VDU and re-attach to the job
started in paragraph 5.
8. Continue construction of the query to completion.
9. Store constructed query.
10. View results in display terminal. Print results
of query on one part paper on a printer.
