|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
 |
|
Getting stat of a queue of last message received and consume |
« View previous topic :: View next topic » |
Author |
Message
|
jeevan |
Posted: Wed Jun 17, 2009 3:01 pm Post subject: Getting stat of a queue of last message received and consume |
|
|
Grand Master
Joined: 12 Nov 2005 Posts: 1432
|
Is there any administrative way( I am not an app folk so I can not write a java or jms app) , or any utility that tells me when a message was received in a queue.
Let me explain my problem. I have a prod qmgr running on mq5.3 which triggers a Microfocus process. It is not doing this for the last 2 weeks and an workaround has been implementated to start this process manually ( means a batch probaly, I do not exactly)
We are upgrading this qmgr eventually ( probably in 2 months time), but need to fix this problem now.
There is not any error in log file, and no FDC file.
The trigger is set to first. They bring down the CICS region every morning at 1.30am and bring up at 2.45 am.
My question which I could not figure out are:
When trigger is set to first, lets say a message arrives at the queue at 10 am. The app was triggered, the messages were picked up, processed and the app is still working /went down.
Anohter message arrives at 12 noon. What happes? When the stats resets? does it trigger the app or does not as it sees that that app has been started? How does MQ check that the app is running ? or if it tries to start again, should not it get an error?
We have BMC patrol. In other queue, we can reset the stats and can se enqueuecount and dequeue count. But initq, it is not showing that? how exactly happens in the triggering mechanism.
I know when the message arrives in the queue, mq should generate a trigger message and put it in the initq. Is not message like other message ?
I would appreciate any suggestion
Last edited by jeevan on Thu Jul 02, 2009 3:32 pm; edited 3 times in total |
|
Back to top |
|
 |
gbaddeley |
Posted: Wed Jun 17, 2009 3:14 pm Post subject: Re: GEtting stat of a queue of last message received and con |
|
|
 Jedi Knight
Joined: 25 Mar 2003 Posts: 2538 Location: Melbourne, Australia
|
jeevan wrote: |
...Also, I can not see the input count in initq... |
You mean IPPROCS is 0? This indicates the CICS trigger monitor is not running. _________________ Glenn |
|
Back to top |
|
 |
bruce2359 |
Posted: Wed Jun 17, 2009 3:18 pm Post subject: |
|
|
 Poobah
Joined: 05 Jan 2008 Posts: 9469 Location: US: west coast, almost. Otherwise, enroute.
|
If you are not a mainframe person, you will need to visit with the m/f cics person to find out why the cics-based trigger monitor transaction CKTI is not running. Or, it is not pointed to the correct initiation queue.
On your mq end, what does the application queue definition look like? Please post it here.
What initiation queue does the initq attribute identify? Is the same init q that the CKTI transaction monitors? _________________ I like deadlines. I like to wave as they pass by.
ב''ה
Lex Orandi, Lex Credendi, Lex Vivendi. As we Worship, So we Believe, So we Live. |
|
Back to top |
|
 |
jeevan |
Posted: Wed Jun 17, 2009 3:51 pm Post subject: |
|
|
Grand Master
Joined: 12 Nov 2005 Posts: 1432
|
bruce2359 wrote: |
If you are not a mainframe person, you will need to visit with the m/f cics person to find out why the cics-based trigger monitor transaction CKTI is not running. |
This particular qmgr is setup by my colleague who is not here now and is not accessible. I did similar setup for test in Mq6. and as I rem, I just have initq, and a process definition eg
DEFINE PROCESS('mf99_START') DESCR(' ') +
APPLTYPE(CICS) APPLICID('mf9971') +
USERDATA('AUTH=IDENTIFY,WAIT=20') ENVRDATA(' ') REPLACE
I did not run any trigger monitor.
The application is a Microfocus process and is running in microfocus server. I am not sure how exactly the trigger works in this particular case. So, I am researching now.
any help in understanding this would be greatly appreciated. |
|
Back to top |
|
 |
jeevan |
Posted: Wed Jun 17, 2009 3:56 pm Post subject: Re: GEtting stat of a queue of last message received and con |
|
|
Grand Master
Joined: 12 Nov 2005 Posts: 1432
|
gbaddeley wrote: |
jeevan wrote: |
...Also, I can not see the input count in initq... |
You mean IPPROCS is 0? This indicates the CICS trigger monitor is not running. |
Yes, I am talking about the IPPROCS in initq.
Should not the TM listening to the initq?
Also, does a trigger message exprie after certain time?
Last edited by jeevan on Thu Jul 02, 2009 3:20 pm; edited 1 time in total |
|
Back to top |
|
 |
Vitor |
Posted: Thu Jun 18, 2009 12:31 am Post subject: |
|
|
 Grand High Poobah
Joined: 11 Nov 2005 Posts: 26093 Location: Texas, USA
|
jeevan wrote: |
I did not run any trigger monitor. |
You shouldn't, but the sys prog should (as my most worthy associate correctly points out CKTI should start at the same time as CICS) _________________ Honesty is the best policy.
Insanity is the best defence. |
|
Back to top |
|
 |
jeevan |
Posted: Thu Jul 02, 2009 3:13 pm Post subject: |
|
|
Grand Master
Joined: 12 Nov 2005 Posts: 1432
|
Vitor wrote: |
jeevan wrote: |
I did not run any trigger monitor. |
You shouldn't, but the sys prog should (as my most worthy associate correctly points out CKTI should start at the same time as CICS) |
I have more information now. The trigger monitor is an CICS trigger monitor (CKTI). CKTI is listening to the initq. This part is working.
However, MQ is not creating the trigger message. I observed that when First message arrives( we will discuss which is the first message later), mq is supposed to create a trigger message but it is not.
Further search revelaed that when MQ sees that there is something connected to the inupt queue, it does not generate a trigger message.
In fact, the problem has been resolved by bouncing the queue manager. However, I have one question which I could not understand.
The trigger interval is default - 999999999 which is equivalent to 277 hours. But MQ is generating a trigger message. what theory is applicaable here? How the trigger message is generated the time between the two message is not equivalent to the trigger interval? and what time interval?
Does MQ generate a trigger message when there is no any process connected to the input queue? |
|
Back to top |
|
 |
bruce2359 |
Posted: Thu Jul 02, 2009 3:54 pm Post subject: |
|
|
 Poobah
Joined: 05 Jan 2008 Posts: 9469 Location: US: west coast, almost. Otherwise, enroute.
|
Code: |
Further search revelaed that when MQ sees that there is something connected to the inupt queue, it does not generate a trigger message. |
The purpose of trigtype(first) is to launch the consuming application to open the queue and mqget the application message. The assumption for trigtype(first) is that the consuming application is NOT yet launched.
You are telling us that the consuming application (or something?) has mqopened the application queue, so no trigger message will be generated. Working as designed. If the something that has the queue opened did so in error, find out who/how, and fix that. Perhaps a change to security will prevent the errant app from opening the queue.
The trigger interval is for detecting triggers that should have fired but didn't. In your case, there is an application that already has the application queue open for input, so no trigger message. Again, working as designed.
Bouncing the qmgr detached the application from the application queue; it did not resolve the problem. _________________ I like deadlines. I like to wave as they pass by.
ב''ה
Lex Orandi, Lex Credendi, Lex Vivendi. As we Worship, So we Believe, So we Live. |
|
Back to top |
|
 |
jeevan |
Posted: Fri Jul 03, 2009 2:41 pm Post subject: How trigger works |
|
|
Grand Master
Joined: 12 Nov 2005 Posts: 1432
|
bruce2359 wrote: |
Code: |
Further search revelaed that when MQ sees that there is something connected to the inupt queue, it does not generate a trigger message. |
The purpose of trigtype(first) is to launch the consuming application to open the queue and mqget the application message. The assumption for trigtype(first) is that the consuming application is NOT yet launched.
You are telling us that the consuming application (or something?) has mqopened the application queue, so no trigger message will be generated. Working as designed. If the something that has the queue opened did so in error, find out who/how, and fix that. Perhaps a change to security will prevent the errant app from opening the queue.
The trigger interval is for detecting triggers that should have fired but didn't. In your case, there is an application that already has the application queue open for input, so no trigger message. Again, working as designed.
Bouncing the qmgr detached the application from the application queue; it did not resolve the problem. |
Let me repeat what happened in sequence
Microfocus prod support team reported that their microfocus process did not come up automatically( used to ). Theier offshore folks are bringing it up each day (night) manually.
Note: The cics region goes down at 1 am . and comes up at 3 am in the morning.
First step, MF group bounce their server assuming their app or server has some problem and bouncing may fix it.
Result: this did not resolve the problem
They asked me to look at the mq side
First I observed that MQ was not generating a trigger message. I did it by reseting the enqueued and dequeued stat of the initq.
I also found out that the TM is not N mq trigger monitor but it was a CKTI.
CKTI listening the initq. There was not a problem.
Obviously, then the problem lies in mq side.
I then again did further search and found out that the input queue has a hung process. ( when the cics is down, there should not be anything listening but I observed one ipprocs.) when cics is up, there are 2 ipprocs while it should be only one.
Conclusion: the hung process is causing the problem. However, it was not sure how. Further reading about trigger related documents, I found that when the mq sees something listening to the input queue, it does not generate a trigger message.
I then recommend to bounce the queue manager. In fact that resolved the problem. Now there is only one process listening to the input queue. when I check the initq, I can see one message enqueued and one message dequeued everyday.
My question is more on how application triggering works. My understanding is like this:
An app puts a message into inputq
mq checks the triggering interval, and if trigger interval has expired, mq generates a trigger message and puts in to the initq.
Also, mq checks whether there is something listening to the input queue. If there is something listening, mq does not generate a trigger message even if the trigger interval has expired.
But my question is does mq generate a trigger message even if the trigger interval has not expired but there is no process listening to the input queue?
Thanks |
|
Back to top |
|
 |
bruce2359 |
Posted: Fri Jul 03, 2009 3:54 pm Post subject: |
|
|
 Poobah
Joined: 05 Jan 2008 Posts: 9469 Location: US: west coast, almost. Otherwise, enroute.
|
Quote: |
something connected to the inupt queue |
Quote: |
My understanding is like this:
An app puts a message into inputq |
Specifically, the application puts a message to the application queue the queue that the consuming application expects to find the message.
If the trigger conditions are met (a dozen pages in the APG and APR document how this works), then the trigger will fire.
Quote: |
mq checks the triggering interval, and if trigger interval has expired, mq generates a trigger message and puts in to the initq. |
No. The tirgger interval is for so-called "missed triggers". This is not the situation you are in. Your app queue is not being triggered because an application (process) already has the queue opened. It is also possible that some of your definitions are incorrect. Is this a new application? New CICS? New trigger?
Quote: |
Also, mq checks whether there is something listening to the input queue. If there is something listening, mq does not generate a trigger message |
Yes - if trigtype(first) is the trigtype on the application queue, AND there is an application with the application queue mqopened, then no trigger msg is generated. This behavior is identical even if the app with the app queue opened is not the consuming application.
Quote: |
even if the trigger interval has expired. |
Trigger interval does not apply here. Therefore, not an issue for you.
Quote: |
But my question is does mq generate a trigger message even if the trigger interval has not expired but there is no process listening to the input queue? |
Triggers fire when a message arrives in an application queue. Certain conditions must be met for the trigger to fire. Please re-read the relevant portions of both APR and APG, where triggers are discussed in detail.
To correct the problem you face, you must identify what application has the application queue open for input. If it is not the consuming application and/or it is not a cics application/transaction, shoot who/what is starting it. For trigtype(first) there should be only one consuming application; but there must be zero for the trigger to fire.
I'm not going to a guess here. You need to find out what is supposed to get launched in the cics region when a message arrives in the app queue. CKTI must be watching the initq that is named in the application qlocal definition.
Does that consuming app have imbedded mq calls? Are you using one of the mq-cics bridges? How is the cics app attempting to consume the message from the application queue? _________________ I like deadlines. I like to wave as they pass by.
ב''ה
Lex Orandi, Lex Credendi, Lex Vivendi. As we Worship, So we Believe, So we Live. |
|
Back to top |
|
 |
fjb_saper |
Posted: Fri Jul 03, 2009 9:46 pm Post subject: |
|
|
 Grand High Poobah
Joined: 18 Nov 2003 Posts: 20756 Location: LI,NY
|
The trigger interval AFAIK only applies in following circumstances:
- Trigger type is set to first or depth
- trigger is enabled
- the queue has messages on it > trigger threshold
- no process is servicing the queue (ipprocs=0)
When a new message hits the queue and the trigger interval has expired a new trigger is generated.
Hope this helps  _________________ MQ & Broker admin |
|
Back to top |
|
 |
bruce2359 |
Posted: Sat Jul 04, 2009 5:50 am Post subject: |
|
|
 Poobah
Joined: 05 Jan 2008 Posts: 9469 Location: US: west coast, almost. Otherwise, enroute.
|
The trigger interval is used to re-drive the triggering process when ALL trigger conditions have been met, BUT no trigger fired.
Add to the list above that a trigger monitor must have the initq open, the process def must exist, the triggered application must exist, ... This is substantially the same list of conditions that must be met for the trigger to fire in the first place. _________________ I like deadlines. I like to wave as they pass by.
ב''ה
Lex Orandi, Lex Credendi, Lex Vivendi. As we Worship, So we Believe, So we Live. |
|
Back to top |
|
 |
bruce2359 |
Posted: Sat Jul 04, 2009 6:37 am Post subject: |
|
|
 Poobah
Joined: 05 Jan 2008 Posts: 9469 Location: US: west coast, almost. Otherwise, enroute.
|
A quick search of Mr. Google 'trigger interval' gave me this:
TriggerInterval (MQLONG)
This is a time interval (in milliseconds) used to restrict the number of trigger messages. This is relevant only when the TriggerType is MQTT_FIRST. In this case trigger messages are usually generated only when a suitable message arrives on the queue, and the queue was previously empty. Under certain circumstances, however, an additional trigger message can be generated with MQTT_FIRST triggering even if the queue was not empty. These additional trigger messages are not generated more often than every TriggerInterval milliseconds. _________________ I like deadlines. I like to wave as they pass by.
ב''ה
Lex Orandi, Lex Credendi, Lex Vivendi. As we Worship, So we Believe, So we Live. |
|
Back to top |
|
 |
|
|
 |
|
Page 1 of 1 |
|
You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot vote in polls in this forum
|
|
|
|