Understanding Phrases


Overview

Tasks

Included with

Tivoli Change Management administration

Overview

What are phrases?

In Tivoli Change Management, a rule definition phrase consists of the following:
Component Description
Table The name of the Tivoli Change Management database table that contains the field (attribute) you want to include in the rule definition.
Attribute The database field that contains the data you want to include in the rule definition.
Operator One of the <, >, =, <=, >=, and <> operators you use to specify the selection criteria for the rule.
Value The actual field value that you use to determine selection in the rule.

For example, the following phrase specifies all CHANGE table records where the Status_ID field contains the value completed:

Change:Status_ID=completed

Notice that when a definition phrase is displayed, it appears with a colon separating the table name and the attribute. Do not use a colon in the Value box.


Tasks

Constructing phrases You can use the following operators to combine single phrases and create a comprehensive rule phrase definition.
  • And

Use the And operator button to link two phrases together. The accessed data must match both conditions. Choose the And button after inserting the first phrase and before inserting the second phrase. In the following example, the use of the And operator specifies changes with a completed status and an event date prior to March 31, 1999:

Change:Status_ID=completed AND Change_History:Event_Date < 03/31/99

  • Or

Use the Or operator button to link two phrases together. Data can match either phrase. Choose Or after inserting the first phrase and before inserting the second phrase. In the following example, the use of the Or operator specifies changes with a completed status or with an event date prior to March 31, 1999:

Change:Status_ID=completed OR Change_History:Event_Date < 03/31/99

  • Not

Use the Not operator button before inserting a phrase to reverse the true or false status of the phrase. For example, the use of the Not operator in the following phrase specifies all changes except those with a completed status:

NOT Change:Status_ID=Completed

which would be equivalent to the phrase:

Change_Status_ID<>completed

You can use the Not operator with the And and Or operators. The following example specifies all changes with a completed status and an event date greater than or equal to March 31, 1999:

Change:Status_ID=completed AND NOT Change:Event_Date<03/31/99

  • Using Parentheses

Use the parentheses buttons to insert parentheses before, after, or between phrases and operators in the list. Just as you use parentheses in mathematical statements to control the order of calculation, you use parentheses here to control the order in which phrases are interpreted.

In the following example, parentheses are used to define a rule that applies to two groups of changes (completed changes with an event date prior to March 31, 1999, and saved changes with an event date after March 31, 1999):

(Change:Status_ID=completed AND Change_History:Event_Date<03/31/99) OR (Change:Status_ID=saved AND Change_History:Event_Date>03/31/99)

Optimizing phrases

When Tivoli Change Management evaluates a phrase at run time, it uses the following logic:
  1. If all conjunctions are And's (there are no Or conjunctions) the evaluation routine will exit and return false as the overall condition as soon as the first condition resolves to false. The conditions are evaluated from left to right.
  2. If all conjunctions are Or's (that is, there are no And conjunctions) the evaluation routine will exit and return true as the overall condition as soon as the first condition resolves to true. The conditions are evaluated from left to right.
  3. If And and Or conjunctions are used in a phrase, then the entire phrase must be evaluated in order to determine the overall true/false resolution.

Using this evaluation logic, you can optimize the definition of rule phrases which has a direct impact on run time performance. If you have a phrase that has multiple conditions with all And conjunctions, then by defining the condition that has the highest probability of evaluating to false on the left side of the phrase definition, you save the processing time that would otherwise be used to evaluate the additional conditions.

For example, assume that:

  1. A rule phrase is defined to detect a Change:Status_ID is completed, the Change:Cost is greater than 100, and the Change:Category is software.

    To optimize the performance of this phrase, the evaluation of the Status_ID is defined first because only a relatively small number of evaluations (compared to all change transactions) have a Status_ID of completed.
  1. Depending on the conditions at your location, the remaining two conditions could be defined in either order, but assume that the majority of the change costs are less than 100, and that the majority of the changes are for the category software. Based on these assumptions, the optimal rule definition is:

    Change:Status_ID = completed AND Change:Cost > 100 AND Change: Category = software
  2. However, if the rule phrase is defined to detect any of the above conditions, then the ordering of the conditions is reversed. By defining the condition in the rule phrase first that has the greatest likelihood of evaluating to true, you take advantage of early exit logic.

    Change:Category = software OR Change:Cost > 100 OR Change:Status_ID = completed