      Software Product  Description   C ___________________________________________________________________   D PRODUCT NAME:  Compaq Galaxy Software Architecture on OpenVMS Alpha,
 Version 1.0-3  SPD 70.44.04   Note:   C This SPD describes the Compaq Galaxy Software Architecture on Open- H VMS, which is available as a separately licensed System Integrated Prod-
 uct (SIP).  E Throughout this document, OpenVMS Galaxy and Galaxy refer to the Com- E paq Galaxy Software Architecture on OpenVMS. The term instance refers 0 to a copy of the OpenVMS Alpha operating system.   DESCRIPTION   C OpenVMS Galaxy enables multiple instances of OpenVMS to execute co- F operatively in a single computer, giving customers the ability to man-C age unpredictable, variable, or growing workloads. With OpenVMS Al- F pha Version 7.2-1 or higher, customers can configure AlphaServer ES40,G GS140, GS60, GS60E, 8400, 8200, and 4100 systems as OpenVMS Galaxy sys-  tems.   C With OpenVMS Alpha Version 7.2-1H1 or higher, customers can config- D ure AlphaServer GS80, GS160 and GS320 systems as OpenVMS Galaxy sys- tems.   E With OpenVMS Galaxy, many processors and other physical resources are D partitioned in order to run multiple instances of operating systems.E Each instance has assigned CPUs, memory, and I/O. The instances share E a part of the memory, and CPUs can be reassigned from one instance to C another while the system is running. This computing environment can C be dynamically adapted to meet changing application needs and work- 
 load demands.   C                                                          March 2001        D Software logically partitions systems by assigning CPUs, memory, andG I/O ports to individual instances of the OpenVMS operating system. This E partitioning, which a system manager directs, is a software function; E no hardware boundaries are required. Each individual instance has the D resources it needs to execute independently. An OpenVMS Galaxy envi-E ronment is adaptive in that resources such as CPUs can be dynamically - reassigned to different instances of OpenVMS.   F Memory is logically partitioned into private and shared sections. EachH instance of the operating system has its own private memory, which meansI that no other instance writes to those physical pages. Some of the shared D memory is available for instances of OpenVMS to communicate with oneD another, and the rest of the shared memory is available for applica-
 tion data.  F An OpenVMS Galaxy has a highly scalable I/O subsystem because the sys-C tem contains multiple primary CPUs - one in each instance. In addi- F tion, OpenVMS currently has features for distributing some I/O to sec-8 ondary CPUs in a symmetric multiprocessing (SMP) system.  9 CPUs within an OpenVMS Galaxy are allocated to instances.   D In an OpenVMS Galaxy environment, the console firmware plays a crit-C ical role in partitioning hardware resources. It maintains the per- C manent configuration in NVRAM and the running configuration in mem- E ory. The console provides each instance of the OpenVMS operating sys- 5 tem with a pointer to the running configuration data.   D The console performs power-up self-tests, initializes hardware, ini-D tiates system booting, and performs I/O services during system boot-E ing and shutdown. The console program also provides run-time services D to the operating system for console terminal I/O, retrieval of envi-4 ronment variables, NVRAM saving, and other services.  F An OpenVMS Galaxy computing environment lets customers decide how muchA cooperation exists between instances in a single computer system.   C In a shared-nothing computing model, the instances do not share any 4 resources; operations are isolated from one another.  "                                  2       G In a shared-partial computing model, the instances share some resources  and cooperate in a limited way.   E In a shared-everything model, the instances cooperate fully and share  all available resources.  E OpenVMS Galaxy leverages proven OpenVMS Cluster, SMP, and performance H capabilities to offer greater levels of performance, scalability, avail- ability, and flexibility.   G By running multiple instances of OpenVMS in a single computer, an Open- C VMS Galaxy computing environment gives you quantum improvements in:   ; o  Compatibility-Existing applications run without changes.   E o  Availability-Presents opportunities to upgrade software and expand $    system capacity without downtime.  C o  Scalability-Offers scaling alternatives that improve performance #    of SMP and cluster environments.   C o  Adaptability-Physical resources can be dynamically reassigned to "    meet changing workload demands.  D o  Cost of ownership-Fewer computer systems reduce system management'    requirements, floor space, and more.   G For companies looking to improve their ability to manage unpredictable, E variable, or growing IT workloads, OpenVMS Galaxy technology provides F a flexible way to dynamically reconfigure and manage system resources.  F An OpenVMS Galaxy computing environment is ideal for high-availability applications, such as:   o  Database servers   ! o  Transaction processing systems    o  Data warehousing    o  Data mining   o  Internet servers   "                                  3         Software and Hardware Components  C An OpenVMS Galaxy computing environment is comprised of the follow-  ing:  ! o  OpenVMS Alpha operating system    o  AlphaServer Console Firmware    o  Supported hardware   F For more information about these components, see the Software Require-5 ments and Hardware Requirements sections of this SPD.    FEATURES  D With OpenVMS Alpha Version 7.2-1H1 or later, you can create an Open-4 VMS Galaxy computing environment that allows you to:  7 o  Run two instances of OpenVMS on an AlphaServer GS80.   9 o  Run four instances of OpenVMS on an AlphaServer GS160.   : o  Run eight instances of OpenVMS on an AlphaServer GS320.  C With OpenVMS Alpha Version 7.2-1 or higher, you can create an Open- 4 VMS Galaxy computing environment that allows you to:  ? o  Run three instances of OpenVMS on an AlphaServer 8400/GS140.   B o  Run two instances of OpenVMS on an AlphaServer 8200/GS60/GS60E.  7 o  Run two instances of OpenVMS on an AlphaServer 4100.   7 o  Run two instances of OpenVMS on an AlphaServer ES40.   # o  Reassign CPUs between instances.   9 o  Perform independent booting and shutdown of instances.   5 o  Use shared memory for interinstance communication.   D o  Create a shared memory RAMdisk with Compaq DECram for OpenVMS Al-    pha Version 3.0.   "                                  4       C o  Cluster instances within an OpenVMS Galaxy using the Shared Mem- #    ory Cluster Interconnect (SMCI).   - o  Cluster instances with non-Galaxy systems.   C o  Create applications using OpenVMS Galaxy application programming G    interfaces (APIs) for resource management, event notification, lock- B    ing for synchronization, and shared memory for global sections.  E o  Use the Galaxy Configuration Utility (GCU) to view and control the     OpenVMS Galaxy environment.  C o  Run a single-instance OpenVMS Galaxy on any Alpha system for ap-     plication development.   F The following sections describe some of these features in more detail.   Galaxy Configuration Utility  G The Galaxy Configuration Utility is a DECwindows Motif application that E allows system managers to configure and manage an OpenVMS Galaxy sys- % tem from a single workstation window.   # Using the GCU, system managers can:   + o  Display the active Galaxy configuration.   - o  Reassign resources among Galaxy instances.   * o  View resource-specific characteristics.  4 o  Shut down or reboot one or more Galaxy instances.  & o  Invoke additional management tools.  1 o  Create and engage Galaxy configuration models.   D o  Create a single-instance Galaxy on any Alpha system (for software1    development on non-Galaxy hardware platforms).   ( o  View the online Galaxy documentation.  C o  Determine hot-swap characteristics of the current hardware plat-     form.  "                                  5       " Shared Memory Cluster Interconnect  D The Shared Memory Cluster Interconnect (SMCI) is a System Communica-F tions Services (SCS) port for communications between Galaxy instances.C When an OpenVMS instance is booted as both a Galaxy and as an Open- C VMS Cluster member, the SMCI driver is loaded. This SCS port driver D communicates with other cluster instances in the same Galaxy throughD shared memory. This capability provides one of the major performanceD benefits of the OpenVMS Galaxy Software Architecture. The ability toD communicate to another clustered instance through shared memory pro-C vides dramatic performance benefits over traditional cluster inter- 	 connects.   4 Local Area Network (LAN) Shared Memory Device Driver  H Local Area Network (LAN) communications between OpenVMS Galaxy instancesG are supported by the Ethernet LAN shared memory driver. This LAN driver I communicates to other instances in the same OpenVMS Galaxy system through E shared memory. Communicating with other instances through shared mem- 8 ory provides performance benefits over traditional LANs.   RAMdisk in Shared Memory  C In DECram for OpenVMS Alpha Version 3.0, DECram's capability is ex- F tended to use OpenVMS Galaxy shared memory to create an OpenVMS sharedI memory disk. This allows users to take advantage of OpenVMS Galaxy shared : memory without modifications to any of their applications.  " Application Programming Interfaces   o  Locks for synchronization   o  Event notification     o  Shared memory global sections   o  Configuration information   o  CPU management   D For more information about OpenVMS Galaxy APIs, refer to the OpenVMS$ Alpha Partitioning and Galaxy Guide.  "                                  6       $ Single-Instance Galaxy Configuration  D A single-instance Galaxy is for non-Galaxy platforms, that is, thoseF without a Galaxy console. Galaxy configuration data, which is normallyC provided by console firmware, is instead created in a file. By set- G ting the system parameter GALAXY to 1, SYSBOOT reads the file into mem- C ory and the system boots as a single-instance Galaxy, complete with D shared memory, Galaxy system services, and even self-reassignment of- CPUs. This can be done on any Alpha platform.   D Single-instance Galaxy configurations will run on any Alpha worksta-H tions or servers (even laptops) running OpenVMS Version 7.2-1 or higher.E This capability allows early adopters to evaluate OpenVMS Galaxy fea- D tures and, most important, to develop and test Galaxy-aware applica-E tions without incurring the expense of setting up a full-scale Galaxy 	 platform.   E Because a single-instance Galaxy is not an emulator-it is real Galaxy C code-applications developed on a single-instance Galaxy will run on ! multiple-instance configurations.    SOFTWARE REQUIREMENTS   D OpenVMS Galaxy configurations require OpenVMS Alpha Version 7.2-1 or higher.   E OpenVMS Galaxy console firmware for the supported AlphaServers is lo- 2 cated on the Alpha Systems Firmware Update CD-ROM.   HARDWARE REQUIREMENTS   = Configuring an OpenVMS Galaxy computing environment requires:   $ o  One I/O module for each partition  3 o  At least one processor module for each partition   5 o  A dedicated serial console port for each partition   C o  Sufficient memory for operating system and required applications   "                                  7        Optional Hardware   F OpenVMS Version 7.3 customers might want to use the following optional	 hardware:   D o  Plug-in units (PIUs) for I/O expansion from an I/O module (PCI or    XMI)   C o  I/O adapters for network, storage, or traditional cluster inter-     connects   $ o  Additional CPUs for SMP instances  3 o  Additional memory for Galaxywide global sections    GCU Hardware Requirements   C Compaq recommends an Alpha or VAX workstation running DECwindows or E a Windows NT workstation with an X terminal emulator as a display de- 2 vice for the OpenVMS Galaxy Configuration Utility.   SUPPORTED HARDWARE  - AlphaServer GS80/160/320 Galaxy Configuration   C OpenVMS Alpha Version 7.2-1H1 or higher supports the following max- 0 imum configurations on AlphaServer GS80 systems:      2 instances	    2 QBBs 	    8 CPUs     64 GB memory   C OpenVMS Alpha Version 7.2-1H1 or higher supports the following max- 0 imum configuration on AlphaServer GS160 systems:      4 instances	    4 QBBs 
    16 CPUs    128 GB memory  "                                  8       C OpenVMS Alpha Version 7.2-1H1 or higher supports the followng maxi- 0 mum configurations on AlphaServer GS320 systems:      8 instances	    8 QBBs 
    32 CPUs    256 GB memory   Configuration Rules   C Note: The AlphaServer GS80, GS160, and GS320 systems can be config- F ured with one or more hard partitions. OpenVMS Galaxy can be installed@ on each hard partition to configure one or more soft partitions.  E o  Must have standard COM1 UART console line for each soft partition.   9 o  Must have a master PCI drawer for each soft partition.   . o  Must have an I/O module per soft partition.  8 o  Must have at least one CPU module per soft partition.  ; o  Must have at least one memory module per soft partition.   % AlphaServer ES40 Galaxy Configuration   H AlphaServer ES40 systems can support a maximum of two instances of Open- VMS.   AlphaServer ES40 Clock  D An AlphaServer ES40 has one clock. For an OpenVMS Galaxy, this meansC that you cannot run the two instances at different times. Also, the C SET TIME command affects both instances. Note that this may not be- 1 come evident until a number of hours have passed.   
 Console Ports    On a rack-mounted system: 0 COM1 (lower) is the console port for instance 0.0 COM2 (upper) is the console port for instance 1.  "                                  9        On a pedestal system: / COM1 (left) is the console port for instance 0. 0 COM2 (right) is the console port for instance 1.  D Unlike creating an OpenVMS Galaxy on an AlphaServer 8400 system, youD do not need additional hardware for the second console. COM2 is used for this purpose.    CPUs  ( CPU0 must be the primary for instance 0.( CPU1 must be the primary for instance 1.> CPUs 2 and 3 are optional secondary CPUs that can be migrated.   I/O Adapters   On a rack-mounted system: ; PCI Hose 0 (PCI0) belongs to instance 0 (upper 4 PCI slots) ; PCI Hose 1 (PCI1) belongs to instance 1 (lower 6 PCI slots)    On a pedestal system: : PCI Hose 0 (PCI0) belongs to instance 0 (right-hand slots)9 PCI Hose 1 (PCI1) belongs to instance 1 (left-hand slots)   3 Note that PCI0 contains an embedded ISA controller.    Storage Controllers   D You will need one storage controller (such as a KZPSA) per instance.C For each instance, this can go to a separate StorageWorks box or to + the same box for running as a SCSI cluster.   
 Network Cards   G If each instance needs network access, a network card (such as a DE600)  is required for each instance.  $ One card each goes in PCI0 and PCI1.   Memory Granularity Restrictions   . Private memory must start on a 64 MB boundary.  "                                 10       - Shared memory must start on an 8 MB boundary.   ) Instance 0 must have a multiple of 64 MB.   + AlphaServer 8400/GS140 Galaxy Configuration   G AlphaServer 8400 systems can support two or three instances of OpenVMS.    9 slots for:      I/O modules    Memory modules (    Processor modules (2 CPUs per module)    Console line for each partition:  $    Standard UART for first partition)    KFE72-DA for each additional partition    Example Configuration 1:" 2 partitions, 8 CPUs, 12 GB memory       9 slots allocated as follows:         Two I/O modules *       Four Processor modules (2 CPUs each)&       Three Memory modules (4 GB each)   Example Configuration 2:! 3 partitions, 8 CPUs, 8 GB memory        9 slots allocated as follows:         Three I/O modules *       Four Processor modules (2 CPUs each)$       Two Memory modules (4 GB each)  0 AlphaServer 8200/GS60/GS60E Galaxy Configuration  J AlphaServer 8200, GS60, and GS60E systems can support one possible OpenVMS* Galaxy configuration (two instances only).  "                                 11 _  _   5 slots for:  (    Two processor modules (two CPUs each)    Two I/O modules    One memory module  D The AlphaServer GS140, GS60, GS60E, 8400, and 8200 systems provide aE built-in UART for the first console line. Each additional console re-M quires a module set.  G The only hardware required for Galaxy operation that is not in the typ-tD ical AlphaServer GS140, GS60, GS60E, 8400, and 8200 configuration is the KFE72-DA console subsystem..  E The KFE72-DA module set is the set of EISA bus modules that establishe a console port.    XMI Bus Supporte  C The XMI bus is supported only on the first instance (Instance 0) ofs5 a Galaxy configuration in an AlphaServer 8400 system.g  E AlphaServer 8400 systems can support only one DWLM-AA XMI PIU subsys-eD tem cage for all XMI devices. Note that the DWLM-AA takes up consid-E erable space in the system because an I/O bulkhead is required on theeE back of the system to connect all XMI devices to the system. This al-f6 lows only two additional DWLPB PCI PIUs in the system.   EISA Bus Support  D The EISA bus is supported only on the first instance (instance 0) ofC a Galaxy configuration. Due to the design of all EISA options, they C must always be on instance 0 of the system. A KFE70 must be used inn= the first instance for any EISA devices in the Galaxy system.o  E All EISA devices must be on Instance 0. No EISA devices are supportedn) on any other instance in a Galaxy system.e  C A KFE72-DA installed in other instances provides console connection / only and cannot be used for other EISA devices.h   AlphaServer 4100 Configuration  "                                 12 m  r  C To create an OpenVMS Galaxy on an AlphaServer 4100 system, you muste> observe the following configuration and hardware requirements:   Two-Instance Maximum  C You can run a maximum of two instances of OpenVMS on an AlphaServerr 4100.n   Console Firmware  D You must have AlphaServer 4100 console firmware, which is located onE the Alpha Systems Firmware Update Version 5.4 CD-ROM that is includedf4 with the OpenVMS Alpha Version 7.2-1 CD-ROM package.   AlphaServer 4100 Clock  D An AlphaServer 4100 has one clock. For an OpenVMS Galaxy, this meansC that you cannot run the two instances at different times. Also, thefC SET TIME command affects both instances. Note that this may not be-c1 come evident until a number of hours have passed.e  
 Console Ports   0 COM1 (upper) is the console port for instance 0.0 COM2 (lower) is the console port for instance 1.  D Unlike creating an OpenVMS Galaxy on an AlphaServer 8400, you do notF need additional hardware for the second console. COM2 is used for this purpose.   CPUs  ( CPU0 must be the primary for instance 0.( CPU1 must be the primary for instance 1.> CPUs 2 and 3 are optional secondary CPUs that can be migrated.   I/O Adapters  E The four lower PCI slots belong to IOD0, which is the I/O adapter for  instance 0.uE The four upper PCI slots belong to IOD1, which is the I/O adapter fore instance 1.h  "                                 13        Storage Controllersu  D You will need two storage controllers (such as KZPSAs). These can goG to separate StorageWorks boxes or to the same box for running as a SCSIc3 cluster. One controller each goes in IOD0 and IOD1.   
 Network Cardsi  G If each instance needs network access, a network card (such as a DE500)e is required for each instance.  $ One card each goes in IOD0 and IOD1.   Physical Memory   C Because OpenVMS Galaxy on an AlphaServer 4100 does not support mem-sD ory holes, physical memory for an OpenVMS Galaxy environment must beC contiguous. To achieve this on an AlphaServer 4100, one of the fol-i lowing must be true:  @ o  All memory modules must be the same size (for example, 1 GB).  C o  If two sizes are present, only one module can be a smaller size. A    You must put the larger modules into the lower-numbered slots.n   LICENSING REQUIREMENTS  D The OpenVMS Galaxy Software Architecture on OpenVMS (OpenVMS Galaxy)D is a System Integrated Product (SIP): the OpenVMS Galaxy code is in-9 tegrated and delivered with the OpenVMS operating system.i  G The License Management Facility (LMF) Product Authorization Keys (PAKs)aF representing OpenVMS Galaxy licenses allow you to access and use Open-C VMS Galaxy software. For more information about the location of the E PAKs available with OpenVMS Alpha Version 7.3, see the Guide to Open-n VMS Version 7.3 CD-ROMs.  D The following list summarizes OpenVMS Galaxy licensing requirements:  ; o  One OpenVMS Operating System License for a Galaxy systemt  = o  One SMP Extension License for each CPU after the first CPUm  "                                 14    o  = o  One OpenVMS Galaxy License for each CPU in a Galaxy systemi  : o  No changes to how Compaq layered products are licensed:  %       One capacity license per systemb       One user license per use  B The following sections describe these requirements in more detail.    OpenVMS Operating System License  E When an AlphaServer system is configured as an OpenVMS Galaxy system,vD there are no changes in how a system is licensed for the OpenVMS op- erating system.   D One OpenVMS Base License is required for the Galaxy system, plus one7 SMP Extension License for each CPU after the first CPU.a   OpenVMS Galaxy License  E In order to create and run multiple instances, one OpenVMS Galaxy Li- 2 cense is required for each CPU in a Galaxy system.  E License rights for running a single-instance Galaxy on any Alpha sys-i- tem are provided by the OpenVMS Base License.u    OpenVMS Layered Products License  F Compaq software layered products on OpenVMS Galaxy configurations con-E tinue to use standard license types: Traditional, Concurrent Use, anda
 Personal Use.:  E o  One Traditional capacity License will continue to license the sys-uC    tem, regardless of the number of instances. The license is baseda.    on the system class of the hardware system.  F o  Concurrent Use Licenses will continue to license one concurrent use    of the product.  C o  Personal Use Licenses will continue to license one named user onh    the system.  # Clustering OpenVMS Galaxy Instances   "                                 15 R  t  E Instances in an OpenVMS Galaxy computing environment can be clusteredoG with other instances in a single system, with instances in other Galaxy E systems, or with non-Galaxy systems. Each type of clustering has dif-eF ferent licensing requirements, as described in the following sections.  ! Clustering within a Galaxy SystemO  F In an OpenVMS Galaxy computing environment, instances can be clusteredD with other instances within a Galaxy system. Clustered instances useF the shared-memory cluster interconnect to communicate with each other.  C The licensing and functionality for clustering within a Galaxy sys-p1 tem is provided under the OpenVMS Galaxy License.s  " Clustering Outside a Galaxy System  E Instances in an OpenVMS Galaxy computing environment can be clustered.E with instances in another OpenVMS Galaxy system or with cluster nodeshC in non-Galaxy systems. Instances clustered outside of a Galaxy sys-S* tem use traditional cluster interconnects.  F Each system that is clustered with another system must be licensed forD OpenVMS Cluster Software. Clustering outside the OpenVMS Galaxy sys-1 tem is not covered by the OpenVMS Galaxy License.n   DISTRIBUTION MEDIA  D The Compaq Galaxy Software Architecture on OpenVMS Alpha is suppliedC on the same distribution media as the OpenVMS operating system. For F more information, refer to the Compaq OpenVMS Operating System for VAX6 and Alpha Software Product Description (SPD 25.01.xx).                  "                                 16 n  n   ORDERING INFORMATION   Software Licenses.  + QL-66XAA-3B     Compaq Galaxy 1 CPU Licenseo  + QL-66XAA-3C     Compaq Galaxy 2 CPU License   + QL-66XAA-3D     Compaq Galaxy 4 CPU Licenseo  + QL-66XAA-3E     Compaq Galaxy 8 CPU Licenseh  , QL-66XAA-3F     Compaq Galaxy 16 CPU License  
 Documentationi  E The OpenVMS Alpha Partitioning and Galaxy Guide describes how to cre- G ate, manage, and use an OpenVMS Galaxy computing environment. This bookm	 includes:   9 o  OpenVMS Galaxy hardware and configuration requirementsC  C o  Procedures for creating OpenVMS Galaxy computing environments onnD    OpenVMS AlphaServer GS80, GS160, GS320, ES40, GS140, GS60, GS60E,    8400, 8200, and 4100 systems   C o  Complete details about how to use all of the OpenVMS Galaxy fea- D    tures and capabilities available in OpenVMS Alpha Versions 7.2-1,    7.2-1H1, and 7.3.  C The OpenVMS Alpha Partitioning and Galaxy Guide is available on thecE OpenVMS Version 7.3 documentation CD-ROM in HTML and PDF formats, andm; on the Version 7.2-1H1 documentation CD-ROM in HTML format.o   SOFTWARE LICENSING  C This software is furnished under the licensing provisions of CompaqcD Computer Corporation's Standard Terms and Conditions and the follow-D ing terms. In case of conflict the latter shall govern. For more in-C formation about Compaq's licensing terms and policies, contact yourr local Compaq office.  "                                 17    v  D License units for OpenVMS Galaxy are allocated on a CPU-capacity ba-E sis. An OpenVMS Galaxy license is required for each CPU within a sys-  tem.  # License Management Facility Supporto  C This system integrated product supports the OpenVMS License Manage-a ment Facility.  E For more information on the License Management Facility, refer to theiD OpenVMS Operating System for VAX and Alpha Software Product Descrip-C tion (SPD 25.01.xx), or the appropriate operating system documenta- 	 tion set.a   SOFTWARE PRODUCT SERVICESn  D A variety of service options are available from Compaq. For more in-, formation, contact your local Compaq office.   SOFTWARE WARRANTY   F Warranty for this software product is provided by Compaq with the pur-F chase of a license for the product as defined in the Software Warranty Addendum of this SPD.y  D The previous information is valid at time of release. Please contact= your local Compaq office for the most up-to-date information.   "  2001 Compaq Computer Corporation  E AlphaServer, Compaq, StorageWorks, VAX, VMS, and the Compaq logo Reg-w, istered in U.S. Patent and Trademark Office.  E OpenVMS is a trademark of Compaq Information Technologies Group, L.P.m) in the United States and other countries.   C Microsoft, Windows, and Windows NT are trademarks of Microsoft Cor- 2 poration in the United States and other countries.    "                                 18 a  f  E Motif is a trademark of The Open Group in the United States and other-
 countries.  G All other product names mentioned herein may be the trademarks of their  respective companies.c  F Confidential computer software. Valid license from Compaq required forG possession, use or copying. Consistent with FAR 12.211 and 12.212, Com-oE mercial Computer Software, Computer Software Documentation, and Tech- C nical Data for Commercial Items are licensed to the U.S. Governmentr+ under vendor's standard commercial license.   E Compaq shall not be liable for technical or editorial errors or omis-TD sions contained herein. The information in this document is providedC "as is" without warranty of any kind and is subject to change with-oC out notice. The warranties for Compaq products are set forth in thecE express limited warranty statements accompanying such products. Noth-aF ing herein should be construed as constituting an additional warranty.                                            "                                 19    d                                                                                  "                                 20