|
|
When you install DAP software, no configuration files for that software are installed. You must create configuration files before running your DAP software. However, sample files - located in the Samples directory - are provided to assist you in this task. The following section describes some Attribute File Hierarchy and the Domain Services Routing Table. We will also touch on some common commands such as how to start objects, stop objects and reload their configuration files. After the common topics are described we will discuss configuration requirements for each object type.
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 over-ride 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.
It is important you understand the hierarchy of these files (dictated by the order in which the files are read) so 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. Much needless 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.<hostname>, 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 is 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:
ini
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 an attribute'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 1 All attributes are defined using keywords, which must start in the first column.
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 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 objects 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.<hostname>.
The Domain Services feature takes a Token and object name, and looks for a match against the Table Tokens specified in the Routing Tables. The token is based on the DomainLookup attribute set in $PARMLIB/parms/TNT/Attrib.<hostname>. If the attribute 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 RDNIS to DNIS. It will do 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 object at that hostname. 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 object 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 object 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:
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 hostname. (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 19:19:54 PDT 2000
Copyright 1989-2000©Cisco Systems Inc.