Alert Action(s) II fields


The following figure shows an example of the second ALERT Action(s) Specification panel.

BMC Software ----------- Alert Action(s) II - MSG ------------ BMC AMI OpsA
COMMAND ===>                                                 TGT  --- AOAO

       Rule-set === RULCICS     Alert    Rule-id  === FT407IA

Auto Delete             ===>                                      Yes/No
Retain                ===>                                      Yes/No

Escalate Direction    ===>                                      Up/Down
         Interval     ===>
                      ===>
                      ===>
                      ===>
                      ===>
                      ===>
         Disposition  ===>                                      Keep/Delete

 * Final Act( EXEC )=>                                                          
                                                                               
 * Enter a question mark(?) and blank in any field on the line for more options.
 Press ENTER to continue, END return to Detail Control, CANCEL to cancel changes

This following describes the fields on this panel:

ALERT Actions field

Description

Auto Delete

Allows you to specify that for a message, when a delete operator action message is performed (DOMed), the ALERT associated with the message is also deleted automatically.

In other words, when you create Rules for action messages that issue ALERTs, you can specify that the ALERT is deleted automatically when the action message is DOMed.

This field appears only when you are creating ALERTs for the MSG event type.

If you do not want to delete operator action messages, specify No in the Auto Delete field.

Note

You should use this field only for messages that will be DOMed

Usually only WTORs and action messages are DOMed. When Auto Delete is used, BMC AMI Ops Automation uses a control block in CSA to store the message's DOM ID. When the message is DOMed, BMC AMI OpsA frees this CSA storage. If Auto Delete is used and the WTO is never DOMed, BMC AMI OpsA continues to maintain this storage in CSA until BMC AMI OpsA is restarted with START=COLD.

Retain

Allows you to specify an ALERT will be retained across BBI-SS PAS restarts (both cold and warm restarts) and MVS IPLs.

Specifies whether the ALERT should be created as a nonvolatile ALERT. Possible values are YES|NO; the default is NO.

For more information about retaining ALERTs, see the documentation for the ALERTNV parameter in the Customizing-BMC-AMI-Ops-Automation-after-installation where the BBPARM member AAOALSxx is documented.

Nonvolatile ALERTs are saved to disk and continue to exist across BBI-SS PAS restarts and MVS IPLs. Be aware that creating nonvolatile ALERTs is very expensive as DASD I/Os are required to create and delete ALERTs. Therefore, nonvolatile ALERTs should be used for very specific situations where it is absolutely necessary and meaningful for an ALERT to survive a BBI-SS PAS or MVS restart.

This feature cannot be used in conjunction with the Escalate parameter; they are mutually exclusive.

For event type MSG-initiated ALERTs that specify RETAIN(YES) and Auto Delete(YES), if the PAS is restarted with START=COLD before the DOM of the message, the ALERT is not deleted.

Escalate Direction

Allows you to create ALERTs that will either increase or decrease in priority over user-specified periods of time.

This parameter cannot be used in conjunction with the RETAIN parameter; they are mutually exclusive.

Possible values for this parameter are:

  • Up: specifies that the ALERT will be upgraded in severity when the time interval elapses
  • Down: specifies that the ALERT will be downgraded in severity when the time interval elapses

The default value is Up.

When you use the Escalate Direction field, you must specify at least one time interval in the Interval field.

Interval

Used with the Escalate Direction field.

Use this field to specify over what period of time (in minutes) the ALERT will change in priority. You can specify up to six separate intervals of time over which the priority of the ALERT can be changed.

You must specify at least one time interval or the Escalate parameter will not work. When the final priority is reached, the action specified by the Disposition parameter is taken.

In addition, when you want to have an ALERT change in priority, you must always code one interval more than the number of changes. No priority changes occur in the last interval.

For example, if you want an ALERT to change from MAJOR to CRITICAL, you must code two interval periods.

Refer to the section Examples of ALERT Escalation in the Using-advanced-automation-with-BMC-AMI-Ops-Automation for more information.

Disposition

Used with the Escalate Direction field.

Allows you to specify what will happen to an ALERT when the ALERT reaches its final priority. Possible values are

  • Keep: specifies that the ALERT will be kept when the last (or only) interval expires
  • Delete: specifies that the ALERT will not be kept when the last (or only) interval expires

The default is Delete.

Final Act ( )

Allows you to specify a final action to be taken when the ALERT reaches its final priority level.

Action types that you can specify are as follows:

  • EXEC: Schedule an EXEC to run.
  • MVS, BBI, CICS, IMS, IMP, MQ, NV, and TOM: Execute a command of this type.

Enter a question mark to display the Alert Escalation Final Action Type panel. From this panel, you can select the action and display an additional panel where you can enter the action and associated keywords. Refer to ALERT-Final-Actions-panels for more information.

This section contains the following topic:


 

Tip: For faster searching, add an asterisk to the end of your partial query. Example: cert*