MrMeeb/snmp_mib_archive
1
0
Fork 0
mirror of https://github.com/hsnodgrass/snmp_mib_archive.git synced 2025-04-18 16:32:45 +00:00
Code Issues Actions Packages Projects Releases Wiki Activity
snmp_mib_archive/readme.txt
Heston Snodgrass 89bf4b016e initial commit
2016-12-15 15:03:18 -07:00

731 lines
29 KiB
Plaintext
Executable File
Raw Blame History

Insight Management MIB
README.TXT
This document contains information on how to use the files provided on
the Management CD in the \TOOLKIT\MIBS directory. It is intended to
give the reader experienced in SNMP management products a summary of
the steps required to start using the Insight MIB as soon as possible.
For more complete information, please refer to the Integrating Insight
Manager with Enterprise Management Platforms Technote or the
Integrating Insight Manager with ManageWise Technote. These
and other Technotes are available located in the \DOCS\ENG directory
and available on the HP World Wide Web server at http://www.hp.com. If
you wish to get a bound hardcopy version of any of the Technotes,
contact your Authorized HP Reseller.
NOTE: The files described in this document and furnished on this CD are
provided under a license agreement. They may be used or copied only in
accordance with the terms of the agreement.
TABLE OF CONTENTS
1.0 Introduction to the Insight Management MIB
2.0 Insight Management Information Base Organization
3.0 Concise MIB format
3.1 Groups
3.2 Data structures
3.2.1 Scalar Data Items
3.2.1.1 Basic Scalar Data Items
3.2.1.2 Defined Scalar Data Items
4.2.1.3 Access of Data Items
3.2.1.4 Status of Data Items
3.2.1.5 Description of Data Items
3.2.1.6 Scalar Item Definition Example
3.2.2 Table Data Items
3.2.2.1 Table Status
3.2.2.2 Table Index
3.2.2.3 Table Definition Example
4.0 Trap definitions
1.0 INTRODUCTION TO THE INSIGHT MANAGEMENT MIB
This directory contains all the files necessary for integrating the
Insight Management Information Base (MIB) into SNMP network
management applications. HP provides these files for inclusion into
SNMP network management applications such as SunNet Manager from
SunConnect, HP OpenView Network Node Manager from Hewlett Packard,
NetView for AIX from IBM and ManageWise from Novell. These files allow
the user to integrate server management into an existing work group
or enterprise management environment. For an in-depth tool to monitor
your ProLiant servers, consider using Insight Manager 7, which provides
a comprehensive management interface to the complete Insight MIB.
Insight Manager 7 is an easy to use application based on the Microsoft
Windows environment.
2.0 INSIGHT MANAGEMENT INFORMATION BASE ORGANIZATION
The Insight Management MIB is a modular definition that follows IETF
RFC 1212 for manageable objects and RFC 1215 for traps. Each piece
of information is an object and related objects represent a group. The
information in the MIB represents important device hardware and device
software information. For example, the MIB includes server and
component device information about the operation, performance, security
and configuration of the devices.
The Insight MIB is modular. The following table provides information
about the different files that compose the Insight Management MIB.
MIB File Description
============ =====================================================
CPQSTDEQ.MIB Standard PC Server Equipment information
CPQSINFO.MIB ProLiant Specific PC Server information
CPQHOST.MIB Host Server Operating System information
CPQIDA.MIB Intelligent Drive Array information
CPQIDE.MIB IDE information
CPQSCSI.MIB SCSI Device information
CPQSTSYS.MIB Storage Systems information
CPQHLTH.MIB Server Health information
CPQTHRSH.MIB Settable Threshold information
CPQUPS.MIB Uninterruptible Power Supply (UPS) information
CPQRECOV.MIB Recovery Server information
CPQSRVMN.MIB Server Manager/R information
CPQSM2.MIB Remote Insight and iLO information
CPQCLUS.MIB Cluster information
CPQFCA.MIB Fibre Array information
CPQSTAT.MIB External Status information
CPQNIC.MIB Network Interface Card information
CPQAPLI.MIB Server Appliance information
CPQCR.MIB CR3500 RAID Controller information
SRVCLU.MIB Common Cluster Management information
SRVNTC.MIB Cluster Management MIB version information
ETHER.MIB RFC 1398 Ethernet NIC information
TOKEN.MIB RFC 1231 Token Ring NIC information
The Insight MIBs represent an extension to the standard MIB
information already defined in several standard MIB documents (for
example, RFC 1213 or RFC 1271). These extensions offer
additional information that will be available to any SNMP management
application supporting the Insight MIBs.
The Insight MIBs are defined to be modular. A series of MIBs address
various aspects of the computer system. A standard equipment MIB provides
information about the standard equipment of any Industry Standard PC
(ISA or EISA). A ProLiant system specific MIB provides information about
ProLiant specific extensions to the standard PC information. Other
MIBs provide information about specific sub-systems developed
by HP; for example Drive Array or Server Health sub-systems.
Using the Insight MIBs in no way affects the standard information already
available with SNMP or the access method for obtaining standard
information.
The Insight MIBs conform to the Concise MIB format (see section 3.0)
and are suitable for use by most MIB compilers used to assimilate MIB
documents. The main portion of the tree with respect to the HP
instrumented management information is:
(root)
|-CCITT(0)
|-ISO(1)
| |-Org(3)
| | |-DOD(6)
| | | |-Internet(1)
| | | | |-Directory(1)
| | | | |-Mgnt(2)
| | | | | |-MIB2(1)
| | | | |-Experimental(3)
| | | | |-Private(4)
| | | | | |-Enterprises(1)
| | | | | | |-Compaq(232)
| | | | | | | |-cpqStdEquipment(1)
| | | | | | | |-cpqSystemInfo(2)
| | | | | | | |-cpqDriveArray(3)
| | | | | | | |-cpqServerManager(4)
| | | | | | | |-cpqScsi(5)
| | | | | | | |-cpqHealth(6)
| | | | | | | |-RESERVED(7)
| | | | | | | |-cpqSsStorageSys(8)
| | | | | | | |-cpqSm2(9)
| | | | | | | |-cpqThresholdMgmt(10)
| | | | | | | |-cpqHostOS(11)
| | | | | | | |-cpqUps(12)
| | | | | | | |-cpqRecovery(13)
| | | | | | | |-cpqIde(14)
| | | | | | | |-cpqCluster(15)
| | | | | | | |-cpqFibreArray(16)
| | | | | | | |-cpqExternalMgmt(17)
| | | | | | | |-cpqNic(18)
| | | | | | | |-cpqWinOsMgmt(19)
| | | | | | | |-cpqApplianceMgmt(21)
| | | | | | | |-cpqRackInfo(22)
Every piece of information is referred to by its full name so each piece
of information can be unambiguously specified. Full names are commonly
given in dotted decimal notation. Dotted decimal notation specifies all
the branch numbers, separated by periods, needed to reach the particular
item. For example the number 1.3.6.1.4.1.232.1 stands for the
Standard Equipment MIB. All information in the Standard Equipment
MIB will start with this prefix and then continue on to distinguish
different pieces of information within the MIB.
The name of each branch is specified in MIB documents. The number series,
in parentheses after the name, is what is sent over the network in an SNMP
packet when referring to a specific item in the tree. Sending a series of
numbers specifying a tree location in a packet rather than a text
description of the item as a name lessens network traffic. However,
this protocol requires that both ends involved in the protocol understand
the meanings of these code numbers and the structure of the information.
This scheme requires a precise grammar to document the MIB structure to
avoid confusion between the agent and the management station. The grammar
typically used is called the Concise MIB format and is defined in RFC 1212.
Further detail about the groups and objects provided by the HP
Insight Management Agents is available in the comments within each MIB
file.
3.0 CONCISE MIB FORMAT
A few notes about the Concise MIB format should allow a reader to
understand a MIB document without learning the full grammar.
A comment is started by two consecutive dashes. All characters until
the end of the line are ignored by a program processing the MIB.
Comments are used to provide information to a reader.
A MIB starts with a line that states the name of the MIB being defined.
This is typically followed by an import statement. An import statement
allows the MIB writer to specify information from other well known MIBs
that are referred to in this MIB.
The term END is used to signify the end of the MIB data definitions.
For example:
CPQSTDEQ-MIB DEFINITIONS ::= BEGIN
IMPORTS
enterprises FROM RFC1155-SMI
DisplayString FROM RFC1213-MIB
OBJECT-TYPE FROM RFC-1212;
-- This is a comment.
-- Typically, structures for organizing managed items are defined
-- here, followed by the definitions and descriptions of the managed
-- items.
END
This example starts a MIB by the name of CPQSTDEQ-MIB. This MIB
will use the term: enterprises as it is defined in RFC 1155,
DisplayString as it is defined in RFC 1213, and OBJECT-TYPE as it is
defined in RFC 1212. Three comment lines follow to show where managed
items would be defined in a real MIB. Then the END statement terminates
the MIB definition.
3.1 GROUPS
A group definition specifies a name for a branch of the tree that contains
sub-groups or specific pieces of information. Groups are used to organize
related pieces of information. A group is defined by stating a name for
the group and showing how it fits into the tree. To show how it fits into
the tree the branch it will be placed under is named and the unique
sub-branch number for this group is given.
Typically, all group definitions are placed immediately following the
IMPORTS statement. Some examples of group definitions are shown below.
compaq OBJECT IDENTIFIER ::= { enterprises 232 }
cpqStdEquipment OBJECT IDENTIFIER ::= { compaq 1 }
cpqSeMibRev OBJECT IDENTIFIER ::= { cpqStdEquipment 1 }
cpqSeComponent OBJECT IDENTIFIER ::= { cpqStdEquipment 2 }
cpqSeInterface OBJECT IDENTIFIER ::= { cpqSeComponent 1 }
cpqSeProcessor OBJECT IDENTIFIER ::= { cpqSeComponent 2 }
cpqSeMemory OBJECT IDENTIFIER ::= { cpqSeComponent 3 }
cpqSeIsaCmos OBJECT IDENTIFIER ::= { cpqSeComponent 4 }
cpqSeEisaNvram OBJECT IDENTIFIER ::= { cpqSeComponent 5 }
cpqSeRom OBJECT IDENTIFIER ::= { cpqSeComponent 6 }
cpqSeKeyboard OBJECT IDENTIFIER ::= { cpqSeComponent 7 }
cpqSeVideo OBJECT IDENTIFIER ::= { cpqSeComponent 8 }
cpqSeSerialPort OBJECT IDENTIFIER ::= { cpqSeComponent 9 }
cpqSeParallelPort OBJECT IDENTIFIER ::= { cpqSeComponent 10 }
cpqSeFloppyDisk OBJECT IDENTIFIER ::= { cpqSeComponent 11 }
cpqSeFixedDisk OBJECT IDENTIFIER ::= { cpqSeComponent 12 }
The group definitions above can be visualized as the following tree
structure:
(Enterprises)
|-Compaq(232)
| |-cpqStdEquipment(1)
| | |-cpqSeMibRev(1)
| | |-cpqSeComponent(2)
| | |-cpqSeInterface(1)
| | |-cpqSeProcessor(2)
| | |-cpqSeMemory(3)
| | |-cpqSeIsaCmos(4)
| | |-cpqSeEisaNvram(5)
| | |-cpqSeRom(6)
| | |-cpqSeKeyboard(7)
| | |-cpqSeVideo(8)
| | |-cpqSeSerialPort(9)
| | |-cpqSeParrallelPort(10)
| | |-cpqSeFloppyDiskette(11)
| | |-cpqSeFixedDisk(12)
A definition for enterprises is not needed here since enterprises has
been defined elsewhere and imported. Anyone wishing to see its
definition can refer to RFC 1155.
Group numbers do not need to be consecutive. A particular Agent
implementation may not support some of the groups.
Some groups (such as cpqSeComponent) are intended for better organization.
These groups have sub-groups below them, and do not directly reference
any data (the data is in the sub-groups). These organizational groups will
typically be given only a brief description since their role should be
easily understood by the description of the sub-groups. When a group
contains information immediately below it, all the items in the group will
be described and defined.
3.2 DATA STRUCTURES
There are two basic types of data: scalar items and tables.
A scalar item is a single piece of information that is in a group. An
example of a scalar is the total memory in a server. This offers
unambiguous information without further qualifications.
A table is a structure for organizing data that requires more information
to uniquely identify a single data item within a group of similar items.
An example of an item that is best organized in a table is an EISA board
ID. The EISA board information is organized in the cpqSeEisaSlotTable, in
the CPQSTDEQ.MIB file. The Board ID is only one piece of information in
that table.
Each item defined in the MIB (scalar or part of a table) has a
description which explains what the item means and can help interpret
the value of the item.
3.2.1 SCALAR DATA ITEMS
The name of a data item, by convention, starts with a lower case letter.
A SYNTAX clause specifies the type of information the item contains.
There are two types, basic and defined types.
3.2.1.1 BASIC SCALAR DATA ITEMS
Basic types are defined as part of the SNMP grammar and are represented
in all capital letters. Examples include INTEGER and OCTET STRING.
The INTEGER type specifies that the value of the item should be
interpreted as a number. In some cases the word INTEGER will be
followed by a range qualifier that restricts the possible values.
In other cases the word INTEGER will be followed by an enumeration
list that explicitly names the possible values and the meaning of
each possible value.
The OCTET STRING type specifies that the value of the item should be
interpreted as a string of octets (bytes). The value of any particular
octet (byte) within the string may be any value from zero to 255. A
size qualifier may be given after the term OCTET STRING to limit the
possible size (in bytes) of the value.
3.2.1.2 DEFINED SCALAR DATA ITEMS
Defined types are defined by macros that refer to the basic types and
start with a capital letter. Examples include Counter and DisplayString.
A Counter is an INTEGER that has an implied range of zero to
4,294,967,295 (a hexadecimal value of FFFFFFFF). When a Counter equals
the maximum value and is incremented again it will return to zero.
A DisplayString is an OCTET STRING where each octet is restricted to
be a printable ASCII character. Like the OCTET STRING from which this
is derived, it may have a size qualifier.
3.2.1.3 ACCESS OF DATA ITEMS
The ACCESS clause specifies the ways this item may be used.
The ACCESS may be read-only, read-write, or not-accessible. Read-only
means that the value of this item may be retrieved by a management
application, but may not be altered. Read-write means this item may
be read and/or altered by a management application. Not-accessible
is given as the access for organizational constructs that do not
represent data items. Not-accessible is only used for table features
and should not be used for a scalar item.
The ACCESS clause shows the actions the agent may support for the item.
In practice this may be limited further by features or limitations of a
particular agent implementation.
3.2.1.4 STATUS OF DATA ITEMS
The STATUS clause specifies whether an agent is required to support this
item if the agent supports this group. A status of mandatory means that
this item will always be present if this group is supported. A status of
optional means that a particular agent implementation has the option to
support this item. A status of deprecated indicates that this item will
not be supported by future agents. Deprecated objects stay in the MIB to
maintain backward compatibility.
3.2.1.5 DESCRIPTION OF DATA ITEMS
The DESCRIPTION clause contains a double quote delimited text description
of the item. This description should give enough information for a
reader to understand the significance of the information this item
provides.
3.2.1.6 SCALAR ITEM DEFINITION EXAMPLE
The item definition ends by specifying how the item fits into the MIB
tree. The group the item belongs to is given followed by the unique
branch number within the group for this item.
Scalar item example:
cpqSeMibRevMajor OBJECT-TYPE
SYNTAX INTEGER (1..65535)
ACCESS read-only
STATUS mandatory
DESCRIPTION
"The Major Revision level of the MIB.
A change in the major revision level represents a major change
in the architecture of the MIB. A change in the major revision
level may indicate a significant change in the information
supported and/or the meaning of the supported information,
correct interpretation of data may require a MIB document with
the same major revision level."
::= { cpqSeMibRev 1 }
This example defines a scalar item named cpqSeMibRevMajor. This item is
an INTEGER that may be read, but may not be changed by a management
station. The cpqSeMibRevMajor item must be present if the group it
belongs to (the cpqSeMibRev group) is supported. The cpqSeMibRevMajor
item has a description to help a reader interpret the meaning of
the value assigned to this item. The cpqSeMibRevMajor item is the member
of the cpqSeMibRev group assigned the unique number one within the group.
3.2.2 TABLE DATA ITEMS
Tables introduce the concept of constructed types. There are two
operators that allow for organization of the standard types, the
SEQUENCE operator and the SEQUENCE OF operator. A table uses both of
these operators.
The SEQUENCE operator allows the definition of a new type that consists
of several standard types in a specific order. This is very similar
to the concept of a structure or a record found in most programming
languages.
The SEQUENCE OF operator allows the definition of a list of zero or
more of the same type of elements. The number of elements is not
specified, but a means of uniquely identifying each element is given
by providing an indexing scheme. This is very similar to the concept
of a dynamic array found in most programming languages. A table entry
is defined a SEQUENCE. A table is defined as a SEQUENCE OF the table
entry type.
Table entry variables are defined after they are referenced in a table
definition.
The Concise MIB format is case sensitive and there are several
conventions on the use of upper and lower case letters. The name
used for the entry type and the variable of that type differ only by the
case of the first letter. It is conventional to start types with an
upper case letter and items (the variables) with a lower case letter.
3.2.2.1 TABLE STATUS
The STATUS of the table and the table entry is not-accessible. There is
no data that is uniquely referred to by the name of the table or entry so
the concept of reading (or writing) the value of a table or entry is
meaningless. Tables and entries are useful for organizing and defining a
MIB, but SNMP commands only allow the manipulation of simple items
(scalars and the items that are part of the SEQUENCE in a table entry).
3.2.2.2 TABLE INDEX
The INDEX clause specifies the items that are used to uniquely identify
an element in the table. An index may simply be a unique number assigned
to an entry that has no specific meaning except to the agent or it may
have some intrinsic meaning.
3.2.2.3 TABLE DEFINITION EXAMPLE
Here is an example of a table definition. It defines the table as
a SEQUENCE OF the CpqSeCpuEntry type that will be defined below.
cpqSeCpuTable OBJECT-TYPE
SYNTAX SEQUENCE OF CpqSeCpuEntry
ACCESS not-accessible
STATUS mandatory
DESCRIPTION
"A list of the CPUs (processors) in the system.
The main processor (if such a concept is valid for this machine)
should be the first entry in the table."
::= { cpqSeProcessor 1 }
Here is an example of an entry definition. It defines an item of the
cpqSeCpuEntry type. It also describes the field used to uniquely
identify entries in the table. No two table entries will have the
same values for the cpqSeCpuUnitIndex field.
cpqSeCpuEntry OBJECT-TYPE
SYNTAX CpqSeCpuEntry
ACCESS not-accessible
STATUS mandatory
DESCRIPTION
"A description of a CPU (processor) in the system."
INDEX { cpqSeCpuUnitIndex }
::= { cpqSeCpuTable 1 }
CpqSeCpuEntry ::= SEQUENCE {
cpqSeCpuUnitIndex INTEGER,
cpqSeCpuSlot INTEGER,
cpqSeCpuName DisplayString,
cpqSeCpuSpeed INTEGER,
cpqSeCpuStep INTEGER,
cpqSeCpuStatus INTEGER
}
The following four definitions are the four scalar items that form the
fields of the CpqSeCpuEntry type.
cpqSeCpuUnitIndex OBJECT-TYPE
SYNTAX INTEGER (0..65535)
ACCESS read-only
STATUS mandatory
DESCRIPTION
"This is a number that uniquely specifies a processor unit.
A processing unit may be a set of processing chips that are
on the same board or for other reasons work together as a unit.
The main processor unit (if such a concept is valid for this
machine) will always have the lowest (first) index."
::= { cpqSeCpuEntry 1 }
cpqSeCpuSlot OBJECT-TYPE
SYNTAX INTEGER (0..255)
ACCESS read-only
STATUS mandatory
DESCRIPTION
"This value represents this processor's slot.
If the slot cannot be determined the value of zero (0) will be
returned."
::= { cpqSeCpuEntry 2 }
cpqSeCpuName OBJECT-TYPE
SYNTAX DisplayString (SIZE (0..255))
ACCESS read-only
STATUS mandatory
DESCRIPTION
"The name of this processor.
For example:
80386"
::= { cpqSeCpuEntry 3 }
cpqSeCpuSpeed OBJECT-TYPE
SYNTAX INTEGER (0..65535)
ACCESS read-only
STATUS mandatory
DESCRIPTION
"The clock speed (in megahertz) of this processor.
Zero will be returned if this value is not available."
::= { cpqSeCpuEntry 4 }
cpqSeCpuStep OBJECT-TYPE
SYNTAX INTEGER (0..65535)
ACCESS read-only
STATUS mandatory
DESCRIPTION
"The step of the processor.
This will be zero (0) if the step cannot be determined."
::= { cpqSeCpuEntry 5 }
cpqSeCpuStatus OBJECT-TYPE
SYNTAX INTEGER {
unknown(1),
ok(2),
degraded(3),
failed(4)
}
ACCESS read-only
STATUS mandatory
DESCRIPTION
"The status of the processor."
::= { cpqSeCpuEntry 6 }
The previous definitions describe a tree structure as follows:
(cpqSeProcessor)
|-cpqSeCpuTable(1)
|-cpqSeCpuEntry1
|-cpqSeCpuEntry2
|- .
|- .
|-cpqSeCpuEntryN
Each processor entry is organized as follows:
cpqSeCpuEntryN
|-cpqSeCpuUnitIndex(1)
|-cpqSeCpuSlot(2)
|-cpqSeCpuName(3)
|-cpqSeCpuSpeed(4)
|-cpqSeCpuStep(5)
|-cpqSeCpuStatus(6)
As an example, to get the clock speed of a Server's second
processor, a management application would request the object with
an ASN.1 notation of 1.3.6.1.4.1.232.1.2.2.1.4.2. The final 2 is
the cpqSeCpuUnitIndex value for the second processor.
4.0 TRAP DEFINITIONS
A MIB may also contain trap definitions. A trap is a notification sent
by the SNMP agent to a management station. The trap is sent to inform
the management station about an event that has occurred on the managed
system. Traps may also be referred to as alerts or alarms.
The trap definition begins with the name of the trap followed by the
term TRAP-TYPE.
An ENTERPRISE clause follows to indicate the MIB in which this trap is
defined.
An optional VARIABLES clause may be included to specify additional
information that will be sent in the trap. The additional information
will be items defined in the MIB shown in the ENTERPRISE clause. When
a variable is included in a trap, both its name and its value are sent
with the trap. If a variable is a data item within a table, the name
will contain the index field(s). This saves the trouble of sending
along the index fields explicitly as additional variables.
A DESCRIPTION clause will follow explaining the significance of the trap
and the conditions that would cause it to be sent.
Finally, the trap is given a number to identify it. This number will be
unique within the scope of the ENTERPRISE. Both the enterprise name and
the trap number are used by the management station to uniquely identify
the trap received.
Trap example:
cpqDa2PhyDrvStatusChange TRAP-TYPE
ENTERPRISE compaq
VARIABLES { cpqDaPhyDrvStatus, cpqDaPhyDrvBusNumber }
DESCRIPTION
"Physical Drive Status Change.
This trap signifies that the Insight Agent has detected
a change in the status of a Drive Array physical
drive. The variable cpaDaPhyDrvStatus indicates the
current physical drive status. The variable
cpqDaPhyDrvBusNumber indicates the SCSI bus number
associated with this drive."
--#TYPE "Physical Drive Status Change"
--#SUMMARY "Status is now %d for a physical drive on bus %d."
--#ARGUMENTS {0,1}
--#TIMEINDEX 99
::= 3003
This example defines a trap named cpqDa2PhyDrvStatusChange. This is trap
number 3003 in the Compaq enterprise. This trap is sent by the agent
responsible for the CPQIDA MIB. The current value of the
cpqDaPhyDrvStatus and the cpqDaPhyDrvBusNumber items is also included in the
trap packet.
The comment section within the trap defines additional information, used
by Novell's NetWare Management Services console, to display upon receiving
a Compaq enterprise trap. In this example, the comments describe the
trap type (--#TYPE "Physical Drive Status Change"), a summary (--#SUMMARY
"Status is now %d for a physical drive on bus %d."), the arguments to
display within the summary statement (--#ARGUMENTS {0,1}), and an
indication about the time parameter to use (--#TIMEINDEX 99).
Note: The additional comments in the trap section specific for NetWare
Management Services does not impact the functionality of how any SNMP
compliant management console, such as SunConnect's SunNet Manager or
HP's OpenView, interacts with traps generated by the Insight Agents.
Traps are defined in the last section of the MIBs. Refer to the actual
trap definitions for more information about the traps generated by the
Insight Management Agents.
______________________________________________________________________
Copyright 1992,2005 Hewlett-Packard Development Company, L.P.
Hewlett-Packard Company shall not be liable for technical or
editorial errors or omissions contained herein. The information in
this document is provided "as is" without warranty of any kind and
is subject to change without notice. The warranties for HP products
are set forth in the express limited warranty statements
accompanying such products. Nothing herein should be construed as
constituting an additional warranty.
Confidential computer software. Valid license from HP required for
possession, use or copying. Consistent with FAR 12.211 and 12.212,
Commercial Computer Software, Computer Software Documentation, and
Technical Data for Commercial Items are licensed to the U.S.
Government under vendor's standard commercial license.
NetWare is a trademarked product of Novell, Inc.
Windows is a trademark of Microsoft Corporation.
Reference in New Issue View Git Blame Copy Permalink