ASG
IBM
Zystems
Cressida
Icon
Netflexity
 
  MQSeries.net
Search  Search       Tech Exchange      Education      Certifications      Library      Info Center      SupportPacs      LinkedIn  Search  Search                                                                   FAQ  FAQ   Usergroups  Usergroups
 
Register  ::  Log in Log in to check your private messages
 
RSS Feed - WebSphere MQ Support RSS Feed - Message Broker Support

MQSeries.net Forum Index » Mainframe, CICS, TXSeries » Rolled back message NOT getting re-triggered

Post new topic  Reply to topic Goto page 1, 2  Next
 Rolled back message NOT getting re-triggered « View previous topic :: View next topic » 
Author Message
MQ_Matt
PostPosted: Wed Sep 14, 2005 9:52 am    Post subject: Rolled back message NOT getting re-triggered Reply with quote

Novice

Joined: 14 Sep 2005
Posts: 10
Location: Toronto

Environment: z/OS, Websphere MQ V5R3, batch IBM COBOL for OS/390 & VM 2.2.2

I’ve encountered a strange situation where a rolled-back message does not cause a re-triggering of the servicing application.

There are three queues: a data queue, a result queue and a control queue. The control queue has a trigger monitor associated with it with TriggerType = First.

The order of processing is this:

    1. Get the single message on the result queue.
    2. Get the single message on the control queue.
    3. Repeatedly get messages from the data queue. Rollback when an error is encountered, otherwise commit at the end of the messages.


For testing purposes I have added code to force a rollback to be performed after the first data message is retrieved.

When I drop messages on the three queues, here’s what I observe:

    1. The trigger monitor starts the servicing application.
    2. The servicing application ends after getting the first data queue message.
    3. The trigger monitor never again starts the servicing application.
    4. The messages are still in their queues. The backout count of the result message, the control message, and the first data message has gone from 0 to 2, and increment by 2 every time I manually re-run the job. I am assuming that the increment by 2 is occurring because the app re-gets a message with an adjusted buffer area if the message is too big.


I use a separate standalone routine to check the backout counts; the application does not have code to check them.

It’s not clear to my why the process does not go into an infinite re-triggering loop.

The logic occurs in this order:

Result queue processing

Code:
1. MQOPEN with MQOO-INPUT-EXCLUSIVE, MQOO-BROWSE.
2. MQGET with MQGMO-BROWSE-NEXT.
3. Reason code is MQRC-TRUNCATED-MSG-FAILED.
4. MQGET with corrected message length.
5. MQGET with MQGMO-MSG-UNDER-CURSOR, MQGMO-SYNCPOINT.
6. MQCLOSE.



Control queue processing

Code:
1. MQOPEN with MQOO-INPUT-EXCLUSIVE, MQOO-BROWSE.
2. MQGET with MQGMO-BROWSE-NEXT.
3. Reason code is MQRC-TRUNCATED-MSG-FAILED.
4. MQGET with corrected message length.
5. MQGET with MQGMO-MSG-UNDER-CURSOR, MQGMO-SYNCPOINT.
6. Message contains a list of message ID’s related to messages in the Data queue – store these values in Working Storage.
7. MQCLOSE.


Data queue processing

Code:
1. MQOPEN with MQOO-INPUT-EXCLUSIVE.
2. MQGET using MQGMO-SYNCPOINT, MQMD-MSGID set to first of stored message ID’s (correlation ID is blank).
3. Reason code is MQRC-TRUNCATED-MSG-FAILED.
4. MQGET with corrected message length.
5. [Forced] MQBACK.
6. MQCLOSE.
7. MQDISC.


I believe the problem is related to the browse/MSG-UNDER-CURSOR combination, because I took the program, removed the result/data queue processing, changed the browse/MSG-UNDER-CURSOR to a straight destructive get, and I got into an infinite re-triggering loop (this tells me that the queue/triggering/infrastructure is set up correctly and therefore not the problem).

I have looked in the manuals and on the web and I can’t find anything that describes or explains this situation.

Any suggestions?
Back to top
View user's profile Send private message
jefflowrey
PostPosted: Wed Sep 14, 2005 10:04 am    Post subject: Reply with quote

Grand Poobah

Joined: 16 Oct 2002
Posts: 19981

There's an entire page about trigger conditions.

I would never expect a rollback, with a trigtype=FIRST, to retrigger, myself. The queue depth never changes until a GET is committed.
_________________
I am *not* the model of the modern major general.
Back to top
View user's profile Send private message
wschutz
PostPosted: Wed Sep 14, 2005 10:13 am    Post subject: Reply with quote

Jedi Knight

Joined: 02 Jun 2005
Posts: 3316
Location: IBM (retired)

but ... for trigtype=first, if ipprocs goes to 0 AND curdepth>0, a trigger event would be generated..... which seems like the condition here ....

Are these shared (in the coupling facility) queues?
_________________
-wayne
Back to top
View user's profile Send private message Send e-mail AIM Address
jefflowrey
PostPosted: Wed Sep 14, 2005 10:20 am    Post subject: Reply with quote

Grand Poobah

Joined: 16 Oct 2002
Posts: 19981

I guess I don't see where ipprocs would go to 0 and still leave curdepth >0 on the control queue.

z/OS implicitly commits on program end if MQDISC is not called, right?
_________________
I am *not* the model of the modern major general.
Back to top
View user's profile Send private message
MQ_Matt
PostPosted: Wed Sep 14, 2005 10:35 am    Post subject: Reply with quote

Novice

Joined: 14 Sep 2005
Posts: 10
Location: Toronto

To the best of my knowledge, no, the queues are not shared.

I have already poured over those 14 conditions for a trigger event and quite frankly my brain hurts.

Here's another twist: I can get the process to re-trigger if I run IBM-supplied program CSQ4BVJ1. This is a sample program for browsing a queue, and uses the standard BROWSE-FIRST/BROWSE-NEXT parameters.

Why would an out-in-left field browse of the queue convince the trigger monitor that the 14 conditions had now been satisfied?

There's no way that the browse could change the queue depth from 1 to 0 and then back to 1, correct? A browse just leaves the message on the queue and makes a copy available to the application, correct?
Back to top
View user's profile Send private message
jefflowrey
PostPosted: Wed Sep 14, 2005 10:39 am    Post subject: Reply with quote

Grand Poobah

Joined: 16 Oct 2002
Posts: 19981

If the control messages expire, then browse can cause the qdepth to go to 0.
_________________
I am *not* the model of the modern major general.
Back to top
View user's profile Send private message
wschutz
PostPosted: Wed Sep 14, 2005 10:45 am    Post subject: Reply with quote

Jedi Knight

Joined: 02 Jun 2005
Posts: 3316
Location: IBM (retired)

Quote:
Environment: z/OS, Websphere MQ V5R3, batch IBM COBOL for OS/390 & VM 2.2.2

How are you triggering the cobol program?

Correct, browse shouldn't have an effect on curdepth.
(except for the expiry case Jeff mentions... )

Are you using MQBACK to rollback the message after the destructive get?

Quote:
I guess I don't see where ipprocs would go to 0 and still leave curdepth >0 on the control queue.

z/OS implicitly commits on program end if MQDISC is not called, right?
But he's rolling back the message, so it should still be there... and yes, there's an implied commit on program end (not abend) if no MQDISC is issued.
_________________
-wayne
Back to top
View user's profile Send private message Send e-mail AIM Address
MQ_Matt
PostPosted: Wed Sep 14, 2005 11:04 am    Post subject: Reply with quote

Novice

Joined: 14 Sep 2005
Posts: 10
Location: Toronto

Back to square one: Is my assumption wrong?

Is it the consensus that I am actually observing the expected result, that as Jeff put it, I should
Quote:
never expect a rollback, with a trigtype=FIRST, to retrigger ... The queue depth never changes until a GET is committed.


If so, how is it that when I change the browse/destructive read combination to a simple destructive read, and the thing re-triggers all over the place? (not to mention other apps that I can get to do this with ease)

Does this suggest an environmental problem (heavy emphasis on the "mental" ) rather than an issue with the application?

To answer wschutz's questions, we have a trigger monitor process that runs all day. When it detects a message it submits JCL to run the servicing application.

The log of the job looks like this:

Code:
//xxxxx002 JOB USER=xxxxxx,CLASS=P,MSGCLASS=0
//JCLOLV   OUTPUT CLASS=0,JESDS=ALL         
//DUMPOUT  OUTPUT CLASS=D,FORMS=STD         
//* Job submitted by CKTIBAT.               
//* Process: xxxx.xxxx.xxxxxxx.CNTRL.GET.PR 
//* Triggering Q: xxxx.xxxx.xxxxxxx.CNTRL   
//BTACLIB JCLLIB ORDER=xxxxxx.xxxx.JCL       
//S1 EXEC PROC=xxxxxxx                       
/*EOF                                         


And yes, I have the servicing app call MQBACK to do the rollback.
Back to top
View user's profile Send private message
jefflowrey
PostPosted: Wed Sep 14, 2005 11:13 am    Post subject: Reply with quote

Grand Poobah

Joined: 16 Oct 2002
Posts: 19981

wschutz wrote:
But he's rolling back the message, so it should still be there... and yes, there's an implied commit on program end (not abend) if no MQDISC is issued.


He's rolling back the message on the DATA queue, not on the CONTROL queue. The control queue is the triggered queue, as I understand it. According to the flow for the control queue, he doesn't do MQDisc and he does do a destructive get in syncpoint on the control queue. Thus, the first message on the control queue should not get rolled back, and thus qdepth should be 0 at program end.

MQ_Matt wrote:
If so, how is it that when I change the browse/destructive read combination to a simple destructive read, and the thing re-triggers all over the place? (not to mention other apps that I can get to do this with ease)

I'm not sure.

Can you maybe reduce this problem to simply the queue and process invoked by the TM? I mean, just repost a clarification of only those things.
_________________
I am *not* the model of the modern major general.
Back to top
View user's profile Send private message
wschutz
PostPosted: Wed Sep 14, 2005 11:22 am    Post subject: Reply with quote

Jedi Knight

Joined: 02 Jun 2005
Posts: 3316
Location: IBM (retired)

Quote:
He's rolling back the message on the DATA queue, not on the CONTROL queue
All the get are under syncpoint control. MQBACK is at the qmgr handle level, not at a queue level.
_________________
-wayne
Back to top
View user's profile Send private message Send e-mail AIM Address
MQ_Matt
PostPosted: Wed Sep 14, 2005 11:28 am    Post subject: Reply with quote

Novice

Joined: 14 Sep 2005
Posts: 10
Location: Toronto

Quote:
He's rolling back the message on the DATA queue, not on the CONTROL queue


Well technically I'm asking the queue manager to roll things back, albeit at the point at which the data queue is being processed.

I guess I don't understand where the queue manager will roll back to. I have:

1. destructive get on Control queue under syncpoint, but no commit (just a close of the queue).

2. destructive get on the Data queue under syncpoint, followed by an MQBACK.

So should it roll back all messages or does the second syncpoint "commit" the get of the Control queue message?
Back to top
View user's profile Send private message
wschutz
PostPosted: Wed Sep 14, 2005 11:32 am    Post subject: Reply with quote

Jedi Knight

Joined: 02 Jun 2005
Posts: 3316
Location: IBM (retired)

TThe MQBACK will roll back both the control and data messages..... what happens if you close the control queue at the very end of your program?
_________________
-wayne
Back to top
View user's profile Send private message Send e-mail AIM Address
MQ_Matt
PostPosted: Wed Sep 14, 2005 11:42 am    Post subject: Reply with quote

Novice

Joined: 14 Sep 2005
Posts: 10
Location: Toronto

wschutz wrote:
TThe MQBACK will roll back both the control and data messages..... what happens if you close the control queue at the very end of your program?


You Sir, are a genius!!!

That little change caused re-triggering!

So, er um, my brain still hurts - could you explain it all to me.

Oh, and again, is it still the consensus that this shouldn't happen?
Back to top
View user's profile Send private message
wschutz
PostPosted: Wed Sep 14, 2005 11:54 am    Post subject: Reply with quote

Jedi Knight

Joined: 02 Jun 2005
Posts: 3316
Location: IBM (retired)


The thing that seems unique about your situation was rolling back the messsage AFTER the queue was closed. As I said earlier, MQ will retrigger for type=first if curdepth>0 AND ipprocs goes to zero. I *suspect* that retriggering didn't occur when you closed the queue because the message was still on the queue, but not committed off the queue yet (and therefore wan't counted in the triggering logic). When you did the MQBACK, the code in the qmgr that determines triggering apparently doesn't get called.

Backing out the message before closing the queue made sure that it got counted in the curdepth calculation for triggering.
_________________
-wayne
Back to top
View user's profile Send private message Send e-mail AIM Address
jefflowrey
PostPosted: Thu Sep 15, 2005 8:42 am    Post subject: Reply with quote

Grand Poobah

Joined: 16 Oct 2002
Posts: 19981

wschutz wrote:
Quote:
He's rolling back the message on the DATA queue, not on the CONTROL queue
All the get are under syncpoint control. MQBACK is at the qmgr handle level, not at a queue level.


It wasn't clear that the logic was all happening inside the same syncpoint or with the same qmgr connection...
_________________
I am *not* the model of the modern major general.
Back to top
View user's profile Send private message
Display posts from previous:   
Post new topic  Reply to topic Goto page 1, 2  Next Page 1 of 2

MQSeries.net Forum Index » Mainframe, CICS, TXSeries » Rolled back message NOT getting re-triggered
Jump to:  



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
Protected by Anti-Spam ACP
 
 


Theme by Dustin Baccetti
Powered by phpBB © 2001, 2002 phpBB Group

Copyright © MQSeries.net. All rights reserved.