Author |
Message
|
MB Developer |
Posted: Wed May 28, 2014 11:09 pm Post subject: Dead Letter Queue Handler runmqdlq |
|
|
 Disciple
Joined: 03 Feb 2014 Posts: 179
|
Hi All,
If I running D:\DEAD>runmqdlq SYSTEM.DEAD.LETTER.QUEUE DL2 < DL2.RUL
The out will shoe like below
D:\DEAD>runmqdlq SYSTEM.DEAD.LETTER.QUEUE DL2 < DL2.RUL
29-May-14 12:21:16 AMQ8708: Dead-letter queue handler started to process INPUTQ(SYSTEM.DEAD.LETTER.QUEUE).
29-May-14 12:21:16 AMQ8722: Dead-letter queue handler unable to put message: Rule 1 Reason 2053.
29-May-14 12:21:16 AMQ8722: Dead-letter queue handler unable to put message: Rule 1 Reason 2053.
but messages are not moved into Business Queue
1) My Rules table name is DL2.RUL and it contains data is REASON(*) ACTION(FWD) FWDQ(DLQ) FWDQM(DL2) and also it ended with new line
2) Recever Queue Maneger is DL2
3) Business Queue is DLQ
4) Dead Letter Queue is SYSTEM.DEAD.LETTER.QUEUE
5) I will set Max Depth is 4
And also I have one more doubt how to show dead letter queue using MQExplorer.
please let me know the error..
Thanks in Advance,
Suresh K  |
|
Back to top |
|
 |
MQsysprog |
Posted: Wed May 28, 2014 11:26 pm Post subject: |
|
|
Centurion
Joined: 24 Feb 2014 Posts: 116
|
Hello,
If we read the messages ,we could see an ''unable tu put message' with reason code 2053 ,that means queue full ,so your destination probably needs a higher qdepth to accept the incoming messages from dlqh .
Ciao |
|
Back to top |
|
 |
MB Developer |
Posted: Thu May 29, 2014 12:41 am Post subject: |
|
|
 Disciple
Joined: 03 Feb 2014 Posts: 179
|
MQsysprog wrote: |
Hello,
If we read the messages ,we could see an ''unable tu put message' with reason code 2053 ,that means queue full ,so your destination probably needs a higher qdepth to accept the incoming messages from dlqh .
Ciao |
Hi MQsysprog,
I know queue is full and it's max depth is 4 but I want to get messages with out changing max depth.
Thanks,
Suresh K |
|
Back to top |
|
 |
MB Developer |
Posted: Thu May 29, 2014 12:57 am Post subject: |
|
|
 Disciple
Joined: 03 Feb 2014 Posts: 179
|
hi all,
now I just change my max depth as 5000 and run above command
D:\DEAD>runmqdlq SYSTEM.DEAD.LETTER.QUEUE DL2 < DL2.RUL
now it is working but when I get messages then It will show message data as DLH
i.e
C:\Windows\system32>amqsget DLQ DL2
Sample AMQSGET0 start
message <1>
message <2>
message <3>
message <4>
message <DLH ☺>
message <DLH ☺>
Thanks,
Suresh K |
|
Back to top |
|
 |
zpat |
Posted: Thu May 29, 2014 2:33 am Post subject: |
|
|
 Jedi Council
Joined: 19 May 2001 Posts: 5866 Location: UK
|
Messages which arrive on the DLQ generally have a DLH added to them by whatever put them on the DLQ.
You need to remove the DLH when moving to the other queue.
There is an option to do this in the DLQ handler rules (reading the documentation is always a good idea!).
Quote: |
HEADER (YES|NO)
Whether the MQDLH should remain on a message for which ACTION (FWD) is requested. By default, the MQDLH remains on the message. The HEADER keyword is not valid for actions other than FWD. |
_________________ Well, I don't think there is any question about it. It can only be attributable to human error. This sort of thing has cropped up before, and it has always been due to human error. |
|
Back to top |
|
 |
MB Developer |
Posted: Thu May 29, 2014 4:19 am Post subject: |
|
|
 Disciple
Joined: 03 Feb 2014 Posts: 179
|
Hi zpat and all,
Thanks for help .
Now my problem is solved I get messages.
ALTER QMGR DEADQ(SYSTEM.DEAD.LETTER.QUEUE)
ALTER QLOCAL(LQ) MAXDEPTH(10)
AMQSBCG SYSTEM.DEAD.LETTER.QUEUE QM2
0508 is 0805 hexadecimal to Decimal
In rules table properties are
REASON(*) ACTION(FWD) FWDQ(DLQ) FWDQM(DL2) HEADER(NO)
runmqdlq SYSTEM.DEAD.LETTER.QUEUE QM8 < DLQ.RUL
Thanks,
Suresh K
Last edited by MB Developer on Tue Mar 10, 2015 11:04 am; edited 1 time in total |
|
Back to top |
|
 |
zpat |
Posted: Thu May 29, 2014 4:52 am Post subject: |
|
|
 Jedi Council
Joined: 19 May 2001 Posts: 5866 Location: UK
|
That rule is going to send all messages on the DLQ to the other QM.
You need to use the DESTQ option to make sure you only process the ones that are relevant to this application. _________________ Well, I don't think there is any question about it. It can only be attributable to human error. This sort of thing has cropped up before, and it has always been due to human error. |
|
Back to top |
|
 |
|