top - download
⟦accad871e⟧ Wang Wps File
Length: 164902 (0x28426)
Types: Wang Wps File
Notes: ACCESS
Names: »3257A «
Derivation
└─⟦1f76ea5a7⟧ Bits:30006218 8" Wang WCS floppy, CR 0277A
└─ ⟦this⟧ »3257A «
WangText
B…00……00…8…0a…8…0b……00……00…8…0c…8…01…8…06…7…0e…7…01…7…06…6…0e…6…07…5…0c…5
4…09…4…0f…4…00…4…07…3…0e…3
2…0a…2…01…2…07…1…0a…1…01…1…07…0…0c…0…0f…0…07…/…0f….…08….…01…. -…0a…-…01…-…07…,…0d…,…0f…,…05…+…0c…+ *…0d…*…05…)…0e…)…06…(…0c…(
'…0b…'
&…0b…&…02…%…86…1 …02… …02… …02… …02…
REV. 2 1983-05-27
Doc 3257A
ACCESS PART I - SYSTEM PROPOSAL SYS/1983-01-25
SUBPART B - REQUIREMENTS Page #
A C C E S S
AUTOMATED COMMAND AND CONTROL
EXECUTIVE SUPPORT SYSTEM
PART I
SYSTEM PROPOSAL
SUBPART B
REQUIREMENTS
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 - REQUIREMENTS .......................
C1 GENERAL .....................................
C2 ENVIRONMENTAL AND PHYSICAL FACILITIES .......
C3 CONFORMANCE TO FEDERAL INFORMATION PROCES-
SING AND TELECOMMUNICATION STANDARDS ........
C4 SYSTEM REQUIREMENTS .........................
C5 LINE ITEM 0001 - EQUIPMENT .................
C6 LINE ITEM 0002 - COMMUNICATIONS .............
C7 LINE ITEM 0003 - SYSTEM SOFTWARE ............
C8 LINE ITEM 0004 - APPLICATION SOFTWARE .......
C9 LINE ITEM 0005 - MAINTENANCE ................
C10 LINE ITEM 0006 - TRAINING ....................
C11 LINE ITEM 0007 - DATA ........................
C12 LINE ITEM 0008 - TECHNICAL SUPPORT ...........
C13 LINE ITEM 0009 - TERMINAL RELOCATION ........
2̲ ̲ ̲S̲U̲B̲P̲A̲R̲T̲ ̲B̲ ̲-̲ ̲R̲E̲Q̲U̲I̲R̲E̲M̲E̲N̲T̲S
C̲1̲.̲ ̲G̲E̲N̲E̲R̲A̲L̲
This subpart contains a detailed response to all requirements
as stated in the RFD Section C.
C̲2̲.̲ ̲E̲N̲V̲I̲R̲O̲N̲M̲E̲N̲T̲A̲L̲ ̲A̲N̲D̲ ̲P̲H̲Y̲S̲I̲C̲A̲L̲ ̲F̲A̲C̲I̲L̲I̲T̲I̲E̲S̲
The system proposal for ACCESS by Christian Rovsing
A/S will be in accordance with the environmental and
physical facilities. Electrical and air conditioning
requirements are standard office computer requirement
and physical facilities has been thoroughy checked
to ensure that increment 1, 2 and 3 are catered for
(Ref Part I, Subpart C Sec. 3.3., Site Layouts).
C̲3̲.̲ ̲C̲O̲N̲F̲O̲R̲M̲A̲N̲C̲E̲ ̲T̲O̲ ̲F̲E̲D̲E̲R̲A̲L̲ ̲I̲N̲F̲O̲R̲M̲A̲T̲I̲O̲N̲ ̲P̲R̲O̲C̲E̲S̲S̲I̲N̲G̲ ̲A̲N̲D̲
̲
T̲E̲L̲E̲C̲O̲M̲M̲U̲N̲I̲C̲A̲T̲I̲O̲N̲S̲ ̲S̲T̲A̲N̲D̲A̲R̲D̲S̲
Christian Rovsing A/S internal standards are based
on International Commercial and Military Standards.
All equipment is of American Origin or has been accepted
by the US Military for installation in USA or Nato
Systems. Christian Rovsing A/S is always using the
best equipment for the systems we deliver to various
users. Hence Christian Rovsing A/S does not foresee
any problems regarding conformance to Federal Information
Processing Telecommunications Standards, and equipment
and software developped in the ACCESS program will
conform to FIPS PUBS.
C̲4̲.̲ ̲S̲Y̲S̲T̲E̲M̲ ̲R̲E̲Q̲U̲I̲R̲E̲M̲E̲N̲T̲S̲
Christian Rovsing A/S 's experience in building User
Friendly System in a military environment will ensure
that the ACCESS System will be easy to use for both
the inexperienced and the experienced user. Special
HELP menus are available to the inexperienced user.
a. Human Factor Considerations
This ACCESS System proposal made by Christian Rovsing
A/S is designed in accordance with all possible Human
Factor Consideration.
The hardware used in very reliable and easily maintainable.
Due to the modular structure of the hardware, a very
flexible system will be established. Only the best
and most accepted peripherals, all of American Origin,
will be used.
The firware used in the computer system is well designed
and in many cases down-loadable from the host computer
system to the various peripherical processors. This
provides great flexibility in operation and saves spare
parts.
The software supplied with ACCESS will be integrated
under a common shell providing a very human friendly
man machine interface. Both experienced and the inexperienced
user issuing HELP functions will easily be aquainted
with the system. The common man machine interface
has been designed to allow easy modification and expansion.
b. C̲o̲n̲f̲i̲g̲u̲r̲a̲t̲i̲o̲n̲ ̲R̲e̲q̲u̲i̲r̲e̲m̲e̲n̲t̲s̲
The Configuration of the proposed system is explained
in detail in part II of this proposal.
The processor configuration servicing the local area
network contains 3 processing element (PE's). The
2 PE's are placed as Front-End Processors connected
to the branches of the local area network. The 3rd
PE is controlling the database memory disc bank. The
3 PE's are tied together with high-speed data transfer
buses. In each PE is included several Processing Units
(PU's) in a dualized configuration, so that a PE is
able to operate continuously.
Each PU is a multi-CPU-unit. Up to 5 CPU's can be
operated in parallel on the buses of the PU. In the
proposed configuration each PU is equipped with 2 CPU's,
which means, that the 3 PE's in total includes 12 CPU's.
In this very powerful distrubuted processing configuration
the interactive communication with the users and batch
mode operations can be run concurrently without recognizable
interference at all.
c. F̲u̲n̲c̲t̲i̲o̲n̲a̲l̲ ̲A̲v̲a̲i̲l̲a̲b̲i̲l̲i̲t̲y̲
The proposed configuration is constructed by using
dualized elements. The configuration is described
in detail in Part II of this proposal, but the following
features can be highlighted:
- The database memory is completely dualized.
- Each of the Processing Elements is in dualized
construction using the CR80 fault tolerant processing
system developed for high-reliability applications
by Christian Rovsing A/S.
- The high speed data transfer network between the
PE's is dualized.
- The local area network is completely dualized to
ensure high availability of service to each user
connecting point.
The availability calculation performed in Part II,
Subpart F, Section 6.3 of this proposal gives the following
predicted availability figures:
Predicted availability A99.99%
Meantime between system failure: 12.500 hours.
Nothing in the proposed configuration separates the
processing of the classes of application defined in
the RFP. For all classes of application the availablility
will be at the same high level. However, a graceful
degredation principle can be implemented, ensuring
an even higher availability for critical and high priority
applications.
This degredation principle can differentiate between
one or more CPU-failures in one of the two active PUs
in each dualized front end system, where low priority
applications will have to be terminated.
More serious failures, which will cause a total PU
and the associated CU in a front end system to fail,
will result in medium and low priority applications
for the attached user to be terminated.
If a double failure occurs, which terminates a PU and
CU and a CPU failure in the still active system, then
also high priority applications must be terminated.
Only critical applications can be processed.
The log in function is considered a critical application,
which can be performed even if more errors have occured.
The function is available in 99.99% of the PPU, exceeding
the required 99% availability.
Recovery in a database transaction will ensure that
at most one line of entry is lost, and it will automatically
return the user to the point just before the failure
after recovery.
In text or message entry the same recovery principle
is applied, meaning that no more than one line is lost.
For an extended response or listing, the system will
automatically recover by resuming the printing at the
point of failure or in the beginning of the current
output i.e. from the top of the interrupted printed
page or interrupted video display page.
All actions of recovery in case of a system failure
are automatic, meaning that the system will notice
the user of the system status and the status of his
application after the system has made the recovery.
No re-login is required if the user continues within
a given time limit, and the user has the option to
continue or abort the interrupted task.
All applications in the proposed system are executed
on a fully dualized hardware configuration and will
thus have the same high availability.
The hardware reliability figures indicate that a PU-switchover
will take place during PPU once every 22. day. Recovery
after switchover will cause less than 1 minute unavailability.
Thus for all applications the functional availability
is 0.99994 with recovery from a failure in less than
1 minute.
Within a dualized configuration the error isolation
and correction is eased by the fact, that error correction
can be performed on the off-lined part without interfering
with the active part and by using the capabilities
of the off-lined part.
Maintenance and diagnostic tools and methods has been
developed using this fact to ensure that in case of
an error occurs, this error is isolated and corrected
using minimum repair time and effort.
System Responsiveness
In the proposed configuration, the user terminals (remote
terminals) are distributed on 8 branches of the local
area network. 4 Processor Unit's (PU's) are host-processors
for the user terminals, each serving 2 branches of
the local area network. In each branch of the local
area network, the data transfer rate of the bus is
0.8192 Mbit per second (i.e. the composite data transfer
rate on the local area network is 6.55 Mbit per second)
Thus the local area network configuration is structed
to provide a high data transmission rate with a low
delay. Estimates shows response time figures well
within the requirements of the RFP.
The processor configuration is powerful and a dedicated
Data Base Processor insures that the database memory
bank is operated efficiently and with minimum delays.
The proposed system contains facilities for transaction
logging.
The System Administrator is provided with facilities
for analysis of the transaction log, such as statistical
measures of processed transactions and responsetime,
etc.
Availability of User Terminals etc.
The terminals proposed for ACCESS in this proposal
have been selected to be compliant with the requirements
of the RFP, but also to be compliant with general requirements
for good quality and reliability.
In Part II, Subpart G of this proposal is provided
a recommendation of the maintenance support including
spares and spare parts to keep the availability of
the user terminals at the required availability level.
Each remote user terminal is connected to the local
area network bus with a separate adaptor box as explained
in detail in part II of this proposal.
This adaptor box is designed to ensure that failures
within the box or in the connected user terminal does
not cause failure of any other other terminal.
The dualized bus concept of the local area network
allows transmission to remote buildings via 2 separate
cryptological circuits. In case of failure on the
one circuit, the communication in the local area network
will be switched to the dual bus, which transmits on
the other circuit.
The proposed unique units are selected in accordance
with the following design criteria:
Each unit is designed using components and materials
with the necessary reliability integrated in accordance
with the best engineering practices to provide an overall
acceptable reliability design. This includes ease of
error diagnostics and replacement of faulty components.
Key aspects of maintenance are:
1) Trained technicians for maintenance.
2) Spare parts.
3) Preventive maintenance
See Part II-G, Contractor Support, for further description
of these items.
d. A̲r̲c̲h̲i̲t̲e̲c̲t̲u̲r̲e̲
Each video copier is connected only to one CGDU and
will only be accessible from that CGDU. Technical
details are found in part II of this proposal.
Letter quality printers are selfstanding remote terminals
and are not accessible by any other remote terminal.
The network configuration and architecture is described
in detail in part II of this proposal.
In the following the main features are highlighted
and shortly described.
- Each remote terminal is connected to the local
area network by an adaptor box. The local area
network has 2 separate buses, the one active and
the other stand-by. The adapter box connects to
both buses through two separate fail-proof galvanic
insolated circuits. Active and Stand-by mode of
the buses is controlled by the Host-Processors.
Each bus has separate Host Processor and separate
controller, separate amplifiers and separate communication
interface to cryptological circuits.
A failure in one of these functional units or in
the bus cables will cause bus failure and the other
Host-processor will take over communication on
the other bus.
Thus only a failure in the terminal or in the associated
adaptor will cause the terminal to be unavailable,
and no single failures will cause more than one
terminal to be unavailable and even the communication
medium, i.e. the bus cables of one bus can fail
without affecting the availability.
e. T̲E̲M̲P̲E̲S̲T̲ ̲R̲e̲q̲u̲i̲r̲e̲m̲e̲n̲t̲
All equipment placed outside the main computer room
meets TEMPEST Specifications as asked for in the RFP.
The following equipment is placed outside the main
computer room:
- Video Display Unit (VDU)
- Color Graphic Display Unit (CGDU)
- Video Copier (attached to a CGDU)
- Letter Quality Printer (DIABLO 630)
- Local Area Network Items.
Part II of this proposal provides data and specifications
for the types of equipment listed above.
f. W̲o̲r̲k̲ ̲L̲o̲a̲d̲ ̲S̲p̲e̲c̲i̲f̲i̲c̲a̲t̲i̲o̲n̲
An estimate of the workload on the proposed system
has been calculated based on the transaction volume
figures specified in the RFP.
The result of the calculations as well as the assumptions
made is shown in table f-1.
Four key figures for the performance of the proposed
system, namely:
- Data base size
- Local Area Network traffic
- Disc access load
- CPU load
have been calculated.
The requested 2,5 Gigabytes of application data for
increment 1 will be stored of 2 sets of 600 Megabytes
disks, providing 4,2 Gigabytes data area, accomodating
working storages and key index overhead.
The basic assumption made is that the busy hour transaction
volume is 0.3 times the specified per day figures.
The busy hour transaction volume has further been translated
into an average per second load.
TABLE f-1
ACCESS WORKLOAD CALCULATION
The calculated average per second transaction load
is used for comparison with the capacity of the proposed
system.
For each transaction type is estimated the resulting
Local Area Network traffic, number of disc accesses
and number of executed CPU instructions. The estimated
figures are shown in table f-1.
From table f-1 it is seen that the resulting total
average per second load figures are:
Network traffic: 15.4 Kbit/sec.
Disc accesses: 60/sec.
Executed CPU instr.: 30.7K/sec.
The capacity of the proposed front-end system (Local
Area Network plus related processors) is:
Network traffic: 6.5 Mbit/sec.
Disc accesses: 120/sec.
Executed CPU instr.: 4M/sec.
By comparison of the calculated workload terms the
capacity of the proposed system it is seen that the
workload constitutes the following percentages of the
system capacity:
Local Area Network: 0.2 %
Disc accesses: 50 %
Executed CPU instr.: 0.8 %
From the above figures it is seen that the average
workload per second only constitutes a fact of the
network and CPU capacity of the proposed system. This
fact will ensure that there is a wide margin for meeting
the response time requirements with a fluctuating real
life workload. The disc load of 50% of the capacity
ensures that disc queuing effects will be minimal.
Expansion of the system workload beyond 50% will only
require addition of extra disc drives.
The proposed system will provide an initial database
capacity of approx. 43oo Mbytes.
The proposed system will support 2000 user identifiers.
g. A̲u̲g̲m̲e̲n̲t̲a̲t̲i̲o̲n̲
a) The number of user identifiers can be increased
by 100% without affecting response time characteristics.
The user identifier lists are stored on the disc's
(80MB) attached to the PU's, and the disc capacity
is sufficient for this expansion.
b) The data storage capacity can be increased with
up to 500 percent with no changes in the application
programs as initially supplied. The impact on
equipment in the main computer room is shortly
described below.
The initial requirements for Data Base Size will
be met using, 2 x 7 Disc Drive Units (7 for each
of the dualized database parts).
The Disc Drive Units are controlled by a dedicated
database processor, with the capacity for max handling
16 disc drive units.
When the data base size exceeds 2 x 16 disc drive
units an additional database processor must be
added on each dualized database part.
To achieve 500 percent data storage increase in
total 2 x 33 disc drive units must be connected
and 2 x 3 database processors must be installed
to interface the disc drives.
Provided space Required space
Inc 1 7 x 0.6 Gb 2.5 Gb Basic
+ 0.5 Gb Working
̲ ̲ ̲ ̲ ̲ ̲ +̲ ̲ ̲0̲.̲7̲ ̲G̲b̲ ̲O̲v̲e̲r̲h̲e̲a̲d̲
4.2 Gb 3.7
Inc 3 33 x 0.6 Gb 2.5 Gb Basic
+ 5 x 2.5 Gb Augm.
+ 0.5 Gb Working
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ +̲ ̲ ̲ ̲ ̲ ̲4̲.̲2̲ ̲G̲b̲ ̲O̲v̲e̲r̲h̲e̲a̲d̲
19.8 Gb 19.7 Gb
The database processor can be controlled by the
same PU within the Back-End Processor.
If the data storage increase implicates an increase
in the database transaction traffic, the Back-End
Processor can be expanded with up to two additional
Processor Units (PU's), each interfacing a dualized
set of database processors.
In Part II of this proposal further details are
provided on the expansion option.
The installation description, Proposal Part II,
Subpart C, Section 3-3, shows how the total amount
of equipment can be placed in the main computer
room.
The modular concept used in the Christian Rovsing
proposal allows augmentation of system components
to be performed without scrapping of all equipment,
meaning that no part will become obsolete when
the system is expanded.
New IDM and associated disk drives for increment
3 has been incorporated in the cost porposal, meaning
that no extra hardware cost will be encounted.
Likewise the installation of the local area network
is prepared for all increments. No new cables will
have to be added in corridors to those installed
in increment 1. Only terminals and physical connections
to the junction boxes in the network will have
to be performed.
c) As explained in the above work load
calculations, 100 percent increase in the number
of transactions can be incorporated as required
by the RFP.
C̲5̲.̲ ̲L̲I̲N̲E̲ ̲I̲T̲E̲M̲ ̲0̲0̲0̲1̲.̲ ̲E̲Q̲U̲I̲P̲M̲E̲N̲T̲
a. C̲e̲n̲t̲r̲a̲l̲ ̲P̲r̲o̲c̲e̲s̲s̲i̲n̲g̲ ̲U̲n̲i̲t̲s̲ ̲(̲C̲P̲U̲s̲)̲
The configuration of the processor is described in
detail in Part II of this proposal.
The processor configuration servicing the local area
network contains 3 Processing Elements(PE's).
The 2 PE's are placed as Front-End Processors connected
to the branches of the local area network. The 3rd
PE is controlling the Database Memory disc bank. The
3 PE's are tied together with high-speed data transfer
buses.
In each PE is included several Processing Units (PU's)
in a dualized configuration, so that a PE is able to
continue operating in case of a single point failure.
each PU contains 2 CPUs operating in parallel.
The PE's are interconnected via a high speed data transfer
network, a supra-net, allowing each PE to communicate
with any of the two other PE's.
The data transfer rate on one supra-bus is 16 Mbit
per second.
If the power input exceeds the limits specified in
the RFP, this will be detected by the processor, and
the system will close down without physical damage
to the equipment.
When the power input is stable within the specified
limits, the automatic restart procedure can be initiated
by the operator.
The Processor interval timer provides a resolution
of 10 millisecond for a duration of 1 minute.
b. M̲a̲i̲n̲ ̲M̲e̲m̲o̲r̲y̲
The size of the memory in each PE is sufficient to
support the work load, performance and responsiveness
requirements of the RFP as explained above. All parity
errors in the main memory are detected by the CPU's
and an interrupt is generated to notify the operating
system.
Automatic error checking and correction is provided
to the extent that this is required by the processor
design.
The initial program loading of each PE is handled by
a bootstrap loader, which is resident firmware in each
PU of the PE's
Program loading is controlled from the operator console
terminals. Each PE has its own operator console.
c. I̲m̲m̲e̲d̲i̲a̲t̲e̲ ̲A̲c̲c̲e̲s̲s̲ ̲S̲t̲o̲r̲a̲g̲e̲ ̲(̲I̲A̲S̲)
The structure of the Processing Elements (PE's) is
described in detail in Part II of this proposal, subparts
B and C.
Each active Processor Unit (PU) within the PE is supported
by a set of 80 MByte Disc's, which are operated as
mirrored discs. No single failure will result in loss
of Disc capacity as the mirrored disc concept is supported
by the completely dualized hardware.
Initially the programs are loaded on the discs using
tape as input.
The disc capacity is sufficient to meet the peak work
load conditions of the RFP.
The database memory is located on a completely dualized
set of disc drive units.
The dualized database memory is supported by a completely
dualized Back-end Processing Element.
This structure ensures that no single component failure
will cause any percentage of the database memory to
be inoperable.
The first increment will include a dualized database
memory capacity of 2 x 4.35 Gbytes. This capacity is
sufficient to store the 2,49 Gbytes required for increment
1 (the Overhead is 75%).
d. O̲p̲e̲r̲a̲t̲o̲r̲ ̲C̲o̲n̲s̲o̲l̲e̲
Each of the 3 Processing Elements (PE's) has individual
operator console terminals.
The master console includes a VDU with keyboard and
a Receive-Only-Printer
The console terminals to the two other PE's are Printers
with Keyboard.
One Console component failure will not deprive the
system of the ability to continue processing.
Specifications are provided in Part II of this proposal.
e. M̲a̲g̲n̲e̲t̲i̲c̲ ̲T̲a̲p̲e̲
Part II of this proposal and the associated technical
literature gives the specifications of the proposed
magnetic tape units. The tape units meets the requirements
of the RFP.
The 3 Tape Drives are placed one in each Front-End
Processor on one in the Back-End Processor, but they
are all connected to the Back-End Processor.
Ref.RFP C5e(3):
Write protection is provided (write rings).
Ref.RFP C5e(4):
BOT (Beginning Of Tape) and EOT (End Of Tape) are recognized
by optical detection.
Ref.RFP C5e(5):
The tape drive performs reading while writing. Stored
bytes are continuously checked for correct parity.
Parity errors are reported to the tape handler S/W,
and further actions (i.e. corrective actions) are taken
by the tape handler S/W.
Ref.RFP C5e(6):
The tape handler S/W decides when an error is unrecoverable
and notifies the operating system.
f. G̲r̲a̲p̲h̲i̲c̲ ̲D̲i̲g̲i̲t̲i̲z̲e̲r̲ ̲a̲n̲d̲ ̲C̲o̲l̲o̲r̲ ̲G̲r̲a̲p̲h̲i̲c̲s̲ ̲C̲a̲m̲e̲r̲a̲
A computer graphics sub-system is proposed for digitizing
graphic representations. The digitizer pad proposed
is:
Houston Instruments Hi Pad
Model DT 11 rev.H.
The resolution is greater than 100 points per inch
with a corresponding accuracy better than 0.01 inch.
The system will interface directly to the on-line ACCESS
System via X-NET.
This subsystem is a complete workstation. The workstation
includes:
i) Graphic Computer System
ii) Operator Console. The Console is a 15 inch
black and white CRT with Keyboard
iii) Color graphic display system including a 19
inch high resolution Color CRT.
iv) Digitizer tablet with tablet range from 11
inches by 11 inches.
v) Dual format Camera Recording Subsystem providing
- 35 mm slides
- overhead transparencies
- 8 x 10 inches Polaroid color prints
Part II of this proposal and the associated technical
literature provides a more detailed specification and
description of the proposed computer graphics system.
The system provides an excellent solution for handling
of graphic information in accordance with the requirements
of the RFP.
g. 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̲
High Speed, Non-Impact Printer
The proposed printer meets the requirements of the
RFP.
Further details and specifications can be found in
Part II of this proposal and in the associated technical
literature.
h. L̲i̲n̲e̲ ̲P̲r̲i̲n̲t̲e̲r̲
The aggregate print speed of 900 lines per minute is
met by using one Line Printer.
Part II of this proposal and the associated technical
literature gives the specifications of the proposed
Line Printer.
The Line Printer meets the requirements of the RFP.
i. L̲e̲t̲t̲e̲r̲ ̲Q̲u̲a̲l̲i̲t̲y̲ ̲P̲r̲i̲n̲t̲e̲r
The letter Quality Printers proposed for the Access
System has been selected to meet the requirements of
the RFP.
The technical literature associated to Part II of this
proposal provides further specifications and detailed
information.
j. R̲e̲m̲o̲t̲e̲ ̲T̲e̲r̲m̲i̲n̲a̲l̲s̲
(1) Video Display Unit (VDU)
The VDUs included in these proposals have been selected
primarily to meet the requirements asked for in the
RFP.
Another important decision parameter has been the very
good experience Christian Rovsing A/S has had working
with the proposed subcontractor on other projects.
The VDU screen is equipped with almost invisible metal
network which ensures TEMPEST capabilities. However,
this network is not of any anoiance to the user.
Further details and specifications on the VDUs are
found in the technical literature associated to Part
II of this proposal.
(2) Color Graphic Display Unit (CGDU)
The Color Graphic display subsystems have been selected
for this proposal because they provide an excellent
solution to the requirements called for in the RFP.
The CGDU is protected in a similar fashion as the VDU
to ensure TEMPEST capabilities without reducing ergonomic
features.
For further details and specifications, please read
the technical literature associated to Part II of this
proposal.
k. O̲p̲t̲i̲c̲a̲l̲ ̲C̲h̲a̲r̲a̲c̲t̲e̲r̲ ̲R̲e̲a̲d̲e̲r̲ ̲(̲O̲C̲R̲)̲
The OCR proposed for the Access application meets the
requirements of the RFP.
The OCR works in accordance with "best guess" mode.
One line of text on the input sheet is scanned and
stored internally, before analysis. The analysis compares
each character position with an internal model representation,
depending on the character set used. The OCR automatically
covers small disalignments of characters by making
several comparison starting at different starting point.
All comparisons of a character position to every internal
character representation results in a score. The highest
score results in selecting the character in question
as "best guess".
For further details and specifications, please refer
to the technical literature associated to part II of
this proposal.
l. C̲o̲l̲o̲r̲ ̲G̲r̲a̲p̲h̲i̲c̲s̲ ̲C̲a̲m̲e̲r̲a̲
Color Graphics Camera the Color Graphics Camera is
part of the computer graphics subsystem described in
C5.f above (Graphic Digitizer).
m. V̲i̲d̲e̲o̲ ̲C̲o̲p̲i̲e̲r̲
The proposed video copiers can be connected to the
CGDUs to provide monocolor reproduction images on paper
of the images created on the CGDU.
The proposed video copier will meet the requirements
called for in the RFP. For further details and specifications,
please refer to the technical literature associated
with part II of this proposal.
n. C̲o̲l̲o̲r̲ ̲G̲r̲a̲p̲h̲i̲c̲ ̲C̲o̲p̲i̲e̲r̲
The color graphic printing station proposed will output
digitized data displays from the database. Output can
be on paper or on transparency materials both monocolor
and color.
For further details and specifications, please refer
to the technical literature associated with part II
of this proposal.
C̲6̲ ̲L̲i̲n̲e̲ ̲I̲t̲e̲m̲ ̲0̲0̲0̲2̲ ̲C̲o̲m̲m̲u̲n̲i̲c̲a̲t̲i̲o̲n̲s̲
A local area computer network will be provided.
The network consists of 8 Time division Multiplexed
(TDX) buses connected to a central CR80 Fault Tolerant
Computer System. The aggregate terminal-to-processor
bandwidth is 8 x 819.2 Kbps = 6.5 Mbps.
A total of 102A terminals can be connected to the network.
Bandwidth for each connected terminal can be allocated
dynamically up to 9.6 Kbps.
CGDUs, VDUs, and LQPs will be connected to the CR-80
X-NET by means of tempest low level filter MIL-188-114
connectors.
XTA's interfacing to these devices will be programmed
to transfer data at 96oo bpsj. This transfer rate can
be accommodated by each terminal (CGDU, VDU and LQP).
a. Sub-line Items 0002AB, and 0002AC Initial Communication
System
The following Hardware (subline items 0002AB) and
Software (SCLIN 0002AB) Items (Note purchase only)
will be provided to the full degree and extent
specified in this proposal for the Initial Communication
System:
(1) Government Provided Communiction Links. Secure
communication links between buildings 501 and buildings
40, 41, and 407 will be provided and maintained
by the Government. Cryptographic Units will be
used to secure the data in the communication links.
Three cryptographic units located in room U102D
in building 501, one in room A206 within building
40, one in room 323 within building 41, and one
in room 34 within building 407 will be installed.
The Government will make the physical attachment
to the cryptographic units.
In addition the Government will provide space in
the crypto-rooms for Contractors Interface Equipment.
The Government will provide cable ducting and
power for contractors equipment in the rooms.
Contractor will provide and install the crypto
interface cable and terminate the cable at contractors
equipment. The Government will terminate the cable
at the cryptographic units.
(2) Cableways/Conduit. The Government will provide,
install, and maintain all conduit (including all
junction boxes) for the communication medium based
upon the Contractor's network topology. The Contracter
will specify locations for the Government to install
junction boxes to support at least 1800 terminal
device connections relatively evenly distributed
throughout the designated areas of buildings 500/501
as explained below. Schematics conduit is to be
installed. The Contractor will provide network
support devices and provide their locations and
specifications, see below. The Steel Electrical
Metallic Tubing (EMT) Conduit will be two inches
in interior diameter. The Government will provide,
install, and maintain the physical intrusion security
system necessary to secure the cableway and rooms.
In building 500 the conduit will be routed within
the suspended ceiling in each hallway. The suspended
ceiling is approximately three feet below the structual
ceiling but is densely packed at corridor intersections
with conduits and airducts. The Government can
not insure straight conduit runs down hallways
and will not provide environmental conditioning
or control in the suspended ceiling. However,
the conduit will adhere to the contractor's specified
topology and will deviate only where physical obstructions
require. In building 501 the conduit can not be
routed down any significant length of hallway because
of densely packed pathways; therefore, the contractor
will use the area above the suspended ceiling within
the rooms to design the most expeditious, expandable
network layout without regard to hallways. A distance
of approximately 160 feet, separate buildings 500
and 501.
In building 40, 41, 407 the EMT Conduit will be
installed in existing hallways.
The SPR will also specify the additional conduit
to be provided and installed by the Government
between a junction box and a wall outlet for a
terminal device. The wall out will be provided
and installed by the contractor.
The routing of the EMT, location of junction boxes,
contractor provided support device, wall outlets
for terminal devices will be determined, together
with the Government during a site survey. (see
PART II, Section 7.2.1)
(3) Installation. The Contractor will provide, install
and maintain to the degree and extent as specified
in this proposal all equipment and software necessary
to establish the network including all access nodes,
interfaces, communication components for terminal
devices shown in Table C-1 of the IFB. In addition,
the Contract will provide the medium to support
the terminal devices in Tables C-1 and C-2. of
the IFB. Planned terminal locations for terminal
devices shown in Table C-1 are shown in Table C-4
of the IFB. The Contractor will provide the interface,
either MIL-STD-188C or MIL-STD-188-114 (balanced
or unbalanced), to the cryptographic units.
(4) Communication Medium. The Contractor will provide,
install and maintain to the degree and extent as
specified in this proposal the communication trunk
line to service every room within building 500/501
(excluding those rooms identified in the schematic
- rest rooms, cafeterias, etc.). In buildings
407, 40 and 41 only the indicated rooms will be
serviced. Cable pulling wire will be available
in the conduit at Contractor specified junction
boxes. The Contractor will insure that the medium,
when installed in the Government provided conduit,
meets the TEMPEST requirements of NACSIM 5100A.
The Contractor will make the network so that terminal(s)
in one location can be moved to any room serviced
by the network within buildings 500/501, attached
to the network at the appropriate junction box
and operated as explained in Section 3.3 and PART
II, Section 2. The attachment to the medium of
additional terminal devices will be without modification
to the trunk line conduit. …86…1 …02… …02… …02…
…02…
The EMT provided and installed by the Government
will be hard drawn seamless steel tubes, which
together with the shielding of the Contractor provided
cable shall provide the required continuation
Comsec installation criterias specifies that waterpipes
or some types of electrical conduits meets these
requirements. Contractor will detail his requirements
to the EMT in the SPR. The cable specification
of the contractor provided cable for the network/trunk
line is given in PART II, Section 3.
To support communication the System Administrator
has the following capabilities:
a) Dynamically connect or block terminal devices
and hosts from the local area network.
b) List all user id's, terminal id's and programs
for all logged-on users.
c) Selectively calculate response time statistics
for 30 terminal devices.
d) Selectively calculate communication traffic
statistics for 30 terminal devices and 1 processor.
b. Sub-Line Items 000 2AD, 0002AE and 0002AF.
Communication System Expansion
The following hardware (SCLINs 0002AD and 0002AE)
and software (SCLIN 0002AF) are required for second
increment purchase:
The Contractor will provide, install, and maintain
to the degree and extent specified in this proposal
all equipment and software necessary to expand
the network including all access nodes, interfaces,
and communication components for terminal devices
shown in Table C-2 and Table C-3 of the IFB. In
addition, the medium for terminal devices on Table
C-3 is to be provided. Planned locations for terminal
devices shown in Table C-2 are shown on Table C-4
of the IFB. Locations for terminal devices shown
in Table C-3 are not specified at this time, but
will be located in building 500/501, 40, 41 and
407. The Contractor will provide the interface,
either MIL-STD-188C or MIL-STD-188-114 (balanced
or unbalanced), to the cryptographic units. Site
preparations and installation of second increment
purchase will be on the conditions specified for
first increment purchase.
c. Sub-Line Item: 0002AG, 0002AH and 0002AJ,
Interfaces to Long-Haul Communications Network
An interface to the ARPANET will be provided directly
to the central CR80 Computer System which will
handle the TCP/IP. Users in the local area network
will communicate with the ARPANET by means of calls
to the IP-module as outlined in para 3.4 of the
Internet Protocol Specification.
The proposed implementation will be in accordance
with method no. 3 outlined in the RFP.
C̲7̲ ̲L̲i̲n̲e̲ ̲I̲t̲e̲m̲ ̲0̲0̲0̲3̲,̲ ̲S̲y̲s̲t̲e̲m̲ ̲S̲o̲f̲t̲w̲a̲r̲e̲
a. Sub-Line Item 0003AA, RESERVED
b. Sub-Line Item 0003AB, Operating System
(1) The Highlevel Operating System (HIOS) will
provide concurrent support of:
(a) Interactive processing
(b) Batch processing
A queue monitor will control scheduling of
the interactive as well as the batch queue.
(2) A queue monitor will provide facilities for
dividing both the interactive - and the batch
queue into a number of subqueues, one for each
priority.
(3) Automatic task preemption is supported by the
queue monitor.
(4) DAMOS Resource Manager monitors resource utilization.
No job will be allowed to exceed a specified
limit of resources.
(5) DAMOS Page Manager executes access control
to all memory.
(6a) File attribute listing is supported by HIOS.
The attributes listed are:
- Space allocated
- Access rights
- Date created
- Date of latest update
- Date of last access
(6b) Transfer of ownership rights is supported by
entry of valid permission code.
(6c) File concatenating is supported under the constraints
of access control.
(6d) File copying from one directory to another
is supported under the constraints of the access
control mechanisms.
(6e) File creation deletion, removing and retrieval
is supported under the constraints of access
control.
(6f) Program development, compilation, linking,
debug and execution is supported in HIOS and
the provided utilities and language processors.
(6g) A library function is included in the provided
utilities.
(6h) The operating system will provide interactive
display of all jobs in the different queues.
Per queue status information containing job,
priority and program name will be displayed.
(6i) Processing of command files is supported.
(6j,6k) File copy utilities will be provided for saving/restoring
files on/from tape.
(6l) The system administrator has capabilities for
user password control and he can delegate this
capability to the individual user, who then
can change his own password.
(6m) The System Administrator will have control
of access right allocation to files, directories
and users.
(6n) (6m) Applies also for System Software.
(6o) The ability to interrupt a process and related
output is provided under the constraints of
the access control mechanism.
(6p) Processing output can be directed to spool
files which in turn can be queued for output
on:
(a) Camera
(b) Color Graphic Copier
(c) Line Printer
(d) High Speed Non-Impact Printer
(6q) Color Graphic screen images can be directed
for output to:
(a) Camera
(b) Color Graphics Copier
(c) Video Copier
(6r) Interactive as well as batch processing can
be initiated by all users.
(6s) A checkpointing mechanism is automatically
executed and a checkpoint stored on disk at
predefined points of each transaction. Upon
recovery after a system failure, all tasks
are resumed from the context saved in the latest
checkpoint related to the task.
(6t) A user controlled logging facility for logging
of a terminal session.
(6u) All system console operations are logged on
the attached printer.
(6v) The user transaction log will be used for generation
of usage statistics.
(6w) DAMOS Kernel provides facilities for generation
of CPU time and job execution statistics.
(7) HIOS provides facilities for creation and execution
of command files.
(8) HIOS provides facilities for display of a calender
clock at all terminals connected to the local
area network.
The displayed clock format is:
HHMMSS for time and YYMMDD for date.
(9) A timer monitor is included in DAMOS Kernel.
(10) HIOS provides the System Administrator with
the facility to control user environment characteristics
including:
(a) Default terminal characteristics, i.e.
screen format and character type
(b) Default menu display.
(c) Access rights
(11) By means of commands the user can override
menu selections, and go directly to a specified
function.
(12) HIOS provides the user with the facility to
create login command files. The command files
can execute any command and set flags used
to control task execution.
(13) HIOS provides the System Administrator with
capabilities to:
(a) Specify access rights to all directories
and their associated files
(b,c) List the attributes and contents of all
files assigned to each directory
(d) Assist users by means of simultaneous monitoring
of any selected user's screen image
(e) Control space allocated for directories
(f) Maintain user passwords
(g,h) Create/delete directories
(i) Specify user access rights
(j) Maintain user profiles
(k) Specify user profiles
(l) Maintain job class type per user request
(m) Control default user environment characteristics
(n) Override or modify sytem generated passwords.
(o) Printout of password list through the report
writer
(p) Any user can request assistance from the
System Administrator.
The System Administrator can assist any
user by having all input/output to/from
a selected user directed to his terminal.
(14) HIOS provides the System Operator with
capabilities to:
(a) Logically remove and replace individual
devices from the configuration without
disrupting the continuity of operation.
(b,c) Job queue control
(d) The operating system will provide interactive
display of all job queues.
Per queue status information containing
job priority and program name will be displayed.
(e) Change job priority for jobs, awaiting
execution and in any output pending queue
(f) Start, stop and restart jobs for the purpose
of manual scheduling of job execution
(g) Save files on off-line storage media
(h) Retrieve files from off-line storage
(i) Send messages to all logged-in users on
and off individual or broadcast basis
(j) Software control for normal system operation
(k) Allocate users to a processor
(l) Receive reports on hardware failures in
the system, exclusive terminal equipment
(m) Transfer operator controls to another terminal
(15) HIOS provides capabilities for automatic
switch-over, restart and recovery.
Recovery procedures are differentiated
according to the type of failure.
Downtime related to switch-over and recovery
will be less than 5 minutes.
(16)(a1) Any change in the system file and system
software identifiers can only be accomplished
via a system initialization procedure.
The System User Catalogue is only available
to the System Administrator
(a2) User Identifiers can be up to 12 ASCII
characters. Passwords and User Identifiers
are changeable solely by the System Administrator.
(a3) Passwords must be alphabetic and from 6
to 8 characters in length. Password entry
will not be echoed to the user terminal.
(16)(b1) No user will be provided access to any
system resources prior to the correct entry
of the user's unique identification and
password.
(b2) DAMOS Kernel provides access protection
for all objects controlled by the Kernel,
these include:
(b2a) Main memory
(b2b) Virtual memory residing on disc
(b2c) Memory occupied by the operating system
program and data
(b2d) File access protection is provided through
the File Management System (FMS).
(16)(b3) The File Management System (FMS) executes
access control to all files contained in
the sytem
(b3a) Each file has an Access Control List (ACL)
which contains user identification and
access rights for users with access permission
to the file
(b3b) User access rights can be designated as
read only, read-write or execute only.
Users can create files within their own
directories.
(b3c) The user identification specified in the
file Access Control List can either be
individual user id's of user group id's.
(b3d) Each file has an associated ACL.
(b3e) The Database Administrator can define views
and associated ACL for database files.
Users can create file within their directory
for storage of text or graphic displays.
At file creation time the user must specify
the ACL associated to the file.
(b3g1) File access under the constraints listed
above can only be accomplished subsequent
to successful login.
(b3g2) File access permission is only provided
to users fulfilling the criterias defined
by the System - or Database Administrator.
(b3h) Printout of files on a letter quality printer
can only be performed for files which have
classification lines inserted.
(16)(c) The proposed system will store classified
data in accordance with DOD 5220.22-M.
(16)(d1) Unauthorized attempts to access files will
be rejected and logged.
(d2) Three consecutive rejections at network
login will result in a termination message
at the terminal and immediate blocking
of any further input. A notification will
be printed at the Operator's printer.
(d3) Summary reports can be extracted from system
generated based on events specified by
a combination of up to four of the following
parameters:
- time interval
- terminal identifier(s)
- user identifier(s)
- system user job
- system and system user file(s)
- unauthorized access attempts
(e) All hard copy output to the high speed
non-impact printers and line printers will
have classification lines at the top and
bottom of each page unless the user specifically
commands suppression of the lines.
(f) A terminal which has remained inactive
for more than 15 minutes will automatically
be logged off. This function can be overruled
for users specified by the System Administrator.
(17)(a) Failure reports will be generated for each
failure occurance. The report shall contain
failure description, time of occurance
and elapsed time before full recovery.
Summary failure reports, with resulting
availability calculated, can be generated
for a specified time period.
(b) Based on user transaction logging data
is available for generation of response
time reports. Data is grouped per command
or transaction type. Statistical measures
of the data can be calculated to provide
response time distribution, average and
maximum.
(c) Based on user transaction logging data
is available for generation of workload
measurement reports. Data is grouped by
user and job number, and contains the number
of transactions processed by transaction
type, the number of file accesses performed
and the consumed CPU time. This report
will contain subtotals by hour and date,
and an overall total for period concerned.
(d) The combination of the reporting facilities
described under (a), (b) and (c) above
will provide the necessary tools for sampling
and tracking system performance during
the life of the contract.
c. Sub-Line Item 0003AC, Data Base Management System
(DBMS)
D̲a̲t̲a̲ ̲B̲a̲s̲e̲ ̲M̲a̲n̲a̲g̲e̲m̲e̲n̲t̲ ̲C̲o̲n̲c̲e̲p̲t̲
The Data Base Management is provided by two identical
IDM Systems using the relational concept of data base
management. The IDM (Intelligent Database Machine)
is a stand alone system, which interfaces up to 8 host
computer systems, each serving multiple user on-line
and batch processing. Being a selfcontained system
dedicated to relational database management the IDM
system offers all facilites to protect data security,
to insure fast data retrieval for on-line query and
report generation, and to support data input and modification.
Access by multiple users for interactive and batch
processing for both updating and retrieval of information
is provided by the IDM without information about the
nature of the application program (on-line or batch),
as it only serves the requested access operations transaction
by transaction.
Each transaction, which may contain several groups
of updates and retrievals, is handled with respect
to any other transaction processed by the system at
the same time, due to the possibility to share reads
from the same data block and to perform exclusive read,
write and update functions. While serving an exclusive
operation by one transaction the IDM automatically
queues all other transactions operating upon the same
datablocks, while transactions operating upon other
datablocks will be served simultaneously.
Application program data independence from physically
stored data structures is secured by the use of the
relational approach in the IDM, where the only references
to data base information in the transaction sent by
the host computer system consists of logical names
of relations and attributes and attribute values.
The file support functions, which support the use of
traditional storage and retrieval of non-database information
are subject to the access navigation imposed by the
application programs.
Data base creation facilities for the initialization,
loading and documentation of the data base are provided
for, due to the fact, that description of the data
base for system use is maintained in the same way as
any other information. So the data base initialization
is input of logical names of relations and attributes
describing the data base and attribute formats.
Loading the data base is performed in the very same
manner, though facilities for bulk load of data are
also available.
The data base description information is accessible
for update (partly), retrieval and output as is any
other information for which the present user has appropriate
access permission.
Access through application programs compiled or assembled
by the language processors are provided by the capability
to embed data base commands in the application source
program.
The embedded data base commands may be the IDM communication
format, though the actual way to accomplish this will
be to state the requested data access, in terms of
the General Purpose Query Language IDL. A precompiler
then translates the data base commands into proper
source language reflecting the IDM comunication format.
RFP C7 c (1) Multiple User Access
Access by multiple users for interactive and batch
processing for both update and retrieval of information
is provided, see above. (Ref. IDM page 3-9, part 3.3.2)
RFP C7 c (2) Data Independence
Application program data independence from a structures
in the data bases is secured, while data input through
the file support is subject to traditional application
programming efforts, see above. (Ref. IDM page 5-11,
part 5.7 and page 7-78 part 7.5.34)
RFP C7 c (3) Data Base Creation and Load
A data base creation facility for the initialization,
loading and documentation of the data base is provided
for, see above, and the data base description information
is accessible, if the user has appropriate access permission.
(Ref. IDM page 2-1, part 2.1.1, page 2-2, page 2-4
part 2.1.4, and page 3-3 part 3.2)
RFP C7 c (4) Application Program Access
Access through application programs compiled or assembled
by the language processors are provided by the capability
to embed data base commands in the application source
program, see above (Ref. IDM page 5-8, part 5.5).
Q̲u̲e̲r̲y̲ ̲L̲a̲n̲g̲u̲a̲g̲e̲ ̲G̲e̲n̲e̲r̲a̲l̲ ̲C̲h̲a̲r̲a̲c̲t̲e̲r̲i̲s̲t̲i̲c̲s̲
A query language to process data in any file (data
base) is provided through appliction dependent interface
programs (application programs) using the General Purpose
Query Language IDL as a embedded query language. Both
for application program usage, i.e. electronic mail,
and for direct data base interogation by the user,
the IDL embedded query language is used. Being an application
program itself the Direct Data Interrogation Program
(DDIP) diverse from the standard IDL in order to meet
the requirements of each subsystem. So the DDIP forms
a common interrogation language with application dependent
variances in functions and data access range.
The DDIP is an interactive program so the response
to a query is by default directed back to the terminal.
By a simple inclusion of the keyword 'into' the response
is instead stored as a new relation with the name provided
by the user.
Response to a query may be directed to a specified
output device through the report generator program
commands included in DDIP, or it may when directed
to the terminal, be used for further menu driven processing
including direction to any output devices such as printers
and magnetic tapes controlled by either the report
generator program or an application program.
The DDIP suports, as an IDM service, the ability to
perform tabulations and simple arithmetic functions.
Through the menu driven interface the ability is extended
with the features supported by the statistical package.
Creation of a query is on user request supported by
dictionary information from the data base system relations
through the DDIP services, see c (8) below. Extended
services may be requested from data base information
about logical relationships maintained by the Data
Base Adinistrator for each application. Furthermore,
the query creation is guided by error responses to
ommitted commands specifying the error type and the
query element in error.
Search of information is permitted using any number
of attribute references, which may be relevant for
the referred relations.
RFP C7 c (5) Query File Usage
A query language to process data in any file (data
base) is provided through application dependent interogation
programs DDIP and application programs using the General
Purpose Query Lanuage IDL, see above (Ref. IDM Software
Reference Manual page 5-8, part 5.5)
RFP C7 c (5) (a) 1 Response to Terminal or Storage
Response to a query is by default directed back to
the terminal or may be stored as a new relation.
(Ref. IDM Software Reference Manual page 2.4 part 2.1.5
and page 2-7 part 2.1.8).
RFP C7 c (5) (a) 2 Respone to Output Devices
Response to a query may directly or later be output
to any output device, see above.
RFP C7 c (5) (a) 3 Response Tabulation etc.
The query system supports tabulations, arithmetic functions
and features supported by the statistical package,
see above. (Ref IDM Software Reference Manual page
3-27 part 3.9.4).…86…1 …02… …02… …02… …02…
RFP C7 c (5) 4 Query Creation Support
Creation of the query is supported by dictionary information
and other data base information requested and is subject
to error check and error responses, see above.
RFP C7 c (5) 5 Number of Search Criteria
Search of information is permitted by using any number
of attribute references, which may be relevant for
the referred relations.
Q̲u̲e̲r̲y̲ ̲L̲a̲n̲g̲u̲a̲g̲e̲ ̲I̲n̲p̲u̲t̲ ̲F̲a̲c̲i̲l̲i̲t̲i̲e̲s̲
Development of a query in the DDIP for application
users is supported by prompting dependant on the application
in use and the prior input parts of the query. An
extended prompting text (help-function) can be invoked
by the users choice. The IDL embedded query language
is an English-like language and the DDIP may furthermore
reflect a terminology closer to each application domain.
One query command is able to retrieve data from up
to 15 relations (files) within one database, while
an application dependent number of data bases may be
accessed within one transaction.
The DDIP provides interactive editing of syntax, terms
and element names and provides the use of the boolean
operators OR and AND in the qualification clause.
RFP C7 c (5) (b) 1 Query Prompt/Help-Function
Development of a query supported by prompted and extended
text (help-function) is provided, see above.
RFP C7 c (5) (b) 2 English-like Language
An English-like language is used.
Suppose you have the following database:
t̲y̲p̲e̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲c̲o̲l̲o̲r̲ ̲ ̲ ̲ ̲f̲l̲a̲v̲o̲r̲ ̲ ̲ ̲ ̲ ̲ ̲b̲o̲d̲y̲
̲ ̲
scheurebe white sweet medium
burgundy red dry medium
beaujolias red dry light
chianti red dry medium
cabernet sauvignon red dry medium
pinot noir red dry light
zinfandel red dry full
chablis white sweet light
liebfraumilch white fruity light
pinot chardonnay white dry medium
johannisberg riesling white sweet light
grey riesling white sweet light
grenache rose rose sweet light
fume blanc white fruity medium
chenin blanc white fruity light
gamay beaujolias red dry medium
gewurztraminer white fruity light
merlot red dry medium
petit sirah red dry light
vin rose rose sweet medium
rhine white sweet light
riesling white sweet light
chinon red dry light
port red sweet full
medeira red sweet medium
sherry red sweet light
beauclair white dry light
chardonnay white sweet light
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
̲ ̲
This relation has all sorts of interesting information
about wine. This is a very nice relation, but it is
also a very big relation. It has information about
all kinds of wine, but only one type of wine. For instance,
if you are having beef for dinner, you will probably
want to have a red wine. Therefore, you want to see
only the information about red wines. The IDM has the
answer. Type the command:
Retrieve (k.all) where k.color = "red" go
You should now see the following response:
t̲y̲p̲e̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲c̲o̲l̲o̲r̲ ̲ ̲ ̲ ̲ ̲f̲l̲a̲v̲o̲r̲ ̲ ̲ ̲ ̲
̲b̲o̲d̲y̲ ̲ ̲ ̲ ̲ ̲
burgundy red dry medium
beaujolias red dry light
chianti red dry medium
cabernet sauvignon red dry medium
pinot noir red dry light
zinfandel red dry full
gamay beaujolias red dry medium
merlot red dry medium
petit sirah red dry light
chinon red dry light
port red sweet full
medeira red sweet medium
sherry red sweet light
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
The IDM has printed all of the attributes (columns)
but it has not printed all of the tuples. It has printed
only the tuples where the color is red. In IDL (our
special language) the words 'where k.color = "red"'
is called a 'qualifier'. A "qualifier" tells the IDM
that you do not want to see all of the tuples (rows).
You are setting up a test (k.color = "red") and the
IDM should only print tuples that qualify (can pass
the test).
Queries (questions) that are written in IDL look something
like question written in English. For instance:
ENGLISH: Show me a type of wine where k.color is
red
IDL: retrieve (k.all) where k.color
= "red"
It is much easier to ask questions in English than
it is to ask them in IDL. However, computers can not
yet understand English as we speak or write it. As
you practice with IDL you will find it much easier
to phrase your questions in IDL.
RFP C7 c (5) (b) 3 Number of Files
One query is able to retrieve data from up to 15 relations
(files) within one database. (Ref IDM Software Reference
Manual Page 7-82 paragraph 'description').
RFP C7 c (5) (b) 4 Query Editing
Interactive editing of syntax, terms and element names
is provided, see above.
RFP C7 c (5) (b) 5 Boolean Operators
The query language provides the use of the boolean
operators, see above (Ref IDM Software Reference Manual
page 7-4) bottom line).
Q̲u̲e̲r̲y̲ ̲L̲a̲n̲g̲u̲a̲g̲e̲ ̲P̲r̲o̲c̲e̲s̲s̲i̲n̲g̲ ̲F̲a̲c̲i̲l̲i̲t̲i̲e̲s̲
The query language supports logical and mathematical
manipulation of data as the user has the possibility
to use relational operators on data and to define response
items as arithmetic expressions using data in the data
base as operands. Using the IDM supported aggregate
facilities the user may perform grouping operations
for total counts and specified calculated fields.
The ability to automatically decode fields lies within
the concept of DDIP as an application dependent query
editor. Prestored views are automatically exchanged
with input name references, forming an extension of
the input text. The same ability is due to the simple
use of combined attributes from two or more relations,
when decoding has not been previously planned.
The user has the ability to limit the output of a data
extraction either by further qualification or in query
mode for application users by setting a maximum number
of output lines or elements from the prime relation.
RFP C7 c (5) (c) 1 Data Manipulation
The query language supports the ability to logical
and mathematical manipulation of data, see above. (Ref.
IDM Software Reference Manual page 3-27, part 3.9.4,
page 2-9 part 2.2.2 and page 7-5 relop and arithop
).
RFP C7 c (5) (c) 2 Grouping Operations
The query language supports the ability to perform
grouping operations for totals, counts and specified
calculated fields. (Ref. IDM Software Reference Manual
page 2-9, part 2.2.2 (aggregates) to page 2-l3).…86…1
…02… …02… …02… …02…
RFP C7 c (5) (c) 3 Field Decoding
The query language supports the ability to decode fields.
(Ref. IDM Software Reference Manual page 1-3 part
1.1.4).
RFP C7 c (5) (c) 4 Query Editing
The user has the ability to limit the output, see above.
Q̲u̲e̲r̲y̲ ̲L̲a̲n̲g̲u̲a̲g̲e̲ ̲O̲u̲t̲p̲u̲t̲ ̲F̲a̲c̲i̲l̲i̲t̲i̲e̲s̲
The DDIP uses the report writer as an output facility,
when the IDL facilities for output formatting is insufficient
for the query mostly in the same way as the user himself
may use it directly. So the facilities of the report
writer is available including the ability to repeat
headings for listings of output on all pages, to format
data items, optionally to round or tuncate numerical
fields and to automatically align decimal points or
other punctuations for fields.
The report writer as used by DDIP has the ability to
specify up to five control break levels (subtotals)
for up to ten columns.
The results of a query is always stored in the terminal
storage unless otherwise requested. The content of
the terminal storage files may be used for further
processing by other application programs. So it is
also able to be incorporated into an electronic mail
message or kept for later printing.
RFP C7 c (5) (d) 1 Repeated Page Headings
The query language repeats headings for listings of
output on all pages, see above. (Ref. IDM page Software
Reference Manual 5-13, part 5.9).
RFP C7 c (5) (d) 2 Response Usage
The results of a query can be incorporated into an
electronic mail message or used by other software,
see above. (Ref. IDM Software Reference Manual page
3-19, part 3.7).
RFP C7 c (5) (d) 3 Later Response Printing
The results of a query displayed on a screen can be
directed to a file for later printing. (Ref. IDM Software
Reference Manual page 5-13, part 5.9).
RFP C7 c (5) (d) 4 Optional Round or Truncate Numerical
Fields
There is the ability to optionally round or truncate
numerical fields.
RFP C7 c (5) (d) 5 Control Break Levels
There is the ability to specify up to five control
break levels (subtotals) for up to ten columns.
RFP C7 x (5) (d) 6 Decimal Point Alignment
The query language will automatically align decimal
points or other punctuations for fields.
Q̲u̲e̲r̲y̲ ̲R̲e̲u̲s̲e̲
Queries developpen by the user can be stored in the
form entered by the user for later modification and
submission.
The IDM permits to store a query as stored commands
and views and allows it to be reused by the user or
other users, who have the proper access permission.
Stored queries are as an IDM facility able to be reused
either in their entirety or with addition or modification
of specific parameter values by the current user, while
stored views are preprocessed and therefore have to
be reused without changes.
Stored queries and views are catalogued by IDM and
the data dictionary is then used by DDIP to support
menu driven retrieval or for direct selection by the
user.
RFP C7 c (6) Query Reuse
Queries may be stored and reused by the user or other
users, subject to security constraints, see above.
(Ref. IDM Software Reference Manual page 3-15, part
3.5.2).
RFP C7 c (6) (a) Modified Query Usage
Stored queries are able to be reused either in their
entirety or with addition or modification of specific
parameters by the current user, and they are catalogued
to support menu driven retrieval. (Ref. IDM Software
Reference Manual page 7-63 and page A-2).
RFP C7 c (6) (b) Catalogue Query Selection
The data directory, which holds the catalogue of relations,
inclusive stored queries, is accessible almost as other
relations.
P̲r̲i̲v̲a̲c̲y̲ ̲a̲n̲d̲ ̲S̲e̲c̲u̲r̲i̲t̲y̲
Privacy and security is provided for every single data
item (attribute) in every relation (file). The Data
Base Administrator and each user (for his own relations
and views) may grant and deny access to data for each
other user, and specify this for each access mode.
Access validation and authorization is performed for
each data item (attribute), when referred to directly
or indirectly during retrieval, update and write.
Some access permissions are dependent upon data values
stored in the data base, i.e. permission codes. These
security measures are handled by the DDIP in compliance
with the constraints for each application subsystem.
RFP C7 c (7) (a) Access Validation
Access validation and authorization is defined by the
Data Base Administrator and checked for each data item
(attribute) when referred to directly or indirectly
during retrieval, update and write. (Ref. IDM Software
Reference Manual page 3-12 to 3-15 Protection).
RFP C7 c (7) (b) File and Data Protection
Security and privacy controls is available as described
earlier under File and Data Protection. (Ref. above
C7 (16) (b) 3).
D̲a̲t̲a̲ ̲D̲i̲c̲t̲i̲o̲n̲a̲r̲y̲
A database dictionary capability is provided by IDM
to maintain all information about data store in the
databases, including databases, relations (files),
attributes (data elements), user authorizations and
permissions, stored queries, views and plenty of other
relevant information.
The Data Base Administrator may, likewise, store information,
i.e. data usage, about application programs, subsystems,
standard reports and screens. All auctionary informations
are available for users having access permission granted
and for application programs and menu drivers.
Restricted access to the dictionary data is provided
as stated above (File and Data Protection) according
to security requirements as defined by the Data Base
Administrator. Though some system data has further
system based access restrictions, the information in
the data dictionary is available for interogation exactly
as is any other data base information, giving the possibility
to output predefined or ad hoc displays of data relationships.
Very little of the dictionary information is subject
to explicit input requirements and it will then be
input with the very same command set, as in other data
base information, including prompting or help facilities.
Apart from the original creation of relations and views
and alternative formatting for report writer output,
all generation of data definitions is provided by the
IDM from the data dictionary, leaving only for the
users, the application programs and the report writer
explicitly to refer to names of relations and attributes
and to attribute values.
RFP C7 c (8) (a) Data Base Dictionary Contents
A data base dictionary capability is provided to contain:
1 data bases
2 files (relations)
3 data elements (attributes)
4 programs, queries and report writers
5 application subsystems to which the programs
belong
6 authorized users
7 permitted user views
8 user permissions
9 output reports or standard screens in which
data appears
The information is available through maintenance mostly
by the IDM and partly by the Data Base Administrator,
see above. (Ref. IDM Software Reference Manual, appendix
A).…86…1 …02… …02… …02… …02…
RFP C7 c (8) (b) Restricted Dictionary Access
Restricted access to the dictionary data base is provided,
see above. (Ref. IDM page A-1, first paragraph).
RFP C7 c (8) (c) Formatted Screens or Prompting
Formatted screens or prompting for on-line input of
dictionary is provided, see above.
RFP C7 c (8) (d,e,f) Generation of Data Definitions
Generation of Data Definitions for query programs (DDIP),
application programs and report writers is provided,
see above. (Ref. IDM pages A-2 to A-3).
RFP C7 c (8) (g) Data Base Dictionary Output
All user relevant information about data and relationships
is available for output reports, see above. (Ref. IDM,
appendix A).
The data dictionary will be implemented as a data base
itself, providing all the standard data base features
for the data dictionary.
D̲a̲t̲a̲ ̲I̲n̲t̲e̲g̲r̲i̲t̲y̲ ̲a̲n̲d̲ ̲R̲e̲c̲o̲v̲e̲r̲y̲
Data integrity and recovery are based on the concept
of Transaction Management, which ensures at any time,
that a consistent data base operation, as defined by
the actual user, is always fully carried out or in
case of failure is without any impact upon the data
base.
During simultaneous service to multiple users the IDM
is capable to detect and solve situations of conflicting
access to the same data, even for deadlock situations.
The concept of this implies the facility to back out
of one or more transactions for later sequential automatic
restart and the queuing of one or more transactions
for later sequential automatic continuation.
Recovery and restart capabilities for the DBMS files
(data bases or single relations) is consistent with
the availability requirements (Ref. Part C4 c above).
In order to avoid a system halt from a single point
failure the system is equipped with two IDM systems,
which are updated in parallel. In case of break down
for any one IDM system the semi-automatic recovery
procedure (see C7 c (11) below) will be performed,
while normal operations continues on the other IDM
system.
After IDM recovery all update transactions serviced
during the down period will be applied automatically
from the running IDM system to the recovered IDM system
controlled by the back end computer until the two IDM
systems are syncronized.
As long as one IDM system is running normally no user
will be prevented from usual data access.
RFP C7 c (9) Data Integrity
Data integrity which prevents simultaneous updates
(of the same datablock) deadlocks, and maintains the
logical and physical structure of the data base is
provided, see above. (Ref. IDM page 3-9, part 3.3.2).
RFP C7 c (10) Recovery and Restart
Recovery and restart capabilities for the DBMS Files
(data bases or single relations) are consistent with
the availability requirements (Ref. part C4 c above).
Recovery and automatic restart facilities are available
partly as IDM features and partly as back end computer
control processes, see above. (Ref. IDM Software Reference
Manual page 3-10, part 3.4).
S̲u̲p̲p̲o̲r̲t̲ ̲U̲t̲i̲l̲i̲t̲i̲e̲s̲
Reorganization is not necessary due to the completely
selfcontrolled reallocation of freed storage space.
However, to improve performance creation of index's
to relations can be used to arrange data in order to
reflect the most frequently used access paths. Index
creation can be invoked at any time for each attribute
in any relation and will be maintained by the IDM system
as long as it is not deleted by a destroy command.
An index is a sorted relation itself pointing to the
physical storage address of each tuple (record) in
the object relation (file). A number of index's for
a relation (file) can exist simultaneously, one of
which can be clustered. A clustered index means that
besides the existence of the separate index, the relation
itself is stored (physically) sorted by the values
of the attribute. Embedded free space inside the data
blocks of sorted relations might develop, when new
tuples are often inserted, in which case a simple recreation
of the index can prove to be useful.
Dump and restore facilities to secure and recover each
data base in case of a fatal malfunction (i.e. disc
crash) are available. The concept to secure and restore
a data base includes a periodical physical dump of
each data base by the data base administrator and an
optional (per relation) transaction logging on another
disc during data base update transactions. The transaction
log is to be dumped frequently by the data base administrator
as well. Both the full data base dump and the transaction
log dump can by choice be directed either to another
data base (backup data base on another disc) or to
the backend computer for storage on magnetic tape.
While dumping is in progress the data base is fully
operational for simultaneous normal use on the other
IDM system, see above.
The recovery procedure is then to load the most recent
complete data base copy and the transaction logs dumped
since the data base dump and then apply each transaction
log by the roll-foreward command.
In case of minor malfunctions (i.e. power failure),
which do not damage the data stored on discs, the disc
resident transaction log can be applied by the roll-
foreward command without reloading the data base from
the backup copy. In order to shorten the time of roll
forward procedure check points can be invoked automatically
at predefined intervals. The check point procedure
outputs all updated data blocks from IDM internal storage
to disc, so the roll-foreward command only has to apply
the transaction log for transactions served after the
last check point.
Usage statistics are supplied by recording for each
transaction the following information: host, user,
command, relations referred, relations changed, completion
code, start time and end time. This is a function
of the control process in the back end computer, which
controls and passes communication between host computers
and the IDM systems. Frequently the information is
stored in the data base, where it is available to the
Data Base Administrator.
RFP C7 c (11) a Reorganization
Reorganization is usually not necessary, however, index
creation can be invoked at any time upon any attribute,
see above. (Ref. IDM Software Reference Manual pages
3-15 to 3-17, part 3.6.1. and 3.6.2).
RFP C 7 c (11) b Dump and Restore
Dump and restore facilities to secure and recover each
data base are available, see above. (Ref. IDM Software
Reference Manual pages 3-10 to 3-11 part 3.4, page
5-12 to 5-13 part 5,8 and page 7.53 Description).
RFP C7 c (11) c Usage Statistics
Usage statistics are supplied by recording information
per transaction, see above.
M̲i̲s̲c̲e̲l̲l̲a̲n̲e̲o̲u̲s̲ ̲D̲B̲M̲S̲ ̲C̲a̲b̲i̲l̲i̲t̲i̲e̲s̲
There is in fact no need to change IDM, so it is only
the way IDM is used that may be changed or extended.
Extention of DBMS functions are easily defined by
the usage of predefined and stored commands and views.
These functions are invoked by name reference as a
standard function of the IDM, so no change is needed
for existing programs.
Handling the minimum record and field sizes listed
for the application subsystems is easily provided for
as the capacity of IDM is the following:
Attributes (Fields):
Character String 255 characters
Bit string 255 8-bit bytes
Integer 31 digits (plus sign)
Floating Point *) 11 bits integer exponent
31 digits (leading plus
fractional)
*) not supported by IDM for aggregates (arithmetic
evaluation)
Miscellaneous: Max.
Attributes 250 per relation
Tuples (records) 2000 bytes length
2 billion per relation
Relation (files 32000 per data base
Data Base 50
Total data storage 32 gigabytes
Defining multiple occurrences of data is part of the
relational concept as this is equal to input a tuple
by the append command for which the value of only one
attribute value differs from the attribute values in
an existing tuple.
When one or more tuples with all values of each attribute
identical to another tuple can occur for a planned
relation, i.e. lines of text, the relation must be
extended with an attribute, i.e. line number, which
can be used to distinguish between otherwise identical
tuples.
Interface to a Report Writer is available through DDIP
(application query interface) and by the menu selection.
The response to the last query on the screen and any
stored set of relations or views in the data base can
be input to the Report Writer.
Support of the ability to modify the data base in size,
relationships, access methods, or fields (attributes)
per record (tuples) without requiring modification
of application programs for which processing logic
does not change, is fully implemented as a consequence
of the relational approach.
- data base size can physically be extended without
any special caution simply by changing the data
base specification with the extent data base command.
In order to physically diminish or relocate the
data base it must be logically copied out of the
data base by the copy out command (through system
relations by name), destroyed and recreated with
new specifications and then copied back.
- relationships between files (relations) or records
(tuples) are dynamically expressed by the user
by phrasing only references to names of relations
(files) and attributes (field) in the query command
according to the actual need of information. So
no tie-up on relationships exist in the IDM except
for the specification of the attributes for each
relation. Even those can be logically rearranged
or extended without impact to existing application.
- access methods in the data base are under exclusive
control and use by the IDM machine, which by hardware,
firmware and software together forms a unique and
totally optimized access strategy. No need exists
to change this concept, though for ease of use
and for performance tuning to reflect often used
access paths the building of ordered index's is
very useful.
- fields per record (attributes per relation) are
to the user and to the IDM system nothing but a
list of attribute names and formats belonging to
the relation name. There is no stored relationship
between attributes in the relation, but the fact
that they belong to the same relation. So no change
to one attribute (size, format or location) will
ever be detectable by programs or users not using
exactly that changed attribute for input or output.
Even programs exclusively referring to a changed
attribute without assigning data values (i.e. for
sorting (in order clause) have no need to reflect
the change.
Support of complete inversion of files (relations)
are accomplished in four ways suited to any single
user or group of users temporary or permanent specific
needs.
First option is to demand retrieved data in a specific
order by the 'order by' clause. In this way no prestored
information about the sequence of output need to exist
and the order of output is independent of the actual
logical or physical sequence of the stored data. The
'order by' clause can refer to any one or more attributes
from the referenced relation even though the attributes
are not included in the output.
Second option is to create index's, which can for the
very same relation reflect each attribute (combined
with up to 14 other attributes (max. 248 bytes) simultaneously.
One of the index's for a relation can be defined 'clustered'
and thereby at the same time rearrange the tuples in
the relation into the same order by value. In the
index's each attribute value or combined values of
more attributes has a pointer to the physical data
block position on the disc, so the access to data is
speeded up in a considerable way. Any reference to
data in a relation, which has index's created, will
access data through the most appropriate index (if
any exists) despite the fact, that the index we created
later than the application program and that the program
is not changed in any way.
Third option is to create views, which are virtual
relations combining other views, relations and attributes
perhaps by aggregate functions for the specific use
of data. Views can be updated if the update is unambiguous
to the referenced relations. With this exception the
views can be treated like any other relation in creation,
append, replace, retrieval and destroy commands. Also
data protection is maintained for views in the same
manner as for relation, though access permissions granted
for the views take precedence over access permissions
granted for the referenced relations owned by the user,
while access permission to relations owned by other
users still are in effect.
Fourth option is to store predefined commands in which
all of the above options may be used in complex data
base access procedures, which in this way need not
to be input every time it is used but simply referred
to by name. Data protection is maintained for stored
commands in the same manner as for views, see above.
Automatic prevention of primary key duplication is
in IDM extended to an optional feature for each attribute
in any relation as being an option in the creation
of index's, see above. While creating or recreating
a unique index for any attribute the option delete-dumps
deletes silently any but one of the tuples having identical
attribute value, or combination of attribute values
if more than one is included in the index. In all
other cases when a unique index is applied any existance
during creation or any update which results in duplicate
attribute value or combination of values will be error
reported and the creation or update aborted.
Add, delete or update a record (tuple) in either batch
or on-line mode is fully supported by the host computers.
The IDM machine is operating in transaction mode servicing
any number of ongoing host computer processes independent
of whether the application programs on the host computers
are performing on-line sessions or batch jobs.
Recovery of data bases from failure independently while
other data bases continue to function is a facility
supplied both by the individual IDM machines as it
recovers one data base per command and by the system
concept using two IDM machines in parallel. If a failure
is affecting only one IDM machine the other IDM machine
continues normal operation during the recovery, see
part (10) above. If a failure affects both IDM machines
though not all data bases on one of the IDM machines
normal operation can continue on one IDM machine for
the data bases not affected there, while the recovery
procedure runs for the other data bases.
Maintenance of concurrent permissions in equivalent
status for any terminal user accessing any CPU (host
computer) in the system, which supports data bases
that the user may access is fully supported. Any one
user transaction is identified to the IDM systems by
both an automatically supplied host computer identification
and the user identification.
The concept of transaction management in the IDM system
provides full control of concurrent reads and updates
of the same data, thus securing data consistency at
any time and a highly advanced handling of deadlock
situations. While one users transaction exclusively
writes some data blocks no other transaction can read
or update the same data blocks before the first transaction
is completed. On the other hand several users transactions
can, at the same time, read any data block not currently
locked by an updating transaction, thus preventing
any updating transaction to modify data read until
all the reading user transaction are completed.
Already started transactions which prove concurrent
as the data blocks are locked by another transactions
are killed and put into wait state by the IDM, which
later on restarts the waiting transaction automatically.
If the IDM machine for some reason should be unable
to restart a waiting transaction the back end computer
will receive a message identifying this situation and
will then reissue the transaction to the IDM machines.
To provide a capability under exclusive control of
the Data Base Administrator to repair a data base record
(tuple) that is unreadable the recovery procedure supported
by the individual IDM systems and by the system concept
of using two IDM systems in parallel are the very best
means as there is no need to deal with physical data
positions or pointers. The whole data base which holds
an unreadable record (tuple), which in fact may prove
to be a data block containing several unrelated and
unidentified data items, should be restored as stated
in the recovery procedure. When the error causing
the trouble, i.e. faulty disc track, has been repaired
or exchanged, normal recovery is launched. In the
meantime the other IDM system has served all transactions
without complications for the users.
RFP C7 c (12) Extention of DBMS Functions
Extention of DBMS functions are easily defined by the
usage of predefined and stored commands and views,
see above. (Ref. IDM Software Reference Manual page
1-3 part 1.1.4 and page 3-19, part 3.7).
RFP C7 c (13) Minimum Record and Field Sizes
Handling the minimum record and field sizes listed
for the application subsystems is easily provided,
see above. (Ref. IDM Software Reference Manual page
2-3, part 1.1.4 and IDM product description page 26).
RFP C7 c (14) Multiple Occurrences
Defining multiple occurrences of data is part of the
relational concept, see above. (Ref. IDM Software Reference
Manual page 1-4 part 1.1.5).
RFP C7 c (15) Report Writer Interface
Interface to a report writer is available, see above.
RFP C7 c (16) Ability to Modify
Support of the ability to modify the data base in size,
relationships, access methods, or fields (attributes)
per record (tuples) without requiring modification
of application programs for which processing logic
does not change, is fully implemented, see above.
(Ref. IDM Software Reference Manual page 1-3 2nd paragraph
and part 1.1.4, page 1-7 part 1.2.5, page 3-3 bottom
paragraph to page 3-6, page 3-19 part 3.7, page 5-12
part 5.8.1, page 7-27 and page 7-66).
RFP C7 c (17) Inversion of Files
Complete inversion of files (relations) are supported
in four ways, see above. (Ref. IDM Software Reference
Manual page 1-3 to 1-4 part 1.1.4, page 1-4 part 1.1.6,
page 1-7 part 1.2.5, page 3-15 to 3-16 part 3.6.1,
page 3-19 to 3-20 part 3.7 and page 7-37 to 7-40)
RFP C7 c (18) Primary Key Duplication
Automatic prevention of primary key duplication is
an optional feature for each attribute, see above.
(Ref. IDM Software Reference Manual pages 1-4 part
1.1.5, page 3-15 to 3-16 part 3.6.1 and page 7.37 to
7-39 part 7.5.12).
RFP C7 c (19) Data Change in On-line and Batch Mode
Add, delete or update in either batch or on-line mode
is fully supported, see above. (Ref. IDM Software Reference
Manual page 3-6 part 3.3).
RFP C7 c (20) Recovery of Data Bases
Recovery of data bases from failure independently while
other data bases continue to function is supported,
see above. (Ref. IDM Software Reference Manual page
1-6 part 1.2.4).
RFP C7 c (21) Concurrent Permissions
Maintenance of concurrent permissions in equivalent
status is supported, see above. (Ref. IDM page 3-9
part 3.3.2 and page 3-12 part 3.5.1).
RFP C7 c (22) Data Base Repair
Faulty data base blocks should be restored as stated
in the recovery procedure, as there is no need for
manual intervention, see above.
d. Sub-Line Item 0003AD, Language Processors
The following language processors (compilers) can
be provided for the proposed system:
- COBOL
- PASCAL
- FORTRAN 77
- SWELL
- Assembler
- ADA (completion ultimo 83)
Each compiler produces relocatable object code
which can be linked and executed with object code
generated by any of the other mentioned compilers.
The proposed application programs will be written
in PASCAL.
A COBOL and a PASCAL compiler is included in this
proposal.
The ANSI COBOL Compiler will implement the high
intermediate level specified in FIPS PUB 21-1.
All program development facilities will be available
from all terminals connected to the system.
e. Sub-Line Item 0003AE, General Utilities
General Utility programs to perform the following functions
will be provided:
(1) Media conversion to transfer data between devices
subject to peripheral constraints.
(2) Program library facility for handling of program
files
(3) Memory dump
(4) File compare
(5) Magnetic Tape Maintenance for handling and conversion
of labels, data code, blocking factor and parity
(6) Programming aids for COBOL with the following functions:
(6a) Trace facility
(6b) Debug facility to print the contents of
all or any part of main memory and registers
and initiate snapshot dumps and printout
of any part of memory specified during
job execution.
(6c) Automatic sequencing of source files
(7) A sort and merge facility with the following capabilities.
(7a) Sort and merge files with input and output
selectable between disk and tape
(7b) Sort and merge will be callable from a program
written in any of the provided programming
languages
(7c) Sort only, merge only and sort and merge
(7d) Handle multi-reel files and multi-file reels
of tape in all combinations and disc files
spanning multiple packs.
(7c) Handle eight ascending and descending keys
in any order
(7f) Handle unblocked variable-length records and
blocked and unblocked fixed-length records.
(7g) Handle non-contiuos sort-key fields containing
a total of 96 characters.
(8) The proposed File Management System will facilitate
the following functions:
(8a) Sequential and indexed sequential (direct)
access of files with variable length records.
(8b) Listings of files including id and physical
characteristics.
(8c) Expand and reduce space allocated for files.
(8d) Create and retain successive generations of
files upon user command. File generations will
be deleted only by user command.
(8e) The user must not be required to specify file
space or file characteristics for any function.
f. Sub-Line Item 0003AF, Graphics
Basic graphics software functions with the following
capabilities will be provided:
(A more detailed description of the proposed graphics
software: MEGATEK TEMPLATE is given in the technical
literature).
(1) Generate the following graphic elements:
(a) Multiple font style and size alphanumeric characters
(b) Circles
(c) Pie charts
(d) Squares and rectangles
(e) Bar charts
(f) Curves
(g) Vectors
(h) Line drawings
(i) Tabular data
(j) Automatic layout
(k) Shading patterns
(l) Stacked or hidden bars
(m) Precomposed images (logos and maps)
(2) Eight plotted lines distinguisable from each
other by the use of different colors.
(3) Multiple line-type segments, shadings filling
and defineable color vectors.
(4) Interactive color labelling
(5) Interactive interface with all seven application
software subsystems and the statistics package.
(6) Insertion of explanatory text.
(7) Selective erasure.
(8) Interactive keyboard editing.
(9) Independent scaling and windowing.
(10) Standard font size, with multiple alternative
fonts and program difinable font size.
(11) Display of available chart formats prior to
display creation.
(12) Selection of specific chart format and plot
of specified data.
(13) Structure charts for data display from user
supplied variables.
(14) Process input from calculations based upon
analysis of database content, by on-line terminal
entry or digitizer entry.
(15) Add/subtract graphs and superimpose one graph
on another.
(16) Paint over a graph.
(17) Use the function and cursor control keys.
(18) Store and retrieve graphic images.
(19) Interactively edit and annotate maps or other
stored graphics which have been entered on
the digitizer.
g. Sub-Line Item 0003AG, Text Editor
The screen oriented text editor provided with ACCESS
will be versatile and general type of editor. It will
be characterized with the following key features:
(1) Security aspects are in accordance with the
secure operating system DAMOS.
(2) Many special keys, like cursor control, insert
character/string etc., are useable in the text
editor.
(3) The text editor can be used to add, delete
replace, search and modify, characters and
strings of characters in text files.
A file can be retrieved and displayed on a
terminal. Then the editor can be used with
most terminal capabilities, including insert/deletes
character etc.
(4) Files can be included within files at arbitrary
points.
(5) Files can be created and named.
(6) The text editor can work with paragraphs or
blocks of data.
(7) Charater string search and replacements are
provided.
(8) The spelling corrector may be called from the
text editor in accordance with the general
philosophy, that all tools are available throughout
the system.
(9) Tabulator satting is provided.
h. S̲u̲b̲-̲L̲i̲n̲e̲ ̲I̲t̲e̲m̲ ̲0̲0̲0̲3̲A̲H̲,̲ ̲R̲e̲p̲o̲r̲t̲ ̲W̲r̲i̲t̲e̲r
R̲F̲P̲ ̲S̲e̲c̲t̲i̲o̲n̲ ̲C̲7̲ ̲h̲ ̲p̲a̲g̲e̲s̲ ̲3̲7̲-̲3̲8̲
R̲e̲p̲o̲r̲t̲ ̲W̲r̲i̲t̲e̲r̲ ̲C̲o̲n̲c̲e̲p̲t̲
The Report Writer facilities are available both as
an integrated function of the DDIP (Direct Data base
Interface Program) and as a separate application program.
The DDIP integrated function uses the query commands
to identify and fetch data from the data bases in the
very same manner as ordinary retrievals. The commands
for report writing may be seen as a supplement, which
gives the ability to specify output formation and control
with a much powerful capability, than in standard output
for IDM.
The separate application program for report writing
uses as object data other types of files than the IDM
data base, i.e. data stored in a user terminal file
storage. The formatting commands are the same as for
data base retrieval, while the data identification
and fetch functions reflect the actual storage medium
and file organization.
The full command set for specific report writing may
be developed and input on-line in either case, and
it may be stored in the data base for later retrieval
and used. The stored report writer commands will then
automatically be included in the data dictionary and
subject for data dictionary functions, see C7 c above.
Data definitions may be obtained automatically from
the data dictionary or specified explicitly for the
individual report. When data is retrieved from the
data base the internally used data definitions are
applied, while definition of other data sources may
be defined and stored for use in a similar way.
For individual report output data items may be formatted,
editted and calculated as data aggregates similar to
the data base retrieval, see C7 c above, including
performance of logic operations. Summation lines for
up to nine control breaks with up to fifteen columnar
totals may be defined for a report to be output at
the end of each group of lines forming the break level.
As an example, let us assume that we have entered data
in a relations "parts" and "products", and that the
relations are as shown below.
Relation: products
Attributes: name, part (part name),
quan (amount of this part in the product)
n̲a̲m̲e̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲p̲a̲r̲t̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲q̲u̲a̲n̲
TV transistor 15
TV speaker 2
TV cabinet 1
TV antenna 1
TV picture tube 1
radio antenna 1
radio cabinet 1
radio transistor 12
radio speaker 1
stereo transistor 10
stereo cabinet 1
stereo speaker 4
tape recorder tape reel 2
tape recorder transistor 20
Suppose we want to know the quantity and type of each
part that goes into making TV's. The query is:
retrieve (pr. part, pr. quan) where pr. name = "TV"
The names of the attributes to be "retrieved" (displayed
to the user) are "part" and "quan". The list of the
attributes to be retrieved is called the "target list".
The "qualification" is the specification of which tuples
to get the data from; the qualification in this is
"where pr.name = "TV". The qualification is also called
the "where clause".
The above query was a one-variable (single relation)
query. The result returned from the report writer could
be:
p̲a̲r̲t̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲q̲u̲a̲n̲
transistor 15
speaker 2
cabinet 1
antenna 1
picture tube 1
The report definition may include specification for
output to any specified device.
RFP C7 h (1) Format, edit, ...
Format, edit, calculate, logic operation and write
to any specified device is provided, see above.
RFP C7 h (2) On-line Development
On-line program development is provided, see above.
RFP C7 h (3) Created Report Formats
Retrieval of previously created report formats is provided,
see above.
RFP C7 h (4) Control Breaks
The ability to process at least nine control breaks
and fifteen columnar totals is provided, see above.
RFP C7 h (5) Summation Lines
Intersperse of summation lines with detail lines is
provided, see above.
RFP C7 h (6) Support all Functions.
All functions of the report writer may be applied to
data from any defined source file, see above.
RFP C7 h (7) Data File Definitions
Data file and field definitions may be obtained from
the data dictionary, see above.
RFP C7 h (8) Store and Catalogue
Defined report formats may be stored in the data base,
see above.
i. S̲u̲b̲-̲L̲i̲n̲e̲ ̲I̲t̲e̲m̲ ̲0̲0̲0̲3̲A̲J̲,̲ ̲S̲p̲e̲l̲l̲i̲n̲g̲ ̲C̲o̲r̲r̲e̲c̲t̲o̲r̲
The spelling correctors provided with the ACCESS is
working interactively from the terminals, either through
the command level, the text editor or while working
in the electronic mail. The spelling corrector works
with a basic set of 35,000 words.
(1) Special and separate dictionaries of words
can be incrementially built by the user to
include abbreviations, acronyms and other symbolic
names.
(2) The spelling corrector will sort and list all
words in a created message and check this list
against one or more dictionaries. All flagged
supposed incorrect words may be corrected and
may also be amended to one of the special dictionaries
for future use.
During the correction process the spelling
corrector will store the most often made misspellings
and their associated correct spellings. These
correct spellings can be displayed in the subsequent
correction processes.
j. S̲u̲b̲-̲L̲i̲n̲e̲ ̲I̲t̲e̲m̲ ̲0̲0̲0̲3̲A̲K̲,̲ ̲D̲o̲c̲u̲m̲e̲n̲t̲ ̲F̲o̲r̲m̲a̲t̲t̲e̲r
The Document Formatter supplied with ACCESS will
have the requested basic features and it will allow
inclusion of data from several files.
The Document Formatter is callable from the system
command level and from within the text editor.
k. Sub-Line Item 0003AL, Statistics
The following mathematical and statistical functions
will be provided for interactive use:
(1) Addition, subtraction, multiplication, division,
square, squareroot, column and row totals and
percentage.
(2) Mode, median, mean and standard deviation.
(3) Coefficients of regression, correlation and
confidence.
1. S̲u̲b̲-̲L̲i̲n̲e̲ ̲I̲t̲e̲m̲ ̲0̲0̲0̲3̲A̲M̲ ̲O̲p̲t̲i̲c̲a̲l̲ ̲C̲h̲a̲r̲a̲c̲t̲e̲r̲ ̲R̲e̲a̲d̲e̲r̲ ̲(̲O̲C̲R̲)̲
A software handler for the OCR to provide the following
functions is proposed:
(1) Operator will input textual data directly into
a file created by him.
(2) The system will prompt the operator to indicate
the directory to which file will be copied.
(3) After correcting any changes flagged by the
OCR, the system will copy the file into the
specified directory.
(4) The system will generate an electronic mail
message to that directory's account stating
that a new file (giving the name of the file)
has been inserted in that directory from the
OCR.
(5) The system will then delete the original file
created at the OCR.
(6) The OCR must be programmable by an operator
for:
(a) Margins from .5 inch to larger in .1 inch
increments.
(b) Sinkage and other area white space.
(c) Page-end and line-end information.
(d) Operator-defined codes.
C̲8̲.̲ ̲L̲i̲n̲e̲ ̲I̲t̲e̲m̲ ̲0̲0̲0̲4̲.̲ ̲A̲p̲p̲l̲i̲c̲a̲t̲i̲o̲n̲ ̲S̲o̲f̲t̲w̲a̲r̲e̲
a. General Requirements
(1) The application software will be of the kind where
the basic user interface will be common for all
functions and features.
The various functions will only look different for
the user through the available sets of menu's, prompts,
and commands.
(2) To create an interface between users and subsystems
that gives a continuity in the use of the different
subsystem we will put the effort on the general
interactive system language instead of splitting
up the application software in unrelated subsystem
packages. We will create the interactive system
language in such a way that the seven subsystems
will only exist for the user through the use of
menu's, prompts and commands. This gives several
advantages like easy maintainability, because new
functions can easily be inserted in the software,
both common and dedicated functions for the seven
subsystems.
It will also give the possibility to introduce
additional subsystems without major impact for
the existing application software because the new
subsystem will be a combination of existing functions
and a few new ones which has to be developed.
(4) Return of Requested Information
Within all our proposed subsystems the general
output facilities will be available for the user
to specify the output device through the use of
the provided command language or through the provided
menu or prompt driven selection facility. The user
will be able to direct output to any output device
or private file to which he has access capabilities
and if he does not specify any destination for
the requested output the default destination will
be on the terminal from where the output request
was issued to the system.
(5) Abbreviation
We are familiar with these abbreviations and will
use them as described.
(6) The security features of the operating system will
ensure that all security rules are adhered to.
Before hard copying on the high speed non-impact
printer, line printer or letter quality printer
the system will check that the output contains
a security classification or that the user has
specifically asks for the suppression hereof.
Printing of files will always be preceded by a
classification banner, which will allow a responsible
person to state and sign the actual classification
of the printed file. The overall classification
as known by the system will still be printed on
the top and bottom of the file.
(6a) For electronic mail messages the classification
will always initially be equal to the highest classification
'SECRET' will be used as default for messages which
has not been inspected and classified by the user.
(6b) All other files can not be printed before the
user has given a classification to the file to be printed.
He can choose between:
'SECRET'
'CONFIDENTIAL'
'FOR OFFICIAL USE ONLY'
'UNCLASSIFIELD'
'SUPPRESS LINES'
All except the last one will result in the classification
being printed on top and bottom of each printed page.
(7) The letter quality printers will be prevented from
printing any files which does not have classification
lines on the top and bottom of each page.
I̲n̲t̲e̲r̲a̲c̲t̲i̲v̲e̲ ̲S̲y̲s̲t̲e̲m̲ ̲L̲a̲n̲g̲u̲a̲g̲e̲
Christian Rovsing A/S will provide an Interactive System
Language, ISL which is used to establish all user interfaces
to the applicaton system. ISL is used to establish
all menus and HELP display.
The ISL will allow easy modifications to all menus
and it will allow new menus and HELP displays to be
established.
The ISL works as a command interpreter, which takes
input from small text files. The text files can be
created, updated and deleted by using the text editor.
ACCESS MAIN MENU
1. ROEXSU Routine Executive Support
2. CEXMAS CINSAC Executive Management Summary
3. PROMON Project Monitoring
4. PERMAN Personnel and Manpower
5. BUDGET Budget
6. PHYREM Physical Resource Monitoring
7. ELECMA Electronic Mail
8. HELP Help Information
ACCESS MAIN MENU
b. S̲u̲b̲-̲L̲i̲n̲e̲ ̲I̲t̲e̲m̲ ̲0̲0̲0̲4̲A̲A̲,̲ ̲E̲l̲e̲c̲t̲r̲o̲n̲i̲c̲ ̲M̲a̲i̲l̲ ̲S̲u̲b̲s̲y̲s̲t̲e̲m̲
(1) (a)
The subsystem maintains a mailbox for each of all the
users with login permissions. The users can receive
and store electronic mail in their associated mailboxes.
(1) (b)
A user can perform print or display of messages with
the following options:
. Print or display a message based on a message number.
. Print or display a message which has a match in
the header part to the specified character string.
. Print or display all or a specified max number
of messages based on a range of message numbers.
. Print or display all or a specified max number
of messages which all contains a match in the header
parts to the specified character string.
(1) (c)
A user can perform a new message preparation to create
a new message. The subsystem assigns an identity (message
number) to the message which later can be used as a
retrieval key to the message.
(1) (d)
By the use of the forward function a user can forward
a previously created message from his mailbox to another
user without being the originator of the message. The
user is allowed to add comments to the message before
it is forwarded. A forwarded message will be denoted
as forwarded and by whom.
(1) (e)
Any user which has received a forwarded message in
his mailbox will be able to reply to the sender of
the previously created message.
(1) (f)
By the use of the available archive functions a user
will be able to create any name files where he can
store received and self-created messages. The files
will be associated with the user's identification.
This facility supports a user to split up messages
in to logical groups and to give the groups relevant
names.
The same set of functions which can be performed on
messages in the mailbox will also be available at the
created files.
(1) (g)
A function which lists addresses is provided for the
user when he prepares a message and wants to fill in
the addresses.
This function can list relations between user names
and the corresponding mailbox addresses with the following
options:
. list relations for a selected user group
. list relations for names which matches a specified
character string
. list all relations
(1) (h)
The electronic mail subsystem allows only a user to
edit and refile messages originated by himself into
the mailbox. The subsystem checks if the user has capabilities
to change the contents of a message or only to append
comments to a message.
(1) (i)
A user is supported with print and display facilities
as described in para. (1) (b) of this subline item.
(1) (j)
When a user commands the electronic mail subsystem
to send a created message it will perform a distribution
based on the list of addresses and notify recipients
of arrival of new mail.
(1) (k)
If a user wants to create a new message he commands
the subsystem to deliver a message input format. If
the user does not specify any particular format the
subsystem will then as default automatically byiod
the standardized message format with the fields 1̲ to
1̲0̲.
Some of the fields demand user input and some other
ones will be administrated by the subsystem (e.g. message
size, date and time sent) and finally some will be
given default values by the subsystem if the user does
not fill in any information in these fields.
…86…1 …02… …02… …02… …02…
(1) (l)
A user can create alternative message formats to be
used instead of the standardized default format to
create, print, display or survey messages.
The user is allowed to interactively compose an alternative
format and define the placement of fields. After creation
the system will validate the specified fields if they
exist. If not, the format is returned to the same screen
with a notification in the screen-header telling about
what went wrong.
(1) (m)
The text editor offered with the operating system provides
the user with facilities to edit a message on field
basis, one field at a time without leaving the electronic
mail subsystem.
The use has only to enter a edit command in the command
line within the screen header. Hereafter the functions
will be available, like;
. Append lines
. Delete lines
. Move lines
. Copy lines
. Insert data from an other file
. Substitute pattern A with pattern B on line bases
or the whole field.
etc.
(1) (n)
During new message preparation or continue message
preparation the user can use previously created data
and input to fields of the message format which requires
user input.
The user inserts the file identification immediately
after the field prompt. If the field is not empty the
file-id must be followed by a space and finally the
user requests the subsystem to insert a file in the
specified position. The new data shall be merged in
front of the original data and the user can then subsequently
erase the old data if he desires so.
(1) (o)
The subsystem provides automatically that a user will
be notified upon arrival of mail in his associated
mailbox. The notification will appear in the two following
situations.
. If a user is logged in at a terminal upon arrival
of a new message in his mailbox, it will be notified
in the screen header at that terminal.
. When a user has passed the login procedure the
presence of unseen mail in his associated mailbox
will be notified in the screen header so the user
can at an early stage decide whether to collect
the mail (by seeing it) immediately or later.
(1) (p)
A user is provided with a facility to store a created
but not sent message temporary in a file for later
distribution. When the message is recalled and distributed
it will not exist in the temporary file but permanently
on the data-base as long as the message is referenced
in a mailbox without a deletion mark.
(1) (q)
As described in para (1) (o) within this sub-line Item
a user will be reminded in the screen header about
the presence of unseen mail in his associated mailbox.
The subsystem provides also a facility for the user
during a new message preparation to inspect recently
arrived messages in his associated mailbox by a survey
function and then proceed with the message preparation
by use of the continue message preparation function.
(1) (r)
A delete function is provided by the subsystem for
the user to delete messages from mailboxes if he is
in possession of the necessary permission right to
do so.
As long as there is at least one reference to a message
without a delete mark within a mailbox or archieves
the message can still be retrieved.
The user is also provided with a regret function, so
he can remove a previously set delete mark if an actual
expunging of the message has not been started.
The necessary input to the delete function is similar
to the print or display functions as described in para
(1) (b) within this sub-line Item.
(1)(s) Directly call the Spelling Corrector Program:
The user can in the command line of the screen header
get the Spelling Corrector program loaded with current
message as input and a default dictionary or he can
enter a specific message and a specific dictionary,
if desired. For the Spelling Correctors functional
Capabilities see description in para. C7.i.
(1)(t)
Allows user to vary procedures by changing parameters.
To support the user with a flexible sub-system it is
provided that the user can vary procedures by changing
parameters.
(1) (u)
The subsystem can provide a facility for a user to
get a copy of a message into one of his logical group
files upon its distribution.
To provide this the user has to select a message format
which contains a file copy field and into this enter
the name of the logical group file where he wants the
reference to the message shall be inserted by the subsystem.
(1) (v)
Our proposed Electronic Mail subsystem can provide
this so that info-copy recipients will be able to see
who else received the message for information purposes
and in contrast to the carbon-copy recipients they
will not be able to see who else is going to receive
the message.
(1) (w)
A copy function is provided by the system which a user
can copy messages from a mailbox to textfiles if he
has the necessary permissions to do so. This implies
that a message appears physical twice on the storage
media.
(2) Input:
The message format selected by the user upon a new
message preparation or continue message preparation
prompts the user at those fields which demands user
input.
The HELP function is provided at any command level
within a subsystem and supports a user with a catelogue
of help information which is related to him and the
sub-system from where the function is called.
Only one copy of a message is contained in the electronic
mail system until a user specifically asks for a new
copy to modify or incorporate in a new message.
C8c. Sub-Line Item 0004AB, CINCSAC Executive Management
Summary (CEMS) Subsystems
(1)
Input
Those agencies which are responsible for data entry
to create CEMS displays will be provided with text
editing, OCR, and graphics facilities to perform their
tasks.
The file transfer feature provided for the ACCESS System
is a Modern View and Queue Technique
The provided transfer technique will be available for
all data entry agencies to forward completed displays
to the ACMI controlled working area. The subsystem
will take care of creating the entries in the necessary
index's upon creation, insertion in the ACMI working
area and insertion in the final CEMS display storage
of displays. The following index's will be provided
one private index for each user who creates the initial
versions of CEMS displays, another index which is common
for all CEMS displays in the ACMI working area and
a third index for displays in the final CEMS Display
Storage
The ACMI will be able to review and update CEMS displays
in the ACMI working area
ACMI can insert it in the final CEMS display storage.
Upon insertion of display into the final CEMS display
storage the entry to it in the ACMI working area index
will be removed and a new one will be created in the
index for the final CEMS display storage.
For the different access capabilities of CEMS displays
see answer to para. (2) (a) within this sub-line item.
(2)
Processing Features
(2) (a)
Access Permission
The subsystem will provide that the individuals of
the agencies responsible for developing CEMS display
files will be able to create and maintain initial CEMS
displays in their private files.
Each individual's private files will be protected upon
creation for access by the creator only if desired.
CEMS display files which are transferred to ACMI working
area wil be protected for being assessed and controlled
by the ACMI only.
Read only permission to the final CEMS storage will
be provided for all users which have passed the system
logic procedure. The ACMI will be provided additional
modify and write permissions.
(2) (b)
Maintenance
The Subsystem will accept that the ACMI shall be responsible
for all display files in both the working area and
the final CEMS storage. Likewise will the subsystem
accept that the agencies initially creating the displays
shall be responsible for supplying ACMS with current
inaccurate versions of their applicable files.
(2) (c)
Storage Directories
The working area and the final CEMS storage will be
provided a capacity of 1000 entries for each one.
For all users which have passed the system logic procedure
a facility will be provided by the subsystem to get
a list showing display sequence number or display title
of each one of the existing CEMS displays in the final
CEMS storage. To get a list of the existing CEMS displays
in the working area will be restricted to the ACMI
only.
(2) (d)
Menu Selection
When a user has entered the CEMS subsystem he will
be provided facilities which in regard to use is similar
to those offered by the other subsystems and this implies
that he will be able to switch between the following
options.
(2) (d) 1̲
Option 1: Use of Menus
The user will be able to perform the following functions'
by the use of the provided menus:
. Get a list output showing the display sequence
number or display title of each one of the existing
CEMS displays in the final CEMS storage and the
list will be output in successive screenloads if
necessary.
. Select one or more CEMS displays from the list
to be displayed.
. Select a range of displays to be output by use
of a prompt condition FROM nnnnnn to mmmmmmm.
. Skip the current display and advance to the next
by a single keystroke if a number of CEMS display
is requested output.
(2) (d) 2̲
Option 2: Use of commands
The user will be permitted to bypass the menus by uniquely
identified commands offered by the provided command
language. To make the functional capabilities use
of menus or of direct commands consistant it will be
provided that the functions available by divert commands
in principle are the same as those listed above in
option 1:
(2) (e)
Display Format
It wil be provided that the output format for CEMS
display contains Classification Banners, Display Title,
and Display Text or Annotated Graphics.
(2) (e) 1̲
Classification Banner.
A 12 character classification banner will be provided
to appear on the extreme top and bottom of each display
page.
(2) (e) 2̲
Display Title
The display title field of the display format will
be provided to consist of two lines of 60 characaters
for each one.
(2) (e) 3̲
As of Date
The As of Date field consisting of up to 12 characters
will be provided updated automatically to the date
of the last CEMS display update PERFORMED BY ACMI.
(2) (e) 4̲
Display Text and Annotated Graphics
The user will be provided with text editor and graphics
facilities to create display text and annotated graphics
where the body of each display file will be provided
to contain up to ten 3640 character display pages.
(3)
Output.
It is taken down that color output is not required
for this subsystem.
It will be provided by the subsystem that text and
annotated graphics displays can be used for CEMS displays.
Similar with the other proposed subsystems the general
output facilities will be available for the user to
specify the output device through use of the provided
command language or through the provided menu or prompt
driven selection facility. The user will be able to
direct output to any output device or private file
to which he has access capabilities and if he does
not specify a destination for the output the default
destination will be the terminal from where the output
function was issued to the system.
(3) (a)
Hard Copy Output.
The user will be provided facilities to get hard copy
monocolor output via letter quality printer (excluding
graphics displays), color graphics copier, high-speed
non-impact printer, and color camera if he is authorized
to use these devices.
(3) (b).
Output of Displays
For output of displays it will be provided that they
are automatically formatted by a system device handler
to fit the specifications of the selected output device.
The graphic display pages will be provided to …86…1
…02… …02… …02… …02…
consist of a sequence of related displays.
The text display pages will be provided to consist
of multiple screen loads but stored as a single text
field which the user will be able to page through the
retrieval purposes.
C8d. S̲u̲b̲-̲L̲i̲n̲e̲ ̲I̲t̲e̲m̲ ̲0̲0̲0̲4̲A̲C̲,̲ ̲P̲r̲o̲j̲e̲c̲t̲ ̲M̲o̲n̲i̲t̲o̲r̲i̲n̲g̲ ̲S̲u̲b̲s̲y̲s̲t̲e̲m̲
(1) (a)
Project input responsibility
The subsystem will accept input from each agency of
projects for which the agency is the monitor.
(1) (b)
Project Package
It will be provided that a Project Package can consist
of the following three elements:
1̲ A Project Index with fields which can be used
for retrieval purposes like menu-driven access
methods.
2̲ A Project Summary
3̲ Text, results of queries, and graphic displays
in an arbitrary sequence determined by the
project monitor preparing the input.
(1) (c)
Min. Project Package
The subsystem will provide that a project package at
least consists of a Project Index and a Project Summary
and that other contents like text, results of queries,
and graphic displays are optional.
(1) (d)
Project Numbering
The subsystem will provide automatic project numbering
without the users interference.
(1) (d) 1̲
Entering of the Subsystem
It will be provided that when a user has passed the
logonical procedure he will be presented with the ACCESS
Main Menu (or the Project Monitoring Menu if desired
and specified in the users profile) which will ask
him for selection of a subsystem. He has then the following
options to reach the Project Monitoring subsystem.
. He can select the Project Monitoring subsystem
by entering the abbreviated identification of the
subsystem in the command line of the screen header
and then be presented with Project Monitoring Menu
asking for the next selection.
. He can enter a unique command like new project
preparation to bypass the Project Monitoring Menu
and then be presented with the default Project
Index Format prompting for user input. The user
will be change into the command mode by the use
of this option.
(1) (d) 2̲
New Project Preparation
After the user has entered the New Project Preparation
Function, the subsystem will provide that the user
is presented with the Project Index format which will
prompt him for input of data. The Project Number will
automatically be assigned by the subsystem
(1) (d) 3̲
The Project Number
The Subsystem will provide a generation of five digit
project numbers with wrap around from 99999 to 00001
and table of used project numbers will be maintained.
Each time a project number has to be assigned to a
new project. The project number counter will be incremented
and the new number checked against the table of used
project numbers. If the number is in use already and
there is still unused number back the procedure will
be repeated until an unused number is found, otherwise
it will be indicated that all project numbers are in
use.
Upon deletion of a project the subsystem will provide
that the associated project number is deleted from
the table of used project numbers
(1) (d) 4̲
Field Protection
It will be provided that the project number field of
the Project Index Record only can be assigned a value
one time and by the subsystem as long as the record
exists in the subsystems file.
(1) (e)
Input
The project monitor will be provided facilities to
contruct and maintain project packages in his private
files and then later on use them as input to the Project
Monitoring subsystem files.
To construct and maintain project package the text
editor, the graphics development facilities, the graphic
digitizer, and use of files created in other subsystem
as input will be provided as a tool for the project
monitor to construct and maintain project packages.
Menu or prompting entry methods to enter a project
index or project summary will be available too.
(1) (e) 1̲ through (1) (e) 1̲5̲.
Project package fields.
During a new project preparation or a continue project
preparation the subsystem will provide that the user
is prompted for input of text and data elements.
By use of a provided view technic it can be supported
that the first 10 out of 15 fields of the Project Summary
forms the Project Index and they can be accessed from
both sides.
The fields will exist in one physical incarnation with
duplicated entries. If it is demanded that the same
10 fields shall exist in two physical incarnations,
one for the Project Index and one for the Project Summary,
it will be implemented.
The subsystem will provide automatically assigning
of the project number and the assigning of date to
the project upon its entering into the permanent Project
Monitoring Subsystem files.
(1) (f)
Project Package Construction.
It will be provided by the subsystem that the following
facilities are available for the user to construct
a project file with data which the user is authorized
to access.
1̲ Use text stored in formatted form in a private
file and which has been developed by use of a text
editory spelling corrector and a formatter.
2̲ Use results of queries stored in display format
and which have been generated by use of another
subsystem.
3̲ Use a graphic display which has been read into
the system through a graphic digitizer.
4̲ Use a graphic display stored in a file and which
has been generated by use of another subsystem.
5̲ Use a graphic display which has been developed
or modified by use of the graphic facilities offered
by the system.
(1) (g)
Field attributes.
The subsystem provides that project package fields
for which input is mandatory will continue to prompt
for user input until input is accepted or the project
preparation is skipped.
For those fields where input is optional the empty
fields will be displayed at a later output as a field
name succeeded by a blank field. This supports the
capability to insert data at a later time through a
provided update project function.
(2)
Processing Features.
(2) (a)
Access Permissions
(2) (a) 1̲
Allocation of access permissions.
Through the combination of the Action Agency field
associated with a project and the provided table of
user profiles it will be determined whether a user
has permission or not to enter or update specific Project
Monitoring files.
It will be supported that the OPR (Action Agency) can
control group access permission to enter or update
Project Monitoring files by assigning a value to the
Action Agency field of a project.
The System Administrator will be provided with facilities
to establish single and group capabilities to users
through the provided table of user profiles where office
symbols can be chained together with one or more identification
and password combinations (group capabilities).
(2) (a) 2̲
Identification and password.
By use of the provided table of user profiles has the
System Administrator a facility to issue unique identification
and password combinations for use by several individuals
within a specific agency.
(2) (a) 3̲
Read write permissions.
It will be provided by the subsystem that the value
of the Action Agency field of a project determines
the read/write capabilities for agencies in the following
way:
. The Action Agency specified in a project will read,
write, add, replace and delete capabilities to
it.
. Action Agencies within the same deputate but above
the agency specified in the project will get read
only capability.
. Other agencies will get neither read nor write
capabilities.
(2) (a) 4̲
Single capabilities.
The System Administrator will be able to assign single
capabilities like read only permission for all files
in the Project Monitoring Subsystem to specifically
authorized individuals through the provided table of
user profiles.
(2) (a) 5̲
Project number protection.
As described in para. (1) (d) 4̲ of this sub-line item
it will be provided that the project number of the
Project Index can not be changed once it has been assigned
by the subsystem.
(2) (a) 6̲
Replace authority.
The OPR who is authorized to update through the identification
and password combination will be provided with an update
authority function, supported by prompts, to change
the authority to update (replace the project) to another
user.
(2) (b)
Update
(2) (b) 1̲
Update location
A project monitor will be provided with facilities
to update a project package either by update the contents
of his previously prepared private files or by copying
the contents of the Project Monitoring Subsystem file
for the package in question into his private files
for updates.
(2) (b) 2̲
Update functions.
The project monitor will be provided with the following
functions to update a project package within his private
files.
. Add, modify and delete text or graphic displays
. Modify Project summary contents.
. Add, modify and delete entries of a Project Index
(with exception of the project number).
(2) (b) 3̲
Project Package deletion.
The capability to delete a complete Project Package
and its associated index entries from the Project Monitoring
Subsystem files and Index will be provided by the subsystem
for the authorized project monitor.
(2) (b) 4̲
As of Date.
Each time a modified or updated project package is
reentered into the Project Monitoring Subsystem file
it will be provided that the As of date of the project
package is automatically updated to the current date.
(2) (b) 5̲
Project number assignment.
The subsystem will provide that the project number
only will be assigned to new Project Packages upon
there entrance into the Project Monitoring Subsystem
final files, and updated project packages only will
replace the old versions.
(2) (b) 6̲
Copy facility.
The subsystem will provide a copy facility, supported
by prompting, for the user to copy a project package
from his private file to another user's private file
(if he has access permission to the other user's private
file).
(3)
Output.
A user of this subsystem will be provided with flexible
retrieve facilities to output project information from
the Project Monitoring Subsystem file to which he is
authorized. The retrieve facilities can be varied in
several optional ways to support easy retrieval of
data.
(3) (a)
View a project.
When the user has entered the Project Monitoring Subsystem
he will be provided with a set of functional capabilities
through which he for instance will be able to view
a Project Summary or the entire Project Package identified
by a specific project number.
(3) (b)
Project selection.
The functional capabilities there are available for
a user when he has entered the Project Monitoring Subsystem
will support him with a hierarchy of menus and prompts
through which he will be able to perform, selections
that present him with a list of index entries which
he is authorized to view. It will be provided that
the list of index entries displays the project number,
the project name, and the As of Date.
As described in para (3) (a) above the user will be
provided with facilities for a selected project to
view either the Project Summary only or the entire
Project Package.
(3) (c) 1̲ through (3) (c) 1̲0̲
Project retrieval
The retrieve facilities which will be available for
the user when he has entered the Project Monitoring
Subsystem will support him with a retrieve format which
consists of the field names of a Project index prompting
for user input. The user will then be able to insert
search data into one to three fields of the format
to make up a search criteria. If more than 3 fields
are filled in with data, only the first three will
be considered.
The search will be performed on the Project Index's
and only those which meet the search criteria and to
which the user is authorized will be output.
The result will appear on the screen with the search
criteria first followed by a list of Project numbers,
project names, and As of Date for each one of the found
Project Index records. Hereafter will the user be able
to select those Project Summaries or complete packages
that he wants to view.
(3) (d)
Data output
Within all our proposed subsystems the general output
facilities will be available for the user to specify
the output device through use of the provided command
language or through the provided menu- or prompt-driven
selection facility. The user will be able to direct
output to any output device or private file to which
he has access capabilities and if he does not specify
a destination for the output the default destination
will the terminal from where the output function was
issued to the system.
(3) (e)
Output of graphic displays.
It will be provided that graphic displays will not
be output to any device without graphic display facilities,
but all text and character information will be output.
(3) (f)
Offline archives.
The capability to archive and retrieve project packages
to and from offline storage media like tape archives
will be provided by the subsystem.
(3) (f) 1̲
Deleted project package.
The subsystem will provide that when a project package
is deleted from the Project Monitoring Subsystem files
by a project monitor it will be assigned an "archive"
status.
(3) (f) 2̲
Move to offline storage.
The capability to move all project packages in "archive"
status, at least monthly, from the Project Monitoring
Subsystem file and store them on tape will be provided
by the subsystem for the person in charge of these
operations.
(3) (f) 3̲
The Archive Table will be provided to control the status
of project packages which have been moved to and offline
Archive tape. The subsystem will provide that each
time a project package is moved to tape, an entry will
be created in the Archive Table containing the Action
Agency, Project Number, Project Name, last associated
access permission, As of Date, The Date Moved To Tape,
and the Tape Identification for the project package
in question.
(3) (f) 4̲
Access permission for offline project packages.
It will be provided that the last access permission
associated with a project package also will be inserted
in the Archive Table upon the project package is moved
to an offline storage.
(3) (f) 5̲
Offline Project Retrieval
The provided retrieve facility for offline projects
through use of a menu will support the user with an
offline retrieve format which consists of the field
names Action Agency, Project Number, Project Name,
and As of Date prompting for user input. The user will
be able to insert search data into one or more fields
of the format to make up a search criteria. The search
will be performed on entries within the Archive Table
and only those entries which meet the search criteria
and to which the user is authorized will be output.
(3) (f) 6̲
Retrieval and delivery of offline project packages.
When a user has selected a project package from the
Archive Table to be displayed at his position the subsystem
will provide that the person in charge of offline retrieval
of project packages is notified in a way so he can
find the right tape and load the requested project
package into the system and create an envelope to it
for delivery to the requestor by Electronic Mail.
It can also be provided that the person in charge of
offline retrieval, he first copies the project into
the requestor's private file and afterwards informs
the requestor by Electronic Mail that the project package
has been transmitted and is stored in th requestor's
private files under a specified filename.
…86…1 …02… …02… …02… …02…
C8 e. S̲u̲b̲-̲L̲i̲n̲e̲ ̲I̲t̲e̲m̲ ̲0̲0̲0̲4̲A̲D̲,̲ ̲P̲e̲r̲s̲o̲n̲n̲e̲l̲ ̲a̲n̲d̲ ̲M̲a̲n̲p̲o̲w̲e̲r̲
Our proposed Personnel and Manpower subsystem will
provide its users with an interface front which in
regard to use is similar to the other available subsystems.
The subsystem is formed through the provided Command
Interactive System Language which is common for all
the subsystems and then a set of programs where some
are dedicated to this Personnel and Manpower subsystem
and the rest are common with one or more of the other
subsystems. The available functional capabilities
depends on the user which has selected the subsystem.
He will be furnished with a set of functional capabilities
to which he is authorized and if he tries a non-authorized
function it will be refused. To authorized users will
the subsystem provide functional capabilities to enter,
update, retrieve, and display Personnel/Manpower Data.
Retrieval of each data element or combination of data
elements contained in the ACCESS Personnel and Manpower
data bases will be supported in the design of this
subsystem.
(1) (b) 2̲
Data Keys
The subsystem will provide keys in the data base for
those manpower data element where it is specified that
they must have keys established.
(1) (b) 3̲
Data Updates
Facilities for updates of the manpower data base approximately
every two weeks will be provided by the subsystem.
(1) Input
(1) (a)
Personnel Data
Our proposed ACCESS System will support the Personnel
and Manpower Subsystem with input facility to get personnel
data loaded into the data base directly from multiple
1600 CPI magnetic tapes written from a Burroughs 6700
Computer.
(1) (a) 1̲
Personnel Data Base
It will be provided that the data base can contain
125.000 of specified records applicable to this subsystem.
(1) (a) 2̲
Update Facility
As mentioned in para. (1) (a) of this sub-line item
will the ACCESS System support input from the specified
tapes for updates of the ACCESS personnel data base.
(1) (a) 3̲
Unique User Records
The Subsystem will be provided with capabilites to
access unique user-created/maintained records.
(1) (a) 4̲
MAJCOM add-on Area
Each staff agency user will be provided with facilities
to update the MAJCOM add-on area with unique information
input from on-line terminals.
For retrieval purposes of a MAJCOOM add-on area it
will be provided that the Social Security Account Number
can be used as retrieval key. The subsystem will provide
that a formatted screen is available for the user to
view and updata a MAJCOM add-on area.
(1) (a) 5̲ a̲ through (1) (a) 5̲ c̲
Extract Tapes.
The Subsystem will provide that the three specified
extract tapes can be loaded into the ACCESS Personnel
Data Base without previous modification
(1) (b)
Manpower Data
The Personnel and Manpower Subsystem will provide input
facilities to get Manpower Data loaded into the Data
Base directly from a 800 CPI Magnetic Tage written
from a Honeywell 6000 Computer.
(1) (b) 1̲
Manpower Data Base
It will be provided that the Data Base can contain
120,000 specified records applicable to this subsystem.
(2) Processing Features:
The Processing Features of the Personnel and Manpower
Subsystem are many and some of them are user group
dependant and others are not. e.g. some features are
dedicated to the Data Base Administrator and others
are common for both Data Base Administrator and users
in general.
(2)(a) Data Base Capabilities:
For the user of the subsystem, a set of functions is
available related to the capabilities for the use of
the Data Base. A user profile tells whether a user
is authorized to perform a given function or not and
the permission table combined with the data base field
permission codes tells whether a user has access to
specific data or not.
(2)(a)1
Facilities are provided by the subsystem for the user
to interactively create queries for any one combination
of keys and fields for which the user is authorized.
The subsystem combines the user profile with the permission
table to gain permission codes to be used in connection
with the queries it has, hereafter, checked whether
the user has permission to access the specified data
fields or not.
(2)(a)2
The subsystem provides the user with functions so he
can save a retrieval request and later on perform a
continue retrieval request preparation for further
edit and finally execution.
(2)(a)3
Batch run retrieval is provided by the subsystem with
use of a create batch job function. During a create
batch job the user can combine previously created retrieval
requests with new ones interactively created off the
terminal by use of a merge function and a create next
retrieval function.
(2)(b) Systems Software Interface:
A full interface with system software applicable for
the subsystem is provided a̲n̲d̲ can be used by user with
the necessary authority. It is provided for the user
that he, through the supplied advanced Interactive
System Language, can use a result of a query as input
to graphics, statistics and report writer functions.
The user has only to select the command function and
to input the necessary parameters together with a reference
to the query result.
(2) (c)
Access Permissions
(2) (c) 1̲
Permission Codes
The subsystem will provide facilities to administor
allocation of permission codes to record which are
loaded from tape input to create data base relations.
. To each loaded record an edit of data elements
will be provided to determine a permission code
which will be added to the record before insertion
in the Data Base.
. During updates it will be provided to prevent changes
that a new edit of data elements is performed to
determine a possible new permission code to replace
the current one.
Permission code for a MAJCOM add-on area which
is related to a Personnel record will be updated
accordingly.
. The Subsystem will prevent that user created Unique
(x) records is not added with a permission code
for which the user is not authorized.
(2) (c) 2̲
General Access Permissions
In connection with Logon Procedures the combination
of use identification and password wil be checked against
a provided table for user profiles to determine whether
a user is known by the system or not.
When the user has passed the logon procedure and he
selects a subsystem it will be checked if he has access
rights to it or not.
If the user has access rights to a subsystem he has
selected, he will be allocated a set of functional
capabilities within the subsystem and if he tries to
perform a function to which de does not have any capability
it will be refused. The same thing will happen if
he tries to access or perform a function on data to
which he does not pocess the necessary permissions.
These above mentioned facilities will be used to allocated
different functional capabilities of different subsystems
to different user groups and individual users of the
ACCESS System.
. The Data Base Administrator will be provided with
capabilities to assign users access permissions
to records with specific permission codes.
. The Chief of Staff (CS) will be provided with read-only
permission to view any record in the Data Base.
. The DCS (DP) personnel will be provided with read-only
permission to view all Personnel record.
. All other users will be provided with read-only
permission to view specific records related to
their own agency and only records containing designated
permission codes.
(2)(c) 3
It is determined through the combination of User Profile,
Permission Table, and Protection Codes associated with
data on the Data Base whether a specific user or user
group of the subsystem has read, write, update, or
create rights or not on specific data.
So it wil be provided that only users with the correct
permission will be allowed to create or update a record
in the MAJCOM add-on area and unique (x) records.
(2)(c)4
The Subsystem provides facilities for the Data Base
Administrator to maintain and update the Permission
Table.
Among the available functions offered by the subsystem
are there change field contents and change field, description,
both of which are provided with the use of prompts.
The change field contents function supports update
of permission codes and the change field description
is used for change of field size, data type (e.g. alpha,
numeric, or alphanumeric). The different field descriptions
are located in separate files so they can be used to
update changes and the interface with the Data Base
Management System.
(2) (d) 1̲
Personnel Data Base Maintenance:
It is provided by the subsystem that the Data Base
Administrator can maintain and update the Data Base.
For all file modification transactions applicable
to the personnel Data Base it will be provided that
the Social Sercurity Account Number can be used as
the primary key. Facilities to maintain and update
the Data Base the covers following batch processing.
. Add single or multiple records
. Update single or multiple records
. Delete single or multiple records
. Update single or multiple data items in MAJCOM
add-on areas.
(2) (d) 1̲ a̲
File Maintenance
When a record is added to the Personnel Data Base the
subsystem will provide that a new Social Security Account
Number (SSAN) can be identified and permissions established
in accordance with the Permission Table. Upon deletion
of a record it will be checked for the record-drop-indicator
"D" and then deleted from the file.
To update a Personnel Data record the first step is
to retrieve it from the Data Base with the use of the
SSAN as primary key. When found, the updates can take
place and then the entire record (excluding the MAJCOM
add-on area) can be overwritten. If the permission
code changes during an update, the subsystem will provide
that the permission code of the associated MAJCOM add-on
area will be changed accordingly for those Personnel
Data records that does not meet specified conditions.
That subsystem will provide that they will be assigned
permission "zz" only allowing the DCS (DP) personnel
to grant permission to them.
(2) (d) 1b MAJCOM Add-on Area:
The Subsystem supports the user with capabilities to
update records in the MAJCOM Add-on Area which are
under the users responsibility. The update function
is performed on unique (x) records with the use of
the SSAN or the identification number as a primary
key.
(2)(d) 1c Unique (x) Records:
For the User which has permission to add unique user
records to the data base the subsystem provides the
following facilities to these records with the identification
number as primary key.
o Add data to the record
o Update the record with new data
o Delete the record from the data base
(2)(d) 2 Manpower Data Base Maintenance
The personnel and manpower subsystem provides the Data
Base Administrator with facilities to maintain the
manpower data base. By the use of the ACC-POSITION-NO
as primary key the following functions are available
for the DBA:
o Add Single or multiple records
o Update single or multiple records
o Delete single or multiple records
Other functions available for the DBA are
o update single or multiple data items
o load new data into the ACCESS Manpower Data Base
(2)(e) Query Construction
The HELP function is provided at any command level
within a subsystem and it supports a user with a catelogue
of help information, which is related to him and the
subsystem from where the function is called. So during
the construction of a query for the personnel files
the user can get help via listing of codes or abbreviations
which are available for this subsystem and which the
user has permission of access.
(3) Output:
It is provided by the subsystem that all output applicable
to it, is available on the specified terminal types
which are Video Display Unit, Color Graphics Display
Unit and Hard Copy Device. On the same terminals it
is provided that retrieval can take place of complete
personnel and manpower data records.
To support the capabilities for variable formatting
of output displays a change format function is provided
which offers facilities to change a copy of an existing
format to a temporary format for one output transaction,
saved as a new format, or to overwrite the predecessor
format, if the user has the necessary authority to
do so.
By a provided create format function new formats can
be built with capabilities for later alteration. The
graphics formatting capabilities of the system will
be supplied with compatible data obtained from the
data base to support fully, exploit data retrieval
from the personnel data base.
C8f. S̲u̲b̲-̲L̲i̲n̲e̲ ̲I̲t̲e̲m̲ ̲0̲0̲0̲4̲A̲E̲,̲ ̲B̲u̲d̲g̲e̲t̲ ̲S̲u̲b̲s̲y̲s̲t̲e̲m̲
(1), (1) (a) through (1) (h)
Input
It will be provided by the subsystem that the listed
data items extracted from the SAC POM yearly can be
input manually on a replacement basis.
(2)
Processing Features
(2) (a)
Agency responsibility
The subsystem will accept input from each agency of
program decision packages for which the agency is the
PDP monitor.
(2) (b) 1̲ through (2) (b) 1̲6̲
During a new program decision package preparation or
a continue program decision package preparation the
subsystem will provide that the user is prompted for
input of test and data element as required.
(2) (c)
Mandatory and optional fields
The subsystem will provide that the mandatory package
title and text description fields will get data filled
in during a prompting sequence. For the other fields
of the program decision package format where input
is optional it will be provided that the empty fields
will be supressed at later output, with the one exception
where the output is performed in connection with an
update of the Program Decision Package where the empty
fields might get data filled in.
(2) (d)
Year fields
It will be provided that XPP can enter the six years
in two digit (2N) fields.
(2) (e)
Input check and validation
A data check on input will be provided for those fields
with specific defined data characteristics and validation
will be performed against the description tables for
any PE, Appropriation Code, BP, EEIC, or PDP level
input.
(2) (f)
ACCESS Permissions
(2) (f) 1̲
Read-only permission
This permission to all Budget subsystem information
will be issued to all user that has passed the system
login procedure.
(2) (f) 2̲
Identification and password.
By use of the provided table of user profiles the System
Administrator has a facility to issue unique identification
and password combinations for use by several individuals
within a specific agency.
(2) (f) 3̲
Allocation of access permissions.
Through the combination of the PDP Monitor Office Symbol
field associated with a PDP and the provided table
of user profiles it will be determined whether a user
has permission or not to update specific PDP records.
It will be supported that the PDP Monitor Office Symbol
field can be used to determine authorization.
The System Administrator will be provided with facilities
to establish single and group capabilities to users
through the provided table of user profiles where office
symbols can be chained together with one or more identification
and password combinations.
(2) (f) 4̲
Single capabilities.
The System Administrator will be able to assign single
capabilities like read or write permission for any
records, files, or description tables in the budget
subsystem to specifically authorized individuals through
the provided table of user profiles.
(3) (h)
Output of graphic displays.
It will be provided that graphic displays will not
be output to any device without graphic display facilities,
but all test and character information will be output.
(2) (f) 5̲
It is taked down that there is no special field privileged
requirements.
(2) (f) 6̲
Write and update restriction.
The subsystem will provide the System Administrator
with capability to restrict write and update permission
for the description tables to XPP (DCS/Plans - Programs).
(2) (f) 7̲
It will be provided too that permissions to produce
rank listings can be restricted to XPP.
(2) (f) 8̲
Change of read and write permission.
The subsystem will provide that the XPP can determine
when the data base shall be opened and closed. The
System Administrator will be provided facilities to
change the read and write permission for the data base
to read-only for all agencies, with exception of XPP
which retain their read/write capability.
(2) (g)
Automatic update.
Upon creation or deletion of a PDP the subsystem will
provide that an index of PDP titles and PDP Monitor
Office Symbols will be automatically updated and maintained.
(2) (h)
Query capabilities will be provided as follows:
(2) (h) 1̲
Display a file
The subsystem will provide that users will be able
to display a file as it is normally maintained in the
POM.
(2) (h) 2̲ and (2) (h) 3̲
Aggregate data
It will be provided by the subsystem that users will
be able to aggregate data by combinations of parameters
including PEC, appropriation, PDP level, SAC and air
staff package numbers, PDP monitor office symbol and
cost element. The aggregation of data will be allowed
to take place within a program decision package, within
a program decision package level, or across several
or all program decision packages.
(2) (h) 4̲
Aggregation level.
Through use of a provided menu of parameters the user
will be able to choose and thereby specify an aggregation
level.
(2) (h) 5̲
User parameters.
The user will be provided capability to find his parameters
by call of description tables of PECs, PDP levels,
cost elements and appropriation codes.
(2) (h) 6̲
List PDPs
To obtain a list of PDPs within an agency the user
will be provided a facility where the PDP monitor office
symbol, or a part of it can be used as key.
(2) (h) 7̲
List PECs
The subsystem will provide a capability for the user
to search the PE description table by a keyword in
order to find a PEC.
(2) (h) 8̲
Separate personnel categories
It will be provided that responses to manpower queries
will keep the five categories of personnel separate.
(2) (h) 9̲
Rank order listing.
The facility to query against any of the rankings in
order to get a rank order listing will be provided
by the subsystem for the XPP.
(2) (h) 1̲0̲
Store query result.
The user will be provided a capability to store a query
and/or the results of a query as a private file in
his directory and indexed for later use.
(2) (h) 1̲1̲
It is taken down.
…86…1 …02… …02… …02… …02…
(2) (i)
Update capabilities will be provided as follows.
(2) (i) 1̲
Update PDPs.
The subsystem will provide the agencies with the capability
to update their program decision packages interactively
without leaving this subsystem.
(2) (i) 2̲
Highlights of changes.
It will be implemented that any changes made to a program
decision package will be flagged or highlighted in
some way.
(2) (i) 3̲
Remove Highlights of changes.
The XPP will be provided a capability to remove flags
or highlights from a program decision package once
they have been reviewed.
(3)
Output
(3) (a)
Output formats.
It will be provided that PDP data can be output in
the desired report format or in graphic/statistical
format and that all program element codes will output
the letter F at the end of the code. It will be provided
too that cost element data will be on a separate page.
(3) (b)
Statistical and graphic output.
The user will be provided facilities to enter data
directly for statistical or graphic output without
leaving the subsystem.
(3) (c)
Report Writer.
The report writer will be provided to be available
to all agencies.
(3) (d) and (3) (e)
PDP output
The subsystem will provide that all PDP output will
list the program decision package title if data is
from only one program, or the aggregation criteria,
such as SAC package number or PE, if more than one
program decision package is involved, the output will
include a list of the program decision packages.
(3) (f)
Rank Listings
To support rank listings it will be provided by the
subsystem that they can be created in ascending or
descending order, as required and when they are build
the TOA will be aggregated and the present accumulated
total will be an output with the TOA. The Rank Listings
will be provided to be output by requested rank, SAC
package number, PDP name, remaining ranks, and PDP
TOA or cummulative TOA for the year requested.
There will be provided a view on the data base which
is associated with the ranks data and it will prevent
that the ranks can be output in any output other than
rank listings.
(3) (g)
Run Stored Queries.
In continuation of para (2) (h) 1̲0̲ within this subline
Item it will be provided that the user will be able
to initiate and run stored queries through the use
of the created index.
TL-13
B̲P̲-̲1̲5̲0̲0̲
Additional Manufacturer's Data:
1. Print speed will be 910 1pm with 132 columns of
asci, 96 chr set.
2. Paper width can be 3.5 to 18-75 inches.
3. Single, double and multiple line feeds are available
also tof using the standard tape, or davfu.
4. Data line 'ready' will be true with the following
conditions:
a. power and dc voltages are on
b. all interlocks are closed
c. paper has been loaded
d. no print faults exist
e. the fault light is off
