Object and set statuses

ACTIVE

Indicates that the object is currently running and TOM is managing the object’s status according to its definition.

If the object has pre-start commands defined, TOM has executed them and they returned RC=0 or specified Wait-for-Completion=No.

TOM performed the start action for the object and has received a notification that the object is active in the system.

If the object has post-start commands defined, TOM executed these commands after the object became ACTIVE and the user-defined interval has passed. Unlike pre-start command processing, TOM does not process return codes from post-start commands, unless Wait-for-Completion=Yes is specified for the command, which waits for the command to complete before executing the next post-start command.

ACTIVE-BOUNCE

This is a transitional status.

Indicates that TOM is performing a BOUNCE function, a shut down and start up, of the object.

When TOM processing restarts the object, the object’s status is ACTIVE.

When the object’s stop action is issued by the BOUNCE function, the object stops and has a status of ACTIVE-BOUNCE. If the object remains in this status, you may have to perform a RESET function with RESETOPT(ALL) or RESETOPT(STATUS) to restart the object. After the object starts, its status will be ACTIVE.

If the object status changes to ACTIVE-BOUNCE-ERR, you issue the RESET RESETOPT(RUNSTAT) command to reconcile the status with the object's state in the system.

ACTIVE-BOUNCE-ERR

Indicates that an error occurred during a bounce request.  TOM is taking action to ensure that any children of this object that specify @STATUS EQ ACTIVE in the dependency property remain active in the TOMPLEX.

It can also indicate that a STOP command has been issued during BOUNCE processing but object was not detected as DOWN during the specified timeout interval, or TOM timed out waiting for the Stop validation events.

This problem usually happens during the pre-stop, stop, post-stop, pre-start or start phases of the bounce request.  You should check the status reason and the TOM journal for additional information. This clearly indicates the nature of the problem encountered.

ACTIVE-ERR

Indicates that the object status was ACTIVE but is no longer present in the system; the object might have been stopped by an operator, some other automation task, or it might have ABENDed and does not have an abnormal-termination event defined for it.

The setting on the EXTERNAL_STOP_STATUS parameter in BBPARM member MAMINIxx determines the following statuses:

• If EXTERNAL_STOP_STATUS = ACTIVE, the object has a status of ACTIVE-ERR.
• If EXTERNAL_STOP_STATUS=STOPPED, the object has a status of STOPPED-EXTERNAL.
• If EXTERNAL_STOP_STATUS=SUSPEND, and the object's control mode is set to SUSPEND, the object has a status of STOPPED.

The object was running and had a status of ACTIVE before it was externally stopped. TOM will discover that the object was externally stopped and determine if the object should be started.

If TOM determines the object should be started and its control mode is not SUSPEND, TOM issues the start command and the object status will become ACTIVE.

ACTIVE-HOLD

Indicates that TOM has performed the stop action for the object with the STOP HOLD command and the FULLAUTO parameter.

This object’s dependent objects are not affected by this status if you defined the dependency property as @STATUS EQ ACTIVE.

TOM schedules any post-stop commands for this object after the object's status changes to STOPPED and the user-defined interval for the post-stop command has passed.

ACTIVE-HOLD-NOA

Indicates that TOM has performed the stop action for the object with the STOP HOLD command without specifying the FULLAUTO parameter.

TOM does not schedule any of the pre-stop or post-stop commands that might be defined for this object.

This object’s dependent objects are not affected by this status if the dependency property is defined as @STATUS EQ ACTIVE.

ACTIVE-SD

Indicates that the object was externally stopped and TOM is performing the start action for the object.

This is a transitory status. Normally, you might only see this status in the message log as the object changes states, or in a view if you refresh the view at just the right time. Under normal circumstances, the object should not stay in this status.

When TOM determines that an object needs to be started, the object status changes to ACTIVE-SD. TOM issues the start process and when the object successfully starts, its status changes to ACTIVE.

If a problem such as an invalid start command or invalid start event occurs, the object's status could change from ACTIVE-SD to FAILURE-CMD-INIT or FAILURE-REC-INIT.

In this case, you should examine the object's definition, correct the part that is causing the problem, and perform the RESET RESETOPT(STATUS), RESET RESETOPT(ALL), or RESET RESETOPT(RUNSTAT|OPER) function.

During the RESET process, if the object is already started, its status changes to ACTIVE and TOM does not perform additional start actions. If the object has not yet started, TOM performs the start actions and the status changes to ACTIVE.

Indicates that TOM received the abnormal termination event, which is defined in the Abnormal Termination Event field of the object’s definition, and the object has ended abnormally.

This object has a parent-to-children relationship strength of WEAK and TOM does not perform stop actions for the objects that are dependent on this object if they specify @STATUS EQ ACTIVE for the dependency property.

Correct whatever caused the abend of the object and perform a RESET function.

After the RESET function completes, if TOM determines that the object should be active, TOM performs the start actions.

BLOCKED

Indicates that the object is unavailable to run on this system.

TOM will not start the object on a BLOCKED VSL entry.

An object might also have a BLOCKED status for one of the following reasons:

• The BLOCK line command is issued from the TOBJO view
• The TOMEXEC BLOCK function is issued in an EXEC
• The BLOCK console command is issued

An object can be in this status for one of the following reasons:

• A request was made to stop this object without the RESNEXTIPL keyword (from an EXEC or console command) or the Reset at next IPL option was set to N (from the TOM user interface).

• The object was moved from the current system to another system listed in its valid system list.

  When a move occurs, the object's status is BLOCKED on the systems that it was not moved to.

• A BLOCK request has been made for this object.

  When this occurs, TOM performs the stop action specified in the definition and set the status to BLOCKED.

BLOCKED-ERR

The object is BLOCKED on this system and is supposed to be inactive; however, TOM has detected that the object is actually up.

If a failure occurs while TOM is stopping the object with a BLOCKED-ERR status, its status changes to a failure status (such as FAILURE-REC-TERM, FAILURE-CMD-TERM, and so on).

If the object goes from BLOCKED-ERR to a failure status, you can use the RESET RESETOPT=(RUNSTAT) or RESET RESETOPT=(OPER) function and TOM will either perform the start or stop actions for the object, depending upon the object's schedule and dependency criteria.

After TOM performs the stop action for the object, the object's status should return to BLOCKED. On the way to the status of BLOCKED, the object's status will be temporarily set to SCHEDULED-BLOCKED.

COMPLETE

This status occurs only for transient objects and indicates that the transient object has completed processing, and has ended.

TOM does not schedule pre-stop commands for transient objects. A transient object stops on its own and TOM does not manage stopping the object.

TOM cannot start a transient object during the life of a Definition Base after its status reaches the COMPLETE status. An operator can start the object using the START command with the FORCE option.

Indicates that TOM has received the abnormal termination event that is defined on the Abnormal Termination Validation field of the object’s definition and the object has ended abnormally.

You must correct the error that caused the abend of the object and perform a RESET RESETOPT(ALL), RESET RESETOPT(STATUS), or RESET RESETOPT(RUNSTAT|OPER) function. If the object's schedule and dependency criteria indicate that object should be active, TOM starts the object.

TOM might also restart any of the dependent objects.

FAILURE-AOLINK

FAILURE-CMD-INIT

FAILURE-CMD-TERM

FAILURE-CMDCOUNT

Indicates that the START command limit has been exceeded by the command counter.

The command counter is incremented each time the object is changed to ACTIVE.

To reset the start command counter, perform a RESET RESETOPT(ALL), RESET RESETOPT(STARTCMDCT), or RESET RESETOPT(OPER|STARTCMDCT) function.

During a RESET function, TOM determines if the object should be started and performs start actions.

To prevent this failure status, you can adjust the settings in the Reset start count at term or the Reset start count after fields in the object definition. Adjusting the value in one or both of these fields can cause TOM to reset the start command counter either when the object is stopped by TOM, or after the prescribed period of time passes after the object's status becomes ACTIVE.

FAILURE-CONFIRM

Indicates that you have specified YES in either the Verify Start or the Verify Stop field of the object definition, and you replied NO to the WTOR that is generated.

TOM does not perform object START or STOP actions.

When TOM is trying to restart an object during a RESET function and the object goes into FAILURE-CONFIRM status, TOM issues a start request if the object dependency and schedule criteria define that the object should be running.

When TOM issues a request to start the object it issues the WTOR again. Reply YES to the WTOR to avoid returning to the FAILURE-CONFIRM status.

If the object dependency and schedule criteria indicates the object should not be running, TOM changes the status to STOPPED.

Performing a RESETOPT=(RUNSTAT) function against an object that TOM was stopping but has gone into FAILURE-CONFIRM status causes TOM to change the status to ACTIVE.

FAILURE-PRESTART

A nonzero return code was returned from a pre-start command while attempting to start an object (unless Wait-for-Completion=No was specified for the command).

You can define an object with one (or more) pre-start commands. If you attempt to start an object and you do not specify an option to bypass automation, TOM schedules the pre-start commands. If one (or more) of the commands return a non-zero return code, TOM changes the object's status to FAILURE-PRESTART.

EXEC-type REXX pre-start commands must contain IMFEXEC EXIT CODE(#) command. The '#' represents a numeric value it specifies the return code that the command returns to TOM. If Wait-for-Completion=No is specified for the pre-start command, the return code is ignored and the next pre-start command is executed or the start command is executed.

FAILURE-PRESTOP

A nonzero return code was returned from a pre-stop command while attempting to stop an object (unless Wait-for-Completion=No was specified for the command).

You can define an object with one (or more) pre-stop commands. If you attempt to stop an object and you do not specify an option to bypass automation, TOM schedules the pre-stop commands. If one (or more) of the commands return a non-zero return code, TOM changes the object's status to FAILURE-PRESTOP.

EXEC-type REXX pre-stop commands must contain IMFEXEC EXIT CODE(#) command. The '#' represents a numeric value it specifies the return code that the command returns to TOM. If Wait-for-Completion=No is specified for the pre-stop command, the return code is ignored and the next pre-stop command is executed or the stop command is executed.

FAILURE-PROPERTY

Indicates an attribute for the object is missing or invalid.

This status might be accompanied by messages in the TOM log, revealing more information about the object definition.

The status of an object could be changed to FAILURE-PROPERTY for the following reasons:

• If an Active Check Program returned an invalid result code

• If an object's unique identifying information (such as STC name for an STM object) contains one or more unresolved variables

This condition can be corrected by correcting the object definition, and performing the RESET function (including a RESET RESETOPT=(RUNSTAT) function) for the object.

FAILURE-REC-INIT

Indicates a START action has been issued but object was not detected as up/active during specified timeout interval, or TOM timed out waiting for the Start validation events.

If an object goes into this status, you should review the following object definition values:

• If the object definition includes start events, ensure that at least one event has a valid message ID.

  Depending on the event type, you can review the syslog, Journal or ALERT queue to find a valid message ID.

• Review the start command timeout value and ensure that enough time is defined.

  The timer starts after TOM processing issues the start command. The timer period ends when TOM detects a start event for the object.

After reviewing these items, perform a RESET RESETOPT=(RUNSTAT) function for the object. If the object is already running in the system, the status should change to ACTIVE. If the object is not running in the system, TOM performs the start actions.

FAILURE-REC-TERM

Indicates a STOP command has been issued but object was not detected as down/inactive during specified timeout interval, or TOM timed out waiting for the Stop validation events.

If an object goes into this status, you should review the following object definition values:

• If the object definition includes stop events, ensure that at least one event has a valid message ID.

  Depending on the event type, you can review the syslog, Journal or ALERT queue to find a valid message ID.

• Review the stop command timeout value and ensure that enough time is defined.

The timer starts after TOM processing issues the stop command. The timer period ends when TOM detects a stop event for the object.

After reviewing these items, perform a RESET RESETOPT=(RUNSTAT) function for the object. If the object is already inactive in the system, the status should change to LOCKED. If the object is running in the system, TOM performs the stop actions.

LOCKED

The object with a LOCKED VSL entry will not be started on the system until the next IPL (unless it is UNLOCKed before the next IPL).

The object status is changed to STOPPED at the next IPL, which will start TOM if it's dependencies and schedules are satisfied.

LOCKED-ERR

Indicates that TOM discovered an object with a LOCKED status is actually active in the system.

If a failure occurs while TOM is stopping the object with a LOCKED-ERR status, its status changes to a failure status (such as FAILURE-REC-TERM, FAILURE-CMD-TERM, and so on).

If the object goes from LOCKED-ERR to a failure status, you can use the RESET RESETOPT=(RUNSTAT) function and TOM will either perform the start or stop actions for the object, depending upon the object's schedule and dependency criteria.

After TOM performs the stop action for the object, the object's status should return to LOCKED. On the way to the status of LOCKED, the object's status will be temporarily set to SCHEDULED-LOCKED.

PENDING

When an object moves from one system to another, the object’s status is either SCHEDULED-LOCKED or SCHEDULED-BLCKED on the system the object is moving from. The status is PENDING on the target system.

When the move completes, the object's status is LOCKED or BLOCKED on the system that the object moved from. The object status is ACTIVE on the target system.

If a failure occurs while stopping the object before it is moved, the object has a failure status on the system that it moved from and a status of PENDING on the target system. To resolve this, perform a RESET RESETOPT=(RUNSTAT) for the object.

SCHEDULED-START

A request to START the object is pending. TOM has issued a command to the initialization controller and the controller has not yet begun to process the command.

This status is visible for a very short period of time.

TOM object evaluation processing has determined that the dependency and schedule criteria for the object to be running have been met and TOM is sending a request to another subtask in TOM to start the object.

SCHEDULED-STOP

A request to STOP the object is pending. TOM has issued a command to the termination controller and the controller has not yet begun to process the command.

This status is visible for a very short period of time.

TOM object evaluation processing has determined that the dependency and schedule criteria for the object to be inactive have been met and TOM is sending a request to another subtask in TOM to stop the object.

SCHEDULED-LOCKED

The object is in the process of being stopped with the intended status of LOCKED when the stop completes.

This status is visible for a very short period of time.

TOM is issuing a request to another subtask in TOM to stop the object.

SCHEDULED-BLOCKED

The object is in the process of being stopped and when it has stopped, will have the status of BLOCKED.

This status is visible for a very short period of time.

TOM is issuing a request to another subtask in TOM to stop the object.

STARTING

TOM is starting the object, and is waiting for the start validation event to arrive. An object can also be in STARTING status if TOM is processing the START RETRY commands.

Under most circumstances, an object does not stay in this status for a long time. If you think the object has been in this status for a long time, you can end the starting process by performing a RESET function and specify the RESETOPT=(INFLIGHT) parameter.

If the object does not start after performing this action, TOM will attempt to start the object again.

If the object starts after performing this action, TOM does not attempt to start the object and sets the object status to ACTIVE.

STOPPED

TOM has stopped the object, which can occur for the following reasons:

• The calendar or schedule indicates the object should be stopped.
• An object or set of objects that this object depends on has been stopped, locked, or blocked.
• The object has multiple entries in its valid systems list, is not in an exception condition, and is active on one system but not active on the system where the status is STOPPED.
• The object's IPLLEVEL does not match the current IPLLEVEL for the  TOM/system.
  

TOM schedules any post-stop commands defined for this object after the object's status becomes STOPPED and after the defined time interval has passed.

STOPPED-EXTERNAL

Indicates that the object has stopped externally.

This status allows any dependent objects of the externally stopped object to remain active if they have a weak dependency relationship.

If a strong dependency relationship is present, TOM also stops the child objects if the dependency property is @STATUS EQ ACTIVE.

The setting on the EXTERNAL_STOP_STATUS parameter in BBPARM member MAMINIxx determines the following statuses:

• If EXTERNAL_STOP_STATUS = ACTIVE, the object has a status of ACTIVE-ERR.
• If EXTERNAL_STOP_STATUS=STOPPED, the object has a status of STOPPED-EXTERNAL.
• If EXTERNAL_STOP_STATUS=SUSPEND, and the object's control mode is set to SUSPEND, the object has a status of STOPPED.

The object was running and had a status of ACTIVE before it was externally stopped. TOM will automatically discover that the object was externally stopped and determine if the object should be started.

If TOM determines the object should be started and its control mode is set to ACTIVE, TOM performs the start action and the object status will be ACTIVE-SD until the start completes; then the status will be ACTIVE.

STOPPING

Indicates that a stop request is in progress.

TOM has internally scheduled the object to STOP because object or calendar dependencies are not met.

Under most circumstances, an object does not stay in this status for a long time. If you think the object has been in this status for a long time, you can end the stopping process by performing a RESET function and specify the RESETOPT=(INFLIGHT) parameter.

If the object does not stop after performing this action, TOM will not attempt to stop the object again and sets the status to ACTIVE.

If the object stops after performing this action, TOM does not attempt to stop the object and sets the object status to STOPPED, LOCKED or BLOCKED.

UNKNOWN

Indicates any of the following situations:

• RESET RESETOPT=(INFLIGHT) was requested for the object and the system corresponding to the Valid System List entry with UNKNOWN status has not yet reconciled the object's state with its TOM status.

• The object is newly defined or a new system VSL entry has been added to the object and the system corresponding to the VSL entry with UNKNOWN status has not yet reconciled the object's state with its TOM status.

• The object's Extension logic (such as WRM) allows states of up/active/ down/inactive, and unknown and the item associated with the object (such as a WLM Resource) is in the unknown state.

An object with an UNKNOWN status might affect the shutdown and start-up of objects if the object with the UNKNOWN status is in the dependency chain.

As TOM cannot determine the status of the object, TOM must treat it as STOPPED during start-up and ACTIVE during shutdown.

WAIT-START

This status occurs when the first system in a sysplex is IPLed and it encounters a RESTART-ONLY object.

A RESTART-ONLY object is an object that was defined to have its status monitored by TOM but is externally started. When TOM encounters a RESTART-ONLY object, TOM sets that object’s status to WAIT-START on all systems, which prevents TOM from starting the object.

After a RESTART-ONLY object either is found ACTIVE or is externally started, its status changes to STOPPED on all systems except the system on which it is active. This process happens only the first time that TOM is started after an IPL of the system.

TOM does not schedule any pre-start or post-start commands defined for a RESTART-ONLY object when it starts in the system for the first time after an IPL, and the status changes from WAIT-START to ACTIVE.

Subsequent starts of the object by TOM will result in the pre-start and post-start commands defined for the object being scheduled for execution.