Question & Answer
Question
How do I enable SNMP traps for OMEGAMON XE on z/OS agents?
Answer
Many Independent Software Vendor (ISV) consoles support Simple Network Management Protocol (SNMP) as a method of alerting. IBM Tivoli Monitoring (ITM) at 6.2.2 introduced Agent Autonomy. This is well documented at http://publib.boulder.ibm.com/infocenter/tivihelp/v15r1/topic/com.ibm.itm.doc_6.2.2fp1/itm_agentautonomy_info.htm
One of the features of agent autonomy is the ability to issue SNMP traps directly from the agent in response to either private (locally defined) or enterprise situations. These can be enabled either only when the agent is offline to its ITM infrastructure or all the time. I will be concentrating on the latter configuration. Note that the SNMP Management Information Bases (MIBs) for these traps are available on the ITM Agents DVD (i.e. LCD7-3539-03 or higher). MIBs are not required for initial testing but will likely be required at some stage by the SNMP Management tool to properly format the traps it is receiving. Although this formatting can be done manually in some tools, MIBs are easier.
Prerequisite levels on z/OS:
* OMEGAMON XE on z/OS at V4.2.0
* Tivoli Management Services (TMS) on z/OS at 6.2.2, Fixpack 1.
To enable SNMP traps to be issued for all enabled situations to be issued to <snmphost> from the <localhost> interface on the z/OS system make the following updates to the libraries belonging to the z/OS TEMS in which the OMEGAMON XE for z/OS agent is running:
1. Add following parameters to &RHILEV..&SYS..RKANPARU(KDSENV):
IRA_AUTONOMOUS_MODE=Y
IRA_EVENT_EXPORT_SNMP_TRAP=Y
2. Create &RHILEV..&SYS..RKANDATV(M5TRAPS):
<SNMP>
<TrapDest name="SNMP_MGR" address="<snmphost>" BindAddress="<localhost>" />
<Situation name="*" target="SNMP_MGR" />
</SNMP>
The TrapDest address specifies your SNMP Manager. If you just want to test this and you have no SNMP Manager you can use, you can easily set one up using a Linux system that has network connectivity to the z/OS host. To set it up as a SNMP Manager install net-snmp and enable the snmptrapd daemon. As a minimal configuration, to log all SNMP traps to /var/log/messages, the /etc/snmp/snmptrapd parameter file needs one line, assuming the default community name of public:
authCommunity log public
The TrapDest BindAddress is required as if you have more than one NIC defined on the z/OS system. The Situation stanza name of "*" selects all sits.
You can expect to receive traps such as the TEMS Connect and Heartbeat ones below by default even when no situations have been explicitly enabled.
Feb 17 16:46:31 RHEL53 snmptrapd[18230]: 2010-02-17 16:46:20 <localhost>(via UDP:
Feb 17 17:00:07 RHEL53 snmptrapd[18230]: 2010-02-17 16:59:55 <localhost>(via UDP:
If you enable the enterprise situation "OS390_RMF_Not_Active_Crit", distribute it to your OMEGAMON XE on z/OS agent and then once the situation is active in the z/OS remote TEMS you should expect to see the following trap issued once every time the situation is refreshed. The default for this situation is every 15 minutes.
Feb 18 20:48:20 RHEL53 snmptrapd[11145]: 2010-02-18 20:48:09 <localhost>(via UDP:
A preferred configuration for many ISV consoles is an alert issued when a situation is triggered and then a clearing alert to be issued once the situation goes false. This can be provided for many situations using SNMP traps in Hysteresis (Or Persistence) mode.
MODE="HY"
Persistence enabled Situation persistence is not evaluated at the agent. Traps can be emitted in two modes: RC (Rising Continuous) whereby a trap is emitted every time the situation is true; and HY (Hysteresis) whereby a trap is emitted the first time the situation is true and a clearing trap is emitted when the situation is no longer true. A persistence rule can be implemented at the trap destination.
Note that because hysteresis mode is not supported for some situations you cannot specify a wildcard the situation name in the M5TRAPS member. If you were to try something like:
<SNMP>
<TrapDest name="SNMP_MGR" address="<snmphost>" BindAddress="<localhost>" />
<Situation name="*" mode="HY" target="SNMP_MGR" />
</SNMP>
you would get an error message like:
KRATPC023,SNMP situation definition error. Hysteresis mode is not valid to all traps and not suitable for use with wildcard., Producer(SNMPTrap Config)
This means you must specifically define in the TRAPS definition each hysteresis mode situation you want to use. For example, to enable SNMP in hysteresis mode for the "OS390_RMF_Not_Active_Crit" situation the parameter member would look like:
<SNMP>
<TrapDest name="SNMP_MGR" address="<snmphost>" BindAddress="<localhost>" />
<Situation name="OS390_RMF_Not_Active_Crit" mode="HY" target="SNMP_MGR" />
</SNMP>
The kind of traps you should then expect to get would be one of number 1 below when the alert is tripped (i.e. RMF is stopped) and then one of number 2 when the alert is reset, or cleared (when RMF is restarted).
1. Feb 24 14:04:08 RHEL53 snmptrapd[1576]: 2010-02-24 14:03:58 <localhost>(via UDP:
2. Feb 24 14:49:28 RHEL53 snmptrapd[1576]: 2010-02-24 14:49:18 <localhost>(via UDP:
The specific TMS FMIDs and PTFs required to bring it up to 6.2.2FP1 is as follows.
SMP/E MAINTENANCE BY FMID
S=Superseded
A=PreApplied in FMID refresh
HKCI310 UA43882 UA44822 UA45653 UA47377 UA48076 UA48096
HKCI310 UA50881
HKCI310 S UA30255 UA30256 UA32351
HKCI310 A UA19519 UA21225 UA22755 UA23836 UA26622 UA26910
HKCI310 A UA28345 UA29835 UA33367 UA33511 UA34143 UA34861
HKCI310 A UA36078 UA39200 UA40601 UA41882 UA42990
HKDS622
HKDS622 UA50195 UA51194 UA51195
HKLV622
HKLV622 UA51196 UA51197
HKT1710
[{"Product":{"code":"SS2JNN","label":"Tivoli OMEGAMON XE on z\/OS"},"Business Unit":{"code":"BU054","label":"Systems w\/TPS"},"Component":"Not Applicable","Platform":[{"code":"PF035","label":"z\/OS"}],"Version":"5.1.0;5.1.1;5.3.0;4.2.0","Edition":"","Line of Business":{"code":"LOB17","label":"Mainframe TPS"}}]
Was this topic helpful?
Document Information
Modified date:
23 December 2019
UID
swg21422088