Event Management › Implementation Process › SNMP Facilities › Management Information Base

Management Information Base

A management information base (MIB) number identifies an event and includes other data to describe the object affected by the event.

Because the MIB number is such an important part of identifying an event, vendors must not use the same MIB number to describe different events.

To avoid the use of the same numeric codes by multiple vendors, standards exist that result in MIBs being organized into one of three broad categories.

• The first category of MIB is the industry standard MIBs. These are sanctioned and published by the International Standards Organization (ISO).
• The second category of MIB is the enterprise MIBs. Enterprise MIB numbers are assigned by the Internet Assigned Numbers Authority (IANA) to a given organization and are reserved for the exclusive use of that organization.
• The third broad category of MIB is the pseudo‑MIBs. They are not sanctioned by or assigned by the IANA, but can be just as meaningful and useful as an ISO or enterprise MIB.

Pseudo‑MIBs often piggy‑back on the enterprise MIB of another organization and take advantage of many of the defaults available on a given platform.

Example:

Consider a pseudo-MIB that describes an event tree, in which each element on the tree represents information that could be sent when specified as a variable on the catrap command. At the top level, Enterprise 999 has two sub-trees, Databases (999.1) and Financial Applications (999.2). The General Ledger database and application are identified as 999.1.1 and 999.2.1 respectively, and they have branches that represent various related events.

999.1.1.1, .2, and .3

Represent General Ledger database shutdown, start, and journal full.

999.2.1.5, .6, and .7

Represent General Ledger application warm start, cold start, and error.

Sending a trap of 999.1.1.2 is equivalent to sending the message "The enterprise database server that handles the General Ledger database has been started." A trap of 999.1.1.3 indicates that the General Ledger database has encountered a journal full condition. And a trap of 999.2.1.5 indicates that the General Ledger application has resumed processing after a temporary outage (warm start).

Taking the example a step further, assume that CA Common Services for z/OS is executing on several nodes in this network, but you have decided that all SNMP trap traffic should be directed to a single monitoring computer, the Earth server. The Earth server receives the SNMP traps, which are recorded and acted on by the Event Management component.

Another computer in the network is used for the production financial applications. This is the Mars server. For some unknown reason, an error occurs and the General Ledger production application running on Mars terminates with an error.

Testing the return code issued by the General Ledger production executable, the shell script realizes that the exit code indicates a problem and issues an SNMP trap to alert the Earth server that something has gone wrong by executing the following command:

catrap earth "" "" 6 0 22 999.2.1.7 integer 128

catrap earth

Sends the identified trap information to the Earth server.

"" and ""

Instructs catrap to take the default Enterprise code and the default agent address respectively for this node.

6

Indicates that this command is sending a specific trap.

0

Identifies the specific trap number for this example.

22

Defines an arbitrary number we have selected as a timestamp indicator.

The next operands identify the variable binding (varbind) information for the trap.

999.2.1.7

Defines the ID of the object about which information is being sent. According to the event tree described earlier, this refers to an error in the enterprise financial application, General Ledger.

integer 128

Provides additional information about the event. It could mean “send an integer value of 128 to the Earth server,” assuming 128 is an error code that has meaning to the General Ledger application; or perhaps it is the exit code that the shell script detected as indicating an error.

When received at the trap target server Earth, the Event Management component (catrapd) decodes the event and performs automatic actions in response.

Returning to the event tree, you can see what other types of events could be sent, such as 999.1.1.1, indicating that the enterprise data server database for the General Ledger system has shut down.

When coupled with the other capabilities of CA Common Services for z/OS, the possibilities expand.

For example, you can use the Event Management facilities to intercept the error messages from any application and automatically execute customized catrap commands in response. The Workload Management function can detect key events and send traps in response to files becoming available for processing or applications completing their processing. Security violation attempts detected by Security Management can result in other SNMP traps being sent, and so on.

When on the receiving side of an SNMP trap, you can use Event Management message handling policies to:

• Open problem tickets automatically
• Send warning messages in human readable form to other consoles or terminals
• Start recovery jobs
• Post dependencies as having been met so that other production jobs can proceed
• Issue additional SNMP traps to one or more other nodes

As this simple example demonstrates, the possibilities for using SNMP trap information are virtually endless.

Note: For more information about the catrap command, including an example of how to issue an SNMP trap using the catrap command, see the Reference Guide.