The status of a virtual alarm’s latched and acknowledgment components are derived from the corresponding statuses of its sub-alarms. This has a side effect—for virtual alarms that are calculated using pessimistic (AND) logic tables, resetting the latch will not necessarily make the status of the latched component of the virtual alarm the same as the status of its current component.

Resetting a latch on a virtual alarm sets the latched component of each of its sub-alarms to the value of its current component. In turn, the statuses of each of the sub-alarms contribute to the reset status for the virtual alarm. If there were virtual alarms included as sub-alarms, then their sub-alarms are reset to the current status, and all these sub-alarms contribute to the status of the top level virtual alarm. This pattern continues through all the levels of the virtual alarm and is referred to as virtual alarm recursion.

In some circumstances, performing actions affecting a large number of complex virtual alarms—such as Reset all latches, or Acknowledge all—may result in a loss of communication with a controlled device. A system property is available to prevent an iControl GSM server from broadcasting alarm actions to specific GSMs. On the server where the broadcasts originate, in /usr/local/iControl/bin/conf/java_gsm.properties/, set the icontrol.gsm.disableActionDispatch property to the appropriate value for your purposes. For example, to disable action dispatches to all remote GSMs, set icontrol.gsm.disableActionDispatch to true; to disable action dispatches to specific GSMs, list the IP addresses of the GSMs you wish to exclude from action dispatches (e.g., icontrol.gsm.disableActionDispatch=10.10.10.10, 10.20.20.20).

When iControl displays a virtual alarm’s latched or acknowledged component, it determines the status (or color) by comparing its sub-alarms according to a pessimistic logic table.