Confusion on Backout MQ

srinut123 · New User Joined: 11 Oct 2005 Posts: 62 Location: India

Hi,
I've some confusion on Backout MQ. Can anyone please clarify this?

I've a trigger MQ with backout threshold limit set to '3'. If the trigger program fails for some reason and doesn't consume the message, the transaction is getting retriggered. I thought the retriggering happens for "3" times and then then message will be moved to Backout queue automatically but that is not happening. The transaction getting triggered more than "3" times and going into loop, infact until I removed the message from trigger MQ the MQ has been triggering the transaction.

Is it the application program responsibility to move the message to backout queue or it is moved automatically?
If application program's responsibility, whats the purpose of delcaring backout queue name in Trigger MQ definition?

If program abends as soon it enters, program can't handle the backout count even, how to stop looping in this case?

Thanks
Sri

Pandora-Box · Posted: Thu May 31, 2012 2:07 pm

What is Backout queue ? Are you talking about DEAD LETTER QUEUE?

What is your triggger type ??

srinut123 · New User Joined: 11 Oct 2005 Posts: 62 Location: India

No, I dont mean "DEAD LETTER QUEUE". Trigger type is "F". I'm talking about the "Backout requeue name" mentioned in the queue properties shown below.

More: -
Queue name . . . . . . . . : TEST.QUEUE
Disposition . . . . . . . . : QMGR VST1

Backout Reporting
Backout threshold . . . : 3 0 - 999999999
Harden backout counter . : N Y=Yes, N=No
Backout requeue name . . : TEST.QUEUE.BACKOUT

Retention interval . . . . : 999999999 0 - 999999999 hours

Monitoring . . . . . . . . : Q Q=Qmgr, L=Low, M=Medium, H=High, O=Off
Accounting . . . . . . . . : Q E=Enabled, D=Disabled, Q=Qmgr

Pandora-Box · Posted: Thu May 31, 2012 3:13 pm

One thing is that trigger type 'F' (FIRST) could cause an infinite loop

Because

The program which executes MQ ( I assume you do a MQGET ) fails due to some reason and you rollback the operation and hence what happens is that the message which was got back writes again to you inputqueue

As it is first it would trigger you program again and again

Try changing the trigger type to every ( It would resolve you infinite loop )

Garry Carroll · Posted: Fri Jun 01, 2012 2:32 pm

Pandora-Box · Posted: Thu Jun 14, 2012 12:34 am

I was wrong earlier

The Trigger type FIRST has nothing to do with looping but since the backout set up was not done properLy you might face looping

Also in Mq v6 I am not sure if you can acieve backout automatically in this or higher version

What you might need to check for is when your program fails after getting from trigger queue and when Abend you might issue a syncpoint rollback so as said earlier the message got from the queue is Fed back to input queue so your program executes again and again

So this what you might need to do

In your program after MQGET check for backout count and threshold count

Set the threshold count as 2 in your get para

so you need to check in get para if backout count > threshold

When yes the record which was go needs to put to error queue and do a execute cics syncpoint

So for error scenarios the failed record will be written to error queue and on commit (syncpoint) your backout count initializes to 0

Hence ensuring successful backout and no looping occurs ,

And ensure your trigger type is F

This is concluded after sever test runs

This was much simpler for me

There might be a much simpler solution if that could be done at the time of trigger definition

Not pretty sure

I know I am replying pretty late on this though ( If you are still figuring out it might help or it will help others )