Tuesday, November 29, 2011

Information on Tivoli Event Pump

So what is the Event Pump?  The Event Pump is a tool to send alerts in the form of EIF events to Netcool OMNIbus.  If you are a z/OS shop that has OMNIbus deployed (that's quite a few shops), then you probably have the need to send alerts/information from z/OS to OMNIbus.  What the Event Pump provides is a convenient method out of the box to send these events to OMNIbus.

My colleague, Wayne Bucek, has recently done a write up about Event Pump, and why you would deploy the tool.  Here's a link to the write up:


 If you are interested in a write up on what is new in Event Pump V4.2.2 here is a link with more information:


Wednesday, November 23, 2011

Managing System Automation Critical Messages in the Tivoli Portal

Many thanks to Art Eisenhour for this valuable tip. 

In earlier posts I've discussed the value of the IBM System Automation (SA) interface with the TEP.  One of the features that was added in V3.3 was support for Critical Messages in the TEP.  This means that messages flagged as critical by SA will appear in the TEP, and can be managed and highlighted using TEP capabilities. 

The Critical Messages workspace in the TEP gets its feed from the SDF fucntion of SA.  Out of the box there is no way to remove the message via the TEP, however if can be removed manually by deleting it from the SDF (3270 interface) panel, or in an automated manner if there is a message that would indicate a clearing event.   The command to remove the message would be as follows:


A question that came up with one customer was, what is the best way to manage messages when they appear in TEP Critical Messages.  In the Tivoli Portal you have the ability to set up commands using the 'Take Action' feature, and using the attribute substitution function to pass the necessary variables to the command.  Using this technique you can clear out a message from Critical Messages using the Tivoli portal without having to go to the 3270 interface.  Here's  an example of how this would work:

Cost of monitoring savings with OMEGAMON IMS IF3

As a follow on to my prior posting on the new feature/function of OMEGAMON IMS Iinterim Feature 3 (IF3) it is worth pointing out that there are some very positive performance savings when running IF3.  For example the following measurements have been noted:
  • CPU usage of IF3 Classic has been reduced by at least 23% when running ATF and a Trace. 
  • CPU usage of the IMS Dependant Regions has been reduced by at least 8% when running ATF and a trace.
  • CPU usage of the IMS Control Region, and it’s associated asids (DLI, DBRC, CQS, etc…) has been reduced by at least 8% when running ATF and a Trace.
 If you want more detail on these measurements, check out this blog entry:


These are some very compelling performance numbers, and show the value of going to the IF3 level of OMEGAMON IMS.

Thanks to Reggie Hubbard, Rocky McMahan, and Robyn Stillwell for this information.

Wednesday, November 16, 2011

OMEGAMON IMS fixes for IMS V12 Currency

If you are looking at running IMS V12 and OMEGAMON, you need to be aware of OMEGAMON fixes relevant to IMS V12 currency.   For IMS V12 currency there are ICAT installer changes required.  For more information on the fixes go to the following link:


Tuesday, November 15, 2011

OMEGAMON XE For IMS V4.20 Interim Feature 3 provides powerful new features

Back in August OMEGAMON IMS V4.20 came out with Interim Feature 3 (IF3) that included a bunch of new enhancements and features. The list of enhancements includes the following:

Greater precision in Tivoli Portal workspaces (now in microseconds)

New application metrics added to the 3270 and TEP interfaces

Numerous Application Trace (ATF) enhancements, such as automatic activation of traces at OMEGAMON startup., trace duration increased to 99999 minutes and forever, more filter options for traces, exception-level trace data can now be written to new a new exception journal, elapsed times for DL/I, DB2, and MQ are now provided.

The trace enhancements, in particular, do a lot to make the trace capability of OMEGAMON IMS much more robust. Being able to do things like trace based on exceptions (versus tracing everything), cuts trace overhead considerably.

Here is more info on IF3:


If you are looking at IF3, then you should also be aware of some relevant fixes after IF3 came out. Here is some information on the fixes:


Thursday, November 10, 2011

A couple useful manuals to be aware of

When you are installing, configuring, or troubleshooting OMEGAMON there are a couple manuals it pays to be aware of.

One manual is the "Common Parameter Reference" (SC14-7280-00). This manual lists the many different parameters that define an OMEGAMON installation, along with the parameters that define key infrastructure, such as the TEMS. Here's a URL for the manual:


Another manual that's relevant to installation and the PARMLIB process that I mentioned on an earlier post this week is the "Common Planning and Configuration Guide" (SC23-9734-03). This manual goes through many aspects of OMEGAMON install and configuration. Chapter 4 goes in detail into the PARMLIB install method. Here's a URL link to the manual:


Tuesday, November 8, 2011

An OMEGAMON webcast you won't want to miss

Support for the PARMLIB installation/config process has been in OMEGAMON for a while now. Most customers probably still use the ICAT install panels to config OMEGAMON, but over time with PARMLIB that is likely to change.

If you are interested in learning more about PARMLIB, you will want to check out this webcast on December 1st. "An improved approach to the configuration of Tivoli OMEGAMON" will cover the PARMLIB install process in detail. Cecile Day is the presenter, and there is no doubt she is the expert when it comes to the OMEGAMON installation processes.

I recommend taking a look at this webcast. PARMLIB offers advantages over the ICAT install process, and I anticipate more users moving to the new process. The event is December 1st at 11 AM ET. If you interested in the webcast, here is the URL to sign up:


Friday, November 4, 2011

Mainframe on a phone?

I was scanning through Destinationz a couple days ago and I noticed an entry in the Evangelizing Mainframe blog called "Mainframe on a phone".


The blog doesn't go into huge detail, but does mention some options about bringing mainframe information to smartphone technology.

This made me think of something I've been experimenting with, which is getting the Tivoli Portal GUI to run on an iPad. I actually have something working now, and what's nice is it's really not that hard to do if you have the right infrastructure.

How to do it? In my home office lab (a.k.a Bearcat Chaos Manor), I run a variety of test/sandbox platforms (z/OS running on zPDT, multiple windows boxes, Linux, you name it). At any time I may have one or more Tivoli Portals running, and usually I run them in VMWare images. VMWare works well and makes things nice and portable.

A nice little thing about VMWare is that you have VNC support built right into it. There's a check box you click to enable the VNC support, you specify a port number to connect to, and you are in business. Once that's done, all you need is to set up VNC support on the iPad side. From the iTunes store there are a variety of VNC viewers you can install. I started with Mocha VNC Lite (in other words free). This worked OK, but had certain limitations. So I broke down and spent $5, and got the full version of Mocha VNC Viewer.

With the full version of Mocha VNC Viewer, the interface works very well. You can easily see the TEP screens, the displays render very quickly, click and drag functions work well. I was even able to do things like create situations using the iPad. It all works very nicely. Now, you are not going to do this on an iPhone (the screen is too small). But for an iPad, this works very well.

Wednesday, November 2, 2011

More on OMEGAMON messages to the z/OS console

As a follow on to my prior post on OMEGAMON issuing messages to the z/OS console, here is an example of how that can be specified in the 'Action" tab of the situation editor.

In the example I show, I've created a DB2 situation that monitors the DB2 EDM pool. When the situation alert is true, the action will be executed, in this case a message will be placed on the z/OS console. Note that in the example the message consists of both text literals and an & variable that passes detailed information from OMEGAMON to the resultant message text (in this case the percentage that the EDM pool is full). To add the & variable to the command string you would click the attribute substitution button on the situation editor Action tab display, and select the desired attribute data to pass.

Using situations to drive messages to the z/OS console offers multiple advantages. First, it's easy to do using the GUI interface options of the situation editor (no REXX code etc. is needed). Second, situations provide the most flexibility for alerts because any metric monitored by OMEGAMON can be incorporated within an alert. Third, it's easy and flexible to control the content of the messages, and make then meaningful using attribute substitution via the situation editor.

Another thing to consider is that this message technique is a very effective way to feed 3rd party (i.e. Non-IBM) automation. It's easy to set up the messages, you can control the content, and can pass detailed information through the message string using attribute substitution.

Tuesday, November 1, 2011

Alternatives for OMEGAMON placing messages on the z/OS console

This is a question that comes up fairly often. If OMEGAMON detects an alert or an issue, how can I have OMEGAMON put a message on the z/OS console?

The first thing to be aware of is that the OMEGAMON classic interface task by itself does not have a syslog message command option for when an exception is detected. You will be able to see your desired exception in the the exception analysis screens in classic interface, but you will need to explore additional options to get that exception message on the z/OS console.

There are three primary options to accomplish this:

1- The first is to use the Tivoli portal interface, create a situation alert for the desired exception, and have that situation execute an action command to place a message with the desired information on the console. Any command string entered into the command field will be executed directly to the console. For example, to log a message you could enter LOG 'test message', and 'test message' will appear on the console. Also, be aware that you can use attribute substitution to enter additional information in the command field.

2- If you do not want to use the Tivoli Portal, the next option is classic interface and connect classic to IBM automation. IBM SA automation is able to detect any of the OMEGAMON classic interface exceptions, and can then issue any desired message or command to the z/OS console.

3- If you do not have IBM automation, you can still interface OMEGAMON to non-IBM automation through the XLFOUT mechanism of OMEGAMON. On an earlier post I mentioned a technote that describes the setup and usage of the XLFOUT DD, and how to direct exceptions to XLFOUT.

In a nutshell, those are the 3 alternatives. In general, I think that the Tivoli Portal is the easiest way to go. You can use visual GUI interface, and you can set up actions without having to code any REXX, etc. However, options 2 and 3 are still there, if you desire to go that direction.