Tek-Tips is the largest IT community on the Internet today!

Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!

  • Congratulations strongm on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

Messages not put to destination queue

Status
Not open for further replies.

lbreton

Programmer
Jun 3, 2003
9
US
We are trying to set up a connection between 2 Unix Servers. The 1st server has the default qmgr sending info thru a xmitq to the 2nd server's Qmgr(not the default qmgr). The remote queue appears fine and the channels connect OK. However, when we put something in the remote Queue on the 1st server, we get an error that the message could not be put into the destination queue. The message ends up in the Dead Letter queue with no reason why? Any suggestions? Thanks!
 
When you say DLQ, i would assume that it is going into DLQ of the 2nd server(2nd qm). Check to see if the destination queue is not full and does exist. Check the reason code of the message that landed up on the DLQ and post it here to help further.

If the error is on 1st Server, Check to see if your channels from Qm1(1st server) to Qm2(2nd server) are in running state. If not, issue ping channel to see if the communcation is good. Then check the remote queue definition to see if it points to a valid queue at the other end.


Cheers
KK
 
Thanks KK. Yes it is ending up in the DLQ for the 2nd qm. The destination q is actually empty and does exists. I'm not sure where the reason code is in the DLQ. Here is the DLQ message. Where is the reason code? Thanks again for your help

****Message descriptor****

StrucId : 'MD ' Version : 2
Report : 0 MsgType : 8
Expiry : -1 Feedback : 0
Encoding : 273 CodedCharSetId : 819
Format : 'MQDEAD '
Priority : 0 Persistence : 0
MsgId : X'000000000000000000003835000000000000000000000000'
CorrelId : X'000000000000000000000000000000000000000000000000'
BackoutCount : 804397264
ReplyToQ : ' '
ReplyToQMgr : 'mqbatch1 '
** Identity Context
UserIdentifier : 'capsadm '
AccountingToken :
X'0335303200000000000000000000000000000000000000000000000000000006'
ApplIdentityData : ' '
** Origin Context
PutApplType : '6'
PutApplName : ' '
PutDate : '20030603' PutTime : '18285871'
ApplOriginData : ' '

GroupId : X'000000000000000000000000000000000000000000000000'
MsgSeqNumber : '1'
Offset : '0'
MsgFlags : '0'
OriginalLength : '-1'

**** Message ****

length - 208 bytes

00000000: 444C 4820 0000 0001 0000 0827 4C54 522E 'DLH .......'LTR.'
00000010: 5445 4D50 2E51 2020 2020 2020 2020 2020 'TEMP.Q '
00000020: 2020 2020 2020 2020 2020 2020 2020 2020 ' '
00000030: 2020 2020 2020 2020 2020 2020 4D51 4241 ' MQBA'
00000040: 5443 4831 2020 2020 2020 2020 2020 2020 'TCH1 '
00000050: 2020 2020 2020 2020 2020 2020 2020 2020 ' '
00000060: 2020 2020 2020 2020 2020 2020 0000 0111 ' ....'
00000070: 0000 0333 2020 2020 2020 2020 0000 0006 '...3 ....'
00000080: 7275 6E6D 716C 7372 5F6E 6420 2020 2020 'runmqlsr_nd '
00000090: 2020 2020 2020 2020 2020 2020 3230 3033 ' 2003'
000000A0: 3036 3033 3138 3238 3538 3831 3835 3832 '0603182858818582'
000000B0: 3237 2C33 3620 2020 2020 2020 202C 3230 '27,36 ,20'
000000C0: 3033 2D30 352D 3239 2C34 3336 3735 3131 '03-05-29,4367511
 
Hi Ibreton,

to find the reason code is a little bit difficult:

the message text begins with
00000000: 444C 4820 0000 0001 0000 0827 4C54 522E 'DLH .......'LTR.'

This is the beginnig of the Dead Letter Header=DLH (described in the WMQ Application Programming Reference).
The third word is the reason code: "0000 0827", it is in hex code and means 2087 = MQRC_UNKNOWN_REMOTE_Q_MGR .

Control your Destination QMGR fields: I see an qmgr called mqbatch1 in the Message descriptor and one "MQBATCH1" in the DLH; this field is case sensitive !

And one hint:
Don't work with default qmgr or other defaults, it's not transparent.


Regards, Norbert
 
Thanks Norbert. That helps a lot. I thought I found the problem ... the qmgrs are mqbatch1 but we had it as MQBATCH1 in the remote queue. I changed it to mqbatch1 but now I get the following error when I try to put a message in the remote queue:

amqsput TO.AZCAPS03.LTR
Sample AMQSPUT0 start
target queue is TO.AZCAPS03.LTR
MQOPEN ended with reason code 2087
unable to open queue for output
Sample AMQSPUT0 end

If I change the Remote queue back to MQBATCH1 I can put the message in the queue but get the original issue. Any help would be greatly appreciated!
 
Please show me the definitions of qmgr1:
- remote queue 'display qr(...) all'
- xmit queue 'display ql(...) all'
- channel 'display chl(...) all'
and of qmgr2:
- qmgr 'display qmgr(...) all'
- destination q 'display ql(...) all'

You do this by the command interface 'runmqsc ....' (.... is the qmgr).


Regards, Norbert
 
Again, thanks for your help! here is the info you requested:

qmgr1:

remoteQ:
AMQ8409: Display Queue details.
DESCR( ) RNAME(LTR.TEMP.Q)
RQMNAME(mqbatch1) XMITQ(TO.AZCAPS03.XMITQ)
CLUSTER( ) CLUSNL( )
QUEUE(TO.AZCAPS03.LTR) ALTDATE(2003-06-10)
ALTTIME(06.36.17) PUT(ENABLED)
DEFPRTY(0) DEFPSIST(NO)
SCOPE(QMGR) DEFBIND(OPEN)
TYPE(QREMOTE)

xmitq:
AMQ8409: Display Queue details.
DESCR( ) PROCESS( )
BOQNAME( ) INITQ( )
TRIGDATA( ) CLUSTER( )
CLUSNL( ) QUEUE(TO.AZCAPS03.XMITQ)
CRDATE(2003-04-29) CRTIME(12.36.22)
ALTDATE(2003-06-10) ALTTIME(05.56.25)
GET(ENABLED) PUT(ENABLED)
DEFPRTY(0) DEFPSIST(NO)
MAXDEPTH(5000) MAXMSGL(4194304)
BOTHRESH(0) SHARE
DEFSOPT(SHARED) HARDENBO
MSGDLVSQ(PRIORITY) RETINTVL(999999999)
USAGE(XMITQ) TRIGGER
TRIGTYPE(FIRST) TRIGDPTH(1)
TRIGMPRI(0) QDEPTHHI(80)
QDEPTHLO(20) QDPMAXEV(ENABLED)
QDPHIEV(DISABLED) QDPLOEV(DISABLED)
QSVCINT(999999999) QSVCIEV(NONE)
DISTL(YES) DEFTYPE(PREDEFINED)
TYPE(QLOCAL) SCOPE(QMGR)
DEFBIND(OPEN) IPPROCS(1)
OPPROCS(1) CURDEPTH(0)

Channel:
AMQ8414: Display Channel details.
CHANNEL(TO.AZCAPS03.CH) CHLTYPE(SDR)
TRPTYPE(TCP) DESCR( )
XMITQ(TO.AZCAPS03.XMITQ) MCANAME( )
MODENAME( ) TPNAME( )
BATCHSZ(50) DISCINT(0)
SHORTRTY(10) SHORTTMR(60)
LONGRTY(999999999) LONGTMR(1200)
SCYEXIT( ) SEQWRAP(999999999)
MAXMSGL(4194304) CONVERT(NO)
SCYDATA( ) USERID( )
PASSWORD( ) MCATYPE(PROCESS)
CONNAME(---.--.---.---(1415)) HBINT(300)
BATCHINT(0) NPMSPEED(FAST)
MCAUSER(MQM) ALTDATE(2003-06-03)
ALTTIME(11.29.56)
MSGEXIT( )
SENDEXIT( )
RCVEXIT( )
MSGDATA( )
SENDDATA( )
RCVDATA( )


qmgr2:

AMQ8408: Display Queue Manager details.
DESCR( ) DEADQ(SYSTEM.DEAD.LETTER.QUEUE)
DEFXMITQ( ) CHADEXIT( )
CLWLEXIT( ) CLWLDATA( )
REPOS( ) REPOSNL( )
COMMANDQ(SYSTEM.ADMIN.COMMAND.QUEUE) QMNAME(mqbatch1)
CRDATE(2003-04-11) CRTIME(05.38.25)
ALTDATE(2003-04-30) ALTTIME(06.20.49)
QMID(mqbatch1_2003-04-11_05.38.25) TRIGINT(999999999)
MAXHANDS(256) MAXUMSGS(10000)
AUTHOREV(DISABLED) INHIBTEV(DISABLED)
LOCALEV(DISABLED) REMOTEEV(DISABLED)
PERFMEV(DISABLED) STRSTPEV(ENABLED)
CHAD(DISABLED) CHADEV(DISABLED)
CLWLLEN(100) MAXMSGL(4194304)
CCSID(819) MAXPRTY(9)
CMDLEVEL(520) PLATFORM(UNIX)
SYNCPT DISTL(YES)

AMQ8409: Display Queue details.
DESCR( ) PROCESS( )
BOQNAME( ) INITQ( )
TRIGDATA( ) CLUSTER( )
CLUSNL( ) QUEUE(LTR.TEMP.Q)
CRDATE(2003-04-29) CRTIME(12.22.46)
ALTDATE(2003-04-29) ALTTIME(12.24.02)
GET(ENABLED) PUT(ENABLED)
DEFPRTY(0) DEFPSIST(YES)
MAXDEPTH(100000) 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)

 
Do you have an alias queue defined somewhere on either of the 2 qms and expecially mqbatch1. Because your config looks fine. While looking at the output from bcg from your earlier post, one thing was fishy. Your replytoqmgr showed the same name as your destination queue manager which is wrong. It should show the originating qm under normal circumstances. Also do you use the supplied sample amqsput or did you write one by yourself. If you have written can you post the code here.

Whats the name of the other queue manager. Can you get dis qmgr on qmgr1.




Cheers
KK
 
KK,

both qmgrs are called mqbatch1. They are just on different servers. As for the amqsput, we're using the sample. Thanks
 
Oh boy !

You never, never, NEVER !, can connect two QMGR's with the same name !!!!
 
Then thats my problem. Thanks so much for everyone's help. Do you know if there is documentation out there describing why the same named qmgrs cannot be connected to each other? I'd like to pass this on to others in my organization. Again, I appreciate all the help!!
 
Hmmm...

The reason this fails is because when you put the name of the local queue manager in the RQMNAME attribute, the queue manager agent gets confused. It is unable to resolve the destination queue as it doesnt know if it should resolve it against a remote queue manager or the local one. But since this queue is a remote queue, it never looks up locally. This confused state is the cause for 2087.

As for the docs, it may be at many places.

But take a look at the messages manual for reason code 2087.
It clearly states that you get this when rqmname is the name of the local queue manager.



Cheers
KK
 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top