Skip to ContentSun and Oracle Channel Sun How to Buy Log In

Site/SunNet/Domain Manager Administration Guide

内に含ま

Site/SunNet/Domain Manager 2.3 AnswerBook

その他のドキュメント

サポートリソース

PDF 文書ファイルをダウンロードする

Management Database

18

This chapter discusses the following topics:

Element type definitions
Element instance definitions
Connection definitions
Background definitions
Tools menu definitions
Definition of requests
Duplicate databases

18.0.1 Purpose of the Management Database

The management database (also called the runtime database) represents the data model of a site's environment. It contains information on the agents that are supported and the objects that are managed. The information in the management database determines how the SunNet Manager Console displays the layout of the site's network, machine icons (glyphs in OPEN LOOK parlance), characteristics, and associated menus.

Certain kinds of changes to your management database can only be made by editing a saved MDB file with a text editor. These kinds of changes include:

Adding or modifying element types.

Specifying a new glyph for an element type.
Adding or modifying tools in an element's Glyph menu.

"Part 1: Network Management Tasks" describes how to make these changes. This chapter describes the format of the definitions contained in the database files. Specifically, these definitions include:

Element type, including definition of the glyph and user commands associated with an element type.
Element instances.
Connections between elements.
Background images for view instances.
Tools available from the Console's Tools menu.
Data requests.
Event requests.

Input to the runtime database comes from two sets of ASCII files, structure files and instance files.

Structure files provide a set of definitions to the Console. These include:

The snm.glue file that contains a starting set of definitions for the Console. The Console depends on these definitions, so do not modify them.
The agent schemas that define the attributes each agent manages. (See your Site/SunNet/Domain Manager Application and Agent Development Guide for a discussion of agent schema files.)
The element schema file(s) that define the element types in a site's configuration. Element schema also specify the glyphs and commands for each element type. SunNet Manager provides definitions of numerous element types in the file, elements.schema. See Section 18.1, "Element Type Definition," for more information.

Note - Do not change the elements.schema or netware_elements.schema file. If you need to add element types, create a file with the .schema extension in the same directory as the elements.schema/netware_elements.schema.

Instance files provide definitions of element and request instances.

The runtime database can also be modified by the Console through its graphical editing capability and through the Discover Tool. As you move glyphs and start requests, you are modifying the runtime management database.

18.1 Element Type Definition

Although many element types are defined in the file, elements.schema, additional types may be added or current types modified to customize the Console to meet a particular site's needs. This section discusses element type definition.

Note - Element types are constructed from data types specified in the enumerated type snmdb_type, which is defined the header file netmgt_db.h. These data types are listed and described in your Site/SunNet/Domain Manager Application and Agent Development Guide.

There are four categories of elements. New element categories cannot be added by a user. The element categories are:

Components. Components represent elements such as workstations, printers, and routers. Components appear as a glyph (see Section 18.1.1, "Glyph Definition (for Component or View Element Type)," for a discussion of how to specify the glyph for a component).
Views. A view is a collection of elements. A view may contain other views. Like a component, a view also appears as a glyph.
Buses. Buses represent elements such as an Ethernet LAN segment. A bus appears as a line with movable endpoints.
Connections. A connection is an element that connects two other elements. A connection appears as a line connecting the two elements. Examples are a leased internet work link and an RS-232-C line.

Element types are defined using a record. The record specifies the fields stored in the database for each instance of that element type. The format is:


  record <category>.<name> (  
              <type field-name>  
              ...  
  )

where:

<category>

one of the element categories discussed above (component, view, bus, or connection).

<name>

provides a name for the element type. Each element category is a separate namespace. For instance, it is legal to define both a view.ethernet and a bus.ethernet. The maximum length of name is 64 bytes.

<type field-name> defines one or more fields that define the properties of the element. The maximum length of <type field-name> is 64 bytes. Certain fields must be defined, while other fields have particular functions--these are described in the following section.

All element type definitions must have a field called Name, which names the element instance.
Connections must have two additional fields, Object1 and Object2 that name the endpoints of the connection.
Glyph_State allows you to enable or disable glyph state propagation to the element.
Components may be SNMP devices. The following fields provide SNMP information that is included with requests to the SNMP proxy agent (see Chapter 19, "SNMP Support," for more information):
SNMP_RdCommunity specifies the SNMP community name to use when reading attribute values.
SNMP_WrCommunity specifies the SNMP community name to use when writing attribute values.

SNMP_Vendor_Proxy specifies a non-SNM SNMP proxy agent. This should only be specified when a vendor has supplied an SNMP proxy agent that communicates with the SunNet Manager SNMP proxy agent.
SNMP_Timeout specifies the number of seconds that the SNMP proxy agent is to wait for a response to requests sent to the target element.
For bus.ethernet elements, Default_Proxy specifies the default proxy system for any elements that are discovered in the subnet. When the Discover Tool is run for the subnet, the name specified in this field is the default proxy system for each element in the subnet.
Label is an optional field you can add that allows a label that is different from Name to appear under the glyph that corresponds to an element instance. To use the Label field, enter in a string in the Element Properties sheet. If no value is entered, the value in the Name field is displayed. If a single hyphen (-) is entered in the Label field, neither the Label nor the Name value is displayed under the element's glyph.

Other fields are optional and provide information used when displaying the element's properties.

The following rules are used to display an element's properties:

The properties are the list of field names and values in an element's record.
Any field whose name begins with underscore is not displayed in an element's properties.
Embedded underscores in field names are converted to blanks in the Properties list. For instance, the field User_Name will be displayed in the Properties under <User Name>.

The following example defines some element types:


  record component.sun4 (  
            string[64]          Name  
            string[40]          IP_Address  
            string[40]          User  
            string[40]          Location  
            string[80]          Description  
            string[40]         SNMP_RdCommunity  
            string[40]         SNMP_WrCommunity  
            string[40]         SNMP_Vendor_Proxy  
            int                SNMP_Timeout  
            string[256]          SNMP_SysObject_ID  
            string[40]           Physical_Address  
  )  
  
  record view.subnet(  
            string[64]          Name  
            string[80]          Description  
           string [40]          NetMask  
            enum stateProp      Glyph_State  
  )  
  
  record connection.rs232 (  
            string[64]          Name  
            string[64]          Object1  
            string[64]          Object2  
            string[80]          Description  
  )  
  
  record bus.ethernet (  
            string[64]          Name  
            string[40]          IP_Network_Number  
            string[80]          Description  
            enum stateProp      Glyph_State  
            string[64]          Default_Proxy  
  )

18.1.1 Glyph Definition (for Component or View Element Type)

Elements that are either a component or view are displayed as a glyph. An elementGlyph instance in the element's schema specifies the glyph for a component or a view.

An elementGlyph instance has the following format:


  instance elementGlyph (  
               ( <element>  "<icon-path-name>" )  
               ...  
  )

Note that the elementGlyph instance must be placed after the element type component record. If the <icon-path-name> begins with a slash (/), it is treated as an absolute path. Otherwise, the path name is relative to the directories specified by the Icon Directories setting in the Console Properties Locations category. See Chapter 14, "Console," for more information about Console Properties settings.

The following example shows an elementGlyph instance that specifies several glyph/component mappings:


  instance elementGlyph (  
            ( component.sun3                            sun3.icon)  
            ( component.sun4                            sun4.icon)  
            ( component.sun386                          sun386.icon)  
            ( component.laserwriter                     laserwriter.icon)  
            ( component.pc                              pc.icon)  
            ( component.genhost                         mainframe.icon)  
            ( component.genws                           generic-ws.icon)  
            ( component.router                          router.icon)  
            ( component.bridge                          bridge.icon)  
            ( component.lanbox                          lanbox.icon)  
  )

Note that you can have up to 1024 icons or raster files defined in the runtime database; this includes background images as well as element glyphs.

18.1.2 User Command Definition for an Element Type

A UNIX command may be defined to appear in the Tools menu of a component, view, bus, or connection by including an elementCommand instance in the element schema. This provides the ability to quickly execute any UNIX command by pointing to a glyph and selecting the command. The elementCommand instance has the following syntax:


  instance elementCommand (  
                  ( <element> "<menu-name>" "<cmd-string>" )  
                   ...  
  )

where:

<element>

specifies an element type. All elements of this type will have the command in their glyph menu. The maximum length of <element> is 64 bytes.

<menu-name>

specifies the name of the command to appear in the menu. The maximum length of <menu-name> is 32 bytes.

<cmd-string>

specifies the UNIX command string to execute. Any word in the command string of the format %field will be replaced by the value of field for that element. The maximum length of <cmd-string> is 1024 bytes.

Note that the elementCommand instance must be placed after the element type component record.

The following example defines two commands that can be run from elements of type component.sun4.


  instance elementCommand (  
     (component.sun4 "Rlogin..." "$SNMHOME/bin/snm_cmdtool  
  $SNMHOME/bin/snm_exec rlogin %Name")  
     (component.sun4 "Telnet..." "$SNMHOME/bin/snm_cmdtool  
  $SNMHOME/bin/snm_exec telnet %Name")  
  )

As shown in the example above, the environment variables $SNMHOME or $SNMDBDIR can be used, even if you have not explicitly set them.

If you have not set SNMHOME or SNMDBDIR, then

/usr/snm and /var/adm/snm are assumed for Solaris 1.x environments
/opt/SUNWconn/snm and /var/opt/SUNWconn/snm are assumed for Solaris 2.x environments.

Thus, for example, if SNM is installed on a SunOS 5.x machine, the string "$SNMHOME/bin/snm_cmdtool" is expanded to

"/opt/SUNWconn/snm/bin/snm_cmdtool" if SNMHOME is not otherwise defined.

18.2 Element Instance Definition

Element and request instances are defined using cluster records. A cluster record provides a means for collecting multiple records to make up a single instance. A cluster record contains an initial record defining the instance's type followed by one or more records providing additional information about the element or request.

For example, the following cluster record defines a component.sun4:


  cluster(  
            component.sun4 ( SunEng14 1.2.2.388 Engineer23  
                                 "Building 2, Room 146"  
                                 "Sun 4/110 - monochrome,  
                                 diskfull" )  
            membership ( Subnet2 100 230 0 )  
            agent ( etherif )  
            agent ( hostif )  
            agent ( hostmem )  
            proxy ( hostperf SunEngServer )  
            agent ( layers )  
            proxy ( ping SunEngServer )  
            agent ( rpcnfs )  
            glyphColor ( 220 220 250 )  
            connect ( SunLAN )  
  )

The first record in the example, component.sun4, defines the instance's type. It must be a record defined in your element's schema file. The first field in the record is normally the name of the element, in this case, SunEng14. The string "Building 2, Room 146" is a single field with a maximum length of 64 bytes. When a field contains an ASCII string with embedded blanks, surround the string with double quotes.

Note - Element names are not case-sensitive. SunEng14 is the same as suneng14.

The other fields in the first record correspond to the component.sun4 record definition in the elements schema. See the section on "Element Type Definition" for more information. Except for when the instance is a connection, these other fields are optional. Connections have two additional required fields that specify the endpoints of the connection.

The second record in the example, the membership record, places the instance in a view. Views represent a logical grouping of elements. A view may contain other views. The way you choose to arrange instances in views is up to you. Some examples are:

Lay out your network elements in a "logical" (network) view as well as in a "physical" (machines in a building) view. For instance, display all the routers in the Routers view and also place them in views corresponding to their location within the network.
Arrange views in a circular (or loop) arrangement where a view that is a member of the Home view can also contain the Home view.

The first field of the membership record indicates the name of the view--in this case, Subnet2. A special view, Home, refers to the view that is displayed when the Console is started. This is also the default view if no membership records are specified.

The remaining fields in the membership record provide positioning coordinates for the instance and are optional. For bus and connection elements, five coordinates are specified: X coordinate, Y coordinate, Z value (used when glyphs are stacked on top of each other in a view), and X and Y coordinates of the second point of the element. For other types of elements, only the X, Y, and Z coordinates are specified. If the coordinates are not specified, the instance will be automatically positioned in the view by the Console.

Although the example shows only a single membership record in the cluster, an instance may be placed into several views by including multiple membership records in the cluster.

The third through ninth records in the example--the agent and proxy records--provide the list of available agents and proxies for the instance. The first field in the record provides the name of the agent or proxy. proxy records contain a second field that supplies the name of the system providing the proxy.

The tenth record in the example is a glyphColor record. This record provides the color for the glyph. It is optional and, if omitted, the glyph is transparent. The three fields provide the red, green, and blue intensities, respectively. Each intensity can vary between 0 and 255. Transparent is all zeros. White is all 255s.

The final record in the example is a connect record. It is optional and indicates that the element is connected to another instance. This will cause a line to be drawn to the connected instance if it appears in the view. connect records are valid only in an instance that is a component, bus, or view. The example connects SunEng14 to SunLAN. Connections made via connect records are referred to as simple connections since they have no name.

Cluster records can also contain a glyphState record, which should not be modified. If you are creating a new cluster record, you do not need to define the glyphState record; glyph state is assumed to be normal.

18.3 Connection Definition

A connection is another element category supported by the SunNet Manager Console. Connections are like any other element and can be selected and named, and can contain subviews containing other elements. A connection is created by creating a cluster whose first record is of type connection.<type>. The endpoints of the connection are named by the second and third fields in the connection.<type> record that correspond to the fields Object1 and Object2.

The following example shows a definition of a link type of connection:


  cluster (  
            connection.link ( ExtLink BigHost SomeNet )  
            membership ( Home 400 320 32766 401 88 )  
            glyphColor ( 255 0 255 )  
  )

In this case, BigHost and SomeNet are the elements that are the endpoints of the connection named ExtLink. The connection will only appear in the view Home if the elements BigHost and SomeNet both exist in that view.

18.4 Background Definition

Background images may be associated with a view instance by including a viewBackground instance record in an instance file. The image should be in raster file format. Icon format is supported if the file ends with the extension .icon. However, large backgrounds in icon format load much more slowly than raster format files.

Before you specify a background, you need to create the view instance that will be associated with the background. If the icon path name begins with a slash (/), it is treated as an absolute path. Otherwise, the path name is relative to the directories specified by the Icon Directories setting in the Console Properties Locations category. See Chapter 14, "Console," for more information about Console Properties settings. The following example shows a definition of a background image file called USmap.im1 with the Home view:


  instance viewBackground (  
           ( Home USmap.im1 )  
  )

The background image file can be a maximum of 64 bytes. Note that the background definitions must be placed after the view instance definition. You can have up to 1024 icon or raster files defined in the runtime database; this includes background images as well as element glyphs.

Note - The preferred method of adding a background image to the current view is to invoke the View >> Add Background option in the Console window. Refer to your Site/SunNet/Domain Manager Application and Agent Development Guide for more information.

18.5 Tools Menu Definition

A UNIX command may be defined to appear in the Tools menu of the Console, allowing you to launch the command as a separate process. This definition is accomplished by an elementCommand instance, similar to the elementCommand definition for an element type.

Starting with version 2.3, a new database record is defined in the snm.glue file:


  (SNM_Console_Menu "<cmd-name>"

This record will allow you to create submenus to facilitate execution of SunNet manager commands. The other way to create submenus is through the Console as follows:

Click SELECT on Tools >> Customize >> Menu to receive the following screen:

Enter a menu or tool name on the appropriate line.
Click SELECT on Apply to save the changes to your runtime database.

Each menu list on the Console provides the opportunity to add submenus, tools or a command menu item.

The following example defines tools that can be invoked from the Console's Tools menu.


  instance elementCommand (  
  (SNM_Console "Browser..." "$SNMHOME/bin/snm_br")  
  (SNM_Console "Grapher..." "$SNMHOME/bin/snm_gr")  
  (SNM_Console "Snapshot.." "snapshot")  
  (SNM_Console_Menu "Discovery")  
  (SNM_Console "IP Discover... "$SNMHOME/bin/snm_discover")  
  (SNM_Console "IPX Discover.. "$SNMHOME/bin/snm_ipx_discover")  
  }  
  (SNM_Console_Menu "cisco")  
       (SNM_Console "Router Mgmt..." "router_mgmt")  
       (SNM_Console "Switch Mgmt..." "switch_mgmt")  
  }  
       (SNM_Console_Menu "Performance")

As shown in the example above, any string in the form $name is replaced by the expanded <name> environment variable. The string

"$SNMHOME/bin/snm_br" is expanded to "/usr/snm/bin/snm_br" if you have the SNMHOME environment variable set to /usr/snm. (If you have not set the SNMHOME environment variable, /usr/snm is assumed for Solaris 1.1 installations; /opt/SUNWconn/snm is the default for Solaris 2.x installations.)

18.6 Definition of Requests

This section discusses the format of requests. Most users will want to create requests from the Console rather than manually building requests as described here. However, this information is included as reference information on how requests are stored in the management database.

Every request, whether active or held, is defined by a cluster record. The definitions of the records used in these clusters can be found in the Console definitions file. This file is located at:

/usr/snm/struct/snm.glue, on Solaris 1.1 installations
/opt/SUNWconn/snm/struct/snm.glue, for Solaris 2.x installations.

Like other instances, the type of request (data or event) is determined by the first record in its cluster. Requests for data begin with a dataRequest record, while event requests begin with an eventRequest record.

18.6.1 Data Requests

The following example is a cluster record representing a Data Request:


  cluster(  
            dataRequest ( hostperf.data.0 0 SunEng14  
                                SunEngServer hostperf data  
                                "'Interval' 'Count' Times"  
                                10 5 "" "" "" undefined True  
                                False "Save Request" undefined  
                                hostperf.data SunEng14 )  
            dataAttribute ( cpu% True 1 True 1473696 None  
                                0 )  
            dataAttribute ( intr False 0 False 0  
                                "Delta Values" 1515136 )  
            rqstState ( Idle 0 0 )  
             membership ( SunEng14 460 260 0 )  
  )

The first record is the dataRequest record. See Table 18-1.

Table 18-1 Data Request -- dataRequest

Field #	Field Name	Description
1	`Name`	Name of the request. Displayed under the request's glyph and in messages about the request. Not sent to the agent. Maximum length is 64 bytes.
2	`_serialnumber`	Serial number of the request. Set serial number to `0` for new requests.
3	`_targetsystem`	Name of the target system. Passed to the agent as the *<system>* name. If the next field is NULL, this field is also used to determine the location of the agent. Maximum length is 64 bytes.
4	`Proxy_System`	Name of the proxy system. Used to determine the location of the agent. If null, the value of the previous field is used to determine the location of the agent. Maximum length is 64 bytes.

Table 18-1 Data Request -- dataRequest

Field #	Field Name	Description
5	`_agent`	Name of the agent. Maximum length is 64 bytes.
6	`_group`	Name of the group/table. Maximum length is 64 bytes.
7	`Interval`	Interval field passed to agent.
8	`Count`	Count field passed to agent.
9	`Key`	Key field passed to agent. Maximum length is 128 bytes.
10	`Restart`	Boolean indicating whether to automatically restart the request if it dies or the system on which it is running dies. Value must be either `True` or `False`.
11	`Defer_Reports`	Boolean indicating whether sending responses should be deferred until requested by the Console. Value must be either `True` or `False`.
12	`On_Completion`	Disposition of request when it terminates. Value must be either `Delete Request` or `Save Request.`
13	`Options`	Options field passed to agent as an argument with the name of the string in `netmgt_optstring`. Maximum length is 128 bytes.
14	`Log_to_File`	File name for data reports. If NULL, reports are sent to the data log window. Maximum length is 128 bytes.
15	`_fileport`	Internal variable for the Console. Set to `undefined` for new requests. Do not modify for existing requests.
16	`To_Program`	Sends reports to a program. This is the name of the program.
17	`_prmport`	Internal variable for the Console. Set to `undefined` for new requests. Do not modify for existing requests.
18	`_timestamp`	Internal variable for the Console. Set to `undefined` for new requests. Do not modify for existing requests.
19	`_groupId`	*<Agent>.<group>* name (should match the values of parameters 5 and 6).
20	`_targetobject`	Object associated with the request. Used to determine the name that should be put in error messages, which glyph should be blinked, etc. Must be the name of an element in the database. Maximum length is 64 bytes.
21	`SnmpRedirect`	Boolean indicating whether an SNMP request is to be redirected to another (vendor's) SNMP proxy agent.
22	Start_Date	Start time in the format mm/dd/yy
23	Stop_Date	Stop time in the format mm/dd/yy
24	Start_Time	Start time in the format hh:mm (hh 0-23, mm 0-59
25	Stop_Time	Stop time in the format hh:mm (hh 0-23, mm 0-59)

Following the dataRequest record are zero or more dataAttribute records.

These records control how data is displayed by the Console. If no dataAttribute records are in a request element, all data is displayed in the Data Reports Log (or specified file). See Table 18-2 for a description of the dataAttribute record.

Table 18-2 --dataAttribute

Field #	Field Name	Description
1	`Attribute`	Name of the attribute. Maximum length is 64 bytes.
2	`Data_Log`	Boolean indicating whether attribute should be displayed in the Data Log. Value must be either `True` or `False`.
3	`_asciiport`	Internal variable for the Console. Set value to `0` for new requests. Do not modify for existing requests.
4	`Indicator`	Boolean indicating whether this attribute should be displayed in an indicator. Value must be either `True` or `False`.
5	`_bargraphport`	Internal variable for the Console. Set value to `0` for new requests. Do not modify for existing requests.
6	`Strip_Chart`	If and how the attribute should be displayed in a strip chart. Value must be either `None`, `Absolute Values`, or `Delta Values`. `None` specifies no strip chart, while `Absolute Values` and `Delta Values` specify a strip chart based on *<absolute>* or *<delta>* (current - previous) values.
7	`_stripchartport`	Internal variable for the Console. Set value to `0` for new requests. Do not modify for existing requests.
8	`Graph_Tool`	If and how the attribute should be displayed in the Grapher. Value must be either `None`, `Absolute Values`, or `Delta Values`. `None` specifies no graph, while `Absolute Values` and `Delta Values` specify a grapher based on *<absolute> or <delta*> (current - previous) values.
9	`_grapherhandle`	Internal variable for the Console. Set value to `0` for new requests. Do not modify for existing requests.

Following the dataAttribute records is the rqstState record. See Table 18-3 for a description of the rqstState record.

Table 18-3 rqstState

Field #	Field Name	Description
1	`state`	State of the request. If you wish the request to be automatically activated when the Console is started, set this field to `Active` and set the `Restart` field in the `dataRequest` record to `True`. Otherwise set this field to `Idle`. Refer to the `rqstmgr_state` enumeration in `snm.glue` for other possible values.
2	`reqflags`	Internal variable. Always set this to `0`.
3	`timestamp`	Internal variable. Always set this to `0`.

The final record is a membership record. This record indicates in which element's subview the request glyph will appear. See Table 18-4 for a description of the membership record.

Table 18-4 membership

Field #	Field Name	Description
1	`view`	Name of the element in whose subview the request glyph appears. Normally, this would be the same as the final value of the `dataRequest` record. Maximum length is 64 bytes.

The remaining fields in this record specify X and Y positioning. These fields should be left blank and the Console used to position the request glyph.

18.6.2 Event Requests

The following shows a cluster record representing an Event Request:


  cluster(  
            eventRequest ( hostperf.data.1 1 SunEng14  
                               SunEngServer hostperf data Once  
                               0 1 "" "" False False False  
                               "Delete Request" undefined  
                               hostperf.data SunEng14 )  
            eventAttribute ( cpu% "Greater Than" 80  
                               "Threshold Not Set" ""  
                               "Blink Glyph" "" Low )  
            rqstState ( Idle 0 0 )  
            glyphState ( 32 )  
            membership ( SunEng14 )  
  )

The first record is an eventRequest record. See Table 18-5 for a description of the eventRequest record.

Table 18-5 eventRequest

Field #	Field Name	Description
1	`Name`	Name of the request. Displayed under the request glyph and in messages about the request. Not sent to the agent. Maximum length is 64 bytes.
2	`_serialnumber`	Serial number of the request. Internal serial number used by the tool. Set this field to `0` for new requests.
3	`_targetsystem`	Name of the target system. Passed to the agent as the <system> name. If the next field is NULL, this field is also used to determine the location of the agent. Maximum length is 64 bytes.
4	`Proxy_System`	Name of the proxy system. Used to determine the location of the agent. If NULL, the value of the previous field is used to determine the location of the agent. Maximum length is 64 bytes.
5	`_agent`	Name of the agent. Maximum length is 64 bytes.
6	`_group`	Name of the group or table. Maximum length is 64 bytes.
7	`Interval`	Interval field passed to agent.
8	`Count`	Count field passed to agent.
9	`Key`	Key field passed to agent. Maximum length is 128 bytes.

Table 18-5 eventRequest

Field #	Field Name	Description
10	`Restart`	Boolean indicating whether to automatically restart the request if it dies or the system on which it is running dies. Value must be either `True` or `False`.
11	`Send_Once`	Boolean indicating whether the request terminates after the first report. Value must be either `True` or `False`.
12	`Defer_Reports`	Boolean indicating whether sending responses should be deferred until requested by the Console. Value must be either `True` or `False`.
13	`On_Completion`	Disposition of the request when it terminates. Value must be either `Delete Request` or `Save Request`.
14	`Options`	Options field passed to agent. Maximum length is 128 bytes.
15	`_timestamp`	Internal variable for the Console. Set to `undefined` for new requests. Do not modify for existing requests.
16	`_groupId`	*<Agent>.<group>* name (should match values of parameters 5 and 6).
17	`_targetobject`	Object associated with the request. Used to determine the name that should be put in error messages, which glyph should be blinked, etc. Must be the name of an element in the database. Maximum length is 64 bytes.
18	`SnmpRedirect`	Boolean indicating whether an SNMP request is to be redirected to another (vendor's) SNMP proxy agent.
19	Start_Date	Start time in the format mm/dd/yy
20	Stop_Date	Stop time in the format mm/dd/yy
21	Start_Time	Start time in the format hh:mm (hh 0-23, mm 0-59
22	Stop_Time	Stop time in the format hh:mm (hh 0-23, mm 0-59)

Following the eventRequest record are one or more eventAttribute records. These records set thresholds that determine when an event should be reported. Each record can set up to two thresholds for a particular attribute. See Table 18-6 for a description of the eventAttribute record.

Note - Only one record can be defined for a particular attribute. If you define multiple eventAttribute records for a request, each eventAttribute record must be for a different attribute.

Table 18-6 eventAttribute

Field #	Field Name	Description
1	`Attribute`	Name of the attribute. Maximum length is 64 bytes.
2	`Relation1`	Relation for first threshold. Refer to the enumeration `threshold` in `snm.glue` for a list of possible relations.
3	`Threshold1`	Value for the first threshold. In the example, an event report is generated if cpu% was greater than 80. Maximum length is 16 bytes.
4	`Relation2`	Relation for the second threshold. `Threshold Not Set` indicates there is no second relation.
5	`Threshold2`	Value for the second threshold. Maximum length is 16 byte.
6	`Priority`	Defines the priority of the event. Must be either `Low`, `Medium`, or `High`.
7	`Glyph_Effect`	Action when event is reported. Refer to the enumeration `visualopt` in `snm.glue` for a list of possible actions.
8	`Audio_Effect`	Action when event is reported. Refer to the enumeration `audioopt` in `snm.glue` for a list of possible actions.
9	`Audio_File`	Name of the audio file. Maximum length is 128 bytes.
10	`Mail_To`	Mail address. Maximum length is 128 bytes.
11	`To_Program`	Shell script or program. Maximum length is 128 bytes.
12	`_relop`	Internal value. Leave blank or set to `undefined`.
13	Stop Request	Boolean indicating to stop the request in case of failure.
14	Start Request	Name of request to be started when this request is stopped.

Following the eventAttribute records is a rqstState record. See Table 18-7 for a description of the rqstState record.

Table 18-7 rqstState

Field #	Field Name	Description
1	`state`	State of the request. Set this field to `Active` to automatically activate the request when the Console is started. Maximum length is 64 bytes.
2	`timeout`	Internal value. Always set this to zero.
3	`reqflags`	Internal value. Always set this to zero.

The final record is a membership record. This record indicates in which element's subview the request glyph will appear. See Table 18-8 for a description of the membership record.

Table 18-8 membership

Field #	Field Name	Description
1	`view`	Name of the element in whose subview the request glyph appears. Normally, this would be the same as the final value of the `dataRequest` record.

18.7 Duplicate Databases

Previously, when you loaded ASCII topology databases and duplicate entries were found, SunNet Manager would abort the load operation. Starting with the current version, you have the following options when duplicate entries are found:

Abort.
Ignore duplicates and proceed with the load.
Replace the old element with the new one from the ASCII database.

The snm.conf configuration file contains the keyword snm.load-mdb-duplicate-objects to which you may add the appropriate value as follows:

Abort - database loading is aborted when a duplicate entry is found

Ignore - all duplicate entries are ignored and placed in a list in the error window as warnings

Replace - all duplicate entries are replaced by objects from the ASCII database. All duplicates are listed in the error window as warnings.

If the keyword is missing from the snm.conf file or an invalid value is specified, the Ignore value, which is the default, is implemented.