Command failures
If TOM does not receive notification of this event before the specified time limit is exceeded, processing for this object goes into recovery mode.
To perform recovery of a failed command, TOM uses the list of optional retry commands that you can define as part of each object’s definition. TOM issues the retry commands until they are all issued or TOM is notified that the event has occurred.
When no retry commands are specified or all retry commands are exhausted, the object’s status is set to
- FAILURE-REC-INIT for objects that did not start
- FAILURE-REC-TERM for objects that did not stop
The following factors can determine whether a retry command is issued and how it is issued:
- Schedule dependency
TOM selects the first retry command that is defined for the object. Each retry can be defined with a schedule dependency, which specifies when a command can be issued. If the time that is specified in the dependency definition indicates that the command is not to be issued at this time, TOM moves to the next command in the list. If a retry command is not defined with a schedule dependency, TOM issues the retry command. Command count
Each START or STOP RETRY command has a command count attribute and a command interval attribute. The count indicates how many times the command can be issued. The interval controls how long to wait between issuing commands. The task that issues the command waits either until TOM receives the specified event (object is now ACTIVE for a start, STOPPED, LOCKED, or BLOCKED for a stop) or until the waiting period expires.When the wait period is exceeded, TOM checks the command count attribute. If the command count has not been exceeded, TOM continues to issue the RETRY command. When the count is exceeded, the counter is reset, and the next command is issued.