|
|
After product software packages have been installed with the installation script and configured using the quickconfig tool, the agents-ACB and CMA-contain configuration information that enables them to function. However, your operational environment may cause configuration changes to be made manually at a future time. The next few chapters will enable you to make these changes by providing information about parameters and file properties. Sample files—located in the $PARMLIB/parms/<Agent>/Samples directory—also provide valuable insight and assistance.
The following sections provide information concerning attribute file hierarchy and the domain services routing table. An overview of various configuration requirements is also provided that may prove useful as reference material.
When an object is initialized, it is assigned default attribute values; the default values are defined in the object software itself. The object then reads a series of files that you can administer to override the defaults. The object reads these files sequentially. If a file exists, only the attributes specified in the file will overwrite the existing values of attributes.
You need to understand the hierarchy of these files (dictated by the order in which the files are read) so that you can configure the objects to behave the way you intend them to. This scheme is such that files read first are intended to have the least override authority and the broadest scope. Files read last have final override authority and the narrowest scope. Use of attribute configuration files should be limited to overriding attribute values that need to be overridden due to inappropriate values at a given level of the hierarchy. Superfluous complexity can arise if you needlessly override default values with the same value.
You will find a list of attributes for each object in the corresponding object configuration section. The attribute file hierarchy is described below. The process occurs in the following order:
Default Values: Attributes are set to default values at object initialization before any configuration files are read.
Global BASE Attribute File Overrides: These settings, defined in $PARMLIB/parms/BASE/Attrib.Global, override the default values of BASE attributes.
Global Object-Specific Attribute File Overrides: These settings, defined in $PARMLIB/parms/<agent_name>/Attrib.Global, should be kept empty by convention. This is reserved for future use.
Node-Specific Attribute File Overrides: These settings, defined in $PARMLIB/parms/ <agent_name>/Attribute.<host name>, override the values of both BASE and agent-specific attributes that were in effect after reading the Global Base Attributes file overrides.
The resultant values from the cumulative effect of the attribute file overrides on the default values are then called the current attribute values in memory.
Changes to object attribute configuration files take effect when you start an object. Therefore, if an object is running and you make attribute configuration file changes, you will need to stop and start the object. However, it is possible to change certain attribute values in memory via SNMP using the atts command or an SNMP manager.
There are two general formats used for uOne configuration files:
Common attribute files are a particular type of configuration file (using the keyword parameter list format), in which each keyword is an attribute name and each keyword has one parameter that specifies a value for the named attribute. Attributes define the way the DAP system behaves. By modifying a parameter's value, you can customize the behavior of your DAP system.
Common attribute files are formatted as lists of AttributeName AttributeValue pairs:
AttributeName AttributeValue
.
.
.
AttributeName AttributeValue
Step 2 Each attribute keyword is followed by one or more parameters, which are separated by white space.
Step 3 Misspelled keywords are treated as comments.
Step 4 Any unrecognized keyword is treated as a comment.
Step 5 Any invalid parameter terminates initialization.
Step 6 Defaults are supplied for all unspecified keywords.
Step 7 Comments are indicated by a # in the first column.
Each object must have a configured domain services routing table. This table contains the entries for all services required by a particular object. The table provides the object with a listing of what objects and hosts are available in its DAP domain to provide such services. Certain agents use their domain services routing tables to determine which host and objects to bind with and route messages to. The routing tables are located in $PARMLIB/parms/<agent_name>/Route.<host name>.
The domain services feature takes a token and agent name; then it looks for a match against the table tokens specified in the routing tables. The token is based on the DomainLookup parameter set in $PARMLIB/parms/TNT/Attrib.<host name>. If the parameter is set to DNIS, then the token will be DNIS. If it is set to RDNIS then the token will be RDNIS. If it is not set, the default is RDNIS. If the startapp fails, then it will automatically try a second time and will switch the token from DNIS to RDNIS or from RDNIS to DNIS. It will perform another domain services route table lookup.
The startapp searches each row of the routing table from top to bottom and left to right. When a match is found, the message is routed to the agent at that host name. Because the table is searched from top to bottom, it is important to place the most specific (i.e., longest) tokens at the top of the table, and the least specific tokens at the bottom of the table. For example, the token 8045551000 is more specific than token 8045551, and should be placed at the top of the table to ensure a match. The token 804 is the least specific, and should be placed at the bottom of the table.
If a matched host and agent are unable to provide service (perhaps due to a capacity overload or service interruption), the table may be searched again from just beyond the current point to find another that can provide service. This process continues until either a matching agent host handles the request or the end of the table is reached (implying failure to bind). The ability to use hosts is dependent upon the implementation of the APIs used by an application.
Token matches are used with both domain services routing and the schedule tables. Token matching is based on a match of two tokens: a passed token and a table token. If the passed token is longer than the table token, the passed token is truncated to the length of the table token during the comparison. If the passed token is shorter than the table token, there will be no match. Therefore, to guarantee a match, the passed token must be longer than or equal to the table token. The passed token within uOne is often a phone number. In the following example, "no" indicates there is no token match, and "yes" indicates there is a match.
| Table Tokens | |||
| Passed Token | 804555 | 8045 | 804 | 8 |
8045557701 | yes | yes | yes | yes |
5557701 | no | no | no | no |
8047621001 | No | no | yes | yes |
Each SERVICE entry has the following format:
Example
SERVICE ObjectType HostName Token1 [Token2 [Token3 [...]]]
The following table describes the parameters and valid values for each.
| Parameter Name | Description | Valid Values and Defaults |
|---|---|---|
ObjectType | An identifier used to specify the kind of object to which this service entry will route. This object type is to provide a service. | A three-character object type identifier. Valid values are: TNT: TNT Agent Default not applicable. |
The host name of the machine on which the Object Type specified in the parameter "ObjectType" resides. This should be a valid host name. (The combination of the ObjectType and HostName makes a particular object unique in an DAP domain because only one instance of an object of a specific type can be running on a host at a given time.) | A valid host name. Default not applicable. | |
Token | The token string that is used to select the appropriate host to provide the service designated by the object type. Multiple tokens may be listed. | A valid token string. * can be used as a wild card token, matching any token. Default not applicable. |
SERVICE APP host804 * SERVICE TNT host804 * |
Posted: Mon Sep 25 20:25:48 PDT 2000
Copyright 1989-2000©Cisco Systems Inc.