Given a sensor such as the one below that is reporting queues that are put Inhibited based on dynamic sensors.
PUT Inhibited
+ Depth 0: Queue(TESTA), QMGR(Prod_QMGR1), Node(ProdSvr1)
+ Depth 0: Queue(Q1), QMGR(Prod_QMGR1), Node(ProdSvr1)
Suppose you want to exclude any TEST queues from the list. You exclude TEST* PUT facts using the following on the Select Facts to Monitor.
Include Facts:
- {QUEMON)\{GROUP}\*\*\*\*\PUT
- {QUEMON)\{GROUP}\*\*\*\*\CURDEPTH
Exclude Facts
- {QUEMON)\{GROUP}\*\*\*\TEST*\PUT
This doesn't work and it still shows TESTA in the results as before.
The reason for this is the difference between subscribing to facts and referencing facts. Excluding the PUT fact would have worked if it was only one fact subscribed, but in this case there are 2 facts subscribed.
When there are 2 facts being subscribed, excluding one (PUT) from the subscription, still leaves the other (CURDEPTH) as subscribed. Whenever CURDEPTH changes, the policy is notified. At this point, the policy recognizes that PUT was referenced and so it looks it up. The end result is that the policy works almost the same without or with the exclude above. The one difference is that since PUT is not subscribed, if PUT is changed and CURDEPTH is not changed, the policy would not be notified of this and would not reflect the change.
To get the desired behavior, there are 2 options. We could exclude both facts (PUT and CURDEPTH) or you can use a generic for the facts using either of the exclude options below.
- {QUEMON)\{GROUP}\*\*\TEST*\*
- {QUEMON)\{GROUP}\*\*\TEST*
These will exclude all TEST* facts from the subscription and the desired result of no TEST queues will be produced.
PUT Inhibited
+ Depth 0: Queue(Q1), QMGR(Prod_QMGR1), Node(ProdSvr1)
In summary, it is important to understand the subscription process and how the subscriptions affect the policy behavior.