Author |
Message
|
janeks |
Posted: Tue Jul 14, 2009 6:23 am Post subject: MQ monitoring client receive send |
|
|
Newbie
Joined: 13 Jul 2009 Posts: 7
|
Hi
Can somebody adivce me how to log fact of clinet program taking off the message from the output queue?
One of our customers insists on such a log, he wants solid proof of his software receiving message from out MQ manager.
Is there any way to increase level of logging by MQ manager that it makes in the log entry about depositing message and the same message being taken off the queue?
We run MQ server on AS400 machine.
Thank you
Janusz |
|
Back to top |
|
 |
gs |
Posted: Tue Jul 14, 2009 7:14 am Post subject: |
|
|
 Master
Joined: 31 May 2007 Posts: 254 Location: Sweden
|
There's no message logging on a queue manager level. If the application owner requests a log, why not implement it in his software?
We've implemented logging in the Message Broker at those clients who use it. |
|
Back to top |
|
 |
janeks |
Posted: Tue Jul 14, 2009 10:48 pm Post subject: |
|
|
Newbie
Joined: 13 Jul 2009 Posts: 7
|
Hi GS
Thanks for your reply.
We already have application log, hwever we are unable to get and entry in it whe client application gets message from the queue. Customer requested proof on the system level, he does not believe in our application log. I would say it is 100% sure since the entry wpuld not exist if message wasn't successfuly put on the queue. What can I do, if somebody is stubborn.
Did you ever try receive/send exit routines? Can I use this mechanism to log moment when client application gets message from the queue?
If so, do you have any example of simple C or Java code I can use for such a roputine? How to set a java routine as a Receive/Send exit program? It resides on the IFS and MQ manager seems to allow only program strored in the librady to be servicing exit routines.
Best regards
Janusz |
|
Back to top |
|
 |
Mr Butcher |
Posted: Wed Jul 15, 2009 12:11 am Post subject: |
|
|
 Padawan
Joined: 23 May 2005 Posts: 1716
|
i would start at the point "why does the customer do not trust the application log"? What is the problem? Why is there the need to prove anything?
receive / send exits are not message driven, but somehow transfer driven. things look different from what you may know from channel message exits.
if you have control over the putting application, then maybe COD (confirm on delivery) is an option to get the date / time the message was read out of the queue. _________________ Regards, Butcher |
|
Back to top |
|
 |
janeks |
Posted: Wed Jul 15, 2009 2:39 am Post subject: |
|
|
Newbie
Joined: 13 Jul 2009 Posts: 7
|
Thanks, I will try Confirm On Deliver when I exhaust RECEIVE EXIT option. Transfer driven will be good enoug.
Why? Simply software provider for client application does not believe that his application is loosing messages. We are sure we put the message for hin into his queue.
Thanks
Janusz |
|
Back to top |
|
 |
vmcgloin |
Posted: Wed Jul 15, 2009 3:51 am Post subject: |
|
|
Knight
Joined: 04 Apr 2002 Posts: 560 Location: Scotland
|
It should be up to the client application to prove they are not receiving the messages. That said I think you are barking up the wrong tree with send/receive exits - have you looked at an API exit?
Or more simply (assuming proving it once will satisfy the customer and get you through integration testing, and that volumes are low or controllable) you could use queue monitoring and queue status to show the last put & get times of the queue in question.
Cheers,
Vicky |
|
Back to top |
|
 |
janeks |
Posted: Sat Jul 18, 2009 1:36 am Post subject: |
|
|
Newbie
Joined: 13 Jul 2009 Posts: 7
|
I tried MQRO_COD, MQRO_COA but I have compile error when trying to invoke mqmessage.report(int ddd) . Why I get this? I have all MQ related imports in my code. Is this functionality available in MQ v 5.3? I also can't set repyQueue and replyManager.
Thanks
Janusz |
|
Back to top |
|
 |
Vitor |
Posted: Sat Jul 18, 2009 6:44 am Post subject: |
|
|
 Grand High Poobah
Joined: 11 Nov 2005 Posts: 26093 Location: Texas, USA
|
janeks wrote: |
Is this functionality available in MQ v 5.3? |
Yes, and you should be planning to upgrade off that out of support version.
janeks wrote: |
I also can't set repyQueue and replyManager. |
Yes you can. Well clearly you can't, but it is possible to set them.
I echo the comment of my associate, "why does the customer do not trust the application log"?. These report options are tricky and have been the subject of much discussion here. Allow me to pose a couple of points here and allow you to search the forum for the rest:
- If you don't get a COD/COA message, what do you assume? That the message failed to arrive at it's destination or that the report message failed to return?
- If you assume the lack of a COD/COA means the message failed and you invoke whatever lost message processing you decide, how do you react if the COD/COA turns up later? _________________ Honesty is the best policy.
Insanity is the best defence. |
|
Back to top |
|
 |
janeks |
Posted: Sun Jul 19, 2009 2:03 am Post subject: |
|
|
Newbie
Joined: 13 Jul 2009 Posts: 7
|
The problem would be of much lower grade if it affected internal departments within one company. In my case it affects financial intitutions that exchange data via MQ. We have proof that our applicaiton performed PUT into a queue and there was no error during the process. Our counterparts request more solid proof that particular message was put into a queue they use. I was told that any log on the system level will be sufficient but Mq logs only errors and wornings for channels activities.
Can anyone give me a clue why I can't use mqmessage.report function in my code?
I have imports:
import com.ibm.mq.server.*;
import com.ibm.mq.MQOD;
import com.ibm.mq.MQMD;
import com.ibm.mqservices.*;
import com.ibm.mq.server.*;
import com.ibm.mqbind.*;
and code looks like in the book:
MQMessage msg = new MQMessage();
int ReportOptions = MQC.MQRO_COA|MQC.MQRO_COD|MQC.MQRO_EXPIRATION;
msg.report(ReportOptions); // <- this line dones not compile
msg.replyToQueueName("DELIVERYREPORTS");// <- this line dones not compile
msg.replyToQueueManagerName(MyMQmanagerName);// <- this line dones not compile
I will appreciate help.
Best regards
Janusz |
|
Back to top |
|
 |
Vitor |
Posted: Sun Jul 19, 2009 6:56 am Post subject: |
|
|
 Grand High Poobah
Joined: 11 Nov 2005 Posts: 26093 Location: Texas, USA
|
janeks wrote: |
In my case it affects financial intitutions that exchange data via MQ. |
Something I've been doing for about 2 decades professionally.
janeks wrote: |
We have proof that our applicaiton performed PUT into a queue and there was no error during the process. |
Then you have a simple "WMQ lost my message" situation. This happens on every site and there are many, many ways to resolve them.
janeks wrote: |
Our counterparts request more solid proof that particular message was put into a queue they use. |
And COD/COA messages don't always prove this - see my comments above. You're making a rod for your own back, and your counterparts will beat you with it.
I've been in your situation so many times over the years I've given up counting. I can count on the thumbs of one foot the number of times the recieving party have started out with "there must be a problem in our application"!
janeks wrote: |
Can anyone give me a clue why I can't use mqmessage.report function in my code? |
Well one thing stands out, even to my very limited Java.
janeks wrote: |
and code looks like in the book: |
Not in the book I look at it doesn't.
janeks wrote: |
msg.report(ReportOptions); // <- this line dones not compile
msg.replyToQueueName("DELIVERYREPORTS");// <- this line dones not compile
msg.replyToQueueManagerName(MyMQmanagerName);// <- this line dones not compile
|
I wonder if it fails to compile with any particually helpful message? Something like a missing property, or property not found.
You're much, much better off working out where this "missing" message is in fact going than starting down this road. Again I urge you to read the various discussions on this subject in the forum; it's a very common topic. You're on a rough and rocky road with these messages. _________________ Honesty is the best policy.
Insanity is the best defence. |
|
Back to top |
|
 |
Vitor |
Posted: Sun Jul 19, 2009 7:00 am Post subject: |
|
|
 Grand High Poobah
Joined: 11 Nov 2005 Posts: 26093 Location: Texas, USA
|
<plug>
Or if your site is wound that tightly about missing messages, have them contact the nice people at Cressida, spend some money and get a warm fuzzy feeling.
</plug>
<disclaimer>
Other monitoring products are available which may or may not suit your needs.
</disclaimer> _________________ Honesty is the best policy.
Insanity is the best defence. |
|
Back to top |
|
 |
fjb_saper |
Posted: Sun Jul 19, 2009 8:49 am Post subject: |
|
|
 Grand High Poobah
Joined: 18 Nov 2003 Posts: 20756 Location: LI,NY
|
Vitor... You're assuming that his message was persistent in the first place.
He only said that he knew for sure they put the message to the queue. He did not say anything about message persistency, or if he did I must have missed that... Looking at his coding exemple I wouldn't be too sure about it...
 _________________ MQ & Broker admin |
|
Back to top |
|
 |
Vitor |
Posted: Sun Jul 19, 2009 10:20 am Post subject: |
|
|
 Grand High Poobah
Joined: 11 Nov 2005 Posts: 26093 Location: Texas, USA
|
fjb_saper wrote: |
Vitor... You're assuming that his message was persistent in the first place. |
I'm actually assuming the opposite as the most likely way for a message to "disappear". I just decided to offer the fishing manual rather than throw a fish... _________________ Honesty is the best policy.
Insanity is the best defence. |
|
Back to top |
|
 |
janeks |
Posted: Tue Jul 21, 2009 12:56 am Post subject: |
|
|
Newbie
Joined: 13 Jul 2009 Posts: 7
|
|
Back to top |
|
 |
Vitor |
Posted: Tue Jul 21, 2009 1:02 am Post subject: |
|
|
 Grand High Poobah
Joined: 11 Nov 2005 Posts: 26093 Location: Texas, USA
|
janeks wrote: |
Can you point me to the book you are looking at? Is it some sort of secret publication I can't get access to?
|
No, it's the Java manual you'll find in the infocentre. Link at the top of this page. _________________ Honesty is the best policy.
Insanity is the best defence. |
|
Back to top |
|
 |
|