One of the challenges in reporting on large amounts of data is, well, reporting on large amounts of data! The process of collecting, storing, and subsequently displaying thousands of objects is a daunting task for any performance management tool. Certain types of data lend themselves to this quandary, and WebSphere MQ queues in large Z/OS queue managers is certainly one of those cases.
Large Z/OS queue managers can easily accommodate 1000’s of WMQ objects. I have seen customer environments which are in excess of 10,000 objects in a single queue manager. Obviously, there is a significant cost in retrieving and displaying such a large amount of data.
Understanding the requirement to reduce the TCO of system management tools, Tivoli R&D has recently delivered functionality which significantly decreases the CPU required to process large amounts of data. CPU reductions of up to 85% have been observed when executing user requests returning a result set of 16mb.
This enhancement is available for Z/OS and distributed system based OMEGAMON / ITM / ITCAM agents. The following table outlines PTFs delivering this function.
OMEGAMON V420 and XE MSG V7 Solutions APAR PTF
All OMEGAMON V420 require ITM 6.2.2 FP1 IZ57703
ITM 6.1.0 OA30094 UA51110
ITM 6.2.0 OA31804
ITM 6.2.1 OA31024 UA51456
ITM 6.2.2 OA31048 UA51194
OMEGAMON V410 and ITM 6.1 Solutions APAR PTF
OM XE on z/OS OA31017 UA51634
OM XE for z/MC OA31025 UA51606
OM XE for CICS TG OA31016 UA51592
OM XE for IMS OA31020 UA52123
OM XE for Storage OA31023 UA51964
OM XE for CICS OA31015 UA51593
OM XE for MFN OA31022 UA52539
OM XE for DB2 PM00695
NetView V53 OA31027
OM XE for Websphere MQ Mon V6 OA31029
OM XE for Websphere MQ Config V6 OA31030
OM XE for Websphere MQ Msg Bkr Mon V6 OA31031
Service Management on System z Blog
with Tags: servicemanagement X
Wayne Bucek 120000989Y firstname.lastname@example.org Tags:  mainframe servicemanagement ztiv 2 Comments 1,735 Visits
OMEGAMON XE for Messaging is a complete WMQ management solution. Many customers focus exclusively on the performance monitoring aspect of the product, which is the ability to monitor WebSphere Broker and WebSphere MQ, and disregard the WMQ configuration agent.
The configuration agent is a robust, feature rich, component of the solution. However, the features and associated benefits of the configuration component are distinctly different from those of the monitoring components. When discussing the WMQ Configuration agent, I like to begin by covering the business benefits it offers. The following items (IMHO) represent the business benefits of the WMQ Configuration agent.
* Centralized administration of WebSphere MQ objects
* Single GUI across platforms
* Eliminates configuration errors
* Assists in dealing with large numbers of objects
* Disaster recovery tool
The list of features offered by the WMQ Configuration agent are too lengthy to list here, but a full accounting can be found in the product documentation at:
Future blog entries will cover this material in more detail.
Many customers manage the performance of their MQ environments based on requirements from the application development community. These requirements are often as simple as monitoring the current depth of the queues used by the application. When the current queue depth of a queue exceeds the threshold specified for the application, an alert must be raised. This relatively straight forward process can become an administrative nightmare in an environment where thousands of queues need to be monitored with this level of granularity. In this case, an OMEGAMON XE for Messaging situation would be required to monitor each queue. This design results in a high cost of collection, along with a high cost of ownership, as the administrative burden of implementing this scheme is prohibitive.
A better way to approach the problem is to group queues into queue depth threshold brackets. For example, queues A, B, C; are all evaluated against a current depth threshold of 10 of more. Queues D, E, F are evaluated against the next higher threshold bracket, perhaps current depth greater than 50. Bracket thresholds are determined based on the current depth requirements specified by the application owners. As many brackets as needed can be defined.
The key to the solution lies in the assignment of a queue to a threshold bracket. Customers will seldom have a queue naming standard based on their queue depth monitoring needs. However, OMEGAMON XE for Messaging provides a creative solution to the problem. OMEGAMON is sensitive to the queue definitions description field. The description field, typically a comment, can be modified to indicate which queue depth threshold bracket the queue should be evaluated against. Then, a single OMEGAMON XE situation can be constructed, reflective of multiple (perhaps all) queue depth threshold brackets. This situation would use an 'OR' construct, essentially checking for combination of Current Depth < threshold AND description field == queue bracket threshold limit, across the multiple specified brackets.