The new OMEGAMON XE for Messaging V7.3.0 provides both real-time and historical performance and availability management capabilities for your IBM MQ. One of the enhancements in V7.3.0 is geared toward the new Enhanced 3270 user interface (E3270UI) and provides Near-Term-History. You can quickly and easily resolve problems by viewing the resources when the symptoms first started – in the last few hours or past few days. This release delivers what focus groups told us to be the most important:
-
Queue Long Term History
-
Queue Status (only if you enable MONQ in queue manager)
-
Channel Long-Term History
-
Channel Summary (only if you use client connections to SVRCONN channels)
-
Current Queue Manager Status
-
Buffer Manager Long-Term History
-
Log Manager Long-Term History
-
Message Manager Long-Term History
-
Topic Manager Long-Term History
-
Page Set Long-Term History
-
Application Long-Term History (only if you enable and use Application Statistics feature)
-
Application Queue Long-Term History (only if you enable and use Application Statistics feature)
-
Application Transaction/Program Long-Term History (only if you enable and use Application Statistics feature)
Here is an example of how the OMEGAMON XE for Messaging V7.3.0 MQ monitoring agent detects a problem that happened in the past:
1. Subject Matter Expert Jim received a call from an operator, Annette, who reported that she received a situation alert indicating that the queue depth is getting high. Thus Jim logged into the Enhanced 3270UI of OMEGAMON XE for Messaging to take a look, and he noticed that in the Current Queue Manager Status the Queue Health of the queue manager Q723 is in Critical status, which was caused by a High Depth Queue:

2. Then Jim clicked the High Depth Queue Count column to see which queue is in high depth, and he noticed that the % Full of Queue APP7.OUT.Q1 is 90.0%:

3. After he entered "S" to select the Queue Status Details of the Queue APP7.OUT.Q1, from the view of Application with Open Handle for the Queue, he could see the Queue was being opened by 2 applications and APP7G and APP7P:

4. In general, as for high depth queue problem, there might be something wrong with the MQ application, possibly not fast enough to process the messages. Therefore, Jim switched to the second tab of the Queue Status to check the Queue Statistics Latest Sample. However, the latest queue statistics sample showed that the Msgs Put per Sec was equal to Msg Read per Sec:

5. Thus Jim decided to check its Near-Term-History. He pressed F3 back to previous panel and entered “H” to select the Queue Statistics History of the queue APP7.OUT.Q1. In the Queue Statistics History panel of queue APP7.OUT.Q1, Jim noticed that the Get Status was changed to Disabled at 04:30:00, which led to the growth of the % Full to 64.5%:

6. Then Jim selected the record of 04:30:00 to check its details, and in the Queue Status History, Jim noticed that the Last Get Time was 04:21:26. Jim was told there was scheduled application maintenance at that time, which turned the Get Status to Disabled:

7. Jim switched back to the previous panel, scrolled right to check the put rate and read rate trend, and he found that the Msg Put per Sec was still equal to Msg Read per Sec after the Get Status changed back to Enabled. Actually an extra batch job needs to be submitted to speed up the message processing for such case. Thus Jim called operation team and told them to submit the extra batch job to speed the message processing.
Also, please check out the following blog on the “Recommended Attribute Groups for Historical Collection for the WebSphere MQ Monitoring Agent”:
Tags: 
performance
omegamon
zos
messaging
mq
management
e3270ui