DataMuseum.dk

Presents historical artifacts from the history of:

CR80 Wang WCS documentation floppies

This is an automatic "excavation" of a thematic subset of
artifacts from Datamuseum.dk's BitArchive.

See our Wiki for more about CR80 Wang WCS documentation floppies

Excavated with: AutoArchaeologist - Free & Open Source Software.


top - download

⟦a34214981⟧ Wang Wps File

    Length: 11279 (0x2c0f)
    Types: Wang Wps File
    Notes: DN SAC ACCESS; HH-1/34    
    Names: »3415A «

Derivation

└─⟦ab79d1adb⟧ Bits:30006221 8" Wang WCS floppy, CR 0269A
    └─ ⟦this⟧ »3415A « 

WangText

…0b……00……00……00……00…9…0a……00……00…9…0b…9…0e…9…00…9…01…9 9…06…9…07…8…08…8…0c…8…86…1         …02…   …02…   …02…   …02…                                           



SAC ACCESS, AFCAC Project 211                       SYS/1983-03-18














C̲o̲n̲t̲r̲o̲l̲ ̲N̲u̲m̲b̲e̲r̲:  HH-1

Please note that the operational floor area requirements given
 in table II 6.1-1 and table II 6.1-2 are considerably smaller
 than specified, because the layout of room BB-30 has been made
 so that different equipment is utilizing the same maintenance
 access area.

We have now updated the proposal to reflect this.

The following pages have been updated.















P̲r̲o̲p̲o̲s̲a̲l̲ ̲C̲h̲a̲n̲g̲e̲ ̲P̲a̲g̲e̲s̲:                                           
                                                                 

I - Section F pages 2-3-4-5-6.
I - Section C pages 14-17-18-25.







C̲o̲n̲t̲r̲o̲l̲ ̲N̲u̲m̲b̲e̲r̲: HH-2


Christian Rovsing A/S will update the proposal and state that
 all equipment and software will be developped in accordance
 with the FIPS PUBS, where applicable.



















Proposal Change Pages:

I-B-2








C̲o̲n̲t̲r̲o̲l̲ ̲N̲u̲m̲b̲e̲r̲: HH-3


The proposal will be updated as shown on the following
 pages.





















Proposal Change Pages:

I-B-5








C̲o̲n̲t̲r̲o̲l̲ ̲N̲u̲m̲b̲e̲r̲:  HH-4

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.













P̲r̲o̲p̲o̲s̲a̲l̲ ̲C̲h̲a̲n̲g̲e̲ ̲P̲a̲g̲e̲s̲:                     

I, B C4c  5a







C̲o̲n̲t̲r̲o̲l̲ ̲N̲u̲m̲b̲e̲r̲:  HH-5



All user transactions are logged on disk.

Statistical measures of the data, such as number of transactions
 processed and responsetime, can be calculated by command from
 the System Administrator.














P̲r̲o̲p̲o̲s̲a̲l̲ ̲C̲h̲a̲n̲g̲e̲ ̲P̲a̲g̲e̲s̲:                                           I,
                                                                 B,
                                                                 C4c
                                                                 
                                                                 b







C̲o̲n̲t̲r̲o̲l̲ ̲N̲u̲m̲b̲e̲r̲: HH-6




























Proposal Change Pages:

I-B-6a (c. Functional Availability)








C̲o̲n̲t̲r̲o̲l̲ ̲N̲u̲m̲b̲e̲r̲:  HH-7



A Diablo 630 will be TEMPEST accredited.


















P̲r̲o̲p̲o̲s̲a̲l̲ ̲C̲h̲a̲n̲g̲e̲ ̲P̲a̲g̲e̲s̲:                     I-B-8
             II-B-36







C̲o̲n̲t̲r̲o̲l̲ ̲N̲u̲m̲b̲e̲r̲: HH-8


The data base will be implemented on dualized IDMs. Each IDM
 can cope with an addressing space of 32 Giga bytes but are limited
 by  current disk technology, which only allows 16 disk drives
 to be used. If 600 Mega bytes disk are used, then only 9,6 Giga
 bytes can be accommodated. However, CR has made an conservative
 estimate allowing one pair of IDMs for the first increment only,
 providing sufficient space for the required 2.5 Gigabytes.

In calculation of the actual space, a working area is allocated
 for basic sorting operations plus an additional space is allocated
 for each required physical key index.

Each IDM can automatically manage a number of physical databases,
 but can also integrate these in one or more databases, still
 maintaining security segregation of access to the individual
 portions of the database.






Proposal Change Pages:

I-B-8








C̲o̲n̲t̲r̲o̲l̲ ̲N̲u̲m̲b̲e̲r̲:  HH-9



The system will support 2000 user identifiers.


















P̲r̲o̲p̲o̲s̲a̲l̲ ̲C̲h̲a̲n̲g̲e̲ ̲P̲a̲g̲e̲s̲:                    I, B, C4f 10







C̲o̲n̲t̲r̲o̲l̲ ̲N̲u̲m̲b̲e̲r̲: HH-10


The amount of data area required for the data base is estimated
 like this: 0.5 Gigabyte for working storage, and overhead area
 for 4 key indices each requiring 7% overhead. Totaling 28% overhead.
 This estimate gives 3.7 Gigabytes for increment 1 requirement,
 provided by 7 x 0.6 = 4.2 Gigabytes. 

Final size is 600% of 2.5 Gigabytes meaning 15 Gigabytes. The
 above formula gives 15 + 0.5 + 4.2 = 19.7 Gigabytes, and the
 storage provided is 33 x 0.6 = 19.8 Gigabytes.

The addressing space for each IDM is 32 Gigabytes, but the limitation
 is 16 disk drives. Present technology only provides 600 Megabyte
 disk, but new 1.2 Gigabyte disk are being tested by CDC and
 will soon be released. This will ease the room space problem
 in increment 3.







Proposal Change Pages:

I-B-11








C̲o̲n̲t̲r̲o̲l̲ ̲N̲u̲m̲b̲e̲r̲: HH-11


The proposal will be updated as requested and shown in
 response to HH-10.




















Proposal Change Pages:

I-B-11








C̲o̲n̲t̲r̲o̲l̲ ̲N̲u̲m̲b̲e̲r̲: HH-12




























Proposal Change Pages:

I-B-14 (C5e)






C̲o̲n̲t̲r̲o̲l̲ ̲N̲u̲m̲b̲e̲r̲:  HH-13



The requested information has been added to the proposal.


















P̲r̲o̲p̲o̲s̲a̲l̲ ̲C̲h̲a̲n̲g̲e̲ ̲P̲a̲g̲e̲s̲:                    I-B-14







C̲o̲n̲t̲r̲o̲l̲ ̲N̲u̲m̲b̲e̲r̲:  HH-14



1.       The HSNIP will interface directly to the ACCESS
         (on-line) system, using the HSNIP on-line interface
         and the terminal emulation capability of the
         XTA unit.

2.       The HSNIP can output the 95 character ASCII
         sub-set, conforming to FIPS-PUB 15.

3.       Merging of forms with data to create a single
         document is possible; an example of this facility
         is given.

4.       Accessing stored charts, logos, signatures,
         and documents for printing is possible; an example
         of this facility is given.









P̲r̲o̲p̲o̲s̲a̲l̲ ̲C̲h̲a̲n̲g̲e̲ ̲P̲a̲g̲e̲s̲:                                           

Two pages have been added to the technical literature,
 illustrating points 3 and 4 above.

TL-12/HSNIP: 2 Pages.







C̲o̲n̲t̲r̲o̲l̲ ̲N̲u̲m̲b̲e̲r̲:  HH-15






















P̲r̲o̲p̲o̲s̲a̲l̲ ̲C̲h̲a̲n̲g̲e̲ ̲P̲a̲g̲e̲s̲:

One page has been added to the technical literature, providing
 manufacturer's data with respect to points 1 through 4 above.

TL-13/LP: 1 Page









C̲o̲n̲t̲r̲o̲l̲ ̲N̲u̲m̲b̲e̲r̲:  HH-16

Technical Literature 14:

Host program control via escape sequences, offering a wide variety
 of forms control, ........., positive/negative line feed, automatic
 carriage return and remote reset.


















P̲r̲o̲p̲o̲s̲a̲l̲ ̲C̲h̲a̲n̲g̲e̲ ̲P̲a̲g̲e̲s̲:

None







C̲o̲n̲t̲r̲o̲l̲ ̲N̲u̲m̲b̲e̲r̲: HH-17


The operator manual of the VDU has been included as technical
 literature.




















Proposal Change Pages:

II-A-1








C̲o̲n̲t̲r̲o̲l̲ ̲N̲u̲m̲b̲e̲r̲: HH-18


Please refer to response on HH-17.




















Proposal Change Pages:

II-A-1








C̲o̲n̲t̲r̲o̲l̲ ̲N̲u̲m̲b̲e̲r̲: HH-19


Please refer to answer given on HH-17.




















Proposal Change Pages:

II-A-1








C̲o̲n̲t̲r̲o̲l̲ ̲N̲u̲m̲b̲e̲r̲: HH-20


Please refer to answer given on HH-17.




















Proposal Change Pages:

II-A-1








C̲o̲n̲t̲r̲o̲l̲ ̲N̲u̲m̲b̲e̲r̲:  HH-21



Technical Specification for the proposed CGDU will be
 included in proposal part II, A.







C̲o̲n̲t̲r̲o̲l̲ ̲N̲u̲m̲b̲e̲r̲: HH-22


Please refer to answer given on HH-17.




















Proposal Change Pages:

II-A-1








C̲o̲n̲t̲r̲o̲l̲ ̲N̲u̲m̲b̲e̲r̲: HH-23


The VDU can operate with several cursor symbols as shown
 in the Operators Manual provided as a technical literature.
 The VDU also has a programmable audible alarm signal.



















Proposal Change Pages:

II-A-1








C̲o̲n̲t̲r̲o̲l̲ ̲N̲u̲m̲b̲e̲r̲: HH-24


No more patterns of any significance exist on the VDU
 and the CGDU. This will be demonstrated in live at the
 FLTD.




















Proposal Change Pages:

I-B-16








C̲o̲n̲t̲r̲o̲l̲ ̲N̲u̲m̲b̲e̲r̲: HH-25


The Operators Manual has been included to provide detailed
 information on the VDU.




















Proposal Change Pages:

II-A-1








C̲o̲n̲t̲r̲o̲l̲ ̲N̲u̲m̲b̲e̲r̲: HH-26


Please refer to the answer given for HH-27.



















                       

      








C̲o̲n̲t̲r̲o̲l̲ ̲N̲u̲m̲b̲e̲r̲: HH-27


The various character set are implemented by software,
 meaning that the requested set of courier 12, prestige
 elite, letter gothic and FIPS PUB 32 OCR-A and OCR-B
 size 1 character sets will be implemented.


















Proposal Change Pages:

I-B-16








C̲o̲n̲t̲r̲o̲l̲ ̲N̲u̲m̲b̲e̲r̲:  HH-28
























P̲r̲o̲p̲o̲s̲a̲l̲ ̲C̲h̲a̲n̲g̲e̲ ̲P̲a̲g̲e̲s̲:

I-B-18






C̲o̲n̲t̲r̲o̲l̲ ̲N̲u̲m̲b̲e̲r̲:  HH-29



The System Administrator has capabilities to:

  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.






P̲r̲o̲p̲o̲s̲a̲l̲ ̲C̲h̲a̲n̲g̲e̲ ̲P̲a̲g̲e̲s̲:                                           I,
                                                                 B,
                                                                 C6a
                                                                 
                                                                 21








C̲o̲n̲t̲r̲o̲l̲ ̲N̲u̲m̲b̲e̲r̲:  HH-30



The proposed implementation will be in accordance with
 method no. 3 outlined in the RFP:

















P̲r̲o̲p̲o̲s̲a̲l̲ ̲C̲h̲a̲n̲g̲e̲ ̲P̲a̲g̲e̲s̲:                                           I,
                                                                 B,
                                                                 C6c
                                                                 
                                                                 21








C̲o̲n̲t̲r̲o̲l̲ ̲N̲u̲m̲b̲e̲r̲: HH-32



























Proposal Change Pages:

II-B-33
II-B-37
II-B-38






C̲o̲n̲t̲r̲o̲l̲ ̲N̲u̲m̲b̲e̲r̲: HH-33


The principle used in all modern OCR's, is the best guess
 methods. Each characters position on the input sheet
 is analysed and compared to internal character representations.
 In order to cope with small non-alignments in character
 positioning the character analysis is performed with
 several different location of the local coordinat system
 used for each character analysis. For each comparison
 a score is calculated, and the character getting the
 highest score is used as the best guess for the character.














Proposal Change Pages:

I-B-16








C̲o̲n̲t̲r̲o̲l̲ ̲N̲u̲m̲b̲e̲r̲: HH-34


The OCR will be selected in accordance with the FIPS
 PUB 85 standards.




















Proposal Change Pages:

I-B-16