| Author |
Message
|
| Tdak |
 Posted: Fri May 06, 2011 7:45 am Post subject: Report message could not be put on a reply-to queue |
 |
|
Novice
Joined: 30 Jun 2008
Posts: 18
Location: South Africa
|
Hi There
We having issues in our prod environment where messages are been generated to the dead-letter-queue on a specific channel. We get reason code 2087 due to that and we confirm the remote queue defined does exist. below is a strip of one of the messages:
the extract of the error is The attempt to put a report message on queue queuname on queue
manager tc_kqmgr failed with reason code 2087. The message will be put on the
MQGET of message number 1
****Message descriptor****
StrucId : 'MD ' Version : 2
Report : 0 MsgType : 4
Expiry : -1 Feedback : 259
Encoding : 273 CodedCharSetId : 819
Format : 'MQDEAD '
Priority : 4 Persistence : 1
MsgId : X'414D512063616C79706166725F716D674DC19E7C2603DA58'
CorrelId : X'414D512065655F70716D6772202020204DC164E82000FC49'
BackoutCount : 0
ReplyToQ : ' '
ReplyToQMgr : 'tc_kqmgr '
** Identity Context
UserIdentifier : 'mqm '
AccountingToken :
X'0332303600000000000000000000000000000000000000000000000000000006'
ApplIdentityData : ' '
** Origin Context
PutApplType : '7'
PutApplName : 'tc_kqmgr '
PutDate : '20110506' PutTime : '13111230'
ApplOriginData : ' '
GroupId : X'000000000000000000000000000000000000000000000000'
MsgSeqNumber : '1'
Offset : '0'
MsgFlags : '0'
OriginalLength : '-1'
**** Message ****
length - 172 bytes
00000000: 444C 4820 0000 0001 0000 0827 4545 5F54 'DLH .......'EE_T'
00000010: 4F5F 4252 4944 4745 5F53 5749 4654 2020 'O_BRIDGE_SWIFT '
00000020: 2020 2020 2020 2020 2020 2020 2020 2020 ' '
00000030: 2020 2020 2020 2020 2020 2020 6565 5F70 ' ee_p'
00000040: 716D 6772 2020 2020 2020 2020 2020 2020 'qmgr '
00000050: 2020 2020 2020 2020 2020 2020 2020 2020 ' '
00000060: 2020 2020 2020 2020 2020 2020 0000 0111 ' ....'
00000070: 0000 0333 4D51 5354 5220 2020 0000 0007 '...3MQSTR ....'
00000080: 6361 6C79 7061 6672 5F71 6D67 7220 2020 'calypafr_qmgr '
00000090: 2020 2020 2020 2020 2020 2020 3230 3131 ' 2011'
000000A0: 3035 3036 3133 3131 3132 3330 '050613111230 '
MQGET of message number 2
****Message descriptor****
StrucId : 'MD ' Version : 2
Report : 0 MsgType : 4
Could you please advise on what could possibly cause this. |
|
| Back to top |
|
 |
| bruce2359 |
| Posted: Fri May 06, 2011 8:00 am Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9469
Location: US: west coast, almost. Otherwise, enroute.
|
| Quote: |
00000000: 444C 4820 0000 0001 0000 0827 4545 5F54 'DLH .......'EE_T'
00000010: 4F5F 4252 4944 4745 5F53 5749 4654 2020 'O_BRIDGE_SWIFT '
00000020: 2020 2020 2020 2020 2020 2020 2020 2020 ' '
00000030: 2020 2020 2020 2020 2020 2020 6565 5F70 ' ee_p'
00000040: 716D 6772 2020 2020 2020 2020 2020 2020 'qmgr ' |
Please display and post the definition of 'ee_pqmgr' on the qmgr where the dead-letter queue is.
_________________
I like deadlines. I like to wave as they pass by.
ב''ה
Lex Orandi, Lex Credendi, Lex Vivendi. As we Worship, So we Believe, So we Live. |
|
| Back to top |
|
|
| mvic |
| Posted: Fri May 06, 2011 8:03 am Post subject: Re: Report message could not be put on a reply-to queue |
|
|
Jedi
Joined: 09 Mar 2004
Posts: 2080
|
The reason code in the 3rd word of the MQDLH block is 0x827 which, in decimal, is 2087. Using the "mqrc" program I can see this is MQRC_UNKNOWN_REMOTE_Q_MGR.
So it's the knowledge of how to reach a remote qmgr, not a remote q, that is the primary problem here.
You should use this information and knowledge of the qmgr connectivity to work out why the local qmgr did not know how to reach the remote qmgr. |
|
| Back to top |
|
|
| Tdak |
| Posted: Sun May 08, 2011 9:36 pm Post subject: |
|
|
Novice
Joined: 30 Jun 2008
Posts: 18
Location: South Africa
|
Thanks for the reply guys.
@Bruce - please find below the definition of the queue manager:
QMNAME(calypafr_qmgr) ACCTCONO(DISABLED)
ACCTINT(1800) ACCTMQI(OFF)
ACCTQ(OFF) ACTIVREC(MSG)
ALTDATE(2010-04-17) ALTTIME(08.23.53)
AUTHOREV(DISABLED) CCSID(819)
CHAD(DISABLED) CHADEV(DISABLED)
CHADEXIT( ) CHLEV(DISABLED)
CLWLDATA( ) CLWLEXIT( )
CLWLLEN(100) CLWLMRUC(999999999)
CLWLUSEQ(LOCAL) CMDLEVEL(600)
COMMANDQ(SYSTEM.ADMIN.COMMAND.QUEUE) CRDATE(2008-06-05)
CRTIME(18.47.26) DEADQ(calypafr_qmgr.DLQ)
DEFXMITQ( ) DESCR( )
DISTL(YES) INHIBTEV(DISABLED)
IPADDRV(IPV4) LOCALEV(DISABLED)
LOGGEREV(DISABLED) MAXHANDS(256)
MAXMSGL(20971520) MAXPRTY(9)
MAXUMSGS(10000) MONACLS(QMGR)
MONCHL(OFF) MONQ(OFF)
PERFMEV(DISABLED) PLATFORM(UNIX)
QMID(calypafr_qmgr_2008-06-05_18.47.26)
REMOTEEV(DISABLED) REPOS( )
REPOSNL( ) ROUTEREC(MSG)
SCHINIT(QMGR) SCMDSERV(QMGR)
SSLCRLNL( ) SSLCRYP( )
SSLEV(DISABLED) SSLFIPS(NO)
SSLKEYR(/mq/calypafr_qmgr/qmgrs/calypafr_qmgr/ssl/key)
SSLRKEYC(0) STATACLS(QMGR)
STATCHL(OFF) STATINT(1800)
STATMQI(OFF) STATQ(OFF)
STRSTPEV(ENABLED) SYNCPT
TRIGINT(999999999)
@Mavic we have confirmed the queue manager and it is valid. Is there some other way of confirming the connectivity of the remote queue manager, cause I'm using ping from the MQ explorer.
for interest sake, which tool do you use to convert the blocks to decimal? |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Sun May 08, 2011 9:43 pm Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
 Intercommunications manual  particularly the chapter about multiple hops.
Your problem is a communication problem where a DEFAULT path does not exist.
If you want to give us more information you will need to show the xmitq of the channel to the remote qmgr and any qmgr aliases you defined...
Have fun 
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Mon May 09, 2011 4:50 am Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9469
Location: US: west coast, almost. Otherwise, enroute.
|
| bruce2359 wrote: |
Please display and post the definition of 'ee_pqmgr' on the qmgr where the dead-letter queue is. |
Sorry, I wasn't specific enough.
Please post the queue definition called 'ee_pgmgr' on the qmgr where the dead-letter queue is.
Usually, there is a transmission queue (or a queue-manager-alias that resolves to the xmitq) with the same name as the qmgr where reply/report messages are put.
_________________
I like deadlines. I like to wave as they pass by.
ב''ה
Lex Orandi, Lex Credendi, Lex Vivendi. As we Worship, So we Believe, So we Live. |
|
| Back to top |
|
|
| Tdak |
| Posted: Mon May 09, 2011 5:13 am Post subject: |
|
|
Novice
Joined: 30 Jun 2008
Posts: 18
Location: South Africa
|
Hi Bruce
The definition is as follows:
AMQ8409: Display Queue details.
QUEUE(EE_TO_BRIDGE_SWIFT) TYPE(QREMOTE)
ALTDATE(2010-10-20) ALTTIME(10.19.44)
CLUSNL( ) CLUSTER( )
CLWLPRTY(0) CLWLRANK(0)
DEFBIND(OPEN) DEFPRTY(0)
DEFPSIST(YES) DESCR( )
PUT(ENABLED) RQMNAME(ee_pqmgr)
RNAME(EE_TO_BRIDGE_SWIFT) SCOPE(QMGR)
XMITQ(calypafr_qmgr.ee_pqmgr.XMITQ) |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Mon May 09, 2011 5:24 am Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9469
Location: US: west coast, almost. Otherwise, enroute.
|
| Tdak wrote: |
Hi Bruce
The definition is as follows:
AMQ8409: Display Queue details.
QUEUE(EE_TO_BRIDGE_SWIFT) TYPE(QREMOTE)
ALTDATE(2010-10-20) ALTTIME(10.19.44)
CLUSNL( ) CLUSTER( )
CLWLPRTY(0) CLWLRANK(0)
DEFBIND(OPEN) DEFPRTY(0)
DEFPSIST(YES) DESCR( )
PUT(ENABLED) RQMNAME(ee_pqmgr)
RNAME(EE_TO_BRIDGE_SWIFT) SCOPE(QMGR)
XMITQ(calypafr_qmgr.ee_pqmgr.XMITQ) |
Nope. EE_TO_BRIDGE_SWIFT is not a match for 'ee_pgmgr'.
When a message arrives at the receiving end of a channel, the MCA ponders if the message is destined for the qmgr it is connected to. In this case, the receiving end MCA connected to calypafr_qmgr?
The message is destined for 'ee_pqmgr' (see DLQ header.)
Since the MCA is not connected to ee_pqmgr, the MCA will then look (on the qmgr it is connected to) for a queue definition that resolves the name ee_pqmr. Is there a transmission queue called ee_pqmgr? No.
Is there a qmgr-alias called ee_pqmgr? No.
The MCA then puts the message in the DLQ as undeliverable.
_________________
I like deadlines. I like to wave as they pass by.
ב''ה
Lex Orandi, Lex Credendi, Lex Vivendi. As we Worship, So we Believe, So we Live. |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Mon May 09, 2011 5:57 am Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9469
Location: US: west coast, almost. Otherwise, enroute.
|
Uh, oh. The subject says report message... you may ignore my previous post.
So, the qmgr on the replying platform is trying to open a transmission queue called ee_pqmgr to put a report message; and the qmgr can't locate a q definition called ee_pqmgr; and it can't find a qmgr-alias called ee_pgmgr that resolves to the transmission queue needed to send the report msg back to the requesting app on its qmgr.
If this process once worked, it is possible that the requesting app has changed the name of the reply-to-queue-manager in the request message MD; OR someone on the replying qmgr has deleted the ee_pqmgr definition.
[edit] ...and I'm guessing that the reply message(s) didn't make it back to the requesting application, either.
[/edit]
_________________
I like deadlines. I like to wave as they pass by.
ב''ה
Lex Orandi, Lex Credendi, Lex Vivendi. As we Worship, So we Believe, So we Live. |
|
| Back to top |
|
|
|
|
