| Author |
Message
|
| nsakthi |
 Posted: Thu Dec 20, 2012 5:26 am Post subject: detecting when the receiving queue is empty |
 |
|
Novice
Joined: 20 Dec 2012
Posts: 18
|
Good day
Our Job runs in every 2 hours and posts messages to the remote queue in MF queue manager, which is pointing to the local queue in windows queue manager.
We need to know the status of the previous run whether the messages got processed by receiving applications and the queue is empty before next job run.
My Question is, Is there a way we
may read a queue on receiving queue manager to detect if its empty? |
|
| Back to top |
|
 |
| mqjeff |
| Posted: Thu Dec 20, 2012 5:53 am Post subject: Re: detecting when the receiving queue is empty |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
| nsakthi wrote: |
My Question is, Is there a way we
may read a queue on receiving queue manager to detect if its empty? |
There is a way, but not from zOS.
And it's the wrong solution anyway.
You should alter the process to cause the receiving applications to send a reply message indicating that they have processed something.
Then you can tell when you have received all of the necessary replies. |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Thu Dec 20, 2012 7:03 am Post subject: Re: detecting when the receiving queue is empty |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9399
Location: US: west coast, almost. Otherwise, enroute.
|
| nsakthi wrote: |
Good day
Our Job runs in every 2 hours |
For clarity: This is a z/OS batch job, yes?
| nsakthi wrote: |
| and posts messages to the remote queue in MF queue manager, which is pointing to the local queue in windows queue manager. |
The messages produced by the z/OS batch job are transmitted down the Sender-Receiver channel to a Windows qmgr and queue, yes?
| nsakthi wrote: |
We need to know the status of the previous run whether the messages got processed by receiving applications and the queue is empty before next job run.
My Question is, Is there a way we may read a queue on receiving queue manager to detect if its empty? |
Do you have any process automation tools (Tivoli, for example) that can deploy an agent on the Windows image, that would notify the agent on z/OS that the Windows app has consumed the messages?
_________________
I like deadlines. I like to wave as they pass by.
ב''ה
Lex Orandi, Lex Credendi, Lex Vivendi. As we Worship, So we Believe, So we Live. |
|
| Back to top |
|
|
| nsakthi |
| Posted: Thu Dec 20, 2012 7:46 am Post subject: detecting when the receiving queue is empty |
|
|
Novice
Joined: 20 Dec 2012
Posts: 18
|
Yes. Its a Z/OS batch job which runs every two hours
we are having server-requester channel setup btw mainframe and windows.
We use Tivoli for monitoring in our environment, and if that we can achieve by Tivoli, how / where do we notify the results, do we need a reply queue to achive this? |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Thu Dec 20, 2012 9:22 am Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9399
Location: US: west coast, almost. Otherwise, enroute.
|
You achieve that, you would research the product documentation.
_________________
I like deadlines. I like to wave as they pass by.
ב''ה
Lex Orandi, Lex Credendi, Lex Vivendi. As we Worship, So we Believe, So we Live. |
|
| Back to top |
|
|
| gbaddeley |
| Posted: Thu Dec 20, 2012 6:48 pm Post subject: Re: detecting when the receiving queue is empty |
|
|
Jedi
Joined: 25 Mar 2003
Posts: 2495
Location: Melbourne, Australia
|
| nsakthi wrote: |
...My Question is, Is there a way we
may read a queue on receiving queue manager to detect if its empty? |
Yes, an application can connect to the qm, open the queue, and inquire on the current depth. Good designs will not ever need to do this....
In a true asynchronous / decoupled MQ messaging design (like yours?) the producer of messages should be completely unconcerned about what the consumer of messages is doing.
Do you have a timing or business logic dependency that the consumer must process all of the previous batch of messages before a new batch is sent? Or is it just a capacity issue? Its really the responsibility of the receiving app to ensure that it is run as required.
_________________
Glenn |
|
| Back to top |
|
|
| nsakthi |
| Posted: Fri Dec 21, 2012 5:29 am Post subject: Re: detecting when the receiving queue is empty |
|
|
Novice
Joined: 20 Dec 2012
Posts: 18
|
Thanks for your response.
| Quote: |
| Do you have a timing or business logic dependency that the consumer must process all of the previous batch of messages before a new batch is sent? Or is it just a capacity issue? Its really the responsibility of the receiving app to ensure that it is run as required. |
[/quote]
Yes. There is a business logic involved.
I discussed the scenario with Automation team, and confirmed that monitoring agent can notify of the requester with status of queue depth at regular intervals. looking forward to test it.
Is there any otherway to get to know the status of delivery confirmation within MQ, not involving automation tool? |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Fri Dec 21, 2012 5:47 am Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7716
|
Explore MQ Reports messages for COA and COD, but then research here on why some of us think its problematic to rely on them.
Forget about MQ for a minute. Explain to us what exactly you need to know about the previous run and why you need to know this before you send the next run.
Unless your receiving queue is incredibly shallow and these messages are huge and numerous, I can almost guarantee you that understanding the depth of that queue is completely irrelevant to your real need.
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| nsakthi |
| Posted: Wed Dec 26, 2012 11:09 am Post subject: |
|
|
Novice
Joined: 20 Dec 2012
Posts: 18
|
Sorry.. I was on vaccation.
The business handles different activities in the flow, and pushing through one activity(which has around 2000 messages) at a time in a batch. The consumer will process those messages and sends a response back and it will be updated in the activity log at the producer end.
the picture at this point looks like
activity #1 = some value
activity #2 = some value
activity #3 = pending
Let say the consumer has some problem and could not process the activity #3 and so leave it in the queue.
The next run comes a long and see activity #3 is pending, so the job sends it again. now the queue has activity #3 twice in the queue. When consumer starts up again, this duplicate entry will cause the problem.
It arises the situation where producer of the messages would know the status of activity sent in previous run.
I would appreciate if you could help me out with any tips/suggestion to overcome this situation. |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Thu Dec 27, 2012 2:05 am Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20696
Location: LI,NY
|
| nsakthi wrote: |
Sorry.. I was on vaccation.
The business handles different activities in the flow, and pushing through one activity(which has around 2000 messages) at a time in a batch. The consumer will process those messages and sends a response back and it will be updated in the activity log at the producer end.
the picture at this point looks like
activity #1 = some value
activity #2 = some value
activity #3 = pending
Let say the consumer has some problem and could not process the activity #3 and so leave it in the queue.
The next run comes a long and see activity #3 is pending, so the job sends it again. now the queue has activity #3 twice in the queue. When consumer starts up again, this duplicate entry will cause the problem.
It arises the situation where producer of the messages would know the status of activity sent in previous run.
I would appreciate if you could help me out with any tips/suggestion to overcome this situation. |
Wrong design:
The provider does not have to know of the status.
The consumer can request an activity from the provider if this is what is needed. However with assured delivery, it is the responsibility of the consumer to process all messages.
Have fun 
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Thu Dec 27, 2012 6:12 am Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9399
Location: US: west coast, almost. Otherwise, enroute.
|
| fjb_saper wrote: |
... it is the responsibility of the consumer to process all messages.
Have fun |
This is one of those best-practice design thingies.
A well-behaved application is one in which the producer and consumer apps can tolerate, detect, and deal with duplicate (or missing) transaction request and reply messages. This has been discussed here many times. Search here for 'well-behaved'.
_________________
I like deadlines. I like to wave as they pass by.
ב''ה
Lex Orandi, Lex Credendi, Lex Vivendi. As we Worship, So we Believe, So we Live. |
|
| Back to top |
|
|
| nsakthi |
| Posted: Thu Dec 27, 2012 10:13 am Post subject: |
|
|
Novice
Joined: 20 Dec 2012
Posts: 18
|
Thanks for your suggestions  |
|
| Back to top |
|
|
|
|
