You can set the MQMD.Report option of a message to MQRO_ACTIVITY, and get a trace of the activity sent to your reply to queue. This is great, but not very usable.
For my MQPUT to a cluster queue I got activities
- Sending Message Channel Agent getting the message
- Sending Message Channel Agent sending it over channel CL.QMC
- Receiving Message Channel Agent receiving the data from channel CL.QMC
- Receiving Message Channel Agent putting the message to the queue on the remote system
Note, I did not get a response saying the back end application had actually processed the message.
So by setting one bit I got this extra information and can do things like calculate times and write the name of the channel used etc – great, go out and celebrate!
The problem is that these activity trace messages come back to the reply to queue you specified in your request. You do not want to have to process these messages in your application, as it will be an ugly program to process these PCF messages.
The best thing your application can do is put these messages somewhere else, by using logic like
If MQMD.Format = ‘MQHEPCF’ then use MQPUT1 to put the message to “MY.ACTIVITY.TRACE.QUEUE”, and get the next message.
The activity trace replies should get to the queue before the back end applications reply, which should prevent having lost activity trace messages.
You can then use the IBM supplied dspmqrte program, for example
dspmqrte -i 0 -q MY.ACTIVITY.TRACE.QUEUE -m QMA -w1
to display the messages. The Knowledge Centre is missing some documentation, for example that you specify -i 0 to get all the messages. The KC says you have to specify the MSGID of the messages – which you will not know.
I tried to use the amqsact sample (which is meant to display activity trace messages), but it does not seem to recognize these activity trace messages as they are in MQEPCF format.
I took a copy of the amqsevt sample which processes PCF and made a few changes to support MQHEPCF format. Im still working on how to make this available.
It is not a good idea to have this MQRO_ACTIVITY set for all applications because of the extra overhead of the additional messages it introduces. You could do it every 1000 messages, or if the milliseconds of the current time is .000 (so you would expect this on average once in 1000 messages). You can then capture the data, and plot real time graphs of your MQ network, and where the delays are.
Good hunting (for delays and bottlenecks)