Space banner

   

This space provides the same content as before, but the organization of the home page has changed. The content is now organized based on logical branches instead of legacy book titles. We hope that the new structure will help you quickly find the content that you need.

Collect information about events

After determining a particular area of your IT infrastructure that could benefit from automation, select a couple of events that can have a negative impact on users.

Answer the following questions to help determine how to automate those events. You can print the Event automation worksheet to help with this task.

Which events?

Talk to application programmers, system programmers, and operators to isolate some critical events, such as

  • DB2 threads that use too much CPU

  • Runaway CICS transactions

  • Abending transactions

Determine the best indicator of those events. Can you use any of the MainView metrics described in Important MainView metrics? Or is a particular message, for example, a WTO or journal message, a better indicator of the event? If so, gather any available information about the message.

Who should be notified and how?

Determine who should be notified of the events and how they should notified. The automated solution can

  • Send a TSO message

  • Send an e-mail message

  • Page personnel by using a notification system such as AlarmPoint

  • Open a problem ticket by interacting with an incident tracking system, such as Remedy Service Desk

  • Forward the event to an event management system, such as BMC Impact Manager

What action should be taken?

Determine what actions should be taken when the event occurs. The automated solution can involve a simple action or a series of more complex actions. A simple action might

  • Issue a z/OS, IMS, CICS, DB2, MQ, or other type of command

  • Log diagnostic information in a repository (MainView AutoOPERATOR journals or system logs)

  • Raise a better, more informative exception by rewording a cryptic message

  • Correlate events with previously captured, less significant events to provide a more meaningful exception (variables can be used to store information about previously captured events)

A complex action might

  • Perform several simple actions concurrently

  • Schedule a REXX EXEC that contains logic to perform any of several actions depending on the context of the event

    For example, an EXEC that can perform actions A through E might perform only actions A, C, and E for one event occurrence, and actions A, B, D, and E for the next occurrence.

  • Schedule a REXX EXEC that executes the MainView API to collect more diagnostic information for logging, or to perform additional actions


Was this page helpful? Yes No Submitting... Thank you

Comments