| Author |
Message
|
| Trainee |
 Posted: Mon May 07, 2007 12:32 pm Post subject: Audit to a Queue |
 |
|
Centurion
Joined: 27 Oct 2006
Posts: 124
|
Is there any way that we can know howmany messages got moved(processed) through particular queue without using monitoring tools.
with regards Trainee |
|
| Back to top |
|
 |
| jefflowrey |
| Posted: Mon May 07, 2007 12:35 pm Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
Yes.
Rewrite a monitoring tool, using PCF messages to get the information.
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| Trainee |
| Posted: Mon May 07, 2007 1:37 pm Post subject: |
|
|
Centurion
Joined: 27 Oct 2006
Posts: 124
|
Jeff answer honestly too precise for me.I am Trainee
If ACCTQ at queue level is on then it helps?
Thank you
Trainee
Last edited by Trainee on Mon May 07, 2007 1:46 pm; edited 1 time in total |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Mon May 07, 2007 1:39 pm Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
Then use a monitoring tool.
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| Trainee |
| Posted: Tue May 08, 2007 3:33 am Post subject: |
|
|
Centurion
Joined: 27 Oct 2006
Posts: 124
|
Some one told me that there are some IBM Security Channel Exit tools which can tell us homany messages got processed and all sutff...any one has any idea
Thanks
Trainee |
|
| Back to top |
|
|
| Vitor |
| Posted: Tue May 08, 2007 3:39 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
There are various exits on the channels and the queues which can be used for various purposes, including possibly number of messages passing through. There's a good sticky on the forum about writing exits. Security exits are an example.
This is the important point!
You will need to write exit code to achieve this - I'm not aware of any IBM supplied exits which provide this out of the box (though I stand to be corrected). Writing exits is not for the beginner (or the trainee) and the consequences of a badly written exit can be dire.
You're much better off using PCF messages as suggested if you're going to write code. Or buy a monitoring solution that supplies the exit code.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| Vitor |
| Posted: Tue May 08, 2007 3:40 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| Trainee wrote: |
| Some one told me that there are some IBM Security Channel Exit tools which can tell us homany messages got processed and all sutff |
Or ask the some one who told you where these items are.... 
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| marcin.kasinski |
| Posted: Tue May 08, 2007 4:04 am Post subject: |
|
|
Sentinel
Joined: 21 Dec 2004
Posts: 850
Location: Poland / Warsaw
|
| Trainee wrote: |
| Some one told me that there are some IBM Security Channel Exit tools which can tell us homany messages got processed and all sutff |
It is not possible with security exit . It is activated only during conection to qmgr, so it can not count messages.
You can do it with other exits and with accounting and statistics mechanism.
_________________
Marcin |
|
| Back to top |
|
|
| Vitor |
| Posted: Tue May 08, 2007 4:27 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| marcin.kasinski wrote: |
| You can do it with other exits |
I stand by my comments above regarding the dangers of badly written exit code.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| Michael Dag |
| Posted: Tue May 08, 2007 5:06 am Post subject: |
|
|
Jedi Knight
Joined: 13 Jun 2002
Posts: 2607
Location: The Netherlands (Amsterdam)
|
| Trainee wrote: |
If ACCTQ at queue level is on then it helps?
|
If you are on V6 you can use the built in Accounting and Statistics, to read the accounting and statistics messages use the supplied sample: amqsmon (it's in the C samples directory)
_________________
Michael
MQSystems Facebook page |
|
| Back to top |
|
|
| marcin.kasinski |
| Posted: Tue May 08, 2007 5:06 am Post subject: |
|
|
Sentinel
Joined: 21 Dec 2004
Posts: 850
Location: Poland / Warsaw
|
| Vitor wrote: |
| marcin.kasinski wrote: |
| You can do it with other exits |
I stand by my comments above regarding the dangers of badly written exit code. |
Of course.
I wanted to say that it is possible.
It is possible but not recommended.
_________________
Marcin |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Tue May 08, 2007 2:44 pm Post subject: |
|
|
Guest
|
Applications should be written to ensure that all messages are processed, that there are no duplicate or missing 'transactions', that the total number of expected transactions were successfully processed.
If a queue contains no messages, then the total number of MQGETS == total number of MQPUTs.
"How many messages..." sounds like an auditor kind of request. What exactly is the auditor trying to accomplish? |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Tue May 08, 2007 6:29 pm Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
| bruce2359 wrote: |
If a queue contains no messages, then the total number of MQGETS == total number of MQPUTs.
|
If I remember right an uncommitted get still counts as a get and an ucommitted put still counts as a put. Now change uncommitted to rolled back and you will see that you may have more puts or gets than there were ever messages passing through the queue. 
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Wed May 09, 2007 4:34 am Post subject: |
|
|
Guest
|
"If I remember right an uncommitted get still counts as a get and an ucommitted put still counts as a put. "
My assumption about a 'simple transaction' (good for most MQ applications) is that the transaction begins (MQBEGIN); a message arrives and is consumed (MQGET) and a reply is sent (MQPUT).
Yes, at a given instance in time, a message may have been MQPUT to a queue, but not MQGET yet. This is an incomplete transaction - in doubt. At MQCMIT, the transaction ends, and MQ in once again in a consistent state.
"Now change uncommitted to rolled back and you will see that you may have more puts or gets than there were ever messages passing through the queue. "
MQCMIT represents the application programs decision to complete (syncpoint) the transaction; MQBACK represents the application programs decision to undo the transaction. For a simple transaction, if committed, MQGET-MQPUT=0. For both MQCMIT and MQBACK, it depends on when in the application logic does the commit/backout. MQCMIT/MQBACK make this into something other than a simple transaction; therefore, the math is more difficult - it depends.
MQs API calls determine how many messages are "passing through the queue."
Counts of these kinds of activities (statistical and accounting) can be captured by MQ Monitoring. Read MQ V6 Monitoring WebSphere MQ (sc34-6593).
Counting things is one aspect of auditing an application. For a payroll application (for example): did the number of time-card messages = the number of employees that submitted time-cards?
More important would be: did the number of dollars balance? did the correct number of employees get paid? MQ can't help much with these, as they are under application control. |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Fri May 11, 2007 6:01 am Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
| bruce2359 wrote: |
If a queue contains no messages, then the total number of MQGETS == total number of MQPUTs.
|
Also, messages expiring on a queue will have # of MQGETS < # of MQPUTS.
Expiring messages are often "missing transactions that MQ lost". 
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
|
|
