Previous Next Contents Generated Index Home


Chapter 15

Module Builder




The Module Builder GUI, part of the Sun Management Center Developer Environment 3.0, provides you with the tools needed to build a simple module. In this chapter, the Sun Management Center is referred to as SunMC and the Developer Environment is referred to as DE.

This chapter describes the steps required to build a simple module, to specify the required and optional parameters for your module, and to save and publish your module when done. For information on how to build a simple module manually, refer to Chapter 5.

As a developer of modules, you can use the GUI Module Builder to develop simple modules using an interactive interface. This tool provides you with a rapid development environment. Before you work with the Module Builder, you may want to familiarize yourself with the Sun Management Center module building concepts that are detailed in Chapter 5 and Chapter 6.

The Module Builder supports only shell based data acquisitions, and does not support rules or filters. You can modify a module after it is published in the DE-compliant format. For example, a module built with the Module Builder in the DE-compliant format can be enhanced manually to support these features by following the steps in the respective chapters of this document.

It includes the following major sections:


The Module Builder Interface

The Module Builder interface allows you to:


Note - You cannot load published modules back into the Module Builder. However, you can take a published module, put it into the metadata repository and then load only the structure of the module using the Load Production Module choice.

The -m.x, -d.x, and -models-d.x Files

The Module Builder provides the means to create and update the three files necessary to implement a module. These files include the following:

The following sections describe steps:


 

To Build a Module Using the Module Builder

Listed below are brief descriptions of the major steps to help build a module using the Module Builder. For more details on each step, refer to the rest of this document.

  1. Launch the Module Builder from the Sun Management Center.
  The Module Builder when launched displays two main folders:

Note - You can create more than one instance of a Module Builder module.

For detailed description of the above step, refer to "To Launch the Module Builder".

  2. Enter the module parameters and values in the Module Parameters tables.
  The Module Parameter folder displays two tables; one where you can enter mandatory or required parameters and another where you can enter optional parameters.
  For detailed description of the above step, refer to the following section, "Building Module Parameter Contents (-m.x)".
  3. Build the module's hierarchy by accessing the Module Root folder.
  For detailed description of the above step, refer to "Building Data Model Contents (-d.x)".
  4. Realize the module and define its Data Acquisition (DAQ)
  For objects defined as "Active," you can define Data Acquisition (DAQ) properties. When you right-click on an object that is Active, you can access its corresponding Attribute Editor. By clicking on the Realization tab within the Attribute Editor, you can specify Data Acquisition commands and other related information. Activate Node and Deactivate Node are menu choices available over any node inside the "Module Root".
  You can also select Activate or Deactivate to turn Data Acquisition ON or OFF in a hierarchy for any particular object and its children. This is also true for the Run Module and the Stop Module menu choices except that it turns the data acquisition ON or OFF for the whole module. The DAQ Mode that is specified when the user launches the Module Builder affects how these menu choices work.
  When the module is published, the results from refresh command/refresh service are saved while test refresh command/service are lost. The refresh command/service values are always saved when you save the module, regardless of the DAQ mode. DAQ Mode only affects the way the module works while it is being developed within the Module Builder. The purpose of the Test DAQ Mode is so that you can write test refresh command/service values if the actual refresh command/service commands are not executable from the same machine where you are developing the module. For example, this would be applicable if you are developing a module for monitoring a database that is not on the same machine as the Sun Management Center Developer Environment.
  For detailed description of the above step, refer to the section, "Defining Data Acquisition (models-d.x)".
  5. Specify alarm thresholds and alarm actions when applicable.
  If the object is a managed property, or a table column that is of a type that supports alarms, you will see the tabs "Alarms" and "Actions" in the Attribute Editor. Specify alarm thresholds and alarm actions within these tabs. For detailed description of the above step, refer to "For Objects that Support Alarms".

 

To Launch the Module Builder

  1. Launch the Module Builder tool from the Agent in the Sun Management Center Developer Environment. Launch the SunMC console on the DE server:

username% <SunMC Install Directory>/SUNWsymon/sbin/es-start -c 

  2. Double-click on the server icon to launch Host Details.
  3. Double-click on the Load Development Module option.
  4. Select the option to load the Module Builder module in the Load Development Module popup.
  The Module Parameters dialog box will be available for you to make your entries:

FIGURE  15-1 Module Loader Window


Note - When an invalid value is typed into the Module Parameter file, the error dialog now gives a hint as to what the correct format should be.

Fill in the following fields with the appropriate information:

TABLE  15-1   Module Loader Fields 
Module Description  

A description of the module, such as "prototype" or "test."  

Instance  

The module instance.  

Description  

A brief description of the module.  

DAQ Mode  

Upon loading, the DAQ mode to be specified. The three DAQ modes are:

  • Default uses the Refresh Command & Refresh Service in the Realization tab.
  • Test uses the Test Refresh Command and the Test Refresh Service in the Realization tab.
  • Metadata basically allows you to look at the design aspects and structure. No data acquisition will ever be performed in a module builder module that is loaded in metadata mode.
  • Note: When you Stop or Deactivate the module, it puts you in the metadata mode. (Deactivate and Stop are menu choices. They do nothing when the Module Builder is loaded in metadata mode.)  

    These are explained in the following section, after which this chapter covers the following topics:


    Module Builder Menu Choices

    Specific menu choices are available over the following Module Builder windows:

      1. Right click on the Module Root to see the following menu choices:

    FIGURE  15-2 Menu Options from Module Root

      2. Right click on the Managed Object to see the following menu choices:

    FIGURE  15-3 Menu Options Over Managed Object Folder

    For more information on Active and Passive modes, refer to Chapter 5.

      3. Right click on the Managed Property to see the following menu choices:

    FIGURE  15-4 Menu Options Over Managed Property

      4. Right click on the Table to see the following menu choices:

    FIGURE  15-5 Menu over Table


    File Specific Commands

    The following commands are available in the Module Builder over the Module Root:


    Note - Other commands are explained in their relevant sections.

    The following table discusses the file specific commands:

    TABLE  15-2   File System Commands

    Load Development Module  

    This choice allows you to load a module currently in use in a Sun Management Development Environment. This choice allows you to load the data structure for any module that is loaded into the "metadata repository."  

    Load Production Module  

    This choice allows you to load a module currently in use in a Sun Management Production Environment.  

    Save Development Module  

    Allows you to save the development module.  

    Publish Module  

    Allows you to publish the development module. Allows you to Save the module in a DE compliant format (-d.x,
    -models-d.x, -m.x
    , and the like.)  

    Export MIB  

    Exports the module to a standard MIB format.  

    Import MIB  

    Imports the structure of a module from a file that is in MIB format.  

    All of the above options are available over the Module Root folder. This folder displays a pop-up window to assist the user in selecting a module in the internal format. The module will be loaded into the Module Builder instance, and the user can resume the module building process.

    Files copied via Solaris to /var/opt/SUNWsymon/cfg may not be visible for no longer than 30 seconds after the copy. This is due to the time that it takes for the console to refresh. The list of modules refreshes immediately after you save the module with a Save Module option and you will see the module that you saved in the Load Development Module popup.

    Once the module is ready, you can save or publish the modules. When working with nodes and tables, you also have the option on deleting nodes or tables if necessary. This section details on all these options.


    Load Production Module

    This choice allows you to load the structure of a Sun Management Center module that is loaded in the metadata repository. This means loading a preexisiting module from the metadata repository.

    FIGURE  15-6 Load Production Module


    Load Development Module

    This option allows the user to load in a module that was previously saved with the Module Builder. This means loading a module that a user is currently in the process of developing.

    FIGURE  15-7 Load Development Module


    Save Development Module

    This menu choice is only available over the Module Root folder.

    This menu choice will display a pop-up window verifying that the user wishes to save. The module is saved with the following format where name is the "Name" parameter specified in the Module Parameters folder in the following directory:

    /var/opt/SUNWsymon/cfg/name.mb
    

    This module is saved in an internal "Module Builder" format. The user will need to use the "Publish Module" feature to save the module in a format that can be installed on a Sun Management Center agent machine. A saved module can be loaded into the Module Builder at a later time using the "Load Development Module" operation.

    In the internal format of the module, all the Module Builder specific parameters like test commands, will be saved. A later load operation will retrieve this information too.

    It displays a pop-up asking the user if they are sure they want to save the module.

    FIGURE  15-8 Save Confirmation


    Publish Module

    This menu choice is only available over the Module Root folder.

    This menu choice takes a saved module and writes it in a form that can be installed on a Sun Management Center agent machine. The module is saved in the following directory:

    /var/opt/SUNWsymon/cfg
    

    Publish creates the following files, where the name is the Name specified in the Module Parameters folder:

    Modules saved in /var/opt/SUNWsymon/cfg can be loaded in the agent is restarted.

    This option will display a pop-up asking you if you are sure you want to publish the module.

    FIGURE  15-9 Publish Confirmation

    Once a publish operation is done, the module files that are created will be in DE compliant format, and are ready for installation on any agent machine. Once this operation is done, the published module can be treated just like any other module that is available in production environment.


    Note - Once we publish the module, the module cannot be loaded into the Module Builder with all the information it had earlier. Especially information like the test commands will no longer be included in the published module.

    Export MIB

    This menu choice is only available over the Module Root folder.

    The export operation exports the SNMP MIB associated with the module. The file is saved as name.mib where name is the name of the module as specified in the Required Module Parameters section.


    Note - MIBs are imported and exported in their standard SNMP format.

    The file will be placed in the following directory: :

    /var/opt/SUNWsymon/cfg
    


    Import MIB

    This menu choice is only available over the Module Root Folder. The import option is used to create a module from an SNMP MIB. The .mib file is imported to the following directory:

    /var/opt/SUNWsymon/cfg
    

    The file must end with the following suffix:

    .mib 
    

    A popup exactly like the one used for Load will be used to select the MIB file.

    The following figure depicts the difference between import and load operations.

    FIGURE  15-10 The Difference between Import and Load operations


    Building Module Parameter Contents (-m.x)

    This section discusses the information you provide in the module parameters form. The information you supply in this form will result in the creation of -m.x file.


     

    To Access the Module Parameters Folder

       Click on the Browser tab from the Details window.
    _
      You will see the Module Parameters folder.

    FIGURE  15-11 Module Parameters Folder Accessed from the Browser tab of Details


     

    To Update the Module Parameters Tables

      1. Click on the Module Parameters folder to access the Parameter tables.

    The Module Parameters folder, when clicked, displays two tables.

    The second table, Optional Module Parameters, initially empty, allows you to enter optional parameters. The following two options are available as menu choices if you right-click over the Optional Parameters:

    The information entered in these tables is placed in the Module Parameters, or the
    -m.x file, when the module is published.

    You cannot load any manual changes that you enter into a "published" version of the module. When an invalid value is typed into the Module Parameter file, the error dialog provides the hint of what the correct format should be. Specifically the format rules are:

    The Module OID must start with:

    1.3.6.1.4.1
    

    Note that if the Module Location and Module OID are not the same length, the Module Builder generates an error message when the user tries to save the module.

      2. Specify the required and mandatory information in the Required Module Parameters table by entering the appropriate values for the required fields.

    FIGURE  15-12 Required Module Parameters Popup Menu

      For more information on Mandatory Parameters, refer to Chapter 5. Specify the following fields:

    TABLE  15-3   Required Module Paramet 
    Name  

    is the filename of the associated module. It is used to build the filename when you save the file. So the file is called name.mb. It is also used when you publish, so the files are called name-m.x, name-d.x, name-models-d.x, and so on.  

    Module Name  

    is a short string naming the module. This parameter can be used internally by the agent.  

    Module Version  

    is the version number of the module and is used internally by the agent. This must be the same as the version used as part of the module name.  

    Module Type  

    identifies the module category. This value determines where the module is placed in the Sun Management Center console when it is loaded.  

    Module Enterprise  

    specifies the SNMP enterprise under which this module is loaded. This value must correspond to the enterprise specified in the <location> module parameter.  

    Module Location  

    specifies the full symbolic OID (from .iso) where the module is to be loaded. The location string must not contain any "-" characters as indicated by RFC 1903.  

    Module OID  

    specifies the numeric OID described by the <location> parameter.  

    Module Desc  

    is a verbose description of the module functionality. This parameter is used when exporting the module MIB during the creation of the module MIB text file.  

      3. Specify the Optional Module Parameters.

    FIGURE  15-13 Optional Module Parameters Popup Menu

    Note that you can also indicate if the values are optional or mandatory. For more information on Optional Module Parameters or Additional Parameters, refer to the Sun Management Center 3.0 Developer Environment Reference.

      4. Click on Add Parameter to add the Optional Parameters for any of the four types of Format choices. Enter a Name, a Description, the Required value for each Optional Parameter, and the Format. The Format can be one of the following:

    The images below present the different formats with their respective default values.

    For details on Required fields, see "Predefined Additional Qualifiers".


    Boolean

    The default value for Boolean can be True or False:

    FIGURE  15-14 Optional Parameter Popup - Add Boolean Entry


    Instance

    The default value for Instance can be any string consisting of alphabetic characters:

    FIGURE  15-15 Optional Parameter Popup - Add Instance Entry


    List

    The default value for List is one whose value you can enter into the text field. Note that you can also edit your lists selecting from the editing values presented:

    FIGURE  15-16 Optional Parameter Table Popup - Add List Entry

    If a string of non-zero length is entered into the text field, the Add to List button is activated. Pressing this button adds the entry to the list. The list is displayed in an editable combo box so that you can modify the entries if necessary. A Clear List button is available to empty the list.

    Password

    The default value for Password is a string that is displayed as asterisks (***) on the screen for security:

    FIGURE  15-17 Optional Parameter Table Popup - Add Password Entry


    Building Data Model Contents
    (-d.x)

    The Module Builder enables you to build a distinct hierarchy for your module. The input you provide in this form will result in the creation of -d.x files once you publish the module. For details on -d.x files, refer to Chapter 5 and Chapter 6. Data model files (-d.x) are created or updated by accessing the pop-up menus from the Module Root folder and publishing the module.


    Commands Used When Building Data Model Contents

    The Module Parameter contents for the file covers the following file system commands:


    Copy Nodes/Copy Table

    This menu choice is available over the Module Root, Managed Properties and any Managed Object or Managed Table that is a child of the Module Root folder. Over a table this menu choice offers the Copy Table option; otherwise, it offers Copy Nodes. Copy lets you copy the node and its children from one node to another within the same instance of the Module Builder module or from one instance of the Module Builder module to another.


    Paste Nodes

    This menu choice is available over the Module Root folder. It is also available over any Managed Object that is a child of the Module Root folder. Any hierarchy that happens to be stored within the buffer will be pasted into this managed object. Use the paste feature even if the copy was performed in another instance of the Module Builder module. This allows you to copy from one module and paste into another module. Users may copy and paste between different instances of the Module Builder module.


    Add Node

    This menu choice is available over the Module Root and any Managed Object inside the Module Root. Add Node launches a pop-up that contains a combo box with a list of objects that can be created for managed objects, managed properties and tables.


    Clear Module

    This menu choice is only available over the Module Root folder. It allows you to clear the module. The following confirmation box checks to see if you are sure you want to clear the Module Root folder. If so, the hierarchy under the Module Root folder is removed from the agent and the Optional and Required Module Parameters tables are cleared.


    Delete Node/Delete Table

    This menu choice is available over any Managed Property, Managed Object, or Table that is a child of the Module Root folder. Over a table this menu choice reads Delete Table; otherwise, it reads Delete Node.

    This option will display a pop-up asking if you are sure they want to delete the object. If so, the node and all of its children are deleted from the module.

    FIGURE  15-18 Delete Node


    Using the Module Root to Define Hierarchy and DAQ

    The Module Root folder of the Module Builder allows you to define the hierarchy and data acquisition for a module. This folder acts as an anchor for the module being built. From the Root Folder's pop-up menu, you can add child nodes and have each created child node become immediately visible. Each created node also has a pop-up menu that allows you to create child nodes from those nodes that are managed objects (not for those that are managed properties or managed tables).


    Note - The Root Menu has a new option to load the DE module, the "Load DE Module." The Load Production Module loads from the metadata repository.

    Data Types

    You can select the type of DAQ for all node types: Managed Object, Managed Property and Managed Table.


    Adding Nodes

    The Add Node option is available over the Module Root and any Managed Object inside the Module Root. When you select it, a popup appears. Using this popup, you can select Managed Property, Managed Object or Managed Table. If you select Managed Property or Managed Object and select OK or Apply, then the node is created immediately. If you select Managed Table, then a second pop-up appears asking for information about each column of the table. Then when you select OK, the Managed Table is created. Selecting Close at any time causes the popup(s) to disappear without the node being created.

    Choosing the Add Node option within each of the above contexts, will display the Add Managed Child window. In this window, fill all text boxes with the object's Name and the object's Description values. Specify if the object's mode is "Passive", "Active", or "Derived." Once these parameters are selected, click on the "OK" or "Apply" button to continue, or select the "Cancel" button to abort.


     

    To Create the Hierarchy of the Module

      1. Access the Module Root folder. Right click on the Managed Object within Module Root.
      2. Click on the Add Node option to add the desired node.
      You will see the Add Managed Child window illustrated in the next step.
      3. Add one of the following: managed object, managed property, or managed table.
      a. Add Managed Object

    FIGURE  15-19 Add Managed Object

    For managed objects, specifying if the added node is to be Active, Passive, or Derived for objects will affect how Data Acquisition (DAQ) for the object is managed. This is explained in Step 4. Invalid data acquisition marks the object with a black mark (black spot).
    For example, the object will receive a black mark if the module was not "stopped" via the Stop Module option. After an active or derived object is created, there should always be a passive property beneath it.
      b. Add Managed Property

    FIGURE  15-20 Add Managed Property

    For managed property, specifying if the added node is to be Active, Passive, or Derived will affect how Data Acquisition (DAQ) for the object is managed. This is explained in Step 4. Also, make sure to select the Property Type from the selections offered.
      c. Add Table

    FIGURE  15-21 Add Managed Table

    If the type of object is a managed table, specify the number of columns. The Add Managed Table popup also results in an additional table popup, the Add Managed Table window, where you can enter values for each table column.
    The Add Managed Table window allows you to specify required and optional table column values:

    FIGURE  15-22 Table Add PopUp

    For information on the Index field, the Table Desc field, and the Short/Medium/Long Descriptions, see TABLE 15-4.

      4. Specify whether the node for the object is Passive or Derived.
      5. Repeat the steps to create the entire hierarchy.

    Based on the type of the object (managed property, managed object, or managed table), the contents of the resulting popup will change. This popup will list only a subset of the parameters available for a node. The images below represent the choices available over the various types of objects that can be seen in the Module Builder. The OK button is greyed out until all the required parameters are entered by the user.


    Note - The rest of the parameters for the node can be edited using the Model tab within the object's attribute editor as discussed in Attribute Editor section.

     

    To Change the Data Model

      1. Access the Attribute Editor for the object you want to change.
      2. Click on the Model Tab in the Attribute Editor.
      Modify any available properties for the object through the "Model" tab. The information provided in this tab will be placed in the Data Model (-d.x) file when the module is published:

    FIGURE  15-23 Model Tab

    For a detailed description of these fields, see below:

    TABLE  15-4   Model Tab Field Descriptions  
    Field

    Description

    Variable  

    represents the name extension from its parent. This is filled automatically.  

    Object SubID  

    gets the oid extension from the parent. This field is filled automatically.  

    Medium Description  

    initially contains the Description entered during node creation.  

    Units  

    is optional parameter, like ms, secs, km., and such.  

    Short and Full Descriptions  

    are not mandatory, and take the value of Medium Description as default value.  

    Access Control  

    Access control can be any of the following: rw

    ro

    wo

     

    Node Type  

    Node type can be whichever of the following is valid for that type. active

    passive

    derived

     

    Current MIB Type  

    Current MIB type is only valid over managed properties and table columns. It allows the user to change the type of the node, like "INT" to "FLOAT" or "INTHI", etc.  


    Defining Data Acquisition
    (models-d.x)

    This section describes what you can do once you have specified the parameters for your module. It helps you manipulate that data. It offers two options, Realization and Model.

    Once you save your data, Realization helps you automatically refresh your information at the desired intervals. In test mode, the dummy commands that you entered in the forms should be visible here.

    Model helps you edit or change any previously specified attributes. Since it is accessed in the context of changing data models, it is described "To Change the Data Model".

    This section concentrates on the Realization tab that helps define Data Acquisition or DAQ.


    Commands Used When Enabling DAQ

    The following commands help you work toward enabling DAQ:

    TABLE  15-5   Relevant Commands that assist in Data Acquisition
    Command
    Description

    Run Module

    and

    Stop Module  

  • If module builder loaded in Default Mode, then Run Module will activate the data acquisition using the Refresh Service and Refresh Command and Stop Module will disable data acqusition.
  • If module builder loaded in Test Mode, then Run Module will activate the data acquisition using the Test Refresh Service and Test Refresh Command and Stop Module will disable data acqusition.
  • If module builder loaded in Metadata Mode, then Run Module will no nothing since Module builder is in metadata mode.
  •  

    Activate Node

    and

    Activate Module  

    Helps you to begin data acquisition on each of the managed objects you created. This option is applicable for Managed Objects, Managed Properties, and Managed Tables.  

    Deactivate Node

    and

    Deactivate Table  

    Helps you to stop data acquisition on each of the managed objects you created. This option is applicable for Managed Objects, Managed Properties, and Managed Tables.  

    Each one of the above commands, displays a corresponding confirmation box to ensure that you are ready to go through with the execution.


    Run Module Confirmation Box

    This menu choice is available over the Module Root folder. It specifies that the "Refresh Command" and "Refresh Service" specified in the module are used for Data Acquisition. It displays a pop-up to ensure that you want to run the module.

    FIGURE  15-24 Run Module Confirmation


    Stop Module Confirmation Box

    This menu choice is available over the Module Root folder. It specifies that the "Test Refresh Command" and Test Refresh Service specified in the module are used for data acquisition. This is the default behavior of the module. It displays a pop-up asking the user if they are sure they want to stop the module.

    FIGURE  15-25 Stop Module Confirmation


    Activate Node/Activate Table Confirmation Box

    This menu choice is available over the Module Root folder. It is also available over any Managed Property, Managed Object, or Table that is a child of the Module Root folder. Over a table, this menu choice reads Activate Table; otherwise, it reads Activate Node. This choice turns on data acquisition for the node and any of its children. It displays a pop-up to ensure if you are sure you want to activate the object.

    FIGURE  15-26 Activate Node/Activate Table Confirmation


    Deactivate Node/Deactivate Table Confirmation Box

    This menu choice is available over the Module Root folder. It is also available over any Managed Property, Managed Object, or Table that is a child of the Module Root folder. Over a table this menu choice reads Deactivate Table, otherwise it reads Deactivate Node. Deactivate turns off data acquisition for the node and any of its children.

    This option will display a pop-up asking the user if they are sure they want to deactivate the object.

    FIGURE  15-27 Deactivate Note/Deactivate Table Confirmation


    Clear Confirmation

    This option will display a pop-up asking the user if they are sure they want to clear the module or the object.

    FIGURE  15-28 Clear Confirmation


     

    To Enable Data Acquisition on a Module, Table, or Object

      1. Invoke the Attribute Editor on an Active Node. Launch the Attribute Editor for each of the following from its respective option:
      2. Click on the Realization Tab.
      Specify the data acquisition information for the object through the "Realization" tab. The information provided in this tab provides the information that will be placed in the Data Model Realization (models-d.x) file when the module is published.
      The following illustration represents the Realization tab:

    FIGURE  15-29 Realization Tab

      3. Define the refresh options.
      Here is a brief description of refresh commands and options:

    TABLE  15-6   Refresh Commands
    Command
    Description

    Refresh Interval (sec):  

    The refresh interval specifies the time specification that the refresh command is executed. For more information, refer to "refreshInterval".  

    Refresh Service  

    A refresh service is an object within the agent that can be used for data acquisition. A refresh service must be specified for active and derived nodes. For more information, refer to "refreshService".  

    Refresh Command  

    A refresh command is a service-dependent command that defines the specific operation to perform. A refresh command is sent to the refresh service each time a refresh is triggered. For more information, refer to "refreshCommand".  

    Refresh Filter  

    The refreshFilter qualifier specifies a Tcl command or procedure that is used to process the data acquired by the refresh command. For more information, refer to "refreshFilter". Note that the Editor is a combo box and not a text entry.  

    Refresh Parameters  

    Refresh parameters is used to specify additional arguments to be passed to the refresh command. For more information, refer to "refreshParams".  

    Initial Interval  

    Specify the time window within which the node must run the refreshCommand for the first time after the module initializes. For more information, refer to "initInterval".  

    Initial Holdoff Time  

    Specify the time, to wait before running the refreshCommand for the first time (required waiting time). For more information, refer to "initHoldoff".  




    Previous Next Contents Generated Index Home

    Copyright © 2000 Sun Microsystems, Inc. All Rights Reserved.