Netview Task Status

ABENDING:
A subsystem goes into the ABENDING status when a termination message is
received for it which indicates that it suffered a recoverable abend (it
had ABEND=YES coded on the call). If the subsystem is undergoing a
NORMAL shutdown by SA for z/OS, no further shutdown commands will be
issued. To resume the shutdown, cancel the current request and enter a
new one with the INGREQ command with type IMMED or FORCE.

A subsystem will remain in the ABENDING status until its final
termination message is received. Its abend thresholds will then be
checked. If it has not exceeded its critical threshold it will be put
into the RESTART status and an attempt will be made to restart it. If
it has exceeded its critical threshold, it will be put into the BROKEN
status (where it will remain until an operator tells SA for z/OS to
restart it). If it is slow to clear the machine after its final message
has been received it may go to ZOMBIE. If it later suffers an
unrecoverable abend it will go into BREAKING status.
=========================================================================
ACTIVE:
The application is running, but is not yet ready for work. An
application can be put into ACTIVE status in response to the following
conditions:

1. SA for z/OS has received an ACTIVE message for the application.
2. The SA for z/OS startup checker has run for the application when its
automation status was STARTED. The startup checker found the
application monitor status for the application to be ACTIVE.
3. During routine status checking the application monitor status for
the application was found to be ACTIVE when its automation status
indicated it should be otherwise.
4. SA for z/OSattempted to start the application, but found that its
application monitor status was ACTIVE.
5. SA for z/OS found that the Automatic Restart Manager status for the
application is STARTING, but has not received any messages
concerning the application status.
6. SA for z/OS checked an attempt by Automatic Restart Manager to
restart the application and found that its Automatic Restart Manager
status is UNREGISTERED, but the application monitor status for the
application is ACTIVE.

An application remains in ACTIVE status until its UP message is
received. If the application is starting or restarting, an SA for z/OS
monitoring check for the application is done after its start delay time.
If the application is no found it is put into INACTIVE status. If it is
found, but is not yet UP, it is put into STARTED2 status.

=========================================================================
ASSIST:
This is an unusual status. When an application has ASSIST=DISPLAY coded
for one or more of its automation flags, SA for z/OS puts the
application into ASSIST status whenever it wants to issue a command that
is controlled by that automation flag. ASSIST indicates that SA for z/OS
is ready to take an action which will affect an application, but that
you must approve the action before it occurs. An application can enter
ASSIST status when SA for z/OS is going to start it, stop it, or perform
secondary automation for it.

When an application is in ASSIST status you can access an ASSIST panel
using SDF. This panel is used to tell SA for z/OS to issue the command
where it should be issued, to issue the command on the your account, or
to ignore the command. The regular monitor ignores applications that are
in ASSIST status, and most command dialogs will not process them.

To get an application out of ASSIST status you must respond to all the
ASSIST panels that are present in SDF for the application. If the
commands are issued in the correct place, the application should come
up. You can use the DISPASST command dialog to see assist settings, and
the SETASST command dialog to change them dynamically.
=========================================================================
AUTODOWN:
The application is shut down. SA for z/OS may restart it to comply with
an operator request. If the shutdown specified that the application was
to be restarted, it is put into RESTART status when the shutdown is
complete.

1. SA for z/OS has shut the application down at the request of an
operator.
2. When SA for z/OS initialized, the operator replied NOSTART to the
AOF603D WTOR. Any applications which would have been put into the
DOWN status during initial status determination have instead been
put into the AUTODOWN automation status.

You can use the SETSTATE command to change the application status to
either RESTART or CTLDOWN.

SA for z/OS may attempt to restart an application in AUTODOWN status
when SA for z/OS is reloaded, or when an operator requests SA for
z/OS to start one of the application descendents. In both cases, the
application goes to RESTART status.

=========================================================================
AUTOTERM:
SA for z/OS is in the process of shutting the application down. The
shutdown is in response to a INGREQ REQ=STOP command. This status
persists until SA for z/OS is sure that the application has been cleaned
up.

Many things may happen to an application that is being shut down. If the
shutdown is successful, the application is placed in either AUTODOWN or
CTLDOWN status. If the shutdown specified that the application should be
restarted it goes through AUTODOWN to RESTART status.

If the application abnormally ends while it is being shutdown it may go
into either ABENDING or BREAKING. A normal shutdown will stop processing
an application that abends, but other shutdowns will continue. If the
shutdown runs out of commands to issue, the application is placed into
STUCK status. If it has problems shutting down, the application may be
placed into ZOMBIE status.
=========================================================================
BREAKING:
The application is undergoing a non-recoverable abend; that is, it has
received a termination message specifying BREAK=YES. If the application
is undergoing a normal shutdown by SA for z/OS no further shutdown
commands are issued. The shutdown may be resumed by using the INGREQ
REQ=STOP command. This status persists until SA for z/OS receives its
final termination message and is sure that the application has been
cleaned up. If the termination experiences difficulties, the application
may be posted to ZOMBIE status.
=========================================================================
BROKEN:
The application has suffered a non-recoverable abend. SA for z/OS will
not restart it. An application can be put into BROKEN status in response
to the following conditions:

1. The application has suffered a non-recoverable abend, indicated by
the reception of a TERMINATION message with the BREAK=YES attribute.
2. The application has suffered sufficient recoverable abends to exceed
its critical threshold.
3. The application has suffered a prestart or startup failure.

This status is preserved across a recycle of SA for z/OS or a re-IPL of
the processor, unless the application has its Start on IPL/RECYCLE
Option set to YES.
=========================================================================
CTLDOWN:
The application is shut down and SA for z/OS is not allowed to restart
it.

1. An operator asked SA for z/OS to shut the application down and not
to restart it until authorized to do so by an operator.
2. An operator used a SETSTATE command to tell SA for z/OS that an
application should not be restarted until an operator authorizes SA
for z/OS to do so.
3. SA for z/OS was recycled, the application monitor status is
INACTIVE, and its Start on RECYCLE Option is NO.
4. SA for z/OS was started for the first time, the application monitor
status is INACTIVE and its Start on IPL Option is NO.
5. SA for z/OS was recycled while the application was in a CTLDOWN
status. If the AOFCTLOPT advanced automation option is set then the
application status remains CTLDOWN regardless of all other settings,
parameters, and options, providing its application monitor status
remains INACTIVE.
You can use the SETSTATE command to change an application status from
CTLDOWN to RESTART or AUTODOWN, in which case SA for z/OS will attempt
to restart it. Alternatively you can use the INGREQ command to start
the subsystem with the OVERRIDE=STS option.

=========================================================================
DOWN:
The application has not been started during the lifetime of this SA for
z/OS.

The DOWN status is set only during initial status determination and is
possible only if the application monitor status is INACTIVE. The
automation status of the application when SA for z/OS was last shut down
on this system is used in the following manner to determine if it is to
be placed into the DOWN status.

1. The previous automation status was not one of STOPPED, CTLDOWN or
BROKEN.
2. The START on IPL option for the application is YES and this is the
first time that SA for z/OS has been started since MVS was last
IPLed. If the previous automation status was CTLDOWN and the
AOFCTLOPT advanced automation option is set then the automation
status remains as CTLDOWN.
3. The START on RECYCLE option for the application is YES and this is
not the first time that SA for z/OS has been started since MVS was
last IPLed. If the previous automation status was CTLDOWN and the
AOFCTLOPT advanced automation option is set, then the automation
status remains as CTLDOWN.
4. The application does not have a Start on IPL Option of NO. If it
does, its status is set to CTLDOWN.
5. The application does not have a Start on RECYCLE Option of NO. If
it does, its status is set to CTLDOWN.
=========================================================================
ENDED:
This status is used for transient applications only, and indicates that
the job for the application has finished and left the system without any
errors. Any start-dependent resources for the application will be
started as though it were a normal z/OS subsystem that was UP.

If the transient application can be re-run, you can use the SETSTATE
command to restart it. If the transient application cannot be re-run, it
will remain in ENDED status.
=========================================================================
ENDING:
A transient application is in the process of terminating. A transient
application goes to ENDING status when a termination message is received
for it, and it is not being shut down by SA for z/OS. This status shows
that the application is terminating, but that this is expected. A
transient application may also go to ENDING if an operator is shutting
it down outside SA for z/OS control, or if it has abnormally ended, but
the abend messages are being treated as normal termination messages.

The application remains in ENDING status until either:

o an abend message is received, which will put it into either ABENDING
or BREAKING status. If the application abends then either SA for
z/OS or Automatic Restart Manager can restart it.
o the application final termination message is received, at which
point the RESTARTOPT for the application is checked. If it is ALWAYS
then the application is put into RESTART status and SA for z/OS will
attempt to restart it. If it is anything else, the application go to
ENDED status. It is assumed that if a transient application ends
normally then it will deregister from Automatic Restart Manager. If
it is slow to clear the system after its FINAL message is received
it may go to ZOMBIE status.

If an ACTIVE or UP message is received for the application, its
automation status is changed to either ACTIVE or UP, as appropriate.
=========================================================================
EXTSTART:
SA for z/OS has determined that the application is being started or
restarted by an agent external to SA for z/OS. In situations where SA
for z/OS is able to identify the external agent (such as Automatic
Restart Manager), it takes appropriate steps to monitor that agent's
actions and, if necessary, step in to assist it. An application can be
put into EXTSTART status in response to the following conditions:

1. SA for z/OS is unable to identify the external agent.
2. Automatic Restart Manager is in the process of restarting the
application.

==========================================================================
FALLBACK:
The application is not running on the primary system where it should
run, but this status has been encountered for this application on one of
its secondary systems. It should be active on another system. If the
other system fails, the application can fall back to this system, where
it could possibly be restarted. However, SA for z/OS, will not perform
the restart on the fallback system, but this may be done by an operator
request. This is implemented to leave the decision of restarting the
application on the fallback system to the operator.

An application can be put into FALLBACK status in response to the
following conditions:

1. It is defined with a secondary association on this system.
2. An operator has used the SETSTATE command to put the application
into the MOVED status. If this is one of the secondary systems for
the application it will go to FALLBACK instead.
=================================================================================
HALFDOWN:
SA for z/OS was in the process of shutting the application down, but the
stop request was canceled while it was in progress. The application
shutdown did not complete (for example, ASCBs may still be active). You
may sometimes find that some, but not all, of the shutdown commands have
been issued. To recover an application from HALFDOWN status you must
determine where it is in its shutdown process and complete the shutdown
manually. Applications go into HALFDOWN only when you cancel a stop
request. Alternatively, you can use SETSTATE to put the application back
into UP or RUNNING status.
===================================================================================
HALTED:
The application is still running, but something has happened which may
have severely impacted its capabilities.

1. SA for z/OS has received a HALT message for the application.
2. SA for z/OS has detected that the application represents a JES2
application which is running short of spool space.
3. The Automatic Restart Manager status for the application is
ELSEWHERE, but SA for z/OS found its application monitor status to
be either STARTING or ACTIVE.

An application is taken out of HALTED status if its UP message is
received. Also, operators may use the SETSTATE command to put the
application into UP/RUNNING status.
====================================================================================
INACTIVE:
At some point in monitoring, the application monitor status was INACTIVE
when the automation status indicated that it should be either ACTIVE or
STARTING. An application can be put into INACTIVE status in response to
the following condition:

1. The application monitor routine found the application's status to be
INACTIVE.

If the application RESTART option is ALWAYS, the application is
restarted rather than put into INACTIVE status.
=================================================================================
MOVED:
The application is not running: this is one of its primary systems: it
should be active on another system. An application can be put into MOVED
status in response to the following condition:

o An operator has used the SETSTATE command to put the application
into the MOVED status. This is possible only on a primary system.

A subsystem will remain in the MOVED status until it is restarted on the
primary system by an external agent, such as an operator. You can also
use the INGREQ command to restart the subsystem.

================================================================================
RESTART:
The application is ready to be started. It has been previously active in
the system. An application can be put into RESTART status in response to
the following conditions:

1. The application abended and, after checking thresholds, SA for z/OS
is allowed to restart it.
2. SA for z/OS has shut the application down in response to an operator
request and is now preparing to restart it.
3. An operator has used the INGREQ REQ=START command to ask SA for z/OS
to restart the application.
4. SA for z/OS checked an attempt by Automatic Restart Manager to
restart the application and found that its Automatic Restart Manager
status is UNREGISTERED and the application monitor status for the
application is INACTIVE. This implies that the attempt by Automatic
Restart Manager to restart the application timed out while the
application was in RESTARTING status. SA for z/OS changes the
automation status of the application to RESTART and attempts to
start the application itself.

During restart processing, the application RESTART automation flag is
checked. If it is turned on, the application start commands are issued
and the application is put into STARTED status. If the RESTART
automation flag is off, the application remains in RESTART status and
the startup monitor cycle initiates the start up process each time it
runs.
===============================================================================
RUNNING:
This status is equivalent to UP, but is used for transient applications.
It indicates that the UP message has been received for the transient
application, or an operator has used the SETSTATE command to change the
status of a transient application to RUNNING. A transient application is
one which SA for z/OS expects to terminate on its own. When the job
finishes the application goes through ENDING status to ENDED, at which
point its descendants are started. Unlike the UP status, the descendants
of a transient application are not started until it has terminated.

A transient application should leave RUNNING status on its own. If it
gets stuck, you should use investigate it. You can use the INGREQ
REQ=STOP command to put it into AUTODOWN status.
================================================================================
STARTED:
The commands to start the application have been issued, but it has yet
to start running. An application can be put into STARTED status in
response to the following conditions:

1. SA for z/OS has issued, or will soon issue, the commands.
2. When SA for z/OS attempted to start the application it found that
the application monitor status for the application was STARTING.
3. During initial status determination, SA for z/OS found that the
application monitor status for the application was STARTING.
4. SA for z/OS checked an attempt by Automatic Restart Manager to
restart the application and found that its Automatic Restart Manager
status is UNREGISTERED, but the application monitor status for the
application is STARTING.

Note that the relevant automation flag, Initstart or Restart, must be
on. The application startup commands as defined in the automation
control file are issued after the application is placed in STARTING
status.

An application remains in STARTING status until either its ACTIVE or its
UP message arrives. After the application start delay time, an SA for
z/OS monitoring check is issued for it. If it is not found, it is put
into INACTIVE status. If it is found, but is not yet UP, it is put into
ACTIVE status.
===========================================================================
STARTED2:
The application has become active, but has not indicated that it is
ready to accept work within its start delay. An application can be put
into STARTED2 status in response to the following conditions:

1. The startup checker found that the application monitor status was
still STARTING.
2. The startup checker was called for an application whose automation
status was ACTIVE.
3. SA for z/OS found the Automatic Restart Manager status for the
application to be AVAILABLE-TO.
4. SA for z/OS checked an attempt by Automatic Restart Manager to
restart the application and found that its Automatic Restart Manager
status is one of AVAILABLE-TO, RESTARTING or RECOVERING.
5. SA for z/OS checked an attempt by Automatic Restart Manager to
restart the application and could not find a better status to put it
into. Its application monitor status is ACTIVE. This covers
situations where the restart checker is unable to determine the
Automatic Restart Manager status for the application, or its status
is FAILED.

An application remains in STARTED2 status until either its UP message
arrives or an operator uses the SETSTATE command to change the
application status to UP/RUNNING.
===========================================================================
STOPPED:
The application has been shut down by an external agent, such as an
operator cancel. SA for z/OS is not permitted to restart it and will not
allow Automatic Restart Manager to restart it. This status is preserved
across a recycle of SA for z/OS or a re-IPL of the processor unless the
application has its Start on IPL/RECYCLE Option set to YES.

An application remains in STOPPED status until an operator uses the
SETSTATE command to change its status to either RESTART or CTLDOWN.

An application may also leave STOPPED status if it is restarted outside
the control of SA for z/OS. In this case, it goes to either the ACTIVE
or the UP status, depending on which message is received.

===========================================================================
STOPPING:
The application is being shut down by an external agent. This status is
entered when a TERMINATION message is received while SA for z/OS is not
in the process of shutting the application down. It may also indicate
that the application is abending, but the abend messages issued are
being treated as normal termination messages by automation.

An application that is STOPPING remains in that status until either an
abend message is received which puts it into ABENDING or BREAKING
status, or the final termination message for the application is
received, at which point the application RESTART option is checked. If
RESTART is ALWAYS, the application is put into RESTART status and SA for
z/OS attempts to restart it. Otherwise, the application goes to STOPPED
status. If it is slow to clear the system after the final message is
received, it may be placed into ZOMBIE status.

If an ACTIVE or UP message is received for the application, its
automation status is changed to either ACTIVE or UP, as appropriate.

Automatic Restart Manager interaction with this status depends on a
number of factors. If the application is deregistered then there is no
interaction. If the application is registered then Automatic Restart
Manager will attempt to restart it. If the application goes to STOPPED
status before the SA for z/OS/Automatic Restart Manager exit is invoked
then SA for z/OS will tell Automatic Restart Manager not to restart the
application. If it does not, then SA for z/OS will tell Automatic
Restart Manager that it can restart the application.
===========================================================================
STUCK:
An application can get STUCK when it is being shut down. This is because
SA for z/OS has run out of NORM, IMMED, or FORCE shutdown commands.
===========================================================================
UP:
The application has finished initializing and is ready for work. An
application can be put into UP status in response to the following
conditions:

1. SA for z/OS has received an UP message for the application.
2. An operator has used the SETSTATE command to change the application
automation status. In this case, SA for z/OS assumes that the
operator has ensured that the application is actually UP.
3. During initial status determination the application monitor status
was found to be ACTIVE.
4. SA for z/OS found the Automatic Restart Manager status for the
application to be AVAILABLE.

There are a number of ways for an application to leave the UP status:

o If it is shutdown with the INGREQ REQ=STOP command, it goes to
AUTOTERM status
o If it is shutdown outside SA for z/OS, it goes to STOPPING status
o If it abends, it might go to STOPPING, ABENDING or BREAKING status
o If it has problems, it may go to HALTED status
o If the regular monitor cannot find it, it will go to INACTIVE status
o If the application abends, SA for z/OS does not pick up the abend
messages, and Automatic Restart Manager detects that the address
space has ended, the application may go to EXTSTART.

===========================================================================
ZOMBIE :
When an application is leaving the system it can get into ZOMBIE status.
This indicates that the final termination message for the application
has been received but that SA z/OS monitoring in TERMMSG still finds the
application. The application is put into ZOMBIE status if this situation
persists for more than twice the application termination delay time.

There are three ways in which an application can get into ZOMBIE status:

o If MVS is slow in clearing the application and the termination delay
time is short.
o If there are two jobs with the same name in the system, one of which
is the application. When either of them terminates SA for z/OS
assumes that the application has stopped, but SA for z/OS monitoring
will find the other job. To change the status to UP, either manually
shut the other job down, or use the SETSTATE command to change the
application status back to UP.
o The job may have become stuck in the system after issuing its final
message.

From ZOMBIE status, if the application suffers an unrecoverable abend it
will go into BREAKING status.

Note: The START ON IPL and START ON RECYCLE options of the
customization dialog may override these resource statuses at SA for z/OS
IPL or RECYCLE, resulting in SA for z/OS starting the subsystem. If
either START ON IPL or START ON RECYCLE are set to NO, the application
is placed in CTLDOWN status.

Unless otherwise stated, the content of this page is licensed under GNU Free Documentation License.