| Author |
Message
|
| bharathvn |
 Posted: Mon Sep 20, 2010 1:58 am Post subject: Message logging using Channel exits. |
 |
|
Newbie
Joined: 25 Mar 2010
Posts: 6
|
Hello,
We have requirement to log all the messages that comes in and goes out of our queue manager.
Earlier our MQ was in AIX system, we were using a c++ program in channel exits. Now we migrated to Redhat linux and the old c++ program that was written fot AIX environment is not working in Linux.
As an alternative we tried using a java program in triggering section of queues. but triggering is kind of unreliable for the setup that we are having.
Can we use java program in channel exits? or is there any alternative?
Thanks in advance
Bharath |
|
| Back to top |
|
 |
| mqjeff |
| Posted: Mon Sep 20, 2010 2:13 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
Yes, it's true that AIX and linux are not binarily compatible. So you would need to recompile any program on linux from the source.
Coincidentally, there is a discussion of SupportPac MA0Z going on. You should look at it. |
|
| Back to top |
|
|
| bharathvn |
| Posted: Mon Sep 20, 2010 9:53 am Post subject: |
|
|
Newbie
Joined: 25 Mar 2010
Posts: 6
|
Sorry I missed an information.
We need to have a copy of the messages that goes out and comes in, in a local queue rather than a file.
For Eg. messages that goes out should be in Q.OUT.LOG.
and that comes in, in Q.IN.LOG |
|
| Back to top |
|
|
| Vitor |
| Posted: Mon Sep 20, 2010 9:58 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| bharathvn wrote: |
| We need to have a copy of the messages that goes out and comes in, in a local queue rather than a file. |
a) Why? What requirement does such logging meet? An answer of "because the client asked for it" is not acceptable. I mean a business or technical requirement.
b) Why are you trying to obtain this at a channel level, i.e. all messages entering over a given route regardless of target queue. An answer of "because we have too many local queues to monitor" should illuminate point a) above.....
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| bharathvn |
| Posted: Tue Sep 21, 2010 8:03 am Post subject: |
|
|
Newbie
Joined: 25 Mar 2010
Posts: 6
|
Thanks mqjeff and vitor for your reply.
@vitor.
1. Most of the time we need to drop the message that already sent to client again for several business reasons. in that time if we have the message in queue its easier to copy the messages and redrop it using tools like M071.
Here, Unicode characters such as double byte space and japanese characters are part of messages. while storing these kind of messages to a file and fetching the same for redropping messages mat get corrupted.
2. We tried to do it in queue level by using triggering mechanism, we wrote a java code to copy the message to log queue. and Poll queue(from which our WBI connectors would pick it up) but this technique proved unreliable since some of the messages were getting corrupted.
In AIX we were using a c++ program in channel exits to log the message to a queue. We tried to use the same program by recompiling it. it did not work.
We thought if we can write Java program and use the class file in channel exits, we can use the same class file in several environments.
is it possible to use the class file in channel exits?
Thanks
Bharath. |
|
| Back to top |
|
|
| Vitor |
| Posted: Tue Sep 21, 2010 8:14 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| bharathvn wrote: |
| Most of the time we need to drop the message that already sent to client again for several business reasons. |
Then the sending application should have the ability to reproduce the message when the business requires it. That sort of business reproduction should not require the involvement of the technical admins.
I'm surprised your audit people are happy with this. In theory this solution means that an admin can not only resubmit any message but produce any message desired using the editing abilities of MO71 and one of the existing messages as a template. Typically they dislike such things.
| bharathvn wrote: |
| 2. We tried to do it in queue level by using triggering mechanism, we wrote a java code to copy the message to log queue. and Poll queue(from which our WBI connectors would pick it up) but this technique proved unreliable since some of the messages were getting corrupted. |
Sounds like a bug in the Java to me.
| bharathvn wrote: |
| In AIX we were using a c++ program in channel exits to log the message to a queue. We tried to use the same program by recompiling it. it did not work. |
Why not? What stopped you? While the 2 OS are not binary compatable, they are source compatable.
| bharathvn wrote: |
| is it possible to use the class file in channel exits? |
No. The channels have no JVM and the exits must be C.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Wed Sep 22, 2010 4:07 pm Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
| Vitor wrote: |
I'm surprised your audit people are happy with this. In theory this solution means that an admin can not only resubmit any message but produce any message desired using the editing abilities of MO71 and one of the existing messages as a template. Typically they dislike such things.
|
Any MQ Admin has this capability on non z/OS Queue Managers. Unless specifically prevented by RACF rules, they also have that same capability on z/OS QMs too.
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Wed Sep 22, 2010 6:53 pm Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
| Quote: |
| 2. We tried to do it in queue level by using triggering mechanism, we wrote a java code to copy the message to log queue. and Poll queue(from which our WBI connectors would pick it up) but this technique proved unreliable since some of the messages were getting corrupted. |
From what you say, most probably a CCSID issue, due to the fact that the program that was doing the work did not preserve a multibyte character environment. (JMS connection factory ccsid wrong, mq java base program not requesting the message or putting the message in a CCSID designed to preserve the multibyte characteristic of the source.)
And by the way just putting the bytes of the message into a DB would not solve the problem either. A good DB message log would need the identifiers (msg_id, correlid, msg_group, sequence, last in group, etc... plus message type, message format, CCSID and MQ Encoding
With this information you could then create a perfect replica of the original message (maybe with a different msg_id).
Have fun 
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| bharathvn |
| Posted: Thu Sep 23, 2010 6:22 pm Post subject: |
|
|
Newbie
Joined: 25 Mar 2010
Posts: 6
|
Thanks to all.. 
I will update in this thread about the decision that we took and the result of it.
-
Bharath |
|
| Back to top |
|
|
|
|
