Service Management on System z Blog
Wayne Bucek 120000989Y email@example.com Tags:  mainframe servicemgmt ztiv 2 Comments 2,132 Visits
Hi. I am Wayne Bucek a 20-year veteran in the systems management arena. When I have to come off the bike trails, I am a Consulting IT Specialist for zTivoli solutions. My favorite part of the job is to assist customers with the selection, design, and implementation of IBM zTivoli products. I am IBM-certified in WebSphere MQ.
Prior to joining vendor community, I had a real job - 10 years' experience across the disciplines of z/OS systems programming, application programming, and performance management.
I hope to make this blog a place z techies can come to link their real world business problems to zTivoli solutions.
Wayne Bucek 120000989Y firstname.lastname@example.org Tags:  mainframe servicemanagement ztiv 2 Comments 1,714 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.
barbara kennedy 2700025GG7 email@example.com Tags:  mainframe ztiv service-mgmt tivz zos 1 Comment 1,695 Visits
Good news for all is that the “Call for Papers” for Pulse 2010 has been extended by popular demand. November 20th is the revised deadline so there is more time to finalize creative input. I spoke with Marcus Boone, product manager for Tivoli’s system z portfolio, regarding suggestions for Pulse participation. He is anxious to hear from those customers who can share real-world experiences on how an integrated approach to service management on System z is creating real benefits. Virtualization projects with savings, new Linux workload projects or best practices in the very complex world of ‘always available’ are good examples. Marcus believes Pulse 2010’s emphasis on alternative forms of customer participation, such as roundtables, panels and open discussions to support a topic will be both more interesting and more meaningful to all.
Please plan to join the conversation. Submit your proposal online at http://www.ibm.com/software/tivoli/pulse/.
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.