Does an mq trace trap the data payloads that are moving thru the qmgr?

[Costa, D. (Damian)]

HI all,
I Was just asked to supply the audit traces of all messages going through a particular queue on a test qmgr. Naturally I can't just do that as no audit logs exist. So I was wondering if I could fudge it by running an mq trace to trap the message payloads being processed off said queue.
Izzat even possible?

********************
Nedbank Limited Reg No 1951/000009/06. The following link displays
the names of the Nedbank Board of Directors and Company Secretary.
[ http://www.nedbank.co.za/terms/DirectorsNedbank.htm ]
This email is confidential and is intended for the addressee only.
The following link will take you to Nedbank's legal notice.
[ http://www.nedbank.co.za/terms/EmailDisclaimer.htm ]
********************

To unsubscribe, write to LISTSERV-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org and,
in the message body (not the subject), write: SIGNOFF MQSERIES

[T.Rob]

X-Report-Abuse-To: spam-RAvZ+8ubYLwZD488Lvc0IA6ISnHq+hSGQ0cMyQF+***@public.gmane.org
X-Filter-Fingerprint: IFrWXGses7OKB5S5G8/dJb0kolOUiviGeQyDsBgQ6PBA3cTUQ1R++keuE7RDJ8Kg3RbMLUalw1oC
mj99/u+Poh38tEMU4IgC4sNz49qn3HHnhRv/ZJ3kEy8bfiAr+Fb/UpndEJ0YoaLytXXo8BMTaX2p
Mk7LBarWD9Fj4R3eIu5amSKkALoA6KDzkQ8jq89Qglr+eUaqsXi6ilYykBRNmy1w3rhXI7ypWHcC
zReLskSoC1jzfYuYzO5TaopJL1l0EkXKTCB9mgAH2nNvM1GFDcH5C2MO7hTENZJE35bUvwA=
X-Originating-IP: 184.154.225.7
X-SpamExperts-Domain: siteground247.com
X-SpamExperts-Username: 184.154.225.7
X-SpamExperts-Outgoing-Class: ham
X-SpamExperts-Outgoing-Evidence: SB/global_tokens (0.000950123030444)
X-Recommended-Action: accept
X-PMX-Version: 6.1.1.2430161, Antispam-Engine: 2.7.2.2107409,
Antispam-Data: 2014.10.8.83019
X-PMX-Spam: Gauge= Probability=9%, Report=' AT_TLD 0.1,
FROM_NAME_ONE_WORD 0.05, HTML_00_01 0.05, HTML_00_10 0.05,
BODYTEXTP_SIZE_3000_LESS 0, BODY_SIZE_1900_1999 0,
BODY_SIZE_2000_LESS 0, BODY_SIZE_5000_LESS 0,
BODY_SIZE_7000_LESS 0, DATE_TZ_NA 0, ECARD_WORD 0,
FORGED_MUA_OUTLOOK 0, URI_ENDS_IN_HTML 0, WEBMAIL_SOURCE 0,
WEBMAIL_XOIP 0, WEBMAIL_X_IP_HDR 0, __ANY_URI 0,
__BOUNCE_CHALLENGE_SUBJ 0, __BOUNCE_NDR_SUBJ_EXEMPT 0,
__CP_URI_IN_BODY 0, __CT 0, __CTE 0, __CT_TEXT_PLAIN 0,
__FORWARDED_MSG 0, __HAS_FROM 0, __HAS_MSGID 0, __HAS_X_MAILER 0,
__IN_REP_TO 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0,
__OUTLOOK_MUA 0, __OUTLOOK_MUA_1 0, __SANE_MSGID 0,
__SUBJ_ALPHA_NEGATE 0, __TO_MALFORMED_2 0, __URI_NS ,
__USER_AGENT_MS_GENERIC 0'
Sender: MQSeries List <MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org>
In-Reply-To: <EAF97B79A5522649962910572C52B04850B6AB73-w/NrggpC+Zo7S9ge+sqUxjpbqlFO0woCiUO8p+t/***@public.gmane.org>
Precedence: list
List-Help: <http://listserv.meduniwien.ac.at/cgi-bin/wa?LIST=MQSERIES>,
<mailto:LISTSERV-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org?body=INFO%20MQSERIES>
List-Unsubscribe: <mailto:MQSERIES-unsubscribe-request-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org>
List-Subscribe: <mailto:MQSERIES-subscribe-request-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org>
List-Owner: <mailto:MQSERIES-request-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org>
List-Archive: <http://listserv.meduniwien.ac.at/cgi-bin/wa?LIST=MQSERIES>
Archived-At: <http://permalink.gmane.org/gmane.network.mq.devel/18285>

If you use the MA0W trace exit I believe that you can specify capturing just
the headers. I do recall though a conversation with Ralph Bateman about how
Support often receives traces and FDC files in PMRs that are filled with
PII, medical data, SSN's, card numbers, etc. So I believe the answer is
"yes." That said, the WMQ native trace can get real big, real fast so you
may want to look at MA0W which traces only API calls and not internals, SSL,
comms, etc.

http://ibm.co/SupptPacMA0W


Kind regards,
-- T.Rob


> -----Original Message-----
> From: MQSeries List [mailto:MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org] On Behalf
> Of Costa, D. (Damian)
> Sent: Wednesday, October 08, 2014 4:00 AM
> To: MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org
> Subject: Does an mq trace trap the data payloads that are moving thru the
> qmgr?
>
> HI all,
> I Was just asked to supply the audit traces of all messages going through
> a particular queue on a test qmgr. Naturally I can't just do that as no
> audit logs exist. So I was wondering if I could fudge it by running an mq
> trace to trap the message payloads being processed off said queue.
> Izzat even possible?
>
> ********************
> Nedbank Limited Reg No 1951/000009/06. The following link displays the
> names of the Nedbank Board of Directors and Company Secretary.
> [ http://www.nedbank.co.za/terms/DirectorsNedbank.htm ] This email is
> confidential and is intended for the addressee only.
> The following link will take you to Nedbank's legal notice.
> [ http://www.nedbank.co.za/terms/EmailDisclaimer.htm ]
> ********************
>
> To unsubscribe, write to LISTSERV-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org and, in the
> message body (not the subject), write: SIGNOFF MQSERIES Instructions for
> managing your mailing list subscription are provided in the Listserv
> General Users Guide available at http://www.lsoft.com
> Archive: http://listserv.meduniwien.ac.at/archives/mqser-l.html

To unsubscribe, write to LISTSERV-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org and,
in the message body (not the subject), write: SIGNOFF MQSERIES

[Andrew Hickson]

If you're using linear logging then all of the message data (control
information + payload) for persistent messages is recorded in the recovery
log, and can be post processed with the dmpmqlog utility.
If you're using circular logging then you've effectively got a wrap around
history of the last X bytes of persistent data, however getting to all of
that data (e.g. dmpmqlog) is much more difficult and typically requires
the help of MQ L3.
The main advantage of using the recovery log for this purpose is that
there's no performance overhead.
The main disadvantage of using the recovery log for this purpose is that
the information isn't in a form that's very easy to process/consume.





From: "T.Rob" <t.rob-CkT6zf+urXSzW/GOMZKyElesiRL1/***@public.gmane.org>
To: MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org,
Date: 08/10/2014 09:41
Subject: Re: Does an mq trace trap the data payloads that are
moving thru the qmgr?
Sent by: MQSeries List <MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org>



If you use the MA0W trace exit I believe that you can specify capturing
just
the headers. I do recall though a conversation with Ralph Bateman about
how
Support often receives traces and FDC files in PMRs that are filled with
PII, medical data, SSN's, card numbers, etc. So I believe the answer is
"yes." That said, the WMQ native trace can get real big, real fast so you
may want to look at MA0W which traces only API calls and not internals,
SSL,
comms, etc.

http://ibm.co/SupptPacMA0W


Kind regards,
-- T.Rob


> -----Original Message-----
> From: MQSeries List [mailto:MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org] On
Behalf
> Of Costa, D. (Damian)
> Sent: Wednesday, October 08, 2014 4:00 AM
> To: MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org
> Subject: Does an mq trace trap the data payloads that are moving thru
the
> qmgr?
>
> HI all,
> I Was just asked to supply the audit traces of all messages going
through
> a particular queue on a test qmgr. Naturally I can't just do that as no
> audit logs exist. So I was wondering if I could fudge it by running an
mq
> trace to trap the message payloads being processed off said queue.
> Izzat even possible?
>
> ********************
> Nedbank Limited Reg No 1951/000009/06. The following link displays the
> names of the Nedbank Board of Directors and Company Secretary.
> [ http://www.nedbank.co.za/terms/DirectorsNedbank.htm ] This email is
> confidential and is intended for the addressee only.
> The following link will take you to Nedbank's legal notice.
> [ http://www.nedbank.co.za/terms/EmailDisclaimer.htm ]
> ********************
>
> To unsubscribe, write to LISTSERV-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org and, in the
> message body (not the subject), write: SIGNOFF MQSERIES Instructions for
> managing your mailing list subscription are provided in the Listserv
> General Users Guide available at http://www.lsoft.com
> Archive: http://listserv.meduniwien.ac.at/archives/mqser-l.html

To unsubscribe, write to LISTSERV-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org and,
in the message body (not the subject), write: SIGNOFF MQSERIES
Instructions for managing your mailing list subscription are provided in
the Listserv General Users Guide available at http://www.lsoft.com
Archive: http://listserv.meduniwien.ac.at/archives/mqser-l.html



Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number
741598.
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU

To unsubscribe, write to LISTSERV-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org and,
in the message body (not the subject), write: SIGNOFF MQSERIES
Instructions for managing your mailing list subscription are provided in
the Listserv General Users Guide available at http://www.lsoft.com
Archive: http://listserv.meduniwien.ac.at/archives/mqser-l.html

[T.Rob]

I think that's *most* of the persistent data. At MQTC Mark Taylor gave the
MQ Internals session and said that the Put To Waiting Getter optimization
permits certain persistent messages that are PUT outside of syncpoint to
bypass the log. So for purposes of an audit you either need to use
API-level tracing or else be able to prove to the auditor that your programs
do everything inside of syncpoint and therefore the dmpmqlog output is
complete.



Trying to find a single or very few messages that appear to have been
processed but for which there is no log entry could REALLY screw up your
day, your audit, your relationship with upper management, etc.



(Do not confuse this with the restaurant management API that can recall
service staff from the golf course on their day off when there's a sudden
surge in business. That is the "Get To Putting Waiter" API call and is
completely different.)



Kind regards,

-- T.Rob



T.Robert Wyatt, Managing partner

IoPT Consulting, LLC

+1 704-443-TROB (8762) Voice/Text

[phone] Voice

https://ioptconsulting.com <https://ioptconsulting.com/>

https://twitter.com/tdotrob



From: MQSeries List [mailto:MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org] On Behalf Of
Andrew Hickson
Sent: Wednesday, October 08, 2014 4:52 AM
To: MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org
Subject: Re: Does an mq trace trap the data payloads that are moving thru
the qmgr?



If you're using linear logging then all of the message data (control
information + payload) for persistent messages is recorded in the recovery
log, and can be post processed with the dmpmqlog utility.
If you're using circular logging then you've effectively got a wrap around
history of the last X bytes of persistent data, however getting to all of
that data (e.g. dmpmqlog) is much more difficult and typically requires the
help of MQ L3.
The main advantage of using the recovery log for this purpose is that
there's no performance overhead.
The main disadvantage of using the recovery log for this purpose is that the
information isn't in a form that's very easy to process/consume.





From: "T.Rob" <t.rob-CkT6zf+urXSzW/GOMZKyElesiRL1/***@public.gmane.org>
To: MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org,
Date: 08/10/2014 09:41
Subject: Re: Does an mq trace trap the data payloads that are moving
thru the qmgr?
Sent by: MQSeries List <MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org>

_____




If you use the MA0W trace exit I believe that you can specify capturing just
the headers. I do recall though a conversation with Ralph Bateman about how
Support often receives traces and FDC files in PMRs that are filled with
PII, medical data, SSN's, card numbers, etc. So I believe the answer is
"yes." That said, the WMQ native trace can get real big, real fast so you
may want to look at MA0W which traces only API calls and not internals, SSL,
comms, etc.

<http://ibm.co/SupptPacMA0W> http://ibm.co/SupptPacMA0W


Kind regards,
-- T.Rob


> -----Original Message-----
> From: MQSeries List [ <mailto:MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org>
mailto:MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org] On Behalf
> Of Costa, D. (Damian)
> Sent: Wednesday, October 08, 2014 4:00 AM
> To: MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org
> Subject: Does an mq trace trap the data payloads that are moving thru the
> qmgr?
>
> HI all,
> I Was just asked to supply the audit traces of all messages going through
> a particular queue on a test qmgr. Naturally I can't just do that as no
> audit logs exist. So I was wondering if I could fudge it by running an mq
> trace to trap the message payloads being processed off said queue.
> Izzat even possible?
>
> ********************
> Nedbank Limited Reg No 1951/000009/06. The following link displays the
> names of the Nedbank Board of Directors and Company Secretary.
> [ <http://www.nedbank.co.za/terms/DirectorsNedbank.htm>
http://www.nedbank.co.za/terms/DirectorsNedbank.htm ] This email is
> confidential and is intended for the addressee only.
> The following link will take you to Nedbank's legal notice.
> [ <http://www.nedbank.co.za/terms/EmailDisclaimer.htm>
http://www.nedbank.co.za/terms/EmailDisclaimer.htm ]
> ********************
>
> To unsubscribe, write to LISTSERV-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org and, in the
> message body (not the subject), write: SIGNOFF MQSERIES Instructions for
> managing your mailing list subscription are provided in the Listserv
> General Users Guide available at <http://www.lsoft.com/>
http://www.lsoft.com
> Archive: <http://listserv.meduniwien.ac.at/archives/mqser-l.html>
http://listserv.meduniwien.ac.at/archives/mqser-l.html

To unsubscribe, write to LISTSERV-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org and,
in the message body (not the subject), write: SIGNOFF MQSERIES
Instructions for managing your mailing list subscription are provided in
the Listserv General Users Guide available at <http://www.lsoft.com/>
http://www.lsoft.com
Archive: <http://listserv.meduniwien.ac.at/archives/mqser-l.html>
http://listserv.meduniwien.ac.at/archives/mqser-l.html



Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number
741598.
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU

_____

List Archive <http://listserv.meduniwien.ac.at/archives/mqser-l.html> -
Manage Your List Settings
<http://listserv.meduniwien.ac.at/cgi-bin/wa?SUBED1=mqser-l&A=1> -
Unsubscribe
<mailto:LISTSERV-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org?subject=Unsubscribe&BODY=signoff%
20mqseries>

Instructions for managing your mailing list subscription are provided in the
Listserv General Users Guide available at http://www.lsoft.com
<http://www.lsoft.com/resources/manuals.asp>


To unsubscribe, write to LISTSERV-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org and,
in the message body (not the subject), write: SIGNOFF MQSERIES
Instructions for managing your mailing list subscription are provided in
the Listserv General Users Guide available at http://www.lsoft.com
Archive: http://listserv.meduniwien.ac.at/archives/mqser-l.html

[Tim Zielke]

Hi Damian,

If your queue manager is 7.1 or higher, another option is the Application Activity Trace.

This IBM article on the AAT -> http://www.ibm.com/developerworks/websphere/library/techarticles/1306_bushby/1306_bushby.html

does give the scenario of "Using Application Activity Trace to keep an audit trail of messages" as one of the AAT's uses.

Personally, I would be hesitant to do what you are being asked to do, and would like to understand from the application team why their application can not do this logging, itself. Do they really need the entire message, or is it really key pieces of data that they could put into an application log.

Thanks,
Tim

From: MQSeries List [mailto:MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org] On Behalf Of T.Rob
Sent: Wednesday, October 08, 2014 4:17 AM
To: MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org
Subject: Re: Does an mq trace trap the data payloads that are moving thru the qmgr?

I think that's *most* of the persistent data. At MQTC Mark Taylor gave the MQ Internals session and said that the Put To Waiting Getter optimization permits certain persistent messages that are PUT outside of syncpoint to bypass the log. So for purposes of an audit you either need to use API-level tracing or else be able to prove to the auditor that your programs do everything inside of syncpoint and therefore the dmpmqlog output is complete.

Trying to find a single or very few messages that appear to have been processed but for which there is no log entry could REALLY screw up your day, your audit, your relationship with upper management, etc.

(Do not confuse this with the restaurant management API that can recall service staff from the golf course on their day off when there's a sudden surge in business. That is the "Get To Putting Waiter" API call and is completely different.)

Kind regards,
-- T.Rob

T.Robert Wyatt, Managing partner
IoPT Consulting, LLC
+1 704-443-TROB (8762) Voice/Text
[phone] Voice
https://ioptconsulting.com<https://ioptconsulting.com/>
https://twitter.com/tdotrob

From: MQSeries List [mailto:MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org] On Behalf Of Andrew Hickson
Sent: Wednesday, October 08, 2014 4:52 AM
To: MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org<mailto:MQSERIES-0lvw86wZMd9k/***@public.gmane.orgAC.AT>
Subject: Re: Does an mq trace trap the data payloads that are moving thru the qmgr?

If you're using linear logging then all of the message data (control information + payload) for persistent messages is recorded in the recovery log, and can be post processed with the dmpmqlog utility.
If you're using circular logging then you've effectively got a wrap around history of the last X bytes of persistent data, however getting to all of that data (e.g. dmpmqlog) is much more difficult and typically requires the help of MQ L3.
The main advantage of using the recovery log for this purpose is that there's no performance overhead.
The main disadvantage of using the recovery log for this purpose is that the information isn't in a form that's very easy to process/consume.





From: "T.Rob" <t.rob-CkT6zf+urXSzW/GOMZKyElesiRL1/***@public.gmane.org<mailto:***@IOPTCONSULTING.COM>>
To: MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org<mailto:MQSERIES-0lvw86wZMd8hNtF/***@public.gmane.orgNIWIEN.AC.AT>,
Date: 08/10/2014 09:41
Subject: Re: Does an mq trace trap the data payloads that are moving thru the qmgr?
Sent by: MQSeries List <MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org<mailto:MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org>>
________________________________



If you use the MA0W trace exit I believe that you can specify capturing just
the headers. I do recall though a conversation with Ralph Bateman about how
Support often receives traces and FDC files in PMRs that are filled with
PII, medical data, SSN's, card numbers, etc. So I believe the answer is
"yes." That said, the WMQ native trace can get real big, real fast so you
may want to look at MA0W which traces only API calls and not internals, SSL,
comms, etc.

http://ibm.co/SupptPacMA0W


Kind regards,
-- T.Rob


> -----Original Message-----
> From: MQSeries List [mailto:MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org] On Behalf
> Of Costa, D. (Damian)
> Sent: Wednesday, October 08, 2014 4:00 AM
> To: MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org<mailto:MQSERIES-0lvw86wZMd9k/***@public.gmane.orgN.AC.AT>
> Subject: Does an mq trace trap the data payloads that are moving thru the
> qmgr?
>
> HI all,
> I Was just asked to supply the audit traces of all messages going through
> a particular queue on a test qmgr. Naturally I can't just do that as no
> audit logs exist. So I was wondering if I could fudge it by running an mq
> trace to trap the message payloads being processed off said queue.
> Izzat even possible?
>
> ********************
> Nedbank Limited Reg No 1951/000009/06. The following link displays the
> names of the Nedbank Board of Directors and Company Secretary.
> [ http://www.nedbank.co.za/terms/DirectorsNedbank.htm ] This email is
> confidential and is intended for the addressee only.
> The following link will take you to Nedbank's legal notice.
> [ http://www.nedbank.co.za/terms/EmailDisclaimer.htm ]
> ********************
>
> To unsubscribe, write to LISTSERV-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org<mailto:LISTSERV-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org> and, in the
> message body (not the subject), write: SIGNOFF MQSERIES Instructions for
> managing your mailing list subscription are provided in the Listserv
> General Users Guide available at http://www.lsoft.com<http://www.lsoft.com/>
> Archive: http://listserv.meduniwien.ac.at/archives/mqser-l.html

To unsubscribe, write to LISTSERV-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org<mailto:***@LISTSERV.MEDUNIWIEN.AC.AT> and,
in the message body (not the subject), write: SIGNOFF MQSERIES
Instructions for managing your mailing list subscription are provided in
the Listserv General Users Guide available at http://www.lsoft.com<http://www.lsoft.com/>
Archive: http://listserv.meduniwien.ac.at/archives/mqser-l.html



Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number 741598.
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU
________________________________
List Archive<http://listserv.meduniwien.ac.at/archives/mqser-l.html> - Manage Your List Settings<http://listserv.meduniwien.ac.at/cgi-bin/wa?SUBED1=mqser-l&A=1> - Unsubscribe<mailto:LISTSERV-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org?subject=Unsubscribe&BODY=signoff%20mqseries>

Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com<http://www.lsoft.com/resources/manuals.asp>

________________________________
List Archive<http://listserv.meduniwien.ac.at/archives/mqser-l.html> - Manage Your List Settings<http://listserv.meduniwien.ac.at/cgi-bin/wa?SUBED1=mqser-l&A=1> - Unsubscribe<mailto:LISTSERV-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org?subject=Unsubscribe&BODY=signoff%20mqseries>

Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com<http://www.lsoft.com/resources/manuals.asp>

To unsubscribe, write to LISTSERV-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org and,
in the message body (not the subject), write: SIGNOFF MQSERIES
Instructions for managing your mailing list subscription are provided in
the Listserv General Users Guide available at http://www.lsoft.com
Archive: http://listserv.meduniwien.ac.at/archives/mqser-l.html

[Costa, D. (Damian)]

Swat I tole 'em..... improve their logging from their apps.
What is disappointing is that they cannot tell what their app is doing with the message. The MQ stats indicate they are taking them off the queue.
Heaven only know where they go from there.

From: MQSeries List [mailto:MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org] On Behalf Of Tim Zielke
Sent: 08 October 2014 02:07 PM
To: MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org
Subject: Re: Does an mq trace trap the data payloads that are moving thru the qmgr?

Hi Damian,

If your queue manager is 7.1 or higher, another option is the Application Activity Trace.

This IBM article on the AAT -> http://www.ibm.com/developerworks/websphere/library/techarticles/1306_bushby/1306_bushby.html

does give the scenario of "Using Application Activity Trace to keep an audit trail of messages" as one of the AAT's uses.

Personally, I would be hesitant to do what you are being asked to do, and would like to understand from the application team why their application can not do this logging, itself. Do they really need the entire message, or is it really key pieces of data that they could put into an application log.

Thanks,
Tim

From: MQSeries List [mailto:MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org] On Behalf Of T.Rob
Sent: Wednesday, October 08, 2014 4:17 AM
To: MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org<mailto:MQSERIES-0lvw86wZMd9k/***@public.gmane.orgAC.AT>
Subject: Re: Does an mq trace trap the data payloads that are moving thru the qmgr?

I think that's *most* of the persistent data. At MQTC Mark Taylor gave the MQ Internals session and said that the Put To Waiting Getter optimization permits certain persistent messages that are PUT outside of syncpoint to bypass the log. So for purposes of an audit you either need to use API-level tracing or else be able to prove to the auditor that your programs do everything inside of syncpoint and therefore the dmpmqlog output is complete.

Trying to find a single or very few messages that appear to have been processed but for which there is no log entry could REALLY screw up your day, your audit, your relationship with upper management, etc.

(Do not confuse this with the restaurant management API that can recall service staff from the golf course on their day off when there's a sudden surge in business. That is the "Get To Putting Waiter" API call and is completely different.)

Kind regards,
-- T.Rob

T.Robert Wyatt, Managing partner
IoPT Consulting, LLC
+1 704-443-TROB (8762) Voice/Text
[phone] Voice
https://ioptconsulting.com<https://ioptconsulting.com/>
https://twitter.com/tdotrob

From: MQSeries List [mailto:MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org] On Behalf Of Andrew Hickson
Sent: Wednesday, October 08, 2014 4:52 AM
To: MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org<mailto:MQSERIES-0lvw86wZMd9k/***@public.gmane.orgAC.AT>
Subject: Re: Does an mq trace trap the data payloads that are moving thru the qmgr?

If you're using linear logging then all of the message data (control information + payload) for persistent messages is recorded in the recovery log, and can be post processed with the dmpmqlog utility.
If you're using circular logging then you've effectively got a wrap around history of the last X bytes of persistent data, however getting to all of that data (e.g. dmpmqlog) is much more difficult and typically requires the help of MQ L3.
The main advantage of using the recovery log for this purpose is that there's no performance overhead.
The main disadvantage of using the recovery log for this purpose is that the information isn't in a form that's very easy to process/consume.





From: "T.Rob" <t.rob-CkT6zf+urXSzW/GOMZKyElesiRL1/***@public.gmane.org<mailto:***@IOPTCONSULTING.COM>>
To: MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org<mailto:MQSERIES-0lvw86wZMd8hNtF/***@public.gmane.orgNIWIEN.AC.AT>,
Date: 08/10/2014 09:41
Subject: Re: Does an mq trace trap the data payloads that are moving thru the qmgr?
Sent by: MQSeries List <MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org<mailto:MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org>>
________________________________



If you use the MA0W trace exit I believe that you can specify capturing just
the headers. I do recall though a conversation with Ralph Bateman about how
Support often receives traces and FDC files in PMRs that are filled with
PII, medical data, SSN's, card numbers, etc. So I believe the answer is
"yes." That said, the WMQ native trace can get real big, real fast so you
may want to look at MA0W which traces only API calls and not internals, SSL,
comms, etc.

http://ibm.co/SupptPacMA0W


Kind regards,
-- T.Rob


> -----Original Message-----
> From: MQSeries List [mailto:MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org] On Behalf
> Of Costa, D. (Damian)
> Sent: Wednesday, October 08, 2014 4:00 AM
> To: MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org<mailto:MQSERIES-0lvw86wZMd9k/***@public.gmane.orgN.AC.AT>
> Subject: Does an mq trace trap the data payloads that are moving thru the
> qmgr?
>
> HI all,
> I Was just asked to supply the audit traces of all messages going through
> a particular queue on a test qmgr. Naturally I can't just do that as no
> audit logs exist. So I was wondering if I could fudge it by running an mq
> trace to trap the message payloads being processed off said queue.
> Izzat even possible?
>
> ********************
> Nedbank Limited Reg No 1951/000009/06. The following link displays the
> names of the Nedbank Board of Directors and Company Secretary.
> [ http://www.nedbank.co.za/terms/DirectorsNedbank.htm ] This email is
> confidential and is intended for the addressee only.
> The following link will take you to Nedbank's legal notice.
> [ http://www.nedbank.co.za/terms/EmailDisclaimer.htm ]
> ********************
>
> To unsubscribe, write to LISTSERV-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org<mailto:LISTSERV-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org> and, in the
> message body (not the subject), write: SIGNOFF MQSERIES Instructions for
> managing your mailing list subscription are provided in the Listserv
> General Users Guide available at http://www.lsoft.com<http://www.lsoft.com/>
> Archive: http://listserv.meduniwien.ac.at/archives/mqser-l.html

To unsubscribe, write to LISTSERV-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org<mailto:***@LISTSERV.MEDUNIWIEN.AC.AT> and,
in the message body (not the subject), write: SIGNOFF MQSERIES
Instructions for managing your mailing list subscription are provided in
the Listserv General Users Guide available at http://www.lsoft.com<http://www.lsoft.com/>
Archive: http://listserv.meduniwien.ac.at/archives/mqser-l.html



Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number 741598.
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU
________________________________
List Archive<http://listserv.meduniwien.ac.at/archives/mqser-l.html> - Manage Your List Settings<http://listserv.meduniwien.ac.at/cgi-bin/wa?SUBED1=mqser-l&A=1> - Unsubscribe<mailto:LISTSERV-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org?subject=Unsubscribe&BODY=signoff%20mqseries>

Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com<http://www.lsoft.com/resources/manuals.asp>

________________________________
List Archive<http://listserv.meduniwien.ac.at/archives/mqser-l.html> - Manage Your List Settings<http://listserv.meduniwien.ac.at/cgi-bin/wa?SUBED1=mqser-l&A=1> - Unsubscribe<mailto:LISTSERV-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org?subject=Unsubscribe&BODY=signoff%20mqseries>

Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com<http://www.lsoft.com/resources/manuals.asp>

________________________________
List Archive<http://listserv.meduniwien.ac.at/archives/mqser-l.html> - Manage Your List Settings<http://listserv.meduniwien.ac.at/cgi-bin/wa?SUBED1=mqser-l&A=1> - Unsubscribe<mailto:LISTSERV-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org?subject=Unsubscribe&BODY=signoff%20mqseries>

Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com<http://www.lsoft.com/resources/manuals.asp>

********************
Nedbank Limited Reg No 1951/000009/06. The following link displays
the names of the Nedbank Board of Directors and Company Secretary.
[ http://www.nedbank.co.za/terms/DirectorsNedbank.htm ]
This email is confidential and is intended for the addressee only.
The following link will take you to Nedbank's legal notice.
[ http://www.nedbank.co.za/terms/EmailDisclaimer.htm ]
********************

To unsubscribe, write to LISTSERV-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org and,
in the message body (not the subject), write: SIGNOFF MQSERIES
Instructions for managing your mailing list subscription are provided in
the Listserv General Users Guide available at http://www.lsoft.com
Archive: http://listserv.meduniwien.ac.at/archives/mqser-l.html

[Tim Zielke]

If this is more something temporary to help debug an issue, then I would go with the Activity Trace (if you are at >= 7.1) over standard tracing (i.e. strmqtrc).

For viewing the AAT data, there are significant enhancements to the amqsact program (called amqsactz) that I find helpful -> http://www.capitalware.com/mq_code_c.html

You do need a C compiler to build it for your platform, but I provide some examples in the comments of the program on how to do this on Windows or Linux. The MQ manual, of course, covers all environments for building an MQ program written in C.

Thanks,
Tim

From: MQSeries List [mailto:MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org] On Behalf Of Costa, D. (Damian)
Sent: Wednesday, October 08, 2014 7:45 AM
To: MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org
Subject: Re: Does an mq trace trap the data payloads that are moving thru the qmgr?

Swat I tole 'em..... improve their logging from their apps.
What is disappointing is that they cannot tell what their app is doing with the message. The MQ stats indicate they are taking them off the queue.
Heaven only know where they go from there.

From: MQSeries List [mailto:MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org] On Behalf Of Tim Zielke
Sent: 08 October 2014 02:07 PM
To: MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org<mailto:MQSERIES-0lvw86wZMd9k/***@public.gmane.orgAC.AT>
Subject: Re: Does an mq trace trap the data payloads that are moving thru the qmgr?

Hi Damian,

If your queue manager is 7.1 or higher, another option is the Application Activity Trace.

This IBM article on the AAT -> http://www.ibm.com/developerworks/websphere/library/techarticles/1306_bushby/1306_bushby.html

does give the scenario of "Using Application Activity Trace to keep an audit trail of messages" as one of the AAT's uses.

Personally, I would be hesitant to do what you are being asked to do, and would like to understand from the application team why their application can not do this logging, itself. Do they really need the entire message, or is it really key pieces of data that they could put into an application log.

Thanks,
Tim

From: MQSeries List [mailto:MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org] On Behalf Of T.Rob
Sent: Wednesday, October 08, 2014 4:17 AM
To: MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org<mailto:MQSERIES-0lvw86wZMd9k/***@public.gmane.orgAC.AT>
Subject: Re: Does an mq trace trap the data payloads that are moving thru the qmgr?

I think that's *most* of the persistent data. At MQTC Mark Taylor gave the MQ Internals session and said that the Put To Waiting Getter optimization permits certain persistent messages that are PUT outside of syncpoint to bypass the log. So for purposes of an audit you either need to use API-level tracing or else be able to prove to the auditor that your programs do everything inside of syncpoint and therefore the dmpmqlog output is complete.

Trying to find a single or very few messages that appear to have been processed but for which there is no log entry could REALLY screw up your day, your audit, your relationship with upper management, etc.

(Do not confuse this with the restaurant management API that can recall service staff from the golf course on their day off when there's a sudden surge in business. That is the "Get To Putting Waiter" API call and is completely different.)

Kind regards,
-- T.Rob

T.Robert Wyatt, Managing partner
IoPT Consulting, LLC
+1 704-443-TROB (8762) Voice/Text
[phone] Voice
https://ioptconsulting.com<https://ioptconsulting.com/>
https://twitter.com/tdotrob

From: MQSeries List [mailto:MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org] On Behalf Of Andrew Hickson
Sent: Wednesday, October 08, 2014 4:52 AM
To: MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org<mailto:MQSERIES-0lvw86wZMd9k/***@public.gmane.orgAC.AT>
Subject: Re: Does an mq trace trap the data payloads that are moving thru the qmgr?

If you're using linear logging then all of the message data (control information + payload) for persistent messages is recorded in the recovery log, and can be post processed with the dmpmqlog utility.
If you're using circular logging then you've effectively got a wrap around history of the last X bytes of persistent data, however getting to all of that data (e.g. dmpmqlog) is much more difficult and typically requires the help of MQ L3.
The main advantage of using the recovery log for this purpose is that there's no performance overhead.
The main disadvantage of using the recovery log for this purpose is that the information isn't in a form that's very easy to process/consume.





From: "T.Rob" <t.rob-CkT6zf+urXSzW/GOMZKyElesiRL1/***@public.gmane.org<mailto:***@IOPTCONSULTING.COM>>
To: MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org<mailto:MQSERIES-0lvw86wZMd8hNtF/***@public.gmane.orgNIWIEN.AC.AT>,
Date: 08/10/2014 09:41
Subject: Re: Does an mq trace trap the data payloads that are moving thru the qmgr?
Sent by: MQSeries List <MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org<mailto:MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org>>
________________________________



If you use the MA0W trace exit I believe that you can specify capturing just
the headers. I do recall though a conversation with Ralph Bateman about how
Support often receives traces and FDC files in PMRs that are filled with
PII, medical data, SSN's, card numbers, etc. So I believe the answer is
"yes." That said, the WMQ native trace can get real big, real fast so you
may want to look at MA0W which traces only API calls and not internals, SSL,
comms, etc.

http://ibm.co/SupptPacMA0W


Kind regards,
-- T.Rob


> -----Original Message-----
> From: MQSeries List [mailto:MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org] On Behalf
> Of Costa, D. (Damian)
> Sent: Wednesday, October 08, 2014 4:00 AM
> To: MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org<mailto:MQSERIES-0lvw86wZMd9k/***@public.gmane.orgN.AC.AT>
> Subject: Does an mq trace trap the data payloads that are moving thru the
> qmgr?
>
> HI all,
> I Was just asked to supply the audit traces of all messages going through
> a particular queue on a test qmgr. Naturally I can't just do that as no
> audit logs exist. So I was wondering if I could fudge it by running an mq
> trace to trap the message payloads being processed off said queue.
> Izzat even possible?
>
> ********************
> Nedbank Limited Reg No 1951/000009/06. The following link displays the
> names of the Nedbank Board of Directors and Company Secretary.
> [ http://www.nedbank.co.za/terms/DirectorsNedbank.htm ] This email is
> confidential and is intended for the addressee only.
> The following link will take you to Nedbank's legal notice.
> [ http://www.nedbank.co.za/terms/EmailDisclaimer.htm ]
> ********************
>
> To unsubscribe, write to LISTSERV-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org<mailto:LISTSERV-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org> and, in the
> message body (not the subject), write: SIGNOFF MQSERIES Instructions for
> managing your mailing list subscription are provided in the Listserv
> General Users Guide available at http://www.lsoft.com<http://www.lsoft.com/>
> Archive: http://listserv.meduniwien.ac.at/archives/mqser-l.html

To unsubscribe, write to LISTSERV-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org<mailto:***@LISTSERV.MEDUNIWIEN.AC.AT> and,
in the message body (not the subject), write: SIGNOFF MQSERIES
Instructions for managing your mailing list subscription are provided in
the Listserv General Users Guide available at http://www.lsoft.com<http://www.lsoft.com/>
Archive: http://listserv.meduniwien.ac.at/archives/mqser-l.html



Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number 741598.
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU
________________________________
List Archive<http://listserv.meduniwien.ac.at/archives/mqser-l.html> - Manage Your List Settings<http://listserv.meduniwien.ac.at/cgi-bin/wa?SUBED1=mqser-l&A=1> - Unsubscribe<mailto:LISTSERV-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org?subject=Unsubscribe&BODY=signoff%20mqseries>

Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com<http://www.lsoft.com/resources/manuals.asp>

________________________________
List Archive<http://listserv.meduniwien.ac.at/archives/mqser-l.html> - Manage Your List Settings<http://listserv.meduniwien.ac.at/cgi-bin/wa?SUBED1=mqser-l&A=1> - Unsubscribe<mailto:LISTSERV-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org?subject=Unsubscribe&BODY=signoff%20mqseries>

Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com<http://www.lsoft.com/resources/manuals.asp>

________________________________
List Archive<http://listserv.meduniwien.ac.at/archives/mqser-l.html> - Manage Your List Settings<http://listserv.meduniwien.ac.at/cgi-bin/wa?SUBED1=mqser-l&A=1> - Unsubscribe<mailto:LISTSERV-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org?subject=Unsubscribe&BODY=signoff%20mqseries>

Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com<http://www.lsoft.com/resources/manuals.asp>

********************
Nedbank Limited Reg No 1951/000009/06. The following link displays
the names of the Nedbank Board of Directors and Company Secretary.
[ http://www.nedbank.co.za/terms/DirectorsNedbank.htm ]
This email is confidential and is intended for the addressee only.
The following link will take you to Nedbank's legal notice.
[ http://www.nedbank.co.za/terms/EmailDisclaimer.htm ]
********************

________________________________
List Archive<http://listserv.meduniwien.ac.at/archives/mqser-l.html> - Manage Your List Settings<http://listserv.meduniwien.ac.at/cgi-bin/wa?SUBED1=mqser-l&A=1> - Unsubscribe<mailto:LISTSERV-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org?subject=Unsubscribe&BODY=signoff%20mqseries>

Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com<http://www.lsoft.com/resources/manuals.asp>

To unsubscribe, write to LISTSERV-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org and,
in the message body (not the subject), write: SIGNOFF MQSERIES
Instructions for managing your mailing list subscription are provided in
the Listserv General Users Guide available at http://www.lsoft.com
Archive: http://listserv.meduniwien.ac.at/archives/mqser-l.html

[Tim Zielke]

One other thing to be aware of if you are going to be using standard tracing (i.e. strmqtrc).

There is a bug in standard tracing where if an application opens multiple connections on a single thread (i.e. an app that uses MQCNO_HANDLE_SHARE_BLOCK on its connections and opens multiple connections in a thread), then tracing will be shut off after the first MQDISC. The end result is you will be missing trace data and have real MQ calls that are unaccounted for in the trace. I have personally ran across this with some of our apps that are coded this way, and the AAT does not miss the MQ calls. There is an APAR IT01972 for this standard tracing bug, that has a targeted delivery of 7.1.0.6, 7.5.0.5, 8.0.0.1.


From: Tim Zielke
Sent: Wednesday, October 08, 2014 8:01 AM
To: MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org
Subject: RE: Does an mq trace trap the data payloads that are moving thru the qmgr?

If this is more something temporary to help debug an issue, then I would go with the Activity Trace (if you are at >= 7.1) over standard tracing (i.e. strmqtrc).

For viewing the AAT data, there are significant enhancements to the amqsact program (called amqsactz) that I find helpful -> http://www.capitalware.com/mq_code_c.html

You do need a C compiler to build it for your platform, but I provide some examples in the comments of the program on how to do this on Windows or Linux. The MQ manual, of course, covers all environments for building an MQ program written in C.

Thanks,
Tim

From: MQSeries List [mailto:MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org] On Behalf Of Costa, D. (Damian)
Sent: Wednesday, October 08, 2014 7:45 AM
To: MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org<mailto:MQSERIES-0lvw86wZMd9k/***@public.gmane.orgAC.AT>
Subject: Re: Does an mq trace trap the data payloads that are moving thru the qmgr?

Swat I tole 'em..... improve their logging from their apps.
What is disappointing is that they cannot tell what their app is doing with the message. The MQ stats indicate they are taking them off the queue.
Heaven only know where they go from there.

From: MQSeries List [mailto:MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org] On Behalf Of Tim Zielke
Sent: 08 October 2014 02:07 PM
To: MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org<mailto:MQSERIES-0lvw86wZMd9k/***@public.gmane.orgAC.AT>
Subject: Re: Does an mq trace trap the data payloads that are moving thru the qmgr?

Hi Damian,

If your queue manager is 7.1 or higher, another option is the Application Activity Trace.

This IBM article on the AAT -> http://www.ibm.com/developerworks/websphere/library/techarticles/1306_bushby/1306_bushby.html

does give the scenario of "Using Application Activity Trace to keep an audit trail of messages" as one of the AAT's uses.

Personally, I would be hesitant to do what you are being asked to do, and would like to understand from the application team why their application can not do this logging, itself. Do they really need the entire message, or is it really key pieces of data that they could put into an application log.

Thanks,
Tim

From: MQSeries List [mailto:MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org] On Behalf Of T.Rob
Sent: Wednesday, October 08, 2014 4:17 AM
To: MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org<mailto:MQSERIES-0lvw86wZMd9k/***@public.gmane.orgAC.AT>
Subject: Re: Does an mq trace trap the data payloads that are moving thru the qmgr?

I think that's *most* of the persistent data. At MQTC Mark Taylor gave the MQ Internals session and said that the Put To Waiting Getter optimization permits certain persistent messages that are PUT outside of syncpoint to bypass the log. So for purposes of an audit you either need to use API-level tracing or else be able to prove to the auditor that your programs do everything inside of syncpoint and therefore the dmpmqlog output is complete.

Trying to find a single or very few messages that appear to have been processed but for which there is no log entry could REALLY screw up your day, your audit, your relationship with upper management, etc.

(Do not confuse this with the restaurant management API that can recall service staff from the golf course on their day off when there's a sudden surge in business. That is the "Get To Putting Waiter" API call and is completely different.)

Kind regards,
-- T.Rob

T.Robert Wyatt, Managing partner
IoPT Consulting, LLC
+1 704-443-TROB (8762) Voice/Text
[phone] Voice
https://ioptconsulting.com<https://ioptconsulting.com/>
https://twitter.com/tdotrob

From: MQSeries List [mailto:MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org] On Behalf Of Andrew Hickson
Sent: Wednesday, October 08, 2014 4:52 AM
To: MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org<mailto:MQSERIES-0lvw86wZMd9k/***@public.gmane.orgAC.AT>
Subject: Re: Does an mq trace trap the data payloads that are moving thru the qmgr?

If you're using linear logging then all of the message data (control information + payload) for persistent messages is recorded in the recovery log, and can be post processed with the dmpmqlog utility.
If you're using circular logging then you've effectively got a wrap around history of the last X bytes of persistent data, however getting to all of that data (e.g. dmpmqlog) is much more difficult and typically requires the help of MQ L3.
The main advantage of using the recovery log for this purpose is that there's no performance overhead.
The main disadvantage of using the recovery log for this purpose is that the information isn't in a form that's very easy to process/consume.





From: "T.Rob" <t.rob-CkT6zf+urXSzW/GOMZKyElesiRL1/***@public.gmane.org<mailto:***@IOPTCONSULTING.COM>>
To: MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org<mailto:MQSERIES-0lvw86wZMd8hNtF/***@public.gmane.orgNIWIEN.AC.AT>,
Date: 08/10/2014 09:41
Subject: Re: Does an mq trace trap the data payloads that are moving thru the qmgr?
Sent by: MQSeries List <MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org<mailto:MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org>>
________________________________



If you use the MA0W trace exit I believe that you can specify capturing just
the headers. I do recall though a conversation with Ralph Bateman about how
Support often receives traces and FDC files in PMRs that are filled with
PII, medical data, SSN's, card numbers, etc. So I believe the answer is
"yes." That said, the WMQ native trace can get real big, real fast so you
may want to look at MA0W which traces only API calls and not internals, SSL,
comms, etc.

http://ibm.co/SupptPacMA0W


Kind regards,
-- T.Rob


> -----Original Message-----
> From: MQSeries List [mailto:MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org] On Behalf
> Of Costa, D. (Damian)
> Sent: Wednesday, October 08, 2014 4:00 AM
> To: MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org<mailto:MQSERIES-0lvw86wZMd9k/***@public.gmane.orgN.AC.AT>
> Subject: Does an mq trace trap the data payloads that are moving thru the
> qmgr?
>
> HI all,
> I Was just asked to supply the audit traces of all messages going through
> a particular queue on a test qmgr. Naturally I can't just do that as no
> audit logs exist. So I was wondering if I could fudge it by running an mq
> trace to trap the message payloads being processed off said queue.
> Izzat even possible?
>
> ********************
> Nedbank Limited Reg No 1951/000009/06. The following link displays the
> names of the Nedbank Board of Directors and Company Secretary.
> [ http://www.nedbank.co.za/terms/DirectorsNedbank.htm ] This email is
> confidential and is intended for the addressee only.
> The following link will take you to Nedbank's legal notice.
> [ http://www.nedbank.co.za/terms/EmailDisclaimer.htm ]
> ********************
>
> To unsubscribe, write to LISTSERV-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org<mailto:LISTSERV-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org> and, in the
> message body (not the subject), write: SIGNOFF MQSERIES Instructions for
> managing your mailing list subscription are provided in the Listserv
> General Users Guide available at http://www.lsoft.com<http://www.lsoft.com/>
> Archive: http://listserv.meduniwien.ac.at/archives/mqser-l.html

To unsubscribe, write to LISTSERV-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org<mailto:***@LISTSERV.MEDUNIWIEN.AC.AT> and,
in the message body (not the subject), write: SIGNOFF MQSERIES
Instructions for managing your mailing list subscription are provided in
the Listserv General Users Guide available at http://www.lsoft.com<http://www.lsoft.com/>
Archive: http://listserv.meduniwien.ac.at/archives/mqser-l.html



Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number 741598.
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU
________________________________
List Archive<http://listserv.meduniwien.ac.at/archives/mqser-l.html> - Manage Your List Settings<http://listserv.meduniwien.ac.at/cgi-bin/wa?SUBED1=mqser-l&A=1> - Unsubscribe<mailto:LISTSERV-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org?subject=Unsubscribe&BODY=signoff%20mqseries>

Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com<http://www.lsoft.com/resources/manuals.asp>

________________________________
List Archive<http://listserv.meduniwien.ac.at/archives/mqser-l.html> - Manage Your List Settings<http://listserv.meduniwien.ac.at/cgi-bin/wa?SUBED1=mqser-l&A=1> - Unsubscribe<mailto:LISTSERV-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org?subject=Unsubscribe&BODY=signoff%20mqseries>

Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com<http://www.lsoft.com/resources/manuals.asp>

________________________________
List Archive<http://listserv.meduniwien.ac.at/archives/mqser-l.html> - Manage Your List Settings<http://listserv.meduniwien.ac.at/cgi-bin/wa?SUBED1=mqser-l&A=1> - Unsubscribe<mailto:LISTSERV-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org?subject=Unsubscribe&BODY=signoff%20mqseries>

Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com<http://www.lsoft.com/resources/manuals.asp>

********************
Nedbank Limited Reg No 1951/000009/06. The following link displays
the names of the Nedbank Board of Directors and Company Secretary.
[ http://www.nedbank.co.za/terms/DirectorsNedbank.htm ]
This email is confidential and is intended for the addressee only.
The following link will take you to Nedbank's legal notice.
[ http://www.nedbank.co.za/terms/EmailDisclaimer.htm ]
********************

________________________________
List Archive<http://listserv.meduniwien.ac.at/archives/mqser-l.html> - Manage Your List Settings<http://listserv.meduniwien.ac.at/cgi-bin/wa?SUBED1=mqser-l&A=1> - Unsubscribe<mailto:LISTSERV-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org?subject=Unsubscribe&BODY=signoff%20mqseries>

Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com<http://www.lsoft.com/resources/manuals.asp>

To unsubscribe, write to LISTSERV-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org and,
in the message body (not the subject), write: SIGNOFF MQSERIES
Instructions for managing your mailing list subscription are provided in
the Listserv General Users Guide available at http://www.lsoft.com
Archive: http://listserv.meduniwien.ac.at/archives/mqser-l.html

[Jefferson Lowrey]

The other thing you can do is (mis) use pub/sub and reroute messages that
are supposed to go to the application input queue to a topic instead, and
then create two admin subscriptions - one to the original input queue and
one to a different queue - something that just gets dumped to a text file
(perhaps by qload or etc.)

This is the basic replacement for mirrorq as of v7's pub/sub function. If,
somehow, you're still at <v7, you can test your googlefu by trying to find
some copy of the mirrorq source code to compile.

Thank you,

Jeff Lowrey




From: Tim Zielke <***@AON.COM>
To: ***@LISTSERV.MEDUNIWIEN.AC.AT
Date: 10/08/2014 08:01 AM
Subject: Re: [MQSERIES] Does an mq trace trap the data payloads
that are moving thru the qmgr?
Sent by: MQSeries List <***@LISTSERV.MEDUNIWIEN.AC.AT>



If this is more something temporary to help debug an issue, then I would
go with the Activity Trace (if you are at >= 7.1) over standard tracing
(i.e. strmqtrc).

For viewing the AAT data, there are significant enhancements to the
amqsact program (called amqsactz) that I find helpful ->
http://www.capitalware.com/mq_code_c.html

You do need a C compiler to build it for your platform, but I provide some
examples in the comments of the program on how to do this on Windows or
Linux. The MQ manual, of course, covers all environments for building an
MQ program written in C.

Thanks,
Tim

From: MQSeries List [mailto:***@LISTSERV.MEDUNIWIEN.AC.AT] On Behalf
Of Costa, D. (Damian)
Sent: Wednesday, October 08, 2014 7:45 AM
To: ***@LISTSERV.MEDUNIWIEN.AC.AT
Subject: Re: Does an mq trace trap the data payloads that are moving thru
the qmgr?

Swat I tole ‘em
.. improve their logging from their apps.
What is disappointing is that they cannot tell what their app is doing
with the message. The MQ stats indicate they are taking them off the
queue.
Heaven only know where they go from there.

From: MQSeries List [mailto:***@LISTSERV.MEDUNIWIEN.AC.AT] On Behalf
Of Tim Zielke
Sent: 08 October 2014 02:07 PM
To: ***@LISTSERV.MEDUNIWIEN.AC.AT
Subject: Re: Does an mq trace trap the data payloads that are moving thru
the qmgr?

Hi Damian,

If your queue manager is 7.1 or higher, another option is the Application
Activity Trace.

This IBM article on the AAT ->
http://www.ibm.com/developerworks/websphere/library/techarticles/1306_bushby/1306_bushby.html

does give the scenario of “Using Application Activity Trace to keep an
audit trail of messages” as one of the AAT’s uses.

Personally, I would be hesitant to do what you are being asked to do, and
would like to understand from the application team why their application
can not do this logging, itself. Do they really need the entire message,
or is it really key pieces of data that they could put into an application
log.

Thanks,
Tim

From: MQSeries List [mailto:***@LISTSERV.MEDUNIWIEN.AC.AT] On Behalf
Of T.Rob
Sent: Wednesday, October 08, 2014 4:17 AM
To: ***@LISTSERV.MEDUNIWIEN.AC.AT
Subject: Re: Does an mq trace trap the data payloads that are moving thru
the qmgr?

I think that's *most* of the persistent data. At MQTC Mark Taylor gave
the MQ Internals session and said that the Put To Waiting Getter
optimization permits certain persistent messages that are PUT outside of
syncpoint to bypass the log. So for purposes of an audit you either need
to use API-level tracing or else be able to prove to the auditor that your
programs do everything inside of syncpoint and therefore the dmpmqlog
output is complete.

Trying to find a single or very few messages that appear to have been
processed but for which there is no log entry could REALLY screw up your
day, your audit, your relationship with upper management, etc.

(Do not confuse this with the restaurant management API that can recall
service staff from the golf course on their day off when there's a sudden
surge in business. That is the "Get To Putting Waiter" API call and is
completely different.)

Kind regards,
-- T.Rob

T.Robert Wyatt, Managing partner
IoPT Consulting, LLC
+1 704-443-TROB (8762) Voice/Text
[phone] Voice
https://ioptconsulting.com
https://twitter.com/tdotrob

From: MQSeries List [mailto:***@LISTSERV.MEDUNIWIEN.AC.AT] On Behalf
Of Andrew Hickson
Sent: Wednesday, October 08, 2014 4:52 AM
To: ***@LISTSERV.MEDUNIWIEN.AC.AT
Subject: Re: Does an mq trace trap the data payloads that are moving thru
the qmgr?

If you're using linear logging then all of the message data (control
information + payload) for persistent messages is recorded in the recovery
log, and can be post processed with the dmpmqlog utility.
If you're using circular logging then you've effectively got a wrap around
history of the last X bytes of persistent data, however getting to all of
that data (e.g. dmpmqlog) is much more difficult and typically requires
the help of MQ L3.
The main advantage of using the recovery log for this purpose is that
there's no performance overhead.
The main disadvantage of using the recovery log for this purpose is that
the information isn't in a form that's very easy to process/consume.





From: "T.Rob" <***@IOPTCONSULTING.COM>
To: ***@LISTSERV.MEDUNIWIEN.AC.AT,
Date: 08/10/2014 09:41
Subject: Re: Does an mq trace trap the data payloads that are
moving thru the qmgr?
Sent by: MQSeries List <***@LISTSERV.MEDUNIWIEN.AC.AT>




If you use the MA0W trace exit I believe that you can specify capturing
just
the headers. I do recall though a conversation with Ralph Bateman about
how
Support often receives traces and FDC files in PMRs that are filled with
PII, medical data, SSN's, card numbers, etc. So I believe the answer is
"yes." That said, the WMQ native trace can get real big, real fast so you
may want to look at MA0W which traces only API calls and not internals,
SSL,
comms, etc.

http://ibm.co/SupptPacMA0W


Kind regards,
-- T.Rob


> -----Original Message-----
> From: MQSeries List [mailto:***@LISTSERV.MEDUNIWIEN.AC.AT] On
Behalf
> Of Costa, D. (Damian)
> Sent: Wednesday, October 08, 2014 4:00 AM
> To: ***@LISTSERV.MEDUNIWIEN.AC.AT
> Subject: Does an mq trace trap the data payloads that are moving thru
the
> qmgr?
>
> HI all,
> I Was just asked to supply the audit traces of all messages going
through
> a particular queue on a test qmgr. Naturally I can't just do that as no
> audit logs exist. So I was wondering if I could fudge it by running an
mq
> trace to trap the message payloads being processed off said queue.
> Izzat even possible?
>
> ********************
> Nedbank Limited Reg No 1951/000009/06. The following link displays the
> names of the Nedbank Board of Directors and Company Secretary.
> [ http://www.nedbank.co.za/terms/DirectorsNedbank.htm ] This email is
> confidential and is intended for the addressee only.
> The following link will take you to Nedbank's legal notice.
> [ http://www.nedbank.co.za/terms/EmailDisclaimer.htm ]
> ********************
>
> To unsubscribe, write to ***@LISTSERV.MEDUNIWIEN.AC.AT and, in the
> message body (not the subject), write: SIGNOFF MQSERIES Instructions for
> managing your mailing list subscription are provided in the Listserv
> General Users Guide available at http://www.lsoft.com
> Archive: http://listserv.meduniwien.ac.at/archives/mqser-l.html

To unsubscribe, write to ***@LISTSERV.MEDUNIWIEN.AC.AT and,
in the message body (not the subject), write: SIGNOFF MQSERIES
Instructions for managing your mailing list subscription are provided in
the Listserv General Users Guide available at http://www.lsoft.com
Archive: http://listserv.meduniwien.ac.at/archives/mqser-l.html



Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number
741598.
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU

List Archive - Manage Your List Settings - Unsubscribe
Instructions for managing your mailing list subscription are provided in
the Listserv General Users Guide available at http://www.lsoft.com


List Archive - Manage Your List Settings - Unsubscribe
Instructions for managing your mailing list subscription are provided in
the Listserv General Users Guide available at http://www.lsoft.com


List Archive - Manage Your List Settings - Unsubscribe
Instructions for managing your mailing list subscription are provided in
the Listserv General Users Guide available at http://www.lsoft.com

********************
Nedbank Limited Reg No 1951/000009/06. The following link displays
the names of the Nedbank Board of Directors and Company Secretary.
[ http://www.nedbank.co.za/terms/DirectorsNedbank.htm ]
This email is confidential and is intended for the addressee only.
The following link will take you to Nedbank's legal notice.
[ http://www.nedbank.co.za/terms/EmailDisclaimer.htm ]
********************


List Archive - Manage Your List Settings - Unsubscribe
Instructions for managing your mailing list subscription are provided in
the Listserv General Users Guide available at http://www.lsoft.com


List Archive - Manage Your List Settings - Unsubscribe
Instructions for managing your mailing list subscription are provided in
the Listserv General Users Guide available at http://www.lsoft.com


To unsubscribe, write to ***@LISTSERV.MEDUNIWIEN.AC.AT and,
in the message body (not the subject), write: SIGNOFF MQSERIES
Instructions for managing your mailing list subscription are provided in
the Listserv General Users Guide available at http://www.lsoft.com
Archive: http://listserv.meduniwien.ac.at/archives/mqser-l.html

[Costa, D. (Damian)]

Great idea re the topic queue. Will go setup and see what is happening.


From: MQSeries List [mailto:***@LISTSERV.MEDUNIWIEN.AC.AT] On Behalf Of Jefferson Lowrey
Sent: 08 October 2014 03:52 PM
To: ***@LISTSERV.MEDUNIWIEN.AC.AT
Subject: Re: Does an mq trace trap the data payloads that are moving thru the qmgr?

The other thing you can do is (mis) use pub/sub and reroute messages that are supposed to go to the application input queue to a topic instead, and then create two admin subscriptions - one to the original input queue and one to a different queue - something that just gets dumped to a text file (perhaps by qload or etc.)

This is the basic replacement for mirrorq as of v7's pub/sub function. If, somehow, you're still at <v7, you can test your googlefu by trying to find some copy of the mirrorq source code to compile.

Thank you,

Jeff Lowrey




From: Tim Zielke <***@AON.COM<mailto:***@AON.COM>>
To: ***@LISTSERV.MEDUNIWIEN.AC.AT<mailto:***@LISTSERV.MEDUNIWIEN.AC.AT>
Date: 10/08/2014 08:01 AM
Subject: Re: [MQSERIES] Does an mq trace trap the data payloads that are moving thru the qmgr?
Sent by: MQSeries List <***@LISTSERV.MEDUNIWIEN.AC.AT<mailto:***@LISTSERV.MEDUNIWIEN.AC.AT>>
________________________________



If this is more something temporary to help debug an issue, then I would go with the Activity Trace (if you are at >= 7.1) over standard tracing (i.e. strmqtrc).

For viewing the AAT data, there are significant enhancements to the amqsact program (called amqsactz) that I find helpful -> http://www.capitalware.com/mq_code_c.html

You do need a C compiler to build it for your platform, but I provide some examples in the comments of the program on how to do this on Windows or Linux. The MQ manual, of course, covers all environments for building an MQ program written in C.

Thanks,
Tim

From: MQSeries List [mailto:***@LISTSERV.MEDUNIWIEN.AC.AT] On Behalf Of Costa, D. (Damian)
Sent: Wednesday, October 08, 2014 7:45 AM
To: ***@LISTSERV.MEDUNIWIEN.AC.AT<mailto:***@LISTSERV.MEDUNIWIEN.AC.AT>
Subject: Re: Does an mq trace trap the data payloads that are moving thru the qmgr?

Swat I tole ‘em
.. improve their logging from their apps.
What is disappointing is that they cannot tell what their app is doing with the message. The MQ stats indicate they are taking them off the queue.
Heaven only know where they go from there.

From: MQSeries List [mailto:***@LISTSERV.MEDUNIWIEN.AC.AT] On Behalf Of Tim Zielke
Sent: 08 October 2014 02:07 PM
To: ***@LISTSERV.MEDUNIWIEN.AC.AT<mailto:***@LISTSERV.MEDUNIWIEN.AC.AT>
Subject: Re: Does an mq trace trap the data payloads that are moving thru the qmgr?

Hi Damian,

If your queue manager is 7.1 or higher, another option is the Application Activity Trace.

This IBM article on the AAT -> http://www.ibm.com/developerworks/websphere/library/techarticles/1306_bushby/1306_bushby.html

does give the scenario of “Using Application Activity Trace to keep an audit trail of messages” as one of the AAT’s uses.

Personally, I would be hesitant to do what you are being asked to do, and would like to understand from the application team why their application can not do this logging, itself. Do they really need the entire message, or is it really key pieces of data that they could put into an application log.

Thanks,
Tim

From: MQSeries List [mailto:***@LISTSERV.MEDUNIWIEN.AC.AT] On Behalf Of T.Rob
Sent: Wednesday, October 08, 2014 4:17 AM
To: ***@LISTSERV.MEDUNIWIEN.AC.AT<mailto:***@LISTSERV.MEDUNIWIEN.AC.AT>
Subject: Re: Does an mq trace trap the data payloads that are moving thru the qmgr?

I think that's *most* of the persistent data. At MQTC Mark Taylor gave the MQ Internals session and said that the Put To Waiting Getter optimization permits certain persistent messages that are PUT outside of syncpoint to bypass the log. So for purposes of an audit you either need to use API-level tracing or else be able to prove to the auditor that your programs do everything inside of syncpoint and therefore the dmpmqlog output is complete.

Trying to find a single or very few messages that appear to have been processed but for which there is no log entry could REALLY screw up your day, your audit, your relationship with upper management, etc.

(Do not confuse this with the restaurant management API that can recall service staff from the golf course on their day off when there's a sudden surge in business. That is the "Get To Putting Waiter" API call and is completely different.)

Kind regards,
-- T.Rob

T.Robert Wyatt, Managing partner
IoPT Consulting, LLC
+1 704-443-TROB (8762) Voice/Text
[phone] Voice
https://ioptconsulting.com<https://ioptconsulting.com/>
https://twitter.com/tdotrob

From: MQSeries List [mailto:***@LISTSERV.MEDUNIWIEN.AC.AT] On Behalf Of Andrew Hickson
Sent: Wednesday, October 08, 2014 4:52 AM
To: ***@LISTSERV.MEDUNIWIEN.AC.AT<mailto:***@LISTSERV.MEDUNIWIEN.AC.AT>
Subject: Re: Does an mq trace trap the data payloads that are moving thru the qmgr?

If you're using linear logging then all of the message data (control information + payload) for persistent messages is recorded in the recovery log, and can be post processed with the dmpmqlog utility.
If you're using circular logging then you've effectively got a wrap around history of the last X bytes of persistent data, however getting to all of that data (e.g. dmpmqlog) is much more difficult and typically requires the help of MQ L3.
The main advantage of using the recovery log for this purpose is that there's no performance overhead.
The main disadvantage of using the recovery log for this purpose is that the information isn't in a form that's very easy to process/consume.





From: "T.Rob" <***@IOPTCONSULTING.COM<mailto:***@IOPTCONSULTING.COM>>
To: ***@LISTSERV.MEDUNIWIEN.AC.AT<mailto:***@LISTSERV.MEDUNIWIEN.AC.AT>,
Date: 08/10/2014 09:41
Subject: Re: Does an mq trace trap the data payloads that are moving thru the qmgr?
Sent by: MQSeries List <***@LISTSERV.MEDUNIWIEN.AC.AT<mailto:***@LISTSERV.MEDUNIWIEN.AC.AT>>
________________________________




If you use the MA0W trace exit I believe that you can specify capturing just
the headers. I do recall though a conversation with Ralph Bateman about how
Support often receives traces and FDC files in PMRs that are filled with
PII, medical data, SSN's, card numbers, etc. So I believe the answer is
"yes." That said, the WMQ native trace can get real big, real fast so you
may want to look at MA0W which traces only API calls and not internals, SSL,
comms, etc.

http://ibm.co/SupptPacMA0W


Kind regards,
-- T.Rob


> -----Original Message-----
> From: MQSeries List [mailto:***@LISTSERV.MEDUNIWIEN.AC.AT] On Behalf
> Of Costa, D. (Damian)
> Sent: Wednesday, October 08, 2014 4:00 AM
> To: ***@LISTSERV.MEDUNIWIEN.AC.AT<mailto:***@LISTSERV.MEDUNIWIEN.AC.AT>
> Subject: Does an mq trace trap the data payloads that are moving thru the
> qmgr?
>
> HI all,
> I Was just asked to supply the audit traces of all messages going through
> a particular queue on a test qmgr. Naturally I can't just do that as no
> audit logs exist. So I was wondering if I could fudge it by running an mq
> trace to trap the message payloads being processed off said queue.
> Izzat even possible?
>
> ********************
> Nedbank Limited Reg No 1951/000009/06. The following link displays the
> names of the Nedbank Board of Directors and Company Secretary.
> [ http://www.nedbank.co.za/terms/DirectorsNedbank.htm ] This email is
> confidential and is intended for the addressee only.
> The following link will take you to Nedbank's legal notice.
> [ http://www.nedbank.co.za/terms/EmailDisclaimer.htm ]
> ********************
>
> To unsubscribe, write to ***@LISTSERV.MEDUNIWIEN.AC.AT<mailto:***@LISTSERV.MEDUNIWIEN.AC.AT> and, in the
> message body (not the subject), write: SIGNOFF MQSERIES Instructions for
> managing your mailing list subscription are provided in the Listserv
> General Users Guide available at http://www.lsoft.com<http://www.lsoft.com/>
> Archive: http://listserv.meduniwien.ac.at/archives/mqser-l.html

To unsubscribe, write to ***@LISTSERV.MEDUNIWIEN.AC.AT<mailto:***@LISTSERV.MEDUNIWIEN.AC.AT> and,
in the message body (not the subject), write: SIGNOFF MQSERIES
Instructions for managing your mailing list subscription are provided in
the Listserv General Users Guide available at http://www.lsoft.com<http://www.lsoft.com/>
Archive: http://listserv.meduniwien.ac.at/archives/mqser-l.html



Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number 741598.
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU
________________________________

List Archive<http://listserv.meduniwien.ac.at/archives/mqser-l.html> - Manage Your List Settings<http://listserv.meduniwien.ac.at/cgi-bin/wa?SUBED1=mqser-l&A=1> - Unsubscribe<mailto:***@LISTSERV.MEDUNIWIEN.AC.AT?subject=Unsubscribe&BODY=signoff%20mqseries>

Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com<http://www.lsoft.com/resources/manuals.asp>


________________________________

List Archive<http://listserv.meduniwien.ac.at/archives/mqser-l.html> - Manage Your List Settings<http://listserv.meduniwien.ac.at/cgi-bin/wa?SUBED1=mqser-l&A=1> - Unsubscribe<mailto:***@LISTSERV.MEDUNIWIEN.AC.AT?subject=Unsubscribe&BODY=signoff%20mqseries>

Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com<http://www.lsoft.com/resources/manuals.asp>


________________________________

List Archive<http://listserv.meduniwien.ac.at/archives/mqser-l.html> - Manage Your List Settings<http://listserv.meduniwien.ac.at/cgi-bin/wa?SUBED1=mqser-l&A=1> - Unsubscribe<mailto:***@LISTSERV.MEDUNIWIEN.AC.AT?subject=Unsubscribe&BODY=signoff%20mqseries>

Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com<http://www.lsoft.com/resources/manuals.asp>

********************
Nedbank Limited Reg No 1951/000009/06. The following link displays
the names of the Nedbank Board of Directors and Company Secretary.
[ http://www.nedbank.co.za/terms/DirectorsNedbank.htm ]
This email is confidential and is intended for the addressee only.
The following link will take you to Nedbank's legal notice.
[ http://www.nedbank.co.za/terms/EmailDisclaimer.htm ]
********************


________________________________

List Archive<http://listserv.meduniwien.ac.at/archives/mqser-l.html> - Manage Your List Settings<http://listserv.meduniwien.ac.at/cgi-bin/wa?SUBED1=mqser-l&A=1> - Unsubscribe<mailto:***@LISTSERV.MEDUNIWIEN.AC.AT?subject=Unsubscribe&BODY=signoff%20mqseries>

Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com<http://www.lsoft.com/resources/manuals.asp>



________________________________
List Archive<http://listserv.meduniwien.ac.at/archives/mqser-l.html> - Manage Your List Settings<http://listserv.meduniwien.ac.at/cgi-bin/wa?SUBED1=mqser-l&A=1> - Unsubscribe<mailto:***@LISTSERV.MEDUNIWIEN.AC.AT?subject=Unsubscribe&BODY=signoff%20mqseries>

Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com<http://www.lsoft.com/resources/manuals.asp>

________________________________
List Archive<http://listserv.meduniwien.ac.at/archives/mqser-l.html> - Manage Your List Settings<http://listserv.meduniwien.ac.at/cgi-bin/wa?SUBED1=mqser-l&A=1> - Unsubscribe<mailto:***@LISTSERV.MEDUNIWIEN.AC.AT?subject=Unsubscribe&BODY=signoff%20mqseries>

Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com<http://www.lsoft.com/resources/manuals.asp>

********************
Nedbank Limited Reg No 1951/000009/06. The following link displays
the names of the Nedbank Board of Directors and Company Secretary.
[ http://www.nedbank.co.za/terms/DirectorsNedbank.htm ]
This email is confidential and is intended for the addressee only.
The following link will take you to Nedbank's legal notice.
[ http://www.nedbank.co.za/terms/EmailDisclaimer.htm ]
********************


To unsubscribe, write to ***@LISTSERV.MEDUNIWIEN.AC.AT and,
in the message body (not the subject), write: SIGNOFF MQSERIES
Instructions for managing your mailing list subscription are provided in
the Listserv General Users Guide available at http://www.lsoft.com
Archive: http://listserv.meduniwien.ac.at/archives/mqser-l.html

[Tim Zielke]

The added benefit of going the Activity Trace route is not only would you get the message (header and body) like you would with the pub/sub “mirrorq” approach, but you would also be able to see the behavior of the putter and getter applications (i.e. what get/put options they are using, etc.), which could be beneficial in getting to the root cause of the issue.


From: MQSeries List [mailto:***@LISTSERV.MEDUNIWIEN.AC.AT] On Behalf Of Costa, D. (Damian)
Sent: Wednesday, October 08, 2014 10:37 AM
To: ***@LISTSERV.MEDUNIWIEN.AC.AT
Subject: Re: Does an mq trace trap the data payloads that are moving thru the qmgr?

Great idea re the topic queue. Will go setup and see what is happening.


From: MQSeries List [mailto:***@LISTSERV.MEDUNIWIEN.AC.AT] On Behalf Of Jefferson Lowrey
Sent: 08 October 2014 03:52 PM
To: ***@LISTSERV.MEDUNIWIEN.AC.AT<mailto:***@LISTSERV.MEDUNIWIEN.AC.AT>
Subject: Re: Does an mq trace trap the data payloads that are moving thru the qmgr?

The other thing you can do is (mis) use pub/sub and reroute messages that are supposed to go to the application input queue to a topic instead, and then create two admin subscriptions - one to the original input queue and one to a different queue - something that just gets dumped to a text file (perhaps by qload or etc.)

This is the basic replacement for mirrorq as of v7's pub/sub function. If, somehow, you're still at <v7, you can test your googlefu by trying to find some copy of the mirrorq source code to compile.

Thank you,

Jeff Lowrey




From: Tim Zielke <***@AON.COM<mailto:***@AON.COM>>
To: ***@LISTSERV.MEDUNIWIEN.AC.AT<mailto:***@LISTSERV.MEDUNIWIEN.AC.AT>
Date: 10/08/2014 08:01 AM
Subject: Re: [MQSERIES] Does an mq trace trap the data payloads that are moving thru the qmgr?
Sent by: MQSeries List <***@LISTSERV.MEDUNIWIEN.AC.AT<mailto:***@LISTSERV.MEDUNIWIEN.AC.AT>>
________________________________



If this is more something temporary to help debug an issue, then I would go with the Activity Trace (if you are at >= 7.1) over standard tracing (i.e. strmqtrc).

For viewing the AAT data, there are significant enhancements to the amqsact program (called amqsactz) that I find helpful -> http://www.capitalware.com/mq_code_c.html

You do need a C compiler to build it for your platform, but I provide some examples in the comments of the program on how to do this on Windows or Linux. The MQ manual, of course, covers all environments for building an MQ program written in C.

Thanks,
Tim

From: MQSeries List [mailto:***@LISTSERV.MEDUNIWIEN.AC.AT] On Behalf Of Costa, D. (Damian)
Sent: Wednesday, October 08, 2014 7:45 AM
To: ***@LISTSERV.MEDUNIWIEN.AC.AT<mailto:***@LISTSERV.MEDUNIWIEN.AC.AT>
Subject: Re: Does an mq trace trap the data payloads that are moving thru the qmgr?

Swat I tole ‘em
.. improve their logging from their apps.
What is disappointing is that they cannot tell what their app is doing with the message. The MQ stats indicate they are taking them off the queue.
Heaven only know where they go from there.

From: MQSeries List [mailto:***@LISTSERV.MEDUNIWIEN.AC.AT] On Behalf Of Tim Zielke
Sent: 08 October 2014 02:07 PM
To: ***@LISTSERV.MEDUNIWIEN.AC.AT<mailto:***@LISTSERV.MEDUNIWIEN.AC.AT>
Subject: Re: Does an mq trace trap the data payloads that are moving thru the qmgr?

Hi Damian,

If your queue manager is 7.1 or higher, another option is the Application Activity Trace.

This IBM article on the AAT -> http://www.ibm.com/developerworks/websphere/library/techarticles/1306_bushby/1306_bushby.html

does give the scenario of “Using Application Activity Trace to keep an audit trail of messages” as one of the AAT’s uses.

Personally, I would be hesitant to do what you are being asked to do, and would like to understand from the application team why their application can not do this logging, itself. Do they really need the entire message, or is it really key pieces of data that they could put into an application log.

Thanks,
Tim

From: MQSeries List [mailto:***@LISTSERV.MEDUNIWIEN.AC.AT] On Behalf Of T.Rob
Sent: Wednesday, October 08, 2014 4:17 AM
To: ***@LISTSERV.MEDUNIWIEN.AC.AT<mailto:***@LISTSERV.MEDUNIWIEN.AC.AT>
Subject: Re: Does an mq trace trap the data payloads that are moving thru the qmgr?

I think that's *most* of the persistent data. At MQTC Mark Taylor gave the MQ Internals session and said that the Put To Waiting Getter optimization permits certain persistent messages that are PUT outside of syncpoint to bypass the log. So for purposes of an audit you either need to use API-level tracing or else be able to prove to the auditor that your programs do everything inside of syncpoint and therefore the dmpmqlog output is complete.

Trying to find a single or very few messages that appear to have been processed but for which there is no log entry could REALLY screw up your day, your audit, your relationship with upper management, etc.

(Do not confuse this with the restaurant management API that can recall service staff from the golf course on their day off when there's a sudden surge in business. That is the "Get To Putting Waiter" API call and is completely different.)

Kind regards,
-- T.Rob

T.Robert Wyatt, Managing partner
IoPT Consulting, LLC
+1 704-443-TROB (8762) Voice/Text
[phone] Voice
https://ioptconsulting.com<https://ioptconsulting.com/>
https://twitter.com/tdotrob

From: MQSeries List [mailto:***@LISTSERV.MEDUNIWIEN.AC.AT] On Behalf Of Andrew Hickson
Sent: Wednesday, October 08, 2014 4:52 AM
To: ***@LISTSERV.MEDUNIWIEN.AC.AT<mailto:***@LISTSERV.MEDUNIWIEN.AC.AT>
Subject: Re: Does an mq trace trap the data payloads that are moving thru the qmgr?

If you're using linear logging then all of the message data (control information + payload) for persistent messages is recorded in the recovery log, and can be post processed with the dmpmqlog utility.
If you're using circular logging then you've effectively got a wrap around history of the last X bytes of persistent data, however getting to all of that data (e.g. dmpmqlog) is much more difficult and typically requires the help of MQ L3.
The main advantage of using the recovery log for this purpose is that there's no performance overhead.
The main disadvantage of using the recovery log for this purpose is that the information isn't in a form that's very easy to process/consume.





From: "T.Rob" <***@IOPTCONSULTING.COM<mailto:***@IOPTCONSULTING.COM>>
To: ***@LISTSERV.MEDUNIWIEN.AC.AT<mailto:***@LISTSERV.MEDUNIWIEN.AC.AT>,
Date: 08/10/2014 09:41
Subject: Re: Does an mq trace trap the data payloads that are moving thru the qmgr?
Sent by: MQSeries List <***@LISTSERV.MEDUNIWIEN.AC.AT<mailto:***@LISTSERV.MEDUNIWIEN.AC.AT>>
________________________________




If you use the MA0W trace exit I believe that you can specify capturing just
the headers. I do recall though a conversation with Ralph Bateman about how
Support often receives traces and FDC files in PMRs that are filled with
PII, medical data, SSN's, card numbers, etc. So I believe the answer is
"yes." That said, the WMQ native trace can get real big, real fast so you
may want to look at MA0W which traces only API calls and not internals, SSL,
comms, etc.

http://ibm.co/SupptPacMA0W


Kind regards,
-- T.Rob


> -----Original Message-----
> From: MQSeries List [mailto:***@LISTSERV.MEDUNIWIEN.AC.AT] On Behalf
> Of Costa, D. (Damian)
> Sent: Wednesday, October 08, 2014 4:00 AM
> To: ***@LISTSERV.MEDUNIWIEN.AC.AT<mailto:***@LISTSERV.MEDUNIWIEN.AC.AT>
> Subject: Does an mq trace trap the data payloads that are moving thru the
> qmgr?
>
> HI all,
> I Was just asked to supply the audit traces of all messages going through
> a particular queue on a test qmgr. Naturally I can't just do that as no
> audit logs exist. So I was wondering if I could fudge it by running an mq
> trace to trap the message payloads being processed off said queue.
> Izzat even possible?
>
> ********************
> Nedbank Limited Reg No 1951/000009/06. The following link displays the
> names of the Nedbank Board of Directors and Company Secretary.
> [ http://www.nedbank.co.za/terms/DirectorsNedbank.htm ] This email is
> confidential and is intended for the addressee only.
> The following link will take you to Nedbank's legal notice.
> [ http://www.nedbank.co.za/terms/EmailDisclaimer.htm ]
> ********************
>
> To unsubscribe, write to ***@LISTSERV.MEDUNIWIEN.AC.AT<mailto:***@LISTSERV.MEDUNIWIEN.AC.AT> and, in the
> message body (not the subject), write: SIGNOFF MQSERIES Instructions for
> managing your mailing list subscription are provided in the Listserv
> General Users Guide available at http://www.lsoft.com<http://www.lsoft.com/>
> Archive: http://listserv.meduniwien.ac.at/archives/mqser-l.html

To unsubscribe, write to ***@LISTSERV.MEDUNIWIEN.AC.AT<mailto:***@LISTSERV.MEDUNIWIEN.AC.AT> and,
in the message body (not the subject), write: SIGNOFF MQSERIES
Instructions for managing your mailing list subscription are provided in
the Listserv General Users Guide available at http://www.lsoft.com<http://www.lsoft.com/>
Archive: http://listserv.meduniwien.ac.at/archives/mqser-l.html



Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number 741598.
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU
________________________________

List Archive<http://listserv.meduniwien.ac.at/archives/mqser-l.html> - Manage Your List Settings<http://listserv.meduniwien.ac.at/cgi-bin/wa?SUBED1=mqser-l&A=1> - Unsubscribe<mailto:***@LISTSERV.MEDUNIWIEN.AC.AT?subject=Unsubscribe&BODY=signoff%20mqseries>

Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com<http://www.lsoft.com/resources/manuals.asp>


________________________________

List Archive<http://listserv.meduniwien.ac.at/archives/mqser-l.html> - Manage Your List Settings<http://listserv.meduniwien.ac.at/cgi-bin/wa?SUBED1=mqser-l&A=1> - Unsubscribe<mailto:***@LISTSERV.MEDUNIWIEN.AC.AT?subject=Unsubscribe&BODY=signoff%20mqseries>

Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com<http://www.lsoft.com/resources/manuals.asp>


________________________________

List Archive<http://listserv.meduniwien.ac.at/archives/mqser-l.html> - Manage Your List Settings<http://listserv.meduniwien.ac.at/cgi-bin/wa?SUBED1=mqser-l&A=1> - Unsubscribe<mailto:***@LISTSERV.MEDUNIWIEN.AC.AT?subject=Unsubscribe&BODY=signoff%20mqseries>

Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com<http://www.lsoft.com/resources/manuals.asp>

********************
Nedbank Limited Reg No 1951/000009/06. The following link displays
the names of the Nedbank Board of Directors and Company Secretary.
[ http://www.nedbank.co.za/terms/DirectorsNedbank.htm ]
This email is confidential and is intended for the addressee only.
The following link will take you to Nedbank's legal notice.
[ http://www.nedbank.co.za/terms/EmailDisclaimer.htm ]
********************


________________________________

List Archive<http://listserv.meduniwien.ac.at/archives/mqser-l.html> - Manage Your List Settings<http://listserv.meduniwien.ac.at/cgi-bin/wa?SUBED1=mqser-l&A=1> - Unsubscribe<mailto:***@LISTSERV.MEDUNIWIEN.AC.AT?subject=Unsubscribe&BODY=signoff%20mqseries>

Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com<http://www.lsoft.com/resources/manuals.asp>



________________________________
List Archive<http://listserv.meduniwien.ac.at/archives/mqser-l.html> - Manage Your List Settings<http://listserv.meduniwien.ac.at/cgi-bin/wa?SUBED1=mqser-l&A=1> - Unsubscribe<mailto:***@LISTSERV.MEDUNIWIEN.AC.AT?subject=Unsubscribe&BODY=signoff%20mqseries>

Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com<http://www.lsoft.com/resources/manuals.asp>

________________________________
List Archive<http://listserv.meduniwien.ac.at/archives/mqser-l.html> - Manage Your List Settings<http://listserv.meduniwien.ac.at/cgi-bin/wa?SUBED1=mqser-l&A=1> - Unsubscribe<mailto:***@LISTSERV.MEDUNIWIEN.AC.AT?subject=Unsubscribe&BODY=signoff%20mqseries>

Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com<http://www.lsoft.com/resources/manuals.asp>

********************
Nedbank Limited Reg No 1951/000009/06. The following link displays
the names of the Nedbank Board of Directors and Company Secretary.
[ http://www.nedbank.co.za/terms/DirectorsNedbank.htm ]
This email is confidential and is intended for the addressee only.
The following link will take you to Nedbank's legal notice.
[ http://www.nedbank.co.za/terms/EmailDisclaimer.htm ]
********************

________________________________
List Archive<http://listserv.meduniwien.ac.at/archives/mqser-l.html> - Manage Your List Settings<http://listserv.meduniwien.ac.at/cgi-bin/wa?SUBED1=mqser-l&A=1> - Unsubscribe<mailto:***@LISTSERV.MEDUNIWIEN.AC.AT?subject=Unsubscribe&BODY=signoff%20mqseries>

Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com<http://www.lsoft.com/resources/manuals.asp>

To unsubscribe, write to ***@LISTSERV.MEDUNIWIEN.AC.AT and,
in the message body (not the subject), write: SIGNOFF MQSERIES
Instructions for managing your mailing list subscription are provided in
the Listserv General Users Guide available at http://www.lsoft.com
Archive: http://listserv.meduniwien.ac.at/archives/mqser-l.html

[Andrew Hickson]

When you get down to the nitty gritty there are lots of edge cases that
might push you one way or another, for example not all message
'consumption' might be visible to a API trace or an activity trace, for
example expiry and purge are two cases that spring to mind.
Similarly it might be a little difficult to see in an API trace, or an
activity trace, what subscribers a publish matched and who received the
message.
Also, when an application terminates abruptly, how does the API or
activity trace know if the message was put/committed or not.

There are pros and cons to each approach, however the recovery log is
pretty much the final arbiter in what persistent messages were put and
got.



From: Tim Zielke <***@AON.COM>
To: ***@LISTSERV.MEDUNIWIEN.AC.AT,
Date: 08/10/2014 16:58
Subject: Re: Does an mq trace trap the data payloads that are
moving thru the qmgr?
Sent by: MQSeries List <***@LISTSERV.MEDUNIWIEN.AC.AT>



The added benefit of going the Activity Trace route is not only would you
get the message (header and body) like you would with the pub/sub
“mirrorq” approach, but you would also be able to see the behavior of the
putter and getter applications (i.e. what get/put options they are using,
etc.), which could be beneficial in getting to the root cause of the
issue.


From: MQSeries List [mailto:***@LISTSERV.MEDUNIWIEN.AC.AT] On Behalf
Of Costa, D. (Damian)
Sent: Wednesday, October 08, 2014 10:37 AM
To: ***@LISTSERV.MEDUNIWIEN.AC.AT
Subject: Re: Does an mq trace trap the data payloads that are moving thru
the qmgr?

Great idea re the topic queue. Will go setup and see what is happening.


From: MQSeries List [mailto:***@LISTSERV.MEDUNIWIEN.AC.AT] On Behalf
Of Jefferson Lowrey
Sent: 08 October 2014 03:52 PM
To: ***@LISTSERV.MEDUNIWIEN.AC.AT
Subject: Re: Does an mq trace trap the data payloads that are moving thru
the qmgr?

The other thing you can do is (mis) use pub/sub and reroute messages that
are supposed to go to the application input queue to a topic instead, and
then create two admin subscriptions - one to the original input queue and
one to a different queue - something that just gets dumped to a text file
(perhaps by qload or etc.)

This is the basic replacement for mirrorq as of v7's pub/sub function. If,
somehow, you're still at <v7, you can test your googlefu by trying to find
some copy of the mirrorq source code to compile.

Thank you,

Jeff Lowrey




From: Tim Zielke <***@AON.COM>
To: ***@LISTSERV.MEDUNIWIEN.AC.AT
Date: 10/08/2014 08:01 AM
Subject: Re: [MQSERIES] Does an mq trace trap the data payloads
that are moving thru the qmgr?
Sent by: MQSeries List <***@LISTSERV.MEDUNIWIEN.AC.AT>




If this is more something temporary to help debug an issue, then I would
go with the Activity Trace (if you are at >= 7.1) over standard tracing
(i.e. strmqtrc).

For viewing the AAT data, there are significant enhancements to the
amqsact program (called amqsactz) that I find helpful ->
http://www.capitalware.com/mq_code_c.html

You do need a C compiler to build it for your platform, but I provide some
examples in the comments of the program on how to do this on Windows or
Linux. The MQ manual, of course, covers all environments for building an
MQ program written in C.

Thanks,
Tim

From: MQSeries List [mailto:***@LISTSERV.MEDUNIWIEN.AC.AT] On Behalf
Of Costa, D. (Damian)
Sent: Wednesday, October 08, 2014 7:45 AM
To: ***@LISTSERV.MEDUNIWIEN.AC.AT
Subject: Re: Does an mq trace trap the data payloads that are moving thru
the qmgr?

Swat I tole ‘em
.. improve their logging from their apps.
What is disappointing is that they cannot tell what their app is doing
with the message. The MQ stats indicate they are taking them off the
queue.
Heaven only know where they go from there.

From: MQSeries List [mailto:***@LISTSERV.MEDUNIWIEN.AC.AT] On Behalf
Of Tim Zielke
Sent: 08 October 2014 02:07 PM
To: ***@LISTSERV.MEDUNIWIEN.AC.AT
Subject: Re: Does an mq trace trap the data payloads that are moving thru
the qmgr?

Hi Damian,

If your queue manager is 7.1 or higher, another option is the Application
Activity Trace.

This IBM article on the AAT ->
http://www.ibm.com/developerworks/websphere/library/techarticles/1306_bushby/1306_bushby.html


does give the scenario of “Using Application Activity Trace to keep an
audit trail of messages” as one of the AAT’s uses.

Personally, I would be hesitant to do what you are being asked to do, and
would like to understand from the application team why their application
can not do this logging, itself. Do they really need the entire message,
or is it really key pieces of data that they could put into an application
log.

Thanks,
Tim

From: MQSeries List [mailto:***@LISTSERV.MEDUNIWIEN.AC.AT] On Behalf
Of T.Rob
Sent: Wednesday, October 08, 2014 4:17 AM
To: ***@LISTSERV.MEDUNIWIEN.AC.AT
Subject: Re: Does an mq trace trap the data payloads that are moving thru
the qmgr?

I think that's *most* of the persistent data. At MQTC Mark Taylor gave
the MQ Internals session and said that the Put To Waiting Getter
optimization permits certain persistent messages that are PUT outside of
syncpoint to bypass the log. So for purposes of an audit you either need
to use API-level tracing or else be able to prove to the auditor that your
programs do everything inside of syncpoint and therefore the dmpmqlog
output is complete.

Trying to find a single or very few messages that appear to have been
processed but for which there is no log entry could REALLY screw up your
day, your audit, your relationship with upper management, etc.

(Do not confuse this with the restaurant management API that can recall
service staff from the golf course on their day off when there's a sudden
surge in business. That is the "Get To Putting Waiter" API call and is
completely different.)

Kind regards,
-- T.Rob

T.Robert Wyatt, Managing partner
IoPT Consulting, LLC
+1 704-443-TROB (8762) Voice/Text
[phone] Voice
https://ioptconsulting.com
https://twitter.com/tdotrob

From: MQSeries List [mailto:***@LISTSERV.MEDUNIWIEN.AC.AT] On Behalf
Of Andrew Hickson
Sent: Wednesday, October 08, 2014 4:52 AM
To: ***@LISTSERV.MEDUNIWIEN.AC.AT
Subject: Re: Does an mq trace trap the data payloads that are moving thru
the qmgr?

If you're using linear logging then all of the message data (control
information + payload) for persistent messages is recorded in the recovery
log, and can be post processed with the dmpmqlog utility.
If you're using circular logging then you've effectively got a wrap around
history of the last X bytes of persistent data, however getting to all of
that data (e.g. dmpmqlog) is much more difficult and typically requires
the help of MQ L3.
The main advantage of using the recovery log for this purpose is that
there's no performance overhead.
The main disadvantage of using the recovery log for this purpose is that
the information isn't in a form that's very easy to process/consume.





From: "T.Rob" <***@IOPTCONSULTING.COM>
To: ***@LISTSERV.MEDUNIWIEN.AC.AT,
Date: 08/10/2014 09:41
Subject: Re: Does an mq trace trap the data payloads that are
moving thru the qmgr?
Sent by: MQSeries List <***@LISTSERV.MEDUNIWIEN.AC.AT>





If you use the MA0W trace exit I believe that you can specify capturing
just
the headers. I do recall though a conversation with Ralph Bateman about
how
Support often receives traces and FDC files in PMRs that are filled with
PII, medical data, SSN's, card numbers, etc. So I believe the answer is
"yes." That said, the WMQ native trace can get real big, real fast so you
may want to look at MA0W which traces only API calls and not internals,
SSL,
comms, etc.

http://ibm.co/SupptPacMA0W


Kind regards,
-- T.Rob


> -----Original Message-----
> From: MQSeries List [mailto:***@LISTSERV.MEDUNIWIEN.AC.AT] On
Behalf
> Of Costa, D. (Damian)
> Sent: Wednesday, October 08, 2014 4:00 AM
> To: ***@LISTSERV.MEDUNIWIEN.AC.AT
> Subject: Does an mq trace trap the data payloads that are moving thru
the
> qmgr?
>
> HI all,
> I Was just asked to supply the audit traces of all messages going
through
> a particular queue on a test qmgr. Naturally I can't just do that as no
> audit logs exist. So I was wondering if I could fudge it by running an
mq
> trace to trap the message payloads being processed off said queue.
> Izzat even possible?
>
> ********************
> Nedbank Limited Reg No 1951/000009/06. The following link displays the
> names of the Nedbank Board of Directors and Company Secretary.
> [ http://www.nedbank.co.za/terms/DirectorsNedbank.htm ] This email is
> confidential and is intended for the addressee only.
> The following link will take you to Nedbank's legal notice.
> [ http://www.nedbank.co.za/terms/EmailDisclaimer.htm ]
> ********************
>
> To unsubscribe, write to ***@LISTSERV.MEDUNIWIEN.AC.AT and, in the
> message body (not the subject), write: SIGNOFF MQSERIES Instructions for
> managing your mailing list subscription are provided in the Listserv
> General Users Guide available at http://www.lsoft.com
> Archive: http://listserv.meduniwien.ac.at/archives/mqser-l.html

To unsubscribe, write to ***@LISTSERV.MEDUNIWIEN.AC.AT and,
in the message body (not the subject), write: SIGNOFF MQSERIES
Instructions for managing your mailing list subscription are provided in
the Listserv General Users Guide available at http://www.lsoft.com
Archive: http://listserv.meduniwien.ac.at/archives/mqser-l.html



Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number
741598.
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU



List Archive - Manage Your List Settings - Unsubscribe
Instructions for managing your mailing list subscription are provided in
the Listserv General Users Guide available at http://www.lsoft.com




List Archive - Manage Your List Settings - Unsubscribe
Instructions for managing your mailing list subscription are provided in
the Listserv General Users Guide available at http://www.lsoft.com




List Archive - Manage Your List Settings - Unsubscribe
Instructions for managing your mailing list subscription are provided in
the Listserv General Users Guide available at http://www.lsoft.com

********************
Nedbank Limited Reg No 1951/000009/06. The following link displays
the names of the Nedbank Board of Directors and Company Secretary.
[ http://www.nedbank.co.za/terms/DirectorsNedbank.htm ]
This email is confidential and is intended for the addressee only.
The following link will take you to Nedbank's legal notice.
[ http://www.nedbank.co.za/terms/EmailDisclaimer.htm ]
********************



List Archive - Manage Your List Settings - Unsubscribe
Instructions for managing your mailing list subscription are provided in
the Listserv General Users Guide available at http://www.lsoft.com


List Archive - Manage Your List Settings - Unsubscribe
Instructions for managing your mailing list subscription are provided in
the Listserv General Users Guide available at http://www.lsoft.com


List Archive - Manage Your List Settings - Unsubscribe
Instructions for managing your mailing list subscription are provided in
the Listserv General Users Guide available at http://www.lsoft.com

********************
Nedbank Limited Reg No 1951/000009/06. The following link displays
the names of the Nedbank Board of Directors and Company Secretary.
[ http://www.nedbank.co.za/terms/DirectorsNedbank.htm ]
This email is confidential and is intended for the addressee only.
The following link will take you to Nedbank's legal notice.
[ http://www.nedbank.co.za/terms/EmailDisclaimer.htm ]
********************


List Archive - Manage Your List Settings - Unsubscribe
Instructions for managing your mailing list subscription are provided in
the Listserv General Users Guide available at http://www.lsoft.com


List Archive - Manage Your List Settings - Unsubscribe
Instructions for managing your mailing list subscription are provided in
the Listserv General Users Guide available at http://www.lsoft.com

Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number
741598.
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU


To unsubscribe, write to ***@LISTSERV.MEDUNIWIEN.AC.AT and,
in the message body (not the subject), write: SIGNOFF MQSERIES
Instructions for managing your mailing list subscription are provided in
the Listserv General Users Guide available at http://www.lsoft.com
Archive: http://listserv.meduniwien.ac.at/archives/mqser-l.html

[Neil Casey]

Hi Damian,

I agree that using a queue alias to a topic and then administrative subscriptions to copy the messages to 2 queues is a great capability.

But remember that it will change the message id, so if your application relies on message id (for example, to copy to correlation Id of the response) copying it this way will break the application. :-(

We’ve had discussions on the list about this before, and there is at least one RFE asking for the ability to keep the message id identical.
http://www.ibm.com/developerworks/rfe/execute?use_case=viewRfe&CR_ID=35062

Regards,

Neil Casey.


On 9 Oct 2014, at 2:37 am, Costa, D. (Damian) <DamianC-3zJjxGF14/***@public.gmane.org> wrote:

> Great idea re the topic queue. Will go setup and see what is happening.
>
>
> From: MQSeries List [mailto:MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org] On Behalf Of Jefferson Lowrey
> Sent: 08 October 2014 03:52 PM
> To: MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org
> Subject: Re: Does an mq trace trap the data payloads that are moving thru the qmgr?
>
> The other thing you can do is (mis) use pub/sub and reroute messages that are supposed to go to the application input queue to a topic instead, and then create two admin subscriptions - one to the original input queue and one to a different queue - something that just gets dumped to a text file (perhaps by qload or etc.)
>
> This is the basic replacement for mirrorq as of v7's pub/sub function. If, somehow, you're still at <v7, you can test your googlefu by trying to find some copy of the mirrorq source code to compile.
>
> Thank you,
>
> Jeff Lowrey
>
>
>
>
> From: Tim Zielke <tim.zielke-PR+tvw7B/***@public.gmane.org>
> To: MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org
> Date: 10/08/2014 08:01 AM
> Subject: Re: [MQSERIES] Does an mq trace trap the data payloads that are moving thru the qmgr?
> Sent by: MQSeries List <MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org>
>
>
>
> If this is more something temporary to help debug an issue, then I would go with the Activity Trace (if you are at >= 7.1) over standard tracing (i.e. strmqtrc).
>
> For viewing the AAT data, there are significant enhancements to the amqsact program (called amqsactz) that I find helpful -> http://www.capitalware.com/mq_code_c.html
>
> You do need a C compiler to build it for your platform, but I provide some examples in the comments of the program on how to do this on Windows or Linux. The MQ manual, of course, covers all environments for building an MQ program written in C.
>
> Thanks,
> Tim
>
> From: MQSeries List [mailto:MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org] On Behalf Of Costa, D. (Damian)
> Sent: Wednesday, October 08, 2014 7:45 AM
> To: MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org
> Subject: Re: Does an mq trace trap the data payloads that are moving thru the qmgr?
>
> Swat I tole ‘em….. improve their logging from their apps.
> What is disappointing is that they cannot tell what their app is doing with the message. The MQ stats indicate they are taking them off the queue.
> Heaven only know where they go from there.
>
> From: MQSeries List [mailto:MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org] On Behalf Of Tim Zielke
> Sent: 08 October 2014 02:07 PM
> To: MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org
> Subject: Re: Does an mq trace trap the data payloads that are moving thru the qmgr?
>
> Hi Damian,
>
> If your queue manager is 7.1 or higher, another option is the Application Activity Trace.
>
> This IBM article on the AAT -> http://www.ibm.com/developerworks/websphere/library/techarticles/1306_bushby/1306_bushby.html
>
> does give the scenario of “Using Application Activity Trace to keep an audit trail of messages” as one of the AAT’s uses.
>
> Personally, I would be hesitant to do what you are being asked to do, and would like to understand from the application team why their application can not do this logging, itself. Do they really need the entire message, or is it really key pieces of data that they could put into an application log.
>
> Thanks,
> Tim
>
> From: MQSeries List [mailto:MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org] On Behalf Of T.Rob
> Sent: Wednesday, October 08, 2014 4:17 AM
> To: MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org
> Subject: Re: Does an mq trace trap the data payloads that are moving thru the qmgr?
>
> I think that's *most* of the persistent data. At MQTC Mark Taylor gave the MQ Internals session and said that the Put To Waiting Getter optimization permits certain persistent messages that are PUT outside of syncpoint to bypass the log. So for purposes of an audit you either need to use API-level tracing or else be able to prove to the auditor that your programs do everything inside of syncpoint and therefore the dmpmqlog output is complete.
>
> Trying to find a single or very few messages that appear to have been processed but for which there is no log entry could REALLY screw up your day, your audit, your relationship with upper management, etc.
>
> (Do not confuse this with the restaurant management API that can recall service staff from the golf course on their day off when there's a sudden surge in business. That is the "Get To Putting Waiter" API call and is completely different.)
>
> Kind regards,
> -- T.Rob
>
> T.Robert Wyatt, Managing partner
> IoPT Consulting, LLC
> +1 704-443-TROB (8762) Voice/Text
> [phone] Voice
> https://ioptconsulting.com
> https://twitter.com/tdotrob
>
> From: MQSeries List [mailto:MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org] On Behalf Of Andrew Hickson
> Sent: Wednesday, October 08, 2014 4:52 AM
> To: MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org
> Subject: Re: Does an mq trace trap the data payloads that are moving thru the qmgr?
>
> If you're using linear logging then all of the message data (control information + payload) for persistent messages is recorded in the recovery log, and can be post processed with the dmpmqlog utility.
> If you're using circular logging then you've effectively got a wrap around history of the last X bytes of persistent data, however getting to all of that data (e.g. dmpmqlog) is much more difficult and typically requires the help of MQ L3.
> The main advantage of using the recovery log for this purpose is that there's no performance overhead.
> The main disadvantage of using the recovery log for this purpose is that the information isn't in a form that's very easy to process/consume.
>
>
>
>
>
> From: "T.Rob" <t.rob-CkT6zf+urXSzW/GOMZKyElesiRL1/***@public.gmane.org>
> To: MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org,
> Date: 08/10/2014 09:41
> Subject: Re: Does an mq trace trap the data payloads that are moving thru the qmgr?
> Sent by: MQSeries List <MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org>
>
>
>
>
> If you use the MA0W trace exit I believe that you can specify capturing just
> the headers. I do recall though a conversation with Ralph Bateman about how
> Support often receives traces and FDC files in PMRs that are filled with
> PII, medical data, SSN's, card numbers, etc. So I believe the answer is
> "yes." That said, the WMQ native trace can get real big, real fast so you
> may want to look at MA0W which traces only API calls and not internals, SSL,
> comms, etc.
>
> http://ibm.co/SupptPacMA0W
>
>
> Kind regards,
> -- T.Rob
>
>
> > -----Original Message-----
> > From: MQSeries List [mailto:MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org] On Behalf
> > Of Costa, D. (Damian)
> > Sent: Wednesday, October 08, 2014 4:00 AM
> > To: MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org
> > Subject: Does an mq trace trap the data payloads that are moving thru the
> > qmgr?
> >
> > HI all,
> > I Was just asked to supply the audit traces of all messages going through
> > a particular queue on a test qmgr. Naturally I can't just do that as no
> > audit logs exist. So I was wondering if I could fudge it by running an mq
> > trace to trap the message payloads being processed off said queue.
> > Izzat even possible?
> >
> > ********************
> > Nedbank Limited Reg No 1951/000009/06. The following link displays the
> > names of the Nedbank Board of Directors and Company Secretary.
> > [ http://www.nedbank.co.za/terms/DirectorsNedbank.htm ] This email is
> > confidential and is intended for the addressee only.
> > The following link will take you to Nedbank's legal notice.
> > [ http://www.nedbank.co.za/terms/EmailDisclaimer.htm ]
> > ********************
> >
> > To unsubscribe, write to LISTSERV-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org and, in the
> > message body (not the subject), write: SIGNOFF MQSERIES Instructions for
> > managing your mailing list subscription are provided in the Listserv
> > General Users Guide available at http://www.lsoft.com
> > Archive: http://listserv.meduniwien.ac.at/archives/mqser-l.html
>
> To unsubscribe, write to LISTSERV-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org and,
> in the message body (not the subject), write: SIGNOFF MQSERIES
> Instructions for managing your mailing list subscription are provided in
> the Listserv General Users Guide available at http://www.lsoft.com
> Archive: http://listserv.meduniwien.ac.at/archives/mqser-l.html
>
>
>
> Unless stated otherwise above:
> IBM United Kingdom Limited - Registered in England and Wales with number 741598.
> Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU
>
> List Archive - Manage Your List Settings - Unsubscribe
> Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com
>
>
>
>
> List Archive - Manage Your List Settings - Unsubscribe
> Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com
>
>
>
>
> List Archive - Manage Your List Settings - Unsubscribe
> Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com
>
>
> ********************
> Nedbank Limited Reg No 1951/000009/06. The following link displays
> the names of the Nedbank Board of Directors and Company Secretary.
> [ http://www.nedbank.co.za/terms/DirectorsNedbank.htm ]
> This email is confidential and is intended for the addressee only.
> The following link will take you to Nedbank's legal notice.
> [ http://www.nedbank.co.za/terms/EmailDisclaimer.htm ]
> ********************
>
>
>
> List Archive - Manage Your List Settings - Unsubscribe
> Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com
>
>
>
> List Archive - Manage Your List Settings - Unsubscribe
> Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com
>
>
> List Archive - Manage Your List Settings - Unsubscribe
> Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com
>
>
> ********************
> Nedbank Limited Reg No 1951/000009/06. The following link displays
> the names of the Nedbank Board of Directors and Company Secretary.
> [ http://www.nedbank.co.za/terms/DirectorsNedbank.htm ]
> This email is confidential and is intended for the addressee only.
> The following link will take you to Nedbank's legal notice.
> [ http://www.nedbank.co.za/terms/EmailDisclaimer.htm ]
> ********************
>
>
> List Archive - Manage Your List Settings - Unsubscribe
> Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com
>


To unsubscribe, write to LISTSERV-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org and,
in the message body (not the subject), write: SIGNOFF MQSERIES
Instructions for managing your mailing list subscription are provided in
the Listserv General Users Guide available at http://www.lsoft.com
Archive: http://listserv.meduniwien.ac.at/archives/mqser-l.html

[Costa, D. (Damian)]

Aw crud! Oh well a twisted the dev's arm enough so they are adding additional logging logic to their app as we speak.
Worst comes to worst I will stop the channel back and trap the message on the xmitq queue on the responders side.


From: MQSeries List [mailto:MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org] On Behalf Of Neil Casey
Sent: 08 October 2014 11:45 PM
To: MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org
Subject: Re: Does an mq trace trap the data payloads that are moving thru the qmgr?

Hi Damian,

I agree that using a queue alias to a topic and then administrative subscriptions to copy the messages to 2 queues is a great capability.

But remember that it will change the message id, so if your application relies on message id (for example, to copy to correlation Id of the response) copying it this way will break the application. :-(

We've had discussions on the list about this before, and there is at least one RFE asking for the ability to keep the message id identical.
http://www.ibm.com/developerworks/rfe/execute?use_case=viewRfe&CR_ID=35062

Regards,

Neil Casey.


On 9 Oct 2014, at 2:37 am, Costa, D. (Damian) <DamianC-3zJjxGF14/***@public.gmane.org<mailto:DamianC-3zJjxGF14/***@public.gmane.org>> wrote:


Great idea re the topic queue. Will go setup and see what is happening.


From: MQSeries List [mailto:MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org] On Behalf Of Jefferson Lowrey
Sent: 08 October 2014 03:52 PM
To: MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org<mailto:MQSERIES-0lvw86wZMd9k/***@public.gmane.orgAC.AT>
Subject: Re: Does an mq trace trap the data payloads that are moving thru the qmgr?

The other thing you can do is (mis) use pub/sub and reroute messages that are supposed to go to the application input queue to a topic instead, and then create two admin subscriptions - one to the original input queue and one to a different queue - something that just gets dumped to a text file (perhaps by qload or etc.)

This is the basic replacement for mirrorq as of v7's pub/sub function. If, somehow, you're still at <v7, you can test your googlefu by trying to find some copy of the mirrorq source code to compile.

Thank you,

Jeff Lowrey




From: Tim Zielke <tim.zielke-PR+tvw7B/***@public.gmane.org<mailto:tim.zielke-PR+tvw7B/***@public.gmane.org>>
To: MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org<mailto:MQSERIES-0lvw86wZMd8hNtF/***@public.gmane.orgNIWIEN.AC.AT>
Date: 10/08/2014 08:01 AM
Subject: Re: [MQSERIES] Does an mq trace trap the data payloads that are moving thru the qmgr?
Sent by: MQSeries List <MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org<mailto:MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org>>
________________________________



If this is more something temporary to help debug an issue, then I would go with the Activity Trace (if you are at >= 7.1) over standard tracing (i.e. strmqtrc).

For viewing the AAT data, there are significant enhancements to the amqsact program (called amqsactz) that I find helpful -> http://www.capitalware.com/mq_code_c.html

You do need a C compiler to build it for your platform, but I provide some examples in the comments of the program on how to do this on Windows or Linux. The MQ manual, of course, covers all environments for building an MQ program written in C.

Thanks,
Tim

From: MQSeries List [mailto:MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org] On Behalf Of Costa, D. (Damian)
Sent: Wednesday, October 08, 2014 7:45 AM
To: MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org<mailto:MQSERIES-0lvw86wZMd9k/***@public.gmane.orgAC.AT>
Subject: Re: Does an mq trace trap the data payloads that are moving thru the qmgr?

Swat I tole 'em..... improve their logging from their apps.
What is disappointing is that they cannot tell what their app is doing with the message. The MQ stats indicate they are taking them off the queue.
Heaven only know where they go from there.

From: MQSeries List [mailto:MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org] On Behalf Of Tim Zielke
Sent: 08 October 2014 02:07 PM
To: MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org<mailto:MQSERIES-0lvw86wZMd9k/***@public.gmane.orgAC.AT>
Subject: Re: Does an mq trace trap the data payloads that are moving thru the qmgr?

Hi Damian,

If your queue manager is 7.1 or higher, another option is the Application Activity Trace.

This IBM article on the AAT -> http://www.ibm.com/developerworks/websphere/library/techarticles/1306_bushby/1306_bushby.html

does give the scenario of "Using Application Activity Trace to keep an audit trail of messages" as one of the AAT's uses.

Personally, I would be hesitant to do what you are being asked to do, and would like to understand from the application team why their application can not do this logging, itself. Do they really need the entire message, or is it really key pieces of data that they could put into an application log.

Thanks,
Tim

From: MQSeries List [mailto:MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org] On Behalf Of T.Rob
Sent: Wednesday, October 08, 2014 4:17 AM
To: MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org<mailto:MQSERIES-0lvw86wZMd9k/***@public.gmane.orgAC.AT>
Subject: Re: Does an mq trace trap the data payloads that are moving thru the qmgr?

I think that's *most* of the persistent data. At MQTC Mark Taylor gave the MQ Internals session and said that the Put To Waiting Getter optimization permits certain persistent messages that are PUT outside of syncpoint to bypass the log. So for purposes of an audit you either need to use API-level tracing or else be able to prove to the auditor that your programs do everything inside of syncpoint and therefore the dmpmqlog output is complete.

Trying to find a single or very few messages that appear to have been processed but for which there is no log entry could REALLY screw up your day, your audit, your relationship with upper management, etc.

(Do not confuse this with the restaurant management API that can recall service staff from the golf course on their day off when there's a sudden surge in business. That is the "Get To Putting Waiter" API call and is completely different.)

Kind regards,
-- T.Rob

T.Robert Wyatt, Managing partner
IoPT Consulting, LLC
+1 704-443-TROB (8762) Voice/Text
[phone] Voice
https://ioptconsulting.com<https://ioptconsulting.com/>
https://twitter.com/tdotrob

From: MQSeries List [mailto:MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org] On Behalf Of Andrew Hickson
Sent: Wednesday, October 08, 2014 4:52 AM
To: MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org<mailto:MQSERIES-0lvw86wZMd9k/***@public.gmane.orgAC.AT>
Subject: Re: Does an mq trace trap the data payloads that are moving thru the qmgr?

If you're using linear logging then all of the message data (control information + payload) for persistent messages is recorded in the recovery log, and can be post processed with the dmpmqlog utility.
If you're using circular logging then you've effectively got a wrap around history of the last X bytes of persistent data, however getting to all of that data (e.g. dmpmqlog) is much more difficult and typically requires the help of MQ L3.
The main advantage of using the recovery log for this purpose is that there's no performance overhead.
The main disadvantage of using the recovery log for this purpose is that the information isn't in a form that's very easy to process/consume.





From: "T.Rob" <t.rob-CkT6zf+urXSzW/GOMZKyElesiRL1/***@public.gmane.org<mailto:***@IOPTCONSULTING.COM>>
To: MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org<mailto:MQSERIES-0lvw86wZMd8hNtF/***@public.gmane.orgNIWIEN.AC.AT>,
Date: 08/10/2014 09:41
Subject: Re: Does an mq trace trap the data payloads that are moving thru the qmgr?
Sent by: MQSeries List <MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org<mailto:MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org>>
________________________________




If you use the MA0W trace exit I believe that you can specify capturing just
the headers. I do recall though a conversation with Ralph Bateman about how
Support often receives traces and FDC files in PMRs that are filled with
PII, medical data, SSN's, card numbers, etc. So I believe the answer is
"yes." That said, the WMQ native trace can get real big, real fast so you
may want to look at MA0W which traces only API calls and not internals, SSL,
comms, etc.

http://ibm.co/SupptPacMA0W


Kind regards,
-- T.Rob


> -----Original Message-----
> From: MQSeries List [mailto:MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org] On Behalf
> Of Costa, D. (Damian)
> Sent: Wednesday, October 08, 2014 4:00 AM
> To: MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org<mailto:MQSERIES-0lvw86wZMd9k/***@public.gmane.orgN.AC.AT>
> Subject: Does an mq trace trap the data payloads that are moving thru the
> qmgr?
>
> HI all,
> I Was just asked to supply the audit traces of all messages going through
> a particular queue on a test qmgr. Naturally I can't just do that as no
> audit logs exist. So I was wondering if I could fudge it by running an mq
> trace to trap the message payloads being processed off said queue.
> Izzat even possible?
>
> ********************
> Nedbank Limited Reg No 1951/000009/06. The following link displays the
> names of the Nedbank Board of Directors and Company Secretary.
> [ http://www.nedbank.co.za/terms/DirectorsNedbank.htm ] This email is
> confidential and is intended for the addressee only.
> The following link will take you to Nedbank's legal notice.
> [ http://www.nedbank.co.za/terms/EmailDisclaimer.htm ]
> ********************
>
> To unsubscribe, write to LISTSERV-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org<mailto:LISTSERV-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org> and, in the
> message body (not the subject), write: SIGNOFF MQSERIES Instructions for
> managing your mailing list subscription are provided in the Listserv
> General Users Guide available at http://www.lsoft.com<http://www.lsoft.com/>
> Archive: http://listserv.meduniwien.ac.at/archives/mqser-l.html

To unsubscribe, write to LISTSERV-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org<mailto:***@LISTSERV.MEDUNIWIEN.AC.AT> and,
in the message body (not the subject), write: SIGNOFF MQSERIES
Instructions for managing your mailing list subscription are provided in
the Listserv General Users Guide available at http://www.lsoft.com<http://www.lsoft.com/>
Archive: http://listserv.meduniwien.ac.at/archives/mqser-l.html



Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number 741598.
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU
________________________________

List Archive<http://listserv.meduniwien.ac.at/archives/mqser-l.html> - Manage Your List Settings<http://listserv.meduniwien.ac.at/cgi-bin/wa?SUBED1=mqser-l&A=1> - Unsubscribe<mailto:LISTSERV-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org?subject=Unsubscribe&BODY=signoff%20mqseries>

Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com<http://www.lsoft.com/resources/manuals.asp>


________________________________

List Archive<http://listserv.meduniwien.ac.at/archives/mqser-l.html> - Manage Your List Settings<http://listserv.meduniwien.ac.at/cgi-bin/wa?SUBED1=mqser-l&A=1> - Unsubscribe<mailto:LISTSERV-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org?subject=Unsubscribe&BODY=signoff%20mqseries>

Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com<http://www.lsoft.com/resources/manuals.asp>


________________________________

List Archive<http://listserv.meduniwien.ac.at/archives/mqser-l.html> - Manage Your List Settings<http://listserv.meduniwien.ac.at/cgi-bin/wa?SUBED1=mqser-l&A=1> - Unsubscribe<mailto:LISTSERV-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org?subject=Unsubscribe&BODY=signoff%20mqseries>

Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com<http://www.lsoft.com/resources/manuals.asp>

********************
Nedbank Limited Reg No 1951/000009/06. The following link displays
the names of the Nedbank Board of Directors and Company Secretary.
[ http://www.nedbank.co.za/terms/DirectorsNedbank.htm ]
This email is confidential and is intended for the addressee only.
The following link will take you to Nedbank's legal notice.
[ http://www.nedbank.co.za/terms/EmailDisclaimer.htm ]
********************


________________________________

List Archive<http://listserv.meduniwien.ac.at/archives/mqser-l.html> - Manage Your List Settings<http://listserv.meduniwien.ac.at/cgi-bin/wa?SUBED1=mqser-l&A=1> - Unsubscribe<mailto:LISTSERV-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org?subject=Unsubscribe&BODY=signoff%20mqseries>

Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com<http://www.lsoft.com/resources/manuals.asp>



________________________________
List Archive<http://listserv.meduniwien.ac.at/archives/mqser-l.html> - Manage Your List Settings<http://listserv.meduniwien.ac.at/cgi-bin/wa?SUBED1=mqser-l&A=1> - Unsubscribe<mailto:LISTSERV-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org?subject=Unsubscribe&BODY=signoff%20mqseries>

Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com<http://www.lsoft.com/resources/manuals.asp>

________________________________
List Archive<http://listserv.meduniwien.ac.at/archives/mqser-l.html> - Manage Your List Settings<http://listserv.meduniwien.ac.at/cgi-bin/wa?SUBED1=mqser-l&A=1> - Unsubscribe<mailto:LISTSERV-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org?subject=Unsubscribe&BODY=signoff%20mqseries>

Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com<http://www.lsoft.com/resources/manuals.asp>

********************
Nedbank Limited Reg No 1951/000009/06. The following link displays
the names of the Nedbank Board of Directors and Company Secretary.
[ http://www.nedbank.co.za/terms/DirectorsNedbank.htm ]
This email is confidential and is intended for the addressee only.
The following link will take you to Nedbank's legal notice.
[ http://www.nedbank.co.za/terms/EmailDisclaimer.htm ]
********************

________________________________
List Archive<http://listserv.meduniwien.ac.at/archives/mqser-l.html> - Manage Your List Settings<http://listserv.meduniwien.ac.at/cgi-bin/wa?SUBED1=mqser-l&A=1> - Unsubscribe<mailto:LISTSERV-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org?subject=Unsubscribe&BODY=signoff%20mqseries>

Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com<http://www.lsoft.com/resources/manuals.asp>


________________________________
List Archive<http://listserv.meduniwien.ac.at/archives/mqser-l.html> - Manage Your List Settings<http://listserv.meduniwien.ac.at/cgi-bin/wa?SUBED1=mqser-l&A=1> - Unsubscribe<mailto:LISTSERV-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org?subject=Unsubscribe&BODY=signoff%20mqseries>

Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com<http://www.lsoft.com/resources/manuals.asp>

********************
Nedbank Limited Reg No 1951/000009/06. The following link displays
the names of the Nedbank Board of Directors and Company Secretary.
[ http://www.nedbank.co.za/terms/DirectorsNedbank.htm ]
This email is confidential and is intended for the addressee only.
The following link will take you to Nedbank's legal notice.
[ http://www.nedbank.co.za/terms/EmailDisclaimer.htm ]
********************

To unsubscribe, write to LISTSERV-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org and,
in the message body (not the subject), write: SIGNOFF MQSERIES
Instructions for managing your mailing list subscription are provided in
the Listserv General Users Guide available at http://www.lsoft.com
Archive: http://listserv.meduniwien.ac.at/archives/mqser-l.html

[Tim Zielke]

Hi Damian,

Earlier in the thread you had mentioned:

"What is disappointing is that they cannot tell what their app is doing with the message. The MQ stats indicate they are taking them off the queue."

Just curious. Is the app claiming that they never did a GET on the message?


From: MQSeries List [mailto:MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org] On Behalf Of Costa, D. (Damian)
Sent: Thursday, October 09, 2014 3:02 AM
To: MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org
Subject: Re: Does an mq trace trap the data payloads that are moving thru the qmgr?

Aw crud! Oh well a twisted the dev's arm enough so they are adding additional logging logic to their app as we speak.
Worst comes to worst I will stop the channel back and trap the message on the xmitq queue on the responders side.


From: MQSeries List [mailto:MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org] On Behalf Of Neil Casey
Sent: 08 October 2014 11:45 PM
To: MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org<mailto:MQSERIES-0lvw86wZMd9k/***@public.gmane.orgAC.AT>
Subject: Re: Does an mq trace trap the data payloads that are moving thru the qmgr?

Hi Damian,

I agree that using a queue alias to a topic and then administrative subscriptions to copy the messages to 2 queues is a great capability.

But remember that it will change the message id, so if your application relies on message id (for example, to copy to correlation Id of the response) copying it this way will break the application. :-(

We've had discussions on the list about this before, and there is at least one RFE asking for the ability to keep the message id identical.
http://www.ibm.com/developerworks/rfe/execute?use_case=viewRfe&CR_ID=35062

Regards,

Neil Casey.


On 9 Oct 2014, at 2:37 am, Costa, D. (Damian) <DamianC-3zJjxGF14/***@public.gmane.org<mailto:DamianC-3zJjxGF14/***@public.gmane.org>> wrote:

Great idea re the topic queue. Will go setup and see what is happening.


From: MQSeries List [mailto:MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org] On Behalf Of Jefferson Lowrey
Sent: 08 October 2014 03:52 PM
To: MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org<mailto:MQSERIES-0lvw86wZMd9k/***@public.gmane.orgAC.AT>
Subject: Re: Does an mq trace trap the data payloads that are moving thru the qmgr?

The other thing you can do is (mis) use pub/sub and reroute messages that are supposed to go to the application input queue to a topic instead, and then create two admin subscriptions - one to the original input queue and one to a different queue - something that just gets dumped to a text file (perhaps by qload or etc.)

This is the basic replacement for mirrorq as of v7's pub/sub function. If, somehow, you're still at <v7, you can test your googlefu by trying to find some copy of the mirrorq source code to compile.

Thank you,

Jeff Lowrey




From: Tim Zielke <tim.zielke-PR+tvw7B/***@public.gmane.org<mailto:tim.zielke-PR+tvw7B/***@public.gmane.org>>
To: MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org<mailto:MQSERIES-0lvw86wZMd8hNtF/***@public.gmane.orgNIWIEN.AC.AT>
Date: 10/08/2014 08:01 AM
Subject: Re: [MQSERIES] Does an mq trace trap the data payloads that are moving thru the qmgr?
Sent by: MQSeries List <MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org<mailto:MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org>>
________________________________



If this is more something temporary to help debug an issue, then I would go with the Activity Trace (if you are at >= 7.1) over standard tracing (i.e. strmqtrc).

For viewing the AAT data, there are significant enhancements to the amqsact program (called amqsactz) that I find helpful -> http://www.capitalware.com/mq_code_c.html

You do need a C compiler to build it for your platform, but I provide some examples in the comments of the program on how to do this on Windows or Linux. The MQ manual, of course, covers all environments for building an MQ program written in C.

Thanks,
Tim

From: MQSeries List [mailto:MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org] On Behalf Of Costa, D. (Damian)
Sent: Wednesday, October 08, 2014 7:45 AM
To: MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org<mailto:MQSERIES-0lvw86wZMd9k/***@public.gmane.orgAC.AT>
Subject: Re: Does an mq trace trap the data payloads that are moving thru the qmgr?

Swat I tole 'em..... improve their logging from their apps.
What is disappointing is that they cannot tell what their app is doing with the message. The MQ stats indicate they are taking them off the queue.
Heaven only know where they go from there.

From: MQSeries List [mailto:MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org] On Behalf Of Tim Zielke
Sent: 08 October 2014 02:07 PM
To: MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org<mailto:MQSERIES-0lvw86wZMd9k/***@public.gmane.orgAC.AT>
Subject: Re: Does an mq trace trap the data payloads that are moving thru the qmgr?

Hi Damian,

If your queue manager is 7.1 or higher, another option is the Application Activity Trace.

This IBM article on the AAT -> http://www.ibm.com/developerworks/websphere/library/techarticles/1306_bushby/1306_bushby.html

does give the scenario of "Using Application Activity Trace to keep an audit trail of messages" as one of the AAT's uses.

Personally, I would be hesitant to do what you are being asked to do, and would like to understand from the application team why their application can not do this logging, itself. Do they really need the entire message, or is it really key pieces of data that they could put into an application log.

Thanks,
Tim

From: MQSeries List [mailto:MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org] On Behalf Of T.Rob
Sent: Wednesday, October 08, 2014 4:17 AM
To: MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org<mailto:MQSERIES-0lvw86wZMd9k/***@public.gmane.orgAC.AT>
Subject: Re: Does an mq trace trap the data payloads that are moving thru the qmgr?

I think that's *most* of the persistent data. At MQTC Mark Taylor gave the MQ Internals session and said that the Put To Waiting Getter optimization permits certain persistent messages that are PUT outside of syncpoint to bypass the log. So for purposes of an audit you either need to use API-level tracing or else be able to prove to the auditor that your programs do everything inside of syncpoint and therefore the dmpmqlog output is complete.

Trying to find a single or very few messages that appear to have been processed but for which there is no log entry could REALLY screw up your day, your audit, your relationship with upper management, etc.

(Do not confuse this with the restaurant management API that can recall service staff from the golf course on their day off when there's a sudden surge in business. That is the "Get To Putting Waiter" API call and is completely different.)

Kind regards,
-- T.Rob

T.Robert Wyatt, Managing partner
IoPT Consulting, LLC
+1 704-443-TROB (8762) Voice/Text
[phone] Voice
https://ioptconsulting.com<https://ioptconsulting.com/>
https://twitter.com/tdotrob

From: MQSeries List [mailto:MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org] On Behalf Of Andrew Hickson
Sent: Wednesday, October 08, 2014 4:52 AM
To: MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org<mailto:MQSERIES-0lvw86wZMd9k/***@public.gmane.orgAC.AT>
Subject: Re: Does an mq trace trap the data payloads that are moving thru the qmgr?

If you're using linear logging then all of the message data (control information + payload) for persistent messages is recorded in the recovery log, and can be post processed with the dmpmqlog utility.
If you're using circular logging then you've effectively got a wrap around history of the last X bytes of persistent data, however getting to all of that data (e.g. dmpmqlog) is much more difficult and typically requires the help of MQ L3.
The main advantage of using the recovery log for this purpose is that there's no performance overhead.
The main disadvantage of using the recovery log for this purpose is that the information isn't in a form that's very easy to process/consume.





From: "T.Rob" <t.rob-CkT6zf+urXSzW/GOMZKyElesiRL1/***@public.gmane.org<mailto:***@IOPTCONSULTING.COM>>
To: MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org<mailto:MQSERIES-0lvw86wZMd8hNtF/***@public.gmane.orgNIWIEN.AC.AT>,
Date: 08/10/2014 09:41
Subject: Re: Does an mq trace trap the data payloads that are moving thru the qmgr?
Sent by: MQSeries List <MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org<mailto:MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org>>
________________________________




If you use the MA0W trace exit I believe that you can specify capturing just
the headers. I do recall though a conversation with Ralph Bateman about how
Support often receives traces and FDC files in PMRs that are filled with
PII, medical data, SSN's, card numbers, etc. So I believe the answer is
"yes." That said, the WMQ native trace can get real big, real fast so you
may want to look at MA0W which traces only API calls and not internals, SSL,
comms, etc.

http://ibm.co/SupptPacMA0W


Kind regards,
-- T.Rob


> -----Original Message-----
> From: MQSeries List [mailto:MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org] On Behalf
> Of Costa, D. (Damian)
> Sent: Wednesday, October 08, 2014 4:00 AM
> To: MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org<mailto:MQSERIES-0lvw86wZMd9k/***@public.gmane.orgN.AC.AT>
> Subject: Does an mq trace trap the data payloads that are moving thru the
> qmgr?
>
> HI all,
> I Was just asked to supply the audit traces of all messages going through
> a particular queue on a test qmgr. Naturally I can't just do that as no
> audit logs exist. So I was wondering if I could fudge it by running an mq
> trace to trap the message payloads being processed off said queue.
> Izzat even possible?
>
> ********************
> Nedbank Limited Reg No 1951/000009/06. The following link displays the
> names of the Nedbank Board of Directors and Company Secretary.
> [ http://www.nedbank.co.za/terms/DirectorsNedbank.htm ] This email is
> confidential and is intended for the addressee only.
> The following link will take you to Nedbank's legal notice.
> [ http://www.nedbank.co.za/terms/EmailDisclaimer.htm ]
> ********************
>
> To unsubscribe, write to LISTSERV-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org<mailto:LISTSERV-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org> and, in the
> message body (not the subject), write: SIGNOFF MQSERIES Instructions for
> managing your mailing list subscription are provided in the Listserv
> General Users Guide available at http://www.lsoft.com<http://www.lsoft.com/>
> Archive: http://listserv.meduniwien.ac.at/archives/mqser-l.html

To unsubscribe, write to LISTSERV-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org<mailto:***@LISTSERV.MEDUNIWIEN.AC.AT> and,
in the message body (not the subject), write: SIGNOFF MQSERIES
Instructions for managing your mailing list subscription are provided in
the Listserv General Users Guide available at http://www.lsoft.com<http://www.lsoft.com/>
Archive: http://listserv.meduniwien.ac.at/archives/mqser-l.html



Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number 741598.
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU
________________________________

List Archive<http://listserv.meduniwien.ac.at/archives/mqser-l.html> - Manage Your List Settings<http://listserv.meduniwien.ac.at/cgi-bin/wa?SUBED1=mqser-l&A=1> - Unsubscribe<mailto:LISTSERV-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org?subject=Unsubscribe&BODY=signoff%20mqseries>

Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com<http://www.lsoft.com/resources/manuals.asp>


________________________________

List Archive<http://listserv.meduniwien.ac.at/archives/mqser-l.html> - Manage Your List Settings<http://listserv.meduniwien.ac.at/cgi-bin/wa?SUBED1=mqser-l&A=1> - Unsubscribe<mailto:LISTSERV-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org?subject=Unsubscribe&BODY=signoff%20mqseries>

Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com<http://www.lsoft.com/resources/manuals.asp>


________________________________

List Archive<http://listserv.meduniwien.ac.at/archives/mqser-l.html> - Manage Your List Settings<http://listserv.meduniwien.ac.at/cgi-bin/wa?SUBED1=mqser-l&A=1> - Unsubscribe<mailto:LISTSERV-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org?subject=Unsubscribe&BODY=signoff%20mqseries>

Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com<http://www.lsoft.com/resources/manuals.asp>

********************
Nedbank Limited Reg No 1951/000009/06. The following link displays
the names of the Nedbank Board of Directors and Company Secretary.
[ http://www.nedbank.co.za/terms/DirectorsNedbank.htm ]
This email is confidential and is intended for the addressee only.
The following link will take you to Nedbank's legal notice.
[ http://www.nedbank.co.za/terms/EmailDisclaimer.htm ]
********************


________________________________

List Archive<http://listserv.meduniwien.ac.at/archives/mqser-l.html> - Manage Your List Settings<http://listserv.meduniwien.ac.at/cgi-bin/wa?SUBED1=mqser-l&A=1> - Unsubscribe<mailto:LISTSERV-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org?subject=Unsubscribe&BODY=signoff%20mqseries>

Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com<http://www.lsoft.com/resources/manuals.asp>



________________________________
List Archive<http://listserv.meduniwien.ac.at/archives/mqser-l.html> - Manage Your List Settings<http://listserv.meduniwien.ac.at/cgi-bin/wa?SUBED1=mqser-l&A=1> - Unsubscribe<mailto:LISTSERV-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org?subject=Unsubscribe&BODY=signoff%20mqseries>

Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com<http://www.lsoft.com/resources/manuals.asp>

________________________________
List Archive<http://listserv.meduniwien.ac.at/archives/mqser-l.html> - Manage Your List Settings<http://listserv.meduniwien.ac.at/cgi-bin/wa?SUBED1=mqser-l&A=1> - Unsubscribe<mailto:LISTSERV-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org?subject=Unsubscribe&BODY=signoff%20mqseries>

Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com<http://www.lsoft.com/resources/manuals.asp>

********************
Nedbank Limited Reg No 1951/000009/06. The following link displays
the names of the Nedbank Board of Directors and Company Secretary.
[ http://www.nedbank.co.za/terms/DirectorsNedbank.htm ]
This email is confidential and is intended for the addressee only.
The following link will take you to Nedbank's legal notice.
[ http://www.nedbank.co.za/terms/EmailDisclaimer.htm ]
********************

________________________________
List Archive<http://listserv.meduniwien.ac.at/archives/mqser-l.html> - Manage Your List Settings<http://listserv.meduniwien.ac.at/cgi-bin/wa?SUBED1=mqser-l&A=1> - Unsubscribe<mailto:LISTSERV-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org?subject=Unsubscribe&BODY=signoff%20mqseries>

Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com<http://www.lsoft.com/resources/manuals.asp>


________________________________
List Archive<http://listserv.meduniwien.ac.at/archives/mqser-l.html> - Manage Your List Settings<http://listserv.meduniwien.ac.at/cgi-bin/wa?SUBED1=mqser-l&A=1> - Unsubscribe<mailto:LISTSERV-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org?subject=Unsubscribe&BODY=signoff%20mqseries>

Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com<http://www.lsoft.com/resources/manuals.asp>

********************
Nedbank Limited Reg No 1951/000009/06. The following link displays
the names of the Nedbank Board of Directors and Company Secretary.
[ http://www.nedbank.co.za/terms/DirectorsNedbank.htm ]
This email is confidential and is intended for the addressee only.
The following link will take you to Nedbank's legal notice.
[ http://www.nedbank.co.za/terms/EmailDisclaimer.htm ]
********************

________________________________
List Archive<http://listserv.meduniwien.ac.at/archives/mqser-l.html> - Manage Your List Settings<http://listserv.meduniwien.ac.at/cgi-bin/wa?SUBED1=mqser-l&A=1> - Unsubscribe<mailto:LISTSERV-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org?subject=Unsubscribe&BODY=signoff%20mqseries>

Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com<http://www.lsoft.com/resources/manuals.asp>

To unsubscribe, write to LISTSERV-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org and,
in the message body (not the subject), write: SIGNOFF MQSERIES
Instructions for managing your mailing list subscription are provided in
the Listserv General Users Guide available at http://www.lsoft.com
Archive: http://listserv.meduniwien.ac.at/archives/mqser-l.html

[Costa, D. (Damian)]

They admit nothing, deny everything. Hard to penetrate...

From: MQSeries List [mailto:MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org] On Behalf Of Tim Zielke
Sent: 09 October 2014 03:02 PM
To: MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org
Subject: Re: Does an mq trace trap the data payloads that are moving thru the qmgr?

Hi Damian,

Earlier in the thread you had mentioned:

"What is disappointing is that they cannot tell what their app is doing with the message. The MQ stats indicate they are taking them off the queue."

Just curious. Is the app claiming that they never did a GET on the message?


From: MQSeries List [mailto:MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org] On Behalf Of Costa, D. (Damian)
Sent: Thursday, October 09, 2014 3:02 AM
To: MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org<mailto:MQSERIES-0lvw86wZMd9k/***@public.gmane.orgAC.AT>
Subject: Re: Does an mq trace trap the data payloads that are moving thru the qmgr?

Aw crud! Oh well a twisted the dev's arm enough so they are adding additional logging logic to their app as we speak.
Worst comes to worst I will stop the channel back and trap the message on the xmitq queue on the responders side.


From: MQSeries List [mailto:MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org] On Behalf Of Neil Casey
Sent: 08 October 2014 11:45 PM
To: MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org<mailto:MQSERIES-0lvw86wZMd9k/***@public.gmane.orgAC.AT>
Subject: Re: Does an mq trace trap the data payloads that are moving thru the qmgr?

Hi Damian,

I agree that using a queue alias to a topic and then administrative subscriptions to copy the messages to 2 queues is a great capability.

But remember that it will change the message id, so if your application relies on message id (for example, to copy to correlation Id of the response) copying it this way will break the application. :-(

We've had discussions on the list about this before, and there is at least one RFE asking for the ability to keep the message id identical.
http://www.ibm.com/developerworks/rfe/execute?use_case=viewRfe&CR_ID=35062

Regards,

Neil Casey.


On 9 Oct 2014, at 2:37 am, Costa, D. (Damian) <DamianC-3zJjxGF14/***@public.gmane.org<mailto:DamianC-3zJjxGF14/***@public.gmane.org>> wrote:

Great idea re the topic queue. Will go setup and see what is happening.


From: MQSeries List [mailto:MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org] On Behalf Of Jefferson Lowrey
Sent: 08 October 2014 03:52 PM
To: MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org<mailto:MQSERIES-0lvw86wZMd9k/***@public.gmane.orgAC.AT>
Subject: Re: Does an mq trace trap the data payloads that are moving thru the qmgr?

The other thing you can do is (mis) use pub/sub and reroute messages that are supposed to go to the application input queue to a topic instead, and then create two admin subscriptions - one to the original input queue and one to a different queue - something that just gets dumped to a text file (perhaps by qload or etc.)

This is the basic replacement for mirrorq as of v7's pub/sub function. If, somehow, you're still at <v7, you can test your googlefu by trying to find some copy of the mirrorq source code to compile.

Thank you,

Jeff Lowrey




From: Tim Zielke <tim.zielke-PR+tvw7B/***@public.gmane.org<mailto:tim.zielke-PR+tvw7B/***@public.gmane.org>>
To: MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org<mailto:MQSERIES-0lvw86wZMd8hNtF/***@public.gmane.orgNIWIEN.AC.AT>
Date: 10/08/2014 08:01 AM
Subject: Re: [MQSERIES] Does an mq trace trap the data payloads that are moving thru the qmgr?
Sent by: MQSeries List <MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org<mailto:MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org>>
________________________________



If this is more something temporary to help debug an issue, then I would go with the Activity Trace (if you are at >= 7.1) over standard tracing (i.e. strmqtrc).

For viewing the AAT data, there are significant enhancements to the amqsact program (called amqsactz) that I find helpful -> http://www.capitalware.com/mq_code_c.html

You do need a C compiler to build it for your platform, but I provide some examples in the comments of the program on how to do this on Windows or Linux. The MQ manual, of course, covers all environments for building an MQ program written in C.

Thanks,
Tim

From: MQSeries List [mailto:MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org] On Behalf Of Costa, D. (Damian)
Sent: Wednesday, October 08, 2014 7:45 AM
To: MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org<mailto:MQSERIES-0lvw86wZMd9k/***@public.gmane.orgAC.AT>
Subject: Re: Does an mq trace trap the data payloads that are moving thru the qmgr?

Swat I tole 'em..... improve their logging from their apps.
What is disappointing is that they cannot tell what their app is doing with the message. The MQ stats indicate they are taking them off the queue.
Heaven only know where they go from there.

From: MQSeries List [mailto:MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org] On Behalf Of Tim Zielke
Sent: 08 October 2014 02:07 PM
To: MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org<mailto:MQSERIES-0lvw86wZMd9k/***@public.gmane.orgAC.AT>
Subject: Re: Does an mq trace trap the data payloads that are moving thru the qmgr?

Hi Damian,

If your queue manager is 7.1 or higher, another option is the Application Activity Trace.

This IBM article on the AAT -> http://www.ibm.com/developerworks/websphere/library/techarticles/1306_bushby/1306_bushby.html

does give the scenario of "Using Application Activity Trace to keep an audit trail of messages" as one of the AAT's uses.

Personally, I would be hesitant to do what you are being asked to do, and would like to understand from the application team why their application can not do this logging, itself. Do they really need the entire message, or is it really key pieces of data that they could put into an application log.

Thanks,
Tim

From: MQSeries List [mailto:MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org] On Behalf Of T.Rob
Sent: Wednesday, October 08, 2014 4:17 AM
To: MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org<mailto:MQSERIES-0lvw86wZMd9k/***@public.gmane.orgAC.AT>
Subject: Re: Does an mq trace trap the data payloads that are moving thru the qmgr?

I think that's *most* of the persistent data. At MQTC Mark Taylor gave the MQ Internals session and said that the Put To Waiting Getter optimization permits certain persistent messages that are PUT outside of syncpoint to bypass the log. So for purposes of an audit you either need to use API-level tracing or else be able to prove to the auditor that your programs do everything inside of syncpoint and therefore the dmpmqlog output is complete.

Trying to find a single or very few messages that appear to have been processed but for which there is no log entry could REALLY screw up your day, your audit, your relationship with upper management, etc.

(Do not confuse this with the restaurant management API that can recall service staff from the golf course on their day off when there's a sudden surge in business. That is the "Get To Putting Waiter" API call and is completely different.)

Kind regards,
-- T.Rob

T.Robert Wyatt, Managing partner
IoPT Consulting, LLC
+1 704-443-TROB (8762) Voice/Text
[phone] Voice
https://ioptconsulting.com<https://ioptconsulting.com/>
https://twitter.com/tdotrob

From: MQSeries List [mailto:MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org] On Behalf Of Andrew Hickson
Sent: Wednesday, October 08, 2014 4:52 AM
To: MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org<mailto:MQSERIES-0lvw86wZMd9k/***@public.gmane.orgAC.AT>
Subject: Re: Does an mq trace trap the data payloads that are moving thru the qmgr?

If you're using linear logging then all of the message data (control information + payload) for persistent messages is recorded in the recovery log, and can be post processed with the dmpmqlog utility.
If you're using circular logging then you've effectively got a wrap around history of the last X bytes of persistent data, however getting to all of that data (e.g. dmpmqlog) is much more difficult and typically requires the help of MQ L3.
The main advantage of using the recovery log for this purpose is that there's no performance overhead.
The main disadvantage of using the recovery log for this purpose is that the information isn't in a form that's very easy to process/consume.





From: "T.Rob" <t.rob-CkT6zf+urXSzW/GOMZKyElesiRL1/***@public.gmane.org<mailto:***@IOPTCONSULTING.COM>>
To: MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org<mailto:MQSERIES-0lvw86wZMd8hNtF/***@public.gmane.orgNIWIEN.AC.AT>,
Date: 08/10/2014 09:41
Subject: Re: Does an mq trace trap the data payloads that are moving thru the qmgr?
Sent by: MQSeries List <MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org<mailto:MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org>>
________________________________




If you use the MA0W trace exit I believe that you can specify capturing just
the headers. I do recall though a conversation with Ralph Bateman about how
Support often receives traces and FDC files in PMRs that are filled with
PII, medical data, SSN's, card numbers, etc. So I believe the answer is
"yes." That said, the WMQ native trace can get real big, real fast so you
may want to look at MA0W which traces only API calls and not internals, SSL,
comms, etc.

http://ibm.co/SupptPacMA0W


Kind regards,
-- T.Rob


> -----Original Message-----
> From: MQSeries List [mailto:MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org] On Behalf
> Of Costa, D. (Damian)
> Sent: Wednesday, October 08, 2014 4:00 AM
> To: MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org<mailto:MQSERIES-0lvw86wZMd9k/***@public.gmane.orgN.AC.AT>
> Subject: Does an mq trace trap the data payloads that are moving thru the
> qmgr?
>
> HI all,
> I Was just asked to supply the audit traces of all messages going through
> a particular queue on a test qmgr. Naturally I can't just do that as no
> audit logs exist. So I was wondering if I could fudge it by running an mq
> trace to trap the message payloads being processed off said queue.
> Izzat even possible?
>
> ********************
> Nedbank Limited Reg No 1951/000009/06. The following link displays the
> names of the Nedbank Board of Directors and Company Secretary.
> [ http://www.nedbank.co.za/terms/DirectorsNedbank.htm ] This email is
> confidential and is intended for the addressee only.
> The following link will take you to Nedbank's legal notice.
> [ http://www.nedbank.co.za/terms/EmailDisclaimer.htm ]
> ********************
>
> To unsubscribe, write to LISTSERV-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org<mailto:LISTSERV-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org> and, in the
> message body (not the subject), write: SIGNOFF MQSERIES Instructions for
> managing your mailing list subscription are provided in the Listserv
> General Users Guide available at http://www.lsoft.com<http://www.lsoft.com/>
> Archive: http://listserv.meduniwien.ac.at/archives/mqser-l.html

To unsubscribe, write to LISTSERV-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org<mailto:***@LISTSERV.MEDUNIWIEN.AC.AT> and,
in the message body (not the subject), write: SIGNOFF MQSERIES
Instructions for managing your mailing list subscription are provided in
the Listserv General Users Guide available at http://www.lsoft.com<http://www.lsoft.com/>
Archive: http://listserv.meduniwien.ac.at/archives/mqser-l.html



Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number 741598.
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU
________________________________

List Archive<http://listserv.meduniwien.ac.at/archives/mqser-l.html> - Manage Your List Settings<http://listserv.meduniwien.ac.at/cgi-bin/wa?SUBED1=mqser-l&A=1> - Unsubscribe<mailto:LISTSERV-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org?subject=Unsubscribe&BODY=signoff%20mqseries>

Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com<http://www.lsoft.com/resources/manuals.asp>


________________________________

List Archive<http://listserv.meduniwien.ac.at/archives/mqser-l.html> - Manage Your List Settings<http://listserv.meduniwien.ac.at/cgi-bin/wa?SUBED1=mqser-l&A=1> - Unsubscribe<mailto:LISTSERV-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org?subject=Unsubscribe&BODY=signoff%20mqseries>

Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com<http://www.lsoft.com/resources/manuals.asp>


________________________________

List Archive<http://listserv.meduniwien.ac.at/archives/mqser-l.html> - Manage Your List Settings<http://listserv.meduniwien.ac.at/cgi-bin/wa?SUBED1=mqser-l&A=1> - Unsubscribe<mailto:LISTSERV-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org?subject=Unsubscribe&BODY=signoff%20mqseries>

Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com<http://www.lsoft.com/resources/manuals.asp>

********************
Nedbank Limited Reg No 1951/000009/06. The following link displays
the names of the Nedbank Board of Directors and Company Secretary.
[ http://www.nedbank.co.za/terms/DirectorsNedbank.htm ]
This email is confidential and is intended for the addressee only.
The following link will take you to Nedbank's legal notice.
[ http://www.nedbank.co.za/terms/EmailDisclaimer.htm ]
********************


________________________________

List Archive<http://listserv.meduniwien.ac.at/archives/mqser-l.html> - Manage Your List Settings<http://listserv.meduniwien.ac.at/cgi-bin/wa?SUBED1=mqser-l&A=1> - Unsubscribe<mailto:LISTSERV-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org?subject=Unsubscribe&BODY=signoff%20mqseries>

Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com<http://www.lsoft.com/resources/manuals.asp>



________________________________
List Archive<http://listserv.meduniwien.ac.at/archives/mqser-l.html> - Manage Your List Settings<http://listserv.meduniwien.ac.at/cgi-bin/wa?SUBED1=mqser-l&A=1> - Unsubscribe<mailto:LISTSERV-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org?subject=Unsubscribe&BODY=signoff%20mqseries>

Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com<http://www.lsoft.com/resources/manuals.asp>

________________________________
List Archive<http://listserv.meduniwien.ac.at/archives/mqser-l.html> - Manage Your List Settings<http://listserv.meduniwien.ac.at/cgi-bin/wa?SUBED1=mqser-l&A=1> - Unsubscribe<mailto:LISTSERV-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org?subject=Unsubscribe&BODY=signoff%20mqseries>

Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com<http://www.lsoft.com/resources/manuals.asp>

********************
Nedbank Limited Reg No 1951/000009/06. The following link displays
the names of the Nedbank Board of Directors and Company Secretary.
[ http://www.nedbank.co.za/terms/DirectorsNedbank.htm ]
This email is confidential and is intended for the addressee only.
The following link will take you to Nedbank's legal notice.
[ http://www.nedbank.co.za/terms/EmailDisclaimer.htm ]
********************

________________________________
List Archive<http://listserv.meduniwien.ac.at/archives/mqser-l.html> - Manage Your List Settings<http://listserv.meduniwien.ac.at/cgi-bin/wa?SUBED1=mqser-l&A=1> - Unsubscribe<mailto:LISTSERV-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org?subject=Unsubscribe&BODY=signoff%20mqseries>

Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com<http://www.lsoft.com/resources/manuals.asp>


________________________________
List Archive<http://listserv.meduniwien.ac.at/archives/mqser-l.html> - Manage Your List Settings<http://listserv.meduniwien.ac.at/cgi-bin/wa?SUBED1=mqser-l&A=1> - Unsubscribe<mailto:LISTSERV-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org?subject=Unsubscribe&BODY=signoff%20mqseries>

Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com<http://www.lsoft.com/resources/manuals.asp>

********************
Nedbank Limited Reg No 1951/000009/06. The following link displays
the names of the Nedbank Board of Directors and Company Secretary.
[ http://www.nedbank.co.za/terms/DirectorsNedbank.htm ]
This email is confidential and is intended for the addressee only.
The following link will take you to Nedbank's legal notice.
[ http://www.nedbank.co.za/terms/EmailDisclaimer.htm ]
********************

________________________________
List Archive<http://listserv.meduniwien.ac.at/archives/mqser-l.html> - Manage Your List Settings<http://listserv.meduniwien.ac.at/cgi-bin/wa?SUBED1=mqser-l&A=1> - Unsubscribe<mailto:LISTSERV-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org?subject=Unsubscribe&BODY=signoff%20mqseries>

Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com<http://www.lsoft.com/resources/manuals.asp>

________________________________
List Archive<http://listserv.meduniwien.ac.at/archives/mqser-l.html> - Manage Your List Settings<http://listserv.meduniwien.ac.at/cgi-bin/wa?SUBED1=mqser-l&A=1> - Unsubscribe<mailto:LISTSERV-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org?subject=Unsubscribe&BODY=signoff%20mqseries>

Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com<http://www.lsoft.com/resources/manuals.asp>

********************
Nedbank Limited Reg No 1951/000009/06. The following link displays
the names of the Nedbank Board of Directors and Company Secretary.
[ http://www.nedbank.co.za/terms/DirectorsNedbank.htm ]
This email is confidential and is intended for the addressee only.
The following link will take you to Nedbank's legal notice.
[ http://www.nedbank.co.za/terms/EmailDisclaimer.htm ]
********************

To unsubscribe, write to LISTSERV-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org and,
in the message body (not the subject), write: SIGNOFF MQSERIES
Instructions for managing your mailing list subscription are provided in
the Listserv General Users Guide available at http://www.lsoft.com
Archive: http://listserv.meduniwien.ac.at/archives/mqser-l.html

[Tim Zielke]

An Activity Trace could be very telling. For example, their application could be doing a GET and not handling a non-zero reason code properly. Inadvertently, they could be throwing the message away and not logging the error, which to the application looks like MQ "lost my message". I have used the Activity Trace to help look into situations similar to this, and it is very helpful, as it lets you look under the covers at what the application is doing.

It is similar to a cookie jar that is missing cookies, and the child says "I didn't take it!". And then you can show them the picture of them with their hand in the cookie jar . . . :-).

From: MQSeries List [mailto:MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org] On Behalf Of Costa, D. (Damian)
Sent: Thursday, October 09, 2014 9:32 AM
To: MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org
Subject: Re: Does an mq trace trap the data payloads that are moving thru the qmgr?

They admit nothing, deny everything. Hard to penetrate...

From: MQSeries List [mailto:MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org] On Behalf Of Tim Zielke
Sent: 09 October 2014 03:02 PM
To: MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org<mailto:MQSERIES-0lvw86wZMd9k/***@public.gmane.orgAC.AT>
Subject: Re: Does an mq trace trap the data payloads that are moving thru the qmgr?

Hi Damian,

Earlier in the thread you had mentioned:

"What is disappointing is that they cannot tell what their app is doing with the message. The MQ stats indicate they are taking them off the queue."

Just curious. Is the app claiming that they never did a GET on the message?


From: MQSeries List [mailto:MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org] On Behalf Of Costa, D. (Damian)
Sent: Thursday, October 09, 2014 3:02 AM
To: MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org<mailto:MQSERIES-0lvw86wZMd9k/***@public.gmane.orgAC.AT>
Subject: Re: Does an mq trace trap the data payloads that are moving thru the qmgr?

Aw crud! Oh well a twisted the dev's arm enough so they are adding additional logging logic to their app as we speak.
Worst comes to worst I will stop the channel back and trap the message on the xmitq queue on the responders side.


From: MQSeries List [mailto:MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org] On Behalf Of Neil Casey
Sent: 08 October 2014 11:45 PM
To: MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org<mailto:MQSERIES-0lvw86wZMd9k/***@public.gmane.orgAC.AT>
Subject: Re: Does an mq trace trap the data payloads that are moving thru the qmgr?

Hi Damian,

I agree that using a queue alias to a topic and then administrative subscriptions to copy the messages to 2 queues is a great capability.

But remember that it will change the message id, so if your application relies on message id (for example, to copy to correlation Id of the response) copying it this way will break the application. :-(

We've had discussions on the list about this before, and there is at least one RFE asking for the ability to keep the message id identical.
http://www.ibm.com/developerworks/rfe/execute?use_case=viewRfe&CR_ID=35062

Regards,

Neil Casey.


On 9 Oct 2014, at 2:37 am, Costa, D. (Damian) <DamianC-3zJjxGF14/***@public.gmane.org<mailto:DamianC-3zJjxGF14/***@public.gmane.org>> wrote:

Great idea re the topic queue. Will go setup and see what is happening.


From: MQSeries List [mailto:MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org] On Behalf Of Jefferson Lowrey
Sent: 08 October 2014 03:52 PM
To: MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org<mailto:MQSERIES-0lvw86wZMd9k/***@public.gmane.orgAC.AT>
Subject: Re: Does an mq trace trap the data payloads that are moving thru the qmgr?

The other thing you can do is (mis) use pub/sub and reroute messages that are supposed to go to the application input queue to a topic instead, and then create two admin subscriptions - one to the original input queue and one to a different queue - something that just gets dumped to a text file (perhaps by qload or etc.)

This is the basic replacement for mirrorq as of v7's pub/sub function. If, somehow, you're still at <v7, you can test your googlefu by trying to find some copy of the mirrorq source code to compile.

Thank you,

Jeff Lowrey




From: Tim Zielke <tim.zielke-PR+tvw7B/***@public.gmane.org<mailto:tim.zielke-PR+tvw7B/***@public.gmane.org>>
To: MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org<mailto:MQSERIES-0lvw86wZMd8hNtF/***@public.gmane.orgNIWIEN.AC.AT>
Date: 10/08/2014 08:01 AM
Subject: Re: [MQSERIES] Does an mq trace trap the data payloads that are moving thru the qmgr?
Sent by: MQSeries List <MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org<mailto:MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org>>
________________________________



If this is more something temporary to help debug an issue, then I would go with the Activity Trace (if you are at >= 7.1) over standard tracing (i.e. strmqtrc).

For viewing the AAT data, there are significant enhancements to the amqsact program (called amqsactz) that I find helpful -> http://www.capitalware.com/mq_code_c.html

You do need a C compiler to build it for your platform, but I provide some examples in the comments of the program on how to do this on Windows or Linux. The MQ manual, of course, covers all environments for building an MQ program written in C.

Thanks,
Tim

From: MQSeries List [mailto:MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org] On Behalf Of Costa, D. (Damian)
Sent: Wednesday, October 08, 2014 7:45 AM
To: MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org<mailto:MQSERIES-0lvw86wZMd9k/***@public.gmane.orgAC.AT>
Subject: Re: Does an mq trace trap the data payloads that are moving thru the qmgr?

Swat I tole 'em..... improve their logging from their apps.
What is disappointing is that they cannot tell what their app is doing with the message. The MQ stats indicate they are taking them off the queue.
Heaven only know where they go from there.

From: MQSeries List [mailto:MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org] On Behalf Of Tim Zielke
Sent: 08 October 2014 02:07 PM
To: MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org<mailto:MQSERIES-0lvw86wZMd9k/***@public.gmane.orgAC.AT>
Subject: Re: Does an mq trace trap the data payloads that are moving thru the qmgr?

Hi Damian,

If your queue manager is 7.1 or higher, another option is the Application Activity Trace.

This IBM article on the AAT -> http://www.ibm.com/developerworks/websphere/library/techarticles/1306_bushby/1306_bushby.html

does give the scenario of "Using Application Activity Trace to keep an audit trail of messages" as one of the AAT's uses.

Personally, I would be hesitant to do what you are being asked to do, and would like to understand from the application team why their application can not do this logging, itself. Do they really need the entire message, or is it really key pieces of data that they could put into an application log.

Thanks,
Tim

From: MQSeries List [mailto:MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org] On Behalf Of T.Rob
Sent: Wednesday, October 08, 2014 4:17 AM
To: MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org<mailto:MQSERIES-0lvw86wZMd9k/***@public.gmane.orgAC.AT>
Subject: Re: Does an mq trace trap the data payloads that are moving thru the qmgr?

I think that's *most* of the persistent data. At MQTC Mark Taylor gave the MQ Internals session and said that the Put To Waiting Getter optimization permits certain persistent messages that are PUT outside of syncpoint to bypass the log. So for purposes of an audit you either need to use API-level tracing or else be able to prove to the auditor that your programs do everything inside of syncpoint and therefore the dmpmqlog output is complete.

Trying to find a single or very few messages that appear to have been processed but for which there is no log entry could REALLY screw up your day, your audit, your relationship with upper management, etc.

(Do not confuse this with the restaurant management API that can recall service staff from the golf course on their day off when there's a sudden surge in business. That is the "Get To Putting Waiter" API call and is completely different.)

Kind regards,
-- T.Rob

T.Robert Wyatt, Managing partner
IoPT Consulting, LLC
+1 704-443-TROB (8762) Voice/Text
[phone] Voice
https://ioptconsulting.com<https://ioptconsulting.com/>
https://twitter.com/tdotrob

From: MQSeries List [mailto:MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org] On Behalf Of Andrew Hickson
Sent: Wednesday, October 08, 2014 4:52 AM
To: MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org<mailto:MQSERIES-0lvw86wZMd9k/***@public.gmane.orgAC.AT>
Subject: Re: Does an mq trace trap the data payloads that are moving thru the qmgr?

If you're using linear logging then all of the message data (control information + payload) for persistent messages is recorded in the recovery log, and can be post processed with the dmpmqlog utility.
If you're using circular logging then you've effectively got a wrap around history of the last X bytes of persistent data, however getting to all of that data (e.g. dmpmqlog) is much more difficult and typically requires the help of MQ L3.
The main advantage of using the recovery log for this purpose is that there's no performance overhead.
The main disadvantage of using the recovery log for this purpose is that the information isn't in a form that's very easy to process/consume.





From: "T.Rob" <t.rob-CkT6zf+urXSzW/GOMZKyElesiRL1/***@public.gmane.org<mailto:***@IOPTCONSULTING.COM>>
To: MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org<mailto:MQSERIES-0lvw86wZMd8hNtF/***@public.gmane.orgNIWIEN.AC.AT>,
Date: 08/10/2014 09:41
Subject: Re: Does an mq trace trap the data payloads that are moving thru the qmgr?
Sent by: MQSeries List <MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org<mailto:MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org>>
________________________________




If you use the MA0W trace exit I believe that you can specify capturing just
the headers. I do recall though a conversation with Ralph Bateman about how
Support often receives traces and FDC files in PMRs that are filled with
PII, medical data, SSN's, card numbers, etc. So I believe the answer is
"yes." That said, the WMQ native trace can get real big, real fast so you
may want to look at MA0W which traces only API calls and not internals, SSL,
comms, etc.

http://ibm.co/SupptPacMA0W


Kind regards,
-- T.Rob


> -----Original Message-----
> From: MQSeries List [mailto:MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org] On Behalf
> Of Costa, D. (Damian)
> Sent: Wednesday, October 08, 2014 4:00 AM
> To: MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org<mailto:MQSERIES-0lvw86wZMd9k/***@public.gmane.orgN.AC.AT>
> Subject: Does an mq trace trap the data payloads that are moving thru the
> qmgr?
>
> HI all,
> I Was just asked to supply the audit traces of all messages going through
> a particular queue on a test qmgr. Naturally I can't just do that as no
> audit logs exist. So I was wondering if I could fudge it by running an mq
> trace to trap the message payloads being processed off said queue.
> Izzat even possible?
>
> ********************
> Nedbank Limited Reg No 1951/000009/06. The following link displays the
> names of the Nedbank Board of Directors and Company Secretary.
> [ http://www.nedbank.co.za/terms/DirectorsNedbank.htm ] This email is
> confidential and is intended for the addressee only.
> The following link will take you to Nedbank's legal notice.
> [ http://www.nedbank.co.za/terms/EmailDisclaimer.htm ]
> ********************
>
> To unsubscribe, write to LISTSERV-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org<mailto:LISTSERV-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org> and, in the
> message body (not the subject), write: SIGNOFF MQSERIES Instructions for
> managing your mailing list subscription are provided in the Listserv
> General Users Guide available at http://www.lsoft.com<http://www.lsoft.com/>
> Archive: http://listserv.meduniwien.ac.at/archives/mqser-l.html

To unsubscribe, write to LISTSERV-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org<mailto:***@LISTSERV.MEDUNIWIEN.AC.AT> and,
in the message body (not the subject), write: SIGNOFF MQSERIES
Instructions for managing your mailing list subscription are provided in
the Listserv General Users Guide available at http://www.lsoft.com<http://www.lsoft.com/>
Archive: http://listserv.meduniwien.ac.at/archives/mqser-l.html



Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number 741598.
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU
________________________________

List Archive<http://listserv.meduniwien.ac.at/archives/mqser-l.html> - Manage Your List Settings<http://listserv.meduniwien.ac.at/cgi-bin/wa?SUBED1=mqser-l&A=1> - Unsubscribe<mailto:LISTSERV-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org?subject=Unsubscribe&BODY=signoff%20mqseries>

Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com<http://www.lsoft.com/resources/manuals.asp>


________________________________

List Archive<http://listserv.meduniwien.ac.at/archives/mqser-l.html> - Manage Your List Settings<http://listserv.meduniwien.ac.at/cgi-bin/wa?SUBED1=mqser-l&A=1> - Unsubscribe<mailto:LISTSERV-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org?subject=Unsubscribe&BODY=signoff%20mqseries>

Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com<http://www.lsoft.com/resources/manuals.asp>


________________________________

List Archive<http://listserv.meduniwien.ac.at/archives/mqser-l.html> - Manage Your List Settings<http://listserv.meduniwien.ac.at/cgi-bin/wa?SUBED1=mqser-l&A=1> - Unsubscribe<mailto:LISTSERV-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org?subject=Unsubscribe&BODY=signoff%20mqseries>

Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com<http://www.lsoft.com/resources/manuals.asp>

********************
Nedbank Limited Reg No 1951/000009/06. The following link displays
the names of the Nedbank Board of Directors and Company Secretary.
[ http://www.nedbank.co.za/terms/DirectorsNedbank.htm ]
This email is confidential and is intended for the addressee only.
The following link will take you to Nedbank's legal notice.
[ http://www.nedbank.co.za/terms/EmailDisclaimer.htm ]
********************


________________________________

List Archive<http://listserv.meduniwien.ac.at/archives/mqser-l.html> - Manage Your List Settings<http://listserv.meduniwien.ac.at/cgi-bin/wa?SUBED1=mqser-l&A=1> - Unsubscribe<mailto:LISTSERV-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org?subject=Unsubscribe&BODY=signoff%20mqseries>

Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com<http://www.lsoft.com/resources/manuals.asp>



________________________________
List Archive<http://listserv.meduniwien.ac.at/archives/mqser-l.html> - Manage Your List Settings<http://listserv.meduniwien.ac.at/cgi-bin/wa?SUBED1=mqser-l&A=1> - Unsubscribe<mailto:LISTSERV-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org?subject=Unsubscribe&BODY=signoff%20mqseries>

Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com<http://www.lsoft.com/resources/manuals.asp>

________________________________
List Archive<http://listserv.meduniwien.ac.at/archives/mqser-l.html> - Manage Your List Settings<http://listserv.meduniwien.ac.at/cgi-bin/wa?SUBED1=mqser-l&A=1> - Unsubscribe<mailto:LISTSERV-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org?subject=Unsubscribe&BODY=signoff%20mqseries>

Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com<http://www.lsoft.com/resources/manuals.asp>

********************
Nedbank Limited Reg No 1951/000009/06. The following link displays
the names of the Nedbank Board of Directors and Company Secretary.
[ http://www.nedbank.co.za/terms/DirectorsNedbank.htm ]
This email is confidential and is intended for the addressee only.
The following link will take you to Nedbank's legal notice.
[ http://www.nedbank.co.za/terms/EmailDisclaimer.htm ]
********************

________________________________
List Archive<http://listserv.meduniwien.ac.at/archives/mqser-l.html> - Manage Your List Settings<http://listserv.meduniwien.ac.at/cgi-bin/wa?SUBED1=mqser-l&A=1> - Unsubscribe<mailto:LISTSERV-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org?subject=Unsubscribe&BODY=signoff%20mqseries>

Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com<http://www.lsoft.com/resources/manuals.asp>


________________________________
List Archive<http://listserv.meduniwien.ac.at/archives/mqser-l.html> - Manage Your List Settings<http://listserv.meduniwien.ac.at/cgi-bin/wa?SUBED1=mqser-l&A=1> - Unsubscribe<mailto:LISTSERV-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org?subject=Unsubscribe&BODY=signoff%20mqseries>

Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com<http://www.lsoft.com/resources/manuals.asp>

********************
Nedbank Limited Reg No 1951/000009/06. The following link displays
the names of the Nedbank Board of Directors and Company Secretary.
[ http://www.nedbank.co.za/terms/DirectorsNedbank.htm ]
This email is confidential and is intended for the addressee only.
The following link will take you to Nedbank's legal notice.
[ http://www.nedbank.co.za/terms/EmailDisclaimer.htm ]
********************

________________________________
List Archive<http://listserv.meduniwien.ac.at/archives/mqser-l.html> - Manage Your List Settings<http://listserv.meduniwien.ac.at/cgi-bin/wa?SUBED1=mqser-l&A=1> - Unsubscribe<mailto:LISTSERV-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org?subject=Unsubscribe&BODY=signoff%20mqseries>

Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com<http://www.lsoft.com/resources/manuals.asp>

________________________________
List Archive<http://listserv.meduniwien.ac.at/archives/mqser-l.html> - Manage Your List Settings<http://listserv.meduniwien.ac.at/cgi-bin/wa?SUBED1=mqser-l&A=1> - Unsubscribe<mailto:LISTSERV-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org?subject=Unsubscribe&BODY=signoff%20mqseries>

Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com<http://www.lsoft.com/resources/manuals.asp>

********************
Nedbank Limited Reg No 1951/000009/06. The following link displays
the names of the Nedbank Board of Directors and Company Secretary.
[ http://www.nedbank.co.za/terms/DirectorsNedbank.htm ]
This email is confidential and is intended for the addressee only.
The following link will take you to Nedbank's legal notice.
[ http://www.nedbank.co.za/terms/EmailDisclaimer.htm ]
********************

________________________________
List Archive<http://listserv.meduniwien.ac.at/archives/mqser-l.html> - Manage Your List Settings<http://listserv.meduniwien.ac.at/cgi-bin/wa?SUBED1=mqser-l&A=1> - Unsubscribe<mailto:LISTSERV-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org?subject=Unsubscribe&BODY=signoff%20mqseries>

Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com<http://www.lsoft.com/resources/manuals.asp>

To unsubscribe, write to LISTSERV-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org and,
in the message body (not the subject), write: SIGNOFF MQSERIES
Instructions for managing your mailing list subscription are provided in
the Listserv General Users Guide available at http://www.lsoft.com
Archive: http://listserv.meduniwien.ac.at/archives/mqser-l.html

[Costa, D. (Damian)]

And it's at V 7.0* only going to V 7.1 next month or later this month. Sob. So no activity trace for me.


From: MQSeries List [mailto:MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org] On Behalf Of Tim Zielke
Sent: 09 October 2014 04:59 PM
To: MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org
Subject: Re: Does an mq trace trap the data payloads that are moving thru the qmgr?

An Activity Trace could be very telling. For example, their application could be doing a GET and not handling a non-zero reason code properly. Inadvertently, they could be throwing the message away and not logging the error, which to the application looks like MQ "lost my message". I have used the Activity Trace to help look into situations similar to this, and it is very helpful, as it lets you look under the covers at what the application is doing.

It is similar to a cookie jar that is missing cookies, and the child says "I didn't take it!". And then you can show them the picture of them with their hand in the cookie jar . . . :-).

From: MQSeries List [mailto:MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org] On Behalf Of Costa, D. (Damian)
Sent: Thursday, October 09, 2014 9:32 AM
To: MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org<mailto:MQSERIES-0lvw86wZMd9k/***@public.gmane.orgAC.AT>
Subject: Re: Does an mq trace trap the data payloads that are moving thru the qmgr?

They admit nothing, deny everything. Hard to penetrate...

From: MQSeries List [mailto:MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org] On Behalf Of Tim Zielke
Sent: 09 October 2014 03:02 PM
To: MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org<mailto:MQSERIES-0lvw86wZMd9k/***@public.gmane.orgAC.AT>
Subject: Re: Does an mq trace trap the data payloads that are moving thru the qmgr?

Hi Damian,

Earlier in the thread you had mentioned:

"What is disappointing is that they cannot tell what their app is doing with the message. The MQ stats indicate they are taking them off the queue."

Just curious. Is the app claiming that they never did a GET on the message?


From: MQSeries List [mailto:MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org] On Behalf Of Costa, D. (Damian)
Sent: Thursday, October 09, 2014 3:02 AM
To: MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org<mailto:MQSERIES-0lvw86wZMd9k/***@public.gmane.orgAC.AT>
Subject: Re: Does an mq trace trap the data payloads that are moving thru the qmgr?

Aw crud! Oh well a twisted the dev's arm enough so they are adding additional logging logic to their app as we speak.
Worst comes to worst I will stop the channel back and trap the message on the xmitq queue on the responders side.


From: MQSeries List [mailto:MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org] On Behalf Of Neil Casey
Sent: 08 October 2014 11:45 PM
To: MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org<mailto:MQSERIES-0lvw86wZMd9k/***@public.gmane.orgAC.AT>
Subject: Re: Does an mq trace trap the data payloads that are moving thru the qmgr?

Hi Damian,

I agree that using a queue alias to a topic and then administrative subscriptions to copy the messages to 2 queues is a great capability.

But remember that it will change the message id, so if your application relies on message id (for example, to copy to correlation Id of the response) copying it this way will break the application. :-(

We've had discussions on the list about this before, and there is at least one RFE asking for the ability to keep the message id identical.
http://www.ibm.com/developerworks/rfe/execute?use_case=viewRfe&CR_ID=35062

Regards,

Neil Casey.


On 9 Oct 2014, at 2:37 am, Costa, D. (Damian) <DamianC-3zJjxGF14/***@public.gmane.org<mailto:DamianC-3zJjxGF14/***@public.gmane.org>> wrote:

Great idea re the topic queue. Will go setup and see what is happening.


From: MQSeries List [mailto:MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org] On Behalf Of Jefferson Lowrey
Sent: 08 October 2014 03:52 PM
To: MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org<mailto:MQSERIES-0lvw86wZMd9k/***@public.gmane.orgAC.AT>
Subject: Re: Does an mq trace trap the data payloads that are moving thru the qmgr?

The other thing you can do is (mis) use pub/sub and reroute messages that are supposed to go to the application input queue to a topic instead, and then create two admin subscriptions - one to the original input queue and one to a different queue - something that just gets dumped to a text file (perhaps by qload or etc.)

This is the basic replacement for mirrorq as of v7's pub/sub function. If, somehow, you're still at <v7, you can test your googlefu by trying to find some copy of the mirrorq source code to compile.

Thank you,

Jeff Lowrey




From: Tim Zielke <tim.zielke-PR+tvw7B/***@public.gmane.org<mailto:tim.zielke-PR+tvw7B/***@public.gmane.org>>
To: MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org<mailto:MQSERIES-0lvw86wZMd8hNtF/***@public.gmane.orgNIWIEN.AC.AT>
Date: 10/08/2014 08:01 AM
Subject: Re: [MQSERIES] Does an mq trace trap the data payloads that are moving thru the qmgr?
Sent by: MQSeries List <MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org<mailto:MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org>>
________________________________



If this is more something temporary to help debug an issue, then I would go with the Activity Trace (if you are at >= 7.1) over standard tracing (i.e. strmqtrc).

For viewing the AAT data, there are significant enhancements to the amqsact program (called amqsactz) that I find helpful -> http://www.capitalware.com/mq_code_c.html

You do need a C compiler to build it for your platform, but I provide some examples in the comments of the program on how to do this on Windows or Linux. The MQ manual, of course, covers all environments for building an MQ program written in C.

Thanks,
Tim

From: MQSeries List [mailto:MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org] On Behalf Of Costa, D. (Damian)
Sent: Wednesday, October 08, 2014 7:45 AM
To: MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org<mailto:MQSERIES-0lvw86wZMd9k/***@public.gmane.orgAC.AT>
Subject: Re: Does an mq trace trap the data payloads that are moving thru the qmgr?

Swat I tole 'em..... improve their logging from their apps.
What is disappointing is that they cannot tell what their app is doing with the message. The MQ stats indicate they are taking them off the queue.
Heaven only know where they go from there.

From: MQSeries List [mailto:MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org] On Behalf Of Tim Zielke
Sent: 08 October 2014 02:07 PM
To: MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org<mailto:MQSERIES-0lvw86wZMd9k/***@public.gmane.orgAC.AT>
Subject: Re: Does an mq trace trap the data payloads that are moving thru the qmgr?

Hi Damian,

If your queue manager is 7.1 or higher, another option is the Application Activity Trace.

This IBM article on the AAT -> http://www.ibm.com/developerworks/websphere/library/techarticles/1306_bushby/1306_bushby.html

does give the scenario of "Using Application Activity Trace to keep an audit trail of messages" as one of the AAT's uses.

Personally, I would be hesitant to do what you are being asked to do, and would like to understand from the application team why their application can not do this logging, itself. Do they really need the entire message, or is it really key pieces of data that they could put into an application log.

Thanks,
Tim

From: MQSeries List [mailto:MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org] On Behalf Of T.Rob
Sent: Wednesday, October 08, 2014 4:17 AM
To: MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org<mailto:MQSERIES-0lvw86wZMd9k/***@public.gmane.orgAC.AT>
Subject: Re: Does an mq trace trap the data payloads that are moving thru the qmgr?

I think that's *most* of the persistent data. At MQTC Mark Taylor gave the MQ Internals session and said that the Put To Waiting Getter optimization permits certain persistent messages that are PUT outside of syncpoint to bypass the log. So for purposes of an audit you either need to use API-level tracing or else be able to prove to the auditor that your programs do everything inside of syncpoint and therefore the dmpmqlog output is complete.

Trying to find a single or very few messages that appear to have been processed but for which there is no log entry could REALLY screw up your day, your audit, your relationship with upper management, etc.

(Do not confuse this with the restaurant management API that can recall service staff from the golf course on their day off when there's a sudden surge in business. That is the "Get To Putting Waiter" API call and is completely different.)

Kind regards,
-- T.Rob

T.Robert Wyatt, Managing partner
IoPT Consulting, LLC
+1 704-443-TROB (8762) Voice/Text
[phone] Voice
https://ioptconsulting.com<https://ioptconsulting.com/>
https://twitter.com/tdotrob

From: MQSeries List [mailto:MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org] On Behalf Of Andrew Hickson
Sent: Wednesday, October 08, 2014 4:52 AM
To: MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org<mailto:MQSERIES-0lvw86wZMd9k/***@public.gmane.orgAC.AT>
Subject: Re: Does an mq trace trap the data payloads that are moving thru the qmgr?

If you're using linear logging then all of the message data (control information + payload) for persistent messages is recorded in the recovery log, and can be post processed with the dmpmqlog utility.
If you're using circular logging then you've effectively got a wrap around history of the last X bytes of persistent data, however getting to all of that data (e.g. dmpmqlog) is much more difficult and typically requires the help of MQ L3.
The main advantage of using the recovery log for this purpose is that there's no performance overhead.
The main disadvantage of using the recovery log for this purpose is that the information isn't in a form that's very easy to process/consume.





From: "T.Rob" <t.rob-CkT6zf+urXSzW/GOMZKyElesiRL1/***@public.gmane.org<mailto:***@IOPTCONSULTING.COM>>
To: MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org<mailto:MQSERIES-0lvw86wZMd8hNtF/***@public.gmane.orgNIWIEN.AC.AT>,
Date: 08/10/2014 09:41
Subject: Re: Does an mq trace trap the data payloads that are moving thru the qmgr?
Sent by: MQSeries List <MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org<mailto:MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org>>
________________________________




If you use the MA0W trace exit I believe that you can specify capturing just
the headers. I do recall though a conversation with Ralph Bateman about how
Support often receives traces and FDC files in PMRs that are filled with
PII, medical data, SSN's, card numbers, etc. So I believe the answer is
"yes." That said, the WMQ native trace can get real big, real fast so you
may want to look at MA0W which traces only API calls and not internals, SSL,
comms, etc.

http://ibm.co/SupptPacMA0W


Kind regards,
-- T.Rob


> -----Original Message-----
> From: MQSeries List [mailto:MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org] On Behalf
> Of Costa, D. (Damian)
> Sent: Wednesday, October 08, 2014 4:00 AM
> To: MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org<mailto:MQSERIES-0lvw86wZMd9k/***@public.gmane.orgN.AC.AT>
> Subject: Does an mq trace trap the data payloads that are moving thru the
> qmgr?
>
> HI all,
> I Was just asked to supply the audit traces of all messages going through
> a particular queue on a test qmgr. Naturally I can't just do that as no
> audit logs exist. So I was wondering if I could fudge it by running an mq
> trace to trap the message payloads being processed off said queue.
> Izzat even possible?
>
> ********************
> Nedbank Limited Reg No 1951/000009/06. The following link displays the
> names of the Nedbank Board of Directors and Company Secretary.
> [ http://www.nedbank.co.za/terms/DirectorsNedbank.htm ] This email is
> confidential and is intended for the addressee only.
> The following link will take you to Nedbank's legal notice.
> [ http://www.nedbank.co.za/terms/EmailDisclaimer.htm ]
> ********************
>
> To unsubscribe, write to LISTSERV-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org<mailto:LISTSERV-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org> and, in the
> message body (not the subject), write: SIGNOFF MQSERIES Instructions for
> managing your mailing list subscription are provided in the Listserv
> General Users Guide available at http://www.lsoft.com<http://www.lsoft.com/>
> Archive: http://listserv.meduniwien.ac.at/archives/mqser-l.html

To unsubscribe, write to LISTSERV-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org<mailto:***@LISTSERV.MEDUNIWIEN.AC.AT> and,
in the message body (not the subject), write: SIGNOFF MQSERIES
Instructions for managing your mailing list subscription are provided in
the Listserv General Users Guide available at http://www.lsoft.com<http://www.lsoft.com/>
Archive: http://listserv.meduniwien.ac.at/archives/mqser-l.html



Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number 741598.
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU
________________________________

List Archive<http://listserv.meduniwien.ac.at/archives/mqser-l.html> - Manage Your List Settings<http://listserv.meduniwien.ac.at/cgi-bin/wa?SUBED1=mqser-l&A=1> - Unsubscribe<mailto:LISTSERV-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org?subject=Unsubscribe&BODY=signoff%20mqseries>

Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com<http://www.lsoft.com/resources/manuals.asp>


________________________________

List Archive<http://listserv.meduniwien.ac.at/archives/mqser-l.html> - Manage Your List Settings<http://listserv.meduniwien.ac.at/cgi-bin/wa?SUBED1=mqser-l&A=1> - Unsubscribe<mailto:LISTSERV-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org?subject=Unsubscribe&BODY=signoff%20mqseries>

Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com<http://www.lsoft.com/resources/manuals.asp>


________________________________

List Archive<http://listserv.meduniwien.ac.at/archives/mqser-l.html> - Manage Your List Settings<http://listserv.meduniwien.ac.at/cgi-bin/wa?SUBED1=mqser-l&A=1> - Unsubscribe<mailto:LISTSERV-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org?subject=Unsubscribe&BODY=signoff%20mqseries>

Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com<http://www.lsoft.com/resources/manuals.asp>

********************
Nedbank Limited Reg No 1951/000009/06. The following link displays
the names of the Nedbank Board of Directors and Company Secretary.
[ http://www.nedbank.co.za/terms/DirectorsNedbank.htm ]
This email is confidential and is intended for the addressee only.
The following link will take you to Nedbank's legal notice.
[ http://www.nedbank.co.za/terms/EmailDisclaimer.htm ]
********************


________________________________

List Archive<http://listserv.meduniwien.ac.at/archives/mqser-l.html> - Manage Your List Settings<http://listserv.meduniwien.ac.at/cgi-bin/wa?SUBED1=mqser-l&A=1> - Unsubscribe<mailto:LISTSERV-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org?subject=Unsubscribe&BODY=signoff%20mqseries>

Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com<http://www.lsoft.com/resources/manuals.asp>



________________________________
List Archive<http://listserv.meduniwien.ac.at/archives/mqser-l.html> - Manage Your List Settings<http://listserv.meduniwien.ac.at/cgi-bin/wa?SUBED1=mqser-l&A=1> - Unsubscribe<mailto:LISTSERV-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org?subject=Unsubscribe&BODY=signoff%20mqseries>

Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com<http://www.lsoft.com/resources/manuals.asp>

________________________________
List Archive<http://listserv.meduniwien.ac.at/archives/mqser-l.html> - Manage Your List Settings<http://listserv.meduniwien.ac.at/cgi-bin/wa?SUBED1=mqser-l&A=1> - Unsubscribe<mailto:LISTSERV-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org?subject=Unsubscribe&BODY=signoff%20mqseries>

Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com<http://www.lsoft.com/resources/manuals.asp>

********************
Nedbank Limited Reg No 1951/000009/06. The following link displays
the names of the Nedbank Board of Directors and Company Secretary.
[ http://www.nedbank.co.za/terms/DirectorsNedbank.htm ]
This email is confidential and is intended for the addressee only.
The following link will take you to Nedbank's legal notice.
[ http://www.nedbank.co.za/terms/EmailDisclaimer.htm ]
********************

________________________________
List Archive<http://listserv.meduniwien.ac.at/archives/mqser-l.html> - Manage Your List Settings<http://listserv.meduniwien.ac.at/cgi-bin/wa?SUBED1=mqser-l&A=1> - Unsubscribe<mailto:LISTSERV-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org?subject=Unsubscribe&BODY=signoff%20mqseries>

Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com<http://www.lsoft.com/resources/manuals.asp>


________________________________
List Archive<http://listserv.meduniwien.ac.at/archives/mqser-l.html> - Manage Your List Settings<http://listserv.meduniwien.ac.at/cgi-bin/wa?SUBED1=mqser-l&A=1> - Unsubscribe<mailto:LISTSERV-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org?subject=Unsubscribe&BODY=signoff%20mqseries>

Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com<http://www.lsoft.com/resources/manuals.asp>

********************
Nedbank Limited Reg No 1951/000009/06. The following link displays
the names of the Nedbank Board of Directors and Company Secretary.
[ http://www.nedbank.co.za/terms/DirectorsNedbank.htm ]
This email is confidential and is intended for the addressee only.
The following link will take you to Nedbank's legal notice.
[ http://www.nedbank.co.za/terms/EmailDisclaimer.htm ]
********************

________________________________
List Archive<http://listserv.meduniwien.ac.at/archives/mqser-l.html> - Manage Your List Settings<http://listserv.meduniwien.ac.at/cgi-bin/wa?SUBED1=mqser-l&A=1> - Unsubscribe<mailto:LISTSERV-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org?subject=Unsubscribe&BODY=signoff%20mqseries>

Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com<http://www.lsoft.com/resources/manuals.asp>

________________________________
List Archive<http://listserv.meduniwien.ac.at/archives/mqser-l.html> - Manage Your List Settings<http://listserv.meduniwien.ac.at/cgi-bin/wa?SUBED1=mqser-l&A=1> - Unsubscribe<mailto:LISTSERV-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org?subject=Unsubscribe&BODY=signoff%20mqseries>

Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com<http://www.lsoft.com/resources/manuals.asp>

********************
Nedbank Limited Reg No 1951/000009/06. The following link displays
the names of the Nedbank Board of Directors and Company Secretary.
[ http://www.nedbank.co.za/terms/DirectorsNedbank.htm ]
This email is confidential and is intended for the addressee only.
The following link will take you to Nedbank's legal notice.
[ http://www.nedbank.co.za/terms/EmailDisclaimer.htm ]
********************

________________________________
List Archive<http://listserv.meduniwien.ac.at/archives/mqser-l.html> - Manage Your List Settings<http://listserv.meduniwien.ac.at/cgi-bin/wa?SUBED1=mqser-l&A=1> - Unsubscribe<mailto:LISTSERV-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org?subject=Unsubscribe&BODY=signoff%20mqseries>

Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com<http://www.lsoft.com/resources/manuals.asp>

________________________________
List Archive<http://listserv.meduniwien.ac.at/archives/mqser-l.html> - Manage Your List Settings<http://listserv.meduniwien.ac.at/cgi-bin/wa?SUBED1=mqser-l&A=1> - Unsubscribe<mailto:LISTSERV-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org?subject=Unsubscribe&BODY=signoff%20mqseries>

Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com<http://www.lsoft.com/resources/manuals.asp>

********************
Nedbank Limited Reg No 1951/000009/06. The following link displays
the names of the Nedbank Board of Directors and Company Secretary.
[ http://www.nedbank.co.za/terms/DirectorsNedbank.htm ]
This email is confidential and is intended for the addressee only.
The following link will take you to Nedbank's legal notice.
[ http://www.nedbank.co.za/terms/EmailDisclaimer.htm ]
********************

To unsubscribe, write to LISTSERV-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org and,
in the message body (not the subject), write: SIGNOFF MQSERIES
Instructions for managing your mailing list subscription are provided in
the Listserv General Users Guide available at http://www.lsoft.com
Archive: http://listserv.meduniwien.ac.at/archives/mqser-l.html

[Tim Zielke]

For your reference:

strmqtrc at 7.0* has the capability to trace the message content with the "-d" switch.

If this is an intermittent issue but reveals itself with some type of application log message, a makeshift "SLIP TRAP" could be set up with a script to look for that log message and then turn the trace off when it is encountered. This could give you a trace that includes the message content plus the API calls leading up to the issue. You would probably also want to leverage the strmqtrc "-l" switch with this approach, which sets a size limit on the trace files.

From: MQSeries List [mailto:MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org] On Behalf Of Costa, D. (Damian)
Sent: Friday, October 10, 2014 6:44 AM
To: MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org
Subject: Re: Does an mq trace trap the data payloads that are moving thru the qmgr?

And it's at V 7.0* only going to V 7.1 next month or later this month. Sob. So no activity trace for me.


From: MQSeries List [mailto:MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org] On Behalf Of Tim Zielke
Sent: 09 October 2014 04:59 PM
To: MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org<mailto:MQSERIES-0lvw86wZMd9k/***@public.gmane.orgAC.AT>
Subject: Re: Does an mq trace trap the data payloads that are moving thru the qmgr?

An Activity Trace could be very telling. For example, their application could be doing a GET and not handling a non-zero reason code properly. Inadvertently, they could be throwing the message away and not logging the error, which to the application looks like MQ "lost my message". I have used the Activity Trace to help look into situations similar to this, and it is very helpful, as it lets you look under the covers at what the application is doing.

It is similar to a cookie jar that is missing cookies, and the child says "I didn't take it!". And then you can show them the picture of them with their hand in the cookie jar . . . :-).

From: MQSeries List [mailto:MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org] On Behalf Of Costa, D. (Damian)
Sent: Thursday, October 09, 2014 9:32 AM
To: MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org<mailto:MQSERIES-0lvw86wZMd9k/***@public.gmane.orgAC.AT>
Subject: Re: Does an mq trace trap the data payloads that are moving thru the qmgr?

They admit nothing, deny everything. Hard to penetrate...

From: MQSeries List [mailto:MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org] On Behalf Of Tim Zielke
Sent: 09 October 2014 03:02 PM
To: MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org<mailto:MQSERIES-0lvw86wZMd9k/***@public.gmane.orgAC.AT>
Subject: Re: Does an mq trace trap the data payloads that are moving thru the qmgr?

Hi Damian,

Earlier in the thread you had mentioned:

"What is disappointing is that they cannot tell what their app is doing with the message. The MQ stats indicate they are taking them off the queue."

Just curious. Is the app claiming that they never did a GET on the message?


From: MQSeries List [mailto:MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org] On Behalf Of Costa, D. (Damian)
Sent: Thursday, October 09, 2014 3:02 AM
To: MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org<mailto:MQSERIES-0lvw86wZMd9k/***@public.gmane.orgAC.AT>
Subject: Re: Does an mq trace trap the data payloads that are moving thru the qmgr?

Aw crud! Oh well a twisted the dev's arm enough so they are adding additional logging logic to their app as we speak.
Worst comes to worst I will stop the channel back and trap the message on the xmitq queue on the responders side.


From: MQSeries List [mailto:MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org] On Behalf Of Neil Casey
Sent: 08 October 2014 11:45 PM
To: MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org<mailto:MQSERIES-0lvw86wZMd9k/***@public.gmane.orgAC.AT>
Subject: Re: Does an mq trace trap the data payloads that are moving thru the qmgr?

Hi Damian,

I agree that using a queue alias to a topic and then administrative subscriptions to copy the messages to 2 queues is a great capability.

But remember that it will change the message id, so if your application relies on message id (for example, to copy to correlation Id of the response) copying it this way will break the application. :-(

We've had discussions on the list about this before, and there is at least one RFE asking for the ability to keep the message id identical.
http://www.ibm.com/developerworks/rfe/execute?use_case=viewRfe&CR_ID=35062

Regards,

Neil Casey.


On 9 Oct 2014, at 2:37 am, Costa, D. (Damian) <DamianC-3zJjxGF14/***@public.gmane.org<mailto:DamianC-3zJjxGF14/***@public.gmane.org>> wrote:

Great idea re the topic queue. Will go setup and see what is happening.


From: MQSeries List [mailto:MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org] On Behalf Of Jefferson Lowrey
Sent: 08 October 2014 03:52 PM
To: MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org<mailto:MQSERIES-0lvw86wZMd9k/***@public.gmane.orgAC.AT>
Subject: Re: Does an mq trace trap the data payloads that are moving thru the qmgr?

The other thing you can do is (mis) use pub/sub and reroute messages that are supposed to go to the application input queue to a topic instead, and then create two admin subscriptions - one to the original input queue and one to a different queue - something that just gets dumped to a text file (perhaps by qload or etc.)

This is the basic replacement for mirrorq as of v7's pub/sub function. If, somehow, you're still at <v7, you can test your googlefu by trying to find some copy of the mirrorq source code to compile.

Thank you,

Jeff Lowrey




From: Tim Zielke <tim.zielke-PR+tvw7B/***@public.gmane.org<mailto:tim.zielke-PR+tvw7B/***@public.gmane.org>>
To: MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org<mailto:MQSERIES-0lvw86wZMd8hNtF/***@public.gmane.orgNIWIEN.AC.AT>
Date: 10/08/2014 08:01 AM
Subject: Re: [MQSERIES] Does an mq trace trap the data payloads that are moving thru the qmgr?
Sent by: MQSeries List <MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org<mailto:MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org>>
________________________________



If this is more something temporary to help debug an issue, then I would go with the Activity Trace (if you are at >= 7.1) over standard tracing (i.e. strmqtrc).

For viewing the AAT data, there are significant enhancements to the amqsact program (called amqsactz) that I find helpful -> http://www.capitalware.com/mq_code_c.html

You do need a C compiler to build it for your platform, but I provide some examples in the comments of the program on how to do this on Windows or Linux. The MQ manual, of course, covers all environments for building an MQ program written in C.

Thanks,
Tim

From: MQSeries List [mailto:MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org] On Behalf Of Costa, D. (Damian)
Sent: Wednesday, October 08, 2014 7:45 AM
To: MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org<mailto:MQSERIES-0lvw86wZMd9k/***@public.gmane.orgAC.AT>
Subject: Re: Does an mq trace trap the data payloads that are moving thru the qmgr?

Swat I tole 'em..... improve their logging from their apps.
What is disappointing is that they cannot tell what their app is doing with the message. The MQ stats indicate they are taking them off the queue.
Heaven only know where they go from there.

From: MQSeries List [mailto:MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org] On Behalf Of Tim Zielke
Sent: 08 October 2014 02:07 PM
To: MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org<mailto:MQSERIES-0lvw86wZMd9k/***@public.gmane.orgAC.AT>
Subject: Re: Does an mq trace trap the data payloads that are moving thru the qmgr?

Hi Damian,

If your queue manager is 7.1 or higher, another option is the Application Activity Trace.

This IBM article on the AAT -> http://www.ibm.com/developerworks/websphere/library/techarticles/1306_bushby/1306_bushby.html

does give the scenario of "Using Application Activity Trace to keep an audit trail of messages" as one of the AAT's uses.

Personally, I would be hesitant to do what you are being asked to do, and would like to understand from the application team why their application can not do this logging, itself. Do they really need the entire message, or is it really key pieces of data that they could put into an application log.

Thanks,
Tim

From: MQSeries List [mailto:MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org] On Behalf Of T.Rob
Sent: Wednesday, October 08, 2014 4:17 AM
To: MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org<mailto:MQSERIES-0lvw86wZMd9k/***@public.gmane.orgAC.AT>
Subject: Re: Does an mq trace trap the data payloads that are moving thru the qmgr?

I think that's *most* of the persistent data. At MQTC Mark Taylor gave the MQ Internals session and said that the Put To Waiting Getter optimization permits certain persistent messages that are PUT outside of syncpoint to bypass the log. So for purposes of an audit you either need to use API-level tracing or else be able to prove to the auditor that your programs do everything inside of syncpoint and therefore the dmpmqlog output is complete.

Trying to find a single or very few messages that appear to have been processed but for which there is no log entry could REALLY screw up your day, your audit, your relationship with upper management, etc.

(Do not confuse this with the restaurant management API that can recall service staff from the golf course on their day off when there's a sudden surge in business. That is the "Get To Putting Waiter" API call and is completely different.)

Kind regards,
-- T.Rob

T.Robert Wyatt, Managing partner
IoPT Consulting, LLC
+1 704-443-TROB (8762) Voice/Text
[phone] Voice
https://ioptconsulting.com<https://ioptconsulting.com/>
https://twitter.com/tdotrob

From: MQSeries List [mailto:MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org] On Behalf Of Andrew Hickson
Sent: Wednesday, October 08, 2014 4:52 AM
To: MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org<mailto:MQSERIES-0lvw86wZMd9k/***@public.gmane.orgAC.AT>
Subject: Re: Does an mq trace trap the data payloads that are moving thru the qmgr?

If you're using linear logging then all of the message data (control information + payload) for persistent messages is recorded in the recovery log, and can be post processed with the dmpmqlog utility.
If you're using circular logging then you've effectively got a wrap around history of the last X bytes of persistent data, however getting to all of that data (e.g. dmpmqlog) is much more difficult and typically requires the help of MQ L3.
The main advantage of using the recovery log for this purpose is that there's no performance overhead.
The main disadvantage of using the recovery log for this purpose is that the information isn't in a form that's very easy to process/consume.





From: "T.Rob" <t.rob-CkT6zf+urXSzW/GOMZKyElesiRL1/***@public.gmane.org<mailto:***@IOPTCONSULTING.COM>>
To: MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org<mailto:MQSERIES-0lvw86wZMd8hNtF/***@public.gmane.orgNIWIEN.AC.AT>,
Date: 08/10/2014 09:41
Subject: Re: Does an mq trace trap the data payloads that are moving thru the qmgr?
Sent by: MQSeries List <MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org<mailto:MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org>>
________________________________




If you use the MA0W trace exit I believe that you can specify capturing just
the headers. I do recall though a conversation with Ralph Bateman about how
Support often receives traces and FDC files in PMRs that are filled with
PII, medical data, SSN's, card numbers, etc. So I believe the answer is
"yes." That said, the WMQ native trace can get real big, real fast so you
may want to look at MA0W which traces only API calls and not internals, SSL,
comms, etc.

http://ibm.co/SupptPacMA0W


Kind regards,
-- T.Rob


> -----Original Message-----
> From: MQSeries List [mailto:MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org] On Behalf
> Of Costa, D. (Damian)
> Sent: Wednesday, October 08, 2014 4:00 AM
> To: MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org<mailto:MQSERIES-0lvw86wZMd9k/***@public.gmane.orgN.AC.AT>
> Subject: Does an mq trace trap the data payloads that are moving thru the
> qmgr?
>
> HI all,
> I Was just asked to supply the audit traces of all messages going through
> a particular queue on a test qmgr. Naturally I can't just do that as no
> audit logs exist. So I was wondering if I could fudge it by running an mq
> trace to trap the message payloads being processed off said queue.
> Izzat even possible?
>
> ********************
> Nedbank Limited Reg No 1951/000009/06. The following link displays the
> names of the Nedbank Board of Directors and Company Secretary.
> [ http://www.nedbank.co.za/terms/DirectorsNedbank.htm ] This email is
> confidential and is intended for the addressee only.
> The following link will take you to Nedbank's legal notice.
> [ http://www.nedbank.co.za/terms/EmailDisclaimer.htm ]
> ********************
>
> To unsubscribe, write to LISTSERV-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org<mailto:LISTSERV-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org> and, in the
> message body (not the subject), write: SIGNOFF MQSERIES Instructions for
> managing your mailing list subscription are provided in the Listserv
> General Users Guide available at http://www.lsoft.com<http://www.lsoft.com/>
> Archive: http://listserv.meduniwien.ac.at/archives/mqser-l.html

To unsubscribe, write to LISTSERV-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org<mailto:***@LISTSERV.MEDUNIWIEN.AC.AT> and,
in the message body (not the subject), write: SIGNOFF MQSERIES
Instructions for managing your mailing list subscription are provided in
the Listserv General Users Guide available at http://www.lsoft.com<http://www.lsoft.com/>
Archive: http://listserv.meduniwien.ac.at/archives/mqser-l.html



Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number 741598.
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU
________________________________

List Archive<http://listserv.meduniwien.ac.at/archives/mqser-l.html> - Manage Your List Settings<http://listserv.meduniwien.ac.at/cgi-bin/wa?SUBED1=mqser-l&A=1> - Unsubscribe<mailto:LISTSERV-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org?subject=Unsubscribe&BODY=signoff%20mqseries>

Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com<http://www.lsoft.com/resources/manuals.asp>


________________________________

List Archive<http://listserv.meduniwien.ac.at/archives/mqser-l.html> - Manage Your List Settings<http://listserv.meduniwien.ac.at/cgi-bin/wa?SUBED1=mqser-l&A=1> - Unsubscribe<mailto:LISTSERV-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org?subject=Unsubscribe&BODY=signoff%20mqseries>

Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com<http://www.lsoft.com/resources/manuals.asp>


________________________________

List Archive<http://listserv.meduniwien.ac.at/archives/mqser-l.html> - Manage Your List Settings<http://listserv.meduniwien.ac.at/cgi-bin/wa?SUBED1=mqser-l&A=1> - Unsubscribe<mailto:LISTSERV-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org?subject=Unsubscribe&BODY=signoff%20mqseries>

Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com<http://www.lsoft.com/resources/manuals.asp>

********************
Nedbank Limited Reg No 1951/000009/06. The following link displays
the names of the Nedbank Board of Directors and Company Secretary.
[ http://www.nedbank.co.za/terms/DirectorsNedbank.htm ]
This email is confidential and is intended for the addressee only.
The following link will take you to Nedbank's legal notice.
[ http://www.nedbank.co.za/terms/EmailDisclaimer.htm ]
********************


________________________________

List Archive<http://listserv.meduniwien.ac.at/archives/mqser-l.html> - Manage Your List Settings<http://listserv.meduniwien.ac.at/cgi-bin/wa?SUBED1=mqser-l&A=1> - Unsubscribe<mailto:LISTSERV-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org?subject=Unsubscribe&BODY=signoff%20mqseries>

Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com<http://www.lsoft.com/resources/manuals.asp>



________________________________
List Archive<http://listserv.meduniwien.ac.at/archives/mqser-l.html> - Manage Your List Settings<http://listserv.meduniwien.ac.at/cgi-bin/wa?SUBED1=mqser-l&A=1> - Unsubscribe<mailto:LISTSERV-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org?subject=Unsubscribe&BODY=signoff%20mqseries>

Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com<http://www.lsoft.com/resources/manuals.asp>

________________________________
List Archive<http://listserv.meduniwien.ac.at/archives/mqser-l.html> - Manage Your List Settings<http://listserv.meduniwien.ac.at/cgi-bin/wa?SUBED1=mqser-l&A=1> - Unsubscribe<mailto:LISTSERV-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org?subject=Unsubscribe&BODY=signoff%20mqseries>

Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com<http://www.lsoft.com/resources/manuals.asp>

********************
Nedbank Limited Reg No 1951/000009/06. The following link displays
the names of the Nedbank Board of Directors and Company Secretary.
[ http://www.nedbank.co.za/terms/DirectorsNedbank.htm ]
This email is confidential and is intended for the addressee only.
The following link will take you to Nedbank's legal notice.
[ http://www.nedbank.co.za/terms/EmailDisclaimer.htm ]
********************

________________________________
List Archive<http://listserv.meduniwien.ac.at/archives/mqser-l.html> - Manage Your List Settings<http://listserv.meduniwien.ac.at/cgi-bin/wa?SUBED1=mqser-l&A=1> - Unsubscribe<mailto:LISTSERV-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org?subject=Unsubscribe&BODY=signoff%20mqseries>

Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com<http://www.lsoft.com/resources/manuals.asp>


________________________________
List Archive<http://listserv.meduniwien.ac.at/archives/mqser-l.html> - Manage Your List Settings<http://listserv.meduniwien.ac.at/cgi-bin/wa?SUBED1=mqser-l&A=1> - Unsubscribe<mailto:LISTSERV-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org?subject=Unsubscribe&BODY=signoff%20mqseries>

Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com<http://www.lsoft.com/resources/manuals.asp>

********************
Nedbank Limited Reg No 1951/000009/06. The following link displays
the names of the Nedbank Board of Directors and Company Secretary.
[ http://www.nedbank.co.za/terms/DirectorsNedbank.htm ]
This email is confidential and is intended for the addressee only.
The following link will take you to Nedbank's legal notice.
[ http://www.nedbank.co.za/terms/EmailDisclaimer.htm ]
********************

________________________________
List Archive<http://listserv.meduniwien.ac.at/archives/mqser-l.html> - Manage Your List Settings<http://listserv.meduniwien.ac.at/cgi-bin/wa?SUBED1=mqser-l&A=1> - Unsubscribe<mailto:LISTSERV-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org?subject=Unsubscribe&BODY=signoff%20mqseries>

Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com<http://www.lsoft.com/resources/manuals.asp>

________________________________
List Archive<http://listserv.meduniwien.ac.at/archives/mqser-l.html> - Manage Your List Settings<http://listserv.meduniwien.ac.at/cgi-bin/wa?SUBED1=mqser-l&A=1> - Unsubscribe<mailto:LISTSERV-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org?subject=Unsubscribe&BODY=signoff%20mqseries>

Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com<http://www.lsoft.com/resources/manuals.asp>

********************
Nedbank Limited Reg No 1951/000009/06. The following link displays
the names of the Nedbank Board of Directors and Company Secretary.
[ http://www.nedbank.co.za/terms/DirectorsNedbank.htm ]
This email is confidential and is intended for the addressee only.
The following link will take you to Nedbank's legal notice.
[ http://www.nedbank.co.za/terms/EmailDisclaimer.htm ]
********************

________________________________
List Archive<http://listserv.meduniwien.ac.at/archives/mqser-l.html> - Manage Your List Settings<http://listserv.meduniwien.ac.at/cgi-bin/wa?SUBED1=mqser-l&A=1> - Unsubscribe<mailto:LISTSERV-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org?subject=Unsubscribe&BODY=signoff%20mqseries>

Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com<http://www.lsoft.com/resources/manuals.asp>

________________________________
List Archive<http://listserv.meduniwien.ac.at/archives/mqser-l.html> - Manage Your List Settings<http://listserv.meduniwien.ac.at/cgi-bin/wa?SUBED1=mqser-l&A=1> - Unsubscribe<mailto:LISTSERV-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org?subject=Unsubscribe&BODY=signoff%20mqseries>

Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com<http://www.lsoft.com/resources/manuals.asp>

********************
Nedbank Limited Reg No 1951/000009/06. The following link displays
the names of the Nedbank Board of Directors and Company Secretary.
[ http://www.nedbank.co.za/terms/DirectorsNedbank.htm ]
This email is confidential and is intended for the addressee only.
The following link will take you to Nedbank's legal notice.
[ http://www.nedbank.co.za/terms/EmailDisclaimer.htm ]
********************

________________________________
List Archive<http://listserv.meduniwien.ac.at/archives/mqser-l.html> - Manage Your List Settings<http://listserv.meduniwien.ac.at/cgi-bin/wa?SUBED1=mqser-l&A=1> - Unsubscribe<mailto:LISTSERV-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org?subject=Unsubscribe&BODY=signoff%20mqseries>

Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com<http://www.lsoft.com/resources/manuals.asp>

To unsubscribe, write to LISTSERV-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org and,
in the message body (not the subject), write: SIGNOFF MQSERIES
Instructions for managing your mailing list subscription are provided in
the Listserv General Users Guide available at http://www.lsoft.com
Archive: http://listserv.meduniwien.ac.at/archives/mqser-l.html

[Costa, D. (Damian)]

Every message gets the same treatment . I'll see what they come back with after they've added their extra logging capability into their application.
Thanks Tim!


From: MQSeries List [mailto:MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org] On Behalf Of Tim Zielke
Sent: 13 October 2014 03:12 PM
To: MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org
Subject: Re: Does an mq trace trap the data payloads that are moving thru the qmgr?

For your reference:

strmqtrc at 7.0* has the capability to trace the message content with the "-d" switch.

If this is an intermittent issue but reveals itself with some type of application log message, a makeshift "SLIP TRAP" could be set up with a script to look for that log message and then turn the trace off when it is encountered. This could give you a trace that includes the message content plus the API calls leading up to the issue. You would probably also want to leverage the strmqtrc "-l" switch with this approach, which sets a size limit on the trace files.

From: MQSeries List [mailto:MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org] On Behalf Of Costa, D. (Damian)
Sent: Friday, October 10, 2014 6:44 AM
To: MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org<mailto:MQSERIES-0lvw86wZMd9k/***@public.gmane.orgAC.AT>
Subject: Re: Does an mq trace trap the data payloads that are moving thru the qmgr?

And it's at V 7.0* only going to V 7.1 next month or later this month. Sob. So no activity trace for me.


From: MQSeries List [mailto:MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org] On Behalf Of Tim Zielke
Sent: 09 October 2014 04:59 PM
To: MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org<mailto:MQSERIES-0lvw86wZMd9k/***@public.gmane.orgAC.AT>
Subject: Re: Does an mq trace trap the data payloads that are moving thru the qmgr?

An Activity Trace could be very telling. For example, their application could be doing a GET and not handling a non-zero reason code properly. Inadvertently, they could be throwing the message away and not logging the error, which to the application looks like MQ "lost my message". I have used the Activity Trace to help look into situations similar to this, and it is very helpful, as it lets you look under the covers at what the application is doing.

It is similar to a cookie jar that is missing cookies, and the child says "I didn't take it!". And then you can show them the picture of them with their hand in the cookie jar . . . :-).

From: MQSeries List [mailto:MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org] On Behalf Of Costa, D. (Damian)
Sent: Thursday, October 09, 2014 9:32 AM
To: MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org<mailto:MQSERIES-0lvw86wZMd9k/***@public.gmane.orgAC.AT>
Subject: Re: Does an mq trace trap the data payloads that are moving thru the qmgr?

They admit nothing, deny everything. Hard to penetrate...

From: MQSeries List [mailto:MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org] On Behalf Of Tim Zielke
Sent: 09 October 2014 03:02 PM
To: MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org<mailto:MQSERIES-0lvw86wZMd9k/***@public.gmane.orgAC.AT>
Subject: Re: Does an mq trace trap the data payloads that are moving thru the qmgr?

Hi Damian,

Earlier in the thread you had mentioned:

"What is disappointing is that they cannot tell what their app is doing with the message. The MQ stats indicate they are taking them off the queue."

Just curious. Is the app claiming that they never did a GET on the message?


From: MQSeries List [mailto:MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org] On Behalf Of Costa, D. (Damian)
Sent: Thursday, October 09, 2014 3:02 AM
To: MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org<mailto:MQSERIES-0lvw86wZMd9k/***@public.gmane.orgAC.AT>
Subject: Re: Does an mq trace trap the data payloads that are moving thru the qmgr?

Aw crud! Oh well a twisted the dev's arm enough so they are adding additional logging logic to their app as we speak.
Worst comes to worst I will stop the channel back and trap the message on the xmitq queue on the responders side.


From: MQSeries List [mailto:MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org] On Behalf Of Neil Casey
Sent: 08 October 2014 11:45 PM
To: MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org<mailto:MQSERIES-0lvw86wZMd9k/***@public.gmane.orgAC.AT>
Subject: Re: Does an mq trace trap the data payloads that are moving thru the qmgr?

Hi Damian,

I agree that using a queue alias to a topic and then administrative subscriptions to copy the messages to 2 queues is a great capability.

But remember that it will change the message id, so if your application relies on message id (for example, to copy to correlation Id of the response) copying it this way will break the application. :-(

We've had discussions on the list about this before, and there is at least one RFE asking for the ability to keep the message id identical.
http://www.ibm.com/developerworks/rfe/execute?use_case=viewRfe&CR_ID=35062

Regards,

Neil Casey.


On 9 Oct 2014, at 2:37 am, Costa, D. (Damian) <DamianC-3zJjxGF14/***@public.gmane.org<mailto:DamianC-3zJjxGF14/***@public.gmane.org>> wrote:

Great idea re the topic queue. Will go setup and see what is happening.


From: MQSeries List [mailto:MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org] On Behalf Of Jefferson Lowrey
Sent: 08 October 2014 03:52 PM
To: MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org<mailto:MQSERIES-0lvw86wZMd9k/***@public.gmane.orgAC.AT>
Subject: Re: Does an mq trace trap the data payloads that are moving thru the qmgr?

The other thing you can do is (mis) use pub/sub and reroute messages that are supposed to go to the application input queue to a topic instead, and then create two admin subscriptions - one to the original input queue and one to a different queue - something that just gets dumped to a text file (perhaps by qload or etc.)

This is the basic replacement for mirrorq as of v7's pub/sub function. If, somehow, you're still at <v7, you can test your googlefu by trying to find some copy of the mirrorq source code to compile.

Thank you,

Jeff Lowrey




From: Tim Zielke <tim.zielke-PR+tvw7B/***@public.gmane.org<mailto:tim.zielke-PR+tvw7B/***@public.gmane.org>>
To: MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org<mailto:MQSERIES-0lvw86wZMd8hNtF/***@public.gmane.orgNIWIEN.AC.AT>
Date: 10/08/2014 08:01 AM
Subject: Re: [MQSERIES] Does an mq trace trap the data payloads that are moving thru the qmgr?
Sent by: MQSeries List <MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org<mailto:MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org>>
________________________________



If this is more something temporary to help debug an issue, then I would go with the Activity Trace (if you are at >= 7.1) over standard tracing (i.e. strmqtrc).

For viewing the AAT data, there are significant enhancements to the amqsact program (called amqsactz) that I find helpful -> http://www.capitalware.com/mq_code_c.html

You do need a C compiler to build it for your platform, but I provide some examples in the comments of the program on how to do this on Windows or Linux. The MQ manual, of course, covers all environments for building an MQ program written in C.

Thanks,
Tim

From: MQSeries List [mailto:MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org] On Behalf Of Costa, D. (Damian)
Sent: Wednesday, October 08, 2014 7:45 AM
To: MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org<mailto:MQSERIES-0lvw86wZMd9k/***@public.gmane.orgAC.AT>
Subject: Re: Does an mq trace trap the data payloads that are moving thru the qmgr?

Swat I tole 'em..... improve their logging from their apps.
What is disappointing is that they cannot tell what their app is doing with the message. The MQ stats indicate they are taking them off the queue.
Heaven only know where they go from there.

From: MQSeries List [mailto:MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org] On Behalf Of Tim Zielke
Sent: 08 October 2014 02:07 PM
To: MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org<mailto:MQSERIES-0lvw86wZMd9k/***@public.gmane.orgAC.AT>
Subject: Re: Does an mq trace trap the data payloads that are moving thru the qmgr?

Hi Damian,

If your queue manager is 7.1 or higher, another option is the Application Activity Trace.

This IBM article on the AAT -> http://www.ibm.com/developerworks/websphere/library/techarticles/1306_bushby/1306_bushby.html

does give the scenario of "Using Application Activity Trace to keep an audit trail of messages" as one of the AAT's uses.

Personally, I would be hesitant to do what you are being asked to do, and would like to understand from the application team why their application can not do this logging, itself. Do they really need the entire message, or is it really key pieces of data that they could put into an application log.

Thanks,
Tim

From: MQSeries List [mailto:MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org] On Behalf Of T.Rob
Sent: Wednesday, October 08, 2014 4:17 AM
To: MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org<mailto:MQSERIES-0lvw86wZMd9k/***@public.gmane.orgAC.AT>
Subject: Re: Does an mq trace trap the data payloads that are moving thru the qmgr?

I think that's *most* of the persistent data. At MQTC Mark Taylor gave the MQ Internals session and said that the Put To Waiting Getter optimization permits certain persistent messages that are PUT outside of syncpoint to bypass the log. So for purposes of an audit you either need to use API-level tracing or else be able to prove to the auditor that your programs do everything inside of syncpoint and therefore the dmpmqlog output is complete.

Trying to find a single or very few messages that appear to have been processed but for which there is no log entry could REALLY screw up your day, your audit, your relationship with upper management, etc.

(Do not confuse this with the restaurant management API that can recall service staff from the golf course on their day off when there's a sudden surge in business. That is the "Get To Putting Waiter" API call and is completely different.)

Kind regards,
-- T.Rob

T.Robert Wyatt, Managing partner
IoPT Consulting, LLC
+1 704-443-TROB (8762) Voice/Text
[phone] Voice
https://ioptconsulting.com<https://ioptconsulting.com/>
https://twitter.com/tdotrob

From: MQSeries List [mailto:MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org] On Behalf Of Andrew Hickson
Sent: Wednesday, October 08, 2014 4:52 AM
To: MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org<mailto:MQSERIES-0lvw86wZMd9k/***@public.gmane.orgAC.AT>
Subject: Re: Does an mq trace trap the data payloads that are moving thru the qmgr?

If you're using linear logging then all of the message data (control information + payload) for persistent messages is recorded in the recovery log, and can be post processed with the dmpmqlog utility.
If you're using circular logging then you've effectively got a wrap around history of the last X bytes of persistent data, however getting to all of that data (e.g. dmpmqlog) is much more difficult and typically requires the help of MQ L3.
The main advantage of using the recovery log for this purpose is that there's no performance overhead.
The main disadvantage of using the recovery log for this purpose is that the information isn't in a form that's very easy to process/consume.





From: "T.Rob" <t.rob-CkT6zf+urXSzW/GOMZKyElesiRL1/***@public.gmane.org<mailto:***@IOPTCONSULTING.COM>>
To: MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org<mailto:MQSERIES-0lvw86wZMd8hNtF/***@public.gmane.orgNIWIEN.AC.AT>,
Date: 08/10/2014 09:41
Subject: Re: Does an mq trace trap the data payloads that are moving thru the qmgr?
Sent by: MQSeries List <MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org<mailto:MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org>>
________________________________




If you use the MA0W trace exit I believe that you can specify capturing just
the headers. I do recall though a conversation with Ralph Bateman about how
Support often receives traces and FDC files in PMRs that are filled with
PII, medical data, SSN's, card numbers, etc. So I believe the answer is
"yes." That said, the WMQ native trace can get real big, real fast so you
may want to look at MA0W which traces only API calls and not internals, SSL,
comms, etc.

http://ibm.co/SupptPacMA0W


Kind regards,
-- T.Rob


> -----Original Message-----
> From: MQSeries List [mailto:MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org] On Behalf
> Of Costa, D. (Damian)
> Sent: Wednesday, October 08, 2014 4:00 AM
> To: MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org<mailto:MQSERIES-0lvw86wZMd9k/***@public.gmane.orgN.AC.AT>
> Subject: Does an mq trace trap the data payloads that are moving thru the
> qmgr?
>
> HI all,
> I Was just asked to supply the audit traces of all messages going through
> a particular queue on a test qmgr. Naturally I can't just do that as no
> audit logs exist. So I was wondering if I could fudge it by running an mq
> trace to trap the message payloads being processed off said queue.
> Izzat even possible?
>
> ********************
> Nedbank Limited Reg No 1951/000009/06. The following link displays the
> names of the Nedbank Board of Directors and Company Secretary.
> [ http://www.nedbank.co.za/terms/DirectorsNedbank.htm ] This email is
> confidential and is intended for the addressee only.
> The following link will take you to Nedbank's legal notice.
> [ http://www.nedbank.co.za/terms/EmailDisclaimer.htm ]
> ********************
>
> To unsubscribe, write to LISTSERV-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org<mailto:LISTSERV-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org> and, in the
> message body (not the subject), write: SIGNOFF MQSERIES Instructions for
> managing your mailing list subscription are provided in the Listserv
> General Users Guide available at http://www.lsoft.com<http://www.lsoft.com/>
> Archive: http://listserv.meduniwien.ac.at/archives/mqser-l.html

To unsubscribe, write to LISTSERV-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org<mailto:***@LISTSERV.MEDUNIWIEN.AC.AT> and,
in the message body (not the subject), write: SIGNOFF MQSERIES
Instructions for managing your mailing list subscription are provided in
the Listserv General Users Guide available at http://www.lsoft.com<http://www.lsoft.com/>
Archive: http://listserv.meduniwien.ac.at/archives/mqser-l.html



Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number 741598.
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU
________________________________

List Archive<http://listserv.meduniwien.ac.at/archives/mqser-l.html> - Manage Your List Settings<http://listserv.meduniwien.ac.at/cgi-bin/wa?SUBED1=mqser-l&A=1> - Unsubscribe<mailto:LISTSERV-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org?subject=Unsubscribe&BODY=signoff%20mqseries>

Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com<http://www.lsoft.com/resources/manuals.asp>


________________________________

List Archive<http://listserv.meduniwien.ac.at/archives/mqser-l.html> - Manage Your List Settings<http://listserv.meduniwien.ac.at/cgi-bin/wa?SUBED1=mqser-l&A=1> - Unsubscribe<mailto:LISTSERV-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org?subject=Unsubscribe&BODY=signoff%20mqseries>

Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com<http://www.lsoft.com/resources/manuals.asp>


________________________________

List Archive<http://listserv.meduniwien.ac.at/archives/mqser-l.html> - Manage Your List Settings<http://listserv.meduniwien.ac.at/cgi-bin/wa?SUBED1=mqser-l&A=1> - Unsubscribe<mailto:LISTSERV-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org?subject=Unsubscribe&BODY=signoff%20mqseries>

Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com<http://www.lsoft.com/resources/manuals.asp>

********************
Nedbank Limited Reg No 1951/000009/06. The following link displays
the names of the Nedbank Board of Directors and Company Secretary.
[ http://www.nedbank.co.za/terms/DirectorsNedbank.htm ]
This email is confidential and is intended for the addressee only.
The following link will take you to Nedbank's legal notice.
[ http://www.nedbank.co.za/terms/EmailDisclaimer.htm ]
********************


________________________________

List Archive<http://listserv.meduniwien.ac.at/archives/mqser-l.html> - Manage Your List Settings<http://listserv.meduniwien.ac.at/cgi-bin/wa?SUBED1=mqser-l&A=1> - Unsubscribe<mailto:LISTSERV-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org?subject=Unsubscribe&BODY=signoff%20mqseries>

Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com<http://www.lsoft.com/resources/manuals.asp>



________________________________
List Archive<http://listserv.meduniwien.ac.at/archives/mqser-l.html> - Manage Your List Settings<http://listserv.meduniwien.ac.at/cgi-bin/wa?SUBED1=mqser-l&A=1> - Unsubscribe<mailto:LISTSERV-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org?subject=Unsubscribe&BODY=signoff%20mqseries>

Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com<http://www.lsoft.com/resources/manuals.asp>

________________________________
List Archive<http://listserv.meduniwien.ac.at/archives/mqser-l.html> - Manage Your List Settings<http://listserv.meduniwien.ac.at/cgi-bin/wa?SUBED1=mqser-l&A=1> - Unsubscribe<mailto:LISTSERV-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org?subject=Unsubscribe&BODY=signoff%20mqseries>

Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com<http://www.lsoft.com/resources/manuals.asp>

********************
Nedbank Limited Reg No 1951/000009/06. The following link displays
the names of the Nedbank Board of Directors and Company Secretary.
[ http://www.nedbank.co.za/terms/DirectorsNedbank.htm ]
This email is confidential and is intended for the addressee only.
The following link will take you to Nedbank's legal notice.
[ http://www.nedbank.co.za/terms/EmailDisclaimer.htm ]
********************

________________________________
List Archive<http://listserv.meduniwien.ac.at/archives/mqser-l.html> - Manage Your List Settings<http://listserv.meduniwien.ac.at/cgi-bin/wa?SUBED1=mqser-l&A=1> - Unsubscribe<mailto:LISTSERV-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org?subject=Unsubscribe&BODY=signoff%20mqseries>

Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com<http://www.lsoft.com/resources/manuals.asp>


________________________________
List Archive<http://listserv.meduniwien.ac.at/archives/mqser-l.html> - Manage Your List Settings<http://listserv.meduniwien.ac.at/cgi-bin/wa?SUBED1=mqser-l&A=1> - Unsubscribe<mailto:LISTSERV-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org?subject=Unsubscribe&BODY=signoff%20mqseries>

Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com<http://www.lsoft.com/resources/manuals.asp>

********************
Nedbank Limited Reg No 1951/000009/06. The following link displays
the names of the Nedbank Board of Directors and Company Secretary.
[ http://www.nedbank.co.za/terms/DirectorsNedbank.htm ]
This email is confidential and is intended for the addressee only.
The following link will take you to Nedbank's legal notice.
[ http://www.nedbank.co.za/terms/EmailDisclaimer.htm ]
********************

________________________________
List Archive<http://listserv.meduniwien.ac.at/archives/mqser-l.html> - Manage Your List Settings<http://listserv.meduniwien.ac.at/cgi-bin/wa?SUBED1=mqser-l&A=1> - Unsubscribe<mailto:LISTSERV-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org?subject=Unsubscribe&BODY=signoff%20mqseries>

Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com<http://www.lsoft.com/resources/manuals.asp>

________________________________
List Archive<http://listserv.meduniwien.ac.at/archives/mqser-l.html> - Manage Your List Settings<http://listserv.meduniwien.ac.at/cgi-bin/wa?SUBED1=mqser-l&A=1> - Unsubscribe<mailto:LISTSERV-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org?subject=Unsubscribe&BODY=signoff%20mqseries>

Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com<http://www.lsoft.com/resources/manuals.asp>

********************
Nedbank Limited Reg No 1951/000009/06. The following link displays
the names of the Nedbank Board of Directors and Company Secretary.
[ http://www.nedbank.co.za/terms/DirectorsNedbank.htm ]
This email is confidential and is intended for the addressee only.
The following link will take you to Nedbank's legal notice.
[ http://www.nedbank.co.za/terms/EmailDisclaimer.htm ]
********************

________________________________
List Archive<http://listserv.meduniwien.ac.at/archives/mqser-l.html> - Manage Your List Settings<http://listserv.meduniwien.ac.at/cgi-bin/wa?SUBED1=mqser-l&A=1> - Unsubscribe<mailto:LISTSERV-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org?subject=Unsubscribe&BODY=signoff%20mqseries>

Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com<http://www.lsoft.com/resources/manuals.asp>

________________________________
List Archive<http://listserv.meduniwien.ac.at/archives/mqser-l.html> - Manage Your List Settings<http://listserv.meduniwien.ac.at/cgi-bin/wa?SUBED1=mqser-l&A=1> - Unsubscribe<mailto:LISTSERV-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org?subject=Unsubscribe&BODY=signoff%20mqseries>

Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com<http://www.lsoft.com/resources/manuals.asp>

********************
Nedbank Limited Reg No 1951/000009/06. The following link displays
the names of the Nedbank Board of Directors and Company Secretary.
[ http://www.nedbank.co.za/terms/DirectorsNedbank.htm ]
This email is confidential and is intended for the addressee only.
The following link will take you to Nedbank's legal notice.
[ http://www.nedbank.co.za/terms/EmailDisclaimer.htm ]
********************

________________________________
List Archive<http://listserv.meduniwien.ac.at/archives/mqser-l.html> - Manage Your List Settings<http://listserv.meduniwien.ac.at/cgi-bin/wa?SUBED1=mqser-l&A=1> - Unsubscribe<mailto:LISTSERV-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org?subject=Unsubscribe&BODY=signoff%20mqseries>

Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com<http://www.lsoft.com/resources/manuals.asp>

________________________________
List Archive<http://listserv.meduniwien.ac.at/archives/mqser-l.html> - Manage Your List Settings<http://listserv.meduniwien.ac.at/cgi-bin/wa?SUBED1=mqser-l&A=1> - Unsubscribe<mailto:LISTSERV-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org?subject=Unsubscribe&BODY=signoff%20mqseries>

Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com<http://www.lsoft.com/resources/manuals.asp>

********************
Nedbank Limited Reg No 1951/000009/06. The following link displays
the names of the Nedbank Board of Directors and Company Secretary.
[ http://www.nedbank.co.za/terms/DirectorsNedbank.htm ]
This email is confidential and is intended for the addressee only.
The following link will take you to Nedbank's legal notice.
[ http://www.nedbank.co.za/terms/EmailDisclaimer.htm ]
********************

To unsubscribe, write to LISTSERV-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org and,
in the message body (not the subject), write: SIGNOFF MQSERIES
Instructions for managing your mailing list subscription are provided in
the Listserv General Users Guide available at http://www.lsoft.com
Archive: http://listserv.meduniwien.ac.at/archives/mqser-l.html

[Jefferson Lowrey]

Even just a basic set of queue statistics will prove that they're getting
messages. "You are the only application connected to this queue for
input. Over the last X minutes, Y messages were put and Y messages were
got."

I had suggested pub/sub because you said you wanted to audit the messages
- not audit the application's use of MQ.

Activity trace is a great idea. But it can leave you with a lot of
information to wade through, which is more information for the app team to
use to distract from the issues at hand. So you'll have to figure out if
it's better to hit them with small, targeted ammunition, or overwhelm them
with data barrages.

Thank you,

Jeff Lowrey




From: Tim Zielke <***@AON.COM>
To: ***@LISTSERV.MEDUNIWIEN.AC.AT
Date: 10/09/2014 09:59 AM
Subject: Re: [MQSERIES] Does an mq trace trap the data payloads
that are moving thru the qmgr?
Sent by: MQSeries List <***@LISTSERV.MEDUNIWIEN.AC.AT>



An Activity Trace could be very telling. For example, their application
could be doing a GET and not handling a non-zero reason code properly.
Inadvertently, they could be throwing the message away and not logging the
error, which to the application looks like MQ “lost my message”. I have
used the Activity Trace to help look into situations similar to this, and
it is very helpful, as it lets you look under the covers at what the
application is doing.

It is similar to a cookie jar that is missing cookies, and the child says
“I didn’t take it!”. And then you can show them the picture of them with
their hand in the cookie jar . . . :-).

From: MQSeries List [mailto:***@LISTSERV.MEDUNIWIEN.AC.AT] On Behalf
Of Costa, D. (Damian)
Sent: Thursday, October 09, 2014 9:32 AM
To: ***@LISTSERV.MEDUNIWIEN.AC.AT
Subject: Re: Does an mq trace trap the data payloads that are moving thru
the qmgr?

They admit nothing, deny everything. Hard to penetrate


From: MQSeries List [mailto:***@LISTSERV.MEDUNIWIEN.AC.AT] On Behalf
Of Tim Zielke
Sent: 09 October 2014 03:02 PM
To: ***@LISTSERV.MEDUNIWIEN.AC.AT
Subject: Re: Does an mq trace trap the data payloads that are moving thru
the qmgr?

Hi Damian,

Earlier in the thread you had mentioned:

“What is disappointing is that they cannot tell what their app is doing
with the message. The MQ stats indicate they are taking them off the
queue.”

Just curious. Is the app claiming that they never did a GET on the
message?


From: MQSeries List [mailto:***@LISTSERV.MEDUNIWIEN.AC.AT] On Behalf
Of Costa, D. (Damian)
Sent: Thursday, October 09, 2014 3:02 AM
To: ***@LISTSERV.MEDUNIWIEN.AC.AT
Subject: Re: Does an mq trace trap the data payloads that are moving thru
the qmgr?

Aw crud! Oh well a twisted the dev’s arm enough so they are adding
additional logging logic to their app as we speak.
Worst comes to worst I will stop the channel back and trap the message on
the xmitq queue on the responders side.


From: MQSeries List [mailto:***@LISTSERV.MEDUNIWIEN.AC.AT] On Behalf
Of Neil Casey
Sent: 08 October 2014 11:45 PM
To: ***@LISTSERV.MEDUNIWIEN.AC.AT
Subject: Re: Does an mq trace trap the data payloads that are moving thru
the qmgr?

Hi Damian,

I agree that using a queue alias to a topic and then administrative
subscriptions to copy the messages to 2 queues is a great capability.

But remember that it will change the message id, so if your application
relies on message id (for example, to copy to correlation Id of the
response) copying it this way will break the application. :-(

We’ve had discussions on the list about this before, and there is at least
one RFE asking for the ability to keep the message id identical.
http://www.ibm.com/developerworks/rfe/execute?use_case=viewRfe&CR_ID=35062

Regards,

Neil Casey.


On 9 Oct 2014, at 2:37 am, Costa, D. (Damian) <***@NEDBANK.CO.ZA>
wrote:

Great idea re the topic queue. Will go setup and see what is happening.


From: MQSeries List [mailto:***@LISTSERV.MEDUNIWIEN.AC.AT] On Behalf
Of Jefferson Lowrey
Sent: 08 October 2014 03:52 PM
To: ***@LISTSERV.MEDUNIWIEN.AC.AT
Subject: Re: Does an mq trace trap the data payloads that are moving thru
the qmgr?

The other thing you can do is (mis) use pub/sub and reroute messages that
are supposed to go to the application input queue to a topic instead, and
then create two admin subscriptions - one to the original input queue and
one to a different queue - something that just gets dumped to a text file
(perhaps by qload or etc.)

This is the basic replacement for mirrorq as of v7's pub/sub function. If,
somehow, you're still at <v7, you can test your googlefu by trying to find
some copy of the mirrorq source code to compile.

Thank you,

Jeff Lowrey




From: Tim Zielke <***@AON.COM>
To: ***@LISTSERV.MEDUNIWIEN.AC.AT
Date: 10/08/2014 08:01 AM
Subject: Re: [MQSERIES] Does an mq trace trap the data payloads
that are moving thru the qmgr?
Sent by: MQSeries List <***@LISTSERV.MEDUNIWIEN.AC.AT>




If this is more something temporary to help debug an issue, then I would
go with the Activity Trace (if you are at >= 7.1) over standard tracing
(i.e. strmqtrc).

For viewing the AAT data, there are significant enhancements to the
amqsact program (called amqsactz) that I find helpful ->
http://www.capitalware.com/mq_code_c.html

You do need a C compiler to build it for your platform, but I provide some
examples in the comments of the program on how to do this on Windows or
Linux. The MQ manual, of course, covers all environments for building an
MQ program written in C.

Thanks,
Tim

From: MQSeries List [mailto:***@LISTSERV.MEDUNIWIEN.AC.AT] On Behalf
Of Costa, D. (Damian)
Sent: Wednesday, October 08, 2014 7:45 AM
To: ***@LISTSERV.MEDUNIWIEN.AC.AT
Subject: Re: Does an mq trace trap the data payloads that are moving thru
the qmgr?

Swat I tole ‘em
.. improve their logging from their apps.
What is disappointing is that they cannot tell what their app is doing
with the message. The MQ stats indicate they are taking them off the
queue.
Heaven only know where they go from there.

From: MQSeries List [mailto:***@LISTSERV.MEDUNIWIEN.AC.AT] On Behalf
Of Tim Zielke
Sent: 08 October 2014 02:07 PM
To: ***@LISTSERV.MEDUNIWIEN.AC.AT
Subject: Re: Does an mq trace trap the data payloads that are moving thru
the qmgr?

Hi Damian,

If your queue manager is 7.1 or higher, another option is the Application
Activity Trace.

This IBM article on the AAT ->
http://www.ibm.com/developerworks/websphere/library/techarticles/1306_bushby/1306_bushby.html


does give the scenario of “Using Application Activity Trace to keep an
audit trail of messages” as one of the AAT’s uses.

Personally, I would be hesitant to do what you are being asked to do, and
would like to understand from the application team why their application
can not do this logging, itself. Do they really need the entire message,
or is it really key pieces of data that they could put into an application
log.

Thanks,
Tim

From: MQSeries List [mailto:***@LISTSERV.MEDUNIWIEN.AC.AT] On Behalf
Of T.Rob
Sent: Wednesday, October 08, 2014 4:17 AM
To: ***@LISTSERV.MEDUNIWIEN.AC.AT
Subject: Re: Does an mq trace trap the data payloads that are moving thru
the qmgr?

I think that's *most* of the persistent data. At MQTC Mark Taylor gave
the MQ Internals session and said that the Put To Waiting Getter
optimization permits certain persistent messages that are PUT outside of
syncpoint to bypass the log. So for purposes of an audit you either need
to use API-level tracing or else be able to prove to the auditor that your
programs do everything inside of syncpoint and therefore the dmpmqlog
output is complete.

Trying to find a single or very few messages that appear to have been
processed but for which there is no log entry could REALLY screw up your
day, your audit, your relationship with upper management, etc.

(Do not confuse this with the restaurant management API that can recall
service staff from the golf course on their day off when there's a sudden
surge in business. That is the "Get To Putting Waiter" API call and is
completely different.)

Kind regards,
-- T.Rob

T.Robert Wyatt, Managing partner
IoPT Consulting, LLC
+1 704-443-TROB (8762) Voice/Text
[phone] Voice
https://ioptconsulting.com
https://twitter.com/tdotrob

From: MQSeries List [mailto:***@LISTSERV.MEDUNIWIEN.AC.AT] On Behalf
Of Andrew Hickson
Sent: Wednesday, October 08, 2014 4:52 AM
To: ***@LISTSERV.MEDUNIWIEN.AC.AT
Subject: Re: Does an mq trace trap the data payloads that are moving thru
the qmgr?

If you're using linear logging then all of the message data (control
information + payload) for persistent messages is recorded in the recovery
log, and can be post processed with the dmpmqlog utility.
If you're using circular logging then you've effectively got a wrap around
history of the last X bytes of persistent data, however getting to all of
that data (e.g. dmpmqlog) is much more difficult and typically requires
the help of MQ L3.
The main advantage of using the recovery log for this purpose is that
there's no performance overhead.
The main disadvantage of using the recovery log for this purpose is that
the information isn't in a form that's very easy to process/consume.





From: "T.Rob" <***@IOPTCONSULTING.COM>
To: ***@LISTSERV.MEDUNIWIEN.AC.AT,
Date: 08/10/2014 09:41
Subject: Re: Does an mq trace trap the data payloads that are
moving thru the qmgr?
Sent by: MQSeries List <***@LISTSERV.MEDUNIWIEN.AC.AT>





If you use the MA0W trace exit I believe that you can specify capturing
just
the headers. I do recall though a conversation with Ralph Bateman about
how
Support often receives traces and FDC files in PMRs that are filled with
PII, medical data, SSN's, card numbers, etc. So I believe the answer is
"yes." That said, the WMQ native trace can get real big, real fast so you
may want to look at MA0W which traces only API calls and not internals,
SSL,
comms, etc.

http://ibm.co/SupptPacMA0W


Kind regards,
-- T.Rob


> -----Original Message-----
> From: MQSeries List [mailto:***@LISTSERV.MEDUNIWIEN.AC.AT] On
Behalf
> Of Costa, D. (Damian)
> Sent: Wednesday, October 08, 2014 4:00 AM
> To: ***@LISTSERV.MEDUNIWIEN.AC.AT
> Subject: Does an mq trace trap the data payloads that are moving thru
the
> qmgr?
>
> HI all,
> I Was just asked to supply the audit traces of all messages going
through
> a particular queue on a test qmgr. Naturally I can't just do that as no
> audit logs exist. So I was wondering if I could fudge it by running an
mq
> trace to trap the message payloads being processed off said queue.
> Izzat even possible?
>
> ********************
> Nedbank Limited Reg No 1951/000009/06. The following link displays the
> names of the Nedbank Board of Directors and Company Secretary.
> [ http://www.nedbank.co.za/terms/DirectorsNedbank.htm ] This email is
> confidential and is intended for the addressee only.
> The following link will take you to Nedbank's legal notice.
> [ http://www.nedbank.co.za/terms/EmailDisclaimer.htm ]
> ********************
>
> To unsubscribe, write to ***@LISTSERV.MEDUNIWIEN.AC.AT and, in the
> message body (not the subject), write: SIGNOFF MQSERIES Instructions for
> managing your mailing list subscription are provided in the Listserv
> General Users Guide available at http://www.lsoft.com
> Archive: http://listserv.meduniwien.ac.at/archives/mqser-l.html

To unsubscribe, write to ***@LISTSERV.MEDUNIWIEN.AC.AT and,
in the message body (not the subject), write: SIGNOFF MQSERIES
Instructions for managing your mailing list subscription are provided in
the Listserv General Users Guide available at http://www.lsoft.com
Archive: http://listserv.meduniwien.ac.at/archives/mqser-l.html



Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number
741598.
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU


List Archive - Manage Your List Settings - Unsubscribe
Instructions for managing your mailing list subscription are provided in
the Listserv General Users Guide available at http://www.lsoft.com




List Archive - Manage Your List Settings - Unsubscribe
Instructions for managing your mailing list subscription are provided in
the Listserv General Users Guide available at http://www.lsoft.com




List Archive - Manage Your List Settings - Unsubscribe
Instructions for managing your mailing list subscription are provided in
the Listserv General Users Guide available at http://www.lsoft.com

********************
Nedbank Limited Reg No 1951/000009/06. The following link displays
the names of the Nedbank Board of Directors and Company Secretary.
[ http://www.nedbank.co.za/terms/DirectorsNedbank.htm ]
This email is confidential and is intended for the addressee only.
The following link will take you to Nedbank's legal notice.
[ http://www.nedbank.co.za/terms/EmailDisclaimer.htm ]
********************



List Archive - Manage Your List Settings - Unsubscribe
Instructions for managing your mailing list subscription are provided in
the Listserv General Users Guide available at http://www.lsoft.com


List Archive - Manage Your List Settings - Unsubscribe
Instructions for managing your mailing list subscription are provided in
the Listserv General Users Guide available at http://www.lsoft.com


List Archive - Manage Your List Settings - Unsubscribe
Instructions for managing your mailing list subscription are provided in
the Listserv General Users Guide available at http://www.lsoft.com

********************
Nedbank Limited Reg No 1951/000009/06. The following link displays
the names of the Nedbank Board of Directors and Company Secretary.
[ http://www.nedbank.co.za/terms/DirectorsNedbank.htm ]
This email is confidential and is intended for the addressee only.
The following link will take you to Nedbank's legal notice.
[ http://www.nedbank.co.za/terms/EmailDisclaimer.htm ]
********************


List Archive - Manage Your List Settings - Unsubscribe
Instructions for managing your mailing list subscription are provided in
the Listserv General Users Guide available at http://www.lsoft.com



List Archive - Manage Your List Settings - Unsubscribe
Instructions for managing your mailing list subscription are provided in
the Listserv General Users Guide available at http://www.lsoft.com

********************
Nedbank Limited Reg No 1951/000009/06. The following link displays
the names of the Nedbank Board of Directors and Company Secretary.
[ http://www.nedbank.co.za/terms/DirectorsNedbank.htm ]
This email is confidential and is intended for the addressee only.
The following link will take you to Nedbank's legal notice.
[ http://www.nedbank.co.za/terms/EmailDisclaimer.htm ]
********************


List Archive - Manage Your List Settings - Unsubscribe
Instructions for managing your mailing list subscription are provided in
the Listserv General Users Guide available at http://www.lsoft.com


List Archive - Manage Your List Settings - Unsubscribe
Instructions for managing your mailing list subscription are provided in
the Listserv General Users Guide available at http://www.lsoft.com

********************
Nedbank Limited Reg No 1951/000009/06. The following link displays
the names of the Nedbank Board of Directors and Company Secretary.
[ http://www.nedbank.co.za/terms/DirectorsNedbank.htm ]
This email is confidential and is intended for the addressee only.
The following link will take you to Nedbank's legal notice.
[ http://www.nedbank.co.za/terms/EmailDisclaimer.htm ]
********************


List Archive - Manage Your List Settings - Unsubscribe
Instructions for managing your mailing list subscription are provided in
the Listserv General Users Guide available at http://www.lsoft.com


List Archive - Manage Your List Settings - Unsubscribe
Instructions for managing your mailing list subscription are provided in
the Listserv General Users Guide available at http://www.lsoft.com


To unsubscribe, write to ***@LISTSERV.MEDUNIWIEN.AC.AT and,
in the message body (not the subject), write: SIGNOFF MQSERIES
Instructions for managing your mailing list subscription are provided in
the Listserv General Users Guide available at http://www.lsoft.com
Archive: http://listserv.meduniwien.ac.at/archives/mqser-l.html

[Tim Zielke]

Hi Jeff,

All good points. And just to be clear, my intention was not to critique the other suggestions here or say the Activity Trace is the best option. It just sounded like diagnosing Damian’s underlying application issue was more relevant at that application behavioral layer, than the message content, and I wanted to make sure he understood the capabilities of the AAT tool to help in that endeavor.

One note on the amount of data that the Activity Trace gives you being a lot of data. I agree. When I first started using it, I found the presentation of the data to be somewhat unwieldy and hard to get your hands around. That was the main reason I enhanced the amqsact program with the amqsactz. It has some helpful summary reports, a way to get a 1 line API summary report with extra fields in the API data (i.e. channel name, connection name), and a way to quickly index from the 1 line API summary report back into a verbose report to find more data about your specific API call.

One last note on the Activity Trace. I did a session that covered this tool at the MQTC 2.0.1.4 conference. There was probably 30-40 people in both sessions. I asked in each session how many people have used the Activity Trace. Only one person raised their hand, and that person was a member of the MQ Development team :-). So I think there is a lack of understanding of the use of this valuable debugging tool in the MQ community, and want to make sure people are aware of its capabilities. But I digress . . . :-).

Thanks,
Tim

From: MQSeries List [mailto:***@LISTSERV.MEDUNIWIEN.AC.AT] On Behalf Of Jefferson Lowrey
Sent: Thursday, October 09, 2014 10:12 AM
To: ***@LISTSERV.MEDUNIWIEN.AC.AT
Subject: Re: Does an mq trace trap the data payloads that are moving thru the qmgr?

Even just a basic set of queue statistics will prove that they're getting messages. "You are the only application connected to this queue for input. Over the last X minutes, Y messages were put and Y messages were got."

I had suggested pub/sub because you said you wanted to audit the messages - not audit the application's use of MQ.

Activity trace is a great idea. But it can leave you with a lot of information to wade through, which is more information for the app team to use to distract from the issues at hand. So you'll have to figure out if it's better to hit them with small, targeted ammunition, or overwhelm them with data barrages.

Thank you,

Jeff Lowrey




From: Tim Zielke <***@AON.COM<mailto:***@AON.COM>>
To: ***@LISTSERV.MEDUNIWIEN.AC.AT<mailto:***@LISTSERV.MEDUNIWIEN.AC.AT>
Date: 10/09/2014 09:59 AM
Subject: Re: [MQSERIES] Does an mq trace trap the data payloads that are moving thru the qmgr?
Sent by: MQSeries List <***@LISTSERV.MEDUNIWIEN.AC.AT<mailto:***@LISTSERV.MEDUNIWIEN.AC.AT>>
________________________________



An Activity Trace could be very telling. For example, their application could be doing a GET and not handling a non-zero reason code properly. Inadvertently, they could be throwing the message away and not logging the error, which to the application looks like MQ “lost my message”. I have used the Activity Trace to help look into situations similar to this, and it is very helpful, as it lets you look under the covers at what the application is doing.

It is similar to a cookie jar that is missing cookies, and the child says “I didn’t take it!”. And then you can show them the picture of them with their hand in the cookie jar . . . :-).

From: MQSeries List [mailto:***@LISTSERV.MEDUNIWIEN.AC.AT] On Behalf Of Costa, D. (Damian)
Sent: Thursday, October 09, 2014 9:32 AM
To: ***@LISTSERV.MEDUNIWIEN.AC.AT<mailto:***@LISTSERV.MEDUNIWIEN.AC.AT>
Subject: Re: Does an mq trace trap the data payloads that are moving thru the qmgr?

They admit nothing, deny everything. Hard to penetrate


From: MQSeries List [mailto:***@LISTSERV.MEDUNIWIEN.AC.AT] On Behalf Of Tim Zielke
Sent: 09 October 2014 03:02 PM
To: ***@LISTSERV.MEDUNIWIEN.AC.AT<mailto:***@LISTSERV.MEDUNIWIEN.AC.AT>
Subject: Re: Does an mq trace trap the data payloads that are moving thru the qmgr?

Hi Damian,

Earlier in the thread you had mentioned:

“What is disappointing is that they cannot tell what their app is doing with the message. The MQ stats indicate they are taking them off the queue.”

Just curious. Is the app claiming that they never did a GET on the message?


From: MQSeries List [mailto:***@LISTSERV.MEDUNIWIEN.AC.AT] On Behalf Of Costa, D. (Damian)
Sent: Thursday, October 09, 2014 3:02 AM
To: ***@LISTSERV.MEDUNIWIEN.AC.AT<mailto:***@LISTSERV.MEDUNIWIEN.AC.AT>
Subject: Re: Does an mq trace trap the data payloads that are moving thru the qmgr?

Aw crud! Oh well a twisted the dev’s arm enough so they are adding additional logging logic to their app as we speak.
Worst comes to worst I will stop the channel back and trap the message on the xmitq queue on the responders side.


From: MQSeries List [mailto:***@LISTSERV.MEDUNIWIEN.AC.AT] On Behalf Of Neil Casey
Sent: 08 October 2014 11:45 PM
To: ***@LISTSERV.MEDUNIWIEN.AC.AT<mailto:***@LISTSERV.MEDUNIWIEN.AC.AT>
Subject: Re: Does an mq trace trap the data payloads that are moving thru the qmgr?

Hi Damian,

I agree that using a queue alias to a topic and then administrative subscriptions to copy the messages to 2 queues is a great capability.

But remember that it will change the message id, so if your application relies on message id (for example, to copy to correlation Id of the response) copying it this way will break the application. :-(

We’ve had discussions on the list about this before, and there is at least one RFE asking for the ability to keep the message id identical.
http://www.ibm.com/developerworks/rfe/execute?use_case=viewRfe&CR_ID=35062

Regards,

Neil Casey.


On 9 Oct 2014, at 2:37 am, Costa, D. (Damian) <***@NEDBANK.CO.ZA<mailto:***@NEDBANK.CO.ZA>> wrote:

Great idea re the topic queue. Will go setup and see what is happening.


From: MQSeries List [mailto:***@LISTSERV.MEDUNIWIEN.AC.AT] On Behalf Of Jefferson Lowrey
Sent: 08 October 2014 03:52 PM
To: ***@LISTSERV.MEDUNIWIEN.AC.AT<mailto:***@LISTSERV.MEDUNIWIEN.AC.AT>
Subject: Re: Does an mq trace trap the data payloads that are moving thru the qmgr?

The other thing you can do is (mis) use pub/sub and reroute messages that are supposed to go to the application input queue to a topic instead, and then create two admin subscriptions - one to the original input queue and one to a different queue - something that just gets dumped to a text file (perhaps by qload or etc.)

This is the basic replacement for mirrorq as of v7's pub/sub function. If, somehow, you're still at <v7, you can test your googlefu by trying to find some copy of the mirrorq source code to compile.

Thank you,

Jeff Lowrey




From: Tim Zielke <***@AON.COM<mailto:***@AON.COM>>
To: ***@LISTSERV.MEDUNIWIEN.AC.AT<mailto:***@LISTSERV.MEDUNIWIEN.AC.AT>
Date: 10/08/2014 08:01 AM
Subject: Re: [MQSERIES] Does an mq trace trap the data payloads that are moving thru the qmgr?
Sent by: MQSeries List <***@LISTSERV.MEDUNIWIEN.AC.AT<mailto:***@LISTSERV.MEDUNIWIEN.AC.AT>>
________________________________




If this is more something temporary to help debug an issue, then I would go with the Activity Trace (if you are at >= 7.1) over standard tracing (i.e. strmqtrc).

For viewing the AAT data, there are significant enhancements to the amqsact program (called amqsactz) that I find helpful -> http://www.capitalware.com/mq_code_c.html

You do need a C compiler to build it for your platform, but I provide some examples in the comments of the program on how to do this on Windows or Linux. The MQ manual, of course, covers all environments for building an MQ program written in C.

Thanks,
Tim

From: MQSeries List [mailto:***@LISTSERV.MEDUNIWIEN.AC.AT] On Behalf Of Costa, D. (Damian)
Sent: Wednesday, October 08, 2014 7:45 AM
To: ***@LISTSERV.MEDUNIWIEN.AC.AT<mailto:***@LISTSERV.MEDUNIWIEN.AC.AT>
Subject: Re: Does an mq trace trap the data payloads that are moving thru the qmgr?

Swat I tole ‘em
.. improve their logging from their apps.
What is disappointing is that they cannot tell what their app is doing with the message. The MQ stats indicate they are taking them off the queue.
Heaven only know where they go from there.

From: MQSeries List [mailto:***@LISTSERV.MEDUNIWIEN.AC.AT] On Behalf Of Tim Zielke
Sent: 08 October 2014 02:07 PM
To: ***@LISTSERV.MEDUNIWIEN.AC.AT<mailto:***@LISTSERV.MEDUNIWIEN.AC.AT>
Subject: Re: Does an mq trace trap the data payloads that are moving thru the qmgr?

Hi Damian,

If your queue manager is 7.1 or higher, another option is the Application Activity Trace.

This IBM article on the AAT -> http://www.ibm.com/developerworks/websphere/library/techarticles/1306_bushby/1306_bushby.html

does give the scenario of “Using Application Activity Trace to keep an audit trail of messages” as one of the AAT’s uses.

Personally, I would be hesitant to do what you are being asked to do, and would like to understand from the application team why their application can not do this logging, itself. Do they really need the entire message, or is it really key pieces of data that they could put into an application log.

Thanks,
Tim

From: MQSeries List [mailto:***@LISTSERV.MEDUNIWIEN.AC.AT] On Behalf Of T.Rob
Sent: Wednesday, October 08, 2014 4:17 AM
To: ***@LISTSERV.MEDUNIWIEN.AC.AT<mailto:***@LISTSERV.MEDUNIWIEN.AC.AT>
Subject: Re: Does an mq trace trap the data payloads that are moving thru the qmgr?

I think that's *most* of the persistent data. At MQTC Mark Taylor gave the MQ Internals session and said that the Put To Waiting Getter optimization permits certain persistent messages that are PUT outside of syncpoint to bypass the log. So for purposes of an audit you either need to use API-level tracing or else be able to prove to the auditor that your programs do everything inside of syncpoint and therefore the dmpmqlog output is complete.

Trying to find a single or very few messages that appear to have been processed but for which there is no log entry could REALLY screw up your day, your audit, your relationship with upper management, etc.

(Do not confuse this with the restaurant management API that can recall service staff from the golf course on their day off when there's a sudden surge in business. That is the "Get To Putting Waiter" API call and is completely different.)

Kind regards,
-- T.Rob

T.Robert Wyatt, Managing partner
IoPT Consulting, LLC
+1 704-443-TROB (8762) Voice/Text
[phone] Voice
https://ioptconsulting.com<https://ioptconsulting.com/>
https://twitter.com/tdotrob

From: MQSeries List [mailto:***@LISTSERV.MEDUNIWIEN.AC.AT] On Behalf Of Andrew Hickson
Sent: Wednesday, October 08, 2014 4:52 AM
To: ***@LISTSERV.MEDUNIWIEN.AC.AT<mailto:***@LISTSERV.MEDUNIWIEN.AC.AT>
Subject: Re: Does an mq trace trap the data payloads that are moving thru the qmgr?

If you're using linear logging then all of the message data (control information + payload) for persistent messages is recorded in the recovery log, and can be post processed with the dmpmqlog utility.
If you're using circular logging then you've effectively got a wrap around history of the last X bytes of persistent data, however getting to all of that data (e.g. dmpmqlog) is much more difficult and typically requires the help of MQ L3.
The main advantage of using the recovery log for this purpose is that there's no performance overhead.
The main disadvantage of using the recovery log for this purpose is that the information isn't in a form that's very easy to process/consume.





From: "T.Rob" <***@IOPTCONSULTING.COM<mailto:***@IOPTCONSULTING.COM>>
To: ***@LISTSERV.MEDUNIWIEN.AC.AT<mailto:***@LISTSERV.MEDUNIWIEN.AC.AT>,
Date: 08/10/2014 09:41
Subject: Re: Does an mq trace trap the data payloads that are moving thru the qmgr?
Sent by: MQSeries List <***@LISTSERV.MEDUNIWIEN.AC.AT<mailto:***@LISTSERV.MEDUNIWIEN.AC.AT>>
________________________________





If you use the MA0W trace exit I believe that you can specify capturing just
the headers. I do recall though a conversation with Ralph Bateman about how
Support often receives traces and FDC files in PMRs that are filled with
PII, medical data, SSN's, card numbers, etc. So I believe the answer is
"yes." That said, the WMQ native trace can get real big, real fast so you
may want to look at MA0W which traces only API calls and not internals, SSL,
comms, etc.

http://ibm.co/SupptPacMA0W


Kind regards,
-- T.Rob


> -----Original Message-----
> From: MQSeries List [mailto:***@LISTSERV.MEDUNIWIEN.AC.AT] On Behalf
> Of Costa, D. (Damian)
> Sent: Wednesday, October 08, 2014 4:00 AM
> To: ***@LISTSERV.MEDUNIWIEN.AC.AT<mailto:***@LISTSERV.MEDUNIWIEN.AC.AT>
> Subject: Does an mq trace trap the data payloads that are moving thru the
> qmgr?
>
> HI all,
> I Was just asked to supply the audit traces of all messages going through
> a particular queue on a test qmgr. Naturally I can't just do that as no
> audit logs exist. So I was wondering if I could fudge it by running an mq
> trace to trap the message payloads being processed off said queue.
> Izzat even possible?
>
> ********************
> Nedbank Limited Reg No 1951/000009/06. The following link displays the
> names of the Nedbank Board of Directors and Company Secretary.
> [ http://www.nedbank.co.za/terms/DirectorsNedbank.htm ] This email is
> confidential and is intended for the addressee only.
> The following link will take you to Nedbank's legal notice.
> [ http://www.nedbank.co.za/terms/EmailDisclaimer.htm ]
> ********************
>
> To unsubscribe, write to ***@LISTSERV.MEDUNIWIEN.AC.AT<mailto:***@LISTSERV.MEDUNIWIEN.AC.AT> and, in the
> message body (not the subject), write: SIGNOFF MQSERIES Instructions for
> managing your mailing list subscription are provided in the Listserv
> General Users Guide available at http://www.lsoft.com<http://www.lsoft.com/>
> Archive: http://listserv.meduniwien.ac.at/archives/mqser-l.html

To unsubscribe, write to ***@LISTSERV.MEDUNIWIEN.AC.AT<mailto:***@LISTSERV.MEDUNIWIEN.AC.AT> and,
in the message body (not the subject), write: SIGNOFF MQSERIES
Instructions for managing your mailing list subscription are provided in
the Listserv General Users Guide available at http://www.lsoft.com<http://www.lsoft.com/>
Archive: http://listserv.meduniwien.ac.at/archives/mqser-l.html



Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number 741598.
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU
________________________________


List Archive<http://listserv.meduniwien.ac.at/archives/mqser-l.html> - Manage Your List Settings<http://listserv.meduniwien.ac.at/cgi-bin/wa?SUBED1=mqser-l&A=1> - Unsubscribe<mailto:***@LISTSERV.MEDUNIWIEN.AC.AT?subject=Unsubscribe&BODY=signoff%20mqseries>

Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com<http://www.lsoft.com/resources/manuals.asp>

________________________________


List Archive<http://listserv.meduniwien.ac.at/archives/mqser-l.html> - Manage Your List Settings<http://listserv.meduniwien.ac.at/cgi-bin/wa?SUBED1=mqser-l&A=1> - Unsubscribe<mailto:***@LISTSERV.MEDUNIWIEN.AC.AT?subject=Unsubscribe&BODY=signoff%20mqseries>

Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com<http://www.lsoft.com/resources/manuals.asp>

________________________________


List Archive<http://listserv.meduniwien.ac.at/archives/mqser-l.html> - Manage Your List Settings<http://listserv.meduniwien.ac.at/cgi-bin/wa?SUBED1=mqser-l&A=1> - Unsubscribe<mailto:***@LISTSERV.MEDUNIWIEN.AC.AT?subject=Unsubscribe&BODY=signoff%20mqseries>

Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com<http://www.lsoft.com/resources/manuals.asp>

********************
Nedbank Limited Reg No 1951/000009/06. The following link displays
the names of the Nedbank Board of Directors and Company Secretary.
[ http://www.nedbank.co.za/terms/DirectorsNedbank.htm ]
This email is confidential and is intended for the addressee only.
The following link will take you to Nedbank's legal notice.
[ http://www.nedbank.co.za/terms/EmailDisclaimer.htm ]
********************

________________________________


List Archive<http://listserv.meduniwien.ac.at/archives/mqser-l.html> - Manage Your List Settings<http://listserv.meduniwien.ac.at/cgi-bin/wa?SUBED1=mqser-l&A=1> - Unsubscribe<mailto:***@LISTSERV.MEDUNIWIEN.AC.AT?subject=Unsubscribe&BODY=signoff%20mqseries>

Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com<http://www.lsoft.com/resources/manuals.asp>



________________________________

List Archive<http://listserv.meduniwien.ac.at/archives/mqser-l.html> - Manage Your List Settings<http://listserv.meduniwien.ac.at/cgi-bin/wa?SUBED1=mqser-l&A=1> - Unsubscribe<mailto:***@LISTSERV.MEDUNIWIEN.AC.AT?subject=Unsubscribe&BODY=signoff%20mqseries>

Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com<http://www.lsoft.com/resources/manuals.asp>


________________________________

List Archive<http://listserv.meduniwien.ac.at/archives/mqser-l.html> - Manage Your List Settings<http://listserv.meduniwien.ac.at/cgi-bin/wa?SUBED1=mqser-l&A=1> - Unsubscribe<mailto:***@LISTSERV.MEDUNIWIEN.AC.AT?subject=Unsubscribe&BODY=signoff%20mqseries>

Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com<http://www.lsoft.com/resources/manuals.asp>

********************
Nedbank Limited Reg No 1951/000009/06. The following link displays
the names of the Nedbank Board of Directors and Company Secretary.
[ http://www.nedbank.co.za/terms/DirectorsNedbank.htm ]
This email is confidential and is intended for the addressee only.
The following link will take you to Nedbank's legal notice.
[ http://www.nedbank.co.za/terms/EmailDisclaimer.htm ]
********************


________________________________

List Archive<http://listserv.meduniwien.ac.at/archives/mqser-l.html> - Manage Your List Settings<http://listserv.meduniwien.ac.at/cgi-bin/wa?SUBED1=mqser-l&A=1> - Unsubscribe<mailto:***@LISTSERV.MEDUNIWIEN.AC.AT?subject=Unsubscribe&BODY=signoff%20mqseries>

Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com<http://www.lsoft.com/resources/manuals.asp>



________________________________

List Archive<http://listserv.meduniwien.ac.at/archives/mqser-l.html> - Manage Your List Settings<http://listserv.meduniwien.ac.at/cgi-bin/wa?SUBED1=mqser-l&A=1> - Unsubscribe<mailto:***@LISTSERV.MEDUNIWIEN.AC.AT?subject=Unsubscribe&BODY=signoff%20mqseries>

Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com<http://www.lsoft.com/resources/manuals.asp>

********************
Nedbank Limited Reg No 1951/000009/06. The following link displays
the names of the Nedbank Board of Directors and Company Secretary.
[ http://www.nedbank.co.za/terms/DirectorsNedbank.htm ]
This email is confidential and is intended for the addressee only.
The following link will take you to Nedbank's legal notice.
[ http://www.nedbank.co.za/terms/EmailDisclaimer.htm ]
********************


________________________________

List Archive<http://listserv.meduniwien.ac.at/archives/mqser-l.html> - Manage Your List Settings<http://listserv.meduniwien.ac.at/cgi-bin/wa?SUBED1=mqser-l&A=1> - Unsubscribe<mailto:***@LISTSERV.MEDUNIWIEN.AC.AT?subject=Unsubscribe&BODY=signoff%20mqseries>

Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com<http://www.lsoft.com/resources/manuals.asp>


________________________________

List Archive<http://listserv.meduniwien.ac.at/archives/mqser-l.html> - Manage Your List Settings<http://listserv.meduniwien.ac.at/cgi-bin/wa?SUBED1=mqser-l&A=1> - Unsubscribe<mailto:***@LISTSERV.MEDUNIWIEN.AC.AT?subject=Unsubscribe&BODY=signoff%20mqseries>

Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com<http://www.lsoft.com/resources/manuals.asp>

********************
Nedbank Limited Reg No 1951/000009/06. The following link displays
the names of the Nedbank Board of Directors and Company Secretary.
[ http://www.nedbank.co.za/terms/DirectorsNedbank.htm ]
This email is confidential and is intended for the addressee only.
The following link will take you to Nedbank's legal notice.
[ http://www.nedbank.co.za/terms/EmailDisclaimer.htm ]
********************


________________________________

List Archive<http://listserv.meduniwien.ac.at/archives/mqser-l.html> - Manage Your List Settings<http://listserv.meduniwien.ac.at/cgi-bin/wa?SUBED1=mqser-l&A=1> - Unsubscribe<mailto:***@LISTSERV.MEDUNIWIEN.AC.AT?subject=Unsubscribe&BODY=signoff%20mqseries>

Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com<http://www.lsoft.com/resources/manuals.asp>



________________________________
List Archive<http://listserv.meduniwien.ac.at/archives/mqser-l.html> - Manage Your List Settings<http://listserv.meduniwien.ac.at/cgi-bin/wa?SUBED1=mqser-l&A=1> - Unsubscribe<mailto:***@LISTSERV.MEDUNIWIEN.AC.AT?subject=Unsubscribe&BODY=signoff%20mqseries>

Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com<http://www.lsoft.com/resources/manuals.asp>

________________________________
List Archive<http://listserv.meduniwien.ac.at/archives/mqser-l.html> - Manage Your List Settings<http://listserv.meduniwien.ac.at/cgi-bin/wa?SUBED1=mqser-l&A=1> - Unsubscribe<mailto:***@LISTSERV.MEDUNIWIEN.AC.AT?subject=Unsubscribe&BODY=signoff%20mqseries>

Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com<http://www.lsoft.com/resources/manuals.asp>

To unsubscribe, write to ***@LISTSERV.MEDUNIWIEN.AC.AT and,
in the message body (not the subject), write: SIGNOFF MQSERIES
Instructions for managing your mailing list subscription are provided in
the Listserv General Users Guide available at http://www.lsoft.com
Archive: http://listserv.meduniwien.ac.at/archives/mqser-l.html

[Costa, D. (Damian)]

I’m more of a sniper type guy. I’ll just hit them with targeted ammo ie the MQ stats.
Also been a busy week haven’t even had time to setup the topic queues yet.
Temper been frayed somewhat so next week I escalate to saturation bombing using topic q’s and an upgrade followed by activity traces.

They won’t know what hit them. snigger.



From: MQSeries List [mailto:***@LISTSERV.MEDUNIWIEN.AC.AT] On Behalf Of Jefferson Lowrey
Sent: 09 October 2014 05:12 PM
To: ***@LISTSERV.MEDUNIWIEN.AC.AT
Subject: Re: Does an mq trace trap the data payloads that are moving thru the qmgr?

Even just a basic set of queue statistics will prove that they're getting messages. "You are the only application connected to this queue for input. Over the last X minutes, Y messages were put and Y messages were got."

I had suggested pub/sub because you said you wanted to audit the messages - not audit the application's use of MQ.

Activity trace is a great idea. But it can leave you with a lot of information to wade through, which is more information for the app team to use to distract from the issues at hand. So you'll have to figure out if it's better to hit them with small, targeted ammunition, or overwhelm them with data barrages.

Thank you,

Jeff Lowrey




From: Tim Zielke <***@AON.COM<mailto:***@AON.COM>>
To: ***@LISTSERV.MEDUNIWIEN.AC.AT<mailto:***@LISTSERV.MEDUNIWIEN.AC.AT>
Date: 10/09/2014 09:59 AM
Subject: Re: [MQSERIES] Does an mq trace trap the data payloads that are moving thru the qmgr?
Sent by: MQSeries List <***@LISTSERV.MEDUNIWIEN.AC.AT<mailto:***@LISTSERV.MEDUNIWIEN.AC.AT>>
________________________________



An Activity Trace could be very telling. For example, their application could be doing a GET and not handling a non-zero reason code properly. Inadvertently, they could be throwing the message away and not logging the error, which to the application looks like MQ “lost my message”. I have used the Activity Trace to help look into situations similar to this, and it is very helpful, as it lets you look under the covers at what the application is doing.

It is similar to a cookie jar that is missing cookies, and the child says “I didn’t take it!”. And then you can show them the picture of them with their hand in the cookie jar . . . :-).

From: MQSeries List [mailto:***@LISTSERV.MEDUNIWIEN.AC.AT] On Behalf Of Costa, D. (Damian)
Sent: Thursday, October 09, 2014 9:32 AM
To: ***@LISTSERV.MEDUNIWIEN.AC.AT<mailto:***@LISTSERV.MEDUNIWIEN.AC.AT>
Subject: Re: Does an mq trace trap the data payloads that are moving thru the qmgr?

They admit nothing, deny everything. Hard to penetrate


From: MQSeries List [mailto:***@LISTSERV.MEDUNIWIEN.AC.AT] On Behalf Of Tim Zielke
Sent: 09 October 2014 03:02 PM
To: ***@LISTSERV.MEDUNIWIEN.AC.AT<mailto:***@LISTSERV.MEDUNIWIEN.AC.AT>
Subject: Re: Does an mq trace trap the data payloads that are moving thru the qmgr?

Hi Damian,

Earlier in the thread you had mentioned:

“What is disappointing is that they cannot tell what their app is doing with the message. The MQ stats indicate they are taking them off the queue.”

Just curious. Is the app claiming that they never did a GET on the message?


From: MQSeries List [mailto:***@LISTSERV.MEDUNIWIEN.AC.AT] On Behalf Of Costa, D. (Damian)
Sent: Thursday, October 09, 2014 3:02 AM
To: ***@LISTSERV.MEDUNIWIEN.AC.AT<mailto:***@LISTSERV.MEDUNIWIEN.AC.AT>
Subject: Re: Does an mq trace trap the data payloads that are moving thru the qmgr?

Aw crud! Oh well a twisted the dev’s arm enough so they are adding additional logging logic to their app as we speak.
Worst comes to worst I will stop the channel back and trap the message on the xmitq queue on the responders side.


From: MQSeries List [mailto:***@LISTSERV.MEDUNIWIEN.AC.AT] On Behalf Of Neil Casey
Sent: 08 October 2014 11:45 PM
To: ***@LISTSERV.MEDUNIWIEN.AC.AT<mailto:***@LISTSERV.MEDUNIWIEN.AC.AT>
Subject: Re: Does an mq trace trap the data payloads that are moving thru the qmgr?

Hi Damian,

I agree that using a queue alias to a topic and then administrative subscriptions to copy the messages to 2 queues is a great capability.

But remember that it will change the message id, so if your application relies on message id (for example, to copy to correlation Id of the response) copying it this way will break the application. :-(

We’ve had discussions on the list about this before, and there is at least one RFE asking for the ability to keep the message id identical.
http://www.ibm.com/developerworks/rfe/execute?use_case=viewRfe&CR_ID=35062

Regards,

Neil Casey.


On 9 Oct 2014, at 2:37 am, Costa, D. (Damian) <***@NEDBANK.CO.ZA<mailto:***@NEDBANK.CO.ZA>> wrote:

Great idea re the topic queue. Will go setup and see what is happening.


From: MQSeries List [mailto:***@LISTSERV.MEDUNIWIEN.AC.AT] On Behalf Of Jefferson Lowrey
Sent: 08 October 2014 03:52 PM
To: ***@LISTSERV.MEDUNIWIEN.AC.AT<mailto:***@LISTSERV.MEDUNIWIEN.AC.AT>
Subject: Re: Does an mq trace trap the data payloads that are moving thru the qmgr?

The other thing you can do is (mis) use pub/sub and reroute messages that are supposed to go to the application input queue to a topic instead, and then create two admin subscriptions - one to the original input queue and one to a different queue - something that just gets dumped to a text file (perhaps by qload or etc.)

This is the basic replacement for mirrorq as of v7's pub/sub function. If, somehow, you're still at <v7, you can test your googlefu by trying to find some copy of the mirrorq source code to compile.

Thank you,

Jeff Lowrey




From: Tim Zielke <***@AON.COM<mailto:***@AON.COM>>
To: ***@LISTSERV.MEDUNIWIEN.AC.AT<mailto:***@LISTSERV.MEDUNIWIEN.AC.AT>
Date: 10/08/2014 08:01 AM
Subject: Re: [MQSERIES] Does an mq trace trap the data payloads that are moving thru the qmgr?
Sent by: MQSeries List <***@LISTSERV.MEDUNIWIEN.AC.AT<mailto:***@LISTSERV.MEDUNIWIEN.AC.AT>>
________________________________




If this is more something temporary to help debug an issue, then I would go with the Activity Trace (if you are at >= 7.1) over standard tracing (i.e. strmqtrc).

For viewing the AAT data, there are significant enhancements to the amqsact program (called amqsactz) that I find helpful -> http://www.capitalware.com/mq_code_c.html

You do need a C compiler to build it for your platform, but I provide some examples in the comments of the program on how to do this on Windows or Linux. The MQ manual, of course, covers all environments for building an MQ program written in C.

Thanks,
Tim

From: MQSeries List [mailto:***@LISTSERV.MEDUNIWIEN.AC.AT] On Behalf Of Costa, D. (Damian)
Sent: Wednesday, October 08, 2014 7:45 AM
To: ***@LISTSERV.MEDUNIWIEN.AC.AT<mailto:***@LISTSERV.MEDUNIWIEN.AC.AT>
Subject: Re: Does an mq trace trap the data payloads that are moving thru the qmgr?

Swat I tole ‘em
.. improve their logging from their apps.
What is disappointing is that they cannot tell what their app is doing with the message. The MQ stats indicate they are taking them off the queue.
Heaven only know where they go from there.

From: MQSeries List [mailto:***@LISTSERV.MEDUNIWIEN.AC.AT] On Behalf Of Tim Zielke
Sent: 08 October 2014 02:07 PM
To: ***@LISTSERV.MEDUNIWIEN.AC.AT<mailto:***@LISTSERV.MEDUNIWIEN.AC.AT>
Subject: Re: Does an mq trace trap the data payloads that are moving thru the qmgr?

Hi Damian,

If your queue manager is 7.1 or higher, another option is the Application Activity Trace.

This IBM article on the AAT -> http://www.ibm.com/developerworks/websphere/library/techarticles/1306_bushby/1306_bushby.html

does give the scenario of “Using Application Activity Trace to keep an audit trail of messages” as one of the AAT’s uses.

Personally, I would be hesitant to do what you are being asked to do, and would like to understand from the application team why their application can not do this logging, itself. Do they really need the entire message, or is it really key pieces of data that they could put into an application log.

Thanks,
Tim

From: MQSeries List [mailto:***@LISTSERV.MEDUNIWIEN.AC.AT] On Behalf Of T.Rob
Sent: Wednesday, October 08, 2014 4:17 AM
To: ***@LISTSERV.MEDUNIWIEN.AC.AT<mailto:***@LISTSERV.MEDUNIWIEN.AC.AT>
Subject: Re: Does an mq trace trap the data payloads that are moving thru the qmgr?

I think that's *most* of the persistent data. At MQTC Mark Taylor gave the MQ Internals session and said that the Put To Waiting Getter optimization permits certain persistent messages that are PUT outside of syncpoint to bypass the log. So for purposes of an audit you either need to use API-level tracing or else be able to prove to the auditor that your programs do everything inside of syncpoint and therefore the dmpmqlog output is complete.

Trying to find a single or very few messages that appear to have been processed but for which there is no log entry could REALLY screw up your day, your audit, your relationship with upper management, etc.

(Do not confuse this with the restaurant management API that can recall service staff from the golf course on their day off when there's a sudden surge in business. That is the "Get To Putting Waiter" API call and is completely different.)

Kind regards,
-- T.Rob

T.Robert Wyatt, Managing partner
IoPT Consulting, LLC
+1 704-443-TROB (8762) Voice/Text
[phone] Voice
https://ioptconsulting.com<https://ioptconsulting.com/>
https://twitter.com/tdotrob

From: MQSeries List [mailto:***@LISTSERV.MEDUNIWIEN.AC.AT] On Behalf Of Andrew Hickson
Sent: Wednesday, October 08, 2014 4:52 AM
To: ***@LISTSERV.MEDUNIWIEN.AC.AT<mailto:***@LISTSERV.MEDUNIWIEN.AC.AT>
Subject: Re: Does an mq trace trap the data payloads that are moving thru the qmgr?

If you're using linear logging then all of the message data (control information + payload) for persistent messages is recorded in the recovery log, and can be post processed with the dmpmqlog utility.
If you're using circular logging then you've effectively got a wrap around history of the last X bytes of persistent data, however getting to all of that data (e.g. dmpmqlog) is much more difficult and typically requires the help of MQ L3.
The main advantage of using the recovery log for this purpose is that there's no performance overhead.
The main disadvantage of using the recovery log for this purpose is that the information isn't in a form that's very easy to process/consume.





From: "T.Rob" <***@IOPTCONSULTING.COM<mailto:***@IOPTCONSULTING.COM>>
To: ***@LISTSERV.MEDUNIWIEN.AC.AT<mailto:***@LISTSERV.MEDUNIWIEN.AC.AT>,
Date: 08/10/2014 09:41
Subject: Re: Does an mq trace trap the data payloads that are moving thru the qmgr?
Sent by: MQSeries List <***@LISTSERV.MEDUNIWIEN.AC.AT<mailto:***@LISTSERV.MEDUNIWIEN.AC.AT>>
________________________________





If you use the MA0W trace exit I believe that you can specify capturing just
the headers. I do recall though a conversation with Ralph Bateman about how
Support often receives traces and FDC files in PMRs that are filled with
PII, medical data, SSN's, card numbers, etc. So I believe the answer is
"yes." That said, the WMQ native trace can get real big, real fast so you
may want to look at MA0W which traces only API calls and not internals, SSL,
comms, etc.

http://ibm.co/SupptPacMA0W


Kind regards,
-- T.Rob


> -----Original Message-----
> From: MQSeries List [mailto:***@LISTSERV.MEDUNIWIEN.AC.AT] On Behalf
> Of Costa, D. (Damian)
> Sent: Wednesday, October 08, 2014 4:00 AM
> To: ***@LISTSERV.MEDUNIWIEN.AC.AT<mailto:***@LISTSERV.MEDUNIWIEN.AC.AT>
> Subject: Does an mq trace trap the data payloads that are moving thru the
> qmgr?
>
> HI all,
> I Was just asked to supply the audit traces of all messages going through
> a particular queue on a test qmgr. Naturally I can't just do that as no
> audit logs exist. So I was wondering if I could fudge it by running an mq
> trace to trap the message payloads being processed off said queue.
> Izzat even possible?
>
> ********************
> Nedbank Limited Reg No 1951/000009/06. The following link displays the
> names of the Nedbank Board of Directors and Company Secretary.
> [ http://www.nedbank.co.za/terms/DirectorsNedbank.htm ] This email is
> confidential and is intended for the addressee only.
> The following link will take you to Nedbank's legal notice.
> [ http://www.nedbank.co.za/terms/EmailDisclaimer.htm ]
> ********************
>
> To unsubscribe, write to ***@LISTSERV.MEDUNIWIEN.AC.AT<mailto:***@LISTSERV.MEDUNIWIEN.AC.AT> and, in the
> message body (not the subject), write: SIGNOFF MQSERIES Instructions for
> managing your mailing list subscription are provided in the Listserv
> General Users Guide available at http://www.lsoft.com<http://www.lsoft.com/>
> Archive: http://listserv.meduniwien.ac.at/archives/mqser-l.html

To unsubscribe, write to ***@LISTSERV.MEDUNIWIEN.AC.AT<mailto:***@LISTSERV.MEDUNIWIEN.AC.AT> and,
in the message body (not the subject), write: SIGNOFF MQSERIES
Instructions for managing your mailing list subscription are provided in
the Listserv General Users Guide available at http://www.lsoft.com<http://www.lsoft.com/>
Archive: http://listserv.meduniwien.ac.at/archives/mqser-l.html



Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number 741598.
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU
________________________________


List Archive<http://listserv.meduniwien.ac.at/archives/mqser-l.html> - Manage Your List Settings<http://listserv.meduniwien.ac.at/cgi-bin/wa?SUBED1=mqser-l&A=1> - Unsubscribe<mailto:***@LISTSERV.MEDUNIWIEN.AC.AT?subject=Unsubscribe&BODY=signoff%20mqseries>

Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com<http://www.lsoft.com/resources/manuals.asp>

________________________________


List Archive<http://listserv.meduniwien.ac.at/archives/mqser-l.html> - Manage Your List Settings<http://listserv.meduniwien.ac.at/cgi-bin/wa?SUBED1=mqser-l&A=1> - Unsubscribe<mailto:***@LISTSERV.MEDUNIWIEN.AC.AT?subject=Unsubscribe&BODY=signoff%20mqseries>

Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com<http://www.lsoft.com/resources/manuals.asp>

________________________________


List Archive<http://listserv.meduniwien.ac.at/archives/mqser-l.html> - Manage Your List Settings<http://listserv.meduniwien.ac.at/cgi-bin/wa?SUBED1=mqser-l&A=1> - Unsubscribe<mailto:***@LISTSERV.MEDUNIWIEN.AC.AT?subject=Unsubscribe&BODY=signoff%20mqseries>

Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com<http://www.lsoft.com/resources/manuals.asp>

********************
Nedbank Limited Reg No 1951/000009/06. The following link displays
the names of the Nedbank Board of Directors and Company Secretary.
[ http://www.nedbank.co.za/terms/DirectorsNedbank.htm ]
This email is confidential and is intended for the addressee only.
The following link will take you to Nedbank's legal notice.
[ http://www.nedbank.co.za/terms/EmailDisclaimer.htm ]
********************

________________________________


List Archive<http://listserv.meduniwien.ac.at/archives/mqser-l.html> - Manage Your List Settings<http://listserv.meduniwien.ac.at/cgi-bin/wa?SUBED1=mqser-l&A=1> - Unsubscribe<mailto:***@LISTSERV.MEDUNIWIEN.AC.AT?subject=Unsubscribe&BODY=signoff%20mqseries>

Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com<http://www.lsoft.com/resources/manuals.asp>



________________________________

List Archive<http://listserv.meduniwien.ac.at/archives/mqser-l.html> - Manage Your List Settings<http://listserv.meduniwien.ac.at/cgi-bin/wa?SUBED1=mqser-l&A=1> - Unsubscribe<mailto:***@LISTSERV.MEDUNIWIEN.AC.AT?subject=Unsubscribe&BODY=signoff%20mqseries>

Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com<http://www.lsoft.com/resources/manuals.asp>


________________________________

List Archive<http://listserv.meduniwien.ac.at/archives/mqser-l.html> - Manage Your List Settings<http://listserv.meduniwien.ac.at/cgi-bin/wa?SUBED1=mqser-l&A=1> - Unsubscribe<mailto:***@LISTSERV.MEDUNIWIEN.AC.AT?subject=Unsubscribe&BODY=signoff%20mqseries>

Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com<http://www.lsoft.com/resources/manuals.asp>

********************
Nedbank Limited Reg No 1951/000009/06. The following link displays
the names of the Nedbank Board of Directors and Company Secretary.
[ http://www.nedbank.co.za/terms/DirectorsNedbank.htm ]
This email is confidential and is intended for the addressee only.
The following link will take you to Nedbank's legal notice.
[ http://www.nedbank.co.za/terms/EmailDisclaimer.htm ]
********************


________________________________

List Archive<http://listserv.meduniwien.ac.at/archives/mqser-l.html> - Manage Your List Settings<http://listserv.meduniwien.ac.at/cgi-bin/wa?SUBED1=mqser-l&A=1> - Unsubscribe<mailto:***@LISTSERV.MEDUNIWIEN.AC.AT?subject=Unsubscribe&BODY=signoff%20mqseries>

Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com<http://www.lsoft.com/resources/manuals.asp>



________________________________

List Archive<http://listserv.meduniwien.ac.at/archives/mqser-l.html> - Manage Your List Settings<http://listserv.meduniwien.ac.at/cgi-bin/wa?SUBED1=mqser-l&A=1> - Unsubscribe<mailto:***@LISTSERV.MEDUNIWIEN.AC.AT?subject=Unsubscribe&BODY=signoff%20mqseries>

Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com<http://www.lsoft.com/resources/manuals.asp>

********************
Nedbank Limited Reg No 1951/000009/06. The following link displays
the names of the Nedbank Board of Directors and Company Secretary.
[ http://www.nedbank.co.za/terms/DirectorsNedbank.htm ]
This email is confidential and is intended for the addressee only.
The following link will take you to Nedbank's legal notice.
[ http://www.nedbank.co.za/terms/EmailDisclaimer.htm ]
********************


________________________________

List Archive<http://listserv.meduniwien.ac.at/archives/mqser-l.html> - Manage Your List Settings<http://listserv.meduniwien.ac.at/cgi-bin/wa?SUBED1=mqser-l&A=1> - Unsubscribe<mailto:***@LISTSERV.MEDUNIWIEN.AC.AT?subject=Unsubscribe&BODY=signoff%20mqseries>

Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com<http://www.lsoft.com/resources/manuals.asp>


________________________________

List Archive<http://listserv.meduniwien.ac.at/archives/mqser-l.html> - Manage Your List Settings<http://listserv.meduniwien.ac.at/cgi-bin/wa?SUBED1=mqser-l&A=1> - Unsubscribe<mailto:***@LISTSERV.MEDUNIWIEN.AC.AT?subject=Unsubscribe&BODY=signoff%20mqseries>

Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com<http://www.lsoft.com/resources/manuals.asp>

********************
Nedbank Limited Reg No 1951/000009/06. The following link displays
the names of the Nedbank Board of Directors and Company Secretary.
[ http://www.nedbank.co.za/terms/DirectorsNedbank.htm ]
This email is confidential and is intended for the addressee only.
The following link will take you to Nedbank's legal notice.
[ http://www.nedbank.co.za/terms/EmailDisclaimer.htm ]
********************


________________________________

List Archive<http://listserv.meduniwien.ac.at/archives/mqser-l.html> - Manage Your List Settings<http://listserv.meduniwien.ac.at/cgi-bin/wa?SUBED1=mqser-l&A=1> - Unsubscribe<mailto:***@LISTSERV.MEDUNIWIEN.AC.AT?subject=Unsubscribe&BODY=signoff%20mqseries>

Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com<http://www.lsoft.com/resources/manuals.asp>



________________________________
List Archive<http://listserv.meduniwien.ac.at/archives/mqser-l.html> - Manage Your List Settings<http://listserv.meduniwien.ac.at/cgi-bin/wa?SUBED1=mqser-l&A=1> - Unsubscribe<mailto:***@LISTSERV.MEDUNIWIEN.AC.AT?subject=Unsubscribe&BODY=signoff%20mqseries>

Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com<http://www.lsoft.com/resources/manuals.asp>

________________________________
List Archive<http://listserv.meduniwien.ac.at/archives/mqser-l.html> - Manage Your List Settings<http://listserv.meduniwien.ac.at/cgi-bin/wa?SUBED1=mqser-l&A=1> - Unsubscribe<mailto:***@LISTSERV.MEDUNIWIEN.AC.AT?subject=Unsubscribe&BODY=signoff%20mqseries>

Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com<http://www.lsoft.com/resources/manuals.asp>

********************
Nedbank Limited Reg No 1951/000009/06. The following link displays
the names of the Nedbank Board of Directors and Company Secretary.
[ http://www.nedbank.co.za/terms/DirectorsNedbank.htm ]
This email is confidential and is intended for the addressee only.
The following link will take you to Nedbank's legal notice.
[ http://www.nedbank.co.za/terms/EmailDisclaimer.htm ]
********************


To unsubscribe, write to ***@LISTSERV.MEDUNIWIEN.AC.AT and,
in the message body (not the subject), write: SIGNOFF MQSERIES
Instructions for managing your mailing list subscription are provided in
the Listserv General Users Guide available at http://www.lsoft.com
Archive: http://listserv.meduniwien.ac.at/archives/mqser-l.html

[Andrew Hickson]

For a persistent message to be eligible for "put to waiting getter" it
must be both put outside sync-point and got outside sync-point.
Anyone consuming persistent messages outside sync-point deserves to have
their day "REALLY screwed up".
An API exit that enforces this would be a simple thing to implement.



From: "T.Rob" <t.rob-CkT6zf+urXSzW/GOMZKyElesiRL1/***@public.gmane.org>
To: MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org,
Date: 08/10/2014 10:17
Subject: Re: Does an mq trace trap the data payloads that are
moving thru the qmgr?
Sent by: MQSeries List <MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org>



I think that's *most* of the persistent data. At MQTC Mark Taylor gave
the MQ Internals session and said that the Put To Waiting Getter
optimization permits certain persistent messages that are PUT outside of
syncpoint to bypass the log. So for purposes of an audit you either need
to use API-level tracing or else be able to prove to the auditor that your
programs do everything inside of syncpoint and therefore the dmpmqlog
output is complete.

Trying to find a single or very few messages that appear to have been
processed but for which there is no log entry could REALLY screw up your
day, your audit, your relationship with upper management, etc.

(Do not confuse this with the restaurant management API that can recall
service staff from the golf course on their day off when there's a sudden
surge in business. That is the "Get To Putting Waiter" API call and is
completely different.)

Kind regards,
-- T.Rob

T.Robert Wyatt, Managing partner
IoPT Consulting, LLC
+1 704-443-TROB (8762) Voice/Text
[phone] Voice
https://ioptconsulting.com
https://twitter.com/tdotrob

From: MQSeries List [mailto:MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org] On Behalf
Of Andrew Hickson
Sent: Wednesday, October 08, 2014 4:52 AM
To: MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org
Subject: Re: Does an mq trace trap the data payloads that are moving thru
the qmgr?

If you're using linear logging then all of the message data (control
information + payload) for persistent messages is recorded in the recovery
log, and can be post processed with the dmpmqlog utility.
If you're using circular logging then you've effectively got a wrap around
history of the last X bytes of persistent data, however getting to all of
that data (e.g. dmpmqlog) is much more difficult and typically requires
the help of MQ L3.
The main advantage of using the recovery log for this purpose is that
there's no performance overhead.
The main disadvantage of using the recovery log for this purpose is that
the information isn't in a form that's very easy to process/consume.





From: "T.Rob" <t.rob-CkT6zf+urXSzW/GOMZKyElesiRL1/***@public.gmane.org>
To: MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org,
Date: 08/10/2014 09:41
Subject: Re: Does an mq trace trap the data payloads that are
moving thru the qmgr?
Sent by: MQSeries List <MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org>




If you use the MA0W trace exit I believe that you can specify capturing
just
the headers. I do recall though a conversation with Ralph Bateman about
how
Support often receives traces and FDC files in PMRs that are filled with
PII, medical data, SSN's, card numbers, etc. So I believe the answer is
"yes." That said, the WMQ native trace can get real big, real fast so you
may want to look at MA0W which traces only API calls and not internals,
SSL,
comms, etc.

http://ibm.co/SupptPacMA0W


Kind regards,
-- T.Rob


> -----Original Message-----
> From: MQSeries List [mailto:MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org] On
Behalf
> Of Costa, D. (Damian)
> Sent: Wednesday, October 08, 2014 4:00 AM
> To: MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org
> Subject: Does an mq trace trap the data payloads that are moving thru
the
> qmgr?
>
> HI all,
> I Was just asked to supply the audit traces of all messages going
through
> a particular queue on a test qmgr. Naturally I can't just do that as no
> audit logs exist. So I was wondering if I could fudge it by running an
mq
> trace to trap the message payloads being processed off said queue.
> Izzat even possible?
>
> ********************
> Nedbank Limited Reg No 1951/000009/06. The following link displays the
> names of the Nedbank Board of Directors and Company Secretary.
> [ http://www.nedbank.co.za/terms/DirectorsNedbank.htm ] This email is
> confidential and is intended for the addressee only.
> The following link will take you to Nedbank's legal notice.
> [ http://www.nedbank.co.za/terms/EmailDisclaimer.htm ]
> ********************
>
> To unsubscribe, write to LISTSERV-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org and, in the
> message body (not the subject), write: SIGNOFF MQSERIES Instructions for
> managing your mailing list subscription are provided in the Listserv
> General Users Guide available at http://www.lsoft.com
> Archive: http://listserv.meduniwien.ac.at/archives/mqser-l.html

To unsubscribe, write to LISTSERV-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org and,
in the message body (not the subject), write: SIGNOFF MQSERIES
Instructions for managing your mailing list subscription are provided in
the Listserv General Users Guide available at http://www.lsoft.com
Archive: http://listserv.meduniwien.ac.at/archives/mqser-l.html



Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number
741598.
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU

List Archive - Manage Your List Settings - Unsubscribe
Instructions for managing your mailing list subscription are provided in
the Listserv General Users Guide available at http://www.lsoft.com


List Archive - Manage Your List Settings - Unsubscribe
Instructions for managing your mailing list subscription are provided in
the Listserv General Users Guide available at http://www.lsoft.com

Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number
741598.
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU

To unsubscribe, write to LISTSERV-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org and,
in the message body (not the subject), write: SIGNOFF MQSERIES
Instructions for managing your mailing list subscription are provided in
the Listserv General Users Guide available at http://www.lsoft.com
Archive: http://listserv.meduniwien.ac.at/archives/mqser-l.html

[T.Rob]

No question and no argument there, Andrew. But however screwed up it would
be to use persistent messages outside of syncpoint, the likelihood of this
adverse event occurring increases proportionally to the potential magnitude
of the impact. Given this was for auditing and the impact is therefore by
definition potentially quite large, the probability that Damian's developers
coded it this way begins to approach certainty. ;-) Though they may
deserve what they get, whether Damian does is not as clear cut.



In any case, I just wanted Damian to be aware of the exception. We've long
discussed on this list the usability of log-scraping tools and the question
of whether the logs actually hold all the intended data. The answer is that
it's possible but only reliably if certain constraints are enforced - namely
exercise of syncpoint. Not everyone is aware of that and certainly someone
acting on an IBM recommendation that "the data's in there" might be
surprised to find out there are cases when it legitimately isn't.



There's also the fact that the optimization even exists. IBM invested in
time to write and test code that makes MQ faster. There are any number of
optimizations that IBM could have made so I have to assume they invested in
this particular one because people actually do that enough for it to
register a performance improvement. Because if IBM coded this optimization
just so a performance report would look better under contrived conditions,
even though nobody actually uses the underlying optimization, that would be
disingenuous. The MQ dev team leads may be stubborn about not giving us
functionality we've been wanting for 20 years such as deleting a log file
when the extent is obsolete, but I can't believe they'd invest valuable
developer and QA time in a performance optimization that nobody actually
uses and which exists only to make performance reports look good. So,
presumably, there are a LOT of people using persistent messages outside of
syncpoint, yes?



-- T.Rob



From: MQSeries List [mailto:MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org] On Behalf Of
Andrew Hickson
Sent: Wednesday, October 08, 2014 7:13 AM
To: MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org
Subject: Re: Does an mq trace trap the data payloads that are moving thru
the qmgr?



For a persistent message to be eligible for "put to waiting getter" it must
be both put outside sync-point and got outside sync-point.
Anyone consuming persistent messages outside sync-point deserves to have
their day "REALLY screwed up".
An API exit that enforces this would be a simple thing to implement.



From: "T.Rob" <t.rob-CkT6zf+urXSzW/GOMZKyElesiRL1/***@public.gmane.org>
To: MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org,
Date: 08/10/2014 10:17
Subject: Re: Does an mq trace trap the data payloads that are moving
thru the qmgr?
Sent by: MQSeries List <MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org>

_____




I think that's *most* of the persistent data. At MQTC Mark Taylor gave the
MQ Internals session and said that the Put To Waiting Getter optimization
permits certain persistent messages that are PUT outside of syncpoint to
bypass the log. So for purposes of an audit you either need to use
API-level tracing or else be able to prove to the auditor that your programs
do everything inside of syncpoint and therefore the dmpmqlog output is
complete.

Trying to find a single or very few messages that appear to have been
processed but for which there is no log entry could REALLY screw up your
day, your audit, your relationship with upper management, etc.

(Do not confuse this with the restaurant management API that can recall
service staff from the golf course on their day off when there's a sudden
surge in business. That is the "Get To Putting Waiter" API call and is
completely different.)

Kind regards,
-- T.Rob

T.Robert Wyatt, Managing partner
IoPT Consulting, LLC
+1 704-443-TROB (8762) Voice/Text
[phone] Voice
<https://ioptconsulting.com/> https://ioptconsulting.com
<https://twitter.com/tdotrob> https://twitter.com/tdotrob

From: MQSeries List [ <mailto:MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org>
mailto:MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org] On Behalf Of Andrew Hickson
Sent: Wednesday, October 08, 2014 4:52 AM
To: MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org
Subject: Re: Does an mq trace trap the data payloads that are moving thru
the qmgr?

If you're using linear logging then all of the message data (control
information + payload) for persistent messages is recorded in the recovery
log, and can be post processed with the dmpmqlog utility.
If you're using circular logging then you've effectively got a wrap around
history of the last X bytes of persistent data, however getting to all of
that data (e.g. dmpmqlog) is much more difficult and typically requires the
help of MQ L3.
The main advantage of using the recovery log for this purpose is that
there's no performance overhead.
The main disadvantage of using the recovery log for this purpose is that the
information isn't in a form that's very easy to process/consume.





From: "T.Rob" < <mailto:t.rob-CkT6zf+urXSzW/GOMZKyElesiRL1/***@public.gmane.org>
t.rob-CkT6zf+urXSzW/GOMZKyElesiRL1/***@public.gmane.org>
To: <mailto:MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org>
MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org,
Date: 08/10/2014 09:41
Subject: Re: Does an mq trace trap the data payloads that are moving
thru the qmgr?
Sent by: MQSeries List < <mailto:MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org>
MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org>

_____





If you use the MA0W trace exit I believe that you can specify capturing just
the headers. I do recall though a conversation with Ralph Bateman about how
Support often receives traces and FDC files in PMRs that are filled with
PII, medical data, SSN's, card numbers, etc. So I believe the answer is
"yes." That said, the WMQ native trace can get real big, real fast so you
may want to look at MA0W which traces only API calls and not internals, SSL,
comms, etc.

<http://ibm.co/SupptPacMA0W> http://ibm.co/SupptPacMA0W


Kind regards,
-- T.Rob


> -----Original Message-----
> From: MQSeries List [ <mailto:MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org>
mailto:MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org] On Behalf
> Of Costa, D. (Damian)
> Sent: Wednesday, October 08, 2014 4:00 AM
> To: <mailto:MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org>
MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org
> Subject: Does an mq trace trap the data payloads that are moving thru the
> qmgr?
>
> HI all,
> I Was just asked to supply the audit traces of all messages going through
> a particular queue on a test qmgr. Naturally I can't just do that as no
> audit logs exist. So I was wondering if I could fudge it by running an mq
> trace to trap the message payloads being processed off said queue.
> Izzat even possible?
>
> ********************
> Nedbank Limited Reg No 1951/000009/06. The following link displays the
> names of the Nedbank Board of Directors and Company Secretary.
> [ <http://www.nedbank.co.za/terms/DirectorsNedbank.htm>
http://www.nedbank.co.za/terms/DirectorsNedbank.htm ] This email is
> confidential and is intended for the addressee only.
> The following link will take you to Nedbank's legal notice.
> [ <http://www.nedbank.co.za/terms/EmailDisclaimer.htm>
http://www.nedbank.co.za/terms/EmailDisclaimer.htm ]
> ********************
>
> To unsubscribe, write to <mailto:LISTSERV-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org>
LISTSERV-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org and, in the
> message body (not the subject), write: SIGNOFF MQSERIES Instructions for
> managing your mailing list subscription are provided in the Listserv
> General Users Guide available at <http://www.lsoft.com/>
http://www.lsoft.com
> Archive: <http://listserv.meduniwien.ac.at/archives/mqser-l.html>
http://listserv.meduniwien.ac.at/archives/mqser-l.html

To unsubscribe, write to <mailto:LISTSERV-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org>
LISTSERV-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org and,
in the message body (not the subject), write: SIGNOFF MQSERIES
Instructions for managing your mailing list subscription are provided in
the Listserv General Users Guide available at <http://www.lsoft.com/>
http://www.lsoft.com
Archive: <http://listserv.meduniwien.ac.at/archives/mqser-l.html>
http://listserv.meduniwien.ac.at/archives/mqser-l.html



Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number
741598.
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU

_____


<http://listserv.meduniwien.ac.at/archives/mqser-l.html> List Archive -
<http://listserv.meduniwien.ac.at/cgi-bin/wa?SUBED1=mqser-l&A=1> Manage Your
List Settings -
<mailto:LISTSERV-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org?subject=Unsubscribe&BODY=signoff%
20mqseries> Unsubscribe

Instructions for managing your mailing list subscription are provided in the
Listserv General Users Guide available at
<http://www.lsoft.com/resources/manuals.asp> http://www.lsoft.com



_____

<http://listserv.meduniwien.ac.at/archives/mqser-l.html> List Archive -
<http://listserv.meduniwien.ac.at/cgi-bin/wa?SUBED1=mqser-l&A=1> Manage Your
List Settings -
<mailto:LISTSERV-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org?subject=Unsubscribe&BODY=signoff%
20mqseries> Unsubscribe

Instructions for managing your mailing list subscription are provided in the
Listserv General Users Guide available at http://www.lsoft.com
<http://www.lsoft.com/resources/manuals.asp>



Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number
741598.
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU

_____

List Archive <http://listserv.meduniwien.ac.at/archives/mqser-l.html> -
Manage Your List Settings
<http://listserv.meduniwien.ac.at/cgi-bin/wa?SUBED1=mqser-l&A=1> -
Unsubscribe
<mailto:LISTSERV-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org?subject=Unsubscribe&BODY=signoff%
20mqseries>

Instructions for managing your mailing list subscription are provided in the
Listserv General Users Guide available at http://www.lsoft.com
<http://www.lsoft.com/resources/manuals.asp>


To unsubscribe, write to LISTSERV-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org and,
in the message body (not the subject), write: SIGNOFF MQSERIES
Instructions for managing your mailing list subscription are provided in
the Listserv General Users Guide available at http://www.lsoft.com
Archive: http://listserv.meduniwien.ac.at/archives/mqser-l.html

[Andrew Hickson]

The fact that put to a waiting get works for persistent messages produced
and consumed outside sync-point is largely an accident, it simply fell out
of an optimization that was implemented primarily for non-persistent
messages.
When MQ is in a competitive bid, we sometime find that an artificial
benchmark has been created because it suits some optimization implemented
in one product or another. It looks like sour grapes if we can't play the
same game, and we're in a much stronger position to rubbish the practice
if it's a game we can also play and hence we've never disabled the
optimization for persistent messages (which would be a trivial change, but
wouldn't make consuming persistent messages outside syncpoint any safer).





From: "T.Rob" <t.rob-CkT6zf+urXSzW/GOMZKyElesiRL1/***@public.gmane.org>
To: MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org,
Date: 08/10/2014 18:03
Subject: Re: Does an mq trace trap the data payloads that are
moving thru the qmgr?
Sent by: MQSeries List <MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org>



No question and no argument there, Andrew. But however screwed up it
would be to use persistent messages outside of syncpoint, the likelihood
of this adverse event occurring increases proportionally to the potential
magnitude of the impact. Given this was for auditing and the impact is
therefore by definition potentially quite large, the probability that
Damian's developers coded it this way begins to approach certainty. ;-)
Though they may deserve what they get, whether Damian does is not as clear
cut.

In any case, I just wanted Damian to be aware of the exception. We've
long discussed on this list the usability of log-scraping tools and the
question of whether the logs actually hold all the intended data. The
answer is that it's possible but only reliably if certain constraints are
enforced - namely exercise of syncpoint. Not everyone is aware of that
and certainly someone acting on an IBM recommendation that "the data's in
there" might be surprised to find out there are cases when it legitimately
isn't.

There's also the fact that the optimization even exists. IBM invested in
time to write and test code that makes MQ faster. There are any number of
optimizations that IBM could have made so I have to assume they invested
in this particular one because people actually do that enough for it to
register a performance improvement. Because if IBM coded this
optimization just so a performance report would look better under
contrived conditions, even though nobody actually uses the underlying
optimization, that would be disingenuous. The MQ dev team leads may be
stubborn about not giving us functionality we've been wanting for 20
years such as deleting a log file when the extent is obsolete, but I can't
believe they'd invest valuable developer and QA time in a performance
optimization that nobody actually uses and which exists only to make
performance reports look good. So, presumably, there are a LOT of people
using persistent messages outside of syncpoint, yes?

-- T.Rob

From: MQSeries List [mailto:MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org] On Behalf
Of Andrew Hickson
Sent: Wednesday, October 08, 2014 7:13 AM
To: MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org
Subject: Re: Does an mq trace trap the data payloads that are moving thru
the qmgr?

For a persistent message to be eligible for "put to waiting getter" it
must be both put outside sync-point and got outside sync-point.
Anyone consuming persistent messages outside sync-point deserves to have
their day "REALLY screwed up".
An API exit that enforces this would be a simple thing to implement.



From: "T.Rob" <t.rob-CkT6zf+urXSzW/GOMZKyElesiRL1/***@public.gmane.org>
To: MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org,
Date: 08/10/2014 10:17
Subject: Re: Does an mq trace trap the data payloads that are
moving thru the qmgr?
Sent by: MQSeries List <MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org>




I think that's *most* of the persistent data. At MQTC Mark Taylor gave
the MQ Internals session and said that the Put To Waiting Getter
optimization permits certain persistent messages that are PUT outside of
syncpoint to bypass the log. So for purposes of an audit you either need
to use API-level tracing or else be able to prove to the auditor that your
programs do everything inside of syncpoint and therefore the dmpmqlog
output is complete.

Trying to find a single or very few messages that appear to have been
processed but for which there is no log entry could REALLY screw up your
day, your audit, your relationship with upper management, etc.

(Do not confuse this with the restaurant management API that can recall
service staff from the golf course on their day off when there's a sudden
surge in business. That is the "Get To Putting Waiter" API call and is
completely different.)

Kind regards,
-- T.Rob

T.Robert Wyatt, Managing partner
IoPT Consulting, LLC
+1 704-443-TROB (8762) Voice/Text
[phone] Voice
https://ioptconsulting.com
https://twitter.com/tdotrob

From: MQSeries List [mailto:MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org] On Behalf
Of Andrew Hickson
Sent: Wednesday, October 08, 2014 4:52 AM
To: MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org
Subject: Re: Does an mq trace trap the data payloads that are moving thru
the qmgr?

If you're using linear logging then all of the message data (control
information + payload) for persistent messages is recorded in the recovery
log, and can be post processed with the dmpmqlog utility.
If you're using circular logging then you've effectively got a wrap around
history of the last X bytes of persistent data, however getting to all of
that data (e.g. dmpmqlog) is much more difficult and typically requires
the help of MQ L3.
The main advantage of using the recovery log for this purpose is that
there's no performance overhead.
The main disadvantage of using the recovery log for this purpose is that
the information isn't in a form that's very easy to process/consume.





From: "T.Rob" <t.rob-CkT6zf+urXSzW/GOMZKyElesiRL1/***@public.gmane.org>
To: MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org,
Date: 08/10/2014 09:41
Subject: Re: Does an mq trace trap the data payloads that are
moving thru the qmgr?
Sent by: MQSeries List <MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org>





If you use the MA0W trace exit I believe that you can specify capturing
just
the headers. I do recall though a conversation with Ralph Bateman about
how
Support often receives traces and FDC files in PMRs that are filled with
PII, medical data, SSN's, card numbers, etc. So I believe the answer is
"yes." That said, the WMQ native trace can get real big, real fast so you
may want to look at MA0W which traces only API calls and not internals,
SSL,
comms, etc.

http://ibm.co/SupptPacMA0W


Kind regards,
-- T.Rob


> -----Original Message-----
> From: MQSeries List [mailto:MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org] On
Behalf
> Of Costa, D. (Damian)
> Sent: Wednesday, October 08, 2014 4:00 AM
> To: MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org
> Subject: Does an mq trace trap the data payloads that are moving thru
the
> qmgr?
>
> HI all,
> I Was just asked to supply the audit traces of all messages going
through
> a particular queue on a test qmgr. Naturally I can't just do that as no
> audit logs exist. So I was wondering if I could fudge it by running an
mq
> trace to trap the message payloads being processed off said queue.
> Izzat even possible?
>
> ********************
> Nedbank Limited Reg No 1951/000009/06. The following link displays the
> names of the Nedbank Board of Directors and Company Secretary.
> [ http://www.nedbank.co.za/terms/DirectorsNedbank.htm ] This email is
> confidential and is intended for the addressee only.
> The following link will take you to Nedbank's legal notice.
> [ http://www.nedbank.co.za/terms/EmailDisclaimer.htm ]
> ********************
>
> To unsubscribe, write to LISTSERV-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org and, in the
> message body (not the subject), write: SIGNOFF MQSERIES Instructions for
> managing your mailing list subscription are provided in the Listserv
> General Users Guide available at http://www.lsoft.com
> Archive: http://listserv.meduniwien.ac.at/archives/mqser-l.html

To unsubscribe, write to LISTSERV-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org and,
in the message body (not the subject), write: SIGNOFF MQSERIES
Instructions for managing your mailing list subscription are provided in
the Listserv General Users Guide available at http://www.lsoft.com
Archive: http://listserv.meduniwien.ac.at/archives/mqser-l.html



Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number
741598.
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU



List Archive - Manage Your List Settings - Unsubscribe
Instructions for managing your mailing list subscription are provided in
the Listserv General Users Guide available at http://www.lsoft.com


List Archive - Manage Your List Settings - Unsubscribe
Instructions for managing your mailing list subscription are provided in
the Listserv General Users Guide available at http://www.lsoft.com


Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number
741598.
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU

List Archive - Manage Your List Settings - Unsubscribe
Instructions for managing your mailing list subscription are provided in
the Listserv General Users Guide available at http://www.lsoft.com


List Archive - Manage Your List Settings - Unsubscribe
Instructions for managing your mailing list subscription are provided in
the Listserv General Users Guide available at http://www.lsoft.com

Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number
741598.
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU

To unsubscribe, write to LISTSERV-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org and,
in the message body (not the subject), write: SIGNOFF MQSERIES
Instructions for managing your mailing list subscription are provided in
the Listserv General Users Guide available at http://www.lsoft.com
Archive: http://listserv.meduniwien.ac.at/archives/mqser-l.html