WIXLIB

SYSLOG messages. These are messages that appear on the operating systemconsole.JOBLOG messages. These are messages that appear on the address spaceJES2 JOBLOG datasets.Performance monitors. These are normally incidents created from thresholdsdefined in a system or subsystem performance monitoring product, whichcan be surfaced (usually to the SYSLOG or an automation product) whenthe threshold is reached, or an exceed threshold has returned to normal.SNA Alerts. These are notification events in the SNA protocol that wouldnormally be received by a SNA Management program such as NetView forz/OS.TCP/IP SNMP traps. These are notification events in the TCP/IP protocolthat would normally be received by a SNMP Manager, such as NetView forz/OS, or IBM Tivoli Monitoring for Network Performance (ITMNP).Log file. These are events written to a dataset or USS file.SYSLOG and JOBLOG messages are the most likely event sources on z/OS;however, the desired components may also use one or more of the other options. Itis important to understand, for a component to be monitored, the event sources ituses. This will better determine the answer to the next question.3. Which probes can z/OS most efficiently surface events to?For each event source, both how an event is detected, and how that event can besent to the probe must be considered. For z/OS there are three implementationoptions, from most to least desirable:1. A product or function with the ability to both detect events from the source andinterface to one of the probes, with no programming required.Having a product perform this function minimizes or eliminates having to writeand maintain custom code. Enabling the product to perform this function ismore likely a “policy” level customization, instead of programmingcustomization. Some programming may be required, but in all cases this shouldbe minimal. The type of z/OS products most likely to offer this level ofintegration include:o Automation productso Performance products2. A product or function that can surface the event so that a custom program canaccess the event information and send it to a probe.The custom program might execute as an extension of the detecting product(such as an automation product with programming capabilities) or it might be a IBM Copyright, 2011(www.ibm.com/support/techdocs)Options for Sending z/OS Events to Netcool/OMNIbus and TBSMVersion 2.0, May 20118

separate program that can be invoked by the detecting product. The “policy”level customization is done to detect the event, and the custom program takesthe event, extracts the desired information, and formats it to meet therequirements of the destination probe.3. Writing a custom program to both surface the event and send it to the probe.This can be the least desirable integration option, based on the amount ofprogramming required to capture, format, and send the event, as well asmaintaining the program as requirements and the environment changes.Capturing the event will likely require constant polling of the event source.There is more custom code to maintain than the previous options, and thus moreeffort required to keep things synchronized as the environment changes.One helpful method to narrow the options and identify the most likely event sourcesand probes is to look at the existing management products (primarily automationand performance) and evaluate their functions against the above options. Forexample, the following matrix uses existing IBM Tivoli z/OS management productfunctions and rates them on the above three options, in the context of the identifiedevent sources and target probes. The rows are the z/OS event source, the columnsare the probes, and the numbers correspond to the implementation options (forimplementation options 1 and 2 the product which can provide the functions inwhole or in part is identified): IBM Copyright, 2011(www.ibm.com/support/techdocs)Options for Sending z/OS Events to Netcool/OMNIbus and TBSMVersion 2.0, May 20119

SYSLOGJOBLOGPerformanceEIF1 (EventPump forz/OS,NetView forz/OS)1(EventPump forz/OS)1(IBM TivoliMonitoringServices)SNA alert1 (NetViewfor z/OS)SNMP trap2 (NetViewfor z/OS –eventcapture)3Log fileEmail2 (NetViewfor z/OS –eventcapture)Log File2 (NetViewfor z/OS –eventcapture)SNMP1 (NetViewfor z/OS)Socket2 (NetViewfor z/OS –eventcapture)33332(IBM TivoliMonitoringServices –eventcapture)2 (NetViewfor z/OS –eventcapture)2 (NetViewfor z/OS –eventcapture)32(IBM TivoliMonitoringServices –eventcapture)2 NetViewfor z/OS –eventcapture)2 (NetViewfor z/OS –eventcapture)31(IBM TivoliMonitoringServices)2(IBM TivoliMonitoringServices –eventcapture)2 (NetViewfor z/OS –eventcapture)2 (NetViewfor z/OS –eventcapture)31 (NetViewfor z/OS)1 (NetViewfor z/OS –eventcapture)3From this quick analysis, several things become clear: Automation products, such as NetView for z/OS, usually offer the widest option forsurfacing information from the event sources. Automation products normallyprovide the most interfaces into and integration with the sources. In the case ofNetView, it has many different ways to both surface information and then connectto multiple probes.Where the automation product does not have a defined interface, it likely includes aprogramming language where the custom code to interface to a source can beimplemented.Performance monitoring products such as IBM Tivoli Monitoring may providedirect generation of events to map to a probe. They may also interface with anautomation product via an event source (e.g. generating a message when aperformance expectation occurs, for an automation product to detect). Forperformance monitors that can create SYSLOG or JOBLOG messages, the optionsfor those event sources apply and should be investigated.The EIF and SNMP probes are the most likely options, as several products havebuilt in support for creating and sending EIF and SNMP events. These probes alsoprovide an initial set of rules to support the event sources, which can then betailored as needed. IBM Copyright, 2011(www.ibm.com/support/techdocs)Options for Sending z/OS Events to Netcool/OMNIbus and TBSMVersion 2.0, May 201110

The rest of this paper provides basic requirements and usage information for each of theidentified integration options.Tivoli Event Integration Facility (EIF) overviewThe Tivoli Event Integration Facility (EIF) is an interface that applications can use to sendor receive notification events. These events are referred to as EIF events or TivoliEnterprise Console (TEC) events, as that is where the event format originated. The EIF isprovided with Netcool OMNIbus and the Tivoli Enterprise Console, and is documented inthe IBM Tivoli Netcool/OMNIbus Event Integration Facility Reference (SC23-9686).An EIF event consists of an Event Class and a list of event “slots” or “tokens”, which is aset of name-value pairs. For example:EVENT: EIFTBSM41;source USSJAVA;sub source eif2tbsm41;hostname hasl125;origin hasl125;sub origin HCB ;status CLOSED;severity HARMLESS;msg ”IEF403I TCPIP – Started”;The Event Class is EIFTBSM41, and the event slots/tokens are source, sub source, origin,sub origin, status, severity, and msg. Each slot/token has a value associated with it.EIF event options for z/OSThere are several ways to send EIF events from z/OS: The Event Pump for z/OS product generates EIF events from various eventsources, including SYSLOG, address space JOBLOGs, subsystems such as CICS,IMS, and DB2, and from data received by a provided API. The NetView for z/OS Event/Automation Service provides a Message Adapter.This adapter receives information via the NetView for z/OS Program-to-Programinterface (PPI) and can use the received information to create and send an EIF event.This allows NetView to send events to TEC; since the EIF probe receives events inthe same format, it can also be used to send events to the EIF Probe. IBM Tivoli Monitoring can generate EIF events from triggered situations. The EIFevent is sent from the Hub Tivoli Enterprise Monitoring Server (TEMS), which canbe on z/OS, Linux on System z, or a supported distributed platform. EIF provides a set of Java classes that can be installed in the z/OS Unix Systems Services (USS) environment. These classes allow Java programs thatexecute in USS to create and send (or receive) EIF events. Any z/OS program thatcan call a Java program can potentially send information to be transformed into an IBM Copyright, 2011(www.ibm.com/support/techdocs)Options for Sending z/OS Events to Netcool/OMNIbus and TBSMVersion 2.0, May 201111

EIF event. If the z/OS application cannot directly invoke a Java program, it maystill be able to send data if it has a socket interface. The Java classes can be usedwithin a TCP/IP Socket server program to receive information, format the data intoan EIF event, and send it to the EIF probe.EIF provides the posteifmsg command (in earlier releases called postzmsg), whichcan be installed in the USS environment. Just as with the EIF Java classes, anyprogram that can call a USS command (or USS shell script) can invoke theposteifmsg command. Also, as described for the Java classes, the posteifmsg can beused within a USS TCP/IP Socket server program.Given all of the available options to generate EIF events from z/OS, deciding which one touse may seem like a challenge. However, positioning the options is fairly easy based uponthe overall objectives for sending events, and the skills and resources available toimplement and maintain these functions.The Event Pump for z/OS is almost always the best option to use. It provides the followingadvantage over the other options: Defining the resources to monitor and the events to capture are done via policyspecifications, not by writing program code. The major task is identifying theaddress spaces and z/OS messages to be monitored. NetView for z/OS definitions and code are provided to more easily captureinformation not available via SYSLOG messages from specific subsystems andproducts. Currently information from IMS , DB2 Universal Database for z/OS,DB2 Performance Monitor, DB2 Performance Expert, and System Automationfor z/OS is captured by the Event Pump through NetView. An External Data Interface (EDI) is provided which can be used to map informationto a standard format that can be filtered by the Event Pump and sent to OMNIbuswithout requiring custom mapping rules for OMNIbus and the Tivoli EIF Probe. When using TBSM the Event Pump is especially attractive, since it provides theEIF probe rules to map z/OS information to the TBSM fields in the ObjectServerdatabase. In fact, the TBSM on z/OS product consists of the Event Pump and theDiscovery Library Adapter for z/OS. The Event Pump can register the addressspaces that have been discovered by the z/OS Discovery Library adapter and areused in TBSM services. This registration automatically generates the EIF eventsthat will map to the objects in TBSM to correctly reflect the address space status.These advantages can make the Event Pump a better candidate for initial use than the otheroptions.IBM Tivoli Monitoring is the best option if events based on performance and availabilityinformation from any ITM agents on z/OS (including OMEGAMON, ITCAM, or productprovided agents) is desired. If TBSM is installed, events from both the Event Pump andITM that are from the same z/OS resource will map to the single TBSM object thatrepresents that resource. IBM Copyright, 2011(www.ibm.com/support/techdocs)Options for Sending z/OS Events to Netcool/OMNIbus and TBSMVersion 2.0, May 201112

The NetView for z/OS Event/Automation Service can also generate EIF events from policydefinitions without requiring any programming. However, some programming will berequired if there are specific mapping requirements – for example, if the informationcaptured by NetView must be mapped against a TBSM resource.Both the Java classes and posteifmsg methods require custom coding on z/OS andcorresponding custom rules and mappings in OMNIbus, which then have to be maintainedonce developed.In summary, if existing z/OS event integration with OMNIbus or TBSM is not in place, thez/OS Event Pump should be the first option considered. If another option is being used, thefunctions of the z/OS Event Pump should be compared to the current optionimplementation, to determine if the Event Pump can be used to achieve the same or betterresults in a more efficient manner.Using the Event Pump for z/OS to send EIF eventsThe IBM Tivoli Event Pump for z/OS is specifically designed to capture z/OS events andcreate EIF events. It is the best option when using EIF events since no programming isrequired, and extensive functions are provided to capture information and send it toNetcool/OMNIbus.The white paper Sending z/OS Events to IBM Tivoli Netcool/OMNIbus using the IBM TivoliEvent Pump for z/OS, available on the IBM TechDocs website, provides a detailedwalkthrough of setting up the Event Pump to send z/OS events to the ObjectServer.Using Tivoli NetView for z/OS to send EIF eventsThe Tivoli NetView Event/Automation Service (NetView EAS) allows NetView to createand send EIF events to an EIF event recipient (TEC, the EIF Probe, another NetViewEvent/Automation Service, or a custom written EIF receiver). The NetView EAS containsmany functions: Create and send TEC/EIF events Receive EIF events and convert to SNA Alerts Receive SNMP traps and convert to SNA Alerts Send SNA alerts as SNMP trapsDetails on enabling the NetView EAS components can be found in IBM Tivoli NetView forz/OS Installation: Configuring Additional Components (SC31-8874).Using IBM Tivoli Monitoring (ITM) to send EIF eventsITM Tivoli Monitoring can send EIF events in three ways: IBM Copyright, 2011(www.ibm.com/support/techdocs)Options for Sending z/OS Events to Netcool/OMNIbus and TBSMVersion 2.0, May 201113

1. A situation can be customized to send an EIF event when it becomes true. ITMwill also send a “clearing” EIF event for sampled situations when the situationis no longer true. The ITM/OMNIbus integration also allows an event that iscleared on OMNIbus (such as an EIF event from a pure situation) to then becleared on ITM.2. An agent (in ITM 6.2.2 fix pack 1 and later) can be customized to directly sendEIF events to an EIF event receiver, without defining a situation. These arecalled private situations, and can be useful at times when a notification must besent and the agent is running but not connected to a TEMS. Files on the agenthave to be customized to enable this integration.3. A situation can, in its reflex automation, invoke a program that implements theEIF API (such as a Java program), or the EIF posteifmsg command lineinterface. This will require custom programming to create and send the event.Details on the use of these options can be found in the IBM Tivoli MonitoringAdministration Guide.Using the EIF Java classes to send EIF eventsThe EIF provides an application programming interface (API) for creating, sending, andreceiving events. Details of the API are provided in the IBM Tivoli Netcool/OMNIbusEvent Integration Facility Reference. The language support includes Java; a set of Javaclasses is provided, which can be used in the USS environment:The main Java objects provided are: TECAgent – object class that defines a sender or receiver for events. When aTECAgent object is created, one of the parameters is a file of configurationinformation. This file, just like the NetView EAS Message Adapter configurationfile, contains the ServerPort and ServerLocation parameters the agent will use toconnect to the EIF Probe. TECEvent – object class for creating EIF eventsThe following Java code fragment provides an example of how these objects are used: IBM Copyright, 2011(www.ibm.com/support/techdocs)Options for Sending z/OS Events to Netcool/OMNIbus and TBSMVersion 2.0, May 201114

//Define a TECAgent sender object. The connectivity parameters//are read from a file named eif2tbsm41.confFile conf new File("eif2tbsm41.conf");Reader cfgin new FileReader(conf);TECAgent agent new TECAgent(cfgin,TECAgent.SENDER MODE, false);//Create a TECEvent object and set its event classTECEvent event new TECEvent();event.setClassName(eventclass);//Set the tokens for the eventevent.setSlot("source", "origin",origin);event.setSlot("sub source","eif2tbsm41");event.setSlot("sub origin",smf ot("hostname",hostname);//Send the TECEvent via the TECAgentint rc agent.sendEvent(event.toString(true));Any z/OS application that can invoke a USS program can invoke a Java program that usesthe EIF classes, and can pass information to the program to build the EIF event. Anotheroption is to run a Java program that implements the EIF functions as a standalone server(batch job or started task), and have other z/OS applications send information to it viaTCP/IP sockets, which the Java server can receive and convert to EIF events.Using the EIF command line interface to send EIF eventsThe process for using the EIF command line interface is similar to that for using the EIFJava classes. The main difference is that instead of writing a Java application, the EIFposteifmsg command is used. This command is provided by the EIF in Netcool/OMNIbus7.3 and later for the USS environment, and can be used directly, within a shell script, orcalled from another USS program to create and send the EIF event. The parameters passedto the posteifmsg command are the name of a configuration file with connectivityinformation, the event class name, and the token names and their values. The posteifmsgsyntax is documented in the IBM Tivoli Netcool/OMNIbus Event Integration FacilityReference.For Netcool/OMNIbus versions prior to 7.3 the postzmsg command, part of the EIF toolkitshipped with Tivoli Enterprise Console but available for use by Netc

Netcool/OMNIbus. Various options exist to send z/OS information as events to events to Netcool/OMNIbus, and if TBSM is also installed allow state change to flow to TBSM. This paper provides and overview of the technical options available for sending z/OS information to Netcool/OMNIbus. It is meant to provide enough information so that an