APPLICATION INFO Policy Item
COMMANDS HELP
------------------------------------------------------------------------------
AOFGDYNA Application Information
Command ===>
Entry Type : Application PolicyDB Name : USER_PDB
Entry Name : APPL1 Enterprise Name : USER_ENTERPRISE
More: +
Category . . . . . . . . . (IBM-defined, user-defined or blank,
see help)
Subcategory . . . . . . . (IBM-defined, user-defined or blank,
see help)
Subsystem Name . . . . . . APPL1
Job Type . . . . . . . . . (MVS NONMVS TRANSIENT)
Job Name . . . . . . . . . APPL1
Transient Rerun. . . . . . (YES NO)
Scheduling Subsystem . . . (MSTR, JES Subsystem)
JCL Procedure Name . . . .
Job Log Monitor Interval . (mm:ss NONE)
Captured Messages Limit. . (0 to 999)
Desired Available. . . . . (ALWAYS ONDEMAND ASIS)
Restart after IPL. . . . . (START NOSTART NONE)
Monitor for IPL complete . (YES NO)
Start Delay. . . . . . . (time for "UP" status checks, hh:mm:ss)
Start Cycles . . . . . . . (start timeout checks, 0 to 99)
UP Status Delay . . . . . (time to delay "UP" status, hh:mm:ss)
Restart Option . . . . . . (ALWAYS ABENDONLY NEVER)
External Startup . . . . . (INITIAL ALWAYS NEVER)
Skip ACTIVE status . . . . (YES NO)
Startup Parameters . . . .
External Shutdown. . . . . (FINAL ALWAYS NEVER blank)
Shutdown Pass Interval . . (hh:mm:ss)
Cleanup Delay . . . . . . (hh:mm:ss)
Command Prefix . . . . . .
Message Prefix . . . . . .
Sysname . . . . . . . . . (System name)
Monitor Routine. . . . . . (name NONE)
Monitor Interval . . . . . (hh:mm NONE)
Inform List . . . . . . .
(SDF EIF E2E IOM ITM SMF TTT USR NONE)
ARM Element Name . . . . .
WLM Resource Name 1 . . .
WLM Resource Name 2 . . .
WLM Resource Name 3 . . .
Owner. . . . . . . . . . .
Info Link . . . . . . . .
Runtokens . . . . . . . .
Any policy values that have been inherited from linked
classes are displayed in a different color. You can find out which
class a value has been inherited from by typing the command classname (or
its abbreviation cn) on the command line, moving
the cursor to the field of interest and pressing Enter. You can override
any inherited values by overtyping them. If you override any values
for a class, they are individually applied to the current application
and change color to turquoise to indicate this.
- Category
- Identifies IBM-defined or user-defined applications. See Category in Creating a New Application.
- Subcategory
- Specifies any IBM-defined or user-defined subcategory of the application for which a category was specified. See Subcategory in Creating a New Application.
- Subsystem Name
- This gives a unique, eleven-character name to the application that you are defining. This name
is used by SA z/OS automation. You can have
multiple application instances with the same subsystem name, however, only one of them can be linked
to a system. The subsystem name of an application class must be unique across the whole policy database, that is, it cannot be the same as the subsystem
name of any other application instance or class.
You can change the subsystem name by overwriting the existing name. If the application instance is linked, the name is checked to be unique across all subsystem names in the policy database. If you want to change the subsystem name to a name that already exists, you first need to unlink the application instance from all application groups.
If no subsystem name is specified, the default is the value of the Entry name (if this name is not longer than 8 characters for applications of category IMAGE, and not longer than 11 characters for all other categories).
For applications of category IMAGE the subsystem name can only be an 8-character name.
Certain values are reserved for SA z/OS and cannot be used. See the online help for a complete list.
- Job Type
- See Job Type in Creating a New Application for more details.
- Job Name
- See Job Name in Creating a New Application for more details.
- Transient Rerun
- See Transient Rerun in Creating a New Application for more details.
- Scheduling Subsystem
- See Scheduling Subsystem in Creating a New Application for more details.
- JCL Procedure Name
- See JCL Procedure Name in Creating a New Application for more details.
- Job Log Monitor Interval
- Specifies how frequently the Job Log should be monitored. The frequency must be specified using
format mm:ss. The allowed minimum is 1 second (00:01), maximum is 60 minutes (60:00). If the field
is left blank the value can be inherited from a class definition. If monitoring is not required,
specify NONE, to prevent inheritance.
If nothing is specified or inherited no monitoring will be done. If scheduling subsystem is MSTR, the specification is ignored.
- Captured Messages Limit
- Specifies the maximum number of captured messages that
will be saved for the SA z/OS command
DISPINFO.
If the field is left blank the value can be inherited from a class, the application defaults (ADF), or the system's default definition (SDF). If neither of these are specified a default value of 0 is used.
- Desired Available
- Lets you specify the default desired status of the resource. The desired state of
each resource is either Available or Unavailable, which is the goal that automation tries to
achieve. You can specify the following values:
- ALWAYS
- The resource's desired status is set to Available, unless it is dependent on a resource that has a Desired Available setting of ONDEMAND. In this case the resource behaves as if it had a Desired Available setting of ONDEMAND itself.
- ONDEMAND
- If there is demand for the resource to be available, its desired status is
set to Available, otherwise its desired status is set to Unavailable.
Demand arises either from propagated MakeAvailable votes or implicitly through membership of a non-passive basic application group (APG) that has a desired status of Available. Demand does not arise from dependent resources with a Desired Available setting of ALWAYS.
A MakeAvailable vote that is propagated to the resource overrides any demand considerations.
An active ONDEMAND member of a move or server group is always sent a vote that sets its desired status, thus overriding any demand considerations.
- ASIS
- The desired status is always set to the observed status. The resource remains in the status that it currently has and no action is taken by SA z/OS at any time, as long as there is no request placed for or propagated to the resource.
If you leave the field blank the value can be inherited from a class or the system defaults definition.
If nothing is specified or inherited the default value is ALWAYS.
- Restart after IPL
- Specifies how SA z/OS determines the
initial status of the application on the first occasion that SA z/OS is started after a z/OS IPL or an automation status file reallocation.
Reallocating the automation status file has the same effect as a z/OS IPL because SA z/OS stores the last IPL date and time in the automation status file. When the automation status file is deleted, SA z/OS assumes that the next startup is the first startup following a z/OS IPL.
You can specify four values for Restart after IPL:
- START
- The application is always startable when the start dependency is fulfilled. The application status is set to DOWN during initialization. It is recommended that you specify START for critical applications such as JES, VTAM®, and TSO. Replying NOSTART to message AOF603D (specify initialization options) overrides this setting.
- NOSTART
- This enforces a STOP request with priority FORCE to be injected during SA z/OS initialization. This results in a desired status of UNAVAILABLE and an observed status of SOFTDOWN, which produces a compound status of SATISFACTORY. If the observed status before IPL was HARDDOWN this status remains in HARDDOWN, which produces a compound status of PROBLEM.
- NONE
- This value is the same as leaving the field blank, except that if the application is an instance, it does not inherit the value from its related application class.
If you leave this field blank, it indicates that the application is startable, depending on its status. If the status is STOPPED, BROKEN or CTLDOWN, it is not changed and the application is not started. Any transient status (for example, BREAKING) is changed to the corresponding final status (for example, BROKEN). Any other status is changed to DOWN during initialization and, if the INITSTART flag is set to YES, the application is started when all its relationships are fulfilled.
Note: If the field is left blank then the DISPINFO panel AOFKINFO will display the value of MAYBE for field Restart after IPL. - Monitor for IPL complete
- Specifies whether the application has to be in an AVAILABLE status before IPL is considered to
be completed.
- YES
- indicates that it has to be in an AVAILABLE status.
- NO
- indicates that this is not the case.
- Start Delay
- Specifies an interval which begins when a start command for the application is issued by
SA z/OS. After the expiration of this
interval, a check occurs to determine whether the application recorded a status of STARTED and/or
ACTIVE depending on the MVS active/inactive state at that time.
Message AOF 571I is issued.
If nothing is specified the default supplied by the automation agent is used, which is 2 minutes.
- Start Cycles
- Specifies the number of times to cycle the start timeout period before posting the subsystem as
a problem which means the application is given a STARTED2 or INACTIVE status.
If nothing is specified the default value is 1.
- UP Status Delay
- Specifies an interval which begins when the UP message is received and ACTIVMSG UP=MSG is
triggered. The application will not be set to an UP status before the specified time has expired. If
the field is left blank the value can be inherited from a class definition.
If nothing is specified or inherited the default value is 00:00:00 which means that there is no delay between receiving the UP message and setting the application to an UP status.
- Restart Option
- Specifies the circumstances that the application should be restarted under. The
options are:
- ALWAYS
- The application is restarted if it was terminated without using the INGREQ command. Note that, if the advanced automation option AOFRESTARTALWAYS is set to 0, the application restart thresholds are checked. The application is restarted only if it has not exceeded the critical threshold. By default the application is restarted every time it is stopped outside the control of SA z/OS.
- ABENDONLY
- The application is eligible for restart only if it abnormally ends. The application is restarted only if its critical error threshold has not been exceeded.
- NEVER
- The application is never eligible for restart by SA z/OS.
You can use this option to force a specific application state. For example, if an application is defined with the restart option set to ALWAYS and an operator tries to shut down the application without using the INGREQ command, the application will be restarted when it has completed its shutdown. The AOFRESTARTALWAYS advanced automation option can be used to modify this behavior.
- External Startup
- Specifies whether the application is started externally or via a specified startup procedure.
- INITIAL
- The application will only initially be started externally.
- ALWAYS
- The application will always be started externally.
- NEVER
- The application will never be started externally.
If you leave this field blank, the value can be inherited from a class definition.
For applications of category IMAGE where the monitor routine is INGMTSYS the value is forced to ALWAYS.If nothing is specified or inherited the default supplied by the automation agent is used, which is NEVER.
- Skip ACTIVE status
- Specifies whether the application has a specific indication for
the UP status.
- YES
- Sets the status to UP for standard applications if
message IEF403I is trapped. For transient applications the status
is changed from ACTIVE to RUNNING.
For USS applications with a job type of NONMVS it also sets the status to UP if the USS process exists.
- NO or blank
- It does not automatically set the status.
- Startup Parameters
- Specifies the desired subsystem startup parameters. These values are added to the MVS START command for the subsystem. For example, suppose the
desired start command for VTAM is:
If this command is to be submitted from SA z/OS, the Startup Parameters field should contain:S VTAM,,,(LIST=00),,,(LIST=00)Whatever you enter in this field is appended directly to the MVS START command for the subsystem, therefore, the commas preceding (LIST=00) are necessary.
You can include system symbols and system automation symbols. See Assigning System Automation Symbols (AOCCLONE) for details on using system automation symbols.
You may also include runtime variables, such as SUBSAPPL, SUBSJOB, SUBSPROC, SUBSSHUTDLY and others. For a complete list of runtime variables, see table AOCQRY Subsystem Task Global Variables in IBM Z® System Automation Programmer's Reference.
- External Shutdown
- Specifies whether the application is stopped externally or via a specified shutdown procedure.
- FINAL
- The application will be stopped externally if the external supporting resource (parent) is also
being stopped.Restriction: A parent is only considered being stopped if any existing PREPUNAVAILABLE relationships are fulfilled and the SHUTINIT commands have been run.
- ALWAYS
- The application will always be stopped externally.
- NEVER
- The application will never be stopped externally.
If you this field is left blank, the value can be inherited from a class definition. For applications of category IMAGE where the monitor routine is INGMTSYS, the value is forced to ALWAYS.
If nothing is specified or inherited, the default supplied by the automation agent is used, which is NEVER.
- Shutdown Pass Interval
- Used to tell SA z/OS how long to wait for
attempts to shutdown the subsystem. These attempts are defined in the SHUTDOWN policy. If the field
is left blank, the value can be inherited from a class or the application defaults definition.
If nothing is specified or inherited, the default supplied by the automation agent is used, which is 2 minutes.
- Cleanup Delay
- Used to specify an interval which begins when the final termination message (TERMMSG FINAL=YES)
for the subsystem is processed. The purpose of this delay is to allow for additional processing
performed by or on behalf of the subsystem to the message being issued.
If the field is left blank, the value can be inherited from a class or the application defaults definition. If nothing is specified or inherited, the default supplied by the automation agent is used, which is 0 second.
- Command Prefix
- This is the console prefix character for the application. Many applications, such as JES2, JES3,
and NetView support the use of a command prefix
character which identifies a command as belonging to that application. If such support is available
for this application, enter the corresponding command character.
Any command that would normally be issued at a z/OS console should be prefixed with MVS. NetView commands to control NetView automation do not require the MVS prefix.
You can include system symbols and system automation symbols, see Assigning System Automation Symbols (AOCCLONE).
The single quotation character ( ' ) is reserved for SA z/OS and should not be used.
- Message Prefix
- Specifies one or more prefixes of messages to ensure that
they are processed on the work operator dedicated to this application. This overrules the "assign by
jobname" established by SA z/OS. So for most
applications this field can be blank. It is recommended to make a specification only if:
- There is no jobname associated to the message (in the control block called WQE).
- The message prefix is unique for this application.
- Sysname
- The system name for the subsystem. This is only required for JES subsystems where the Sysname for the subsystem is not the same as the MVS Sysname. If Sysname is not specified, it will default to the name specified in the SYSTEM INFO policy item of the System entry type.
- Monitor Routine
- The name of the application monitor routine that is used to
monitor the application's status.
The following specifications are valid:
- INGPJMON
- Monitors status via ASCB checking.
- INGPSMON
- Monitors status via IEFSSI service.
- INGVMON
- Monitors status of a VOST via LIST STATUS=VOST.
- AOFADMON
- Monitors status via MVS DA commands.
- AOFATMON
- Monitors status of a task in the NetView environment.
- AOFUXMON
- Routine used to monitor USS applications.
- AOFAPMON
- Routine used to monitor a PPI receiver.
- AOFCPSM
- Dedicated routine used to monitor SA z/OS Proc-Ops.
- INGMTSYS
- Dedicated routine used to monitor IMAGE applications for BCPii usage.
- INGROMON
- Dedicated routine used to monitor OMVS which should not be used for any other application.
- INGDBMON
- Monitors status via ASCB checking plus additional check whether application is registered to SSI (MVS D OPDATA command). Especially to be used for DB2 applications.
- INGDVMON
- Dedicated routine used to monitor a Dynamic Virtual IP address (DVIPA) application.
- ISQMTSYS
- Dedicated routine used to monitor SA z/OS Proc-Ops target system resources.
- NONE
- No monitor routine is to be used.
- username
- A monitor routine that is defined and created by the user.
If a user-defined routine is not found by automation, the SA z/OS routine INGPJMON is used except for applications of category IMAGE, when INGMTSYS is the default. For non-MVS applications, make sure that either a user-defined monitoring routine or NONE is specified.
- Monitor Interval
- This is the amount of time between application subsystem monitoring cycles. If you
specify NONE, no monitoring takes place.
This will also prevent inheritance.
Note: If the monitor routine is NONE, any value specified here is not honored. It is forced to NONE. - Inform List
- This field allows you to specify:
- Where the application is registered to
- Where all status changes are propagated to
- Whether SMF records are written
Valid receivers are SDF, EIF, E2E, IOM, ITM, SMF, TTT and USR. You can specify more than one receiver. The list of values can be blank or comma separated. Neither system automation symbols (AOCCLONEs) nor system symbols are allowed.
If the field is left blank the value is obtained from the systems default definition (see System Defaults Entry Type).
Specify NONE to prevent the default from the systems default definition. This prevents inheritance from the system's default definitions (SDF).
If nothing is specified or inherited, no status changes are propagated. If E2E is specified, the application will be shown on the e2e domain view. T his applies only to applications that are members of an application group without an automation name specified. For others, the specification will be ignored.
- ARM Element Name
- An application defined to MVS Automatic Restart Manager must
have an element name that is unique within each sysplex where the
application runs. Each element name consists of up to 16 alphanumeric
and national characters including @,#,$ and _ (underscore) after clone
resolution, provided the first character is not numeric. Clone resolution
occurs at automation control file load.
You can include system symbols and system automation symbols. For more details, see Assigning System Automation Symbols (AOCCLONE).
The element name can be:- Constant
- The element name is the same, regardless of which system the application is running on. This is
required for applications that are restartable on multiple systems in the sysplex. An application
with a constant Automatic Restart Manager element name may at the
same time have a cloned job name.
An application with a cloned job name and a constant Automatic Restart Manager element name can be started on only one system within a sysplex.
For applications of category IMAGE the value is forced to blank.
- Cloned
- The application has a different element name on each system. The element name is derived from
some attribute that is unique to the system that the application runs on. Applications with cloned
element names must be defined to MVS
Automatic Restart Manager in such a way that MVS will only attempt to restart them on the same system and not move them to
other systems in the sysplex.
Applications with cloned element names may have constant job names. This can be useful if you want to have the same application running on multiple systems with Automatic Restart Manager recovery enabled.
For example, you have a USERPROC that runs on all your systems and you want Automatic Restart Manager recovery for it. Automatic restart management requires that USERPROC have a different element name on each system. Defining USERPROC to SA z/OS with a constant job name, but with a cloned element name (and perhaps some parameters to define the element name) allows you to define a single SA z/OS application with a different element name on each system.
- WLM Resource Name 1–3
- These are the names of the WLM Resources that are associated with the application.
The same WLM resource name can be used for multiple applications. If any of these applications are in the UP or ENDED automation status, the WLM resource status is set to ON. When all the applications that are associated with the same WLM resource name are in any other status, the resource is set to OFF.
You can include system symbols and system automation symbols, see Assigning System Automation Symbols (AOCCLONE).
You can specify up to three different WLM resource names, but only one per field.
No WLM resource names are accepted for applications of category IMAGE.
All three WLM resource names are inherited together. Thus if you specify one for an instance and another for a class, this is not inherited.
- Owner
- This specifies information for the operator about who to contact in case of error.
- Info Link
- This field can be used to specify a location (for example, a URL) where additional information about the application can be found.
- Runtokens
- This field can be used to specify one or more blank delimited tokens (each up to 20 characters long) to define a runmode qualification for the application.