Data queues are designed to provide fast communications between programs. You might have a dozen programs feeding entries onto a queue and a single program receiving those entries. Problems begin to arise when that single receiver program fails and thus the data queue starts to fill up. Unfortunately the contents of data queues are almost invisible, but this is where QSystem Monitor can help.
QSystem Monitor has two monitors that specifically assist with data queue monitoring:
The following window shows how QSystem Monitor can monitor for the number of entries for a specific data queue:
In this example, we are monitoring queue MMTCPDTAQ in library MMDEMO. One of the features of the product is that it can go out to the systems and locate all the objects available for monitoring. This saves you the aggravation of having to know which queues need to be monitored.
Having defined the queue, we can now look at the threshold:
In our example, we can see that we have a threshold set if the number of entries exceeds 100. Note: The threshold can also be inverted, so that we can also monitor if the number of entries falls below a certain value.
In addition to the number of entries, the monitor also checks the status of the data queue, reporting back on whether the queue is damaged, not found, etc.
Note also the “Msg” column. A value in this column indicates that we wish to send a message to an IBM i message queue when the threshold is exceeded. We can then use QMessage Monitor to monitor for this message and send alerts accordingly.
The QSystem Monitor console has a window that can show only those monitors that have exceeded their thresholds:
Our window above shows an example of how the information can be displayed. The window is currently monitoring five systems/partitions and there are a number of monitors running (in actual fact 2500 monitors across the systems).
The Current Thresholds window is showing two conditions at present, one for our data queue entry issue and a second for the number of libraries beginning with “QSC”.
Other windows are showing the size of libraries and objects on the network in real time.
Data queues have a maximum size and a maximum entry length. From these figures it's possible to calculate the percentage of available capacity for a data queue. Once it reaches 100% it will not accept any more entries.
The same technique can be used to monitor the percentage used for a specific data queue.
Having identified how we can monitor data queues in real time, it is also useful to be able to monitor them historically. This type of monitoring may show trends where the queues are getting full at certain times during the day for example. A second module within Robot Monitor, the History Summary, allows us to show this data.
The above window shows the same data queue and its average depth over the past 12 months, on a monthly basis.
If we drill down for the month of July, we can get the monthly average breakdown as shown below:
If we now select the 27th, as that looks suspiciously high, we get the following view:
If we now drill down even further from 14:00 to 15:00 we get the following view:
It is now even possible to drill down at 14:05 and see which jobs were actually running at the time when our entries started to increase:
The presence of the MON.LOCAL job, tells us that there was a communications issue on this system which would result in this particular data queue filling up.
We have shown how we can monitor two attributes of data queues in real time, namely the number of entries and the percent full. In addition to that, we have also shown that we can set thresholds for these monitors to monitor for excessive entries, or insufficient entries, again in real time. Finally, we have also shown that we can subsequently analyze the monitoring of these queues to highlight trends or conditions over a period of hours, days, weeks, or months.
Still have questions? We can help. Submit a case to Technical Support.