It's what you don't see that may be the most significant

In many of my prior posts and webcasts I talk about things like the vaule of the Tivoli Portal, the value of the ability customize and craft views using the TEP, and the importance of meaningful and useful situation alerts.

Aside from the fact I find this picture amusing, it also illustrates a key point when we are talking about systems performance and availability management. Sometimes it's what you don't see that may be the biggest challenge. Monitoring technologies, like OMEGAMON and the TEP, provide the user with a massive amount of information. Often the challenge is how to filter through the flood of data to find what is most critical.

NetView integrates with the Tivoli Enterprise Portal

OMEGAMON XE for Mainframe Networks makes extensive use of the Tivoli Enterprise Portal user interface. OMEGAMON Networks provides quite a bit of detail on network connections, and network performance relative to applications and workloads on z/OS. Many customers have NetView, but may be unaware of the fact the NetView has the capability to connect with the TEP. The NetView TEP displays have some information, such as session information, that may overlap with data that you can get from OMEGAMON Networks. But, there is also information that is unique to the NetView agent, such as DVIPA data, and NetView log information. The picture shows an example of the NetView data available in the TEP. Note also that you may issue NetView commands from the TEP.

My recommendation is that you view the NetView agent as a complementary component to OMEGAMON Networks. And, whether you have OMEGAMON Networks or not, it is worth enabling the NetView agent and connecting NetView to the TEP.

OMEGAMON IMS Near Term History Provides Powerful Functionality

In an earlier post I talked about the new/improved application trace facility in OMEGAMON XE for IMS V4.20. Along with the new/improved application trace, V4.20 also comes with a Near Term History (NTH) function to show the most recent IMS transactions, and drill down performance detail for those transactions. The transaction detail is kept in the new OMEGAMON IMS journal logging facility, and provides an easy way to go back in time and see what transactions ran, how many times a given transaction ran, and the ability to drill down on a specific transaction scheduling to get performance and execution detail on that given transaction. NTH includes a filter panel option, so that you may filter out transactions, and focus on problem applications, and outliers. The included screen shot shows NTH and how you can F11 drill down for more detail.

OMEGAMON XE for CICS V4.20 is GA

For many of you waiting and planning on that V4.2 migration, the final piece of the puzzle, OMEGAMON XE For CICS V4.20 is now generally available. With OMEGAMON CICS V4.20 being GA, now all the "Big Six" (OMEGAMON for z/OS, CICS, DB2, IMS, Mainframe Networks, Storage) are now available in a V4.20 version. I will post more detail on what is available in V4.20 in a later post.

Optimize the use of OMEGAMON DB2

Object Analysis is one of the most powerful and useful features of OMEGAMON DB2. Object Analysis will gather information on DB2 subsystem getpage and I/O activity, and in turn break out and correlate that information by DB2 object and by DB2 application. Object Analysis is a great tool for understanding where the DB2 database and application 'hot spots' may be happening. What makes Object Analysis nice is that it provides great information, but it does it without running expensive DB2 I/O traces.

A way to optimize Object Analysis usage is to use it when needed. If no one is looking at the data at the moment there may be no need to have it on. The user has the ability to turn it on when needed, and shut it back off when finished. In the RKD2PAR start up options for OMEGAMON DB2 all you need to do is make sure that the Event Manager is started (that portion always needs to be enabled for Object Analysis to run), but let the users manually start Object Analysis when they need it (you can see the options on the screen shot here).

A tip on the configuration of the IMS trace and Near Term History features

On an earlier post I talked about the new and improved IMS application trace feature in OMEGAMON IMS V4.20, and how improved it is over prior versions of OMEGAMON IMS. Another feature of interest is the OMEGAMON IMS Near Term History feature (NTH). The NTH feature of OMEGAMON IMS lets you see response time and DB call information for recent transactions through the system. This is very useful for seeing detail on the last 'n' transactions that have gone through the system. Especially since IMS systems have transactions flowing through very quickly, this can be quite useful.

Both the trace facility and NTH may buffer data before making it viewable to the user. If you are working with these feaures of OMEGAMON IMS for the first time, it may be helpful to be aware of a new option. The SANDBOX option (SANDBOX=ON) for both NTH and trace will make information available in the OMEGAMON classic interface more quickly, and is useful when testing out the tool in a lightly loaded test environment. There is a SANDBOX option available in the startp members for both the trace facility, and for the NTH facility.

Inspect is a powerful tool

OMEGAMON XE for z/OS has many powerful capabilities. One of the features that I find very useful, but is often overlooked, is a component called inspect. Inspect is great because it provides detailed CPU analysis for a given z/OS address space. With inspect you can get CPU usage detail down to the task, offset, and instruction level. Trying to get a handle on CPU usage for certain workloads? Using the inspect facility is a great way to do it. For more information on using the inspect facility, check out the following link for a very detailed presentation on using inspect:

http://www-01.ibm.com/support/docview.wss?uid=swg27017423&myns=swgtiv&mynp=OCSS2JNN&mync=R

Management by exception displays

With the Tivoli Enterprise Portal, once you have multiple agents and platforms checked in and providing performance and availability information, you have access to potentially thousands of metrics of information. Often times a technique I like to use is what I call management by exception. The premise of the approach is that rather than try to fit the entire fire hose of information on a TEP display, just focus on the key information. In the case of management by exception workspace we are focusing on information that may indicate an issue. In the example here I show I can do things like just show high CPU tasks, high MSR DASD, etc. The TEP provides robust capabilities to filter displays to make just such a display easy to create. It's part of the strategy I like to employ built around the notion of tuning out the noise, and focusing on real issues.

More Hiperdispatch info

Hiperdispatch is a great feature of z/OS that provides much more power and flexibility for the dispatching and management of workloads and processors on z/OS. I really think that features, such as Hiperdispatch, are an important part of what makes z/OS such a powerful computing platform. In a prior post I mentioned a presentation I saw at Share about Hiperdispatch, and the support OMEGAMON z/OS provides for Hiperdispatch. While I'm at it I want to mention that if you run OMEGAMON z/OS V420 and are current on maintenance you can get even more information on Hiperdispatch. Here is an example of what I'm talking about.

ITM 6.2.2 or ITM 6.2.1?

So you just upgraded your ITM infrastructure to the ITM 6.2.1 level, and now ITM 6.2.2 is available. What should you do? When should you consider the next step? While there are several benefits to ITM 6.2.2, many of the most interesting features revolve around enhancements to the historical data collection and historical data usage capabilities of the ITM infrastructure. More granularity, more control, more ways to exploit and use the historical data. If history is your thing, then maybe you want to take a look at ITM 6.2.2. I will be posting more detail on this later.

How to enable the EIF tab in the situation editor

In a prior post I mentioned using the EIF interface to send OMEGAMON situation alerts to OMINbus. So in case you logged on to your TEP and went to the situation editor and did not see the EIF tab I showed, here's a couple things to check on.

First, you want to be running your ITM infrastrucuture at ITM 6.21 or above. Second, you need to be sure you have enabled the EIF interface when you configured your environment. Don't assume it's on by default. To turn on the EIF with a z/OS hub TEMS, you need to go into your ICAT advanced options and specify that you want the option enabled. See the screen shots I show here. The option to enable EIF is buried under an F5 advanced option panel. Click on the above image to be able to read the example more easily.

Sending OMEGAMON z/OS situation alerts to OMNIbus

Many customers use Netcool OMNIbus to manage events and alerts, and to act as a "Manager of Managers". OMNIbus works well with large numbers of events and with the management of events from a wide array of sources. There are a variety of ways to send alerts from OMEGAMON on z/OS, or from z/OS in general to OMNIbus. You could have console automation execute a REXX exec that would issue SNMP traps that would appear in OMNIbus. Another mechanism is to use the Tivoli Event Pump to send events from z/OS to OMNIbus. The advantage of the Event Pump is you have a set of packaged events to forward. Another way to send alerts and events from z/OS and OMEGAMON running on z/OS is by using situations in the Tivoli Portal, and using the EIF interface option. The EIF interface is an easy to use mechanism to send information from OMEGAMON to OMNIbus, and you get a lot of flexibility in terms of the detail that may be sent. The picture shows an example of the EIF tab in the situation editor.

Using the Tivoli Portal to create integrated end to end views

One of the powerful aspects of using the Tivoli Enterprise Portal is the flexibility of using the portal to create customized views of the enterprise. One of the views I commonly like to build is what I call an end to end technical view. This view will include information from a variety of sources that are connected to the Tivoli monitoring infrastructure (remember that the TEP can pull in information from a variety of sources, not just monitoring). Here is an example of an end to end view that pulls together information from both z/OS mainframe and open systems sources. Notice I'm pulling in data from sources such as middleware and z/VM. To create views like this you need the Tivoli OMEGAMON monitoring, the Tivoli Enterprise Portal, and enablement for what is called Dashboard Edition (or DE as it is commonly termed).