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 schedules these commands and the command has returned a zero (0) return code.

TOM performs 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 schedules these commands after the object becomes ACTIVE and the user-defined interval has passed. Unlike pre-start command processing, TOM does not process the return codes from the post-start commands.

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 must perform a RESET function with RESETOPT(ALL) or RESETOPT(STATUS) to restart the object. After the object starts, its status will be ACTIVE.

When the object’s start command is issued by the BOUNCE function, the object starts and has a status of ACTIVE-BOUNCE. If the object remains in this status, you must perform a RESET function with RESETOPT(ALL) or RESET 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-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 set to ACTIVE, 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=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. Unlike pre-stop processing, TOM does not process the return codes from the post-stop commands.

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=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 Journal 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.

ACTIVE-ABENDED

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 an object dependency strength of WEAK and TOM does not perform stop actions for the objects that are dependent on this object.

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 you have moved the object to another system, which makes the object unavailable to run on this system.

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

An object or set 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 sets the 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(STATUS) or RESET RESETOPT(ALL) 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 schedules post-start commands for a transient object in the same way as for a normal object.

TOM schedules any post-stop commands for this object after the object's status changes to COMPLETE and the user-defined interval for the post-stop command has passed. Unlike pre-stop processing, TOM does not process the return codes from the post-stop commands.

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. Because TOM does not manage stopping the object, TOM cannot determine when to schedule a pre-stop commands.

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.

FAILURE-ABENDED

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 also restarts any of the dependent objects.

FAILURE-AOLINK

Indicates that TOM has lost communication with the MainView AutoOPERATOR BBI-SS PAS.

The link is re-established when the MainView AutoOPERATOR PAS initialization is complete and TOM is active.

This status occurs for an object when the MainView AutoOPERATOR PAS that is associated with TOM has failed, and TOM (or a user) makes a request to start or stop an object in the active definition base.

Restart the MainView AutoOPERATOR PAS and objects in this status will change back to either ACTIVE or STOPPED.

FAILURE-CMD-INIT

Indicates that TOM encountered an error while attempting to issue the START command for the object.

The following situations can cause an object to have this status:

• A user (either from the UI or from the console) or an EXEC issued a START, UNLOCK, or UNBLOCK function, and specified an invalid value for the CMDNUMBER parameter.
• A user (either from the UI or from the console) or an EXEC attempted to start an object that specifies an EXEC that does not exist in the MainView AutoOPERATOR SYSPROC concatenation.
• You selected the AO-Svcs command in the Specify Start Command panel for the object's definition and the QTMIMFX EXEC is not the MainView AutoOPERATOR SYSPROC concatenation.

In all of these cases, the object’s start actions were not successfully completed. The following list provides describes how to correct these issues:

• Specify a valid number for the CMDNUMBER parameter when issuing the START, UNLOCK, or UNBLOCK function and reissue the function with the correct number.
• Ensure that the EXEC defined for the start action is in the MainView AutoOPERATOR SYSPROC concatenation.
• Ensure that the QTMIMFX EXEC is copied from BBPROC to the MainView AutoOPERATOR SYSPROC concatenation for the MainView AutoOPERATOR address space.

After correcting the problem, issue the RESET RESETOPT(STATUS), RESET RESETOPT(ALL), or RESET RESETOPT(RUNSTAT|OPER) function to change the object status back to STOPPED. TOM performs object evaluation after the status has been set to STOPPED and should issue the start action for the object.

FAILURE-CMD-TERM

Indicates that TOM encountered an error while attempting to issue the STOP command for the object.

The following situations can cause an object to have this status:

• A user (either from the UI or from the console) or an EXEC issued a STOP, LOCK or BLOCK function, and specified an invalid value for the CMDNUMBER parameter.
• A user (either from the UI or from the console) or an EXEC attempted to stop an object that specifies an EXEC that does not exist in the MainView AutoOPERATOR SYSPROC concatenation.
• You selected the AO-Svcs command in the Specify Stop Command panel for the object's definition and the QTMIMFX EXEC is not the MainView AutoOPERATOR SYSPROC concatenation.

In all of these cases, the object’s stop actions were not successfully completed. The following list describes how to correct these issues:

• Specify a valid number for the CMDNUMBER parameter when issuing the STOP, LOCK, or BLOCK function and reissue the function with the correct number.
• Ensure that the EXEC defined for the stop action is in the MainView AutoOPERATOR SYSPROC concatenation.
• Ensure that the QTMIMFX EXEC is copied from BBPROC to theMainView AutoOPERATOR SYSPROC concatenation for the MainView AutoOPERATOR address space.

After correcting the problem, perform the RESET RESETOPT(STATUS) or RESET RESETOPT(ALL), or RESET RESETOPT(RUNSTAT|OPER) function to change the object status back to ACTIVE. TOM performs object evaluation after the status has been set to ACTIVE and performs the stop action for the object.

FAILURE-CMDCOUNT

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

The command counter is incremented by one each time a START command is issued or a start retry command is issued while attempting to start the object.

You should first check to see if there might be a problem with the object which is keeping TOM from successfully performing the start actions.

If you do not discover a problem with the object, 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 issue 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 RESET 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 when TOM attempted to schedule a pre-start EXEC (or the EXEC did not exist) while attempting to start an object.

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.

The command processed by TOM must end with an IMFEXEC EXIT CODE(#) command. The '#' represents a numeric value it specifies the return code that the command returns to TOM.

FAILURE-PRESTOP

A nonzero return code was returned from when TOM attempted to schedule a pre-stop EXEC (or the EXEC did not exist) while attempting to stop an object.

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.

The command processed by TOM must end with an IMFEXEC EXIT CODE(#) command. The '#' represents a numeric value it specifies the return code that the command returns to TOM.

FAILURE-PROPERTY

Indicates a property for an object was missing.

This status might be accompanied by messages in the TOM log, indicating the missing object definition.

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

• If you specified a value other than EXEC or USS as the type in an active check program.
• If the object uses the UPM extension and the FULLCMD attribute is not specified. Message MAMUP1008W describes this error.

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 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(STATUS), RESET RESETOPT(ALL), or RESET RESETOPT(RUNSTAT|OPER) 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 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(STATUS), RESET RESETOPT(ALL), or RESET RESETOPT(RUNSTAT|OPER) function for the object. If the object is already inactive in the system, the status should change to LOCKED. If the object is not 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 reset at the next IPL.

An object can have a LOCKED status for one of the following reasons:

• An EXEC or console command includes a request to stop the object and specified the RESNEXTIPL keyword and or, you specified the Y in the Reset at next IPL field from the TOM user interface in the object definition.

• The object is moved from the current system to another system listed in its VSL and the RESNEXTIPL keyword is specified.

  In this situation, during a move the object's status is LOCKED on the systems that it was not moved to.

• A LOCK request is made for this object.

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

• You specify N for the attribute Move if system failure and the system where the object is active is stopped or fails.

  In this situation, the object's status is LOCKED on all of the system listed in the object's VSL.

• If you specify YES in Locked at IPL: field, this causes an object status to appear as LOCKED.
• The SHUTSYS or SHUTSET function is issued and stopped the object.

If the object definition includes post-stop commands, TOM schedules the commands after the object becomes LOCKED and after a user-defined interval.

LOCKED-ERR

Indicates that TOM discovered an object with a LOCKED status is actually active in the system and TOM changed the status to LOCKED-ERR.

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(STATUS), RESET RESETOPT(ALL) or RESET RESETOPT(RUNSTAT|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 LOCKED. On the way to the status of LOCKED, the object's status will be temporarily set to SCHEDULED-LOCKED.

PENDING

Indicates that TOM is in the process of moving an object.

TOM cannot start an object on another system before stopping it on the current system. TOM puts the object into PENDING status during this period of time on the target system.

When an object moves from one system to another, the object’s status is either SCHEDULED-LOCKED or SCHEDULED-BLOCKED 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 moved from and a status of PENDING on the target system. To resolve this, perform a RESET RESETOPT(RUNSTAT) function on the system that the object moved from.

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 or locked.

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

TOM has received a request to lock the object. TOM changes the object's status to SCHEDULED-LOCKED and 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 has received a request to block the object. TOM changes the object's status to SCHEDULED-BLOCKED and is issuing a request to another subtask in TOM to stop the object.

STARTING

TOM is starting the object, and any pre-start commands have completed, the return codes from the commands are zero (they ended successfully) and the START command has been issued.

TOM 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.

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.

TOM restarts stopped objects that have a status of STOPPED-EXTERNAL in dependency order.

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.

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:

• The object is in the process of being reset by the RESET line command, an EXEC, or a console command.
• The object is defined for a system, but the link to that system is inactive. The status remains UNKNOWN until the link is re-established.
• A RESET command was issued for an object that must run on another system, but you are not connected to that system. The status remains UNKNOWN until the situation is resolved.

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.