NAME

      mxnode - Systems Insight Manager system file format


SYNOPSIS

      mxnode


DESCRIPTION

      The mxnode command supports reading and writing node information in
      the eXtensible Markup Language (XML) format. You may use this
      capability to add, modify, remove or list multiple nodes in the
      Systems Insight Manager environment.  Each file may contain the
      definitions of one or more nodes.

    Document Type Definition
      The Document Type Definition (DTD) file defines the constraints for an
      XML file. These constraints include the valid element tags,
      attributes, and the cardinality of elements in an XML file. The user
      DTD file is named nodelist.dtd and is included in the following
      paragraph. Note that due to man page formatting, the DTD contents may
      not appear the same as in the file.


--- BEGIN NODELIST.DTD FILE SOURCE ---

      <?xml version="1.0" encoding="UTF-8" ?>

      <!-- READ THIS FIRST! This file is intentionally formatted with a
	   right margin set at 70. This allows the DTD file to be pasted
	   directly into the mxnode(4) man page file. Please respect this
	   constraint when editing this file. After edits are final for
	   a given release, please paste the final DTD version in the
	   mxnode(4) man page to keep the documentation current.
      -->

      <!-- The node-list element consists of zero or more node elements.
      -->
      <!ELEMENT node-list ( node* ) >

      <!-- The node element consists zero or more sw-attribute elements,
	   zero or more hw-attribute elements, or zero or more credentials or a
	   combination of all of these elements.
      -->
      <!ELEMENT node ( sw-attribute |
		       hw-attribute |
		       credential |
		       managementpath-list )* >

      <!-- The node element has the following attributes:
	   The name attribute specifies the node name and is optional.
	   The host-name attribute specifies the host name and is optional.
	   The monitoring attribute specifies whether discover or
	   identification of the node is suspended/resumed and is optional.
	   The guid attribute specifies the node GUID and is optional.
      -->
      <!ATTLIST node name	 CDATA	 #IMPLIED
		     host-name	 CDATA	 #IMPLIED
		     monitoring	 CDATA	 #IMPLIED
		     guid	 NMTOKEN #IMPLIED >

      <!-- The sw-attribute element specifies a list of software attributes
	   for a node. A software attribute is specified as a name/value
	   pair. In an sw-attribute element, the software attribute name
	   portion is specified using the element's attribute called "name",
	   and the software attribute value portion is specified as the
	   PCDATA of the element.
      -->
      <!ELEMENT sw-attribute (#PCDATA) >
      <!ATTLIST sw-attribute name CDATA #REQUIRED >

      <!-- The hw-attribute element specifies a list of hardware attributes
	   for a node. A hardware attribute is specified as a name/value
	   pair. In a hw-attribute element, the hardware attribute name
	   portion is specified using the element's attribute called "name",
	   and the hardware attribute value portion is specified as the
	   PCDATA of the element.
      -->
      <!ELEMENT hw-attribute (#PCDATA) >
      <!ATTLIST hw-attribute name CDATA #REQUIRED >

      <!-- The credential element specifies the credential for a specified protocol.
	   The credential element is empty and is specified with the defined attributes.
	   The protocol attribute is required and specifies the credentialed protocol,
	   such as wbem or snmp.
	   The user name attribute is optional and associates a user name with the protocol.
	   The password attribute is optional and is associated with the user name.
      -->
      <!ELEMENT credential EMPTY >
      <!ATTLIST credential protocol CDATA #REQUIRED
			   username CDATA #IMPLIED
			   password CDATA #IMPLIED >


      <!-- ************************************************** -->
      <!--	   ManagementPath definitions below	      -->
      <!-- ************************************************** -->

      <!-- The managementpath-list element consists of zero or more managementpath elements -->
      <!ELEMENT managementpath-list ( managementpath )* >
      <!ATTLIST managementpath-list totalmpos CDATA #IMPLIED >

      <!-- The managementpath element consists of zero or more of the following elements -->
      <!ELEMENT managementpath ( catagoryname |
				 mroluid |
				 profilelist |
				 namespace |
				 cimcspath |
				 associatedmaoguid |
				 associatedmaoluid |
				 managementagent |
				 nodeguid |
				 nodename |
				 proxytype |
				 portnumber |
				 ipaddress |
				 protocol |
				 maoluid |
				 interopnamespace |
				 functionalprofilelist )* >

      <!-- The managementpath element may have the following attributes -->
      <!-- The mpotype attribute is required for the managementpath element -->
      <!-- Its value can be either "MRO" or "MAO" -->
      <!-- The maotype attribute is required for the managementpath element -->
      <!-- Its value can be: "WBEM_CIMOM", "WMI_MAPPER" -->
      <!-- The location attribute is optional for the managementpath element -->
      <!-- Its vaue can be either "OnThisNode" or "OnOtherNode" -->
      <!ATTLIST managementpath mpotype	  CDATA #IMPLIED
			       mpoversion CDATA #IMPLIED
			       maotype	  CDATA #IMPLIED
			       location	  CDATA #IMPLIED >

      <!--  -->
      <!ELEMENT catagoryname (#PCDATA) >

      <!--  -->
      <!ELEMENT mroluid (#PCDATA) >

      <!-- The profilelist element applies to both the managementpath and managementagent elements -->
      <!ELEMENT profilelist ( profilename )* >

      <!--  -->
      <!ELEMENT profilename (#PCDATA) >

      <!--  -->
      <!ELEMENT namespace (#PCDATA) >

      <!--  -->
      <!ELEMENT cimcspath (#PCDATA) >

      <!--  -->
      <!ELEMENT associatedmaoguid (#PCDATA) >

      <!--  -->
      <!ELEMENT associatedmaoluid (#PCDATA) >

      <!-- The managementagent element consists of zero or more of the following elements -->
      <!ELEMENT managementagent ( nodeguid |
				  nodename |
				  proxytype |
				  portnumber |
				  ipaddress |
				  protocol |
				  maoluid |
				  interopnamespace |
				  profilelist |
				  functionalprofilelist )* >

      <!-- The managementagent element may have the following attributes -->
      <!-- The mpotype attribute is required for the managementpath element -->
      <!-- Its vaue can be either "MRO" or "MAO" -->
      <!-- The maotype attribute is required for the managementpath element -->
      <!-- Its value can be: "WBEM_CIMOM", "WMI_MAPPER" -->
      <!-- The location attribute is optional for the managementpath element -->
      <!-- Its vaue can be either "OnThisNode" or "OnOtherNode" -->
      <!ATTLIST managementagent mpotype	   CDATA #IMPLIED
				mpoversion CDATA #IMPLIED
				maotype	   CDATA #IMPLIED
				location   CDATA #IMPLIED >

      <!--  -->
      <!ELEMENT nodeguid (#PCDATA) >

      <!--  -->
      <!ELEMENT nodename (#PCDATA) >

      <!--  -->
      <!ELEMENT proxytype (#PCDATA) >

      <!--  -->
      <!ELEMENT portnumber (#PCDATA) >

      <!--  -->
      <!ELEMENT ipaddress (#PCDATA) >

      <!--  -->
      <!ELEMENT protocol (#PCDATA) >

      <!--  -->
      <!ELEMENT maoluid (#PCDATA) >

      <!--  -->
      <!ELEMENT interopnamespace (#PCDATA) >

      <!--  -->
      <!ELEMENT functionalprofilelist ( profilename )* >


--- END NODELIST.DTD FILE SOURCE ---

    Elements
      As defined in the DTD, the node XML file may contain the following
      elements.

      The first line of a node XML file should be in the following format:

      <?xml version="1.0" encoding="encoding-value" ?>

      where the user substitutes a recognized encoding value for the
      encoding-value parameter.	 The recognized encoding values may be found
      at the following web site:

      http://www.iana.org/assignments/character-sets

      If no XML header line is specified, the system defaults encoding to
      "UTF-8".

      The "node-list" element must appear once in a node XML file and wraps
      the list of node information. The "node-list" element may contain zero
      or more "node" elements. Note that if the "node-list" element contains
      no "node" elements, the associated  mxnode command will have no
      effect.

      The "node" element supports four attributes.

      (1) The "name" attribute is optional and specifies the node name.

      (2) The "host-name" attribute is optional and specifies the network
      hostname.

      (3) The "guid" attribute is optional and specifies the globally unique
      identifier of the node. Because this value is assigned by the system,
      the system ignores this attribute when adding a new node.

      (4) The "monitoring" attribute allows the user to control the
      monitoring of the system/node by Systems Insight Manager.	 In normal
      operation, the system is continously monitored (includes Discovery and
      Identification) by Systems Insight Manager.  Monitoring of the system
      may be suspended for one of several pre-defined time duration values,
      or monitoring may be suspended indefinately.  If the 'monitoring'
      attribute is not included in the XML file for a '-m -f' command, then
      the current monitoring state for the node is left as is.

      As reference, this same 'monitoring' feature may be modified through
      the "Suspend/Resume Monitoring" page of the Systems Insight Manager
      GUI.

      Valid values for the 'monitoring' attribute are as follows.


      monitoring="resume" Do not suspend monitoring
      monitoring="suspend.5m" Suspend monitoring for 5 minutes
      monitoring="suspend.15m" Suspend monitoring for 15 minutes
      monitoring="suspend.1h" Suspend monitoring for 1 hour
      monitoring="suspend.1d" Suspend monitoring for 1 day
      monitoring="suspend" Suspend monitoring indefinitely

      The "node" element may contain a number of optional elements. The
      "sw-attribute", "hw-attribute" and "credential" elements may appear
      zero or more times.

      The "sw-attribute" element specifies a software-related node
      attribute, such as the operating system type.  The required "name"
      specifies the attribute name.  The text content of this element
      specifies the attribute value.

      The "hw-attribute" element specifies a hardware-related node
      attribute, such as the device type.  The required "name" specifies the
      attribute name.  The text content of this element specifies the
      attribute value.

      The "credential" element specifies the credential to use with a
      specified protocol.  The required "protocol" attribute specifies the
      protocol, such as WBEM or SNMP.  The optional "username" attribute
      specifies a user name, and the optional "password" attribute specifies
      a password.  Note that the credential information is included only for
      compatibility with mxnodesecurity.  It is ignored by mxnode.

    Pre-defined system attributes/properties
      The following is the complete list of system attributes (or
      properties) that are pre-defined and recognized by Systems Insight
      Manager.	Invoking mxnode with either the -ld or -lf options on a
      particular existing system or node will allow you to view the current
      values for some or all of the attributes shown below.

      Note that the next section contains the limited list of those
      attributes that may be modified and locked via XML, by using the
      'mxnode -m -f <filename> command.

	   System name	  The system name is by default the same as the
			  hostname, if a hostname exists, or else the IP
			  address. The system name may be anything as long
			  as it is unique among all the systems in the
			  repository, and it may be changed.

	   Host name	  The hostname available from gethostbyname(1). It
			  may have embedded spaces and its maximum length is
			  16 characters. Hostnames are not case sensitive
			  and are represented internally as fully-qualified
			  names.

	   IP address	  The IP address corresponding to the hostname.

	   OS name	  This is the name of the operating system on the
			  managed system.

	   OS revision	  This is the revision level of the operating
			  system.

	   OS revision text
			  This is the operating system revision with
			  vendor-specific descriptive information.  Note
			  that this attribute will contain same descriptive
			  text as the 'OS Description' attribute.

	   OS vendor	  This is the operating system vendor.

	   Protocols	  These are the management protocols supported by
			  the managed system, with the revision level of
			  each protocol.

	   GUID		  The GUID is a unique identifier assigned to a
			  system in the repository.

	   Hardware device ID
			  The hardware device ID is another unique
			  identifier assigned to the hardware-specific
			  portion of a system in the repository.

	   Device type	  This is the major type of the device.

	   Device subtype This is a subtype of the device within the major
			  type.	 Up to 8 subtypes per node may be specified
			  within the XML file.

	   Model	  This is the device model.

	   Added By	  This is the login of the Systems Insight Manager
			  user who added the system.

	   Added Date	  This is the date and time the system was added.

	   Preferred Node Name
			  This attribute defines an alternate system/node
			  name of your choosing which may make it easier for
			  you to identify, find or organize systems/nodes
			  residing in the Systems Insight Manager
			  repository.

	   System Description
			  This is a description of the system.

	   Serial Number  This is the serial number of the system.

	   Asset Number	  This is the asset number of the system.

	   OS Description This is the description of the system's operating
			  system.  Note that this attribute will contain
			  same descriptive text as the 'OS Revision Text'
			  attribute.

	   Contact	  This is the person to contact in case of system
			  maintenance.

	   Location	  This is the location where the system physically
			  resides.

    System attributes that may be locked
      The following is the complete list of system attributes (or
      properties) that may be modified and locked via the 'mxnode -m -f
      <filename>' command.  Locking an attribute prevents that attribute
      from being over written by any possible Discovery and Identification
      processes.  Note that the attribute name that's enclosed in
      parenthesis is the actual attribute name that would be used in the
      mxnode XML file.

      Also note that system attributes are categorized into two distinct
      groups, hardware and software attributes, and that when specifying an
      attribute to be modified within an mxnode XML file, the correct
      attribute modifier must be used.

      For example, the Device Type attribute is considered a 'hardware'
      attribute and would be specified as follows within the XML file by
      using the 'hw-attribute' modifier.

      <hw-attribute name="DeviceType">Device Type here</hw-attribute>

      The OS Name is considered a 'sofware' attribute and would be specified
      as follows within the XML file by using the 'sw-attribute' modifier.

      <sw-attribute name="OSName">Your OS name here</sw-attribute>

      Again, only the following system attributes may be locked:

	   Preferred Node Name (software attribute)
			  (PreferredNodeName) This attribute defines an
			  alternate system/node name of your choosing which
			  may make it easier for you to identify, find or
			  organize systems/nodes residing in the Systems
			  Insight Manager repository.

	   Device Type (hardware attribute)
			  (DeviceType) This attribute is the major type of
			  the device.  Note that only the following pre-
			  defined valid device types may be used as a value
			  for a device type.  Note that only 1 device type
			  may be specified within the XML file.

	   Unknown, Unmanaged, Server, Desktop, Workstation, Portable,
	   Router, Cluster, Printer, Switch, Hub, RAS, MgmtProc, Rack,
	   Enclosure, KVM, UPS, PDU, Env, Complex, Handheld, Partition,
	   PowerSupply, ThinClient, Storage.

	   Device Subtype (hardware attribute)
		(DeviceSubType) This attribute is a subtype within the
		device's major type.  Up to 8 total of the following pre-
		defined valid device subtypes may be specified as device
		subtypes within the XML file.  Again, 1-8 DeviceSubType hw
		attribute lines may be specified within the XML file.

	   None, Blade, Dell, HPSuperdome, HPAlphaServer, HPAlphaStation,
	   HPDeskpro HPEvo, HPIntegrity, HPIntegrityServer,
	   HPIntegritySuperdome HPINtegrityWorkstation, HPKayak,
	   HPNetServer, HPOmnibook, HPProLiant HPServer, HP ServiceGuard,
	   HPVectra, HPVisualize, HPWorkstation HighAvailabilityArray,
	   HighAvailabilityCluster, MSCS, NSCUW7, HPNonStop OVM7, PowerEnc,
	   RAC, ServerEnc, Storage, TCR_PS, TruCluster HPUNCFG, VMGuest,
	   VMHost.

	   Model (hardware attribute)
		(Model) This attribute describes the device model.  Any
		displayable text may be used as a value for this attribute.

	   System Description (software attribute)
		(SystemDescription) This attribute describes the device.
		Any displayable text may be used as a value for this
		attribute.

	   Serial Number (hardware attribute)
		(SerialNumber) This attribute is the device's serial number.
		Any displayable text may be used as a value for this
		attribute.

	   Asset Number (software attribute)
		(AssetNumber) This attribute is the  device's asset number.
		Any displayable text may be used as a value for this
		attribute.

	   OS Description (software attribute)
		(OSDescription) This attribute describes the device's
		Operating System. Any displayable text may be used as a
		value for this attribute.  Note that setting this attribute
		will also change the 'OS Revision Text' attribute to same
		value as they will both contain same descriptive text.
	   OS Name (software attribute)
		(OSName) This attribute defines the name of the Operating
		System. Note that only the following pre-defined valid
		values may be used as values for this attribute.

	   HPUX, WINNT, LINUX, NOVEL, Tru64.

	   OS Revision (software attribute)
		(OSRevision) This attribute defined the Operating System
		revision or version.  Any displayable text may be used as a
		value for this attribute.

	   Contact (software attribute)
		(Contact) This attribute is used to define a contact person
		for this device.  Any displayable text may be used as a
		value for this attribute.

	   Location (software attribute)
		(Location) This attribute is used to define a physical
		location for this device.  Any displayable text may be used
		as a value for this attribute.

      As reference, these same attributes may be modified through the "Edit
      System Properties" page of the Systems Insight Manager GUI. However,
      note that there is some difference in the wording between the
      attribute name as required in the XML file, and the attribute label as
      displayed in the GUI.  The following list may be used as a cross
      reference:

      XML Attribute Name     GUI Attribute Label
      PreferredNodeName	     Preferred display name:
      DeviceType	     System type:
      DeviceSubType	     System subtype:
      Model		     Product model:
      SysDescription	     Hardware description:
      SerialNumber	     Serial number:
      AssetNumber	     Asset number:
      OSDescription	     Operating System description:
      OSName		     Operating System for tool filtering:
      OSRevision	     Operating System version:
      Contact		     Contact:
      Location		     Location:

    Commenting
      Comments may be included in XML files.  The comment must begin with
      the characters "<!--" and end with the characters "-->". Comments may
      span multiple lines within the beginning and ending character tags.

    Examples
      This section contains some examples of node XML files.

      This example shows a file containing nodes to be identified and added
      to the repository via a 'mxnode -a -f <filename>' command.  Note that
      the node may be specified either by providing a Name or IP address.
      Also note the difference in syntax as to specifying the node either by
      name or IP address.

      <?xml version="1.0" encoding="UTF-8"?>
      <node-list>
      <node name="abc" host-name="abc.mycompany.com" />
      <node>
      <sw-attribute name="IPAddress">192.1.1.1</sw-attribute>
      </node>
      <node name="maple" />
      </node-list>

      This example shows what an identified node might look like. Note that
      in this example, there are 4 device subtypes specified.  A maximum of
      8 valid subtypes are allowed to be specified per node.  See preceding
      section for list of valid subtypes that may be specified within the
      XML.  Also note that the 3 default settings have been set to false
      which specifies that all three setting types shall not be changed
      when/if a new discovery process is run on this particular 'abc' node.
      Specifying a 'true' attribute value for a particular setting would
      allow a discovery process to overwrite that setting's value.

      <?xml version="1.0" encoding="UTF-8"?>
      <node-list>
      <node name="abc" guid="..." host-name="abc.mycompany.com">
      <hw-attribute name="DeviceType">Workstation</hw-attribute>
      <hw-attribute name="DeviceSubType">HP9000</hw-attribute>
      <hw-attribute name="DeviceSubType">HighAvailabilityArray</hw-attribute>
      <hw-attribute name="DeviceSubType">HighAvailabilityCluster</hw-attribute>
      <hw-attribute name="DeviceSubType">TruCluster</hw-attribute>
      <hw-attribute name="Model">9000/785</hw-attribute>
      <hw-attribute name="ProcessorFamily">pa-risc</hw-attribute>
      <sw-attribute name="OSName">HPUX</sw-attribute>
      <sw-attribute name="OSVendor">HP</sw-attribute>
      <sw-attribute name="OSRevision">11.00</sw-attribute>
      <sw-attribute name="IPAddress">192.1.2.3</sw-attribute>
      <sw-attribute name="ProtocolSupport">SNMP:1.0</sw-attribute>
      <sw-attribute name="Description">HP-UX phoenix</sw-attribute>
      <sw-attribute name="SystemName">abc.mycompany.com</sw-attribute>
      <sw-attribute name="DefaultProtoSettings">false</sw-attribute>
      <sw-attribute name="DefaultAttributeSettings">false</sw-attribute>
      <sw-attribute name="DefaultSystemName">false</sw-attribute>
      </node>
      </node-list>

      The following example lists a node in XML format and includes all
      pre-defined system attributes for reference, including those that may
      be modified and/or locked. One method for modifying a particular
      system/node would be to use the 'mxnode -lf >filename' command to
      output the XML data to an external output file.  The output file could
      then be manually edited so as to change/add those attributes that need
      to be modified and/or locked.  After the file is edited, then use the
      'mxnode -m -f <filename>' command to actually modify the system/node,
      specifying the file just edited as the input file for the command.

      Note that the XML below also includes the method for locking those
      attributes that are lockable.  If the desire is to keep certain
      attributes from being over-written (locked) by the Discovery or
      Identification process, then ALL THREE of the attribute lock flags
      (see example XML) must be set to a 'false' value, as shown below.
      Else, all three attributes must be set to 'true'.

      <sw-attribute name="DefaultProtoSettings">false</sw-attribute>
      <sw-attribute name="DefaultAttributeSettings">false</sw-attribute>
      <sw-attribute name="DefaultSystemName">false</sw-attribute>

      As reference, these same three attribute lock flags may be modified
      through the "Edit System Properties" page of the Systems Insight
      Manager GUI.  Checking or Unchecking the the "Prevent the Discovery
      and Identification processes from changing these system attributes"
      checkbox is the same as setting the three attribute lock flags to
      either true or false.  Checking the checkbox is the same as setting
      all 3 flags to 'false'.  Unchecking the checkbox is the same as
      setting all 3 flags to 'true'.

      Note that the XML also includes the 'monitoring' feature attribute
      within the node element.	This feature allows the user to control the
      monitoring of the system/node by Systems Insight Manager.	 In normal
      operation, the system is continously monitored (includes Discovery and
      Identification) by Systems Insight Manager.  Monitoring of the system
      may be suspended for some pre-determined time, or monitoring may be
      suspended indefinately.

      As reference, this same 'monitoring' feature may be modified through
      the "Suspend/Resume Monitoring" page of the Systems Insight Manager
      GUI.

      Valid values for the 'monitoring' attribute are as follows.

      monitoring="resume" Do not suspend monitoring
      monitoring="suspend" Suspend monitoring indefinitely
      monitoring="suspend.5m" Suspend monitoring for 5 minutes
      monitoring="suspend.15m" Suspend monitoring for 15 minutes
      monitoring="suspend.1h" Suspend monitoring for 1 hour
      monitoring="suspend.1d" Suspend monitoring for 1 day

      For your reference, all attributes that may be modified and locked are
      prepended (marked) with an 'L'.  Those attributes that may be modified
      and locked, but require a pre-defined value are marked with an
      asterisk character.  See preceding sections that list the valid values
      for the 'DeviceType', 'Device Subtype' and 'OS Name' attributes.	And
      again, be aware of those attributes that are categorized as hardware
      versus software attributes.  The three attribute lock flags are
      prepended with an 'LF' marker.

      Note that setting the 'OS Description' attribute will also change the
      'OS Revision Text' attribute to same value as they will both contain
      same descriptive text.

      Sample XML file showing all system attribute formats and syntax:

      <?xml version="1.0" encoding="windows-1252"?>
      <node-list>
      <node name="systemName" host-name="hostName" monitoring="resume">
      L* <hw-attribute name="DeviceType">your data here</hw-attribute>
      L* <hw-attribute name="DeviceSubType">your data here</hw-attribute>
      L <hw-attribute name="Model">your data here</hw-attribute>
      L <hw-attribute name="SerialNumber">your data here</hw-attribute>
      <hw-attribute name="OverallStatus">NORMAL</hw-attribute>
      <hw-attribute name="ProductID">12345</hw-attribute>
      L* <sw-attribute name="OSName">your data here</sw-attribute>
      L <sw-attribute name="OSRevision">your data here</sw-attribute>
      <sw-attribute name="OSRevisionText">info here</sw-attribute>
      <sw-attribute name="TrustStatus">false</sw-attribute>
      L <sw-attribute name="AssetNumber">your data here</sw-attribute>
      L <sw-attribute name="Contact">your data here</sw-attribute>
      L <sw-attribute name="Location">your data here</sw-attribute>
      L <sw-attribute name="PreferredNodeName">your data here</sw-attribute>
      L <sw-attribute name="SysDescription">your data here</sw-attribute>
      L <sw-attribute name="OSDescription">your data here</sw-attribute>
      <sw-attribute name="OSNameStr">OS name str</sw-attribute>
      <sw-attribute name="OSVendor">OS vendor info</sw-attribute>
      <sw-attribute name="IPAddress">0.0.0.0</sw-attribute>
      <sw-attribute name="ProtocolSupport">SNMP:1.0</sw-attribute>
      <sw-attribute name="discovery.source">Ping</sw-attribute>
      LF <sw-attribute name="DefaultProtoSettings">false</sw-attribute>
      LF <sw-attribute name="DefaultAttributeSettings">false</sw-attribute>
      LF <sw-attribute name="DefaultSystemName">false</sw-attribute>
      </node>
      </node-list>

      As an example, let's say you wanted to change the 'PreferredNodeName'
      attribute for a particular system/node via the mxnode CLI.  You want
      to change the system name from "abc" to "LABabc" to signify that this
      system is a Lab system.  You would first dump the XML for the node via
      a 'mxnode -lf >filename' command.	 You could then manually edit the
      output file.  You could either leave all the current attributes as is
      in the file, or remove all attributes except for the
      'PreferredNodeName' attribute (if it does not exist, you will need to
      add it).	The following example shows what the XML file could look
      like if you wanted to change the PreferredNodeName attribute for node
      abc.  You could then use the XML file as the input for the 'mxnode -m
      -f filename' node modify command.	 Note that the example XML also has
      set all 3 attribute lock flags to 'false' as we want the
      PreferredNodeName attribute to not be over written by the Discovery or
      Identification process.  This same process could be used to change any
      of the other attributes, or change and lock any of the lockable
      attributes.

      <?xml version="1.0" encoding="windows-1252"?>
      <node-list>
      <node name="abc">
      <sw-attribute name="PreferredNodeName">LABabc</sw-attribute>
      <sw-attribute name="DefaultProtoSettings">false</sw-attribute>
      <sw-attribute name="DefaultAttributeSettings">false</sw-attribute>
      <sw-attribute name="DefaultSystemName">false</sw-attribute>
      </node>
      </node-list>

      To restore the Preferred node name back to the original 'discovered'
      node name, simply set the PreferredNodeName attribute to the same
      value 'name=' value as shown in the node element.	 This 'name=' value
      for the node/system will always be the original 'discovered' name.  To
      Restore the preferred node name back to its original 'discovered'
      value using the above example, you could do the following.

      <?xml version="1.0" encoding="windows-1252"?>
      <node-list>
      <node name="abc">
      <sw-attribute name="PreferredNodeName">abc</sw-attribute>
      <sw-attribute name="DefaultProtoSettings">false</sw-attribute>
      <sw-attribute name="DefaultAttributeSettings">false</sw-attribute>
      <sw-attribute name="DefaultSystemName">false</sw-attribute>
      </node>
      </node-list>


NODE PROXY/MANAGEMENT PATHS (MPO)

      A node may have zero or more management paths associated with it.
      Node management paths (MPOs - Management Path Objects) are created to
      assist WBEM CIMOM protocol identification as well as other 'proxy'
      type based management.  When dealing with CIMOMs and the other sources
      of management data that may not come directly from a node itself, a
      proxy type MPO will be added to the node by identification.  This MPO
      must be able to define and handle the WMI mapper and SMI-S based
      CIMOMs as proxies to a storage device that does not support a network
      connection.  The MPO must also be able to support defining a path to
      obtain SNMP data for a server via an iLO for cases where a server is
      in a DMZ with the iLO on a management network.

      The two types of MPOs that may possibly reside on a node are a
      Management Agent type (MAO), and Management Route type (MRO).
      The purpose of the MAO type is to define and support a management
      agent such as a CIMOM on SNMP agent.  The MAO contains information
      specific to accessing the agent, which includes attributes such as
      agent type, port number and IP address by which it was accessed.

      The purpose of the MRO type is to provide information required to
      access an agent (MAO).  An MRO will always have an associated MAO
      included within its overall information.	A MRO residing on a given
      node will either point to a MAO residing on the same node, or may
      point to a MAO residing on some other node.

      MPO = Management Path Object (MRO or MAO)

      MRO = Management Route Object (Points to an MAO)

      MAO = Management Agent Object (Agent, Proxy, CIMOM)

      The following example node XML listing shows a node with one MAO and
      one MRO residing on the node.  A node's MPOs will be included in the
      XML within the <managementpath-list> block.  Within this list block,
      each MPO will be included in its own <managementpath> block, whereby a
      'mpotype' atribute will define either a MRO type MPO, or a MAO type
      MPO.  Note that the MRO in the following sample XML has an associated
      MAO that resides on some other system.

      <?xml version="1.0" encoding="windows-1252"?>
      <node-list>
	.-<node name="abc" guid="..." host-name="..." monitoring="resume">
	|   <hw-attribute name="DeviceType">Server</hw-attribute>
	|   <sw-attribute name="PreferredNodeName">abc</sw-attribute>
	|   <sw-attribute name="OverallStatus">NORMAL</sw-attribute>
	|   <sw-attribute name="IPAddress">nn.nn.nnn.nn</sw-attribute>
	|   <sw-attribute name="ProtocolSupport">WBEM:1.0</sw-attribute>
	|   <sw-attribute name="ProtocolSupport">SNMP:1.0</sw-attribute>
	|   <sw-attribute name="discovery.source">Ping</sw-attribute>
	|   <sw-attribute name="DefaultProtoSettings">true</sw-attribute>
	|   <sw-attribute name="DefaultAttributeSettings">true</sw-attribute>
	|   <sw-attribute name="DefaultSystemName">true</sw-attribute>
	| .-<managementpath-list totalmpos="2">
	| |   .-<managementpath mpotype="MAO" mpoversion="1.0" maotype="WBEM_CIMOM" location="OnThisNode">
	| |   |	  <nodeguid>nn...nn</nodeguid>
	| |   |	  <nodename>abc</nodename>
	| |   |	  <proxytype>WBEM_CIMOM</proxytype>
	| |   |	  <portnumber>nnnn</portnumber>
	| |   |	  <ipaddress>nn.nn.nnn.nn</ipaddress>
	| |   |	  <protocol>https</protocol>
	| |   |	  <maoluid>nnnnnnnnnnn</maoluid>
	| |   |	  <interopnamespace>interop</interopnamespace>
	| |   |	  <profilelist>
	| |   |	    <profilename>Array</profilename>
	| |   |	    <profilename>Server</profilename>
	| |   |	  </profilelist>
	| |   |	  <functionalprofilelist>
	| |   |	    <profilename>Basic Read</profilename>
	| |   |	    <profilename>Basic Write</profilename>
	| |   |	  </functionalprofilelist>
	| |   `-</managementpath>
	| |   .-<managementpath mpotype="MRO" mpoversion="1.0">
	| |   |	  <catagoryname>hpmxCimomMro</catagoryname>
	| |   |	  <mroluid>nnnnnnnnnnn</mroluid>
	| |   |	  <profilelist>
	| |   |	    <profilename>Switch</profilename>
	| |   |	  </profilelist>
	| |   |	  <namespace>root</namespace>
	| |   |	  <cimcspath>....</cimcspath>
	| |   |	  <associatedmaoguid>nn...nn</associatedmaoguid>
	| |   |	  <associatedmaoluid>nnnnnnnnnnn</associatedmaoluid>
	| |   | .-<managementagent mpotype="MAO" maotype="WBEM_CIMOM" location="OnOtherNode">
	| |   | |   <nodeguid>nn...nn</nodeguid>
	| |   | |   <nodename>dpiwin5</nodename>
	| |   | |   <proxytype>WBEM_CIMOM</proxytype>
	| |   | |   <portnumber>nnnn</portnumber>
	| |   | |   <ipaddress>nn.nn.nnn.nn</ipaddress>
	| |   | |   <protocol>https</protocol>
	| |   | |   <maoluid>nnnnnnnnnnn</maoluid>
	| |   | |   <interopnamespace>interop</interopnamespace>
	| |   | |   <profilelist />
	| |   | |   <functionalprofilelist />
	| |   | `-</managementagent>
	| |   `-</managementpath>
	| `-</managementpath-list>
	`-</node>
      </node-list>

    MPO XML ELEMENTS and ATTRIBUTES
      As defined in the DTD, the node XML file may contain the following MPO
      related elements and information.

      The <managementpath-list> element must appear once in a node XML file
      and wraps the list of associated MPO information for the node.  The
      <managementpath-list> element supports one attribute called
      "totalmpos" and is provided only as an informational numerical
      attribute when listing mxnode data as XML, and shows the total number
      of MPOs (MROs and MAOs) listed in the XML.  This attribute is not
      required when adding or modifying MPO data for a given node.  The
      <managementpath-list> element may contain zero or more
      <managementpath> element blocks, which define each MRO or MAO that is
      associated with this node.

      The <managementpath> element supports several possible attributes.


      The "mpotype" attribute is required and specifies the type of MPO
      defined within the managementpath block.	Valid values for this
      attribute are "MRO" or "MAO".

      The "mpoversion" attribute is required and specifies the MPO version.
      When creating a new MRO or MAO, a value of 1.0.0 may be used as the
      default.

      The "location" attribute is provided only as an informational MAO
      attribute when listing mxnode data as XML.  The value for this
      attribute can either be "OnThisNode" or "OnOtherNode", and thus
      provides a quick method for determining whether this MAO actually
      resides on this node or some other remote node.  This attribute is not
      required when adding or modifying an MAO.

      The "maotype" attribute is required and specifies the MAO type only
      for a MAO type <managementpath> XML data block.  An MRO
      <managementpath> type XML data block does not require an "maotype"
      attribute.  An "maotype" attribute defines the proxy type for this
      particular MAO.  Valid values for the "maotype" attribute are
      "WMI_MAPPER", "WBEM_CIMOM", "SNMP_PROXY" or "SSH_PROXY".


ALL MAO XML ELEMENTS and ATTRIBUTES

      The following is a sample XML MAO (Management Agent) type
      <managementpath> element block and may be used as a reference for the
      following MAO element discussion.

      <managementpath mpotype="MAO" mpoversion="1.0" maotype="WBEM_CIMOM" location="OnThisNode">
	<nodeguid>nn...nn</nodeguid>
	<nodename>abc</nodename>
	<proxytype>WBEM_CIMOM</proxytype>
	<portnumber>nnnn</portnumber>
	<ipaddress>nn.nn.nnn.nn</ipaddress>
	<protocol>https</protocol>
	<maoluid>nnnnnnnnnnn</maoluid>
	<interopnamespace>interop</interopnamespace>
	<profilelist>
	  <profilename>Array</profilename>
	  <profilename>Server</profilename>
	</profilelist>
	<functionalprofilelist>
	  <profilename>Basic Read</profilename>
	  <profilename>Basic Write</profilename>
	</functionalprofilelist>
      </managementpath>

      The following XML elements are defined for the MAO <managementpath>
      block when it is declared as an MAO type block via the "mpotype"
      attribute (mpotype="MAO").


      The <nodeguid> element specifies the GUID of the node this MAO is
      residing on.  This element is included in the MAO block when a -lf
      option is executed, but is not required when adding or modifying a
      node's MPOs, and if present, will be ignored.

      The <nodename> element specifies the Name of the node this MAO is
      residing on.  This element is included in the MAO block when a -lf
      option is executed, but is not required when adding or modifying a
      node's MPOs, and if present, will be ignored.

      The <proxytype> element specifies the MAO type and is required.  Valid
      values for this attribute are "WMI_MAPPER", "WBEM_CIMOM", "SNMP_PROXY"
      or "SSH_PROXY".

      The <portnumber> element specifies the port number this MAO operates
      on.

      The <ipaddress> element specifies the IP address used to communicate
      with the MAO (Proxy CIMOM).

      The <protocol> element specifies the protocol to use to communicate
      with the MAO.  Valid values for this attribute include "http",
      "https", etc.

      The <maoluid> element specifies the unique numerical LUID value for
      this MAO.

      The <interopnamespace> element specifies the namespace within the
      target WEBEM Server where the CIM Interop Schema can be accessed.

      The <profilelist> element specifies zero or more profiles supported by
      this MAO (CIMOM, WBEM Server).  The list may include sub profiles.
      The profile(s) are specified by one or more <profilename> sub elements
      residing within the <profilelist> block.

      The <functionalprofilelist> element specifies zero or more functional
      profiles supported by this MAO (CIMOM, WBEM Server).  The profile(s)
      are specified by one or more <profilename> sub elements residing
      within the <functionalprofilelist> block.


ALL MRO XML ELEMENTS and ATTRIBUTES

      The following is a sample XML MRO (Management Route) type
      <managementpath> element block and may be used as a reference for the
      following MRO element discussion.	 Note that the MRO's associated MAO
      <managementagent> data block is embedded within the MRO
      <managementpath> block.

      <managementpath mpotype="MRO" mpoversion="1.0">
	<catagoryname>hpmxCimomMro</catagoryname>
	<mroluid>nnnnnnnnnnn</mroluid>
	<profilelist>
	  <profilename>Switch</profilename>
	</profilelist>
	<namespace>root</namespace>
	<cimcspath>....</cimcspath>
	<associatedmaoguid>nn...nn</associatedmaoguid>
	<associatedmaoluid>nnnnnnnnnnn</associatedmaoluid>
	<managementagent mpotype="MAO" maotype="WBEM_CIMOM" location="OnOtherNode">
	  <nodeguid>nn...nn</nodeguid>
	  <nodename>dpiwin5</nodename>
	  <proxytype>WBEM_CIMOM</proxytype>
	  <portnumber>nnnn</portnumber>
	  <ipaddress>nn.nn.nnn.nn</ipaddress>
	  <protocol>https</protocol>
	  <maoluid>nnnnnnnnnnn</maoluid>
	  <interopnamespace>interop</interopnamespace>
	  <profilelist />
	  <functionalprofilelist />
	</managementagent>
	</managementpath>
      </managementpath>

      The following XML elements are defined for the MRO <managementpath>
      block when it is declared as an MRO type block via the "mpotype"
      attribute (mpotype="MRO").

      The <catagoryname> element specifies a category for this MRO.  This
      element value is set internally and is not required when adding or
      modifying a MRO.

      The <mroluid> element specifies the unique numerical LUID value for
      this MRO.

      The <profilelist> element specifies zero or more profiles supported by
      this MRO.	 The profile(s) are specified by one or more <profilename>
      sub elements residing within the <profilelist> block.

      The <namespace> element specifies the namespace for the MRO.

      The <cimcspath> element specifies the source CIM Computer Space path
      object that this node points to.

      The <associatedmaoguid> element specifies the unique numerical GUID
      value for the associated MAO.  This element is not required when
      adding or modifying a MRO.

      The <associatedmaoluid> element specifies the unique numerical LUID
      value for the associated MAO, and is required when adding or modifying
      an MRO.

      The <managementagent> element is an XML data block that specifies the
      details of the MAO that's associated with this MRO.  This
      <managementagent> block is identical to the previously described MAO
      XML ELEMENTS and ATTRIBUTES section.  This entire element block is not
      required when adding or modifying a MRO.


DETECTING ADD/REMOVE OPERATION FOR MPOs

      Logic internal to the mxnode CLI scans the <managementpath-list>
      section and attempts to determine which <managementpath> blocks are to
      be added, modified or removed.

      If a MRO <managementpath> block contains a <mroluid> element with a
      valid MRO LUID value, then a Modification operation on that MRO will
      be performed.  Else if there is no <mroluid> element present in the
      MRO <managementpath> block, or if the LUID is invalid, then a Add
      operation will be performed.

      If an MAO <managementpath> block contains a <maoluid> element with a
      valid MAO LUID value, then a Modification operation on that MAO will
      be performed.  Else if there is no <maoluid> element present in the
      MAO <managementpath> block, or the LUID is invalid, then an Add
      operation will be performed.


ADDING AN MAO VIA XML

      To add an MAO to a node, do not include an MAO LUID element/value as
      shown in the example XML below.  All the elements shown below should
      be included within the XML, along with valid values.

      <managementpath mpotype="MAO" mpoversion="1.0" maotype="WBEM_CIMOM">
	<proxytype>WBEM_CIMOM</proxytype>
	<portnumber>nnnn</portnumber>
	<ipaddress>nn.nn.nnn.nn</ipaddress>
	<protocol>https</protocol>
	<interopnamespace>interop</interopnamespace>
	<profilelist>
	  <profilename>Array</profilename>
	</profilelist>
	<functionalprofilelist>
	  <profilename>Basic Read</profilename>
	</functionalprofilelist>
      </managementpath>


MODIFYING AN MAO VIA XML

      To modify an MAO on a node, include a valid MAO LUID element/value as
      shown in the example XML below.  A valid MAO LUID value could have
      been gathered from running an "mxnode -lf nodename >xmlfilename"
      command on a particular node and piping the XML to an external file,
      editing the file (editing those element values that require changes)
      and then feeding the file back into an "mxnode -m -p -f xmlfilename"
      'modify' command.	 Also, any elements/values omitted from the MAO
      block will not be modified.


      <managementpath mpotype="MAO" mpoversion="1.0" maotype="WBEM_CIMOM">
	<proxytype>WBEM_CIMOM</proxytype>
	<portnumber>nnnn</portnumber>
	<ipaddress>nn.nn.nnn.nn</ipaddress>
	<protocol>https</protocol>
	<maoluid>nnnnnnnnnnn</maoluid>
	<interopnamespace>interop</interopnamespace>
	<profilelist>
	  <profilename>Array</profilename>
	</profilelist>
	<functionalprofilelist>
	  <profilename>Basic Read</profilename>
	</functionalprofilelist>
      </managementpath>


ADDING AN MRO VIA XML

      To add an MRO to a node, do not include an MRO LUID element/value as
      shown in the example XML below.  Be sure the <associatedmaoluid> value
      is a valid LUID for an existing MAO residing on this node or some
      other remote node.

      <managementpath mpotype="MRO" mpoversion="1.0">
	<profilelist>
	  <profilename>Switch</profilename>
	</profilelist>
	<namespace>root</namespace>
	<cimcspath>....</cimcspath>
	<associatedmaoluid>nnnnnnnnnnn</associatedmaoluid>
      </managementpath>


MODIFYING AN MRO VIA XML

      To modify an MRO on a node, include a valid MRO LUID element/value as
      shown in the example XML below.  A valid MRO LUID value could have
      been gathered from running an "mxnode -lf nodename >xmlfilename"
      command on a particular node and piping the XML to an external file,
      editing the file and then feeding the file back into an "mxnode -m -p
      -f xmlfilename" 'modify' command.	 Any elements/values omitted from
      the MRO block will not be modified.  Be sure the <associatedmaoluid>
      value is a valid LUID for an existing MAO residing on this node or
      some other remote node.

      <managementpath mpotype="MRO" mpoversion="1.0">
	<mroluid>nnnnnnnnnnn</mroluid>
	<profilelist>
	  <profilename>Switch</profilename>
	</profilelist>
	<namespace>root</namespace>
	<cimcspath>....</cimcspath>
	<associatedmaoluid>nnnnnnnnnnn</associatedmaoluid>
      </managementpath>


REMOVING AN MRO OR MAO VIA

      Use the -p (prune) option and omit those MPOs from the XML that are to
      be removed from the node.	 For each MAO that will be removed, all
      associated MROs (MROs that may be pointing to this now removed MAO)
      residing on other nodes will also be automatically found and removed.


MANAGEMENT PATH NOTES

      The following notes may help when adding, modifying, listing or
      removing node MPOs via XML.

      Adding, modifying or removing MPO data for a given node is available
      only via the mxnode CLI 'modify' option whereby the MPO data is
      provided via XML input.  Adding, modifying or removing MPOs is not
      available directly on the mxnode CLI command line.

      To Add, Modify or Remove any MPOs for a particular node, ONLY the
      Modify ('-m') option may be used to perform the said MPO tasks.
      Internal mxnode logic will determine whether the Add or Modify
      operation will be performed on any MPOs residing within the XML based
      of the existance or non-existance of an <maoluid> or <mroluid> element
      and valid value.	Either of the following mxnode command line formats
      will allow for adding or modifying of a node's MPOs.

      >mxnode -mf xmlfilename

      >mxnode -m -f filename

      >mxnode -m -p -f filename (prune option specified - must precede '-f')

      To Add a node(s) with one or more specified MPOs, you would first
      perform an "mxnode -af filename" to add the node to the system via
      XML.  Any MPO data residing within the node XML will be ignored during
      the Add operation.  Once the node(s) has been successfully added, you
      would then perform a "mxnode -mf filename" command, using the same xml
      file used in the add operation.  The MPO data residing within the XML
      would then be honored, and the MPO(s) would be added for the
      associated node(s).  This two-phase operation is required because MPO
      addition/modification can only be performed on an existing node(s).

      Do this first:   mxnode -af filename.xml
      Then this:       mxnode -mf filename.xml

      When the "mxnode -a -f filename" Add command or the "mxnode -r -f
      filename" Remove command is used to Add/Remove a node via XML file,
      then any existing MPO data residing in the input XML is ignored!

      If an <mroluid> element is not present within an MRO section, then an
      Add operation will be performed on that MRO.

      If an <maoluid> element is not present within an MAO section, then an
      Add operation will be performed on that MAO.
      If an <mroluid> element is present within an MRO section, but this MRO
      does not exist within the node's MPO list, then an Add operation will
      be performed on that MRO.

      If an <maoluid> element is present within an MAO section, but this MAO
      does not exist within the node's MPO list, then an Add operation will
      be performed on that MAO.

      If an <mroluid> is present within an MRO section, and this MRO does
      exist within the node's MPO list, then a Modify operation will be
      performed on that MRO.

      If an <maoluid> is present within an MAO section, and this MAO does
      exist within the node's MPO list, then a Modify operation will be
      performed on that MAO.

      To Remove any MPO(s) for a particular node, the '-p' (Prune) option
      MUST also be specified along with the '-m' (Modify) option. The '-p'
      option tells the CLI that it's ok to remove those MPO(s) that are
      currently assigned to the node, but have been omitted from the XML.
      In other words, the '-p' option says: "Prune those MPOs that have been
      omitted from the specified XML or XML file".  Those MPOs that you wish
      to remain associated with the node must reside within the XML.

      When using the '-p' option with the "mxnode -m -f filename" command,
      the format and order for the options on the command line must look as
      follows, with the '-p' option coming before the '-f' option.

      mxnode -m -p -f filename

      Warning!	Be careful when using the -p (Prune) option for MPOs.  For
      example, if you want to add one MPO to a particular node and the XML
      includes only the MPO data for that one node in the XML, then any/all
      other MPOs that may be associated with that node will be removed, if
      the -p option was include in the command line!  Only use the -p prune
      option when you really want to remove one or more MPOs from a node.
      When only adding or modifying MPOs for a node(s), do NOT include the
      -p option.

      When adding or modifying an MRO (Management Route), any MAO data
      residing within the associated <managementagent> block is ignored.
      The reason is for this behavior is that the associated MAO may reside
      on some other node, and the MRO is simply 'pointing' to that MAO.	 To
      actually modify the associated MAO, the node that the MAO resides on
      would have to be modified.  In other words, an MAO can only be added
      or modified when defined within its own XML <managementpath> block.

      When modifying the <profilelist> element or <functionalprofilelist>
      element for either a MRO or MAO, a <profilename> can be removed by
      simply omitting it from within the XML <profilelist> block or the
      <functionalprovilelist> element block.
      You can modify the associated MAO LUID (intent is for the MRO to point
      to a different MAO), for an existing MRO.	 Note that the associated
      <managementagent> block may or may not exist within the XML.  When
      modifying an MRO, the associated MAO <managementagent> block, if
      present, is ignored.

      When modifying MPOs, the <managementpath-list> element attribute
      <totalmpos> is ignored. You can either leave it in the XML, or remove
      it.

      Note that if an <maoluid> is present within a particular MAO block,
      but this MAO cannot be found in the node's current MPO list, then an
      Add operation will be assumed and automatically performed.  The same
      holds true for an <mroluid> that may be present within an MRO block,
      but cannot be found in the node's current MPO list.  It too will then
      be automatically added to the node.

      When a node is removed via the -r -f option, all MROs and MAOs
      associated with that node will also be removed.  For removed MAOs,
      this also includes the removal of any associated MROs that may be
      residing on other nodes.	Any MRO or MAO data residing within the XML
      is ignored during the node(s) removal operation.


EXAMPLE NODE XML CONTAINING MPO DATA

      The following XML example shows how to add an MAO to a node.  Note
      that the Add operation is triggered by the fact that there is no
      <maoluid> element present in the MAO <managementpath> block. Also note
      that the <nodeguid> and <nodename> elements will be ignored, and that
      they could be removed if desired.

      <?xml version="1.0" encoding="windows-1252"?>
      <node-list>
	<node name="abc" guid="..." host-name="..." monitoring="resume">
	  <hw-attribute name="DeviceType">Server</hw-attribute>
	  <sw-attribute name="PreferredNodeName">abc</sw-attribute>
	  <sw-attribute name="OverallStatus">NORMAL</sw-attribute>
	  <sw-attribute name="IPAddress">nn.nn.nnn.nn</sw-attribute>
	  <sw-attribute name="ProtocolSupport">WBEM:1.0</sw-attribute>
	  <sw-attribute name="ProtocolSupport">SNMP:1.0</sw-attribute>
	  <sw-attribute name="discovery.source">Ping</sw-attribute>
	  <sw-attribute name="DefaultProtoSettings">true</sw-attribute>
	  <sw-attribute name="DefaultAttributeSettings">true</sw-attribute>
	  <sw-attribute name="DefaultSystemName">true</sw-attribute>
	  <managementpath-list totalmpos="1">
	    <managementpath mpotype="MAO" mpoversion="1.0" maotype="WBEM_CIMOM">
	      <nodeguid>nn...nn</nodeguid>
	      <nodename>abc</nodename>
	      <proxytype>WBEM_CIMOM</proxytype>
	      <portnumber>nnnn</portnumber>
	      <ipaddress>nn.nn.nnn.nn</ipaddress>
	      <protocol>https</protocol>
	      <maoluid>nnnnnnnnnnn</maoluid>
	      <interopnamespace>interop</interopnamespace>
	      <profilelist>
		<profilename>Array</profilename>
		<profilename>Server</profilename>
	      </profilelist>
	      <functionalprofilelist>
		<profilename>Basic Read</profilename>
		<profilename>Basic Write</profilename>
	      </functionalprofilelist>
	    </managementpath>
	  </managementpath-list>
	</node>
      </node-list>

      The following XML example shows how to add an MRO to a node.  Note
      that the Add operation is triggered by the fact that there is no
      <mroluid> element present in the MRO <managementpath> block.  Also be
      aware that the <associatedmaoluid> value must be valid, that is, this
      particular MAO must already reside either on this node or some other
      remote node.  Also, in this particular example, the <managementagent>
      element block does exist, however, note that it is ignored, and could
      in fact be removed if desired. The <catagoryname> element, the
      <associatedmaoguid> element and the "totalmpos" attribute are also
      ignored, and could in fact be removed if desired.	 You would use the
      following mxnode command for an already existing node.

      mxnode -m -f xmlfilename

      <?xml version="1.0" encoding="windows-1252"?>
      <node-list>
	<node name="abc" guid="..." host-name="..." monitoring="resume">
	  <hw-attribute name="DeviceType">Server</hw-attribute>
	  <sw-attribute name="PreferredNodeName">abc</sw-attribute>
	  <sw-attribute name="OverallStatus">NORMAL</sw-attribute>
	  <sw-attribute name="IPAddress">nn.nn.nnn.nn</sw-attribute>
	  <sw-attribute name="ProtocolSupport">WBEM:1.0</sw-attribute>
	  <sw-attribute name="ProtocolSupport">SNMP:1.0</sw-attribute>
	  <sw-attribute name="discovery.source">Ping</sw-attribute>
	  <sw-attribute name="DefaultProtoSettings">true</sw-attribute>
	  <sw-attribute name="DefaultAttributeSettings">true</sw-attribute>
	  <sw-attribute name="DefaultSystemName">true</sw-attribute>
	  <managementpath-list totalmpos="1">
	    <managementpath mpotype="MRO" mpoversion="1.0">
	      <catagoryname>hpmxCimomMro</catagoryname>
	      <profilelist>
		<profilename>Switch</profilename>
	      </profilelist>
	      <namespace>root</namespace>
	      <cimcspath>....</cimcspath>
	      <associatedmaoguid>nn...nn</associatedmaoguid>
	      <associatedmaoluid>nnnnnnnnnnn</associatedmaoluid>
	      <managementagent mpotype="MAO" maotype="WBEM_CIMOM" location="OnOtherNode">
		<nodeguid>nn...nn</nodeguid>
		<nodename>dpiwin5</nodename>
		<proxytype>WBEM_CIMOM</proxytype>
		<portnumber>nnnn</portnumber>
		<ipaddress>nn.nn.nnn.nn</ipaddress>
		<protocol>https</protocol>
		<maoluid>nnnnnnnnnnn</maoluid>
		<interopnamespace>interop</interopnamespace>
		<profilelist />
		<functionalprofilelist />
	      </managementagent>
	    </managementpath>
	  </managementpath-list>
	</node>
      </node-list>

      The following XML example shows how to add an MRO to a node, and is
      the same at the previous example, except all the non-required MPO
      elements and attributes have been removed.  You would use the
      following mxnode command for an already existing node.

      mxnode -m -f xmlfilename

      <?xml version="1.0" encoding="windows-1252"?>
      <node-list>
	<node name="abc" guid="..." host-name="..." monitoring="resume">
	  <hw-attribute name="DeviceType">Server</hw-attribute>
	  <sw-attribute name="PreferredNodeName">abc</sw-attribute>
	  <sw-attribute name="OverallStatus">NORMAL</sw-attribute>
	  <sw-attribute name="IPAddress">nn.nn.nnn.nn</sw-attribute>
	  <sw-attribute name="ProtocolSupport">WBEM:1.0</sw-attribute>
	  <sw-attribute name="ProtocolSupport">SNMP:1.0</sw-attribute>
	  <sw-attribute name="discovery.source">Ping</sw-attribute>
	  <sw-attribute name="DefaultProtoSettings">true</sw-attribute>
	  <sw-attribute name="DefaultAttributeSettings">true</sw-attribute>
	  <sw-attribute name="DefaultSystemName">true</sw-attribute>
	  <managementpath-list>
	    <managementpath mpotype="MRO" mpoversion="1.0">
	      <profilelist>
		<profilename>Switch</profilename>
	      </profilelist>
	      <namespace>root</namespace>
	      <cimcspath>....</cimcspath>
	      <associatedmaoluid>nnnnnnnnnnn</associatedmaoluid>
	    </managementpath>
	  </managementpath-list>
	</node>
      </node-list>

      The following XML example shows how to add two MROs and an MAO to a
      node.  Note that the second MRO and the MAO have no values for the
      <profilelist> and the <functionalprofilelist> elements.  Also note in
      this particular example, the associated MAO <managementagent> element
      blocks for both MROs have been omitted.  You would use the following
      mxnode command for an already existing node.

      mxnode -m -f xmlfilename

      <?xml version="1.0" encoding="windows-1252"?>
      <node-list>
	<node name="abc" guid="..." host-name="..." monitoring="resume">
	  <hw-attribute name="DeviceType">Server</hw-attribute>
	  <sw-attribute name="PreferredNodeName">abc</sw-attribute>
	  <sw-attribute name="OverallStatus">NORMAL</sw-attribute>
	  <sw-attribute name="IPAddress">nn.nn.nnn.nn</sw-attribute>
	  <sw-attribute name="ProtocolSupport">WBEM:1.0</sw-attribute>
	  <sw-attribute name="ProtocolSupport">SNMP:1.0</sw-attribute>
	  <sw-attribute name="discovery.source">Ping</sw-attribute>
	  <sw-attribute name="DefaultProtoSettings">true</sw-attribute>
	  <sw-attribute name="DefaultAttributeSettings">true</sw-attribute>
	  <sw-attribute name="DefaultSystemName">true</sw-attribute>
	  <managementpath-list>
	    <managementpath mpotype="MRO" mpoversion="1.0">
	      <profilelist>
		<profilename>Switch</profilename>
	      </profilelist>
	      <namespace>root</namespace>
	      <cimcspath>....</cimcspath>
	      <associatedmaoluid>nnnnnnnnnnn</associatedmaoluid>
	    </managementpath>
	    <managementpath mpotype="MRO" mpoversion="1.1">
	      <profilelist />
	      <namespace>root</namespace>
	      <cimcspath>....</cimcspath>
	      <associatedmaoluid>nnnnnnnnnnn</associatedmaoluid>
	    </managementpath>
	    <managementpath mpotype="MAO" mpoversion="1.0" maotype="WBEM_CIMOM">
	      <proxytype>WBEM_CIMOM</proxytype>
	      <portnumber>nnnn</portnumber>
	      <ipaddress>nn.nn.nnn.nn</ipaddress>
	      <protocol>https</protocol>
	      <interopnamespace>interop</interopnamespace>
	      <profilelist />
	      <functionalprofilelist />
	    </managementpath>
	  </managementpath-list>
	</node>
      </node-list>


      The following XML example shows how to modify an MRO and an MAO on a
      node.  Note that the MRO and the MAO do both have LUIDs defined, which
      is an indicator that these MPOs already exist for this particular
      node.

      Do note however, that if an <maoluid> is present within a particular
      MAO block, but this MAO cannot be found in the node's current MPO
      list, then an Add operation will be assumed and automatically
      performed.  The same holds true for an <mroluid> that may be present
      within an MRO block, but cannot be found in the node's current MPO
      list.  It too will then be automatically added to the node.  You would
      use the following mxnode command for an already existing node.

      mxnode -m -f xmlfilename

      <?xml version="1.0" encoding="windows-1252"?>
      <node-list>
	<node name="abc" guid="..." host-name="..." monitoring="resume">
	  <hw-attribute name="DeviceType">Server</hw-attribute>
	  <sw-attribute name="PreferredNodeName">abc</sw-attribute>
	  <sw-attribute name="OverallStatus">NORMAL</sw-attribute>
	  <sw-attribute name="IPAddress">nn.nn.nnn.nn</sw-attribute>
	  <sw-attribute name="ProtocolSupport">WBEM:1.0</sw-attribute>
	  <sw-attribute name="ProtocolSupport">SNMP:1.0</sw-attribute>
	  <sw-attribute name="discovery.source">Ping</sw-attribute>
	  <sw-attribute name="DefaultProtoSettings">true</sw-attribute>
	  <sw-attribute name="DefaultAttributeSettings">true</sw-attribute>
	  <sw-attribute name="DefaultSystemName">true</sw-attribute>
	  <managementpath-list>
	    <managementpath mpotype="MRO" mpoversion="1.0">
	      <mroluid>nnnnnnnnnnn</mroluid>
	      <profilelist>
		<profilename>Switch</profilename>
	      </profilelist>
	      <namespace>root</namespace>
	      <cimcspath>....</cimcspath>
	      <associatedmaoluid>nnnnnnnnnnn</associatedmaoluid>
	    </managementpath>
	    <managementpath mpotype="MAO" mpoversion="1.0" maotype="WBEM_CIMOM">
	      <proxytype>WBEM_CIMOM</proxytype>
	      <portnumber>nnnn</portnumber>
	      <ipaddress>nn.nn.nnn.nn</ipaddress>
	      <protocol>https</protocol>
	      <maoluid>nnnnnnnnnnn</maoluid>
	      <interopnamespace>interop</interopnamespace>
	      <profilelist />
	      <functionalprofilelist />
	    </managementpath>
	  </managementpath-list>
	</node>
      </node-list>
      The following XML example shows how to remove, or prune all MROs and
      MAOs from a node.	 Note that any MROs or MAOs omitted from the XmL
      will be removed from the node, and in this example, the
      <managementpathlist> is empty.  Be careful using the -p option.  You
      would use the following mxnode command for an already existing node.

      mxnode -m -p -f xmlfilename

      <?xml version="1.0" encoding="windows-1252"?>
      <node-list>
	<node name="abc" guid="..." host-name="..." monitoring="resume">
	  <hw-attribute name="DeviceType">Server</hw-attribute>
	  <sw-attribute name="PreferredNodeName">abc</sw-attribute>
	  <sw-attribute name="OverallStatus">NORMAL</sw-attribute>
	  <sw-attribute name="IPAddress">nn.nn.nnn.nn</sw-attribute>
	  <sw-attribute name="ProtocolSupport">WBEM:1.0</sw-attribute>
	  <sw-attribute name="ProtocolSupport">SNMP:1.0</sw-attribute>
	  <sw-attribute name="discovery.source">Ping</sw-attribute>
	  <sw-attribute name="DefaultProtoSettings">true</sw-attribute>
	  <sw-attribute name="DefaultAttributeSettings">true</sw-attribute>
	  <sw-attribute name="DefaultSystemName">true</sw-attribute>
	  <managementpath-list />
	</node>
      </node-list>


GENERAL NOTES

      (1) When modifying a node via the -m -f <filename> command, you only
      need to include those attributes that you wish to modify within the
      XML file.	 However, you must always include the 3 attribute lock flags
      and set all 3 attribute lock flags to either 'true' or 'false'.  Most
      likely, you'll want the latter setting (false) so that the lockable
      attributes will not be over written whenever the Discovery and
      Identification processes run on the particular system/node.

      (2) The only way to clear a particular system/node attribute using the
      mxnode -m -f <filename> command, is to include that attribute in the
      XML file and provide a value for that attribute of 1 space character.

      (3) Including a software type attribute within the XML file that is
      not a pre-defined attribute will still be accepted by mxnode during a
      system 'modify' operation (-m -f <filename>) command.  This 'user-
      defined' type attribute will also be persistant and remain in the
      repository as an associated node attribute, even if Discovery or
      Identification is run on the node.  However, it is not recommended to
      add user-defined node attributes via an edited XML file as this
      ability to include user-defined attributes for a node is intended for
      other applications support.  This may help explain why non pre-defined
      system attributes may be visible via -lf option at times with a
      particluar node(s).


      (4) Although any system/node attribute may be modified via an XML
      file, only a limited set of all pre-defined system attributes may be
      additionally locked or protected from being over written by the
      Discovery or Identification processes. See preceding documentation for
      a complete list of those system attributes that may be modified AND
      locked.

      (5) The mxnode CLI does provide a way through the XML to 'Restore' the
      preferred node name back to the original 'discovered' node name.	See
      above section on example XML files.


LIMITATIONS

      This command may only be run on the CMS.


AUTHOR

      mxnode was developed by the Hewlett-Packard Company.


SEE ALSO for HP-UX

      mxnode(1M)


SEE ALSO for Linux

      mxnode(8)