They call if flipper

It's usually a good idea to test situation logic when designing and deploying new alerts into the Tivoli Portal. One technique to test a situation is to set the threshold artificially low so that the alert will be more likely to be true and fire. For example, if you you want to test out a z/OS average system CPU alert and CPU in the environment in question usually runs at around 50% or 60%, setting the alert at a lower level like 20% will usually mean the alert should fire, once the situation is saved and started. Once you've tested the alert you can set the threshold at the desired level, and you are done.

The down side of the "set the threshold low" scenario is that once you set the alert, it will, if done correctly, fire and stay true. But what if you want to test out scenarios where a situation is going true, then false, and then perhaps back to true? That's where the "flipper" technique comes in handy. With flipper you take a situation that is likely to fire and add timer logic. As I show in the example, half the time when seconds counter of local time is GT 30 seconds, the situation will be true. When time is 30 seconds or less, the situation will flip back to false. This is a handy technique to drive alert activity for test purposes.