​I have a client who has 'lost' an MQ message, and is asking if we can prove that they received (MQGET) from the MQ queue? We have IB logs that show that the message was MQPUT onto the queue. The message is question is not on a DLQ or stuck in a XMIT queue. This is just a single instance problem, and in general this a working scenario.

BUT In more general terms, is there a way (an exit perhaps) to create an audit log of every message that moves thru a queue manager?

------------------------------
hirschel wasserman
------------------------------

Hi Hirschel

One point to look into is non-repudiation messages from MQ.  Read up on COA (confirmation on arrival) and COD (confirmation on delivery).  It is a mechanism for the sending application to ask the target queue manager (very important, the target queue manager) to respond when a message arrives at its final destination queue with a COA.  It can then also respond with a COD when the message is destructively read from the queue.  In this <g class="gr_ gr_512 gr-alert gr_gramm gr_inline_cards gr_run_anim Punctuation only-ins replaceWithoutSep" id="512" data-gr-id="512">way</g> the source application/system can then log these COA and COD messages in a database for non-repudiation.  It is important to note that it is the queue manager that respond to these messages and not the target application.

Combine this with error messages etc. and you can get a very good idea of what happened to a message.

------------------------------
Francois van der Merwe
Hybrid Cloud / Integration Specialist Tech Sales
IBM
Johannesburg
+27825569467
------------------------------

Original Message:
Sent: 07-25-2018 19:26
From: hirschel wasserman
Subject: audit log of every message going thru MQ

​I have a client who has 'lost' an MQ message, and is asking if we can prove that they received (MQGET) from the MQ queue? We have IB logs that show that the message was MQPUT onto the queue. The message is question is not on a DLQ or stuck in a XMIT queue. This is just a single instance problem, and in general this a working scenario.

BUT In more general terms, is there a way (an exit perhaps) to create an audit log of every message that moves thru a queue manager?

------------------------------
hirschel wasserman
------------------------------

As mentioned in an earlier reply, CODs could be used, but alternatively MQ (the distributed version, not z/OS) does support the development of an Exit.  See https://www.ibm.com/support/knowledgecenter/en/SSFKSJ_9.0.0/com.ibm.mq.ref.dev.doc/q109670_.html.  Incidentally, if the QM involved happens to be a z/OS QM, then MQ z/OS also includes a tool that can process the logs and print out the log entries showing the processing of the message, but this would  only be useful if the message was Persistent (and even then.... not every Persistent message is logged either...).

------------------------------
Carl Farkas
------------------------------

Original Message:
Sent: 07-25-2018 19:26
From: hirschel wasserman
Subject: audit log of every message going thru MQ

​I have a client who has 'lost' an MQ message, and is asking if we can prove that they received (MQGET) from the MQ queue? We have IB logs that show that the message was MQPUT onto the queue. The message is question is not on a DLQ or stuck in a XMIT queue. This is just a single instance problem, and in general this a working scenario.

BUT In more general terms, is there a way (an exit perhaps) to create an audit log of every message that moves thru a queue manager?

------------------------------
hirschel wasserman
------------------------------

​Dankie Francois, thanks Carl.
That is useful MQ info.

------------------------------
hirschel wasserman
------------------------------

Original Message:
Sent: 07-26-2018 03:08
From: Carl Farkas
Subject: audit log of every message going thru MQ

As mentioned in an earlier reply, CODs could be used, but alternatively MQ (the distributed version, not z/OS) does support the development of an Exit.  See https://www.ibm.com/support/knowledgecenter/en/SSFKSJ_9.0.0/com.ibm.mq.ref.dev.doc/q109670_.html.  Incidentally, if the QM involved happens to be a z/OS QM, then MQ z/OS also includes a tool that can process the logs and print out the log entries showing the processing of the message, but this would  only be useful if the message was Persistent (and even then.... not every Persistent message is logged either...).

------------------------------
Carl Farkas

Original Message:
Sent: 07-25-2018 19:26
From: hirschel wasserman
Subject: audit log of every message going thru MQ

​I have a client who has 'lost' an MQ message, and is asking if we can prove that they received (MQGET) from the MQ queue? We have IB logs that show that the message was MQPUT onto the queue. The message is question is not on a DLQ or stuck in a XMIT queue. This is just a single instance problem, and in general this a working scenario.

BUT In more general terms, is there a way (an exit perhaps) to create an audit log of every message that moves thru a queue manager?

------------------------------
hirschel wasserman
------------------------------

As Carl and Francois have suggested, look at COD.
If the application is retrieving the message within a UOW and rolls back, then the COD report message will NOT be sent so you need to work out from your audit requirements whether you want to know if an application successfully retrieved a message (in which case COD might fit the bill) or whether you want to know if it just made the attempt (in which case a COD that rolls back may not fit the bill).
You will have some work to do to match the COD report message with the message that was MQPUT but if Msgid/CoreliD won't do it, then you can request that the COD report includes some of the actual message data which might include a more readily identifiable piece of data.
Of course, what COD will tell you is that the message has "left the MQ domain". If the application then "loses" the message, MQ can't tell you that !

------------------------------
Dermot Flaherty
MQ Solutions Architect
Contractor
------------------------------

Original Message:
Sent: 07-26-2018 19:56
From: hirschel wasserman
Subject: audit log of every message going thru MQ

​Dankie Francois, thanks Carl.
That is useful MQ info.

------------------------------
hirschel wasserman

Original Message:
Sent: 07-26-2018 03:08
From: Carl Farkas
Subject: audit log of every message going thru MQ

As mentioned in an earlier reply, CODs could be used, but alternatively MQ (the distributed version, not z/OS) does support the development of an Exit.  See https://www.ibm.com/support/knowledgecenter/en/SSFKSJ_9.0.0/com.ibm.mq.ref.dev.doc/q109670_.html.  Incidentally, if the QM involved happens to be a z/OS QM, then MQ z/OS also includes a tool that can process the logs and print out the log entries showing the processing of the message, but this would  only be useful if the message was Persistent (and even then.... not every Persistent message is logged either...).

------------------------------
Carl Farkas

Original Message:
Sent: 07-25-2018 19:26
From: hirschel wasserman
Subject: audit log of every message going thru MQ

​I have a client who has 'lost' an MQ message, and is asking if we can prove that they received (MQGET) from the MQ queue? We have IB logs that show that the message was MQPUT onto the queue. The message is question is not on a DLQ or stuck in a XMIT queue. This is just a single instance problem, and in general this a working scenario.

BUT In more general terms, is there a way (an exit perhaps) to create an audit log of every message that moves thru a queue manager?

------------------------------
hirschel wasserman
------------------------------

Hi,

That's an very interesting subject. Does anybody has an example how to use COA and COD ? For example if I have two Java JMS applications, one for put and one for get ?   

The goal we have is always be able to deliver the proof that MQ is not the one to blame.  

We cannot use exits, because we are running on MQ Appliances M2001B.

Background:
All our queues are persistent. But sometimes we have internal discussions that messages have been "dissapeared" from MQ. If analyses are done most times the conclusion is that the exceptionshandling on the MQ Client is missing or not correctly implemented. Off course MQ can't help that.

Hope to hear from you.
Kind Regards



------------------------------
Bernard Pittens
Integration Engeneer
Sligro Foodgroup B.V.
Veghel
------------------------------

Original Message:
Sent: 07-27-2018 02:06
From: Dermot Flaherty
Subject: audit log of every message going thru MQ

As Carl and Francois have suggested, look at COD.
If the application is retrieving the message within a UOW and rolls back, then the COD report message will NOT be sent so you need to work out from your audit requirements whether you want to know if an application successfully retrieved a message (in which case COD might fit the bill) or whether you want to know if it just made the attempt (in which case a COD that rolls back may not fit the bill).
You will have some work to do to match the COD report message with the message that was MQPUT but if Msgid/CoreliD won't do it, then you can request that the COD report includes some of the actual message data which might include a more readily identifiable piece of data.
Of course, what COD will tell you is that the message has "left the MQ domain". If the application then "loses" the message, MQ can't tell you that !

------------------------------
Dermot Flaherty
MQ Solutions Architect
Contractor

Original Message:
Sent: 07-26-2018 19:56
From: hirschel wasserman
Subject: audit log of every message going thru MQ

​Dankie Francois, thanks Carl.
That is useful MQ info.

------------------------------
hirschel wasserman

Original Message:
Sent: 07-26-2018 03:08
From: Carl Farkas
Subject: audit log of every message going thru MQ

As mentioned in an earlier reply, CODs could be used, but alternatively MQ (the distributed version, not z/OS) does support the development of an Exit.  See https://www.ibm.com/support/knowledgecenter/en/SSFKSJ_9.0.0/com.ibm.mq.ref.dev.doc/q109670_.html.  Incidentally, if the QM involved happens to be a z/OS QM, then MQ z/OS also includes a tool that can process the logs and print out the log entries showing the processing of the message, but this would  only be useful if the message was Persistent (and even then.... not every Persistent message is logged either...).

------------------------------
Carl Farkas

Original Message:
Sent: 07-25-2018 19:26
From: hirschel wasserman
Subject: audit log of every message going thru MQ

​I have a client who has 'lost' an MQ message, and is asking if we can prove that they received (MQGET) from the MQ queue? We have IB logs that show that the message was MQPUT onto the queue. The message is question is not on a DLQ or stuck in a XMIT queue. This is just a single instance problem, and in general this a working scenario.

BUT In more general terms, is there a way (an exit perhaps) to create an audit log of every message that moves thru a queue manager?

------------------------------
hirschel wasserman
------------------------------

Hi Bernard
See "Report messages" section in https://www.ibm.com/support/knowledgecenter/en/SSFKSJ_7.5.0/com.ibm.mq.dev.doc/q022870_.htm

<g class="gr_ gr_38 gr-alert gr_spell gr_inline_cards gr_run_anim ContextualSpelling ins-del multiReplace" id="38" data-gr-id="38">Ibm</g>		remove preview
View this on <g class="gr_ gr_40 gr-alert gr_spell gr_inline_cards gr_run_anim ContextualSpelling ins-del multiReplace" id="40" data-gr-id="40">Ibm</g> >

------------------------------
Francois van der Merwe
Hybrid Cloud / Integration Specialist Tech Sales
IBM
Johannesburg
+27825569467
------------------------------

Original Message:
Sent: 07-29-2018 16:41
From: Bernard Pittens
Subject: audit log of every message going thru MQ

Hi,

That's an very interesting subject. Does anybody has an example how to use COA and COD ? For example if I have two Java JMS applications, one for put and one for get ?

The goal we have is always be able to deliver the proof that MQ is not the one to blame.

We cannot use exits, because we are running on MQ Appliances M2001B.

Background:
All our queues are persistent. But sometimes we have internal discussions that messages have been "dissapeared" from MQ. If analyses are done most times the conclusion is that the exceptionshandling on the MQ Client is missing or not correctly implemented. Off course MQ can't help that.

Hope to hear from you.
Kind Regards



------------------------------
Bernard Pittens
Integration Engeneer
Sligro Foodgroup B.V.
Veghel

Original Message:
Sent: 07-27-2018 02:06
From: Dermot Flaherty
Subject: audit log of every message going thru MQ

As Carl and Francois have suggested, look at COD.
If the application is retrieving the message within a UOW and rolls back, then the COD report message will NOT be sent so you need to work out from your audit requirements whether you want to know if an application successfully retrieved a message (in which case COD might fit the bill) or whether you want to know if it just made the attempt (in which case a COD that rolls back may not fit the bill).
You will have some work to do to match the COD report message with the message that was MQPUT but if Msgid/CoreliD won't do it, then you can request that the COD report includes some of the actual message data which might include a more readily identifiable piece of data.
Of course, what COD will tell you is that the message has "left the MQ domain". If the application then "loses" the message, MQ can't tell you that !

------------------------------
Dermot Flaherty
MQ Solutions Architect
Contractor

Original Message:
Sent: 07-26-2018 19:56
From: hirschel wasserman
Subject: audit log of every message going thru MQ

​Dankie Francois, thanks Carl.
That is useful MQ info.

------------------------------
hirschel wasserman

Original Message:
Sent: 07-26-2018 03:08
From: Carl Farkas
Subject: audit log of every message going thru MQ

As mentioned in an earlier reply, CODs could be used, but alternatively MQ (the distributed version, not z/OS) does support the development of an Exit.  See https://www.ibm.com/support/knowledgecenter/en/SSFKSJ_9.0.0/com.ibm.mq.ref.dev.doc/q109670_.html.  Incidentally, if the QM involved happens to be a z/OS QM, then MQ z/OS also includes a tool that can process the logs and print out the log entries showing the processing of the message, but this would  only be useful if the message was Persistent (and even then.... not every Persistent message is logged either...).

------------------------------
Carl Farkas

Original Message:
Sent: 07-25-2018 19:26
From: hirschel wasserman
Subject: audit log of every message going thru MQ

​I have a client who has 'lost' an MQ message, and is asking if we can prove that they received (MQGET) from the MQ queue? We have IB logs that show that the message was MQPUT onto the queue. The message is question is not on a DLQ or stuck in a XMIT queue. This is just a single instance problem, and in general this a working scenario.

BUT In more general terms, is there a way (an exit perhaps) to create an audit log of every message that moves thru a queue manager?

------------------------------
hirschel wasserman
------------------------------

Hi Bernard,

If you are on the MQ Appliance you should be able to change the mqat.ini file using the appliance's commands and create an activity log of all that the target application does. You could then show that the application dequeued the message. That the messaged caused an exception and the app dropped the ball is then something that the app has to discover. No need for COD messages.

------------------------------
Francois Brandelik
Madison CT

------------------------------

Original Message:
Sent: 07-29-2018 16:41
From: Bernard Pittens
Subject: audit log of every message going thru MQ

Hi,

That's an very interesting subject. Does anybody has an example how to use COA and COD ? For example if I have two Java JMS applications, one for put and one for get ?

The goal we have is always be able to deliver the proof that MQ is not the one to blame.

We cannot use exits, because we are running on MQ Appliances M2001B.

Background:
All our queues are persistent. But sometimes we have internal discussions that messages have been "dissapeared" from MQ. If analyses are done most times the conclusion is that the exceptionshandling on the MQ Client is missing or not correctly implemented. Off course MQ can't help that.

Hope to hear from you.
Kind Regards



------------------------------
Bernard Pittens
Integration Engeneer
Sligro Foodgroup B.V.
Veghel

Original Message:
Sent: 07-27-2018 02:06
From: Dermot Flaherty
Subject: audit log of every message going thru MQ

As Carl and Francois have suggested, look at COD.
If the application is retrieving the message within a UOW and rolls back, then the COD report message will NOT be sent so you need to work out from your audit requirements whether you want to know if an application successfully retrieved a message (in which case COD might fit the bill) or whether you want to know if it just made the attempt (in which case a COD that rolls back may not fit the bill).
You will have some work to do to match the COD report message with the message that was MQPUT but if Msgid/CoreliD won't do it, then you can request that the COD report includes some of the actual message data which might include a more readily identifiable piece of data.
Of course, what COD will tell you is that the message has "left the MQ domain". If the application then "loses" the message, MQ can't tell you that !

------------------------------
Dermot Flaherty
MQ Solutions Architect
Contractor

Original Message:
Sent: 07-26-2018 19:56
From: hirschel wasserman
Subject: audit log of every message going thru MQ

​Dankie Francois, thanks Carl.
That is useful MQ info.

------------------------------
hirschel wasserman

Original Message:
Sent: 07-26-2018 03:08
From: Carl Farkas
Subject: audit log of every message going thru MQ

As mentioned in an earlier reply, CODs could be used, but alternatively MQ (the distributed version, not z/OS) does support the development of an Exit.  See https://www.ibm.com/support/knowledgecenter/en/SSFKSJ_9.0.0/com.ibm.mq.ref.dev.doc/q109670_.html.  Incidentally, if the QM involved happens to be a z/OS QM, then MQ z/OS also includes a tool that can process the logs and print out the log entries showing the processing of the message, but this would  only be useful if the message was Persistent (and even then.... not every Persistent message is logged either...).

------------------------------
Carl Farkas

Original Message:
Sent: 07-25-2018 19:26
From: hirschel wasserman
Subject: audit log of every message going thru MQ

​I have a client who has 'lost' an MQ message, and is asking if we can prove that they received (MQGET) from the MQ queue? We have IB logs that show that the message was MQPUT onto the queue. The message is question is not on a DLQ or stuck in a XMIT queue. This is just a single instance problem, and in general this a working scenario.

BUT In more general terms, is there a way (an exit perhaps) to create an audit log of every message that moves thru a queue manager?

------------------------------
hirschel wasserman
------------------------------

Hi Bernard

Just to expand on what Francois has said, the feature which most closely matches what I think you are looking for here is application activity tracing: https://www.ibm.com/support/knowledgecenter/en/SS5K6E_9.0.0/com.ibm.mqa.doc/monitoring/mo00020_.htm

Our intent in the changes made to Activity Trace in V8 (with the first appliance release) was to provide exactly the kind of function described (audit, message tracking, problem analysis) without the need for custom exit code.  There is obviously a performance implication to enabling this as there would be for any audit mechanism, but with appropriate tuning it should be fairly low impact (and of course you may choose to enable it for only some applications or during certain periods).

We have considered extensions in this area - for example more control over exactly what is captured in the digest messages, or alternative options for selecting which activity is traced - so if you look at what is available today and find it doesn't meet your exact requirements we'd certainly be interested in that feedback, here/directly or via an RFE.

Hope this helps
Anthony

------------------------------
Anthony Beardsmore
IBM MQ Appliance Architect
IBM
------------------------------

Original Message:
Sent: 07-31-2018 03:52
From: Francois Brandelik
Subject: audit log of every message going thru MQ

Hi Bernard,

If you are on the MQ Appliance you should be able to change the mqat.ini file using the appliance's commands and create an activity log of all that the target application does. You could then show that the application dequeued the message. That the messaged caused an exception and the app dropped the ball is then something that the app has to discover. No need for COD messages.

------------------------------
Francois Brandelik
Madison CT


Original Message:
Sent: 07-29-2018 16:41
From: Bernard Pittens
Subject: audit log of every message going thru MQ

Hi,

That's an very interesting subject. Does anybody has an example how to use COA and COD ? For example if I have two Java JMS applications, one for put and one for get ?

The goal we have is always be able to deliver the proof that MQ is not the one to blame.

We cannot use exits, because we are running on MQ Appliances M2001B.

Background:
All our queues are persistent. But sometimes we have internal discussions that messages have been "dissapeared" from MQ. If analyses are done most times the conclusion is that the exceptionshandling on the MQ Client is missing or not correctly implemented. Off course MQ can't help that.

Hope to hear from you.
Kind Regards



------------------------------
Bernard Pittens
Integration Engeneer
Sligro Foodgroup B.V.
Veghel

Original Message:
Sent: 07-27-2018 02:06
From: Dermot Flaherty
Subject: audit log of every message going thru MQ

As Carl and Francois have suggested, look at COD.
If the application is retrieving the message within a UOW and rolls back, then the COD report message will NOT be sent so you need to work out from your audit requirements whether you want to know if an application successfully retrieved a message (in which case COD might fit the bill) or whether you want to know if it just made the attempt (in which case a COD that rolls back may not fit the bill).
You will have some work to do to match the COD report message with the message that was MQPUT but if Msgid/CoreliD won't do it, then you can request that the COD report includes some of the actual message data which might include a more readily identifiable piece of data.
Of course, what COD will tell you is that the message has "left the MQ domain". If the application then "loses" the message, MQ can't tell you that !

------------------------------
Dermot Flaherty
MQ Solutions Architect
Contractor

Original Message:
Sent: 07-26-2018 19:56
From: hirschel wasserman
Subject: audit log of every message going thru MQ

​Dankie Francois, thanks Carl.
That is useful MQ info.

------------------------------
hirschel wasserman

Original Message:
Sent: 07-26-2018 03:08
From: Carl Farkas
Subject: audit log of every message going thru MQ

As mentioned in an earlier reply, CODs could be used, but alternatively MQ (the distributed version, not z/OS) does support the development of an Exit.  See https://www.ibm.com/support/knowledgecenter/en/SSFKSJ_9.0.0/com.ibm.mq.ref.dev.doc/q109670_.html.  Incidentally, if the QM involved happens to be a z/OS QM, then MQ z/OS also includes a tool that can process the logs and print out the log entries showing the processing of the message, but this would  only be useful if the message was Persistent (and even then.... not every Persistent message is logged either...).

------------------------------
Carl Farkas

Original Message:
Sent: 07-25-2018 19:26
From: hirschel wasserman
Subject: audit log of every message going thru MQ

​I have a client who has 'lost' an MQ message, and is asking if we can prove that they received (MQGET) from the MQ queue? We have IB logs that show that the message was MQPUT onto the queue. The message is question is not on a DLQ or stuck in a XMIT queue. This is just a single instance problem, and in general this a working scenario.

BUT In more general terms, is there a way (an exit perhaps) to create an audit log of every message that moves thru a queue manager?

------------------------------
hirschel wasserman
------------------------------

​Hi Hirschel,
In practice, COA and COD report messages are not often used. They add extra complexity to the producer app to handle the messages and it adds overhead in MQ.  Apps should be able to trust MQ's assured delivery. Messages are never 'lost'. There is always a rational explanation for why a message ended up in a certain queue or was expired or discarded due to its QOS. This paradigm has never failed me.

If apps are concerned about traceability of MQ messages, audit logging should be done in the app code. eg. The apps log MQPUT returned reason code and message data, and log MQGET returned reason code and message data. The onus is on the app instances to be able to prove that they processed MQ messages. It can be a very enlightening experience for them.

If the failure can be reproduced or happens often, MQ trace features can be very useful, as it shows app MQI calls and results.

Cheers, Glenn.

------------------------------
Glenn Baddeley
Senior Middleware Software Engineer
Coles Supermarkets Australia Pty Ltd
Hawthorn East
+61 3 9829 4473
------------------------------

Original Message:
Sent: 07-25-2018 19:26
From: hirschel wasserman
Subject: audit log of every message going thru MQ

​I have a client who has 'lost' an MQ message, and is asking if we can prove that they received (MQGET) from the MQ queue? We have IB logs that show that the message was MQPUT onto the queue. The message is question is not on a DLQ or stuck in a XMIT queue. This is just a single instance problem, and in general this a working scenario.

BUT In more general terms, is there a way (an exit perhaps) to create an audit log of every message that moves thru a queue manager?

------------------------------
hirschel wasserman
------------------------------

Thanks Glenn.
I accidentally replied privately to Bernard a day or so ago and what I basically said was that COD (and COA) will give you a data volume/retention problem to add to the point about performance that you made.
So if today you have a system with a producer at one end and a consumer at the other and 200 msgs/sec are being sent and consumed, adding COD to each msg sent will cause 200 msgs/sec to now be sent to the designated ReplyToQ.
Clearly, these need to be archived somewhere (an RDBMS) to not only prevent Qfull, but to be able to support searches (perhaps hours or even days later) which may require a match on some field in the actual data (Order number for example).
So whether COD with some amount of data is used or - as you suggest - doing it in the application - there is a data volume/retention issue to be addressed.

Bernard responded and he said that he had found an interesting CapitalWare blog on the subject and the usual good advice from Roger LaCroix but that in his case, he would only want "tracking/auditing" capablity for some important flows which while being fairly large messages, only flow at the rate on 1 per sec.

I now think I have added the missing bits of discussion.

------------------------------
Dermot Flaherty
MQ Solutions Architect
Contractor
------------------------------

Original Message:
Sent: 07-30-2018 02:27
From: Glenn Baddeley
Subject: audit log of every message going thru MQ

​Hi Hirschel,
In practice, COA and COD report messages are not often used. They add extra complexity to the producer app to handle the messages and it adds overhead in MQ.  Apps should be able to trust MQ's assured delivery. Messages are never 'lost'. There is always a rational explanation for why a message ended up in a certain queue or was expired or discarded due to its QOS. This paradigm has never failed me.

If apps are concerned about traceability of MQ messages, audit logging should be done in the app code. eg. The apps log MQPUT returned reason code and message data, and log MQGET returned reason code and message data. The onus is on the app instances to be able to prove that they processed MQ messages. It can be a very enlightening experience for them.

If the failure can be reproduced or happens often, MQ trace features can be very useful, as it shows app MQI calls and results.

Cheers, Glenn.

------------------------------
Glenn Baddeley
Senior Middleware Software Engineer
Coles Supermarkets Australia Pty Ltd
Hawthorn East
+61 3 9829 4473

Original Message:
Sent: 07-25-2018 19:26
From: hirschel wasserman
Subject: audit log of every message going thru MQ

​I have a client who has 'lost' an MQ message, and is asking if we can prove that they received (MQGET) from the MQ queue? We have IB logs that show that the message was MQPUT onto the queue. The message is question is not on a DLQ or stuck in a XMIT queue. This is just a single instance problem, and in general this a working scenario.

BUT In more general terms, is there a way (an exit perhaps) to create an audit log of every message that moves thru a queue manager?

------------------------------
hirschel wasserman
------------------------------

Hi,

Thanks all for your info.
I think the mqat (Activity Trace) is the solution that fits our needs.

One question left:
We have in our DTAP environment Windows MQ v8(Dev, Test) and MQ Appliance v8 (in AC and PRD).

Is the behaviour of the MQ Windows system and the MQ Appiance regarding mqat the same ?
Can I use the same mqat.ini file in all environments ?

Kind Regards

------------------------------
Bernard Pittens
Integration Engeneer
Sligro Foodgroup B.V.
Veghel
------------------------------

Original Message:
Sent: 07-31-2018 08:21
From: Dermot Flaherty
Subject: audit log of every message going thru MQ

Thanks Glenn.
I accidentally replied privately to Bernard a day or so ago and what I basically said was that COD (and COA) will give you a data volume/retention problem to add to the point about performance that you made.
So if today you have a system with a producer at one end and a consumer at the other and 200 msgs/sec are being sent and consumed, adding COD to each msg sent will cause 200 msgs/sec to now be sent to the designated ReplyToQ.
Clearly, these need to be archived somewhere (an RDBMS) to not only prevent Qfull, but to be able to support searches (perhaps hours or even days later) which may require a match on some field in the actual data (Order number for example).
So whether COD with some amount of data is used or - as you suggest - doing it in the application - there is a data volume/retention issue to be addressed.

Bernard responded and he said that he had found an interesting CapitalWare blog on the subject and the usual good advice from Roger LaCroix but that in his case, he would only want "tracking/auditing" capablity for some important flows which while being fairly large messages, only flow at the rate on 1 per sec.

I now think I have added the missing bits of discussion.

------------------------------
Dermot Flaherty
MQ Solutions Architect
Contractor

Original Message:
Sent: 07-30-2018 02:27
From: Glenn Baddeley
Subject: audit log of every message going thru MQ

​Hi Hirschel,
In practice, COA and COD report messages are not often used. They add extra complexity to the producer app to handle the messages and it adds overhead in MQ.  Apps should be able to trust MQ's assured delivery. Messages are never 'lost'. There is always a rational explanation for why a message ended up in a certain queue or was expired or discarded due to its QOS. This paradigm has never failed me.

If apps are concerned about traceability of MQ messages, audit logging should be done in the app code. eg. The apps log MQPUT returned reason code and message data, and log MQGET returned reason code and message data. The onus is on the app instances to be able to prove that they processed MQ messages. It can be a very enlightening experience for them.

If the failure can be reproduced or happens often, MQ trace features can be very useful, as it shows app MQI calls and results.

Cheers, Glenn.

------------------------------
Glenn Baddeley
Senior Middleware Software Engineer
Coles Supermarkets Australia Pty Ltd
Hawthorn East
+61 3 9829 4473

Original Message:
Sent: 07-25-2018 19:26
From: hirschel wasserman
Subject: audit log of every message going thru MQ

​I have a client who has 'lost' an MQ message, and is asking if we can prove that they received (MQGET) from the MQ queue? We have IB logs that show that the message was MQPUT onto the queue. The message is question is not on a DLQ or stuck in a XMIT queue. This is just a single instance problem, and in general this a working scenario.

BUT In more general terms, is there a way (an exit perhaps) to create an audit log of every message that moves thru a queue manager?

------------------------------
hirschel wasserman
------------------------------

Hi Bernard

The MQ Appliance (from day one in V8) made some changes to MQAT - moving to an arguably more natural pub/sub model - which only became available in software MQ with V9.  So I'm afraid at V8 the exact configuration of activity trace will look a little different between the appliance and Windows (where you have to process the messages from the SYSTEM.ADMIN.TRACE.ACTIVITY.QUEUE), though you can do the same kinds of things.

Note that even at V9 you wouldn't be using the same 'file' since on the appliance you'd configure through setmqini - but the settings could then take effect identically.

Regards

------------------------------
Anthony Beardsmore
IBM MQ Appliance Architect
IBM
------------------------------

Original Message:
Sent: 08-06-2018 04:58
From: Bernard Pittens
Subject: audit log of every message going thru MQ

Hi,

Thanks all for your info.
I think the mqat (Activity Trace) is the solution that fits our needs.

One question left:
We have in our DTAP environment Windows MQ v8(Dev, Test) and MQ Appliance v8 (in AC and PRD).

Is the behaviour of the MQ Windows system and the MQ Appiance regarding mqat the same ?
Can I use the same mqat.ini file in all environments ?

Kind Regards

------------------------------
Bernard Pittens
Integration Engeneer
Sligro Foodgroup B.V.
Veghel

Original Message:
Sent: 07-31-2018 08:21
From: Dermot Flaherty
Subject: audit log of every message going thru MQ

Thanks Glenn.
I accidentally replied privately to Bernard a day or so ago and what I basically said was that COD (and COA) will give you a data volume/retention problem to add to the point about performance that you made.
So if today you have a system with a producer at one end and a consumer at the other and 200 msgs/sec are being sent and consumed, adding COD to each msg sent will cause 200 msgs/sec to now be sent to the designated ReplyToQ.
Clearly, these need to be archived somewhere (an RDBMS) to not only prevent Qfull, but to be able to support searches (perhaps hours or even days later) which may require a match on some field in the actual data (Order number for example).
So whether COD with some amount of data is used or - as you suggest - doing it in the application - there is a data volume/retention issue to be addressed.

Bernard responded and he said that he had found an interesting CapitalWare blog on the subject and the usual good advice from Roger LaCroix but that in his case, he would only want "tracking/auditing" capablity for some important flows which while being fairly large messages, only flow at the rate on 1 per sec.

I now think I have added the missing bits of discussion.

------------------------------
Dermot Flaherty
MQ Solutions Architect
Contractor

Original Message:
Sent: 07-30-2018 02:27
From: Glenn Baddeley
Subject: audit log of every message going thru MQ

​Hi Hirschel,
In practice, COA and COD report messages are not often used. They add extra complexity to the producer app to handle the messages and it adds overhead in MQ.  Apps should be able to trust MQ's assured delivery. Messages are never 'lost'. There is always a rational explanation for why a message ended up in a certain queue or was expired or discarded due to its QOS. This paradigm has never failed me.

If apps are concerned about traceability of MQ messages, audit logging should be done in the app code. eg. The apps log MQPUT returned reason code and message data, and log MQGET returned reason code and message data. The onus is on the app instances to be able to prove that they processed MQ messages. It can be a very enlightening experience for them.

If the failure can be reproduced or happens often, MQ trace features can be very useful, as it shows app MQI calls and results.

Cheers, Glenn.

------------------------------
Glenn Baddeley
Senior Middleware Software Engineer
Coles Supermarkets Australia Pty Ltd
Hawthorn East
+61 3 9829 4473

Original Message:
Sent: 07-25-2018 19:26
From: hirschel wasserman
Subject: audit log of every message going thru MQ

​I have a client who has 'lost' an MQ message, and is asking if we can prove that they received (MQGET) from the MQ queue? We have IB logs that show that the message was MQPUT onto the queue. The message is question is not on a DLQ or stuck in a XMIT queue. This is just a single instance problem, and in general this a working scenario.

BUT In more general terms, is there a way (an exit perhaps) to create an audit log of every message that moves thru a queue manager?

------------------------------
hirschel wasserman
------------------------------

Hi,
If we want to log the message contents as well, I see some cons in Application Activity trace approach like:

1. Message Data is in Hex & Bytes and how we can convert it to readable format, i am not sure may be possibly using: MH06: WebSphere MQ - Trace Tools

2. Msg Id is also not maintained in new queue: system.admin.trace.activity.queue.

3.You will have a window of missed messages, between when you try and see them, and when they have been consumed

Isn't it better to use MQ API trace exits. May be custom or this one - MA0W: WebSphere MQ API Trace

Thanks.

------------------------------
Muhammad Haider Raza
Royal Cyber Inc.
------------------------------

Original Message:
Sent: 08-07-2018 05:16
From: Anthony Beardsmore
Subject: audit log of every message going thru MQ

Hi Bernard

The MQ Appliance (from day one in V8) made some changes to MQAT - moving to an arguably more natural pub/sub model - which only became available in software MQ with V9.  So I'm afraid at V8 the exact configuration of activity trace will look a little different between the appliance and Windows (where you have to process the messages from the SYSTEM.ADMIN.TRACE.ACTIVITY.QUEUE), though you can do the same kinds of things.

Note that even at V9 you wouldn't be using the same 'file' since on the appliance you'd configure through setmqini - but the settings could then take effect identically.

Regards

------------------------------
Anthony Beardsmore
IBM MQ Appliance Architect
IBM

Original Message:
Sent: 08-06-2018 04:58
From: Bernard Pittens
Subject: audit log of every message going thru MQ

Hi,

Thanks all for your info.
I think the mqat (Activity Trace) is the solution that fits our needs.

One question left:
We have in our DTAP environment Windows MQ v8(Dev, Test) and MQ Appliance v8 (in AC and PRD).

Is the behaviour of the MQ Windows system and the MQ Appiance regarding mqat the same ?
Can I use the same mqat.ini file in all environments ?

Kind Regards

------------------------------
Bernard Pittens
Integration Engeneer
Sligro Foodgroup B.V.
Veghel

Original Message:
Sent: 07-31-2018 08:21
From: Dermot Flaherty
Subject: audit log of every message going thru MQ

Thanks Glenn.
I accidentally replied privately to Bernard a day or so ago and what I basically said was that COD (and COA) will give you a data volume/retention problem to add to the point about performance that you made.
So if today you have a system with a producer at one end and a consumer at the other and 200 msgs/sec are being sent and consumed, adding COD to each msg sent will cause 200 msgs/sec to now be sent to the designated ReplyToQ.
Clearly, these need to be archived somewhere (an RDBMS) to not only prevent Qfull, but to be able to support searches (perhaps hours or even days later) which may require a match on some field in the actual data (Order number for example).
So whether COD with some amount of data is used or - as you suggest - doing it in the application - there is a data volume/retention issue to be addressed.

Bernard responded and he said that he had found an interesting CapitalWare blog on the subject and the usual good advice from Roger LaCroix but that in his case, he would only want "tracking/auditing" capablity for some important flows which while being fairly large messages, only flow at the rate on 1 per sec.

I now think I have added the missing bits of discussion.

------------------------------
Dermot Flaherty
MQ Solutions Architect
Contractor

Original Message:
Sent: 07-30-2018 02:27
From: Glenn Baddeley
Subject: audit log of every message going thru MQ

​Hi Hirschel,
In practice, COA and COD report messages are not often used. They add extra complexity to the producer app to handle the messages and it adds overhead in MQ.  Apps should be able to trust MQ's assured delivery. Messages are never 'lost'. There is always a rational explanation for why a message ended up in a certain queue or was expired or discarded due to its QOS. This paradigm has never failed me.

If apps are concerned about traceability of MQ messages, audit logging should be done in the app code. eg. The apps log MQPUT returned reason code and message data, and log MQGET returned reason code and message data. The onus is on the app instances to be able to prove that they processed MQ messages. It can be a very enlightening experience for them.

If the failure can be reproduced or happens often, MQ trace features can be very useful, as it shows app MQI calls and results.

Cheers, Glenn.

------------------------------
Glenn Baddeley
Senior Middleware Software Engineer
Coles Supermarkets Australia Pty Ltd
Hawthorn East
+61 3 9829 4473

Original Message:
Sent: 07-25-2018 19:26
From: hirschel wasserman
Subject: audit log of every message going thru MQ

​I have a client who has 'lost' an MQ message, and is asking if we can prove that they received (MQGET) from the MQ queue? We have IB logs that show that the message was MQPUT onto the queue. The message is question is not on a DLQ or stuck in a XMIT queue. This is just a single instance problem, and in general this a working scenario.

BUT In more general terms, is there a way (an exit perhaps) to create an audit log of every message that moves thru a queue manager?

------------------------------
hirschel wasserman
------------------------------

Hi Muhammad

Exits will always be most the most fully flexible option of course, but (aside from the potential overhead of taking on custom code to maintain) there are increasingly environments where they aren't really viable because of the administration or security practicalities - the signed firmware requirement in the case of an appliance, and the shared platform in hosted environments - especially SAAS offerings like MQ on Cloud.

To meet these needs we definitely want to provide comprehensive basic function in this area (and if there are complex custom requirements beyond that requiring native exits, it may of course mean those platforms aren't the most appropriate choice for some applications).

I wasn't sure I fully understood your three points, would you mind expanding on them?  The message body can of course be any data so 'readable' in the general case would be tricky - and although we concatenate many trace messages together into one logged message, the individual MQMDs (with MsgID) are available inside the PCF wrapper - is there a reason this is not sufficient?

On the 'window of missed messages' I afraid I don't think I understand the issue properly at all, would you mind clarifying the concern?

If you prefer of course, there is always the option of raising an RFE for anything you see missing or in need of improvement in the product - we appreciate the feedback by whichever route.

Kind Regards
Anthony

------------------------------
Anthony Beardsmore
IBM MQ Appliance Architect
IBM
------------------------------

Original Message:
Sent: 08-16-2018 14:25
From: Muhammad Haider Raza
Subject: audit log of every message going thru MQ


Hi,
If we want to log the message contents as well, I see some cons in Application Activity trace approach like:

1. Message Data is in Hex & Bytes and how we can convert it to readable format, i am not sure may be possibly using: MH06: WebSphere MQ - Trace Tools

2. Msg Id is also not maintained in new queue: system.admin.trace.activity.queue.

3.You will have a window of missed messages, between when you try and see them, and when they have been consumed

Isn't it better to use MQ API trace exits. May be custom or this one - MA0W: WebSphere MQ API Trace

Thanks.

------------------------------
Muhammad Haider Raza
Royal Cyber Inc.

Original Message:
Sent: 08-07-2018 05:16
From: Anthony Beardsmore
Subject: audit log of every message going thru MQ

Hi Bernard

The MQ Appliance (from day one in V8) made some changes to MQAT - moving to an arguably more natural pub/sub model - which only became available in software MQ with V9.  So I'm afraid at V8 the exact configuration of activity trace will look a little different between the appliance and Windows (where you have to process the messages from the SYSTEM.ADMIN.TRACE.ACTIVITY.QUEUE), though you can do the same kinds of things.

Note that even at V9 you wouldn't be using the same 'file' since on the appliance you'd configure through setmqini - but the settings could then take effect identically.

Regards

------------------------------
Anthony Beardsmore
IBM MQ Appliance Architect
IBM

Original Message:
Sent: 08-06-2018 04:58
From: Bernard Pittens
Subject: audit log of every message going thru MQ

Hi,

Thanks all for your info.
I think the mqat (Activity Trace) is the solution that fits our needs.

One question left:
We have in our DTAP environment Windows MQ v8(Dev, Test) and MQ Appliance v8 (in AC and PRD).

Is the behaviour of the MQ Windows system and the MQ Appiance regarding mqat the same ?
Can I use the same mqat.ini file in all environments ?

Kind Regards

------------------------------
Bernard Pittens
Integration Engeneer
Sligro Foodgroup B.V.
Veghel

Original Message:
Sent: 07-31-2018 08:21
From: Dermot Flaherty
Subject: audit log of every message going thru MQ

Thanks Glenn.
I accidentally replied privately to Bernard a day or so ago and what I basically said was that COD (and COA) will give you a data volume/retention problem to add to the point about performance that you made.
So if today you have a system with a producer at one end and a consumer at the other and 200 msgs/sec are being sent and consumed, adding COD to each msg sent will cause 200 msgs/sec to now be sent to the designated ReplyToQ.
Clearly, these need to be archived somewhere (an RDBMS) to not only prevent Qfull, but to be able to support searches (perhaps hours or even days later) which may require a match on some field in the actual data (Order number for example).
So whether COD with some amount of data is used or - as you suggest - doing it in the application - there is a data volume/retention issue to be addressed.

Bernard responded and he said that he had found an interesting CapitalWare blog on the subject and the usual good advice from Roger LaCroix but that in his case, he would only want "tracking/auditing" capablity for some important flows which while being fairly large messages, only flow at the rate on 1 per sec.

I now think I have added the missing bits of discussion.

------------------------------
Dermot Flaherty
MQ Solutions Architect
Contractor

Original Message:
Sent: 07-30-2018 02:27
From: Glenn Baddeley
Subject: audit log of every message going thru MQ

​Hi Hirschel,
In practice, COA and COD report messages are not often used. They add extra complexity to the producer app to handle the messages and it adds overhead in MQ.  Apps should be able to trust MQ's assured delivery. Messages are never 'lost'. There is always a rational explanation for why a message ended up in a certain queue or was expired or discarded due to its QOS. This paradigm has never failed me.

If apps are concerned about traceability of MQ messages, audit logging should be done in the app code. eg. The apps log MQPUT returned reason code and message data, and log MQGET returned reason code and message data. The onus is on the app instances to be able to prove that they processed MQ messages. It can be a very enlightening experience for them.

If the failure can be reproduced or happens often, MQ trace features can be very useful, as it shows app MQI calls and results.

Cheers, Glenn.

------------------------------
Glenn Baddeley
Senior Middleware Software Engineer
Coles Supermarkets Australia Pty Ltd
Hawthorn East
+61 3 9829 4473

Original Message:
Sent: 07-25-2018 19:26
From: hirschel wasserman
Subject: audit log of every message going thru MQ

​I have a client who has 'lost' an MQ message, and is asking if we can prove that they received (MQGET) from the MQ queue? We have IB logs that show that the message was MQPUT onto the queue. The message is question is not on a DLQ or stuck in a XMIT queue. This is just a single instance problem, and in general this a working scenario.

BUT In more general terms, is there a way (an exit perhaps) to create an audit log of every message that moves thru a queue manager?

------------------------------
hirschel wasserman
------------------------------

Hirschel

Monitoring every message and Stitching together MQ messages across the application stack is a core competency of the Nastel AutoPilot product. Nastel AutoPilot can report on the status of every transaction and is used by many companies for compliance and governance purposes.

Have a look at this link for an overview https://www.nastel.com/transaction-tracking/

------------------------------
David Liff
------------------------------

Original Message:
Sent: 07-25-2018 19:26
From: hirschel wasserman
Subject: audit log of every message going thru MQ

​I have a client who has 'lost' an MQ message, and is asking if we can prove that they received (MQGET) from the MQ queue? We have IB logs that show that the message was MQPUT onto the queue. The message is question is not on a DLQ or stuck in a XMIT queue. This is just a single instance problem, and in general this a working scenario.

BUT In more general terms, is there a way (an exit perhaps) to create an audit log of every message that moves thru a queue manager?

------------------------------
hirschel wasserman
------------------------------

Herschel

We have customers today who are using Nastel AutoPilot to confirm that messages were sent and were received. 

A couple of simple examples - a customer using this solution to report on ACH payments and another using it to track managed file transfers (MFT)

Automated Clearing House Payment Tracking

Nastel Technologies, Inc.		remove preview
Automated Clearing House Payment Tracking Nastel AutoPilot Insight tracks payments in both real time and batch file transfers. It provides a simple visual image of all end-to-end transaction flows, where you can drill down to see each application or process, and drill into categories (such as those that are performing outside of SLA's). View this on Nastel Technologies, Inc. >

AutoPilot for Managed File Transfer (MFT)

Nastel Technologies, Inc.		remove preview
AutoPilot for Managed File Transfer (MFT) Every day, enterprises rely upon many thousands or hundreds of thousands of managed file transfers (MFTs) that underlie myriad business functions. This represents a huge amount of information in numerous data formats being shuttled across IT applications, storage devices, file queues, and databases. View this on Nastel Technologies, Inc. >

------------------------------
David Liff
------------------------------

Original Message:
Sent: 07-25-2018 19:26
From: hirschel wasserman
Subject: audit log of every message going thru MQ

​I have a client who has 'lost' an MQ message, and is asking if we can prove that they received (MQGET) from the MQ queue? We have IB logs that show that the message was MQPUT onto the queue. The message is question is not on a DLQ or stuck in a XMIT queue. This is just a single instance problem, and in general this a working scenario.

BUT In more general terms, is there a way (an exit perhaps) to create an audit log of every message that moves thru a queue manager?

------------------------------
hirschel wasserman
------------------------------