| Author |
Message
|
| KathyB |
 Posted: Tue Jul 05, 2005 7:07 am Post subject: Trigger event occuring with no message |
 |
|
Apprentice
Joined: 02 Feb 2004
Posts: 30
|
I have a user who has a mainframe (z/OS CICS 2.2) CICS application that is triggered on first by a message originating from a web application running on windows.
The user is experiencing the following intermittent and unpredictable situation where his CICS program gets triggered and gets an at-end condition, MQRC-NO-MSG-AVAILABLE , the first time through the program and there is no message to get .
My first thought was a coding error/loop. I looked over the program code and can see no mistake in coding.
TriggerInterval is set to the default value.
Is it possible something, a non-message, is being sent across at the wrong time to the mainframe queue manager that is being recognized as a trigger event?
Has anyone every had this type of problem?
Any ideas on how I can track down what is occuring would be appreciated? |
|
| Back to top |
|
 |
| sebastianhirt |
| Posted: Tue Jul 05, 2005 7:13 am Post subject: |
|
|
Yatiri
Joined: 07 Jun 2004
Posts: 620
Location: Germany
|
Just an idea:
I could imagine that if there are messages send with a very very short expiry interval, that they will be long enough there to trigger the queue, but not long enough that the application can get them. Would that be possible?
cheers
Sebastian |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Tue Jul 05, 2005 7:20 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
Also, if they are in syncpoint and are not committed, the qdepth will still go from 0 to more than 1, and cause a trigger. But the message won't be gettable until it is committed.
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| KathyB |
| Posted: Tue Jul 05, 2005 7:42 am Post subject: trigger event occuring with no message |
|
|
Apprentice
Joined: 02 Feb 2004
Posts: 30
|
In response to Sebastian:
I checked with the user and he is not setting an expiry time on the message. If he were, then there would be the same problem with every message being sent over. All messages that are sent are being received, processed, and accounted for. There are extra trigger events being generated and CICS tasks running.
In response to Jeff:
I have seen when a message was not available within a unit of work because it had not been committed. But I do not believe this is the case here unless there can be a unit of work that spans platforms with the unit of work starting on the windows platform.
Doesn't the execution of the CICS program start a brand new unit of work?
The program flow is:
1. Get a message and check the return code
2a. If it is a good return code then do a CICS Syncpoint, perform main program processing, do a CICS Syncpoint, return a reply message, and end.
2b. If the return code is 2033 and first time through the program, then send a return message and end.
I appreciate your responses. Do you have any other thoughts? |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Tue Jul 05, 2005 7:45 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
The message could be in syncpoint from the channel, not from the user.
But you'd know if you were having channel hiccups that caused the message to get retried.
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| KathyB |
| Posted: Tue Jul 05, 2005 8:00 am Post subject: Trigger event occuring with no message |
|
|
Apprentice
Joined: 02 Feb 2004
Posts: 30
|
| There do not appear to be any channel problems where there has been a loss of communication. |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Tue Jul 05, 2005 3:33 pm Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
Kathy,
Do you know if your programs ever get triggered and process more than one message?
The queue is definitly triggered on first, correct?
If a message is put under syncpoint to a triggered q, the trigger message is generated immediatly, but also under syncpoint. The trigger monitor cannot act on that trigger message until the application message is committed (in which case it will get the message assuming it has not expired) or in the case where the app message is backed out. Note that in this scenario, the trigger mesage is still committed! And now the app would get a 2033. Hard to beleive a channel would act like that though, but channels can and do backout batches of work.
Although Trigger Interval has nothing to do with this, I would change it from the default. Do a search for that term with my name as the author on why that would be a good thing.
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Tue Jul 05, 2005 4:07 pm Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
Could the ....SIGCHILD be of significance ?
 |
|
| Back to top |
|
|
| KathyB |
| Posted: Wed Jul 06, 2005 3:03 am Post subject: Trigger event occuring with no message |
|
|
Apprentice
Joined: 02 Feb 2004
Posts: 30
|
In response to fjp_saper:
I'm not familiar with the SIGCHILD parameter. If you could give me an explanation, I could ask the user about it.
In response to Peter:
The very first thing the program does is an MQGET. It loops around until it gets all the messages.
Yes. The queue is triggered on first.
Shouldn't the message, if there is one, be available immediately once it is MQPUT by the distributed platform? Is there a such thing as cross-platform syncpoints?
Any suggestions how I might be able to track down what is happening on the mainframe side? Would get-disabling the initiation queue to see what is being sent over tell me anything? |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Wed Jul 06, 2005 3:19 pm Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
| Quote: |
Shouldn't the message, if there is one, be available immediately once it is MQPUT by the distributed platform? Is there a such thing as cross-platform syncpoints?
|
When the RCVR channel puts the message to the destination queue, it does so as part of a batch that it is coordinating with the SNDR channel. Not until the SNDR channel commits the batch, will the RCVR channel commit those messages. And only at that point will the messages be available for MQGETs on the receiving side.
Hold on! That's not the answer!
2 points. A, these batches are usually extremly fast, unless you have enormouse messages, or you have upped the BATCHINT on the SNDR side to some crazy high number, in effect telling MQ to keep the batch open. Regardless, point B comes into play, and that is:
****************
If a message is put under syncpoint to a triggered q, the trigger message is generated immediatly, but also under syncpoint. The trigger monitor cannot act on that trigger message until the application message is committed...
****************
So even if the channel was keeping its batches open for a long time, the trigger messages would not be available to the trigger monitor until the channel batch did commit, at which point both the app messages and the trigger messages became available at the same time.
| Quote: |
Would get-disabling the initiation queue to see what is being sent over tell me anything? |
'fraid not. If you get disable the init q, the trigger monitor will take a dirt nap, the IPROCS on the init q will go to zero, and the QM will no longer generate trigger messages for any queues that use that init q.
It is possible that the RCVR channel puts a message to your q as part of a batch, but before the SNDR has a chance to commit that batch, the channel has a problem, and those messages are rolled back. Note that in this case, the trigger message was generated, and in fact committed, even though the app message got rolled back. Now your app gets triggered, and finds the empty q. But if you say the channels have been running clean, that's not it.
100% sure messages with tiny expiries are not landing there?
And I know this is a suckie answer, but every triggered program should be written to gracefully handle 2033s, even if it is the first MQGET. It is possible, through very weird and specific conditions, to get a trigger message sent to the trigger monitor, when there is no message to truly get come MQGET time.
Regardless, I sure am really curious as to what could be causing your scenario.
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| MohanJBella |
| Posted: Mon Jul 11, 2005 4:10 am Post subject: |
|
|
Newbie
Joined: 25 Jul 2004
Posts: 1
|
Kathy,
Since your CICS application is getting triggered it means that the trigger event has occured.But if you are getting 2033 that means there is no message physically in the queue.You will have to check if the web application is commiting the messages which it puts on the queue.In simple terms , message will be logically present but not physically unless it is commited.
-- MohanJ  |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Mon Jul 11, 2005 6:09 am Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
MohanJ,
Read again from the top. This is not a posible cause in this particular scenario given her architecture.
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| wschutz |
| Posted: Mon Jul 11, 2005 6:40 am Post subject: |
|
|
Jedi Knight
Joined: 02 Jun 2005
Posts: 3316
Location: IBM (retired)
|
You should make sure that the MQGET specifies a relatively small wait interval (15 sec is good), because there might be a delay in committing the application message. Does the appl do a get with wait?
_________________
-wayne |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Mon Jul 11, 2005 6:45 am Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
Wayne, even if the app was putting directly to the q under syncpoint (it is not here), the Trigger Message is not comitted until the app comitts or backs out the original MQ application message, so there is no reason for the triggered app to wait for that first message.
It may chosse to wait after that for additional messages to avoid a retriggering every couple of seconds.
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| wschutz |
| Posted: Mon Jul 11, 2005 7:09 am Post subject: |
|
|
Jedi Knight
Joined: 02 Jun 2005
Posts: 3316
Location: IBM (retired)
|
Peter...as a general "best practice", I have always advised doing a get with wait, even on the first get call. The APG cites examples. Since this is an intermittent problem, I'll always suspect a timing issue.
But in any case, I think we all agree that the application should be coded to handle the NO_MSG_AVAIL condition and not throw an error if it does. Peace ..... 
_________________
-wayne |
|
| Back to top |
|
|
|
|
