IBM Tivoli OMEGAMON XE V3.1 Deep Dive on z/OS

Chapter 5. IBM Tivoli OMEGAMON XE performance optimization 171

alerts to the Tivoli Enterprise Portal Server and are not eligible for situation

synchronization.

If you have three situations that are eligible for synchronization in one

synchronized data collection, and you add them to policies, the result will be

additional schedulings of the collector. Depending on the level of the code, the

behaviors are:

򐂰 Level 350 and level 360: Policies have no impact on synchronization eligibility.

A policy-based situation is always a separate schedule and the second

schedule is never eligible for synchronization. The original situation is eligible

for synchronization. Level 350 is shipped with the IBM Tivoli OMEGAMON XE

on z/OS V100 or V220. Level 360 is shipped with the IBM Tivoli OMEGAMON

XE on z/OS V3.1.0.

򐂰 IBM Tivoli Monitoring V6.1: Makes the original situation not eligible for

synchronization but shares the collected data with the policy. This offers some

processing reduction compared to previous levels. ITMS:Engine V400 is

shipped with the IBM Tivoli Monitoring V6.1 solutions and can be enabled to

support IBM Tivoli OMEGAMON XE on z/OS V3.1.0.

In a policy, the Evaluate a Situation Now activity does not actually start the

situation, it just performs one-time sampling of data; however, Wait Until A

Situation is True activity does start the situation.

5.4.7 Embedded situations

Embedded situations are inserted into the formula of another situation, called the

embedded or parent situation. The properties of the parent situation override

those of the embedded situation. Thus, the parent situation uses its interval to

drive a take sample for the data required from the embedded situation. You might

use embedded situations to look for time-dependent workload issues.

The embedded situation runs independent from the original (non-embedded)

form. When the same situation is embedded in several different other situations,

they are triggered independent of each other, which can cause excessive

situation evaluation and unnecessary processing. However, when embedding

several product-specific situations into a single parent situation, each situation

runs only once (as long as none of the embedded situations are autostarted).

An example of embedded situation usage is to provide a time-sensitive situation.

Instead of changing all situations to include time checking, you can use

embedded situations. There are two approaches to this. The following example

illustrates the differentiation of weekday and weekend situations:

򐂰 Create a common Weekday situation that detects the day of the week to be

greater than or equal to 2 and less than 6 (Monday to Friday). Now embed all

172 IBM Tivoli OMEGAMON XE V3.1 – Deep Dive on z/OS

weekday-sensitive situations into the Weekday situation. This means that if

you have 20 situations embedded in the Weekday situation, then the

Weekday situation will be executed 21 times if Weekday is autostarted. This

can mean unnecessary processing.

򐂰 Another alternative is to have the Weekday situation embed all situations that

must be evaluated on a weekday. This removes the overhead of the additional

20 Weekday situations evaluation. However, the generated event will be a

generic one, called Weekday. (You could use a more meaningful name for

Weekday, such as CICS_Weekday_Alerts, as shown in Figure 5-13). This

situation checks to see whether the day of the week is Monday through Friday,

and if true, it evaluates the situation CICSplex_AtMaxTask_Critical.

Figure 5-13 Embedded situation - CICS_Weedkday_Alerts

Any time you use embedded situations, neither the parent nor child are eligible

for situation synchronization. This may cause the product-specific situation to run