| Author |
Message
|
| ajaykumar |
 Posted: Tue Oct 21, 2008 2:41 am Post subject: How to get the count of committed messages in a queue |
 |
|
Novice
Joined: 20 Sep 2008
Posts: 10
|
Hi All,
We have a program that checks for the depth of queue and if the depth returned in non zero then it tries to get the message from the queue. But the problem is checking for depth returns the number of messages that are there in the queue(both committed & non committed) and issuing a get message based on the depth may not be the correct way.I would like to know can we know the number of committed messages in queue. |
|
| Back to top |
|
 |
| David.Partridge |
| Posted: Tue Oct 21, 2008 2:54 am Post subject: |
|
|
Master
Joined: 28 Jun 2001
Posts: 249
|
In general you wouldn't want to check the q depth from an application. Normal procedure would be to have the queue manager start the application using TRIGTYPE(FIRST) on the queue, and the application then does get/wait until the queue is empty (2033), at which point it would terminate.
The only case in which you might want to do otherwise is in a CICS initiation application which starts a number of application instances to drain a queue and the number of instances started is controlled by Q depth (e.g. start one instance if depth <20, two if < 50 etc. with an upper limit).
_________________
Cheers,
David C. Partridge |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Tue Oct 21, 2008 3:12 am Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
| David.Partridge wrote: |
In general you wouldn't want to check the q depth from an application. Normal procedure would be to have the queue manager start the application using TRIGTYPE(FIRST) on the queue, and the application then does get/wait until the queue is empty (2033), at which point it would terminate.
The only case in which you might want to do otherwise is in a CICS initiation application which starts a number of application instances to drain a queue and the number of instances started is controlled by Q depth (e.g. start one instance if depth <20, two if < 50 etc. with an upper limit). |
Some CICS shops do not go to so much trouble. The transaction is "T Classed" (only allow x concurrent instances of the transaction) and the triggering is set to every. The downside is you do not get such a gradual ramp up of resources. You go right to the max allowed if you have enough work in the queue. 
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| ajaykumar |
| Posted: Tue Oct 21, 2008 11:24 pm Post subject: |
|
|
Novice
Joined: 20 Sep 2008
Posts: 10
|
Thanks David,
The application that i mentioned above has got a method which checks for depth and also gets the message from the queue. These methods are called by another application.So when the application tries to know the depth if depth is non zero it then attempts to get the message. Sometimes its not able to get the message though there are messages in the queue and returns 2033. One possible reason could be that the getCurrentDepth returns the depth os the queue irrespective of the statius of messages in the queue(Committed ,Uncommitted) due to which sometimes it gets and sometimes it isnt able to get the message. So i would like know is there any way by which i could know weteher the messages in the queue are committed and then issue the get message.
This is happening on Unix,Linux environments. |
|
| Back to top |
|
|
| David.Partridge |
| Posted: Tue Oct 21, 2008 11:29 pm Post subject: |
|
|
Master
Joined: 28 Jun 2001
Posts: 249
|
The point I was trying to make is that this is bad application design, and it needs to be changed. I don't believe there is a simple way (or even a complex one) to get the information you are asking for, and you shouldn't be doing that anyway.
_________________
Cheers,
David C. Partridge |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Wed Oct 22, 2008 12:47 am Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
| ajaykumar wrote: |
Thanks David,
The application that i mentioned above has got a method which checks for depth and also gets the message from the queue. These methods are called by another application.So when the application tries to know the depth if depth is non zero it then attempts to get the message. Sometimes its not able to get the message though there are messages in the queue and returns 2033. One possible reason could be that the getCurrentDepth returns the depth os the queue irrespective of the statius of messages in the queue(Committed ,Uncommitted) due to which sometimes it gets and sometimes it isnt able to get the message. So i would like know is there any way by which i could know weteher the messages in the queue are committed and then issue the get message.
This is happening on Unix,Linux environments. |
Don't do any type of queue depth checking. When called just issue an MQGET. If the reason code returned is 2033 you can send back no message available
_________________
MQ & Broker admin |
|
| Back to top |
|
|
|
|
