Alert Actions I and II fields
The following figure shows an example of the first ALERT Action(s) I panel.
COMMAND ===> TGT --- AOAO
Rule-set === RULTEST1 Rule-id === FT407IA
Function ===> (ADD, DELETE, DELETEQ)
Key ===>
Text ===>
Queues ===> Alert Queue Name(s)
Priority ===> (CRIT,MAJ,MIN,WARN,INFO,CLEAR)
Color ===> RED,PINK,YEL,DKBL,LTBL,GRE,WHI
PCMD ===>
System ===> Return to target after PCMD
* Exec ===> Follow-up EXEC
Help ===> Associated HELP Panel
Targets ===> Target System
Udata ===> User Data
Origin ===> Origin
User ===> Userid
Alarm ===> Sound Alarm (YES/NO)
Publish ===> Alert Publishing Mode
* Enter a question mark(?) and blank for more options.
Press ENTER to continue, END return to Detail Control, CANCEL to cancel change
The following table describes the fields on Alert Action(s) I panel:
Field | Description |
|---|---|
Function | Specify the function to be performed. This field is used in conjunction with the Queue field where possible values are:
For the ALRT event type, using MODIFY allows you to change any ALERT specifications except Key, Queue, and Target. For more information, refer to optional-Modifying-an-ALERT-in-a-Rule-using-the-MODIFY-function. |
Key | Specify the 64-alphanumeric ALERT identifier used to uniquely identify the ALERT in the queue. You must specify a unique key for every ALERT you create. If you create a second ALERT with the same key as an already existing ALERT in the queue, the second ALERT will overwrite the first ALERT. This field cannot be modified by using the MODIFY function for an ALRT-initiated Rule. |
Text | Specify the text of an ALERT message sent when the ALERT is generated. The text is shown on the panel of the ALERT Detail application. The text can use any shared or function variable, any &WORDn variables, or literals. |
Queues | Specify a 33-byte field specifying the names of the ALERT queues. This field is used in conjunction with the Function field where valid values are ADD (to add an ALERT to the specified queue), DELETE (to delete an ALERT from the specified queue) or DELETEQ (to delete the ALERT and the ALERT queue). This field can contain any shared or function variable. The default is MAIN. You can specify multiple queues by separating them with double colon marks (::). If a queue name is a variable, you must use a third colon; for example: &IMFOJOB:::MAIN This field cannot be modified by using the MODIFY function for an ALRT-initiated Rule. |
Priority | Specify the priority of the ALERT. Valid values are CRITICAL, MAJOR, MINOR, WARNING, INFORMATIONAL, and CLEARING. The default is INFO. |
Color | Specify the color of the alert text. This field overrides the color assigned by Alert Priority. Valid colors are RED, PINK, YELLOW, DKBLUE, LTBLUE, GREEN, and WHITE. |
PCMD | Specify a 142-byte field specifying the primary command associated with the ALERT that can be executed from the ALERT Management Facility. This field can contain variables that can expand to 252 bytes. |
System | Specify the SYSTEM command after the PCMD is issued. This action passes control back to the target. Valid values are Yes and No; Yes is the default. |
Exec | Refer to REXX-Exec-or-CLIST-panel for more information. |
Help | Specify the name of the help panel associated with the ALERT that can be accessed from the ALERT Management Facility. |
Targets | Specify the target system the ALERT is sent to. You can specify multiple targets; separate each target name with a blank. This field cannot be modified by using the MODIFY function for an ALRT-initiated Rule. |
Udata | Specify any desired user data string. |
Origin | Specify a user-defined name of the origin to assign to the ALERT. When you specify an Origin and a follow-up EXEC that includes performing certain actions (such as issuing the IMFEXEC RES or IMFEXEC CICS commands), you must ensure that the Origin resolves to a user ID that has been authorized in your security definitions to issue these commands. For example, you might create a Rule that traps an event in a CICS address space and creates an ALERT with a follow-up EXEC. The follow-up EXEC has the 'IMFEXEC RES ST jobname' command in it. When BMC AMI Ops Automationpasses control to SYSPROG, the value specified in Origin for the ALERT is passed to SYSPROG as the user attempting the action. If that Origin value is not an authorized user ID defined in your security definitions to issue SYSPROG commands, the SYSPROG command will fail. When an Origin is not specified, the Origin value defaults the jobname of the event that created the ALERT. |
User | Specify the user assigned to the ALERT. See also the description for the Origin field |
Alarm | Specify whether to emit an audible alarm. |
Publish | Specify whether an ALERT is published and how it is published to connected PATROL EM workstations or to BMC Impact Manager cells that have been customized to receive ALERTs through the General Message Exchange (GME). Settings for GME are defined in BBPARM member AAOGME00. Possible values are REPLACE (where the previous ALERT is deleted from the workstation before the new ALERT is sent), ADD (where a new ALERT is added to the workstation), and NO (where the ALERT is not written to the workstation). The default setting for Publish is set with the PUBLISH= parameter in BBPARM member AAOALSxx. For more information about setting the default setting for Publish, refer to the Customizing-BMC-AMI-Ops-Automation-after-installation where the Dynamic Parameter Manager application is described or where BBPARM members for BMC AMI Ops Automation are documented. For more information about implementing BMC AMI OpsA connection to BMC Impact Manager cells, see Implementing the MainView AutoOPERATOR Interface to BMC Impact Manager. |
This section contains the following topic:
Related topic