Object status and dependencies

TOM attempts to keep the status of every normal object as ACTIVE (which means it is running and available). However, due to various system conditions and changes, an object can have many object statuses (see Object-and-set-statuses).

An object’s status can have profound effects when one object is defined to be dependent on the status of another object. TOM will make a normal object’s status ACTIVE only when the dependency on another object (or set) has been satisfied. You can define these dependencies between objects (and objects and sets) on the object ADD or EDIT dialog.

An object can have more than one parent. Multiple dependency entries are specified in the same manner that dependencies are specified for multiple events or multiple pre or post commands. 

Each dependency entry specified in an object's definition will be evaluated. The results will be ANDed together by default to provide an overall dependency check result. All of the dependency checks for an object must evaluate as 'TRUE' in order for the object's dependency requirement to be met.

Sometimes there are situations where an object should be active only when one parent object is active but another parent is not. In another example an object might need to be active when one parent is active or another parent is active but not necessarily both.

Handling these complex conditions often requires a User Property containing a variable in its value. User-written automation can maintain the value of the variable to satisfy the dependency conditions.

Instead, TOM can handle these situations by TOM by defining a complex dependency relationship for a child object. For example, suppose the CICS Transaction Gateway (CICSTG) must be started as soon as one of many CICS subsystems becomes ACTIVE. The CICSTG object should only stop (for example, at SHUTSYS) when all of the CICS subsystems are down and have a status of LOCKED or BLOCKED.

In this example, there are 3 CICS subsystems: CICS1, CICS2, and CICS3. The following describes how the CICSTG object depends on the three CICS subsystems: 

Each dependency entry when evaluated returns a result of either TRUE or FALSE. If the dependency is satisfied, the result of TRUE is returned. If is not satisfied, the result of FALSE is returned.

To use a dependency entry as part of a complex dependency relationship, you must provide a unique one- to eight-character expression ID. For example, these dependencies can have expression IDs D1, D2, and D3.

Define a rule using the expression IDs in the CICSTG object definition to obtain the resulting fact of dependency satisfied or not satisfied. This rule is also known as the Dependency Formula:

If any of the dependencies associated with D1, D2, or D3 returned a result of TRUE, TOM considers the dependency requirement for CICSTG as satisfied. TOM would start the CICSTG object.

To change the condition so that the CICSTG object is started when D1 and D3 had a result of TRUE or when D1 had a result of TRUE and D2 had a result of FALSE, you can set up the following dependency formula:

You can use the Simulate command from the Dependency Formula panel in the object add/edit dialog to determine if the formula you have written will evaluate the complex dependency the way you want.