Limited supportBMC provides limited support for this version of the product. As a result, BMC no longer accepts comments in this space. If you encounter problems with the product version or the space, contact BMC Support.BMC recommends upgrading to the latest version of the product. To see documentation for that version, see BMC AMI Ops Infrastructure 7.1.

Manage application exceptions

MainView Alarm Management

 can help you manage application exceptions by setting alarms on important 

MainView

 metrics.

Alarms eliminate the need to monitor views constantly to find exception conditions. Instead, exceptions can be displayed automatically on a single screen. By responding to the alarms, you can proactively address small problems before they become big problems--often before users are even aware of the problem. Alarms also provide a path to automation because exception events can be sent to MainView AutoOPERATOR.

To set an alarm on a view field

  • Choose a metric from a table in Important-MainView-metrics.
  • Display the view listed in the table.
  • Use the MAKEALARM wizard to create the alarm definition.
  • Activate the alarm definition.
  • Optionally, use the deployment wizard to deploy the alarm definition to multiple systems.

Example

To monitor Db2 users that are suspended for locks, you would

  • Find 'users suspended for locks' in the table of Db2 metrics (Db2-metrics)
  • Display the LSTSUSPZ view in MainView for DB2
  • Use view customization to review the threshold for the Lock Wait Time field (element L100LELP) and do one of the following actions:
    • Accept the default threshold (if one exists) and exit view customization.
    • Update the threshold to the recommended threshold shown in the table of Db2 metrics, which is L100LELP > 2, and save the customized view.
    • Update the threshold as appropriate for your situation and save the customized view.
  • Position the cursor on the Lock Wait Time field
  • Use the MAKEALARM wizard to create an alarm definition
  • Activate the alarm

Customizing the threshold for the field before invoking MAKEALARM ensures that the view and alarm definition use the same threshold.

For more information about alarms and the wizards, see the

Best practices for alarms

Use the following Best Practices to effectively use alarms in your event management strategy:

Set alarms judiciously

  • Set alarms only for conditions that require intervention; do not set alarms for informational purposes. Raising a lot of insignificant alarms might result in all alarms being ignored, and clutters the exception displays with irrelevant information.
  • Reduce false alarms by using reasonable thresholds and alarm persistence to ignore short-term exceptions due to data anomalies.

Avoid unnecessary alarm overhead

  • Specify the predefined SSI context CURRSYS in the Context field of the alarm definition.

    This context reduces the number of records processed by MainView Alarm Management, and lets you install the alarm definition on multiple LPARs without having to change the alarm definition.

  • Avoid setting alarms on views that supply hundreds or thousands of records, such as the following views:

    • Device views in MainView for z/OS
    • Transaction views in MainView for CICS
    • Thread views in MainView for DB2
    • Queue views in MainView for MQ

    If you have to set alarms on these views (and there are instances when you should), set the frequency of the alarm to at least 60 seconds, and preferably to 120 seconds or more.

  • Use an alarm frequency of 60 seconds to avoid excessive alarms.

Make alarms more effective

  • Avoid setting alarms on interval views. If possible, set alarms from real-time views. Real-time views use a smaller, rolling sample set to provide more consistent, relevant data. In those instances where interval views must be used, validate the persistence of the condition prior to raising the alarm externally.
  • Use a consistent naming convention for alarm definition directories.
  • Assign queue names to summarize alarms.

  • Do not accept the default values for the Message ID and Message Text when creating an alarm definition. Instead, specify a Message ID that identifies the business application affected by the alarm, and a Message Text that explains the impact on that application.

    Example

    The default values might result in the following message in the alarm displays:

    JDELAYAAS00 IDSYSBDEMO Jobname: QMRP ( >= 50)

    However, specifying your own message ID and text will result in a more descriptive and useful message, such as the following example:

    PAY0001 Payroll application jobs unacceptably delayed for lack of resources

Improve the usefulness of alarm views

  • Establish a single point of control by displaying all alarms on one dashboard.

    For example, the ALERTxx or ALARMxx views are available in the MainView products and MainView Explorer. Customized views that focus on specific business applications are highly recommended.

  • Use view customization to customize hyperlinks to shorten the navigation path to problem details.
  • Avoid using alarm library names and alarm group names greater than eight characters. Alarm group and library names can contain up to 16 characters, however, due to space constraints, the distributed alarm views display only the first eight characters of these names. If you need to use library and group names longer than eight characters, you can create customized views that display up to 16 characters. This recommendation applies only to group and library names; MainView Alarm Management fully supports alarm names up to 16 characters.

For more information about alarms, see Using-Alarm-Management.

Related topic

Managing applications6-2-00

 

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