Using System State Manager › ops--How Transient States Work

ops--How Transient States Work

States such as STARTING, which change to something else without SSM intervening, are called transient states. States that do not change, unless SSM takes action are called stable states.

SSM reacts to changes in the finite state machine by executing actions that are defined in its actions table. So, the DOWN_UP transition must initiate an action to make the resource leave the (stable) DOWN state.

Any action that is defined for a transient state may or may not execute, depending on the timing of events, nor does it need to execute for things to happen:

• The action that is defined for a transient state may not execute if the triggering event occurs before SSM discovers that state. If SSM queues and executes the action, the current state of the machine can change by the time the action routine begins. Therefore, if you define any actions involving transient states such as STARTING, make them actions that do not necessarily have to execute.

  For example, you want to define an action for a transient state such as STARTING that executes an automation procedure that checks in 2 minutes to see if the current resource state is UP and issues an error message if the state is anything else. This action is a safe, prudent action to take, because if the rule executes, an error condition can exist. Actions such as issuing a VARY command or setting a critical global variable, or any action that is required for the resource that is starting, are not safe to take for the STARTING transition, because these actions may not execute (and if they do, they may execute after the state of the resource has already changed to UP).

• Actions that are defined for transient states execute mostly for resources that are defined in the first table listed in the directory table. Remember that the directory table lists the resource tables in alphabetical order. But, the lower resources are in the table list order in the directory table, the more likely it is that external state changes occur before the actions defined for transient states execute, or that these actions never execute.
• If you have critical actions that must be taken for transient resource states, the safest place to specify those actions is in the rules packet for the applicable resource type. In our example, if you want to take a critical action at START TSO time, execute this action at the same point where you detect and set the STARTING state. Complete this action before you update the table row for the appropriate resource.