Author |
Message
|
LemonJelly |
Posted: Mon Nov 27, 2006 4:38 am Post subject: [SOLVED]Messages going straigth to dead letter queue |
|
|
Novice
Joined: 24 Nov 2006 Posts: 23
|
I am sending messages from 1 q manager to another.
The messages seem to go onto the transmission q, and across to the other 1 manager but then straight to the dead letter q.
The message should be picked up on the local q by a mdb listener but instead is ending up on the dead letter q.
Any suggestions?
Ta
Last edited by LemonJelly on Tue Dec 05, 2006 4:46 am; edited 1 time in total |
|
Back to top |
|
 |
Vitor |
Posted: Mon Nov 27, 2006 4:42 am Post subject: |
|
|
 Grand High Poobah
Joined: 11 Nov 2005 Posts: 26093 Location: Texas, USA
|
What's the reason code in the DLH? _________________ Honesty is the best policy.
Insanity is the best defence. |
|
Back to top |
|
 |
Nigelg |
Posted: Mon Nov 27, 2006 4:47 am Post subject: |
|
|
Grand Master
Joined: 02 Aug 2004 Posts: 1046
|
The qmgr error logs on either the sending qmgr or receviving qmgr should have an entry with he reason the msg is being written to the DLQ. The msg is probably AMQ9544, with text like:
Quote: |
During the processing of channel 'CHLNAME' one or more messages
could not be put to the destination queue and attempts were
made to put them
to a dead-letter queue. The location of the queue is NN,
where 1 is the local dead-letter queue and 2 is the remote
dead-letter queue. |
_________________ MQSeries.net helps those who help themselves.. |
|
Back to top |
|
 |
Vitor |
Posted: Mon Nov 27, 2006 4:55 am Post subject: |
|
|
 Grand High Poobah
Joined: 11 Nov 2005 Posts: 26093 Location: Texas, USA
|
Though if I had to guess, I'd guess the target queue was missing, misspelt or otherwise unusable.
Just a guess though. _________________ Honesty is the best policy.
Insanity is the best defence. |
|
Back to top |
|
 |
LemonJelly |
Posted: Mon Nov 27, 2006 4:59 am Post subject: |
|
|
Novice
Joined: 24 Nov 2006 Posts: 23
|
Vitor wrote: |
Though if I had to guess, I'd guess the target queue was missing, misspelt or otherwise unusable.
Just a guess though. |
AMQ9544: Messages not put to destination queue.
EXPLANATION:
During the processing of channel 'CHN NAME' one or more messages could not
be put to the destination queue and attempts were made to put them to a
dead-letter queue. The location of the queue is 1, where 1 is the local
dead-letter queue and 2 is the remote dead-letter queue.
ACTION:
Examine the contents of the dead-letter queue. Each message is contained in a
structure that describes why the message was put to the queue, and to where it
was originally addressed. Also look at previous error messages to see if the
attempt to put messages to a dead-letter queue failed. The program identifier
(PID) of the processing program was '6031'. |
|
Back to top |
|
 |
Vitor |
Posted: Mon Nov 27, 2006 5:19 am Post subject: |
|
|
 Grand High Poobah
Joined: 11 Nov 2005 Posts: 26093 Location: Texas, USA
|
LemonJelly wrote: |
ACTION:
Examine the contents of the dead-letter queue. Each message is contained in a
structure that describes why the message was put to the queue, and to where it
was originally addressed. |
And so I repeat, what's the reason code given????
This log message says nothing not already known, nor any diagnostic tips not already imparted. _________________ Honesty is the best policy.
Insanity is the best defence. |
|
Back to top |
|
 |
LemonJelly |
Posted: Mon Nov 27, 2006 5:21 am Post subject: |
|
|
Novice
Joined: 24 Nov 2006 Posts: 23
|
Vitor wrote: |
Though if I had to guess, I'd guess the target queue was missing, misspelt or otherwise unusable.
Just a guess though. |
RQ and LQ definition look ok ...
remote q des:
DESCR()
RNAME(AML.AMLS.MED.TOIN) RQMNAME(SUNSCB.QUEUE.MANAGER)
XMITQ(MED.XMIT.DF) CLUSTER( )
CLUSNL( ) QUEUE(AML.SAA.MED.TO)
ALTDATE(2006-11-23) ALTTIME(16.25.25)
PUT(ENABLED) DEFPRTY(0)
DEFPSIST(YES) SCOPE(QMGR)
DEFBIND(OPEN) TYPE(QREMOTE)
local q des
DESCR(Suspect Message from Mediator to SAA)
PROCESS( ) BOQNAME( )
INITQ( ) TRIGDATA( )
CLUSTER( ) CLUSNL( )
QUEUE(AML.AMLS.MED.TOIN) CRDATE(2006-11-27)
CRTIME(12.47.11) ALTDATE(2006-11-27)
ALTTIME(12.47.11) GET(ENABLED)
PUT(ENABLED) DEFPRTY(0)
DEFPSIST(YES) MAXDEPTH(5000)
MAXMSGL(4194304) BOTHRESH(0)
SHARE DEFSOPT(SHARED)
HARDENBO MSGDLVSQ(PRIORITY)
RETINTVL(999999999) USAGE(NORMAL)
NOTRIGGER TRIGTYPE(FIRST)
TRIGDPTH(1) TRIGMPRI(0)
QDEPTHHI(80) QDEPTHLO(20)
QDPMAXEV(ENABLED) QDPHIEV(DISABLED)
QDPLOEV(DISABLED) QSVCINT(999999999)
QSVCIEV(NONE) DISTL(NO)
DEFTYPE(PREDEFINED) TYPE(QLOCAL)
SCOPE(QMGR) DEFBIND(OPEN)
IPPROCS(0) OPPROCS(0)
CURDEPTH(0) |
|
Back to top |
|
 |
Vitor |
Posted: Mon Nov 27, 2006 5:23 am Post subject: |
|
|
 Grand High Poobah
Joined: 11 Nov 2005 Posts: 26093 Location: Texas, USA
|
How many times do I need to ask about the RC in the DLH before you post it? It will remove the need to guess by saying what's wrong.....  _________________ Honesty is the best policy.
Insanity is the best defence. |
|
Back to top |
|
 |
LemonJelly |
Posted: Mon Nov 27, 2006 6:51 am Post subject: |
|
|
Novice
Joined: 24 Nov 2006 Posts: 23
|
Vitor wrote: |
How many times do I need to ask about the RC in the DLH before you post it? It will remove the need to guess by saying what's wrong.....  |
opps...
ok im not entirely sure how to retrive this code.
When I open the message in hermes I get:
JMS Message class: jms_bytes
JMSType: null
JMSDeliveryMode: 2
JMSExpiration: 0
JMSPriority: 4
JMSMessageID: ID:414d5120616c6368616978312e717565456acb6020000201
JMSTimestamp: 1164626791560
JMSCorrelationID:null
JMSDestination: null
JMSReplyTo: null
JMSRedelivered: false
JMSXDeliveryCount:1
JMS_IBM_MsgType:8
JMSXAppID:
JMS_IBM_Format:MQDEAD
JMS_IBM_Encoding:273
JMS_IBM_PutApplType:6
JMS_IBM_Character_Set:ISO8859_1
JMSXUserID:all_adm
JMS_IBM_PutTime:11263156
JMS_IBM_PutDate:20061127
Integer encoding: 1, Floating point encoding 256
444c4820000000010
0000827414d4c2e414d4c532e4d45442e544f494e2020202020202020202020
202020202020202020202020202020202020202053554e5343422e51554555452e4d414e41474552
2020202020202020202020202020202020202020202020202020202000000111000003334d514852
4632202000000006616d71726d707061202020202020202020202020202020202020202032303036
3131323730393031313937385246482000000002000000b400000111000004b84d51535452202020
00000000000004b8000000203c6d63643e3c4d73643e6a6d735f746578743c2f4d73643e3c2f6d63
643e2020000000683c6a6d733e3c4473743e71756575653a2f2f616c6368616978312e7175657565
2e6d616e616765722f414d4c2e5341412e4d45442e544f3c2f4473743e3c546d733e313136343632
363739313535393c2f546d733e3c446c763e323c2f446c763e3c2f6a6d733e203c4d657373616765
3e0a3c49643e3c215b43444154415b49424f46494945324458585831303331323334353637383930 |
|
Back to top |
|
 |
Vitor |
Posted: Mon Nov 27, 2006 7:00 am Post subject: |
|
|
 Grand High Poobah
Joined: 11 Nov 2005 Posts: 26093 Location: Texas, USA
|
Spend a few minutes browsing the documentation and you'll discover that all messages are put on to a dead letter queue with a dead letter header in front of the data (hence the message format MQDEAD). This header, like the MQMD, has a specific format. Hence you can interogate the data to find the value of the DLH which contains the reason code of why the queue manager saw fit to put it there.
At worst, count the number of bytes in that the reason code is in the structure, count that number of bytes into the message and decode the reason. Other methods are possible, and are an exercise for the reader...
(Hint - view the message in mixed hex / txt format. Makes it easier...) _________________ Honesty is the best policy.
Insanity is the best defence.
Last edited by Vitor on Mon Nov 27, 2006 7:23 am; edited 1 time in total |
|
Back to top |
|
 |
Vitor |
Posted: Mon Nov 27, 2006 7:16 am Post subject: |
|
|
 Grand High Poobah
Joined: 11 Nov 2005 Posts: 26093 Location: Texas, USA
|
Another hint - the structure is in the Application Programming Reference.
On the plus side, the reason code you're getting is fairly self explainitory.
Once you've discovered the problem, can I draw to your attention the dead letter handler? May save you some time in your problem resolution and is a good thing to have in the back pocket for next time. You'll find it laid out in the System Administration Guide.
(When I talk about manuals, I of course include their online, web based equivalents) _________________ Honesty is the best policy.
Insanity is the best defence. |
|
Back to top |
|
 |
LemonJelly |
Posted: Mon Nov 27, 2006 8:24 am Post subject: |
|
|
Novice
Joined: 24 Nov 2006 Posts: 23
|
Vitor wrote: |
Spend a few minutes browsing the documentation and you'll discover that all messages are put on to a dead letter queue with a dead letter header in front of the data (hence the message format MQDEAD). This header, like the MQMD, has a specific format. Hence you can interogate the data to find the value of the DLH which contains the reason code of why the queue manager saw fit to put it there.
At worst, count the number of bytes in that the reason code is in the structure, count that number of bytes into the message and decode the reason. Other methods are possible, and are an exercise for the reader...
(Hint - view the message in mixed hex / txt format. Makes it easier...) |
Can I assume that I have all the info on the message as posted above?
Im still a little stumped on what im looking for |
|
Back to top |
|
 |
Vitor |
Posted: Mon Nov 27, 2006 8:31 am Post subject: |
|
|
 Grand High Poobah
Joined: 11 Nov 2005 Posts: 26093 Location: Texas, USA
|
You certainly have!
Let's break this down:
1) Have you satisifed yourself that the message contains a dead letter header?
2) Are you clear what this header is for and how it's produced?
3) Have you found the explaination of the structure, and the reason code therein?
4) Have you used this information to extract the code?
5) Have you looked up this code and determined what's causing the message to go to the DLQ?
6) Have you formulated a way to resolve the issue?
7) Have you found the explaination of the dead letter hander?
Have you written rules to apply, via the handler, to the message?
About where do you get stumped? What is unclear? What do I need to explain better? Have you searched the forum for other, possibly clearer & better descriptions of the steps you must take?
Work methodically through it - you will reap the benefits when resolving future problems. _________________ Honesty is the best policy.
Insanity is the best defence.
Last edited by Vitor on Mon Nov 27, 2006 8:39 am; edited 1 time in total |
|
Back to top |
|
 |
LemonJelly |
Posted: Mon Nov 27, 2006 8:38 am Post subject: |
|
|
Novice
Joined: 24 Nov 2006 Posts: 23
|
Vitor wrote: |
You certainly have!
Let's break this down:
1) Have you satisifed yourself that the message contains a dead letter header
No. This is what I am trying to figure how to extract.
2) Are you clear what this header is for and how it's produced?
Yes
3) Have you found the explaination of the structure, and the reason code therein?
Yes. But need to identify the reason code from above 1st
4) Have you used this information to extract the code?
No as I havnt identified it yet
5) Have you looked up this code and determined what's causing the message to go to the DLQ?
No as I havnt identified it yet
6) Have you formulated a way to resolve the issue?
7) Have you found the explaination of the dead letter hander?
Have you written rules to apply, via the handler, to the message?
About where do you get stumped? |
|
|
Back to top |
|
 |
Vitor |
Posted: Mon Nov 27, 2006 8:42 am Post subject: |
|
|
 Grand High Poobah
Joined: 11 Nov 2005 Posts: 26093 Location: Texas, USA
|
Don't get too sophisticated - the reason code is just a numeric field. You know where the header is (point 2) and it's structure (point 3) so you can locate the code (point 4).
All you need is a means to locate the code within the header and read it off. I used my finger on your post, but other methods are possible.....  _________________ Honesty is the best policy.
Insanity is the best defence. |
|
Back to top |
|
 |
|