Tim Zielke
2014-05-15 13:03:43 UTC
I did open a PMR on this issue, and it ended up being a bug with tracing. It looks like when you have a program that creates more than one connection per thread (i.e. with using the MQCNO_HANDLE_SHARE_BLOCK connect option), the first DISC will turn off the trace and any previous existing connections will no longer write out their trace information for that thread. I was able to recreate the issue with the amqsput0.c sample in 7.0.1, 7.1 and 7.5. IBM is working on an APAR, and I have tested out successfully their fix. Also, the AAT (Application Activity Trace) does not appear to have this issue, so you can use that as a sanity check if you feel you are running across this issue with tracing (I felt like I was taking crazy pills, when I first encountered it).
Thanks,
Tim
From: Tim Zielke
Sent: Wednesday, March 19, 2014 12:42 PM
To: MQSeries List (MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org)
Subject: strmqtrc inadvertently turning off after connection disconnect
Hello,
I ran across something odd when running a strmqtrc, and was curious if anyone else has seen this behavior. I will probably be opening a service request about it, too.
The environment here is MQ 7.5.0.2 on a Red Hat 5 Linux server.
I was running a trace on a java process with the following options. This java process does a local bindings connection to the queue manager.
strmqtrc -m qmgr -t api -p java
This java process is a singled threaded process which opens 4 different connections with these options:
418.1 MQCNO.Options= (MQLONG) : 320
418.1 x'40010000'
418.1 Options=MQCNO_HANDLE_SHARE_BLOCK
418.1 Options=MQCNO_SHARED_BINDING
What I noticed is that after the second time a connection did a MQDISC, the tracing stopped. The process however continued to run and do more API calls with the remaining open connections.
I verified this behavior by running an Application Activity Trace (AAT) simultaneously with the strmqtrc. The AAT did get track correctly all the API calls for the entire run of the process. When I looked at the corresponding strmqtrc, it was missing trace activity right after the second connection disconnect.
Has anyone else seen this type of behavior with strmqtrc?
Thanks,
Tim Zielke
CICS/MQ Systems Programmer
Aon
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
Thanks,
Tim
From: Tim Zielke
Sent: Wednesday, March 19, 2014 12:42 PM
To: MQSeries List (MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org)
Subject: strmqtrc inadvertently turning off after connection disconnect
Hello,
I ran across something odd when running a strmqtrc, and was curious if anyone else has seen this behavior. I will probably be opening a service request about it, too.
The environment here is MQ 7.5.0.2 on a Red Hat 5 Linux server.
I was running a trace on a java process with the following options. This java process does a local bindings connection to the queue manager.
strmqtrc -m qmgr -t api -p java
This java process is a singled threaded process which opens 4 different connections with these options:
418.1 MQCNO.Options= (MQLONG) : 320
418.1 x'40010000'
418.1 Options=MQCNO_HANDLE_SHARE_BLOCK
418.1 Options=MQCNO_SHARED_BINDING
What I noticed is that after the second time a connection did a MQDISC, the tracing stopped. The process however continued to run and do more API calls with the remaining open connections.
I verified this behavior by running an Application Activity Trace (AAT) simultaneously with the strmqtrc. The AAT did get track correctly all the API calls for the entire run of the process. When I looked at the corresponding strmqtrc, it was missing trace activity right after the second connection disconnect.
Has anyone else seen this type of behavior with strmqtrc?
Thanks,
Tim Zielke
CICS/MQ Systems Programmer
Aon
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